解密敏捷自动化测试
团队敏捷化转型过后，该如何进行项目的测试以及验收？敏捷测试与传统测试有什么不同？自动化测试在其中又担任着怎样的角色？本文将给大家介绍敏捷自动化测试，以及Choerodon猪齿鱼自动化测试的落地。
敏捷测试的定义和意义
在传统开发模式中，开发人员和测试人员往往各司其职：开发人员了解到产品需求后开始编写代码，测试人员拿到产品需求说明书后开始编写测试用例，等到开发完成，再开始对照测试用例进行人工测试工作。
但是在软件生命周期的需求、设计、开发、测试这四个阶段中，后面的阶段一般是依赖于前面的阶段的，所以越往后期响应变化的难度越大。比如，在开发过程中不仅需要响应需求变更，而且需要响应设计上的变化。从这个角度来看，处于最后阶段的测试必须及时响应前面三个阶段的所有变化。可是在传统的开发模式中，当需求变更产生的时候测试人员所编写的测试用例往往已经完成，需要对其进行推倒重构，整个测试流程就是在重复一些没有用的工作。
传统测试流程图：
而敏捷测试是遵从敏捷软件开发原则的一种测试实践。敏捷开发模式把测试集成到了整个开发流程中而不再把它当成一个独立的阶段，因此测试变成了整个软件开发流程中必不可少，需要考虑人力、时间成本的一环。敏捷测试包含了具备专业测试技能人员在内的跨职能团队，这使得这种组合式的团队能更好地交付价值，满足项目的业务、质量和进度目标。
在敏捷开发模式中，所有的开发人员同时也是测试人员，对自己的业务负责，对团队的代码负责，是一种边开发边测试的模式。敏捷模式中一到四周的短开发周期，克服了传统模式中项目周期长、生命周期的工作内容不好分配、后期变更影响大等困难。
由于敏捷方法中迭代周期短，测试人员应尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。敏捷测试中通常包含以下几个阶段来保证敏捷测试的可靠性、时效性：
1. 验收测试：对于这个迭代中新增、修改的功能按照迭代初期提出的需求内容进行测试验收。可采用冒烟测试的方法对新版本的业务流程进行测试。
2. 回归测试：对于模块进行全量测试，保证其全部功能的可用性，验证当前迭代新增、修改过的功能对于其他内容没有不良影响。
3. 系统测试：运用场景法测试和相互交叉测试保证整个系统在迭代结束后处于一个可发布状态。
简单地说，敏捷测试就是持续地对软件质量问题进行及时的反馈与响应。
敏捷测试流程图：
自动化测试能带来什么
自动化测试在敏捷测试中占有绝对的主导地位。虽然在传统项目开发周期的测试阶段也推荐自动化测试，但由于整体的项目周期比较长，人员上的资源也较为充足，不使用自动化测试也可以控制测试人员人天成本并且达到测试目标。一般来说，回归测试能够获得几周甚至上月的时间，而在敏捷的开发模式中则迫切要求测试的高度自动化，一个迭代通常是两三周的时间，那也就意味着你只有两三天的时间来进行整个项目的全套测试流程。没有自动化，也就谈不上敏捷。在敏捷测试流程中，主要分为以下几个主要测试阶段：
▌单元测试（Unit Test，UT）
是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。
▌集成测试（Integration Test，IT）
整合测试又称组装测试，即对程序模块采用一次性或增值方式组装起来，对系统的接口进行正确性检验的测试工作。整合测试一般在单元测试之后、系统测试之前进行。实践表明，有时模块虽然可以单独工作，但是并不能保证组装起来也可以同时工作。
▌用户验收测试（User Acceptance Test，UAT）
用户验收测试，也叫用户可接受测试，一般在项目流程的最后阶段，这时相关的产品经理、业务人员、用户或测试人员根据测试计划和结果对系统进行测试和验收，来决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。
▌回归测试（Regression Test）
回归测试是软件测试的一种，旨在检验软件原有功能在修改后是否保持完整。回归测试主要是以检查退化为目的的测试。退化主要指由于系统的版本更新，在之前的版本中正常运行的功能变得无法正常运行，或者紧急修正了某个问题，但引发了其他的问题的现象。
以上这四种测试模式，目前都可以找到适用的主流自动化测试框架来满足需求。单元测试和集成测试可以使用如今比较流行的JUnit、TestNG、Spock等框架进行测试。而用户验收测试与回归测试可以使用一些api接口测试框架 REST Assured + TestNG 、mocha + chai 等。还可以使用一些针对UI界面的测试框架例如selenium和appium来编写测试脚本。
Choerodon自动化测试落地
在敏捷测试的支持过程中，Choerodon平台支持了基于手动测试的操作结构（项目版本->用例文件夹，测试循环->测试阶段）的主流自动化测试框架。目前包括 mocha + chai 的api测试框架，以及 TestNG + REST Assured 的api测试框架。未来迭代中会新增支持 TestNG + selenium 的前端测试UI框架。从而完整地支持了敏捷测试中包含四个测试方面的主流框架（单元测试与集成测试在持续交付模块中落地实现）。
在自动化测试的运行模式上，我们沿用了持续交付模块所使用的基于不同的k8s平台定义环境，然后通过页面修改运行配置，达到可在不同环境中嵌入运行测试的目的。运行结束后将测试报告回传并加以解析，生成测试用例、测试阶段和测试执行。并尽可能保留并重新设计了不同框架的原生html报告，给了PO多种查看测试结果的途径，且支持定时任务等运行方式。
类原生的 Mocha + chai 测试报告：
虽然在技术上支持了敏捷化的自动化测试，但是在自动化测试落地的过程中，也遇到了一些问题的。
1. 重新定义工作量
在敏捷的开发模式中，迭代规划会议尤为重要。因为敏捷团队中没有专门的测试人员，所以当一个团队决定去实践自动化测试的时候，意味着相同难度的任务工作量基本变成了原来的两倍。作为PO在规划故事的过程中，应该充分考虑到测试脚本的编写工作量，并计算到成员的工作内容当中，从而给团队成员”减负“，鼓励他们更高质量地完成测试任务（毕竟在测试脚本上偷懒可比在业务代码上偷懒容易多了）。
2. 鼓励互相帮助
从敏捷测试的理论上来说，每个开发人员负责维护自己功能的测试代码。但是在实际的迭代过程中，难免会造成任务分配有轻微失衡的情况出现。这种情况下应鼓励队员主动帮助其他成员分担测试代码维护等琐碎任务，促进团队成员间的互帮互助，作为团队的一份子应当把整个项目当成自己分内的工作内容。而不是说这个功能是”李四“写的，事不关己高高挂起。
3. 留出足够的测试时间
在实践自动化测试以后，可能在迭代结束前的测试阶段会更容易测出Bug，这个时候应比以前多预留出一段时间给团队成员以确保在迭代结束前可以求证全部缺陷，鼓励团队成员把这个迭代发现的问题就在这个迭代中解决，从而使用自动化测试提高交付质量。
写在最后
手动测试和自动化测试对于敏捷项目来说同等重要，人工手动测试才是保证交付结果的最后一关。不能因为使用了自动化测试而忽视传统测试，这两者只是在开发的不同阶段中扮演了不同的角色。
关于敏捷的自动化测试的实践，太多人有不同的见解，正所谓一千个观众眼中有一千个哈姆雷特。每个团队的敏捷落地都有各自的特色与道路，所以实践出最适合自己团队的自动化测试方案，提高团队的凝聚力与生产力才是敏捷的最终目的，祝大家都找到一个适合自己团队的敏捷方法。
关于猪齿鱼
Choerodon 猪齿鱼是一个全场景效能平台，基于 Kubernetes 的容器编排和管理能力，整合 DevOps 工具链、微服务和移动应用框架，来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台，同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件，致力帮助企业聚焦于业务，加速数字化转型。
大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：
作者：王喆
出处：Choerodon
欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接。