敏捷测试实例

敏捷测试实例^[1]

2015-06-04

目录

1 敏捷软件开发流程
2 敏捷开发中的测试人员
  2.1 敏捷开发团队介绍
  2.2 测试人员的主要职责
3 敏捷开发中的测试流程
  3.1 介绍项目实例
  3.2 用户故事设计和发布计划阶段
    3.2.1 寻找隐藏的假设
    3.2.2 设计概要的验收测试用例
  3.3 迭代 Sprint 阶段
    3.3.1 估算验收测试时间
    3.3.2 估算测试框架的搭建
    3.3.3 详细设计验收测试用例
    3.3.4 编写验收测试用例
  3.4 Sprint 结束和下一个 Sprint 开始
    3.4.1 重构验收测试
    3.4.2 执行验收测试
    3.4.3 执行回归测试
4 总结

1 敏捷软件开发流程

---

 返回

 图 1. 敏捷软件开发流程

整个过程当中夹杂了不少在敏捷开发前己经出现的软件开发方法，包括极限编程（Extreme Programming,1996）、Scrum（1986）、特征驱动开发（Feature Driven Development），测试驱动开发（Test Driven Development）等。这些方法在敏捷软件开发流程的各个阶段都有充分的体现和应用。

• Scrum 主要着重于项目管理，团队中的项目经理（Scrum master）须要在每一个客户需求到来的时候制定 Sprint 的周期，定义每一个 Sprint 的目标、分派任务、进行监督、最后总结得失并开始计划新的 Sprint。
• 特征驱动开发和测试驱动开发主要被应用于 Sprint 周期中。若是项目进行于开发新功能时期，这个阶段主要推行特征驱动开发。全部测试和开发人员都将本身的工做重心放在新的功能上面，从开发和测试两个方面来完成各自的任务。若是项目进行于测试新功能时期，这个阶段须要将工做的重点挪到测试上来。全部的测试和开发人员都密切关注着目前版本的缺陷情况。测试人员须要在天天的站立会议（Daily Standup Meeting）上报告前一个工做日发现的新缺陷状况，项目经理根据项目进度和缺陷严重性来决定是否修复这些问题。须要及时修复的缺陷是目前 Sprint 中的一个新任务，将由项目经理添加到 Sprint Backlog 上并通知开发人员去修复漏洞。
• 对于敏捷开发和测试中的审查过程，极限编程中的同行评审（peer review）思想获得了充分应用。代码和文档的审查追求简单而高效。团队成员两两组成一对，互相评审；有时候，一个开发和一个测试人员也能够组成一对，互相协做。这样可以有助于缺陷和问题在第一时间被抹杀在萌芽中。

敏捷开发还有如下几个关键概念 (Key Issues)：

• 迭代过程（Iterative process）
• 用户故事（User stories）
• 任务（Tasks）
• 站立会议（Stand-up meeting）
• 持续集成（Continuous integration）
• 最简方案（Simplest solutions）
• 重构（Re-factoring）

2 敏捷开发中的测试人员

---

 返回

2.1 敏捷开发团队介绍

咱们的敏捷开发团队由四位开发人员、两位测试人员、一位产品设计，一位项目经理和一位产品经理组成（参见图 2）。天天早上十点，在固定的时间和会议室里面，团队会举行站立会议。这时候，团队成员按照既定的顺序向项目经理汇报各自前一天完成的任务，所遇到的困难和当天要完成的任务。同时，项目经理更新 Sprint Backlog（一张制做精良的 Excel 表格），并及时解决每一个人所提出的问题。敏捷团对人数不宜过多，不然会增长沟通成本。

图 2. 敏捷开发团队成员

2.2 测试人员的主要职责

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

