这是单元测试系列文章第一篇，完整的系列内容：
深入单元测试系列之一，软件测试的历史
深入单元测试系列之二，TDD和单元测试
深入单元测试系列之三，Junit5和Mockito
深入单元测试系列之四，测试的度量
深入单元测试系列之五，持续集成和持续交付
软件测试是在软件的发展过程中逐渐产生和成熟的，要了解单元测试，也不得不从软件测试说起，只有了解一件事物的过去和历史背景，才能站在更高的视角去看待这个世界。
1962年6月22日9点26分，在弗罗里达州的卡纳维拉尔角火箭发射基地，随着一声巨响，Atlas号火箭点火成功腾空而起，它装载着水手一号探测器准备送入太空。发射站的工作人员紧张地盯着监控中心的屏幕，因巡航系统故障火箭已经偏离了正常的轨道，工作人员切换到了备用雷达，切换之后发现一处BUG导致雷达无法正常运行，偏离越来越远，第293秒，安全主管做出决定，摧毁该火箭，又一声巨响，Atlas瞬时化为一团火球，造价约1850美元的设备付之一炬。在此之前，相同的系统已经成功发射过两次，没有出现问题，是因为导航系统正常而未启动备用雷达系统，而这一次是切换到有问题的雷达系统了。一个月之后，该BUG被修复，水手二号发射成功。
历史总在不停地重演，大约从1995年开始，成千上万的程序员忙着升级程序，解决千年虫问题，将原本设计成两位的年份转换为四位的年份。2011年，捷豹被迫召回2006年-2010年期间出厂的柴油动力车，因为软件缺陷阻止巡航系统关闭，发动机停下来才能关闭巡航控制。
1957年，Charles L Baker在IBM工作期间，读到一本书《Digital Computer Programming》获得灵感，提出了Debugging和Testing进行区分的观点，这是首次将测试作为软件开发中的独立活动的里程碑，他为此写文章讲述了他在项目中的应用，在此之前通常认为软件的测试就是Debugging。
1979年，经典之作《The Art of Software Testing》问世，作者Glenford J. Myers，当时同样在IBM工作，曾经参与过System360的研发工作，他提出了关于测试的核心观点：测试是为了发现程序中错误而执行程序的过程。在书中探讨了代码检查、代码评审、测试用例的设计、模块测试、系统测试、调试等测试相关的话题，至今广泛流传。
1983年，美国国家标准局发布“Guideline for Lifecycle Validation, Verification and Testing of Computer Software”，明确定义了测试的两个活动：
Verification: Are we building the product right
Validation: Are we building the right product
软件测试工程在这个时期得到了快速的发展，软件测试正作为一门独立的，专业的，具有影响力的工程学发展起来了，出现测试经理、测试分析师等职称，越来越多的测试会议和活动开展了，也有越来越多的文章和刊物出版。这个时期，软件测试不再是程序验证的过程，而是贯穿软件生命周期的活动，包含从需求、设计、单元测试、集成、验收等过程。
2001年2月，在美国犹他州的雪鸟度假村，有17个中年男性汇聚一堂，本来邀请了一位女士，但是没有到场。他们在软件行业都有二三十年的经验，可谓是业界顶级专家，有计算机科学家，有软件公司CEO，有极限编程XP之父，有Scrum之父，还有重构之父等。这些人对软件开发的现状深恶痛绝，他们虽然观点各异，但都希望改变低效的、重量级的、高度仪式化的软件开发过程，比如瀑布方法，找到一个轻量而高效的方法。他们激烈讨论了两天，在头脑风暴中不断擦出思想的火花，最终排除万难达成一致，签署了影响软件行业二十年的《敏捷宣言》。一石激起千层浪，宣言发布后，簇拥者不断，后人不断在敏捷宣言的基础上实践和改进，产生了大量提升软件开发效率的方法和工具。
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值
作为历史的见证者和推动者，这段历史在Bob大叔（Robert C. Martin）的书《敏捷整洁之道》中有更详细的描述。宣言下方的署名第一个Kent Beck就是极限编程和测试驱动开发的创始人，在Java流行之前，他对Smalltalk编程语言造诣颇深，著有《Smalltalk Best Practice Patterns》一书，并写出了Smalltalk的测试框架SUnit。
测试驱动开发的测试先行，重构，以及小步前进等理念极大的提高了软件开发的质量，得到广泛的支持。测试已经变成了软件开发的一部分，测试不仅仅是事后的验证，还需要在开发阶段就要提前预防，通过重构防止质量变差，代码腐化。 通过自动化和持续集成等工具，做到变更即测试，时刻保证软件的可工作和可用，达到快速交付的目标。例如在Facebook，没有专门的测试人员，自动化测试案例是由开发人员完成，我还专门联系了一个在Facebook的前同事进行了确认，他们团队就没有专职测试人员。历史一次次证明，没有不变更的需求，总会有测试不出来的生产问题，那么尽早的开始测试，尽早发现问题，上线之后的风险也就越小，修复的成本也就越低。
随着云计算、微服务、DevOps、AI等工具和技术的发展，软件的规模越来越复杂，已经不是几台服务器就可以独立运行起来的系统了，可能是成百上千的微服务构成的庞大的复杂系统，不仅仅包含了应用软件，还包括底层的基础设置，各种依赖的服务，未来的软件测试也势必进化，在效率、智能化、安全性等方面需要更多关注。
下一篇文章将讲解TDD的实践，敬请关注。
网友评论