测试用例设计方法 与 什么是“好的”测试用例

一、如何设计测试用例

1、测试用例设计方法

      等价类划分法、如等价类划分法、边界值分析法、错误推测方法、因果图方法、判定表驱动分析法、正交实验设计方法、功能图分析方法、场景设计方法、形式化方法、扩展有限状态机方法.....

2、测试用例范围：

      包括功能性（产品需求）和非功能性，非功能性包括：安全性，兼容性，性能，用户体验度（对产品业务的理解，站在用户角度审视需求的合理性，覆盖各种显性隐性非功能的需求）

3、测试用例举例：就用户登录设计一个测试用例

      功能测试：

1. 用户名和密码是否大小写敏感，是否支持特殊字符；
2. 页面上的密码框是否加密显示，密码强弱校验，密码输入最大次数；
3. 后台系统创建的用户第一次登录成功时，是否提示修改密码；
4. 忘记用户名和忘记密码的功能是否可用；
5. 前端页面是否根据设计要求限制用户名和密码长度；
6. 如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用；
7. 刷新页面是否会刷新验证码；
8. 如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
9. 用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；
10. 不同级别的用户，比如管理员用户和普通用户，登录系统后的权限是否正确；
11. 页面默认焦点是否定位在用户名的输入框中；
12. 快捷键Tab 和Enter等，是否可以正常使用。
13. 数据库设计和数据库实操时候是否合理。
14‘网络延迟或者弱网或者切换网络或者断网时正常登录是否正常
15.是否支持第三方登录
16.记住密码是否有有效期，有有效期，过期之后是否会清空密码
17.是否可以使用登录的API发送登录请求，并绕开验证码校验
18.是否可以用抓包工具抓到的请求包直接登录
19. 截取到的token等信息，是否可以在其他终端上直接使用，绕开登录。token过期时间校验
20.除了前端校验格式长度等，后端是否也校验？
21. 登录后输入登录URL，是否还能再次登录？如果能，原登录用户是否变得无效
22. 登录错误后的提示是否有安全隐患

     安全性测试：

1. 用户密码后台存储是否加密；
2. 用户密码在网络传输过程中是否加密；
3. 密码是否具有有效期，密码有效期到期后，是否提示需要修改密码；
4. 不登录的情况下，在浏览器中直接输入登录后的URL地址，验证是否会重新定向到用户登录界面；
5. 密码输入框是否不支持复制和粘贴；
6. 密码输入框内输入的密码是否都可以在页面源码模式下被查看；
7. 用户名和密码的输入框中分别输入典型的“SQL注入攻击”字符串，验证系统的返回页面；
8. 用户名和密码的输入框中分别输入典型的“XSS跨站脚本攻击”字符串，验证系统行为是否被篡改；
9. 连续多次登录失败情况下，系统是否会阻止后续的尝试以应对暴力破解；
10. 同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；
11. 同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。

    兼容性测试：

1. 不同浏览器下，验证登录页面的显示以及功能正确性；
2. 相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
3. 不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
4. 不同分辨率的界面下，验证登录页面的显示以及功能正确性。

    性能测试：

1. 单用户登录的响应时间是否小于3秒；
2. 单用户登录时，后台请求数量是否过多；
3. 高并发场景下用户登录的响应时间是否小于5秒；
4. 高并发场景下服务端的监控指标是否符合预期；
5. 高集合点并发场景下，是否存在资源死锁和不合理的资源等待；
6. 长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。

4、总结

       看完了这些测试用例，你可能会说还有一些遗漏的测试点没有覆盖到，这个功能的测试点还不够全面。 测试是不可穷尽性的，在测试实践中，由于受限于时间成本和经济成本，是不可能去穷尽所有可能的组合，而是采用基于风险驱动的模式，有侧重的选择测试范围和设计测试用例，以寻求缺陷风险和研发成本之前的平衡。

 

      一个优秀的测试工程师必须具有很宽广的知识面，如果你不能对被测系统的设计有很深入的理解，不明白安全攻击的基本原理，没有掌握性能测试的基本设计方法，很难设计出“有的放矢”的测试用例。

 

二、什么是“好的“测试用例

1、  “好的”测试用例是一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷是没有关系的。

        举个例子： 就拿“池塘捕鱼”的例子，可以帮你更好地理解什么是“好的”测试用例。

                如果把被测试软件看作一个池塘，软件缺陷是池塘中的鱼，建立测试用例集的过程就像是在编织一张捕渔网。“好的”测试          用例集就是一张能够覆盖整个池塘的大渔网，只要池塘里有鱼，这个大渔网就一定能把鱼给捞上来。如果渔网本身是完整的且          合格的，那么捞不到鱼，就证明池塘中没有鱼，而渔网的好坏与池塘中是否有鱼无关。

2、一个“好的”测试用例，必须具备以下三个特征。

          1. 整体完备性： “好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。

          2. 等价类划分的准确性： 指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也 一定测试通过。

          3. 等价类集合的完备性： 需要保证所有可能的边界值和边界条件都已经正确识别

 

3、对“好的”测试用例补充

     在具体的用例设计时，首先需要搞清楚每一个行业需求所对应的多个软件功能需求点，然后分析出每个软件功能需求对应点的多个测试需求点，最后再正对每个需求点设计测试用例。

          1. 只有深入理解被测试软件的架构，你才能设计出“有的放矢”的测试用例集，去发现系统边界以及

          系统集成上的潜在缺陷。

                  作为测试工程师，切忌不能把整个被测系统看作一个大黑盒，你必须对内部的架构有清楚的认识，比如数据库连接方                 式、数据库的读写分离、消息中间件Kafka的配置、缓存系统的层级分布、第三 方系统的集成等等。

          2. 必须深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑。

                  单单根据测试需求点设计的用例，只能覆盖“表面”的一层，往往会覆盖不到内部的处理流程、分支处理，而没有覆盖到              的部分就很可能出现缺陷遗漏。在具体实践中，你可以通过代码覆盖率指标找出可能的测试遗漏点。同时，切忌不要以开发              代码的实现为依据设计测试用例。因为开发代码实现的错误会导致测试用例也出错，所以你应该根据原始需求设计测试用                例。

          3. 需要引入需求覆盖率和代码覆盖率来衡量测试执行的完备性，并以此为依据来找出遗漏的测试点。

                  关于什么是需求覆盖率和代码覆盖率，我会在后续的文章中详细介绍。

          4. 测试人员应该是比产品和开发、更了解用户使用习惯的

                   例如一些UI交互设计、push 短信发送节点、banner按钮位置、不同客户端的手势快捷操作习惯等

          5. 测试不仅不能依赖开发也不能过分依赖产品 

                  测试人员应该是对全线产品逻辑细节最熟知的，需求设计的业务漏洞也需要测试来把控，所以需求评审的过程中测试

          人员就应该能凭经验构思出初步的测试策略并推测出常见错误予以提醒避免开发阶段浪费时间。再次测试用例的后期归档整              理也属于测试人员需要注意的事项，系统科学的整理用例有利于后期的阶段性

          回归测试，可以减少在编写测试用例上浪费不必要的时间。