设计测试用例常用方法

基于需求的设计方法

基于需求设计测试用例是测试设计和开发测试用例的基础
1：第一步就要分析测试需求，验证需求是否正确、完整、无二义性，并且逻辑自洽。
2：细化测试需求，从测试需求提炼出一个个测试点
3：根据每一个测试点进行测试用例的设计；因为测试用例是一组集合；实际上我们还需要补充其它内容（测试环境、测试数据、操作步骤、预期结果……）

一般有以下测试需求：功能、性能、易用、兼容、安全、界面、中断、多开、可靠

功能测试

软件的功能是否满足软件需求：通常需要考虑以下的点
1：各个部件的功能是否能满足需要
2：业务流程测试；把这些功能串起来是否能满足软件需求
3：系统的不同输入，结果输出的业务数据测试。
4：功能的错误操作，异常操作的测试（属于负面测试）
5：边界值测试；验证边界上的点是否正常

非功能

性能测试
软件的性能是否满足软件需求
1：页面的响应时间；或者某个操作的响应时间；接口的响应时间
2：多人同时访问；服务器的响应的性能情况怎么样

易用性测试
站在用户体验的角度；去测试功能是否好用；有没有一些引导的操作或者提示。关键或者常用的功能是否在明显的地方。易用性测试通常是与界面测试一起完成的。

兼容性测试
不同型号或版本的浏览器、操作系统（windows、Linux、ios、Android）、多开的情况下能否兼容
不同网络环境：比如会不会网络太差然后就访问失败了

安全测试
1：测试是否SQL注入、XSS漏洞问题；
2：权限管理有没有漏洞（有些网站有管理员和普通用户它们权限不同；登录的用户与为登录的用户权限也不同）；
3：重要的数据有没有加密处理（比如用户密码传输使用的是不是https协议）。

界面测试
界面：判断文字/输入框/图片/下拉框…颜色、形状、大小、形状（比如我们一般比较喜欢圆角矩形）、大小、布局。是否存在错别字、病句、折行、折叠、重叠等都需要进行测试。易用性测试通常是与界面测试一起完成的。

中断测试
在进行某个操作的时候；突然有弹窗、网络断了、系统资源崩溃等别的外在因素影响这一次操作；看看是否会产生一些与我们的预期不可预估的结果

多开测试
比如网页你在多个的浏览器进行登录；只操作一个看看数据能否同步。在不同的环境上能不能同时登录；是登录失败还是把另一个挤下来。

可靠测试
比如：软件进行长时间运行、容错率、以及错误处理能力、高压下能否正常过程、在用户内存小的时候使用这个软件能不能抢的过别的后台软件内容等方面的测试

网易邮箱测试用例设计

黑盒测试用例设计方法

等价类

根据需求将输入(特殊情况下会考虑输出)划分为若干个等价类，从等价类中选出一个测试用例，如这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多功能覆盖，解决了不能穷举测试的问题。（一个代表一类）
简单来说：针对不同的输入；看软件的功能是否正常。功能的错误操作；看看异常的情况是否符合需求（比如说转账：我转了100块钱在输入密码的时候；输错密码有没有提示我错误原因和转账失败）

等价类可分：有效等价类（正反馈：满足用户需求输入集合）；无效等价类（负反馈：不满足用户需求的输入集合）。
比如：网页邮箱注册密码要求6-15位；那么有效等价类6-15位密码；无效等价类是小于6位或者大于15位。

等价类思想设计测试用例步骤
1：充分理解需求
2：划分有效等价类，划分无效等价类
3：从有效等价类抽取其中一个数据进行设计测试用例;从无效等价类中抽取其中一个进行测试用例设计

边界值

上述的测试用例设计还不够；而且在边界的地方；程序员特别容易因为手抖就出现不符合需求的情况
上点:边界上的点
内点:边界内的点
离点:边界值附近的一个点 (闭区间区间外距离上点最近的点，开区间区间内距离上点最近的点；但是不在边界上)
闭区间【6-15】：离点：5、16.。 开区间（6-15)：离点：6、15

假设已经充分理解需求；6-15为位用户名

判定表法

判定表将不同的输入条件与相应的期望结果或行为相关联
输入与输出关系：
与:所有的条件必须满足，如果一个条件不满足，此时结果为假
或:满足其中一个条件结果就为真，如果条件全部为假，结果就为假
恒等:条件为真，结果一定为真
非:条件为假，结果才为真0

