软件测试52讲 学习笔记

开篇

对开篇提到的一些测试思维、技术、能力的自查自检（截至24.04.25）

能力

1、知其然知其所以然
2、从业务本身出发来对软件进行测试验证
3、测试设计能力、测试开发能力和测试平台化抽象能力
4、快速学习的能力：迅速掌握被测软件的业务功能与内部架构，并在此基础上运用各种测试方法，尽可能多地发现潜在缺陷，并能够在已知缺陷的基础上进一步发现相关的连带缺陷。
5、关注软件整体的质量
6、需要根据业务风险以及影响来制定测试策略，有效控制测试时间和成本，并且能够对测试框架以及工具做出适合项目需求的选型。
7、清楚测试工具的实现原理，以及多个同类测试工具各自的优缺点和适用场景

自查自检：拥有快速学习的能力，能够快速掌握业务及系统实现的底层逻辑，关注数据流向。在工作中能够保持知其然知其所以然和从业务出发测试验证的态度。对于熟悉度较高的系统，在测试过程中能够关注交付的整体质量，及把控整体时间；
有待改进：测试开发能力、测试平台抽象画能力；测试策略能力；测试框架和工具选型能力；对测试工具实现原理的了解及对比

技术

1、AI + Big Data + Cloud
2、全面的计算机基础知识
3、互联网的基础架构、安全攻击、软件性能、用户体验和常见缺陷等知识

自查自检：上述都需要提升

自动化相关

1、掌握完整的自动化测试开发技术来设计自动化测试用例
2、一套完善的高并发测试执行基础架构的支持
3、掌握设计开发测试基础架构的关键技术
4、系统性地思考如何才能将测试数据的准备工具化、服务化、最终实现平台化
5、能够使用常见的测试框架或者工具
6、具有一定的自动化测试脚本的开发能力
7、理解代码级的测试技术
8、自动化测试的关注点从原本的“如何把手工测试步骤用自动化脚本实现”变成了“如何构建低维护成本，可以灵活组装的自动化脚本”，
9、理解自动化脚本的分层设计、页面对象模型以及业务流程模型，并应用到测试框架里

自查自检：需要从“如何把手工测试步骤用自动化脚本实现”起步学习，学习一门代码

1-1如何做测试

1、等价类划分方法，是将所有可能的输入数据划分成若干个子集，在每个子集中，如果任意一个输入数据对于揭露程序中潜在错误都具有同等效果，那么这样的子集就构成了一个等价类。后续只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
2、边界值分析方法，是选取输入、输出的边界值进行测试。通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
3.1、显式功能性需求，指的是软件本身需要实现的具体功能；
3.2、非功能性需求主要涉及安全性、性能以及兼容性三大方面；
4、对被测系统的设计有深入的理解、明白安全攻击的基本原理、掌握性能测试的基本设计方法
5、需要兼顾缺陷风险和研发成本之间的平衡

1-2如何写一个好的测试用例

好的测试用例的要点

“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。
1、整体完备性： 是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。
2、等价类划分的准确性： 对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
3、等价类集合的完备性： 需要保证所有可能的边界值和边界条件都已经正确识别。
做到了以上三点，就可以肯定测试是充分且完备的，即做到了完整的测试需求覆盖。

常用的方法解析

对大多数的软件测试而言，综合使用等价类划分、边界值分析和错误推测这三大类方法就足够了。
1、等价类划分方法：等价类中任意一个输入数据对于揭露程序中潜在错误都具有同等效果。可以用少量具有代表性的测试输入取得较好的测试覆盖结果。等价类划分方法的另一个关键点是要找出所有“无效等价类”
2、边界值分析方法：边界值分析是对等价类划分的补充，指对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
3、错误推测方法：指基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，基于曾经遇到的问题而进行的错误推测来设计测试用例，依赖个人能力。为了减少对个人能力的依赖，团队通常会建立常见缺陷知识库，在测试设计的过程中，会使用缺陷知识库作为检查点列表，去帮助优化补充测试用例的设计。

测试人员应…

1、对被测软件的需求有深入的理解；
2、在需求分析和设计阶段就开始介入：从业务需求的角度去设计针对性明确、从终端用户使用场景考虑的端到端的测试用例集；
3、用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例；
4、可引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。

