敏捷测试

敏捷测试的实践

摘要：在敏捷测试流程中,参与单元测试,关注持续迭代的新功能,针对这些新功能进行足够的验收测试,而对原有功能的回归测试则依赖于自动化测试.由于敏捷方法中迭代周期短,测试人员尽早开始测试,包括及时对需求、开发设计的评审,更重要的是能够及时、持续的对软件产品质量进行反馈.

关键词：敏捷测试;敏捷开发;开发周期;单元测试

1引言

之前跟众人一样对敏捷开发比较熟悉，觉得新鲜而有效率。刚看到老师给的题目时才知道敏捷测试这个概念，自己一直局限于测试方法的学习，并没有系统并从大体框架去学习和了解测试这个行业。在学习敏捷测试过程中了解到这样几个概念：TDD（测试驱动开发Test Driven Development）、ATDD(验收测试驱动开发Acceptance Test Driven Development)、UTDD(单元驱动测试Unit Test Driven Development)以及精益方法，并由此开始了解到软件测试和其他知识领域的交叉处。

敏捷测试进入国内研究领域还是一个新生力，查找到的国内文献也是极其有限的，在这里也只是发表自己浅陋的理解。通过之前的对软件项目案例的学习，我比较欣赏的是软件生命周期中的螺旋式模型，那敏捷是先于开发，也就跟传统的测试有本质的区别。传统的测试是先写测试计划，此后的测试过程分布在螺旋式模型中的每一次完善的循环中，而敏捷测试则是在开发前写好了用例，根据用例再去开发系统，可以减少很多错误，但这也就意味着开发人员的主导作用更明显。与传统的测试不同，敏捷软件测试并不是一个独立的过程，相反，它与整个敏捷开发中的其他活动交织在一起，处处都能看到它的影子。

敏捷测试接纳了敏捷的核心价值观（沟通，简单，反馈，勇气，尊重），在敏捷软件开发过程中开展的测试就可以被称作是敏捷软件测试。因此，敏捷软件测试并不是一个与敏捷软件开发同一层次的划分，而是敏捷软件开发中的一部分。

2 敏捷测试背景

2.1敏捷测试

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

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

2.2敏捷测试的核心

首先要从整个项目全局考虑，及早发现需要更改设计的问题。其实这个测试更多的是观察与思考，而是否能发现问题就要看开发人员对需求掌握是否透彻，对整个项目是否有一个全局的把握，是否从最终用户角度去考虑问题，是否以实现客户的商业价值为目标。

然后在最短时间内完成所有功能和业务逻辑的测试，最好是每人分配不同的功能和业务逻辑进行测试，这样就可以在最短时间内及时将优先级较高的缺陷及时反馈给开发人员。

最后在开发人员忙于修改那些优先级较高，难度较大，比较耗时的缺陷的同时测试人员可以有充分的时间来对这一迭代进行较细致的测试，发现功能和业务逻辑中不易察觉的问题，次要功能问题、验证、界面等。那么，作为一个测试工程师在测试中使用敏捷的思想进行测试，并且需要敏捷测试中需要保证其工作符合相应的准则：①获取和明确用户的质量期望；②建立合适的系统测试、用户验收测试质量标准；③推进单元测试、开发测试；④建立持续构建框架；⑤持续改进自动化测试；⑥保持质量度量结果的可见性。

2.3敏捷测试流程优化

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

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

图2 敏捷测试流程简要图

在敏捷测试流程中，如前所述，测试是一个持续的质量反馈过程，测试中发现的问题要及时反馈给产品经理和开发人员，而且某些关键方面也要得到我们足够的关注，主要有：测试人员不仅要全程参与需求、产品功能设计等讨论，而且要面对面地、充分地讨论（包括带语言、视频的即时通讯），仅仅通过邮件是不够的。

参与代码复审（Code Review），并适当辅助开发人员进行单元测试。

在流程中增加一个环节―产品走查（Product Walk-through）‖——测试人员和产品经理、开发人员等在一起，从头到尾将新功能看一遍，可直观、快速地发现问题。

