这样做，让你的测试用例覆盖性最强！

转载：http://www.51testing.com/html/34/n-3725634.html​

​对专业的测试人员来说，编写测试用例并不陌生，但是如何编写覆盖性强的测试用例，就需要我们再三思考后落笔哦~

首先我们来想下测试用例的前世今生：

1.测试用例因何产生？

2.测试用例为谁而写？

这两个问题我们各用一句话来回答：测试用例是产品原型下的衍生物，为想要了解这个系统（需求）的人而写，且随着产品原型的调整及时更新。

了解一个系统更多时候不是从已经使用的案例中抽取其中之一作为了解对象，而是从需求原型中，梳理分析，整合成测试用例来帮助用户去理解。而一个覆盖性强的测试用例，可以保障系统的强健性。

​

从大的方面讲，测试用例分为功能测试、非功能测试两个方面；

增删改查是基础，也是重中之重。这一点不仅我们测试人员重视，研发也同样了解，因此在提测之前，增删改查的部分大多数情况下已经由研发人员验证过一次。若非如此，测试人员还是有权力拒测或执行一键驳回的，直到醒目达到最基本的提测状态。

GUI页面检查以及元素验证。这类验证几乎在我们的日常工作中均有涉及，从设备来讲PC项目，移动端（Android，IOS）；从系统应用来说，办公系统，娱乐网站，直播平台，交易系统等等，均离不开用户与系统之间的交互。可以说，GUI部分的验证占据了测试人员大量的工作时长，所以我们回顾罗列的测试用例，大范围陈述了页面元素的验证：字符限长，非法验证，非空校验，提示语，二次弹窗，非空集合等等。这部分工作繁琐冗长，往往是研发人员忽视的部分，稍有不慎就会引发问题，需要测试人员从不同角度多次验证。

数据准确性。我们在验证数据准确性的时候，更多侧重于已经产生的数据，在数据的生命周期中验证其准确性，往往忽视了数据的初始化及消亡两个极端。以往我测试过一个WEB系统，测试数据是由研发人员导入的线上数据，但是在测试过程中，发现这批线上测试数据的生命周期并没有异常，反而是我自己通过系统导入的初始数据，在接下来的页面交互中出现不少问题。这就涉及到了前端如何处理初始数据的问题，假如自己同样忽视数据的产生，上线后，就是引发测试事故的重要漏洞。

业务逻辑的正确性。这个问题往往是产品原型产生初期就被遗漏的问题，带来的后果是用户体验度差。举个例子，用户通过手持端进入领取优惠页面，一系列验证用户操作完毕后，提示领取成功。现在，作为一个用户，大多数情况下应该会找使用优惠券的入口，或者去查看这个优惠券如何使用。然并卵，产品经理忽视了最终的体验对象，只是将用户领取优惠完成来当做这一动作的终结。所以说，测试不仅仅是去验证产品原型，还要考虑业务逻辑是否正常。

　后端的特殊验证。这类测试多出现在前端UI界面简易，后端判断复杂。例如，文档的上传下载，上传一批手机号到服务器，实现发送短信的目的。给出几个错误验证的例子，一，导入Excel文件中，同一个手机号连续输入两次，查看发送短信条数（此部分验证的是短信攻击性）；二，导入Excel文件中，同一个手机号不连续输入多次，查看发送短信条数（此部分验证的是数据去重性）。

业务关联性。例如数据变更等信息同步问题时，有关联的业务之间产生联系，会出现此类验证。举个例子，ES数据实现同步功能，在首批数据导入后，不同业务之间共享同一批数据，当某一条数据进入生命周期时，此时不仅要观察当前数据库中的数据变化，还要观察使用ES技术同步后的数据是否一致。

　并发操作。此类问题的产生情景在较多用户共享同一批数据，且同时对此数据进行同一功能操作下产生的问题。此类问题需要测试人员使用两个浏览器即可完成问题复现，左右各开一个显示器，同时对一个数据进行编辑后的提交，查看界面反馈。

以上罗列的功能测试点和处理的例子尚有不完整之处，在此不再多做赘述。功能测试过程中，上述常见测试要点，酌情参考，每个测试需求不同，不能统一照搬，在原有经验的基础上，更进测试方法，达到测试目的。

此外，除了功能测试还有非功能测试需要在梳理测试用例时覆盖到。

　浏览器兼容。目前市场上广泛使用的浏览器较多，Firefox，Chrome，IE，UC，猎豹，Opera等等，在测试过程中，摘选主要2-3个应用广泛的作为重点测试对象，其次，酌情考虑项目参与人员的意见，如研发或产品人员，并入测试范围。

　压力。目前各个公司有自己的压力测试平台，考虑当前项目的使用人数后酌情进行压力测试。

　接口。更多时候是在界面上不能完成增删改查操作时，使用手动接口测试，查看返回值。

　安全和风险。这个也要看所测试的项目需要关注此类问题。

此外，测试用例评审，测试用例更新完善等环节也是对测试用例的查漏补缺。

覆盖性强的测试用例是需要我们针对项目具体制定的测试用例，以上所梳理的测试点，是在大多数工作中需要考虑的方面，总而言之，言而总之，测试用例不能照搬照抄，可以参考不同测试用例的思考点，以这种思考的方式来当做当前项目的切入点，达到测试目的：发现程序的错误。