一. 软件产品质量模型

1. 软件产品质量六属性：功能性、可靠性、易用性、效率、可维护性、可移植性。

1.1. 功能性：

软件产品质量属性中的功能性，是指软件产品在指定条件下使用时，提供满足明确和隐含要求的功能的能力。
从功能性的定义来看，产品的功能并不像表面上看起来那么简单 - 除了满足 “明确” 的要求，还有更深一层的 “隐含” 的要求。“明确”+“隐含” 才构成了用户对产品真正的、完整的功能要求。
功能性被分成了 5 个子属性：

• 适合性：软件产品为特定的任务和用户目标提供一组合适功能的能力。
• 准确性：软件产品提供具有所需精度的正确或相符的结果及效果的能力。
• 互操作性：软件产品与一个或多个特性、系统相互配好的能力。
• 安全性：软件产品保护信息和数据的能力，以保证未授权的用户或系统不能阅读和修改这些信息与数据，而合法用户或系统不会被拒绝访问。
• 功能顺从性：软件产品符合和该功能相关的标准、规范、规则或特定的能力。
  

1.2. 可靠性： 软件产品质量属性中的可靠性，是指在特定条件下使用时，软件产品维持规定的性能级别的能力。

可靠性被分成了 5 个子属性：
成熟性：软件产品为避免因软件故障而导致失效的能力。
容错性：软件产品在软件发生故障或者违反指定接口的情况下，维持规定的性能级别的能力。
可恢复性：软件产品在失效发生的情况下，重建规定的性能级别并恢复受直接影响的数据的能力。
可靠性顺从性：软件产品遵循与可靠性相关的标准、约定或规定的能力。

1.3. 易用性：

• 软件产品质量属性中的易用性，是指在指定条件下使用软件产品时，产品被用户理解、学习、使用和吸引用户的能力。这个能力，简单的说就是 10 个字：易懂、易学、易用、漂亮好看。 易用性被分成了 5 个子属性：
• 易理解性：软件产品使用户能理解软件是否适合以及如何能将软件用户特定的任务和使用环境的能力。
• 易学性：软件产品使用户能学习其应用的能力。
• 易操作性：软件产品使用户能够操作和控制它的能力。
• 吸引性：软件呢产品吸引用户的能力。
• 易用性的依从性：软件产品遵循与易用性相关的标准、约定、风格指南或法规的能力。

1.4. 效率： 软件产品质量属性中的效率，是指在规定条件下，相对于所用资源的数量，软件产品可提供适当的性能的能力。通常，效率就是我们常说的产品选性能。

• 效率被分成了 3 个子属性：
  • 时间特性：在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间及流量 (吞吐量) 的能力。
  • 资源利用率：在规定条件下，软件产品执行其功能时，使用合适数量和类别的资源的能力。
  • 效率依从性：软件产品遵循与效率相关的标准或约定的能力。

1.5. 可维护性： 软件产品质量属性中可维护性，是指　软件产品可被修改的能力。这里的修改是指纠正、改进软件产品和软件产品对环境、功能规格变化的适应性。

• 可维护性被分成了 3 个子属性：
  • 可分析性：软件产品诊断软件中的缺陷、失效原因或识别待修改部分的能力。
  • 可修改性：软件产品能被修改的能力。
  • 稳定性：软件产品不会因为修改而造成意外结果的能力。
  • 可测试性：软件产品已修改的部分能够被确认修复的能力。
  • 可维护性的依从性：软件产品遵循与维护性相关的标准或约定的能力。

1.6. 可移植性：

• 软件产品质量属性中的可移植性，是指软件产品从一种环境迁移到另外一种环境的能力。这里的环境，可以理解为硬件、软件或组织等不同的环境。
• 可移植被分成了 3 个子属性：　
  • 适应性：软件产品无须采用额外的活动或手段就可适应不同指定环境的能力。
  • 可安装性：软件产品在指定环境中被安装的能力。
  • 共存性：软件产品在公共环境中同其分享公共资源的其他独立共存的能力。
  • 易替换性：软件产品在同样的环境下，替换另一个相同用途的指定软件产品的能力。
  • 可移植性的依从性：软件产品遵循与可移植性相关的标准或约定的能力。　　　

