测试周期之第一阶段

第一阶段：准备阶段，在这个阶段中，大致会做以下事情：

参与需求评审、熟悉业务需求、编写测试计划、测试用例以及测试脚本、最后就是准备测试数据。

其中，这里面除了测试数据和脚本之外基本不需要评审外，其它工作都需要进行评审。 以下重点说明这三会的评审及实用情况：

   对于新人、新项目来说，好的建议是多评审需求，在参加产品需求评审完之后，我们并不急于写用例，而是会在内部继续熟悉需求并评审。具体的策略就是约定一个时间点，参与该项目的测试人员要轮流进行需求宣讲，尽量要达到让每个同事不仅能讲出来，而且能回答了每个同事提出的问题 。如果期间有新的需求问题大家都解答不了，统一记下来再和产品确认。这样整个一轮下来，大家基本都会对需求有一个清晰的认识。 这里要强调一点就是，要尽量让每个同事都要熟悉所有的需求，主要原因是对于这样的新项目来说，可变因素太多。每个人若都对需求熟悉，后来人员安排比较方便 。 另外就是计划和用例别写的太详细，还是那个原因，新项目可变因素太多，写详细了往往不能很好的执行。

    对于项目已经稳定但时间紧且测试功能多的情况，此类项目就要重点做计划，因为时间紧，你要明确那些要重点测、那些少测、那些可以不测、那些要优先测，而且要明确测试什么、比如本次有新增后台接口，那么就要测试版本兼容，如果有UI调整，那么就要测试机型适配的情况。其次，就是要明确人员分配，通过对计划进行评审，要明确各测试人员的具体任务以及里程碑；最后，就是就是落实计划，在测试过程中，要进行实施监控，如有偏差，进行及时调整 。

    对于项目时间不是很紧但是含有重点功能的情况，则重在做用例。相关人员除了要完成用例编写及自评外，我们还要进行组内评审，有的时候还要进行组外评审 。当然，在评审过程中也从几个维度进行考虑，新增功能的覆盖率、如新增功能是否影响已有的某个功能、新增功能是否导致部分用户数据不兼容等 。 通过评审把这些情况都考虑到，然后在测试过程中进行测试验证，最后再补充一些个人的探索式测试和交叉测试 。从而保证主要功能线上不出现大问题。

    以上就是准备阶段我们要进行的三会评审，这里要说明的是，并不是每个项目都要进行这些评审，我们完全根据实际的项目情况而定，有的时候甚至连一会都没有，有的时候是这几个会的组合。 我们只是通过一种机制，让大家都能识别出来，在什么情况该进行需求内部评审会、什么情况下应该进行测试计划评审会。