自学软件测试Day1
本文系统介绍了软件测试的基本概念和常用方法。软件测试是通过预防、发现和跟踪缺陷来提高软件质量的过程,其核心目标是尽早发现缺陷。文章详细阐述了等价类划分法、边界值法、因果图法、判定表法、用户故事法和错误推测法等6种测试设计方法,并提供了用户名验证、订单检查等实例说明。同时介绍了测试用例设计三部曲、测试流程、需求评审、测试计划等内容,以及测试启动三原则和测试完成准则。全文涵盖了从测试设计到执行的完整流程,为软件测试工作提供了系统的方法论指导。
一、软件测试是什么?
在规定条件下对软件进行预防、发现、跟踪软件的缺陷,提高软件质量。
核心目标:尽早、尽快、尽多发现软件缺陷,促进软件质量与客户满意度的提升
二、软件测试设计方法
1.等价类划分法
是一种典型的、重要的黑盒测试方法,其将无穷的测试输入变成有限的输入,把程序的输入域分成若干等价类,从中选取少数代表性数据当做测试输入数据(n种→2种)
有效:范围以内,任意一个同等效果
无效:范围以外
1.1 等价有效类划分原则
①划分有效及无效等价类,为每一个等价类规定一个唯一的编号
②设计一个新的测试用例(数据),使其尽可能多的覆盖尚未被覆盖的有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止;
③设计一个新的测试用例(数据),使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆盖为止;
1.1.2 实例:用户名格式验证
系统要求用户名为6-12位字母数字组合,可以划分为:
- 有效等价类:长度6-12位数字字母组合,如:abc123
无效等价类:①长度小于6位,如:a123
②长度大于12位,如:abcd123456789
③长度为6-12位纯数字,如:123456
④长度为6-12位纯字母,如:ABCDabcd
⑤长度为6-12位包含非字母数字字符,如:ab123!@
⑥为空
1.2 边界值法
从划分的等价类里面选取数据,使等价类的每个边界都要作为测试条件
上点:边界上的点(6、12)
离点:离边界最近的点(5 、13)
内点:范围内的点(9)
离点:开内避外(开区间选择内部离点,闭区间选择外部离点)
边界值法必须与等价类划分法结合使用,因为边界值法只关注长度不关注类型
1.3因果图法
考虑输入数据之间的组合关系
分析需求规格说明中的描述中哪些是原因,哪些是结果
原因是输入条件,结果是输出条件 在等价类划分、边界值产生的有限条件后进行组合
因果图最终生成判定表,它适合于程序输入条件的各种组合情况 ,如果有N个条件,每个条件有2个取值,那么将产生2的N次方条路径
1.4 判定表
判定表是分析和表达多条件下执行不同操作的情况下的工具
判定表由以下四个组成部分:
-
条件桩:列出了问题的所有条件
-
动作桩:列出了问题规定可能采取的操作
-
条件项:列出特定条件的取值
-
动作项:列出在条件项目的各种取值情况下应该采取的动作
1.4.1 实例:订购单的检查
需求:如果金额超过500元,又未过期,则发出批准单和提货单:如果金额超过500元,但过期了,则不发批准单和提货单;如果金额小于等于500元,则不论是否过期都发出批准单和提货单,在过期的情况下还需要发出过期通知单
将这段需求进行判定表分析,可以得到如下判定表
条件-条件项:金额(大于500,小于等于500)
有效性(是,否)
结果:是否发出批准单,是否发出提货单,是否发出通知单
| 金额 | >500 | >500 | <=500 | <=500 |
|---|---|---|---|---|
| 状态 | 未过期 | 已过期 | 未过期 | 已过期 |
| 发出批准单 | ✅️ | ✅️ | ✅️ | |
| 发出提货单 | ✅️ | ✅️ | ✅️ | |
| 发出通知单 | ✅️ |
| 用例编号 | 用例标题 | 项目/模块 | 优先级 | 预置条件 | 测试步骤 | 测试数据 | 预期结果 |
|---|---|---|---|---|---|---|---|
|
order_check_001 |
金额大于500且未过期 |
订购单检查 |
P0 |
打开订单验证程序 |
1、输入金额:501 2、选择未过期 3、点击确定 |
1、金额:501 2、状态:未过期 |
发出批准单和提货单 |
|
order_check_002 |
金额大于500但已过期 |
订购单检查 |
p0 |
打开订单验证程序 |
1、输入金额:501 2、选择过期 3、点击确定 |
2、状态:过期 |
不发出任何单据 |
|
order_check_003 |
金额小于等于500元且未过期 |
订购单检查 |
P0 |
打开订单验证程序 |
1、输入金额:499 2、选择未过期 3、点击确定 |
1、金额:499 2、状态:未过期 |
发出批准单、提货单 |
|
order_check_004 |
金额小于等于500元但已过期 |
金额小于等于500元但已过期 |
P0 |
打开订单验证程序 |
1、输入金额:499 2、选择过期 3、点击确定 |
1、金额:499 2、状态:过期 |
发出批准单、提货单及过期通知单 |
order_check_001和order_check_003可以合并,因为无论金额大小,只要未过期,都发出批准单、提货单
|
order_check_001 |
金额不限且未过期 |
订购单的检查 |
P0 |
打开订单验证程序 |
1、输入金额:400 2、选择未过期 3、点击确定 |
1、金额:400 2、状态:未过期 |
发出批准单、提货单及过期通知单 |
1.5 用户故事法(场景法、用例法)
通过场景来对系统的功能点或业务流程的描述,从而提高测试效果的一种方法
模拟特定场景发生的事情,通过事件来触发某个动作的发生,观察事件的最终结果,从而用来发现软件存在的问题
模拟用户的行为,用户故事只是描述系统的外在行为 ① 用户做XX ② 系统做YY ③ 用户做ZZ ④ 系统做TT ⑤ ...
1.6 错误推测法
基于经验和直觉推理程序中可能出现的各种错误和容易发生错误的特殊情况
-
错误推测法常见依据
-
在单元测试时列出的模块中的常见错误
-
以前产品测试中曾经出现的错误
-
产品在客户实际使用过程中发现的错误
-
容易发生错误的情况
-
一些公共模块、功能
-
修改了bug的功能和模块
-
三、测试用例
3.1 什么是测试用例
测试用例就是设计一种情况,软件在这种情况下,能够正常运行并且达到期望执行结果
如果程序在这种情况下不能正常运行,而且这种问题会重复发生,那可能是一个软件缺陷
测试用例就是测试方法过程格式化、文档化
3.2 如何设计测试用例(三部曲)
①要测试什么——业务是什么(需求)
②怎么样测试——测试环境搭建
③如何判断正确与否——对照需求
3.3 软件测试流程

