讨论：如何从测试的角度对软件质量做一个measure

waitress_0000

对于软件质量，最重要的就是好不好。
但是到底怎么样，我们可以说这个软件质量是好的呢？
在现在这个行业环境中，我们越来越需要一个量化的指标来确定这个概念，特别是对于测试来讲，如果我们想让测试在公司或者行业发展中占据更加重要的地位的话。
我相信对于很多公司中，测试地位很低的一个重要原因也是没有一个量化的概念来让老板觉得，测试在产品质量上作出了什么贡献。
而在某些公司，测试部门意识到了这点，正在做这方面的工作，比如对于一个项目，创建测试用例的多少，某个测试用例的重复使用次数（牵涉到某个具体测试工程师的performance），发现bug的多少，漏了多少bug，报错bug数量。
但是这种量化指标明显有不足的地方，比如可能导致测试人员过多的去创建测试用例，把长的改短，一个改几个；或者用例中故意增加一些基础验证，看上去无可厚非但是实际对于测试方法来讲很冗余的东西；再或者相同原因的bug，因为不同表现而去多报，或者怕报错bug而故意少报（特别是某些概率性的bug）。
其实这些问题对于开发人员也是存在的，DE可以去规避出现bug，而将代码层次结构做的越来越复杂越来越难以维护，如果DE有这种量化考评指标的话。
因此，我发现工作几年下来，对于测试来讲，很难但是又很有必要去做的事情就是，确定合理的，或者相对合理正确的measurement，来从测试的角度，去说，这个软件的质量到底是好还是不好。
我感觉似乎也只有用例数量，bug数量，执行用例的数量这些方面去做一个评判。但是这种数字明显不是一个很好的量化标准，所以可能需要引入其他的东西，比如一个用例覆盖的需求多少，相同长度用例能验证的功能点的多少。但是这样又牵涉到更多不那么量化的指标，并增加评判的复杂度。
不知道大家对于这点有什么样的想法和考虑呢

waitress_0000

恩，我说的不清楚
其实想度量的就是软件质量，而这个度量我想很有可能会被引入到测试考核当中
这在某种程度上会不会是相似的
因为你想，如果有一个量化的度量指标可以评判软件质量，那么它肯定会被老板拿来做测试人员的考核指标，对不对？

waitress_0000

恩，说的一点没错
我绝对同意这一点
但是站在老板的角度上，如何去鞭策员工，往预订的目标上前进，自然而然会把度量目标好坏的指标用于对员工的评定上，以此来激励员工。
因此，这似乎是不可避免的，毕竟公司是老板最终说了算