《软件测试52讲》学习笔记（三）_软件测试 测试者行为和数据 期待的结果

因为报了一个课程，记录一些自己觉得有用的东西，课程链接：https://time.geekbang.org/column/article/10150

 

二、测试基础知识篇

• 第七小节  如何高效填写软件缺陷报告？

1. 缺陷报告是测试工程师与开发工程师交流沟通的重要桥梁，也是测试工程师日常工作的重要输出。 作为优秀的测试工程师，最基本的一项技能就是，把发现的缺陷准确无歧义地表达清楚。
2. 缺陷报告本身的质量将直接关系到缺陷被修复的速度以及开发工程师的效率，同时还会影响测试工程师的信用、测试与开发人员协作的有效性。
3. 你必须牢牢记住的是，好的缺陷报告绝对不是大量信息的堆叠，而是以高效的方式提供准确有用的信息。

1、高效的缺陷报告主要由哪些部分组成？以及每部分内容的关键点是什么？

1.1、缺陷标题

缺陷标题通常是别人最先看到的部分，是对缺陷的概括性描述，通常采用“在什么情况下发生了什么问题”的模式。可以参考以下三个步骤：

• 首先，对“什么问题”的描述不仅要做到清晰简洁，最关键是要足够具体，切忌不能采用过于笼统的描述。描述“什么问题”的同时还必须清楚地表述发生问题时的上下文，也就是问题出现的场景；
• 其次，标题应该尽可能描述问题本质，而避免只停留在问题的表面；

     比如，“商品金额输入框，可以输入英文字母和其他字符”这个描述就只描述了问题的表面现象，而采用诸如“商品金额输入框，没有对输入内容做校验”的方式，就可以透过标题看到缺陷的本质，这样可以帮助开发人员快速掌握问题的本质。

• 最后，缺陷标题不易过长，对缺陷更详细的描述应该放在“缺陷概述”里；

1.2、缺陷概述

缺陷概述通常会提供更多概括性的缺陷本质与现象的描述，用清晰简短的语句将问题的本质描述清楚是关键。

总之，缺陷概述的目的是，清晰简洁地描述缺陷，使开发工程师能够聚焦缺陷的本质。

1.3、缺陷影响

缺陷影响描述的是，缺陷引起的问题对用户或者对业务的影响范围以及严重程度。

缺陷影响决定了缺陷的优先级（Priority）和严重程度（Severity），这两个方面会影响到开发修复的优先级与产品经理决定这个是否要修复后才发布。

测试工程师准确描述缺陷影响的前提是，必须对软件的应用场景以及需求有深入的理解，这也是对测试工程师业务基本功的考验。

1.4、环境配置

环境配置用以详细描述测试环境的配置细节，为缺陷的重现提供必要的环境信息。比如，操作系统的类型与版本、被测软件版本、浏览器的种类和版本、被测软件的配置信息、集群的配置参数、中间件的版本信息等等。

需要注意的是，环境配置的内容通常是按需描述，也就是说通常只描述那些重现缺陷的环境敏感信息。

1.5、前置条件

前置条件是指测试步骤开始前系统应该处在的状态，其目的是减少缺陷重现步骤的描述。合理地使用前置条件可以在描述缺陷重现步骤时排除不必要的干扰，使其更有针对性。比如，某个业务操作需要先完成用户登录，你在缺陷重现步骤里就没有必要描述登录操作的步骤细节，可以直接使用 “前置条件：用户已完成登录”的描述方式。

1.6、缺陷重现步骤

缺陷重现步骤是整个缺陷报告中最核心的内容，其目的在于用简洁的语言向开发工程师展示缺陷重现的具体操作步骤。注意：操作步骤通常是从用户角度出发来描述的，每个步骤都应该是可操作并且是连贯的，所以往往会采用步骤列表的表现形式。

通常测试工程师在写缺陷重现步骤前，需要反复执行这些步骤 3 次以上：一是，确保缺陷的可重现性；二是，找到最短的重现路径，过滤掉那些非必要的步骤，避免产生不必要的干扰。

