思考：敏捷项目如何展开自动化测试--敏捷测试是什么（1）

在前文《Selenium3自动化测试实战--第1章 自动化测试基础》产生疑问：敏捷项目是否适合展开自动化测试？

本来文章题目叫 思考：敏捷项目是否适合展开自动化测试，但读了几篇文章，都提到了 敏捷测试必须展开自动化测试。那再思考是否适合，已经不适合了。只能改成 思考：敏捷项目如何展开自动化测试。

敏捷(agile)项目的概念，我之前模糊的了解是：

1.敏捷项目，也就是分为 敏捷开发和敏捷测试

2.敏捷项目不断迭代，持续集成+持续测试（这是不是也同时代表着需求不停变更？）

3.讲用户故事（与传统的功能使用场景有区别？）

上面肯定是不准确的，只好不停百度“敏捷测试”。

百度第1篇： https://www.jianshu.com/p/cf676ea815a1

  敏捷开发，以用户需求进化为核心，迭代，循序激进的开发方法。（以用户需求为核心，传统开发不也应该是这样么？ 这里的迭代，与传统的迭代模型有什么区别？）

  敏捷开发，首先是做原型（这不是原型模式么？），然后快速修改弥补需求不足，再次发版。细化story（不就是需求更细化么？）

  敏捷测试，在敏捷开发方法中所需要的测试流程，方法和实践。敏捷测试就是持续测试，持续反馈（在迭代模型中，不也是持续测试？）。需要测试人员扮演用户代表角色，确保产品满足客户需求（测试人员站在用户的角度进行测试，不是一直这样么？）

  敏捷测试与传统测试侧重点不同有以下几点：

  1 减少测试计划，测试用例设计等工作，只在每个迭代周期，测试计划将测试要点（策略，特定方法，重点范围）列出来。测试用例针对story直接验证，节约出来的时间，用于开发原有功能的自动化测试脚本，为回归测试服务。

  （关于这点，减少测试计划，我们倒是一直这样，但我觉得省略的测试要点之外的部分，也节省不了多少时间。至于测试用例，我们更是有时全部省略。）

  （说开发原有功能的自动化测试脚本，从实际经历上讲，因为需求的不详细，新迭代的功能往往导致原有功能变动不小，如果使用自动化测试脚本，常常开发加修改脚本的时间，比手动回归，还花更多时间。）

  2 测试人员需要更加关注探索性测试，组合交互性测试和用户场景测试。

  （我的测试经历就是以用户场景为测试中心，结合组合交互性测试和探索性测试。因为需求描述不详细，只能展开探索。。。）

  3 增加与产品设计人员，开发人员的交流和协作

  （这也算敏捷？因为需求不详细，开发人员按着自己的理解开发的，尤其是原型后面的数据处理逻辑，很多时候与测试人员的理解不一致，只能互相讨论，甚至找产品讨论、确认，往往导致开发和测试都要返工。交流确实是多了。）

  4 在敏捷开发流程中增加“产品走查”的环节。

  （在传统项目模型中，也有这一步吧？）

  5 测试人员需要有较强的代码功底：包括回归测试的自动化测试和代码复审，安全测试等。

  （这里倒是对敏捷测试是否适合展开自动化测试有了直接的答案。但代码复审这个，在传统项目中，是由开发组内部也有的，敏捷测试是改成由测试人员进行？）

  最后提到敏捷测试的难点，也说到因为敏捷开发的功能和页面都会经常变化，UI自动化测试投资与回报会非常低（这也算回答了我第1点时的疑问）。回归测试依赖自动化测试，应该以接口自动化为主（难道接口就不常变化么？功能变，一般接口也会变吧）。

  至于说持续测试的过程，就是有时间就测试（废话），开发和产品也参与到日常的测试（更是废话，开发说自己提交时测试过就算不错了。产品也就在功能基本没问题后才走走主流程。）

  （另外想到，感觉敏捷就是将整个需求拆分到尽量小的迭代中。但实际的项目，往往很难这样拆分到很小，或者说，往往系统的整个功能都是相互关联，一部分完不成，往往即便开发完的部分，也无法测试。）

百度第2篇：https://baijiahao.baidu.com/s?id=1715553167720460193&wfr=spider&for=pc

  敏捷测试 vs 传统测试

