1. 为什么要做好测试分析和测试设计

以业务驱动测试：当下的测试圈子内，大家一直在强调自动化技术、DevOps等，这些是提高效率和质量的利器，但是所有有效的测试行为，都是建立在对业务需求有正确的理解和分析的基础上的。软件系统以满足用户的业务需求为目标，做好需求分析、测试分析和设计，是开展后续测试行为的必要条件。在提升效率的同时，也丝毫不能减少在这几方面的投入，对业务的快速学习能力、抽象能力是测试人员必备的技能，测试思维需要在这些行为中不断完善。
测试分析的必要性：除了做好业务分析之外，还需分析被测对象的其他测试需求，例如性能、稳定性、安全、是否适合做自动化、被测对象的重点、难点等等，明确了被测对象的范围、重点和难点，我们才能有针对性地去设计测试用例，评估测试风险，做好测试计划。
测试设计的必要性：测试行为的开展，需要高质量的测试用例；高质量的测试用例来自于科学的测试分析和测试设计。在测试分析的基础上，根据需求有重点、有优先级地合理的设计用例，能更好地满足对被测对象的覆盖。

2. 测试分析

测试分析的过程，就是明确需求的目的和价值、分析需求的可行性以及评估需求的优先级，最终明确测试对象和测试范围，测试的重点和难点。

步骤	目的
1. 理解需求、分析需求的价值。	理解需求的目的和价值。
2. 分析需求的可行性。	评估实现方案的可行性，是否可以做。
3. 评估需求的优先级。	评估做不做，什么时候做。
4. 测试分析。	1. 明确测试对象、测试范围； 2. 明确测试的重点、难点。

理解需求、分析需求的价值。

在需求评审阶段，运用5W1H方法，理解需求的目的和价值。
1. What: 产品需求是什么？（需求概况）
  - 了解需求概况，大概是个什么需求，来龙去脉。
2. Why：为什么要做这个需求？（用户的需求是什么？为了解决什么问题？需求目标）
  - 明确需求的目标，做这个需求，本质上是为了解决什么问题？用户提的需求解决了真正的问题了吗？
3. Who：需求的服务对象是谁？
  - 用户是谁？有什么特征？
4. Where：在什么场景下使用？
  - 用户需要在什么场景下使用？有什么特殊性？
5. When：什么时候用？
  - deadline是什么时候？
6. How：怎么实现？
  - 产品的需求是怎么玩的（具体的产品流程、规则）？需求实现的标准（验收的标准）是怎样的？
分析需求的可行性。
1. 需求实现方案是否可行？对现行系统的影响大不大？代价大不大？
2. 是否满足了用户真正的需求？
3. 有没有更好的替代方案？
评估需求的优先级。

常见方法：
1. 四象限法则
  1. 按照需求内容、当前公司/项目商业目标、人力投入和产品能力，评估需求在哪一个象限，再根据具体象限的建议执行。
  2. 四象限法则示意图：
  3. 重要且紧急：立即去做。
  4. 重要不紧急：列入计划做。
  5. 紧急不重要：授权他人做；以高效率的方式做；或者不做。
  6. 不重要不紧急：尽量不要做。
2. KANO模型
  1. 按照用户满意度、功能必备程度来分析需求的价值。
  2. KANO模型示意图：
  3. KANO模型因素释义：
    1. 必备因素：必须具备的，不做无法满足用户的需求，用户满意度会大幅下降。
    2. 期望属性：如果具备，用户的满意度会显著增加；如果不具备，用户的满意度也会显著下降。
    3. 魅力属性：如果具备，用户的满意度会显著增加；如果不具备，用户的满意度也不会下降。
    4. 反向属性：没有没关系，存在了反而令用户反感。
    5. 无差异属性：有或者没有，用户的满意度都不会有大的变化。
3. 根据优先级，安排开发计划。
测试分析
1. 明确测试对象和测试范围。
  1. 测什么？
  2. 测哪些？
2. 明确测试重点和测试难点。
  1. 重点保证什么？
  2. 哪些地方有风险？需要花时间？

3. 测试设计方法

基本流程
1. 设计基本框架。
2. 完善分支场景、特殊场景和异常场景。
3. 补充测试条件、测试步骤、测试数据，形成测试用例。
设计方法
1. 从流程设计。
  1. 核心流程覆盖、分支流程覆盖。
  2. 重点步骤覆盖、分支步骤覆盖。
2. 从参数设计。
  1. 因果图。
  2. 参数值的范围。
3. 从数据范围设计。
  1. 边界值。
  2. 等价类。
4. 组合设计。
  1. 因果图。
  2. 判定表。
5. 贯穿所有设计中的界面检查。
  1. 界面风格。
  2. 稳定性。
  3. 操作性。
  4. 对比设计稿检验。