热血传奇敏捷属性测试

篇一：敏捷测试

敏捷测试的实践

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

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

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.负责的任务和执行

在本次测试过程中，由于之前有功能测试的经验，所以被安排设计测试用例并执行。但在实际的工作中仅仅按照等价类划分和判断表驱动法这样的分类方法去设计用例，并相应的删除冗余。 首先，熟悉了解需要测试的两个模块：购买模块以及注册模块；然后根据系统设计文档列出系统的待测功能点。

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

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

篇二：敏捷测试流程

敏捷测试流程

在敏捷方法中，XP方法强调测试在整个项目开发过程中的重要性。针对敏捷开发方法的敏捷测试不同于以往针对传统开发模式的测试,在敏捷团队中,测试是整个项目组的“车头灯”，它告诉大家现在到哪了，正在往哪个方向走。测试员为项目组提供丰富的信息，使得项目组基于这些可靠的信息作出正确的决定。不仅是测试员要保证质量，而是整个项目组的每一个人都要对质量负责。测试员不跟开发人员纠缠错误，而是帮助他们找到目标,共同为达到项目的最终目标而努力。敏捷测试也需要高度迭代工作、频繁得到客户的反馈，需要动态调整测试计划、测试的执行。并且，敏捷测试人员参与到了更多的敏捷生产活动中，积极的影响了团队做出的决定和计划。根据公司项目目前采用的敏捷开发模式，相应的敏捷测试建议采用以下流程：

1. 验证需求和设计

需求和设计具体来说一般包括：

1) 由项目经理根据需求文本而编写的功能设计文本（Functional Design Specification）

2) 由开发人员根据功能文本而编写的实施设计文本（Implementation Design Specification）包括(Architecture Document, Project Scope Statement, Use Case )。作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性.

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

产出物:测试需要提交评审结果文档,可以让测试更多的参与DB Design,框架的评审中来

2. 测试计划，测试用例

1) 编写计划、测试用例

在敏捷开发的过程中由于是根据每个user story来估算时间的。开发人员将对本次迭代所需要的完成的user story进行评估。开发人员可以和客户直接沟通，来确定每个user story的优先级。

好处：客户可以很清楚的了解到哪些user story需要花费多长的时间，以及他们的优先级。 问题： 在user story的时间估算上，开发人员常会估算过少。引起版本无法按时发布或者必须进行加班才能进行发布。

分析： 由于版本更新很快，任务的时间都是以小时来进行估算的。开发人员一般会忽略掉开发以外的时间，比如开发中遇到问题的时间，开会，给其他成员提供帮助的时间，等等。 举个例子： 开发人员估算某个user story编码的时间需要1.5天，开发人员自己估算了其他时间为半天。于是开发人员给的估算时间是2天。 开发阶段实际的花费时间如下，每天花费开例会的时间。在例会中项目的其他成员需要技术上的支持。于是发费了3个小时进行帮助。在开发的过程中遇到了一些没有预见到的问题，结果解决问题花费了4个小时。（也许更多）。需要处理一些公司突发性的事务等等。

所以非常建议大家在估算时间上能充分的考虑到以外的因素，某本XP相关的书上写到，在时间估算上最好的时间是编码时间的2－3倍。听起来很吓人，但是实际的过程中，的确需要这么多的时间。 测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例。在前面提到的三种文本中，功能设计文本是主要依据。测试的这两个文本也要被项目经理和开发人员审核。

2) 测试用例的审核

为使开发人员能参与到Test Case的Review中来，以保证TC的质量和可行性，确保测试工

作的顺利进行，让开发人员迅速地了解测试的重点并给出相应的意见和建议，测试人员在出 TC的同时，应出一份TC_Matrix（Test Case跟踪矩阵），其中注明TC已覆盖了哪些Features，具体每个Features对应的TC的编号，这样在测试经理和PM对TC进行 Review的时候，能够对TC的覆盖率一目了然，对覆盖率不足（如某个重点Feature的Test Case不够）的地方能够及时给出意见。

