《软件测试的艺术》高清脑图总结（文末免费送书）
各位朋友，大家好，我是财哥。
今天财哥为大家带来一本软件测试的经典书籍分享：《软件测试的艺术》，这本书堪称软件测试书籍中的圣经，该书首次印刷于1979年，距今一共发行过三版：第一版，第二版和第三版。很难想象有一本如此“古老”的书籍能存活30多年，本书作者由Glenford J. Myers，Tom Badgett，Corey Sandler几位大佬联手完成。本书在豆瓣上也获得了8.4的评分。
豆瓣评分：
作者简介：
Glenford J. Myers，IBM系统研究所前高级研究员，同时还是RadiSys公司的创始人和前CEO。
Tom Badgett，曾经主管大型企业软件开发团队，已出版超过60本关于计算机软件和硬件的技术书籍，同时他还是PcJr,Digital News等主流计算机杂志的技术编辑。
Corey Sandler，计算机新闻的先锋，他曾经负责Gannett Newspapers 和the Associated Press的技术部分以及之后成为Pc Magazine的第一任主编。他同时还是Digital News（针对DEC小型机的一份报纸）的编辑创始团队成员，他著作等身，目前已经出版了超过150本书籍，覆盖了从计算机到商业以及很多其他领域。
我与本书是2013年刚去百度时候相识的，之前我是在外企负责C++开发，对于软件测试的理解仅限于在大学时期的一些概念。后来去百度做测试开发后，当时的mentor把这本书送给我研读，书很薄，才120页，当时我花了几天时间草草地翻阅完了这本书。说来惭愧，后来我也重读过几遍《软件测试的艺术》，但始终没有投入精力去思考这本书于我的意义。如今我工作将近十年了，在测试开发这个航道大约也有近八年的职场历程，期间也亲身过各式各样软件测试的技术和流程的实践与落地，回想起来，很多软件测试的理念和原则早已经在这本书被作者描绘地一清二楚。
这回再次重读本书，我将对照着逐个章节，反复思考自己是否有在正确地践行软件测试活动，文末也我也为大家整理了一份高清脑图，对本书进行了较为全面的内容整理。下面我就根据书中的每个章节，分享下我的感悟，包括其中的得与失。
第一章「一次自我评价的测试」是本书开篇之章，作者仅仅用了两页，就一语道破软件测试的天机："所谓软件测试，就是一个过程或一些系列的过程，用来确认计算机代码完成了其该完成的功能，不执行不该有的操作。"，这句话可能对很多刚入行软件测试的朋友，或者非软件测试人员（譬如项目经理，产品经理，或者很多开发，算的上是认知上的挑战。软件测试不是仅仅为了验证功能，而是验证在验证其功能的基础上，去尽最大努力发现其没有做不该做的事情。第一章最后也留下了软件测试的小测验，非常建议新入行软件的测试或者对软件测试还不太了解的朋友尝试着做下，可能做完后你会发现，软件测试绝对是一项需要智慧才能完成的活动。
第二章的标题是「软件测试的心理学和经济学」，作者从经济学出发，告诉大家：软件测试无法穷尽测试，需要制定适当的策略（黑盒和白盒）来发现软件的缺陷。另外从心理学上来讲，软件测试应该致力于认为程序/软件是有问题的，用破坏性的思维去设计测试用例，用发散性的思维找出可能之前没有想到的问题，最终作者也给出了软件测试的十大经典原则：
-
原则1：测试用例中一个必须的部分是对预期输出或结果的定义。
-
原则2：程序员应当避免测试自己编写的程序。
-
原则3：编写软件的组织不应当测试自己编写的软件。
-
原则4：应当彻底检查每个测试的执行结果。
-
原则5：测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入情况。
-
原则6：检查程序是否“未做其应当做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”。
-
原则7：应避免测试用例用后即弃，除非软件本身就是一个一次性的软件
-
原则8：计划测试工作时不应该默许假定不会发现错误。
-
原则9：程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比。
-
原则10：软件测试是一项极富创造性、极具智力挑战性的工作。
在实际的软件测试活动中，我们需要时刻去反思自己是否遵循了以上原则，并应当时时刻刻地用原则去指引自己的软件测试行为，采用PDCA（计划，执行，检查，重复）的方法，不断优化我们的测试模型。
第三章讲到了「代码检查，走查与评审」，我相信除了一二线的软件公司，在其它大部分的公司里面，软件测试人员可能没有义务和权限去评审开发的代码。但不得不说的是：认真地阅读开发的代码，不仅能让自己的业务深度更深，还可以提升自己的技术层次，最终这种代码评审活动会让测试和开发两者产生深厚地联系。所以要做一个好的测试，尽量给自己创造机会，阅读开发的代码，对自己的以后的职场发展，绝对是大有裨益的。在百度的时候，几乎每个人都需要参与code review，对于测试而言，code review不仅帮自己了解清楚了业务逻辑，很多时候对开发代码的设计模式也是叹为观止。经常听有的测试同行抱怨技术得不到提升，其实主动去review 开发同事的代码，并多向其请教细节，就是一件能够快速提升自己代码能力的快捷之路。
第四章是「测试用例的设计」，这一章应该是很多测试小伙伴有共鸣的一章。作者分享了白盒测试，黑盒测试两种测试方法和实用的测试策略。白盒测试是检查程序内部逻辑和结构的一种测试方法，简单来讲：白盒测试需要对代码的分支逻辑进行足够多的用例设计，来验证每条语句的执行结果符合其预期性。白盒测试有如下几类覆盖深度（由浅到深）：
-
语句覆盖：较弱的准则，将程序中的每条语句至少执行一次。
-
判定覆盖或分支覆盖：较强的逻辑覆盖准则，必须编写足够的测试用例，使得每个判断都至少有一个为真和为假的输出结果。也就是说每条分支路径都必须至少遍历一次。
-
条件覆盖：比判定覆盖更强的准则，条件覆盖要编写足够的测试用例以确保将一个判断中的每个条件的所有可能的结果至少执行一次。
-
判定/条件覆盖：设计出充足的测试用例，将一个判断中的每个条件的所有可能的结果至少执行一次，将每个判断的所有可能的结果至少执行一次，将每个入口点都至少调用一次。
-
多重条件覆盖：要求编写足够多的测试用例，将每个判定中的所有可能的条件结果的组合，以及所有的入口点都至少执行一次。
从我个人的实际经验来看，从经济和效率的角度出发，我比较建议至少做到条件覆盖，如果能做到判定/条件覆盖更好。很多代码覆盖率检查工具提供了软件测试的代码覆盖度，一般都能分析出语句覆盖率和判定覆盖率。除了代码逻辑的覆盖，我们更常规的测试方法是黑盒的，通过程序功能，设计对应的测试用例，设计输入，判读输出预期，下面再看下黑盒测试：
-
等价类划分：简单来讲，就是把输入条件进行分类，分为有效等价类（代表对程序的有效输入）无效等价类（代表的则是其他任何可能的输入条件，即不正确的输入值），一分为二地对软件功能进行验证。
-
边界值分析：挑选出输入和输出等价类中的那些恰好处于边界、或超越边界、或在边界以下的状态，这种临界状态更容易发现一些非预期的问题。
-
因果图：是一种形式语言，用自然语言描述的规格说明可以转换为因果图，简单来讲就是通过"与,或,非"三类逻辑运算，梳理不同输入条件组合得到的结果。
-
判定表：对因果图的转换，最终方便设计测试用例。
-
错误猜测：利用直觉和经验猜测出错的可能类型，然后编写测试用例来暴露这些错误。
黑盒测试中，我觉得比较常用是等价类划分，边界值分析和错误猜测这三类测试方法，这三类测试用例设计方法能够覆盖80%以上的case。因果图和判定表虽然能够更全地设计测试用例，但由于互联网的迭代和节奏的原因，想要完全实践起来并不是那么有效，我建议在一些核心的功能点上去使用因果图判定表去设计测试思路，而在大多数的情况下，因果图可以作为梳理测试用例思路的辅助方法。最终作者也提出了建议的测试策略，先以黑盒测试为主，然后辅佐以白盒测试用例，在测试用例的设计过程中，尽可能地使用错误猜测。
第五章是「模块（单元）测试」，这一部分主要是讲如何设计单元/模块的测试用例，里面讲到了非增量测试和增量测试的两种测试方法。可能大部分的软件测试同行都没在实际的软件测试活动中写过单元测试，原因主要有两个：一是大部分公司不要求写单元测试用例，另外原因是单元测试一般由开发人员编写。我说说我的经历：我在阿里的时候参与过一个大项目的单元测试的编写，最大的感受就是：太过于完整的单元测试确实可以在早期发现很多问题，但是如果工期较紧，最终其实也会拖累软件工期。毕竟在软件开发初期，很多服务都没有一开始就打算完美，都是存在着各种不完美的实现，随着这个过程中不断重构，单元测试用例也需要重构，这个时候，测试用例的工作量可能比软件代码本身工作量还大。
另外再说说模块测试，模块测试其实比较适合现在的软件架构中的微服务模式，作为测试人员，可以基于模块的接口进行测试用例的设计，一般接口的代码稳定程度都还比较高，比函数或者类级别单元测试要稳定许多。和单元测试一样，如果采用的是自底向上的软件开发模式，我们需要及时编写测试驱动程序（driver），去验证已实现模块的功能；如果是自顶向下的软件开发模式，也可以使用mock的方式，编写stub（代码桩）程序，及时对已完成的模块进行输入逻辑的验证。
第六章是「更高级别的测试」，作者分别从如下维度，对功能测试之外的部分进行了测试类型补充。
-
能力测试：确保程序的目标功能实现。
-
容量测试：发现处理大容量数据时的程序异常。
-
强度测试：发现在大规模负载、高强度不间断持续的数据处理中的异常。
-
可用性测试：评估最终用户在使用软件并与软件交互时存在的可用性问题。
-
安全性测试：试图攻破程序的安全防线。
-
性能测试：评估程序的的响应时间和吞吐率。
-
存储测试：确保程序可以正确处理其对存储的需求。
-
配置测试：检查程序是否能在推荐配置上流程运行。
-
兼容性/转换测试：评估新版本是否能兼容老的版本。
-
安装测试：确保能够在所有支持的平台上安装软件。
-
可靠性测试：评估程序是否能达到规格说明中的运行时常和平均故障间隔时间要求。
-
可恢复性测试：测试系统恢复相关的功能是否按设计要求实现。
-
服务/可维护性测试：评估系统是否拥有良好的数据处理和日志机制，以备技术支持和调试之需。
-
文档测试：校验所有用户文档是否准确。
-
过程测试：对软件操作系统或维护所需涉及的流程进行评估和确定。
以上测试方法其实是"点点点"软件测试工程师晋升为高级工程师的必经之路：功能测试只是第一步，只有能够覆盖更多维度的测试内容，我们才能成为真正意义上的质量保障工程师。
第七章是「调试」，这一章节主要讲如何调试软件功能，定位问题。可能大部分的业务测试人员还无法完全领会其精髓。如果是做测试开发的朋友，可能会经常需要和代码调试打交道，调试脚本，工具或者平台的一些业务逻辑。文章讲到了蛮力法，归纳法，演绎法，回溯法，测试法这五类方法去调试自己的程序。其实我们可以借鉴这种作者提出这几种思路，用于复盘我们日常生活和工作：到底问题出现在哪里，其原因是什么，有没有更深层次的原因，如何避免下次再犯此类错误？
第八章是「极限测试」，其对应的是互联网敏捷开发下的一种测试模式，其内容更多地是讲了一些XP的软件开发与测试原则，可能更多是说给开发人员的，但从中我们也能了解到，测试活动只有通过左移，并高频率和相关上下游沟通，才能最有效率地提升软件开发和测试效率。
以上就是《软件测试的艺术》的主要内容，希望对大家有所启发，最后我也精心整理出来一张脑图，方便大家预览本书的全部核心内容，大家可以在本公众号「测试生财」后台回复关键字：软件测试的艺术，获取高清大图还有对应电子书资源。
如下是我整理的缩略图：
最后，为了感谢各位朋友的长期以来的支持，我也给大家准备了《软件测试的艺术》第三版的纸书的送书活动：给有缘的朋友免费送出共计两本《软件测试的艺术》原书第三版。
活动时间：2021.03.29~2021.04.03晚19点。
参与方式：关注本微信公众号「测试生财」。
参与人：已关注公众号「测试生财」的朋友。
送书规则：
1. 在公众号文末留言板中积极留言：取留言数获赞数最高的一位赠送《软件测试的艺术》第三版，点赞截止时间为2021年4月3号晚上19点。
2. 在文末的送书问卷中填写问卷，我将最终根据反馈内容的质量高低，额外送出一本《软件测试的艺术》给反馈最给力的小伙伴，问卷填写截止时间为2021.04.03晚上19点。
温馨提示：
以上两个送书活动规则不重叠，也就是如果你在留言板中获取了足够多的点赞，又给出了给力的问卷反馈，那么就可以拿到两本哦~
送书方式：
联系财哥微信「qa_freeroad」，私发下你的邮寄地址和联系方式，财哥将第一时间为你寄出书籍~
送书问卷活动地址：https://jinshuju.net/f/Ak1zuI
二维码：
传送门：2021最新测试资料&大厂职位
博主：测试生财（一个不为996而996的测开码农）
座右铭：专注测试开发与自动化运维，努力读书思考写作，为内卷的人生奠定财务自由。
内容范畴：技术提升，职场杂谈，事业发展，阅读写作，投资理财，健康人生。
csdn：https://blog.csdn.net/ccgshigao
博客园：https://www.cnblogs.com/qa-freeroad/
51cto：https://blog.51cto.com/14900374
微信公众号：测试生财（定期分享独家内容和资源）
