敏捷测试

ゝ一纸荒年。 2021-10-29 11:58 350阅读 0赞

有一次，当开发人员**完成当前****Sprint 任务的代码**之后，**测试人员、开发人员和产品经理**一起来**浏览产品**、从头到尾走一遍，**产品经理发现了问题，认为需要对功能进行比较大的修改**。这时开发人员估计需要**两天时间**才能完成代码，但**测试人员反对**这样做，我们本来只有**5天测试**时间，加上这次新做的功能比较多、开发代码质量不高，验收测试已经很紧张。如果再**延迟两天，测试没法完成**。产品经理说，你们不是在用**敏捷测试方法**，**应该测得很快**，三天应该能完成测试工作啊！

什么是敏捷测试呢？敏捷测试当然**不能简单地理解为测得更快**，绝对不是**比以前用更少时间进行测试**，也不是将测试的**范围缩小**了或将**质量降低**来**减少测试任务**。也有人说，只有敏捷开发，没有敏捷测试。下面我们将要讨论一下：

*  **什么是敏捷测试？**
 *  **敏捷测试有哪些流程改进？**
 *  **测试人员如何面对敏捷测试的挑战？**
 *  **在敏捷测试中如何制定相应的自动化测试策略？**

**什么是敏捷测试**

假如将过去传统的测试流程和方法硬塞入敏捷开发流程中，测试工作可能会事倍功半，测试人员可能会天天加班，而不能发挥应有的作用。**敏捷测试**应该是**适应敏捷方法**而采用的**新的测试流程、方法和实践**，对**传统的测试流程有所剪裁**，有**不同的侧重**，**例如**减少测试计划、测试用例设计等工作的比重，**增加与产品设计人员、开发人员的交流和协作**。在敏捷测试流程中，参与单元测试，**关注持续迭代的新功能**，针对这些新功能进行**足够的验收测试**，而对**原有功能**的回归测试则依赖于**自动化测试**。由于敏捷方法中**迭代周期短**，测试人员**尽早**开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。简单地说，**敏捷测试就是持续地对软件质量问题进行及时地反馈**，如图1所示。

[ ][Link 1]

图1 敏捷测试定义的形象描述

**敏捷测试流程的优化**

在敏捷方法中，需求变化比较快、产品开发周期很短，我们目前采用**四周时间**，也就是**每个月发布一个新版本**。**开发周期短，功能不断累加**，给软件测试带来很大的挑战，软件测试流程要做相应的调整。例如，我们原有的测试规范**明确规定**，首先要建立项目的**主测试计划书**，然后再建立**每个功能任务**的测试计划书，测试计划书有严格的模板，而且需要和产品经理、开发人员讨论，并和测试团队其他人员（包括测试经理）讨论，最终得到大家的认可和签字才能通过，仅**测试计划**经过“**起草、评审和签发**”**一个完整的周期就需要一个月**。**在敏捷方法中**，不再要求写几十页的测试计划书，而是在每个迭代周期，**写出一页纸的测试计划**，**将测试要点（包括策略、特定方法、重点范围等）列出来就可以了。**

在原有测试规范中，要求先用Excel写出测试用例，然后进行讨论、评审，评审通过以后再导入测试用例库（在线管理系统）中。**在敏捷测试中，可能不需要测试用例，而是针对****Use Case或User Story直接进行验证，并进行探索性测试**。而节约出来的时间，用于开发**原有功能的自动化测试脚本，为回归测试服务**。自动化测试脚本将代替测试用例，成为软件组织的财富。原有测试规范还要求进行两轮回归测试，在敏捷测试中，**只能进行一轮回归测试**。综合这些考虑，敏捷测试的流程简单有效，如图2所示。

图2 敏捷测试流程简要图

在敏捷测试流程中，如前所述，测试是一个持续的质量反馈过程，**测试中发现的问题要及时反馈给产品经理和开发人员**，而且某些关键方面也要得到我们足够的关注，主要有：

*  测试人员不仅要全程参与需求、产品功能设计等讨论，而且要面对面地、充分地讨论（包括带语言、视频的即时通讯），仅仅通过邮件是不够的。
 *  参与代码复审（Code Review），并适当辅助开发人员进行单元测试。
 *  在流程中增加一个环节“产品走查（Product Walk-through）”**DEMO**——测试人员和产品经理、开发人员等在一起，从头到尾将新功能看一遍，可直观、快速地发现问题。

**新功能的测试和回归测试策略**

测试任务简单地可分为**新功能测试**和**回归测试**。在敏捷方法中，针对这两部分的测试建立相应的策略，以提高测试的效率，最大限度地降低质量风险。**新功能测试的策略**主要有：

