本文目录导航：
矫捷交付中的智能化测试
提到矫捷交付，咱们总会说到继续集成，继续交付，继续颁布，即频繁地交付产品个性。而咱们都知道要成功真正的继续交付，肯定少不了两个关键因素：
只要测试不行，只要集成工具也不行，二者需合二为一，坚持相反的步伐，成功继续始终的质量反应，方能成功保质地继续颁布。
可以开业见山地说：Automation Test ≠ Automation Tools ≠ Continuous Test
依据我团体的名目阅历，试着画了上方这个图来表白这三者的相关。
在提及智能化测试的时刻，很多人会把工具的经常使用同等于智能化测试。
智能化测试应该是一个战略性的系统工程，不只要智能化工具。
像咱们的产品一样，不只要有技术言语，还要有产品架构设计。
智能化测试除了工具框架，还须要思考：
名目的技术栈，产品架构，开发流程，基础设备，牢靠的测试数据，稳固洁净的测试环境，如何出现测试报告，如何工程化测试性能，测试套件等等。
有了智能化测试还不够，咱们的目的是在继续交付的环节中成功极速频繁的质量反应，咱们须要继续始终地测试（Continous Testing)。
成功继续测试，不只须要团队从文明上去允许，真正做到全员对测试和质量担任，创立Devops文明气氛，买通开发-测试-运维的壁垒；还需团队从技术上去储藏常识，比如云平台、虚构化技术，容器及相应的编排技术，甚至网络常识等等。
维基百科对智能化的解释：
In software testing, test automation is the use of software separate from the software being tested to control the execution of tests and the comparison of actual outcomes with predicted outcomes.
从定义可以总结出智能化测试的两个特点：
测试，质量评价的关键手腕之一，而智能化测试只是测试的一种详细成功模式而已。
它能监禁QA的双手和一局部大脑（这局部大脑，即know knowns），将对已知个性和既定逻辑流程的检测交由计算机来成功。
而QA去做更多须要思辨才干，剖析判别才干的事件。
例如，经过向团队提问，来廓清需求的unknowns；经过探求产品去拓宽对产品的knowns；抑或运用阅历协助团队走出Unknown Unknowns 带来的迷局。
维基百科对继续测试的解释：
Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate.
从这个定义可以看出，继续测试的目的即在软件交付的流水线中口头智能化测试以提供对产质量量的反应。
想强调定义里的几个关键字：automated tests, delivery pipeline, immediate feedback, business risks.
不论多火的工具，假设不能兼容名目的技术栈和基础设备，那都无处施展其长处，盛行的不肯定是适宜名目的。
在写智能化之前，QA须要对名目的技术栈，开发流程，和基础设备有基本的看法和了解；另外也须要了解和把握各个工具之间的优劣，这样才干为名目决定最婚配的智能化工具。
是不是像老生常谈？然而他人通知你的阅历和自己阅历的实战真的两种不同的收获。
就跟蹲家看电视和去现场看演唱会的区别一样，他人的阅历之谈总归是他人的，自己走过的路才是自己的。
这两年 Cypress 真的很火，去年在名目上做UI智能化测试的时刻，出于猎奇也想通常一把。
通常出真知，Cypress自身可以经过环境变量和plugin性能代理，然而不允许socks5的代理（主观现状是名目一切资产，包括测试环境都是经过socks5的代理衔接），线上环境无法访问。
过后还试过将socks5的代理转换成http代理，但由于Cypress自身是多线程的，而socks5只能截获第一个进程的网络通讯， 即使能连通运行自身，Cypress也无法将测试环节可视化的长处施展出来。
人无完人，工具也一样，只要适宜你的才是好的。
思考自己也不会造轮子，青睐拿来就用，加之名目上socks5代理解放，之后便转用了CodeceptJS, 几次尝试上去，觉得十分满足名目须要。
上方列举CodeceptJS 几个好用的点，详细细节请移步 官方 。
由于团队有齐全的自在来决定技术栈，在做第三个产品的时刻， 咱们的开发小哥哥就曾经不满足于只写REST API了，第三个产品开局引入GraphQL。
在以前的名目上用过REST Assured 做API测试，觉得也是好用的，但过后并没有决定REST Assured, 由于在那时，刚好发现一枚ThouhgtWorks开发自己做的API性能测试工具Pandaria 。
（这也从正面证实TW的开发很有质量看法）决定这个工具，除了自己不会造轮子，除了它允许代理，更关键的是它基于Cucumber JVM，我团体以前的名目上用过cucumber，对gherkin语法还算相熟，还有它能提供美丽的测试报告。
它既允许REST API的测试，也允许GraphQL 的测试，完美婚配我团体的技术和名目的实践状况。
在名目做第一个规范安保流程的产品时，MVP1(Minimum Viable Product) 一成功，该产品的接口智能化测试和端到端智能化测试便成功了，并集成到了产品CI/ CD 流水线上。
后因由于客户方配件集成的疑问，该产品基于MVP1启动了一次性演进，从产品间接融入并规范安保流程换成了‘曲线救国’地强化安保流程，页面和接口设计也有较大变化。
由于产品流程设计上的变化造成之前的接口测试和端到端的智能化测试所有都失效，须要从新编写和保养。
这个阅历挺实在的，智能化是无好处，然而也是有代价的： 在MVP1，特意是POC（Proof Of Concept)阶段的产品倡导不要急于做智能化，名目的初期更别尝试做UI层面的智能化。
当然对工具的spike是可以的，把框架搭建好，期待个性稳固了，就可以间接加测试用例了。
咱们决定智能化肯定是要思考名目能否存在主观的事实需求，在入手实施详细的智能化测试之前，肯定要对智能化测试的投入产出比做一次性主观理性地评价。
如上图所示，智能化测试的老本相对单次（或许大批的）手动测试来说是较高的，为了大批的测试优惠而做智能化，投入产出比是很低的。
须要QA依据名目进展，产品演进水平，测试战略，回归频率等等做一个综合评价，找到出图中交加的点，即何时何种状况团队和产品应该肯定引入智能化测试了。
由于智能化前期须要投入产品剖析，工具框架选型，用例设计，数据环境预备等等，前期还须要继续始终地投入人力启动及时的保养和降级以保障智能化测试的严密性和足够的笼罩率。
只管矫捷强调质量全员担任，但我所待过的团队，做过的名目，践行得好的很少。
幸运的是，如今团队的质量看法都很好。
但故事一开局不都是美妙的，每个团队都是在 “掉坑-反应-调整磨合” 的循环里走向成熟的。
在交付一个微服务化的产品时，后端多个API，每个API有相应的API集成测试，产品还有UI测试，同时团队还有额外的3个产品须要保养。
每个产品都有智能化测试，前端的后端的。
其中一个微服务虚现的产品就有四套测试，而且后续还会参与视觉测试。
在刚开局的时刻，测试挂了没人去看，也没人去修。
由于名目是基于 Trunk based Development ，为了保障测试的及时性，每天不是在加新用例的路上，就是在修各种测试的路上。
UI测试相较于API测试更为软弱，须要频繁的保养老本，特意是名目基于骨干开发的团队。
那段期间觉得自己成了automation engineer，对产品新增的性能个性并不是十分分明，对故事卡的可测性也没及时作出反应，觉得智能化并未真的到达监禁自己精神和期间的初衷。
假设只是QA一团体来保养治理，那么这个QA肯定做不了智能化以外的事件了。
ThoughtWorks好多名目都只要一个QA，咱们的这个QA是Quality Analyst， 并不是Automation Engineer。
矫捷名目之下，QA的首要义务应该是驱动团队各个角色对质量担任。
为了优化团队对智能化测试的注重水平， 如下是一些我团体在名目上通常过的方法：
除了以上，名目还须要有高度可视化或许能及时通知测试形态的模式。
名目上用的是Jenkins自带的 Build Monitor View。
将对名目pipeline的监控投影到电视上，并性能相应的提醒音，能十分及时地让团队知道最新的构建，部署，测试形态。
如下是咱们名目上以后的一个流水线dashboard：
这些通常都是对‘质量全员担任’最落地的践行。
我置信，每个团队是不一样的，然而矫捷QA的关键价值肯定是能驱动团队为质量作出改良和奉献。
矫捷QA是对名目流程质量，产品外部质量，产品外部质量都须要担任的，而智能化测试只是质量保障的一种措施而已而非惟一措施。
‘质量全员担任’的团队才干监禁出你们的QA，去做更多Quality Analysis的上班，比如提更多须要思辨才干的疑问以成功产品危险的识别和治理，反思开发流程以促成团队流程质量的优化，剖析产品架构制订适宜名目产品的全体测试战略等等。
在名目上做智能化集成到流水线的时刻，有遇到一些经常出现的在云容器里运转测试会遇到的疑问。
1）测试工具相关的
只管很多疑问都是可以从网上找到答案，然而在处置疑问的时刻，通常须要咱们了解工具框架的上班原理，否则连搜查关键字或许都憋不出来。
2）测试报告可视化相关的
测试报告关于咱们极速定位失败根因有很大的协助，好的测试报告可以间接提醒疑问的根源。
在云端运转测试，咱们通常宿愿测试工具能输入可读性强的测试报告以繁难非技术人员阅读，也宿愿测试工具能把运转环节的细节打印在console里，以繁难技术人员定位根因。
像前面提到的CodeceptJS它就提供多种不同外形的运转，并且可以运用Mocha生成各种类型的测试报告。
目前市面上的测试工具，都会有对第三方库的依赖，特意是前端测试框架和工具，这个对QA或许团队的技术宽度是有肯定要求的。
另外Jenkins有十分丰盛的插件库，在决定测试工具的时刻可以把能否有Jenkins报告可视化允许思考出来。
QA须要对Jenkins和测试工具都相当相熟，还须要知道如何经过将某一测试工具生成的某种格局的测试报告集成在Jenkins上以繁难一键失掉测试报告。
像cucumber的测试报告插件：
像Allure的测试报告插件：
有了这些插件的辅佐，在流水线上就一键可得测试报告，为‘质量团队担任’提供了很好的契机。
3） Pipeline as Code,想要集成测试到流水线，无法防止是须要一些DevOps相关常识的
兴许名目的需求是如何经过Jenkinsfile 并行运转各种测试，兴许是经过Jenkinsfile传递测试相关参数认为云上运转测试所用，还兴许你须要在Jenkinsfile里参与调试消息用以线上调试，等等。
云上运转，咱们还要学会如何在一个slave 上优雅地治理运转测试的容器，不出现容器占用，slave内存无余，测试失败之后报告无法得等等疑问。
所以只会智能化工具不够，只要智能化测试也不够。
假设你们团队开发们没有DevOps的阅历，或许他们忙于个性开发，上线冲刺，那么QA肯定对Docker，Kubernetes 基本命令和用法有些了解。
QA就是一个不分前后端，不挑技术栈，须要继续始终学习的角色。
会智能化工具算是有了织网的道具，有智能化测试资产算是编出了能捞鱼的网，而继续测试才干真正地成功继续交付，才算是把一张张过滤不同毛病的网搁置于了始终提交变卦的交付之流中。
只要网而无法至于河里，或许不知道于何处搁置，那就只能站于岸边时时撒网捕鱼，不够及时，也不算监禁了捕鱼人 （QA和团队) 。
咱们希冀的是，各种不同的网 （智能化测试资产） ，置于不同的河段（ 软件产品不同层级：函数级别？组件级别？接口级别？系统级别？） ，过滤不同的鱼 （毛病） ，而不论是谁 （团队的一切角色） 都可以去确认有没有捞着鱼 （测试挂了吗？为什么挂？咱们对目前的变卦有足够的信念吗？） ，也须要一切人时时确认咱们的渔网是不是破了？ （测试笼罩率不够？断言不谨严？测试用例过期？） 。
软件交付是一项团队上班，即使智能化测试也一样须要全员单干。
文/ThoughtWorks郭泰瑜
如何应用jenkins来做android智能化
如何应用jenkins来做android智能化 概述继续集成是一种软件开发通常，即团队开发成员经常集成他们的上班，通常每个成员每天至少集成一次性，也就象征着每天或许会出现屡次集成。
每次集成都经过智能化的构建（包括编译，颁布，智能化测试)来验证，从而尽快地发现集成失误。
许多团队发现这个环节可以大大缩小集成的疑问，让团队能够更快的开发内聚的软件。
其中蕴含一些代码静态审核工具，智能打包和智能测试性能。
继续集成流程环境性能启动Jenkins1、装置jdk从略，倡导1.6或以上版本，性能好环境变量。
2、装置tomcat从略，装置完调试下tomcat能否反常。
3、装置ant下载zip包，解压后性能好环境变量。
4、装置jenkins下载war包，命名为Jenkins，拷贝到tomcat/webapps目录下。
5、装置Android SDK下载装置,成功后性能好Android_SDK_HOME环境变量。
此步骤关键用于启动android智能化测试，若不启动此项可略过。
装置成功后启动tomcat/bin/文件(linux下是)，在阅读器输入，8080为tomcat端口，即可访问jenkins主机。
性能Jenkins1、JDK性能新增JDK，指定JDK名字和JAVA_HOME2、ANT性能新增ANT，指定ANT名字和ANT_HOME3、Maven性能从略，本文未经常使用到Maven，详细性能方法参考Google。
4、Subversion决定1.6版本SVN，勾选Update default Subversion credentialscache after successful authentication5、邮件通知填写SMTP server、Default user E-mail suffix、System Admin E-mail Address、Jenkins URL、勾选Use SMTP Authentication，填写User Name、Password、Use SSL、SMTP port、Chareset(UTF-8) 、Default Content Type(自动)、Default Recipients(自动收件人)，性能成功后可启动测试邮件。
6、Jenkins URL性能该URL，用于他人访问。
插件治理1、Hudson Subversion Plug-in，jenkins的svn插件。
2、Android Emulator Plugin，android模拟器插件。
3、JUnit Attachments Plugin，junit测试报告附件插件。
4、Email-ext plugin，邮件裁减插件。
此处说明下，自动Jenkins只会发送构建失败的邮件，咱们需装置此插件才干自定义不同场景。
5、Deploy to container Plugin远程颁布插件。
智能化测试打包源工程Android程序本小节讲诉如何打包一个Android工程，以后经常使用的是ant启动编译源码。
1、首先构建一个自在格调的Job。
2、参与源码门路，决定所经常使用的版本控制器，输入源码门路。
3、构建触发器可依据须要决定能否认时构建。
4、构建环境，此处Jenkins装置了Android Emulator Plugin插件，可以启动已有模拟器或参与新的模拟器，本文案例中经常使用真机调试。
5、构建，卸载手机边疆程序 adb –s uninstall 6、生成文件，-p前面跟工程所在的本地jenkins下门路android update project -n *** c:\被测工程Job门路\workspace7、Ant启动编译程序，并装置到以后手机中ant debug install -f c:\被测工程Job门路\workspace\8、构建后操作，本案例中构建成功后智能启动构建下一个测试JobBulid other projects，决定测试工程的Job.打包测试工程Android程序本小节讲诉如何构建一个Android测试工程，包括邮件发送和测试报告展现。
1、构建步骤1-7和Android程序章节一样，从略。
2、本文案例中测试程序是经过命令行启动运转的，所以在此处参与一个批处置运转。
P.S. adb shell am instrument -w -e class #testDeleteContact / ，此处是经过批处置来独自运转一个个的测试用例。
防止了Junit3的无序口头的疑问。
3、删除Workspace边疆来存在的测试报告文件，普通不删除也会笼罩。
如何让测试程序生成xml格局的测试报告，其余文章会重点引见。
4、从手机中拷贝测试报告，最终测试是在手机上运转，所以报告也生成在手机中，经常使用adb pull命令把测试报告所有拷贝到workspace下制订目录。
5、构建后操作，颁布测试报告，假设报告中蕴含附件，此处经常使用到JUnit Attachments Plugin插件。
6、邮件通知，此处经常使用到Email-ext plugin插件，前面的自动，间接经常使用咱们在系统治理外面设置的自动值。
7、点击右下角初级按钮，可决定不同场景下发送邮件。
8、测试结果展现，在本次构建的控制台可以显示以后一切的构建日志。
9、测试报告点击Test Result可以显示一切测试记载。
z转载，仅供参考，祝你欢快，满意请采用。
qt技术栈能走ci/cd吗
关于Qt技术栈，能走各种工具和技术来成功CI/CD。
以下是一些经常出现的做法：1、版本控制系统：经常使用像Git这样的版本控制系统来治理代码，并确保团队成员可以共享和单干。
2、继续集成工具：经常使用诸如Jenkins、GitLabCI、TravisCI等继续集成工具，将代码智能构建、编译和测试。
3、智能化测试：编写智能化测试用例，确保在每次提交代码后能够智能运转测试，并及早发现潜在的疑问。
4、容器化技术：经常使用容器化技术，如Docker，将运行程序及其依赖项打包成一个镜像，使得在不同环境中的部署愈加繁难和牢靠。
5、部署和交付流程：经过智能化脚本或工具，将运行程序部署到指标环境，例如云主机、物理主机或移动设备。
Qt是一个跨平台的运行程序开发框架，最后由挪威公司Trolltech开发。
它提供了一套丰盛的工具和库，使开发者能够创立高性能、交互丰盛的运行程序。
