一、背景

有些测试同学，写测试用例的时候，直接就是将需求文档上的内容抄一遍，转换成测试用例的格式。没有加入任何自己的思考和理解，没有融入任何测试方法论。测试完全依赖于需求文档的质量，依赖于产品经理保姆级的服务。需求写得细，测试用例覆盖就全面，需求写得粗，就有很多地方都没有测试用例覆盖。

让他针对一个功能设计测试用例，总是习惯性的回答：根据PRD来写呗，PRD怎么说我就怎么写，慢慢地将自己变成只会复制、粘贴的工具人。在他们眼里，做测试和进厂打螺丝没有任何区别。最后上线出bug了，就转过头来攻击PRD写的怎么那么粗糙，完全不会思考自己的用例是否有问题。

二、测试用例的作用

1. 理清测试细节，提高测试覆盖率，避免漏测；
2. 通过详细的用例设计反推是否有需求漏洞，提前发现需求细节问题；
3. 提前准备测试数据，便于测试过程高效执行；
4. 测试过程中用于判断测试进度，预知测试风险；
5. 测试用例是测试的重要资产，便于测试内容回溯、测试工作交接；

看懂了以上测试用例的作用，请不要再将测试用例像垃圾一样用完随手丢弃，而是要好好写，好好存。

三、你真的会写测试用例吗？

传统的测试用例编写，会采用Excel的方式编写，用例中包含的内容大致如下：
测试模块、用例编号、用例标题、用例类型、用例等级、是否可自动化、预置条件、步骤描述、预期结果、备注。

Excel的方式适用于系统逻辑简单、清晰的需求。

如果系统需求较为复杂，需要测试人员做复杂的测试数据设计、做较多的联动场景测试时，推荐用Xmind的方式编写测试用例，通过脑图的方式，相比纯文字更有利于测试人员梳理测试逻辑。此外Xmind梳理测试点的方式也更适应如今互联网高效的模式，Excel编写维护起来会比较臃肿耗时，可读性方面也比xmind差。

测试类型：从从功能测试、UI测试、异常测试、场景化测试、功能性并发测试、兼容性测试、易用性测试、性能测试、安全测试、回归测试等多个维度去编写测试用例，用例才能有比较高的覆盖率，不容易漏测一些特殊场
景。

测试范围：如果需求是涉及多个终端（比如：App、小程序、PC端都涉及），或者需求是多方一起合作测试，最好单独拉一个模块写清楚：测试范围，提前划分好测试边界，确保信息对齐，各方的理解一致。

冒烟测试：抽出主流程冒烟测试用例，方便需求进测时先测试冒烟是否通过，并且冒烟用例也可以提供给研发自测使用。

用例分级：P1级用例、P2级用例、P3级用例，做好用例分级。测试过程中做好标记：测试通过、测试失败，便于统计进度。需要添加备注描述的，做好用例执行备注。

用例评审：比较重要的一个环节，需要拉齐测试leader、研发、产品一起评审，确认用例的正确性和完整性，排除因信息误差、理解偏差等导致错误的用例、用例覆盖率不全等问题。和研发约定好，开发需自测保证冒烟测试用例通过，才能达到提测标准。

用例平台：如果公司有专门的用例平台来管理整体的用例，也没关系，目前市面上常用的用例管理平台，或者公司自研的用例管理平台，基本都是支持Excel或者Xmind导入的。用例平台最好能支持将项目-需求-用例能关联起来存储，便于后续管理和回溯。也可以打通bug管理平台，建立用例和bug的关联关系。

四、测试用例模板

文章的最后，杨叔也将Excel和Xmind的测试用例模板上传到了百度网盘，搜索关注杨叔的微信公众号：程序员杨叔，下载地址在公众号同篇文章【你真的会写测试用例吗？】末尾，感谢关注~

都看到这里了，如果对你有帮助，麻烦点个赞+收藏+分享，一键三连啦~

程序员杨叔：
测开一枚，持续分享全栈测试知识干货。标签：自动化测试、性能测试、Java、Python、DevOps、CI/CD、小程序测试、测试工具、测试开发、测试框架/平台、测试管理…

标签：怎么,需求,Excel,用例,测试用例,Xmind,测试,应该
来源： https://blog.csdn.net/baidu_28340727/article/details/123607886