最近公司又新上马一个项目，为了项目能够尽快抢占市场，产品、设计、开发、测试等小伙伴们在夜以继日地赶进度。除了加班赶进度，摆在大熊面前的一个巨大挑战是：项目组提出每两周迭代并上线一个版本。
相信这种情况在各大小公司非常常见，也如大熊一样苦恼着这些问题：
1.在版本迭代频繁的情况下，产品的质量如何保证？
2.测试人员的测试时间应该留有多少？两周，一周又或者是2天？
3.如果测试时间被压缩得很短情况下，质量和进度如何同时保证呢？
为此，大熊把当前项目的流程(区分传统测试流程，简称非敏测试流程)在纸上画了出来，同时在纸上画了另外一个心中理想的流程(简称敏捷测试流程)：
非敏测试流程
1.流程介绍：我们简单回归下大熊所带项目的测试流程过程，这一测试流程普遍存在于各个公司和各种项目。
需求&设计阶段：与敏捷思想一致，将需求拆分成一个一个的story，安排在一个迭代内(如两周)可完成的需求。不求多、不求最全，通过一个版本接版本不断完善功能。
编码阶段：开发人员根据需求进行相应的开发工作，待所有功能开发完毕后，提交给测试组进行测试。
测试设计阶段：测试人员在需求、设计和开发编码阶段的同时，进行测试用例的准备。
测试执行&Bug修复：待开发提测后，测试人员进行测试用例的执行和Bug提交；而开发人员同时进行Bug的修复。
上线：当所有不阻塞上线的问题处理完毕后，版本上线发布。
2.流程问题：
存在开发提测质量不足的风险，阻塞后续的测试执行。
大量的Bug在提测之后才暴露出来，而这些问题的发现和修复成本都比较高。
测试执行阶段基本依赖于手工测试，版本迭代的测试成本比较大。
即便是在测试执行阶段引入appium或selenium等自动化测试，问题暴露得依然很晚。(此外自动化脚本的稳定性也是一个更大的成本投入)
敏捷测试流程
1.流程介绍：参考业界优秀公司和团队的一些做法，大熊拟定了一个改进流程。
需求&设计阶段：不做赘述，仍然做好story的拆分和安排。
编码阶段：
引入代码Review机制，加强代码Review的评审和发现。(见附录3)
引入单元测试机制。在编码的同时，开发人员将自己实现的类进行单元测试。
加入测试驱动框架搭建，方便开发人员和测试人员进行集成测试的执行。
测试开发人员编写集成测试用例并执行。
持续集成：
代码每日提交时都经过Review系统进行代码审核。
代码每日进行自动化的单元测试执行和集成测试执行。
当发现构建失败、或者测试用例不通过时，当下立刻解决其中的问题。
测试执行&Bug修复：待开发编码均完成，单元测试和集成测试用例均通过之后(有些公司还会追求代码行覆盖率达到设定好的百分比)，进入测试执行(系统测试)阶段
上线：当所有不阻塞上线的问题处理完毕后，版本上线发布。
Note：为了提升覆盖度和效率，还可以在回归测试阶段引入主路径的CheckList自动化和monkey稳定性自动化测试等工作，在上线前增加众测等。
2.流程分析：对比非敏测试流程的问题，问题会得到进一步改善。
因为单元测试和集成测试的引入，提测质量相比之前会变得更好。
大量的Bug会在代码Review和持续集成过程中暴露出来，而问题越早发现，修复的成本也越低。
测试手段会拓展为自动化+手工测试，后续版本迭代复用性高。
3.流程问题：这一测试流程也存在很多问题和隐患
代码Review机制能否贯彻执行的问题。
开发人员单元测试的意愿度和成本问题。(见附录4)
测试开发人员的框架设计和编码能力要求。
项目初期需要进行测试框架搭建、持续系统搭建、自动构建和自动执行等大量的基础工作建设。
路虽遥远，君心不摇。大熊和他们的小伙伴们正在不断实践和改进中….
附录1：代码Review系统
附录2：持续集成&单元测试
附录3：引自《代码大全》中什么时候进行质量保证工作章节
附录4：引自《代码大全》中开发者测试章节
“质量保证的一部分就是制订出一套与产品需求、架构及设计相关联的测试策略。许多项目开发商把测试作为质量评估和质量改善的首要方法，这样的想法将使得测试不堪重负。” --引自《代码大全》