2.常见测试类型及其与质量属性关系：

• 2.1.功能性：验证产品能否满足特定功能要求并做出正确响应。

• 2.2.安全性测试：验证产品是否有保护数据的能力，并能在合适的范围内承受恶意攻击。

• 2.3.兼容性测试：验证产品是否能够和其它相关产品顺利对接。

• 2.4. 配置测试：验证产品是否能够在推荐配置上流畅运行；验证产品为了完成特定功能的输入是否会出现故障。

• 2.5.可靠性测试：验证产品在长时间运行下能否满足保证系统的性能水平；在存在异常的情况下系统是否依然可靠。

• 2.6. 易用性测试：验证产品是否易于理解、易于学习和易于操作。

• 2.7. 性能测试：测试产品提供某项功能时的时间和资源使用情况。

• 2.8. 安装测试：测试产品能否被正确安装并运行。

3.测试方法：

3.1. 产品测试车轮图：

　　

3.2. 功能测试方法：

• 单运行正常值输入法
• 单运行边界值输入法
• 多运行顺序执行法
• 多运行相互作用法

3.3. 可靠性测试方法：

• 概念：产品在各种条件下维持规定的性能级别的能力。前提条件 - 基本功能要先正确。
• 异常值输入法：一种使用系统不允许用户输入的数值 (即异常值) 作为测试输入的 可靠性测试方法。
• 故障植入法：把系统放在有问题的环境中进行测试的一种 可靠性测试方法，主要能够测试到的质量属性是容错性和成熟性。
• 稳定性测试法：在一段时间里，长时间大容量运行某种业务的一种 可靠性测试方法，它能够非常有效地测试到系统的 “成熟性”，是非常重要的一种 可靠性测试方法。
• 压力测试法：在一段时间内，持续使用超过系统规格的负载，进行测试的一种 可靠性测试方法。
• 恢复测试法：指使用持续超过规格的负载，进行测试后，再将负载降到规格以内的测试方法。　　　

3.4. 性能测试方法：

测试出系统最好的性能值：
系统能够正确处理新业务的最大能力
系统能够同时正确处理的最大业务能力

分析会影响性能值的各种因素，测试它们对性能的影响
以场景为单位来测试性能　　　
　　

3.5. 易用性测试方法：

一致性测试法：
测试对象：用户界面，如 Web 页面、命令行等用户和产品直接进行交互的地方。
关注产品的用户界面：
风格、布局、元素上是否一致、统一。
布局的合理性、操作的合理性、提示等是否符合 UI 设计规范。

可用性测试法：
测试对象：用户界面。
关注产品提供的功能：对用户来说，是否易于学习理解、易于使用。
可用性测试，需要和功能测试结合，以场景作为测试粒度，以用户的视角进行测试。

　　

4. 测试设计技术：

4.1.测试点不等于测试用例：测试用例是在测试点 “加工” 的基础上得到的。

4.2.四步测试设计法：

4.2.1.建模：

• 类型 1-“流程”：对 “流程” 类，可以通过绘制 “流程图”，来建立测试模型；
• 类型 2-"参数"：对” 参数 “类，可以通过” 输入输出表 “，来建立测试模型；
• 类型 3-"数据"：对 “数据” 类，可以通过 “等价类分析表”，来建立测试模型；
• 类型 4-“组合”：对 “组合” 类，可以通过 “因子表”，来建立测试模型；

4.2.2.设计基础测试用例。

4.2.3.补充测试数据。

4.2.4.扩展。

4.3.对测试点进行分类：

4.3.1. 流程类测试点有哪些特征: 流程类测试点，拥有流程方面的一些特征。

4.3.2. 参数类测试点有哪些特征：

• 特征一：“参数值” 的个数是有限的，可以通过遍历的方式来测试覆盖到；

• 特征二：系统会对不同的 “参数值”，作出不同的处理或响应。

4.3.3. 数据类测试点有哪些特征：

• 特点一：数据的取值是一个范围，通常不能用遍历的方式来测试覆盖。

• 特点二：系统对允许输入的 “数据” 作出的处理或响应往往是一样的。

　　　　　　

4.3.4. 组合类测试点有哪些特征：

