如何编写测试用例？

作为一名测试小白，刚接触测试工作，对如何设计用例很头疼，对需求理解深度不够，只能站在自己已有的知识角度去做测试，但是这样测试会导致需求覆盖率不能达到100%，这时候就需要编写测试用例了，但是怎么写总感觉写不好，这是测试小白的痛点问题！

更多小白找到bug不懂如何追踪？与开发的接触基本上口头交流，没有完善的测试体系规范。

测试用例又是软件测试的核心内容。

实施项目软件测试设计测试案例的时间占比60%，这也是萌新测试最大的难点。

因为测试用例设计的覆盖率全面性直接影响着产品的质量，并且设计的测试用例一定要能够发现bug才能真正体现测试人员的价值。

用例设计除了影响质量，一个好的测试用例能够发现至今尚未发现的问题，并且好的测试用例一定能够体现测试人员的综合思维能力。

一、用例组成

测试用例包括以下内容：用例编号、用例名称、用例操作步骤、用例优先级、预期结果这块内容是用例的核心内容，其中最需要关注的内容是【用例名称、用例优先级、预期结果】，一条好的用例如果没有包括这些完全内容都不算是一条完整的用例。

那么设计用例我们一定要遵循用例设计的规范：一定要包括两种思维即正向思维与逆向思维。

最最重要的就是逆向思维，因为正向思维大家都有，类似于一种程序员思维，但是逆向思维的并不是每个人都有，只有将产品的需求全面覆盖率达到100%才能满足当前产品版本的要求。

二、用例编写规范

当然一个好的测试用例更应该关注 标题的规范，一般来说设计用例标题如果不规范，下次你如果请假就不能很好的指导其它测试人员来执行你的测试工作，会浪费很多时间在沟通上，所以用例标题最好按这个规范去编写。

1.案例：【需求名称】输入条件与操作结果。

2.操作步骤一定要编写清楚。

例如：

  2.1   第一步：打开浏览器，输入URL

   2.2   第二步:输入用户名与密码

4.预期结果（重中之重）

所有的用例一定要包括预期结果，预期结果就是基于需求说明书中的正常结果，没有预期结果的用例不是一条完整的用例，也没有bug的判定依据。

三、用例评审

自己编写的用例因为经验能力的问题，难免会存在用例考虑不全面的情况，所以用例评审是实施测试工作的必经之路。

要想完善自己的用例覆盖率，提前完成的使用一定要与产品、开发、测试一起过审，以便发现自己用例的不足点，及时提出改善建议，保障所有的需求都有对应的用例覆盖，为软件质量保驾护航。

四、用例维护

通过一轮评审各产品、开发、测试人员总会对自己的用例提出一些不足问题与建议，这时候要想用例设计更全面，一定要按照开发与产品的建议去维护修改用例，不然实施测试工作会产生需求覆盖率不全面，最终影响产品不达标，所以用例维护就显得尤其重要。

结语：总而言之，设计用例也是一场人生的修行之路，需要多写多思考，多换位思考问题，多站在用户的角度考虑问题，才能更好的保障产品质量，当然用例设计你考虑再全面也不可能100%没有缺陷，但是你要保障100%的产品需要功能都要覆盖到，不然企业中的测试就无价值体现。

当然一个好的用例除了能够保障质量，也能发现产品、开发、用户层面的各种问题，所以要想提升用例设计能力，建议大家对产品的业务及用户使用场景一定要深入分析挖掘。

毕竟，你们常说：“要想更好的发现问题，你必须熟悉系统及业务”。

只有站在比用户更高的维度来思考问题才能提出更高级的问题。

所以发现问题比解决问题更重要，如果问题未发现程序员更加无法解决问题，对产品质量风险大。

建议大家一定要严格按照以上方法与流程来实施设计用例，让我们的产品质量提升可靠的保障。