# 做好测试用例设计 工作的关键有几点

1. 熟悉业务、需求和用户的使用场景

2. 了解本次需求对其他系统模块的影响

3. 了解开发技术实现和数据库的设计

   > 参加设计评审, 拿到开发画出的用例图、流程图、时序图等物料；了解数据库的设计 字段含义

4. 从不同维度编写测试用例。

   基础功能：

   - 正向、反向

   交互场景：

   - 简单、易用、响应时长（可关注前端静态资源加载、后台慢sql、数据返回量太大无分页等）、友好提示

   业务场景：

   - 很重要
   
   并发场景：
   
   - 主动思考并提取出来
   
   兼容：
   
   性能：
   
   

## 编写测试用例的设计方法、用例模板、规范

### 设计方法

场景法 、边界值、等价类、正向反向。详细可参考如下教程

> [设计方法: 教程1](https://blog.csdn.net/m0_50542287/article/details/121493305) 
>
> [设计方法2: 教程2](https://blog.csdn.net/OtsukaA1/article/details/102599151)

### 测试用例模板 

![测试用例模板（版本号7.0.1）](http://biji.51automate.cn/blogs/img%E6%B5%8B%E8%AF%95%E7%94%A8%E4%BE%8B%E6%A8%A1%E6%9D%BF%EF%BC%88%E7%89%88%E6%9C%AC%E5%8F%B77.0.1%EF%BC%89.png)

### 具体规范（原则）

> 每一条用例 有明确的测试步骤和预期结果和前置物料
>
> 用例一条一条的可执行的 
>
> 用例解耦（不要在测试用例中引用别的测试用例）

## 实操过程

需求评审通过了之后，拿到 需求文档，才开始写， 写的过程就是加深思考的过程 。
用例按 功能模块 功能点 层级关系 ,基本就是对应用例的分组 ，分组（模块）写好了，大方向就不会遗漏 。

通过测试用例的设计方法、按照用例模板 和 规范 一点点的写 。

如果时间不够 先把 层级 功能模块分好，对应的用例标题写完，慢慢补充，看着标题页可以用例评审 （如果只是那测试点 去评审，别人的思维可能和你的不一样，产研同学很容易蒙）。



每一个模块从6个大方面验证 ：`UI&交互`、`功能验证`（比如列表搜索、翻页 、上传下载等）、`流程验证`（正向、反向）、`安全验证`（敏感信息非明文等）、`异常验证`（友好提示）、`兼容性验证`



总之，好的用例就像记录一个bug一样，不单单是给自己看，即便是其他借调过来的同学也可以根据你的用例，清晰明了的按步骤一步步执行，并对比预期和实际的结果。

作为测试leader，要有意识的统一`xmind`用例模板，才好基于脚本 统一导入jira等平台 进行`用例沉淀`，方便也能为以后的测试绩效考核奠定基础。



## 规范（原则）

关于用例解耦原则

> 我还是反对用例依赖的做法，理由如下： 
>
> 1. 功能用例设计，每条用例都应该是独立执行的；测试用例由多个测试步骤组成，每个步骤由操作描述和预期结果组成；这个规范其实应该套用到自动化用例设计上的，据我了解京东的接口测试平台也是这个逻辑；
> 2. 功能测试步骤里面的操作描述对应到接口调用、数据库查询等逻辑，预期对应到断言； 
> 3. 在分布式并发执行用例时，不用担心用例依赖问题，不存在依赖导致的执行出错； 
> 4. 如何实现复用？回到功能用例设计，就能发现复用的其实是测试步骤，那么自动化用例也应该复用测试步骤，京东的接口测试平台复用的就是测试步骤；
> 5. 复用技术如何实现？业内其实是有现成技术的，叫做依赖注入。pytest的fixture就是一种依赖注入技术，即插即用，所谓的自动找依赖的事情，fixture已经有很成熟的实现把它做好了。 
> 6. ao模式我是第一次听说，可能这是基于pytest开发“测试框架”自己发明出来的？我在网上并没有找到类似解释，只有po模式，page object，UI自动化里面的一种设计模式。 
> 7. 自己开发框架确实能实现落地，也能证明一些技术能力。但是很可能是自己玩嗨了，别人根本用不了，代码都看不太懂更别说写用例了。所以遵循良好自动化设计的框架比如robotframework、httprunner、pytest，aamt、tep工具等，才会被更多人使用。好的代码是看起来很整洁的，而不是故作高深。 
> 8. 关于断言，功能测试用例，假如某个测试步骤的预期结果不符合，那么整条用例就应该是失败了。



其他原则待补充