• 1. 测试点是可以 “组合” 的。在测试设计时，可以把流程类、数据类和参数类的测试点，组合在一起进行测试设计。
• 1. 和单纯的流程类相比，它可能有多个 “输入”，这个 “输入” 可能为参数，也可能为数据。

4.4 流程类测试设计：

4.4.1. 路径分析法：

• 通过绘制业务流程图来建模：对流程类的测试点，建模就是绘制这些测试点代表的业务流程图。
  • 注意点：
  • 测试者要充分理解和测试点相关的功能业务流程，确保流程图的正确性。
  • 测试者要和 产品设计者充分交流，保证绘制出的流程图能够正确覆盖产品的设计。
  • 如果开发已经提供该功能的流程图，测试者需要仔细审核流程图的正确性，如有必要，可以重新绘制。

4.4.2. 路径分析法：

• 对流程类的测试点，把模型建立好了之后 (即绘出了流程图)，就会使用路径分析法，来覆盖这个流程图，设计基础测试用例。

• 路径是指，完成一个功能，用户所执行的步骤，即通过程序代码的一条运行轨迹。

• 路径分析法：指对能够覆盖流程的各种路径进行分析，得到一个路径的集合。在测试时，只需要按照这个路径进行集合测试即可。

• 不同的覆盖策略，能够得到不同的路径集合。常见覆盖策略：语句覆盖、分支覆盖、全覆盖、最小线性无关覆盖。

  • 语句覆盖：指覆盖系统中所有判断和过程的最下路径集合。
  • 缺点： 覆盖程度较弱，不会考虑流程中的 “判定” 以及这些 “判定” 过程之间的相互关系，如果测试只按照 “语句覆盖” 的方式来进行测试，很容易出现遗漏。
    
  • 分支覆盖：指覆盖系统中每个判定的所有分支所需的最小路径数。
  • 缺点：分支覆盖考虑了流程中的 “判定”，但是没有考虑这些 “判定” 之间的关系。分支覆盖也是一种不是很强的覆盖。　
    
  • 全覆盖：指 100% 的覆盖系统，所有可能的路径的集合。
  • 缺点：对普通系统来说，随着判定增加而呈指数类型增长的路径数，使得需要测试的路径数目非常庞大，完成超出了一个测试团队能够承担的正常工作量，在实际中很难按此执行。
  • 最小线性无关覆盖：流程图中每个路径片段，能够被至少执行一次，得到的最小路径组合。
    • 计算一个流程中的最小线性无关路径的数目 (三个等式是等效的)：
    • 等式 1：一个系统中的线性无关路径 (IP) = 边数 (E) - 节点数 (N) + 2
    • 等式 2：一个系统中的线性无关路径 (IP) = 判断数 (P) + 1
    • 等式 3：一个系统中的线性无关路径 (IP) = 区域数 (R) + 1
    • 流程需遵循如下约定：
      
    • 约定 1：“流程图” 的 入口和 “出口”，不作为边数计算。
      
    • 约定 2：一个 “流程图” 只有一个 “入口点” 和一个 “出口点”。
    • 存在 “多个输入” 或输出时，先要对流程图进行分解，使其满足 “约定 2”： 这时系统中最小线性无关路径的总数，等于被分解的每个流程中最小线性无关路径的总和：

4.4.3. 使用路径分析法来设计基础测试用例：

1. 单元测试阶段：主要使用语句覆盖或分支覆盖的方式，来设计测试用例；

2. 集成测试和系统测试阶段：主要使用最小线性无关覆盖；

3. 特别重要的部分：使用全覆盖；

4. 不那么重要的部分：使用 语句覆盖或者分支覆盖。

4.4.4. 确定测试数据，完成测试用例：

• 如果流程的 “输入” 是一些参数，选择合适的参数值即可；如果 “输入” 是一个取值范围，使用 “等价类/边界值” 来选择一个输入数据。

4.4.5. 根据经验补充测试用例：

• 1. 是否要增加一些需要覆盖的路径？
• 2. 是否要增加一些测试数据？
• 3. 有哪些地方是容易出问题的，是否还需要补充一些测试用例？

