编写测试用例是一个测试人员的基本功，如果你从网上搜索如何编写测试用例的话，大概率会得到如下答案：
编写测试用例的方法：1、正交试验法；2、边界值分析法；3、等价类划分；4、测试大纲法；5、因果图法；6、判定表驱动法；7、场景图法；8、错误推测法。正交实验法是在各因素互相独立的情况下，设计一种特殊的表格，找出能以少数替代全面的测试用例。
这几种方法如果你学会了，就能写出高质量的测试用例吗？其实根据我的工作经验，感觉会适得其反的。
什么是测试用例？先不管专家或是学者如何定义，测试用例就是我们从需求出发，针对每个功能点编写的检测开发的代码是否符合需求的操作步骤。当然要包括正常操作步骤，异常操作步骤等等。用例的编写形式也非常多，常用的有思维导图，Excel 或是各个公司的用例管理平台。
那作为一个测试人员，如何才能写出高质量的测试用例呢？

一，测试人员全程参与

一个项目从立项开始，测试人员就要参与进来，一定要了解项目的整体计划，然后把测试计划也规划进去。当然在需求评审完成后，就进入了用例编写阶段，根据项目大小安排好编写用例的时间。同时也要有用例评审环节，防止因需求理解有出入，对程序实现逻辑不了解等产生漏测的现象发生。用户评审一定要产品，需求的开发人员都参与进来，后来面详细说如何评审。

二，用例编写形式

用例的编写形式很多，常用的有思维导图，Excel 或是各个公司的用例管理平台，那我们应该采取何种形式呢？先了解一下一个完整的用例包括哪些方面：

• 用例标题：概括描述用例的功能
• 用例等级：用例等级，常用的是 P0,P1,P2,P3.....
• 用例前置条件: 包括测试环境，测试数据，测试前置条件等等；
• 用例操作步骤：测试的具体操作步骤，一定要写详情，这关系到用例是否要以复用，不能写的用例无法读懂。
• 预期结果：用例执行的正确结果，这也是用例是否可复用的重要指标。

常规公司的 Excel 用例模板或是用例管理平台都会包括这几项，当然根据公司的需求也会增加其他项目，如，用例类型（Web,App，接口），是否关联自动化等等。

而我们在写用例的时候，个人建议先以思维导图 FreeMind 的形式罗列出需求的核心测试点，大概的测试点都要给出来，不用太细也不能太笼统了。然后可以拿着这个思维导图做用例评审，在评审的时候，可以查漏补缺，后面再转化成正常的用例，也有用例平台直接支持导入思维导图生成用例的。

三，用例编写要点

在用例编写过程中，如果公司没有规范的话，很多人尤其是老员工就会偷懒，把用例写的一塌糊涂，只有一个标题的用例，根本无法复用。这样写用例数量是上去了，可以后面怎么办，创建测试计划，选择 checklist 等等，一堆问题无法处理。所以一开始编写用例的时候就必须做到以下几点：
1，用例标题简明扼要
无论你是用 Excell 还是公司的用例管理平台，用例标题必须简明扼要，用最简洁的话描述用例的功能。不要把大段的描述或是需求文档上的文字来做标题，当用例多的时候可以从标题快速筛选用例，同时后续如果做关联自动化，或是其他用到用例的技术项目时，不会因标题过长而产生不必要的麻烦。
2，用例在突出级别
不少人写用例不分级别，所有的用例都是 P2，或是检测一个文字也要写成一个单独的用例；这样非常不好维护，后面创建测试计划，提出 checklist 的时候，也不容易挑选用例。可以这样划分用例：一个完整的操作的用例可以写成一个单独的；对于检测样式的用例，可以按功能页面进行归类，同一页面的检测放到一个用例中；同一操作可以按结果进行归类，如正常的操作结果下的几种情况；异常场景下的异常提醒等；再按公司对用例的要求，分别标注合适的等级。
3，操作步骤必须写清楚
不少同学写用例为了简单，就不写操作步骤，或是直接截图放到用例中；这是很不好的习惯，一是用例不通用，换个同学来执行用例，他就可能不知道如何执行用例的。二是不方便维护，如果用例涉及的操作有变化，用例如何维护便成了问题。高质量的用例必须有清晰的操作步骤，这样无论任何人拿到用例，都能按步骤执行到你的预期结果，或是重现用例导致的 bug。
4，预期结果必须完备
一个好的用例必须有预期结果的，这也是判断用例执行成功或是失败的依据。如果没有预期结果，其他人来执行时候，就不知道什么情况下算用例执行通过了？后续按用例来转化成自动化用例的时候，断言怎么写呢？
5，用例要及时维护
通常情况下一个测试用例集是针对特定的需求的，在需求上线后会将其中核心的用例转化成 checkllist,以便在后续的回归测试中进行回归相关功能。但由于产品的不断完善，早期的功能会进行优化，或是删除，无论任何情况，受影响的用例必须进行及时维护，以保证用例的可用性。如果不维护，在回归相关的功能的时候，可能会找不到相应的功能或是页面，操作逻辑有变化等等，导致用例无法执行下去。

