测试效果评估

我理解，最简单的测试效果评估方式就是看软件发布后bug数目和严重性了。但是这是事后诸葛亮了。软件发布之前怎么看呢？我所知的有3种办法。
1. 代码覆盖率
这个是最基本的方式了。一般来说，测试集覆盖的代码量越高越好，80%覆盖率就可以算达标了，覆盖100%代码基本是没戏的。大多数编程语言都有对应的代码覆盖率收集工具，比如gcov for c/c++, emma for java.
除了评估当前的代码覆盖率情况，一般的工具也支持未覆盖代码的显示，这样就能比较方便地设计新的测试样例来提高测试质量。
除了代码覆盖率，其实也可以根据需要设计别的覆盖率准则，然后去统计覆盖率的。
2. Mutation Testing
不知道怎么翻译了。所谓mutation testing就是往程序里插入bug，然后跑测试集，看找到多少插入的bug和实际存在的bug，再来预测剩下的bug数。比如插入100个bug，测试集找到了40个插入的bug以及80个实际存在的bug，那么在假设插入的bug和实际bug的分布一样的情况下，总的实际存在的bug数就是80* (100/40)=200，也就是说还有180个bug没被找到。
这种方法的问题是，一来插入的bug和实际bug的分布是不一样的，一般插入的bug都比较简单，而且可能互相等价，二来各个bug单独评估 (就是看测试集能不能发现它)的话要反复编译程序和执行测试，开销很大，而如果多个bug同时插入代码中的话bug之间会互相干扰，很难评估。
3. 软件可靠性建模
这个和其他的可靠性建模是一样的，就是根据不同时间里bug总数的分布来预测未来一段时间里的bug数，只是针对软件的特点做些不同的假设，来得到不同的数学公式而已。比如，如果一个软件在前t个时间段的bug总数分别为100, 130, 150, 160, 165, ..., 那么就可以算出一个bug总数和时间t之间的关系，然后预测t到未来某个时间t'之间的bug总数。具体公式也有不少，可以参考http://www.cse.cuhk.edu.hk/~lyu/book/reliability/pdf/Chap_3.pdf，看看里面的NHPP模型就行了。除了预测bug总数，也可以预测某一段时间内没有bug(应该是失效)出现的概率，这就是所谓99.999%的可靠性这种结果了。
可靠性建模问题也不少，模型本身都有不那么合理的假设，而且已有的bug数目和测试的场景，采用的测试技术和测试强度(这个或许可以折算到测试时间里)有关，所以预测结果和实际数据还是可能有大的出入的。不过我觉得它还是比mutation testing考谱些，和代码覆盖率相比呢，它是直接评估软件质量的，而代码覆盖率其实只能间接评估软件质量(我理解代码覆盖率反映的是测试代码的质量，甚至严格点说，测试代码的质量也说不上)。
 
当然，如果不是全新应用或者全新的开发方式的话，或许经验的判断还是最有效的。不管怎么样，以上几种方式所得结果还是可以做参考吧。