第一部分软件测试概述
软件测试概述——内容概要
软件测试概要
一:软件与系统工程领域标准
-
2020.4.28,发布软件与系统工程领域5项国家标准,分别是GB/T38634.1~ GB/T 38634.4, GB/T 38639。
-
GB/T 38634:适用于各个企业、测评机构规范软件测试过程,建立适合自己情况的软件测试管理和执行能力。其中第1部分规定了软件测试的通用概念;第2部分详细说明了软件测试过程模型;第3部分规定了测试过程中产生的测试文档的模板和实例;第4部分规定了测试过程中使用的软件测试技术。
-
GB/T 38639:规定了软件组合测试方法的测试对象、输入预处理、组合强度、种子组合、约束条件表示、组合测试过程以及组合测试输入输出表示。组合测试方法适用于受多因素影响的软件系统在保证测试充分性的前提下,有效地减少测试用例的数量,提升测试效率,降低测试成本。
-
2021.3.9,发布系统与软件工程 性能测试方法标准,标准号为:GB/T 39788-2021。
-
GB/T 39788-2021 :规定了性能测试标准过程、性能测试需求模型、性能测试类型等内容。
-
38634↓
二:25000的八个质量特性
-
依从性:现定的标准复核情况
三:软件测试定义
-
软件测试(IEEE定义)
-
使用人工或者自动的手段来测试软件系统的过程,以检验软件系统是否满足规定的要求,并找出与预期结果之间的差异。
-
软件测试必要性(38634
-
决策者需要有关测试项质量特性的信息;
-
被测项并不总是达到预期效果;
-
被测项需验证;(验证有现成的依据文档
-
被测项需确认;(确认是否符合某种需求[用户需求])
-
被测项的评价需贯穿整个软件与系统开发生存周期。(最晚需求评审测试要参与)
-
尽可能多地发现软件中的缺陷;(在发布之前发现测试项的缺)
-
检查软件系统是否满足规格说明/用户的需求;(并减轻由产品质量不足带给相关利益方的风险)
-
为软件质量评价提供依据(提供有关测试项的质量信息以及与测试项测试数量相关的任何残余风险);
-
确保软件符合行业标准;
-
为软件开发过程的改进提供支持。
-
软件测试的主要对象
-
文档;
-
(需求文档、设计文档、用户手册、配置文档等)
-
程序;
-
数据。
四:对软件测试认识的偏差
偏差一:调试等同于测试,没必要进行测试。
-
测试与调试的主要区别:
-
目的不同(检错和排错);
-
任务、指导方法不同(测试从已知条件开始,使用预先定义的规程并且有可预知的结果;调试的开始条件可能不可知,结果不可预见);
-
操作者不同(测试一般由非程序设计人员完成;调试常常由程序设计人员完成)。
偏差二:可以对程序进行完全的测试。
-
无法实现的原因
-
所需测试的数量巨大(无法穷举);
-
无法保证测试环境100%满足测试要求;
-
没有足够的资源彻底完成软件测试(时间、人员、设备等)。
偏差三:测试后的软件没有缺陷。
-
无法实现的原因
-
无法通过测试确信测试依据文档100%正确;无法确信测试人员完全理解了软件;
-
无法确信测试系统(或环境)的正确性。
-
在资源制约和技术限制的条件下,无法保证找到软件中所有的缺陷;
偏差四:测试发现的问题越多,剩下的问题就越少。
-
原因
-
缺陷率水平与开发能力、复杂性等存在关联。
-
发现问题越多地方, 潜在的问题也更多。缺陷存在聚集效应,适用于80-20定律;(冒烟测试)
-
思考:发现问题少就是无效测试?
偏差五:测试是“silver bullet”(万金油),能够解决一切软件质量问题。
-
测试不是“silver bullet”,它具有有效范围,它不能替代其它
软件工程方法的作用。
软件测试方法
软件测试方法 - 按是否需要内部代码信息
-
黑盒测试& & 白盒测试
-
黑盒测试像中医:使用望、闻、问、切
-
白盒测试像西医:使用X光、CT扫描
-
目的都是发现病人的病症
黑盒测试方法
-
黑盒测试/基于规格说明的测试:
-
不涉及程序结构,把程序看成黑盒子
-
依据需求规格说明生成测试需求和用例
-
某些代码段得不到测试,需要用白盒测试加以补充
黑盒测试的优点
-
黑盒测试是在程序或软件界面上进行测试,相比白盒测试,主要有三个优点:
-
简单,无需了解代码细节,测试效率较高;
-
黑盒测试与软件如何实现无关,如果编码实现发生变化,黑盒测试用例仍然可用;
-
用例设计可以与软件的实现同时进行,加快了软件测试与开发的速度。
黑盒测试的缺点
-
只能找到缺陷,难以查找错误的具体原因和位置;(不如白盒测试)
-
没有清晰的需求文档,测试用例很难被设计;
-
相比白盒测试,测试用例产生遗漏或冗余的可能性大大增加
白盒测试
-
白盒测试属于代码级测试。一般用在单元测试和集成测试阶段。
-
白盒测试可以借助白盒自动化测试工具去完成测试。在国内,白盒测试通常需要软件开发人员支持进行。
白盒测试优缺点
-
优点
-
迫使软件测试人员深入到程序内部进行测试,易于定位错误的
-
原因和具体的位置;
-
检查代码中的每条分支和路径,进行较彻底测试;
-
揭示隐藏在代码中的错误,如:内存泄漏、数组越界等等;
-
优化代码,如:去掉冗余代码,规范代码(命名、注释等)。
-
局限性
-
很难查出程序中设计的缺陷,如遗漏了某些功能或业务;
-
时序问题、中断相关的缺陷
-
可能发现不了一些数据敏感性错误,如边界值很难考虑全面。
-
很难查出程序中兼容性、易用性等问题;
黑盒测试和白盒测试的结合
-
白盒测试是代码级测试,测试员需要深入了解代码的具体实现。通过白盒测试,测试员不仅可以找到代码级的缺陷,像内存泄漏、数组越界、空指针误用、代码不可达、代码规范性等等缺陷,还可以通过代码深入了解系统的功能、性能等,从而设计出高效的测试用例。
-
黑盒测试可以从宏观上把握系统,全面测试系统的功能,并且测试周期短,测试人力成本低。
-
在实际的测试过程中,最好采用黑白盒结合的策略,即测试员从整体上把握系统的功能和性能,又能在一定程度上了解软件的实现细节,设计出高效的测试用例。
软件测试方法 - 按照执行方式分类
-
静态测试
-
不动态执行程序代码,而寻找程序代码中可能存在的缺陷或评估程序代码的过程。
-
动态测试
-
需要运行测试项的测试。实际运行被测试程序,取得程序运行的真实情况和动态情况,进行分析
静态测试特征
-
可以由人工进行, 充分发挥人的逻辑思维优势;(如代码走查、审查)
-
可以借助软件工具自动完成部分工作, 提高测试的一致性和效率;(静态分析工具)
-
对测试环境的要求较低;(最多编译下)
-
测试成果取决于测试人员的能力和态度。
静态测试类型
-
需求(文档)或设计评审/审查;921、38634
-
代码质量度量;
-
静态代码分析。
-
代码审查/走查;
动态测试过程
动态测试特征
-
使用测试用例运行程序, 取得程序运行的真实情况
-
生成测试用例、分析测试结果工作量大
-
动态测试的关键在选择测试用例,测试的质量依赖于使用的测试数据;(数据充分性、代表性)
-
主要包括黑盒测试和白盒测试
软件测试方法 -按测试手段分类
-
手工测试
-
自动化测试
-
自动化测试是计算机代替人进行软件测试的技术,
-
即利用测试工具来开展和实施测试。
软件测试方法 -按开发过程分类
-
按照开发过程,分成四种测试方法:
-
单元/组件测试
-
软件集成测试/部件测试
-
软件配置项测试(文档分开????主要测试内部功能和外部接口,配置项外部接口是一部分,)
-
软件系统测试
-
从单元测试到系统测试,是测试对象是由小到大的过程,也叫四个测试级别
软件测试级别
-
与软件开发过程相适应
-
单元/组件测试;
-
集成测试;
-
软件配置项测试;
-
系统测试
用户需求--------------------------验收测试
↓ -------------------------- ↑
系统需求分析---------------------配置项测试和系统测试
↓ -------------------------- ↑
概要设计--------------------------集成测试
↓ -------------------------- ↑
详细设计--------------------------单元/组件测试
↓ -------------------------- ↑
→ 编码 →
软件测试级别设置建议
-
军工企业常用测试级别
-
单元测试、集成测试、配置项测试、系统测试;
-
非军工企业常用测试级别
-
单元测试、集成测试、系统测试;
-
三方测试机构常用测试级别
-
(确认测试??) 单元测试、集成测试、确认测试。
软件测试过程
软件测试过程模型-W模型
W模型:尽早、全面、全程。
软件测试过程模型 - H模型
H模型:独立、灵活
软件测试一般流程
-
1. 测试策划
-
(设计评审;测试需求分析;测试计划设计等)
-
2. 测试设计
-
(测试用例编写、测试脚本开发等)
-
3. 测试执行
-
(搭建测试环境、准备测试数据、执行测试用例、测试执行记录、缺陷处理与回归测试等)
-
4. 测试总结
-
(测试报告编写、测试总结、文档归档等)
软件测试完成准则
-
当时间用光时;
-
当继续测试没有发现新的缺陷时;
-
当测试的回报很小时;
-
当达到所要求的覆盖时;(动态单元、集成)
-
当所有发现的缺陷都已经清除时。
软件测试管理
测试组织管理
-
独立性级别
-
开发人员的测试;
-
专职测试人员的测试;(开发部的测试人员)
-
专职测试团队的测试; (测试部)
-
用户的测试;(验收测试)
-
独立机构的测试。(第三方测试)
-
组织结构与独立性级别匹配
测试需求管理-测试需求分析
-
任务
-
依据收集的原始需求,明确测试范围、测试类型和测试重点等,编制测试需求。
-
输入
-
需求规格说明书、需求评审记录等测试需求分析依据文档;
-
同类产品历史遗留问题。
测试需求管理-测试需求技术要求
-
充分性:测试需求必须充分的覆盖软件需求所有的功能性要求和非功能性要求,不能有遗漏。
-
准确性:测试需求当中的每一项内容都必须是描述清楚的,且正确地反应了测试任务和用户的要求。
-
可追溯性:从测试需求可向上回溯到原始需求,向下追踪到测试用例。
-
一致性:测试需求中各部分内容的描述是一致的,不存在相互矛盾的地方。
-
可行性:每一项测试需求在已有的条件下都是可以测试、可以实施的,可以作为编写测试用例的依据。
测试需求管理-测试需求分析步骤
-
1. 阅读需求规格说明书等测试依据文档,明确测试的内容和测试类型;
-
2. 从需求中提取测试项,对测试项进行细化和分解,形成可测试的测试要点;
-
3. 针对测试要点确定产品的质量要求,对每条质量要求分析确定出不同的测试内容,形成测试项说明;
-
4. 找出用户关注点,明确验收关键指标,制定测试的重点,确定测试项的优先级;
-
5. 编制测试需求文档。在编制测试需求时,优先复用已有测试需求库中的测试项,然后再补充其它的新的测试项。
测试需求管理-测试需求变更管理
测试缺陷管理
-
常见缺陷分类(不同企业分类项可能不同)
-
按缺陷状态分:新建、拒绝、打开、已修改、重新打开、已关闭;
-
按严重程度分:关键、重要、一般、建议等;
-
按测试类型分:文档审查、代码质量度量、静态代码分析、动态单元测试、集成测试、功能测试、性能测试、界面
-
测试、接口测试、安全性测试等。
包含缺陷状态的软件缺陷处理流程(举例)
-
假设项目组包含四种角色,分别是:
-
测试经理、测试人员、开发经理和开发人员。
-
测试人员针对程序中的缺陷(BUG)编写软件缺陷问题报告单,将其指派给开发经理,并将缺陷的状态设置为“新建”;
-
开发经理收到通知后,查看新建的缺陷。如果确认的确是一个缺陷,开发经理就将这个缺陷指定给某位开发人员处理,并将缺陷的状态改为“打开”。如果发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作缺陷的时候,开发经理将这个缺陷返回给测试经理,并将缺陷的状态设置为“拒绝”;
-
开发人员收到通知后,查看并处理该缺陷。当开发人员进行处理并认为已经解决之后,就可以将这个缺陷的状态设置为“已修正”,并将其返还给测试人员;
-
测试人员收到通知后,查看并验证缺陷修改情况。如果经过再次测试发现缺陷仍然存在,测试人员将缺陷再次传递给开发人员,并将缺陷的状态设置为“重新打开”。如果测试人员经过再次测试确认缺陷已经解决,就将缺陷的状态设置为“已关闭”;
-
如果测试经理收到某缺陷被拒绝通知,验证该缺陷,如果确实不能算作缺陷,关闭缺陷,将缺陷状态设置为“已关闭”。如果认为的确是一个缺陷,修改缺陷描述,并将其重新指派给开发经理,并将缺陷的状态设置为“新建
缺陷状态变化图
-
其他测试人员使用“T”表示,测试经理使用“TM”表示,开发人员使用“D”表示,开发经理使用“DM”表示
软件缺陷报告
-
缺陷报告包括的主要内容:缺陷的标识、关联测试用例、测试的软件和硬件环境、测试的软件版本、缺陷的类型、缺陷的严重程度、缺陷的概要、详细信息和截取的缺陷图像等;
-
软件缺陷问题报告单可以用word书写,也可以使用excel文档书写
软件缺陷模板、
处理缺陷的注意事项
-
在执行测试时,应及时记录缺陷;
-
缺陷的出现通常有集群现象;
-
建议测试人员可以尽早地与开发人员交流已发现的缺陷,确认缺陷产生的原因;
-
除了完成用例库中用例的执行,可以依据软件的特点和测试人员的经验去进行随机测试,有可能发现意想不到的缺陷;
-
测试人员需全程跟踪缺陷,直至它被解决;
-
当缺陷被开发人员修改完后,测试人员需要进行回归测试。
缺陷管理工具
-
Mantis、禅道、jira、QC(ALM)等
软件回归测试原因
-
由于某些原因,开发人员遗漏对bug的修改;
-
开发人员未完全搞清bug产生的实质原因,只是修改了bug的外
在表现,没有修复bug本身;
-
Bug的修改可能导致原来正确的相关功能出现问题。
软件回归测试目标
-
检验修改是否达到了预期的目的;
-
检验是否损害原有的正常功能, 从而造成系统的回归。
软件回归测试流程
-
识别变更, 进行变更影响分析;
-
对原测试集进行维护, 生成新的测试集;
-
从测试集中选择回归测试包;
-
用选择的测试包进行回归测试;
-
对回归测试结果进行分析并报告。
软件回归测试用例集选择
-
重新测试全部用例(很少用)
-
基于风险选择测试
-
(基于一定的风险标准从用例库中选择一部分用例去进行回归测试。例如:测试出错的测试用例(复测)和出错模块相关模块的测试用例以及重要的、关键的测试用例。)
软件开发生存周期的支持过程
-
质量保证和测试(监督与控制)
-
项目管理和测试(监督与控制)
-
配置管理和测试
-
过程改进与测试
第二部分测试用例设计及方法
测试用例概念及主要元素
-
测试用例(Test Case)
-
前置条件、输入(包括操作,如果适用)和预期结果的集合,用于驱动测试项的执行以满足测试目标,测试目标包括正确实现、错误识别、检查质量和其他有价值的信息。
-
测试用例文档是测试执行的依据文档。
-
测试用例的主要元素
-
测试名称:测试用例的编号和名称;
-
测试说明:测试用例的详细描述;
-
前提条件:测试用例执行的前提条件,包括测试环境、已有数据(如数据库)、被测软件、硬件等;
-
步骤描述、预期结果及实际结果;
-
状态:测试用例的状态(是否执行,是否通过);
-
设计人员和执行人员,创建日期和执行日期。
-
每个公司都有自己的测试模版,用例要素也略有不同。
-
可以使用Word、Excel,也可以使用测试工具管理。
测试用例实例 1word
测试用例实例 2excel
测试用例实例 3性能
测试用例实例 4-1动态白盒
测试用例实例 4-2
测试用例的设计准则
-
测试用例无法穷举所有操作可能,
-
设计尽可能少的用例去尽可能多的发现软件的缺陷。
-
基本准则如下
-
测试用例的代表性;
-
测试用例的非重复性;
-
测试结果的可判定性;
-
测试结果的可再现性;
-
一个好的测试用例是可以发现迄今为止尚未发现错误的测试用例。
-
其他准则
-
测试用例能够完全覆盖测试需求中的功能项(充分性);
-
既要考虑正确性测试,又要考虑容错性测试(正向和反向);
-
应该考虑不同测试用例的优先级(如:核心功能先测;回归时,修改功能先测;根据需求功能时序、业务流程去考虑);
-
功能模块测试用例的粒度(尽量细化,即一个用例解决一个测试目的);
-
描述语言要专业、清晰,无二义性;
-
……
-
-
测试用例的管理
-
使用测试管理工具来管理测试用例是目前比较流行的一种方式,即将测试用例录入到测试管理工具中。
-
常见的测试管理工具包括:
-
ALM(QC)、禅道、jira、testlink等。
-
主要好处
-
用例容易维护(编辑、版本控制等);
-
便于测试结果的多维统计;
-
不同角色人员查看
测试用例设计方法
-
等价类划分法;
-
边界值法;
-
错误推/猜测法;
-
组合测试技术
-
场景法;
-
因果图法;
-
正交实验法;
-
状态转移图测试。
等价类划分法
-
使用原因
-
测试用例数量大、无法穷举出来。
-
解决思路
-
把无限多的测试用例(测试数据)减少到同样有效的有限的、小范围的测试用例。
-
等价类划分法的具体做法
-
把测试项的输入域或输出域划分成若干部分,然后从每个部分中选取少数、代表性数据当作测试用例。
-
例如:计算器软件中的开方运算y=sqrt(x),输入域X可划分为正实数、0和负实数三部分,假设我们选定+1.4444代表正实数,-2.345代表负实数,则为该程序设计的测试用例的输入为+1.4444、0和-2.345。
-
有效等价类和无效等价类
-
有效等价类
-
合理、合法的输入或输出数据;
-
有效等价类构成的测试用例用于检验程序是否实现了预期的功能、性能等特性。(正确性)
-
无效等价类
-
不合理、非法的输入或输出数据;
-
无效等价类构成的测试用例检验程序对于无效数据的处理能力。(容错性)
-
计算器软件中的开方运算y=sqrt(x)中,有效类:0和正实数;无效类:负实数。
-
划分等价类需要保证以下三点:
-
1. 划分的完备性。要求所有的输入或操作可能都要考虑到,不能有遗漏;(划分等价类可以考虑使用等价树的思想)
-
2. 划分部分的有限性。划分出来有限个等价类,避免冗余测试;
-
3. 选取数据的有效性、代表性。可以结合边界值、错误推测等方法的思想选取代表性的数据,避免冗余测试。
-
丼例(保险费率计算)
-
按照输入项划分等价类的例子:
-
某保险公司承担人寿保险,该公司保费计算方式为:
-
保费=投保额*保险费率,保险费率依点数不同而有别,10点以上(含10点)费率为0.6%,10点以下费率为0.1%。
-
点数是由年龄、性别、婚姻、抚养人数所得的点数加起来得到的。
-
输入数据说明
-
第一步:输入和输出变量确认
-
输入
-
年龄、性别、婚姻、抚养人数
-
输出
-
保险费率
-
等价类划分原则
-
按照输入变量来确认等价类
-
(有效等价类和无效等价类)
-
第二步:等价类划分生成等价类表
-
-
第三步:根据等价类表设计测试用例
-
为每一个等价类规定一个唯一的编号。(表上已标明)
-
设计测试用例,尽可能多的覆盖尚未覆盖的有效等价类。
-
(1)(8)(10)(12)
-
(2)(9)(11)(13)
-
(3)(8)(10)(14)
-
设计测试用例,使每个新设计测试用例只包含一个无效等价类,其他的选择有效等价类。
-
(4)(8)(10)(12)
-
(5)(9)(11)(13)
-
(6)(8)(10)(14)
-
(7)(8)(10)(14)
-
(1)(8)(10)(15)
-
(2)(9)(11)(16)
-
(3)(8)(10)(16)
-
说明:在设计无效部分的测试用例的时候(第3步),有效等价类部分,可以任意选择。
-
第四步:选取测试用例
-
等价类划分法步骤总结
-
确定测试项的输入和输出;
-
选择输入或输出为目标划分有效等价类和无效等价类,生成等价类表(以输入为目标的比较多);
-
根据等价类表设计测试用例;
-
为每一个等价类规定一个唯一的编号;
-
设计测试用例,使其尽可能多地覆盖尚未覆盖的有效等价类。以此重复,直至所有有效等价类均被测试用例覆盖;
-
设计一个测试用例,使其覆盖一个尚未被覆盖的无效等价类。如此重复,直至所有无效等价类均被测试用例覆盖。
-
生成具体的测试用例。
-
1、按区间划分
-
在输入条件规定了取值范围的情况下,可以确定有效等价类和无效等价类。
-
例:程序输入条件为小于100大于10 的整数x,则有效等价类为
-
10<x<100,两个无效等价类x≤10和x≥100。
-
2、按照数值划分
-
在规定了一组输入数据(假设包括n个输入值),并且程序要对每一个输入值分别进行处理的情况下,可确定n个有效等价类(每个值确定一个有效等价类)和一个无效等价类(所有不允许的输入值的集合)。
-
例如:程序输入x取值于一个固定的枚举类型{1,3,7,15},且程序中对这4个数值分别进行处理,则有等价有效类为x=1,x=3,x=7,x=15,无效等价类为x≠1,3,7,15的值的集合。
单元测试
集成测试
系统测试
自动化测试