软件可靠性测试指标,软件可靠性测试分析

软件的可靠，其实就是代码运行流程的可靠性。如果一段程序不管在任何输入条件下都可以稳定的长期运行下去，那这段代码就不存在软件可靠性问题。但是随着代码的复杂，函数调用关系的复杂，参数耦合也越来越多，难免会遇到程序运行到某一定次数，某个时间的时候出现问题。如一个游戏app，当玩家玩的时间超过2小时后，就会概率性的自动退出。电视在运行中突然死机，关闭电源开关重启。如果从表面看软件可靠性的问题，问题种类会多种多样，但是如果从触发软件可靠性问题的bug来说，

主要有两类;

软件的可靠性可分为软件本身的持续压力可靠性问题以及概率性碰撞可靠性问题;

先来说说持续压力类可靠性问题。

先举个简单的例子;

现有一个简单的程序，是统计每天一个学校进出图书馆的次数，假设编程人员在做程序设计时，错误的估计了每天进出图书馆的人数的次数，认为最大不会超过256，他就会定义一个int

8

类型的数据。这样就会出现一个问题，当进出人数超过256时，就会出现数据反转，如果测试人员在测试这一段程序时，设计了一个用例：模拟每天进出图书馆次数超过1000次，那这个程序就无法工作，甚至跑飞了，产生了不可预期的结果(如随机数)。

这是一种由于数据类型不合理，导致的软件可靠性问题。

还有一种时因为约束条件不合理，同时也没有做保护，导致在一定次数/某段时间后出现的软件可靠性问题，总体盒第一个种类相类。

A函数调用了B函数，A函数某个参数在本函数中的范围是1000以内，但B函数是公共函数，他的入参值比A函数小，函数中有一个人计数器，会不断增加A函数传进来的变量，导致在一定次数之后，B函数的参数超出范围，由于此时没有做保护机制，所以B函数无法处理预期外的参数，导致程序出问题。

第二类是概率性碰撞类软件可靠性问题;

如何理解概率性碰撞这个词。还是要先拆解。概率性，是指软件中的问题具有一定的随机性，不是随着持续压力就能触发的，具有一定的概率统计的意思。如一件事情发生的概率是千分之一，那么跑到了一千次，并不一定会出现，因为千分之一的概率是统计出来的，是基于样本量的一个统计值。可能要跑一万次，才会出现，但是从统计学的角度看，它出现的概率就是千分之一。这就是和第一类软件可靠性问题最大的不同;再来说碰撞，为什么叫碰撞?我们知道，在一个大型的商业软件中，客户如果使用一个功能，可能需要成千上万个函数一直在不停的调度中，一个参数可能会在百十个函数中传来传去，这就构成了函数之间的相互耦合。如果一个函数的运行(或其参数)依赖于其他几个函数，而其他函数的运行又依赖于第三个，或者依赖于硬件的性能，如手机的配置，cpu，内存，甚至于环境的温度等，就会造成相互之间有依赖关系的函数执行的不确定性;A函数需要获取B函数的值，而B函数需要从内存中读取某个值作为输出的计算，而此时B函数又被C调用，修改了B函数的内部

变量，导致B函数的出参异常，此时A函数的入参就会异常，程序就执行异常了。这个可以形象的称之为“碰撞”。软件运行过程中 内部的单元运行中的耦合碰撞。

从事这么多年软件测试工作

，也遇到过很多软件可靠性问题，但是归其类，大致可以分为上述两类，其他细分还会有一些特殊情况，但是或多或少会与这两个类型有关联。

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