*  **不需要测试用例**，直接基于用例和对需求的理解来完成新功能的验证。即使要写测试用例，只要保证各个功能点被覆盖，不要过于详细（大颗粒度）。
 *  **持续地进行验证**，一旦某块新代码完成（Code Drop），就开始验证，而不是等到所有代码完成后才开始测试。这也包括参与到单元测试和集成测试中。
 *  **实施端到端**（End-to-End）的测试，确保完整的业务流程的实现，同时，也容易发现业务逻辑不够清晰、不够合理等各方面的问题。
 *  **阅读代码来发现问题**，可以和开发人员工作保持同步，消除测试周期的压力。
 *  **基于经验**，可以实施更多的探索性测试、组合交互性（Interoperation）测试和用户场景(User Scenario)测试，更有效地发现埋藏较深的缺陷。

回归测试是敏捷测试中需要面对的难点。每次迭代都会增加新的功能，一个产品可能会经过十几次、甚至几十次迭代，回归测试范围在不断增大，而每次迭代周期没变，可能还是一个月。这样验收测试的时间非常有限，所以回归测试很大程度上依赖于自动化测试，因为很难将回归测试控制在非常有限的范围内。当然，还是有些办法可以帮助我们减少回归测试的范围，例如：

*  **通过执行****Code Diff** 来了解代码变动的所有地方，再做代码关联分析，就可以明确知道要进行哪些地方的回归测试，回归测试范围会大大缩小。
 *  **基于风险和操作面分析来减少回归测试的范围**，例如回归测试只是保证主要功能点没有问题，而忽视一些细节的问题。
 *  **持续测试的过程**，只要有时间，就进行测试，包括开发人员、产品设计人员都参与到日常的试用和测试中来。

**自动化测试策略**

由于开发周期短，需求、设计等方面沟通也需要花费很多时间，没有足够时间开发自动化测试脚本，至少对新功能的测试很难实现自动化测试。这时候，就需要正确的策略来提高自动化测试的效益，如图3所示，并说明如下。

图3 自动化测试的策略

*  **构建一个灵活的、开放的自动化测试框架**，如基于关键字驱动的自动化框架，使测试脚本的开发简单易行，脚本维护也方便。
 *  **针对稳定的产品特性开发自动化测试脚本**，也就是针对前期完成的已有功能开发自动化测试的脚本,小部分主要功能自动化,而大部分新功能测试采用手工测试
 *  **集中精力在单元层次上实现自动化测试**，主要由开发人员实施，测试人员提供单元测试框架，并辅助完成一些所需的基础工作。
 *  **在产品设计、编程时就很好地考虑了自动化测试的需求**，使全面的、自动化的底层测试、接口测试成为可能，尽量避免用户界面（UI）的自动化测试。
 *  **良好的****IT基础设施**，包括自动化构建软件包、自动化版本验证（BVT）、自动化部署、覆盖率自动产生等。

**敏捷测试工具**

自动化测试依赖于测试工具，所幸的是，目前已有很多敏捷测试工具。由于篇幅所限，这里只是简单地列出一些常用的敏捷测试工具，不再深入讨论了。

*  单元测试工具：TestNG、xUnit家族（如JUnit、**NUnit**）、JMock、BizMock等。
 *  功能测试自动化：ThoughtWorks Twist。
 *  Web功能测试（**frontend**）：Selenium IDE/RC、WatiR、WatiN。
 *  Web service测试工具（**backend**）：soapUI。
 *  性能测试：JMeter+BadBoy。
 *  验收测试框架：Fitnesse、Tellurium。
 *  敏捷测试过程管理工具：微软的Visual Studio 2010，包括**TFS** **2010**、**Scrum模板**（**MS VS Scrum 1.0**）、**Test Manager 2010**、Coded UI Test等。
 *  业务智能（BI）应用的测试框架：Oraylis BI.Quality （+ NUnit）。
 *  其他一些协作工具等，如TestLink、BugZilla、**BugFree**、**Wiki**等。

**测试人员在敏捷方法中的价值**

在敏捷方法中，开发人员的主导作用更明显，系统设计、编程实现、单元测试、重构等看似关键的一些任务都落在开发人员身上，测试人员容易被边缘化。那么，在敏捷方法中，测试人员的价值又如何体现呢？