另外，在每天早上的Morning Meeting上，测试人员可以简洁地讲述一下当天测试的重点部分，以及项目中存在哪些严重的bug，让开发人员了解当天测试的重点是什么，怎样进行测试，并提出自己的意见和建议。这样做加强了开发与测试人员的交流和沟通，使测试工作能够更加有效，更加顺利地开展。 在迭代后期测试要抽时间更新test case。

3. 实施运行测试

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

1) 单元测试

在daily build版本给测试前，开发首先要做单元测试，提前告知软件中的薄弱环节，帮助测试人员调整测试重点。Unit test 做单元测试的好处是可以提高版本质量，减轻测试的工作量，减少浅层次的bug的发生率，使测试人员能够将更多的精力投入到寻找深层次的bug上面。

2) 验证测试

测试人员的验证测试从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。这一阶段的测试必须在周密的计划下进行。这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。从测试的过程来看，测试执行的一开始可以是针对部分功能的，之后可以逐步扩展。接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分（组件，构件）做完整的测试。接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试。

3) 每日提供bug趋势

为方便衡量项目的进度，测试可每天测试完毕后提供测试的bug趋势，即将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势，到项目中后期被解决Bug数曲线会趋于上升，而新生Bug数曲线应下降，到项目最后，两条曲线都趋向于零。PM会持续观察这张图表，确保项目健康发展，同时通过分析预测项目Bug，对于每个版本的bug，开发都应该想想为什么会出现这样的问题，特别是很低级的bug，对于同类的bug，是否可以避免。 测试需要考虑:探索性测试用例的编写

4) 测试用例的维护

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

5) 根据项目不断补充Common Sense

在项目进行过程中，测试人员需要不断积累经验，不断补充、完善各类目的

Common Sense标准。例如，由CTTS项目总结出的Common Sense for USA标准，在以后的美国项目中要严格按照它来执行测试，保证以前出现过的失误在以后的项目测试中不会再出现。在保证项目质量的同时，不断积累新的经验。

6) 控制中间版本

为更好地保证软件质量，规避风险，必须加强对中间版本的控制。例如，客户要求或者计划周五要提交版本，则周三一定要提交一个中间过程的版本进行测试，也就是控制中间版本，避免所有的工作都压到后期最紧急的时候去完成。以前的项目中出现过项目前期很轻松，到后期bug越来越多，开发人员和测试人员都异常忙碌，经常加班的情况。为减少后期工作量，规避风险，建议开发进行Daliy Build，或者按照完成一个feature就进行一次build，针对这个feature进行测试，这样就可以有效避免后期bug越来越多的状况发生，后期工作量也就会相应减少，项目的质量也会更有保证。

7) 发布版本前编写Release Note

在每次发布版本之前，测试人员要根据待发布的版本情况编写Release Note，使客户对发布的版本情况一目了然。Release Note主要包括三方面的内容：Fixed，New Features，Known Problems。其中，Fixed部分写明此版本修复了上个版本中存在的的哪些比较大的bug；New Features部分写明此版本新增加了哪些功能；Known Problems部分写明此版本尚存在哪些比较大的问题，有待下个版本改善；或者列出需求不太明确的地方，有待客户给出明确答复意见，在下个版本中完成。

4. 需求管理

采用敏捷开发模式的项目中，客户对于需求的变更很频繁。因此，需求管理是十分必要和重要的工作。整个项目进行过程中，对不断变化的需求，一定要作跟踪，每次的需求变更都要

篇三：敏捷开发与敏捷测试(很详细的说明)

敏捷开发与敏捷测试

来源: cnblogs 敏捷开发：1.敏捷型方法是“适配性”而非“预设性”。重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。2.敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。

我认为以上两个特点很好的概括了敏捷开发方法的核心思想：适应变化和以人为中心。

敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发，这两种在任何一本软件工程教材中都会被提到的方法，在敏捷开发模式中扮演了很重要的角色。再向前追溯，我们还也可见到瀑布式与快速原型法的影子，也许还有多。 改善，而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中，我们每两周都会得到一个可以工作的软件，”Fowler介绍，“这种非常短的循环，使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。”