• 定义质量 (Define Quality)：这应该是软件测试人员的基本职责。敏捷方法鼓励测试人员在 Sprint 计划的时候直接与客户交流，从本身的经验出发，共同为产品功能制定质量要求。
• 交流缺陷（Communication）：敏捷过程强调团队中的交流。开发人员常常会专一于重要而新奇的功能，测试人员应该抓住细节，寻找设计中的“missing door”；另外，开发人员使用单元测试来保证产品的基本质量，测试人员可使用验收测试（Acceptance Test）来鉴定客户需求与实际成果之间的不一致性。
• 及时反馈 (Feedback): 敏捷过程强调简单而高效。测试人员须要及时反馈产品目前的质量问题。这样一来，团队才能够马上着手解决。若是传统的流程是一周汇总一次状态的话，敏捷流程要求天天汇总质量问题。在咱们的项目中，内部的测试报告会以网页的形式显示在内部站点上。每一个团队成员可以随时获取。另外，咱们的测试框架提供自助测试 (Self-assistant Test)：经过点击测试用例列表中的某个具体用例，开发人员不须要中断测试人员的工做就能够重现缺陷。

3 敏捷开发中的测试流程

---

 返回

下面详细介绍项目流程中的主要测试活动，每一个活动的前提条件和目标任务等。

3.1 介绍项目实例

项目介绍：根据一家在线 B2B 公司的要求，咱们将为其开发一款相似于谷歌的搜索服务。做为 Web Service，该服务能够内嵌于网页中。当用户输入关键词并选择商户的类型和位置后，系统会返回具体商户的列表（参见图 3）。

图 3. 项目实例图

敏捷开发它主要由三部分构成，每一个时间段都有相应的测试活动：

1. 从最初的用户故事设计和发布计划，
2. 到几回 Sprint 周期的迭代开发和测试，
3. 以及最后的产品发布阶段。

图 4. 敏捷开发 三部分构成

一般 Sprint 周期被分红两类：特征周期（Feature Sprint）和发布周期（Release Sprint）。特征周期主要涉及新功能的开发和各种测试。发布周期则会结合计划，肯定新版本功能，而后对最新的功能进行测试。

表一：敏捷开发和测试活动

敏捷开发的主要活动	测试活动
用户故事设计	寻找隐藏的假设
发布计划	设计概要的验收测试用例
迭代 Sprint
编码和单元测试	估算验收测试时间 -> 估算测试框架的搭建 -> 详细设计验收测试用例 -> 编写验收测试用例
重构
集成
执行验收测试 or 执行回归测试	执行验收测试 or 执行回归测试
Sprint 结束
下一个 Sprint 开始	重构验收测试
发布	发布

 

在上表中，迭代的 Sprint 周期（Feature Sprint）中，开发部分能够根据传统步骤分红编码和单元测试、重构和集成。须要指出的是，重构和集成是敏捷开发的 Sprint 迭代中不可忽视的任务。若是在新的 Sprint 周期中要对上次的功能加以优化和改进，必然离不开重构和集成。

在每一个 Sprint 周期结束前，测试团队将提交针对该 Sprint 周期或者上个 Sprint 周期中已完成的功能的验收测试（在实际项目中，测试团队的进度一般会晚于开发团队）。这样一来，开发团队能够运行验收测试来验证所开发的功能目前是否符合预期。固然，这个预期也是在迭代中不断变化和完善的。

当产品的全部功能得以实现，测试工做基本结束后，就进入了发布周期（Release Sprint）。此时，测试团队的任务相对较多。

3.2 用户故事设计和发布计划阶段

在用户故事和发布计划阶段，项目经理和产品经理会根据客户的需求，制定概要的产品发布日程计划。此时，测试人员能够和开发人员一块儿学习新的功能，了解客户的需求。其中，有两个主要活动：寻找隐藏的假设和设计概要的验收测试用例。

3.2.1 寻找隐藏的假设

正如前文所述，开发人员一般关注一些重要的系统功能而忽视细节。此外，敏捷开发倡导简单的实现方案，每一个开发 Sprint 周期不可能将功能完美得实现；相反，每一个 Sprint 都会增量得开发一些功能。因此，测试人员在最初就须要从各类角度来寻找系统需求，探索隐藏的假设。

项目实例：

1.从在线 B2B 公司角度思考

Q：这个搜索框对公司的业务有什么价值？

A：搜索框能够为用户方便得提供商户的目录信息。若是愈来愈多用户使用这个搜索框，能够增长咱们网站的访问量。

