软件测试基础理论、测试用例及设计方法、易混淆概念总结【软件测试】_软件测试理论

一.软件测试基础理论

1.软件定义

软件是计算机系统中与硬件相互依存的一部分，包括程序、数据以及与其相关文档
的完整集合。
程序是按事先设计的功能和性能要求执行的指令序列；
数据是使程序能正常操作信息的数据结构；
文档是与程序开发、维护和使用有关的图文材料。

2.软件测试定义

1983，IEEE给出了软件测试的标准定义：
使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满
足规定的需求或是弄清预期结果与实际结果之间的差别。

3.软件测试原则

所有的测试都应追溯到用户需求
尽早启动测试工作
早做测试计划
穷尽测试不可能
测试工作的 Good-enough 原则
Pareto 法则应用于软件测试
尽可能使用分阶段测试
应该由独立的第三方来构造测试

4.测试标准

国际标准：如 ISO、CMM（Capability Maturity Model，软件能力成熟度模型）、
IEEE（国际电气电子工程师协会）
国家标准：GB、GB/T
行业标准
公司标准
用户规定

5.软件生命周期

软件生命周期包括可行性分析、需求分析、概要设计、详细设计、编码、测试、维护7大阶段。
不同阶段对应的岗位及职责如下：

6.软件开发模型

瀑布模型（文档驱动模型）

优点：
	为项目提供各阶段的检查点
	可在迭代模型中应用瀑布模型
1
2
3

 缺点： 	
	各阶段划分比较固定，阶段之间会产生大量文档，增大工作量 	
 	由于开发模型为线性的，客户只能等到过程末期才见到效果，增大开发风险
 	无法适应用户需求的变化
1
2
3
4

增量模型（渐增模型）

优点：
	将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展
	以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。
	开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整
1
2
3
4

缺点：
	如果待开发的软件系统很难被模块化，那么将会给增量开发带来很多麻烦
	对项目管理人员管理全局水平有较高要求
	对开发人员有较高要求
1
2
3
4

快速原型模型（原型模型）

优点：
	增加用户与开发人员的交流
	用户在项目开发中占主导作用
	满足用户的动态需求
	降低开发风险
1
2
3
4
5

缺点：
	因为用户的参与，使得忽视原型对实际环境的适应性等技术问题，所以不适合大型、复杂项目开发
	对于技术层面远大于其分析层面的问题不宜使用快速原型法
1
2
3

螺旋模型（风险驱动模型）

优点：
	增加用户与开发人员的交流
	用户在项目开发中占主导作用
	满足用户的动态需求
	降低开发风险
1
2
3
4
5

缺点：
	因为用户的参与，使得忽视原型对实际环境的适应性等技术问题，所以不适合大型、复杂项目开发
	对于技术层面远大于其分析层面的问题不宜使用快速原型法
1
2
3

7.测试模型

V模型

优点：自上而下逐步求精，每个阶段分工明确，便于整体项目的把控
缺点：V模型是基于瀑布模型的，缺点是将测试放在整个开发的最后阶段，没有让测试今早介入开发，没有在需求阶段就进入测试。过程是线性、顺序的，无法反复、迭代。
1
2

W模型

优点：测试与开发并行，让测试今早介入开发环节，使测试今早发现问题尽早解决。
缺点：虽然开发与测试并行了，但是在整个开发阶段，仍然是串行的，上一阶段未完全完成无法进入下一阶段，不支持敏捷模式的开发。
1
2

H模型

特点：
它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测
试执行活动清晰地体现出来。测试贯穿产品整个生命周期，与其他流程并发地
进行。
软件测试不仅仅指测试的执行，还包括很多其他的活动（计划、需求分析、用
例设计、环境搭建、提交缺陷、评估总结等）。
当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。
软件测试要尽早准备，尽早执行。
软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按
照某个次序先后进行的，但也可能是反复的。
1
2
3
4
5
6
7
8
9
10

敏捷测试模型

极限编程：20 世纪 90 年代 Kent Beck 设计了一种名为极限编程（eXtreme Programming，XP）的新型软件开发方法。
极限测试：为了满足 XP 的流程和思想，开发人员使用了极限测试方法，该方法强调连续测试。测试在 XP 中的地位非常重要，所以需要首先创建单元（模块）测试和验收测试，然后才能创建代码库。这种形式的测试称为极限测试（eXtreme Testing，XT）。
特点:
	XP 模型需要客户参与，高度依赖模块的单元和验收测试。
	对任何一个递增的代码变更，开发人员都必须进行单元测试，以确保代码库满足其规格说明的要求。
	单元测试完成后，用户进行验收测试。
1
2
3
4
5
6

8.测试流程

测试工作包括以下步骤：需求分析、设计测试计划、设计测试用例、执行测试、测试评估。

各个阶段任务如下：
需求分析阶段：依据需求文档，设计、开发、测试三方举行会议，明确需求，消除歧义。
设计测试计划阶段：依据需求文档，由测试组长（测试经理/测试负责人）设计测试文档并召开评审。测试计划主要涉及功能模块的划分、人员安排、测试方法、测试工具、进度安排、资源分配、风险分析等。
设计测试用例阶段：依据需求文档、设计文档、用户手册，测试人员按分工设计测试用例，完成后进行评审，保证用例正确、覆盖全面、对需求无遗漏。
执行测试阶段：搭建环境、执行用例。
测试评估阶段：出具测试报告，上线或者打回。

