软件测试之困：测试工程化实践之路

版权信息

书名：抢读版-软件测试之困：测试工程化实践之路

ISBN：978-7-115-59933-9

本书由人民邮电出版社发行数字版。版权所有，侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

版　　权

著    肖利琼

责任编辑 张 涛

人民邮电出版社出版发行　　北京市丰台区成寿寺路11号

邮编　100164 　电子邮件　315@ptpress.com.cn

网址　http://www.ptpress.com.cn

读者服务热线：(010)81055410

反盗版热线：(010)81055315

内 容 提 要

本书以软件测试工程化思维为基础，立足项目，采用描述、对话和独白等方式讲述测试工作中发生的故事，内容丰富，实用性强，是一本能帮助测试人员快速成长的图书。

本书首先介绍了测试工程化的认识和测试人员的商业意识；接着介绍了测试流程设计，以及如何通过流程拉齐各成员之间的目标，达到成员之间的合作有序和软件产品的质量可控；然后通过流程与技术的融合、测试用例规范化编写、测试平台建设和测试创新4个重要测试主题的讲解，指导测试同行在测试工程化的道路上不断探索并找到流程、技术的最优解；最后介绍测试工作评价过程中的常见问题及解决方法。

本书既可作为测试主管（或测试经理）和一线软件测试人员的进阶读物，又可作为软件开发及相关专业人士的参考用书。

序　　一

软件测试工程化是一个朴素、自然的概念，但许多人并不理解这个概念。多数软件测试人员的工作岗位是“测试工程师”，如果不理解“软件测试工程化”，就谈不上测试工程的落地。

什么是软件测试工程化？要弄清楚这个概念，首先需要理解什么是工程化，如软件研发如何从作坊式研发上升到软件工程式研发（可参考阿朱于2009年出版的《走出软件作坊》）。工程化一般从项目目标出发，经过获取需求、分析需求、方案设计、实现落地等一系列规范操作，实现阶段性目标，最终在预算内按时、保质、保量地实现业务目标，甚至可以做到“多、快、好、省”。工程化中存在计划、分析、设计、实施和评价等关键环节，而且重视项目管理、质量管理和工具的使用等，具体体现在3个方面：系统化、模块化和规范化，即能够系统地解决问题，而不是片面、局部地解决问题；面对复杂问题，能够逐层分解问题，然后各个击破；最终把解决问题的思路梳理成合适的流程、策略和模式等，并持续改进，保证软件测试能够持续、稳定地进行。

读者基于上述理解，就容易理解软件测试工程化、测试计划、测试分析和测试设计等的重要性。在面对测试风险时，也会清楚如何寻找合适的测试策略来应对，并了解如何通过测试流程更好地保证测试质量，如何通过自动化测试提高测试效率，以及如何规范测试行为、评价测试结果等。这些都是测试中的重要工作思维，也就是工程化思维。测试的目的是守护质量，因此“防守”要全面、系统，尽可能做到万无一失，否则上线后某个功能特性可能出现严重缺陷，影响交付质量。测试工作符合“木桶原理”，即表现最差的环节会降低测试的整体水平。在测试工作中，工程化的思维和实践尤为重要，因为每一个环节都需要测试工程化的支撑。软件测试有以下发展趋势：从性能测试、安全测试发展为性能工程、安全工程，从测试发展为质量工程。

本书从测试工程化的角度出发，关注市场需求和业务价值的实现，努力找到质量和进度的平衡点，帮助测试人员建立工程化思维。本书重点讨论测试流程设计、测试用例规范化、测试平台的建设、技术与流程的融合、测试工作评价和测试创新等主题，每一个主题都和测试工程化紧密相关。测试人员想要做好测试工作，本书涉及的这些内容不容忽视。因此，我们不是为了工程化而工程化，而是为了项目成功和业务成功的需要。现在，自动化测试和测试开发大行其道，除测试平台建设以外，其他环节容易被忽视，作者在这个时候写作这样一本书，就是为了点醒许多“梦中人”，提醒他们不要忘记测试之本，更不可本末倒置。

本书在写作时使用了对话和独白的方式，可使读者身临其境，切实感受所处的工作场景，从而更容易理解作者的经验和思考。

本书围绕实际案例介绍测试工程化的方方面面，内容丰富，语言活泼生动，读者在阅读中会感到轻松愉悦，在阅读后会感觉印象深刻、回味无穷。相信读者会喜欢本书，并从中受益。

——朱少民

同济大学特聘教授

《全程软件测试》《敏捷测试：以持续测试促进持续交付》作者

序　　二

2006年，我作为一名测试工程师，赴香港并现场支持一个新特性的首次商用。为此，我进行了3个月的充分准备：熟悉需求、设计测试用例、搭建测试环境、执行测试、提交一堆bug、与开发人员一起定位问题和开展多轮回归测试等。通过努力，我对这个特性涉及的每一个需求场景、曾经出现的每一种bug类型、目前的质量现状，以及如何开启“后门”进行测试和调试，了如指掌。

在特性开通的当晚，我在客户的机房中守候了一夜，并且在接下来的几天，持续关注各种指标是否正常。在观察后台的日志时，我被频频报出的错误码惊出了一身冷汗。从以往的经验来看，每个错误码意味着系统里可能潜伏着一个严重的bug。可是，这并没有引起其他人的注意，因为没有用户抱怨，客户也没有任何感知，现场反而一片称赞声，认为本次特性的商用开通非常成功，他们对我的现场支持表示感谢。

虽然客户对我的测试工作表示认同，但是我对自己的测试工作却产生了质疑。在返回的途中，我一直在思考两个问题：

● 我平常那么看重并全力以赴的测试工作，意义究竟何在？

● 新特性在上线运行后明明有那么多错误码和潜藏的bug，为什么客户和用户都不在意？

对于这些错误码，测试人员和开发人员通常会如临大敌，想尽一切办法降低它们发生的可能性。为此，我们耗费了大量的时间和精力。

