测无定法,测必有法:测试策略运用之道

发表于:2019-9-09 11:36

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:软件质量报道    来源:软件质量报道

  软件测试实施中,综合运用测试策略,就是根据项目的实际情况协调好手上有限的测试资源和要素,从项目整体上分析测试难点、破解测试痛点、控制测试风险,在恰当的测试阶段运用恰当的测试方法和技术,面向目标,提纲挈领,让测试任务相关的人、事、物等要素发挥协同效应,力争在有效时间内产生最佳的测试效率和测试交付。
  1. 测试策略的重要性
  任何一个测试项目都会受到范围、时间、质量、成本等因素的制约,这里的测试资源和要素简言之就是人、事、物:
  人不仅有测试人员,还有开发人员、项目管理人员、以及外包供应商、领导层等;
  事就是可能的风险事项、需求变化、人员变更、各利益方角力以及突发事件等;
  物最好理解,就是测试时间、测试进度、测试范围、测试环境等实际资源。
  测试策略就在不同的阶段把人、事、物等要素综合考虑和运用,使各方资源发挥合力,让有限的资源产生最好的组合效能。在软件测试时选择合适的测试策略和方法组合,才能有效地提升测试效率和质量。尤其是在当今互联网软件时代,软件更新迭代周期短,对软件测试的质量需求和效率要求提出了新挑战,就更需要有合理的测试策略的综合应用。
  2. 测试策略的综合应用
  测试策略的综合运用,概括起来就是 先找项目的测试难点、痛点、风险点,然后 更精准地确定范围,更细致地准备业务知识,更合理地安排测试资源和进度,更有效地调动测试人员的积极性,最后 集中优势兵力攻难点、破痛点、控风险,更早更及时地找出系统问题。同时持续开展业务学习和技术交流,提升团体战斗力,动态跟进项目风险点,并针对性地动态调整测试策略,最终高效地保证测试交付质量。下面以笔者所经历过的两个金融测试项目实例来探讨测试策略的综合应用,希望能够管中窥豹,投石探路,引发读者的讨论和思考。
  2.1  某大型商业银行核心系统UAT测试 项目背景 : 为适应互联网化的发展,强调用户体验,强化全行业务统一管理、数据统一管理、全行一本账, 某银行对使用了十多年的大集中系统进行全新的设计和替换, 某银行总行IT中心特地成立测试中心,用以保障新核心系统的交付质量。 项目开发规模 : 开发人员600+ 项目测试规模 : 六家外包测试供应商+甲方自己的团队,测试人员初期有150多人,高峰时有500多人。 项目实施难度 :
  总行领导直接关注,每月要定期汇报,甲方测试中心领导高度重视,测试交付人员压力空前巨大。
  项目加班严重,测试人员非常疲惫。前期是996模式(早上9点上班,晚上9点下班,一周工作6天),后面测试人员增加后改成每周5个工作日中三天固定加班到晚上9点,周末周六固定一天加班。
  项目组的管理人员都是从各省分行支行抽调的业务骨干,他们在业务上没问题的,但管理水平的确有限,对测试更是没什么积累,有点外行领导内行的感觉。
  测试人员众多,来自多个测试服务供应商,人员管理复杂,且测试人员能力参差不齐。
  测试策略运用:面对这样的大型项目,测试组织和执行犹如大兵团作战,如果没有合适的系列化的测试策略组合,很难有效发挥测试团队的协同作战能力,打赢测试的运动战和歼灭战,下面是我们当时所在管理团队针对团队现状并结合测试策略的基本理论方法, 从业务维度、技术维度和管理维度去综合制定测试策略组合:1) 群组内的配对测试策略。针对基于测试人员业务不熟练而调拨的业务人员测试技术不熟练的问题,测试分组上让测试人员与业务人员搭配,让业务与技术互补,配备业务正组长和技术副组长,让他们各施所长,又相互影响,最终每个UAT测试都能变成技术和业务双能测试人员。 策略分析:有效地规避业务人员测试技术不足,而测试人员业务储备不够的风险。
  2) 基于人员能力层级的测试分工策略。针对测试人员业务能力参差不齐的问题, 专门设立需求分析组,承接所有的上游测试需求分析、案例框架和场景设计,集体评审后,发给中初级人员做案例补全、测试数据准备和测试执行。每一个测试周期对分析组人员与优秀的测试执行人员都业务考核,进行适当岗位轮动和优胜劣汰,持续优化业务分析组的能力。 策略分析:让合适的人做合适的事,让测试考核驱动人员层级流动。
  3) 基于业务场景的测试策略。测试用例的设计全部源于真实的业务场景,全覆盖对应业务曾经的生产事故,业务场景的下一层设计中对所有页面功能点和页面控件做检验, 功能点检验按照一正三反的比例设计。 策略分析:强调负面用例、异常用例的作用,关注程序对错误的处理覆盖。
  4) 基于高频业务的快速回归测试。每个版本上线前,除了对应维护的业务部分做全面的回归外,其他业务则选择Top100的高频业务做必要的快速回归。 策略分析:让测试紧贴生产实际,客户生产关心的业务是测试最应该重点保护的。
  5) 基于不同环境的三轮交叉验证。由于是银行业务,用户广,每个功能点的上线都是经过三轮交叉验证测试,第一轮甲测试员在A环境做初测,通过后则第二轮乙测试员在B环境做复测,复测通过后丙测试员在C环境做回归测试。并且鼓励不同的测试员不要局限评审过的用例,要基于需求多做发散性的随机测试。 策略分析:有效规避基于测试人员个人的思维定式而引发测试盲点和测试不充分的风险。
  6) 基于自动化的冒烟测试。每个开发版本提交后,首先会通过自动化测试来验证版本的配置及代码的可测性。如果冒烟通过率小于90%则直接打回,大于90%小于100%的根据缺陷情况来决定是否退回。持续更新冒烟测试的用例集(动态的)。 策略分析:有效利用自动化工具,用制度把关测试准入关,避免无效测试执行。
  7) 基于测试结果的考核驱动策略。针对测试人员众多、态度及能力良莠不齐的现象,每两个月的上线周期结束后,对所有测试执行人员进行主客观共十个维度的量化评分考核,奖励前三分,通报后六名,清退后三名,也清退连续两次在后六名的人员。这一策略有效发挥了鲶鱼效应,提升了测试人员的积极性和交付能力。 策略分析:利用鲇鱼效应,让测试人员学会居安思危,压力直接转换为动力,有效调动测试人员的自驱力!
  8) 基于测试需求工单的责任人策略。一个测试需求从测试到上线,测试通过的最后报告中有ABC三轮测试人员签字、测试组长签字、测试经理签字,层层责任落实。 策略分析: 问责驱动,让需求工单的测试质量关联多级责任人。从人员业务管理出发,中间整合业务特点设计用例、选择用例、选择环境,融合测试考核和激励策略, 测试策略始终围绕人、业务两个核心,促进人和业务的有机融合,最终提升测试效率和交付质量。
  2.2  某大型证券公司PB系统项目测试 项目背景 : 为抢占核心用户,扩大营业规模,某券商根据重点客户的需求,同时上线了几套PB业务系统。 项目开发规模 : 开发人员50+ 项目测试规模 : 专职测试3人 项目实施难度 :
  PB业务系统直接对接股票、期权、基金、债券、新三板等全市场全品种的核心业务,对测试人员的业务能力的广度和尝试都有非常高的要求。尤其是对风控这一块需要测试人员有较高的业务理解度。
  项目上线测试有显著的测试交付高峰,公司配置的测试只有一个测试管理和两个外包测试执行人员,人手非常紧张。
  开发商也是面对多家券商,开发内部也有任务排期,也有许多分支版本。三个相关系统在三个月内将依次上线,版本控制、测试计划安排都有较大挑战。
  开发人员多数是外包供应商,且是离岸开发,测试沟通角色多且难以实时讨论。
  业务部门基于客户需求,对系统上线期望非常高。上线质量保障压力巨大。
  测试策略运用:
  1) 基于稳定版本测试,节约每一发子弹,严守测试准入关口。严格控制发布的版本频率和质量,累计三次冒烟测试不通过,约谈开发供应商负责人。 策略分析:把关与问责,双管齐下,有效规避开发版本质量太差或缺少内部测试的风险。
  2) 基于业务场景的测试。由于测试人员紧张,且任务相对集中,项目组专门请相关业务模块的老师给测试人员做指导,理清业务流程、列举业务场景,测试人员基于业务场景整理好测试用例,让业务老师帮忙审核把关,确保业务覆盖率。 策略分析:让测试人的技术和业务人的业务有机结合,形成1+1>2的测试合力。
  3) 基于完整业务能力提升的测试执行。俗话说磨刀不误砍柴功,测试经理并未因为人少任务多而盲目地投入测试执行。项目组针对测试人员业务积累有限的现状,组织了9 次系列化的业务培训和技术培训,并调动同一测试供应商的其他另外三名测试人员加入培训,作为测试预备队。 策略分析:曾国藩当年的湘勇未训练成军时都敢违抗圣旨不发兵,也是这个道理,只有测试人员的业务积累到一定程度时,再做去做测试执行才有效果。没有战斗力的拼杀只会徒耗资源、抹杀士气。
  4) 基于业务划分的分批测试。基于业务系统中公共模块之外的业务模板的相对独立性,测试组与开发组约定好相关交付计划,按公共模块到高频业务模块再到低频业务模块。测试组分割包围,逐步测试,最后做一轮集成测试和上线版本测试。 策略分析:合理切割,集中兵力应对重点业务,分批有序执行,这是兵力不足时的必选策略。
  5) 基于业务波及分析的回归测试。由于测试人员较少,有限的资源和时间无法全量回归,测试经理非常珍惜每一份测试人力的合理高效使用。对于回归测试,测试经理会先对每一个版本的代码做两个层次的分析,一是黑盒分析,针对变动的功能点,找出与之相关的业务场景用例和功能点用例,无则立即补充。二是白盒分析,请开发人员协助,整理出代码变化后,相关有调动关系的函数、类或程序包,理清这些函数涉及的功能点和业务路径,最后根据这两层波及分析,精准确定需要回归的用例范围。 策略分析:调动周边开发资源,定向波及分析,有效定位回归范围。最大限度降低回归测试可能不充分的风险。
  6) 基于交叉测试的快速执 行,强调执行效率和可见成果。测试沟通上每日站立晨会同步进度和问题,测试用例重点强调业务场景分析和团队评审,测试缺陷跟踪强调解决问题,开发交付版本进入执行周期时强调普通模块快速测试与重点模块交叉测试相结合,有问题的模块则集中轰炸。 策略分析:抓测试重点,紧跟重点模块和缺陷模块,狠捣缺陷窝,是每个测试人必学的策略。
  7) 按必要场景有序测试和随机发散性测试相结合,既要保证正常需求覆盖率,也要保证异常处理的探索性测试。 策略分析:有序测试是保证覆盖,随机发散探索更依赖测试经验积累,不仅能有效降低漏测风险,更有助于培养测试人员跳出限定边界的测试思维习惯。
  2.3  测试策略运用的经验与教训
  我们在长期的测试管理实践中,总结了一些测试策略运用的经验和教训,主要有以下几点。
  重视自动化测试但不依赖自动化测试,同时考虑自动化测试的投入产出比。
  资源紧张时,更能凸显业务积累的重要性、单兵能力提高的必要性,因此,业务培训需要常抓不懈。能有效提升测试团队的整体素质。
  测试策略的最重要控制就是对测试资源的高效整合和最优化利用。整合和利用的资源中,人是决定性因素,如何调动(或拆借)测试资源,让测试工程师乐意测,测到实处,测有所得,关键一点是要和组员平等相处,为组员的成长着想,从而进行有效的激励。
  凡事预则立,不预则废。在测试策略的制定上需要有预见性的计划,整盘考虑资源、范围、时间、成本、相关干系人诉求等情况,预判困难预判风险。
  工作氛围的营造与控制是测试策略推进和有效执行的保证。首先,负面情绪传导,止于测试经理。其次,战略上要相信一定有解决办法,战术上重视项目中时刻发生的风险问题,调动项目团队的集体力量,并及时寻求公司帮助。
  阶段性测试执行后的沟通总结非常重要,测试反馈推动测试策略优化和微调。
  3. 总结
  本文介绍了测试策略的重要性,重点阐述了测试策略综合运用的两个金融项目实践,最后总结了测试策略综合运用的经验与教训。测试策略实施是测试管理实施的重要组成部分,测试策略管理也是 技术和艺术的综合运用。 测试策略是测试实施的“纲”和“领”,测试策略综合应用没有定法,依项目而定,比较灵活。针对不同的团队,同一项目阶段也可能需要采取不同的测试策略。同样,测试策略的运用不仅是技术的发挥,也是艺术的展现。 “测”无定法,“测”必有法,作为测试工程师和测试管理者,优化测试实践、精进测试管理,任重道远,我们需要不断探索测试策略的新模式新方法,为项目保驾护航。

      上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号