功能测试之如何写好测试用例篇

一、本文背景：

虽然我已经写过上千条功能测试用例了，但是总还是觉得自己的测试用例写的不够完善，需要优化的地方很多，本身工作之后持续学习也是必不可少的，之前公司也会经常对新老员工进行测试用例编写培训，让大家意识到什么样的用例才是好的用例，之前测试leader就会说即使有很多工作经验颇为丰富的测试老员工们也会存在用例存在瑕疵的情况，因为我自身测试经验浅薄，本文仅供参考欢迎指正。

二、测试用例是什么？为什么需要写？

先说为什么测试需要写测试用例，都属于个人见解：

首先，我认为如果上级给你一个功能极少，使用极简单的产品，或许三下五除二你就能对它完全进行主流程功能测试，但是细节可能容易被忽略，导致测试覆盖度不全，隐藏上线风险。其实，市场上不乏有很多小型公司是不进行用例编写的，产品开发完直接就进入测试了，我身边就有朋友在这种公司工作过，基本不写用例，要写也只写验证点。其次，如果拿到的是一个庞大复杂的产品，如果不写梳理测试点，编写用例，测试起来会显得杂乱无章，会东测一点西测一点，那样的话覆盖度更加难保证，会有极大的上线风险。

上述可知为什么需要写用例了，其实一条用例就是一个验证点，一个一个点的去验证产品的功能、性能、人性化体验才能最终保证产品的质量。

三、测试用例怎么写？

用例怎么写，其实网上可查到的答案数不胜数，我之前学习写用例见过最多的就是博主们以登录功能为例子举例说明，不得不说这个例子很通俗易懂，并且我在好多次面试过程中，也会被面试官问到“给你一个登录界面，你会怎么进行测试？”。

首先说说测试用例的要素，不同的公司可能会有不同的用例模板，但是基本要素是不变的，如下：

上述表格里“用例标题”、“操作步骤”、“预期结果”、“实际结果”是一条用例最主要的要素，一定要写并写写清楚。另外，写用例基本上都是使用Excel表格写，不用去寻找别的杂七杂八的工具了，最多就是在写用例之前想要梳理一下功能模块和测试点，可以使用Xmind、亿图图示进行导图绘制。

下面我也举个简单的栗子：

以微信中给自己换头像这个功能为例说明，仅换头像功能。

可以自己思考一下，我在下面也分享我的测试点

下

下

下

下

下

下

面

上面的测试验证点是我目前能想到的，欢迎大家指正添加。

梳理罗列完测试点后，就可以使用Excel进行用例编写了，下面根据个人用例风格写两条分享一下：

每个人可能都有自己的用例风格，有的公司不会严格要求用例具体内容书写规范，有的公司会有一些小的要求，比如有的公司会要求按钮必须在用例中使用“【】”标注，“点击【返回】，页面回到上一个页面”。不过，只要将用例写清楚就没问题啦，尤其是用例标题、测试步骤和预期结果，之前我所在公司导师就说一份好的用例是要让不懂业务、不懂产品的人都能执行，哈哈。但是其实没有那么夸张，但是如果有用例评审这一环节，会给到开发、产品、设计一起会议评审，需要写清楚，大家才能理解，节约更多时间。

四、如何让用例得到优化

首先，用例设计的基本方法需要知晓并且能够熟练应用到实践中，尤其是等价类和边界值，这两种方法是最最常用的。

其二，就是用例一定要规范，描述清楚，不要后面评审时自己都看不懂某条用例是什么意思。

其三，用例覆盖度是一个可以一直总结提升的点，因为现在很多公司产品都是敏捷迭代，随着迭代新增和优化功能，慢慢的之前的用例可能部分不再适用，需要修改新增，这种时候就需要好好按功能模块梳理验证点，结合用例设计方法设计用例，提高用例覆盖度。这一点也是我毕生所有追求的，害。

另外，我个人很多时候写用例，发现满篇用例更多的都在描述UI界面，功能细节方面描述不足，后续这方面也值得思考提升。

最后，总结一点，一份优秀的用例应该是描述规范清楚，粒度几乎全覆盖的，这也能反应一位测试工程师的能力，优秀的测试工程师并不止是看测试能力足够强，也看用例编写能力。

————————————————————————————

本篇完结