一. 软件测试架构师的核心技能- 制定测试策略：

1. 如何才能制定好测试策略：

　　

1.1 理解测试策略 - 什么是测试策略：

　　

1.1.1 通俗说：就是 6 个字：“测什么” 和 “怎么测”。

　　

1.1.2 具体来讲，就是答好和产品测试相关的六大问题：

• a. 测试的对象和范围是什么？

• b. 测试的目标是什么？

• c. 测试的重点和难点是什么？

• d. 测试的深度和广度？

• e. 如何安排各种测试活动 (先测试什么，再测试什么)？

• f. 如何评价测试的效果？

　　

1.2 测试策略不等于测试方针：

1.2.1 测试方针：

• a. 是产品测试中的通用要求、原则或底线。

• b. 显著特点：通用。它不针对某个特点产品，而是一个产品族，或是一个产品系列，并且在较长的一段时间内都是适用的。

　　

1.2.2 测试策略：

• a. 针对当前特定的产品版本而言，不像测试方针那样具备通用性。

• b. 测试策略 = 遵循测试方针 + 项目实际情况。

　　

1.3 测试策略不等于测试计划：

• a. 测试策略不是测试计划，之间的关系：通过测试策略确定的测试活动，在测试计划中拆解为一个个任务，并为每个任务确定工期、执行的先后次序和责任人。

• b. 测试计划的制定者是测试经理，属于测试管理的范畴。而测试策略的制定者是软件测试架构师，属于测试技术的范畴。

　　

1.4 测试策略不等于测试方案：

• a. 测试方案主要解决的是，特性在测试设计和测试执行方面的问题。

• b. 测试策略要解决的是产品测试的六大问题。测试方案要解决的问题，没有那么 “高大上”，就是如何对特性进行测试设计和如何安排这个特性的测试执行，具体包括：

  • b1. 对特性的需求、场景、设计进行分析，提取测试点。
  • b2. 对测试点选择合适的测试设计方法 (如使用怎样的测试设计模型、测试数据的选择)，生成测试用例。
  • b3. 自动化测试设计。
  • b4. 测试执行时，需要按照怎样的顺序来执行这些测试用例。

• c. 测试方案需要遵循测试策略：

  • 测试方案需要遵循测试策略对具体某个特性的测试深度和广度的要求。

• d. 从责任人的角度：

  • 测试策略的责任人是软件测试架构师；测试方案的责任人是各个特性测试责任人。

　　

1.2 四步测试策略制定法：

1.2.1 明确 “产品质量目标”：

• a. 我们的测试目标，就是让产品在发布的时候，能满足事先约定的质量目标。

• b. 围绕产品质量目标进行刚刚好的测试：

  • 产品质量要求高的是测试重点，反之未非重点；
  • 产品质量要求高的测试投入打，反之小；
  • 产品质量要求高的要测得深，反之浅。

• c. 将目标 - 行为 - 评估 形成闭环：

  • 产品质量目标使得产品质量评估变得可行。思路：
  • 首先，将产品质量评估模型作用于具体的产品，得到产品质量目标；
  • 其次，根据产品质量目标来制定测试策略，确定接下来的测试活动；
  • 再次，执行各种测试活动；
  • 最后，对测试效果进行评估，评估产品的质量目标是否达到。

　　

1.2.2 进行 “风险分析”：

• a. 提前识别项目中，可能存在哪些会阻塞测试的风险，然后基于风险来调整测试策略。

• b. 基于风险来加强和降低测试投入：

  • 对高风险的部分，加强测试投入；
  • 对低风险的部分，降低测试投入。

• c. 适配 “产品研发流程”：

  • c1. 测试策略的结构：

• c2. 根据研发流程来安排测试活动：

　　　　　　　　　　

• d. 进行 “测试分层”：

  • 概念：测试分层，是指将有共同测试目的的测试活动，放在一起形成一个组，然后一组一组地逐一进行测试。

• e. “四步测试策略制定法” 中的测试技术：

  • 产品质量评估模型缺陷分析技术；
  • 风险分析技术；
  • 老功能分析技术；
  • 分层测试技术。

　　　　　　　　　　

• 1.3.2 软件质量评估模型：

  • 从 3 个方面来建立软件产品质量评估模型，对产品质量进行分析、确定和评估：
  • a. 测试覆盖度评估：
    • 对测试范围及测试的深度与广度进行分析和评估；
    • 包括需求覆盖度评估和路径覆盖度分析两个方面，从 “需求” 和 “实现” 两个纬度来对测试的全面性进行分析和评估，属于定量指标。
  • b. 测试过程评估：
    • 对测试过程和测试的投入情况进行分析与评估； 包括测试用例分析、测试方法分析和测试投入分析 3 个方面，既包含定量指标，又包含定性分析。
  • c. 缺陷分析：
    * 对测试结果进行分析和评估；
    * 包括缺陷密度分析、缺陷修复情况分析、缺陷趋势分析、缺陷年龄分析和缺陷触发因素分析。从这 5 个方面来对测试结果进行分析和评估，也是既包含定量指标，又包含定性分析。

　　

　　　　　　　　

