本文以最常见的几种测试场景来展开讨论如何设计出更为高效且覆盖面更为全的测试用例。

在讨论前，我们先来大概了解下目前行业里常用到的几种测试用例的设计方法，目前主流的测试用例设计方法有如下几种

1、测试用例常用设计方法

1.1 等价类划分法

此设计方法算是黑盒测试中用得最多的一个了，而且此方法常常与其他方法一起来设计测试用例，常用的组合就是与边界值划分法；

定义：等价类划分法是把所有可能输入的数据划分成若干部分，然后从每一个部分选取少数具有代表性的数据作为测试用例。

划分标准：

1. 完整性，即被划分的各个部分测试数据共同组成了所有可能输入的数据；

2. 排他性，即每个部分的测试数据原则上来说，不应该有重叠部分。

划分方法：

1. 在输入条件规定了取值范围或值的个数的情况下，则可以划分为一个有效等价类和二个无效等价类；

2. 在输入条件规定了输入值的集合或规定了必须如何的条件下，则可划分为一个有效等价类和一个无效等价类；

3. 在输入条件是一个布尔量的情况下，可划分为一个有效等价类和一个无效等价类；

4. 在规定了输入数据必须遵守的规则情况下，可划分为一个有效等价类和若干个无效等价类（从不同角度违反规则）；

5. 在规定了输入数据为一组值，每个值分别处理不同情况，则可确定n个有效等价类和一个无效等价类；

6. 假如在已经确认已划分的等价类中各元素在程序处理中的方式不同情况下，则需将该等价类进一步的划分为更小的等价类。

1.2 边界值分析法

此方法根据也是特别常用的一种设计方法了，写过代码或者有丰富测试经验的同学应该知道，代码中的判断逻辑是非常多的，越是复杂的业务流程，判断逻辑就越多。就算有丰富经验的开发者，在进行判断逻辑代码的时候也会有所疏忽，尤其是哪些欠缺开发经验的同学来说，就更容易忽略某些边界问题了。

定义：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

分析：大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

1.3 场景分析法（流程图法）

随着系统功能越来越多，业务越来越复杂，这时候为了更好的进行测试，确保所有业务流程都能被覆盖测试到，这时候引入场景分析法就非常有必要了。

定义：现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。

1.4 经验推断法

随着测试人员对系统的不断熟悉，对业务的理解不断加深，对程序员的不断了解，有时候就可以有针对性的去验证是否存在某个问题。

1.5 因果图法

等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。

如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

定义：因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

其他几种方法不常用，就不介绍了，如有需要再去学习了解即可。

2、设计思路概况

上面我们大概了解了下各个测试用例设计方法，接下来就开始以实际例子来说明如何更高效的设计测试用例了。

2.1 web登录页面的测试

分析：首先我们可以分析一下，该界面都有哪些哪些元素，每个元素又具备哪些规则要求，是否有其他特殊化要求，比如缓存，加密等；分析完毕后，我们就可以根据了解到的去选择合适的测试用例设计方法，对这个页面进行用例的编写。

2.1.0 UI界面测试

首先对于用户来说，对一个系统的评价，首先从界面视觉方面去判断，就好比男女之间的第一次见面，嗯，你想的没错，就是相亲，第一印象基本上是从个人长相，精神面貌来的，我们都知道第一印象很重要，尤其是在如今这个快节奏的社会；

对于一个用户来说，界面的风格，人机交互性，易理解性，易操作性等将直接印象用户的第一使用体验，假如第一使用体验都不好了的话，假如该产品不是不可替代性的产品的话，用户很有可能就此流失掉，假如该系统是用户已经付费了的，虽然不好看的页面，难于操作的页面，难于理解的页面不会马上导致客户退货，但起码会使该用户产生一种一点都不专业的感觉，接下来用户很可能带着一种不愉快的心情去操作了，这就很有可能导致各种各样的刁难挑刺，最终导致彻底对该产品失去兴趣，要不就是打回要求重新调整，要不就是退回退款。