3敏捷测试人员的作用

测试是软件开发中不可或缺的一部分。在敏捷软件开发中亦是如此。不同的组织给测试人员以不同的称号：测试开发(Test Developer)、质量分析员(Quality Analyst)、软件质量工程师(Software Quality Engineer) 等。

每个称号隐含有不同的职能。以上的称号分别对应以下的能力要求：

具有质量检测和编写代码的能力–> 测试开发

具有防止缺陷(Quality Assurance) 和质量控制(Quality Control) 的能力–> 质量分析员

具有开发和执行测试程序的能力-> 软件质量工程师

总结而言，有三方面的基本素质要求：代码编写（Coding）、测试(Testing) 和分析(Analysis)。

在很多其他的开发流程中，各个测试阶段对测试人员的能力有所不同；有时候侧重分析（比如系统配置测试），有时候侧重代码编写( 比如功能测试)。但是，在敏捷开发流程中，测试人员需要结合这三方面来开展工作，只有这样才能真正反映敏捷测试的本质：简单而高效得应对变化。

在敏捷软件开发中，测试人员的职责有三个主要方面：

定义质量(Define Quality)：这应该是软件测试人员的基本职责。敏捷方法鼓励测试人员在Sprint 计划的时候直接与客户交流，从自己的经验出发，共同为产品功能制定质量要求。

交流缺陷（Communication）：敏捷过程强调团队中的交流。开发人员经常会专注于重要而新奇的功能，测试人员应该抓住细节，寻找设计中的―missing door‖；另外，开发人员使用单元测试来保证产品的基本质量，测试人员可以使用验收测试（Acceptance Test）来鉴定客户需求与实际成果之间的不一致性。

及时反馈(Feedback): 敏捷过程强调简单而高效。测试人员需要及时反馈产品目前的质量问题。这样一来，团队才可以立刻着手解决。如果传统的流程是一周汇总一次状态的话，敏捷流程要求每天汇总质量问题。在我们的项目中，内部的测试报告会以网页的形式显示在内部站点上。每个团队成员能够随时获取。另外，我们的测试框架提供自助测试(Self-assistant Test)：通过点击测试用例列表中的某个具体用例，开发人员不需要中断测试人员的工作就可以重现缺陷。

4敏捷测试的管理

敏捷测试的管理同样是一个非常重要的部分，敏捷测试过程管理应该包括以下内容。

4.1测试计划

敏捷测试并不需要为每次迭代准备特别详细的测试计划文档，但最好能够在测试计划中描述：①在本次迭代中哪些内容是需要被测试的；②本次迭代中会安排测试的类型；③测试通过的质量标准，同时测试计划应尽可能的简洁，以清晰、易懂为原则。

4.2测试设计

对于每个迭代中新增或是发生变化的功能, 敏捷测试采用探索性测试的方法来设计测试。对于稳定的部分, 敏捷测试采用自动化测试的方式建立可接受的质量度量框架。

4.3测试执行

测试过程中有不同的测试方式，不同的测试方式其侧重点有所不同。根据测试的自动化程度不同，测试方式主要包括以下几种：①手工测试：新功能和修改功能的了解、验证；②Adhoc 测试：基于对应用的理解，尝试发现应用中可能的问题；③动化测试：不同层次级别的自动化验证；安全性测试、Fuzz 测试等分析、调试、优化现有的自动化测试。

4.4反馈与提高

在产品发布以后, 可以说敏捷项目告一段落。但是为了不断提高测试能力、不断提高测试有效性, 测试工程师还需要对在测试过程中收集的数据进行缺陷分析。将缺陷进行分类整理, 采用合理的分析方法找出造成缺陷的真实原因, 并对其原因进行分类整理。如果有可能建立缺陷资料库, 对不同类别的缺陷建立缺陷资料库供敏捷团队进行学习, 在整个团队中分享测试知识, 包括敏捷开发人员对缺陷原因的认识。如果有可能的话, 敏捷测试工程师应根据已有知识体系, 建立更多纬度的自动化测试。在已定义的产品中, 追溯缺陷对应的需求, 建立需求- 缺陷追踪矩阵。结合缺陷描述进行需求重定义, 使得能需求清晰定义, 不断提高产品的可测试性。