2.从用户角度思考

Q：做为查询信息、寻找商业合做伙伴的网站用户，搜索框对我有什么好处？

A：坏处：找到一家商户的地址，过去才发现已经关门歇业

     好处：查找商户很简单，只要轻点鼠标

     不快：有时候在寻找一类商户，却记不清楚具体名字

3.从程序员角度思考

Q：一个搜索框的最简单实现方法是什么？

A：一个有 text input 和 search button 组成的 form；后台经过 server 程序将符合类型和地址的商户名从数据库中取出，返回给用户；每一个返回项包括商户的名称、地址和评价意见。

4.寻找这些观点中的问题

Q：搜索框如何在用户忘记具体名字的时候提醒用户？

A：在初版本中实现比较困难。可让用户输入至少一个类型来提升模糊查找的效果。

5.最后寻找到隐藏的假设

以上的思考让测试人员对系统的隐含假设更加清晰：

• 首先，系统应该可以在高峰时候处理 200 条搜索请求和 1000 个鼠标点击事件。
• 其次，用户能够在已经查找到的内容中继续查找
• 最后，系统提供一个商户类别清单；若是用户选择商户类别而忘记具体名字，系统提供模糊查询。

在敏捷开发中，这些假设能够做为用户故事记录下来，从而指导将来系统的开发和测试。

3.2.2 设计概要的验收测试用例

定义完一系列用户故过后，测试人员就能够着手设计概要的验收测试用例。正如咱们在前文论述，不一样于单元测试，验收测试检查系统是否知足客户的预期，也就是用户故事是否可以实现。因而，测试人员能够根据每条用户故事来扩展，寻找其中的“动做”，而后为每条“动做”制定正例和反例。

项目实例：

动做	数据	期待的结果
搜索	一组能成功搜索到的（类别，位置）数据	在该类别和位置条件下的一组商户信息
搜索	一组不能成功搜索到的（类别，位置）数据	空列表

 

3.3 迭代 Sprint 阶段

当一个 Sprint 周期正式开始时，项目经理将制定该周期的具体开发和测试任务。在按期的 Sprint 计划会议（Planning Meeting）上，每位团队成员都要提供本身在将来一个 Sprint 周期中的休假和培训计划。另外，每一个团队能够根据各自团队成员的能力和工做经验，适当设定一个工做负载值（Load Factor）。好比，咱们团队的工做负载值为 75%，也就是说每一个人平均天天工做 6 小时（以 8 小时计算）。接着，你们就能够开始分配任务。

当开发团队开始编码和单元测试时，测试人员的工做重点包括：估算验收测试的时间、估算测试框架的搭建、详细设计验收测试和编写验收测试代码。第两个主要活动通常在项目初期的 Sprint 周期中完成。其余的三个主要活动将在接下来的多个 Sprint 周期中视状况迭代进行。下面咱们将具体介绍每一个主要活动。

3.3.1 估算验收测试时间

在软件开发初期，须要估算时间以制定计划。这一点在敏捷开发中应用更加普遍。若是之前的开发模式须要测试人员估算一个软件版本发行的计划（这样的计划一般会延续几个月），那么如今则要在每一个 Sprint 机会会议上估算两周到一个月的任务。此外，在天天的站立会议上，测试人员须要不断得更新本身的估算时间，以应对变化的需求。因此，每一个测试人员都应该具有必定的估算任务能力。

下面咱们将介绍两个通用的估算测试计划的方法：

1.快速而粗糙的方法

从经验而言，测试一般占项目开发的三分之一时间。若是一个项目开发估计要 30 天 1 人，那么测试时间为 10 天 1 人。

项目实例：

搜索框的开发估计须要 78 天 1 人完成。可是，考虑到系统有模糊搜索的功能，因此测试任务可能会占 40％左右，大概 31 天 1 人。下面列出了具体的任务：

任务	估计时间
设计测试用例，准备测试数据（搜索数据集）	8
加载数据集	2
编写自动测试代码	18
执行测试和汇报结果	3
总结	31

 

2.细致而周全的方法

