1.测试用例的密度--用例密度直接影响bug的数量和严重级别
2.测试用例覆盖率--因为覆盖率很小发现的bug很少时能说明质量很好吗？ 3.bug数量--用户使用过程中出现很多bug，用户一定是不会再认可这个软件了 4.bug的严重级别--严重的bug会使用户无法使用软件更别说能接受这个产品了
1、软件需求规格说明书的功能点尽可能的量化； 2、测试用例设计要通过评审，要求需求覆盖率达100％；
3、查看缺陷分别按时间的趋势图、按模块的饼状分布图，按时间的趋势图是否是下降的趋势，按模块的分
布图可以发现缺陷集中的相关模块；
4、完成系统的性能、安全、易用性等其他隐式需求的测试；
5、测试用例的执行覆盖率要达到100％； 6、程序代码语句覆盖率不低于80％；
7、缺陷修复率情况：
1) 致命、严重的缺陷修复率要达到100％以上； 2) 一般不太严重的缺陷修复率要达到80％以上； 3) 易用性不影响系统应用的缺陷修复率达到60％以上； 8、系统通过需求人员的确认测试，系统满足需求规格说明书的说明。
如何量化评估被测试软件的质量？
评估被测软件质量可分为从内部、外部看两方面，内部评价软件质量时多用功能、可靠性、可用性、可维护性、可移植性、性能等多个衡量指标，但不同的软件衡量质量的指标权重是不一样。WEB应该更看重功
能、安全、性能，应用程序偏重于功能、可用性、可维护性等方面。
功能性看程序对用户需求的覆盖率，但超出用户需求的部分不一定是好的，从BUG定义的角度来看，也是
一种缺陷。
可靠性看程序能无故障运行时间、容错、可恢复、安全性等，与需求初始定义去比较。
可用性看程序的设计是否符合用户场景中的使用习惯，是否方便用户的操作，是否是用户操作的最快捷步
骤。
可维护性是指工程实施时是否方便，维护基础数据方便，能快速解决用户维护方面的问题。 可移植性是指能否支持多个平台的使用，各平台、版本之间是否有快速切换的解决方案。 性能是否满足客户需求，能否满足不断增长的数据量和用户量，而程序的性能不下降。
从外部看，一般从用户验收测试、使用过程中的BUG反馈来评价质量。
用户验收是从用户的角度去看程序是否实现既定的需求，是否满足他们工作场景中的使用习惯，操作是否
方便等多方面，可以设计问卷，调查结果的分值可以体现用户对软件质量的评价。
使用过程中的BUG反馈，是指用户购买软件后，在使用的过程中发现的BUG量，可以与公司内部发现的BUG进行对比，这个比值可以来衡量软件的质量，同时也可以衡量软件测试的质量。具体的衡量值可以根据不
同的软件项目、产品经验来设定。
如何量化评估被测试软件的质量？
首先是需求需要量化：
a、有功能的规格列表以及每个功能的重要级别,市场定位等。
b、给出性能指标。
根据以上信息,定义产品的完成标准及质量,首先在客户层定义好质量标准.
下面就是根据测试情况定义,更多的是测试人员自己的理解与定义：
1、产品所运用技术的可扩展性、可移植性、安全性，当然这个跟产品的定位有关。 2、重要功能是否全部实现，就算存在问题，是否有规避措施。次要功能在要求上可以低些。
3、性能是否达到预期结果，就算没达到，是否能满足当前的市场。
当然上面的结果取决于你测试列表的覆盖度及深度。
软件质量量化指标