我清晰地记得，每当我在实验室发现一个错误码被触发的场景时，就会立即记录准确的信息并保留现场环境，然后让开发人员定位分析，最后修改代码，并验证问题是否重现。

在平时的实验室测试中，只有反复尝试，才能“幸运”地触发一个错误码，然后提交一个有效的严重bug，就像找到“宝藏”一样；而在客户现场，我什么都不需要做，只是把特性开通上线，就有一堆错误码出现在面前。令人意想不到的是，现场的客户关心的一些运营指标等，我在测试中却完全没有关注过！

如何才能高效地开展测试呢？如何设置合理的测试目标呢？测试价值又是通过什么体现的呢？

如果我只是把自己局限为一名普通的测试工程师，那么上述问题可能一直困扰着我。幸运的是，经过几年的不断思考，我渐渐明白，要从“测试工程商人”的角度思考问题。

阅读本书时，我欣喜地发现，本书开篇就讲述了“测试的工程化”和“测试人员的商业意识”，并且以“房子验收”的比喻和人物对话的形式，生动、形象地诠释了“测试工程商人”。相信本书这样的安排会为很多与我同样处于“困扰中”的测试人员打开一扇窗，启发大家重新思考测试的价值。

本书引用了“敏捷铁三角”模型，启发我们对测试工作进行进一步思考。

● 系统的视角：从测试的约束（时间、范围和成本）、质量的目标和要求，以及对客户的价值等维度出发，系统地考虑如何做出每一个测试的决策。

● 平衡的艺术：测试是一种平衡的艺术，需要我们在一系列问题中进行平衡和取舍：测试什么，测试到什么程度，如何变化和追踪测试的移动靶向目标，如何分配测试的投入，如何分配测试的时间，重点测试哪些质量属性，如何设定合理的质量目标，如何从用户的角度进行测试，以及针对哪种用户的哪种价值进行测试等。

● ROI最大化：正如本书提到的“测试是一种投资”，需要追求投入产出比（ROI）的最大化。这不仅仅是针对测试经理等管理者而言，而且每一位测试人员都应该在自己负责的工作范围内，像“测试工程商人”一样思考如何基于风险开展测试活动。当没有时间继续测试，又必须马上发布时，你是否能够确保所有已经完成的测试都比那些还没有开展的测试的优先级更高？你是否已经优先测试了那些风险和优先级更高的部分，让严重bug尽可能多地尽早暴露？

本书穿插了众多“小故事”，这种写作风格可以让读者的阅读感到轻松愉悦，而且这种写作风格在技术类图书中难能可贵。这些小故事贴近日常工作，这得益于肖利琼平时收集各种素材和持续不断地思考测试领域的各类问题，我们能感受到她的用心和细心。她作为一名测试“老兵”，其敬业精神令人钦佩！

建议各位读者寻找一段属于自己的休闲时光，沏一杯茶，轻松惬意地阅读书中的小故事，开启不一样的“奇妙”测试之旅！

——邰晓梅

“海盗派”方法学创始人

对本书的赞誉

本书作者肖利琼不但是杰出的软件测试专业人士，而且是优秀的软件测试团队主管。本书是作者在软件测试领域多年实践的总结，讲授的不仅仅是软件测试的技术和实践经验，而且更是在传递软件测试工程化思想——一种将软件测试作为商业投资活动并与业务的商业成功相结合的理念。相信这种理念不但会让读者得到启发并在实践中受益，而且会助力企业取得成功。

——李新胜

迈瑞生物医疗电子股份有限公司集团副总裁

在数字化转型时代，软件测试工程化是非常复杂的，相当依赖测试人员在具体工程实践过程中积累的经验。在此过程中，我们会面对层出不穷的新技术与新工具。此时，我们需要以不变应万变，掌握软件测试的底层逻辑，透过纷繁、复杂的表象，回归软件测试的本质，以测试策略设计为主线，有目的和有针对性地开展各项测试活动。本书提供的理论与实践内容可以很好地体现上述逻辑。本书值得软件测试从业者细细品读。

——茹炳晟

腾讯Tech Lead、腾讯研究院特约研究员、《测试工程师全栈技术进阶与实践》作者

肖利琼是软件测试领域的实践型专业人士。本书是她多年从事软件测试工作的又一标志性成果，闪耀着测试工程化思维的光芒。本书通过生动的测试故事、真实的项目案例、有趣的简笔画，将测试思维、测试技术、测试流程、测试评价融于一体。本书写作风格清新，令人爱不释手，阅读时犹如春风拂面。她提出“测试人员应该具备商业意识、标准化意识、创新意识”，这在测试领域具有前瞻性和导向性。

——崔启亮

北京昱达环球科技有限公司培训经理、中国软件测试认证委员会（CSTQB）资深专家

本书是肖利琼20多年实践经验与思考的总结，她将测试工程化的思想与方法娓娓道来，破解了测试人员面临的诸多困惑。测试生涯犹如攀登高峰，山路崎岖漫长，却奇景不断。读者以本书为手杖，在漫漫实践路上推敲和探索，一定能更上一层楼。

——史亮

《软件测试实战：微软技术专家经验总结》作者

本书通过生动的故事、对话，以及轻松的文笔，阐述了测试工程化的理论和实践，剖析了测试的深层机理，值得测试从业者阅读。

——陈晓鹏

测试、敏捷及DevOps专家

本书从测试工程化的角度提供测试实践中的经验，让人眼前一亮。本书作者结合自己的丰富项目经历，发掘出了大量测试实施过程中的痛点，并针对这些痛点给出了切实的解决方案和实施建议。无论是测试行业的新人，还是测试项目的管理人员，都可以阅读这本“接地气”的佳作。

——吴晓华

光荣之路测试开发培训创始人

