什么是敏捷测试？传统的开发模式和敏捷开发模式有什么不同？(测试开发项目需求客户)

最后，关于软件测试学习，offer选择等等，都可以通过后台私信交流。
需要学习资料或者帮忙修改简历也可以私信！
！
也可百度搜索“特斯汀软件测试腾讯课堂”或关注公众号“特斯汀软件测试”，里面涵盖很多精彩免费视频或干货知识

1、什么是敏捷测试？

2、传统的开发模式和敏捷开发模式有什么不同？

3、到底如何进行敏捷开发呢？

敏捷开发分类：敏捷开发的实现主要包括 SCRUM、XP（极限编程）、Crystal Methods、FDD（特性驱动开发）等等。
其中SCRUM与XP最为流行。

一、四大价值观（特点）

敏捷开发的特点就是下面4句话：

「个体与交互」胜过「过程与工具」

「可以工作的软件」胜过「面面俱到的文档」

「客户协作」胜过「合同谈判」

「响应变化」胜过「遵循计划」

说明：

（1）敏捷开发（scrum）适用于竞争激烈，快速变化的市场。
敏捷的客户协作观念，快速迭代能帮助团队以最小的成本，最快速度满足客户真正的需求。
对比传统开发模式来说：

（2）传统开发模式以文档为驱动，而敏捷开发提倡少写文档

传统开发模式下开发人员按照产品文档进行研发，过程中客户不参与到产品的验收和体验中，这样就会导致最后开发出来的成品并不是客户想要的。
而敏捷开发模式从开始就强调客户协作，分步提供产品模块客户体验。

（3）敏捷模式采取迭代式开发，传统模式采用瀑布式开发。

敏捷开发采取迭代式开发的形式，即每个阶段有每个阶段需要完成、并且能使用的产品，这一阶段只要开发某几个功能，且这些功能的产品必须是可以使用的，这一阶段产品完成之后与客户进行对接交付，再进行下一阶段的开发。

（4）敏捷开发更适应变化

传统开发模式下软件开发过程是执行研发计划，而实际工作中，需求往往在开发过程中会产生巨大变化。
敏捷开发更能适应不确定性强的产品和市场。

二、十二原则

1-我们的最高目标是通过尽早和持续第交付有价值的软件来满足客户；

2-欢迎对需求提出变更 - 即使在项目开发后期，也要善于利用需求变更，帮助客户获得竞争优势；

3-要不断交付可用的软件，周期从几周到几个月不等，越短越好

4-项目过程中，业务人员与开发人员必须在一起

5-要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务

6-无论是团队内还是团队间，最有效的沟通方法是面对面的交谈

7-可用的软件是衡量进度的主要指标

8-敏捷过程提倡可持续的开发，项目方，开发人员和用户应该能够保持恒久稳定的进展速度

9-对技术的精益求精以及对设计的不断完善将提升敏捷性

10-要做到简洁，尽可能减少不必要的工作，这是一门艺术

11-最佳的架构，需求和设计出自于自组织的团队

12-团队要定期反省如何能够做到更有效，并相应调整团队的行为。

三、Scrum的三大角色

产品负责人（Product Owner）

主要负责和客户沟通确定产品的功能和达到要求的标准，并指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果，一般是由产品经理担任。

流程管理员（Scrum Master）

问题清道夫！
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

开发团队（Scrum Team）

开发主力！
主要负责软件产品在Scrum规定流程下进行开发工作。
人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每个成员必须要有很强的自我管理能力，同时具有一定的表达能力；不论过程只问结果！
只要能达到目标，不论任何工作时间、方式。

四、Scrum的组成

Sprint：指的是一次迭代，而一次迭代的周期最好是1-4个星期，也就是我们要把产品需求分布到各个周期完成，这个过程我们称它为Sprint。

Story：用户故事，也可以看做是用户需求点。

Task：story的进一步细分。
为了能够及时，高效地完成每个 Story，Scrum 团队会把每个 Story 分解成若干个 Task。
每个Task 的时间最好不要超过8小时，保证在1个工作日内完成，如果 Task 的时间超过了8个小时，就说明Task的划分有问题，需要特别注意。

Backlog：Backlog是Scrum中的一个专用名词，意思是待办工作事项的集合。
在开发中需要明确2个Backlog。