5敏捷测试的自动化

没有自动化，就没有持续集成，也就没有敏捷。在敏捷测试中自动化测试就更加迫切，这一点比较容易理解，每个迭代（如Scrum中的Sprint）都在增加新的功能，而迭代周期的时间相对固定，随着时间的推移，已实现的功能越来越多，这就要求越来越多的回归测试在时间相对固定的周期内完成。如果没有自动化测试，这是不可能完成的任务。

在过去一年中，敏捷测试的自动化又发生了哪些变化？如何重构自动化测试脚本以提高产出投入比（ROI）？下面就简单讨论一下敏捷自动化测试框架和敏捷测试工具等内容。

敏捷测试对测试工具要求简单、实用，随时可用，而对敏捷测试来说，自动化测试框架更为重要，它将负责集成各种测试工具，包括单元测试工具和验收测试工具等，还负责与持续集成、缺陷管理系统等整个开发环境集成。作为敏捷测试的自动化框架，一般会选择轻量型、开放类型的框架。说到这种类型的框架，可以参考RobotFramework。在最近一年，其版本发布比较频繁，也日渐成熟。RobotFramework是基于Python开发的、可扩展的框架，所以适用于多种接口的复杂软件（如用户接口、命令行、Web Service、编程接口等）的测试。

敏捷测试工具很多，但对敏捷测试来说，我们更要关注能够适应ATDD或BDD的测试工具，如Cucumber、RSpec、NBehave /CBehave /JBehave、EasyB、JDave等。也可以结合先前熟悉的测试工具开展工作，例如用自己熟悉的WatiN来结合SpecFlow 完成BDD模式的自动化测试。

6总结

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

敏捷测试就是持续测试、持续反馈，扮演―用户代表‖角色，确保产品满足客户的需求。

敏捷测试人员和开发人员的区别越来越小，理想情况下，敏捷方法中，测试人员和开发人员在不同的迭代周期可以互换。

接纳了敏捷的核心价值观（沟通，简单，反馈，勇气，尊重），在敏捷软件开发过程中开展的测试就可以被称作是敏捷软件测试。因此，敏捷软件测试并不是一个与敏捷软件开发同一层次的划分，而是敏捷软件开发中的一部分，与传统的测试不同，敏捷软件测试并不是一个独立的过程，相反，它与整个敏捷开发中的其他活动交织在一起，处处都能看到它的影子。

参考文献

[1] Glenford J. Myers. The arts of software testing [M]. 第二版，2004.

[2] William E.Lewis,David Dobbs. Software Testing and Continuous Quality Improvement [M]. 第三版，2011.

[3] 朱少民. 敏捷测试的方法和实践[J]. 2010.

[4] 徐飞.敏捷测试过程[J]. 软件导刊2013.

[5] 张孟. 敏捷开发中原则与过程的分析与研究[J]. 科技传播2013.

通用电子商务平台测试用例的设计及执行（实践部分）

1.负责的任务和执行

在本次测试过程中，由于之前有功能测试的经验，所以被安排设计测试用例并执行。但在实际的工作中仅仅按照等价类划分和判断表驱动法这样的分类方法去设计用例，并相应的删除冗余。

首先，熟悉了解需要测试的两个模块：购买模块以及注册模块；然后根据系统设计文档列出系统的待测功能点。

第一部分是购买模块的功能点，这部分主要是单元测试，除了购物车部分，其他部分均不需要输入值，依次点击链接查看功能是否实现。

购物车物品数量部分本应该只存在正数，在我们输入不合法字符之后，系统有提醒输入异常，但当输入的为负数值时，系统却在结算部分显示了相应的负数金额，这在实际操作中是不合理的，并且很有修改的必要。结算部分就算购物车没有商品，它依然会跳转至结算页面，而按照需求和设计文档，此部分应该提示购物车为空。

第二部分是注册模块测试，因为系统需要输入值的模块并不多，所以特意选取了输入值要求比较多的注册模块。