9.软件测试阶段

单元测试：模块测试，验证软件的基本组成单位的正确性，是白盒测试
集成测试：模块间的测试，测试接口是否正确，是灰盒测试
系统测试：系统测试包括冒烟测试、系统测试、回归测试

冒烟测试：主干流程测试，确认软件的基本功能正常，可以进行后续的测试工作
系统测试：是检测系统的功能、质量、性能能否满足系统的要求，包括功能、性能、界面、可靠性、兼容性等等，是黑盒测试
回归测试：修改了旧代码之后重新进行测试，确认修改后的代码没有引入新的错误或导致其他代码产生新的错误

验收测试：是确保软件的实现能否满足用户的需求或合同的要求

10.软件测试分类

软件测试按不同维度划分有以下类型：功能测试、接口测试、性能测试、界面测试、易用性测试、兼容性测试、安全性测试文档测试、安装测试、数据库测试、本地化和国际化测试等。
按待测产品可以分为：web测试、app测试、小程序测试。
一般测试主要从功能测试、接口测试、界面测试、性能测试、可用性测试、兼容性测试、安全性测试六个维度进行，根据具体情况有所调整。

二.软件测试用例

1.测试用例思维导图

2.测试用例设计方法

（1）等价类划分法、边界值分析法

案例：qq登录账号检测模块（等价类划分+边界值分析）

登陆要求：

6-10（包括6，10）位数的账号

必须为整数，不能以0开头

划分等价类如下：

有效等价类：不以0开头的6、7、8、9、10位数字

无效等价类：以0开头的6、7、8、9、10位数字，小数、字母、特殊符号、汉字及其组合

部分测试用例设计如下：

（2）因果图法、判定表法

案例：公交卡充值系统（因果图法+判定表）

系统只接受50/100的纸币，一次只接受一张，只能充值50/100

若输入50纸币，选择充值50，完成充值后退卡，提示充值成功

若输入50纸币，选择充值100，提示错误：输入金额不足，并退回(找零)50元

若输入100纸币，选择充值50，完成充值后退卡，提示充值成功，找零50

若输入100纸币，选择充值100，完成充值后退卡，提示充值成功

若选择充值按钮后不投入纸币，提示错误

若投入纸币后规定时间不选择重新充值面额，退回纸币并提示错误

因果图分析：

原因：

条件1、2不能组合        条件3、4不能组合

条件1、3能组合        条件1、4能组合

条件2、3能组合        条件2、4能组合

条件1、2、3、4可单独出现
1
2
3
4
5
6
7

结果：

结果a、b必须组合        结果a、b、c可以组合

结果c、d可以组合        结果a、d不能组合

结果b、d不能组合        结果d可以单独出现
1
2
3
4
5

因果图绘制关键要素：

因果图样例：

（本案例绘制的因果图未附，可以阅读此文了解：《因果图法》-有这篇就够了 - 知乎https://zhuanlan.zhihu.com/p/129342944）

根据因果图画判定表如下：

根据判定表每一列设计测试用例，部分用例设计如下：

（3）场景法、流程分析法

（流程分析法大致了解，进一步了解可以阅读：黑盒测试用例设计方法之流程分析法 - 测试牛的文章 - 知乎https://zhuanlan.zhihu.com/p/115115339）

场景法业务流组成：基本流 + 备选流

案例：在线购物（场景法）

在线网站订购书籍，整个订购过程为：用户登录到网站后，进行书籍的选择，当选好自己心仪的书籍后进行订购，这时把所需图书放进购物车，等进行结帐的时候，用户需要登录自己注册的帐号，登录成功后，进行结帐并生成订单，整个购物过程结束。

基本流和备选流如下：

根据基本流和备选流来确定场景：

可以采用矩阵或决策表来确定和管理测试用例。在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。

以上表是把每个场景成立的条件进行了分析，基本上已经明确了测试用例的数量，现在只要把真实数据填充上，那么整个测试用例就完成了。

测试用例设计如下：

（4）正交表法、错误推断法

正交表法使用步骤：
1.制作取值表，不需要编号，列出数据即可。

2.复制表格中的数据放在一个新建的txt文本文档中，保存到allpairs文件夹中（例如：test2.txt）。

3.Win+r再输入cmd进入控制台界面， 进入allpairs文件夹中，输入allpairs.exe test2.txt>chenggong.txt （chenggong.txt是我们最终生成出来的正交表文件)。

4.打开allpairs的文件夹，可以看到chengong.txt正交设计表。根据正交设计表进行用例设计即可。

工具链接: https://pan.baidu.com/s/1pbgDwzoAEhIflK6J-SjYBw?pwd=5g52
提取码: 5g52
1
2

三.几个易混淆概念

1.测试 & 调试

2.软件质量保证 & 软件测试

小结

本次介绍了软件测试中的一些基础理论、测试用例以及设计测试用例的主要方法，附带了一些案例和相关资源。
​