如何破坏软件功能：常见缺陷模式

大家有没有发现这个有趣的现象，在研发过程中，不管开发自测的多完善，验收标准多完备，QA总能发现更多缺陷。哪怕是一个在线上已经稳定运行很久的既有系统，QA一来立马搞挂了。有时候不得不感慨，QA好像柯南一样具备招虫体质，这发现更多bug的脑子是怎么长的？

本文就来讨论一下，这种能发现更多bug的思路是如何形成的，QA们都是如何破坏软件功能的。

求而不得 - 不提供想要的资源

这个模式简单来说，就是软件期待一个A，尝试以各种方式不给A，使其欲求不满。有以下几类可以尝试的方式。

想要A不给

直接拒绝提供想要的内容，如系统期待上传照片，就不上传。

想要A给A'

提供一个容易混淆的类似内容，如系统期待上传证件照，上传一个动物图。

想要A给B：正常B/溢出值/错误类型

提供一个不是同类的内容，如系统期待上传图片，可尝试上传非图片类型的文件。

想要一定数量，给数量外

提供一个超出需求的资源数量，如系统最多上传5张照片，在批量上传时选6张。

不求硬给 - 提供多余或错误的资源

这个模式简单来说，就是在系统并不期待的情况下，尝试给各种各样的内容。有以下几类可以尝试的方式。

不想要A给A

提供系统不需要的内容，如业务不允许修改审批后的图纸，尝试重新上传进行修改。

不想要A给A'

提供系统不需要的内容，且与需求内容不一致但容易混淆，如在压力峰值时给一个错误的数据请求。

不想要A给B（似乎没问题？试试呢）

提供系统不想要的内容，且与需求内容完全无关，如在上传Excel导入数据时，插入多余的列信息、多余的标签页或截图等。

不按规矩办事 - 尝试绕过限制（时间、数量、空间等）

这个模式有点像薅羊毛，需要绞尽脑汁绕过障碍。

有时限的事情，在时限边界或时限外做

在时限不允许时尝试，如超过截止日期尝试下载文件。在时限边界疯狂试探，如跨时、日、月、年等操作。

有次数限制的事情，在超次边界或超次做

限制次数的事情，尝试多做，如下单按钮多点击，重复提交信息，重复刷新页面等。

有顺序的事情，不按顺序做

不按顺序的方式有很多，如跳步、故意不完成流程、反复在同一个节点进进退退、尝试倒序等。

Mission Impossible - 限制资源

这个模式尝试让系统做各种做不到的事情，又要马儿跑得快，又要马儿不吃草。

尝试占用、移动或删除正使用的资源

如尝试上传正在编辑的文件，删除正在下载中的文件等。

尝试在较差环境下做事情

较差的环境可能包括：弱网、磁盘空间不足、CPU占满、风扇狂转。

尝试做业务不允许的事情

如库存删到零继续删，或取消锁定状态的订单等。

构建你的“捉虫清单”

如果遍历了上面的情况还没出bug，那说明程序的健壮性不错，可以再尝试以上一种或几种的组合，大概率能有“意外收获”。当然，上面列出的是一些常见的能引发软件缺陷的模式，对于不同软件来讲，由于其涉及的业务、产品形态、技术架构、资源环境等条件均不相同，在不同上下文里可产生基于特定系统的“捉虫清单”，在一些公司也会以启发式列表的形态沉淀下来，这个列表对于了解软件特性和缺陷是很好的输入，每个组织都应该沉淀属于自己的启发式列表。