如果只有时间点的划分，那我已经可以断定，这个项目势必会延期，原因是在整个生产活动过程中没有明确的阶段点交付的检验标准，问题肯定会沿着整个开发过程逐步的传递下去，终归会在某一点爆发，最不幸的爆发点是在客户处。
如果想尽量的避免上述的风险，就需要在开发过程中明确各个阶段点之间的交付、确认条件。而且这些条件必须可量化、可衡量，决不能是含糊的，不易操作的，否则在实际操作过程中还是会将大量的问题推入下一个阶段。
下面也以单元测试为例，看看怎么建立一个可量化、可衡量的单元测试阶段的交付标准。
首先，需要确定开发人员是否进行了单元测试。可以让开发人员提交一份单元测试总结报告，上面需要大致的描述一下进行了那些单元测试。单元测试总结报告是否提交是一个可以量化的条件。
其次，需要评估一下单元测试的质量，主要可以通过如下方法：
是否有足够的单元测试用例?可以对照详细设计规定单元测试用例的数量，这是个量化的方法。
单元测试用例的通过率必须达到90%以上。
测试人员还可以抽样执行开发人员编写的单元测试用例，抽样执行的单元测试用例的一次通过率必须在90%以上。这也是一个量化的方法，同时检查了测试用例书写的质量和单元测试执行的质量。
以上是一些常用的方式，而且这只是非常少的一部分，当给出确实可行的方法和可以量化的指标后，我们发现，评估一个产品是否达到了预计的质量要求就会变得相对容易很多，而且也避免了人为主观判断的尴尬。
最终的交付验收有无和客户确认通过的验收标准和范围?上线、割接和维护期有无明确的成功、失败判定标准?
对于项目类的软件开发，上面的监控非常重要。为客户做项目的时候，一定要在前期和客户确认怎么进行验收，验收通过的标准是什么，最好能形成书面的文档，这样才能在最后交货的时候避免不必要的麻烦。而且，验收标准和范围应该是测试的一个最小测试集，要最大程度的确保正确性。
如果是比较大的软件开发项目，还会牵扯到：上线、割接、维护，一般会写在前期 的合同中，客户会按照上述阶段点阶段性付费，所以如果上述阶段点没有明确的成功、失败判定标准的话，对于公司尾款的收取是个挑战。
通过以上的详细询问，我相信，测试工作范围界定的是否有问题，测试工作是否规划的全面、细致，监控者应该比较清楚了，下面的任务就是将你的疑问记录下来，留待后面做证实。
2.测试实施期
在这个阶段，测试工作进行了一段时间，测试人员的工作应该已经步入正轨，按部就班的完成一些任务。这个阶段的特点是：开发人员和测试人员都按照日常的规范开始有条不紊的工作，有可能对一些问题已经习以为常，或者已经被同化。作为测试工作的监控者，应该在看似合理的工作中找出影响质量的问题，规避风险。
在这个阶段，应该关注以下问题:
缺陷管理流程是否规范?每个缺陷的提交和关闭是否都有复查?
文章来源于领测软件测试网 https://www.ltesting.net/