肖利琼从事软件质量工作20多年，一直在思考和寻找测试工程化的方法并付诸实践，希望能够通过工程化方式将测试工程师从繁琐的测试工作中解放出来。本书是肖利琼多年软件工程化实践与思考的总结，是市面上测试工程化相关读物的上乘之作，给测试行业从业者在测试工程化方面的探索指明了方向。

——薛亚斌

京东金融

肖利琼在软件测试领域深耕20多年，积累了大量的软件测试工程化实践经验，她现将这些经验进行梳理并集结成书。

你可以将本书放在办公桌上，当在工作中有疑惑的时候，可以翻开它，从中寻找适合自己的解决方法。本书提到的“测试人员的商业意识”尤其值得细细品味，或许会带给你新的启发。

测试是一项没有终点的实践技术，正因为如此，它才值得我们不断探索。

——杨晓慧

华为前测试专家、AI机器时代公司首席技术官

前　　言

为什么写本书

2010年前后，业界很多人都在讨论“软件测试的未来”这个话题，相当一部分人认为手工测试必然终结，未来将是自动化测试的“天下”。后来，作者作为面试官，参加了多场招聘活动，发现上述言论对当时的测试从业人员和打算从事测试工作的人都产生了深远影响。在某个周末，作者写了一篇以“软件测试的未来”为主题的评论文章，然后将它发布到国内知名测试网站51Testing上。在该文中，作者提到了业界人员当时普遍存在的迷茫、浮躁等问题。第二天早上，该篇文章的点击量破千，并成为该网站置顶的头条文章。

12年过去了，IT界发生了诸多大的变化，软件测试领域也随之发生了很大变化。随着智能化时代的到来，软件出现在我们生活、学习和工作的各个角落，一些优秀的软件甚至改变了我们生活、学习和工作的方式。例如，网络购物、网络聊天、线上云课堂、线上办公和生活机器人等，软件在它们中起到了关键作用。软件本身的特性决定了工程化软件不可能没有bug，这也决定了有软件存在的地方便有软件测试的需求。软件测试工作的本质是通过发现问题来守护软件质量，正如很多同行提到的，测试是一项“挑刺”的工作。

软件市场瞬息万变，测试行业在遵循市场规律的同时也在变化，但我们会发现，测试的底层逻辑是不会变的。每个测试人员的测试思维是不一样的，任何方法、工具都不能代替它，这与手工测试、自动化测试的测试手段并无直接关系。测试思维背后的内容有很多，不但包括测试人员对现有业务的认知，而且包括测试人员已掌握的编程语言、数据库、操作系统和网络等基础知识，以及测试人员思考问题的方式，而这涉及抽象能力、心理学、经济学等技能和知识，这些都将影响测试人员采取何种策略开展测试工作。

作者一直在测试领域耕耘，并且经常与业界人士探讨测试技术的变化与发展。每当在某些方面有所感悟时，作者就会将它们记录下来，当积累到一定程度时，总想拿出来与大家分享，以期帮助更多的测试从业人员成长，共同推动行业发展。

2020年年初，突如其来的新冠肺炎疫情打乱了我们原来工作与生活的节奏，但是在这段时间里，作者有了更多时间思考如何进行软件测试，并将多年测试经验梳理成测试知识体系。尽管市面上软件测试类的图书不少，但作者发现很多图书采取“教科书式”的讲解方式，不够生动，难以吸引读者，于是作者尝试改变写作风格，在不失科技类图书严谨性的同时，采取描写、对话和独白等方式讲述测试工作中发生的故事，并给出研发工作的实际场景，读者可以从故事和场景中感悟测试技术、测试流程的变化或创新的价值。

由于作者水平和时间有限，书中难免会存在一些问题，欢迎读者批评指正，并与作者联系（邮箱为ch_testinfo@126.com）。本书编辑联系邮箱为zhangtao@ptpress.com.cn。

致谢

按照讲故事的方式编写科技类图书，这的确给作者带来了不少挑战，但是，作者的初心不变，直面挑战，最终完成了本书的写作工作。在此，感谢人民邮电出版社编辑的鼓励与支持。

感谢我的女儿，本书中的简笔画均由女儿张顺媛创作，尽管她学业繁忙，但是依然抽出时间进行创作，这无疑给了我极大的支持。感谢我的先生张滔清，他一直在背后默默地支持我，他也是本书的第一位读者。

感谢朱少民、邰晓梅在百忙之中抽出时间为本书作序，并为完善本书提出了许多宝贵建议。同时，感谢所有为本书写推荐语的同行。

肖利琼

2021年9月21日

第1章　测试工程化的认识

本章简介

在本章中，我们将从工程化角度介绍软件测试，首先以“房子验收”为例进行类比，帮助读者理解什么是测试工程化；然后通过“填写测试用例的故事”“测试经理的尴尬”和“工作量评估的差异”3个案例阐述测试工程化对测试工作的意义；最后阐述工程化的测试工作会带给测试人员哪些收获和挑战。

1.1　什么是测试工程化

在项目的实际开展过程中，我们经常面临如下场景：

● 需求不断变化，然而软件交付时间不变；

● 开发人员将版本发布延期，但没给测试人员留下太多测试时间；

● 在项目经理要求的新功能上线后，市场人员的反馈是新功能基本没人用。

在面对上述场景时，作为软件测试人员的我们可能会感到压力，因为我们不仅有产品交付的紧迫感，还要守护软件质量。随着项目迭代过程的推进，我们可能发现测试人员并不一定能够在早期就参与到项目中，以及测试人员发现的bug并不一定能及时得到修复。有时，我们会遇到软件版本上线时间临近，无论是已发现的bug，还是不符合需求的设计，都可能不再修改的情况。我们可能并不赞成带缺陷的版本上线，但产品经理认为已知问题风险可控，版本必须发布，此时我们需要或可以接受目前的版本。

为什么呢？这个决策的背后其实遵循一个原则：测试是一种商业性投资活动。而作为投资活动，投资方必然考虑产品的投资回报率（Return On Investment，ROI），即产品价值问题。这些正是“敏捷铁三角”模型（见图1-1）所要表达的重要思想。

