测试和开发开展的依据：软件需求。
基于需求的设计方法也是总的设计测试用例的方法，在工作中，我们需要参考需求文档/产品规格说明书来设计测试用例。
测试人员接到需求之后，要对需求进行分析和验证，从合理的需求中进一步分析细化需求，从细化的需求中找出测试点，根据这些测试点再去设计测试用例。
编写邮箱测试用例
这里还需要添加，数据兼容性（手机号兼容、微信兼容、数据过多展示是否正常）
之前根据需求文档先设计初步的设计用例，而部分用例还需要细化，就需要借助具体的设计方法。
在测试的时候应该测试哪些长度的姓名？（测试了软件是否做其应该做的，是否做了其不应该做的），在这个数据中，穷举法数据太多，无法借助该方法来进行测试。
等价类主要分为俩种：有效等价类、无效等价类
有效等价类：对于程序的规格说明书是合理的、有意义的输⼊数据构成的集合，利⽤有效等价类验证程序是否实现了规格说明中所规定的功能和性能
⽆效等价类：根据需求说明书，不满⾜需求的集合。
根据等价类设计测试用例的方式：
缺点：等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。
边界值分析法就是对输⼊或输出的边界值进⾏测试的⼀种⿊盒测试⽅法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试⽤例来⾃等价类的边界。
边界值包含：边界值+次边界值
（1）有效范围是[6, 15]，闭区间
（2）有效范围是(6, 15)，开区间
边界值即给定范围返回的左数据和右数据；选择次边界值为有效等价类中的数据，则次边界值为无效等价类中的应用。
因素：存在的条件
水平：因素的取值
最简单的正交表是L4(2^3)，含意如下：“L”代表正交表；L 下角的数字“4”表示有 4 横行，简称行，即要做四次试验；括号内的指数“3”表示有3 纵列，简称列，即最多允许安排的因素是3 个；括号内的数“2”表示表的主要部分只有2 种数字，即因素有两种水平1与2。
上表的表示方法为：L12(2^11)
正交表的性质：
正交法的目的是为了减少用例数目，用尽量少的用例覆盖输入的俩俩组合。
正交试验设计(Orthogonal experimentaldesign)是研究多因素多⽔平的⼀种设计⽅法，它是根据正交性，由试验因素的全部⽔平组合中挑选出部分有代表性的点进⾏试验，通过对这部分试验结果的分析了解全⾯试验的情况，找出最优的⽔平组合。正交试验设计是⼀种基于正交表的、⾼效率、快速、经济的试验。
设计正交表：（借助工具allpairs：设计正交表）
步骤：
- 根据需求找出因素和水平
- 将因素和水平写到excel表格中（表格不需要保存），建议使用微软自带的Excel软件。
- 在allparis.exe同级文件夹下创建一个txt文件，将excel表格中的内容复制到txt文件中，不要有其他的操作直接保存。
- 使用allparis.exe工具对txt文件生成正交表文件（建议不要提前创建该文件，可以是一个不存在的文件）
- 没有任何提示表示生成成功。
- ~符号表示可以是任意的选项：填写/不填写
- 根据生成好的正交表来编写测试用例，继续将重要的用例补全
（1）姓名填写、电子邮箱填写、密码填写、确认密码填写、验证码填写
（2）姓名填写、电子邮箱不填写、密码不填写、确认密码不填写、验证码不填写
（3）姓名不填写、电子邮箱填写、密码不填写、确认密码填写、验证码不填写
（4）姓名不填写、电子邮箱不填写、密码填写、确认密码不填写、验证码填写
（5）姓名不/填写、电子邮箱填写、密码填写、确认密码不填写、验证码不填写
（6）姓名不/填写、电子邮箱不填写、密码不填写、确认密码填写、验证码填写
（7）姓名不填写、电子邮箱不填写、密码不填写、确认密码不填写、验证码不填写
【注意】若不使用excel，而直接手动在txt文件中编写因素和水平，使用命令生成正交表会存在格式校验错误的情况，allpairs工具对格式的要求非常严格。
allpairs工具生成的正交表和实际的正交表会有一定的出入但是不影响整体的情况
使用正交表法最终得出7种测试结果。
通过具体的⽅法能够将测试⽤例设计的更加完整和规范。
需求中会存在各种各样的场景，现在我们把需求改成如下的要求：
用户输⼊的账号中包含admin字符，或者通过内部链接进⼊注册页⾯，提交注册按钮成为管理员⾝份；反之⽆管理员⾝份。
通过这个需求可以看出，不同的组合操作可能对应不同的结果。采⽤正交法⽆法解决这样的问题。⽽正交法能够解决需要考虑输⼊之间的组合关系对应不同结果的场景。
判定表是⼀种表达逻辑判断的⼯具，形如：
通过判定表法，可以非常编写出测试用例（思路清晰）
步骤：
- 确认需求中输入条件和输出条件
- 找出输入条件和输出条件之间的关系（通过对输入条件的组合找出不同组合对应的结果）
- 画判定表
- 根据判定表编写测试用例
进行测试：
根据判定表编写测试⽤例
a. 账号包含admin，⾮内部注册链接，点击注册按钮，为管理员⾝份
b. 账号包含admin，内部注册链接，不点击注册按钮，⾮管理员⾝份
c. 账号不包含admin，内部注册链接，点击注册按钮，为管理员⾝份
d. 账号包含admin，内部注册链接，点击注册按钮，为管理员⾝份
e. 账号包含admin，⾮内部注册链接，不点击注册按钮，⾮管理员⾝份
f. 账号不包含admin，⾮内部注册链接，点击注册按钮，⾮管理员⾝份
g. 账号不包含admin，⾮内部注册链接，不点击注册按钮，⾮管理员⾝份
现在的软件⼏乎都是⽤事件触发来控制流程的，事件触发时的情景便形成了场景，⽽同⼀事件不同的触发顺序和处理结果就形成事件流。
通过运⽤场景来对系统的功能点或业务流程的描述，从⽽提⾼测试效果的⼀种⽅法。⽤例场景来测试需求是指模拟特定场景边界发⽣的事情，通过事件来触发某个动作的发⽣，观察事件的最终结果，从⽽用来发现需求中存在的问题。我们通常以正常的⽤例场景分析开始，然后再着⼿其他的场景分析。
场景法⼀般包含基本流（基本事件流）和备用流（备用事件流），从⼀个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备⽤流来完成整个场景。
场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。
场景法就是⼀个常规的流程中，某些阶段可能会出现⼀些意想不到的情况，常规流程是基本流，从阶段中分析出来的不同情况被称之为备选流，
典型的应⽤是是⽤业务流把各个孤⽴的功能点串起来，为测试⼈员建⽴整体业务感觉，从⽽避免陷⼊ 功能细节忽视业务流程要点的错误倾向
在确认基本流和备用流后，编写测试用例：
场景法在工作中也是一个非常有用的设计测试用例思路。
错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。
这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。
错误推测法和⽬前流⾏的“探索式测试⽅法”的基本思想⼀致，这类⽅法在敏捷开发模式下的投⼊产出⽐很⾼，被⼴泛应⽤于测试。
命令行测试
存在功能可以在命令⾏使⽤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命令不会泄漏⽂件内容
如何在页面打开开发者工具：
方法一：页面鼠标右键选择“检查”
方法二：通过快捷键：ctrl + shift + i
对接口执行测试：
请求方法，URL，请求参数，响应
通过页面的开发者工具无法对接口进行具体的测试，需要借助接口测试工具：postman