测试用例
概念
什么是测试用例？
测试用例（Test Case）是为了实施测试而向被测试的系统提供的⼀组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
设计测试用例原则⼀：测试用例中⼀个必需部分是对预期输出或结果进行定义。
现在买回来一个新的电视机，进行测试：
根据个人经验-
- 开机测试
- 切换频道
- 调一下分辨率
- 测试一下网络电视
- 蓝牙功能
- ……
这些是买完后一定会做的测试内容，而这些测试内容并不会写到纸上。
软件中涉及到的特性太多了，仅仅通过自己想无法进行一次完整的测试。通过编写测试用例我可以想到要测试哪些内容，通过一次又一次的更新修改将测试用例写到完成，功能覆盖更高即可。
笔试的时候编写测试用例题，需要按照excel表格的方式来答题(涉及到测试用例的要素)。而面试的时候回答测试用例题，按照思维导图的方式一一道来(不会涉及到测试用例的要素)。
什么是要素？我们在编写测试用例的时候，每个用例需要给出这些要素对应的信息。
设计测试用例的万能公式
现在有一款产品，要求我们对“门锁”设计测试用例，假如你是测试人员，你会怎么设计呢？ 
可以看出，用例的设计最重要的⼀点是保证功能是正确的。上图给出的案例，在互联网企业中，这样去设计测试用例非常少。
工作中测试用例不是越多越好，而是能够达到更大的功能覆盖率是最好的。学习中测试用例的设计越多越好！(证明思维发散能力如何)
常规思考+逆向思维+发散性思维
- 测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应该根据无效和未预料到的输入情况。
- 检查程序是否“未做其应该做的”仅是成功的⼀半，测试的另⼀半是检查程序是否“做了其不应该 做的”。（是上⼀条原则的必然结果）
- 计划测试⼯作时不应默许假定不会发现错误。
万能公式
打开思维后进行设计测试用例想到一条说一条，如果没有正确的引导，说出来的测试用例一定是有限的且数量不容乐观的。
假如让你说出家里的电器：你会想到好多但是会卡壳，但是我给你提示你就会想到。万能公式就是一个引导的作用。帮助大家按照分类来设计测试用例。
设计测试用例的万能公式：功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全测试。
功能测试：从产品功能角度出发，验证功能功能是否是正确的。
界面测试：肉眼可看到的部分都是界面，界面所有的元素都要测试。
界面设计用到的内容：元素(大小，颜色，材质–可以摸到的，形状)
性能测试：通常在极端的情况，性能测试和功能测试的区别是：功能测试检查软件是否做了，而性能测试测试软件做的好不好。比如法拉利和五菱比较百里加速。
兼容性测试：涉及到不同的运行环境/版本。
软件是部署在硬件系统之上，并依赖所需要的软件环境。如QQ可以在PC端打开，也可以在移动端打开；移动端又分为IOS系统和Android系统，且市面上手机又有不同的品牌、不同的机型、不同的版本。软件是否能够在不同的环境下正确运行需要测试人员进行验证。
- 优先选择使用当前产品top级别的机型进行测试，实际在企业中，后台是可以获取到使用产品的机型，并以报表的形式统计在后台，供产品人员或其他人员制定策略参考。
- 选择主流的浏览器/机型进行测试
易用性测试：具备简单易上手的属性(引导教程)
安全测试：明文/密文展示或接口响应数据也要考虑到用户数据的安全性或通过用户表来保存账号和密码，而密码通过加密算法如MD5来保存–数据库存储用户隐私数据是否加密。
或后端获取到用户输入的账号和密码后，会进行sql拼接查询数据库：
SELECT * FROM users WHERE username = 'alice' AND password = '123456'；
SELECT * FROM users WHERE username = or 1=1 and password = '123456'；//or 1=1会将users表中的所有用户信息返回；
使用万能公式对水杯进行用例的设计：
弱网测试
弱网测试(网不好时)的目的就是尽可能保证用户体验–为了覆盖更多的场景，关注的关键点包括：
- 页面响应时间是否可以接受，关注包括热启动、冷启动（冷启动就是从零开始加载，热启动是复用已有状态）时间、页面切换、前后台切换等。
- 页面呈现是否完成⼀致。
- 超时文案是否符合定义，异常信息是否显示正常。
- 是否有超时重连。
- 安全角度：是否会发生dns劫持、登陆ip更换频繁、单点登陆异常等。
- 大流量事件风险：是否会在弱网下进行更新apk包、下载文件等大流量动作。
如何进行弱网测试？
2G 3G 5G等，不需要不同的手机，而是用工具来进行弱网测试：抓包工具-fiddler
数字越大则会显示数据正在加载中。
安装卸载测试
针对需要进行部署的软件，除了软件功能外，我们还需要关注软件的能够成功安装和卸载。
设计测试用例的方法
基于需求的设计方法
测试和开发开展工作的依据：软件需求(需求文档)。
基于需求的设计方法也是总的设计测试用例的方法，在工作中，我们需要参考需求文档/产品规格说明书来设计测试用例。
测试人员接到需求之后，要对需求进行分析和验证，从合理的需求中进⼀步分析细化需求，从细化的需求中找出测试点，根据这些测试点再去设计测试用例。
以该注册邮箱账号需求为例，我们来设计测试用例。
1. 明确需求中的功能点
账号注册，账号登陆
2.结合万能公式设计测试点 
具体的设计方法
等价类
上述设计的测试用例，存在用例还未完全设计完成，“姓名必填，6~15位的字符类型”，这样⼀个具体的需求该如何来设计测试用例呢？
测试的时候通过穷举法来测试6位、7位、8位……14位，15位是否测试通过，这样的方法能够满足测试的要求吗？若此时把范围从“6~15位”改成“6~150位呢”？试想⼀下这样⼀个简单的测试点需要测试多久呢，现实是不符合企业测试要求的。
而等价类法的出现就解决了穷举法不能解决的问题
依据需求将输如（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出⼀个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
生活中等价类的案例：原则上讲,老师应该依据每个学生自身的情况,指定符合的学习方案.但是实际上学生太多老师管不过来,只能分成几类:优等生强调知识面的扩展和综合能力的提升;中等生强调夯实基础,查缺补漏;差等生强调优先掌握重点,暂时跳过难点…(例如讲题不能一个一个问听懂了么？但是只要区间有人说听懂了就行)
思路：输入的集合是无穷的,不能全都覆盖到
等价类分类：
- 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
- 无效等价类：根据需求说明书，不满足需求的集合。
根据等价类设计测试用例的方式：
- 1.确定有效等价类和无效等价类
- 2.编写测试用例，设计具体测试数据
6-15位为有效等价类，<6或>15位为无效等价位；
边界值
边界值分析法就是对输入或输出的边界值进行测试的⼀种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
日常语言中的"边界"漏洞
考完试发成绩了,老师布置寒假作业:超过60分的,所有题目抄写1遍,低于60分的,所有题目抄写3遍。于是小明就没有写作业~~,因为他刚好60分.
边界值包含：边界值+次边界值
继续将上述用例通过边界值补充完整。
边界值为给定数据范围的左数据和右数据；
选择次边界值的时候需要根据边界值的有效无效情况来定：若边界值为有效等价类中的数据，则次边界值为无效等价类中的边界。若边界值为无效等价类中的数据，则次边界值为有效等价类中的边界。
正交法
正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的⼀种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交试验设计是⼀种基于正交表的、高效率、快速、经济的试验。
正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。
通常来说，为了保证系统的测试覆盖率，我们首先能够想到的就是排列组合。
假如当前有两个选项A和B，可以设计出都填写、都不填写、填写A、填写B四个测试用例（2²）。
假如当前有三个选项A、B、C，通过设计可以得到8个测试用例（2³）
……
当前可选的选项是5个，分别是，姓名、电子邮箱、密码、确认密码、验证码。按照排列组合设计出来的用例是32个…..
正交表的性质：
- 每⼀列中，不同的数字出现的次数相等。
- 任意两列中数字的排列方式齐全而且均衡
根据正交表的性质，⼀般人很难通过首动设计出正交表，可以根据工具来设计–allpairs。
正交法设计测试用例的步骤：
1. 找到因素和水平
2. 用allparis工具生成正交表
a. 将因素和水平写⼊Excel表格中(不需要保存)
b. allparis目录下创建新的文本文件new.txt，复制Excel中的因素和水平，直接粘贴到文本中保存并退出
错位正常
c. 使用allparis命令生成正交表：allparis.exe new.txt>zhengjiao.txt
创建成功时没有任何提示
复制到excel中是正常的
allpairs生成的正交表与实际的正交表会有一定出入，例如第一列的5，6因为是~；
~表示可以是任意的选项：填写/不填写
3. 根据正交表编写测试用例
4. 补充遗漏的重要测试用例
使用excel可以保证格式是正确的，因为allpairs对格式非常严格，若自己在txt中编写数据那么最后无法生成。
判定表法
需求中会存在各种各样的场景，现在我们把需求改成如下的要求： 用户输入的账号中包含admin字符，或者通过内部链接进入注册页面，提交注册按钮成为管理员身份；反之无管理员身份。
通过这个需求可以看出，不同的组合操作可能对应不同的结果。采用正交法无法解决这样的问题。而正交法能够解决需要考虑输入之间的组合关系对应不同结果的场景。
判定表是⼀种表达逻辑判断的工具，形如： 
通过该图，可以把所有条件对应的结果清晰的表达出来。我们就需要借助该表来清晰的写出测试用例。
根据判定表法设计测试用例的步骤：
- 确认需求中输入条件和输出条件
- 找出输入条件和输出条件之间的关系
- 画判定表(用excel表格)
- 根据判定表编写测试用例
1)账户包含admin，提交注册，成为管理员
2)内部链接进入，提交注册，成为管理员
……
场景法
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同⼀事件不同的触发顺序和处理结果就形成事件流。(不同的操作有不同的事件流)
我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。 场景法⼀般包含基本流(基本事件流)和备用流(备用事件流)，从⼀个流程开始，通过描述经过的路径来确定的过程，经过遍历所 有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。场景法就是⼀个常规的流程中，某些阶段可能会出现⼀些意想不到的情况，常规流程是基本流，从阶段中分析出来的不同情况被称之为备选流。
场景法是一个非常有用的设计测试用例思路。
若现在来测试一个活动，该活动每个月都要进行一次，但是每个月的福利不一样。前置：5.20测试完后就要上线。但是现在声明要求6月福利变为奖励10元。
这样会导致5月福利没了；那么新活动上线要保证旧活动不受影响(新增的代码对旧代码没影响)；
错误猜测法
错误猜测法是对被测试软件设计的理解，过往经验以及个⼈直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。
这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。
错误推测法和目前流行的“探索式测试方法”的基本思想⼀致，这类方法在敏捷开发模式下的投入产 出比很高，被⼴泛应用于测试。
当我们⼀提到某个非常熟悉的人的名字，脑海会立刻浮现对他的评价
“武大郎”：憨厚，老实，为人坦诚，乐于助人
“潘⾦莲”：美丽，“温柔”，“疼爱丈夫”，“善于交友”，“精通制衣”
张三要去卖瓜
用例1：张三这人不实诚，小心他缺斤少两
用例2：张三这人粗心，小心他的瓜被压坏了
用例3：张三这人小气，小心不要把他惹哭了
这个方法的缺点是难以系统化，并且过度依赖个人能力。
例子：对zip进行测试
功能测试：对不同的文件类型进行测试
普通的txt文件能够生成zip文件
2）图片/视频/zip文件能够生成zip文件
3）多个文件能够生成zip文件（混合文件）
4）空文件夹可以生成zip文件
5）错误的命令是否可以解压（zip zip/没有写压缩包文件名称/没有源文件）
6）其他参数的测试
界面测试：
文件压缩成功命令行提示是否美观
文件压缩报错命令行提示是否友好
性能测试：文件大小超过1G时文件是否可以压缩
文件大小超过1G时文件压缩消耗的时间是否在合理的时间范围内
兼容性测试：
zip⼯具可以在多系统上使用，如Windows、Linux、Mac
易用性测试：
zip命令有使用帮助教程，如zip–help命令下会展示如何使用
安全性：使用zip命令会不会泄漏文件内容
web接口测试
如何打开开发者工具：鼠标右键点击检查/ctrl+shift+i/f12
点击network可以看到网络请求哪些接口(可以刷新)
对接口进行测试，主要关心四个部分：请求方法(request method)，url，请求参数(有时会直接拼接到url后或Payload/Request Body)，响应(response)
有时候url中？后就是请求参数
1.通过get方法请求
2.通过post方法请求
3.请求参数拼接blogld
4.请求参数拼接非blogld
……
通过页面的开发者工具无法对接口进行具体的测试，需要借助接口测试工具：postman(登录与不登录都行但是使用的功能不同)
申请一个测试：
当用post时出错
添加到postman的方式：
1）打开页面开发者工具，选中要复制的接⼝，右键复制URL
2）打开postman，点击“import”按钮，选择"Raw text"方式导入请求，将复制好的URL粘贴到文本 框中，选择“continue” 
4）最终，接⼝被成功导⼊到postman中啦
cookie表示用户的登陆状态，若没有cookie则表示用户没有登陆；
如何对一个项目进行测试？
1.项目背景
2.项目功能
3.对项目进行测试
1）编写测试用例
用例截图放这里
2）执行测试
选取几个用例的步骤截图放到这里展示
4.项目总结(覆盖了多少页面，用例是否都安全通过，发现多少bug，bug出现的原因……）
