预防性测试

预防性测试，是在写代码之前，针对需求的测试。

预防性测试的要求，就是尽早的发现问题，进而提高产品的质量。

下面来分享一个实例。

比如针对提款机，提出了这样一个需求：一名有效用户能够提取多达200美元的金额或者其账户中的最高数额。

我们来想一想这是个多么可怕的需求。

我们来想一想这是个多么可怕的需求。

我们来想一想这是个多么可怕的需求。

针对这个需求，各位可以尝试写下测试用例，来发现其中的可怕之处。

面试的时候，就喜欢提问这些发散的问题，来分析应聘者的测试思路能达到的程度。

—————————————————————我是分割线————————————————————————--------------------------------------

那么这个需求到底有多可怕，我提几点：

1.“或”是两者任取其一就可，但是需求中的两条却互相冲突；

2.作为有效用户，可能账户中没有200美元，也允许提取200美元吗？

3.账户中的最高额的范围可以是0~无穷，1分也可以取？千万亿账户也可以一次取出？

不明确的需求是可怕的，即使是一字之差，也可能让开发谬之千里。

测试一定要仔细，一丝一毫不要放过。并且要尽早，从需求开始测试。

分享如下故事共勉：

AWS在昨天给出了确切的解释：一名程序员在调试系统的时候，运行了一条原本打算删除少量服务器的脚本，结果输错了一个字母，导致大量服务器被删。为了修复这个错误，亚马逊不得不重启整个系统(在此之前已经几年都没有重启过了)，最终导致了震惊全球的Amazon S 3 宕机 4 个小时事件。 程序员的世界就是这样的不近人情，一丁点儿错误就足以酿成大错。在这次“一个字母造成的血案”之前，刚刚发生了Gitlab程序猿用错一条命令误删了整个数据库的悲剧。再久一点以前，欧洲宇航局的的火星探测器因为传感器失灵了仅仅一秒钟，就造成探测器在火星表面坠毁，历时数年的探测计划功亏一篑。 　　所以，当你身边的程序员为了一点点小事较真的时候，你一定要理解：魔鬼都藏在细节里啊