虽然大多数时候我们是在测试同一个软件产品，但是在测试的方向上，还是分类进行分析：

1)针对第一类，持续压力可靠性问题，顾名思义，我们要进行持续压力的长期测试，等测试执行的次数/时间到一定的程度时，必然会触发该问题。这里说的必然，可能需要两个条件。

1，我们设计的测试用例以及其中的步骤，能够覆盖到这个可靠性问题的函数/流程或者分支(函数这个概念对于测试太小了)

2，在满足第一个条件的基础上，测试用例执行的次数要大于等于触发该问题所必需的次数

有了上述两个条件，我们必然可以触发某个持续压力类型的软件可靠性问题

接下来就要分析，如何达成上述两个条件。前面已经说过，我们事先无法知道软件中的问题在哪里，更别说要相对准确的评估触发问题需要的用例执行次数了。

是的，这样看来似乎无法解决这两个条件了。但是在实际的软件产品测试中，还是有很多可以做的，至少我们可以确定问题的方向。

针对第一点 ，测试用例以及步骤，需要覆盖到这个可靠性问题的流程或者分支;我们知道，在一个软件功能运行中，一个bug可能隐藏在一个函数中，可能隐藏在一个分支中，也可能隐藏在一个由多个函数组成的流程中。我们可以称某个函数，某个分支，某个流程为这个bug的最小触发单元，只要我们的测试用例场景以及步骤，可以涵盖住这个最小单元， 那么第一个条件极有可能会满足;

同时，必须要强调一点，如果这个测试用例以及测试步骤往另外一个极端走：覆盖的流程不断的放大，极有可能，它是无法满足第一个条件的，除非我们对这个软件系统非常的清楚，知道它必然会走到这个最小单元中，当然，这需要一定的软件开发能力了。

说到这里，大家可能会觉得似乎这样的测试有一定的探索性测试的意思。有这样的想法是对的，但是这并不完全等同于探索性测试。可靠性测试用例和基本功能的测试用例从设计方向上是一致的：我们发现某个场景的问题，是为了保证这个场景下软件产品的正确性。

那接下来就是第二个条件了：如何设定测试用例执行的次数或者时间

首先要说明的是，测试用例执行的次数和时间，典型的代表着测试的成本;一个测试用例执行1个小时，执行一天，一周，甚至一个月，就会导致软件中的问题推迟暴露1个小时甚至一个月，这样如果软件产品到了使用者的手中，就可能会遇到这样的问题 ，那么这个测试工作就是个失败的测试工作，测试人员也是一个“不合格”的测试人员。

我们可以假定，一个程序中的bug，需要通过一个用例执行65535（一个16位二进制无符号型数据的最大值）次才会出现因为数据内存不够导致的系统崩溃。每一次的时间大约需要25秒。这样算下来，我们一共需要91.5小时的时间，接近4天的时间才能触发这个问题。4天的时间相对于一个将要发布上线的需求或者软件产品，已是一个很长的时间，因为毕竟在现代社会中，程序员已是一个很普遍的职业，开发出一个游戏app或者一个产品的软件，在人力投入充足的条件下，大约一个月甚至2周足矣，而且现在的模块化设计，甚至一个网站，直接套用模板，只需要做少量的修改，便可以快速上线。更不用说一个简单的需求了。

那么如何在我们不知道一个bug的触发次数的情况下，能够评估出触发该bug的用例次数或以上的次数呢。

这里只能提供一个方向，否则，如果有一种必然的手段，我们的用例设计就不叫测试用例“设计”了，可以叫做测试用例“写作”。

这个需要结合软件本身和软件产品的功能来进行评估。软件本身，即是刚刚提到的程序本身，程序的数据定义本身有一定的范围，在一个几万行代码的程序中，有着错综复杂的数据类型的定义和使用，在任何一个函数中，都有可能使某个变量超出其定义的范围。一些典型的数据如255/65535/等。软件产品本身呢，就跟其功能强相关。一个软件系统支持用户收藏其喜欢的图片，为了很好的客户体验，我们不去设定用户收藏图片的上限，这个时候，测试人员就要保证用户使用该功能的时候不出现缺陷，我们可能会测试收藏1000张照片的功能，甚至是1万张照片，甚至是10万张。

总结：我们应该根据程序本身和软件产品功能两个方面来确定在发现持续压力类型的软件可靠性问题时用例所需要执行的次数。

2)针对第二类，概率性碰撞类软件可靠性问题。

如果要发现这类问题，我们应该如何确定测试的方向呢？

