接口测试用例设计

一、编写接口测试用例的一些感想

书写接口测试测试用例的考虑点：

1，充分滴熟悉PRD（产品需求设计）

了解PRD，熟悉业务规则，根据业务规则来确定测试点。为了辅助理解产品的架构，可以画mm图，将需求分类。在编写用例的过程中进行等价类的划分，最后用判定表进行评判，补充缺少的用例，剔除冗余的用例。做到对需求的100%覆盖。要明白哪些是核心功能！

（测试用例的有效性）测试用例应该包含清晰的输入数据以及预期输出，没有测试数据的用例更多的是具有指导意义，执行过程中更多的是靠个人根据指导的自由发挥。但是看看我们的基线库更多的是这样指导意义的用例。（但是输入数据又涉及到了维护的问题，以及环境或者业务发生变更后引起的有效性问题）。对于预期的结果不能仅仅是页面上或者界面上的可见结果，如果和数据库发生了交互，必须包含数据库里准确的验证结果。用例基于数据驱动。

    （测试用例的可理解性）测试用例步骤必须描述清晰，不能出现模棱两可以及重复的话语，测试用例应该按照增删改的顺序进行安排，这样执行的时候效率比较高，避免不必要的重复测试，用例写完不是就ok了，我们最好通读2遍，进行修改，让单条用例流畅。

    （测试用例的清晰性）测试用例的验证点必须明确清晰重点突出，按照最新的用例标准，一个用例进行一个功能点的验证，一个萝卜一个坑。对于流程性的用例也是建议按照流程顺序进行用例安排，从第一个验证点到最后一个验证点，组成流程的开始到结束，方便测试执行。测试用例包含前置条件的必须将前置条件描述清楚，包括入口等。

   （测试用例的可维护性）我们的用例主要是基于web的，用例存在一定的变数。

因此在测试用例因为业务需求发生变更的时候，请及时修改，维护测试用例，做到测试用例的实时性与有效性，同时也方便后来的新人同学及时学习，不会产生误解与费解

二、如何规范公司的测试流程

不管是不是刚组建的测试团队，流程大概分为如下。

1、梳理测试流程，可以重点把关的测试流程有：

需求Review：策划完成的需求文档必须让开发、测试、运营进行Review，提出Review意见并最终改掉。这种Review能发现需求的漏洞并提早改掉，提高整个研发过程的效率。

测试用例Review：测试人员针对需求写出粗略的用例点之后，再让策划、开发、测试、运营Review一遍，目的还是发现需求的遗漏点，根据我们的经验，由于测试人员已经思考了测试点，所以相当于是对需求的细化和剖析，这个Review环节还是能发现很多需求的漏洞。

开发提测：测试人员事先发出冒烟测试用例，开发完成后，让开发人员先根据冒烟用例进行自测，自测通过了以后才提交给测试，然后测试再根据相同的用例做冒烟测试。这样能提高开发提测的质量。

上线前报告：上线以前，需要让测试人员发一封报告，重点指出测试过程中发现的问题、及上线以后可能会出的质量问题，并在项目群里面、或者召集开会把这些风险一一沟通过。如果有因为时间不足、或者因为客观条件限制导致的测试不足的情况，一定要在这个环节进行说明，这样，如果上线以后出问题了，大家也能理解测试。

线上Bug Review：对于线上发现的Bug，如果没有分析流程，测试人员需要制定线上Bug的分析流程，先重点分析这个线上Bug产生的原因、线上Bug的影响范围，然后大家一起决定可以有哪些改进措施可以避免同类线上Bug再犯。这种改进措施需要能真正落实的，如果是可有可无的改进措施，就不要提了。这个措施可以让大家一起剖析线上Bug的产生原因，一方面可以避免项目组认为都是测试的错导致线上Bug，一方面，也发挥了测试人员质量保证的角色，推动流程让质量更好。

2、确定测试技术可以提升的点：

环境部署：如果有技术积累，可以把测试环境的部署拿来让测试来做，这样测试人员可以自己控制测试的版本和配置。也提高测试人员的工作范围。

性能测试：如果是流量很大的产品，需要专业的服务端性能测试人员来进行性能测试，对于测试的专业性提升有很大的价值。

专项测试：如果是APP产品，需要让技术比较好的同学来探索专项的测试，把APP端的性能、流量、电量等体验提升上去。

大家可以自己先评估需要引入上述哪些流程，然后，就是沟通、沟通、再沟通。所谓新官上任三把火，第一把火就是要把现有的情况先摸清楚。跟自己的组员沟通、跟项目的开发负责人、产品负责人沟通、跟自己的老大沟通。清楚他们希望我们重点改进的点，同时也把我们想要推的流程、理念传递出去。

在推流程的时候，建议尽量不要把自己站在产品的对立面，而是要跟产品站在同一边，以产品的质量、开发效率等出发点来进行流程的推广。大家相处愉快，整个团队齐心协力，这才是老大愿意看到的局面。根据我的经验，其实不管是开发负责人还是老大，还是比较愿意尊重我们的职业经验，只要我们真正站在产品的角度去沟通，大多数人还是愿意配合的