一、软件测试理论
1.软件缺陷:软件产品(文档、数据、程序)中存在的问题,最终表现为用户需要的功能没有完全实现,不能满足或不能全部满足用户的需求。
软件缺陷表现:设计不合理,不是用户所期望的风格、格式,部分实现了软件功能,系统界面混乱,数据结果不正确、精度不够,存取时间过长、界面不美观,超出范围,难以理解
例:千年虫、北京奥运会
2.软件测试:使用人工或自动手段,运行或测定某个软件系统的过程,目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
软件测试与质量的关系:软件测试作为一种辅助且必需的手段,客观反映某个时间段内的软件质量。软件测试是实现软件质量保证的一种途径。软件测试是软件质量技术所采取的主要技术。
1)软件测试与软件开发的关系
① 同时开始、同时结束,同步。
② 测试过程是对开发过程中阶段性成果和最终产品进行验证的过程,两者相互依赖。前期,测试更多依赖开发;后期,开发更多依赖测试。
③ 工作重点可能不同,各有特点。
2)软件测试目的:检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
① 测试是为了证明程序有错,而不是证明程序无错。
② 一个好的测试用例在于它能发现至今未发现的错误。
③ 一个成功的测试是指发现了至今未发现的错误的测试。
目标:以最少时间和人力找出软件中潜在的各种错误和缺陷,证明软件功能和性能与需求说明相符。
3)软件测试原则
① 软件测试是证伪而非证真。
② 尽早地和不断地进行软件测试。
③ 重视无效数据和非预期的测试。
④ 应当对每一个测试结果做全面检查。
⑤ 测试现场保护和资料归档。
⑥ 程序员应避免检查自己的程序。
⑦ 充分注意测试中的群集现象。
⑧ 用例要定期评审,适时补充修改用例。
3.软件测试的基本思路
1)增加/注册:必填项、最大长度、判重、字段具体属性、字段数据组合
2)修改:↑+考虑什么类型的数据允许修改
3)删除:能否删除、数据库是否已删除、删除权限、批量删除出现异常
4)查询:不输入查询条件、单条件、组合查询项、默认条件查询、模糊/精确查询
5)导入/导出:文件格式、文件大小、文件数据格式、结果正常/异常
6)计算/业务流程:所有可能出现的情况
4.测试用例:为特定目标而开发的一组测试输入、执行条件和预期结果,其目标可以是测试某个程序路径或核实是否满足某个特定的需求。
1)为什么需要测试用例?
① 更有效、更快地发现软件缺陷。
② 具有很高的有效性和可重复性,依据测试用例进行测试可以节约测试时间,提升测试效率。
③ 具有良好的组织性和可跟踪性,有利于测试的管理。
5.软件测试过程(生命周期):测试计划、测试设计、测试开发、测试执行、测试评估
其中,测试执行按测试阶段划分,包括
1)单元测试:对软件中最小的可测试单元进行检查和验证。程序的多个模块可以并行地进行单元测试。主要用白盒测试
① 时间:编码后,代码通过编译后
② 人员:白盒测试工程师/开发人员(开发人员最好交叉测试)
③ 依据:A.源程序本身,代码+注释 B.开发文档
④ 通过标准:A.通过所有测试用例 B.语句覆盖率100% C.分支覆盖率85%
⑤ 一般步骤(白盒测试):
A.编译运行程序
B.静态测试 《编码规范》检查代码是否符合规范
C.动态测试 《测试用例》动态运行代码,检查实际运行结果
⑥ 模块:
※ 模块接口测试:全局变量定义一致性,调用参数
※ 局部数据结构测试:数据定义、使用
※ 执行路径测试:关键路径、重要路径
※ 错误处理测试:非合理输入、系统异常
※ 边界条件测试:循环边界、输入边界
⑦ 单元测试的辅助模块
※ 驱动模块:模拟被测模块的上一级模块(被测模块的主程序),用于接收测试数据,并把这些数据传给被测模块,启动被测模块,最后输出实测结果。
※ 桩模块:模拟被测模块所调用的模块。
2)集成测试:将已通过测试的单元模块组装成系统或子系统,再进行测试,重点测试不同模块的接口部分。灰盒测试
① 时间:和单元测试同步进行,在单元测试先测试几个函数功能,再集成测试这几个函数的接口(参数传递)
② 人员:白盒测试工程师/开发人员
③ 依据:A.单元测试模块 B.《概要设计》文档
④ 方法:
⑤ 增量式集成设计方法:课本p23-28
※ 自顶向下:深度优先/宽度优先,越重要越优先,大量桩程序
※ 自底向上:基础函数优先,需要创建驱动程序
※ 三明治:混合
3)确认测试:验证软件有效性,验证软件功能及其他特性是否与用户的要求一致。黑盒测试
基础:需求规格说明书包含的用户需求信息
4)系统测试:验证软件产品是否符合质量特性要求。黑盒测试
包括易用性测试、性能测试、安全测试、兼容性测试
5)验收测试:系统测试后期,以用户测试为主,或有测试人员等质量保证人员共同参与的测试,它也是软件正式交给用户使用的最后一道工序。
① Alpha测试:由用户、测试人员、开发人员共同参与的内部测试(内测)
② Beta测试:内测后的公测,完全交给最终用户的测试(公测)
③ 冒烟测试:版本验证测试/版本准入测试,意指软件版本进入正式测试阶段之前,对其主要功能进行验证,确认是否存在阻塞性缺陷。
④ 回归测试:修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
⑤ 随机测试:根据测试者的经验对软件进行功能和性能的抽查。
6.软件测试分类
软件测试 | 按开发阶段 | 单元测试 | ||
集成测试 | ||||
确认测试 | ||||
系统测试 | ||||
验收测试 | ||||
是否运行 | 动态测试 | |||
静态测试 | ||||
是否查看源代码 | 白盒 | |||
黑盒 | 功能 | 逻辑功能测试 | ||
界面测试 | ||||
易用性测试 | ||||
安装测试 | ||||
兼容性测试 | ||||
性能 | 一般性能测试 | |||
稳定性测试 | ||||
负载测试 | ||||
压力测试 | ||||
灰盒 | ||||
其它 | 冒烟测试 | |||
回归测试 | ||||
随机测试 |
7.软件测试模型 p9-10
1)V模型:左开发右测试
明确开发和测试各个阶段之间的对应关系
局限性:忽视了需求分析、系统设计等活动
2)W模型:测试开发同步,无法支持迭代开发模型
增加了各开发阶段中应同步进行的验证和确认活动,有利于尽早地发现问题
二、黑盒测试
1.黑盒测试:也称功能测试,完全不考虑程序内部结构和内部特性,对程序接口进行测试,只检测每个功能是否都能正常使用。
2.等价类划分法:等价类指某个输入域的子集合。在该子集和中,测试某等价类的代表值=测试该等价类的其他值,对于揭露程序的错误是等效的。
1)有效等价类和无效等价类
① 有效等价类:合理的、有意义的输入数据构成的集合
② 无效等价类:无意义、不合理的输入数据构成的集合
2)等价类划分原则
规定输入数据的 | 可确定 |
取值范围 | 1个有效,2个无效(a<=X<=b) |
集合 | 1个有效(符合规则),n个无效(从不同角度违反规则) |
数值 | n个有效(每个允许值1个),1个无效(所有不允许值的集合) |
规则 | n个有效(细分),n个无效 |
3)使用等价类划分法确定测试用例
① 为等价类表中的每个等价类唯一编号
② 设计一个新测试用例,使它能够尽量覆盖尚未覆盖的有效等价类,重复直到所有有效等价类均被测试用例所覆盖
③ 设计一个新测试用例,使它仅覆盖一个尚未覆盖的无效等价类,重复直到所有无效等价类均被测试用例所覆盖
3.边界值分析法:对输入或输出的边界值进行测试的一种黑盒测试方法。
1)如何确定边界值
项 | 举例 |
字符 | 允许输入1-255个字符,①有效等价类:1、255 ②无效等价类:0、256 |
数值范围 | 输入域1-999,测试4个:0、1、999、1000 |
空间 | 比零空间小一点/比满空间大一点 |
① 一般边界值分析:Min、Min+、Max-、Max(+Normal,共4n+1个测试用例)
② 健壮边界值分析:Min-、Min、Min+、Max-、Max、Max+(6n+1个测试用例)
4.决策表(判定表)法:分析和表达多逻辑条件下执行不同操作的情况的工具。
条件桩 | 条件项 |
动作桩 | 动作项 |
条件桩:列出问题的所有条件
条件项:条件桩条件所有可能的取值
动作桩:列出问题规定的可能采取的操作
动作项:条件项各组取值情况下应采取的动作
1)规则的简化和合并:
如果两条或多条规则动作项相同,条件项只有一项不同,则可合并,合并后的条件项用符号“-”表示,说明执行的动作与该条件的取值无关,称为无关条件。
5.因果图法:一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,适合于检查程序输入条件的各种组合情况。PPT第4课28-33
1)原因-结果图(输入输出关系)
(a)恒等:e1 = c1
(b)非:e1 = !c1
(c)或:e1 = c1 || c2 || c3
(d)与:e1 = c1 && c2
2)约束图(约束关系)
① E约束(Exclusive,异或):a和b至多一个1,a和b不能同时为1
② I约束(Inclusive,包含):a、b、c至少一个1,a、b、c不能同时为0
③ O约束(One and Only,唯一):a和b必须有一个,且仅有一个为1
④ R约束(Require,要求):a是1时,结果b是1
⑤ M约束(Masks,强制、屏蔽):a是1时,结果b是0
三、白盒测试
1.白盒测试:根据模块内部结构,基于程序内部逻辑结构,针对程序语句、路径、变量状态等进行测试。
1)单元测试主要采用白盒测试,辅以黑盒测试
白盒测试:用于代码评审、单元程序
黑盒测试:用于模块、组件等大单元的功能测试
2)分类
① 静态白盒测试:一种不执行程序而进行测试的技术,检查软件的表示和描述是否一致,没有冲突或者没有歧义。
编译器、人工方法(代码检查法、静态结构分析法:关系图、控制流图)
常见问题:
- 程序没有注释:程序 = 代码 + 注释;注释语句/总代码行数 = 1/5 ~ 1/4
- 精度丢失
- 程序存在未使用的变量
- 函数返回值
② 动态白盒测试:软件执行,当软件系统在模拟或真实环境中执行前、中、后,对软件系统行为的分析。显示一个系统在检查状态下是否正确。
2.逻辑覆盖法:通过对程序逻辑结构的遍历实现对程序的覆盖,一系列测试过程的总称。
(1)逻辑覆盖法开始前的准备工作
① 分析程序源代码
② 根据程序源代码画出对应的程序结构图
(2)以不同的覆盖项作为测试标准:(5种)
覆盖项:作为测试基础的一个入口或属性,比如语句、判定(分支)、条件等。
1)语句覆盖(SC,Statement Coverage):设计若干用例,使每个可执行语句至少被执行一次(所有的矩形框)
2)判定/分支覆盖(DC,Decision Coverage):设计若干用例,使每个判断取真分支和取假分支至少经历一次,即判断真假值均曾被满足(所有菱形框出来带有T/F的线)
3)条件覆盖(CC,Condition Coverage):设计若干用例,使每个判断中的每个条件的可能取值至少满足一次。
(比如条件a>0 and b>0,需要对a>0有T/F两种取值,也需要对b>0有T/F两种取值)
4)条件判定覆盖(CDC,Condition/ Decision Coverage):判定+条件,使所有条件可能取值至少执行一次、所有判断的可能结果至少执行一次。
5)条件组合覆盖(MCC,Multiple Condition Coverage):使判断中每个条件的所有可能至少出现一次,每个判断本身的判定结果也至少出现一次,所有组合都至少出现一次。
3.基本路径:程序所有路径中的最短路径。
基本路径测试:在不能做到所有路径覆盖的前提下,如果某一程序的每一个独立路径都被测试过,那么可认为程序中的每个语句都已经检验过了,即达到了语句覆盖。
圈复杂度:为程序逻辑复杂性提供定量的测度,用于计算基本独立路径数目,确保所有语句至少执行一次的测试数量的上界。
1)主要步骤:
① 绘制控制流图
② 计算V(G) = 边E – 点N + 2 = 区域数 = 判断节点数 + 1= 基本独立路径数目
③ 确定独立路径的集合,独立路径必须包含一条在定义之前没用过的边
④ 生成测试用例,确保基本路径集中每条路径的执行
注意事项:
- 在选择或多分支结构中,分支的汇聚处应有一个汇聚节点。
- 边和节点圈定的区域称为区域,图形外的区域也应记为一个区域。
2)复合条件下生成控制流图:
3)程序流程图->控制流图->控制流图矩阵
四、性能测试
1.性能测试:测试在一定条件下系统行为表现是否满足需求规格的性能指标。
1)模拟真实生产环境,以各种不同的压力去测试、“攻击”被测系统。同时记录下各台服务器的各种重要资源情况,包括CPU、内存、磁盘和网络等资源。
2)性能测试之前要做好系统备份。
3)性能测试时首先要看性能需求(规格说明中的性能指标),如没有要凭借和客户交流的信息、被测系统资料、经验等去编写性能测试计划,进行性能测试。
2.性能指标
1)响应时间:对请求做出响应所需要的时间。
页面响应时间 = 网络传输时间 + 应用延迟时间(数据库 + 应用服务器)
交易响应时间:系统完成事务执行准备和完成待执行事务后所采集的时间戳之间的时间间隔,是衡量特定类型应用事务性能的重要指标,标志用户执行一项操作大致需要的时间。
2)并发用户数
① 同时,同类操作
② 同时,同类/不同类操作
- 并发强调所有用户必须在同一时刻对服务器进行施压
- 强调要与服务器进行数据交互
3)吞吐量:在一次性能测试过程中,网络上传输数据量的总和。
交易吞吐量:系统服务器每秒能处理通过的交易数。
80~20原理:吞吐量 = 事务数 x 80% / 交易时间 x 20% (trans/s)
① 一般在系统设计范围内,吞吐量随并发用户数增加而增加
② 超出范围后,可能:
情况1:系统只能处理这么多,超过不接收,最后呈现水平直线
情况2:不管多少都接收,吞吐量下降,系统崩溃
4)性能计数器:描述服务器/操作系统性能的一些数据指标,如使用内存数、进程时间等,在性能测试中发挥着“监控和分析”作用。
资源利用率:CPU利用率、内存占用率、磁盘使用率、网络等,分析服务器出现瓶颈和对其进行配置调优的主要依据
5)思考时间(休眠时间):用户在进行操作时,每个请求之间的时间间隔。
模拟用户向服务端发送一个请求后,会等待一段时间再发送下一个请求。
6)点击率:每秒钟用户向服务器提交的HTTP数量。
对Web系统,点击率是服务器处理的最小单位,点击率越大能承受的压力越大。
3.常见的性能测试
1)基准测试、并发测试、联机测试、综合场景测试:
① 验证测试场景
② 获得软件的性能指标数据
2)负载测试:通过测试系统在超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。
目标:确定并确保系统在超出最大预期工作量的情况下仍能正常运行。
执行方式:一次加载、递增加载、高低突变加载、随机加载
① 不断增加被测系统的负载量
② 观察不同负载下被测系统响应时间、所耗资源等
③ 直到系统性能瓶颈
3)压力测试:也称强度测试,是在强负载(大数据量、大量并发用户等)下的测试,通过查看应用系统在峰值使用情况下的操作行为,发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。
① 不断增加系统的负载量
② 直到系统失效
③ 观察长时间或系统失效下的状态