测试架构师的知识能力模型

内容来源：《测试架构师修炼之道》第二版

必备的能力和知识体系

必备的6个关键能力

归结来说，针对不同的组织、产品和研发模式作出最适合当前情况的选择的能力，就是制定测试策略的能力。

知识体系

软件产品质量模型

相关解释：

• 依从性：产品遵循与相关的标准、约定或规定的能力，比如：可靠性的依从性指产品遵循可靠性相关的标准

基于质量的测试方法🌟

如何划分压力测试、性能测试、稳定性测试和可靠性测试，标准是根据质量属性来定义测试类型。举例：

• 测试负载在系统允许的负载范围内，属于功能性测试，在此基础上加大测试时间，属于稳定性测试
• 测试负载正好和系统负载一致，属于性能测试
• 测试负载超过系统允许的测试范围，测试系统容错性，属于可靠性中的压力测试

功能性测试方法

• 运行：在软件测试中，测试者模拟用户的一次输入到一次输出称为一次运行

• 单运行：在软件测试中，测试者模拟用户的一个操作或一个行为
  

• 多运行：在软件测试中，测试者模拟用户的多个操作或多个行为
  

可靠性测试方法

• 异常值输入法：使用系统不允许输入的数值作为测试输入值（包括为空）。
• 故障植入法：将系统放在有问题的环境中，输入正常值，预期有相应的应对措施。
• 稳定性测试法：在一段时间里长时间、高负载运行某种业务的可靠性测试方法。重点是：多(多个功能)+并(多个用户同时)+复(反复操作)+异(部分用户反复进行异常操作)。
• 压力测试法：持续压力负载模型测试、突发压力负载模型测试
  
• 恢复测试法：使用持续超过性能规格的负载进行测试后，再将负载降到性能规格以内的测试方法。

性能测试方法

• 基线性能测试法：测试系统可以达到的最优性能。
  • 系统能够正确处理新业务的最大能力
  • 系统能够同时正确处理业务的最大能力
  • 基线性能测试法的关键：控制性能指标之间的相互影响
• 影响性能的因子测试法：测试系统在各种因子影响下的最差性能。
  • 单功能因子影响下的性能：二分五点去值法，比如最大因子是1000，则取值1 >> 1000 >> 500 >> 250和750。
  • 多功能因子影响下的性能
    
• 场景性能测试法：验证系统在用户真实场景下的使用性能。
  • 从用户使用习惯入手，分析用户有哪些典型的部署场景、部署方式和部署环境来构造测试用例。

易用性测试法

• 一致性测试法：页面和产品整体的风格是否相符、图标和元素是否符合产品的设计规范等。
• 可用性测试：梳理用户典型场景确认测试范围、讨论确定测试关注点和测试标准。

安全性测试方法

• 权限测试：主要包括未授权访问和越权两大类。
• 参数校验测试
  
• 传输安全性测试：通信方式、数据传输、升级接口、文件传输、拒绝服务工具等安全性测试。

基于车轮图的测试分析方法

• 测试分析不等于测试设计
  
• 测试点不等于测试用例
• 产品测试车轮图：从哪些方面（测试类型）用哪些方法（测试方法）去测试产品（质量属性）。
  
• 在MM图（思维导图工具）中使用车轮图
  
• 使用测试分析设计表来进行测试分析
  

基于模型的测试设计技术

测试设计四步法🌟

1. 步骤一，对测试点进行分类：流程类、参数类、数据类和组合类。
2. 步骤二，建模：
   • 流程类，绘制流程图
   • 参数类，创建输入输出表
   • 数据类，创建等价类分析表
   • 组合类，创建因子表
3. 步骤三，确定测试条件和测试数据
   
4. 步骤四，根据经验扩展、补充测试用例
   • 对测试点进行分类
   • 流程类测试点
     
   • 参数类测试点的特点：
     • 参数值的取值范围是有限的，可以通过遍历的方式来测试覆盖度。
     • 系统会对不同的参数值作出不同的处理和响应。
   • 数据类测试点的特点：
     • 数据的取值是一个范围，通常用于遍历覆盖测试效率低下或者无法完成的场景。
     • 系统对允许输入的数据值的处理或响应往往是一样的。
   • 组合类测试点的特点：一般有多个输入