敏捷开发提出了以下遵循的原则：

· 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

· 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

· 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 · 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

· 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 · 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。

· 工作的软件是首要的进度度量标准。

· 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

· 不断地关注优秀的技能和好的设计会增强敏捷能力。

· 简单是最根本的。

· 最好的构架、需求和设计出于自组织团队。

· 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。 敏捷测试流程总结：

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

根据公司项目目前采用的敏捷开发模式，相应的敏捷测试建议采用以下流程：

1. 验证需求和设计

需求和设计具体来说一般包括：（1）由项目经理根据需求文本而编写的功能设计文本（Functional Design Specification）；（2）由开发人员根据功能文本而编写的实施设计文本（Implementation Design Specification）包括(Architecture Document, Project Scope Statement, Use Case )。作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性.

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

产出物:测试需要提交评审结果文档,可以让测试更多的参与DB Design,框架的评审中来

2. 测试计划，测试用例

2.1 编写计划、测试用例

在敏捷开发的过程中由于是根据每个user story来估算时间的。开发人员将对本次迭代所需要的完成的user story进行评估。开发人员可以和客户直接沟通，来确定每个user story的优先级。

好处：

客户可以很清楚的了解到哪些user story需要花费多长的时间，以及他们的优先级。

问题：

在user story的时间估算上，开发人员常会估算过少。引起版本无法按时发布或者必须进行加班才能进行发布。

分析：

由于版本更新很快，任务的时间都是以小时来进行估算的。开发人员一般会忽略掉开发以外的时间，比如开发中遇到问题的时间，开会，给其他成员提供帮助的时间，等等。

举个例子：

开发人员估算某个user story编码的时间需要1.5天，开发人员自己估算了其他时间为半天。于是开发人员给的估算时间是2天。

开发阶段实际的花费时间如下，每天花费开例会的时间。在例会中项目的其他成员需要技术上的支持。于是发费了3个小时进行帮助。在开发的过程中遇到了一些没有预见到的问题，结果解决问题花费了4个小时。（也许更多）。需要处理一些公司突发性的事务等等。

所以非常建议大家在估算时间上能充分的考虑到以外的因素，某本XP相关的书上写到，在时间估算上最好的时间是编码时间的2－3倍。听起来很吓人，但是实际的过程中，的确需要这么多的时间。

测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例。在前面提到的三种文本中，功能设计文本是主要依据。测试的这两个文本也要被项目经理和开发人员审核。

2.2 测试用例的审核

为使开发人员能参与到Test Case的Review中来，以保证TC的质量和可行性，确保测试工作的顺利进行，让开发人员迅速地了解测试的重点并给出相应的意见和建议，测试人员在出 TC的同时，应出一份TC_Matrix（Test Case跟踪矩阵），其中注明TC已覆盖了哪些Features，具体每个Features对应的TC的编号，这样在测试经理和PM对TC进行 Review的时候，能够对TC的覆盖率一目了然，对覆盖率不足（如某个重点Feature的Test Case不够）的地方能够及时给出意见。

另外，在每天早上的Morning Meeting上，测试人员可以简洁地讲述一下当天测试的重点部分，以及项目中存在哪些严重的bug，让开发人员了解当天测试的重点是什么，怎样进行测试，并提出自己的意见和建议。这样做加强了开发与测试人员的交流和沟通，使测试工作能够更加有效，更加顺利地开展。 在迭代后期测试要抽时间更新test case。

3. 实施运行测试

在敏捷方法中，测试有两种：单元测试和接收测试。单元测试是由开发人员来完成的，接收测试是由客户代表来完成。

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

· 单元测试

在daily build版本给测试前，开发首先要做单元测试，提前告知软件中的薄弱环节，帮助测试人员调整测试重点。Unit test

做单元测试的好处是可以提高版本质量，减轻测试的工作量，减少浅层次的bug的发生率，使测试人员能够将更多的精力投入到寻找深层次的bug上面。

· 验证测试

