近期，为了对外缩短发布周期，对内建立更加快速的反馈机制，我们团队全面尝试了从“先开发后测试”到“边开发边测试”的转变。在此过程中，我感到测试用例设计和评审、测试执行两个活动需要做出一定的调整。
1、测试用例设计和评审：从时间驱动转变为用户故事驱动
当开发和测试顺序执行时，我们的功能测试计划会指定测试用例设计和评审时间。当开发和测试并行时，我们不再以时间的维度来计划测试用例的设计和评审，而是以用户故事的维度。我称这一转变为“从时间驱动的测试用例设计和评审转为用户故事驱动”。“用户故事驱动的测试用例设计和评审”有两个要点：（1）以用户故事的优先级来确定测试用例设计的优先级；（2）配合开发节奏，以一个或多个用户故事为批次，多次分批进行测试用例评审。为了让团队对测试用例设计的进度有一个直观的了解，我们为每个用户故事创建了一个设计测试用例的任务。
2、测试执行
（1）从广度优先转变为深度优先
以前的测试我们会安排多个轮次，每个轮次的测试重点和方法都有所变化。而现在再也没有测试轮次的概念了，因为除了回归测试期间，基本都是每日构建，有什么测什么。那么这样的变化要求测试人员怎样调整测试执行呢？我认为是要把“回锅肉”模式变为“煮饭”模式。“回锅肉”模式是先把五花肉煮个八成熟（类似我们先把某个用户故事测试完成），然后再和大蒜等配料一起回到锅里炒，并最终装盘（类似我们通过回归测试最后确保所有功能在一起工作正常，然后发布）。“煮饭”模式是“一灶火把饭煮熟”，因为夹生饭再煮又浪费时间又不好吃。这类似我们的测试要围绕该用户故事尽量一次测试充分，而不要象以前因为知道后续还有多轮测试而有意识地推迟某些当前就可以做的测试。从某种程度上说，是要把广度优先测试转移到深度优先测试。
当然，深度优先的一个缺陷在于可能会忽视用户故事间的关系。因为用户故事的INVEST（Independent，Negotiable，Verifiable，Estimable，Small，Testable）特性，故事间是比较独立的。但是由用户故事构成的系统却不能忽视故事间的内在关联。所以，我建议在测试单个用户故事之后，在回归测试之前，尽量穿插一定的用户场景测试（scenario testing），把在某些用户场景上自然集成起来的多个故事一起测试，从而尽早暴露故事间的一些缺陷，弥补深度优先测试的不足。当然，最后的回归测试也是对深度优先测试的一个补充。
（2）测试执行需要借力于持续集成
持续集成不是传统测试范畴的内容，但为了及时保卫胜利果实，对已经进行过测试之处的正确性和稳定性提供必要的及时的检查和信心保障，持续集成不可或缺。边开发边测试的过程中，我们通过集成了自动化测试的每日构建，及时发现了由于版本不断被修改而造成的意料之外的问题。开发人员也因为能将引起这些问题的原因及时锁定在近期刚刚修改过的内容上而加快了修复一些棘手问题的速度。当开发和测试人员马不停蹄地向前冲的时候，持续集成为我们巩固了后方。
除了上述两个较大的方面，我也隐约感到其它一些方面，如测试进度报告、测试人员心态的困扰等，也有一些变化，还有更多细节需要调整。所以，我们仍然需要拥抱变化，应需而变，持续调整和改进我们的测试实践。
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/