这个方法从测试任务的基本步骤出发，进行详细分类。其中包括 :

• 测试的准备（设计测试用例、准备测试数据、编写自动测试代码并完善代码）
• 测试的运行（创建环境、执行测试、分析和汇报结果）
• 特殊的考虑

项目实例：

估算单个测试任务的事例参见下表：

测试	准备		运行		特殊考虑	估算
1	设计测试用例	0.5	创建环境	0.1
	准备测试数据	0.5	执行测试	0.1
	编写自动测试代码	0.5	分析结果	0.1
	完善自动测试代码	2.5	汇报结果	0.1
总共		4		0.4	0	4.4

估算多个测试任务的汇总参见下表：

测试任务编号	准备	运行	特殊考虑	估算
1	4	0.4	0	4.4
2	4	0.4	0	4.4
3	12	4.5	8.5	25
4	4	0.4	0	4.4
5	4	0.4	0	4.4
6	4	0.4	0	4.4
7	4	0.4	0	4.4
总共				51.4

3.3.2 估算测试框架的搭建

测试框架是自动测试必不可少的一部分工做。因为敏捷开发流程倡导快速而高效得完成任务，这就要求必定的自动测试率。一个完善的测试框架能够大大提升测试效率，及时反馈产品的质量。

在敏捷开发流程中，在第一个 Sprint 周期里，须要增长一项创建测试框架的任务。在随后的迭代过程当中，只有当测试框架须要大幅度调整时，测试团队才须要考虑将其单独做为任务，不然能够不用做为主要任务罗列出来。

项目实例：

考虑该项目刚刚进入测试，须要为此创建一个测试框架。因而，在原先的估算中多增长一些任务。

任务	估算（小时）
选择测试工具	3
创建测试系统	3
编写下载、存放和恢复测试数据的脚本	2
寻找或创建测试结果汇报工具	8
设计具体的搜索测试用例	4
准备搜索测试数据	4
编写和测试“搜索”模块	3
编写和测试“验证返回列表”的模块	1
学习“在结果中搜索”的模块设计	4
编写和测试“在结果中搜索”模块	4
第一次执行测试	4
分析第一轮测试结果	4
第二次执行测试	4
分析第二轮测试结果	4
总共	52

3.3.3 详细设计验收测试用例

完成对测试任务的估算，接着就能够着手详细设计验收测试用例。咱们能够对概要设计中的测试用例进行细化，根据不一样的测试环境、测试数据以及测试结果，编写更详细的测试用例。另外，能够结合几个用例，完成一个复杂的测试操做。

因为敏捷开发的流程是不断迭代的过程，因此不少复杂的功能可能会在将来的 Sprint 周期中被优化。对测试人员而言，一个有效的方法是尽可能将一些验证基本功能的测试用例做为基本验证测试用例（Basic Verification Test Case）在第一时间实现自动化；而对一些复杂的功能测试用例，能够先采用手工的方法测试，直到在将来 Sprint 周期中该功能达到稳定时候再考虑自动化。此外，对测试中出现的缺陷能够设计回归测试用例（Regression Test Case），为其编写自动测试代码，使得此类问题在发布周期（Release Sprint）时能够顺利而高效得进行验证。

项目实例：

基本验证测试用例：

动做	数据	期待的结果
登陆	用户名：（空） 密码：（空）	“用户名和密码无效”

功能测试用例：

动做	数据	期待的结果
登陆	正确的用户名和密码	进入系统：请输入搜索条件并点击“搜索”按钮
搜索	错误的类型	提示正确的类型
搜索	使用正确的类型	商户列表

 

3.3.4 编写验收测试用例

敏捷开发不提倡撰写太多的文档，提倡直接编写测试用例。此外，测试人员和客户应取得良好的沟通，将这些需求总结下来，转化成验收测试用例。若是资源充足，最好对验收测试用例创建版本控制机制。

考虑到需求在每一轮 Sprint 周期中会不断得变化，测试团队要控制测试的自动化率，正确估计将来功能的增减。自动化率太高会致使后期大量测试代码须要重构，反而增长不少工做量。

3.4 Sprint 结束和下一个 Sprint 开始

