如何编写测试用例，梳理测试用例思路

作为测试工程师，写用例时候的目标是要保证系统在各种应用场景下的功能是符合设计要求的，所以需要考虑的测试用例就需要更多、更全面。

"以“用户登录”为例，梳理测试用例编写思维")以“用户登录”为例，梳理测试用例编写思维

单纯的以”用户登录”作为测试对象，梳理一下测试用例的编写，用户在操作界面上用户登陆操作无非，三个步骤

• 输入用户名
• 输入密码
• 点击”确认”按钮

这是一个最基本、最典型的测试用例，围绕这个测试的对象，应该如何设计测试用例？

作为测试工程师，写用例时候的目标是要保证系统在各种应用场景下的功能是符合设计要求的，所以需要考虑的测试用例就需要更多、更全面。在不考虑其他情况下，简而言之就是覆盖率要高。

一般用最常用、最典型、也是最重要的黑盒测试方法，也就是等价类划分和边界值分析法来设计一系列的测试用例。
简单介绍一下等价类划分和边界值分析法

等价类划分方法：是将所有可能的输入数据划分成若干个子集，在每个子集中，如果任意一个输入数据对于揭露程序中潜在错误都具有同等效果，那么这样的子集就构成了一个等价类。后续只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。

边界值分析方法：是选取输入、输出的边界值进行测试。因为通常大量的软件错误是发生在输入或输出范围的边界上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。

从方法论上可以看出来，边界值分析是对等价类划分的补充，所以这两种测试方法经常结合起来使用。

针对”用户登录”功能，基于等价类划分和边界值分析方法，

设计的测试用例包括：

1. 入已注册的用户名和正确的密码，验证是否登录成功；
2. 输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确；
3. 输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确；
4. 用户名和密码两者都为空，验证是否登录失败，并且提示信息正确；
5. 用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确；
6. 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，验证是否登录成功；
7. 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登录失败，并且提示信息正确；

看起来似乎这些测试用例已经基本完整的覆盖了”用户登录”这个功能要测试的功能点。

仔细思考一下这些测试用例还需要扩充。

有经验的测试工程师会再增加的测试用例：

1. 用户名和密码是否大小写敏感；
2. 页面上的密码框是否加密显示；
3. 后台系统创建的用户第一次登录成功时，是否提示修改密码；
4. 忘记用户名和忘记密码的功能是否可用；
5. 前端页面是否根据设计要求限制用户名和密码长度；
6. 如果登录功能需要验证码，点击验证码图片是否可以更换验证码，更换后的验证码是否可用；
7. 刷新页面是否会刷新验证码；
8. 如果验证码具有时效性，需要分别验证时效内和时效外验证码的有效性；
9. 用户登录成功但是会话超时后，继续操作是否会重定向到用户登录界面；
10. 不同级别的用户，比如管理员用户和普通用户；登录系统后的权限是否正确；
11. 页面默认焦点是否定位在用户名的输入框中；
12. 快捷键 Tab 和 Enter 等，是否可以正常使用；

改进后的测试用例集相比之前的测试覆盖率的确已经提高了很多。

但是我们发现上面所有的测试用例设计都是围绕显式功能性需求的验证展开的，这些用例都是直接针对”用户登录”功能的功能性进行验证和测试的。

但一个质量过硬的软件系统，除了显式功能性需求以外，隐式功能性需求也是极其关键的。
先介绍下这两个概念：

显式功能性需求（Functionalrequirement）：
指的是软件本身需要实现的具体功能， 比如”正常用户使用正确的用户名和密码可以成功登录”、”非注册用户无法登录”等，这都是属于典型的显式功能性需求描述。

非功能性需求（Non-functionalrequirement）：
从软件测试的维度来看，非功能性需求主要涉及安全性、性能以及兼容性三大方面。 在上面所有的测试用例设计中，我们完全没有考虑对非功能性需求的测试，但这些往往是决定软件质量的关键因素。

了解了非功能性需求测试的重要性后，我们又可以设计一系列的测试用例；

安全性测试用例包括：

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

性能压力测试用例包括:

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

兼容性测试用例包括：

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

合理需求和用户场景

当然除了基于等价类，边界值的分析，还要基于场景的组合，等价类边界值就像类似于公式的一种科学工具，可以直接套用；

而在使用场景方法时需要的是对业务以及实现该业务的过程和技术的掌握深度和广度，是属于一种经验的积累达成的测试手段。

鉴于此我们还要考虑

需求合理性测试：
当时需求的场景是什么？
这样设计是否符合用户的使用需求？
……

用户场景测试：
用户在哪几种情况下才会看到这个界面？
那个场景的前后流转过程是否顺畅？
设计是否合理？
……

第三方登录：（现在很多人喜欢用微信等等第三方登录）

1. 是否支持第三方登录；
2. 第三方登陆方式，是扫码还是输入账号和密码；
3. 第三方登陆后是否还要重新绑定手机邮箱等其他方式；
4. 第三方第一次登陆是否要设置密码；
5. 三方登录修改密码的影响(解绑后是否能正常登录，和退登)

登录失败后二次登录（主要针对app）

1. 输入正确的用户名，不输入密码，点击登录；登录失败后，再次输入正确的密码登录并观察登录情况；
2. 输入正确的用户名和错误的密码登录失败后，登陆失败，再次输入正确的密码登录并观察登录情况；
3. 输入正确的用户名和错误的密码登录失败后，再次输入正确的密码登录并观察登录情况；
4. 输入未注册的用户和任意密码登录失败后，再次输入正确的用户名和密码，观察登录情况；