对于缺陷重现步骤的描述应该尽量避免以下 3 个常见问题：

1. 笼统的描述，缺乏可操作的具体步骤；
2. 出现与缺陷重现不相关的步骤；
3. 缺乏对测试数据的相关描述。

1.7、期望结果和实际结果

期待结果来自于对需求的理解，而实际结果来自于测试执行的结果。

通常来讲，当你描述期望结果时，需要说明应该发生什么，而不是什么不应该发生；而描述实际结果时，你应该说明发生了什么，而不是什么没有发生。

1.8、优先级（Priority）和严重程度（Severity）

我之所以将优先级和严重程度放在一起，是因为这两个概念看起来有点类似，而本质却完全不同。而且，很多入行不久的测试工程师，也很难搞清楚这两者的差异到底在哪里。

缺陷优先级是指缺陷必须被修复的紧急程度，而缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。 ---- 百度百科

可见，严重程度是缺陷本身的属性，通常确定后就不再变化，而优先级是缺陷的工程属性，会随着项目进度、解决缺陷的成本等因素而变动。

缺陷的优先级和严重程度的关系：

1. 缺陷越严重，优先级就越高；
2. 缺陷影响的范围越大，优先级也会越高；
3. 有些缺陷虽然从用户影响角度来说不算严重，但是会妨碍测试或者是自动化测试的执行，这类缺陷属于典型的严重程度低，但是优先级高；
4. 有些缺陷虽然严重程度比较高，但是考虑到修复成本以及技术难度，也会出现优先级较低的情况。

1.9、变通方案（Workaround）

变通方案是提供一种临时绕开当前缺陷而不影响产品功能的方式，通常由测试工程师或者开发工程师完成，或者他们一同决定。

1.10、根原因分析（Root Cause Analysis）

根原因分析就是我们平时常说的 RCA，如果你能在发现缺陷的同时，定位出问题的根本原因，清楚地描述缺陷产生的原因并反馈给开发工程师，那么开发工程师修复缺陷的效率就会大幅提升，而且你的技术影响力也会被开发认可。

可以做好根原因分析的测试工程师，通常都具有开发背景，或者至少有较好的代码阅读以及代码调试的能力。

所以做为测试工程师，你很有必要去深入学习一门高级语言，这将帮助你体系化地建立起编程思想和方法，这样在之后的工作中，无论你是面对开发的代码，还是自动化测试代码和脚本都能做到得心应手，应对自如。

2、总结

1. 缺陷报告是测试工程师与开发工程师交流沟通的重要桥梁，也是测试工程师日常工作的重要输出。
2. 一份高效的软件缺陷报告，应该包括缺陷标题、缺陷概述、缺陷影响、环境配置、前置条件、缺陷重现步骤、期望结果和实际结果、优先级和严重程度、变通方案、根原因分析，以及附件这几大部分。
3. 缺陷报告的每一部分内容，都会因为目的、表现形式有各自的侧重点，所以想要写出一份高效的软件缺陷报告，需要对其组成有深入的理解。

---

• 第八小节  以终为始，如何才能做好测试计划？

早期的软件工程实践中，软件测试计划的制定通常是在需求分析以及测试需求分析完成后开始，并且是整个软件研发生命周期中的重要环节。

在敏捷开发模式下测试计划的表现形式已经不再是传统意义上庞大的、正式的测试计划文档了，而更多的是体现在每个迭代（sprint）的计划环节，而且这样的短期测试计划可以非常迅速地根据项目情况实时调整。

不管在以前的瀑布式开发模式，还是现在的敏捷式开发模式下，测试计划依旧存在，只是从原来的一次性集中制定测试计划，变成了以迭代的方式持续制定测试计划。 但是对于传统软件企业，或者是做非互联网软件产品的企业，它们通常还是会有非常正式的软件测试计划。

1、没有测试计划会怎么样？