大部分产品开发过程中，在前期需求确定及评审过程中就会这方面进行一定讨论研究，所以建议测试同学在需求阶段就要介入进去，从界面风格，人机交互性，易理解性，易操作性等几方面去进行审视，给出比较不错的建议。

根据一般的测试套路，我们先是进行基本的功能测试，只有基本的功能实现了，我们才有意义去进行其他方面的测试。

备注：扫一扫登录页面由于过于简单就不在此进行阐释了

2.1.1 功能测试

结合我们所掌握到该页面的相关需求知识以及我们后期拓展到的隐性需求（最好在需求阶段就提出来），提炼出我们所需要的测试点，然后再结合我们所掌握的测试用例设计方法进行测试用例的编写。

以下就是提炼出的测试点：

• 输入框的空值登录；

• 输入框的空格测试；

1. 账号密码输入框前后中间有空格是否有过滤处理处理；

2. 有效账号密码等信息登录；

3. 无效账号密码信息登录。

• 正确账号，错误密码；

• 不存在的账号，A账号的密码；

• A账号，B账号的密码；

• 密码特殊要求测试。

1. 在输入框内是否密文展示；

2. 是否可从外部复制到输入框；

3. 是否可从密码输入框复制密码出去；

4. 密码防破解机制验证；

5. 密码在传输过程中及日志信息中是否做了加密处理；

6. 密码在数据库表中是否以加密形式保存；

7. 密码信息是否会被浏览器所记住并保存。

• 验证码测试

1. 输入正确的验证码登录；

2. 验证码输入框置空登录；

3. 输入错误的验证码登录；

4. 输入过时的验证码登录；

5. 图片刷新机制是否合理。

• 账号密码记忆保存测试

1. 正确账号密码登录成功后记忆保存；

2. 正确账号错误密码登录失败后是否只保存账号信息；

3. 错误账号登录错误密码登录失败是否会保存；

4. 正确账号，密码置空登录，是否会保存账号信息；

5. 记忆保存有效时间验证；

6. 手动清除缓存是是否仍然保留登录信息。

• 同时登录测试

1. 一个账号能否在同一浏览器上同时登录；

2. 一个账号能否在同一台机器上不同浏览器同时登录；

3. 一个账号能否在不同机器上同时登录；

4. 一个账号能否在web端和移动app端同时登录；

5. 二个账号能否在同一浏览器上同时登录；

6. 二个账号能否在同一台机器上不同浏览器同时登录。

• 默认语言的记忆测试

1. 修改界面语言选项，成功登陆后，下次登录是否会记忆上次保存的语言；

2. 修改界面语言选项，登录失败后，当前页面是否会保存修改的语言；

3. 修改界面语言选项，登录失败后，关闭浏览器，下次打开登录是否保存上次的语言选项。

• 输入框长度限制测试；

• 输入框可输入类型测试；

• 输入框的大小写是否敏感。

2.1.2 友好及易操作性测试

1. 在输入框内能否使用windows常用快捷键，比如复制粘贴，tab切换，回车等；

2. 在输入框内能否切换大小写，输入法，且切换后是否有相应提示；

3. 网络异常时，是否有友好加载页面提示；

4. 各种登录失败情况下的提示是否友好，清晰，易懂。

2.1.3 健壮性测试

1. 对浏览器程序进程杀死，重新打开浏览器，已输入的登录信息是否还在；

2. 登录页面与其他页面页签之间的切换以及缩小到后台，已输入的登录信息是否还在；

3. 假如快速多次点击登录按钮界面是否仍然正常显示及提示；

4. 假如快速进行多次刷新操作，界面是否仍然显。

2.1.4 安全测试

1. 账号密码框是否屏蔽SQL注入攻击；

2. 账号密码输入框是否禁止脚本输入（避免XSS攻击）；

3. 登录是否有防破解机制；

4. 密码的缓存信息是保存在cookies中还是session中；

5. 密码在任何场所是否都是加密形式展示的；