流程类测试设计——路经分析法

• 语句覆盖：覆盖系统中所有判定过程的最小路径的集合。
• 分支覆盖：覆盖系统中每个判定的所有分支所需的最小路径数。
• 全覆盖法：覆盖所有可能路径的集合。
• 最小线性无关覆盖：在保证流程图中每个路径片段都能被至少执行一次的情况下，得到的路径组合是最少的。计算最小线性无关路径的数目：
  • 等式1：最小线性无关路径 = 边数 - 节点数 + 2
  • 等式2：最小线性无关路径 = 判定数 + 1
  • 等式3：最小线性无关路径 = 区域数 + 1
  • 上述计算需要遵循如下约定：（将系统流程分解成满足约定的小流程，路径数等于每个流程最小线性无关路径总和。）
    • 约定1: 流程图的入口和出口不作为边数计算。
    • 约定2: 一个流程图只有一个入口点和一个出口点。

参数类测试设计——输入-输出表分析法

表格内容：编号、各种输入类型、输出、说明

数据类测试设计——等价类和边界值分析法

有效等价类、无效等价类

组合类测试设计——正交分析法

错误推断法

控制测试用例的粒度

测试点的组合和拆分：

• 对系统可能没有影响或者影响很弱的地方，没有必要使用Pairwise来进行正交
• 和其他测试点没有关联，没必要正交
• 重要、优先级高的因子，可以加大分配量
• 尽量将和这个测试用例有关的因子或数据值分配到一起，便于测试执行

影响测试设计效果的因素

• 烂需求、伪需求和不清晰的需求。
• 开发的功能无法有效验证，可测试性不强。
• 过于死板的测试设计策略。

有效澄清和确认需求

有针对性的可测试性需求

• 用户层面的可测试性：用户便于验收、确认产品/系统功能的正确性或故障的需求。
• 测试层面的可测试性：开发/测试人员方便确认产品需求设计的需求。
• 维护支持层面的可测试性：维护支持人员用于快速定位或确认产品/系统故障的需求。

从业务流程交互的角度来分析可测试性需求

分析如何能在测试时方便跟踪到业务的整个交互过程，便于确认交互的正确性相关的可测试性需求。

从异常状态的角度来分析可测试性需求

如服务器异常退出、超时、统计服务器连接情况等角度的可测试性需求。

从测试用例的预期结果来分析可测试性需求

针对一些测试用例的结果不易于观察时，提出可测试性需求。

可测试性分析展开的时机和要点

• 前期需求阶段：主要从用户层面来提出可测试性需求。
• 开发设计阶段：主要从测试验证角度来提出可测试性需求。

基于场景的测试方法

• 场景和场景测试：从场景的角度对系统进行测试和验证。
• 使用场景测试模型来进行测试分析：
  • 从用户使用习惯来分析和组织场景
    
  • 分析主要场景和次要场景
    
  • 确定用户部署、配置、负载和用户关注点
  • 场景测试用例输出
    

探索式测试

探索式测试是一种软件测试风格：希望可以边学边测，重视反馈，持续优化调整。
但可能会带来一些问题：

• 测试人员会有短期无法弥补的能力短板
• 学习能力不足的测试人员不能快速抓到测试重点，上手慢
• 探索失败会带来挫败感，会项目交付造成影响
• 更多的沟通不一定是有效的沟通
• 测试人员的独立人格会使合作性变差
• 经验传承会成为一种瓶颈
• 探索使测试快捷搜、不断学习和变化的特点会引发测试人员的疲惫感，这一点团队人员不一定都可以接受

探索式测试的基本思想：CPIE思维模型

CPIE思维模型：Collation 收集、Prioritization 划分优先级、Investigation 分析调研、Experimentation 实验

选择合适的探索式测试方法

1. 第一步：对被测对象进行分区（可能存在相互重叠的情况，这就需要对一个特性使用多种探索式测试方法）
   • 历史区（继承特性）
   • 商业区（销售特性）
   • 娱乐区（辅助特性）
   • 破旧区（问题高发区）
   • 旅游区（噱头特性）
