详情
本书共分12章，以案例为背景，以项目实际运行的全过程为路线图，全面展开软件测试的思维方式、流程、方法和优秀实践，涉及测试计划、测试需求分析与设计、软件评审、自动化测试、测试执行、缺陷跟踪、结果评估等关键内容，最后辅以深刻的剖析与总结。新版更侧重架构，策略、分析、设计和基础的内容会去掉。
书名：全程软件测试（第3版）
ISBN：978-7-115-49656-0
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
编 著 朱少民
责任编辑 陈冀康
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
本书系统地总结了过去十年中软件测试发生的变化，浓缩了作者许多宝贵的软件测试经验。本书首先介绍对于软件测试的不同看法，全程软件测试的思想，软件测试的基础设施与TA框架、团队能力建设；然后逐步深入到测试的计划、设计、执行、持续反馈和改进；接着，讨论全程测试的思想，包括全程静态测试、全程性能测试、全程安全性、全程建模、全程可视化。本书最后展望了软件测试的未来。
本书适合软件测试人员阅读，也可作为相关专业人士的参考指南。
朱少民老师的新书既涵盖了前一版的精髓，又融合了最新的方法和技术，好比业界的一盏明灯，为软件测试行业引领方向。希望更多的有志者能通过学习本书，帮助企业走向“高效率的软件测试而获取高质量软件产品”的光明之路。
——刘琴，ISTQB中国首席代表、同济大学软件学院教授
全程测试，全程有亮点。少民的《全程软件测试》（第3版）恰似一盏明灯，为年轻测试从业人员照亮前进的道路。
——蔡立志，ISO/IEC中国专家代表、中国软件测试机构联盟技术委员会主任、上海计算机软件技术开发中心副主任
坐下来，写一本书，是我的一个愿望。凡尘俗事纷扰，使我的愿望变成了梦想，但朱老师做到了。怀着羡慕的心，读起这本书。正如朱老师的为人，这本书荡漾着对理想的热情向往，和对现实的冷峻思考，恰是一个有着深厚产业实践底蕴的学者对他所钟爱的工作的深刻思考和精确总结。笔者乐谈，读者乐思，这是一本能够驱动你去思考的好书。唯盼朱老师永不收尾，持续优化。
——李戈，北京大学副教授，CCF软件工程专委秘书长
2010年，在《赢在测试2》中，我把《全程软件测试》作为新员工入门指南推荐给读者。如今，新一版的《全程软件测试》再次让我这个从业20年的人眼前一亮，它不仅是对新入门和新项目经理的指南，也是每位测试从业者的必读。
——王冬，360测试总监
本书阐述了全生命周期软件测试思想和方法，展现了软件测试的精髓，对所有软件测试的从业人员和技术研发人员都具有极强的指导意义，是一本难得的软件测试人员案头必备书籍。
——杨春晖，中国赛宝实验室软件评测中心主任
抽空看了朱老师的“全程软件测试”第3版，感触很深。随着科学技术的不断快速发展，保障质量的测试也在不断调整，软件测试也覆盖了全生命周期，包括前期的用户需求，还包括了后期的运维过程。此书定能给读者带来对测试较全面的理解。
——周震漪，CSTQB 常务副理事长，TMMi中国分会副理事长
本书辅以大量生动的真实案例，带你系统的思考软件测试如何贯穿在整个流程中发挥作用。无论你是象牙塔中的同学，还是已经工作的从业人员，本书都有很好的指导意义。
——杨凯球，中兴通讯测试经理
本书给我的印象可以两个关键词来概括——“全面、匠心”。能够受邀为本书做推荐辞，本身即说明了朱老师全面的视野和思路。我曾提出自己已经从测试岗位转为业务研发工作，朱老师很快表示他就是希望能从业务、整体研发角度来评论本书，不愧为持续关注业界最新进展、活跃在业界众多类型企业的大家。从内容来看，本书囊括了软件测试的方方面面，亦可作为一部专业人员和测试工程师案头的全面工程手册。本书也体现了朱老师的匠心孤诣。他二十年专注并活跃于软件测试领域，把自己对于软件测试的认识扩展和升华过程凝练成本书的三个版本。我个人觉得，对于把握测试团队方向、思考软件测试演进趋势的业界前辈们来说，把本书三个版本对照起来看看也许别有一番体验和参考价值。在本书中，朱老师仍然紧密围绕软件测试的技术和知识体系不断雕琢、围绕主题有舍有取，而不是单纯追逐最近业界学界的热点方向去扩张、去蹭热点，依然体现的是一位专业匠人的以始为终。虽然离开直接的软件测试工作一段时间了，我如今在自动驾驶这个快速发展变化新领域的业务研发过程中，仍然觉得在软件测试工作中接收到的体系化知识和训练，不仅是测试专业技能的充实和提升过程，也是对于自己的系统性思维和辩证思路的潜移默化的训练，让我在现在的工作中仍然受益匪浅。
——胡星， 百度智能驾驶事业群主任研发架构师
《全程软件测试》是一本有着丰富理论和实践经验的软件测试经典，更是一本与时俱进的“活着”的书！从2007年第1版到如今2018年的第3版，每一次出版都融入了少民老师对软件测试工作的最新思考与长期沉淀。相信在如今的Devops和EP潮流之下，无论是软件测试工程师、开发工程师还是运维工程师，读完此书，定会对如何全流程、全方位地开展高效的软件测试工作有着良多的启发和感悟！
——廖志，腾讯质量管理通道委员、CSIG地图产品质量中心总监
非常高兴地看到，本书在十年后还有新版问世，这在原创技术图书里是非常少见的，也充分证明了本书自身的价值。作者既有多年的一线工业界的实践和咨询经历，又有丰富的高校教学经验，故能给出全面的测试知识框架，所介绍的流程、思想、工具、应用场合贴近最新的业界实践，非常适合测试人员阅读。
——刘江，美团点评技术学院院长，CCF技术前线委员会秘书长
从《软件测试方法和技术》到《软件测试-基于问题驱动模式》再到《全程软件测试》，朱老师不断保持着对技术及理论的探索，持续为行业做着贡献。软件行业发展这些年，我们逐步意识到作坊式的软件开发已经逐步被工厂级的工程体系所替代。敏捷、DevOps、CMDB都在不断减少着自身对测试的依赖，力求为用户创造更大的价值。而在这个“淘汰测试”的时代，本书给了我们新的方向，从软件测试走向全程软件测试，无论是需求端的ATDD还是运维端的环境数据延伸都一一覆盖，并且还给出从思想到技术、从技术到体系、从体系到管理的整套方案。
对于在软件测试行业的迷茫着朋友，本书就是那盏明灯，也许你以前错过了跟上风口的列车，那么这次一定不要错过走在测试前列的良机。
——陈霁，上海霁晦信息科技有限公司CEO，VipTest联合创始人
作为该书第1版的老读者，我有幸提前阅读本书。与10年前相比，本书虽然还是按软件测试的生命周期作为主线，但内容与时俱进，其中每个环节都赋予了新的内容，基本上覆盖了近几年主流和热点，堪称测试大全。
——陈晓鹏，埃森哲中国卓越测试中心负责人
作为质量保障的主要手段，软件测试应该贯穿软件开发和运维的全流程。在工程实践和课堂教学中，常常出现知易行难的情况。本书以软件开发全流程为主线，介绍了不同阶段的软件测试主流方法及工具。对于软件工程专业学生和从业人员都有很好的参考价值。
——陈振宇，南京大学教授，慕测平台创始人
毫不夸张地讲，本书是献给所有从事软件测试朋友的礼物。朱少民老师将各种软件测试方法、流程、理论及实践融会贯通于整个软件产品的开发过程中，深入探讨了其经济性、哲学性以及社会性，为软件开发中的质量和测试画了一张全景图。沏上一杯茶，关上电脑和手机，顺着这幅图，一窥这百家争鸣的软件测试流派贯穿于软件开发的始终，实乃一件美事。
——耿晓倩(Christina Gen), Splunk旧金山总部测试总监
这是很好的一本全面、系统介绍完整软件研发过程中测试相关活动如何考虑开展的书。本书吸取了最新的软件工程实践和思想，即便在技术日新月异的今天，至少在多年内对测试工作都有指导性。
——孔德晋，华为终端Hicloud测试经理
软件测试很重要，是质量守护的关键工作之一，但如何在从需求到上线的全过程中守护质量是个难题。软件测试需要和开发不一样的思维方式，一般想不到的也就测不到，如何做好测试的分析和设计呢？软件测试很有难度，也容易被误解，经常遭到简单的质问——为什么没测出来？为什么要那么多测试时间或资源？敏捷研发模式下，速度决定成败，在快速迭代中如何高效测试、如何与开发和运维融合等都是新课题……朱老师以多年的理论研究和实践，在本书中为我们抽丝剥茧、解开谜团。
——李怀根，广发银行研发中心总经理
还记得十年前《全程软件测试》（第1版）问世时，我刚开始负责一个测试团队，每天忙得昏天黑地还不得要领。正是这本书帮我系统地梳理了测试知识，建立了自己的测试思想体系，助我走顺了测试之路。转眼间，这本书到了第3版，接到朱少民老师试读邀请后，细读书中内容，无论是书的构思结构，还是讨论的测试思想和测试技术，以及对测试趋势的理解和分析，都让我眼前一亮，非常值得测试者们深入学习思考，诚意推荐。
——刘琛梅（梅子），绿盟科技防火墙研发经理，《软件测试架构师修炼之道》作者
软件测试是当前评估软件质量最有效的方法，而本书对此进行了系统的、深入简出的讲解。本书不仅包括了软件开发全过程中的测试知识，还包括了当前工业界的各种测试实践。如果你需要一本书来对当前软件行业中的测试有一个全方位的、系统性的学习，那就是它了。
——刘冉，ThoughtWorks资深软件质量咨询师
这本经典之作源于十几年前我们WebEx的实战经验的总结。当时WebEx开硅谷历史先河，首创SaaS云服务（那时还没叫“云”）。我们中美两国几百个WebEx工程师积累了一套非常行之有效的、云应用程序的测试体系。这套体系不仅在中国，在硅谷也处于领先水平。在过去十几年里，我很高兴看到Kerry把这些实战经验不断地总结演化发展到今天。回过头看，我们当年的很多测试方法与实践在今天的软件开发领域很好地与时俱进，而Kerry最近几年在同济大学的教授生涯又让他有机会把这些实践经验上升到理论层面，然后结合他和其他所有的大小公司的接触合作，让他有机会获得了更广大和前卫的视觉和理论基础来把这些东西都很好地总结起来。所以我可以很负责地告诉大家，这本书的理论实践一体化价值在大陆同类题材书中应该是首屈一指的。
——Phyllis Chang, Senior Manager, WebEx Engineering，Cisco HQ
如果你正在寻找一本以真实项目为背景，并且从软件研发生命周期的全程视角来探讨软件测试体系化知识以及最佳实践的书籍，本书无疑将会是你的不二选择。作者在国际一线IT公司的从业经验加上深厚的软件工程学术功底，才使本书的呈现成为可能。更难能可贵的是，本书不仅系统性描绘了全程软件测试的整体技术框架以及管理实践，还对软件测试将来的发展方向进行了展望，讨论了如何让AI为测试服务、云计算与测试的基础设施建设、微服务下的契约测试和智能单元测试等前沿的主题。可以说，这是一本软件测试工程领域中理论与实践全面融合的力作，无论你是测试的新人，还是久经沙场的测试老兵，都不容错过这一佳作。
——茹炳晟，Dell EMC 测试架构师
《全程软件测试》从第一版问世到如今发布第3版，已经十载有余，这本书的修订过程不仅是朱少民老师个人软件测试思想精髓不断升华的过程，更可以说它本身就是测试行业发展史中最闪光的那一部分。
——王斌，Testin云测解决方案事业部副总，VIPTEST测试社群架构师
如果你是一位测试领域的从业者或是初学者，能读到这本书是非常幸运的。它可以引导你系统地了解软件测试全过程的方法和技巧——从测试需求分析到设计，再到测试框架，甚至也谈及了最新的AI技术应用。常读常新，这本书值得拥有！
——王金波，中国科学院空间软件评测中心主任/研究员
十年过去，“全程软件测试”的理念仍然历久弥新。2007年通过本书第一次接触到“测试前移”的概念，深深地影响了我，并推动着我从功能测试、自动化测试逐步到现在做持续集成和代码质量提升的工作。十年前的第1版作为教科书般为广大测试人员指导迷津；十年后的第3版加入了很多新的测试理念和技术实践，无论是功能测试人员、测试开发人员、测试架构师还是测试质量管理人员，都能够从书中找到自己所要的知识和答案。
——熊志男，京东高级测试开发工程师、测试窝社区联合创始人
作者从认知、思想和理念层面介绍了对软件测试的核心理念、方法和术语的认知，剖析了要“全程”软件测试的原因，视角极具高度。此外，本书详细介绍了业界最为流行的测试方法、技术和工具，具有极高的实操性和参考性。无论你是软件测试的大牛，还是软件测试的初学者，这本书都值得你仔细研读。
——许永会，知名通信企业资深测试工程师
在敏捷开发、DevOps日渐流行的今天，怎样围绕需求和风险全面开展测试工作？怎样让整个研发过程始终保持对质量和风险的掌控？这本书将带你完成一趟全景式的体验，并从中找到答案。
——杨晓慧，前华为测试专家，现AI机器时代CTO
和开发、运维等相比，测试有一个很重要的特殊性，即开发和运维等的门槛相对较高。想做这些工作，需要先登山，可能登山到半山腰才能算入门，然后再继续攀登提高；而测试的门槛相对较低，测试的大门在山脚下，一般人都可以很快入门，但入门后会发现一座大山，所以说，测试是入门后才开始登山的行业。这是一本难得的理论结合软件工程实践的“红宝书”，它不仅适合刚入行的人，也能帮助多年从业者梳理已有的知识体系，更上一层楼。
——杨忠琪，东方证券测试负责人
这是一本经历了大量读者验证的佳作，十年后的第3版本身就说明了一切。新版既包含了“测试贯穿软件全生命周期”这样历久弥新的观点，又加入了敏捷、DevOps、微服务、云计算、AI技术等新话题。无论是测试界新兵，还是已经入行多年的老将，都应该听一听“测试老古董”怎么说“全程软件测试”。
——于洪奎，中国银行软件中心高级经理
在“客户体验为王”的互联网时代背景下，本书的再版无疑为我们跳出测试看测试、跳回测试做好测试提供了更多可能。测试之内，本书多维度、多层面对软件测试工作展开了介绍：有理论指导，有实践说明，自然又自成体系，于软件质量保证、过程改进有积极的指导意义；测试之外，如果有心，看到的就不仅是软件质量保障方法、技术，还能看到一个行业的缘起与趋势、机会和挑战，然后做正确的事。若都能高质量完成，则组成一个个高质量的“测试人生”。
——钟思德，灼识咨询顾问、知名通信公司高级测试经理
本书作为国内软件测试领域原创的经典教科书，已历经十余载，随着近年软件开发流程的不断演进以及互联网化的冲击，对软件测试和质量管理也相应提出了更高的要求和标准，本书第三版在前两版的基础上，贴合业界前沿，增补了开发运维一体（DevOps），安全软件研发流程（SSDLC），微服务等内容。无论是对于在校学生，或对于从事软件测试和质量相关领域的职场人士，相信本书都会是一本贴近前沿，集理论与最佳实践于一体的一本佳作。
——朱波，香港航空有限公司IT经理
读完这本书，我的脑海里出现“测试人生”四个字。作者从测试经理、QA总监到大学老师，一步一步走来，在软件测试领域辛勤耕耘几十年。他自称“测试老古董”，但我更愿意称他是国内软件测试行业的元老级人物。朱老师亲历了中国软件测试从作坊式到科学方法论、从瀑布模型到敏捷开发模式、从手工测试到自动化测试、AI测试，细推物理，孜孜不倦，坚守几十年，不断迎接新技术的挑战，反思、总结、布道和分享。也正是这份精神，让我这个不是很懂软件测试的IT人欣然答应为本书作序。
我最近有一个演讲——“产业互联网时代不是产品运营而是客户运营”，强调对客户足够的关注与尊重，其实质就是“质量”的价值。当年，我掌管亚信，带领亚信成功地实现了向软件与服务的转型，立足于自主开发软件产品，形成大型软件研发和质量控制体系，深刻懂得“质量”是企业立业之本。鉴于国内软件行业的惯例，软件质量控制体系的建设更多依托于软件测试体系的建设，软件测试是软件企业不可忽视的一面。“质量”和“测试”正是我和作者之间的纽带，将我们联系在一起，共同探讨其中的奥秘。虽然成就了我们不同的人生，但在“质量”和“测试”上，我们存在诸多的共鸣。
软件测试技术起源于西方，但在广泛应用的中国市场得到极大的丰富和发展。一本写得好的书必定是有其启发性，从本土文化的视角去读这本书，也是趣味盎然。这本书让人想到了《孙子兵法》（英文译作“The Art of War”），由此我们不妨称这本书为“测试的艺术”。让我们从章节中撷取几朵“小花”，去体会一下万物相通的奇妙和测试之美。
上医治未病。第2章给出了全程测试的概念，其中测试过程的左移强调了在软件产品如何构建高质量的需求和设计，以及如何在项目早期将软件缺陷消灭在萌芽状态，减少后期测试和返工的工作量。毋庸置疑，这会大大降低软件企业的研发成本，更好地提升交付质量。
兵马未动，粮草先行。第3章叙述了测试项目的准备工作，不仅介绍了如何构建持续集成的环境和展示了层次清晰的优秀测试工程师能力图谱，还重点描绘了DevOps工具链和整个团队的测试能力建设，基于DevOps开发模式和团队技术全栈能力的要求，在当下广受关注。
知彼知己，百战不殆。在项目启动前要清楚测试的上下文——项目背景、产品结构、技术条件和其他各种因素，清楚产品的服务对象是谁，准确理解用户的需求，达到有的放矢和有效沟通目的，为后续的测试计划与执行做好充分的准备。
磨刀不误砍柴工。第6章的测试计划核心是测试分析和制定测试策略，本书也给予了透彻的说明。制定一个切实可行的计划，是后续测试工作的基线和准则。
工欲善其事，必先利其器。第8章和第13章给出了测试自动化的两种不同境界，从使用工具半自动化测试到基于模型的彻底自动化，是未来许多企业要经历的过程。而这中间，始终离不开软件工程师的探索与创新。
以不变应万变，持续优化、持续加固，这些都是永恒的主题。无论技术如何突飞猛进地发展，总有一些需求是基本不变的，要以静制动，持续改进，软件质量终究帮助企业胜出。第9章到第12章，一气呵成，值得软件企业好好学习，让自己立于不败之地。
不以规矩，不成方圆。第14章给出了全程可视化的测试管理，重点呈现软件测试过程中的各种度量，这些完整全面、细致周到的度量指标对众多软件企业都有良好的参考价值。仅仅这一点，我也毫不犹豫地买下这本书。
非常之观，常在于险远。最后的测试展望介绍了新技术给测试带来的新的机遇和挑战。云计算、微服务、AI等这些前沿技术带给IT业的冲击是巨大的，如何测试基于这些新技术应运而生的软件产品和服务，以及如何把新技术应用到下一代的测试过程中，本书促进读者进行深度的思考。
该书从第1版到3版，跨越十年，与时俱进，不断融合先进测试技术，不断迭代和自我完善。透过这本书，我们感受到了当今高科技的发展对测试领域的冲击和变革，新技术层出不穷，势不可挡。未来几十年，5G会成为产业互联网的基础设施，物联网、人工智能将带来万亿规模的连接，“Software” 会进化为“Dataware”，软件定义世界真切发生在我们周围。在这样一个时代，企业会从产品的运营转向“客户的运营”，计算架构会从传统的PC转为云计算、边缘计算架构，新一代的软件体系会出现，每个人的生活方式、社会的运行方式都会随之深度改变， 只有掌握了软件的企业，才能理解和把握未来世界，紧跟时代浪潮。
田溯宁
哈佛商学院顾问，宽带资本董事长
本书以实际测试案例为背景，以项目实际运行的全过程为路线图，从软件测试的基本认知，到测试思维方式、框架、流程、优秀实践以及极具实用价值的DevOps工具链操作攻略，将读者带入一次灵感之旅，让我们看到多维度全新诠释下的创新测试模式是怎样解决挑战性测试工作问题的。对于那些想知道如何用新点子和创新的测试模式来解决复杂而快速变化的挑战性测试问题的人来说，这本力作的问世是重要而及时的。
《庄子知北游》有云，“人生天地间，若白驹之过隙，忽然而已”。从2007年《全程软件测试（第1版）》问世至今，一晃已有十余年载，而朱老师最初坚持的“软件测试是贯穿整个软件生命周期的活动”这个主题依旧有效，而“全过程的软件测试”不论是在传统的瀑布开发模式层面还是敏捷开发模式层面都是大家所极力提倡的。很难得也很幸运，一路走来，《全程软件测试》的三个版本对各种优秀的测试技术、测试实践、测试管理以及测试总结的深入思考，巧妙地将软件工程的理论佐证与用例实践系统化的贯穿在一起，在帮助我快速实现工作提升的同时，这也正指引着越来越多的创变者解决越来越棘手的测试问题。
软件测试是软件质量的基石，同时也直接影响软件是否能顺利交付。这几年，在移动互联、Web应用以及大数据应用等迅猛发展的时代背景下，软件开发模式及其管理环境也发生着翻天覆地的变化。而要做有质量的软件测试，就要不断探索如何才能将测试技术更好地与业界的测试技术与最新实践保持同步，与国际领先的测试技术和理念持续吻合。不可置否，《全程软件测试（第3版）》正是解决上述问题的必读之作。朱老师通过精湛的技巧与情感，编织了一幅“测试=已知的检测+未知的试验”的美丽画面，摒弃了行业中对软件测试纸上谈兵的夸夸其谈， 真正实现着软件测试的终极“四”性——正确性、完整性、安全性和质量性。
本书的概念关联性强，不论是具有改变思维的测试工程师们，还是具有创变思维的优秀组织，都可以通过阅读这些精彩的案例与洞见，打破测试思维传统，激发创新，动员员工积极性，更好地满足客户需求，同时提高自身技术实力，产生更大的影响。这本书值得一读，一定会为你带来深刻的体验。最后，再次祝贺朱老师又一全新力作面世！
程岩，京东物流研发负责人
翻阅少民的这部新作时，不禁让我想起歌德的《叙事谣曲》中“只弯一次腰”的故事：有一次，耶稣带着他的门徒彼得出门远行，在路上发现了一块破烂的马蹄铁，耶稣就让彼得拣起来，不料彼得懒得弯腰，假装没有听见。耶稣没说什么，自己弯腰拣起马蹄铁，用它在铁匠那里换了几文钱，并用这些钱买了十几颗樱桃。出了城，两人继续向前走，沿途都是茫茫的荒野，看不到人烟，也找不到水源。耶稣猜到彼得渴得厉害，就把藏在袖子里的樱桃悄悄掉出一颗。彼得一见，赶紧捡起来吃掉。耶稣边走边掉，彼得也就狼狈地弯了十七八次腰。于是耶稣对他说：“要是你刚才弯一次腰，就不会在后来没完没了地弯腰了。小事不干，就将在更多的小事上操劳。”
对于这个故事，不同的人有不同的感悟。多年来，作为一名软件行业从业者，我很自然就联想到了软件开发过程。软件测试（具体到每一个测试用例的实施）正是在庞大复杂的软件产品开发过程中做好多种“小事”，从而确保软件产品的质量。软件测试工作繁杂、琐碎又耗时，甚至有时吃力不讨好，这使得许多软件从业者对其不够重视，好多技术人员热衷于编码而不愿从事测试工作这样的“小事”。有些公司认为开发能出成果，而测试可有可无，因而非常重视开发但不重视测试。许多国内软件企业存在着漠视测试过程、测试时间不充分、测试计划不细致、测试软硬件资源不足等问题，从而在软件质量控制上存在相当大的问题，以致项目延迟甚至失败。
在软件行业几十年的发展中，软件测试已逐步渗透到各个领域，成为越来越不可或缺的技术环节。例如，以前被认为距离软件技术比较远的汽车行业，现在已把高级车制造费用的20%～25%投入到电子设备与软件系统上。由此看来，软件的品质已成为人们日益关注的重中之重。如何找到一种全面的分析方法，来检测软件开发过程中不同阶段的结果，以便尽可能早地与系统地保证或提高软件产品的质量和可靠性，从而减少后期“弯腰”的必要性与次数，已成为影响软件企业生产力与生产效率的关键问题。
可喜的是，越来越多的软件公司和管理技术人员在工作中将更多的时间和资源投入到了测试方面。很多优秀企业中开发与测试的人员比例达到了3:1或2:1，许多顶尖的技术人员在从事质量控制和软件测试工作。而国内这几年软件测试人员的短缺和招聘难度的提高也从另一个方面证明软件测试正越来越得到重视。
近年来，软件行业的发展正从产品模式向服务模式转变，并提出了“软件即服务”（Software as a Service，SaaS）的理念。在过去的多年中，WebEx公司一直处于这一浪潮的领导地位。WebEx提供的网络会议（Web Conference）服务被称为改变人们工作方式的技术革命。少民与他带领的团队非常自豪而荣幸地参与了WebEx产品开发的整个过程，在这个过程中他们夯实了软件测试的理论基础，并积累了丰富的实战经验。
少民从事高校教育及软件开发测试工作多年，并且在美国硅谷工作过两年，他非常重视理论与实践的结合。与少民共事过多年，了解他在软件测试领域的积累，从开始时采用简单、初级的测试方法，一步步发展到今天系统、科学的软件质量管理体系；从手工测试过渡到自动化测试；从几个人的测试小组转变为几百名测试工程师的大规模团队。现在，他将过去的经验教训做一番总结，以其亲身经历为业界同仁揭示软件测试的规律并介绍成功的实践经验。
本书是少民及其工作团队多年来的经验积累，其中一些观点与见解已经成为WebEx公司的基本工作准则，对软件研发领域有着重要的实质性贡献。本书通过实例全面描述了软件测试的整个过程，覆盖了测试管理的各个重要方面。对测试管理的各个层次和环节进行了系统的介绍，包括测试策略制订、风险控制、缺陷跟踪和分析、测试管理系统的应用等，并且更进一步对如何执行本地化测试和国际化测试进行了阐述。作者重点聚焦在实践性上，从软件测试项目启动、测试计划开始，深入到测试用例设计、测试工具选择、脚本开发，以及功能测试和系统测试等步骤，并对它们都做了详细阐述。
让人印象深刻的是本书对软件测试工作中几个看似简单但实际上非常关键的问题做了详细的说明。例如，关于开发团队模式，作者介绍了以开发为核心、以项目经理为核心，以及“三国鼎立”（以项目经理、开发组长、测试组长为核心）的模式。而“三国鼎立”的测试团队具有独立、权威性地位的概念也是作者工作经验的总结。相信读者会从实战中体会到作者的深刻用意。
在探索高效软件测试与软件开发的过程中，本书覆盖了全面的理论分析和详细的实战阐述，对任何从事软件测试的人员和软件开发人员以及软件工程相关专业的高校师生，都具有重要的参考价值。希望书中的这些真知灼见对广大读者有所裨益。
WebEx总部工程技术及中国研发高级总监
2007年春节后，我从美国返回国内，曾在美丽的西子湖畔与少民一叙，其间我们谈到了本书。我高兴地接受了少民的邀请——为本书写推荐序。我和少民共事近7年，结下了深厚的友谊。从2000年开始，我们就合作开发美国WebEx公司（纳斯达克上市公司，2007年5月被CISCO以32亿美元收购）互联网通信平台产品第一个基于PHP的网页。那时，我在美国领导着整个Web开发部门，他则在国内负责软件测试。再到后来，我们在产品研发、部署和服务运营等多个领域的合作不断深入。在我管理整个WebEx（中国）公司的这段时间里，他作为公司的质量管理总监直接向我汇报工作。当然，这也是我们合作最亲密的一段时间。
话说回来，在加盟WebEx公司之前，虽然少民已是一所重点大学的副研究员、硕士生导师，而且拥有良好的软件开发和项目管理经验，但那时国内软件测试还刚刚起步，他对软件测试也了解甚少，可以说是一个门外汉。
时光如梭，7年的时间一晃而过。同样拥有7年的时光，如果缺乏思考，收获就屈指可数；如果勤于钻研，就会硕果累累。而他不但勤于思考、善于思考，而且凭着智慧、毅力和坚实的计算机基础，很快就从一个门外汉成为软件测试领域的资深专家，他先后主编了软件工程领域的3本高等学校教材。在这7年里，他不断通过自学、努力和追求，帮助WebEx（中国）公司从零开始建立和发展软件测试团队，圆满地完成了全线产品的软件测试任务，并向全球的客户提供了高质量的软件产品和服务。目前，他领导着这支近300人的国内一流测试团队，正向下一个目标前进。
软件质量管理在软件研发团队中的作用是显而易见的。其中软件测试人员在保障和改进软件质量的工作中发挥着越来越大的作用。但是从整个软件工程周期来看，软件质量其实是在整个开发过程中形成的，或者说软件质量是构造出来的，而不是测出来的。程序代码完成之后，其质量水平就基本确定了，虽然可以通过测试发现大部分缺陷，但是程序代码中存在的缺陷越多，遗漏的缺陷就会越多，质量很难得到改善。如果缺陷发生在需求阶段或设计阶段，则将导致更高的成本和更大的风险。如果将软件测试贯穿于整个软件开发过程，从项目启动的第一天就开始将软件测试引入进来，情况就完全不一样了。贯穿于软件开发全过程的测试，不但可以在第一时间发现缺陷，而且能有效地预防缺陷的产生。缺陷的预防，可以大大减少软件缺陷的数量，提高软件质量。更有价值的是，它可以极大地缩短开发周期，降低软件开发的成本。
全过程的软件测试，赋予了软件测试更多的责任和内容。软件测试不再是事后检查，而是缺陷预防和检查的统一。在需求分析阶段，通过测试团队和开发团队的共同努力，尽可能把用户的需求全部挖掘出来，清除一切模糊的需求描述。在设计阶段，测试人员可以对不合理的设计提出质疑，督促开发人员在设计时充分考虑性能、可靠性和安全性等方面的要求，以确定每一个设计项的可测试性。在编程阶段，测试人员参与代码评审、单元测试等。所有这些都是为了告诉人们，测试过程可以看作保证质量的过程，测试不再是产品质量的一个检验环节。这也就是本书书名的由来，将软件测试扩展到保证软件质量的全过程中，作者赋予了软件测试新的含义和新的生命。
全程软件测试的另一层含义就是手把手地教会读者如何做测试，从头到尾，覆盖每一个环节。从项目启动——如何把握项目的背景和需求、如何选定测试组长等开始，逐渐深入测试计划、设计评审、用例设计、测试执行等过程，直至缺陷报告、测试结果分析和测试报告，每一过程都能得到细致的辅导。作者还用了不少笔墨来介绍如何选择测试工具、如何更有效地开展测试自动化的工作。因为测试自动化非常重要，它可以解放测试人员，使测试工作变得非常有趣。测试自动化能够提高测试效率，使测试人员有更多的时间思考，从而可以更好地分析测试范围和设计好测试用例，形成一个良性循环。
本书不仅阐述了先进、独特且成熟的软件测试思想和方法，还呈现了丰富多彩而又实实在在的测试技术和实践。测试的知识、概念是比较容易学习的，但要获得多年通过实践积累的心得和经验，是非常困难的。现在，这些内容就在你的眼前，唾手可得。本书能帮助你获得你所需要的东西，帮你解答心中的疑惑。本书给出的最佳实践不但代表着国内的先进水平，而且与美国硅谷的软件测试水平保持同步。它一定会帮助读者高效地、高质量地完成测试和软件质量保证任务。
最后，希望读者喜欢这本书，并从中受益。
沈剑（Joss Shen）
Dreamcast Systems公司创始人兼CEO
十年前，《全程软件测试》第1版和广大读者见面了，它是我在WebEx七年测试工作之结晶。这本书受到了读者的喜欢，甚至有好几家公司把这本书作为测试工程师的入职培训教材。十年过去了，软件测试领域发生了很大变化，我自己也发生了很大变化。我虽然离开了WebEx、Cisco，离开了在企业一线的测试工作，来到了同济大学教书，但我一直没有失去和工业界的联系，而且不再局限一家公司的实践，视野更开阔了。我和近百家公司的测试工程师都有交流，为他们提供测试培训、咨询等服务（包括为中国南车、华为2012实验室的研发能力中心等提供较长期的测试技术咨询服务）。今天，我对测试的理解和认识，相比自己写本书第一版、第二版时，在广度和深度方面都有了较大的提升。这也可以从我的公众号“软件质量报道”的几篇文章中略见一斑。
软件测试的一个新公式引起的思考
软件测试进入了一个新时代
究竟什么是软件测试架构？
看家本领系列：软件测试的系统性思维、分析性思维……
DevOps兴起意味着专职测试人员消亡？
安息吧，“全栈工程师”
你被“敏捷测试四象限”蒙蔽多少年了
这才是世界上最全的“软件测试”思维导图
《软件测试能力图谱》升级版
十年来，软件测试自身也发生了很大变化。在测试理论方面，业界提倡测试左移、测试右移（这和我十年前写本书的主要思想——“测试贯穿软件全生命周期”是一致的），DevOps也快速兴起，而且在实际工作中，我们看到专职测试人员开始融入研发之中，同时更多的开发人员开始做测试；人们更关注自动化测试和探索式测试，招聘更多的测试开发人员……
理论的发展和实践的创新固然可喜，但是在今天，软件测试仍然存在被引入“歧途”的风险。具体表现为：软件测试的定义日渐模糊，对软件测试的功能和职能的各种说法、看法莫衷一是。
例如，一些公司号称“赋予了软件测试团队新的价值和使命”，将软件测试部门改名为“工程生产力（Engineering Productivity，EP）”部门。作为EP，其职责是提高专业服务，给产品部门提供一些专业的建议（这些建议涵盖可靠性、安全、国际化、测试、发布、部署等）。EP更重要的职责是负责所有能够提高软件研发效率的工具的开发与维护。这些工具包括业务建模工具、源代码管理系统、代码分析工具、版本构建工具、自动化测试工具、质量管理工具、缺陷管理系统等。他们甚至强调，在策略上多开发有助于缺陷预防的工具，而不是仅开发传统的测试工具（发现缺陷的工具）。将工作重点放在“提升工程生产力、降低软件缺陷”之上，强调缺陷预防，从这个角度上讲，“成立EP部门”这种做法是一件好事，但EP部门做的事情已不是软件测试的主要工作，和测试工作已相差甚远，这时不能把EP看作软件测试，EP就是EP，不能将EP和软件测试混为一谈。就像我们有时候容易把测试称为质量保证（Quality Assurance，QA）、把QA当作测试，但实际上两者也有明显的区别。QA强调有好的研发过程产生好的产品，侧重过程定义、过程评审和过程改进，工作重心是预防缺陷；而测试属于质量控制，强调对软件阶段性产品和最终产品的质量检验，其工作重心是发现缺陷。虽然测试是QA的重要手段之一，但是不等同于QA。
即使测试左移、测试右移，敏捷开发模式、DevOps已经流行，我们讨论软件测试需要在这样背景展开——要将软件测试更好地融入整个软件开发和运维的大环境中，但我们依旧需要清楚软件测试本身要做的工作，区分质量管理、运维管理、研发能力提升等工作。在谈到“软件测试”时，人们说的是软件测试的相关工作，如单元测试、集成测试、系统测试等，也不局限于动态测试，也可以包括静态测试——需求评审、设计评审、代码评审和借助工具进行代码静态分析。如今谈软件测试，也不再专指测试人员所做的工作，而是指完全可以由开发人员所完成的测试工作。开发人员做测试，也不再局限于单元测试，他们可以做集成测试、系统测试等。
虽然不能说“一千个测试人员就有一千种说法”，但可以列出对软件测试的很多种不同定义：
软件测试是验证软件产品是否满足用户的需求；
软件测试不仅要验证设计和需求、实现和设计的一致性，还要确认所实现的功能是否真正满足用户的实际需求。
软件测试是为了发现软件缺陷而开展的活动；
软件测试就是不断揭示软件产品的质量风险；
软件测试就是对软件产品质量进行全面评估，提供产品质量信息。
十年弹指一挥间，软件行业和软件测试发生了这么多的变化，我个人也有了很多新的实践、经验和体会。基于此，我觉得非常有必要对《全程软件测试》一书的内容进行全面的更新和补充。恰逢第1版推出十周年之际，《全程软件测试（第3版）》得以与广大读者见面，这便是我对软件测试过去十年所发生的变化以及自身经历和经验的一次全新概括和总结。
正是基于上述的这些现象，本书一开始（本书的第一部分，第1章和第2章）就全面阐述对软件测试的不同理解，解析全程测试思想，力求揭示软件测试的内涵，以期帮助读者更好地理解不同的测试目标、测试价值，进而有利于做好软件测试的策划和执行。
本书的第二部分（第3章至第9章）讨论了完整的一个软件测试生命周期。这部分从测试项目的“准备”开始，侧重讨论测试基础设施与TA框架、团队能力等建设——这是后续测试计划、设计和执行的基础。在目前复杂的环境和技术、快速交付的背景下，我们必须首先关注基础设施，然后逐步深入到测试计划、设计、执行。其中，测试计划侧重讨论测试需求分析——往往被测试人员忽视，而实际上测试需求分析是测试设计的基础。这部分兼顾传统的测试和敏捷模式下的测试，的确不容易，但核心的东西一般都具有良好的生命力，是不容易被抛弃的，而且最好不要把“测试计划、设计、执行”看作不同的测试阶段，而是看作研发过程中要经历的、基本的测试活动。注意：本书重点讨论测试方法的灵活运用和实践，而不再赘述基本的测试设计方法（即人们通常提到的黑盒测试方法、白盒测试方法等），相关内容建议可以参考我写的测试教材——《软件测试方法和技术（第3版）》和《软件测试——基于问题驱动模式》。
全程测试思想，不仅局限于功能测试，还要扩展到非功能性测试（包括持续的性能测试与优化、持续的安全性测试与加固），并聚焦到彻底的自动化测试——全程测试建模、全程可视化管理。这就是本书的第三部分（第10章至第14章）所介绍的内容。
本书最后一部分内容（第15章）对软件测试的发展趋势加以展望——涉及当今软件测试面临的挑战，如微服务、云技术、AI技术及其应用等。囿于篇幅，这部分力图启发读者如何应对挑战、如何设计出云测试和AI测试的解决方案，让云计算技术、AI技术更好地为测试服务。
即使写了15章、几百页、几十万字，但我还是感觉许多东西还没写出来。如果慢慢写，可以写1000页、100-200万字。如果把具体的操作步骤都描述出来，再多给几个实例分析，每一章都可以写一本书。毕竟精力有限，我还是先把精髓展现出来，至于细枝末节，留给大家自学、自我拓展。IT人，最主要的能力就是学习能力——自学能力，所以对于工具如何使用这样的问题，答案就是“自己实践是最有效的”。专业的软件工程师使用工具不是一件难事，但改变自己的思想、思维方式倒是挺难的。归根结底，通过编写本书，我力求给大家呈现软件测试的思想、流程、方法、优秀实践以及自己的思考，剩下的事，就留给读者思考、实践、再思考、再实践吧。
首先感谢美国哈佛商学院顾问委员会委员、宽带资本基金董事长田溯宁老师在百忙之中为本书写序，把软件测试与当今时代的客户运营联系起来，进而提升到“只有掌握了软件的企业，才能理解和把握未来世界，紧跟时代浪潮”的高度。
其次，感谢为本书写推荐辞的诸位朋友，其中有些朋友还提了宝贵意见，他们是（排名不分先后，只是按拼音首字母列出）：
蔡立志 ISO/IEC中国专家代表，中国软件测试机构联盟技术委员会主任，上海计算机软件技术开发中心副主任
陈霁 上海霁晦信息科技有限公司CEO & VipTest联合创始人
程岩 京东物流研发负责人
陈晓鹏 埃森哲中国卓越测试中心负责人
陈振宇 南京大学教授、慕测平台创始人
耿晓倩（Christina Gen）Splunk旧金山总部测试总监
胡星 百度智能驾驶事业群主任研发架构师
孔德晋 华为终端Hicloud测试经理
李戈 北京大学副教授、CCF软件工程专委秘书长
李怀根 广发银行研发中心总经理
刘琛梅（梅子）绿盟科技防火墙研发经理、《软件测试架构师修炼之道》作者
刘江 美团点评技术学院院长、CCF技术前线委员会秘书长
刘琴 ISTQB中国首席代表、同济大学软件学院教授
刘冉 ThoughtWorks资深软件质量咨询师
廖志 腾讯质量管理通道委员、CSIG地图产品质量中心总监
Phyllis Chang Senior Manager, Webex Engineering，Cisco HQ
茹炳晟 Dell EMC 测试架构师
王斌 Testin云测解决方案事业部副总
王冬 360测试总监
王金波 中国科学院空间软件评测中心、主任/研究员
熊志男 京东高级测试开发工程师、“测试窝”社区联合创始人
许永会 知名通信企业资深测试专家
杨春晖 工信部第五研究所软件中心主任、中国赛宝实验室软件评测中心主任
杨凯球 中兴通讯公司测试经理
杨晓慧 前华为测试专家、现AI机器时代CTO
杨忠琪 东方证券测试负责人
于洪奎 中国银行软件中心高级经理
钟思德 灼识咨询顾问、知名通信公司高级测试经理
周震漪 CSTQB 常务副理事长、TMMi中国分会副理事长
朱波 香港航空有限公司IT经理
再者，感谢人民邮电出版社编辑们的辛勤工作，特别是陈冀康、吴晋瑜等编辑大力支持和愉快的合作，使本书以良好的状态与读者见面。最后，感谢家人的全力支持，使我能够全心致力于本书的写作，能够和读者有一次更深、更流畅的思想和技术交流。
谢谢你们！
朱少民（Test Ninja）
于乙未仲夏之夜
“人生天地之间，若白驹之过隙，忽然而已”，这样开头虽然比较俗，但它的确反映我的真实感受。2007年本书第1版和读者见面了，一晃六年了。欣慰的是，本书深受读者喜欢，在当当网有非常多的评论，总评是五颗星，在京东网也得到五星级的好评，甚至有些公司把这本书作为新员工的培训教材，有些公司的测试工程师人手一本。但随着时间的推移，越来越感觉这本书需要修改，但似乎“笔头懒”，迟迟没有动手修改本书，出版社编辑常常催促，我似乎不为所动，但终究拗不过编辑，趁着节日终于完成其修改，使本书第2版能够与读者见面。
六年来，笔者经常参加一些软件技术大会，和测试同仁有很多交流，阅读了不少测试类图书，也经常上网浏览国外测试大师的博客，自己对软件测试有了更深的理解。每当浏览本书第1版时，总觉得其中太多内容需要修改，本书可能会被改得面目全非，但大幅修改需要很多时间，甚至不如重新写一本书，这也就是迟迟没有修改本书的潜在原因之一。客观地讲，也不能翻天覆地地大改，应该保持其基本面貌，否则就不是本书的第2版了。
幸好，当初本书写作时就认定“软件测试是贯穿整个软件生命周期的活动”，这个观点在今天依旧有效。即使在敏捷开发模式下，“全过程的软件测试”也是大家全力提倡的，可以说本书的主题和敏捷测试不谋而合（虽然在局部或某些具体的实践上有冲突）。本书所介绍的许多实践来自美国硅谷，跟随时代的技术潮流，并且具有很好的普适性，即使若干年后，这些实践中的大部分内容在今天依旧有很好的借鉴作用。
在这次修改中，为了保持本书的风格和一致性，全书结构没有进行大的改动，还是原来的12章，从引子、项目启动到最后的思考与总结，但有几个小节做了较大调整，使全书结构更合理，同时融入了一些敏捷测试实践，包括持续测试、验收测试驱动开发、探索式测试等内容，以适应目前业界的环境。第2版的主要修改如下。
引子中增加了两小节内容，即“究竟什么是敏捷测试？”“敏捷测试过程”，以达到更好的铺垫效果。
把第2章中的“团队组建”“培训”两小节移到了第1章中，删除了“测试组长的人选”这一小节，1.2节比较彻底地讨论了测试团队相关的问题。
将“产品需求评审”移到了第3章，第2章补充了测试需求分析的内容，包括质量要求和测试目标、测试需求的分析方法和技术。测试需求分析不仅是测试设计的基础，也是制订测试计划的基础，第2章命名为“测试需求分析与计划”，就更加自然。先进行测试需求分析，再逐步完成测试计划所要进行的工作，包括测试风险分析、工作量估算。
第3章的重点放在需求和设计的评审上，完整地介绍了“静态测试”。而且，在这一章增加了“需求的可测试性”和“设计的可测试性”两小节，使需求评审和设计评审更具价值，也为将来的测试设计和执行打下了更坚实的基础。
第4章不仅增加了“探索式测试之设计”，顺带介绍了基于会话的测试管理（SBTM），而且重新组织了黑盒测试的具体方法，让读者更有效地运用测试方法，如将等价类划分方法和边界值分析法结合在一起来应用。pair-wise方法使用起来方便，所以也添加进来了。
第5章进行了简化，把具体工具的介绍和对比删除了。因为工具的变化很快，所以尽量删减工具的一般介绍性内容。同时，增加了自动化测试策略，包括整体策略和功能测试自动化策略。
第7章增加了“敏捷测试的执行”一节，该节包含两个小节：“策略与实践”和“探索式测试的执行”。第1章已讨论了“培训”，该章删除了原来的“培训和知识传递”，并简化了测试环境爆炸性组合的优化方法。
第9章的章名改为“系统非功能性测试”，所以原来“安装测试”一节的内容整改为“部署测试”，移到第10章中。删除原9.1节讨论的非功能性测试内容，部分内容和第2章、第3章进行了合并。
第10章删除了“文档测试”一节，少量有价值内容并入“验收测试”一节中，而且增加了敏捷流程的“验收测试”，以和传统的“验收测试”加以区分。最后，把α测试和β测试整合为在线测试。
将第12章中的一节移到第11章中，整合为“测试自动化的管理准则”，第11章对测试自动化的框架做了较大修改，更准确地定义了自动化测试框架的概念。对“软件缺陷清除率”“测试管理思想和策略”两小节也做了较多修改，测试用例的管理也从原来的三小节整合为两小节。
第12章的改动也比较大，测试原则由原来的10条增加到12条，而改动更大的两节是“软件测试之辩证统一” “持续改进”。同时增加了“基于脚本测试和探索式测试”“TMMi和TPI Next分析”，而且对相应的内容做了删减。另外“软件测试的多维空间”“软件测试的优秀实践”两节也有一些修改。
附录删除了“完整的项目检查表”和“完整的测试工具列表”，因为前者和测试关系不是十分密切，而删除后者则是因为在第5章已将主要的测试工具做了介绍，有那么多工具已足够读者使用了。如果还需要其他工具，可以借助网络搜索引擎来查找。而增加了“用例设计模板”“缺陷报告模板”“测试相关的国家标准”三个附录，“软件测试计划模板”也换了最新的国家标准定义的模板。
第6章、第8章没有大的改动，只进行了少量文字修改。
看起来，第2版做了比较大的改动，但自己也不是十分满意，可能是第1版的基础还不够扎实，总觉得有些内容还可以不断改下去，但时间又不允许。另外，在敏捷时代追求完美也是不合情理的，虽然不能做到持续交付、快速交付，但缩短迭代时间还是可以的，如1～2年本书出一个版本还是可以的，也是比较好的。
希望经过修改后，本书更能满足当今软件测试的知识传递和技能培养的需求，可以给读者带来更多的收益，更希望读者不吝赐教，我将继续努力提升本书，继续更好、更多地为测试人服务。
朱少民
2013年国庆节于上海
2000年刚建立测试团队时，测试人员和开发人员是一种对立的关系，开发人员觉得软件测试是在挑他们的毛病，和他们过不去。有一个简单的故事可以说明这一点。当时，条件有限，测试人员和开发人员共享一台小型机服务器，测试人员发现了一个缺陷，告诉了某个开发人员，而他趁测试人员不注意，回到自己的座位上偷偷地修改了代码，处理了那个缺陷，然后跑到测试人员身边说：“你把那个bug再现给我看看？”结果，可想而知，这个测试人员无论如何也不能复现那个bug了。
几年以后，这种情况不再出现了，不是因为条件好了，可以买很多服务器，将测试环境和开发环境分离开来，而是观念改变了。虽然的确购买了几百台服务器（不用小型机，越来越多的服务器采用Linux系统），将测试环境和开发环境分离开了，在客观上可以避免那类“悲剧”的发生，但是观念远比机器重要。拥有正确的观念，就比较容易营造良好的质量文化，开发人员的态度也随之发生变化，他们在以下方面有了更深刻的认识。
软件测试是在帮助开发人员，测试人员是在找产品定义、设计和实现的bug，不是找缺陷。
测试人员越快地发现bug，项目越能尽早结束。
测试人员尽可能多地发现bug，遗留在产品中的bug就会越少，产品的质量就会越高。
测试人员和开发人员的工作都旨在实现一个相同的目标——按时、高质量地发布产品。
开发人员的水平越高，所写程序中的bug就越少，而不在于他使用了别人不知道的技巧。
现在，有的开发人员向我抱怨道：是不是换了一个新人测试他写的模块？因为这次发现的bug比前一次发现的少多了。开发人员希望更多的bug被测试人员发现，绝不希望bug留待客户去发现。
今天，我们高兴地看到开发人员和测试人员心往一处想。从项目启动的第一天起到需求和设计的评审阶段，从后期的bug修正到产品维护——在整个软件生命周期中，开发人员和测试人员愉快地合作、共同努力，将软件产品的开发效率和质量提升到一个新的高度。一方面，开发人员主动介绍自己对产品特性是如何理解的，又是如何实现这些特性的，他们主动邀请测试人员参与代码的走查并对新发现的bug快速响应。另一方面，测试人员提前将设计好的一些测试用例交给开发人员，让开发人员先根据这些测试用例验证正在开发的功能特性，测试人员还愉快地帮助开发人员再现某个bug。
从所有这些变化中，都可以看出软件测试在国内越来越受重视，软件测试领域正迎来朝气蓬勃的新气象。当更多的人投入到测试行业时，他们需要一本实践性强、富有启发性的专业书，来指导他们进行测试，出色地完成测试任务。本书就承担了这样一个任务，它会从项目启动开始，一步一步地介绍如何做好测试工作，包括建立测试组、计划测试、设计测试用例、选择测试工具、开发测试脚本、执行测试和编写测试报告等。书中涵盖了我多年来积累的软件测试经验与技术实践，以及深刻的体会。
为了写这本书，我事先也做了一些尝试，尽量收集软件测试人员对软件测试需求的反馈，并在CSDN的个人博客上演义了30回的软件测试，受到了大家的好评。也许就因为这个，在CSDN上建立博客不到8个月，我的博客就成为2006年十大最具价值的博客之一。
此前，我曾写过一本名为《软件测试方法和技术》的教材，这本教材在比较短的时间内重印了好几次，也颇受欢迎。但那本书在很大程度上是从理论、概念上讲解软件测试的方法和技术的，适合在校学生使用。而这本书重实践、重应用，适合软件公司的测试经理、工程师和想进入软件测试行业的人员学习。
全书共12章，以两个案例为背景，以项目向前发展的实际过程为路线图，全面展示了软件测试的思想、流程、方法、技术和最佳实践。全书力求做到方法有效、技术实用，集中讲解了实际的测试工作，没有单纯地介绍概念，而是将概念穿插在测试流程中。
第1章介绍测试项目启动后要做好哪些准备，如何掌控项目背景和要素，为制订测试计划打下坚实的基础。
第2章重点介绍测试计划，主要讨论测试人员在需求评审中的作用。
第3章从系统架构的审查开始，深入讨论了系统组件设计、设计规格说明书、界面设计和系统部署设计等一系列的审查。
第4章围绕测试设计展开讨论，首先从测试用例框架的设计入手，然后逐步介绍测试用例的构成、设计方法、评审、功能测试用例和系统测试用例的设计。
第5章着重介绍测试工具的选择和脚本的开发。
第6章展示测试和编程的交互过程。
第7章开始进入功能测试的执行阶段，并着重介绍自动化功能测试的执行。
第8章介绍如何进行国际化测试和本地化测试。
第9章的重点内容是如何执行系统测试。
第10章介绍验收测试、文档测试、α测试和β测试、产品后继版本的测试。
第11章介绍测试管理的思想和系统、测试用例的管理、测试自动化的管理、缺陷跟踪和分析、测试进度和风险的控制、测试覆盖度和结果分析等。
第12章是对测试的总结和思考。
本书最后附有软件测试全景图、完整的项目检查表、软件测试计划通用模板、完整的测试工具列表和代码审查的示范性列表等资料。
由于水平和时间的限制，书中难免会出现错误，欢迎读者及业界同仁不吝指正。
朱少民
2007年
“什么是软件测试？”这个看似简单的一个问题，其实也是最难的问题。说它简单，是因为这是一个基本的问题，做软件测试工作多年的小伙伴，自然知道什么是软件测试。说它难，是因为“软件测试”有很多内涵，要了解其全部内涵，并非那么容易。如果我们去问软件研发人员什么是软件测试，得到的答案可能五花八门，人们对软件测试有不同的理解。现在最常见的理解就是：
软件测试就是找bug、发现缺陷。
但也有人会认为软件测试就是：
检查软件产品是否符合设计要求；
验证软件产品需求、设计和实现的一致性；
确认软件产品是否满足用户的实际需求；
对软件产品质量的全面评估；
提供软件产品质量信息；
揭示软件产品的质量风险；
投入较低的保障性成本极大地降低劣质成本；
验证与确认（Verification&Validation，V&V）；
调查、分析和比较；
不断探索；
……
有太多的理解，而且都没有错，只是看问题的角度不一样。虽然回答问题时，也容易脱口而出，不会仔细斟酌，只看到软件测试的一面，没有系统地分析“什么是软件测试”。
下面我们就好好讨论“什么是软件测试”，因为有什么理解就有什么行动。有正确的理解，就有正确的操作；相反，有错误的理解，就有错误的操作。所以，先帮助读者对“软件测试”建立正确、全面的认识，构建起一个完整的“软件测试”轮廓，不至于陷入“盲人摸象”的困境，对软件测试有片面的理解。然后，我们再展开流程、方法、技术和实践的讨论。也就是在全面讨论“全程软件测试”之前，咱们需要找到共同语言，即对软件测试的一些基本概念达成共识，为后面的沟通扫除障碍。
什么是软件测试？人们常常回答：软件测试就是发现软件产品中的bug（缺陷）。也有人说，不对，软件测试是验证软件产品特性是否满足用户的需求。实际上，上述回答都没错，是对软件测试的正反两个方面的解释。
早期，人们更多的是将“测试”看作是对产品的“检验”，检查软件的每个功能是否运行正常。正如1983年Bill Hetzel将软件测试定义为：“软件测试就是一系列活动，这些活动是为了评估一个程序或软件系统的特性或能力，并确定其是否达到了预期结果。”从这个定义中，至少我们可以看到以下两点。
测试试图验证软件是“工作的”，也就是验证软件功能执行的正确性。
测试的活动是以人们的“设想”或“预期的结果”为依据。这里的“设想”或“预期的结果”是指需求定义、软件设计的结果。
但同时我们知道，软件测试有一条原则：测试是不能穷尽的。测试会面对大量的测试数据、测试场景或代码路径等，测试也只是一个样本实验，不能证明软件是正确的，只能说明发现的缺陷的确是缺陷。但如果没有发现问题，并不能说明问题就不存在，而是至今未发现软件中所潜在的问题。正如《软件测试的艺术》一书作者Glenford J. Myers所说，测试不应该着眼于验证软件是工作的，相反，应该用逆向思维去发现尽可能多的错误。他认为，从心理学的角度看，如果将 “验证软件是工作的”作为测试的目的，非常不利于测试人员发现软件的错误。因此，1979年他给出了软件测试的不同的定义：“测试是为了发现错误而执行一个程序或者系统的过程。”从这个定义可以看出，假定软件总是存在缺陷的（事实上也是如此）、有错误的，测试就是为了发现缺陷，而不是证明程序无错误。
从这个定义延伸出去，一个成功的测试是发现了软件问题的测试，否则测试就没有价值。这就如同一个病人（因为是病人，假定确实有病），到医院去做相应的检查，结果没有发现问题，那说明这次体检是失败的，浪费了病人的时间和金钱。以逆向思维方式引导人们证明软件是“不工作的”，会促进我们不断思考开发人员对需求理解的误区、不良的习惯、程序代码的边界、无效数据的输入等，找到系统的薄弱环节或识别出系统复杂的区域，目标就是发现系统中各种各样的问题。
人类的活动具有高度的目的性，建立适当的目标具有显著的心理作用。如果测试目的是为了证明程序里面没有错误，潜意识里就可能不自觉地朝这个方向去做。在进行测试的过程中，就不会刻意选择一些尽量使程序出错的测试数据，而选择一些常用的数据，测试容易通过，而不容易发现问题。如果测试的目的是要证明程序中有错，那我们会设法选择一些易于发现程序错误的测试数据，这样，更早、更快地发现缺陷。毕竟开发人员力求构造软件，以正向思维方式为主，所以逆向思维方式可以提升我们的测试效率。
逆向思维也有不利的一面，容易陷于局部的深度测试，缺乏广度。因为觉得某个地方有缺陷，就对这个地方进行测试，然后不断深入下去，这样容易忽视一些区域。虽然那些地方产生的缺陷不多，但如果产生了严重缺陷，也是我们不能承受的。所以正向思维也是有价值的，它会督促针对软件系统的所有功能点，逐个验证其正确性，哪个功能越重要越要进行检验。正向思维会让我们的测试更有广度——良好的测试覆盖面。
为了做好测试，既要有深度，又要有广度；既要有效率，又要有测试工作自身完整的质量。所以，我们应该将正向思维和逆向思维有机地结合起来，做到效率和质量的平衡。换句话说，当我们需要效率时，更多采用逆向思维，当我们需要测试广度来确保完整的测试质量时，则多采用正向思维。这种平衡还体现在不同的应用领域，例如国防、航天、银行等关键性软件系统，承受不了系统的任何一次失效。因为这些失效完全有可能导致灾难性的事件，所以强调验证（verify），以保证非常高的软件质量。而一般的商业应用软件或服务，质量目标设置在“用户可接受水平”，以降低软件开发成本，加快软件发布速度，有利于市场的扩张，则可以强调逆向思维，尽快找出大部分缺陷。
前面提到Glenford J. Myers，他早期给软件测试的简单定义是：“程序测试是为了发现错误而执行程序的过程”，也体现出当时对软件测试的认识非常具有局限性。这也是受软件开发瀑布模型的影响，认为软件测试是编程之后的一个阶段。只有等待代码开发出来之后，通过执行程序，像用户那样操作软件发现问题，这就是“动态测试”。
对于需求阶段产生的缺陷，在不同阶段发现和修复的成本是不一样的。如果在需求阶段发现需求方面的缺陷并进行修复，只要修改需求文档，其成本很低。需求阶段产生的缺陷，如果在需求阶段没有发现，等待设计完成之后才被发现，就需要修改需求和设计，成本增大。需求阶段产生的缺陷，如果在需求和设计阶段都没有发现，等待代码写完之后才被发现，就需要修改需求、设计、代码，成本就更大。设计上的问题，在设计阶段被发现，只要修改设计，如果在后期发现，返工的路径就变长了，其修复的成本自然就增大。缺陷发现得越迟，其修复的成本就越高，如图1-1所示，呈现了不同阶段产生的缺陷在不同阶段修复的成本，所以这要求我们尽早发现缺陷。
图1-1 不同阶段产生的缺陷在不同阶段修复的成本
为了尽早发现缺陷，我们有必要将软件测试延伸到需求、设计阶段，即对软件产品的阶段性成果——需求定义文档、设计技术文档进行评审或验证。这不同于软件质量保证（Quality Assurance，QA），虽然QA侧重评审，但它重点评审流程、评审管理，包括对需求、设计、编码和测试过程规范性的评审。而这里提到的需求和设计的评审依旧是对软件产品的检验或验证，只是需求文档和设计文档只是软件产品的阶段性产品。如果按照“软件=程序+文档+数据结构”这样的定义，需求文档和设计文档等也属于软件的组成部分，软件测试自然也包括需求和设计的验证。
基于上述考虑，将早期的动态测试延伸到静态测试，即从狭义的软件测试发展到广义的软件测试。
狭义的软件测试：动态测试——运行程序而进行的测试，测试只是编程之后的阶段，这也是由传统的瀑布模型而决定的。
广义的软件测试：动态测试+静态测试，将需求评审、设计评审、代码评审（含代码的静态分析）等也纳入软件测试工作之中。这也使“软件测试”不再停留在编程之后的某个阶段上，而成为贯穿整个软件研发周期的质量保证活动，这也是本书“全程软件测试”的最早立意所在。
静态测试就是在不运行软件系统时对软件或阶段性成果进行评审，包括需求评审、设计评审、代码评审等。引入静态测试，就可以尽早地发现问题，把问题消灭在萌芽之中，将每个阶段产生的缺陷及时清除，极大地提高产品的质量，有效地降低企业的成本。
软件测试虽然不能等同于软件质量保证（SQA），但它是软件质量保证的主要手段之一。当我们讨论软件测试时，绝对离不开“质量”。基于质量的认识，软件测试就是对软件产品的质量评估，提高软件产品有关的质量信息。即使从1.1节中我们认为软件测试就是发现软件产品中的bug（缺陷），哪什么是“缺陷”呢？简单地说，缺陷就是质量的对立面，一切违背质量的问题都可以看作软件缺陷（虽然从专业术语来仔细辨析的话，会将问题分为“内在错误，外部失效”等）。所以要理解软件测试，就必须理解软件质量。
说起“质量”这个概念，我们都很熟悉，会说“坏的质量会怎样怎样，好的质量会怎样怎样”，但让我们给出质量的正式定义，可能不是容易的事情。我们也可以查国际标准，了解如何给质量下定义。例如IEEE Std 829-2008定义质量就是系统、组件或过程满足特定需求的程度，满足客户/用户需求或期望的程度。满足程度越高，质量就越好。例如，从软件需求定义文档来看，它所描述的需求和客户实际业务需求越吻合，将来实现的软件越有可能满足客户的业务需求，也意味着需求文档的质量越高。但这样说，还是比较宽泛，很难衡量质量。那究竟如何评估质量？从哪些维度来衡量质量呢？这就引出质量模型。基于质量模型，我们可以清楚质量有哪些属性（或维度），然后针对这些属性逐个地进行评估，不需要对软件质量进行整体评估，相当于按质量的各个维度来进行评估、各个击破。
过去将软件质量分为内部质量、外部质量和使用质量，像代码的规范性、复杂度、耦合性等可以看作是内部质量，内部质量和外部质量共用一个质量模型。现在国际/国家标准将内部质量和外部质量合并为产品质量。产品质量可以认为是软件系统自身固有的内在特征和外部表现，而使用质量是从客户或用户使用的角度去感知到的质量。因为质量是相对客户而存在，没有客户就没有质量，质量是客户的满意度。过去认为，内部质量影响外部质量、外部质量影响使用质量，而使用质量依赖外部质量、外部质量依赖内部质量。今天可以理解为产品质量影响使用质量，而使用质量依赖产品质量。
根据国际标准IEEE 24765-2010，产品质量是指在特定的使用条件下产品满足明示的和隐含的需求所明确具备能力的全部固有特性。而根据ISO 25010:2011标准，质量模型从原来的6个特性增加到8个特性，新增加了“安全性、兼容性”。如图1-2所示，蓝色标注的内容属于新增加或改动的内容。这里的安全性是指信息安全性（Security），原来放在“功能性”下面，但现在绝大部分产品都是网络产品，安全性越来越重要，所以有必要作为单独的一个维度来度量。今天系统互联互通已经很普遍，其次终端设备越来越多，除了传统的PC机，还有许多智能移动设备，如手机、平板电脑、智能手环、智能手表等，这些都要求系统具有良好的兼容性。这些特性就对应着测试类型，如功能测试、性能测试（效率）、兼容性测试、安全性测试等。
图1-2 ISO 25010 2016 产品质量模型
功能适应性（functional suitability）：软件所实现的功能达到其设计规范和满足用户需求的程度，强调正确性、完备性、适合性等。
效率（efficiency）：在指定条件下，软件对操作所表现出的时间特性（如响应速度）以及实现某种功能有效利用计算机资源（包括内存大小、CPU占用时间等）的程度，局部资源占用高通常是性能瓶颈存在；系统可承受的并发用户数、连接数量等，需要考虑系统的可伸缩性。
兼容性（compatibility），涉及共存和互操作性，共存要求软件能给与系统平台、子系统、第三方软件等兼容，同时针对国际化和本地化进行合适的处理。 互操作性要求系统功能之间的有效对接，涉及API和文件格式等。
易用性（usability）：对于一个软件，用户学习、操作、准备输入和理解输出所做努力的程度，如安装简单方便、容易使用、界面友好，并能适用于不同特点的用户，包括对残疾人、有缺陷的人能提供产品使用的有效途径或手段（即可达性）。
可靠性（reliability）：在规定的时间和条件下，软件所能维持其正常的功能操作、性能水平的程度／概率，如成熟性越高，可靠性就越高；用平均失效前时间（Mean Time To Failure，MTTF）或平均故障间隔时间（Mean Time Between Failures，MTBF）来衡量可靠性。
安全性（security）：要求其数据传输和存储等方面能确保其安全，包括对用户身份的认证、对数据进行加密和完整性校验，所有关键性的操作都有记录（log），能够审查不同用户角色所做的操作。它涉及保密性、完整性、不可抗抵赖性、可审核性、真实性。
可维护性（maintainability）：当一个软件投入运行应用后，需求发生变化、环境改变或软件发生错误时，进行相应修改所做努力的程度。它涉及模块化、可复用性、易分析性、易修改性、易测试性等
可移植性（portability）：软件从一个计算机系统或环境移植到另一个系统或环境的容易程度，或者是一个系统和外部条件共同工作的容易程度。它涉及适应性、可安装性、可替换性。
从ISO/IEC 25010标准看，软件测试还要关注使用质量，如图1-3所示。在使用质量中，不仅包含基本的功能和非功能特性，如功能（有效与有用）、效率（性能）、安全性等，还要求用户在使用软件产品过程中获得愉悦，对产品信任，产品也不应该给用户带来经济、健康和环境等风险，并能处理好业务的上下文关系，覆盖完整的业务领域。
图1-3 使用质量的属性描述
为了便于理解使用质量，下面举3个例子。
【例1-1】我自己亲身经历的例子。我在手机上安装了一个英语学习软件，自动下载该款软件用到的多个语音库（如新概念英语、六级英语等），它在我讲课时，但并没有判断我手机连接的是Wi-Fi还是3G/4G，造成我的流量大大超过套餐额度，产生了额外的300元流量费。从功能上看，自动下载是一个不错的功能，但有很大的经济风险，在使用质量上有明显缺陷。
【例1-2】当我们玩游戏，沉醉于某款游戏，从产品本身质量属性看。是一个好产品，没有问题。但从使用质量看，会有损于玩家的健康，有健康风险，所以需要设置防沉迷功能。
【例1-3】当我们使用百度地图、滴滴打车等软件时，往往是在大街上。如果站在人行道或安全地方使用没问题，但是如果一面横穿马路一面还在使用，就有安全风险。这类软件应该给予提示，否则它们要承担相应的风险责任。
因为没有办法证明软件是正确的，软件测试本身总是具有一定的风险性，所以软件测试被认为是对软件系统中潜在的各种风险进行评估的活动。从风险的观点看，软件测试就是对软件产品质量风险的不断评估，引导软件开发工作，进而将最终发布的软件所存在的风险降到最低。基于风险的软件测试认知主要体现在两点上：
软件测试不仅仅停留在单个缺陷上，要从所发现的问题看到（分析出）某类质量风险或某个具有潜在风险的区域。
软件测试被看作是一个动态的质量监控过程，对软件开发全过程进行检测，随时发现不健康的征兆，及时评估新的风险，设置新的监控基准，不断地持续下去。
基于风险对测试的认知，会强调测试的持续性，持续地进行测试，写几行代码就要做测试、实现一个功能就要对这个功能进行测试，开发和测试相伴而行。这种认知特别适合敏捷开发模式下的测试——敏捷测试。在敏捷开发中，软件测试就能被解释为对软件产品质量的持续评估。在敏捷方法中，不仅提倡持续集成，而且提倡持续测试，持续集成实际上也是为了持续测试。
基于风险对测试的认知还不断提醒我们：在尽力做好测试工作的前提下，工作有所侧重，在风险和开发周期限制上获得平衡。首先评估测试的风险，每个功能出问题的概率有多大？根据Pareto原则（也叫80/20原则），哪些功能是用户最常用的20％功能？如果某个功能有问题，其对用户的影响又有多大？然后根据风险大小确定测试的优先级。优先级高的功能特性，测试优先得到执行。一般来讲，针对用户最常用的20％功能（优先级高）的测试会得到完全地、充分地执行，而低优先级功能的测试（另外用户不常用的80％功能）就可能由于时间或经费的限制，测试的要求降低、减少测试工作量。
软件不同于硬件，软件一般都是应用系统，常常和人们的娱乐、事务处理、商业活动、社区交流等紧密联系在一起，所以软件具有很强的社会性，所以有必要把心理学、人类学和社会学等引入到软件测试中。软件测试不仅仅是技术活动，而且是社会、心理等综合性活动，软件测试是跨学科的（inter-disciplinary）活动，以系统为焦点（systems-focused），通过不断调查（investigative）和讲故事（storytelling）的方式完成软件质量的评估。
通过软件测试的社会性认知，强调测试人员的思维能力和探索能力，强调测试的有效性和可靠性，在测试中要理解用户的行为、人们活动的背景和目的（上下文关系），不断观察，不断学习，发现和质量相关的信息（差异或质疑），从客户利益、业务特性出发来守护产品的价值。
也正是由于软件测试的社会性，需要对软件产品的易用性、免于风险的程度、上下文覆盖等进行验证。在易用性测试中，人们常常进行A/B测试，给出不同的解决方案（UI布局、功能设计等），向不同的用户群发布产品，来检测哪个解决方案更受用户喜欢。
一般来说，一个软件产品没有经过测试是不会发布（release）、不会部署(deploy)到产品线上，或者说，不敢发布、不敢上线。因为在当前的开发模式和开发技术情况下，人们开发的软件存在严重的缺陷绝对是大概率事件。如果没有经过测试，就发布出去，可能软件根本不能用、不好用，或者用起来出现各种各样的问题，用户满意度很低，给产品造成负面影响，甚至给客户带来严重的经济损失或影响到用户的生命安全。
从经济观点看，软件缺陷会给企业带来成本，这个成本就叫劣质成本（Cost of Poor Quality，COPQ）。基于经济的认知，软件测试就是通过投入较低的保障性成本来降低劣质成本，帮助企业获得利润。高质量不仅是有竞争力，而且是带来良好的经济收益的。例如苹果手机就是以其高质量获得比其他品牌手机更高的利润率。据相关媒体统计数据看，苹果智能手机在高端手机市场只占四分之一，但利润占到一半。
测试的经济观点就是如何以最小的代价获得更高的收益，这也要求软件测试尽早开展工作，发现缺陷越早，返工的工作量就越小，所造成的损失就越小。所以，从经济观点出发，测试不能在软件代码写完之后才开始，而是从项目启动的第一天起，测试人员就参与进去，尽快尽早地发现更多的缺陷，并督促和帮助开发人员修正缺陷。
软件测试被视为“验证（Verification）”和“有效性确认（Validation）”这两类活动构成的整体，缺一不可。如果只做到其中一项，测试是不完整的。
“验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。验证过程提供证据表明软件相关产品与所有生命周期活动的要求相一致，即验证软件实现（即交付给客户的产品）是否达到了软件需求定义和设计目标。
“有效性确认”是确认所开发的软件是否满足用户实际需求的活动。因为软件需求定义和设计可能就不对，上述一致性不能保证软件产品符合客户的实际需求，而且客户的需求也是在变化的，当需求定义是半年前确定的，这种变化的可能性就比较大。
对验证和确认有不同的解释。简单地说，单元测试、集成测试和系统测试都可以理解为“验证”，都是基于需求定义文档和设计规格说明书文档来进行验证；而验收测试则在用户现场、由用户共同参与进行，可以理解为“有效性确认”，因为之前的需求定义和设计都可能存在错误，研发团队没有正确理解用户的原意（用户的真实期望），仅仅根据需求定义文档和设计规格说明书文档来完成测试，并不能代表所实现的功能特性是用户真正想要的。而在验收测试中，用户参与进来，是可以确认所实现的功能特性是否是用户真正想要的。
另一种解释是根据图1-4所示的V模型，验证是架构设计评审、详细设计评审和代码评审/单元测试，分别验证架构设计是否和需求一致、详细设计是否和架构设计一致、代码是否和详细设计一致，用左边带箭头的粗虚线表示。而有效性确认则是集成测试、系统测试、验收测试，如中间带箭头的细虚线表示。
图1-4 软件研发的V模型
概念
单元测试是对软件基本组成单元进行的测试，其测试对象是软件设计的最小单位——模块或组件，也可以包括类或函数。软件单元具有独立性，可以将它与系统/程序的其他部分隔离出来，从而完成测试。单元测试也是软件测试过程中最早期的测试活动，是软件的基础测试。
集成测试是将已分别通过测试的单元按设计要求组合起来再进行的测试，以检查这些单元之间的接口是否存在问题。集成测试一般是一个逐渐加入单元进行测试的持续过程，直至所有单元被组合在一起，成功地构成完整的软件系统，从而完成集成测试的使命。
系统测试是充分运行或模拟运行软件系统，以验证系统是否满足产品的质量需求。系统测试包含系统功能测试和系统非功能性测试，系统非功能性测试主要是指系统性能测试、容量测试、安全性测试、兼容性测试和可靠性测试等。系统功能测试和非功能性测试可以并行实施，但一般在基本功能已能正常运行后，才进行系统性能测试、兼容性测试、可靠性测试等。
验收测试是在软件产品完成了系统测试之后、产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。验收测试一般会根据产品规格说明书或用户故事等各种需求定义，严格地、逐项检查产品，确保所开发的软件产品符合用户预期的各项要求，即验收测试是检验产品和产品规格说明书（包括软件开发的技术合同）的一致性，同时考虑用户的实际使用环境、数据和习惯等。验收测试的重要特征就是用户参与，或用户代表（如产品经理、Product Owner）参与。
回归测试是由于软件修改或变更，对修改后的工作版本所有可能影响的范围进行测试。回归测试的目的是发现原来正常的功能特性出现新的问题——回归缺陷，从而确保原来正常的或符合要求的特性不受其他区域修改的影响。回归测试伴随着整个测试过程，在功能测试和系统测试、单元测试和集成测试中，一旦有变更或修正，都要进行相应的回归测试。
针对今天的软件开发环境，最近一年，我一直倡导重新认识软件测试，对软件测试应该有一个新的理解，即给出“软件测试”一个新的公式：
测试 ＝ 检测 ＋ 试验
这个公式意味着软件测试包括两部分工作：检测和试验。对于产品中确定性特性进行验证，可以进行检验，因为其验证标准或依据是明确的。而对产品中不确定性特性进行验证，只能通过实验来验证。所以可以将上述公式再展开，就成为：
测试 ＝ 检测已知的 ＋ 试验未知的
即软件测试包括两部分工作—对已知的检测和对未知的试验。
已知的部分，是指测试目标、测试需求和测试的验证准则等都是明确的，也可以理解待测试的功能特性是清楚的、测试范围和数据是有限的，具有良好的可测试性。例如，某些功能在规范的需求规格说明书或其他需求文档中得到清晰的描述，那么这些功能是可以检测（check）的，可以根据文档直接进行验证，判断软件系统中所实现的功能是不是符合之前所定义的需求。在性能测试需求中，如果针对众多的性能指标给出了量化的要求，那么这性能是可以检验的，是可以直接验证的。
未知的部分，即测试目标、测试需求和测试预言等是不明确的，也可以理解为产品的功能需求定义是不清楚、不稳定的，测试范围和数据是无限的，很难直接进行验证，而是需要通过不断地试验，才能知道所实现的功能特性是否正确。例如，用户故事对需求描述过于简洁，验证就很困难，需要足够的探索和沟通才能搞清楚，才能判断系统的实现是否满足用户的需求。如果我们开发一个崭新的系统，之前也没有性能指标数据，这时也需要先试验，获得性能指标数据作为性能基准线。当测试数据是无限的，我们的测试就是一个有限样本的试验。
要理解已知的部分和未知的部分，不仅要了解测试的输入具有两重性——确定性和不确定性，而且测试的输出也具有很大的不确定性。在今天移动互联、大数据时代，移动app的用户数量特别大，操作方式、应用环境、喜好也存在较大的差异，大数据的复杂性、多样性、快速变化特性等，都增加了测试输入和输出的不确定性。针对输出结果的判断，需要进一步了解Test Oracle（可译为“测试预言”）所带来的挑战。什么是Test Oracle呢？Test Oracle就是一种决定一项测试是否通过的（判断）机制。Test Oracle的使用会要求将被测试系统的实际输出与我们所期望的输出进行比较，从而判断是否有差异。如果有差异，可能就存在缺陷。Test Oracle一般依据下列内容做出判断：
① 需求规格说明书和其他需求、设计规范文档；
② 竞争对手的产品；
③ 启发式测试预言（Heuristic oracle）；
④ 统计测试预言（Statistical oracle）；
⑤ 一致性测试预言（Consistency oracle）；
⑥ 基于模型的测试预言（Model-based oracle）；
⑦ 人类预言（Human oracle）。
测试过程中，判断测试结果是否通过，Test Oracle举足轻重。对于已知的检测，我们会用到测试预言①、②、⑤、⑥ （如清晰的Spec、竞品参照、一致性要求、确定性模型等），如图1-5所示。其中基于模型的语言，也只能是确定性的模型。如果是随机模型、模糊模型，就属于不确定模型。
图1-5 对已知的输入／输出进行检测示意图
当我们开始一个软件项目，测试工作也随之开始——进行测试需求分析。这时，我们就可以将测试的范围（测试项）分为两部分：相对稳定的、明确的测试项和不确定的、容易变更的测试内容。针对已知的测试项，比较容易设计测试用例，理论上也基本能百分之百实现自动化。而针对未知的部分，就需要试验、需要探索。只是这种试验或探索，可以手工来做，也可以由工具来做。测试的风险也往往来自这部分——不确定的测试内容，值得我们特别关注，测试需求分析时分为这两部分就更加有意义。
① 如果Test Oracle属于启发式的，需要综合判断的，就需要手工测试——测试人员的试验，不断质疑系统，根据系统的反馈来做出判断，这就是探索式测试。探索式测试也有测试场景、测试思路的设计，但没有详细的设计——测试用例的设计，但探索式测试能发挥人的创造性、分析能力和思维能力，不断设计、执行、分析、学习，再设计、再执行、再分析、再学习……这样持续改进的测试过程，使测试不断优化，测试的效力不断得到提升，能更快、更多地发现问题。
② 对于工具的实验，例如一些系统出现崩溃的原因不明，只知道很有可能是异常数据造成的，这时就可以由工具来进行测试，包括产生随机数据来实现测试，或建立一个初步的数据模型，由模糊控制器产生数据或对正常输入数据直接进行变异数来完成测试，如图1-6所示，这就是自动的随机测试、模糊测试、变异测试等。这时，可以基于统计准则或系统异常的表现，来做出判断：是否发现了缺陷，这些方法常常用于系统的安全性测试、稳定性测试等。
图1-6 借助测试工具进行未知实验的示意图
未来，随着大数据的积累和技术的成熟、人工智能（AI）的发展，这种对未知的测试，可以由人工智能完成（参考第15章相关内容），可以兼具上面两种不同方式的优势，不断学习、不断进行数据（输入、输出、log等）挖掘，不断构造、完善验证的推理规则和测试预言，完成自动的测试，从未知逐步走到已知，达到更好的测试效果。概括起来，“测试＝检测＋试验”意味着：
测试＝基于确定性模型／明确测试预言的自动化测试
＋基于AI搜索的／工具随机／模糊模型的／手工的探索式测试
在做测试需求分析之初，就需要将测试的范围（测试项）分为两部分：已知的（包括确定性的/稳定的）、未知的（包括不确定的/动态的）。已知的测试项，理论上都可以实现自动化；未知的部分，也可以用工具进行测试（模糊测试/随机测试等），更多地是依赖人的探索式测试。图1-7就是对本节的一个小结。
图1-7 基于Test Oracle的测试新认知
批判性思维是指一种合理的反思性（反省的）思维，是一种训练有素的思维方式的体现。它借助观察、经验、反思、推理或沟通等收集信息，并对这些信息进行抽象、应用、分析、综合或评估，以此决定相信什么或做什么。从批判性思维看，软件测试就是借助观察、经验、反思、推理或沟通等收集信息，并对软件产品相关的质量信息进行分析，以此评估软件质量，并做出结论。
但是在下结论之前，或多或少包含了假定和推理，而作为批判性思维的践行者就可以质疑其假定、推理和结论，这样可以消除认知中的误区，突破知识构建时的边界，重新认识某个主体（如软件产品/系统）。如“人们彼此之间也有欺骗”分为恶意欺骗和善意欺骗，但如果不仔细想，就会局限于恶意欺骗。人类的认知是有限的，人们在常识（普遍接触的条件，这也是有边界的）下得出的理论，当达到或超出边界时，认知就会发生谬误。而且，需求文档也包含着一定的模糊性、不确定性和局限性，只有消除其中的模糊性、不确定性和局限性，对软件产品或系统的认知才会前进一大步，测试才会深入下去。
没有审视和分析就不能做出正确的判断。批判性思维促进我们重新审视问题或主题、意图和陈述之间实际的推论关系，勇于质疑证据，去分析和评估陈述、论证的过程。清楚对方是表达一种信念、判断还是一种经验？其理由正当、充分吗？仅仅是个人的感觉？相关的因素都考虑了？有依据支撑吗？依据来源哪里？可靠吗？也就是要评估陈述的可信性，分析其推理的合理性、前后逻辑关系的严谨性等。这些恰恰是软件测试所需要的。
基于批判性思维，我们需要重新定义“软件测试”：软件测试就是测试人员不断质疑被测系统的过程1，如图1-8所示。
1这里的测试人员是泛指，而不是指专职的测试人员，开发人员在做测试时就是扮演测试人员的角色。——作者注
图1-8 “基于批判性思维的软件测试”示意图
需求定义、系统设计中存在研发人员太多的猜测、不真实的假定、片面的理解、不合理的推理等，软件测试在需求评审、设计评审、代码评审和系统测试中就是要重新审视被测对象，质疑那些不合理、不真实的内容，发现软件中的错误、漏洞。
这种软件测试定义，特别适合探索式测试方式。探索式测试聚焦被测系统，侧重发现缺陷，强调在一个相对封闭时间（90min左右的session）内以“设计、执行、分析、学习”的过程不断循环、不断优化测试过程。这里的session 不宜翻译为“测程”，而是会话——测试人员和SUT一次真正的对话，不断地向系统提出问题（质疑系统），再审视SUT所做出的回答（系统的响应），从而根据Test Oracle判断SUT的响应是否符合我们的期望。从隐喻看，可以把“测试人员”看成客户端（浏览器），把SUT看成服务器，测试过程就是测试人员和SUT建立会话的过程，客户端不断发出请求，并检验系统发回来的响应结果。
再举一个例子，帮助大家理解这样一个过程。我们招聘一个新人，会给出职位描述（JD）——详细描述工作岗位要求和责任，应聘者会根据JD提交详细的简历。本来我们就可以根据应聘者的简历来决定是否录用他/她了，为什么不能？还需要安排面试呢？原因如下。
质疑简历不真实（这种情况虽然很少）。
简历中某些描述，大家的理解可能不一致，例如“精通Java”“沟通能力”“情商”没有明确的标准，应聘者和企业对此认识可能差别很大，需要收集更多信息和数据，进行比较分析，才能更加具体客观。
有些内容缺失或不宜在简历中描述，个人气质、性格、情绪控制能力等需要在面试中获得相关信息，做出判断。
简历中某些描述可能比较粗，不够具体，不知是否和企业需求匹配如何，需要从多个应聘者中择优录用。
从批判性思维角度来理解软件测试，就是测试人员“面试”SUT的一次会话过程。虽然有需求文档和设计文档，但是不够。今天敏捷开发模式下就更不充分，需要测试人员去面试系统。探索式测试的核心（出发点）就是质疑系统，不断深入下去质疑系统的每一个业务入口、应用场景、业务操作和数据输出等，怀疑某个地方存在某类缺陷。
开发人员对用户真实的需求的错误理解。
漏掉某些需求。
错误地实现了需求或设计。
没有完整实现需求或设计。
算法不够优化，存在性能问题。
数据输入缺乏保护。
……
这就要求测试人员善于质疑、善于向系统提问，可以参考M.N.Browne的《Asking the Right Questions: A Guide to Ctitical Thinking（10th edition）》（中文版书名《学会提问》）。
在著名的软件瀑布模型中，软件测试处在“编程”的下游，在“软件维护”的上游，先有编程后有测试，测试的位置很清楚。但瀑布模型没有反映SDLC的本质，没能准确无误地反映测试在SDLC的位置，瀑布模型中的软件测试是狭义的测试，落后的测试观念。
如前所述，软件测试贯穿整个SDLC，从需求评审、设计评审开始，就介入到软件产品的开发活动或软件项目实施中了。测试人员参与需求分析和需求评审，通过积极参与需求活动，测试人员不仅能发现需求定义、自身存在的问题，而且能更深入理解业务需求、特定的用户需求和产品的功能特性，为测试需求分析与设计等打下坚实的基础。更进一步，这个阶段可以确定产品测试的验收标准，可以制订验收测试的计划和设计验收测试用例（test case）。同理，在软件设计阶段，测试人员要清楚地了解系统是如何实现的、采用哪些开发技术以及构建在什么样的应用平台之上等各类问题，这样可以提前准备系统的测试环境，包括硬件和第三方软件的采购。更要针对一些非功能特性（如性能、安全性、兼容性、可靠性等）检查系统架构设计的合理性和有效性，发现设计中存在的问题，并着手研究如何测试当前的软件系统，完成系统测试用例设计、测试工具的选型或启动测试工具的开发，进一步完善测试计划等。所有这些准备工作，都要花很多时间，应尽早开展起来。
当设计人员在做详细设计时，测试人员可以直接参与具体的设计、参与设计的评审，找出设计的缺陷。同时，完成功能特性测试的用例，并基于这些测试用例开发测试脚本。
编程阶段的单元测试是很有效的，越来越得到业界的关注和实施。有数据显示，单元测试可以发现代码中60%～70%的问题，充分的单元测试可以大幅度提高程序质量。其次，单元测试和编程同步进行，极其自然，可以尽早发现程序问题。
软件测试在SDLC中的位置，可以通过基于W模型（加入了我个人的理解）来呈现，如图1-9所示。软件测试和软件开发构成一个全过程的交互、协作的关系，两者自始至终一起工作，共同致力于同一个目标——按时、高质量地完成项目。同时也体现了软件测试的4个层次，是从低层次（单元测试）向高层次推进：
图1-9 基于W模型呈现软件测试和开发的关系
单元测试；
接口测试、集成测试；
系统测试；
业务层次的验收测试；
从敏捷开发模式来认知什么是软件测试，这也是讨论什么是敏捷测试，包括在敏捷开发模式下软件测试的思想、原则等。先研究如下敏捷宣言背后所蕴含的12条原则。
① 我们最重要的目标是通过持续不断地及早交付有价值的软件使客户满意。
② 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程、掌控变化。
③ 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
④ 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
⑤ 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
⑥ 不论团队内外，传递信息效果最好、效率也最高的方式是面对面的交谈。
⑦ 可工作的软件是进度的首要度量标准。
⑧ 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
⑨ 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
⑩ 以简洁为本，它是极力减少不必要工作量的艺术。
⑪ 最好的架构、需求和设计出自自组织团队。
⑫ 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
这12条原则中没有一条直接谈到测试，那是否说明敏捷开发对软件测试没有影响呢？有开发就有测试，只是原来参加敏捷宣言的17人，基本是清一色的程序员，没有在原则中单独阐述一下测试的原则。但如下的一些原则和测试的关联性很强。
① 软件测试如何支撑或协助“持续不断地及早交付有价值的软件”？如何在非常有限的时间内进行充分的测试？这就是我们经常在敏捷测试中强调的“自动化测试”。如果没有自动化测试，就没有敏捷，就不能持续不断地及早交付有价值的软件，而且还要“使客户满意”。
② “欣然面对需求变化，即使在开发后期也一样”和传统的开发原则是不同的，传统的开发希望有严格的需求变更控制，越到后期控制越严。而敏捷开发拥抱变化，那么测试如何适应这种变化？如何快速地完成回归测试？这可能要依赖于开发做好单元测试，或全员参与测试，以及全面支持系统级的、端到端的回归测试的自动化测试执行。
③ 传统的开发也要求“业务人员和开发人员必须相互合作”，但存在一定的阶段性，例如前期需求评审、期间产品走查（product walk-through）、后期验收测试等要求有紧密的沟通与协作。但敏捷开发更强调“项目中的每一天都不例外”，在这样的原则下，如何去做敏捷测试？这样可以减少测试文档，刚开始也没必要把测试计划写得很详细，而是写一页纸测试计划就可以，将来再持续地加以完善和调整。
④ “可工作的软件是进度的首要度量标准”，不再是测试计划完成情况、完成的测试用例数目、测试脚本量等，而是如何及时验证每天完成的功能特性。开发的工作量也不能按代码行来衡量，而是看多少个具体的用户故事（功能特性）被实现了（done）。某个开发说已完成了某个用户故事，要么是通过他自己的验证，要么是通过测试人员的验证，谁做的测试不重要，关键是要有准备好的测试，随时验证已完成的工作。
⑤ “坚持不懈地追求技术卓越和良好设计”，一方面要求测试的技术要不断提高，在处理每个测试任务时，都应该找到最有效的办法；另一方面，在前期要更多地参与设计评审，及时发现设计的问题。只有良好的设计，才能更好地支持系统的功能扩充和不断的重构。
基于这些原则，我们就可以概括出敏捷测试的下列特点。
① 敏捷测试一定是敏捷开发方法的一部分，应符合敏捷测试宣言的思想，也遵守上面所列的敏捷开发的原则，强调测试人员的个人技能，始终保持与客户/用户、其他成员（特别是业务人员、产品设计人员等）的紧密协作，建立良好的测试框架（特别是持续集成测试和自动化回归测试的基础设施）以适应需求的变化，更关注被测系统的本身而不是测试文档（如测试计划、测试用例等）。
② 敏捷测试具有鲜明的敏捷开发的特征，如测试驱动开发（TDD）、验收测试驱动开发（ATDD），可以见笔者的另一篇文章《敏捷测试的思考和新发展》所讨论的。测试驱动开发的思想是敏捷测试的核心，或者说，单元测试是敏捷测试的基础，如果没有足够的单元测试就无法应付将来需求的快速变化、也无法实现持续的交付。这也说明，在敏捷测试中，开发人员承担更多的测试，这也就是我们说的，敏捷测试，是整个团队的共同努力。在敏捷测试中，可以没有专职的测试人员，每个人都可以主动去取设计任务和代码任务做，也可以去拿测试任务来做。在敏捷测试中，也可以像开发人员的结对编程那样，实践结对测试——一个测试人员对应一个开发人员、或一个测试人员对应另一个测试人员。
③ 敏捷测试无处不在、无时不在。在传统测试中也提倡尽早测试，包括需求和设计的评审；在传统测试里也提倡全过程测试。但在传统测试里阶段性特征相对突出一些，例如，需求评审意味着先让产品人员去写需求，但需求文档写好之后，测试人员再参加评审。而在敏捷测试里，团队每一天都在一起工作，一起讨论需求、一起评审需求。在敏捷测试中，这种持续性更为显著一些。
④ 敏捷测试是基于自动化测试的，自动化测试在敏捷测试中占有绝对的主导地位。在传统测试中也提倡自动化测试，但由于传统开发的周期比较长（几个月到几年），即使没有自动化测试也是可以应付的。一般来说，回归测试能够获得几周时间，甚至1～2个月的时间。而敏捷测试的持续性迫切要求测试的高度自动化，在1～3天内就能完成整个的验收测试（包括回归测试）。没有自动化，就没有敏捷。
敏捷测试就是符合敏捷宣言思想，遵守敏捷开发原则，在敏捷开发环境下能够很好地和其整体开发流程融合的一系列的测试实践，并具有鲜明的敏捷开发的特征，如TDD、ATDD、结对编程、持续测试等。敏捷测试和传统测试的区分，可以概括如下。
① 传统测试更强调测试的独立性，将“开发人员”和“测试人员”角色分得比较清楚。而敏捷测试可以有专职的测试人员，也可以是全民测试，即在敏捷测试中，可以没有“测试人员”角色，强调整个团队对测试负责。
② 传统测试更具有阶段性，从需求评审、设计评审、单元测试到集成测试、系统测试等，从测试计划、测试设计再到测试执行、测试报告等，但敏捷测试更强调持续测试、持续的质量反馈，阶段性比较模糊。
③ 传统测试强调测试的计划性，认为没有良好的测试计划和不按计划执行，测试就难以控制和管理，而敏捷测试更强调测试的速度和适应性，侧重计划的不断调整以适应需求的变化。
④ 传统测试强调测试是由“验证”和“确认”两种活动构成的，而敏捷测试没有这种区分，始终以用户需求为中心，每时每刻不离开用户需求，将验证和确认统一起来。
⑤ 传统测试强调任何发现的缺陷要记录下来，以便进行缺陷根本原因分析，达到缺陷预防的目的，并强调缺陷跟踪和处理的流程，区分测试人员和开发人员的各自不同的责任。而敏捷测试强调面对面的沟通、协作，强调团队的责任，不太关注对缺陷的记录与跟踪。
⑥ 传统测试更关注缺陷，围绕缺陷开展一系列的活动，如缺陷跟踪、缺陷度量、缺陷分析、缺陷报告质量检查等，而敏捷测试更关注产品本身，关注可以交付的客户价值。在快速交付的敏捷开发模式下，缺陷修复的成本很低。
⑦ 传统测试鼓励自动化测试，但自动化测试的成功与否对测试没有致命的影响。但敏捷测试的基础就是自动化测试，敏捷测试是具有良好的自动化测试框架支撑的快速测试。
从另一个角度看，有什么实现，就有相应的构建。任何构建的东西，没经过验证都是不靠谱的。理解这个角度，V模型是最好的，笔者适当做了一些修改，如图1-4所示。
在购买商品时，消费者会发现商品上贴有一个“QC”标签，这就是产品经过质量检验（Quality Control）的标志。软件测试就好比制造工厂的质量检验工作，是对软件产品和阶段性工作成果进行质量检验，不仅验证产品是否符合事先的需求定义、设计要求和代码规范等，完成一致性的检查，而且要确认所实现的产品功能特性是否满足用户需求，每个功能特性都是用户真正所需要的。由于时间和预算的限制，我们无法证明一般的应用系统软件是没有问题的，而只能通过发现问题并消除这些问题来降低产品的质量风险、提高产品的质量。所以，软件测试是软件公司致力于衡量产品质量、保证产品质量的重要手段之一。
有人反驳说，质量是构建的，不是靠测试测出来的。没错，从“质量是构建的”角度看，开发人员对产品质量有更大贡献，测试对质量的贡献要低于开发工作，测试人员对质量的贡献要小。但这也不能否定测试的作用，测试人员帮助整个团队发现产品中存在的各种缺陷，然后督促开发人员消灭这些缺陷，软件产品的质量还是有显著的提高。如果从产品质量和质量责任来看，无论是把测试人员比作“产品质量守门员”还是比作“产品质量过程的监督者”，都显示测试人员对产品质量负有更大的责任，这是由“软件测试人员”这个角色所决定的，软件测试是质量保证的重要手段之一，许多公司也把测试人员放在质量保证（Quality Assurance）部门，甚至有的公司干脆就叫测试人员为QA人员。
概括起来，软件测试有以下4个方面的作用。
① 产品质量评估：全面地评估软件产品的质量，为软件产品发布（验收测试）、软件系统部署（性能规划测试）、软件产品鉴定（第三方独立测试）委托方和被委托方纠纷仲裁（第三方独立测试）和其他决策提供产品质量所需的各种信息，也就是能够提供准确、客观、完整的软件产品质量报告。
② 持续的质量反馈：通过持续地测试（包括需求评审、设计评审、代码评审等）可以对产品质量提供持续的、快速的反馈，从而在整个开发过程中不断地、及时地解决存在的质量问题，不断改进产品的质量，并减少各种返工，最大限度地降低软件开发的劣质成本。
③ 客户满意度的提升：通过测试发现所要交付产品的缺陷，特别是尽可能地发现各种严重的缺陷，降低或消除产品质量风险，提高客户的满意度，扩大市场份额，提高客户的忠诚度。
④ 缺陷预防：通过对缺陷进行分析，找出缺陷发生的根本原因（软件开发过程中所存在的流程缺失、不遵守流程、错误的行为方式、不良习惯等问题）或总结出软件缺陷模式，采取措施纠正深层次的问题，避免将来犯同样的错误，达到缺陷预防的效果，有效减少开发中出现的问题，提高开发的效率。
软件测试工作，在软件研发中的作用是显而易见的，但软件质量其实是在软件开发生命周期中慢慢形成的，或者说，软件质量是内建的（Quality is built in），而不是测试测出来的。软件产品经过需求、设计、编程之后，当程序代码完成之时，其质量水平就基本确定了，虽然可以通过测试发现其中大部分潜在的缺陷，但是程序代码中存在的缺陷越多，遗漏的缺陷就会越多，质量很难得到彻底的改善。如果缺陷发生在需求阶段或设计阶段，且直到系统测试时才被发现，则需要修改需求或设计，进一步造成大量代码的返工和回归测试，从而给项目进度带来较大风险，给软件研发也增加额外的成本。
如果将软件测试贯穿于整个软件开发过程，从项目启动的第一天开始就将软件测试引入进来，情况就完全不一样了：
在需求阶段，通过测试团队和开发团队的共同努力，尽可能把用户的需求全部挖掘出来，清除一切模糊的需求描述，需求文档或需求定义中存在的问题在需求评审中能被及时发现；
在设计阶段对不合理的设计提出质疑，设计中存在的性能、安全性、可靠性等潜在的风险也能被及时发现，督促开发人员在设计时更充分地考虑性能、可靠性和安全性等各个方面的要求，以确定每一个设计项的可测试性；
不规范的代码、不合理的算法、逻辑错误可以在代码评审中被及时发现；
代码功能的错误实现，在单元测试中被发现；
之前发现的问题对后续的设计和编程工作有良好的借鉴作用，预防同样的问题发生。
贯穿于软件开发全过程的测试，不仅可以在第一时间内发现缺陷，降低缺陷带来的成本（劣质成本），而且能有效地预防缺陷的产生，构建更好的软件产品质量。所以，贯穿于软件开发全过程的测试，软件测试不再是事后检查，而是缺陷预防和检查的统一，将软件测试扩展到软件质量保证的全过程中，从而大大减少软件缺陷的数量、提高软件质量。更有价值的是，它可以极大地缩短开发周期、降低软件开发的成本。
传统的瀑布模型中，测试只是一个阶段，而且是编程之后的一个阶段，也意味着传统的瀑布模型中软件测试只是动态测试，即运行可执行程序而进行的测试，传统的软件测试是一种“狭义的测试”。全程软件测试的思想就是将软件测试从动态测试扩展到静态测试——需求评审、设计评审和代码评审。之前，我们了解到软件的基本定义：软件 = 程序 +文档 +数据结构，所以需求（文档）、设计（文档）和代码都是软件的一部分，软件测试自然包含对需求、设计、代码的测试。静态测试，是“软件测试”，而不是“软件质量保证（Software Quality Assurance，SQA）”工作的一部分，SQA更侧重流程的定义和评审，侧重评审各项软件研发工作（包括需求、设计、编程、测试）的规范性、合规性等。
全程软件测试，不仅将测试左移（左移到需求、设计阶段），而且还右移到运维，如在线测试（Test in Production，TiP）、在线监控和日志分析等。全程软件测试，再进一步扩展，左移可以包括测试驱动开发（Test Driven Development，TDD）、验收测试驱动开发（Acceptance Test Driven Development，ATDD）。左移和右移合起来，可以和现在流行的DevOps1联系起来。
1DevOps是新的软件工程实践，旨在统一软件开发（Dev）和运维（Ops）、缩短开发周期、增加部署频率、更可靠地发布，在软件构建、集成、测试、发布到部署和基础设施管理中大力提倡自动化和监控。——作者注
全程软件测试也不局限于功能测试，还包括非功能性测试——安全性测试、性能测试、易用性测试等，使各种类型的软件测试覆盖软件研发全生命周期。
测试左移与右移（见图2-1）的基点是瀑布模型的测试阶段，在其测试阶段侧重系统测试，可以涵盖集成测试，其中单元测试属于编程阶段，和编程同时进行：
测试左移，就将测试提前进行，包括需求评审、设计评审、代码评审等。
测试右移，就是将测试延伸到研发阶段之后的其他阶段，一般主要指产品上线后的测试，包括在线测试、在线监控和日志分析，甚至包括alpha测试、beta测试。
图2-1 测试左移与右移示意图
从所了解的现实情况看，单元测试做得不够好甚至做得很少，如表2-1所示，58.8%的项目没有要求，还有24.4%的项目要求低于50%代码行覆盖率，许多软件公司或研发团队依赖于测试团队后期的系统测试，这会导致成本高，无法进行测试的测试。所以从现实角度出发，测试左移也包括加强单元测试，对单元测试有较高的要求，如代码行覆盖做到100%，而且强调代码编写和单元测试同步进行，写好一个类测一个类、写好一个方法测一个方法，而不是集中写几天代码，再集中做单元测试。发现自己问题越早越好，避免以后重复犯同样的问题。
表2-1 国内软件项目对单元测试代码行覆盖率的要求的调查结果
| 选项 |
小计（总样本数为750） |
比例 |
|---|---|---|
| 100% |
26 |
|
| 大于80% （或大于90%） |
100 |
|
| 大于50% （或大于60%） |
118 |
|
| 大于20% |
65 |
|
| 没有要求 |
441 |
|
测试右移指在线测试，传统的alpha测试、beta测试也是上线后的测试，分别指内部用户、外部有限用户的试用，通过试用来发现问题。现在软件作为服务，通常部署在软件研发公司的数据中心，有利于监控和分析系统运行的行为，虽然不是真正意义上的主动测试，属于被动测试，但大量用户的操作使用自然是对软件系统的真正考验，有问题还是能够暴露出来。由于系统就部署在自己的数据中心，有问题可以快速及时修复，对用户的影响会控制在比较小的范围内，降低缺陷带来的风险。许多易用性测试（如A/B测试）、性能测试等都可以在线进行（监控、数据收集与分析）。
在目前比较流行的敏捷开发模式（如极限编程、Scrum方法等）中，推崇“测试驱动开发（Test Driven Development，TDD）”——测试在先、编码在后的开发实践。TDD有别于以往的“先编码、后测试”的开发过程，而是在编程之前，先写测试脚本或设计测试用例。TDD在敏捷开发模式中被称为“测试优先的编程（test-first programming）”，而在IBM Rational统一过程（Rational Unified Process，RUP）中被称为“测试优先的设计（test-first design）”。所有这些都在强调“测试先行”，使得开发人员对所做的设计或所写的代码有足够的信心，同时也有勇气进行设计或代码的快速重构，有利于快速迭代、持续交付。重构的前提就是测试就绪（testing is ready），在这样的前提下，重构的风险就很低，否则就有比较高的风险。
TDD具体实施过程，可以看作两个层次，如图2-2所示。
① 在代码层次，在编码之前写测试脚本，可以称为单元测试驱动开发（Unit Test Driven Development ，UTDD）。
② 在业务层次，在需求分析时就确定需求（如用户故事）的验收标准，即验收测试驱动开发（ATDD）。
图2-2 TDD的两个不同层次
先来讨论UTDD，如图2-3所示。在打算添加某项新功能时，先不要急着写程序代码，而是将各种特定条件、使用场景等想清楚，为待编写（类或方法）的代码先写好测试脚本。然后，利用集成开发环境或相应的测试工具来执行这段测试用例，结果自然是通过不了（失败）。利用没有通过测试的错误信息反馈，了解到代码没有通过测试用例的原因，有针对性地逐步地添加代码。为了要使该测试用例通过，就要补充、修改代码，直到代码符合测试用例的要求，获得通过。测试用例全部执行成功，说明新添加的功能通过了单元测试，可以进入下一个环节。这样的流程也适合代码修改或重构，真正执行时，也不会严格按照这样的流程去做，但最基本要求是：先写好测试脚本（代码），再写产品代码并通过测试。按照UTDD做法，不是先写产品代码的类，再写测试类，而是先写测试类，再写产品的类。
图2-3 UTDD执行的过程
UTDD从根本上改变了开发人员的编程态度，开发人员不能再像过去那样随意写代码，要求写的每行代码都是有效的代码，写完所有的代码就意味着真正完成了编码任务。而在此之前，代码写完了，实际上只完成了一半工作，远没有结束，因为单元测试还没执行，可能会发现许多错误，一旦缺陷比较多，缺陷就比较难以定位与修正。UTDD在于促进开发人员思考功能特性的应用场景、异常情况或边界条件，写出更完善的代码，避免犯较多的错误。其次，也确保测试具有独立性，不受实现思维的影响，确保测试的客观、全面。这一点，对开发人员测试自己的代码是必要的。如果是倒过来，先写产品代码（即功能实现在前）再进行测试，那么测试会受实现思维影响。例如，我们自己写的文章自己检查，有时很明显的问题都发现不了，就是受实现思维的影响。一般来说（多数情况下），开发人员测试自己的代码有两个障碍：思维障碍和心理障碍。心理障碍是指开发人员对自己的代码不会穷追猛打，发现了一些缺陷，很可能会适可而止。我们知道，实际上缺陷越多的地方越有风险，越要进行足够的测试。最后，UTDD也确保所有代码的可测试性，每一行代码得到了测试，比较彻底地确保代码的（微观）质量。
许多研发人员不习惯UTDD这种模式，是推行UTDD困难较大的原因之一，那TDD的实施可以移到业务层，推行ATDD，即在设计、写代码之前，明确系统功能特性的验收标准。例如，在敏捷开发模式中，每个用户故事的描述过于简单，是不具有可测试性的。例如，开发一个在线旅游网，可以提供交通、酒店、门票等预定服务，有一个最基本的用户故事：
US 2-1：作为一个旅行者，我想通过一次性的操作，快速删除事先预定的订单包（含飞机票、酒店和门票）
像这样的用户故事，如果不加验收标准，开发实现起来很容易，在数据库某个表中删除一条记录，在其他关联表上修改相应的标志位即可。但实际的业务不会那么简单，说取消就取消？不需要有一个时间提前量？取消一定成功吗？收不收相关的费用？是否需要线下处理的时间？是否需要通知用户？通过什么方式通知取消成功或失败？要回答这些问题，就是要给这个用户故事增加“验收标准”，具体如下。
取消前，需要提醒用户再次确认。
需提前24小时取消。
需要4小时处理时间，才能知道取消成功与否。
这类取消需要收取总金额10%的费用。
不管取消成功与否，采用邮件和短信双重通知。
用户事后可以查询取消的相关记录。
需要保留客户和旅行网双向操作记录日志。
这样，这个用户故事才具有可测试性，开发也会清楚如何实现这个用户故事，实现的结果和产品经理所期望的结果不会有太大差异。
从ATDD演化出来一种具体落地的开发模式就是行为驱动开发（Behavior Driven Development，BDD）。BDD只是将验收标准更加明确化，可以看作ATDD的实例化，即列出用户故事所可能遇到的应用场景，而且将这种应用场景的表达方式规定为GWT格式，如下所示。
Given：给定什么上下文/条件 AND/OR 其他条件。
When：当什么事件被触发。
Then：产生什么结果 AND/OR 其他结果。
3.47%
13.33%
15.73%
8.67%
58.8%Title (one line describing the story)
Narrative:
As a [role]
I want [feature]
So that [benefit]
Acceptance criteria: (presented as Scenarios)
Scenario 1: Title
Given [context]
And [some more context]...
When [event]
Then [outcome]
And [another outcome]...
Scenario 2: ...例如，用户故事(US)2-1至少存在两个场景：
① 场景1 取消操作时，距离使用时间不到24h；
② 场景2 取消操作时，距离使用时间超过24h。
BDD再往前推进一步，就是需求实例化（Requirements By Example，RBE），更加明确需求的具体表现。例如，还是以上面用户故事US 2-1为示例，可以建立下列的需求实例化的内容，如表2-2所示。
表2-2 用户故事US 2-1需求实例化示例
| 用户名 |
操作 |
时间 |
金额 |
期望的结果 |
|---|---|---|---|---|
| David |
预定 |
9月27日 |
9000元 |
10月1日开始使用 |
| David |
取消订单 |
9月30日下午1点 |
无法取消 |
|
| David |
取消订单 |
9月29日下午1点 |
收取900元 |
可以取消 |
| David |
查询取消结果 |
9月29日下午2点 |
显示“正在处理” |
|
| David |
检查手机短信 |
9月29日下午6点 |
有一条新短信，显示已取消 |
|
| David |
访问网站查询取消结果 |
9月29日下午6点 |
有结果 |
需求越明确，用户、产品经理、开发与测试等之间的理解就越一致，更不容易产生偏差和误解，有利于需求的定义、产品的开发和测试。基于RBE，开发人员写产品的代码，测试人员可以独立写测试的代码，产品经理的工作也会变得轻松，不需要太多的解释、不需要回答开发和测试的各种问题。
从需求角度看，BDD和需求实例化比较彻底地明确需求，统一用户、产品经理、开发与测试等认识，让大家处在一个层面上，使研发工作更高效。
从测试角度看，需求即测试，产品的需求就是测试的需求，需求可以被执行，即一步到位，将需求变为自动化测试脚本，开发出来的功能特性随时可以被自动验证。
TDD一改以往的破坏性测试的思维方式，测试在先、编码在后，更符合“缺陷预防”的思想。这样一来，编码的思维方式发生了很大的变化，编写出高质量的代码去通过这些测试，在进行每项设计、写每一行代码时都要想想用户的真实需求、应用场景和一些例外等，确保实现的功能特性符合预期，并具有健壮性。测试，也从以前的破坏性的方法转移到一种建设性的方法中来。在这种积极心态的影响下，开发人员的工作效率和产品的质量都会有显著的提高，真正实现“质量是内建的（Quality is built in）”的目标。
在今天移动互联时代，传统的研发模式还存在。根据最近做的一次调查，国内还有48%以上的公司或团队还没有采用敏捷开发模式，依旧采用传统的开发模式。即使不从最早的水晶开发模式算起，而从2001敏捷宣言发布开始算，距今也超过17年了，为什么敏捷没有得到很好的推行呢？一方面，大家普遍认为敏捷开发模式能够快速响应用户需求变化，更适合需求不明确或不稳定的、规模不大的产品研发，但不适合其他类型的产品开发，如需求明确且对质量要求很高的关键系统，所以像银行、航空航天等关键性系统的研发，还依旧采用传统的开发模式。这其中也包括目前的国家标准、行业规范不支持敏捷开发。另一方面，由于惯性作用，有些公司也不想做出改变，或者说，改变开发模式会承担一定的风险，有些公司的管理者也不愿冒这种风险。
20年前，就开始形成软件即服务（Software as a Service, SaaS），而且软件从产品转化为服务也是大势所趋，但今天的软件生态环境依旧有多样性。在互联网企业，特别是面向普通个人用户（B2C）的产品，绝大部分都是通过服务来提供的。但是，许多政府和企业内部的软件，如工业控制软件、智能设备的嵌入式软件、航空航天通信软件等，还是以产品的形态存在。即使一些大型企业内部使用的软件在内部以服务的形式提供给员工，但这类软件如果不是自己开发的，是委托第三方开发的，这类软件（B2B）的交付也不可能频繁交付，可能也不适合敏捷开发。而且这类软件产品研发出来之后，需要部署到用户所在的公司环境中，这种交付本身也不支持研发和运维的融合，不支持DevOps，因为运维是由用户来做，研发公司也只是提供技术支持。从传统研发过程看，测试在研发过程形成闭环，虽然在产品期间可能会收集用户使用产品的反馈，但这只是可选项，不是必然发生的活动。
在传统的研发过程模式中，瀑布模型是典型的代表，强调工程的阶段性，每个阶段完成自身的工作，也就是说，某个阶段未达到出口准则，这个阶段就不能结束。没有达到下一个阶段的入口准则，就不能进入下一个阶段。例如，需求阶段需要完成需求的收集、整理、分析和评审，当之前发现的问题已经得到纠正之后，所有参与评审的人一致同意需求（包括相关的文档）达到事先要求的质量，意味着需求通过评审，可以进入设计阶段。但是，采用传统的软件过程，也不是一触而就的，也是通过多次迭代来开发产品，不断推出新的版本，只是没有像敏捷那样进行快速迭代，而是迭代周期长，在每一个迭代周期，需求、设计、编码、测试、发布等阶段性非常明确。就传统的软件测试过程，属于螺旋式上升过程，能够形成研发的闭环，只是没有扩展到运行和维护，研发和运维相对隔离。
为了更明确测试过程，从两条线索角度分别展示传统软件测试环，如图2-4所示。
① 从软件工程过程来看，经过需求评审、设计评审、代码评审与单元测试、集成测试、系统测试和验收测试，再到产品缺陷根因分析、产品改进计划（提出新的产品需求）阶段，再进入下一个循环。
② 从项目管理角度看，经过测试分析、测试计划、测试设计、脚本开发、测试件评审、测试执行与监控、测试过程与结果的评估、测试与质量报告和项目总结阶段，形成项目过程环。
过程的描述尽量简单，从而使读者一目了然，基本知道各个环节主要的工作，但实际许多工作是交替进行或同时进行的，例如系统测试和验收测试的计划、设计工作可以很早开始，例如在需求评审就可以开展验收测试的计划、设计工作，在设计评审时就可以开展系统测试的计划和设计工作，虽然在后续时间还有待继续完善。
图2-4 传统软件测试的闭环
因为提倡每日构建或持续集成，如果仅从软件代码角度看，单元测试和集成测试是同时进行的，没有单独的集成测试阶段。但如果考虑和其他子系统的集成和第三方系统集成、硬件集成等工作，集成测试的阶段还是存在的。
上面的闭环只是一般的实践，仅供参考。在实际操作中，还可以定义自己所需的阶段，设立相应的里程碑，如可以增加测试计划书的评审和签发、测试用例的评审和签发、系统功能测试阶段、系统性能测试阶段等。
在敏捷测试流程中，提倡测试驱动开发，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试则依赖于自动化测试。由于敏捷方法中迭代周期短，研发人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续地对软件产品质量进行反馈。简单地说，在敏捷开发流程中，阶段性不够明显，持续测试和持续质量反馈的特征明显，这可以通过图2-5来描述。虽然在测试环上分布了不同的测试活动，这些活动（如用户故事评审、TDD、代码评审、持续构建、持续测试等）并不是分布在不同的阶段，而是交织在一起、同步进行，持续往前推进。在敏捷开发中，可以这么说：持续设计、持续编程、持续构建、持续集成、持续测试、持续交付等。
图2-5 简化的敏捷测试环
如果再具体一些，以敏捷Scrum为例，来理解全过程的敏捷测试流程。在Scrum流程中，如图2-6所示，前期的确有一个发布计划（Release Planning）阶段，定义需求，即给出用户故事及其验收标准、估算基本工作量、优先级排序和迭代阶段划分，形成产品特性列表（Product Backlog）。在这个阶段，测试也已介入，包括用户故事评审、明确用户故事验收标准，列出用户故事的应用场景。在设计、写代码之前，需要将验收标准确定下来，即前面介绍的ATDD、BDD，为后面迭代测试建立良好的基础（测试的依据）。
图2-6 Scrum流程示意图
在迭代（Sprint）过程中，全程测试特征显著，就是图2-6 中那个大圆圈——在整个迭代过程持续进行测试，包括新功能的持续测试、持续的集成测试和持续的回归测试。
① 新功能的持续测试，意味着完成一个特性，就测试一个特性，完成一个类就测试一个类。新功能的持续测试可以依赖于自动化测试，也可以依赖于探索式测试。
② 持续的集成测试，主要指有代码构建（Build），就要验证是否成功完成构建，即通常所说的BVT（Build Verification Test）。
③ 持续的回归测试，意味着每天都在执行回归测试，甚至时时在进行回归测试，只要有构建就有回归测试，只要有代码的改动，就要进行回归测试。回归测试依赖于自动化测试的支撑。
在产品交付前，最好有一个完整的验收测试。之前，虽然我们开展持续测试，有缺陷就能及时发现，但测试具有一定的局限性，侧重一个单元一个单元地测、一个故事一个故事地测，测试范围小，比较零碎。在交付前，需要将这些单元、这些用户故事串起来进行比较全面的测试，可以从业务流程出发，进行端到端（End-to-End，E2E）的测试，真正从业务的角度来验收所有实现的特性。
概括起来，从产品发布计划开始，直到交付、运维，测试融于其中、与开发形影不离，随时暴露产品的质量风险，随时了解产品质量状态，从而满足持续交付对测试、质量管理所提出的新要求。
早在2004年，我们已具有DevOps的思想，毕竟WebEx公司（1996年成立，2000年纳斯达克上市，2007年被思科以32亿美元收购）是最早进入软件即服务（Software as a Service，SaaS）领域的公司，从一开始就重视软件部署和运维，在需求、架构设计阶段就考虑运维的需求、开发运维工具，如GSB（Global System Backup，全球系统备份）工具、SLiM（Service Life Management，服务生命周期管理）等工具，软件部署之后，研发部门也给予大力支持，而且需要进行部署验证（PQA），以客户需求为中心，运维和研发是贯通的、协作的，没有在两个部门之间形成一座高高的隔离墙，图2-7就是那时形成的覆盖研发（Dev）和运维（Operation）全生命周期的质量保证流程。
虽然DevOps这个概念现在还没有标准的定义，但我们可以追溯一下其过去9年的历史发展过程（2009—2017年），列出几个相对明确又有所不同不同的定义，从而能够比较全面了解DevOps的内涵。
2009年 DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和QA部门之间的沟通、协作与整合。
2011年，DevOps快速响应业务和客户的需求，通过行为科学改善IT各部门之间的沟通，以加快IT组织交付满足快速生产软件产品和服务的目。
图2-7 WebEx软件研发与运维质量保证全流程
2015年，DevOps强调沟通、协作、集成、自动化和度量，以帮助组织快速开发软件产品，并提高操作性能和质量保证；强调自动化软件交付和基础设施变更的过程，以建立一种文化和环境，通过构建、测试和发布软件等方法，可以快速、频繁地、更可靠地发布软件。
2016年，DevOps的目标是建立流水线式的准时制（JIT）的业务流程，以获得最大化业务成果，例如增加销售和利润率，提高业务速度、减少运营成本。
2017年，作为一个软件工程实践，DevOps旨在统一软件开发和运维，与业务目标紧密结合，在软件构建、集成、测试、发布到部署和基础设施管理中大力提倡自动化和监控。DevOps的目标是缩短开发周期，增加部署频率，更可靠地发布。
简单地说，DevOps是敏捷研发中持续构建（Continuous Build，CB）、持续集成（Continuous Integration，CI）、持续交付（Continuous Delivery，CD）的自然延伸，从研发周期向右扩展到部署、运维，不仅打通研发的“需求、开发与测试”各个环节，还打通“研发”与“运维”。DevOps 适合“软件即服务”（SaaS）或“平台即服务”（PaaS）这样的应用领域，其显著的特征如下。
① 打通用户、PMO、需求、设计、开发、测试、运维等各上下游部门或不同角色。
② 打通业务、架构、代码、测试、部署、监控、安全、性能等各领域工具链。
DevOps在软件构建、集成、测试、发布到部署和基础设施管理中大力提倡自动化和监控，形成软件研发完整的生态。
全程软件测试，强调软件测试不再是一个阶段，而是贯穿整个软件开发与维护的生命周期，只要软件研发项目一启动，软件测试就介入，从需求评审开始，直到产品交付后的在线测试。测试左移，将传统的动态测试扩展到静态测试，开展需求、设计和代码的评审；测试右移，将测试验收到软件研发周期之外，进入软件运维阶段，意味着始终关注软件产品质量，而不是说，软件交付之后就万事大吉了。测试左移更到位的话，就是实施TDD，测试右移到位，就是今天推崇的DevOps。