4.5. 流程类测试设计 - “输入 - 输出表” 分析表：

• 使用四步测试设计法对参数类的测试点进行测试设计：
  

• 2.使用 “输入 - 输出表” 来建模：

• 3."输入 - 输出表"是一张分析测试点，在某种条件下，特定的 “输入” 会有怎样 “输出” 的表。
  

• 4.覆盖 “输入 - 输出表”，完成测试用例：

  • 4.1 在建立 “输入 - 输出表” 的时候，会充分考虑各个参数之间的关系和它们的约束条件，并据此进行逐一的分析，在覆盖 “输入 - 输出表” 的时候，会进行 100% 的覆盖，即将 “输入 - 输出表” 的每一行作为一个测试用例。

• 5.根据经验补充测试用例：

  • 5.1. 是否需要要考虑一些别的 “条件”？
  • 5.2. 有哪些地方是容易出问题的，是否还需要补充一些测试用例？

4.6. 数据类测试设计 - 等价类和边界值分析法：

　　　　

1. 等价类和边界值：

• 1.1. 等价类是指，对输入值按照测试效果进行划分，将测试效果相同的测试数据归为一类，然后在测试时，只需要在每类中选择一些测试样本来进行测试，而无测试所有的值。

  • 1.2. 边界值：参数在输入边界上的取值。

• 2.使用 “等价类分析表” 来建模：

  • 2.1. 等价类分析表，是一张对数据在 “xxx 条件下”，“有效输入” 和 “无效输入” 进行分析的表。

• 3.覆盖等价类分析表 - 完成测试用例：

  • 3.1. 在建立等价类分析表的时候，已经对输入数据分好了类。将分析好的等价类进行 “边界值” 分析，确定具体的测试数据，生成测试用例。

• 4.根据经验补充测试用例：

  • 4.1. 是否要在 “等价类” 中增加一些除 “边界值” 之外的测试数据？
  • 4.2. 有哪些地方是容易出问题的，是否需要补充一些测试用例？

4.7. 组合类测试设计 - 正交分析法：

• 1.使用 “因子表” 来建模：

  • 1.1. “因子表” 是一张分析测试点需要考虑哪些方面，并且这些方面要包含哪些内容的表。

• 2.使用 “PICT” 工具，生成测试用例：

  • 2.1. “PICT” 是针对 “Pairwise Testing” 实现的测试用例设计工具。可以直接将 “正交表” 转换成测试用例。

• 3.根据经验补充测试用例：　　

  • 3.1. 是否需要增加因子取值的组合？
  • 3.2. 有哪些地方是容易出问题的，是否还需要补充一些测试用例？

4.8. 控制用例粒度 - 测试点的组合和拆分：

• 1.控制用例粒度：用例粒度是对测试用例是精细还是笼统地描述测试点的通俗说法。测试用例越聚集到一个功能点上，这个功能点越小越细，用例粒度就越细；反之，如果一个测试用例包含了比较多的功能点，这个测试用例的用例粒度就会比较粗。

• 2.控制用例粒度，意味着要做以下两件事：

  • 2.1. 第一，我们希望整个团队的测试用例的总数，维持在一个比较合理的范围内，同时很好地达到测试验证产品的效果。这就需要我们控制测试用例的源头 - 测试点：让测试点不要过粗或者过细。如果测试点过粗或过细，就要去拆分或者组合它，保证设计出来的测试用例粒度比较统一。
  • 2.2. 第二，不同的用例粒度，可能会发现产品不同层次的问题 (细粒度的用例可能更容易发现产品功能的设计和实现方面的问题，而粗粒度的用例更容易从系统的角度去发现一些功能交互或是需求方面的问题)，所以需要在不同的测试阶段，对测试点进行一些拆分或组合，以求可以从不同的层次去测试产品，发现问题。

• 3.策略覆盖：

  • 3.1. 在测试设计时，经常会遇到以下情况：
  • 3.1.1. 有些因子，如操作系统、平台等，除了那些可以分析到的对系统有影响的地方之外，对系统的其它功能可能没有影响、影响很弱或者影响未知，没有必要使用 Pairwise 来进行正交。
  • 3.1.2. 有些数据类的测试点，比如就是测试一个名称，测试点比较细，但是它和其它的测试点可能没有关系或者关系很弱，也没有必要使用 Pairwise 来做正交。
  • 3.1.3. 这时，可以考虑使用策略覆盖的方式，将这些因子或数据的取值，分配到其它测试用例中，作为其它测试用例的测试数据输入或者是测试条件 (或预置条件)。