图1-1　“敏捷铁三角”模型

在一般情况下，所有产品的开发都会受到其价值、质量和约束的限制。其中，约束是指产品的开发受到投入成本、产品功能范围和产品发布进度的共同约束，三者关系紧密，相互影响。软件测试活动也不例外。本书探讨的测试工程化正是这种围绕产品价值的一系列测试活动而有序进行的过程。测试工程化是一个系统化、模块化和规范化的复杂过程。

为了便于读者进一步理解，作者以“房子验收”为例进行类比。下面是关于“房子验收”的故事（本故事仅为类比，与实际房子验收有出入）。

某天，一位名叫陈师的测试专业人士，将一群测试行业“小白”带到一个房子验收现场，现场示意图如图1-2所示。

图1-2　房子验收现场示意图

陈师：这面墙由什么组成？

小白A：红砖、钢筋、水泥和砂石。

陈师：好！这面墙的完成质量如何？

小白B：墙已经封顶，而且墙的表面看上去很平整，但墙的完成质量如何评判呢？

陈师首先用锤子在墙面上敲了几下，然后用放大镜看了看，最后用铁凿在红砖之间的接缝处凿了几下。

陈师：你们听到和看到了什么？

小白C：敲打的声音，有些红砖在敲打后出现了裂痕，而且红砖之间的接缝处掉渣子了。

陈师：昨晚，施工队长告诉我，房子可以验收了，你们就把这个房子当成软件发布的版本吧。大家看看我手上的放大镜、锤子和铁凿，它们可都是验收房子的“利器”呀！我手上的这把锤子很特别，它可以更换几种不同形状的锤头，我在墙面的不同地方使用不同的锤头和不同的力敲打，发出的声音是不一样的。这些锤头和力的组合构成了多种验收方法。通过放大镜，我们可以看到墙面上不易觉察的纹理。根据纹理，我们可以决定使用何种锤头与力的组合来敲打墙面，这与软件测试中的工具和方法的应用类似。在软件测试中，工具和方法的不同组合构成了软件的不同输入，不同的输入会带来不同的输出。我们可以把敲打红砖后出现的裂痕理解为软件的某个功能函数有bug，需要进一步判断是否修改。红砖之间的接缝处掉渣，说明它们之间的连接有问题，不能通过验收，这就像软件模块之间的接口有问题。如果模块间的耦合度高，那么我们需要考虑优化或重构。

小白A：哦，原来如此。但是，对于砌好的墙，我们为什么要用锤子、铁凿去破坏呢？这好像是在拆墙。

小白B：陈老师想表达的是一种测试思想。软件测试不是让你与开发人员对着干。为了测试软件的质量，测试人员需要应用一系列工具和方法。另外，测试人员还需要对软件的功能、性能等进行验收与评价。

此时，陈师冲小白B笑了笑，然后说：是的。

陈师接着说：开发人员通过编写代码实现了软件的各种功能。我们可以将一块块红砖看成一个个函数。函数是软件代码中的最小单元。当批量的红砖通过水泥、砂石和水砌在一起时，就会形成一面墙（见图1-3），这面墙可以发挥比一块砖更大的作用。同理，函数通过多层调用，形成功能模块。多面墙连接在一起，相当于软件的模块集成。这些墙经过组合后，就可以形成一座完整的建筑，如一栋3层的楼房。软件开发建造的是软件“房子”。这个“房子”既可以是可独立运行的App（Application，应用程序），如手机上的备忘录App，又可以是复杂的控制系统，如航空航天软件系统。

图1-3　由红砖砌成的一面墙

为了方便读者理解，作者将建造房子和开发软件进行对比，见表1-1。

表1-1　建造房子与开发软件的对比

小白C听后恍然大悟：原来如此，事物是相通的。

小白C：陈老师，软件测试中有黑盒测试和白盒测试，它们分别适用于何处？

陈师：这个问题提得好！对于功能模块的测试，我们通常采用黑盒测试。白盒测试可用于单元测试、模块集成测试和接口测试。

小白B：对于软件测试，我理解为“拆房子”，也就是逆向思维有利于发现并解决问题，从而更好地守护软件质量。

陈师：“拆房子”这种逆向思维虽好，但并不全面、系统，我们还需要从软件构建的整个体系出发，通过工程化方式，思考如何在软件生命周期的各阶段更好、更快地发现问题。例如，在需求阶段，我们可以纳入需求测试活动，也就是在开发人员未开始编码之前，解决需求问题，避免软件项目未实现需求而推倒重来，从而避免浪费开发人员和测试人员的时间。从产品软件在研发端交付后的后续流程来看，软件在产品量产环境下的安装和售后的用户服务是否方便，以及软件在客户端是否易用等，都是我们在软件生命周期内需要考虑的质量要素。对这些要素进行评估的活动通常称为非功能性DFX^[1]测试。

[1]　DFX（Design for X，面向产品生命周期各环节或特性的设计），X表示产品生命周期的某一环节或特性，如可制造性（Manufacturability）设计称为DFM，可装配性（Assembly）设计称为DFA，可靠性（Reliability）设计称为DFR，等等。

作者认为，只有具备良好工程特性的产品，才是满足客户需求的好产品。软件测试始终需要围绕全链路的工程特性开展，这样才能全面、系统地守护软件质量。

1.2　填写测试用例的故事

一直以来，一些人对软件测试存在如下认识误区：

● 软件测试就是用鼠标随便点击几下；

● 从事黑盒测试工作没有前途，软件测试人员应向自动化测试、性能测试和安全测试等专项测试方面发展，或者从事测试工具的开发工作；

● 软件测试如果不包含需要编码的技术工作，就没技术含量。

下面以“填写测试用例的故事”为例探讨产生这些认识误区的原因，帮助读者建立正确的认知。

