第一章

对软件测试的全面认识，测试不能是穷尽的
软件测试的作用：
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、全程性能测试示意图：