敏捷开发的软件测试过程概述

李嫚

摘 要：近年来，敏捷化开发方式的流行，使得敏捷测试应运而生。它应用新的测试流程、方法和实践，精剪并改进传统的测试流程，如减少测试用例设计，增加与产品设计人员的交流。本文根据在敏捷化开发项目组做测试工作的经历，介绍在敏捷开发过程中的对于测试的一些体会和经验。

关键词：敏捷测试；软件测试；测试执行

1 敏捷测试人员的定位

敏捷化开发近年来逐渐引起广泛关注，它是一种递增式的，持续迭代和不断调整的开发模式，它可以应对快速变化的需求。通过不断增量开发和持续集成我们逐渐建立起软件系统，可以看到系统的成长。敏捷测试是适应敏捷开发方法而采用的新的测试流程。在敏捷开发模式中，迭代周期短，需求变化快，敏捷测试总概括起来可以说是对原有功能的回归测试和对新功能的验收测试，根据系统的持续集成持续地对软件质量信息进行反馈。

敏捷中测试人员又叫QA（质量保证）。因此，从项目一开始就需要让全员达成一致：关注质量，随时构建质量，形成零缺陷文化。从用户角度出发关注用户使用，引导开发人员能够从用户的角度去思考、设计和实现软件，测试人员可以通过架构预演等方式，从整体上把握产品，及时提出架构上的问题，以及一些组件化开发的共享。测试人员需要对用户故事及时反馈，以便团队的及时改进以及持续改进，与开发紧密合作，形成技能互补，避免开发老是测试不出问题现象，以及测试不充分的情况。

2 敏捷测试的各个阶段

针对敏捷开发方法的敏捷测试不同于以往针对传统开发模式的测试，在敏捷团队中，测试是整个项目组的指向，它告诉大家现在到哪了，正在往哪个方向走，使得项目组基于这些可靠的信息作出正确的决定。不仅是测试员要保证质量，而是整个项目组的每一个人都要对质量负责。测试员不跟开发人员纠缠错误，而是帮助他们找到目标，共同为达到项目的最终目标而努力。敏捷测试也需要高度迭代工作、频繁得到客户的反馈，需要动态调整测试计划、测试的执行，并且，敏捷测试人员参与到了更多的敏捷开发活动中，积极的影响了团队做出的决定和计划。

2.1 验证需求和设计

需求和设计具体来说一般包括：（1）由项目经理根据需求文档而编写的功能设计文档；（2）由开发人员根据功能文档而编写设计文档。作为测试人员，审核重点是检查文档对用户需求定义的完整性、严密性和功能设计的可测性。

在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试，不要等待到功能完全做好才开始测试。

2.2 测试计划和测试用例

在敏捷开发的过程中由于是根据每个用户故事来估算时间的。开发人员将对本次迭代所需要的完成的用户故事进行评估。开发人员可以和客户直接沟通，来确定每个用户故事的优先级。测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例。在前面提到的三种文档中，功能设计文档是主要依据。测试的这两个文档也要被项目经理和开发人员审核。

为使开发人员能参与到测试用例的审阅中来并让开发人员迅速地了解测试的重点并给出相应的意见和建议，以保证测试用例的质量和可行性，确保测试工作的顺利进行，测试人员在出测试用例的同时，应出一份测试用例映射，其中注明测试用例已覆盖了哪些产品功能，具体每个产品功能对应的测试用例编号，这样在对测试用例进行审阅的时候，能够对测试用例的覆盖率一目了然，对覆盖率不足的地方能够及时给出意见。

2.3 测试执行

在敏捷方法中，测试有两种：单元测试和接收测试。单元测试是由开发人员来完成的，接收测试是由客户代表来完成。由于我们客户无法在现场，我们采取了，开发人员做单元测试，测试人员做验证测试，最后由客户进行接收测试。在每个版本发布给客户之前必须由测试人员进行测试，发布版本之后由客户做接收测试，提出需要修改的地方。需要修改的地方将在下一个发布完成。

为方便衡量项目的进度，测试可每天测试完毕后提供测试的Bug趋势，即将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势，到项目中后期被解决Bug数曲线会趋于上升，而新生Bug数曲线应下降，到项目最后，两条曲线都趋向于零。

在执行测试阶段中，测试人员需要对已有的测试用例进行及时的维护。通常以下两种情况下要新增一些测试用例：一是对于当初测试设计不周全的领域，二是对于外部的Bug，比如从客户报告来的，没有被现有测试用例所覆盖。当产品的功能设计出现更改时，所涉及的测试用例也要相应地修改，使测试用例保持和现有的功能需求同步。

为更好地保证软件质量，规避风险，必须加强对中间版本的控制。例如，客户要求或者计划周五要提交版本，则周三一定要提交一个中间过程的版本进行测试，也就是控制中间版本，避免所有的工作都压到后期最紧急的时候去完成。以前的项目中出现过项目前期很轻松，到后期Bug越来越多，开发人员和测试人员都异常忙碌，经常加班的情况。为减少后期工作量，规避风险，建议开发每天做一个Build，或者按照完成一个功能特性就进行一次Build，针对这个功能特性进行测试，这样就可以有效避免后期Bug越来越多的状况发生，后期工作量也就会相应减少，项目的质量也会更有保证。在每次发布版本之前，测试人员要根据待发布的版本情况编写版本说明，使客户对发布的版本情况一目了然。版本说明主要包括三方面的内容：已经修复的上个版本中存在的Bug，新的功能，此版本尚存在哪些比较大的问题。

在每日立会上，测试人员可以简洁地讲述一下当天测试的重点部分，以及项目中存在哪些严重的Bug，让开发人员了解当天测试的重点是什么，并提出自己的意见和建议。这样加强了开发与测试人员的交流和沟通，使测试工作能够更加有效，更加顺利地开展。

2.4 需求管理

采用敏捷开发模式的项目中，客户对于需求的变更很频繁。因此，需求管理是十分必要和重要的工作。整个项目进行过程中，对不断变化的需求，一定要作跟踪，每次的需求变更都要有相应的历史记录，可将每次的变更整理记录到需求跟踪文档中，并使该文档始终保持最新更新的状态，与需求的变化保持同步，方便后期的管理和维护工作。

2.5 清理Bug

在项目开发的末期，可以开展“Bug大扫除”活动。划出一个专门的时间段，在这期间所有参与项目的人员，集中全部精力，搜寻项目的Bug。注意以下要点：（1）尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加。目的是要集思广益；（2）要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug；（3）为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。（4）可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。