《全程软件测试第三版》拆书笔记

Violettt.

已于 2023-11-16 16:34:07 修改

阅读量334

点赞数 1

文章标签：单元测试测试工具压力测试

于 2023-11-16 16:18:58 首次发布

本文链接：https://blog.csdn.net/qq_46126666/article/details/131738257

版权

第一章

对软件测试的全面认识，测试不能是穷尽的
软件测试的作用：
1.产品质量评估；2.持续质量反馈；3.客户满意度提升；4.缺陷的预防

正反思维：正向思维（广度，良好覆盖面）+逆向思维（深度，提升效率）
狭义到广义：动态测试（狭义，编程之后介入测试），动+静（广义，贯穿全程）
基于质量：产品质量（质量模型）+使用质量
基于风险：测试的持续性，工作有侧重（2/8原则）
基于社会性：思维能力和探索能力，理解用户
基于经济：以最小代价获得更高收益
基于标准：验证（v模型）+有效性确认
基于Test Oracle：检验已知的+试验未知的
基于批判性思维：不断地质疑
传统与敏捷模型：瀑布模型（传统），敏捷侧重迭代式与增量型更关注产品本身，快速交付

第二章

强调测试是全阶段的，DevOps就是推动左移右移的完整链条

测试左移与右移：左移是提前介入测试，右移是将测试延伸，在线测试等
测试驱动开发：TDD测试优先，左移，编码在后，缺陷预防
传统研发模式的测试环：分阶段，单元&集成测试同时进行
敏捷研发中的测试环：测试融入全程
DevOps 与测试：打通开发、运维与测试各环节，自动化和监控，形成生态链。

第三章

测试的基础设施：测试工具&机器、网络、自动化框架、DevOps工具链