还是要解决两个问题：概率和碰撞。

一提到概率，就会想起大学里面学过的一门课程，概率论与数理统计，一打开此书，就是满屏的超长的数学公式。各种排列组合，阶乘，数据量庞大到不可想象。整个课程我也是晕晕乎乎的，而我自然也不能将此书应用于软件测试。

其实，在软件测试中所需要的概率，并不需要你概率论那么复杂，而主要聚焦的，还是软件相关的因素。可能需要那么一点点的数学知识。

我们可以把概率往外引申，例如随机数。造成软件中的随机现象的因素，出了软件本身外，还依托于执行软件产品平台的硬件系统。我们先从这一个点开始分析。

任何的软件，脱离了硬件，将会毫无意义。软硬件就好比一个人的肉身和灵魂，没有了肉身，灵魂将无处依托。而肉身是实物，如果肉身出了一些问题，精神上难免会受到影响。所以我们要说的第一类的因素，就是这个“肉身”。

在当前集成电路呈摩尔定律发展的现代，电子产品已经普及到生活的各个方面，正在往智能化发展。软件运行在各种各样的芯片上，芯片的集成度越来越高，性能越来越强。但是，硬件与软件一样，再强大的的芯片，也会出现bug。这种bug，或许是在芯片设计之初的bug，或许是在软件使用/调用时触发的bug，总之，硬件同软件一样都是不可靠的，除非经过测试。我们所说的第一类的概率问题，即是可能存在软硬件结合导致的随机性。在cpu芯片中，会有各种各样的管脚，不同的管脚代表不同的芯片计算结果。每个管脚的高电平和低电平代表了数据的有和无。芯片在计算的过程中由于硬件内部/链路的原因(我在这里不想分析出现硬件问题的各种情况，因为这里要表述的主要是软件测试的问题)。给软件系统的运行带来一定的不确定性。我们常常会遇到，因为一个软件产品对硬件的要求非常高，导致性能较差的硬件无法满足软件在各种场景下运行流畅。我们设想，在某种条件下，软件读取芯片中某个管脚时会概率性的无法读取，或是因为硬件的原因，导致管脚的电平值概率性的出现反转，这样程序就会概率性的出错，由此软件问题就会概率性的触发。

另一个因素就是碰撞，其实，对比第一个因素，这个可以理解为软件本身的因素。正如前面叙述的一样。一个数万行代码运行的软件产品，难免函数/分支/流程之间会不停的“碰撞”，这种碰撞就会引发一系列问题。虽然不同的碰撞有一定的关系，但是测试用例毕竟是一种黑盒，即使是白盒测试，将这种关系梳理清楚，也是一件很困难的事情，可能需要投入很多的人力/时间来做这件事情，这样的成本是耗不起的，而且不会有人愿意做这样的事情(这可比研究那些数学复杂公式枯燥多了，毕竟没有那么多牛掰的数学家以此为乐)所以从测试角度看，更多的是一种概率分析。由此，我们可以引入一个“对象”的概念，将我们认为可能存在的某种关系的两个函数/分支/流程称之为对象，我们通过一个步骤/几个步骤，或者一个测试用例将其涵盖，这样的用例执行下去，就可以满足触发该问题需要的场景。

说到这，我们已经在尝试着去测试发现这类问题了。我们已经分析如何设计步骤发现碰撞类问题，那么接下来，就要解决“概率”的问题，即触发该问题所需要的用例执行次数。

似乎我们只能通过软件产品本身来分析测试用例需要执行的次数。但是首先一点，概率碰撞类型的软件可靠性问题与持续压力可靠性问题最大的不同之处在于，其测试用例执行的次数是可以间断的。对于持续压力软件可靠性问题，如果测试用例执行中间做了中断，或者软件本身有了变化，那么测试用例的执行次数就要重新开始计数。而对于概率碰撞类可靠性问题，我们只需要最终统计出该用例执行的次数总和即可。

如果一个程序有一个打开关闭的功能，需要调用一系列的函数，最终通过芯片的管脚来控制开关，这样就会涉及到程序本身的碰撞和芯片与代码之间调用导致的概率问题。如果产品设计的开关使用次数是10万次，似乎我们就要进行10万次或以上的该用例的测试，因为跟硬件相关，可能还需要很大的样本量。所以，该类问题需要大量的测试成本。

总结：概率碰撞类软件可靠性问题，需要结合产品本身特征，评估出发现此类问题所需要的用例执行次数。

免责声明：内容和图片源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。