在一个 Sprint 周期结束时，团队要举行一个回顾会议（Retrospective Meeting）。团队成员能够在会议上畅所欲言，指出在过去一个 Sprint 周期中可行的，不可行的和有待改进的地方。待改进之处将在项目经理监督下于将来的 Sprint 周期中实现。

因为敏捷开发倡导增量开发，当新的 Sprint 开始时，测试团队须要根据新 Sprint 周期的开发进度及时重构验收测试。若是新 Sprint 周期没有具体的新功能开发，测试团队能够将精力集中在执行验收测试和寻找缺陷上。

如果下一个 Sprint 周期是发布周期，那么测试人员须要准备执行回归测试。下面咱们来详细了解每一个测试活动。

3.4.1 重构验收测试

正如上文所说起，敏捷开发是以迭代方式进行的，功能在每次迭代中推陈出新。因而，验收测试用例常常须要修改或者添加，相应的验收测试代码也须要删减。这部分工做若是时间花销很大，最好在估算的时候一并提出。

项目实例：

在下一个 Sprint 周期中，咱们须要实现以前没有实现的“模糊查找”功能。测试人员要在新的 Sprint 周期中更新原来的验收测试用例，在测试“搜索”模块中添加模糊查找测试。从新估算的测试任务参加下表：

任务	估计时间
设计测试用例，准备测试数据（模糊搜索数据集）	2
加载数据集	1
编写自动测试代码	3
执行测试和汇报结果	2
总结	8

 

3.4.2 执行验收测试

验收测试能够分为两大类，基本验证测试和功能测试。若是是基本验证测试，推荐开发人员在运行完单元测试和提交代码前直接运行自动测试脚本。若是是功能测试，能够在每一个 Sprint 后期，新功能代码提交后，由测试人员单独执行。

敏捷开发的开发和测试是相辅相成的。一旦基本验证测试出现问题，那就说明开发人员的实现违反了最初客户定义的需求，因此不可以提交。若是功能测试出现问题，那么测试人员要及时与开发人员沟通。若是是缺陷，需及时上报给项目经理，并在天天站立会议中提出；若是不是，那么继续下一项任务。这个过程充分体现了敏捷开发所提倡的团队交流机制。

3.4.3 执行回归测试

在发布周期中，测试人员所肩负的任务很是重要，由于这是产品发布前的最后质量检验。

• 首先，要创建一套自动生成 build、运行自动测试代码、手工执行测试用例并汇总测试结果的框架。估算方法参加上文。
• 其次，按期执行各种测试，包括功能和系统测试。
• 最后，要整理以前在每一个特征测试周期中出现的问题。若是已经整理并归类为回归测试用例，那么只要定时执行就能够了；不然，需一一添加。若是用例已经被自动化，能够直接运行；若是是手工测试，测试人员须要按照测试用例进行操做，最后汇总测试结果。这部分测试就是所谓的回归测试。

总结

---

 返回

以上咱们回顾了敏捷测试在整个项目开发中的基本流程。详细介绍了各阶段存在的主要测试活动，结合实际项目，叙述每一个测试活动的最佳实践。

最后，咱们来探讨一下测试中的两个问题：手工测试和测试报告。

手工测试和自动测试是两个主要的测试类型。考虑到敏捷开发的高效性，自动测试会优于手工测试。手工测试有两个主要的缺点：不可靠和容易被遗忘。好比，在文中的搜索实例中，一旦咱们从新创建索引，那么先前在搜索文本中出现的文字错误就没法重现。另外，当测试人员循序渐进得手工完成一个一个测试用例时，他们很容易遗忘一些特殊的测试用例，不少缺陷所以而被埋没。敏捷测试主张一些基本的验收测试能够被自动化；对一些涉及系统方面的测试，手工测试比较适合。

测试报告是反映一个测试团队工做的最好成果。为适应敏捷开发的节奏，测试报告能够以网页的形式发布在内部的 web 服务器上，在一些问题区域上标注鲜明的色彩，用来警示团队中的每一个人。

参考 

[1] 从一个实例详解敏捷测试的最佳实践