1.4 测试覆盖度评估：

* 概念：测试覆盖评估是对产品测试的全面性的分析和评估，是对产品测试能够对产品质量进行评估的基础。

1.4.1 需求覆盖度评估：

• 概念：需求覆盖度是 “已经测试验证的产品需求数” 和 “产品需求规格总数” 的比值。

• 需求覆盖度的目标必须为 100%，即测试保证对产品承诺要实现的需求都进行了验证，并要对产品是否满足需求给出评估。

• 需求覆盖度评估方法：

  • 方法 1：直接在需求表中确认测试情况 - 各个测试责任人，直接在需求表中对需求的测试情况进行确认。
  • 方法 1 最好不要在测试快结束的时候才进行，可以根据开发的合入计划，一边测试，一边确认：

  • 方法 2：在测试设计的时候，通过编号来建立需求和测试用例的对应关系。只要保证这些测试用例都被执行了，需求也都就被验证了。

    • 优势：　　

      • 测试能够从一开始就保证需求的覆盖，从源头上避免了需求遗漏的风险；
      • 很容易通过不同的测试设计方法，让不同优先级的需求能够有不同的测试深度，更利于软件测试架构师对整个项目进行把控。

      • 注意点：

        • 需要注意需求变化的部分 - 特别是在项目后期 “增加”、“修改” 和 “删除” 的需求，避免遗漏。
        • 方法 2 和测试设计的关系变得比较紧密，测试设计遗漏，可能会影响对需求覆盖度的评估。
          

1.4.2 路径覆盖法评估：

• 1.概念：路径覆盖度是 “已经测试到的语句的数量” 和 “程序中可执行语句的总数量” 的比值。

• 2.路径分析法总结：

• 3.对产品的路径覆盖度进行评估：

  • 第一步：确定路径覆盖率策略：
  • 软件测试架构师，可以以特性或者功能未粒度，根据该功能的质量目标，来确定路径覆盖策略。方法：
  • a. 可以将最小线性无关覆盖作为一个基本的路径覆盖方式；
  • b. 对优先级高的功能特性，可以在最小无关覆盖的基础上增加一些路径；
  • c. 对优先级低的功能特性，可以在最小无关覆盖的基础上减少一些路径；　　
  • d. 不建议全面进行全覆盖，也不建议使用语句覆盖。
  • 第二步：使用路径分析法，设计测试用例。
  • 第三步：跟踪测试用例的执行情况。

　　　　　　　　

1.5 测试过程评估：

• 1.测试过程评估分析的对象：测试用例、测试方法和测试投入。

• 2.测试用例评估：

  • 2.1 测试用例执行率：
  • a.测试用例执行率：指 “已经执行的测试用例数目” 和 “测试用例总数” 的比值。
  • b."已经执行的测试用例数目"包含 测试结果为 “通过” 和 “失败” 的测试用例。
  • c.测试用例执行率可以帮助我们分析测试的全面性，影响测试用例的执行率的因素：
    • 测试阻塞：指测试用例因为产品开发 (一般是指缺陷)、测试 (如测试环境不具备) 等原因，无法被执行的测试用例。
    • 未执行：指可以执行，但是因为进度、人力或其它原因等还没有被执行的测试用例。

　　　　　　

• 2.2 测试用例执行通过率：

  • a. 概念：指 “测试用例执行结果” 为 “通过” 的测试用例数和 “已经执行的测试用例数目” 的比值。
  • b. 将测试用例执行通过率细分为：
  • 测试用例首次执行通过率：指 “第一次执行该测试用例的结果为 ‘通过’ 的测试用例数” 和 “已经执行的测试用例数目” 的比值。
  • 测试用例累积执行通过率：指 “测试用例结果为 ‘通过’ 的测试用例数” 和 “已经执行的测试用例数目” 的比值。

　　　　　　

