Bug等级：崩溃、严重、一般、次要
bug的生命周期
面试高频考题：跟开发产生争执怎么办？
(1)反思自己，是不是bug描述写的不清楚
(2)站在用户思考问题，反问开发人员：“如果你是用户，你能接受这样的设计吗？”
(3)bug定级一定要有理有据
(4)除了可以提出bug，最好也能给出解决方案
设计测试用例的万能思路
安装卸载测试
针对需要进行部署的软件，除了软件功能外，我们还需要关注软件的能够成功安装和卸载
设计测试用例的方法
基于需求的设计方法
需求文档
测试和开发工作开展的依据：软件需求 用户需求
需求分析
具体的设计方法
等价类
依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题
缺点：等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充
边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
边界值包含：边界值+次边界值
判定表法
根据判定表法设计测试用例的步骤：
1.确认需求中输入条件和输出条件
输入：账户包含admin字符，内部链接进入注册页面，提交注册按钮
输出：管理员/无管理员
2.找出输入条件和输出条件之间的关系
3.画判定表
4.根据判定表编写测试用例
1）账户包含admin字符，提交注册按钮，成为管理员账号
2）内部链接进入注册页面，提交注册按钮，成为管理员账号
3）账户包含admin字符，内部链接进入注册页面，无管理员身份
4）账户包含admin字符，内部链接进入注册页面，提交注册按钮，成为管理员账号
5）账户不包含admin字符，非内部链接进入注册页面，未提交注册按钮，无管理员身份
6）账户包含admin字符，无管理员身份
7）内部链接进入注册页面，无管理员身份
8）提交注册按钮，无管理员身份
正交法
正交表因素多种，水平取值只有1和2
最简单的正交表是L4(23)，含意如下：“L”代表正交表；L 下角的数字“4”表示有 4 横行，简称行，即要做四次试验；括号内的指数“3”表示有3 纵列，简称列，即最多允许安排的因素是3 个；括号内的数“2”表示表的主要部分只有2 种数字，即因素有两种水平1与2。正交表的特点是其安排的试验方法具有均衡搭配特性。
例子：输入选项有：姓名、电子邮箱、密码、确认密码、验证码。排列组合出来的用例是32个
正交试验设计是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行实验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。
设计正交表：
借助工具来实现正交表 allpairs:设计正交表
步骤：
1.根据需求找出因素和水平
因素： 姓名、 电子邮箱、 密码、 确认密码、 验证码
填写 填写 填写 填写 填写
水平： 不填写 不填写 不填写 不填写 不填写
2.将因素和水平写入到excel表格中（表格不需要保存）
建议使用微软自带的Excel软件（建议使用），wps，其他的excel工具（不建议使用）
3.在allpris.exe同级文件夹下创建一个.txt文件，将excel表格中的内容复制到.txt文件中，不要有其他操作直接保存文件
4.使用allparis.exe工具对.txt文件生成正交表文件
allparis.exe test01.txt > res-test01.txt
建议不要提前创建该文件，可以是一个不存在的文件
这是使用allparis工具生成的正交表
allparis工具生成的正交表和实际的正交表会有一定的出入
但是不影响整体的情况
~:表示可以是任意的选项：填写/不填写
5.根据生成好的正交表来编写测试用例，继续将重要的用例补全
1）姓名填写，电子邮箱填写，密码填写，确认密码填写，验证码填写 全部填写
2）姓名填写，电子邮箱不填写，密码不填写，确认密码不填写，验证码不填写
3）姓名不填写，电子邮箱填写，密码不填写，确认密码填写，验证码不填写
4）姓名不填写，电子邮箱不填写，密码填写，确认密码不填写，验证码填写
5）姓名不/填写，电子邮箱填写，密码填写，确认密码不填写，验证码不填写
6）姓名不/填写，电子邮箱不填写，密码不填写，确认密码填写，验证码不填写
7）姓名不填写，电子邮箱不填写，密码不填写，确认密码不填写，验证码不填写 全部不填写
使用正交表从32种用例到7种
场景法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。
场景法原理
在了解场景法之前，要先了解基本流和备选流：
1.基本流：软件功能按照正确的事件流，中间无任何差错，从开始直接执行到结束的一条正确流程
2.备选流：软件功能在执行过程中，除了基本流之外可能遇到的各种情况，是包含可能存在问题的各支流
边界值法：取边界值+次边界值 边界值有效，那次边界值无效 边界值无效，那次边界值有效
这些具体的方法旨在提高我们的测试思路+提高我们设计测试用例的能力
错误猜测法
错误猜测法是对被软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。
这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。
错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应用于测试。
当我们一提到某个非常熟悉的人的名字，脑海会浮现出对他的评价
“武大郎”：憨厚，老实，为人坦诚，乐于助人
“潘金莲”：美丽，“温柔”，“疼爱丈夫”，“善于交友”，“精通制衣”
“登录功能”设计测试用例
1.明确需求
2.使用万能公式+测试用例方法设计测试用例
3.按照测试用例对系统进行测试
4.记录测试，编写一篇测试博客
博客系统测试
1.项目背景
2.项目功能
3.对项目进行测试
1)编写测试用例
用例截图放到这里
2）执行测试
选取几个用例的步骤截图放到这里仅做展示
4.测试总结（覆盖了多少个页面、用例是否全部执行通过，发现了多少个bug?bug出现的原因/设计到的页面在哪里…）
命令行程序
zip/unzip命令对文件进行解压缩，这样的场景来设计测试用例
Zip命令
功能测试：对不同的文件类型进行测试
1）普通的txt文件能够生成zip文件
2）图片/视频/zip文件能够生成zip文件
3）多个文件能够生成zip文件（混合文件）
4）空文件夹可以生成zip文件
5）错误的命令是否可以解压（zip zip/没有写压缩包文件名称/没有源文件）
6）其他参数的测试
界面测试：
1）文件压缩成功命令行提示是否美观
2）文件压缩报错命令行提示是否友好
性能测试：
1）文件大小超过1G时文件是否可以压缩
2）文件大小超过1G时文件压缩消耗的时间是否在合理的时间范围内
兼容性测试：
1）zip工具可以在多系统上使用，如Windows、Linux、Mac
易用性测试：
1）zip命令有使用帮助教程，如zip --help命令下会展示如何使用
安全性：
1）使用zip命令不会泄露文件内容
接口：http://192.168.47.135:8080/blog_system/blog?blogid=10