2. 第二步：根据不同的分区来选择合适的探索式测试方法
   • 历史区测试方法
     
   • 商业区测试方法
     
   • 娱乐区测试方法
     
   • 破旧区测试法
     
   • 旅游区测试法
     

开展探索式测试

1. 确定任务：全局场景探索（整个系统）、特性漫游探索（系统特性）、局部功能点探索（某具体功能点）。
2. 确定测试时间：在一个确定的时间（如2小时、4小时）里去执行、回顾和总结，并调整测试策略。
3. 绘制探索地图：使用思维导图工具绘制，根据被测对象的特点进行分区，选择相关的探索方法，获得测试点，再根据测试点执行。
   
4. 测试报告：整理测试中发现的问题、测试思路、方法、工具和需要注意的地方等。
5. 总结回顾：
   • 本次探索式测试的效果如何？
   • 哪些方法更有效？
   • 有哪些更有效的工具？
   • 哪些案例值得总结、分享和推广？

自动化测试

自动化测试最基本的要求：
1、能充分信任的自动化结果。
2、可稳定持续运行，可维护，可移植。

自动化测试的真相：

• 自动化测试并不廉价，其实自动化很贵。（前期投入，后期维护与结果检查）
• 自动化测试的意义首先在于固化能力，其次才是提升效率。（把原来测试人员的能力，通过脚本固化，形成标准的组织资产）
• 自动化测试不是单靠测试人员就能搞定的。（需要整个团队的支持）

自动化测试分层

单元测试、接口测试、UI测试

Test double：为保证测试代码可以顺利进行而编写的各种依赖
Stub（桩）：在被测对象需要调用其他代码时，提供所需功能存在的假象。
Mock：对预期进行编程，形成被调用后预期的规范。

自动化测试框架

AW：可被自动化脚本直接调用的、有意义的测试接口。

• 操作关键字
• 检查关键字
• 业务负载关键字
• 测试数据关键字
• 测试环境关键字

自动化脚本组织结构举例：

DevOps自动化效能平台架构：

如何有效开展自动化测试

1. 自动化测试可行性分析
   
   
   
2. 有效开展自动化测试
   
3. 如何评估自动化的收益
   • 自动化测试的实施成本 = 自动化前期开发成本（人力、时间、钱） + 自动化后期维护成本（需求设计变更、问题定位与修复）
   • 自动化测试的执行次数
   • 自动化测试实施成本比 = (执行测试的时间x执行次数)/(前期成本+后期成本)

自动化测试成熟度模型

软能力修炼

沟通与协商

• 通过沟通来获得需求、设计的细节。
• 通过沟通来和团队成员就测试目标、范围、策略、方法达成一致，确保测试效果。
• 通过沟通来获得对测试有用的信息，以此来确定测试策略。
  • 阅读相关文档时，不仅是去理解被测对象是如何设计实现的，更重要的是思考如何正确、有效验证被测对象，以及开发者是如何完成开发的，开发过程是否引入了风险。
• 向领导或者决策者汇报当前的版本质量

沟通原则：

• 尽早沟通对齐：各个角色在一开始就目标、思路和方法，沟通清楚要求和限制。
• 既要对事，也要对人：理解沟通对象、换位思考，要以对方能够理解的方式来表达。
• 主动反复沟通：要有确认的方法，确保大家在第一时间都真正理解了任务。
  • 询问听众的意见，加强互动。
  • 请被沟通方输出纪要，通过纪要确认是否对齐。
  • 请一位听众再复述一遍，确认是否有偏差。
  • 确保大家都在参与讨论，而不是只有少数人在讨论。
  • 请被沟通对象就沟通内容输出提纲，对提纲做一轮快速确认或评审，确保理解一致。
  • 从正向和逆向的角度分别进行沟通，确认对同一事物的理解达成一致。

写出漂亮的测试用例

• 统一测试用例编写风格
• 测试用例编写风格指导
  
  
  注意：对测试用例中需要反复、多次、大量、长时间进行的操作量化，具体到次数和时间。
• 如何编写测试用例案例集
  

组织和管理测试用例

测试用例模板

基于特性树组织测试用例

特性：用户可见的价值点。
特性集：对特性进行归类。
特性树：特性及和特性形成的树形结构。

持续学习和探索