下面也以单元测试为例，看看怎么建立一个可量化、可衡量的单元测试阶段的交付标准。

　　首先，需要确定开发人员是否进行了单元测试。可以让开发人员提交一份单元测试总结报告，上面需要大致的描述一下进行了那些单元测试。单元测试总结报告是否提交是一个可以量化的条件。

　　其次，需要评估一下单元测试的质量，主要可以通过如下方法：

　　是否有足够的单元测试用例？可以对照详细设计规定单元测试用例的数量，这是个量化的方法。

　　单元测试用例的通过率必须达到90%以上。

　　测试人员还可以抽样执行开发人员编写的单元测试用例，抽样执行的单元测试用例的一次通过率必须在90％以上。这也是一个量化的方法，同时检查了测试用例书写的质量和单元测试执行的质量。
　　
　　以上是一些常用的方式，而且这只是非常少的一部分，当给出确实可行的方法和可以量化的指标后，我们发现，评估一个产品是否达到了预计的质量要求就会变得相对容易很多，而且也避免了人为主观判断的尴尬。

　　最终的交付验收有无和客户确认通过的验收标准和范围？上线、割接和维护期有无明确的成功、失败判定标准？

    对于项目类的软件开发，上面的监控非常重要。为客户做项目的时候，一定要在前期和客户确认怎么进行验收，验收通过的标准是什么，最好能形成书面的文档，这样才能在最后交货的时候避免不必要的麻烦。而且，验收标准和范围应该是测试的一个最小测试集，要最大程度的确保正确性。

　　如果是比较大的软件开发项目，还会牵扯到：上线、割接、维护，一般会写在前期 的合同中，客户会按照上述阶段点阶段性付费，所以如果上述阶段点没有明确的成功、失败判定标准的话，对于公司尾款的收取是个挑战。

　　通过以上的详细询问，我相信，测试工作范围界定的是否有问题，测试工作是否规划的全面、细致，监控者应该比较清楚了，下面的任务就是将你的疑问记录下来，留待后面做证实。

　　2.测试实施期

　　在这个阶段，测试工作进行了一段时间，测试人员的工作应该已经步入正轨，按部就班的完成一些任务。这个阶段的特点是：开发人员和测试人员都按照日常的规范开始有条不紊的工作，有可能对一些问题已经习以为常，或者已经被同化。作为测试工作的监控者，应该在看似合理的工作中找出影响质量的问题，规避风险。