51Testing独家连载:大型IT系统智能一体化测试

发表于:2017-8-21 17:12

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

 作者:陈绍英 许威 金成姬    来源:51Testing软件测试网原创

分享:
  【编辑推荐】
  全面分享了作者推广智能一体化测试的经验
  结合真实案例讲解了如何在银行实施智能一体化测试
  【前言】
  何为智能一体化测试
  关于智能一体化测试,作者先后在多个IT行业技术大会上进行主题演讲,不断分享这一理论及相关平台的最新进展。为了更好地讲解智能一体化测试的理论及开展意义,通常会用6幅图来展示银行IT系统研发现状和测试发展趋势,从而更好地感悟智能一体化测试的创新特色。
  银行IT系统研发特色
  我们可以借助一座高山来描述银行IT系统研发工作的特色,开发、测试、运维各个团队的最终目标是成功爬上山顶,山的坡度可以用来代表系统研发工作的难度。为什么要用大山来描述银行IT系统的研发?银行IT系统的开发真的那么具有挑战吗?这是因为银行在社会中具有特殊的地位,因此其IT系统对功能与性能、稳定性与健壮性也将有非常高的要求,因此其系统的开发、测试、运维的过程如同在爬一座座高山。
  在当下,银行最有难度和挑战的工作就是核心系统再造工程,其难度不亚于攀登珠穆朗玛峰。作者在亲历民生银行新一代核心系统的研发过程后,不断地反思与总结测试过程,终于悟出了智能一体化测试理论,同时研发了智能一体化测试平台,进而对银行后台IT系统更好地进行全生命周期质量管理。
  银行IT系统功能测试现状
  银行IT系统的功能测试实际上仍然以手工测试为主,大部分后台系统的测试主要通过前台渠道来完成。自动化测试在功能测试中所占的比例极低,主要面向一些稳定下来的交易场景的回归测试。
  功能测试人员的优势主要体现在对业务的理解上,在测试过程中体现的技术含量相对较低。感觉功能测试的过程很像是一群人在徒手爬山,大家全靠体力爬到山顶,基本不会采用什么工具。
  银行IT系统功能自动化测试的现状
  银行IT系统的功能自动化测试发展相对落后,整体感觉明显低于互联网公司的自动化测试水平,目前银行领域用得最多的测试工具就是QTP及基于QTP的测试平台。
  银行IT系统功能自动化测试的主要特点是依托渠道来开展测试,而渠道的界面往往很容易发生变化,这会导致很多自动化测试工作推倒重来,最终结果是投入产出不成正比。银行IT系统自动化测试人员的门槛也高于手工功能测试人员,通常具有一定开发能力的测试人员才能从事银行IT系统的自动化测试。
  银行IT系统的自动化测试很像一名越野高手开着一辆豪华越野车,往没有路的山顶去冲,这很容易滑下去或翻车。
  银行后台IT系统接口测试现状
  银行后台IT系统多数采用三种方式来直接测试服务/接口:借助通用工具、厂商提供工具、自开发工具。通用工具指诸如SoapUI之类的商业/免费/开源性质的工具,可以在工具中设计测试案例,然后手工执行;厂商提供工具指系统的平台厂商会提供一些测试工具,例如银联会提供银联8583报文的测试工具,同时可以和银联的系统进行联调;当没有可以用的工具时,开发团队会临时开发一些接口测试工具,以方便调用接口进行功能测试。
  上面的三种方式尽管引入了测试工具,但是没有实现真正的自动化测试。在传统的服务/接口功能测试过程中,测试工具本质上只是报文编辑与发送的工具,而不是用来进行自动化测试。对于接口不是特别复杂、数量也不是特别多的系统,选择上面三种方式之一进行测试是可以满足测试需求的,但对于复杂的系统,应该在测试方法上进行突破,以提高效率和测试效果。
  整体来看,银行IT系统服务/接口测试的技术水平并不高,基本属于基于工具的手工测试。尤其值得关注的是,银行IT系统服务/接口的测试在管理方面也很落后,测试案例在投产运维阶段的复用率很低。这种水平相当于开一辆摩托车来爬山,效率可想而知。
  自动化测试以后台系统为重心
  长期以来,银行IT系统自动化测试的重心主要放在前台渠道上,脚本的开发与维护成本很高,导致其并没有很好地发挥作用。当我们把自动化测试的目标转向后台系统时,将会有一种豁然开朗的感觉,很多问题可以迎刃而解。对后台系统的服务/接口进行自动化测试时,首先是测试脚本与案例相对容易维护,因为服务/接口不会像界面那样变化频繁;其次是可以并行执行测试案例,效率可以大幅提升。
  自动化测试主要面向后台系统,只要我们解决了现有服务/接口测试的问题,可发挥的空间将会非常大。这相当于修了一条盘山路,普通轿车就可以冲上山去。
  终极发展方向——智能一体化测试
  银行IT系统自动化测试需要重点解决两个问题:一个是如何快速开发与执行测试案例,并快速生成测试结果;一个是如何管理测试案例,保证测试案例在开发、测试、运维的各个阶段随时可以执行。
  智能一体化测试完美解决了上面的问题,同时还实现了功能与性能的同步测试。推行智能一体化测试,相当于坐直升飞机上山,我们已经实现了银行IT系统自动化测试的突破性创新。
  认识智能一体化测试平台
  智能一体化测试平台(DefectTerminator,简称DT)是民生银行测试中心自主研发、面向后台系统全生命周期的新一代测试平台,DT将成为软件缺陷的终结者。DT实现了功能测试、性能测试的同步一体化,测试结果分析智能化,测试报告自动化,测试案例执行瞬时化。
  下图是智能一体化测试平台对两个系统的全回归测试案例,可以看到与手工测试相比,测试场景的执行时间几乎可以忽略。案例二中的分布式核心系统案例的执行效率相对较低,是因为系统的很多交易存在性能问题,但智能一体化测试平台可以轻松发现问题交易。
  智能一体化测试平台之所以运行效率如此之高,是因为其主要通过并发的方式来执行案例。并发方式执行测试案例,很容易实现功能、性能的同步测试。
  激动人心的前景分析
  我们以银行的IT系统作为背景,进行一个激动人心的分析:
  多数银行大概有150套到200套IT系统,而其中80%左右的系统为后台系统即主要负责对外提供服务的系统,这些后台系统中能有20%左右属于公共系统,30%左右属于比较重要的业务系统。保守估计一下,我们对后台系统中20%的公共核心服务系统和30%左右的重要业务系统开展接口智能一体化测试,能带来多大的收益呢?
  假设推广智能一体化测试的系统至少可以达到50个以上的规模,每个系统可以节省一个人力成本,那一年可以节省多少个成本呢?50*1*12=600个人月!折合成人民币能有多少呢?可以在心里默算一下。
  如果是银行开发新一代核心系统,在上百套系统的开发过程中开展智能一体化测试,能够节省多少成本呢?想想会更加激动!
  上面只是直接节省成本的估算,接下来再考虑一下推广智能一体化测试间接节省成本情况,主要的收益如下:
  增强了测试人员的实力和水平,不擅长开发的测试人员可以非常容易开展自动化测试,测试团队的武器立刻从冷兵器发展到现代高级武器。
  大量后台系统的缺陷可以在开发阶段解决,大大降低了功能缺陷的修复周期与流转成本,节省了大量UAT测试时的渠道测试成本。
  大量性能问题尤其是响应时间问题可以在开发阶段解决,大大降低了性能问题的修复周期,节省了性能测试团队的成本。
  性能问题尽早解决可大大降低代码变更对功能测试的影响,尤其大幅降低了在UAT测试阶段发现严重性能问题从而对代码进行较大变更的风险,节省了很多潜在问题的修复成本。
  后台模块功能比较稳定后,集成测试与UAT测试阶段在前台渠道更容易定位缺陷,避免了一些问题前后台互相扯皮的情况,大大加快了测试进度。
  后台系统有了好的测试工具,自己进行充分测试后,不再像以前一样很多问题依赖外围系统来发现,大家的关系更和谐。
  借助智能一体化测试平台,可以在系统投产前快速进行案例全集的回归测试,避免了以往投产前部分回归测试不全面的风险,排除了潜在的功能与性能问题,降低了发生生产问题的风险。
  系统在投产后如果进行变更与升级,随时可以进行面向案例全集的全回归测试,这将大幅降低变更或升级后出现生产问题的风险。
  ……
  想想如果在组织中成功推广了智能一体化测试,其带来的价值简直是难以估量的!碰巧老板也非常仗义,拿出一部分节省的成本作为奖金发给大家,是不是有种两眼放光的感觉,所以赶快行动吧!
  实际推广案例分析
  智能一体化测试已经在作者所在的组织进行推广,尤其是在XXX核心系统的测试过程中得到了很好的应用和推广,这是一个全新开发的系统。XXX核心系统在开发阶段全面引入了智能一体化测试,我们可以通过分析看到实际引入效果。系统功能测试从2016年12月12日到2017年2月28日,历时53个工作日。主要统计数据如下:
  主要测试人员3人(未全职投入);
  共涉及关键服务/接口47个,累计设计测试案例2225个;
  实现自动化测试案例1483个,累计执行81150次,发现服务/接口问题1560次;
  平均每日执行案例1531个,平均每日发现接口问题29个。
  和传统服务/接口测试相比,可以得到如下测试投入分析表(单位:人天):
  注:本次测试截止到统计时间,历时53个工作日,人员投入53*3=159人天,其中包含批处理测试30人天左右,因此实际投入接口测试时间为129人天。
  就XXX核心系统而言,智能一体化测试与传统测试进行对比后得出主要结论如下。
  测试需求分析:在测试需求分析环节,智能一体化测试与传统测试并无太大差异,工作量基本一致。
  测试案例设计:在案例设计环节,智能一体化测试与传统测试并无太大差异,工作量基本一致。
  自动化案例开发:智能一体化测试平台则提供了非常强大的案例编写辅助功能,案例开发效率大大提升,传统测试方式使用SoapUI进行案例编写,效率没有优势。
  测试案例维护:智能一体化测试平台提供多种参数来生成测试数据,增加了数据的持久性,例如提供随机数、流水号、日期、文件数据等测试参数,大大降低案例维护成本;采用传统测试,需要经常维护SoapUI中的案例与数据。
  特别值得一提的是,XXX核心系统的服务/接口变化特别频繁,在每次发布的新版本中往往会对原有服务/接口进行一些调整。采用传统测试,服务/接口变化后需要在SoapUI中修改每一个案例,耗费大量时间和精力,这给案例维护带来了极大的不便。智能一体化测试平台则完美解决了这个问题,采用智能一体化测试平台提供的智能服务/接口更新(案例升级)功能,服务/接口更新后只需要重新下载模板,平台将自动根据新老服务/接口模板的差异进行案例升级,保留未发生变动的案例字段值,大大减少了由于服务/接口变化导致的案例重复编写和修改工作。
  数据准备:智能一体化测试平台提供服务组合执行方式,前置服务可以生成测试数据,供后续服务使用,大幅压缩了数据准备时间;采用传统测试,需要提前准备测试数据,并拷贝执行结果数据,供后续接口使用,数据经常由于后续操作失效而成为脏数据,导致经常重新造数,耗时较长。
  例如一个账户,进行销户操作后数据已无效,使用SoapUI需要重新再找一条账户数据;采用智能一体化测试平台,将开户和销户服务捆绑,每次开户后再进行销户,不存在重新准备数据的问题。另外智能一体化平台可以自动执行产生大量账务数据,为XXX系统批量作业案例执行提供了便捷的数据准备方式,测试人员感觉受益良多,间接节省了大量批量作业的数据准备时间。
  测试执行:智能一体化测试平台中非常容易组织测试案例形成各种测试场景,采用并发方式执行场景中的测试案例,效率极高,测试执行环节的耗时几乎可以忽略。相比于传统测试方式,智能一体化平台具备结果自动验证功能,节省大量人工检验测试结果的时间。传统的SoapUI不能进行测试案例大规模地并发执行,需要人工参与测试执行阶段的各个环节。
  回归测试:由于XXX核心系统正在研发当中,服务/接口变更频繁,经常需要全面回归测试,智能一体化测试平台可以一键瞬时完成所有测试案例的执行,在此过程中体现了极大的价值。智能一体化测试平台对于发现问题的案例还可以自动显示结果,免去了人工逐个检查执行结果的烦恼,大大降低了测试风险。
  测试报告:智能一体化测试平台自动生成测试报告,对于存在功能或性能问题的服务/接口进行分析,测试结果一目了然。方便易用的测试结果分析报告,大大提升了问题定位与解决的效率。
  通过上面的分析可以看出:到目前为止,分布式核心系统采用智能一体化测试平台,实际统计得出共投入了129人天;如果采用传统测试方式,总投入工作量预估在345人天左右。从整个测试过程的统计结果看,智能一体化测试相当于传统测试投入的129/345=37%左右;单从智能一体化测试平台相关项的统计结果看,智能一体化测试相当于传统测试投入的(15+45+2+14+3)/(30+70+10+120+60)=27%。在统计时间范围内,总计节省成本(345-129)/22=9.82人月。
  以上只是开发前期测试工作引入智能一体化测试的效益分析。接下来在系统测试、运维阶段的变更与升级测试过程中,在已经完成大部分测试案例设计工作的基础上,智能一体化测试将会体现出巨大的优势。其随时可以极速完成案例全集的执行,将测试效率提升到极致,大幅降低研发成本和加快投产进度。
  本书写作背景介绍
  本书主要为作者的团队在组织中推广智能一体化测试而创作。在本书创作前,已经完成了智能一体化测试平台“DefectTerminator”的大部分开发工作,为了更有效地推广使用这套系统而特别创作了本书,以期达到理论与实践并重的目标。
  本书理论适用范围
  本书理论主要在银行IT系统的开发、测试、运维等工作中总结提出,因此本书理论方法首先适合在银行IT系统的开发、测试、运维等工作中进行推广。
  对于拥有几十套甚至上百套IT系统的其他组织,例如电信类企业,同样可以推广智能一体化测试,进而有效地降低开发、测试、运维成本。
  对于IT规模较小的组织,则可以根据实际情况决定是否推广智能一体化测试。因为这样的组织即使对于一般的自动化测试,也会由于资源有限而不进行投入,反而更倾向于选择容易开展的手工测试。
  如何掌握本书内容
  在学习本书的过程中,重点掌握下面两方面的内容:
  智能一体化测试理论的核心思想。掌握核心思想后,才能理解智能一体化测试的实施意义,从而学会如何进行智能一体化测试需求分析、如何在组织中推广智能一体化测试、如何在具体项目中实施智能一体化测试,最终把智能一体化测试理论的核心思想转化为自己的思想。
  智能一体化测试平台的设计思想。智能一体化测试属于自动化测试,需要通过具体的自动化测试平台才能落实与开展。掌握智能一体化测试平台设计思想后,才能设计并研发出符合自己组织需求的平台,进而在组织中推广智能一体化测试。本书提供了智能一体化测试平台的设计思路,并提供了大量的具体问题的设计方案,读者可以在此基础上更快研发出自己的平台,尽早实施智能一体化测试。
  掌握了智能一体化测试理论的核心思想和平台的设计思想,就掌握了本书的内容精髓,接下来就可以勇往直前地去探索和开拓这一全新的自动化测试领域!
  致谢
  感谢我的老板牛新庄总、张国勇总、毛斌总以及李文老师对智能一体化测试项目的大力支持。在他们的大力支持下,智能一体化测试理论提出后立刻开始进行实践,最终我们成功研发出了自主知识产权的“中国民生银行智能一体化测试平台DT”。
  感谢分布式核心、客户安全平台、用户安全平台、安保基础平台、PE、现金管理、海外零售平台、基金、理财、柜面等开发与测试团队的兄弟姐妹们,他们与我的团队共同完成了首批项目的智能一体化测试工作。
  感谢性能测试团队的建华、许威、志龙、李锋、雅洁,他们一起和我完成了智能一体化测试平台的研发与推广工作。
  感谢功能测试团队的于雪、王海亮、张博,他们在自己负责的项目中积极推广智能一体化测试。
  感谢所有在性能测试领域合作过的朋友,性能测试是智能一体化测试理论的源泉。
  感谢电子工业出版社的郭立、孙学瑛两位老师,她们对本书的出版提供了非常大的支持。
  感谢本书合作者周志龙、金成姬、刘蕙兰、刘建华,本书的写作过程占用了大家大量的休息时间。
  感谢电子工业出版社为本书辛勤付出的所有朋友们。
  尤其要感谢夫人金成姬和宝贝女儿米菲,夫人通篇审校了本书并润色了那些难于理解的句子,还一起和米菲提供了大量本来可以用来陪她们的时间来让我写作。
  【媒体评论】
  “工欲善其事必先利其器”,建设高效易用的自动化测试平台是银行IT系统测试的必由之路。本书的智能一体化测试理论及平台实现了对银行IT系统测试的创新性探索,为提高银行IT系统的研发质量与效率提供了全新的思路与解决方案。
  对于银行、证券等金融领域的大型IT系统,本书具有非常好的借鉴意义。
  ——中国银行软件中心副主任工程师、质量管理部主管陈镔
  如何通过自动化测试提高测试效率、降低测试成本、保障测试质量一直是银行IT测试部门的研究课题以及实践目标。作者基于丰富的银行IT测试实战经验,提出的智能一体化测试理论及方法,符合银行IT实际需要,实用性强,能有效实现降本增效及质量保障目标,应用前景广泛。
  ——中信银行软件开发中心系统测试处负责人吴志刚
  软件测试与测试技术在目前已引起业界广泛的重视,国内有关这方面的教材和参考书也不少,但将传统的功能测试与性能测试完美地融合,并提出智能一体化测试的概念在业界还是首次。本书既包含智能一体化测试的理论、方案,也包含平台的应用与展望,内容丰富详实,体现了作者在测试方面深厚的功底,无论是从事软件测试还是软件开发人员都会从中受益匪浅。总之,本书是近年测试方面难得一遇的好书,值得推荐。
  ——中国银河证券股份有限公司研发中心开发总监王作敬
  优秀的测试人员一定是有思想的,也是有创造性的,对测试工作的准确理解将有助于自身在测试领域成为佼佼者,而本书正是从测试工作的思想出发,帮助测试人员从上而下,对测试工作有一个全局的、系统的认识,建立无偏差的测试思维,扩展了测试人员的工作范畴和知识面,以提高测试人员的整体水平。
  ——国内知名UNIX系统、数据库专家东兴证券总监董国兴
  作者在测试领域,耕耘、践行,摸索出一条具有核心内容的智能一体化测试之路,尤其是在金融领域的测试工作中,已然解决了接口测试方面的核心问题。这对于以后台业务为主的金融业务,具有突破性的重要意义。
  希望本书能够和更多测试领域的专家产生碰撞、讨论和互动,使得作者的思想和产品能够臻于至善,回馈行业!
  ——云和恩墨创始人、OracleACE总监盖国强
  对于测试人员来说,将传统的功能测试与性能测试结合起来,这确实是一个全新的课题,这也是业界第一次提出智能一体化测试的概念。本书蕴含的极富创意的测试思想,一定能给读者带来不一样的启发。依托智能一体化测试理论,并结合目前金融业的测试实践,作者设计了智能一体化测试平台,该平台的设计思想让人受益匪浅。
  ——《大型IT系统性能测试入门经典》、《LoadRunner虚拟用户高级开发指南》作者周志龙
  【目录】
  第一部分 理论篇 
  第1章 智能一体化测试基础理论 2
  1.1 智能一体化测试研究对象 3
  1.2 智能一体化测试提出背景 3
  1.2.1 行业背景 3
  1.2.2 工作背景 4
  1.3 智能一体化测试核心思想 6
  1.3.1 智能一体化测试理论核心 6
  1.3.2 接口智能一体化测试平台 8
  1.3.3 智能一体化测试终极目标 9
  1.4 智能一体化测试实际应用意义 9
  1.4.1 优化流程尽早启动测试 9
  1.4.2 同步测试提高测试效率 10
  1.4.3 改变测试人员工作重心 10
  1.4.4 拓展了功能测试的阵地 11
  1.4.5 开发人员可以测试性能 11
  1.4.6 降低了代码变更频次 12
  1.4.7 降低了性能测试成本 12
  1.4.8 加快集成/UAT测试速度 12
  1.4.9 降低变更的投产风险 13
  1.5 智能一体化测试应用条件介绍 13
  1.5.1 应用的企业组织 13
  1.5.2 应用的测试对象 14
  1.5.3 应用的测试阶段 14
  1.6 智能一体化测试平台建设目标 15
  1.7 智能一体化测试引入效益分析 16
  1.8 本章小结 21
  第2章 智能一体化测试需求分析 22
  2.1 为什么打破银行的接口测试传统 22
  2.2 传统接口测试方法的优缺点分析 25
  2.2.1 传统的服务/接口功能测试方法 25
  2.2.2 传统的服务/接口性能测试方法 27
  2.3 功能测试需求分析 28
  2.3.1 功能测试目标 28
  2.3.2 功能测试范围 29
  2.3.3 功能测试场景 29
  2.3.4 功能问题定位 29
  2.3.5 功能测试报告 30
  2.4 性能测试需求分析 30
  2.4.1 性能测试目标 30
  2.4.2 性能测试范围 32
  2.4.3 性能测试种类 32
  2.4.4 性能测试场景 34
  2.4.5 性能测试标准 35
  2.4.6 性能测试指标 35
  2.4.7 性能问题定位 36
  2.4.8 性能测试报告 36
  2.5 平台公共需求分析 36
  2.5.1 测试服务管理 36
  2.5.2 测试数据管理 37
  2.5.3 测试案例管理 41
  2.5.4 测试场景管理 42
  2.5.5 测试运行管理 43
  2.5.6 测试结果管理 44
  2.6 本章小结 46
  第二部分 方案篇 
  第3章 智能一体化测试平台设计 50
  3.1 系统关键设计概念 50
  3.1.1 测试工厂 50
  3.1.2 测试车间 52
  3.1.3 测试机器人 55
  3.1.4 测试场景 58
  3.1.5 测试案例 60
  3.2 系统逻辑架构设计 63
  3.2.1 系统架构设计与功能模块 63
  3.2.2 系统核心设计与特色功能 66
  3.3 系统核心技术分析 68
  3.3.1 功能与性能同步执行 69
  3.3.2 通用接口调用技术 72
  3.3.3 关联服务调用技术 73
  3.3.4 智能测试参数技术 76
  3.4 系统二次开发接口 85
  3.5 本章小结 88
  第4章 智能一体化测试平台应用 90
  4.1 工作流程介绍 90
  4.2 配置基础信息 92
  4.2.1 工厂参数配置 92
  4.2.2 公共数据配置 93
  4.2.3 案例参数配置 94
  4.2.4 字段信息配置 95
  4.2.5 默认场景配置 97
  4.2.6 默认车间配置 98
  4.3 配置测试工厂 100
  4.3.1 登记系统信息 100
  4.3.2 登记服务信息 101
  4.3.3 关联服务与地址 102
  4.3.4 下载或编辑模板 103
  4.4 设计测试车间 106
  4.4.1 基本信息设置 106
  4.4.2 输入输出设置 108
  4.4.3 校验编辑设置 112
  4.5 设计测试案例 113
  4.6 设计测试场景 115
  4.7 运行与监控场景 116
  4.8 分析测试结果 119
  4.8.1 结果分析步骤 119
  4.8.2 结果目录解析 121
  4.9 本章小结 122
  第三部分 应用篇 
  第5章 智能一体化测试实施方案 126
  5.1 智能一体化测试实施目标 126
  5.2 智能一体化测试实施策略 126
  5.3 智能一体化测试实施原则 128
  5.3.1 选择合适的项目与团队 129
  5.3.2 充分沟通与交流 129
  5.3.3 尽早介入测试 130
  5.3.4 主动维护案例 130
  5.3.5 执行全面测试 131
  5.4 智能一体化测试实施流程 132
  5.4.1 测试工作实施流程 132
  5.4.2 测试平台二次开发 139
  5.5 测试实施过程重难点分析 146
  5.5.1 平台研发资源限制 146
  5.5.2 测试资源投入限制 147
  5.5.3 适应测试平台变革 148
  5.5.4 推广过程遇到问题 149
  5.5.5 形成新的研发流程 153
  5.6 智能一体化测试推广情况 154
  5.7 本章小结 155
  第6章 类FIX协议应用案例 156
  6.1 类FIX协议介绍 156
  6.1.1 类FIX协议说明 156
  6.1.2 类FIX结构示意和举例 157
  6.2 测试需求分析 158
  6.2.1 现有处理方案 158
  6.2.2 工具需求设想 160
  6.3 开发方案定制 160
  6.4 实施效果展示 165
  6.5 本章小结 168
  第四部分 展望篇 
  第7章 智能一体化测试未来展望 172
  7.1 智能一体化测试发展趋势 172
  7.1.1 逐步延伸到单元测试 172
  7.1.2 从后台系统拓展到渠道 173
  7.2 智能一体化测试平台展望 174
  7.2.1 实现多台测试机联合测试 174
  7.2.2 实现多系统同步联动测试 176
  7.2.3 构建测试结果大数据平台 178
  7.3 银行IT系统研发流程展望 180
  7.4 引入全生命周期质量体系 182
  7.5 本章小结 187
  附 录 
  附录A 测试环境检查表 190
  附录B 常见问题说明 195 

51Testing软件测试网将在近期对本书部分章节进行独家连载,敬请关注

查看更多《51Testing软件测试网作品系列》书籍:http://www.51testing.com/html/36/category-catid-136.html

22/2<12
精选软件测试好文,快来阅读吧~

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号