四，用例评审

不少公司的项目流程中会要求有用例评审环节，大型的项目必须有用例评审，那应该如何评审用例呢？
1，测试人员组织
用例评审必须是由测试人员组织的，参与人包括需求对应的产品，开发，如果项目较大的话，包括项目经理以及项目涉及到的上下游人员。只有相关人员都参与了进行，才能更好，更加全面的评审用例。
2，用例的形式
用例评审的时候，不少同学会以 Excell 或是用例管理平台上的用例来评审，其实这个形式不好，因为都是用例的罗列，不能很好地体现用例间的关系。最好以思维导图的形式，大概罗列一下需求涉及到的功能点，上下游的影响关系，测试应该注意的事项以及异常情况的兜底策略等等。同时思维导图的形式也方便全面的展示用例，及时进行增加或是减少测试点。
3，用例评审记录
用例评审的时候要及时做好记录，方便后面细化或是补充用例，同时也要做好会议记录。评审结束后，发个邮件给评审的参与人，同时抄送经相关开发，产品的领导，让他们知道有这个事情。要记录好评审的结果，后续要做的事情，同时针对评审后补充全面的用例，也要发给相关人员确认一下，防止后面漏测时牵扯不清。

五，用例的常规用法

1，常规需求测试
编写测试用例是为了测试对应的代码是否满足需求，通常在测试过程中创建相应的测试计划，然后再按计划验证开发的代码是否符合预期。这个测试过程可能要反复测试多次，期间因需求变化，或是代码变化，需要修改相应的测试用例。一直到上线前进行回归测试，上线完成后，这个测试计划才算完成。
2，发版本回归 checklist
一个产品的核心功能在发版前都需要进行回归测试，所以也就必须维护一个 checklist。每个迭代增加的新功能，都会挑选核心的用例放到 checklist 当中。这就产生了一个问题：checklist 随着功能的增加会不断地增加，最终变得非常庞大，我们有个产品的 checklist 有 6000 多条用例。这是非常可怕的事情，一旦用例太多，回归的时候就大概率不会按 checklist 来了，根据自己熟悉的业务流程，简单地过一下就算回归完成。这样也会造成漏测的事情发生，checklist 也起不到作用了。checklist 必须定期维护，将 P0，P1 级别的用例放进来即可，早期一些 P1 级别的用例如果长期不改动，也可以先移出 checklist，保持 checklist 的高可用性。
3，自动化用例编写
在产品发展到一定的阶段的情况下，通常都会开展自动化测试的，无论是接口自动化还是 UI 自动化。编写自动化必须依赖于手工用例，不能自动化用例和手工用例完全没有关系，这也是不现实的。所以编写自动化用例的时候，就可以体现出一个高质量的手工用例的重要性了，测试步骤清晰，预期结果明确，自动化用例非常容易编写，否则写起来会非常困难的。
4，精准测试用例推荐
现在不少公司在做精准测试，其中有一个环节就是用例推荐。根据用例和代码关联关系，在一个需求提交后先 diff 出代码变化，再根据变化结合推荐算法，推荐需要回归的测试用例，以及来界定回归范围，提高测试效率。如果用例写的很乱，关联用例的时候涉及到非常多的代码，后续根本达不到推荐的效果。

六，总结

测试用例虽然很简单，也是测试人员入门必备的能力，但是要想写好一份高质量的用例也不那么简单。如果你能负责维护一套高可用，清晰易读的产品用例库，那就更加不简单了。当这样的能力成为你的习惯的时候，就不仅仅是在用例编写上，所以涉及到的项目，技术都能总结的很好，慢慢沉淀成你的知识体系，最后想不进步都难。