提到的一些具体的技术点

1、数据库连接方式；
2、数据库的读写分离；
3、消息中间件 Kafka 的配置；
4、缓存系统的层级分布；
5、第三方系统的集成；
6、Web 界面的 GUI 功能测试，需要考虑浏览器在有缓存和没有缓存下的表现；
7、Web Service 的 API 测试，需要考虑被测 API 所依赖的第三方 API 出错下的处理逻辑；
8、对于代码级的单元测试，需要考虑被测函数的输入参数为空情况下的内部处理逻辑；

1-3单元测试

概念

对函数或者类的测试，是单元测试；
对模块的测试，是集成测试；
对预发布版本测试，是系统测试；

单元测试是指，对软件中的最小可测试单元在与程序其他部分相隔离的情况下进行检查和验证的工作，这里的最小可测试单元通常是指函数或者类，单元测试的对象是代码。

单元测试用例相关

单元测试的用例是一个“输入数据”和“预计输出”的集合——
输入数据：
1、被测试函数的输入参数；
2、被测试函数内部需要读取的全局静态变量；
3、被测试函数内部需要读取的成员变量；
4、函数内部调用子函数获得的数据；
5、函数内部调用子函数改写的数据；
6、嵌入式系统中，在中断调用时改写的数据；
预计输出：
1、函数返回值、函数执行完成后所改写的所有数据；
2、被测试函数的返回值；被测试函数的输出参数；
3、被测试函数所改写的成员变量；
4、被测试函数所改写的全局变量；
5、被测试函数中进行的文件更新；
6、被测试函数中进行的数据库更新；
7、被测试函数中进行的消息队列更新；
注意点：必须严格根据代码的功能逻辑来设定，而不能通过阅读代码来推算预期输出

驱动代码相关

驱动代码，桩代码和 Mock 代码，是单元测试中最常出现的三个名词。
驱动代码是用来调用被测函数的，而桩代码和 Mock 代码是用来代替被测函数调用的真实代码的。
桩代码的应用首先起到了隔离和补齐的作用，使被测代码能够独立编译、链接，并独立运行。同时，桩代码还具有控制被测函数执行路径的作用

1-4什么样的项目适合自动化测试？

1、需求稳定，不会频繁变更
2、研发和维护周期长，需要频繁执行回归测试：软件产品比软件项目更适合做自动化测试；对于软件项目的自动化测试，可对比较稳定的软件功能进行自动化测试，对变动较大或者需求暂时不明确的功能进行手工测试
3、需要在多种平台上重复运行相同测试的场景
4、某些测试项目通过手工测试无法实现，或者手工成本太高
5、被测软件的开发较为规范，能够保证系统的可测试性。某些用例的自动化必须要求开发人员在产品中预留可测试性接口，否则后续的自动化会很难开展
6、测试人员已经具备一定的编程能力

1-5各阶段的自动化测试技术

在软件研发生命周期的各个阶段都有自动化测试技术的存在，并且对提升测试效率有着至关重要的作用

单元测试的自动化

1、用例框架代码生成的自动化
2、部分测试输入数据的自动化生成
3、自动桩代码的生成
4、被测代码的自动化静态分析（Sonar 、 Coverity等）
5、测试覆盖率的自动统计与分析

代码级集成测试的自动化（略过）

代码级集成测试与单元测试最大的区别只是，代码级集成测试中被测函数内部调用的其他函数必须是真实的，不允许使用桩代码代替，而单元测试中允许使用桩代码来模拟内部调用的其他函数。

Web Service 测试的自动化

1、SOAP API 和 REST API 这两类 API 测试
2、工具：SoapUI 或 Postman 等（手动发起 Request 并验证 Response）
3、API 自动化测试框架：基于代码的 API 测试用例，通常包含三大步骤：准备 API 调用时需要的测试数据；准备 API 的调用参数并发起 API 的调用；验证 API 调用的返回结果；
4、Web Service 测试“自动化”的内涵：
4.1）测试脚手架代码的自动化生成（被测试 API 的调用、测试数据与脚本的分离，以及 Response 验证的空实现）
4.2）部分测试输入数据的自动生成（API 的参数以及 API 调用的 Payload）
4.3）Response 验证的自动化（返回状态码（status code）、Scheme 结构以及具体的字段值；Response 验证自动化的核心思想是自动比较两次相同 API 调用的返回结果，并自动识别出有差异的字段值，比较过程可以通过规则配置去掉诸如时间戳、会话 ID（Session ID）等动态值。）
4.4）基于 SoapUI 或者 Postman 的自动化脚本生成

