52讲笔记

登录测试用例

功能性

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

安全性

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. 不同分辨率的界面下，验证登录页面的显示以及功能正确性。

测试用例常用设计方法

对大多数的软件测试而言，综合使用等价类划分、边界值分析和错误推测这三大类方法就足
够了。

自动化测试

什么项目适合做自动化测试

第一，需求稳定，不会频繁变更。

第二，研发和维护周期长，需要频繁执行回归测试。

第三，需要在多种平台上重复运行相同测试的场景。

• 对于 GUI 测试，同样的测试用例需要在多种不同的浏览器上执行；
• 对于移动端应用测试，同样的测试用例需要在多个不同的 Android 或者 iOS 版本上执行，
或者是同样的测试需要在大量不同的移动终端上执行；
• 对于一些企业级软件，如果对于不同的客户有不同的定制版本，各个定制版本的主体功能绝
大多数是一致的，可能只有个别功能有轻微差别，测试也是需要覆盖每个定制版本的所有测
试；

第四，某些测试项目通过手工测试无法实现，或者手工成本太高。

第五，被测软件的开发较为规范，能够保证系统的可测试性。

第六，测试人员已经具备一定的编程能力。

传统测试工程师师应该具备的核心竞争力

测试策略设计能力、测试用例设计能力、快速学习能力、探索性测试思
维、缺陷分析能力、自动化测试技术和良好的沟通能力。

GUI自动化测试

测试脚本和数据解耦

1. 数据驱动很好地解决了大量重复脚本的问题，实现了“测试脚本和数据的解耦”。
2. 数据驱动测试的数据文件中不仅可以包含测试输入数据，还可以包含测试验证结果数据，甚
   至可以包含测试逻辑分支的控制变量。
3. 数据驱动测试的思想不仅适用于 GUI 测试，还可以用于 API 测试、接口测试、单元测试
   等。 所以，很多 API 测试工具（比如 SoapUI），以及单元测试框架都支持数据驱动测试，
   它们往往都是通过 Test Data Provider 模块将外部测试数据源逐条“喂”给测试脚本。

五种造成 GUI 测试不稳定的因素：

1. 非预计的弹出对话框；

2. 页面控件属性的细微变化；

3. 被测系统的 A/B 测试；

4. 随机的页面延迟造成控件识别失败；

5. 测试数据问题。

6. 对于非预计的弹出对话框引起的不稳定，可以引入“异常场景恢复模式”来解决。

7. 对于页面控件属性的细微变化造成的不稳定，可以使用“组合属性”定位控件，并且可以通
   过“模糊匹配技术”提高定位识别率。

8. 对于 A/B 测试带来的不稳定，需要在测试用例脚本中做分支处理，并且需要脚本做到正确识
   别出不同的分支。

9. 对于随机的页面延迟造成的不稳定，可以引入重试机制，重试可以是步骤级别的，也可以是
   页面级别的，甚至是业务流程级别的。

10. 对于测试数据引起的不稳定，我在这里没有详细展开，留到后续的测试数据准备系列文章中
    做专门介绍。

API 测试的基本步骤主要包括以下三大步骤

1. 准备测试数据（这是可选步骤，不一定所有 API 测试都需要这一步）；
2. 通过 API 测试工具，发起对被测 API 的 request；
3. 验证返回结果的 response。

完整的后端性能测试应该包括性能需求获取、性能场景设计、性能测试脚本开发、性能场景实现、性能测试执行、性能结果报告分析、性能优化和再验证。

性能测试场景设计