• 2.3 测试用例和非测试用例发现缺陷比：

  • a. “通过测试用例发现的缺陷” 和 “发散测试，也就是非测试用例发现的缺陷” 的比值，能够在一个合理的范围内。
  • b. 如果比值过低，即大部分缺陷都是通过发散测试发现的，可能的问题是：
  • 随机测试投入太多；
  • 测试设计水平不高，存在测试设计遗漏；
  • 对产品的需求或者设计的理解不正确、不准确或者不深入，存在测试设计错误；
  • c. 如果比值过高，大多数缺陷都是通过测试用例发现的，可能的问题是：
  • 测试人员不愿意进行发散测试 (这样的测试团队可能也是一个比较沉闷、缺乏激情、只是完成任务的测试团队);
  • 测试投入不足，没有时间进行发散测试；
  • 测试思路还没有打开。

　　　　　　

• 3.测试方法分析：

  • 3.1 对软件测试架构师来说，在测试之前，我们就需要根据产品的质量要求，根据测试目标、测试的深度和广度来确定测试方法；在测试设计和测试执行中跟进，保证各个特性使用的测试方法和测试策略相符，并通过缺陷来确认测试策略是否符合，是否需要调整测试策略。

• 3.2 “分析测试设计是否和测试策略中的测试方法符合”，可以通过测试设计的过程跟踪、测试评审等方式去跟踪和分析。

• 3.3 “分析测试执行时的测试方法是否符合测试策略”，可以通过测试执行时的日报、周报，测试用例执行情况等方式去跟踪和分析。

• 3.4 “通过缺陷分析来确定测试策略是否需要调整”，主要是对缺陷进行缺陷触发因素分析。

　　　　

• 4.测试投入分析：

  • 4.1 主要从测试人员安排和测试投入工作量来进行分析，确认重要的、高风险的特性，能够保证测试投入，符合测试策略。
  • 4.2 如果发现测试投入和测试策略不符，则需要考虑调整测试投入，或者调整测试策略。进行风险识别和风险控制，及时调整测试策略。

　　

1.6 缺陷分析：

• 概念：缺陷是指在产品测试中，发现产品不符合需求和设计的地方。
  

　　

• 1.6.1 缺陷密度：

  • a. 缺陷密度是指每千行发现的缺陷数。对一个产品研发项目而言，确定、分析缺陷密度的重要意义在于：
  • a1. 通过缺陷密度，我们可以预测产品中可能会有多少缺陷；
  • a2. 通过缺陷密度，可以帮助我们评估当前已经发现的缺陷总数是否足够多。如果 “缺陷密度” 和预期偏差较大，原则上不应该退出测试，发布产品。
  • b. 在实际项目中，真实 的缺陷密度不会和预估的缺陷密度恰好相等，往往会有一点的偏差。
  • b1. 实际的缺陷密度偏高，通常最可能的原因为：产品质量不高。此时，软件测试架构师可以：
    • 提高缺陷密度的预估值；
    • 对缺陷较多的地方增加测试投入，如增加测试人力、增加测试时间、使用更多的测试方法等；
    • 考虑和研发经理、开发人员、系统工程师等一起进行一些质量改进和质量保证工作，如加强评审等。
  • b2. 实际的缺陷密度偏低，通常最可能的原因为：
    • 产品整体质量较好；
    • 测试能力不足，未能充分暴露缺陷；
    • 测试投入不足，未能充分暴露缺陷；

　　　　

• 1.6.2 缺陷修复率：

  • 概念：缺陷修复率是指，产品 “已经修复的缺陷总数” 和 “已经发现缺陷总数” 的比值。　
  • a1. 缺陷修复率能够帮助我们确定当前产品发现的缺陷，是否被有效修复，为当前的产品质量是否达到测试质量目标提供最直接的判断依据。这需要我们：
  • 在每个测试分层 (如集成测试、系统测试) 开始的时候，确定缺陷修复率目标；
  • 在每个测试分层结束时，判断是否达到目标，是否可以进入下一阶段的测试；
  • 如果最终的缺陷修复率不能达到预期，原则上不应该退出测试，发布产品。
    

　　　

• a2. 缺陷的严重程度：

  • 概念：缺陷的严重程度是基于缺陷如果不修改，会对用户造成的影响来划分的。

• a3. 考虑了缺陷的严重程度的缺陷修复率：

  • 考虑了缺陷的严重程度后，缺陷修复率变成了在某些特定的严重程度下，缺陷的修复率，例如：
  • 一般以上的缺陷的修复率：缺陷的严重程度为 “一般” 、“严重” 和 “致命” 的修复率。
  • 严重以上的缺陷的修复率：缺陷的严重程度为 “严重” 和 “致命” 的修复率。 　　　

　　　　