4.9.错误推断法：

• 1.错误推断法，是测试者根据经验来判断在哪些地方容易出现问题，然后针对这些地方来设计测试用例的方法。
• 2.错误推断法，是一种基于经验的测试设计方法。使用错误推断法来设计测试用例，优点是测试用例的有效性会比较高 (所谓测试用例的有效性，就是指测试用例发现产品缺陷的能力)。
• 3.错误推断法的缺点：这时测试专注于发现缺陷，可能会测试得很严苛，却忽视或遗漏掉对一些基本功能和场景的测试验证，造成测试遗漏。

5. 探索式测试：

• 1.探索性测试 (exploratory testing)，最早由测试专家 Cem Kanner 博士 在 1983 年提出，是一种强调测试人员同时开展测试学习、测试设计、测试执行，并根据测试结果反馈及时优化的测试方法。

• 2.探索式测试的基本思想-CPIE：

  • 2.1. 基本思想：
  • 2.1.1. 收集 (Collection)：收集所有关于测试对象的信息并去理解这些信息。
  • 2.1.2. 划分优先级 (Prioritization)：对所有需要测试的任务进行优先级划分。
  • 2.1.3. 分析调研 (Investigation)：对测试的任务进行仔细分析，预测可能输出的结果。
  • 2.1.4. 实验 (Experimentation)：进行测试实验，确认测试结果和预期是否符合。分析是否需要修改策略和方法。如有需要，进入 “收集” 阶段。
  • 2.2. CPIE 模型很好地总结了探索式测试的基本思想。和传统式测试相比，探索式测试弱化了流程，强调实践，边学边测，持续改进。使用探索式测试的优势是显而易见的:能够更快地进行测试，能够得到更有效的测试点，能够更高效地发现产品缺陷。但是，探索式测试也有一定的局限性:容易将焦点集中在缺陷发现上而偏离对需求的验证，对基本测试点的测试和覆盖容易不足，测试点不易复用，不易积累。 此外，探索式测试对人的要求很高，包括测试者的思维能力，分析能力，总结能力，持续改进、追求卓越的意愿，等等。在实际项目中，以传统式测试为主线，将探索式测试作为很好的补充是比较不错的方式，两种思想结合起来，能比较不错地将探索式测试的思想运用到各种测试活动中。

• 3.选择合适的探索式测试方法：

  • 3.1. 第一步： 对产品的特性进行 “分区”：
  • 3.1.1 将产品特性划分为 “历史区 (继承特性)”、“商业区 (销售特性)”、“娱乐区 (辅助特性)”、"破旧区 (问题高发区)"、“旅馆区 (平台、维护特性)”、“旅游区 (噱头特性)” 和 “其它区”。
  • 3.1.2 如果产品同时具备多个区域的特性，就将这个特性分别划分到这些区域中去。
  • 3.2.第二步：根据不同的分区来选择适合这个分区的探索式测试方法：
  • 3.2.1 历史区测试法：
    • 含义：历史区测试法针对的是 “老代码”，即在前几个版本就已经存在的软件特性。也包括那些用于修复已知缺陷的代码。
    • 包含的探索式测试法：
    • 恶邻测试法：指那些缺陷横行的代码段，测试人员应该在这些区域尽量多花时间。
    • 博物馆测试法：重视老的可执行文件和那些遗留代码，另外还包含累积许久没有执行过的用例，确保它们和新增代码享受同等待遇。
    • 上一版本测试法：检查那些在新版本中无法再运行的测试用例，以确保产品没有遗留必需的功能，也就是说，如果当前产品构造是对先前版本的更新，必须先运行先前版本上支持的所有场景和测试用例。
  • 3.2.2 商业区测试法：
    • 含义：商业测试法针对的是销售特性。所谓的销售特性，就是指产品的重要功能和特性，是测试时需要重点测试的对象。
    • 包含的探索式测试法：
    • 指南针测试法：主要要求测试人员通过阅读用户手册、场景及产品需求进行相关的测试。
    • 卖点测试法：对那些能够吸引用户的特性进行测试，至于哪些特性能够吸引用户，可以向销售人员咨询，或者拜访客户。
    • 地标测试法：主要是寻找测试点，明确测试项，这里的测试点就是 “地标”。
    • 极限测试法：向软件提出很多难以回答的问题。比如，如何使软件发挥到最大限度？哪个特性会使软件运行到其设计极限？哪些输入和数据会耗费软件最多的运算能力？等等。
    • 快递测试法：要求测试人员专注于数据，即数据从输入到输出展现给客户或页面过程中，数据执行的流程。
    • 深夜测试法：当我们不对测试对象操作时，测试对象能否自动完成各种维护任务，将数据归档，自动记录发送的异常情况，等等。
    • 遍历测试法：通过选定一个目标，然后使用可以发现的最短路径来访问目标包含的所有对象。测试中不要追求细节，只是检查那些明显的东西。

　　　　　　

