怎样写好一个测试用例。作为我们部门的测试OG，我认真的做了一下总结，打算今天给大家做一次分享，希望能帮到各位测试新手们。

再分享之前，我认为聊一聊“为什么要写测试用例”非常重要。因为正是它的重要性决定的。

我认为，写测试用例的理由有5个，分别是为了：

理顺思路，避免漏测和重复测试

帮助预估测试排期，把控进度

方便bug回归验证

便于发现、记录并复现问题

标记测试结果，即对于测试结果有个交代

接下来，我们来说说“优秀的测试用例是什么样”的。好的测试用例，一般有这些特征：

包含基本信息

包括测试人/开发/产品/需求文档链接地址/技术文档链接地址

包括你测试过程中需要的物料

每一条用例，有很明显的突出测试预期和测试目的

所有用例都是可执行的

逻辑脉络清晰，几乎不存在重复的用例，简约而不简单

用例做到分级分层

待测功能点覆盖全面

说到这里，我还想要强调2个观点：

千万不要纠结测试用例的格式或形式！

也千万不要觉得测试用例写得越细越好！

有了以上基础，接下来才能够讲明白如何去写好测试用例，不，确切的说是写好测试方案。

一、基础信息

这里再补充一点：测试排期/上线时间/Bug提交地址 等

所以，基础信息至少要包含：

标题：【xxx】测试用例

新功能简介（或者需求目的目标）

参考资料

干系人

测试排期

上线时间

Bug提交地址

如果项目有 业务流程图 或者 系统框架图，也可以po到测试方案里面去体现，方便熟悉业务目的或者上下游系统间的依赖。

二、测试方法

根据需求的不同，又可以分为多种测试手段（手段）

最主要的：

功能测试

单元测试

性能测试

稳定性测试

兼容性测试

安全测试

UAT测试

根据测试项目的实际情况而定，比方说：你只是测试一个搜索框改了个默认提示文案，你就没必要去单独再去硬套模版测试性能了。

其实谈到写测试用例，大家更多的还是在写功能测试用例，所以这块重点讲。

功能测试用例，要做好分层设计（至少2层）：

第一层：冒烟测试用例

第二层：常规测试用例

冒烟测试用例，其实也可以当作是 提测准入测试用例 以及 验收回归测试用例

这部分用例相当于P0级的测试用例，主要是为了保证主流程是完全走通的，如果走不通，则测试有权利打回给开发，让开发把主流程跑通后，测试再继续往下进行。

常规测试用例，呵！这里就是八方神仙、各显神通了！

设计测试用例的时候，是有一些策略和方法可循的。

测试方法不必多言，掌握几种常用的黑盒测试方法即可：

等价类

边界值

场景法

判定法

正交试验法

因果图

状态迁移图

其中用得最多的，恐怕就是 等价类、边界值、场景法 了。

测试策略就比较有讲究，需要大量的测试实践，才能形成一套自己的测试策略。

我自己总结了几条：

1）二八原则：重点抓主流程进行测试，不过分钻牛角尖。

80%的问题，集中在20%的模块里

80%的Bug，由20%的开发者写出（日久见人心，你懂）

2）要模拟真实的用户场景，不要YY出来一个永远都不可能发生的场景。

3）相互依赖的服务之间，最容易滋生Bug。

4）金字塔原理编写法，可以自上而下或者自下而上，杜绝重复用例。

三、数据构造

很多人不注重数据的重复利用，每次测试，都花费大量时间在构造数据上。

但是假如你在些测试方案时，就把数据构造和数据构造的方法写上去，

包括一些SQL、表格数据、json数据、账号密码等等测试数据

当下次还有相同的测试场景时，可以翻一翻之前的测试方案，就不用再花费太多精力在构造数据上了。

写测试用例的五大注意事项：

第一步、明确测试范围

有些需求是多个部门一起合作的，可能会有多个测试和你一起分工合作。

你需要明确自己主要负责测试哪些地方，细化到功能模块。

这个时候，你应该明确两点：

你测试的模块到底依赖哪些其他模块

有哪些模块依赖你所负责测试的模块

设计测试用例的时候，把重点放在设计你自己负责的测试范围上；

对于有依赖的模块，也需要考虑降级和容错，也就是你要考虑，你负责的模块出问题了，对人家造成什么影响；

或者，人家负责的模块出问题了，对你所负责的模块有什么影响。

明确测试范围的2个好方法：

需求评审会一般产品会按功能模块去划分，分别评审，你需要和与你对接的产品和开发步调一致。

测前沟通，找开发和产品去做测试前的沟通，必要时，甚至要找关联的测试人员去做一次沟通，明确测试范围。

第二步、熟悉需求文档

需求文档至少要看三遍！

在你熟悉需求文档的时候，也相当于已经进入测试了，像一些公司美其名曰：文档测试。

产品经理写需求没想到的，你想到了，都可以大胆的提出来，要有质疑的精神。

另外这里还有一个小建议：尽量让产品经理把产品的流程图画上，流程图可以反映出数据流向是怎样的，这可比文字更加直观。

这样你会对整个需求文档有更深的理解。

第三步、熟悉开发文档

开发的系统设计文档、接口设计文档、数据库表结构，如果有的话，最好都看一遍。

第四步、设计和编写测试用例

现在大部分测试工程师手工测试都喜欢用Excel或者Xmind来编写测试用例。

Excel 比较适合用例较少、操作步骤简单、可能性有限、结果预期比较明确的功能。

Xmind 比较适合用例较多、功能相对复杂、结果预期比较多样的功能。

以下分别举两个使用场景：

（1）假如说测app的话，个人感觉用Xmind可能会更合适，

用Excel的话，由于功能比较繁琐，可能用例条数会很庞大，一方面测试起来，看太多表格，容易头晕。另一方面维护起来也比较麻烦。

而Xmind可以只是把功能点写上，本身结构化的设计思维会让测试思路比较清晰，测试用例维护起来比较方便。

（2）对于上线后的回归测试验证点（CheckList），我们可以用Excel去表达，主要是针对主流程主功能的正向操作进行验证，逐条操作也防止漏测。

但其实用哪种软件编辑测试用例，都是看个人的使用习惯，关键是自己能看懂，别人也可以看懂就可以了。

设计测试用例时的，需要结合需求文档，把测试点罗列清楚，尽量用简洁的语句表述，非常忌讳写出过于啰嗦的用例。

另外，设计测试用例的几条思路我也简单介绍一下：

按模块把功能点罗列全，切记不要照抄需求文档，这样写不写有什么区别？

软件测试的基本测试方法要有效利用上，像边界值法、等价划分类、场景法等等，都是特别实用测试方法。

不要在细枝末节上纠结太多，根据二八法则，80%的bug都集中在主流程里面，要确保主功能主流程没问题。

第五、用例评审

测试用例设计完，一定要和产品研发一起评审测试用例，漏掉的测试点要及时补充。

文章来源：网络 版权归原作者所有

上文内容不用于商业目的，如涉及知识产权问题，请权利人联系小编，我们将立即处理