传统测试	敏捷测试
1，测试发生在最后阶段	1，测试发生在每个Sprint迭代里
2，组与组之间的沟通是正式的	2，组与组之间除了正式沟通外也有很多非正式沟通
3，测试自动化是可选项	3，测试自动化被高度推荐
4，测试以需求文档为准	4，测试以最终用户为准
5，详细的测试计划	5，精益化的测试计划
6，计划是一次性活动	6，计划分为不同的级别 --开始阶段为粗粒度的计划 --在Sprint 0 及后续Sprint为Just-in-Time式计划
7，项目经理计划整个团队的工作	7，团队被授权和主动参与到计划中
8，开始阶段要求详细需求	8，开始阶段允许High-Level需求
9，需求被定义后客户有限的参与	9，客户参与贯穿到整个项目生命周期

  该文中又强调了”开发、测试人员角色的职能变得模糊化“。但我认为，首先这需要每个人的自我责任感强和能力强，才会测试帮审代码，开发帮测试；其次，容易导致责任不清，拖延进度。

  该文中又强调”轻流程，减少不必要的文档“。但传统测试，也不是每个项目都严格按照标准的流程进行。也不是必须要有所有相关文档，需要准备的文档也不会按标准格式完全填写，都是根据公司和项目实际情况有所改变。这也能是传统测试和敏捷测试的区别？

  最后，该文也强调了自动化是敏捷测试非常重要的元素。从上面2篇文章，基本可以确定：敏捷项目不但适合展开自动化测试，而且是必不可少的一部分。

  针对上面9点，我一一总结一下：

  1 敏捷测试发生在每个Sprint。传统的迭代模型不也是这样？

  2 组与组的沟通多了非正式沟通。就算是传统测试，也有非正式的沟通吧。

  3 自动化被高度推荐。这是我一直思考的。

  4 测试以用户为准。在传统测试中，需求文档的评审，不也是以用户为准么？如果评审通过后，以需求文档为准和以用户为准有什么区别？

  5 精细的测试计划。即便是传统测试，也应该要求精细，有重点，而不是完全照本宣科，啰里啰嗦。

  6 计划分为不同的级别。传统测试中，测试计划往往随着项目进展，不断更新啊。

  7 团队被授权和主动参与计划。传统测试中，项目的计划，和开发计划，测试计划也应该是互相参照。只是项目经理完成最后的汇总而已。

  8 开始阶段要求High-level需求。我们现在的项目，往往也是给出简单的原型，需求不详细。但结果就是，不用长时间等需求，快速开始，但后面就往往因为需求理解不一致，导致大量的BUG，然后开发和测试返工。

  9 客户参与贯穿整个项目周期。传统测试中，需求定义后，客户往往只会进行最后的验收测试，当然中途有问题，也会由产品或测试找客户确认。这与敏捷提的贯穿什么区别？

  即便这样，我还是感觉，依据敏捷的特点，自动化测试仍是难以展开。----继续学习。

百度第3篇：https://www.cnblogs.com/TesterChang/p/16416042.html

  该文提出了敏捷测试的几种应用形式：

  1 每日站会

  我说不清我们项目是不是敏捷测试，但也有每日站会，介绍每个人的昨天完成的，遇到的问题，今天要做的。但感觉很多时侯都流于形式。不说其它，遇到的问题，说别人造成的问题，容易导致同事不和，说自己的问题，显得自己无能，大实话吧？

  2 迭代复盘

  每个Sprint结束后，项目组成员回顾迭代目标，结果，过程，总结。

  首先，我还是不清楚，敏捷的迭代，和传统测试迭代模型的迭代有什么区别？

  其次，我们也有迭代，但不像敏捷测试提到的迭代，甚至一两天一个迭代。而是很粗的一期，二期。每期都很长。每期的任务会按功能模块的重要性和关联关系，确立优选级。

  最后，如何说结束后的回顾，一般都是测试人员提交测试报告（正式的，非正式的），每个人更想简单知道系统是不是测试通过，能否上线了。

  3 测试驱动开发

  测试驱动开发，重要是在编码之前先写测试代码。后面根据测试代码进行编码，最后用测试代码去验证编码。

  不论这步说如何好，如何重要。现实情况是，1，测试写测试代码，那这时开发干吗？2，这要求测试的代码能力至少不弱于开发，如果这样还有多少人做测试？3，没了，反正没见过这样的。

  最后，文中提到敏捷测试的核心是质量内建，目标不是发现更多的BUG，而是帮助开发人员理解需求。真的是高大上，但不知道实际项目如何进行，如何与传统测试区别开来。

