测试思想-测试流程敏捷测试与开发之我见-CSDN博客

敏捷测试与开发之我见

by:授客 QQ：1033553122

下文本着实用性原则，谈谈敏捷测试与开发相关的一些想法，如有不同意见或想法，欢迎提出~~

1、 团队优先

个人觉得，不管做啥，应该把“团队合作”放在第一位。如果团队本身没有凝聚力，没有向心力，那团队就是一盘散沙，有力无处使。“敏捷”也不例外，敏捷宣言中第一句就是“个体和交互胜过过程和工具”，充分强调了团队合作的重要性。

如果把“敏捷团队”比作一个木桶，那么团队中的每个角色就是组成木桶的木板，团队的效率就是桶里的水。根据木桶原理，团队中只要有任何一个角色不够效率，不够敏捷，那么整体的效率也就受到影响。

所以，我的观点是，“敏捷”的前提是“团队优先”，重视团队，重视团队中的每个角色，无差别的对待每个合作成员，让每个角色、成员有动力，有激情的弥补自己的短板，让自己更敏捷，从而促进整个团队的敏捷。

所以，应该跳出旧的思维，看看到底是自身不敏捷，还是其他成员、团队、组织的不敏捷影响了整体的“敏捷”。

问题：

产品经理、策划人员、设计人员(UE、UI)，开发人员，测试人员、运营人员……都做到敏捷了么？

2、 需求为主

所有的一切源于需求。由需求而生，随需求而灭。

所以，我的观点是，“敏捷”从“需求”开始。

自然而然，从产品经理、策划人员的“短板”抓起。从需求说起，书上说，他们需要做的第一件事情就是整理需求 --- 编写用户故事

3、 编写故事

书上说用户故事代表对用户、客户有价值的功能，即用户(客户)需求，不含过多的需求细节。

不过个人觉得产品经理、策划等“产品人士”，其专业性一般强于非专业人事，通常有他们自己的想法，所以可以预先以非故事的方式，比如注释、要点的方式进行简单记录。

关于用户故事的编写要求，可网上搜索相关资料，这里暂时不提供。当然，也不必要完全参照网上说的一定要是某种格式，关键是怎么方便，有效。怎么样写一份好的需求，是合格的产品人士必备的技能

4、 讨论细节

书上说，需求的细节要在“对话”中获得，并在确认部分得以记录。

这里，团队成员在聚在一起，头脑风暴，针对3中的每个用户故事，逐个展开关于需求细节，并记录讨论结果

特别说明：

很多事情，唯有参与，才有认同.....。

5、 版本规划

确定当前迭代的版本包含的需求及优先级安排

6、 任务量评估

开发人员评估大致大致的工作量。

7、 原型设计

将讨论结果以以实际的原型、界面展现出来，是构建一个真正产品很好的方法，同时把重心从“需求文档评审”转移到“原型(Demo)评审” ，以原型评审为中心，辅以必要的文档说明，作为原型的补充，也是去掉无用的功能定义文档、需求文档可行方法。

原型设计好了，共享给相关人员查阅，以便及时获得反馈，及时更正，如果时间来得及，最好是评审下原型

8、 项目开发与用例设计

开发人员根据原型进行项目、产品开发，测试人员根据用户故事、原型(假定原型已经被认可的情况下)来测试设计用例。

说明：

这里为了方便，建议用类似xmind工具或excel等来写编写需要评审的测试用例，方便评审，同时，建议编写一份按功能模块汇总的用例。

这里有些人可能会觉得写两份用例，麻烦，耗费时间，但我认为实际花不了多少时间，因为执行中可在“复制黏贴”的基础上完成，而且用例某种程度上也代表了产品整体，有一份按模块展开的用例，让你很容易看到“大局”，不仅在测试时起到很好的提醒作用，而且还方便优化用例。再进一步，要是把汇总的用例，写在管理系统，比如禅道上，是不是容易分配任务、跟踪任务、统计任务执行等情况呢？

备注：用例是需要维护的，需要不断优化的，试问，做测试的亲们，你们能一次性就写出很完美的用例么，特别是在很时间短，项目赶的情况？不能吧，，，所以如果每次都在前一次基础上修改，迭代，效果是否会好点呢？

例子

汇总的用例：

提交评审用例：

说明：从图上也可看到，这种情况下的用例，会是比较零散的，针对故事点，具体执行时，很多时候需要重复编写用例，即重复的时间投入。。。。

备注：

很早前我写过一篇关于精简测试用例的文章，后面看了下，发现好像执行性不高，删了，没分享出来。最近今天思考了下，发现用例还是可以精简的，精简用例的出发点是“用例主要是起提醒作用”，这个观点也是隔壁公司某项目负责人交流时，她提到的。当时没怎么在意，现在想来，发现还是挺有价值的一句话。结合上面的格式说明，用例名称，模块、故事名，验证点，一般是不能少的，那可不写的是啥？答案是：步骤、预期结果。当且仅当你一看用例名称，即测试验证点，就能想到步骤和结果时(比如翻页，密码大小写验证等)，那么可省略，因为这时候，用例名已经起到了足够的“提醒”，……

9、 开发自测

开发发布前，根据测试提供的用例进行简单自测，当然，开发自测环节的可能性是基于规范成熟度、工作任务量等因素的，一开始就让他们自测，估计会要了他们的命。

备注：开发如果有看下测试给的用例，哪怕是瞄下，说不定就看到没注意的细节了，，进而可将bug于测试前修复，要是再细看下就更好了……知道大致做到什么程度，才不会让测试抓住辫子，才算完成了开发工作，，，这里体现的就是敏捷的思想。

10、内网测试

QA进行内网测试，这些测试可能包括单元测试，接口测试等等，至于能做到哪种程度，就看各方面的配合了

11、外网发布与走查

12、下一轮迭代

重复流程3~11

难点说明：

结合实际，流程3~6 要怎么做？

方案要求：

1）可执行性高