关于软件测试

1,关于测试的杀虫剂效应

最近看到的这个词,可能有点落伍,但觉得很有道理,当一个测试和一个开发团队合作时间很长,就像同一款农药对农作物上面的害虫的效果,最开始的时候锋芒毕露,有奇效,慢慢的效果会越来越差,也就是害虫知道了杀虫剂的弱点在哪,盲区在哪,因而产生了耐受性,免疫杀虫剂。测试就像杀虫剂,想去去除开发出来的软件上面的虫子(bug),而长时间的一直合作,测试同学的手法,思维方式会在一定区间内禁锢,使得这个区间之外的错误不容易被看的到,事实上这个问题也不是不能解,借鉴农药的例子,也许可以想一下:

<李>

换别的牌子的农药,也就是测试岗轮换,每个人的思维方式不同,每个人的盲区也不同,这个时候轮换可以将重叠的部分加固,盲区部分被一点点发现,相辅相成互相沟通,可成活水。

<李>

农药升级,修改配方,也就是测试同学通过各种途径,拓展自己的视野和思路,试着消灭自己的盲区,这个拓展和提高不仅局限于技术,还包括思考方式以及对业务核心的理解等。

<李>

多用集中不同农药,也就是交叉测试,跟换品牌农药差不多一个意思,多种不同的覆盖面,会让盲区变得小,但也可能会导致副作用,比如耗时会比较长,投资回报率低。

<李>

提升农药浓度,也就是加大测试密度和强度,这样也可以解决一部分盲区,一些耐受力不强的虫子会被去掉,但也有弊端,比如ROI低,高密度和强度会使顽固的错误更加顽固,还会使降低工作积极性和成就感。

2。关于测试的逆向思考

我们一直在做自动化覆盖的核心思路是:“我来看看系统是不是有错误,是不是和之前不一样了”,就像有一条路,有一个机器人按照既定路线往前走,看看原来平坦的地方是否有坑了。

按照这个思路再拓展一下,另一个核心思路也许是“系统里现在可以确认有1个错误,能不能找的到”,就像有一条路,现在明确了有1个坑,这个机器人按照它既定的路线走,能否找到这个坑。

再按照这个思路往下想,想发现也许也可以这么想

<李>

系统里现在有1个错误,能不能都找到

<李>

系统里现在有至少10个错误,能找到多少

<李>

系统里面有1个关于数字格式化的错误,能不能找到

<李>

系统里面有1个关于数字格式化的错误,有1个空指针错误,能不能找到

<李>

系统里有3个类型的缺陷各2个,能不能都找到

<李>

…

想了想,今年云栖大会上有人的分享了一个思路,修改被测代码,用AOP等手段注入故障或者修改运行时数据,以此来检查测试用例有效性,也就是说,不再是从未知的一片漆黑中找坑,而是制造明确的1个或者多个坑,看看我们的用例是否能找得到。

这个思路可以做的事情其实还挺多的,也是对于测试同学对业务代码的理解要求更高了一层,需要能够通晓业务代码,并且有模拟故障模拟bug的能力,然后以此去测试自己的自动化的覆盖能力,也许这就是有同学曾经问过,但至今不知道怎么回答的那个问题:

“你用自动化去测试业务系统,那用什么来测试你的自动化呢?”

现在这个问题也许可以这么回答:“用自动化的断言测业务系统,用业务系统的bug测自动化,测开闭环,相辅相成”

3。用开发业务系统的思路写自动化测试用例

我们测试业务系统的时候,从单元考虑到接口考虑ui然后考虑大每秒考虑多并发,考虑容错考虑异常处理,考虑监控考虑.....

设计自动化测试的用例的时候,也许也应该试试能不能这么做,比如:

<李>

单元能力封装,可能是接口,可能是数据准备,每个单元可以单独运行,可以复用

<李>

单元能力编排成流程,可能是接口,接口——数据可能是数据,数据,接口,每个编排可以单独运行,可以复用,比如编排成提交流程,发起审批流程,审批通过流程

<李>

流程编排成业务,可能是提交——审批,通过可能是提交——审批——拒绝

<李>

考虑并发问题,单个用例多触发,同时触发运行

<李>

单元用例,也是需要测试的输入——运行,输出,断言,就像业务代码中1个的方法一样。

<李>

把自己业务线的自动化用例封装成一套以单元用例,单元流程,单元业务组成的一套有层次有验证侧重点的框架,比如单元用例主要校验单个接口或者数据准备的健壮性、可靠性,正确性等等,单元流程用例主要通过每个单元用例吐出的数据进行业务流程串联,以验证单个流程【或者某页面,1个页面的渲染需要很多接口同时生效】正确性,业务用例主要通过各流程的能力串联完成完整的业务,验证业务正确性。

关于软件测试