百度第4篇：http://wjhsh.net/lcw-p-4059291.html

  第一部分：敏捷软件开发简介

  4.1 敏捷的4条价值原则：

  1 人员交流重于过程与工具。（重于？难道过程与工具不也是为了方便交流么？口头的交流，最终导致的就是记忆的错乱，责任的不清）

  2 软件产品重于长篇大论。（观念完全正确，但传统的也不是倡导 长篇大论重于软件产品）

  3 客户协作重于合同谈判。（这完全看公司做事风格了。不论是和外公司，还是同公司不同部门间，协作当然重要，但最好还是落于纸上。）

  4 随机应变重于循规蹈矩。（先立规矩，有了变化，再跟着变。这叫应变。如果开始就没规矩，直接追求随机应变，那叫偷懒，叫乱弹琴。）

  4.2 敏捷软件开发流程：

看下来与迭代模型（scrum）差不多啊，只是多了一个daily meeting。这是玩笑话。读了这几篇文章，已经发现敏捷Agile，是夹杂了迭代（Scrum)，极限编辑（XP)，特征驱动开发（Feature Driven Development)，测试驱动开发（Test Driven Development）。现在要了解敏捷Agile，就是要找出他们的区别。不能一直带着“差不多”的想法。差不多，也总是有差的地方。

项目经理根据项目进度和缺陷严重性来决定是否修复昨日的问题。需要及时修复的是目前Sprint中的一个新任务，将由项目经理添加到Sprint Backlog上，并通知开发人员去修复漏洞。

对于敏捷开发和测试中的审查过程，极限编程中的同行评审（peer review）思想得到了充分应分。代码和文档的审查追求简单而高效。团队成员两两组成一对，互相评审；有时侯，一个开发和一个测试也可以组成一对，互相协作。这样有助于缺陷和问题在第一时间被萌芽中。（感觉这是这篇文章，说得通透、有用。）

4.3 敏捷开发还有以下几个关键概念：

1 迭代过程（iterative process) 

2 用户故事（user stories)

3 任务（Tasks）

4 站立会议（Stand-up meeting)

5 持续集成（CI: Continuous integration)

6 最简方案（Simplest solutions)

7 重构（Re-factoring)

第二部分：敏捷开发中的测试人员

2.1 敏捷开发团队介绍