测试人员的验证测试从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。这一阶段的测试必须在周密的计划下进行。这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。从测试的过程来看，测试执行的一开始可以是针对部分功能的，之后可以逐步扩展。接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分（组件，构件）做完整的测试。接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试。

3.1 每日提供bug趋势

为方便衡量项目的进度，测试可每天测试完毕后提供测试的bug趋势，即将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势，到项目中后期被解决Bug数曲线会趋于上升，而新生Bug数曲线应下降，到项目最后，两条曲线都趋向于零。PM会持续观察这张图表，确保项目健康发展，同时通过分析预测项目Bug，对于每个版本的bug，开发都应该想想为什么会出现这样的问题，特别是很低级的bug，对于同类的bug，是否可以避免。

测试需要考虑:探索性测试用例的编写

3.2 测试用例的维护

在执行测试阶段中，测试人员需要对已有的测试用例进行及时的维护。通常以下两种情况下要新增一些测试用例：一是对于当初测试设计不周全的领域，二是对于外部的Bug（比如从Beta客户报告来的），

没有被现有测试用例所覆盖。当产品的功能设计出现更改时（敏捷项目中功能设计的更改频繁），所涉及的测试用例也要相应地修改，使测试用例保持和现有的功能需求同步。

3.3 根据项目不断补充Common Sense

在项目进行过程中，测试人员需要不断积累经验，不断补充、完善各类目的Common Sense标准。例如，由CTTS项目总结出的Common Sense for USA标准，在以后的美国项目中要严格按照它来执行测试，保证以前出现过的失误在以后的项目测试中不会再出现。在保证项目质量的同时，不断积累新的经验。

3.4 控制中间版本

为更好地保证软件质量，规避风险，必须加强对中间版本的控制。例如，客户要求或者计划周五要提交版本，则周三一定要提交一个中间过程的版本进行测试，也就是控制中间版本，避免所有的工作都压到后期最紧急的时候去完成。以前的项目中出现过项目前期很轻松，到后期bug越来越多，开发人员和测试人员都异常忙碌，经常加班的情况。为减少后期工作量，规避风险，建议开发进行Daliy Build，或者按照完成一个feature就进行一次build，针对这个feature进行测试，这样就可以有效避免后期bug越来越多的状况发生，后期工作量也就会相应减少，项目的质量也会更有保证。

3.5 发布版本前编写Release Note

在每次发布版本之前，测试人员要根据待发布的版本情况编写Release Note，使客户对发布的版本情况一目了然。Release Note主要包括三方面的内容：Fixed，New Features，Known Problems。其中，Fixed部分写明此版本修复了上个版本中存在的的哪些比较大的bug；New Features部分写明此版本新增加了哪些功能；Known Problems部分写明此版本尚存在哪些比较大的问题，有待下个版本改善；或者列出需求不太明确的地方，有待客户给出明确答复意见，在下个版本中完成。

4. 需求管理

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

问题：

客户可能会在一个功能点上来回修改他们的需求，也许开始需要某个功能，结果做完以后又觉得不好，于是让去掉这个功能。后来又由于一些原因，有需要加上。在整个过程中可能来回修改了很多次。那一定要记录下变更的内容和日期。可能后期客户会觉得一个功能怎么会花那么多的时间，不是以前很早就做过

篇四：敏捷测试流程

敏捷测试流程

敏捷开发更注重人与人之间的沟通交流，弱化文档，但是一些必要性的文档还是需要保留。

第一阶段，需求分析验证，测试人员对需求分析的质量控制主要体现在验证该需求的可实现性。本阶段，测试要尽量详细的了解需求，对整个业务有一个比较全面的了解。

第二阶段，迭代过程—研发阶段，项目立项，整个团队进入研发阶段。项目经理制定项目的周期、迭代次数、里程碑事件等，测试的总体时间和规划参照此规范进行。

其中，在每个迭代过程中，

1. 迭代开始会议，测试人员充分了解每个用户故事的功能、输入输出以及该功能的结束标准，并规定软件的交付条件。此会议中，评估时间时需要考虑测试的时间。

2. 测试用例编写及审核。迭代前期，测试人员编写测试用例，测试人员之间互审用例，开发人员和项目经理负责审核测试用例；