• 3.2.3 娱乐区测试法：
  • 含义：娱乐区测试法，针对的是辅助特性，也就是那些并不是那么重要的特性的测试。
  • 包含的探索式测试法：
  • 配角测试法：专注于某些特定的特性，它们虽然不是那种我们希望用户使用的主要特性，但和那些主要的特性会一同出现。它们紧邻那些主要功能，越容易被人注意，所以必须给予足够的重视，不能忽视。
  • 深巷测试法：测试产品特性的使用情况中，排在最下面的几项特性 (最不可能被用到的或是那些最不吸引用户的特性)。它的变种是 “混合测试法”，试着把最流行和最不流行的特性放在一起混着测。因为开发人员可能从来没有预想过它们会在这样的场景中被混合在一起。
  • 通宵测试法：测试软件长时间运行后，各功能模块是否正常，有点像稳定性测试。这个方法容易和 “深夜测试法” 混淆，但是测试侧重点不同：“深夜测试法” 测试的是测试对象的自动处理能力。

　　　　　　

• 3.2.4 破旧区测试法：

  • 含义： 破旧区测试法针对的是问题高发特性。对这些让人头痛的问题高发特性，破旧区测试法的测试思想就是继续 “落井下石”：如输入恶意数据、破坏操作、修改配置文件等，所有这些你能想到的 “有害” 的事情，都往这些特性上想就对了。
  • 包含的探索式测试法：　　
  • 破坏测试法：指那些缺陷横行的代码段，测试人员应该在这些区域尽量多花时间。　
  • 反叛测试法：要求输入最不可能的数据，或者已知的恶意输入。要求输入最不可能的数据。
  • 强迫症测试法：强迫软件一遍又一遍接受同样的数据，反复执行同样的操作。此种思维方式，常常打破了开发人员设计代码的思路，他们预想这你会按步骤操作，却不曾考虑过你反复地执行第一步应该如何处理。

• 3.2.5 旅馆区测试法：

  • 含义：旅馆区测试法针对的是平台或维护特性。这些特性的特定容易被忽视，而旅馆区测试法就是让我们再回头去测试一些经常被忽视的或在测试计划中较少描述的次要辅助功能的方法。
  • 包含的主要测试方法：
  • 取消测试法：启动相关操作，然后停止它，查看测试对象的处理机制及反应。例如，在功能进行中使用 Esc 键、取消键、回退键、关闭按键或者彻底关闭程序等。
  • 懒汉测试法：做尽量少的实际工作，让程序自行处理空字段及运行所有默认值。

　　　　　　

