13.5 软件测试的本质
13.5.1 纯软件测试方法介绍
武术的本质是“攻”与“防”，那么软件测试的本质是什么？笔者认为也是两个字“测”和“试”。所谓“测”，就是针对软件文档，对软件产品进行检测，找出其缺陷，也就是通常所说的Bug，供开发工程师修改的一系列工作；所谓“试”，就是在用户使用的软件环境（包括操作系统、数据库系统及应用软件系统等）、硬件网络环境（包括CPU、内存、硬盘空间、网卡和网络带宽等）和其他特殊情况（包括高并发、高容量）的环境下，尝试软件是否可以正常运行的工作。
为了解决让软件研发人员头疼的软件危机问题，出现了各种软件工程模型：比如本书中“软件工程模型”所提及的瀑布模型、迭代模型等，根据这些软件工程模型又建立了各种软件测试模型（本书中“软件测试模型”所提及的V模型、X模型、H模型），以至于现在很流行的敏捷开发与测试模型。但是这些模型的建立，并没有从本质上解决软件危机的现象。据2014年统计，美国仅有5%的软件项目是按照计划发布的。因此，业界流行一种说法：“一个软件产品能否交付，主要看软件支持工程师能否说服用户接受带有缺陷的产品，这就是所谓的灰色发布”，显然，这是很不严谨的。
众所周知，软件测试是保证软件产品质量的一个重要环节。因此，要把软件测试做好，就应该抓住软件测试的本质“测”和“试”。抛弃各种模型中的“套路”，不要把过多的时间花在书写软件测试文档和软件测试代码上，而是要集中精力，多把时间花在“测”和“试”上。整个“测”和“试”的过程要贯穿软件生命周期的各个阶段，这个过程从软件需求阶段就开始，一直贯穿概要设计、详细设计和代码，直到最后软件形成后再一版接一版地测试。
这里，笔者不是反对书写软件测试文档和软件测试代码。而是强调不要过度地书写软件测试文档和软件测试代码，必要的软件测试文档和软件测试代码也是必须的。比如，没有软件测试计划，那整个软件测试管理就要失控；比如不书写软件测试代码，那么许多软件测试，特别是回归测试和性能测试就不能有效地进行。但是用在文档和代码上的时间过多，就得不偿失了。在这里举个例子：一个人设计书写一个功能测试用例起码需要花费20分钟的时间，那么书写1000个功能测试用例就要花费20000分钟（约334小时），把这1000个功能测试用例的四分之一转化成功能测试代码就要花费约334/4×2.5=208小时（按照书写一个功能测试代码需要2.5倍的功能测试用例的时间计算），加上书写功能测试用例花费的334个小时，总共需要花费542小时。按照每人每天工作8小时计算，也就是需要67个工作日。事实上，一个项目中一个软件测试设计工程师需要书写的测试用例一般都有上千甚至上万个，这样估算下来，如果把时间都花在书写功能测试用例和书写功能测试脚本的时间上，读者可以算一下这样下来大概需要花费几个月甚至几年的时间了，这个项目也就过了交工期限了，也就没有时间搞软件测试了。
抓住软件测试的实质“测”和“试”，把主要时间和精力花在“测”和“试”二字上，软件产品的质量才能得到保证。我把这种软件测试方法叫作“纯软件测试方法”，这也正是软件测试的本质。
顾翔凡言：
不是好的工作会给你带来好的心情，而是好的心情会给你带来好的工作。
