测试基础理论&思想

测试基础理论&思想

功能测试（测试的时候要思考更多，避免 Happy Path 场景）

举例：用户登录

输入账号密码，点击登录，成功。这是最典型的 Happy Path 场景。
而作为测试工程师，就要考虑更多更全面。一般需要结合等价类划分法，边界值/边界条件分析法，错误推断法去展开思考。

非功能测试

举例：用户登录

一：安全性测试
1. 是否加密传输
2. 密码框是否支持复制粘贴
3. sql注入
4. 跨站脚本攻击
5. 登录过多，是否有应对暴力破解
6. 是否支持多端登录
...

二：性能测试
1. 登录响应时间
2. 接口请求数量是否过多
3. 高并发的响应时间
4. 服务器监控指标是否符合预期
5. 集合点高并发下，是否存在资源死锁或不合理的资源等待
6. 同时间大量用户登录退出，是否有内存泄漏
...

三：兼容性测试
1. 不同浏览器
2. 浏览器不同版本
3. 不同终端设备
4. 不同分辨率界面
5. 不同环境（app，H5，微信，小程序）
...

什么是“好的”测试用例

一般包含以下特征：
1. 整体的完备性：优效的测试用例集合，能够完全覆盖测试需求
2. 等价类划分的准确性
3. 等价类集合的完备性：保证所有可能的边界值或条件都正确覆盖
  Tips：什么是边界条件？比如购买1个商品和购买多个商品；
        还有比如selectOne，selectList经常出错等。

所以没有好的测试用例，只有好的测试用例集合。

设计“好的”测试用例秘诀

首先了解不同的测试类型：通常测试包含黑盒测试，白盒测试，灰盒测试（如微服务架构中的测试）。

以黑盒测试展开：
(1)只有深入理解被测试软件的架构，才能设计出有的放矢的测试用例集，去发现系统边界以及系统集成上的潜在缺陷。作为测试工程师，切忌把整个被测系统看作一个大黑盒，必须对内部的架构有清楚的认识，比如，数据库连接方式、数据库的读写分离、消息中间件 Kafka 的配置、缓存系统的层级分布、第三方系统的集成等。

(2)必须深入理解被测软件的设计与实现细节，深入理解软件内部的处理逻辑。单单根据测试需求点设计的测试用例，只能覆盖“表面”的一层，往往会覆盖不到内部的处理流程、分支处理，而没有覆盖到的部分就可能出现测试遗漏。在具体实践中，测试人员可以通过代码覆盖率指标找出可能的测试遗漏点。同时，切忌以开发代码的实现为依据设计测试用例。因为开发代码实现的错误会导致测试用例也出错，所以应该根据原始需求设计测试用例。

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

作为测试人员，需要注意以下几点。
(1)需要明白，“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各 种边界值，而能否发现软件缺陷并不是衡量测试用例好坏的标准。
(2)设计测试用例的方法有很多种，但综合运用等价类划分方法、边界值分析方法和错误推测方法，可以满足绝大多数软件测试用例设计的需求。
(3)在设计时，“好的”测试用例需要从软件功能需求出发，全面地、无遗漏地识别出测试需求。
(4)如果想设计一个“好的”测试用例，必须要深入理解被测软件的架构设计，深入理解软件内部的处理逻辑。