测试用例的准确性和充分性决定着对软件中存在问题的揭露能力。测试用例对测试工作的重要性不言而喻，但测试用例的设计与代码的编写并没有必然联系。

Carl是作者的朋友，同时是消费电子产品领域的软件测试专业人士。某天，他和作者分享了让他感到意外的一次与测试用例设计相关的面试（作为面试官）经历。

Carl：请介绍一下你在工作中执行一项具体测试任务的流程。

应聘者：首先，组长安排任务，然后，我们直接在手机上测试APK（Android Application Package，Android应用程序包）。

显然，应聘者的回答并不是Carl想要的答案，于是Carl对应聘者稍加提示。

Carl：领到任务后，你首先做什么呢？

应聘者：开始测试，也就是在手机上测试。

Carl认为应聘者还是没有明白他的意思，于是再次提示。

Carl：你们进行测试分析、测试用例设计吗？

应聘者：我们会填写测试用例，但好像没有测试分析与测试用例设计活动。

Carl当时第一次听到“填写测试用例”这样的说法，感到很诧异。Carl认为测试用例是设计出来的，他不明白测试用例为什么是填写的。

于是，Carl问：“填写测试用例”是什么意思？

应聘者：我们的项目属于外包项目，任务交付时，需要输出测试报告。因此，我们事先复制外包项目的需求内容，并将它们粘贴到测试用例表格中。当执行完测试用例后，我们再在“测试结果”栏中填上“PASS”（通过），我们将这个过程称为“填写测试用例”。

Carl突然明白，原来应聘者对软件测试的认识与其工作环境有密切联系。

如果读者作为应聘者，那么应该如何回答Carl的问题？虽然答案并非绝对，但可以在一定程度上反映读者对测试工作中测试分析与测试用例设计的认识。

点评

在Carl与作者分享了那次经历后，我们就此事进行了热烈讨论。最后，我们一致认为，在测试工程化的路上，技术只有为客户解决问题并创造价值，才是有意义的。目前的软件市场中仍然存在大量项目外包的情况。在从事外包项目的公司中，与上面提到的“应聘者”从事类似工作的人不在少数，这可能会令相关人员产生“测试就是用鼠标随便点击几下”“测试没有技术含量”等认识误区。

1.3　测试经理的尴尬

Sherry是作者的朋友，同时是一家国际知名医疗设备外企的测试经理。在一次讨论测试技术的应用时，她给作者讲述了一个被部门总监A质疑的故事。

某天，部门总监A请Sherry到其办公室，让她解释一下什么是软件测试技术。Sherry被问得一头雾水，不明白背后发生了什么事情。Sherry心想，这位总监也曾是程序员，不可能一点都不了解软件测试，肯定是自己工作的某个方面出了问题，而且是他认为相当低级的问题。但这位总监有些“古怪”，偏偏不提及提问背后的原因，只是要求Sherry给他解释什么是软件测试技术。Sherry只好根据自己所学知识和过往经验，介绍了软件测试的方法、工具，以及如何应用等，但总监似乎不太满意，不断追问。

在这样的场景下，Sherry感到尴尬和委屈，因为部门总监A的问题难以用三言两语讲清楚，甚至这个问题太基础，部门总监A不应该向她提问。虽有不解，但Sherry还是在离开部门总监A的办公室后思考良久。

后来，Sherry了解到，其他研发部门开发的产品因软件质量问题被召回了上千台，风险意识极强的部门总监A想要仔细了解自己部门研发的产品是否存在类似问题，于是查看了相关软件测试报告。其中，关于仪器测量病人血液数据的保存正确性的测试用例很少或不充分，甚至大部分测试用例只用来检查界面显示情况，如某按钮亮显、某按钮灰显等。部门总监A认为，这样的测试不但毫无重点，而且无关痛痒，是“表面”测试。于是，才发生了上面的对话。

根据Sherry后来的描述，部门总监A是对图1-4所示的“测量数据浏览”界面的测试工作产生了质疑。

图1-4　“测量数据浏览”界面

为了测试图1-4所示的界面上的软件功能（此界面由用户单击前一界面中的“浏览”按钮进入），测试人员设计了一批测试用例，表1-2是相应的测试报告。

表1-2　“测量数据浏览”界面测试报告

一开始，Sherry感到有些委屈，但在她仔细看完这份测试报告后，也认为测试用例的设计不够严谨和专业。后来，她带领团队重新梳理了测试用例设计规范，以及测试用例的设计模板与方法等，并以流程规范为指引推动它们在项目中落地，最终收到成效。

优化之后的“测量数据浏览”界面测试报告见表1-3。

表1-3　优化之后的“测量数据浏览”界面测试报告

点评

对于表1-2所列的测试用例，“预设条件”“测试用例标题”“操作步骤”和“预期结果”中的内容有多处相同或类似，根据每条测试用例的唯一性要求，测试用例的设计与组织明显存在问题。在查看他人编写的测试用例报告时，我们只有了解测试用例设计人员的思路，结合被测试对象的用户需求和软件设计的实现原理，如用户浏览数据的主要目的、目前的实现结果是否满足用户需求、浏览数据从何而来、浏览数据时可能遇到的问题，以及是否设计了相应的测试用例等，才会发现测试用例的缺失或冗余之处，以及漏测带来的风险。

测试用例是测试工作的重中之重。无论是测试通过的测试用例，还是发现bug的测试用例，都是测试人员的重要产出，它们是守护产品质量的关键。

如果我们的测试分析高效，测试用例的设计充分，那么，就可以既守护产品质量，又不影响产品上市时间。

1.4　工作量评估的差异

“凡事预则立，不预则废”。在项目立项前，对研发各专业方向工作量的评估便是“预”，工作量评估的准确性对“立”有重要影响。企业通过立项方式管理产品的研发过程是一种投资行为，研发人力成本（与工作量对应）通常是其中最大的一笔投入。如果对研发各专业方向评估的工作量太大，那么项目不一定立项成功；如果评估的工作量太小，那么产品可能不会按期交付，继而影响产品上市销售时间。可以看出，项目立项前的工作量评估是一项重要活动，我们需要综合多方面因素对工作量进行评估。