• 很难确切地知道具体的测试范围，以及应该采取的具体测试策略；
• 很难预估具体的工作量和所需要的测试工程师数量，同时还会造成各个测试工程师的分工不明确，引发某些测试工作被重复执行而有些测试则被遗漏的问题；
• 测试的整体进度完全不可控，甚至很难确切知道目前测试的完成情况，对于测试完成时间就更难预估准确的时间节点了；
• 整个项目对潜在风险的抵抗能力很弱，很难应对需求的变更以及其他突发事件。

从这些问题中，你可以逆向思维推导出，一份好的测试计划要包括：测试范围、测试策略、测试资源、测试进度和测试风险预估，这五大方面，并且每一部分都要给出应对可能出现问题的解决办法。

2、测试范围

测试范围描述的是被测对象以及主要的测试内容。

比如，对于用户登录模块，功能测试既需要测试浏览器端又需要测试移动端，同时还考虑登录的安全和并发性能相关的非功能性需求的测试等。

由于不可能进行穷尽测试，而且测试的时间和资源都是有限的，所以必须有所取舍，进行有针对性的测试。因此，测试范围中需要明确“测什么”和“不测什么”。

3、测试策略的话题

测试策略简单来讲就是需要明确“先测什么后测什么”和“如何来测”这两个问题。测试策略会要求我们明确测试的重点，以及各项测试的先后顺序。比如，对用户登录模块来讲，“用户无法正常登录”和“用户无法重置密码”这两个潜在问题，对业务的影响孰轻孰重一目了然，所以，你应该按照优先级来先测“用户正常登录”，再测“用户重置密码”。

测试策略还需要说明，采用什么样的测试类型和测试方法。 这里需要注意的是，不仅要给出为什么要选用这个测试类型，还要详细说明具体的实施方法。

3.1、第一，功能测试

• 这里需要注意的是，你通常应该先实现主干业务流程的测试自动化。
• 实际操作时，你通常需要先列出主要的功能测试点，并决定哪些测试点适合采用自动化测试，并且决定具体使用什么样的框架和技术。
• 对于需要手工测试的测试点，你要决定采用什么类型的测试用例设计方法，以及如何准备相关的测试数据。
• 另外，你还要评估被测软件的可测试性，如果有可测试性的问题，需要提前考虑切实可行的变通方案，甚至要求开发人员提供可测试性的接口。

3.2、第二，兼容性测试

对于兼容性测试来说，Web 测试需要确定覆盖的浏览器类型和版本，移动设备测试需要确定覆盖的设备类型和具体 iOS/Android 的版本等。

我要怎么确定需要覆盖的移动设备类型以及 iOS/Android 的版本列表呢？这个问题其实并不难：

• 如果是既有产品，你可以通过大数据技术分析产品的历史数据得出 Top 30% 的移动设备以及 iOS/Android 的版本列表，那么兼容性测试只需覆盖这部分即可；
• 如果是一个全新的产品，你可以通过 TalkingData 这样的网站来查看目前主流的移动设备，分辨率大小、iOS/Android 版本等信息来确定测试范围。

兼容性测试往往在测试的最后阶段执行，也有一些在测试阶段最前面的特例，例如：前端引入了新的前端框架或者组件库，兼容性测试用例的选取，往往来自于已经实现的自动化测试用例。道理很简单，因为兼容性测试往往要覆盖最常用的业务场景，而这些最常用的业务场景通常也是首批实现自动化测试的目标。

3.3、第三，性能测试

性能测试，需要在明确了性能需求（并发用户数、响应时间、事务吞吐量等）的前提下，结合被测系统的特点，设计性能测试场景并确定性能测试框架。

具体展开性能测试的点：

• 性能测试的实施，往往先要根据业务场景来决定需要开发哪些单用户脚本，脚本的开发会涉及到很多性能测试脚本特有的概念，比如思考时间、集合点、动态关联等等；
• 脚本开发完成后，你还要以脚本为单位组织测试场景（Scenario），场景定义简单来说就是百分之多少的用户在做登录、百分之多少的用户在做查询、每个用户的操作步骤之间需要等待多少时间、并发用户的增速是 5 秒一个，还是 5 秒 2 个等等；
• 最后，才是具体的测试场景执行。和自动化功能测试不同，性能测试执行完成后性能测试报告的解读，是整个测试过程中最关键的点。