• 1.6.3 缺陷趋势分析：

  • 1.概念：缺陷趋势是指 “随着测试时间的进行，测试发现的缺陷趋势和开发解决缺陷的趋势”。
  • 2.进行此项分析的重要原因：缺陷趋势分析，能够帮助我们判断当前系统是否还能很容易发现缺陷，进而帮我们确定是否可以退出测试，发布产品。
  • 3.绘制缺陷趋势图：进行缺陷分析的第一步就是绘制缺陷趋势分析图：

缺陷趋势分析图：

　　　　　　　　

　　　　　　

• 4.缺陷趋势曲线的 “凹凸性” 和 “拐点”：

  • 4.1 概念：用于凹函数特性的曲线，呈现出递增的变化趋势；用于凸函数特性的曲线，呈现出递减的变化趋势；拐点就是凹函数和凸函数中间的连接点，即函数的变化趋势出现改变的点。 　　　　　　

　　　　　　　　

• 4.2 理想的 “累积发现的趋势趋势” 曲线：

  • a. 在一个新的测试阶段开始的时候，希望 “累积发现缺陷的趋势” 未凹函数，如 “①” 所示。
  • b. 在测试策略不变的情况下，测试一段时间后，出现 “拐点”。如下图中的 “拐点 1”。

　　　　　　　　　　

• 4.3 “累积发现的缺陷趋势” 的 “拐点” 出现得过早：
  

• a. 出现可能的原因：

  • a1. 测试团队的投入发送了变化 (如人员调动或减少)，并且已经影响了测试。
  • a2. 测试发送了阻塞 (如产品质量差，存在会阻塞测试执行的缺陷)，无法有效开展测试活动。
  • a3. 测试策略不当，当前的测试方法确实已经发现不了产品的缺陷了。

　　　　　　　　　　

• 4.4 “累积发现的缺陷趋势” 的 “拐点” 出现得过早：
  

• a. 出现可能的原因：

  • a1. 测试团队未按照测试策略进行测试，可能使用了更多、更复杂的方法来发现产品缺陷。
  • a2. 版本质量太差，缺陷密度高于预期。

　　　　

• 1.6.4 缺陷年龄分析：
• 1.含义：指软件 (系统) 产生或引入缺陷的时间。

　　　　　　　