Sherry所在企业研发的产品首次上市时必须提供中文和英语两种语言功能。在产品上市以后，根据市场需求，该企业还会陆续推出包含其他语言（如法语、德语等）功能的产品，以满足全球用户的需求。

产品本地化是在现有产品的基础上实施的，属于工程改进性项目。以软件为例，一般情况下，软件在设计之初已考虑了国际化需求。对于具备多语言功能的软件产品，我们在测试时需要先进行沟通与模板制作工作，再设计测试方案和测试用例。

关于软件产品多语言功能的测试，Sherry讲的一个故事让作者印象深刻。某天，Sherry所在公司的软件总监J（下称总监J）找到她，并询问了多语言功能测试相关的问题。

总监J：目前，你们测试一种产品的某一种语言功能需要多长时间？

Sherry：以一个含4000条字符串的中等规模的产品为例，测试工作量多则5人天，少则3人天，平均为3～4人天。

总监J在听取某个新部门的测试人员的汇报时，得到的答案是1人月。他觉得两个部门存在这么大的差异，有些不可思议，于是询问Sherry是如何开展相关工作的。

Sherry：通过实践，我们已摸索出规范的流程和方法，同时开发出了相关工具，才确保实现了这个效率的提升。

总监J：包括哪些流程、方法和工具呢？

Sherry：流程与多语言项目的运营有关。就我们公司而言，多语言的翻译由专业翻译组或专业翻译公司完成。翻译的结果由软件读取并显示在界面上，翻译的结果和质量对软件测试的工作量有重要影响。例如，对于某个术语，其俄语字符比英语字符宽，翻译返回的俄语结果显示在界面上时，可能出现超长问题。这样，我们需要多次沟通和修改，才能让该术语对应的俄语字符满足软件界面的显示要求。那么，在第一次将中文字符串发给第三方翻译公司前，我们是否可估算出字符串在界面上能够完整显示的宽度呢？可以。于是，我们开发了一款小工具，该工具可以方便地获取软件的界面、对话框、提示框和按钮等控件资源显示的长度，并把此长度作为翻译结果的最大长度（maxlen）进行约束。关于外发翻译的对象、翻译的质量要求和相关费用等，我们与翻译组或翻译公司开会讨论。在了解了翻译组或翻译公司的工作流程后，我们共同设计了一个“字符串翻译承载模板”，见表1-4（最大长度要素便体现在其中）。在流程规范中，模板是一种常见的解决问题的标准化方法，是工程化的一种体现。按照流程规范做正确的事，可避免我们工作无序时的返工。在采用了此模板后，后续翻译返回的字符串超长的问题大幅减少。例如，原来3000个字符串中就存在300多个字符串在界面中显示超长的问题，比例大于10%，而现在我们可以控制在1%左右。这种接口流程、交付方法的变化大大提升了后面测试验证的效率。

表1-4　字符串翻译承载模板

总监J：这是一种比较好的从源头控制字符串超长的好方法。在面对翻译字符串超长的情况时，你们是否也需要调整软件的界面，使之适应不同语言的字符串，以达到完整显示的目的？

Sherry：在面对这种情况时，我们遵守一个原则，即对于多语言的界面显示，尽量不调整界面。对软件的改动尽量小或不对软件进行改动，因为软件的设计是同一套代码，共享同一套界面布局，如果为了适应某种语言而调整界面的宽度，那么在显示其他语言时可能带来问题。

总监J：明白了。在字符串翻译回来后，你们如何开展后续工作？

Sherry：我们会按照规范的测试流程进行相关工作。在领取任务时，我们需要进行测试方案的设计，即启动多语言测试方案和测试用例的设计。我们的团队经历了多个产品的多语言测试工作，积累了不少经验，形成了可复用的平台性测试方案。同时，我们总结了不同语言的本地化习惯和基于我们的软件的设计特点而需要关注的特性，获得了一套稳定、可复用的测试用例。当开发的新产品需要增加多语言功能时，测试人员无须从头开始分析和设计多语言相关的测试用例，只需将从公共测试用例库中筛选出的测试用例放到新产品上执行即可。

总监J：这套流程及方法很实用，能够提升整个团队的工作效率。你们可否将这些经验和做法分享给新部门的测试人员？他们那边有个刚上市的新产品，该产品亟需支持多语言，现在的主要瓶颈在测试方面。

Sherry站在公司发展的角度，答应向新部门的同事提供帮助。

点评

从上述总监J与Sherry的对话中，读者得到了哪些启发？或许，Sherry所在团队的有些做法值得读者学习。多语言测试工作需要测试人员细心、耐心，又需要多种技巧、方法和工具，在工程实践中，还有很多值得我们挖掘的地方。

多语言测试涉及软件的国际化设计、国际化测试，关于它们的详细讲解，读者可参考崔启亮和胡一鸣编写的《国际化软件测试》。

1.5　测试专业人士眼中的黑盒测试

上面4个故事都与测试技术有关，通过阅读它们，读者应该对测试技术及其应用有了自己的理解。

测试行业新人经常会对软件测试包含哪些常用方法，以及如何学习软件测试等问题感到困惑。测试方法是多种多样的。在开发不同类型的项目和遇到不同的问题时，我们采取的测试策略和测试方法有所不同。在多年的测试工作中，作者使用较多的是以业务为主的系统测试。

作者所在团队的测试人员勇于挑战，敢于尝试。当遇到偶发性漏测bug时，我们尝试开启内存泄露测试、压力测试和性能测试等专项测试；当出现黑盒测试的“盲区”时，我们积极寻找其他手段修复bug，包括静态代码分析、动态代码调试和插桩编译等白盒测试方法；当因开发人员对项目更改而有可能出现测试不充分的情况时，我们采取灰盒测试方法，或者通过代码覆盖率分析方法设计相关测试用例，进行补充测试；当需要提升测试效率时，我们会有针对性地开发一些测试辅助工具，或者引入业界已有的自动化测试框架或工具。