虚拟机与容器技术：早期是物理机器，虚拟机搭建整体架构，容器通过命名空间隔离(更小
基础设施即代码 Iac：价值体现在环境维护成本、速度和风险
持续集成环境 CI：自动构建、部署、验证、发布结果供浏览
自动化测试框架：分不同层次（单元、接口、系统）
DevOps完整工具链：构建、测试、工件管理、部署、评估

第四章

个体与团队
个体需要在技术上挖掘深度（如某个技术栈的深度）
团队

测试3个发展方向：技术管理、业务专家、测试开发/专线测试
软件测试的系统性思维：关注软件质量模型、关注自己的测试质量、效率、缺陷命中率、交付质量、非功能性缺陷，可度量；分析性思维、批判性思维、创造性/发散性思维
软件测试要素：思想、方法、方式、技术、流程、管理等
敏捷测试关注的能力
DepOps对测试的影响：测试要快、测试自动化大挑战、业务测试、少量专业测试（测试教练、顾问、QA）、测试开发SET受宠

第五章

项目启动的准备

产品使用质量模型&产品质量模型
了解项目背景，重要元素：项目的目标、交付物、质量要求、范围、进度、可用的资源(开发)团队、开发环境、相关利益者。
了解产品元素：主要从结构、功能、数据、平台、操作、时间等方面分析。
采用合适的测试技术/方法：方法有很多，要根据每种方法的应用场景以及技术特点来划分。主要为：
基于直觉和经验的方法
基于输入域的方法。
组合测试方法。
基于逻辑覆盖的方法。
基本路径测试方法。
基于故障模式的测试方法。
基于模型的测试方法。
模糊测试方法。
基于场景的测试方法。
不同的开发模式就有不同的测试实践，如敏捷开发中应该采用更适合敏捷的测试实践。
确定测试规范：主要从以下几个方面，角色的确定，进入准则，输入项，活动过程，输出项，评审与评估，退出准则，度量。

第六章

测试需求与测试计划的考虑

计划是一个持续的过程，在制定计划前要明确测试的目标，既要有优先级，又要从测试和业务的角度全面分析（如功能、非功能、依赖于项目的特性问题等）
根据测试的范围和任务去估算测试的工作量，根据一个公式： W代表工作量（人时） Rx代表第x轮测试的程度 R是递减的（如：90% 70% 50%）

其中W可以通过“工作分解结构表”WBS（任务分解通过对测试任务一层层细分工时直到不能分解）来计算

测试里程碑：敏捷测试

  1测试任务定义
  
  2测试计划制订和评审通过。
  
  3测试需求或测试点 (或测试场景)列表制定
  
  4评审通过验收测试结束。

在这里插入图片描述

测试风险：

风险识别的有效方法是建立风险项目检查表，按风险内容进行逐项检查

风险检查表：

人员风险、环境风险、测试范围(广度)、测试深度、回归测试、需求变更、用户期望、测试技术、测试工具

风险管理：风险评估+风险控制

第七章

测试用例设计思想、方法和组织角度

从需求到测试用例：“从需求、功能特性、用例 (用户故事)到场景、测试数据/条件等”
从用户的需求到使用的场景，用户可能会进行的操作来思考，可以查缺补漏到一些特殊场景。
基于SUT（被测系统）结构设计：“层次很清晰，有业务逻辑层、具体数据层”
设计测试用例需要考虑的因素：

1、测试需求目标：包含功能性和非功能性。
2、用户实际使用的场景：贴近用户更正确。
3、软件功能需求规格说明书、产品设计文档等：描述方式、文档是否详细等。

4、测试的方法对测试用例的设计影响大：白盒测试和黑盒测试的思路方式不同。

5、被测试对象：被测对象是客户端还是服务端侧重点是不同的。
如何运用测试设计方法？

1.测试设计服务测试目标：首先用例上3个程度的覆盖（20%高优，80%基础，尽可能覆盖）
从代码角度的覆盖：

2、可以通过数据流、控制流层面做到覆盖

3、灵活运用多种测试方法，如白盒的基本路径覆盖、逻辑覆盖、等价类划分、边界值分析等
非功能性测试如何设计？（更多的单独后几章讲，此处特指本地故障转移）
探索性测试没有设计吗？处于流程完善性考虑，人们提出了基于会话的测试管理方法：

基于会话，顾名思义就是把一次会话设定为一次不被打扰的进程：通过角色扮演的方式，实际以用户角度的具体场景进行测试
测试用例的规范性与评审？
1、规范性：从5W1H上看构成，why what when where which how

2、评审：建立checkList，通过各方面提问模式查缺补漏
测试集的创建？

通用的三种测试集的方式：
1、按照程序的功能模块组织
2、按照测试用例的类型组织
3、按照测试用例的优先级组织
根据这三种可得出大致框架：

第八章

测试的执行与探索型测试
缺陷及缺陷报告

测试的执行过程？是立体的，前半段强调测试效率、侧重发现缺陷，后半段重点是降低风险、系统地覆盖测试范围。
测试的执行的准备

1、测试任务安排：预估时间和工作量（任务估算），分析软件模块之间的关系，将关联性很强的若干个 (子)任务安排给一个人，不同的阶段可以适当交叉互换测试人员。

2、测试环境建立与配置：
```
    开发一个测试环境审计工具，自动检查环境的配置项是比较彻底。如果没有，就建立一个环境检查表 (Checklist)，靠人工逐项检查。

    测试自动化平台运行，要对结果进行分析（失败的话 是脚本需要维护？还是缺陷）
```
3、有效的创建测试集
功能测试会经历以下几轮不同的测试执行阶段：
```
                     新功能的快速测试。

                     完整的功能性测试，并集中在逻辑性、行为方面的测试界面、适用性测试。

                     探索式测试和回归测试。
   测试集可以按照下列不同维度(功能模块、测试用例优先级、新功能和回归测试、手工测试与自动化测试等)去构建。
```
4、敏捷测试的执行
敏捷开发最有价值的目标：持续交付。更依赖于自动化测试。

5、用户体验和易用性：7元素（符合标准和规范、直观性、一致性、灵活性、舒适性、正确性、实用性）

6、回归测试（策略：兼顾效率和风险）
常见的策略：
(1)再测试全部用例
(2)基于风险选择测试。（风险系数大的优先级高）
(3)基于操作剖面选择测试。（如从用户角度，按照82原则，2的优先级高）

7、缺陷报告（好处：加快缺陷的修正、产品的质量评估、预防缺陷）
更有效的缺陷报告：需要使用简单、准确、专业的语言来抓住缺陷的本质，提供了如何复现当前缺陷的所需信息 (包括截图、Trace log 等)。
缺陷属性：

第九章

不收尾的测试（用户验收、部署验证、在线测试）

验收测试（传统意义上是和用户一同验收，也称交付测试）

1、如今验收测试不一定是最后一项测试，因为我们还可以进行上线后的测试：在线测试。
2、alpha测试：a测试戏称“吃自己做的狗食”，指在公司内部试用。
beta测试：让少数用户/合作伙伴使用反馈。

3、验证list：产品规格说明书、用户环境和准则。

4、实际实践中的验收主要是“产运”，验收标准大多以‘P0/P1case’为准，而UI部分在客户端类型也是重要的一环，我们不做验收标准。
部署验证（主要针对于客户端类，B/S架构的部分存在需要安装插件等）

1、安装前：考虑测试环境，至少准备两种（一版之前安装过，一版之前从未安装过），同时也要考虑两种不同的安装方式（先卸再安、直接覆盖安）。

2、安装测试中：严格按照PRD（此外注意：容错性、灵活性、占用过多资源等问题）。

3、安装结束：检查是否达标正常运行。

4、后台系统的部署验证：相比客户端会更复杂，特别注意系统配置、配置项选择、配置项组合等

（对于我们主要是要注意部署前Apollo的check，以及是否存在多个版本并存的问题）
在线验证（在真实环境上操作）

1、产品工程发布的后续过程：

1-1、LA（Limited Available）：有限可用
1-2、GA（General Available）：全面可用

2、出现有效的线上问题，应仔细分析：

是否是对需求不清楚、是否确实对应使用情景与case、若有case是否环境错误/case遗漏、回归测试是否不充分等。

通过日志分析（Linux的登录日志、移动 App 日志、Web 服务器 Access Log等，由于日志数量巨大需借助一些日志查询工具）

ES：具有索引自动分片、索引副本机制、restful 风格接口、多数据源、自动搜索负载等功能。
测试过程中评审

1、并非等测试结束后再评审复盘，而是在测试过程中发现问题及时纠正。（结合测试计划、测试效果了解测试过程是否规范、是否按期进行等）
在这里插入图片描述

2、与团队成员进行交流（每日的早站会，与开发人员直接沟通更早的发现情况）

具体量化如：到目前为止还没有被关闭的缺陷数、每天开发修正的缺陷数、每天关闭的缺陷数等。

团队反思：持续改进

1、以用户为中心（谁是用户？用户关心哪些问题？忽视了哪些问题？）

2、根因分析（是什么问题→造成问题的根本原因→找到解决问题的措施）

3、数据驱动（应该将数据作为分析手段而非数据驱动目标，以价值为导向引领方向更为准确）

收集相关测试质量数据，可以采用鱼骨图进行分析

4、PDCA循环（闭合的、具有螺旋上升的特性）

PDCA 是一个用于持续改进的简单但有效的模型，代表由计划 (PIan)、执行(Do)、检查(Check)和行动(Action)构成的一个循环过程，如图所示。

第十章

引入静态测试，从而实现“测试左移(Left Shift)”
重点是“审查“

常用的评审方法
在不同阶段各种评审方法是交替使用的，比如我们的需求初评、需求终评、技术反讲、用例评审等。
常用的技术与工具
需求评审的优秀实践
1、需求评审是软件开发的源头，需求评审，是做好软件测试需求分析、测试计划和测试设计等工作的基础。

主要考虑以下几点：
对软件需求进行正确性的检查，以发现需求定义中的问题，尽早地将缺陷发现出来，降低成本，并使后续过程的变更减少，降低风险。
并且及时沟通后达成对需求认知的一致性。

2、需求评审标准

主要包含：正确性、完备性、易理解性、一致性、可行性、易修改性、可测试性、可追溯性。

完备性主要涵盖：涵盖系统需求的功能、性能、输入/输出、条件限制、应用范围等方面。

可追溯性：对需求的背景以及存在的理由进行追溯，每一项需求定义是否可以确定其来源？

3、需求评审方法：

4、需求的可测试性（在敏捷开发中尤为重要，因为对文档的投入较少，不够重视，文档质量堪忧）

需求描述简单，容易造成理解偏差，需要对需求增加一个验收标准。—验收测试驱动开发（ATDD）
系统架构的审查（os：至少目前感觉用不太上）

1、软件体系结构，一般可以分为客户机/服务器 (C/S) 结构、浏览器/服务器 (B/S)结构和中间件多层结构等，也可以分为集中式系统、分布式系统 (如 Cloud、微服务系统)和对等的 P2P 系统(如区块链、以太坊等平台)等，还可以分为实时同步系统、异步系统等。

2、设计技术的评审标准：

结果的稳定性，清晰性，高内聚、低耦合，低复杂度。

3、非功能性质量特性的设计评审要求：安全性、性能、稳定性、扩展性、可靠性。

4、保证设计的可测性：

可观察性、可控制性组成的，可以考虑增加可预见性。

可观察性(Observability): 在有限的时间内使用输出描述系统当前状态的能力。

可控制性(Controllability ): 在特定的合理操作情况下，整个配置空间操作(改变)系统的能力，包括状态控制和输出控制。
可预见性(Predictability): 预测系统状态发生变化的能力。
PRD（设计规格说明书）的复审

PRD的审核应该在整个生命周期的初期，非常重要是测试的标准，可能会灵活性调整，测试人员要想到并且针对变化不断调整计划和方法。

1、编写方式3种：

采用良好的结构化和专业语言编写文本型文档。

建立图形化模型，这些模型可以描绘系统状态及其之间的变化、转换的过程、数据字典及其关系、逻辑流或对象类及其之间的关系。
编写形式化规格说明，通过使用数学上精确的形式化逻辑语言来定义系统设计

2、多层次审查：
系统部署设计的审查
代码评审与静态分析

1、如前文所述，代码的评审通常采用互查（peer review）；关键代码采用会议评审（Inspection）方式。

2、有研究表明，代码评审会不仅不会降低整个开发效率，还会使缺陷率降低15-50%

3、每个公司/团队都有自己的编程规范，建立相应的代码评审检查表，也可使用相关静态代码检查工具（如：FindBugs）

【OS】

第十章的内容，有一些我可能接触不到，做一些了解，但是在需求评审这里确实是日常需要重视的地方，尤其是敏捷开发的特性更需要测试人员去思考补全PRD，需求是验收的标准，对保障测试质量至关重要。

另一个是代码评审，对关键代码/有隐患的应推动MR，提前预防。

第十一章

强调全生命周期的性能测试

常见的性能问题

在这里插入图片描述

如何确定系统的性能需求

1、新系统：“性能基准测试”，作为下一版本的基准。

2、需要优化时：负载测试（“压力测试”、“容量测试”）：更快的找到性能瓶颈。

3、不同配置下获得性能数据：“性能规划测试”，可验证系统的可伸缩性。

4、关键指标分析

5、关键业务分析

结合“2-8原则”操作频率和操作计算量、对资源的需求和依赖等。

如：搜索-下单-提交订单-支付

搜索频率可能有95%，后者是5%，

但订单和支付关联的数据多、对数据库的读写操作和支付相关外部接口往往会成为系统的瓶颈。
如何完成性能测试的设计

1、模拟用户操作：

2、“负载”（可定义为并发用户数）

并发用户数=并发连接数 +请求数据量 +思考时间

3、有效模拟加载过程

负载模式的三阶段（启动、持续进行、结束）

不同的加载模式：

我们通常使用的是递增加载，通过阶梯分段，逐步达到目标。

【os】在线上真实环境测试，阶梯模式在实际性能测试中会更可控。

4、实时准确控制加载：同步点（“集合点”）
```
  同步点，就是用于同步虚拟用户恰好在某一时刻执行任务，确保众多的虚拟并发用户更准确集中进行某个设定的操作。

  注意：同步点也是“相对”的，即使设置同步点 大操作量也无法在几毫秒内完成，可能需要几百毫秒，但不设置则需要几秒或者几十秒。
```
如何执行性能测试

1、工具：Jmeter、Locust、Gatling、Tsung、Flood等

2、工具的具体结构组件：

3、组件顺序

1、配置元件
2、逻辑
3、前置
4、定时器
5、取样器
6、后置
7、断言
8、监听
如何分析和评估测试结果

1、借助监控数据，分析关键数据：

2、对数据分析&定位问题

通过关键指标反映问题，主要从资源（cpu 内存磁盘）和DB相关分析

3、全程性能测试示意图：