• 2.不同阶段，缺陷年龄的定义：

  • 2.1 继承或历史遗留：属于历史版本、继承版本或是移植代码中的问题，非新开发的问题。
    　　　　　
  • 2.2 需求阶段引入：缺陷是在产品需求设计阶段引入的，主要包括如下情况：
  • (1）“需求不清” 的问题；
  • (2）“需求错误” 的问题；
  • (3）“系统整体设计” 的问题。
    

　　　　　

• 2.3 设计阶段引入：缺陷是在产品设计阶段引入的，主要包括如下情况：

  • （1）“功能和功能之间接口” 的问题；
  • （2）“功能交互” 的问题；
  • （3）“边界值设计” 方面的问题；
  • （4）“流程、逻辑设计相关” 的问题；
  • 5）“算法设计” 方面的问题。

　　　　　

• 2.4 编码阶段引入：缺陷是在编码设计阶段引入的，主要包括如下情况：

  • （1）“流程、逻辑实现相关” 的问题；
  • （2）“算法实现相关” 的问题；
  • （3）“编程规范相关” 的问题；
  • （4）“模块和模块之间接口” 的问题。

　　　　　

• 2.5 新需求或变更引入：缺陷是因为新需求、需求变更或设计变更引入的问题。

  　　　　　

• 2.6 缺陷修改引入：缺陷是因为修改缺陷时引入的问题。
  　　　　　

  　　　　　

  • 2.开展缺陷年龄分析活动步骤：

• 第一步：确定缺陷的缺陷年龄：
  

• 第二步：统计出各类缺陷年龄的数量，绘制缺陷年龄分析图：
  

　　　　　　　　

• 第三步：进行缺陷年龄分析：

  • （1）理想的缺陷年龄分析图：
    
  • （2）在测试分层发现该层的问题：

　　　　

• 1.6.5 缺陷触发因素分析：

  • 1.含义：缺陷的触发因素就是测试者发现缺陷的测试方法。缺陷触发因素分析，就是对测试中使用的测试方法进行分析。
  • 2.进行缺陷触发因素分析步骤：
  • 第一步：确定缺陷的测试方法和测试类型:
  • 第二步：统计出各种测试方法发现的缺陷数目，绘制缺陷触发因素分析图。
  • 第三步：进行缺陷触发因素分析:
    • 1.功能测试-- 单运行正常输入：进行基本功能测试，覆盖业务流程的基本路径和测试时发现的问题。
    • 2.功能测试 -- 单运行边界值测试：进行配置测试时发现的问题。
    • 3.功能测试 -- 多运行相互作用：进行基本功能测试，覆盖业务流程的基本路径和配置测试时发现的问题。
    • 4.性能测试：进行满规格测试时发现的问题。

　　　　

• 1.6.6 组合使用各种缺陷分析技术：

  • 1. 产品质量评估表：
    
• 1. 组合使用缺陷分析技术：

1.7 风险分析技术：

• 1.含义：风险分析技术，用在保证测试策略的顺利进行和基于风险来加强或降低测试投入上，涉及的主要技术：风险识别、风险评估、风险应对和老功能分析。

• 2.风险分析：此处讨论的风险分析的对象是测试策略，目标是提前识别那些可能会阻塞测试策略顺利进行的问题，包括风险识别和风险评估。

  • 2.1 风险识别：
  • a. 可以根据测试策略的内容，逐一分析哪些问题可能会对测试策略的开展带来阻碍，并进行风险识别；
  • b. Step3 中不能满足的那些条件，就是我们寻觅的风险点。
    
  • c. 风险识别清单：
  • 2.2 风险评估：

  • A. 风险评估的目标：确定风险优先级。

    • B. 风险优先级正交表：
    • b1. 风险评估的两个方面：风险发送频率、风险影响程度。
      

  • C. 需求类的风险 - 高：

    • c1：需求的质量不高，不足以支撑后续开发和测试。
    • c2：开发和测试未能正确理解需求。
      

  • D. 设计类的风险 - 高：

    • d1. 设计类的风险，主要集中在设计的正确性和全面性上。
      

  • E. 流程类的风险 - 中：

    • e1：从风险影响程度的角度来说，会影响到团队合作，或是设计规范性方面的风险。
      

  • F：历史类的风险：

    • f1：历史类的风险影响程度，参考历史的风险影响程度来确定。

　　

• 3.风险应对：

  • 3.1 风险管理中，风险应对主要分为 4 种：
  • 回避风险：指主动避开损失发生 的可能性。
  • 转移风险：指通过某种安排，将自己面临的风险全部或部分转移给其它一方。
  • 减轻风险：指采取预防措施，以降低损失发生的可能性和影响程度。
  • 接受风险：指自己理性或非理性地主动承担风险。 　 　　

• 4.老功能分析：

  • 4.1 差异性分析：指找出老功能在新版本和老版本上的差异。这些差异包括需求、设计、平台、实现等各种差异。“找” 差异也是新版本中做好老功能测试的金钥匙。
  • 4.2 历史测试情况分析：历史测试情况分析，是对老功能在老版本中的测试情况 (包括测试策略、测试用例、缺陷) 进行分析，以此来确定老功能在新版本中需要采用怎样的测试策略。
  • A. 确认老功能在新版本和老版本中的质量要求是否一致。
  • B. 进行测试方法分析：
    
  • C. 进行缺陷分析：
    
  • D. 对 “组织和人” 进行分析：

　　　　　　　　　　

1.8 分层测试技术：

• 1.V 模型：
  

• 对 V 模型而言，每个测试分层测试图测试的重点：

  • A. 单元测试：从产品实现的函数单元的角度，验证函数单元是否正确。
  • B. 集成测试：从产品模块和功能的角度，验证功能模块和模块之间的接口是否正确。
  • C. 系统测试：从系统的角度，验证功能是否正确，验证系统的非功能属性是否能够满足用户的需求。
  • D. 验收测试：从用户的角度，确认产品是否能够满足用户的业务需求。
    

　　

• 2.设计测试层次：

  • A. 测试层次设计的基本原则：使得每个测试层次中的测试目标都是 “SMART”(具体、可衡量、可获得、具有相关性和时限性) 化的。
  • B.某通信公司的测试分层：
    
  • B1. 模块级系统测试 (MST)：保证软件开发项目组各个单元/模块之间的接口正确，以及对项目组级别的功能进行验证。
  • B2. Building Block Integrated Test(BBIT)：验证的是子系统之间的单元/模块的接口的正确性，也就是 “联调”。
  • B3. 系统设计确认 (SDV)：从系统的角度来验证功能的正确性。
  • B4. 系统集成测试 (SIT)：从系统的角度来验证功能交互和非功能方面的正确性。
  • B5. 系统验证测试 (SVT)：验证场景、解决方案的正确性。
    

　　

• C. 某公司在敏捷环境下的测试分层：

  • C1：单元测试 (UT test)：针对代码或者组件的测试。
  • C2：功能测试 (function test)：针对产品功能方面的测试。
  • C3：非功能测试 (non-functional test)：指非功能方面的其它质量属性的测试。
  • C4：探索测试 (Explore test)：基于任务的测试。