*  在需求和功能设计讨论上，测试人员可以站在客户角度来阐述自己的观点，扮演“用户代表”角色，强调用户体验，真正体现测试人员和开发人员的互补作用。
 *  测试人员不仅扮演“**用户代表**”角色，而且通过需求讨论、代码复审等各种活动及时地提供质量反馈，包括代码质量、接口一致性等，保证在产品构造的整个过程中质量受到足够的关注，以提高质量改进的持续性和可视性。
 *  测试人员应积极参与单元测试，即使不参加单元测试，也应督促开发人员进行单元测试，确保单元测试达到80% 以上覆盖率，确保开发出具有良好可测试性的代码。
 *  在敏捷方法中，往往将一个大的系统开发分解成多个**小的子系统（模块或组件），集成测试和端到端（****End-to-End）测试**显得更为重要，测试人员在这些测试上能发挥更大的作用。
 *  产品发布前，**验收测试和回归测试**依然不可缺少，这更是测试人员的用武之地。
 *  一个迭代周期结束后，**对缺陷根本原因进行分析、总结规律**，帮助开发人员建立良好的习惯，预防缺陷，从根本上提高产品质量。

理想情况下，测试人员掌握**设计模式**、具有很好的**编程能力**，可以和开发人员进行角色互换，如在当前版本开发中担任测试人员角色，在下一个版本开发中则担任开发人员角色。这样双方对不同角色的工作有着更深刻的认识，消除沟通的障碍，开发的效率和质量会有进一步的提高。

**总结**

根据上面的讨论和我们的实践，最后针对敏捷测试进行一个简单的总结，就是：

*  敏捷测试就是持续测试、持续反馈，扮演“**用户代表**”角色，确保产品满足客户的需求。
 *  **敏捷功能测试** = **新特性的手工测试**（Use Case验证和探索性测试）+**新功能的****BVT测试**(建议有) + **原有功能的自动化测试** （回归测试）。作为一个偷巧的办法，某些情况下，可以对代码进行diff 检查，比较代码改动的部分，让测试更有针对性。
 *  **合理的利用自动化**。自动化并不是越多越好。自动化可以保证已有功能的回归。对新增的功能，需要评估到底是自动化效率高还是手动测试效率高？我更倾向于对新增功能执行手动或者半自动化的测试，而在产品发布之后再补充完善自动化回归脚本。随着开发的进行，产品质量的提升，以及对产品了解程度的加深，对自动化测试进行持续改进，提供更大的覆盖，更好和更快速的验证。
 *  **敏捷开发追求持续的集成，持续的进行单元测试和回归测试**。我们计划与过程改进一起推进Check-In Test, BVT, daily regression test的自动化，让开发人员随时可以得到关于代码质量的反馈（例如，每一次的check-in是否break了build），帮助开发人员生产出具有良好可测试性的代码，进而提升测试的效率。帮助开发，就是帮助测试自己。
 *  **通过自动化和测试报告**，建立可见的质量度量体系，让产品和代码质量反馈持续可
 *  **让测试用例更有效率**，**避免在测试用例上面浪费太多的时间**。测试用例不是越多越详细就好。太详细的测试用例会降低测试效率，增加维护成本，并且会限制测试执行人员的思维。如果你的Bug大部分是通过执行测试用例发现的，那说明有两个问题：你在测试用例上面浪费了太多的时间，或者你在测试经验上面比较欠缺。如何定义测试用例的粒度——从业务出发，测试用例只要覆盖所有的业务功能和逻辑就够了。而数据检查、边界条件的测试用例，就留给测试人员去执行探索性的测试吧，希望每个人都**增强探索性测试的意识**。
 *  **为各系统维护一套测试点的****checklist**，越精简越好。让负责测试的人员（尤其是新手）能在几分钟之内就知道有哪些测试点是被遗漏的、需要关注的。我们已经把部分的checklist放在在wiki上了（例如引擎测试），希望大家都能参与进来，不断补充完善。
 *  前端应用的测试：UI变更频繁，测试非常容易失效？是否可以考虑把测试重心向相对稳定的**接口测试倾斜**？大家可以一起来思考。
 *  **开发和测试团队具有同样的质量目标和质量责任**。开发人员有义务对产品的可测试性和可自动化负责。如果你有这方面的需求，一定要跟开发人员讲出来。
 *  敏捷测试人员和开发人员的区别越来越小，理想情况下，敏捷方法中，测试人员和开发人员在不同的迭代周期可以互换。
 *  敏捷测试流程依据不同的团队特点、不同产品的特点而不同，因地制宜，适合才是最好。

敏捷测试的定义

l 强调从客户的角度，即使用系统的用户的角度，来测试系统

l 重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。

l 建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性

转载于:https://www.cnblogs.com/georgexu/p/11224304.html

[Link 1]: http://www.programmer.com.cn/wp-content/uploads/2011/09/%E6%95%8F%E6%8D%B7%E6%B5%8B%E8%AF%95%E7%9A%84%E6%96%B9%E6%B3%95%E5%92%8C%E5%AE%9E%E8%B7%B512.jpg