Product Backlog ——产品待办事项列表，产品负责人量化用户需求，逐条列出实际需要开发的需求（Story）。

Sprint Backlog——任务列表，是一次迭代中需要完成的任务，主要是开发团队细化工作的列表。

燃尽图（Burn Down Chart）

是一个展示开发时间的图，但是展示的是每天累加所有任务的剩余时间。

燃尽图是用来跟踪sprint中未完成工作的情况。
每做完一个sprint的用户故事就烧掉，最后烧完sprint也就完成了。
用蓝色线表示计划走向，红色线则是实际走向，两条线共同组成了燃尽图。
如下图，每一个点代表一个用户故事，或者故事点，或者可度量的工作量。
所有点组成sprint。

在这里插入图片描述

五、4个会议

Sprint计划会

Sprint 计划会就是大家坐下来，PO 向大家介绍排好序的产品待办事项（Product Backlog），然后大家共同思考决定如何推进计划，梳理出 Sprint Backlog 来完成后续的工作。

每日站会

每位开发成员都要交代3点

昨天完成了什么

今天计划完成什么

是否有困难需要帮助

在这里插入图片描述

上图就是每日的站立会议了，参会人员可以随意姿势站立，任务看板要保证让每个人看到，当每个人发言完后，要走到任务版前更新自己的看板和燃尽图。

Sprint 评审会

当一个Sprint完成，这时就要进行最重要的演示会议，也称为评审会议，产品负责人和客户都要参加，每一个开发团队的成员都要演示自己完成的软件产品，然后被判定产品合格、成功、需要修改还是重新做。

Sprint 总结会

总结会议以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中。

以上的会议都不需要准备PPT或者大量的文档，但要注意会议的时长。

六、Scrum项目的开发步骤

1.产品负责人使用产品Tab收集产品需求（story）。

在这里插入图片描述

图：Product Backlog

2.开发团队根据Product Backlog列表，在Sprint计划会议中做工作量的预估和安排，确定需求提交研发，进入Story看板。

在这里插入图片描述

图：Story看板

3.确定Sprint周期（1-4周）和本次开发迭代冲刺的开发需求（Stories）。
进入Sprint的story出现在Task看板。
在Task看板，研发团队可以拆分Story到任务进行协作。

在这里插入图片描述

图：task看板

5.每日立会，团队更新Task看板，和Story看板，保持信息的同步。

功能强大的鱼骨精益看板能协助开发团队更好的实施SCRUM。

瀑布模型：

优点：

1. 为项目提供了按阶段划分的检查点。

2. 当前一阶段完成后，您只需要去关注后续阶段.

3. 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

缺点：

1. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。

2. 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。

3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

4. 瀑布模型的突出缺点是不适应用户需求的变化。

敏捷模型：

优点：

敏捷开发的高适应性，以人为本的特性。

更加的灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。

缺点：

由于其项目周期很长，所以很难保证开发的人员不更换，而没有文档就会造成在交接的过程中出现很大的困难。

根据目前流行的敏捷项目管理方法我们总结了敏捷测试流程规范：

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. 需求管理

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

问题：客户可能会在一个功能点上来回修改他们的需求，也许开始需要某个功能，结果做完以后又觉得不好，于是让去掉这个功能。
后来又由于一些原因，又需要加上。
在整个过程中可能来回修改了很多次。
那一定要记录下变更的内容和日期。
可能后期客户会觉得一个功能怎么会花那么多的时间，不是以前很早就做过了吗？这时这些记录才是解决客户疑虑的最好证明。
说白了，是有证据证明我们做了很多的变更。
大家可能觉得，怎么会有这个问题。
其实当一个项目长达半年以上，也许大家的记忆力都不可靠了。

建议：目前采用的是vss工具，对每天的Email中提到的需求变更做一次backup，文档以当天收到Email的日期命名

5. 项目开发末期开展“bug大扫除”

在项目开发的末期，可以开展“bug大扫除”活动。
划出一个专门的时间段，在这期间所有参与项目的人员，集中全部精力，搜寻项目的Bug。
注意以下要点：

（1）尽管这是一个测试活动，但参与者并不仅限于测试人员。
项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。
目的是要集思广益；

（2）要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug；

（3）为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。

（4）可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。