【用例设计】写不好测试用例是因为没时间吗?

工作当中,总会有人为自己的测试用例写得不够好去找各种理由,时间不够是我印象当中涉及到最多的,也是最反感。想写好测试用例，前提是测试分析和需求拆解做的足够好，通过xmind或者UML图把需求和开发设计提供的产品信息提炼出来。

我个人的提炼标准一般是：

1. 所有业务链路是否是闭环；

2. 所有业务场景以用户层面来观察是否合情合理；

3. 技术设计是否存在性能/可靠/安全等风险；

4. 梳理测试要点，明确每个业务在测试环节里面需要观察的功能预期；

5. 开始明确测试方案，确认列出来的测试要点要怎么样才能实施测试。这里多问自己一句：只做功能测试能满足质量覆盖的要求吗？不能就扩展考虑是否做白盒测试/接口测试/性能测试/稳定性测试/安全测试/体验测试/...；

6. 然后才进入测试用例编写的阶段，通过对测试点的特征评估考虑用哪种测试用例设计方法覆盖；

7. 最后输出用例。

在这里,我想说说我对用例的个人看法：
1.用例不仅仅只是为了满足功能测试，它应该是通过一组输入输出的方式用来衡量产品功能是否符合预期。
2.测试用例不可能永远只被设计者执行，所以请严格按照规范来设计和编写用例，让其他后继的执行人能高效准确的执行。
3.用例设计是极其严肃的任务，但是业内很少QA会真正的做到根据被测试对象的特征来挑选测试用例设计方法并严格按照这些方法来输出用例。

所以,不要说什么时间不够来不及，假设有一天你去了一个时间充足对质量要求极高的测试岗位，你能保证最细的测试颗粒度是多少？做测试要知道自己的上限在哪里，因为绝大多数的质量问题不是因为时间太少，而是测试眼界不够高，想得不够多，做的不够好。

 

学习安排上

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。【保证100%免费】

视频文档获取方式：

这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。