如何写好测试用例

如何写好测试用例

测试用例设计能力作为测试人员的核心竞争力之一，一般有过2年以上工作经验的大部分测试人员都会觉得没有太多的技术含量，无非是对需求的理解透彻后就能写出覆盖比较全的测试用例；但当一问到如何写好测试用例时，往往又说不出来。一来是自己在用例编写方面没有总结思考过，往往只是在写用例而不是设计用例；二来是随着经验的增长，测试沉淀的方向偏向了测试工具，测试自动化等等，却忽视了测试用例基础的沉淀。
那么功能测试人员，如何设计一份好的测试用例来？
一、需求层面
项目过程中，测试人员是对产品细节了解最全面的角色，测试人员要写好测试用例不仅仅是自己需要对这个产品需求理解透彻，而且还要帮助产品，开发来理清楚产品的需求细节。有同学可能会觉得，我自己理解透不就可以了不，产品自己出的需求还需要我们来梳理？开发对需求的理解也需要我们来帮助？
为何要这么做？一方面质量需要整个项目共建，需求是源头，做好需求管理整个项目都受益；另一方面，当产品，开发和测试对需求各个细节都达成一致时，会减少后续的变更的风险。
那么要如何做？作为测试人员更能挖掘出产品需求的一些细节点，常见的一些方式是我们可根据自己的产品，制作一些该产品类型的需求checklist，规划产品按照我们给出的检查点来补充产品需求，同时我们在需求评审时也可以按检查点提出一些我们的思考。
如：
针对需求本身
1.需求的流程节点是否完善；
2.需求是否存在逻辑分支，是否考虑全面；
3.需求的用户场景是否存在漏动；
4.需求耦合模块有哪些，主要影响哪些功能；
5.需求的预期是否明确。
6.······
开发设计
1.页面跳转是否需要缓存；
2.并发量需要控制在多少范围；
3.页面的FPS，响应时间多少是可以接受；
4.界面的渲染是否新开发子线程；
5.数据拉取和加载是否分页模式；
6.······
做好这一步，也就意味着我们在需求评审时，已涉及好了一部分用例，且让产品和开发在执行我们设计的用例了，同时我们也达到了测试左移的目的。

二、开发层面
我们对需求理解清楚后，基本上也可以完成黑盒层面的用例场景编写了，目前我们大多数测试人员都是这样做的，而我要说的是与开发了解他们的设计方式，往往能提高我们测试用例设计的准确性和效率。当我们清楚开发的代码流走向，以及各条件分支流向和数据存贮逻辑，我们也可以考虑针对性的一些场景用例，比如，有两个判断条件A和B，开发是先判断A再判断B，还是先B再A，我们在用例设计时是可以有针对性的。

三、测试层面
测试人员从黑盒层面来思考用例设计。
1.需求的业务流程，以及各个流程节点进行模块划分成各个小功能模块；
2.针对小功能模块进行从入口，UI，正向流场景，异常场景，耦合交互场景等各个模块的思考设计；
3.针对功能的等价类，边界值，错误推断，正交表等常规设计方法的思考，用于用例场景中；
4.思考各小功能模块的兼容性，安全性，易用性，性能方面等影响；
5.异常场景结合探索性测试思维方式进行思考
如，破坏测试法，取消测试法，麻烦测试法，恶阾测试法，遍历测试法，极限测试法等等（具体参考我分享的探索性测试方法一文）。
那是不是这样做了设计出的测试用例就完美了？
我们以前流传着这样的说法，“好的用例都是改出来的”。用例设计也比较考验我们的文字功底，我们有用例模板，模板涉及功能模块，用例标题，条件，步骤，预期结果等。其实就是我让我们描述，谁在什么地方，什么前提下干了啥事，产生了什么结果。就像我们小学学习一句话的主语、谓语、定语、宾语一样。我们在描述时，谁是主语，谁是宾语，在不同的产品或不同操作情况，表达起来会产生不同的效果。打个比方，用例步骤：用户点击按钮跳转到搜索页面检查页面表现；预期结果：按钮变成灰色；搜索页面自动搜索出热点新闻。用例步骤和预期结果中，主语宾语都在变换。按钮由宾语变成了主语。
总体来说，文字描述就是为了让用例易操作，易理解。有些用例刚开始我们自己觉得写得没什么总是，但当我们评审或执行用例时，觉得描述有歧义或不清晰时，我们就得改过来更通俗易懂。所以就有好的用例都是改出来的说法。