无论是采用白盒测试方法还是灰盒测试方法验证某个功能点，也无论是采用手工方式还是自动化方式执行测试用例，这些方法和方式都是我们有针对性采用的重要测试方法和测试手段，在不同的复杂的软件系统或子系统测试中，它们发挥着重要作用。基于它们的应用特点，我们将它们统一划入专项测试范畴。

如果我们把测试方法比作一条河流，那么系统测试为主河道,易用性测试、可靠性测试、压力测试、性能测试和安全性测试等就是这条河流的分支河道（即专项测试），它们与系统测试相辅相成，用于验证软件系统中各个方面的质量特性（见图1-5）。自动化测试是提升系统测试和专项测试效率的“利器”。

图1-5　测试方法与河道的类比

我们根据不同产品的需求选择不同的专项测试作为测试时的补充，以便发挥不同专项测试的优势。对于一些类别的产品，我们需要改变测试方法落地的方向，如腾讯公司微信产品的测试主方向是用户体验方面。我们在尝试使用一种新方法或新工具时，并不是每一次都能带来明显回报，但我们仍然要勇于尝试，力求创新。

一些测试人员认为黑盒测试就是功能测试，其实二者是有区别的，黑盒测试是一种软件测试方法，而功能测试是对软件的功能特性进行测试的统称。软件功能层面的测试可以采用黑盒测试方法、白盒测试方法和灰盒测试方法。目前，在测试行业内，测试以功能测试为主，而且在测试功能时，大部分人采用黑盒测试方法，于是便产生了上述误区。

尽管技术在不断更新，但一些底层逻辑是不会变的。美国软件测试专业人士Cem Kaner等人合著的《软件测试经验与教训》汇总了293条来自软件测试界专业人士的经验与建议，阐述了如何做好测试工作、如何管理测试，以及如何澄清有关软件测试的常见误解，其中的“经验22”提到“黑盒测试并不是基于无知的测试”。

经验22：黑盒测试并不是基于无知的测试

黑盒测试意味着产品内部知识在测试中不起重要作用。大多数测试员都是黑盒测试员。想要做好黑盒测试，就要了解用户及其期望和需求，了解技术，了解软件运行环境的配置，了解这个软件要与之交互的其他软件，了解软件必须管理的数据，以及了解开发过程等。黑盒测试的优势在于测试人员与程序员的思考方式不同，因此，测试人员有可能预测出程序员忽略的风险。

黑盒测试强调有关软件的用户和环境知识，这一点并不是所有人都喜欢。我们甚至把黑盒测试描述为基于无知的测试，因为测试人员自始至终都不了解软件内部代码。我们认为这说明人们对测试团队存在误解。我们并不反对测试人员了解产品的工作原理，测试人员对产品了解越多，了解产品的方式越多，测试它的效果越好。但是，如果测试人员主要关注源代码，以及能够从源代码导出（直接生成）的测试，那么测试人员所做的工作也许是程序员已经做过的，并且测试人员掌握的关于这些代码的知识少于程序员。

尽管《软件测试经验与教训》已出版多年，但是书中提到的很多经验与教训，仍然值得我们学习、借鉴。

1.6　测试工作的产出问题

软件测试是软件工程领域的一个分支。软件测试工作的性质决定着它总是处于软件开发工作的“对立面”。关于测试工作的产出，业界人士有着不同的看法。先不论对错，这些看法或多或少会对已从事或打算从事软件测试工作的人产生一些认识上的影响。Carl向作者分享了他作为面试官的一次经历，在那场面试中，他引导应聘者正确地认识测试工作的产出问题。

Carl：有些人认为，代码是开发人员编写的，即便是测试人员发现的bug，也是开发人员编写的，而且bug的修复也是开发人员通过修改代码进行的。就产品而言，根本看不到测试人员的任何踪迹。你怎么看待这番言论？

应聘者：代码是开发人员编写的，bug也确实是开发人员的输出，测试人员只是发现它，但这一点已足够重要。开发人员为什么没有在代码设计时发现bug呢？因为人都会犯错误，开发人员也一样。其实我认为，开发人员与测试人员在工作中存在一种互补关系。二者的共同目标是及时发现并解决bug，提高软件质量。

Carl：很好，理解到位。那么，你认为测试工作的产出包括哪些内容？

应聘者：对于用户使用的产品，测试工作的产出好像没有看得到、摸得着的。

Carl：尽管测试人员的输出没有直接体现在产品上，但对产品是否有间接影响呢？

应聘者：间接影响肯定有，如测试人员将bug反馈给开发人员，从而提高产品的质量。感谢面试官的提示，面试官可否谈一下自己的看法呢？

Carl：从项目角度来看，测试工作的产出包括测试计划、测试方案、测试用例、测试代码、bug、测试报告和开发的测试工具等。这些产出都是为了更多、更快地在研发内部发现bug。从测试本身来看，能够提升测试工作的质量和效率的输出都是测试工作的产出。测试工作的产出是指能够给项目或组织带来反馈的所有输出。测试工作的产出出现在产品的整个开发链路中，除服务于软件项目以外，还包括对测试人员的培养和对团队的整体赋能等。

应聘者：领教了，感谢面试官的指点。

这里，作者给出一般的测试工作的产出，如图1-6所示。

测试工作的产出在不同业务领域有所不同。图1-6以测试的输出为出发点，从全局角度给出测试工作的产出，读者可根据自己所在企业的实际情况进行补充或缩减。测试工作的产出与测试人员的成就感的关系，不同的人有不同的感受。接下来，作者谈一下测试人员的成就感。

图1-6　测试工作的产出

1.7　测试人员的成就感

