测试设计应该怎么写？

测试设计应该怎么写？

一、测试设计三要素

1. 测试方案

• 也称为测试设计说明，细化测试计划中描述的测试内容和方法。
• 在一定的软件测试标准、测试规范指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式和方法的集合。

2. 测试需求

• 描述测试项及其特征。

3. 测试用例

• 包括测试过程说明，描述执行一次的输入和预期输出。

二、测试方案

测试方案有何作用？

1. 可以帮助我们考虑如何平衡测试资源投入何质量风险。
2. 帮助我们确定测试方案、明确测试重点、选择测试方法和工具。
3. 帮助我们丰富和细化测试计划。

那么测试方案又考虑什么呢？用何作为输入？有以下几点：

1. 质量要求
2. 需求范围
3. 测试技术
4. 测试资源
5. 开发计划
6. 上线计划

测试方案的输出为？通常有以下分类：

1. 基于功能性需求的测试方案
2. 基于非功能性需求的方案
3. 基于测试阶段的测试方案

二、测试需求

为什么从测试需求开始做测试设计？

1. 测试需求比功能点更精细，可以根据测试需求得出精准的测试工作量。
2. 在功能点的优先级已经确定下，我们可以再对测试需求做一个优先级分析和排位。

如何梳理测试需求呢？根据不同的测试也有不同的考虑，比如：

1. UI测试

• 检查页面是否跟设计图一样。
• 是否符合UI规范。
• 是否具备兼容性。

2. 交互测试

• 检查用户使用中的界面交互，页面跳转是否跟产品交互设计原型一致。
• 提示信息是否合理、友善、具备指导下。

3. 业务逻辑测试

• 按照需求文档或功能规格说明书去验证每个功能模块的逻辑和流程是否符合设计要求。

4. 数据验证

• 对业务产生的数据做完整性、逻辑性、合理性、兼容性测试。

三、测试用例

设计测试用例难得不是方法，而是思路，而思路的形成依赖于业务的熟悉程度，那么通常编写测试用例的思路是怎么样的呢？
测试用例编写思路（重点！！！）

1. 划分功能模块
2. 正向功能验证：正常操作功能是否无误
3. 单个功能项验证：正向+异常（也就是骚操作）
4. 功能之间交互验证：有些功能模块之间是有数据交互的
5. 隐形需求：这里需要你对业务十分熟悉，开拓自己的思维，发掘测试点

测试用例编写的方法
方法很多，有黑盒、白盒、灰盒，一般常用的的是黑盒测试，黑盒测试的方法可以参考另一篇文章：黑盒测试方法