为什么要写测试用例？
一、测试用例的设计方法
- 需求设计法
二、具体的设计方法
- 2.1 等价类
- 2.2 边界值
- 2.3 因果图
- 2.4 场景设计法
- 2.5 错误猜测法
- 2.6 正交法
三、测试分类
- 3.1 按开发阶段划分
- - 单元测试
  - 集成测试
  - 系统测试
  - - 回归测试
    - 冒烟测试
  - 验收测试
- 3.2 按测试实施组织
- - α测试和β测试的区别
  - 第三方测试
- 3.3 按是否运行划分
- - 静态测试(Static testing)
  - 动态测试(Dynamic testing)
- 3.4 按是否手工划分
- - 手工测试(Manual testing)
  - 自动化测试(Automation Testing）
- 3.5 按是否查看代码划分
- - 黑盒测试(Black-box Testing)
  - 白盒测试(White-box Testing)
  - 灰盒测试(Gray-Box Testing)
- 3.6 按测试地域划分
- - 国际化测试
  - 本地化测试
- 3.7 按测试对象划分
- - 按业务测试
  - 按照界面测试
  - 容错性测试
  - 文档测试
  - 兼容性测试
  - 易用性测试
  - 安装测试
  - 安全测试
  - 性能测试
  - 内存泄露测试

为什么要写测试用例？

复用性，回归测试的时候可以拿之前的测试用例进行回归
衡量测试需求的覆盖率
自动化测试的依据
方便其他人借鉴

一、测试用例的设计方法

从整体角度设计分析的测试用例

需求设计法

(1)验证需求的正确性和合理性。
(2)分析需求,细化需求,从需求中分解出测试项,根据测试项找出功能,进行测试用例的编写。
(3)功能性测试
界面功能的全面性测试（界面从上到下，从左到右）
按照业务的场景把一个个独立的功能串起来进行测试，验证功能之间的交互性和一致性，不能有冲突。
同一个功能不同的输入数据的测试。
同一个功能的异常数据，错误操作测试。
功能相关的算法的验证（一般用白盒测试，需要看代码，对代码进行直接测试）。
(4)非功能性测试
可靠性测试，容错性测试，安全测试，易用性测试，兼容性测试，可移植性测试。

例如：
用户需求:购买3000块钱以内的华为智能手机
测试用例：
1.价格<=3000元
2.品牌为华为
3.智能手机
4.手机功能验证：
4-1.打电话
4-2.接电话
4-3.发短信
4-4.收短信…

软件需求：事件流
1.若用户未收到激活邮件，可在登录界面录入电子邮件及密码后，再次发送激活邮件。
2. 每次发送的激活邮件，仅在发送邮件后起24小时之内有效，超过24小时后需重新发送激活邮件。
测试用例：
1-1、未收到邮件，登录时输入电子邮件及密码后，再次发送激活邮件
1-2、已收到邮件，登录时输入电子邮件及密码后，不发送激活邮件

2-1、收到邮件，24小时内进行激活
2-2、收到邮件，24小时后链接过期进行激活。
2-3、收到邮件，已激活，24小时后链接过期，再次点击激活？

页面检查：
1、收到激活邮件，邮件能不能打开。
2、邮件内容正确
3、激活URl正确，可激活
4、24小时内已经点击邮件激活了，24小时后再次激活提示已激活
5、24小时内已经点击邮件激活了，24小时之内又重新点击，不会重新激活，提示已激活。
6、过期激活提示已过期。

二、具体的设计方法

2.1 等价类

等价类就是把输入划分成若干个等价类，从每一个等价类中取出一个（多个）测试用例，如果这个测试用例能够测试通过，那么我们就说这个测试用例代表的等价类测试通过。
这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

等价类适用场景:测试用例无法进行穷举,测试用例无法一一进行测试.

有效等价类:符合程序规格说明的数据集合.
无效等价类:不符合软件需求规格说明的数据集合.

2.2 边界值

针对输入和输出的边界进行测试用例的设计。通常边界值分析法是作为对等价类划分法的补充。

例如：
购买3000块钱以内的华为智能手机
价钱:小于等于3000
等价类:
有效等价类:小于3000
无效等价类:大于3000
边界值:2999 、3000、3001

2.3 因果图

因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。

当输入很多，并且不同的输入组合对应着不同的输出，这个时候用因果图法来分析不同输入组合和输出之间的对应关系。

因果图:逻辑图

恒等

恒等：如果原因为真，那么结果必定为真。例如：动物园运来大熊猫，动物园一定有大熊猫

只有2个原因都为真，那么结果为真 例如：北京姑娘，必须有车且有房。

2个原因中有一个为真时，结果就为真。例如：长沙姑娘，你有车或者有房

只有原因为假，结果才为真。例如：你不好好学习，找到好工作。

因果图法设计测试用例的步骤:
1，分析出所有的输入和输出
2，找出输入和输出之间的关系
3，画因果图
4，画判定表
5，把判定表转换成测试用例

例：
淘宝618活动:订单金额满300，或者有红包，则提交订单后享受优惠。

输入和输出
输入:金额小于300，金额大于等于300，有红包，无红包，提交订单
输出:享受优惠，不享受优惠
输入和输出之间的关系
(1)订单已提交，订单金额大于等于300元，无红包，则优惠。
(2)订单已提交，订单金额小于300元，无红包，不优惠
(3)订单已提交，订单金额小于300元，有红包，则优惠。
(4)订单已提交，订单金额大于300元，有红包，则优惠。
(5)订单未提交，不优惠
画因果图
根据因果图画判定表
根据判定表写测试用例
订单已提交，金额大于300，有红包，有优惠
订单已提交，金额大于300，没有红包，有优惠
订单已提交，金额小于300，有红包，有优惠
订单已提交，金额小于300，没有红包，没有优惠
订单没有提交，金额大于300，有红包，没有优惠
订单没有提交，金额大于300，没有红包，没有优惠
订单没有提交，金额小于300，有红包，没有优惠
订单没有提交，金额小于300，没有红包，没有优惠

因果法设计测试用例可以帮助测试人员理清输入和输出的关系，但是对于比较复杂的输入和输出，会耗费大量时间。

2.4 场景设计法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，使测试用例更容易理解和执行。

例：
ATM取款场景
插卡—输入密码—输入钱数—取款
(1）插卡:插反了，插错卡（饭卡，会员卡，公交卡，不是本行的)
注销，消磁，冻结
有不良记录的卡
插卡插反了，第二次重新正确插入，仍然可以正常取钱;
卡注销/冻结，无法正常取钱，会给用户提示“卡已经注销/冻结”

(2)输入密码:密码错误，密码输入正确，
密码输入三次错误，账户被冻结，无法取款
密码第一次输入错误，第二次输入正确密码，取款流程正常向后推行;
前两次输入错误，第三次输入正确，取款流程正常向后推行;

(3）输入的钱数小于等于银行卡余额
输入的钱数大于银行卡余额
输入的不是整百
ATM机余额不足
超过每日取款限额
超过每次取款最大上限
超过每次取款最大次数
(4）取款:
确认取款钱数后，ATM机会吐出相应的钱数，ATM机吐钞规则
操作超时，长时间不取吐出的钱
ATM机:断网，断电，出现故障

2.5 错误猜测法

根据测试人员的直觉，知识，经验，判断软件的哪一块有问题，专门针对性的设计测试用例。适合作为一种补充设计测试用例的方法。

以注册为例：
1、校验中特殊字符空格的处理?
2、密码校验中的大小写？
3、姓名中的特殊字符？
4、密码发送是否明文？

2.6 正交法

正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。
研究多因素多水平的一种方法，根据正交性选出最优的水平组合进行试验，用实验的结果来分析这个测试用例的结果。

因素:输入变量
水平:因素的取值

正交表的构成：
因素数:变量的个数
水平数:变量取值的最大个数
正交表的表示形式：
行:L=(水平数-1）*因素数+1
列:因素数
正交表的性质:
1.每一列不同数据出现的次数一样多
2.任意两列各数据组台出现的次数一样多

正交表设计测试用例的步骤
1，找出所有的输入变量，确定因素数
2，确定变量的取值，确定水平数
3，确定正交表的行和列
4，根据正交表的性质去填写正交表
5，把正交表的每一行对应写成一个测试用例
6，补充你认为重要但没有体现在正交表中的测试用例

三、测试分类

3.1 按开发阶段划分

单元测试

单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。测试的对象是软件设计的最小单位：模块。又称为模块测试。
测试阶段：编码后或者编码前（TDD Test-Driven——Development）
测试对象：最小模块
测试人员：白盒测试工程师或开发工程师
测试依据：代码和注释+详细设计文档
测试方法：白盒测试
测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试

集成测试

集成测试也称联合测试（联调）、组装测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。集成主要目的是检查软件单位之间的接口是否正确。

按照一定的策略把单元功能模块组装起来，对组装起来的模块进行测试。
测试阶段:单元测试之后
测试依据:概要设计文档
测试对象:接口
测试方法:黑盒和白盒相结合
测试人员:黑盒测试工程师和白盒测试工程师
测试内容:模块和模块之间的接口，全局数据结构的测试，单个模块的缺陷对整个功能的影响，模块功能的正确性，冲突。

系统测试

将软件系统看成是一个系统的测试。包括对功能、性能以及软件所运行的软硬件环境进行测试。时间大部分在系统测试执行阶段，包括回归测试和冒烟测试。

测试阶段:集成测试之后
测试依据:详细设计文档
测试对象:整个软件系统
测试方法:黑盒测试
测试人员:黑盒测试工程师
测试内容:功能，界面，性能，易用性，安全性，兼容性，可靠性，可移植性等。

回归测试

回归测试:当系统引入新代码的时候，进行回归测试
增加新功能
修改系统的BUG
回归测试的策略:自动化测试

冒烟测试

冒烟测试:对系统的主要功能和核心流程进行测试
正式进行系统测试之前，测试人员是否接受本次迭代正式测试的依据。

验收测试

验收测试是部署软件之前的最后一个测试操作。它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，按照项目合同、任务书、双方约定的验收依据文档，向软件购买都展示该软件系统满足原始需求。
系统文档（产品设计文档，用户功能使用手册，产品使用说明书等)
测试阶段:系统测试之后
测试依据:用户需求
测试方法:黑盒测试
测试人员:用户
测试内容:和系统测试一致，增加了文档测试

3.2 按测试实施组织

α测试和β测试的区别

测试人员：α是除了测试人员和开发人员以外的任何人，β测试是实际用户
测试环境:α在开发环境下，β在实际使用环境下
β测试之前要进行很长一段时间α测试，产品面向用户正式发布之前，会进行β测试

第三方测试

介于开发方和用户方间的组织的测试。

3.3 按是否运行划分

静态测试(Static testing)

不运行代码，通过静态分析代码的语法、编写规范、逻辑、结构、实现的功能来判断软件是否满足用户的需求。

静态测试的标准:

动态测试(Dynamic testing)

运行软件，进行测试。

3.4 按是否手工划分

手工测试(Manual testing)

手工测试（黑盒测试），测试人员先写测试用例，运行系统，执行测试用例，分析结果。

优点：自动化无法替代探索性测试、发散思维结果的测试。
缺点：执行效率慢，量大易错，会花费大量的时间。

自动化测试(Automation Testing）

机器按照预先设定好的条件去运行系统。
自动化脚本：把手工测试的测试用例转化成脚本。

自动化测试的条件：系统功能稳定之后。

3.5 按是否查看代码划分

黑盒测试(Black-box Testing)

黑盒测试也称功能测试，测试中把被测的软件当成一个黑盒子，不关心软件内部的结构、逻辑、功能的具体代码实现，只关心软件的输入与输出数据是否满足用户的需求。

黑盒测试设计测试用例的方法有哪些？
等价类、边界值、因果图、场景法、错误猜测法等。
按照开发阶段划分的那几个阶段用的是黑盒测试？
集成测试、系统测试、验收测试

白盒测试(White-box Testing)

白盒测试又称结构测试。
白盒测试：把软件看成一个透明的盒子，去测试软件内部代码的逻辑、结构、功能是否满足用户需求。
接口测试也是白盒测试的是一种。
白盒测试的方法：语句覆盖、循环覆盖、逻辑覆盖（路径覆盖、条件覆盖、判定覆盖、条件组合、判定组合）

灰盒测试(Gray-Box Testing)

即关心软件的输入和输出，又关心软件内容的逻辑结构功能的实现。

3.6 按测试地域划分

国际化测试

软件的国际化和软件的本地化是开发面向全球不同地区用户使用的软件系统的两个过程。而本地化测试和国际化测试则是针对这类软件产品进行的测试。由于软件的全球化普及，还有软件外包行业的兴起，软件的本地化和国际化测试俨然成为了一个独特的测试专门领域。

软件国际化：在设计软件的时候，使用一种工程技术，使得软件在转化成不同国家的语言和适应不同国家风俗习惯的时候，不需要去修改源码，叫做软件国际化。

本地化和国际化测试与其他类型的测试存在很多不同之处。下面是本地化和国际化测试的一些要点。
1、本地化后的软件在外观上与原来版本是否存在很大的差异，外观是否整齐、不走样。
2、是否对所有界面元素都进行了本地化处理，包括对话框、菜单、工具栏、状态栏、提示信息（包括声音的提示）、日志等。
3、在不同的屏幕分辨率下界面是否正常显示。
4、是否存在不同的字体大小，字体设置是否恰当。
5、日期、数字格式、货币等是否能适应不同国家的文化习俗。例如，中文是年月日，而英文是月日年。
6、排序的方式是否考虑了不同语言的特点。例如，中文按照第一个字的汉语拼音顺序排序，而英文按照首字母排序。
7、在不同的国家采用不同的度量单位，软件是否能自适应和转换。
8、软件是否能在不同类型的硬件上正常运行，特别是在当地市场上销售的流行硬件上。
9、软件是否能在Windows或者其他操作系统的当地版本上正常运行。
10、联机帮助和文档是否已经翻译，翻译后的链接是否正常。正文翻译是否正确、恰当，是否有语法错误。软件本地化和国际化测试是一个综合了翻译行业和软件测试行业的测试类型。它要求测试人员具备一定的翻译能力、语言文化，同时具备测试人员的基本技能。

本地化测试

上述所讲的均是本地化测试。

3.7 按测试对象划分

按业务测试

ATM取款机取款流程 —> ATM取款机取款业务
把一个个孤立的功能点按照一定的策略组合在一起，形成一个业务，对这个业务进行测试，就是业务测试。
用场景设计法来进行测试。

按照界面测试

界面测试（简称UI测试)
测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯，此外还要测试界面操作便捷性、导航简单易懂性，页面元素的可用性，界面中文字是否正确，命名是否统一，页面是否美观，文字、图片组合是否完美等。

布局（图片的位置、文字的展示、各种控件的展示）
文字：标题、字号、粗细、是否斜体，字体、是否下划线
图片：位置是否合适，大小，是否遮挡，是否不清晰
控件：按钮，滚动条是否可以正常使用，CheckBox
页面元素有效无效的状态:有效：高亮展示，无效：灰色弹出框，提示框位置布局是否合理
用户操作下一步，是否容易操作
页面测试常见的BUG:不合适的快捷键，丢失的文字，截断，自动换行，重叠，重复的快捷键，没有对齐

响应式页面:页面可以响应不同大小的浏览器，在不同大小的浏览器下有不同的合理的展现形式。 PC iPad 手机屏幕大小不一样
响应式页面的测试:
1，页面大小进行切换的时候，切换过程页面元素展示无缝衔接，丝滑，不会出现页面空白，图片或功能丢失
2，页面从大到小切换，页面图片，文字，都不会丢失。
3，页面从大到小切换，页面功能不丢失，并且可以正常使用;
4，页面从大到小切换，都遵循UI界面设计需求。

容错性测试

当系统由于外部环境或者用户不当引起一些问题的时候，系统可以自我消化掉这些错误，不直接展示给用户。
数据级别:时间，货币;
校验级别:前后空格，验证码，同系统前后信息一致;
环境级别:断网，断电，服务器瘫痪无缝切换
界面级别:界面会屏蔽违规违法操作，对于一些固定的输入，可以使用下拉框或者固定信息选择，模糊匹配，对于一些复杂或者危险的操作，有详细的用户提示信息;
失效恢复性测试：故意人为的让系统受到一些破坏、破坏系统的网络、电源、攻击系统的服务器，等到系统恢复正常的时候，用户的数据信息可以正常恢复。（用户信息数据是否可以完全恢复，系统恢复数据所需要的时间;）

文档测试

文档测试的关注点：
文档的术语
文档的正确性
文档的完整性
文档的一致性
文档的易用性

兼容性测试

兼容性主要是指软件之间能否很好的运做，会不会有影响、软件和硬件之间能否发挥很好的效率工作，会不会影响导致系统的崩溃。
平台测试:
PC : Windows (7，8，10)不同品牌的电脑上
lOS(MAC) iOS不同的版本
手机端︰
Android:不同的Android系统，不同品牌的手机全向用例测试ios:不同的IOS版本在不同的苹果手机版本上测试
Windows:
浏览器的兼容性:
Firefox、 Chrome、 edge、 360、 QQ 、UC、搜狗、 IE、夸克、 Safari(手机端和PC)、Opera，不同的浏览器有不同的版本，可进行自动化测试。
软件本身向前或者向后的兼容性；
软件和其他相关软件的兼容性；
数据的兼容性。

易用性测试

又称为用户体验测试。

需要遵循一定的标准和规范：（软件行业默认的）比如弹框的提示信息（白色）、警告（黄色）及严重错误（红色）的默认颜色。
直观性：（日历的显示，让人一目了然）
灵活性：用户可以有多种选择，可以选择自己认为比较方便的使用方式。（比如输入法中的九宫格和全键）
舒适性：比如进度条（上传、下载、移动文件的时候）
实用性：软件的设计和软件的定位一致。

安装测试

测试程序的安装、卸载
典型的是app的安装、卸载

安全测试

安全测试是一个相对独立的领域，需要更多的专业知识。例如web的安全测试，需要熟悉各种网络协议TCP\HTTP，防火墙，CDN，熟悉各种操作系统的漏洞，熟悉路由器等。从软件来说，熟悉各种攻击手段，例如SQL注入、Xss等。

性能测试

系统是否可以很快响应用户的请求；
在超过用户负载的情况下，系统是否可以稳定的运行;
系统要在预期和非预期的情况下，用户有良好的体验;
响应时间，点击率，事务平均响应时间(TPS)，系统运行的时候占用的资源使用情况。

内存泄露测试

内存泄漏的坏处:系统的可以用内存越来越少;系统运行越来越慢;长期运行系统可能会崩溃。

内存泄漏的原因:

分配了内存，忘记回收；
API函数使用不正确；
函数写的有问题，无法释放内存；
分配的内存没有及时释放。
查内存泄漏：静态测试、工具测试。

测试用例的设计方法及测试分类相关推荐

测试篇(三)：测试用例的万能公式、对水杯和登录页面设计测试用例、测试用例的设计方法
目录一.测试用例的万能公式二.对登录页面设计测试用例三.测试用例的设计方法 3.1 基于需求的设计方法 3.2 等价类 3.3 边界值 3.4 判定表 3.5 正交排列 3.6 场景设计法 3. ...
2021最详细的测试用例的设计方法及案例——骚操作
测试用例的设计方法一．概念 1.什么是测试用例? 在测试过程中很重要的一类文档,它是测试工作的核心.是一组在测试时输入输出的标准.是软件需求的具体对照. 2.测试用例的作用: 检验软件是否满足客户需 ...
（转）测试用例的设计方法（全）之二错误推断、因果图
测试用例的设计方法(全)之二 (3)错误推测方法一. 方法简介 1. 定义:基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 2. ...
3.4 黑盒测试用例的设计方法之等价类划分与边界值分析
3.4 黑盒测试用例的设计方法具体的黑盒测试用例设计方法包括等价类划分法.边界值分析法.场景法.错误推测法.因果图法.判定表驱动法.正交试验设计法.功能图法等. 这些方法是比较实用的,但采用什么方法 ...
（转）测试用例的设计方法（全）之三判定表、正交实验
测试用例的设计方法(全)之三 (5)判定表驱动分析方法一. 方法简介 1.定义:判定表是分析和表达多逻辑条件下执行不同操作的情况的工具. 2.判定表的优点能够将复杂的问题按照各种可能的情况全 ...
测试用例的设计方法（全）
测试用例的设计方法(全) 等价类划分方法: 一.方法简介 1.定义是把所有可能的输入数据,即程序的输入域 ...
测试用例的设计方法及案例
测试用例的设计方法一.软件测试的生命周期(软件测试的流程是什么?) 二.如何描述一个BUG? 三.测试用例的设计方法 3.1等价类 3.2边界值法 3.3因果图法 3.4场景设计法 3.5正交排列法 ...
测试用例及其设计方法
测试用例测试用例的定义※ 设计一个情况,软件程序在这种情况下,必须能够正常运行并且达到程序所设计的预期结果. 测试用例的模板包括和包含的内容测试用例模版: 标识符:由测试设计过程说明和测试程序说明 ...
软件测试学习笔记：测试用例的设计方法（全）
测试用例的设计方法(全) 等价类划分方法: 一.方法简介 1.定义 2.划分等价类: (1)有效等价类 (2)无效等价类 3.划分等价类的标准: 4.划分等价类的方法 5.设计测试用例二.实战演习 ...
【软件测试】测试用例的设计方法大全
1.测试用例的八要素用例编号:用于标识当前的用例,具有唯一性和易识别性测试项目:对当前测试用例的子项有进一步说明的作用测试标题:简单说明测试的目的,便于他人理解重要级别:一般分为高.中.低三个 ...

测试用例的设计方法及测试分类

目录