• 3.2.6 旅游区测试法：

  • 含义：旅游区测试法针对的是噱头特性。特点：关注如何快速访问文件的各种功能，测试目的就像方法的名称一样，只是为了到此一游。
  • 包含的主要测试方法：
  • 收藏家测试法：测试人员通过测试去收集软件的输出，将那些可以到达的 “地方” 都到达一遍，并把观察到的输出结果记录下来，收集得越多越好。
  • 长路径测试法：访问离应用程序的某个开始点尽可能远的特性。哪个特性需要点击 N 次才能被用到？ 哪个特性需要经过最多的界面才能访问？ 主要指导思想是到达目的地之前尽量多地在应用程序中穿行。
  • 超模测试法：要求测试人员去关心那些表面的东西，只测试界面。测试中注意观察界面上各种元素。它们看上去怎么样？有没有被正确地绘制出来？ 变化界面时，图形用户界面刷新情况如何？ 如果软件用颜色来传达某种意思，这种 信息是否一致？ 界面是否违反了任何惯例或标准？
  • 测一送一测试法：测试同一个应用程序多个复制的情况。测试程序同时处理多个功能要求时，是否正常，各功能之间同时处理时，是否会相互影响。

• 3.2.6 其它区测试法：

  • 含义：“其它区” 是指那些无法归类在历史区、商业区、娱乐区、破旧区、旅馆区和旅游区中的探索测试的区域。比如产品的一些可测试性、可维护性 (最终用户不一定会使用，但是对测试或者开发、维护却比较有用的内容)，再比如对当前有代码变动的一些地方的测试等。
  • 包含的主要测试方法：
  • 内部测试法：这个方法一般在你需要进行某项功能测试之前完成。首先收集这个功能有哪些部分是对确认测试结果、定位问题有用的 “内部输出”(可能就是些中间结果，而不是最终的用户可以看到的信息)，然后确认这些地方是否有效。(如果你发现你的测试功能无法使用内部测试法，这时可以和开发人员、需求人员聊聊，也许这里有新的需求)
  • 变动区测试法：首先分析当前版本和上个版本有哪些内容上的变化。然后只针对变化的内容进行探索测试。对 bug 的回归测试、验证 bug 的修改是否正确，就是使用的这种方法。

4. 开展探索式测试：

1.确定探索式测试任务：

1.1 确定任务的范围：

• 思路 1：进行全局场景探索：指准备进行探索的对象是整个系统；
• 思路 2：进行特性漫游探索：指准备进行探索的对象是整个特性；
• 思路 3：进行局部功能点探索：是指准备进行探索的对象是某个具体的功能。

1.2 三者之间关系图：

　　　　　　　　

1.3 根据范围和方法来确定探索式测试的任务：

• 例如：使用 xxx 测试方法，对 xxxx 场景进行探索测试。

2. 设计探索地图并执行探索式测试：

2.1 探索地图，就是测试者根据被测对象的特定，使用探索式测试方法，分析得到的测试点，然后就可以按照测试点对被测对象进行探索式测试，并记录测试结果。

　　　　　　　　

3. 探索性测试总结：

• 3.1 探索式测试者每执行完一个任务，都需要围绕如何有效地发现产品缺陷，立即进行总结：
  • 3.1.1 总结使用哪些方法，能够更有效发现产品的问题。
  • 3.1.2 总结本次探索式测试中的教训。

6. 自动化测试：

1. 对软件测试架构师来说，掌握自动化测试相关的知识和技术是必要的，但是掌握这些知识的目的不是设计自动化的架构或是具体来部署自动化，而是用好自动化：

• 第一，用好已有的自动化 - 让现有自动化能在产品测试中发挥最大的功效；
• 第二，会根据产品的测试需要向自动化团队提出合适的自动化需求，和自动化团队保持良好的互动。

2. 自动化并不廉价，相反，自动化很贵：

• 2.1 时间成本、人力成本和技术成本，都是自动化中需要考虑的成本。

3. 自动化脚本往往没有想象中那么可靠：

• 3.1 无论是正确的自动化测试结果，还是错误的自动化测试结果，都需要人再去确认。

4. 自动化测试不是单靠测试就能搞定的事：

• 4.1 自动化测试，需要 SE、开发、测试、自动化工程师紧密配合才能有效运作起来。
• 4.2 对软件测试架构师来说，如果决定要部署自动化测试，可能需要调整测试策略，加强对自动化测试中的风险识别，做好风险控制，并有针对性地对测试设计做一些调整。

5. 如何评估自动化的收益：

1.自动化测试的实施成本：

• 1.1 计算公式：自动化实施成本 = 前期开发成本 + 后期的维护成本

