3 基于风险的测试
风险是当前未发生而未来有肯会发生并造成一定负面影响的事件。
3.1 基于风险的测试概述
(1)测试计划内容的核心:
1)测什么:从风险出发,需要明确地列举出要测试哪些具体的功能和非功能的质量特性,即测试范围。
2)如何测:应用测试基础知识、原则和设计技术,结合非功能质量特性的风险情况,设计和安排测试阶段,结合测试类型等内容形成测试策略。
3)什么时候测:结合风险缓解措施和软件开发的生存周期安排测试活动。将测试内容、测试策略的内容进一步分解为具体的测试任务。
4)谁来测:根据不同的测试阶段、测试类型、技术特长等要素确定测试团队。
(2)基于风险的测试计划指定的步骤如下:
(3)基于风险的测试的应用领域:基于风险的测试目前通常用于商业产品、非安全攸关的产品或服务。
3.2 风险分析和缓解措施设计
风险分析和缓解措施设计的过程如下:
(1)风险识别:通常的做法是通过专家访谈、头脑风暴和采用风险框架或检查表来尽量保证识别完整的风险和客观地评估其优先级。
(2)风险的影响和发生概率评估:风险是可能发生的负面影响的事件,其两个基本要素为:风险发生的可能性(概率)和风险一旦发生可能造成的影响(损失)。以软件测试作为度量软件产品质量的手段,简而言之就是通过执行测试,获取相关数据,再经过计算得到软件产品正确运行的概率或发生失效的概率。
(3)风险的优先级:如果风险发生的概率确定,则风险造成的负面影响越大,一旦发生所造成的损失也越大,也应该优先处理。所以风险优先级(R)、发生概率(P)和影响(I)的关系,可以初步总结为以下公式:R=PI。然而,测试活动解决的是当前的开发测试活动中遭到风险的概率(C)与期望产品上市后发生风险的可能性(P)之间的差距。所以对于软件测试计划,其要对应的风险的优先级,应该修正为如下公式:R=(C-P)
I。
(4)风险与缓解措施如下所示:
1)测试级别的划分,能对应解决软件开发的复杂性问题。
2)测试类型的设计和安排,将测试类型安排在最适合对应的测试级别中来识别和缓解产品的风险。
3)测试设计方法,在每个测试级别和类型中,都需要进行测试设计和执行的工作。
4)测试执行方法,对每个测试级别和测试类型都应具体地设计安排对应的测试执行手段。
(5)一般性的缓解措施指南:绝大部分软件产品是一个历史产品线的沿袭,系统的整体架构、模块和功能基本与历史产品线相同。变化的是少量的非核心新功能和底层硬件的升级换代。
1)可能的测试级别的划分:
- 对于没有代码变更的已有软件模块,无需进行单元测试。
- 根据单元测试最终的情况考虑是否安排一轮在模拟器环境中执行的预集成测试,包括新功能的所有集成测试和回归测试。
- 对新添加的功能进行集成测试。
- 在系统测试级别,对所有功能进行完整的三轮回归测试。
2)设计风险缓解措施的步骤:
- 安排测试级别来对应软件系统的复杂度风险。
- 根据各个测试级别的特点和资源情况安排,通过特定的测试类型在本级别内对应特定的质量特性风险。
- 在安排测试类型后,考虑采用哪些测试设计方法设计测试用例。
- 根据与被测试对象的交互方式可能的测试环境、测试工具的情况来设计测试执行的方法。
3)基于风险的原则:
- 由风险导出相关质量特性,而非单纯考虑质量特性,避免扩大某些不必要的质量特性的测试,忽略应覆盖到的质量特性测试。
- 由质量特性得到的测试类型,避免安排无意义的测试活动来进行某些特定目标的测试。
- 根据测试类型考虑测试设计方法,更有针对性。
- 根据测试类型和测试级别设计测试执行的方法,而非相反。避免安排哪些能测试的测试类型,应根据需要去设计开发测试环境和测试工具。
3.3测试级别与测试实施
测试级别与测试实施过程如下:
(1)单元测试设计与实施:在单元测试级别,设计测试用例的依据是模块、组件、函数等单元的详细设计书或代码。一般安排测试设计方法的参考规则如下:
- 对单元的明确功能,根据具体特性选择基于规格说明的测试设计技术。
- 对于单元输入的各项参数可以采用等价类划分、边界值、组合测试技术。
- 对于有着美国你却的状态和转移定义的模块,应该采用状态转移测试进行覆盖。
- 对于有明确逻辑判断规格要求的,应采用判定表技术。
- 通过代码覆盖度工具可对执行以上测试用例时达到的白盒测试覆盖进行度量。对于未能达到覆盖目标的部分代码,通过基于结构的测试设计技术来补充测试用例进行覆盖。
- 一般对生命攸关系统中关键模块、核心算法模块,有法规或行业标准要求必须达成某种代码覆盖。
(2)集成测试设计与实施:集成测试的测试设计方法为“灰盒”测试设计,其具体的做法是综合运用基于规格说明的测试设计技术和基于结构的测试设计技术来设计测试用例。
1)通常的测试设计技术的参考规则如下:
- 以场景测试为主要测试设计技术。
- 为了在场景中找出异常或极端的情况,可对通信消息的内容参数或调用的接口参数及返回值,应用等价类和边界值方法。
- 对于通过异步通信来进行的模块间交互协同,还应考虑异步通信带来的固有风险:消息丢失、重复、内容错误、超时、响应延迟与请求的重发、消息流程的交叉。
- 对于有状态转移的模块间交互协同,可采用状态转移测试,测试多个状态机间同步的情况。
2)集成测工具应具备以下功能:
- 获取模块间调用的信息。
- 根据测试要求匹配模块间调用(响应)。
- 根据测试要求修改模块间调用(响应),包括修改调用的方法和参数内容。
- 根据测试要求重复模块间调用(响应)。
- 根据测试要求丢弃模块间调用(响应)。
- 根据测试要求延迟发送模块间调用(响应)。
(3)系统测试设计与实施:系统测试中主要应用基于规格说明的各种测试技术。通常系统测试采用手工测试和自动化测试相结合的方式来实施,由测试人员根据测试用例和用户手册等资料,对系统进行输入,观察其输出等外部行为。
(4)验收测试设计与实施:验收测试的实施通常以手工测试为主。验收测试的测试用例一般有两个来源:
- 从系统测试用例中随机抽取一些基本使用场景。
- 从用户实际使用的场景出发,采用场景法来设计测试用例。验收测试的测试用例与其他测试级别的不同之处在于,验收测试更关注软件系统的功能在用户真实的使用场景中是否能提供用户所需要的价值,以及能否更优化的用法或需求来更好地满足客户的需求。
3.4 测试估算
目前主要有3种测试估算的方法,如下:
(1)宽带德尔斐(Delphi)法:又称为专家法,基本方法是召集多位产品领域、开发领域和测试领域的专家,最好能包含产品的利益相关方,各自独立地对识别的风险和风险缓解措施进行头脑风暴式的估算,或通过访谈,收集专家和有经验的工程师的经验和看法。
(2)基于历史数据法:当软件产品在组织内有过类似的经验时,可参考过去项目的历史经验比如一系列产品线中的某个特定产品的测试。
(3)根据测试级别、测试类型和测试技术进行测试估算:从功能和风险对应的测试类型和测试设计技术出发,逐个地根据功能和测试设计技术来估算可能的测试用例数量,然后根据测试用例数量可以估计出测试设计和测试执行一轮的工时。
4 软件测试新技术的应用
4.1 移动应用软件
(1)移动应用软件常见的操作系统如下:
- Android: 基于Linux内核和其他开源软件的修改版移动操作系统。免费的开源软件,源代码称为Android Open Source Project(AOSP),并主要以Apache许可发行。软件包使用APK格式。
- iOS:曾用名iPhone OS。由苹果公司专门为其硬件创建和开发的移动操作系统。
(2)移动应用软件的主要特点:
- 多样的交互方式
- 多样的移动设备
- 快速的软件版本迭代
(3)移动应用软件测试的手段如下:
1)人工测试仍然是开发人员和测试人员使用最普遍的测试方法。
2)脚本编程测试的主要方法有两类:
- 测试脚本编程技术:利用测试脚本编程框架和接口编写测试脚本,然后交由测试框架实施自动测试执行和功能检查。
- 测试脚本录制技术:利用录制回放工具自动化记录和执行测试脚本。
(4)移动应用软件测试遇到的挑战:
1)脚本编程测试的局限性:
- 最突出的问题是由于应用软件的用户界面经常发送变化,经常出现脚本无法顺利执行的情况。
- 测试脚本录制回放工具为测试脚本自动化生成提供了极大的方便,但是通过录制生成的测试脚本受限于录制时移动设备的屏幕大小和分辨率,在没有任何修改适配的情况下,生成的脚本很难直接运行于不同屏幕大小的其他移动设备上,而这一点恰恰是自动化测试框架技术可以轻松解决的问题。
- 脚本编程测试方法生成的测试脚本依赖开发或测试人员在适当位置插入测试语言用于检查软件功能正确性,因此仍然需要人工参与。
2)网络基础设施与架构的多样性:
- 现代的移动应用软件大部分需要联网操作,而网络在软件使用过程中可能会发生变化,比如可能会在4G、3G网络模式下自动切换。
- 用户在不同物理位置区域上,网络设施的稳定性也会不同,比如网络延时、网络掉包、网络服务中断等,这些情况都可能对移动应用的正常运行带来意想不到的影响。
- 如今移动应用架构越来越复杂,很多应用需要和后台服务器、其他联网设备、移动设备进行交互。面对复杂的架构设计,如何实施有效的测试方法也是需要探索和解决的问题。
3)移动设备多样性的挑战。在同一时期市场上存在许多不同系统版本、不同型号和屏幕大小以及不同厂商定制的移动设备。此类现象需要尽可能保证应用软件能够在大部分主流设备上平稳、正确运行。因此,移动应用软件的开发和测试人员在发布应用之前,至少需要在几类不同的Android系统版本的各类型号的移动设备上实施测试,以保证其软件在最大限度下能够正确运行,尽可能减少移动应用兼容性错误。
(5)移动应用软件的测试如下:
1)功能测试:测试目标是验证移动应用的功能是否符合预期。主流测试方法为手工测试方式、自动化脚本测试方式。
2)性能测试:测试目标是移动应用能提供流畅的用户体验,包括设备性能、服务器/API性能、网络性能方面。
3)易用性测试:测试目标是在开发周期的早期识别出系统中的易用性错误,并可以避免产品出现故障。关注点有:软件的有效性、软件的使用效率、软件内容的准确性、用户界面的友好性。
4)信息安全测试:测试目标是防止针对移动应用软件的欺诈攻击、病毒或恶意软件感染、尽早发现可能的安全漏洞、非必要的权限许可等。主流测试方法为:设计审查、白盒代码安全性审查、黑盒安全审计。
5)可移植性测试:测试目标是确保移动应用软件在不同的主流移动设备上能够正确安装、启动和卸载,以及能够正确、平稳地运行。主流测试方法为:人工测试和众包测试、第三方自动化云测试服务。
6)网络测试:测试目标是模拟不同的网络环境和质量,检测应用软件的健壮性、易用性和稳定性。根据不同的测试目标,可以细分为:弱网测试、无网测试、异常机制测试。主流测试方法有:通过将移动设备连接到PC上进行网络测试;在专有服务器上构建网络Wi-Fi,移动设备连接该Wi-Fi进行网络测试。
4.2 物联网
物联网检测IoT,是指能够让所有的被独立寻址的普通的物理对象实现互联互通的网络,是一个在互联网、传统电信网等基础上的信息承载体。
(1)信息交互的基本特征如下图:
(2)物联网的安全架构如下图:
(3)物联网测试面临的挑战:
1)软硬件协同网络挑战:物联网是一种结构性的网络,其中各种软硬件紧密耦合,不仅仅是软件的应用,传感器、通信网关等设备也发挥着重要的作用。
2)模块交互强连接挑战:由于物联网会涉及不同的软硬件组件之间的体系结构,测试必须接近各种实际的情况。当不同的模块之间进行强连接交互,相互融合时,安全性、兼容性等问题都是测过程中会遇到的挑战。
3)实时数据测试挑战:因为监管测试和试点测试都具有强制性,所以得到实时的数据在测试过程中是非常困难的,测试人员获得监管点也是非常困难的,因此物联网测试过程中的实时数据测试对测试团队来说也是一大挑战。
4)网络可用性测试挑战:由于物联网中网络连接有着重要的作用。我们需要在不同的网络环境下进行测试,主要目标是在网络中更快地传输数据。这样我们就需要通过改变网络负载、连接和稳定性等网络可用性指标进行测试。
(4)物联网的测试类型如下:
1)可用性测试:测试人员需要对物联网设备及其应用程序的每一个功能、数据处理、消息传递等方面进行测试。另一方面,物联网还应该时刻保持互联相通。建立设备的连接,数据的传输以及消息任务的传递都应该是流畅的。
2)安全测试:物联网是以数据为中心的,所有设备的连接和操作都基于可用的数据,当数据在设备之间进行交换时,数据就很容易在交换过程中被截取,所以在测试过程中就需要检查数据从一个设备传输到另一个设备时是否被保护或加密。
3)性能测试:物联网性能测试通过各种自动化的测试工具模拟各种正常的、异常的、峰值的条件对物联网应用的性能指标进行测试。性能测试包含了负载测试和压力测试等。
4)兼容性测试:物联网兼容性测试的内容主要包括操作系统、浏览器、设备、通信模式等的各种版本。
5)监管测试:指物联网系统测试过程中需要通过多个监管合规的检查点。
(5)物联网渗透测试技术:指为了发现系统最脆弱的环节,对目标系统的安全性做更深入地探测,通过模拟黑客可能使用的漏洞发现技术和真实的攻击技术进行测试。物联网渗透测试步骤如下:
1)威胁建模(固件、嵌入式网络、移动应用)
2)漏洞利用( 固件、嵌入式网络、移动应用)
3)攻击技术(物联网设备、无线电)
物联网渗透测试流程如下:
1)信息收集:通过探知物联网的感知层、网络层和应用层的相关信息进行信息收集。
2)进行分析:对收集到的信息进行分类、组织、分析进而识别出目标的攻击路径,并且尝试获得目标的访问权限。
3)针对性开发:针对已经分析出来的可攻击路径模拟真实的攻击。
4)生成报告:一个成功的渗透测试能够发现漏洞,并提供日志报告,以便提高未来的物联网的安全性。
4.3 大数据
大数据是将包含结构化、非结构化甚至多结构化的海量数据进行整合,并通过对这些数据的分析来发现数据中隐藏的相关信息,进而优化业务和管理。
(1)大数据产品的四个特征:
1)数据类型多样:数据不仅仅是文本形式,也有图片、视频、音频等多类型的数据。
2)数据体量巨大:大数据具有海量的数据规模。
3)处理速度高速:为了这些海量数据能够得到有效的处理,要求这些数据几乎能够被实时地接收和处理,才能满足大数据应用的需求。
4)价值密度低:因为数据大量地存在,可能有用的数据分散在其中。
(2)大数据测试面临的挑战:
1)数据多样性和不完整性
2)高度扩展性
3)测试数据管理
(3)大数据的测试类型:
1)功能测试:前端应用测试能够为数据的验证提供便利。
2)性能测试:大数据的自动化,能够方便我们在不同的条件下测试目标应用的性能。
3)数据提取测试:通过测试性地提取数据,可以验证并确保所有的数据均能在大数据应用中被正确地提取和加载。
4)数据处理测试:在针对大数据的处理策略上,我们需要运用数据自动化工具,重点关注数据的获取与处理过程,通过比较输出文件和输入文件,来验证业务逻辑是否能够被正确地实现。
5)数据存储测试:借助大数据自动化测试工具,测试人员可以通过将输出数据与数据库中的数据进行比较,来验证输出数据是否已正确地被加载到了数据库中。
6)数据迁移测试:当应用程序被迁移到其他服务器,或发生任何技术变更时,我们都需要通过软件测试,来验证数据从旧的传统系统迁移到新系统的过程中,所经历的停机时间最少,而且不会造成任何数据丢失。
(4)大数据测试流程如下:
(5)常见的大数据测试工具:Hadoop、HPCC、Storm、Cloudera、Cassandra.
4.4 可信软件
是指软件系统的动态行为及其结果是符合人们预期,并在受到干扰时仍能提供连续服务的软件,这里的“干扰”包括操作错误、环境影响和外部攻击等。
(1)软件可信评估与传统的软件质量测量的区别如下:
1)软件在运行时可能会受到木马、病毒、窃听等外界的恶意攻击,传统的仅考虑自身系统质量的质量测量已难以适用,需考虑软件实际运行时的适用质量。
2)传统的质量测量通常针对具体的质量属性,如正确性、容错性、易安装性等,较少考虑不同质量属性的综合。而可信性是软件的可用性、可靠性、安全性、正确性、可预测性等诸多属性在使用层面的综合反映。
3)传统软件质量测量的客观性交高,而可信评估则是主观与客观的结合。
(2)可信软件的验证技术:
1)形式化建模与方法:
- 通过数据流描述、变量关系描述和软件体系结构描述等图形符号,从形式化需求模型中抽取不同形态的分析模型。
- 根据软件的特点划分为不同分析目标,为每个验证目标定义出相应的技术。
- 针对建立的性质集合,采用模型检测的方法自动地发现漏洞与验证软件是否满足高安全可靠性需求。
- 自动生成测试用例,基于系统模型及需求自动生成关于软件实现的测试用例集,提高系统测试的效率和错误发现能力。
- 将形式化模型进行仿真。
2)主流的形式化验证技术如下:
- 定理证明:1. 把软件系统是否满足性质归约的问题转化为定理的形式,然后通过数学逻辑公式和推导演绎规则进行验证;2.需要人工干预,存在因引入人为因素而影响其验证正确性的隐患。
- 模型检查:1. 用一个模型转换图对软件系统的程序状态和状态之间的迁移关系进行形象建模,用时态逻辑公式对性质归约进行刻画,然后来验证性质归约是否被满足;2. 与定理证明不同的是,模型检查是高度自动化的,而且能在性质违反时给出反例。
3)可信软件的验证工具: Spin、NuSMV、Atelier-B
4.5 人工智能
人工智能是一种思维和响应方式与人的方式相似的自动化计算技术。狭义的人工智能是指描述或完成具体的任务,例如棋牌对弈、语言翻译、自动驾驶、图像识别等;广义的人工智能是指能够完成多种工作,并能够根据推理在这些任务之间切换。
(1)人工智能在各行各业的应用:自然语言处理、虚拟现实、语言翻译、广告推送、人脸识别、X光医学影像判断、作曲、案情分析、围棋比赛等等。
(2)人工智能对软件测试技术的影响:
1)测试工作前移:人工智能对软件测试的显著影响之一,就是使测试工作前移成为可能。
2)自动化程度提高:测试项目管理、测试需求分析与测试设计、测试执行
3)测试更可靠:软件测试的可靠性,主要通过测试的充分性和有效性体现
(3)人工智能会取代测试人员吗?
1)软件测试行业由于其工作类型的性质,不太可能被完全取代。
2)软件测试中有关数据处理的工作,未来会被取代
3)人工智能在软件测试中的应用还会催生出一些新的富有挑战的工作类型。
(4)人工智能辅助测试技术:
1)基于约束的技术:将被测程序或其模型,以及测试准测或测试目标转换为约束,然后通过约束消解器消解约束,最终获得测试用例。
2)启发式搜索算法:遗传算法、蚂蚁算法、模拟退火算法。