GUI 测试的自动化

1）Web 浏览器的 GUI 自动化测试：开源方案 Selenium，商业方案 Micro Focus 的 UFT
2）移动端原生应用，主流Appium，它对 iOS 环境集成了 XCUITest，对 Android 环境集成了 UIAutomator 和 Espresso。

1-6测试覆盖率

测试覆盖率：衡量测试的充分性和完整性
测试覆盖率主要分为两大类：面向项目的需求覆盖率；偏向技术的代码覆盖率

需求覆盖率

需求覆盖率是指测试对需求的覆盖程度
工具：ALM、Doors 、 TestLink等
主流倾向：将软件需求转换成测试需求，然后基于测试需求再来设计测试点。将分解后的软件需求和对应的测试建立一对多的映射关系，最终目标是保证测试可以覆盖每个需求，以保证软件产品的质量。

代码覆盖率

最常用的三种代码覆盖率指标：
1）行覆盖率又称为语句覆盖率，指已经被执行到的语句占总可执行语句（不包含类似 C++ 的头文件声明、代码注释、空行等等）的百分比。
2）判定覆盖又称分支覆盖，用以度量程序中每一个判定的分支是否都被测试到了，即代码中每个判断的取真分支和取假分支是否各被覆盖至少各一次。
3）条件覆盖是指，判定中的每个条件的可能取值至少满足一次，度量判定中的每个条件的结果 TRUE 和 FALSE 是否都被测试到了。
价值：找出潜在的遗漏测试用例，并有针对性的进行补充，同时还可以识别出代码中那些由于需求变更等原因造成的不可达的废弃代码
局限性：并不能发现那些“未考虑某些输入”以及“未处理某些情况”形成的缺陷。

1-7怎么写bug

测试工程师最基本的一项技能就是把发现的缺陷准确无歧义地表达清楚
好的缺陷报告不是大量信息堆叠，而是以高效的方式提供准确有用的信息

缺陷标题

对缺陷的概括性描述，通常说明“在什么情况下发生了什么问题”，以及清楚表述问题出现的场景。尽可能描述问题本质，不宜过长

缺陷描述

缺陷概述通常会提供更多概括性的缺陷本质与现象的描述，用清晰简短的语句将问题的本质描述清楚是关键。缺陷概述的目的是清晰简洁地描述缺陷，使开发工程师能够聚焦缺陷的本质

缺点影响

缺陷引起的问题对用户或者对业务的影响范围以及严重程度。缺陷影响决定了缺陷的优先级和严重程度

环境配置

详细描述测试环境关键的配置细节，为缺陷的重现提供必要的环境信息

前置及条件

前置条件是指测试步骤开始前系统应该处在的状态，其目的是减少缺陷重现步骤的描述，提高描述的针对性

缺陷重现步骤（核心内容）

其目的在于用简洁的语言向开发工程师展示缺陷重现的具体操作步骤
操作步骤通常是从用户角度出发来描述的，每个步骤都应是可操作并且是连贯的

期望结果和实际结果

期待结果来自于对需求的理解，而实际结果来自于测试执行的结果
描述期望结果时，需要说明应该发生什么，而不是什么不应该发生
描述实际结果时，你应该说明发生了什么，而不是什么没有发生

优先级和严重程度

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

变通方案

变通方案是提供一种临时绕开当前缺陷而不影响产品功能的方式

根原因分析（RCA）

发现缺陷的同时，定位出问题的根本原因，清楚地描述缺陷产生的原因并反馈给开发（尽量尝试，提升自我）

附件

附件为缺陷的存在提供必要的证据支持，常见的附件有界面截图、测试用例日志、服务器端日志、GUI 测试的执行视频等。