解密敏捷自动化测试

摘要：团队敏捷化转型过后，该如何进行项目的测试以及验收？敏捷测试与传统测试有什么不同？自动化测试在其中又担任着怎样的角色？

一、敏捷测试的定义和意义

在传统开发模式中，开发人员和测试人员往往各司其职：开发人员了解到产品需求后开始编写代码，测试人员拿到产品需求说明书后开始编写测试用例，等到开发完成，再开始对照测试用例进行人工测试工作。

但是在软件生命周期的需求、设计、开发、测试这四个阶段中，后面的阶段一般是依赖于前面的阶段的，所以越往后期响应变化的难度越大。比如，在开发过程中不仅需要响应需求变更，而且需要响应设计上的变化。从这个角度来看，处于最后阶段的测试必须及时响应前面三个阶段的所有变化。可是在传统的开发模式中，当需求变更产生的时候测试人员所编写的测试用例往往已经完成，需要对其进行推倒重构，整个测试流程就是在重复一些没有用的工作。

（传统测试流程图）

而敏捷测试是遵从敏捷软件开发原则的一种测试实践。敏捷开发模式把测试集成到了整个开发流程中而不再把它当成一个独立的阶段，因此测试变成了整个软件开发流程中必不可少，需要考虑人力、时间成本的一环。敏捷测试包含了具备专业测试技能人员在内的跨职能团队，这使得这种组合式的团队能更好地交付价值，满足项目的业务、质量和进度目标。

在敏捷开发模式中，所有的开发人员同时也是测试人员，对自己的业务负责，对团队的代码负责，是一种边开发边测试的模式。敏捷模式中一到四周的短开发周期，克服了传统模式中项目周期长、生命周期的工作内容不好分配、后期变更影响大等困难。

由于敏捷方法中迭代周期短，测试人员应尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。敏捷测试中通常包含以下几个阶段来保证敏捷测试的可靠性、时效性：

验收测试：对于这个迭代中新增、修改的功能按照迭代初期提出的需求内容进行测试验收。可采用冒烟测试的方法对新版本的业务流程进行测试。
回归测试：对于模块进行全量测试，保证其全部功能的可用性，验证当前迭代新增、修改过的功能对于其他内容没有不良影响。
系统测试：运用场景法测试和相互交叉测试保证整个系统在迭代结束后处于一个可发布状态。

简单地说，敏捷测试就是持续地对软件质量问题进行及时的反馈与响应。

（敏捷测试流程图）

二、自动化测试能带来什么

自动化测试在敏捷测试中占有绝对的主导地位。虽然在传统项目开发周期的测试阶段也推荐自动化测试，但由于整体的项目周期比较长，人员上的资源也较为充足，不使用自动化测试也可以控制测试人员人天成本并且达到测试目标。一般来说，回归测试能够获得几周甚至上月的时间，而在敏捷的开发模式中则迫切要求测试的高度自动化，一个迭代通常是两三周的时间，那也就意味着你只有两三天的时间来进行整个项目的全套测试流程。没有自动化，也就谈不上敏捷。在敏捷测试流程中，主要分为以下几个主要测试阶段：

单元测试（Unit Test，UT）

是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。

集成测试（Integration Test，IT）

整合测试又称组装测试，即对程序模块采用一次性或增值方式组装起来，对系统的接口进行正确性检验的测试工作。整合测试一般在单元测试之后、系统测试之前进行。实践表明，有时模块虽然可以单独工作，但是并不能保证组装起来也可以同时工作。

用户验收测试（User Acceptance Test，UAT）

用户验收测试，也叫用户可接受测试，一般在项目流程的最后阶段，这时相关的产品经理、业务人员、用户或测试人员根据测试计划和结果对系统进行测试和验收，来决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。

回归测试（Regression Test）

回归测试是软件测试的一种，旨在检验软件原有功能在修改后是否保持完整。回归测试主要是以检查退化为目的的测试。退化主要指由于系统的版本更新，在之前的版本中正常运行的功能变得无法正常运行，或者紧急修正了某个问题，但引发了其他的问题的现象。

以上这四种测试模式，目前都可以找到适用的主流自动化测试框架来满足需求。单元测试和集成测试可以使用如今比较流行的JUnit、TestNG、Spock等框架进行测试。而用户验收测试与回归测试可以使用一些api接口测试框架 REST Assured + TestNG 、mocha + chai 等。还可以使用一些针对UI界面的测试框架例如selenium和appium来编写测试脚本。

一、敏捷测试的定义和意义

二、自动化测试能带来什么

文章

教程

其他

联系我们