programmer（开发人员），tester(测试），product designer(产品设计），program manager,project manager（项目经理）.

program manager的中文名称没有准确的，网上有人说是 项目集经理，指 项目经理的上级。

2.2 测试人员需要具备的素质

不同的组织给测试人员不同的称号：

测试开发(test developer)， 具体质量检测和编写代码的能力

质量分析员(QA quality analyst)，防止缺陷和质量控制的能力

软件质量工程师（Software Quality Engineer），开发和执行测试程序的能力

总体而言，三方面的基本素质：代码编写，测试，分析。不同测试阶段对测试人员能力有所不同，但敏捷开发流程中，测试人员需要结合这三方面来开展工作，只有这样才能真正反映敏捷测试的本质：简单而高效地应对变化。

2.3 测试人员的主要职责

1 定义质量，基本职责，敏捷方法鼓励测试人员在sprint计划的时候直接与客户交流（那产品经理有什么用？测试好几个，一个个交流？），从自己的经验出发，共同为产品功能制定质量要求。

2 交流缺陷，团队中的交流。测试人员抓开发人员不注意的细节。测试人员验收测试来鉴定客户需求与实际成果之间的不一致性。

3 及时反馈，敏捷强调简单而高效。测试人员需要及时反馈（这没问题啊，谁不是发现问题就提BUG）。敏捷要求每天汇总质量问题（不好摸鱼了）

第三部分：敏捷开发中的测试流程（重头戏，通过项目实例来了解敏捷测试）

3.1 介绍项目实例

项目介绍：根据一家在线B2B公司的要求，我们将为其开发一款类似于谷歌的搜索服务，作为web service，该服务可以内嵌于网页中。当用户输入关键词并选择商户的类型和位置后，系统会返回具体商户的列表。

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

通常Sprint周期被分成两类：特征周期（Feature Sprint）和发布周期（Release Sprint).

特征周期，主要涉及新功能的开发和各类测试。

发布周期，结合计划，确定新版本功能，然后对最新的功能进行测试。

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

3.2.1 寻找隐藏的假设

项目实例：

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阶段

工作负载值为75%，就是每个人平均工作6小时（以8小时算）

3.3.1 估算验收测试时间

现在需要在每个Sprint机会会议上估算两周到一个月的任务。此外，在每天的站点会议上，测试人员需要不断得更新自己的估算时间，以应对变化的需求。所以，每个测试人员都应该具备一定的估算任务能力。

估算测试计划的方法：

1 快速而粗糙的方法

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

项目实例：

考虑到系统有模糊搜索的功能，所以任务可能占40%

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

2 细致而周全的方法

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

  1 测试的准备（设计测试用例，准备测试数据，编写自动测试代码并完善代码）

  2 测试的运行（建立环境，执行测试，分析和汇总结果）

  3 特殊的考虑

项目实例：

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

测试	准备		运行		特殊考虑	估算
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
总共				33.8

3.3.2 估算测试框架的搭建

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

测试框架只需要在第一个Sprint周期里作为任务，后面的除非大幅度调整，不再需要。

项目实例：

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

3.3.3 详细设计验收测试用例

对概要设计中的测试用例进行细化，根据不同的测试环境，测试数据及测试结果，编写更详细的测试用例，另外，可以结合几个用例，完成一个复杂的测试操作。

对测试人员而言，一个有效的方法是尽量将一些验证基本功能的测试用例作为基本验证测试用例在第一时间实现自动化；而对一些复杂的功能测试用例，可以先采用手工的方法测试。直到在未来Sprint周期中该功能达到稳定时间再考虑自动化。此外，对测试中出现的缺陷可以设计回归测试用例，为其编写自动化测试代码，使得此类问题在发布周期可以顺利而高效得进行验证。

项目实例：

基本验证测试用例：

动作	数据	期待的结果
登录	用户名 空，密码 空	用户名和密码无效

功能测试用例：

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

类型这种，应该使用下拉列表控件，怎么会出现错误的类型？

3.3.4 编写验收测试用例

敏捷开发不提倡写太多的文档，提倡直接编写测试用例（我们是这样，但应该不是敏捷）。此外，测试人员和客户应取得良好的沟通，将这些需求总结下来，转化为验收测试用例（使用正确的用例中优先级别较高的不行么？）如果资源充足，最好对验收测试用例建立版本控制机制。

考虑到需求在每一轮Sprint周期中会不断得变化，测试团队要控制测试的自动化率，正确估计未来功能的增减。自动化率过高会导致后期大量测试代码需要重构，反而增加很多工作量。

3.4 Sprint结束和下一个Sprint开始

回顾会议。由于敏捷开发倡导增量开发，当新的Sprint开始时，测试团队需要根据新Sprint周期的开发进度及时重构验收测试。如果新Sprint周期没有具体的新功能开发，测试团队可以将精力集中在执行验收测试和寻找缺陷上。

如果下一个Sprint周期是发布周期，那么测试人员需要准备执行回归测试。

3.4.1 重构验收测试

项目实例：

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

3.4.2 执行验收测试

基本验证测试和功能测试。基本验证测试，推荐开发人员在运行完单元测试和提交代码前直接运行自动测试脚本。

功能测试，在每个Sprint后期，新功能代码提交后，由测试人员单独执行。

如果每个BUG，都靠测试与开发口头交流，不但慢，而且问题一多，绝对记不住。还是记录在BUG管理系统中最安全，快捷。

3.4.3 执行回归测试

首先，要建立一套自动生成build，运行自动测试代码，手工执行测试用例，并汇总测试结果的框架。

其次，定期执行各类测试，包括功能和系统测试

最后，整理之前在每个特征测试周期中出现的问题。如果已经整理并归类为回归测试用例，那么只要定时执行就可以了。否则，需要一一添加。如果用例已经被自动化，可以直接运行，如果是手工测试，测试人员需要按照测试用例进行操作，最后汇总测试结果。这部分测试就是所谓的回归测试

总结

手工测试有两个主要的缺点：不可靠和容易被遗忘。比如，在文中的搜索实例中，一旦我们重新建立索引，那么先前在搜索文本中出现的文字错误就无法重现。（没明白）另外，当测试人员按部就班得手工完成一个个测试用例时，他们很容易遗忘一些特殊的测试用例，很多缺陷因此而被埋没。（这也算问题？归根到底，是测试用例设计时有没有遗忘。至于执行时，一些不在用例中的特殊问题是不是能发现，我觉得手工测试更容易发现。毕竟自动脚本执行时，测试人员走开去潇洒了，更会遗漏问题。）

敏捷测试主张一些基本的验收测试可以被自动化；对一些涉及系统方面的测试，手工测试比较适合。（赞成）

敏捷测试，测试报告可以以网页的形式发布到内部的web服务器上。在一些问题区域上标注鲜明的色彩，用来警示团队中的每个人。

 

第4篇百度文，自己感觉是最有料的。虽然仍有部分有疑问，但该文确实详细，实用的多。我摘抄的内容是节选的重要的，一些我觉得啰嗦的或很明白的，就没有再摘抄。有要看全文的，可以去看原文。