文档介绍：软件测试质量评估方法讨论稿
当前我们的软件测试质量评估主要考虑测试设计、测试执行两个方面，在测试过程中加入检查点进行监督，避免项目后期对项目的进展产生影响。
一、测试设计
测试设计主要指测试用例，其衡量方法采用事后追溯法，通过所有的测这几项。
--客户反馈缺陷，即漏测。其实这是一个很直观的质量保证结果，本人非常崇尚用这个指标衡量测试人员的结果绩效。虽然漏测的原因不单单在于测试的疏忽，但终究能在很大程度上体现测试的质量。且通过对这个指标的线性观察，发现一些潜在的可能在未来会反馈回来的问题，我们还能亡羊补牢，出补丁提前堵漏。
--模块缺陷密度。往往找到缺陷最多的地方也是潜在缺陷最多的地方。这个规律几乎是千真万确。就跟越是担心会出问题的时候一般都是会出问题的，类似。这个在测试过程中或者发布之后拿来分析都很有意义。
--遗留缺陷。仅仅看一个绝对的数字并无太大意义，它的意义在于与之前拟定的交付标准做比对，假若在标准之内就放行，不在标准之内那就卡住。另外，被允许的遗留缺陷一般也是下一阶段启动任务之时开发任务的首要任务之一。
5---趋势分析。这是一个质量活动如期完成的强力证明工具，当然要真正看到收敛才对。
15--测试用例有效率。这个指标更大意义的是规范测试活动，其次才是提高测试用例的质量。想要统计出有效率，有个前提就是测试集驱动测试，即你开展每一轮测试之前，根据测试需求建立好测试集，并且集里面的测试用例也都已经确定好，之后照着逐一测试。很多测试人员说测试用例只不过是我用来熟悉需求的产物，等我拿到被测对象，我根本就不看测试用例就刷刷的往下测。殊不知，人的记忆往往是有漏洞的当你脱离测试用例来测试，你就是在走向随机测试，大家想想随机的活动有没有可把握性？
简单评论之后，我再加一个度量项，尤其是在这提倡测试先行的年代。--需求review阶段发现的需求issue数/整个测试过程中发现的需求Issue的总数，这个指标体现测试人员在需求熟悉阶段对需求透析程度，透析度越深往往对促进需求精致化的贡献度越大，对测试用例的有效性的贡献也越大。我们毕竟不希望到了测试执行阶段才来不停的质疑需求这里有问题那里有问题。
评估软件质量的标准不是绝对的，是相对的。一个软件的质量特性包括：功能，性能，安全性，易用性，可靠性，可维护性，可移植性等，还有一些行业特性。而让这些特性达到什么样的指标，则是根据用户的需求来规定的。软件测试就是要验证软件的这些特性与需求的符合程度，符合程度越高表明质量就越好。
所以个人认为量化的依据应该包括：
1•测试用例的密度-用例密度直接影响bug的数量和严重级别
2•测试用例覆盖率-因为覆盖率很小发现的bug很少时能说明质量很好吗？
bug数量-用户使用过程中出现很多bug,用户一定是不会再认可这个软件了
bug的严重级别-严重的bug会使用户无法使用软件更别说能接受这个产品了软件质量的量化评估就是所有数据的整合,经过对数据的加工得到的数据便是软件的质量级数。
具体数据包含以下几个：，，（功能，性能，压力等等），
质量，，6•客户试用满意度，7•员工工作效率，等几个方面的数据。各项数据按其在
项目中的重要级别对数据进行+-*/运算，最后得到的数据便是软件