这样做是为了让您的测试用例最容易被覆盖！

这样做是为了让您的测试用例最容易被覆盖！:转载：http://www.51testing.com/html/34/n-3725634.html对于专业测试人员来说，写测试用例并不陌生，但是如何写一个覆盖测试用例的文章，你需要先把笔放到纸上再考虑哦~首先，让我们想想测试用例的化身：1。是否为生成测试用例？2。测试用例是为谁编写的？我们用一句话回答了所有这些问题：测试用例是产品原型的衍生产品，为那些想了解系统的人编写，并随着产品原型的适应而更新。为了理解一个系统，更重要的是不要提取一个已经被使用的用例作为理解的对象，而是分析需求原型并将其集成到测试用例中，以帮助用户理解。一个覆盖性强的测试用例可以保证系统的鲁棒性。一般来说，测试用例分为功能测试和非功能测试。添加、删除、更改和检查是基础，也是最重要的。这不仅被我们的测试人员强调，而且被研究和开发人员理解。因此，在测试之前，大部分添加、删除和检查的部件都经过了研发人员的验证。否则，测试人员有权拒绝测试或执行一次单击拒绝，直到达到最基本的测试。GUI页面检查和元素验证。这种验证几乎涉及到我们的日常工作中，从设备、PC项目、移动终端（Android、iOS）的角度来看；从系统应用、办公系统、娱乐网站、直播平台、交易系统等方面来说，都离不开用户和系统之间的交互。可以说，GUI部分的验证占用了大量的测试人员的工作时间，因此我们对列出的测试用例进行了回顾，并对页面元素的验证进行了广泛的说明：字符限制、非法验证、非空验证、提示、二次弹出、非空集和等等。这部分工作枯燥乏味，研究开发人员经常忽视。稍有疏忽就会导致问题，需要测试人员从不同的角度进行多次验证。数据准确性。在验证数据的准确性时，我们更关注已生成的数据，并在数据的生命周期中验证其准确性，往往忽略了数据初始化和消亡的两个极端。在过去，我测试了一个Web系统，测试数据是由研发人员导入的。但是，在测试过程中，我发现这批在线测试数据的生命周期并没有异常。相反，它是我通过系统导入的初始数据。这涉及到如何处理前端的初始数据。如果我也忽略了数据的生成，那么在上线之后，这是导致测试事故的一个重要漏洞。业务逻辑的正确性。这个问题在产品原型生产的早期阶段经常被忽视，导致用户体验不佳。例如，用户通过手持端进入优惠报价页面，经过一系列用户操作验证后，成功收到提示。现在，作为一个用户，大多数时候你应该寻找一个入口点来使用优惠券，或者看看优惠券是如何被使用的。但是，它不起作用。产品经理忽略最终用户，只将其作为流程的结束。因此，测试不仅仅是验证原型，还需要考虑业务逻辑是否有效。后端的特殊验证。其中大多数测试在前端UI界面中很简单，在后端判断中很复杂。例如，上传下载文档，向服务器上传一批手机号码，实现短信发送的目的。给出几个错误验证的例子。首先，导入excel文件，连续两次输入同一手机号码，检查发送的短信数量（本部分验证短信攻击性）；其次，导入excel文件，多次输入同一手机号码，检查短屏幕号码（本部分t检验重复数据消除）。业务相关性。当信息同步问题（如数据更改）导致相关业务之间的关联时，就会发生这种验证。例如，ES数据实现了同步功能。导入第一批数据后，不同的业务共享同一批数据。当某个数据进入生命周期时，不仅需要观察当前数据库中的数据变化，还需要观察ES技术同步的数据是否一致。并行操作。当更多的用户共享同一批数据并对数据执行相同的功能操作时，就会出现这种问题。这种问题需要测试人员使用两个浏览器来完成问题的重现，每侧各有一个监视器，编辑后提交一个数据来查看界面反馈。上述功能测试点和处理示例列表不完整，此处不再重复。在功能测试过程中，上述常见的测试点，作为适当的参考，每个测试需要不同的，不能统一复制，在原有经验的基础上，更多地融入到测试方法中，以达到测试的目的。此外，除了功能测试之外，在组合测试用例时还需要覆盖一些非功能测试。浏览器兼容性。目前市场上广泛使用的浏览器有：火狐、Chrome、IE、UC、猎豹、Opera等。在测试过程中，选择了2-3个应用广泛的主要测试对象作为关键测试对象。其次，研究开发或产品人员等项目参与者的意见被认为是适当的，并纳入测试范围。压力。目前，每家公司都有自己的压力测试平台。考虑到当前项目的用户数量，应酌情进行压力测试。接口。更常见的是，在界面上添加、删除、更改、检查等操作不能完成时，使用手工界面对返回值进行测试和检查。安全和风险。这还取决于测试项目中需要解决的问题类型。此外，测试用例评审、测试用例更新和改进也是填补测试用例空白的步骤。测试用例的覆盖范围是我们需要具体的一套测试用例，上面的梳理测试点，在大多数方面都是要考虑的，一般来说，但是，简而言之，测试用例不能复制、思考，你可以用这种方式把不同的测试用例作为思维的突破口。当前项目，测试目的：找出程序的错误。这样做是为了让您的测试用例最容易被覆盖！