杨 燕 刘 钊 蔡久涛
1(江西航天鄱湖云科技有限公司 江西 南昌 330096)
2(航天恒星科技有限公司 北京 100086)
3(金蝶软件(中国)有限公司南昌分公司 江西 南昌 330096)
脚本化测试是先设计、再执行,设计时就指定输入值和预期结果,执行时严格按照测试设计进行。一方面随着软件应用的发展,软件出现了推出快、变化频繁、接口杂、重体验、开放性等特点,另一方面随着测试的积累测试人员发现缺陷的类型增长缓慢。为了适用这种变化,也为了解决现存问题,需要引入新的测试技术。探索性测试作为一种前沿的测试思维,在项目周期短、需求不明确或者需求变更频繁的项目中发现缺陷的效果显著,也能发现一些脚本化测试发现不了的缺陷,因此受到越来越多软件测试人员的青睐。
目前对探索性测试的研究主要集中在测试思想和方法上[1-3],近年来也有研究探索性测试在个别领域上的应用。文献[4]将探索性测试应用到航空声纳软件中能够有效发掘软件中隐藏的缺陷。文献[5]研究表明,将探索性测试思维引入到军用软件中与传统的软件测试相结合,能有效提高软件测试效率和测试覆盖率。但是在实际工作中对实施探索性测试发现的缺陷特征及在不同测试阶段的实施的研究甚少。本文通过对“同时进行设计、测试和学习”的探索性测试进行研究,总结出几种可采用探索性测试的情况,并将探索性测试融入到传统的测试流程体系中,再选取三个不同类型的项目进行实践来研究如何采用探索性测试方法开展软件测试工作。
探索性测试最先由Cem Kaner在1983年提出,它是一种软件测试风格,也是一种测试思维[6]。这种测试思维不同于传统软件测试过程中严格的“先设计,后执行”,它将学习、测试设计和测试执行整合在一起,测试人员通过不断的学习,并把学习到的关于软件系统的更多信息通过综合的整理和分析,创造出更多的关于测试的想法。它强调测试执行、学习、测试设计的同时性,注重思考和学习,通过思考和学习改善测试设计与测试执行,不断地发现新的缺陷。
探索性测试在软件生命周期的任一阶段均可使用,如:集成测试、系统测试、验收测试等;也适用于各种类型的测试,如:功能测试、可靠性测试、兼容性测试、易用性测试、性能测试、安全性测试等[7]。
不同于随机测试,探索性测试是带着“反思”的测试,通过对测试结果的分析和判断,驱动下一步的测试设计和测试执行,达到持续优化测试价值的目的。随机测试通常利用错误猜测、典型风险来验证软件,可以在短时间内发现许多软件错误,但是它不强调测试的系统性和完整性,漏测风险很高。而探索性测试会拓展测试的深度和广度,能够发现一些隐藏较深的缺陷[6]。
探索性测试的指导方法有局部探索性测试和全局探索性测试两种[6]。
局部探索性测试关注局部小范围,测试时需要考虑5个部分:输入、状态、代码路径、用户数据和执行环境[6]。这5个部分的测试可按照传统的脚本化测试用例设计方法进行设计测试,如:输入,可采用等价类划分法、边界值法、错误推测法等方法进行测试[3]。
全局探索性测试也叫漫游测试,把全局探索性测试和旅游进行类比,测试人员就是游客,被测软件就是旅游地。旅游地按照功能区域划分可划分为:商业区、历史区、旅游区、娱乐区、旅馆区和破旧区[6]。各功能区域说明及测试要点如表1所示。
针对不同区域选取不同的测试方法进行测试:商业区侧重于测试用户关注的核心业务和功能,可采用指南测试法、卖点测试法、地标测试法、极限测试法、快递测试法、深夜测试法、遍历测试法;针对历史区旧的功能和缺陷修复代码可采用恶邻测试法、博物馆测试法、上一版测试法;娱乐区测试对应到软件上就是辅助功能,可采用配角测试法、深巷测试法、通宵测试法进行测试;类比旅游区的可快速访问功能的测试可采用收藏家测试法、长路径测试法、超模测试、测一送一测试法;旅馆区可采用取消测试法、懒汉测试法;破旧区测试可采用破坏测试法、反叛测试法、强迫症测试法。
在实际测试工作中针对功能点的测试可以采用局部探索性测试,针对涉及到业务的场景及整体层面的可以采用全局探索性测试。
文献[9]指出了采用探索性测试的情况,如:文档资料缺乏;产品不稳定、软件版本较多;测试人员专业技能不足;没有时间编写测试计划和测试脚本。根据对探索性测试的研究,结合项目测试管理经验,在以下情况下也可考虑采用探索性测试:
(1) 项目组人员调整后,新成员为了能够在短时间内快速了解系统,可以执行一次探索性测试。
(2) 在缺陷验证时,为了确认修复缺陷时是否引入新缺陷,可以加入适当围绕该被测功能点的探索性测试,及时发现可能由修复带来的新缺陷。
(3) 在完成常规测试且时间充沛的情况下进行探索性测试可以检查测试的完整性,拓展当前测试的覆盖度和深度。
(4) 出于对现存测试设计和结果存疑的情况下,可以执行探索性测试来验证。
由于探索性测试不同于传统的先设计、再执行,它强调设计和测试的同时性,如果不讲究方法、没有重点地盲目进行测试,就会出现重复测试和漏测的情况。在实际工作中,实施探索性测试也要保证测试覆盖率。
文献[10]提出将探索性测试和脚本测试的优势结合到混合测试过程中的方法。文献[11]研究表明,将探索式软件测试融入传统测试模型,在每个阶段测试执行完成后进行探索式测试可以提高测试覆盖率。目前许多国内外专家学者也认可这种“脚本化为主、探索性测试为辅”的二者融合方案[7]。即执行脚本化测试用例,又边测试边记录新的测试点,过程中不断分析、不断学习,发现更多的脚本化测试发现不了的缺陷。
传统的软件测试一般严格按照测试需求分析、编写测试计划、测试计划评审、编写测试用例、测试用例评审、搭建测试环境、执行测试、提交缺陷、修复缺陷、验证缺陷、回归测试等流程执行,测试流程如图1所示。
图1 传统测试流程
随着软件应用的发展,软件出现了推出快、变化频繁、接口杂、重体验、开放性等特点[12],测试也需要适当进行调整以适应这种变化。文献[13]表明,不论如何测试也不能保证软件中不存在任何错误,但是通过测试策略可以努力使测试尽可能完全。
通过在传统测试流程中加入探索性测试,分别分析在系统测试阶段后和系统测试阶段加入探索性测试发现的缺陷的有效性、在总缺陷数中的占比及发现的缺陷类型,查看实施探索性测试对脚本化测试的助力到底如何。
在测试需求分析、设计测试用例及测试用例评审阶段融入探索性测试思维,融入探索性测试后测试流程如图2所示。
图2 融入探索性测试后测试流程
在测试需求分析阶段加入探索性测试,通过换位思考站在包括业务领域专家、用户、项目经理、开发人员、公司管理者角度分析他们对需求规格的要求,也可以参考同类软件或以前项目经验等对其进行探索性测试,从而发现更多隐形需求,进而避免由于需求原因而埋下缺陷。
在设计测试用例阶段加入探索性测试,将通过思考学习获得的一切与软件系统相关的信息设计成测试用例,意在通过执行测试用例发现更多的需求规格说明中没有明确说明的隐形或深层业务方面的缺陷。在测试用例评审阶段加入探索性测试,通过借助众人的智慧和经验,丰富用例设计内容,减少漏测率。在执行测试阶段加入探索性测试,意在将测试人员的测试经验和测试思想转化为尽早发现的缺陷,降低后期缺陷修复成本。在验证缺陷阶段加入探索性测试意在验证修复缺陷时是否影响到了其他模块功能使用,是否引入新的缺陷。在回归测试阶段加入探索性测试意在确认最终效果是否满足用户需要。
实施探索性测试的难点在于测试执行环节,执行时面对持续变化的情况,由于测试人员的认知不同,应对方式也会不同。为了指导测试,探索性测试也需要进行测试设计,此工作可以在执行前进行,也可在执行测试时进行。探索性测试设计不局限于传统的脚本化测试用例的设计,需要包含:唯一标识、摘要、描述、设计方法、测试阶段、测试类型、预期结果、测试步骤等。探索性测试设计可以是思维导图等,意在记录测试点及系统业务等,便于后期系统维护及回归测试。
结合项目实际情况基于1.3节中场景(3)和场景(4)的考虑,选择某区实验室管理系统、某任务管理软件和某信息化平台这三个项目为实践对象来研究如何采用探索性测试开展软件测试工作,并对测试结果进行分析,选取的项目基本信息如表2所示。
表2 实践项目信息
这三个项目的测试过程都是按照CMMI3级标准进行管理的,对其分析的结果具有一定的可参考性,对于后期软件管理过程改进也有一定的帮助。
某区实验室管理系统是一个专属于该区环境保护检测站实验室内部工作管理的管理系统。主要用于实验室基础信息管理、样品报告流转、报告数据统计和样品数据统计。
按照已有的测试流程完成测试后,得出该系统的千行代码缺陷率为2.56,而根据2016年-2018年项目测试累计数据得到的平均千行代码缺陷率分别为4.5、5.0和4.3,故在此系统中引入探索性测试,通过探索性测试确认该系统是否测试充分,是否存在漏测的情况。
某区实验室管理系统采用“脚本化为主、探索性测试为辅”的测试方案进行测试,在系统测试完成后引入探索性测试,软件测试总体流程见图3。
图3 软件测试总体流程图
探索性测试的测试过程如下:
(1) 测试负责人收集测试相关文档,包括:需求规格说明书、需求变更申请单、测试说明等,并结合已完成系统获取需要测试的内容,然后制定测试计划、分配测试人员和测试内容。
(2) 探索性测试人员与项目组测试人员进行沟通,了解更多业务信息及缺陷分布情况等,确定高风险功能点。
(3) 开始执行探索性测试,在这个过程中同时进行测试执行、思考学习、测试设计,并根据实际情况随时更改测试策略,同时记录软件逻辑和发现的缺陷。
(4) 项目组开发人员对缺陷进行修复,测试人员再对其进行验证,待所有缺陷闭环后,进行测试结果分析、总结。
文献[12]指出,不同的人实施探索性测试会有不同的效果,在制定探索性测试计划时需要做到:给新人分配的是基本信息的增删改查,除了希望发现更多缺陷外,也希望通过此次测试能够加深对测试的理解;经验丰富的人,用于执行核心的业务流程,希望通过他确认重要的影响因素在设计中已经都考虑到了;有开发经验的,期望他能够发现框架等更深层次的缺陷。
通过对脚本化测试发现的缺陷,及执行完脚本化测试后加入探索性测试后探索性测试发现的缺陷进行统计分析,得到加入探索性测试后发现的缺陷数和测试耗时情况如表3所示。
表3 加入探索性测试后测试结果
由表3可知,实施探索性测试后又发现了92个缺陷,说明实施探索性测试是有必要的,能够提高产品的质量。分析投入与产出效能可知,实施探索性测试虽然耗时增加了37.5%,但是发现的缺陷增量也高达35.11%,实施探索性测试后该系统的千行代码缺陷率也达到了4.6,参考以往测试结果说明此次探索性测试是较充分的。针对92个缺陷进行分析后可知,有90%的缺陷是有效缺陷,也是被项目组的开发人员所认可的缺陷,探索性测试发现的缺陷分类如图4所示。
图4 探索性测试缺陷分类
探索性测试发现的有效缺陷的类别如图5所示。
图5 有效缺陷类别
由图5可知,探索性测试发现的缺陷主要集中在功能性和易用性这两个方面,同时也能发现安全性、维护性、兼容性和可靠性方面的缺陷。
参考文献[14-15]后,将探索性测试思维应用到传统软件测试中,应用后测试流程如图6所示。
图6 加入探索性测试后测试流程
将探索性测试应用于某任务管理软件和某信息化平台的执行测试、缺陷验证和回归测试阶段中,对测试数据进行整理分析后得到表4和表5所示测试结果。
表4 某任务管理软件实施了探索性测试后测试结果
表5 某信息化平台实施了探索性测试后测试结果
将实施探索性测试后发现的缺陷进行整理后,得到实施探索性测试发现的缺陷分布情况如图7所示。
图7 探索性测试发现缺陷分布
从测试结果可以看出,探索性测试发现的缺陷分布主要集中在功能性和易用性两个方面。
将探索性测试应用到三个不同类型的项目中,发现均能够助力脚本化测试使发现缺陷的总量增长至少25%以上。由此可知,探索性测试对于脚本测试是一种非常有益有效的补充。
探索性测试作为一种新的测试理论,除了将探索性测试思维融入到软件测试的各个阶段外,后期还可从以下两个方面继续进行研究:(1) 目前已有脚本化测试的公共测试用例库,随着开展探索性测试的项目越来越多,通过探索性测试方法分析出一些测试点,抽取可以复用的探索性测试的测试用例也是一种需要;(2) 针对已经出了原型需要进行测试的项目,及采购类产品和设备构建以探索性测试为主的测试过程也是一种可尝试的方向。