• 1.2 前期开发成本：

  • 人力成本： 和自动化开发人员相关的费用成本。
  • 时间成本：自动化准备时间，自动化开发、调试的时间成本。
  • 金钱成本：工具购买、开发、维护的费用成本。

• 1.3 影响后期维护的成本：

  • 产品变更引起的自动化测试脚本变更的成本。
  • 定位、修复自动化运行环境引起的脚本的健壮性问题的成本。
  • 定位、修复自动化运行环境的可靠性问题的成本。
  • 其它任何未知的引起测试脚本变更的因素引发的成本。

2. 自动化测试的运行次数：

• 2.1 自动化测试的运行次数，是指自动化测试脚本的生命周期内，这个脚本能被执行的次数。
• 2.2 自动化测试的收益 = 自动化测试运行次数

　　

3. 自动化测试实施成本比：

• 3.1 计算公式：

• K ：手工执行自动化用例所花费的时间成本；
• n：自动化测试用例执行的次数；
• c1：花费在自动化测试前期的成本 (时间成本 + 人力成本 + 金钱成本);
• c2：花费在自动化测试后期的成本 (时间成本 + 人力成本 + 金钱成本)。

7. 软件测试架构师的软能力修炼：

1. 沟通和协商：

• 1.1 产品测试中的沟通原则：

  • 1.1.1 尽早沟通：
  • a.在进行一项测试活动 (如测试设计、测试执行等) 之前，需要把目标、要求、期望的结果和可能的问题尽早沟通清楚，防患于未然。
  • b.尽早沟通能够帮助我们预防分歧。
  • 1.1.2 既要对事，也要对人：
  • a."对人"意在强调我们在沟通时，需要理解你的沟通对象，要学会换位思考，即使是同一件事情，在表达上也需要以对方能够理解的方式来表达。
    

• 1.2 通过沟通来获得对产品测试有用的信息：

  • 1.2.1 以测试的视角来读需求、设计文档，来准备沟通的问题：
  • 测试的视角：
    • a.需求是否可以测试？ 需求怎么测试？ 怎样才算验证通过了？
    • b.设计是否可以测试？ 需要怎么测试？ 怎样才算验证通过了？　　　
      　　　　　
  • 1.2.2 以需求工程师或开发的视角来问问题：
    
  • 1.2.3 总结、跟踪和确认：
  • a. 有时候需要分多次进行沟通，这就需要我们及时总结本次沟通的结论和需要进一步跟踪或确认的事情，并且确定下一次沟通的时间和主题。

• 1.3 和测试团队成员沟通：

  • 1.3.1 对一个测试团队来说，测试用例和产品缺陷是主要输出。测试用例质量的好坏，会影响测试执行；测试执行又会影响到产品缺陷的发现，影响产品质量。
  • 1.3.2 软件测试架构师，作为测试团队的首席技术官，通过制定测试策略来保证测试活动的顺序进行，测试策略制定好后，需要和测试团队沟通，统一策略中的目标、思路和方法。

• 1.4 和领导或投资决策者沟通：

  • 1.4.1 对领导或决策者来说，它们一般不会太关注测试的细节，而会更关心下面所列的内容：
  • a.产品测试结果和产品的质量评估结论；
  • b.重要 bug；
  • c.重要风险；
  • d.进度。
  • 1.4.2 因此我们在和他们沟通时，首先要避免陷入沟通产品测试的细节中。在措辞方面，少用 “可能”、“感觉” 等这类不确定的词语，在表达上也不要轻易下结论，尽量不让不好的沟通习惯，在领导面前形成一种不够成熟稳重的印象，使领导对你的基本素质产生怀疑。
  • 1.4.3 在沟通产品测试结果和产品的质量评估结论时，我们可以将测试覆盖情况、质量目标的达成、遗留缺陷作为沟通重点。
  • 1.4.4 重要 bug 需要沟通的是当前进展、修改方式或规避措施。对典型的缺陷、后续改进计划也可作为沟通内容。
  • 1.4.5 如果在沟通时，你发现你对某些信息还不清楚，就承认自己不清楚，并声称自己马上会去询问相关信息，并承诺反馈时间 (承诺反馈时间非常重要)。

2. 写出漂亮的测试用例。