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