6.3 测试用例

测试用例

如何设计一份优秀的测试用例？
写成非常清晰的步骤 这样的步骤能够引导不熟悉这个业务的人根据步骤执行下去，从而完成测试的目的
之前公司怎么设计用例的，有没有什么框架？

1. 正例反例分开写
2. 正例优先级高、反例低
3. 正例使用连贯式写作风格，一般最后的1-2个步骤和测试目的上下呼应；连贯式的写作风格最大的好处就是可以把设计好的用例交给不熟悉业务的人，也可以顺利执行。
4. 反例使用一个步骤，一个反向场景的方式去书写
5. 为什么要正反拆分，为了QA数据统计，以及回归测试的优先级选取。

要素：测试编号、前置条件、名称、日期、作者、优先级、 步骤描述、预期结果

所属模块、所属模块、测试步骤、测试数据、

边界值用来缩小测试范围，无效边界一定要测
等价类用来分类确定有效等价和无效等价，在有取值范围的情况下，取一个有效等价和两个无效等价
场景法：很常用
错误推断：头脑风暴

用例设计

模块化设计
美观、快速定位测试用例位置、对业务逻辑梳理的一种良好表现，如何划分：

1. 系统大功能划分
2. 产品怎么分你就怎么分
3. 在大功能划分好之后对二级模块进行划分
4. 细分子功能的业务场景
5. 至少把正常流和异常流区别开来

eg：
网盘_上传_上传文件夹
网盘_离线下载_新建BT_任务下载成功
网盘_离线下载_新建BT_任务中途取消（下载失败）

用例颗粒度

1.粗颗粒度：
优势：维护简单，节省时间
劣势：不熟悉功能的人没法执行设计的测试用例
2.细颗粒度：
与粗相反

用例执行

执行结果：

1. Pass

2. Failed

   写实际结果
   提交缺陷并在实际结果中标注缺陷编号

3. N/A

4. Blocked

测试报告

一、测试周期

1. 测试设计：yyy/mmm/ddd~yyy/mmm/ddd
2. 测试执行：yyy/mmm/ddd~yyy/mmm/ddd

二、测试轮次

截止发布日，测试一共执行了n轮测试

三、测试用例执行情况

1. 测试用例个数：100
2. 测试执行率（case execution rate）100%
3. 测试通过率 （case passed rate） 95%
4. 测试通过率 = 通过的用例数量 / 总用例数量 * 100%

四、缺陷一览

1. 本次测试我一共发现了n条缺陷，其中，严重程度高的有x条，中y条，低z条
2. 本次缺陷的模块分布图如下:(禅道饼图或者excel)

五、本次还有以下列表中的缺陷未修复

eg：

缺陷ID	1
缺陷描述	xxxxx
严重程度	中
提交缺陷人	张三
当前指派人	开发1
未修复原因	优先级不高
计划修复时间

缺陷ID 缺陷描述 未修复原因
计划修复时间

六、风险评估（免责）

回归测试粒度不足，方向不明确，可能存在风险

七、测试结论

所测功能，基本没有问题，且经过多轮回归测试，经综合评估，建议上线