摘要
正文
在实际的项目测试中，我们不得不承认有些环节还是要依靠人的经验来判断，这也是为什么企业中的中高级岗位更青睐于有经验的工程师（当然，除了经验还有能力）。
例如，根据软件或模块的成熟度来判断是否能进入到下一个spring，这里的成熟度大多数是根据软件的测试结果汇总来判断的，往往这个工作会找一些有经验的工程师来完成，这里主要利用了他们在既往项目中的经验。
在信息化如此高的今天，这些工作能不能通过量化的方式来呈现呢？本文试图通过简单的数学概率建模方式来为读者揭开所谓经验里面的秘密。
引用软件工程中里面的两个规律："80%的问题总是出现在20%的没有测试到的模块中的"和"测试是不可能穷尽的"。后一个规律在强调敏捷和快速的今天更为突出。其实，这个问题和数学中遇到的一个概率问题是很类似的，即在一个箱子中不知道红球和黑球的数量，通过每次拿出的球的颜色来判断箱子中红球和黑球的比率。
日常中，我们较为擅长的问题是在知道全部的问题后来判断软件风险的大小，而不擅长的就是在没有做充分测试的情况下，要评估软件的成熟度或者是软件的风险。前者，称之为正向概率问题，后者称之为逆向概率问题。通过上述软件工程中的两个规律我们知道，显然正向概率是不可能的了。现在我们就用在机器学习中广泛使用的贝叶斯原则来解决这个问题。
这里简单介绍一下贝叶斯原则：
猜测，当然就是不确定的（很可能有好多种乃至无数种猜测都能满足目前的观测），但也绝对不是两眼一抹黑瞎蒙--具体地说，我们需要做两件事情：1. 算出各种不同猜测的可能性大小。2. 算出最靠谱的猜测是什么。第一个就是计算特定猜测的后验概率，对于连续的猜测空间则是计算猜测的概率密度函数。第二个则是所谓的模型比较，模型比较如果不考虑先验概率的话就是最大似然方法。
以下是贝叶斯公式：
P(A│B)=(P(B│A)*P(A))/(P(B))
具体的含义P(A)是A的先验概率或边缘概率。之所以称为"先验"是因为它不考虑任何B方面的因素。
P(A|B)是已知B发生后A的条件概率，也由于得自B的取值而被称作A的后验概率。
P(B|A)是已知A发生后B的条件概率，也由于得自A的取值而被称作B的后验概率。
P(B)是B的先验概率或边缘概率。
下面我们就看看它怎样来解决我们实际的问题。
实际工作中对我们来说一个棘手的问题是，如果一个软件或模块在完成了各种各样的测试没有测试出问题，那么能说这个模块就成熟吗？风险有多大？
根据这个问题，我们假设以下变量
A：代码中有bug的事件
X：代码pass所有测试的事件
P(A): 代码中任何bug的概率，这里的意思是开发人员出错的概率
P(X)：代码中pass所有测试环节的概率，这里的意思是测试人员pass所有测试概率
那么在代码在pass所有测试的前提下，还有bug的概率就是P(A|X)
跟据贝叶斯原则：
P(A│X)=(P(X│A)*P(A))/(P(X))
P(X)这里在实际中存在两种情况，即pass所有测试仍然存在bug的概率和pass所有测试且没有bug的概率，分别用P(X and A)和P(X and ~A)这两个联合概率来表示。
所以有，P(X)= P(X and A)+ P(X and ~A)
将这两个联合概率展开，分别为：P(X and A)=P(X|A)*P(A)和P(X and ~A)=P(x|~A)*P(~A)
所以
P(X)=P (X│A)*P(A)+P(X│~A)*P(~A)
P(A│X)=(P(X│A)*P(A))/(P (X│A)*P(A)+P(X│~A)*P(~A))
版权声明：本文出自51Testing软件测试网电子杂志——《51测试天地》第三十五期文章投稿。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