4、测试资源

测试资源通常包括测试人员和测试环境，这两类资源都是有限的。测试计划的目的就是，保证在有限资源下的产出最大化。所以，测试资源就是需要明确“谁来测”和“在哪里测”这两个问题。

测试人员的资源通常有两个维度：一是，测试工程师的数量；二是，测试工程师的个人经验和能力。

你要想规划好测试资源，除了要了解项目本身外，还必须对测试团队的人员特点有清晰的把控。另外，我强烈建议你把具体的任务清晰地落实到每个人的身上，这将有利于建立清晰的责任机制，避免后续可能发生的扯皮。

5、测试进度

在明确了测试范围、测试策略和测试资源之后，你就要考虑具体的测试进度了。测试进度主要描述各类测试的开始时间，所需工作量，预计完成时间，并以此为依据来建议最终产品的上线发布时间。

6、测试风险预估

在制定测试计划时，你就要预估整个测试过程中可能存在的潜在风险，以及当这些风险发生时的应对策略。

7、总结

• 软件测试同软件项目一样，也要制定详细的测试计划。虽然在敏捷开发模式下，软件测试不再局限于厚重的、正式的计划文档，但是测试计划的重要性丝毫没有发生变化；
• 一份成功的测试计划，必须清楚地描述：测试范围、测试策略、测试资源、测试进度和测试风险预估这五个最重要的方面；
• 测试范围需要明确“测什么”和“不测什么”；测试策略需要明确“先测什么后测什么”和“如何来测”；测试资源需要明确“谁来测”和“在哪里测”；测试进度是需要明确各类测试的开始时间，所需工作量和预计完成时间；测试风险预估是需要明确如何有效应对各种潜在的变化。

---

• 第九小节  软件测试工程师的核心竞争力是什么？

​​​​​​​作为测试人员，必须要深入理解业务，但是业务知识不能等同于测试能力。

测试开发岗位的核心其实是“测试”，“开发”的目的是更好地服务于测试。

1、传统测试工程师师应该具备的核心竞争力

测试工程师要具备的七项核心竞争力，包括：

1.1、测试策略设计能力

测试策略设计能力是指，对于各种不同的被测软件，能够快速准确地理解需求，并在有限的时间和资源下，明确测试重点以及最适合的测试方法的能力。具备出色的测试策略设计能力，你可以非常明确地回答出测试过程中遇到的这些关键问题：

• 测试要具体执行到什么程度；
• 测试需要借助于什么工具；
• 如何运用自动化测试以及自动化测试框架，以及如何选型；
• 测试人员资源如何合理分配；
• 测试进度如何安排；
• 测试风险如何应对。

培养出色的测试策略设计能力，不是一朝一夕的事情，通常需要经过大量项目的实际历练，并且你还要保持持续思考，主动去提炼共性的内容。测试策略设计能力一定是需要你在大量实践的基础上潜移默化形成的。我认为，测试策略设计能力是功能测试工程师最核心的竞争力，也是最难培养的。

1.2、测试用例设计能力

测试用例设计能力是指，无论对于什么类型的测试，都能设计出高效地发现缺陷，保证产品质量的优秀测试用例。在平时设计测试用例时，要多多了解项目实现的原理，例如：运行环境、技术架构、缓存机制、中间件、第三方等，另一方面，设计测试用例不能局限于你现在熟悉的领域，要在各个领域都能融会贯通，提取共性。

要想提高测试用例设计能力，你平时就要多积累，对常见的缺陷模式、典型的错误类型以及遇到过的缺陷，要不断地总结、归纳，才能逐渐形成体系化的用例设计思维。

同时，你还可以阅读一些好的测试用例设计实例开阔思路，日后遇到类似的被测系统时，可以做到融会贯通和举一反三。

1.3、快速学习能力

快速学习能力，包含两个层面的含义：对不同业务需求和功能的快速学习与理解能力；对于测试新技术和新方法的学习与应用能力。

培养学习能力的小窍门：

