如何编写测试用例

这篇我们来讲一下测试人员最基础的一项技能-编写测试用例。

先普及一下写测试用例的好处哈，可能刚入门的测试不太了解。
1.我个人觉的测试用例比较大的一个好处，就是纪录。如果你测试的是一个功能比较大的系统，测试时间又比较紧迫，那么在测试期间很有可能就把已经测试过的东西忘了。这样无形之中就浪费掉了很多时间，有测试用例的纪录就能清楚的知道什么已经测试通过了。
2.第二个好处表现在时间差上面，一般写case的时间是在开发阶段，在这期间测试的事情不会太多，有充足的时间进行思维发散，能够想到更多的情况，并且记录下来。
3.第三个好处就是盲点，我们每个人都有一定的思维习惯，如果把你写的用例交给其他人检阅或者进行用例评审，其他人就能够进行查缺补漏，这样能够更好的保证系统的稳定性。
4.第四个好处就是新人熟悉，如果有部门来了新的测试人员，老人又不可能给他讲的太细。那么熟悉业务的最快的手段，就是跑几遍测试用例，这样可以快速上手。

关于用什么工具写测试用例，这个主要还是看公司或者部门的要求和自己的习惯来选择，没有什么优劣之分，可以用xmind，excel等等。自己用的顺手就好。

我个人习惯把测试用例的分类从使用场景上分，把测试用例分为功能用例和回归用例。我们一般说的测试用例就是功能的测试用例，比如，产品提了一个需求A，我们需要写一下A的测试用例。这个就是功能用例。A功能测试完成后，要发版了，app里原先可能还有BCDEF功能，需要我们回归一下，具体怎么回归，这个时候就需要我们制定一份回归用例，在发版前跑一遍回归用例，确保我们的基础的功能是正常。

接下来说一下如何编写测试用例，个人在设计测试用例上的有几条主要的原则。
1.思路清晰，逻辑清楚，文字要简单易懂。因为你写的测试用例，很有可能是有别人来测试，甚至你的用例是要进行评审的。那么具体简单易懂到什么程度？就是任意一个没有测试经验的人根据你的描述能够跑完全部的测试用例。
2.一定要有一条输入和一条输出，就像加减法一样，例如:1+1=2，1+1是输入，2是输出，这样就是正常的，如果输入1+1，输出是3，那么就是bug了。
3.干净整洁，层次分明，这点和第一点类似，如果一个比较复杂的功能，那么可能会有成百上千条测试用例，管理起来会比较麻烦，界面干净整洁，层次分明会省去你很多的管理时间，看起来心情也会很好。

再来说一下编写功能测试用例的方法，常用的方法有：等价类划分法，边界值分析法之类的。我们编写时可以根据具体的情况来设计，如果不太清楚，可以自己百度一下。我这里再补充一点，那就是多注意一下异常情况。一般线上的出现bug都是由异常操作导致的，因为异常的情况一般不太容易想到。不同的测试场景，异常的情况是不同的，也是多种多样，这个只能靠大家平常积累。我在最下面贴了一份我曾经写的关于下载的测试用例，仅供参考。

最后来说一下编写回归用例，可能有的人不重视回归测试用例。在这里我要强调一下回归测试用例，非常有必要，尤其是在大公司里，因为你根本不知道其他部门的修改会不会对你负责功能有没有影响，跑一遍回归用例，可以确保基础功能是正常的。
编写回归用例有几个要点：
1.尽可能的覆盖所有的基础功能，只是基础功能。
2.所有的用例都以模拟用户的行为为主。
3.每一条测试用例都要尽量简单。
4.跑一遍回归测试用例时间不宜过长。
5.如果有能力，部分回归测试用例可以用自动化来代替。

关于如何编写测试用例暂时说的就这么多，如果大家有什么不足的或者想补充的，欢迎进行评论。