对于组合，还有比如验证码第一次失败后，第二次登陆，一天获取验证码的数量等等，对于有这个方面需求考虑的项目，一定要测试。

注册后第一次登陆修改密码，以及修改密码，输入密码次数问题

1. 第一次登陆是否要重新设置密码；
2. 系统原始密码/临时密码为ABC，成功登入更改新密码之后，原始密码是否依然有效；
3. 系统原始密码/临时密码为ABC，如果更新的新密码依然为ABC，此时，是否提示更新成功，或者根据设计提示用户新密码不能与原始/临时密码相同。
4. 修改完密码后是否重定向到登录界面；
5. 修改完密码后，分别使用原密码和新密码登录；
6. 在其他终端修改密码后，本终端是否自动下线；
7. 下线后，使用原密码能否继续登录；
8. 退出登录是否有记住账号或记住密码功能；
9. 密码输入错误是否有最大次数限制？分别测试最大值-1、最大值、最大值+1时的输错密码情况；
10. 超过最大次数限制后，是否采取强制手段限制登录或对账号暂时冻结处理；
11. 超过最大次数限制后，分别输入正确的密码和错误的密码再次登录；

输入密码的一些测试点（密码是一个系统非常重要的部分）

1. 使用中文键盘输入字母时和使用英文键盘输入字母时传给后端的字符长度是否一致；
2. 密码是否有明码暗码的设置按钮，以及是都显示密码；
3. 输入栏是否有快速删除按钮
4. 是否允许第三方存储密码，存储的期限是多少；

一些特殊的软件和系统必须的要测试项

1. 输入密码是否是否需要安全键盘、安全控件（金融软件）；
2. 本终端用户已经登陆，在其他终端尝试登陆，是否有提示
3. 异地登陆是否有提示（金融软件非常重要）
4. 本地第一次登陆，数据是否同步，刷新头像等
5. 本地切换用户，是否新建文件夹等等
6. ios、安卓、网页等等是否有互踢机制
7. 更换设备是否需要校验
8. 浏览器登陆页面，再打开本网站一个网页，用户信息是否同步；
9. 浏览器登陆网页，地址被复制粘贴后，在其他终端是否不需要密码可以直接登陆；
10. 被停用用户登陆
11. 未激活用户登陆，后台数据库是否有i记录
12. 付费用户，会员等，到期后，是否有续费页面弹出，是否能正常登陆；
13. 浏览器关掉，多长时间没再次打开，不用重新输入密码
14. 一个ip地址支持同时等级几台设备
15. 是否有时间段登陆，比如1点到5点不能登陆
16. 在时间段内，用户没有下线，是否强制下线。（游戏）
17. 为空检测检测空格键对登陆的
18. 无网络模式下登录，是否给出”网络未连接”或”网络异常”的提示及提示是否正确；
19. 第一次登录请求超时后（服务器出问题，随后恢复正常），再次请求登录能否登录成功；
20. 第一次无网络情况下登录失败后，再次连接网络并登录；
21. 正在登录过程中，遇到网络切换，如（4G切换到WiFi环境时）能否正常登录；
22. 已登录的用户，杀死APP进程后，再次打开APP是否依然为已登录状态；
23. 若支持手机号+验证码登录，验证码是否有时间限制？移动端设备是否可以直接获取验证码？
24. 断开网络链接，输入正确的账号密码，点登录是否有网络提示？
25. 用户名或密码输入错误后是否有次数限制，登陆多次错误后是否会提醒多久才能再次操作

“用户登录”功能的测试，一个看似简单的功能测试，居然涵盖了如此多的测试用例，除了要覆盖明确的功能性需求，还需要考虑其他诸多的非功能性需求。

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

通过”用户登录”功能测试这个实例，可以激发我们对测试更多的思考，也可以开拓设计测试用例的思路。

看完了这些测试用例，你可能会说还有一些遗漏的测试点没有覆盖到，这个功能的测试点还不够
全面。那么，接下来我再跟你说说测试的不可穷尽性，即绝大多数情况下，是不可能进行穷尽测

“穷尽测试”：指包含了软件输入值和前提条件所有可能组合的测试方法，完成穷尽测试的系统里应该不残留任何未知的软件缺陷。 因为如果有未知的软件缺陷，你可以通过做更多的测试来找到它们，也就是说你的测试还没有穷尽。

但是，在绝大多数的软件工程实践中，测试由于受限于时间成本和经济成本，是不可能去穷尽所有可能的组合的，而是采用基于风险驱动的模式，有所侧重地选择测试范围和设计测试用例，以寻求缺陷风险和研发成本之间的平衡。

总结

• 首先，对于高质量的软件测试，用例设计不仅需要考虑明确的显式功能性需求，还要涉及兼容
  性、安全性和性能等一系列的非功能性需求，这些非功能性需求对软件系统的质量有着举足轻重
  的作用。

• 其次，优秀的测试工程师必须具有宽广的知识面，才能设计出有针对性、更易于发现问题的测试用例。

• 最后，软件测试的用例设计是不可穷尽的，工程实践中难免受制于时间成本和经济成本，所以优秀的测试工程师需要兼顾缺陷风险和研发成本之间的平衡。