3.4 需求评审的目的
发现需求规格说明书中的问题,依据测试尽早介入的原则,尽早发现缺陷降低修复成本
与市场、产品、开发等人员在需求的理解上达成一致,避免因需求理解不一致导致后期的争吵
通过需求评审,更好的理解产品的功能与非功能性需求,为制定测试计划打下基础
确定测试目标和范围
3.5 什么是测试计划
叙述预定的测试活动范围、途径、资源以及安排进度的文档。确定了测试项、测试任务、人员安排及计划相关的风险
3.6 测试计划的作用
测试计划能给团队人员指明方向
计划可以减少不确定性对项目或团队造成的影响
计划可以减少无序和浪费
计划有利于管理和控制
3.7 测试计划的内容
-
测试范围
-
测试环境
-
测试策略
-
测试策略是指在一定的软件测试标准,测试规范的指导下,依据测试项目的特定环境约束而规定的软件测试的原则方式方法的集合
-
测试策略会根据项目的产品特点不同而做响应的策略
-
-
资源和时间进度安排
-
风险评估
3.8 测试启动三原则
⑴ 测试计划已经制定并且通过了审批;
⑵ 测试用例已经设计并且通过了审批;
⑶ 被测试对象已经开发完毕并等待测试。
3.9 测试何时结束
⑴ 基于测试用例的规则:如8000个用例
⑵ 基于 “ 测试期缺陷密度 ” 的规则:5天中bug数小于多少个,没有严重的bug
⑶ 基于 “ 运行期缺陷密度 ” 的规则
3.10 测试完成准则
对于非严格系统可以采用 “ 基于测试用例 ” 的准则。同时满足以下条件运行结束测试:
① 功能性测试用例通过率达到100%
② 非功能性测试用例通过率达到90%时
对于严格系统,应当补充 “ 基于测试期缺陷密度 ” 的规则:
① N天内 “ 测试期缺陷密度 ” 全部低于某个值M
浙公网安备 33010602011771号