一些对可靠性测试的思考

1.为什么很多软件都没有可靠性测试

        a.因为业务类型,最常见的软件系统的业务是增删查改,比如校园的管理系统,人力资源管理系统,产品进销存管理系统,常见的个人网站,知识类网站.

        b.因为业务强度,通常来说如果业务量不大,那么也就不需要性能测试,在不需要性能测试的前提下,大概率也是不需要严格的可靠性测试的,比如小心的公众号系统,某某奶茶的管理系统,某某博物网站,因为请求数量达不到一定的数量,完全在硬件性能瓶颈下面.这个时候的测试常常是功能测试下面的边界值测试.所以相对应的一些大型的平台,就一定会有可靠性测试,比如淘宝,或者京东这些网站,或者说一些基础设施,例如百度的搜索,腾讯版的游戏等等

2.可靠性测试中的资产有哪一些

        a.产品相关的故障树.比如会基于产品架构层面的可靠性测试,基于产品运维层面的可靠性测试,基于进程设计层面的资源相关的可靠性测试.以及基于产品业务流程的可靠性测试

        b.产品相关的可靠性测试设计方法.这个点反而是最欠缺的,我读过很多一些书籍,但是却很少由可靠性相关的测试方法,更别提测试设计的方法了.常常遇见的就是,在功能测试的设计过程中,可能发现有些点可能会影响系统的稳定性,以及响应,回复能力等,然后再另外去独立出这部分可靠性用例.

        c.产品相关的可靠性BUG,我个人认为这是一个可以让部门非常快速的积累测试经验的方法.通过回溯,设计,开发和测试在这个过程中的设计策略,技术选型,设计概要,测试策略是非常有帮助的.而这样一个漏出去的可靠性BUG,通常是已经藏得比较隐蔽,而人们又常常会疏忽的地方了.

3.可靠性问题的出发原因会有哪一些

        a.由外界灌入的大量的业务请求呼叫,这种场景触发的可靠性BUG,常见于资源快速被使用完,然后性的任务调度不出资源,然后系统又没有对这些业务请求做限制限流或者流控,那么就一定会引起系统的崩溃.所以对于这场场景,最好的方法就是模拟大量的业务请求,或者呼叫,而如果资源相对稀缺的话,可以采取便捷的方法,即进入系统后台,使用准备的进程软件去将资源消耗空.

        像上述我说的,使用软件在系统后台,讲资源消耗完的方法,我第一次见到的时候,还是非常的困惑的,不太了解是怎么回事,而我看测试设计的时候,也没有找到相关的说明,看起来就像是一种直觉上的经验和敏感性.而在我梳理性能测试和可靠性测试的时候,才有了这个理解.

        b.外界输入的特殊异常的请求,举个常见的例子就是mysql注入了,因为大部分开发者再做数据库开发的时候,会因为技术原因,以及系统复杂度,版本迭代节奏等等原因而采取一个简单便捷的设计开发方法.而这样子就会导致安全问题.另外的,还有,一些软件严格依赖协议去处理业务,这种的话,如果开发者对协议的了解不深,并且在没有做严格的全面的错误拦截的话,就有可能处理失败,轻则可能导致大量请求呼叫失败,重则有可能导致模块瘫痪或者系统故障.

        c.内部的文件使用冲突,比如某个进程处于非预期原因将其他进程所需要使用的文件给破坏了,而在另外一个进程没有做严格的荣誉设施,或者异常防范的时候,则有可能出现程序卡死这种情况,所以应对这种情况有个比较好的方法就是所以必要使用的文件都被被备份一份.比如最近流行的软件架构方式就是将产品容器化,微服务化.如果有某个模块或者进程故障之后,那么被检测系统检测到之后,就可以重新拉起一个新的容器.

        另外,我还设想了一种场景,也就是软件开发层面的BUG了,比如说文件互锁,进程互锁这些,而这些根据我的经验,是常常不会被测试到的,或者说,机会不会遇到的.我想有一个理由就是开发在对代码走读或者合入对的时候,非常注意这个逻辑,然后这样子就可以将可靠性BUG扼杀在摇篮里面.

        d.被黑客攻击,并进入系统内部破坏,这种场景就不是这篇文章说考虑的场景了

4.升级过程中对可靠性的思考

        我曾了解过升级的需求

        a.升级到任何一个过程失败了,都要求嗯能够回退

        b.升级过程中要求业务平稳圆滑

        所以我理解这其实也是一种可靠性的诉求

5.是否有软件可靠性的测试设计方法呢?

        在我看来,应该是有的,根据我的经验,我总结了几点

        a.从大容量的业务场景来设计,比如承诺能力的多倍压力测试,比如3倍,5倍,甚至是10倍

        b.从异常的外界请求场景来设计,这个则是要充分了解,软件产品所处的组网环境,以及业务过程说设计的协议或者约束或者诉求.这个对测试者的经验积累是非常高的

        c.从业务的逻辑流程来设计,比如升级过程的每个关键过程设计故障,测试其是否能够检测响应和恢复,以及回退.

        d.从内部进程的交互逻辑来设计,即使用有相互影响的两个进程或者模块之间的一个来构造故障,测试另外一个模块或者进程的响应方法

        e.从客户的诉求层面来测试,比如数据安全备份等等.