测试理论（2）——测试用例
1、测试用例概述
1.1定义
测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。
1.2编写步骤
拿到测试需求——分析需求（画思维导图）——编写用例——划分用例优先级。
1.3编写特征
（1）一致性：主要包括用例模板一致；各同事的编写方式一致；以及用例的细腻度一致。
（2）覆盖率：主要包括对需求的覆盖（也包含隐含的需求）；新需求可能对哪些功能会产生影响的覆盖；对各种场景的覆盖，包括功能和非功能以及异常功能。
（3）可执行性：主要是指步骤易于理解、信息描述准确、且能快速识别出测试点。
（4）执行准确性：是指用例执行的准确度，本身没什么技术含量。但这里需要注意的是执行人对待执行用例的态度。不要因为用例简单或者一些外界的因素，导致部分用例未实际执行但标为测
试通过的情况。
（5）持续更新：要及时不断的更新，要尽量减少用例库中失效的用例。
（6）复用性：主要用例可以被不断的复用。
1.4组成元素
（1）用例ID；（2）用例名称；（3）测试目的；（4）测试级别；（5）参考信息；（6）测试环境；（7）前提条件；（8）测试步骤；（9）预期结果；（10）设计人员。
写测试步骤的注意事项：详细、清晰、通俗易懂。
1.5编写方式
（1）思维导图的模式，使用一句话描述测试场景 特点：结构化思维非常强，让人很明晰的可以看到编写测试人员的思维结构
（2）表格模式，excel/csv 或者WEB平台编写，特点，非常详细，步骤非常明确，缺点，写起来很慢。
（3）checklist，在记事本上写，与思维导图类似。
场景一：比如早上出需求，晚上上线，那么就使用这种方式
场景二：使用该方式梳理出测试的思路
场景三：和开发单独去对一些复杂的逻辑
选择原则是什么：和现在的团队保持一致，至少对自我的要求上，要比现在的团队做的好。
1.6测试用例示例
（1）思维导图模式示例
（2）表格模式示例
（3）checklist
2、测试用例设计方法
2.1.1定义
等价类是把所有可能的输⼊数据，即程序的输⼊域划分成若⼲部分（⼦集），然后从每⼀个⼦集中选取少数具有代表性的数据作为测试用例。从逻辑学角度而言，输入----》中间处理-
---〉输出，如下图所示，简单理解就是针对被测对象输入的数据，可以分为有效数据与无效数据。即被测对象可以分为两个维度的测试：
（1）正常流程 ：需要测试的数据可以理解为有效数据；
（2）异常流程：需要测试的数据可以理解为无效数据；
2.1.2实例
（1）如拉勾网：验证码输入，返回的正常的6位数字的验证码数据为有效数据；其他如多于/少于6位数字、数字字母组合等为无效数据。
（2）又如拉勾网的注册（用手机号码注册）：
1、有效数据：有效的11位数字且由三大运营商发布的正常使用的手机号码。
2、无效数据
A、少于/多于11位数字；
B、数字+字母/其他符号的组合；
C、11位数字，但是不是有效的手机号码，如连续相同的数字；
D、输入空白内容；
（3）又如拉勾网（测试类）
1、有效数据：
A、输入测试关键字进行搜索，如测试开发工程师；
B、输入相关互联网公司名称+测试关键字进行搜索；
C、输入地区+测试关键字进行搜索；
D、输入测试关键字+任意字符进行搜索；
2、无效数据：
A、输入空白内容；
B、输入其他非测试类职位关键字；
C、输入特殊/数字字符；
（4）后台（代码：登录服务）
代码如下：写出用户名、密码、年龄、性别的等价类
用户名
有效数据：输入注册成功的1~6个字符串；
无效数据：
（1）输入没有注册或注册不成功的1~6个随机字符串；
（2）输入大于6个的字符串；
（3）输入空白内容；
密码
有效数据：输入注册成功且与用户名对应的1~6个字符串；
无效数据：
（1）输入没有注册或注册不成功的1~6个随机字符串，或者不与用户名对应的1~6个字符串；
（2）输入大于6个的字符串；
（3）输入空白内容；
年龄
有效数据：
（1）输入正整数；
无效数据：
（1）输入字符串/非正整数的数字等；
（2）输入空白内容；
性别
有效数据：
（1）输入一个字符串，且是”男“或者”女“；
无效数据：
（1）输入一个非男/女的字符串；
（2）输入大于一个的字符串；
（3）输入空白内容；
2.2边界值
2.2.1定义
边界值分析法就是对输⼊或输出的边界值进⾏测试的⼀种⿊盒测试⽅法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试⽤例来⾃等价类的边界。
2.2.2实例
（1）新浪注册，密码信息为6-16位数字、字母的形式，5和17位都是边界值，在测试时，可以将密码5、6、16、17位都进行测试；
（2）如手机号，12位就是边界值。在测试时，就可以测试10、11、12位数字。
2.3因果图
2.3.1定义
是⼀种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。简单的理解就是被测对象有多个输入条件，根据排列组合的数学概念，把多
个条件结合逻辑的关系(并且，或者)进行组合，得到一个输出的结果信息。
结合python代码理解，如下：
a(==)恒等：一个输入项只对应一个肯定的结果；
b(!=)非：一个输入项只对应一个否定的结果；
c(or)或：多个输入项，满足其中任意一项就会对应一个肯定的结果；
d(and)与：多个输入项，同时满足才会对应一个肯定的结果。
2.3.2实例
（1）boss直聘职位搜索
与
A、输入测试关键字+地区：西安，搜索到西安测试类的职位信息；
B、输入测试关键字+工作经验：1-3/学历：本科/薪资：5-10K/融资不限/规模不限+地区：背景，搜索到工作经验1-3年的/学历为本科/薪资5-10K/融资不限/规模不限西安测试类的职位信息；
C、关键字+工作经验+学历+薪资等多个条件组合，搜索对应条件的职位信息。
非
输入特殊字符搜索不到职位信息
2.4正交实验分解法
2.4.1定义
利用因果图来设计测试用例时，作为输入条件的原因与输出结果之间的因果关系，有时很难从软件需求规格说明中得到。往往因果关系非常庞大，以至于据此因果图而得到的测试用例数目多的惊
人，给软件测试带来沉重的负担，为了有效地，合理地减少测试的工时与费用，可利用正交实验设计方法进行测试用例的设计。简单来讲就是因果图结合排列组合设计出来的测试用例的个数是无
限扩张的，但是测试资源是有限的，所以在这个情况下，只需要选择有代表性的数据进行测试。
2.4.2实例
（1）boss直聘测试职位搜索代表性数据：
A、年限：1-3年、3-5年、5-10年
B、学历：大专、本科、研究生
C、地区：全国、北京、上海、广州、深圳、杭州、西安、武汉、成都
D、薪资：5-10k、10-15k
E、融资：都需要测
F、公司规模：都需要测
2.5错误推测法
2.5.1定义
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。简单的理解就是针对测试的对象，假设他可能出现某个问题，我们去进行测试，验证他是否真的会出
现我们假设的问题。
2.5.2实例
（1）如电商类网站，打开首页之后他只会加载当前能看到的页面的图片，随着我们向下滑动，图片会依次加载出来，那么在加载图片的过程中，可能会出现页面卡顿或者卡死的情况，这时候我
们就需要去测试验证是否真的会出现这样的情况。
（2）针对翻页的组件：数据很多时，某一页只展示当前页面的数据，后面的数据是随着翻页的过程中逐步加载的，那么可能就会出现页面卡死或者卡住。
（3）上传文件的组件：上传1G的文件，那么可能就会导致上传的文件缺失，或者是文件上传成功后，文件内容是乱码，还有可能会出现内存泄露。
（4）针对底层服务：可能会出现超时、堵塞、假死的情况。
2.6判定表驱动分析法
2.6.1定义
判定表是分析和表达多逻辑条件下执⾏不同操作的情况的工具，也就是考虑整个测试点的范围，在因果图和正交试验之前，用来定测试的范围和边界。
（1）优点：相较于因果图法，它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。
（2）适用场景：在⼀些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。
（3）判断表组成部分
A、条件桩（Condition Stub）：列出了问题的所有条件。通常认为列出的条件的次序无关紧要。
B、动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
C、条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
D、动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
（4）判定表驱动分析和因果图以及正交实验分解法的关联：
A、判定表驱动分析法：划分测试的边界和范围，列表需要测试不同的条件和范围；
B、因果图：在划分测试范围的基础上，列出各个条件的不同排列组合；
C、正交：在因果图的基础上，选择有代表性的数据；
2.6.2实例
（1）如boss直聘测试职位搜索的测试范围：职位关键字、地区、工作经验、学历、薪资要求、融资、公司规模及其范围。
（2）如在京东找到”python自动化测试实战“这本书，他的测试范围为：关键字、作者、出版社、计算机与互联网、品牌。
2.7场景设计法
2.7.1定义
这种在软件设计方面的思想也可以引⼊到软件测试中，可以比较⽣动地描绘出事件触发时的情景，有利于测试设计者设计测试⽤例，同时使测试用例更容易理解和执行。主要是从产品全流程考
虑，列出产品整个流程的业务场景，这里不仅需要考虑正常的业务逻辑，也需要考虑到异常的业务逻辑。
2.7.2实例
（1）如招聘类网站全流程的业务场景：
A、注册 B、登录 C、添加职位 D、搜索职位 E、查看详情 F、与hr沟通 G、文件上传（简历） H、修改职位 I、删除职位 J、退出
（2）电商类消费者购物的业务场景：
A、开始：商家上线产品，产品审核通过；
B、过程：买家搜索产品、查看产品详情、与商家沟通、产品收藏加购、下单支付、查看物流、确认收货；
C、结束：卖家下架产品，搜索不到产品。
如以商品上架为例，其正常和异常的业务场景：
A、上架审核通过，可以正常搜索购买；
B、审核失败，搜索不到产品；
C、库存为0，商品未下架。
2.8功能图分析法
2.8.1定义
⼀个程序的功能说明通常由动态说明和静态说明组成。动态说明描述了输⼊数据的次序或转移的次序。静态说明描述了输入条件与输出条件之间的对应关系。对于较复杂的程序，由于存在⼤量的
组合情况，因此，仅用静态说明组成的规格说明对于测试来说往往是不够的。必须⽤动态说明来补充功能说明。功能图方法是用功能图形式化地表示程序的功能说明，并机械地生成功能图的测试
用例。测试用例则是由测试中经过的⼀系列状态和在每个状态中必须依靠输⼊/输出数据满⾜的⼀对条件组成。功能图方法其实是是⼀种⿊盒与⽩盒混合用例的设计方法。
2.8.2实例
以电商类买家购买商品时搜索产品为例：
3、快速建立产品测试全局思维
（1）使用场景设计方法快速梳理出被测产品的核心业务逻辑；
（2）使用判定表驱动分析方法列出流程中可能的逻辑判断条件，使用功能图法列出产品的输入输出，完善每个不同条件下的业务场景；
（3）然后再使用等价类、边界值、错误推测法、因果图、判定表驱动法、正交试验法再去设计每个业务场景中的测试用例。
4、环境
（1）QA：测试环境，供测试使用的环境；
（2）预发布环境：产品上线前供内部人员访问的环境；
（3）生产环境（线上环境）：产品上线后，用户使用的环境。
5、测试用例评审
5.1步骤
（1）发起会议邀请；
（2）在约定的时间在会议室评审测试用例；
（3）评审结束后，完善测试用例；
（4）完善结束后，再次发出来。
5.2参与人员
产品、开发以及其他测试，谁发起的谁来主持。
5.3注意事项
别人的意见需要当场记录，有可能的话当场进行修改。