根据上述思想设计测试用例：
1：分析所有可能的输入和可能的输出
2：找出输入与输出之间的对应关系。
3：输出判定表（）
4：把判定表对应到每一个测试用例

例如：假设业务单据的处理规则为:“淘宝618活动，订单已提交，订单合计金额大于300元或有红包，则进优惠
1：输入是什么？订单提交与否；金额大于300与否、有红包与否。输出是什么？优惠和不优惠。3个输入；输入情况两种；2的3次方；写出所有的组合。
2：输入和输出之间关系；啥时候优惠；啥时候不优惠。

得到传说中的判定表：

对着这个表编写测试用例；把这些条件写下来；

正交表法

正交表：组合表；通过最小化测试用例集来覆盖种可能的输入组合。正交表的设计基于正交性原则，即在各个测试步骤中对每个因素进行均等和充分测试。通过组合的方式；尽量的覆盖各种输入情况。

当我们输入的情况非常多且输入的组合非常多的时候；例如刚才的注册邮箱：姓名、邮箱、密码、确认密码、验证码必须全部输入才能进行注册；每一种的输入可以是正常/异常/不输入。
那需要设计多少用例? 非常多；即便设计完执行也是非常费劲的；所以希望用少的测试用例去覆盖这些测试点 。

因素：输入变量
水平：每一个输入变量取值
正交表性质：
1：每一列中各数字出现的次数都一样多。（每一个输入变量的水平个数是一样；细品：简单来说就是你的输入a；a的取值是1、2、3。你输入的1、2、3个数是一样的）
2：任何两列中的各有序数对出现的次数都一样多（如下：两个变量输入的水平组合都是出现一次）
什么叫有序数对；假设第一列和第二列；1、1还有1、2.这样子的横着的只会出现一次

充分理解需求 ->确定因素水平 ->画正交表>补充正交表 ->将正交表转换成测试用例

举例：
需求：注册邮箱：姓名、邮箱、密码、确认密码、验证码必须全部输入
因素是什么；姓名、邮箱、密码；确认密码、验证码
水平是什么；填写\不填写。看具体需求；我们这里没有限制位数和符号。

如何画正交表：使用allpirs工具
1：先将因素在Excel表填一下

2：把这三行表格复制一下；在记事本粘贴。保存到这个allpirs下载路径下
3：win+r 。cmd。进入到allpirs的路径里。
4：在命令行执行这个文件；这样子就能生成正交表到20230425_result.txt下


得到结果：

美观一下：我们之关注这上面的test cases；下面其它的和我们设计测试用例没什么关系；pairings我们不需要去关注。~表示可填可不填

这个正交表出来会有遗漏；因为因素可能全部为不填。我们再补充一下。

5：输出测试用例；一行就是一个测试用例

场景设计法

通常情况下，需要把用户经常用到的功能模块串联到一起进行测试；起码能保证；我们用户经常使用的功能它是没有问题的。这个是针对全流程的或者是部分流程操作
充分理解需求 ->确定主事件流 -> 确定次事件流 ->每一个事件流就是一个测试用例

错误猜测法

依靠测试人员经验。比如；网易邮箱登录；你用户名开头加空格也是一样能登录。中间有空格就不行了。密码打空格当然登录失败。

上述方法产生只是一个个的测试点；要变成测试用例你得补充完整测试用例的要素；比如：环境、版本号、数据、操作步骤、预期结果。

模拟弱网

可以使用Fiddler：
1：打开弱网模式

2：

3：

2G和3G怎么模拟

修改完成进行保存即可

接口如何测试

通过postman模拟请求
开发者工具；复制这个

在postman进行导入

如果出现问题就换一个复制看看；导不进去也没关系：我们直接手动模拟

怎么设计这个接口的测试用例：
get方法；那么post方法行不行呢。假设你说产品经理只要get呢；你肯定不能有post的。后面的参数你乱改会不会有问题呢？传参数、不传参数、非法参数。你乱写参数；当然不能给你返回数据。传null会什么情况呢

针对代码测试

命令测试

还是从设计测试用例的常见测试点出发去补充：zib命令“”打压缩包；将web打压缩包成web.zip?

水杯测试用例

微信朋友圈案例