设计测试用例
设计测试用例主要分为以下几种：
功能测试
功能测试是试图发现程序和规定的说明不一致的过程，这个规定的说明是从最终用户的角度对程序行为的一个精准描述，测试人员需要通过这份说明进行分析以提炼测试用例。
在工作中，常常会存在需求不明确的功能，这种情况下我们需要以下几个方式进行功能测试：
- 查找其他相关的文档，帮助理解要测试的产品要完成的目标
- 参加组内的会议，进行需求讨论，设计讨论，计划讨论等，加深对产品的理解
- 召集相关人员，对整理的结果进行讨论，通过评审后，这份文档就可以作为依据来设计用例了
- 如果是一款已经上线的产品，可以多使用产品，多问产品经理
- 去看历史bug
界面测试
对软件界面上所有的内容都要测试，比如说我们要测试百度的网页，百度网页上的输入框要进行测试，有可能输入的字体太小，看起来不美观等，注意界面上的这些控件，每一个都进行测试，获得其对应的操作，整体界面的设计要和设计图上的一致等等
性能测试
性能测试和功能测试的区别是，功能测试检查软件是否做了，而性能测试检测软件做的好不好，比如说做了一个HTTP服务器，可以检测服务器的并发量，也可以检测服务器传输大文件等极端场景下的性能。
兼容性测试
软件是部署在硬件系统上，以来所需要的软件环境，兼容性测试是检测软件是否可以在移动端和PC端打开，移动端又分为IOS系统和Android系统，同一个操作系统又有不同的品牌，不同的机型，不同的版本，软件能不能在不同的环境下正确运行需要测试人员来验证。
在测试的时候，不太可能在兼容性测试的时候把所有机型全覆盖一遍，所以在执行兼容性测试的时候就优先选择当前产品最主流的机型进行测试。
易用性测试
易用性测试的标准是检测产品是否具有简单易上手的属性，是否有完整的使用引导，如果是命令行软件，那么是否具有完整的文档用于用户的参考，如果是GUI软件，是否具有合适的页面或者提示让用户快速适应产品。
安全测试
软件有一些常见的安全问题，比如说登录的时候密码这一类隐私数据明文显示，或者没有对传入的数据进行校验检测，可能导致SQL注入，返回一些明文隐私数据等，还有越权的问题，越权指的是普通用户也可以执行管理员权限的操作。
网络测试
- 各个网络功能的测试：在WIFI，4G，3G，高延时，高丢包，假热点，无网的条件下进行测试。
- 无网测试：在没有网络的条件下看各个功能是否受到影响，最低原则是不能闪退。
- 网络切换测试：从WIFI切换位流量，从WIFI切换为无网，从2G切换到3G等，查看在网络切换的时候页面是否符合要求。
- 弱网测试：弱网测试的目的就是尽可能保证用户体验，很多时候用户的网络并不会那么良好，在检测的时候，要关注页面响应时间是否可以接受，包括热启动时间，冷启动时间，页面切换，前后台切换等，也要关注超时的文案是否与预期的一致，超时的页面是否呈现正确，是否有超时重连，在弱网情况下可能会更新apk安装包，也可能下载文件等，这些都需要进行测试。
- 异常机制：打印异常信息，和无网区分，有对应的容错机制和超时/重连机制。
安装卸载测试
在测试的时候需要测试这个软件是否可以正确安装，安装完是否可以正确卸载，卸载完是否可以再安装，卸载完再安装是否可以再卸载等等。
设计方法
等价类
在设计一个邮箱登录注册界面的时候，可能会规定邮箱姓名等字段，比如说邮箱姓名应该在6~15位才有效，那么我们要通过穷举法测试6位，7位，8位...是否测试通过吗？显然不可能的，等价类法就解决了穷举法不能解决的问题。
首先要根据需求将输入划分为若干个等价类，从每一个等价类中选出一个测试用例，如果这个测试用例通过，那么就认为其代表的等价类测试通过，以此可以用较少的测试用例达到尽量多的功能覆盖，但等价类有一个缺点，它只考虑了输入域的分类，没有考虑到输入域的组合。
等价类分为两种：
有效等价类 ：有效等价类指的是那些对于程序规格说明书是合理的，有意义的输入数据构成的集合，使用有效等价类验证程序是否实现了程序规格说明中规定的功能或者性能。
无效等价类：不满足需求说明书的输入集合。
边界值
边界值是对输入输出的边界值进行测试的一种黑盒测试方法，通常边界值作为对等价类划分法的补充。
边界值包含边界值和次边界值，如果输入输出的边界值有效的区间是闭合的，那么边界值就是有效数据，次边界值就是无效数据，例如，我们在注册邮箱的时候，邮箱的名字长度范围在[6,15]，那么边界值就是6和15，次边界值就是5和16，如果有效的区间不是闭合的，那么区间的端点就是边界值，指代的是无效的数据，次边界值指代的就是有效的数据，比如说邮箱名字的长度在(6,15)，边界值就是6和15，次边界值就是5和14。
正交法
概念
为了保证系统的测试覆盖率，最简单的方法就是排列组合，但排列组合的测试用例会按指数级增长，会大大消耗测试的时间，正交法的目的就是减少测试用例的数目，用尽量少的用例覆盖输入的组合。
最简单的正交表是L4(2^3)，L表示这是正交表，L下角的数字4代表的是4行，即要做4次实验，3表示有三个纵列，即允许安排的要素是3个，2代表的是表的主要部分只有两种数字。
正交表由三部分构成：
因素 ：对指标的影响条件，通常是正交表的一列，比如说上图正交表的第一行的1，2，3指代的就是三个因素。
水平 ：水平指的是因素的值域，在正交表每一列里，不同数字出现的数量是相等的，任意两列中数字排列的方式齐全。
行数：表示的是实验的次数。
制作正交表
一般人很难通过手动设计出正交表，所以我们会借助到一个工具称为allparis。
- 首先找到因素和水平，比如说我们要设计的是邮箱注册时候是否填写字段的正交表，里面包含名字，电话号码，密码，确认密码，验证码这五个属性。
由于allparis对格式要求严格，所以需要使用微软的excel编写格式，在allparis文件夹同级目录下创建严格txt文件，用于存放excel表格里的数据。
如果没有使用微软的excel表格格式，那么就会出现如下报错：
判定表法
需求中存在各种各样的常见，如果我们有一个要求：用户登录或者用户之前有保存cookie，就可以进入个人主页，反之无法进入个人主页。
从这个需求可以看出，不同的组合可能导致不一样的结果,以下是画判定表的步骤：
- 确认需求中的输入输出条件，比如说我们例子的输入条件是用户登录和用户保存cookie，输出条件是进入个人主页和不进入个人主页
- 找出输入条件和输出条件之间的关系
- 画判定表
- 通过判定表编写测试用例
1.用户登录并且用户之前有保存cookie，会进入个人主页。
2.用户登录且用户之前没有保存cookie，会进入个人主页。
3.用户不登录且用户之前有保存cookie，会进入个人主页。
4.用户不登录且用户之前没有保存cookie，不会进入个人主页。
场景法
软件几乎都是事件触发来控制流程的，事件触发的情景就形成了场景，而同一事件不同的触发顺序和处理结果就称为事件流，场景主要包含四种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。
举个例子，如果我们要出去吃个饭，那么我们正常的流程是出门->饭店->点菜->吃饭，这个是事件的基本流，而每一个流程并不会是很顺利的，比如说出门这个流程，可能会因为突然接到电话，说朋友带了饭要来家里，那么出门这个事件就不会发生，还有去饭店这个流程，可能饭店没有开门，或者没有喜欢吃的饭店，点菜这个流程也可能出现问题，比如说没有喜欢的菜，可能会离开这个店，吃饭流程也可能出现问题，比如说要吃饭了，家里打来电话说有什么事情要紧急处理，那么这个饭就没办法吃了，这些意料之外的事件称为备选流，测试人员可以通过这些备选流补充测试用例，去编写测试用例。
错误猜测法
错误猜测法是测试人员通过对软件设计的理解，过往经验和个人直觉，推测软件可能存在的缺陷，比如说开发人员写了一个活动，我们会下意识去检查边界条件，但这个方法不太容易系统化，大部分依赖个人能力。