在戴尔·卡耐基所著的《人性的弱点》中，成功包含下列两方面含义。

1）个人价值得到社会承认，并赋予个人相应的回报，如职位、金钱和尊重等。

2）自己承认自己的价值，从而充满自信，并获得幸福感和成就感^[2]。

[2]　成就感是一个人做完一件事情或正在做一件事情时，为自己所做的事情感到愉快或满足的感受，是愿望与现实达到平衡而产生的一种心理感受。

在软件测试工作中，测试人员的成就感是什么呢？作者通过下列4个案例给出相应的心理剖析，来介绍一下测试人员的成就感。

【案例1】

当发现一个bug，尤其是这个bug对客户的使用有严重影响，并且开发人员难于解决时，我很开心，很有成就感。

心理剖析：开发人员生产代码并构建产品，但在生产代码的过程中，不可避免地会产生bug。测试人员发现bug，开发人员修复bug，从而使产品质量得到提升。如果测试人员发现的bug对产品质量的提升贡献较大，那么自然会产生很强的满足感。开发人员是产品的直接贡献者，测试人员是产品的间接贡献者。

【案例2】

我开发的几个小工具可以实现测试过程中的数据自动生成和自动删除功能，还可以进行自动测试和夜间无人值守的压力测试。除自己使用这些小工具以外，我还将它们分享给其他同事。因此，我很开心。

心理剖析：应用编码技术开发测试小工具，不但提高了自己的测试工作效率，而且通过分享也提升了同事的工作效率。这是通过自身努力提升整体测试效率而获得的成就感。

【案例3】

由于我对产品业务很熟悉，因此，在软件开发的过程中，我提出的需求问题经常被采纳。特别是在一次需求测试^[3]过程中，我发现某个产品组件的布局与竞品公司拥有的专利有冲突，于是及时阻止了原有需求的开发，规避了后面相关软件开发、测试工作推倒重来的风险，得到了产品经理的肯定。

[3]　需求测试：以用户为核心，针对需求，对背景、使用场景和风险等方面可能遇到的问题进行回答的过程。需求测试是我们在软件测试实践过程中摸索出来的一套测试左移的方法。

心理剖析：需求是测试人员进行测试分析、测试设计的重要依据。前面的需求有误或遗漏会导致后续开发工作、测试工作增加或推倒重来。企业往往以结果为导向，因此不愿意看到此类事件发生。我在开发前期发现此类问题，使得项目及时止损，从而规避了风险，确保了产品的开发进度。产品经理的肯定和为产品做出的贡献使我获得成就感。

【案例4】

我们团队收到客户的表扬信，一是肯定了我们在软件升级现场的服务态度非常好，业务能力强；二是认为我们的产品质量并不比国外产品差，性价比更高。

心理剖析：“让客户满意”就是我们追求的目标，只有产品的成功，才能带来测试的真正成功。客户的肯定使我获得成就感。

1.8　测试人员的挫败感

前面谈了测试的成就感，接下来谈一下测试人员的挫败感。软件测试工作的性质决定了测试人员与bug有“不解之缘”。软件测试工作不仅包括拦截bug，还包括在开发前期预防bug，以及对产品在用户端使用时返回的日志进行分析，这些往往离不开bug定位工作。因此，无论是测试左移还是测试右移，我们在整个软件生命周期都要关注bug问题。

作者仍然通过案例给出相应的心理剖析的方式，来介绍一下测试人员的挫败感。

【案例1】

测试是一种商业活动，我们不可能在有限的时间内穷尽所有测试路径，也不可能找到软件中的所有bug。从理论上来说，出现漏测bug^[4]很正常，但有时我们会因此受到领导或同事的指责。

[4]　漏测bug：一般是指本该在公司内部测试时发现的bug，但实际上却被遗漏到用户端，由非测试人员在实际使用产品时发现。在不同公司中，漏测bug可能有不同含义，如一些公司在开展内部测试活动时，会进行交叉测试（两个测试人员交换测试对象）。交叉测试活动中发现的问题也称为漏测bug，属于内部漏测bug。

心理剖析：测试工作的目的是发布质量可靠的软件，特别是要确保用户常用的功能是可靠的。用户对核心场景的bug是零容忍的。在很多公司中，用户反馈的质量问题是考核测试人员的重要指标。漏测严重的bug会给客户和公司带来损失。漏测bug给测试人员带来的挫败感可想而知。

【案例2】

产品有“电话本最多可以保存500条记录，每条记录有10个字段”这个需求。为了对500条记录进行边界测试，我通过手工方式录入100条记录，感到效率低下。还有，产品上线后需要进行需求更改，由于担心对更改点的测试不全面和不充分，因此我将相关模块的上万条测试用例重新执行了一遍，由于是手工测试，因此我对这种测试策略感到无奈。

心理剖析：尽管测试人员需要不断地对软件的一个个版本进行迭代测试，但效率低下的手工方式不仅浪费时间，而且会使测试人员产生挫败感。

【案例3】

本来今天计划发布产品的最新版本，不再扩充新需求，但项目经理应客户的要求，需要增加一个重要功能。需求的变化经常导致开发和测试工作重新进行，不仅影响交付时间，还人为地增加了开发人员和测试人员的工作量。

心理剖析：项目的需求缺乏管控机制，突发需求不断，而计划却没相应调整，最后出现工作量增加和影响交付等情况。这些突然增加的需求和工作量的增加会给测试人员带来极大的挫败感。

【案例4】

项目经理说，产品在最近的使用过程中，每天会自动重启，这影响了用户的正常使用。项目经理要求研发人员在两天时间内把问题解决，否则用户要求更换产品或退货。

心理剖析：问题产生的原因往往还未分析清楚，我们就需要拿出“止血”（立即制止产品中的问题）方案并使之落地生效。此方案需要兼顾进度与质量，相关人员感到压力非常大，同时会产生挫败感。此外，我们还需要对产品暴露的问题进行复盘，这时也容易产生挫败感。