6. 密码是否具有有效期，有效期到快到或者到期后，是否需要提示修改密码；

7. 不登录的情况下，直接输入登陆后的url访问，重定向到用户登录页面；

8. 密码输入框是否支持复制粘贴；

9. 密码输入框输入的密码是否可以在页面源码模式下被查看；

10. 同一用户在同一终端的多种浏览器上登录，验证登录功能的互斥性是否符合设计预期；

11. 同一用户先后在多台终端的浏览器上登录，验证登录是否具有互斥性。

2.1.5 性能测试

1. 单用户打开登录页面及登录所花的时间是否满足要求；

2. 点击登录按钮进入到登录成功后的页面所花时间是否满足要求；

3. 支持多少人同时正常打开，同时正常登录操作；

4. 单用户登录时，后台请求数量是否过多；

5. 高并发场景下用户登录的响应时间是否小于规定值；

6. 高并发场景下服务端的监控指标是否符合预期；

7. 高集合点并发场景下，是否存在资源死锁和不合理的资源等待；

8. 长时间大量用户连续登录和登出，服务器端是否存在内存泄漏。

2.1.6 兼容性测试

1. 主流的浏览器及各版本，是否很好的兼容该页面；

2. 不同的操作平台及各版本是否正常使用；

3. 不同屏幕分配率是否合理的显示该页面；

4. 放大缩小状态下界面显示是否正常。

2.2 一个水杯的测试（以喝水的杯子为准）

以此例子来说明，一般我们的测试思路可以怎么展开，其实和上个例子一样的思路，再举例说下这个例子，是用来说明作为测试同学来说，具备很强的逻辑归纳能力，很强的发散思维能力，及很强的产品用户思维能力是很重要的。

2.2.1 UI界面测试

1. 整体形状外观是否符合用户审美观；

2. 杯身图案是否符合用户需求，是否涉及到民族，伦理道德，商业侵权等会引起纠纷的标识。

2.2.2 功能测试

1. 能否正常装水；

2. 能否正常喝水。

2.2.3 易用性测试

1. 杯子是否容易装水；

2. 杯子是否容易出水；

3. 杯子是否很方便的拿放（体积质量是否合理）。

2.2.4 健壮性测试

1. 当水装过满的时候，是否有预防水漫出的机制；

2. 当水喝的几乎没有的时候，剩下的一点点水是否能够顺利的喝到；

3. 当水杯不小心打翻时候，是否很好的避免水流出；

4. 当用户手湿滑时候，是否也能够顺利拿起放下杯子。

2.2.5 安全测试

1. 制作杯子的材料是否会对用户造成损害；

2. 当杯子不小心打碎的时候，碎片是否会伤害到用户；

3. 当装的水过热或者过冷的时候，是否会对用户造成伤害；

4. 当杯子由于外部原因被加热过或者被冰冻过，是否会对用户造成伤害；

5. 当杯子长时间装水状态下，是否会滋生细菌或产生危害到用户的事务；

6. 当杯口以及杯身出现裂痕的时候，是否会对用户造成割伤；

7. 当杯子放进微波炉时，杯子是否会发生爆炸或融化。

2.2.6 性能测试

1. 杯子在长时间震动下是否会破碎；

2. 杯子在长时间装水状态下是否发生漏水；

3. 当用户使用杯子时用力过猛情况下，杯子是否会破碎；

4. 当杯子不小心摔下的时候，是否会发生破碎变形现象；

5. 当杯子装入过热或过冷的水时，杯子是否会发生破裂等事故；

6. 当杯子用久了，杯身是否会掉色，杯体是否会发生变形，褪色等。

2.2.7 兼容性测试

1. 杯子除了装水外，是否还能装其他液体；

2. 杯子除了装液体外，是否还能装固体；

3. 杯子是否能液体和固定的混合物；

4. 杯子是否可以在一些特殊场合使用。

作者：꧁北拧陌寒꧂

原文链接：https://www.cnblogs.com/Aaron-007/p/10697277.html