3. 执行测试。开发人员交付软件版本，如果符合条件（由测试提出，核心功能验证），测试人员进入测试阶段，包括功能测试，系统测试等，提交bug验证bug以及维护测试用例；

4. 测试结束，测试人员提交本期迭代的完成情况；

5. 迭代结束会议，团队总结本期迭代的经验教训。好的习惯和方法，继续保留；需要改进的地方，下期迭代改进。

另外，最开始的迭代，主要关注功能测试；随着研发过程的推进，除了每个迭代本身的功能测试，需要加入集成了前面迭代的系统测试；还要考虑是否要加入自动化测试； 每日站立会议，描述今日的测试重点以及遇到的困难，加强开发和测试的沟通，提供工作效率。

第三阶段，迭代过程结束，符合准入标准后（同样由测试提出）进入alpha版本测试，alpha测试主要是整个业务流程的系统测试以及性能测试；本期测试结束，发布测试报告。本阶段需要测试人员控制软件版本，保证上线的软件是经过测试的版本。

篇五：敏捷测试

九 01

敏捷测试的方法和实践

作者：baiyuzhong分类：选题策划, 高端视点 阅读：11,298 次添加评论

文 / 朱少民

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

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

?

?

?

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

什么是敏捷测试

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

图

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

敏捷测试流程的优化

在敏捷方法中，需求变化比较快、产品开发周期很短，我们目前采用四周时间，也就是每个?a href="http://www.zw2.cn/zhuanti/guanyuluzuowen/" target="_blank" class="keylink">路⒉家桓鲂掳姹尽？⒅芷诙蹋δ懿欢侠奂樱砑馐源春艽蟮奶粽剑砑馐粤鞒桃鱿嘤Φ牡髡＠纾颐窃械牟馐怨娣睹魅饭娑ǎ紫纫⑾钅康闹鞑馐约苹椋缓笤俳⒚扛龉δ苋挝竦牟馐约苹椋馐约苹橛醒细竦哪０澹倚枰筒肪怼⒖?a href="http://www.zw2.cn/zhuanti/guanyurenzuowen/" target="_blank" class="keylink">人员讨论，并和测试团队其他人员（包括测试经理）讨论，最终得到大家的认可和签字才能通过，仅测试计划经过“起草、评审和签发”一个完整的周期就需要一个月。在敏捷方法中，不再要求写几十页的测试计划书，而是在每个迭代周期，写出一页纸的测试计划，将测试要点（包括策略、特定方法、重点范围等）列出来就可以了。

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

图

2 敏捷测试流程简要图

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

带语言、视频的即时通讯），仅仅通过邮件是不够的。

?

? 参与代码复审（Code Review），并适当辅助开发人员进行单元测试。 在流程中增加一个环节“产品走查（Product Walk-through）”——测试人员和产品经理、

开发人员等在一起，从头到尾将新功能看一遍，可直观、快速地发现问题。

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

测试任务简单地可分为新功能测试和回归测试。在敏捷方法中，针对这两部分的测试建立相应的策略，以提高测试的效率，最大限度地降低质量风险。新功能测试的策略主要有： ? 不需要测试用例，直接基于用例和对需求的理解来完成新功能的验证。即使要写测试用例，

只要保证各个功能点被覆盖，不要过于详细（大颗粒度）。

? 持续地进行验证，一旦某块新代码完成（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）应用的测试框架：OraylisBI.Quality（+ NUnit）。 其他一些协作工具等，如TestLink、BugZilla、BugFree、Wiki等。

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

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

? 在需求和功能设计讨论上，测试人员可以站在客户角度来阐述自己的观点，扮演“用户代表”

角色，强调用户体验，真正体现测试人员和开发人员的互补作用。

? 测试人员不仅扮演“用户代表”角色，而且通过需求讨论、代码复审等各种活动及时地提供质

量反馈，包括代码质量、接口一致性等，保证在产品构造的整个过程中质量受到足够的关注，以提高质量改进的持续性和可视性。

体裁作文