在设计测试用例的过程中，由于需求和系统设计文档等资料不详细，所以在邮箱这部分的测试比较琐碎，甚至为了测试用例覆盖比较完整，特意去研究了邮箱的校验机制var pattern = /\b(^['_A-Za-z0-9-]+(\.['_A-Za-z0-9-]+)*@([A-Za-z0-9-])+(\.[A-Za-z0-9-]+)*((\.[A-Za-z0-9]{2,})|(\.[A-Z a-z0-9]{2,}\.[A-Za-z0-9]{2,}))$)\b/;这部分的测试用例主要是针对邮箱校验的每一部分，但仅仅根据这个还是不够的，因为这部分校验机制也不一定完整并且合理，所以主要是校验机制和大型邮箱网站的校验机制想综合进行测试用例的设计。

此外根据之前的测试经验进行了冗余测试用例的删除，减少了测试用例的数量，使得执行效率变高。另外一个问题比较集中的是昵称部分，在测试到此部分时，发现校验机制做的饼不完善，无论输入任何不合法的字符或者超过正常昵称长度的昵称都可以通过验证，这在实际的项目中是一个比较严重的问题。

在实际的测试中我们第一部分进行的是静态测试，正常的代码走查需要4个人左右，主要人员包括：总协调人1名、参与项目的程序员1名、设计人员1名、测试专家1名。而我们的项目中由于自己之前的经验，所以充当了总协调人和测试专家的角色，当然除了程序的设计者和程序员，我们还安排有其他组员一起发现代码设计或者采用框架上的不足。前期的代码走查也为后期我做注册部分的测试用例设计提供了很大的帮助，我不仅仅了解其他邮箱网站的输入合理性，也了解本系统的校验机制以及邮箱校验的不合理之处、昵称输入的缺陷等问题。

2.收获和体会

之前在公司做测试时主要的是执行测试用例以及做回归测试，有试着写过测试用例，但效果不理想，后期得益于组长的指导，对根据设计文档写测试用例有了一定的了解，但还不熟练，这一次在小组中由于自己的组织能力和之前的经验，虽然不想担任组长的责任，但仍然做着组长的事情，因为我想知道自己一个人去安排并负责这些到底能不能行。

第一次去自己独立完成测试用例，心里还是比较紧张的，不知道能做到什么样的程度，首先是回顾之前自己学的测试的知识以及老师课堂教授的内容，然后列出功能点，再依次列出各部分需要

执行的条件，一路走下来，对自己还是比较满意的，因为老师给了这样一个机会去让我看到自己是可以做到这些的，虽然在测试用例的设计中还存在很大的问题。

3.实践中的困难

一个主要的问题，并且一直放在心上的是，老师课堂讲授的正交表排除冗余，当时没有听懂，课下也一直因为事情比较多，所以至今未深入学习这部分，但我知道我一定要学会这个知识点，不然自己在测试的路上还会积累更多的疑惑。本次测试过程中本来想实际应用下老师讲的减少冗余的方法，但对这些方法掌握有限，所以做不到灵活的运用。读软件工程，很多同学是为了做开发，很多人跟我讲测试开发人员都会做等这样轻视测试人员的话，但我从未放弃，我的目标至始至终都是为了成为了一名顶尖的测试大师，我学习各种算法，我努力研究项目管理，各种过去的以及现在流行的测试手段及方法，在年初实习的时候就已经完整了读完了《the arts of software testing》,这是我学习软件测试的启蒙书籍。在学习的过程中，发现测试也是那么困难的，需要学的很多，难以理解的知识点也很多，但我相信如果我学的好，我可以获得跟做开发的同学同等的地位，任何的理想都是有价值的，任何实现的理想都是了不起的。我并没有希望去麻烦老师教授我多少东西，我相信我目前在学的知识都是通过自己的思考可以解决的，等我掌握基础之后不懂的问题才是值得去麻烦老师指导的。感谢老师在这门课的实践中让我第一次鼓起勇气去尽最大努力完成系统的测试。