软件测试基础

软件测试生命周期

测试报告是一个文档；大部分邮件发送：

如何描述一个bug

1、发现问题的版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。
2、问题出现的环境
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
3、错误重现的步骤
描述问题重现的最短步骤
4、预期行为的描述
要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。
要相信:测试人员是最懂需求的
5、错误行为的描述
描述错误的现象。crash等可以上传log，Ul问题可以有截图。
6、其他
某些公司会有一些其他的要求，例如故障的分类: 功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。
7、不要把多个bug放到一起
在无法确认是同一段代码造成的故障时，不要将bug放在一起提交

bug优先级：不同公司不同；但是都是根据影响程度来定位的

注意：如果发现崩溃级别的BUG，那么此时就需要停止测试，测试打回

bug生命周期

测试用例

回顾一下测试用例的基本要素？
测试用例是一组集合;测试环境、测试数据、预期结果、操作步骤……注意：不需要执行结果；只有预期结果；执行结果是要拿着测试用例去执行才有的

针对黑盒测试用例设计方法：

基于需求的设计方法

如何基于需求设计测试用例：我们针对网页邮箱的注册进行基于需求设计测试用例

先分类：功能相关、非功能相关；功能有什么；非功能有什么。最后面再讲具体的测试点。例如：

等价类

依据需求将输入(特殊情况下会考虑输出)划分为若干个等价类，从等价类中选出一个测试用例，如这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多功能覆盖，解决了不能穷举测试的问题。（一个代表一类）
等价类可分：有效等价类（满足用户需求输入集合）；无效等价类（不满足用户需求的输入集合）。
比如：网页邮箱注册密码要求6-15位；那么有效等价类6-15位密码；无效等价类是小于6位或者大于15位。

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

边界值

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

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

判定表法

与:所有的条件必须满足，如果一个条件不满足，此时结果为假
或:满足其中一个条件结果就为真，如果条件全部为假，结果就为假
恒等:条件为真，结果一定为真
非:条件为假，结果才为真
根据上述思想设计测试用例：

例如：假设业务单据的处理规则为:“淘宝618活动，订单已提交，订单合计金额大于300元或有红包，则进优惠
1：输入是什么；输出是什么
2：输入和输出之间关系

得到传说中的判定表：

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

所以这个表的意义是什么？和上面的分析出来的关系很像啊；简直一模一样。因为这只是测试点；我们还要补充后面的测试用例；测试用例要素。变成测试用例；我们还得要那几个要素；环境、预期结果、输入；执行步骤

正交排列

当我们的需求非常多的时候；希望用少的测试用例去覆盖这些测试点 。例如刚才的注册邮箱：姓名、邮箱、密码、确认密码、验证码必须全部输入,才能进行注册需要设计多少用例? 2x2x2x2x2.

因素：输入变量
水平：每一个输入变量取值
正交表性质：每一列中各数字出现的次数都一样多。任何两列中的各有序数对出现的次数都一样多
什么叫有序数对；假设第一列和第二列；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：

接口如何测试

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

在postman进行导入

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

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

针对代码测试

命令测试

zib命令“”打压缩包；将web打压缩包成web.zip?

水杯测试用例

微信朋友圈案例