最近在极客时间学习了茹炳晟2018年出的课程——《软件测试52讲》，总结了测试知识的方方面面。
我想知道最完整的测试知识体系是什么样，就写了一个小web项目，练习各种主流的测试技术，试着整理，搞完后发现深度不够，知识点太散，所以没有实质提升。学习课程后深感佩服，现在以茹炳晟的课程体系为框架，再以一个项目生命周期为脉络，总结一份最全的测试知识体系。
课程是2018年的，现在出了很多新技术，我会补充上。
零 前言
大部分公司用的还是瀑布流模式：
1、项目立项、需求调研；
2、定技术架构、写各种文档；
3、开发（单元测试介入、编写测试脚本）；
4、测试（各种测试执行）；
5、运维（项目上线管理环境）。
测试人员主要工作在第4步，其他步骤的参与程度，要取决于测试人员的职业定位。测试职业定位有两个方向：
1、业务功能测试。深耕于某一行业的业务流程，很资深，离开此行业多年经验就没价值了，看起来路有些窄，但公司不能没有这个角色，脱离了业务技术再厉害也没用。要想走这条路，有7个核心竞争力：第一项核心竞争力—— 测试策略设计能力：这是在大量实践的基础上潜移默化形成。（包括：测试要具体执行到什么程度；测试需要借助于什么工具；如何运用自动化测试以及自动化测试框架，以及如何选型（因为GUI自动化主要应用在核心功能上）；测试人员资源如何合理分配；测试进度如何安排；测试风险如何应对）。第二项核心竞争力——测试用例设计能力：要不断地总结、归纳，新人可以阅读一些好的测试用例设计实例。前两个最重要，其余5个是：快速学习能力、探索性测试思维、缺陷分析能力、自动化测试技术、良好的沟通能力。
2、测试开发。开发测试框架和工具，提高测试效率。有2个核心竞争力：第一项核心竞争力——测试系统需求分析能力：站在测试架构师的高度，识别出测试基础架构的需求和提高效率的应用场景。第二项核心竞争力——更宽广的知识体系：你不仅要构建测试工具或者平台给测试开发工程师用，还要知道你的工具和平台如何接入到 CI/CD 的流水线以及运维的监控系统中去。
这两个只是职业发展的侧重点。目前测试平台刚刚起步，深度学习还没能运用到测试领域，还能点几年，只是以后会基本的开发技能是测试的发展趋势。
作为一名工程师得进步，在学会了基本的开发技能之后，既可以选择一个行业，比如电商、金融、直播视频等等，成为资深功能测试，也可以选择继续深入研究测试技术，能搭建测试架构、通过各种手段提升测试效率，成为测试开发专家，测试开发可能业务经验没那么深厚，遇到的业务坑少了点，但没关系，公司是团队协作，关键是——你的优势是什么？
一 项目立项、需求调研
此时测试人员开始介入，学业务。进行测试需求分析：1、显式功能性需求：等价类划分方法；边界值分析方法。2、非功能性需求：安全、性能、兼容性。
二 定技术架构、写各种文档
这时高级测试介入做两件事：一是对备选技术框架或工具做些对比验证。二是考虑测试架构。
此时一个测试人员要掌握：测试策略设计原则、测试覆盖率、测试用例设计、测试计划制定。
1、测试策略设计原则：
有个经典的三层理论，按重要程度从下往上，底层单元测试，中层是接口测试（API测试），上层是界面测试（GUI测试）。而互联网项目，由于项目更新快，测试时间短，大多为微服务架构，因此采用橄榄球的形状分层，以接口测试为主。
互联网产品测试策略设计原则：重量级 API 测试，轻量级 GUI 测试，轻量级单元测试 1.1 单元测试：互联网产品的全面单元测试只会应用在那些相对稳定和最核心的模块和服务上，而应用层或者上层业务服务很少会大规模开展单元测试。 1.2 API 测试： 1.2.1 API 测试用例的开发与调试效率比 GUI 测试要高得多
1.2.2 API 测试用例的执行稳定性远远高于 GUI 测试
1.2.3 单个 API 测试用例的执行时间往往要比 GUI 测试短很多
1.2.4 很多互联网产品采用了微服务架构，微服务本质上就是对不同的 Web Service 的测试，也就是 API 测试。
1.2.5 API 接口的改动一般比较少，即使有改动，绝大多数情况下也需要保证后向兼容性，进而可以保证较高的投入产出比（ROI）
1.3 GUI 测试：“手工为主，自动化为辅”：互联网产品的 GUI 测试通常采用“手工为主，自动化为辅”的测试策略，手工测试往往利用探索性测试思想，针对新开发或者新修改的界面功能进行测试，
而自动化测试的关注点主要放在相对稳定且核心业务的基本功能验证上。所以，GUI 的自动化测试往往只覆盖最核心且直接影响主营业务流程的 E2E 场景。
2、测试覆盖率
1.1 需求覆盖率：需求覆盖率是指测试对需求的覆盖程度，通常的做法是将每一条分解后的软件需求和对应的测试建立一对多的映射关系，最终目标是保证测试可以覆盖每个需求，以保证软件产品的质量。
需求覆盖率统计方法属于传统瀑布模型下的软件工程实践。
我们通常采用 ALM，Doors 和 TestLink 等需求管理工具来建立需求和测试的对应关系，并以此计算测试覆盖率。
1.2 代码覆盖率：
1.2.1 代码覆盖率指标
1.2.1.1 行覆盖率：又称为语句覆盖率，指已经被执行到的语句占总可执行语句的百分比
1.2.1.2 判定覆盖：又称分支覆盖，用以度量程序中每一个判定的分支是否都被测试到了
1.2.1.3 条件覆盖：是指判定中的每个条件的可能取值至少满足一次
1.2.2 代码覆盖率的价值
1.2.2.1 找出潜在的遗漏测试用例
1.2.2.2 识别出代码中那些由于需求变更等原因造成的不可达的废弃代码
1.2.3 代码覆盖率工具：JaCoCo
3、测试用例设计
1.1 设计标准
1.1.1 整体完备性:有效测试用例组成的集合，能够完全覆盖测试需求。
1.1.2 等价类划分的准确性
1.1.3 等价类集合的完备性:概要需要保证所有可能的边界值和边界条件都已经正确识别。
1.2 设计方法
1.2.1 等价类划分方法:概要需要保证所有可能的边界值和边界条件都已经正确识别。
1.2.1.1 有效等价类
1.2.1.2 无效等价类
1.2.2 边界值分析方法:通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据
1.2.3 错误推测方法:对被测试软件的需求理解以及设计实现的细节把握
1.3 设计原则:首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，
最后再针对每个测试需求点综合运用等价类划分、边界值分析和错误推测方法来全面地设计设计测试用例。
4、制定测试计划：
测试计划
1.1 测试范围：明确“测什么”和“不测什么”
1.2 测试策略：
1.2.1 测试顺序：先测什么后测什么
1.2.2 测试类型、测试方法：如何来测
1.2.2.1 功能测试
1.2.2.1.1 主干业务流程的测试自动化：因为经常需要执行回归测试
1.2.2.1.2 先列出主要的功能测试点，并决定哪些测试点适合采用自动化测试，并且决定具体使用什么样的框架和技术
1.2.2.1.3 需要手工测试的测试点，你要决定采用什么类型的测试用例设计方法，以及如何准备相关的测试数据。
1.2.2.1.4 评估被测软件的可测试性，如果有可测试性的问题，需要提前考虑切实可行的变通方案，甚至要求开发人员提供可测试性的接口
1.2.2.2 兼容性测试：Web 测试的浏览器类型和版本，移动设备测试的设备类型和 iOS/Android 的版本。
既有产品，通过大数据分析产品的历史数据得出 Top 30% 的移动设备以及 iOS/Android 的版本列表。
全新产品，通过 TalkingData 这样的网站来查看目前主流的移动设备，分辨率大小、iOS/Android 版本等信息来确定测试范围。
兼容性测试的实施一般在功能测试后期。偶尔在前期，如前端引入新框架或组件库，会先做兼容性评估。
兼容性测试用例来自于已经实现的GUI自动化测试用例，因为自动化的用例是最常用的业务场景。注意：GUI测试用例要能运行在不同浏览器。
1.2.2.3 性能测试、接口测试、集成测试、安全测试、容量验证、安装测试、故障恢复测试等
1.3 测试资源：测试资源就是需要明确“谁来测”和“在哪里测”这两个问题。
1.4 测试进度
1.5 测试风险预估
三 开发（单元测试介入、编写测试脚本）
开发开始编码。此时根据测试职业定位不同，会有不同的介入时机，分2类：
一是偏开发，介入早，要进行单元测试、白盒测试，接口测试、功能测试、自动化测试等。
二是偏运维，介入晚，功能测试基本完事，要进行性能测试、安全测试，专项测试等。
另外，自动化是未来趋势，“到2030年，全球有将有2.7亿工人因为自动化而不得不去寻找新工作”——纪录片《美国工厂》。什么样的项目适合自动化测试？
1.1 需求稳定，不会频繁变更
1.2 研发和维护周期长，需要频繁执行回归测试。软件产品比软件项目更适合
1.3 需要在多种平台上重复运行相同测试的场景。
1.4 某些测试项目通过手工测试无法实现，或者手工成本太高。
接下来，我们按照下图顺序，进行描述
（传统软件模式）
（互联网产品模式）
0、测试数据准备
1.1 测试脚本和数据的解耦：数据驱动（Data-driven）测试
1.1.1 数据驱动很好地解决了大量重复脚本的问题，实现了“测试脚本和数据的解耦”
1.1.2 数据驱动测试的数据文件中不仅可以包含测试输入数据，还可以包含测试验证结果数据，甚至可以包含测试逻辑分支的控制变量。
1.1.3 数据驱动测试的思想不仅适用于 GUI 测试，还可以用于 API 测试、接口测试、单元测试等
1.2 创建测试数据的方法
1.2.1 按创建的技术手段分
1.2.1.1 API 调用
1.2.1.2 数据库操作
1.2.1.3 综合运用 API 调用和数据库操作
1.2.2 按创建的时机分
1.2.2.1 测试用例执行过程中，实时创建测试数据：On-the-fly
1.2.2.2 测试用例执行前，事先创建好“开箱即用”的测试数据：Out-of-box
1.2.2.3 综合运用这两种手段
1.3 测试数据平台
1.3.1 测试数据准备的 1.0 时代：将测试数据准备的相关操作封装成数据准备函数。利用这种数据准备函数创建测试数据方法的最大短板，在于其参数非常多、也非常复杂。
绝大多数的测试数据准备场景，只对个别几个参数有明确的要求，而其他参数都可以是缺省值的。
1.3.2 测试数据准备的 2.0 时代：引入 Builder Pattern（生成器模式）的封装方式，如果仅仅需要一个全部采用缺省参数的数据的话，你可以直接使用 TestDataBuilder.build() 得到；
如果你对其中的某个或某几个参数有特定要求的话，你可以通过“.withParameter()”的方式指定，而没有指定的参数将自动采用默认值。引入 Build Strategy 数据构建的策略，
引入Search Only、Create Only、Smart 和 Out-of-box 这四种数据构建的策略
1.3.3 测试数据准备的 3.0 时代：跨平台，将基于 Java 开发的数据准备函数用 Spring Boot 包装成了 Restful API，并且结合 Swagger 给这些 Restful API 提供了 GUI 界面和文档。
所以只要测试框架能够发起 http 调用，就能使用这些 Restful API
1、单元测试
一般由开发自行完成，但测试框架选型、覆盖率统计工具选型、测试用例设计原则等都需要资深的测试工程师或者测试架构师参与。
1.1 代码错误
1.1.1 有特征”的错误
1.1.1.1 语法特征错误：从编程语法上就能发现的错误
1.1.1.2 边界行为特征错误：代码在执行过程中发生异常，崩溃或者超时
1.1.1.3 经验特征错误：根据过往经验发现代码错误
1.1.2 无特征”的错误
1.1.2.1 算法错误：代码完成的计算（或者功能）和之前预先设计的计算结果（或者功能）不一致。
1.1.2.2 部分算法错误：在一些特定的条件或者输入情况下，算法不能准确完成业务要求实现的功能
1.2 测试方法
1.2.1 静态方法
1.2.1.1 人工静态方法：代码走查、结对编程、同行评审（最普遍）
1.2.1.2 自动静态方法：词法分析、语法分析、控制流分析等技术，并结合各种预定义和自定义的代码规则，对程序代码进行静态扫描，与持续集成绑定。Sonar、Coverity
1.2.2 动态方法
1.2.2.1 人工动态方法：单元测试框架，Java的Junit、TestNG，C语言Google Test
1.2.2.1.1 单元测试用例“输入参数”的复杂性
1.2.2.1.1.1 被测试函数的输入参数
1.2.2.1.1.2 被测试函数内部需要读取的全局静态变量
1.2.2.1.1.3 被测试函数内部需要读取的类成员变量
1.2.2.1.1.4 函数内部调用子函数获得的数据
1.2.2.1.1.5 函数内部调用子函数改写的数据
1.2.2.1.1.6 嵌入式系统中，在中断调用中改写的数据
1.2.2.1.2 单元测试用例“预期输出”的复杂
1.2.2.1.2.1 被测函数的返回值
1.2.2.1.2.2 被测函数的输出参数
1.2.2.1.2.3 被测函数所改写的成员变量和全局变量
1.2.2.1.2.4 被测函数中进行的文件更新、数据库更新、消息队列更新等
1.2.2.1.3 关联依赖的代码不可用：桩函数主要有两个作用，一个是隔离和补齐，另一个是实现被测函数的逻辑控制。mockito
1.2.2.2 自动动态方法：基于代码自动生成边界测试用例并执行，以捕捉潜在的异常、崩溃和超时。
1.2.2.2.1 根据被测函数的输入参数生成可能的边界值
1.2.2.2.2 根据被测函数的原形，生成测试用例代码模板
1.2.2.2.3 将参数 @a@和 @s@的各种取值循环组合，分别替换模板中的相应内容，即可生成用例集。
1.3 单元测试阶段自动化
1.3.1 第一，用例框架代码生成的自动化：如TestNG 框架代码应该由自动化工具生成
1.3.2 第二，部分测试输入数据的自动化生成：自动化工具能够根据不同变量类型自动生成测试输入数据
1.3.3 第三，自动桩代码的生成：桩代码（stub code）是用来代替真实代码的临时代码
1.3.4 第四，被测代码的自动化静态分析：分析工具有 Sonar 和 Coverity 等
1.3.5 第五，测试覆盖率的自动统计与分析：包括代码行覆盖率、分支覆盖率、MC/DC 覆盖率等
代码级集成测试的自动化技术，就是单元测试的桩代码换成了真实函数而已。
2、API自动化
1.0 Web Service 测试的自动化技术：主要是指 SOAP API 和 REST API 这两类 API 测试，最典型的是采用 SoapUI 或 Postman 等类似的工具。
但这类测试工具基本都是界面操作手动发起 Request 并验证 Response，所以难以和 CI/CD 集成，于是就出现了 API 自动化测试框架。
1.0.1 API 测试用例执行的自动化：目前最流行的 API 自动测试框架是 REST Assured
1.0.1.1 准备 API 调用时需要的测试数据；
1.0.1.2 准备 API 的调用参数并发起 API 的调用；
1.0.1.3 验证 API 调用的返回结果。
1.0.2 测试脚手架代码的自动化生成：包含了被测试 API 的调用、测试数据与脚本的分离，以及 Response 验证的空实现
1.0.3 部分测试输入数据的自动生成
1.0.4 Response 验证的自动化：Response 验证自动化的核心思想是自动比较两次相同 API 调用的返回结果，并自动识别出有差异的字段值，
比较过程可以通过规则配置去掉诸如时间戳、会话 ID（Session ID）等动态值。
1.0.5 基于 SoapUI 或者 Postman 的自动化脚本生成：开发一个自动化代码转换生成工具。这个工具的输入是 SoapUI 或者 Postman 的测试用例元数据（即测试用例的 JSON 元文件），
输出是符合 API 测试框架规范的基于代码实现的测试用例。这样一来，原本的测试用例积累可以直接转换成在 CI/CD 上可以直接接入的自动化测试用例。
1.1 早期：Postman+Newman，基于命令行，与 CI/CD 流水线整合
1.2 后期：连续调用多个 API 并涉及到参数传递，基于代码
1.2.1 小企业：API 测试框架
1.2.1.1 基于 Java
1.2.1.1.1 OkHttP
1.2.1.1.2 Unirest
1.2.1.2 基于 Python
1.2.1.2.1 http.client
1.2.1.2.2 Requests
1.2.1.3 基于 NodeJS
1.2.1.3.1 Native
1.2.1.3.2 Request
1.2.2 中大企业：在成熟 API 测试框架的基础上封装自己的 API 测试框架
1.2.2.1 自动生成 API 测试代码
1.2.2.2 Response 结果发生变化时的自动识别
3、GUI自动化
1.1 GUI 测试的自动化技术
1.1.1 传统 Web 浏览器
1.1.1.1 业内主流的开源方案采用 Selenium
1.1.1.2 商业方案采用 Micro Focus 的 UFT（前身是 HP 的 QTP）
1.1.2 移动端原生应用（Native App）
1.1.2.1 业界主流Appium：iOS 环境集成了 XCUITest，对 Android 环境集成了 UIAutomator 和 Espresso
1.1.2.2 蚂蚁金服开源SoloPi
1.1.3 全部支持：阿里开发的macaca
1.2 代码设计
1.2.1 页面对象（Page Object）模型
1.2.1.1 解决了脚本可读性差的问题，脚本的逻辑层次也更清晰了；
1.2.1.2 解决了通用步骤会在大量测试脚本中重复出现的问题
1.2.1.3 页面对象模型的核心理念是，以页面（Web Page 或者 Native App Page）为单位来封装页面上的控件以及控件的部分操作。
而测试用例，更确切地说是操作函数，基于页面封装对象来完成具体的界面操作，最典型的模式是“XXXPage.YYYComponent.ZZZOperation”
1.2.2 业务流程抽象：从业务的维度来指导测试业务流程的封装
1.2.2.1 业务流程（Business Flow）的封装更接近实际业务；
1.2.2.2 基于业务流程的测试用例非常标准化，遵循“参数准备”、“实例化 Flow”和“执行 Flow”这三个大步骤，非常适用于测试代码的自动生成
1.2.2.3 由于更接近实际业务，所以可以很方便地和 BDD（Behavior Driven Development，即行为驱动开发） 结合
1.3 GUI测试稳定性
1.3.1 非预计的弹出对话框——GUI 自动化框架自动进入“异常场景恢复模式”
1.3.2 页面控件属性的细微变化：实现自己的对象识别控制层，也就是在原本的对象识别基础上额外封装一层，在这个额外封装的层中加上模糊匹配的实现逻辑；
不建议把模糊匹配逻辑以硬编码的方式写在代码里，而是引入规则引擎，将具体的规则通过配置文件的方式与代码逻辑解耦。
1.3.3 被测系统的 A/B 测试：界面或流程提供两个不同的版本，然后让用户随机访问其中一个版本。在测试脚本内部对不同的被测版本做分支处理
1.3.4 随机的页面延迟造成控件识别失败：加入重试（retry）机制
1.3.5 测试数据问题
1.4 GUI 测试报告
1.4.1 理想中的 GUI 测试报告应该是由一系列按时间顺序排列的屏幕截图组成，并且这些截图上可以高亮显示所操作的元素，同时按照执行顺序配有相关操作步骤的详细描述
1.4.2 商业的 GUI 自动化测试软件：UFT（就是以前的 QTP）自带了截图以及高亮显示操作元素功能
1.4.3 开源 GUI 测试框架:
1.4.3.1 利用 Selenium WebDriver 的 screenshot 函数在一些特定的时机（比如，页面发生跳转时，在页面上操作某个控件时，或者是测试失败时，等等）完成界面截图功能。
1.4.3.2 扩展 Selenium 原本的操作函数实现截图以及高亮显示操作元素的功能
1.4.3.3 在相关的 Hook 操作中调用 screenshot 函数实现截图以及高亮显示操作元素的功能
1.4.3.4 全球化 GUI 测试报告
下面以全球大型电商网站为例，介绍GUI测试策略
1.1 GUI自动化测试策略设计
1.1.1 首先，要从前端组件的级别来保证质量，也就是需要对那些自定义开发的组件进行完整全面的测试。
1.1.2 其次，每一个前端模块，都会构建自己的页面对象库，并且在此基础上封装开发自己的业务流程脚本。这些业务流程的脚本，可以组装成每个前端模块的测试用例。
1.1.3 最后，组合各个前端模块，并站在终端用户的视角，以黑盒的方式使用网站的端到端（E2E）测试。
1.1.3.1 一部分是，通过探索式测试的方法手工执行测试，目标是尽可能多地发现新问题
1.1.3.2 另一部分是，通过 GUI 自动化测试执行基本业务功能的回归测试
1.2 测试用例开发人员：各模块自己开发团队应该尽可能地利用各个模块已有的页面对象和业务流程脚本，组装端到端的 GUI 测试。
1.3 GUI 自动化测试脚本管理
1.3.1 各模块自己开发团队自己开发页面对象和业务流程脚本
1.3.2 成立系统级别GUI测试团队，及时更新各模块的组件，组装端到端的 GUI 测试
下面介绍移动端GUI测试
1.1 Web App：指的是移动端的 Web 浏览器
1.1.1 本质就是 Web 浏览器的测试
1.1.2 自适应网页设计，也能用PC端的测试用例，但移动端浏览器必须支持 Web Driver
1.2 Native App：指的是移动端的原生应用
1.2.1 iOS 一般采用 XCUITest Driver
1.2.2 Android 一般采用 UiAutomator2 或者 Espresso
1.3 Hybrid App（俗称：混血应用）：是介于 Web App 和 Native App 两者之间的一种 App 形式
1.3.1 对 Native Container 的测试，可能需要用到 XCUITest 或者 UiAutomator2 这样的原生测试框架
1.3.2 对 Container 中 HTML5 的测试跟PC一样
展望GUI测试最新技术应用
1.1 页面对象自动生成：只需要提供 Web 的 URL，自动生成这个页面上所有控件的定位信息，并自动生成 Page Class
1.1.1 商用自动化工具UFT
1.1.2 免费的Katalon Studio
1.2 GUI 测试数据自动生成：指的由机器自动生成测试用例的输入数据
1.2.1 根据 GUI 输入数据类型，以及对应的自定义规则库自动生成测试输入数据
1.2.2 对于需要组合多个测试输入数据的场景，测试数据自动生成可以自动完成多个测试数据的笛卡尔积组合，然后再以人工的方式剔除掉非法的数据组合
1.3 无头浏览器：无头浏览器执行过程中看不到运行的界面，但是你依然可以用 GUI 测试框架的截图功能截取它执行中的页面
1.3.1 主要应用场景
1.3.1.1 GUI 自动化测试
1.3.1.2 页面监控
1.3.1.3 网络爬虫
1.3.2 优点：测试执行速度更快、减少对测试执行的干扰、简化测试执行环境的搭建、在单机环境实现测试的并发执行
1.3.3 最新技术：2017 年 Google 发布了 Headless Chrome，以及与之配套的 Puppeteer 框架；Puppeteer 是一个 Node 库，提供了高级别的 API 封装
偏功能的三层测试讲解完毕，接下来是偏运维的部分。
4、性能测试
5、安全测试
6、专项测试（移动端）
1.1 第一，交叉事件测试：此类测试目前基本还都是采用手工测试的方式，并且都是在真机上进行，不会使用模拟器。
1.2 第二，兼容性测试：通常都需要在各种真机上执行相同或者类似的测试用例，所以往往采用自动化测试的手段。
大公司会基于 Appium + Selenium Grid + OpenSTF 去搭建自己的移动设备私有云平台外，其他公司一般都会使用第三方的移动设备云测平台完成兼容性测试。
第三方的移动设备云测平台，国外最知名的是 SauceLab，国内主流的是 Testin。
1.3 第三，流量测试：往往借助于 Android 和 iOS 自带的工具进行流量统计，也可以利用 tcpdump、Wireshark 和 Fiddler 等网络分析工具
1.4 第四，耗电量测试
1.5 第五，弱网络测试：开源移动网络测试工具：Facebook 的 Augmented Traffic Control（ATC）。
1.6 第六，边界测试
测试执行结束，编写测试报告：
7、测试报告
1.1 缺陷标题：采用“在什么情况下发生了什么问题”的模式
1.2 缺陷概述：是缺陷标题的细化
1.3 缺陷影响：按需描述，只描述那些重现缺陷的环境敏感信息
1.4 前置条件：测试步骤开始前系统应该处在的状态
1.5 缺陷重现步骤
1.6 期望结果和实际结果
1.7 优先级（Priority）和严重程度（Severity）
1.7.1 优先级：指缺陷必须被修复的紧急程度，是缺陷的工程属性，会随着项目进度、解决缺陷的成本等因素而变动。
1.7.2 严重程度：是指因缺陷引起的故障对软件产品的影响程度，缺陷本身的属性，通常确定后就不再变化
1.7.3 两者关系：缺陷不严重但妨碍测试执行，优先级就越高；缺陷严重但修复成本高
1.8 变通方案（Workaround）：临时绕开当前缺陷而不影响产品功能的方式
1.9 根原因分析（Root Cause Analysis）
2.0 附件（Attachment）界面截图、测试用例日志、服务器端日志、GUI 测试的执行视频
四 测试（各种测试执行）
1、测试架构
1.1 测试执行机器：Selenium Grid
1.2 测试执行环境：
1.2.1 目标：简化测试的执行过程、最大化测试执行机器的资源利用率、提供大量测试用例的并发执行能力、提供测试用例的版本控制机制、提供友好的用户界面、提供了与 CI/CD 流水线的统一集成机制
1.2.2 设计原则：保证对使用者的“透明性”；需要具备对维护者而言的“易维护性”；做到对大量测试用例并发执行的“可扩展性”；兼顾移动 App 对测试执行环境的需求。
1.2.3 具体设计：
为了降低测试用例过多时 Selenium Grid 的维护成本，用 Docker 容器代替经典测试基础架构中的实体机 / 虚拟机，形成了基于 Docker 实现的 Selenium Grid 测试基础架构。
测试用例的数量过多，管理和执行发起测试的Jenkins Job成了问题。于是引入一个基于 GUI 界面的测试执行平台，并在其上扩展了诸如测试用例版本化、提供基于 Restful API 的测试执行接口等功能。
单个 Jenkins 有瓶颈，过渡到基于 Jenkins 集群的测试基础架构，通过多个同时工作的 Jenkins Slave，解决了大量测试请求排队的问题
为解决 Selenium Grid 中 Node 的数量到底多少才合适的问题，引入创新设计的 Selenium Grid 的自动扩容和收缩技术
2、电商平台测试架构实例
测试服务化
1.1 统一测试执行服务：CI/CD 流水线脚本调用 Restful API 进行统一测试服务执行。
1.2 统一测试数据服务：就是统一测试数据平台，隐藏了测试数据准备的所有相关细节
1.3 测试执行环境准备服务：对于 GUI 自动化测试来说，指的就是 Selenium Grid；对于 API 测试来说，指的就是实际发起 API 调用的测试执行机器集群。
1.4 被测系统部署服务
1.5 测试报告服务：将测试报告的元数据存入到测试报告服务的 NoSQL 数据库，开发一些用于分析统计的 SQL 脚本
五 测试知识扩展
1、探索式测试
2、测试驱动开发
3、精准测试
4、渗透测试
5、基于模型的测试：是自动化测试的一个分支。它是将测试用例的设计依托于被测系统的模型，并基于该模型自动生成测试用例的技术。
六 测试以外的知识
1、网站架构
2、容器技术
3、云计算技术
4、DevOps 思维
5、前端开发技术：做前端组件精细化测试