• 学习一个新的开源工具时，建议你直接看官方文档：一来，这里的内容是最新而且是最权威的；二来，可以避免网上信息质量的参差不齐。知识输入源头是单一，而且权威的话，你的学习曲线也必然会比较平滑。
• 当学习新内容时，你一定要做到理解其原理，而不是只停留在表面的、简单的操作和使用，长期保持这种学习状态，可以在很大程度上提高逻辑思维和理解能力。这样，当你再面对其他新鲜事物时候，也会更容易理解，形成良性循环。

1.4、探索性测试思维

探索性测试是指，测试工程师在执行测试的过程中不断学习被测系统，同时结合基于自己经验的错误猜测和逻辑推理，整理和分析出更多的有针对性的测试关注点。

本质上，探索性测试思维是“测试用例设计能力”和“快速学习能力”有机结合的必然结果。

1.5、缺陷分析能力

缺陷分析能力，通常包含三个层面的含义：

• 对于已经发现的缺陷，结合发生错误的上下文以及后台日志，可以预测或者定位缺陷的发生原因，甚至可以明确指出具体出错的代码行，由此可以大幅缩短缺陷的修复周期，并提高开发工程师对于测试工程师的认可以及信任度；
• 根据已经发现的缺陷，结合探索性测试思维，推断同类缺陷存在的可能性，并由此找出所有相关的潜在缺陷；
• 可以对一段时间内所发生的缺陷类型和趋势进行合理分析，由点到面预估整体质量的健康状态，并能够对高频缺陷类型提供系统性的发现和预防措施，并以此来调整后续的测试策略。

这三个层面是依次递进的关系，越往后越能体现出测试工程师的核心竞争力。

1.6、自动化测试技术

掌握自动化测试技术，可以把你从大量的重复性手工劳动中解放出来，这样你可以把更多的时间花在更多类型的测试上。

切记，自动化测试的核心价值还是“测试”本身，“自动化”仅仅是手段，实际工作中千万不要本末倒置，把大量的精力放在“自动化”上，一味追求自动化而把本质的“测试”弱化了。

1.7、良好的沟通能力

测试工程师在软件项目中作用，有点像“润滑剂”：

• 一方面，你需要对接产品经理和项目经理，以确保需求的正确实现和项目整体质量的达标；
• 另一方面，你还要和开发人员不断地沟通、协调，确保缺陷的及时修复与验证。

所以，测试工程师的沟通能力会直接影响事务开展的效率。良好清晰的沟通能力，是一个技术优秀的测试工程师能否获得更大发展的“敲门砖”，也是资深测试工程师或者测试主管的核心竞争力。

2、测试开发工程师的核心竞争力

首先既然是测试开发工程师，那么代码开发能力是最基本的要求。测试开发工程师可以是开发工程师，但是开发工程师不一定能做测试开发工程师。

2.1、测试系统需求分析能力

除了代码开发能力，测试开发工程师更要具备测试系统需求分析的能力。需要分析产品使用的场景、测试架构需求，或许更像一个产品经理，就是为要测试的产品服务。

2.2、更宽广的知识体系

测试开发工程师除了需要掌握开发工程师的技能，还需要了解运维、CI/CD方面的知识，将自己的系统或者工具接入监控系统中去，并且了解更高级别的测试架构部署和生产架构部署、你还必须对开发采用的各种技术非常熟悉，可见要求是非常高的。

3、总结

我把测试工程师按照工作内容，分为了功能测试工程师（即传统测试工程师）和测试开发工程师两类，分别给你分享了他们的核心竞争力。

对于功能测试工程师来说，其核心竞争力包括：测试策略设计能力、测试用例设计能力、快速学习能力、探索性测试思维、缺陷分析能力、自动化测试技术和良好的沟通能力这七大部分，你可以有针对性地提升自己某方面的能力，去获取更大发展空间的“敲门砖”。

而对于测试开发工程师来说，你需要具备优秀的测试系统需求分析能力和完备的知识体系，这样才能保证你设计的测试工作和平台，可以更好地满足提升测试效率的要求。