5.5 测试实施过程重难点分析
智能一体化测试平台测试平台的推广与实施并不是一件非常容易的事情，作者团队在近一年的推广过程中，进行了各种各样的调整，克服了重重困难。下面是总结的一些推广过程遇到的重难点问题以及相应的应对策略。
5.5.1 平台研发资源限制
智能一体化测试平台是一个系统，需要投入大量的研发成本才能投产使用。而对于多数组织，在没有见到成效前，不会轻易投入资源来开展这项工作，尤其是不会以正式的开发项目立项的方式来开发平台。
以作者单位民生银行的智能一体化测试平台为例，在开发阶段主要由性能测试团队三个成员来负责开发：两个人负责后台开发，一个人负责前台界面开发。开发团队在负责开发的同时还要完成日常性能测试工作，最终研发了两年左右的时间才投入使用，其代码规模10万行以上，且目前仍在开发中。测试团队的开发能力毕竟有限，开发过程会遇到各种各样的技术问题，这无疑会影响项目的投产进度。
在推广过程中，仍然会遇到各种新的测试需求、服务/接口调用上技术难题，往往一个项目就会独占一个甚至两个人员来解决技术问题。有限的研发资源，无疑大大降低了智能一体化测试平台的推广进度。
5.5.2 测试资源投入限制
无论对于新开发项目还是对于已投产项目，推广智能一体化测试都会受到测试资源投入方面的限制。对于新开发项目，项目在开发阶段投入的测试人员往往较少，甚至没有专职的测试人员可以投入；对于已投产的项目，往往保留一到两个测试人员来对日常变更进行测试。这种背景下，推广智能一体化测试首先要解决测试人力资源问题。
下面以智能一体化测试平台实际投产的部分项目为例，介绍一下推广过程遇到的测试资源投入限制问题以及应对策略。
●支付引擎
整个项目投产后只有一个功能测试人员（隶属于开发团队，属于开发团队的内部测试人员），负责系统日常变更与升级的测试。由于是后台关键业务模块，因此唯一的测试人员基本是超负荷工作，根本无暇顾及推广工作。
从与项目组沟通确定推广智能一体化测试开始，整整将近半年的时间毫无实际进展，技术方面已经没有任何问题。主要问题是没有人将现有案例迁移到智能一体化测试平台中，导致推广工作时断时续。推广前期无论是项目开发组还是测试中心的团队，都没有稳定的资源投入到推广工作中。
解决策略是性能测试团队安排两个人专职人员，在项目组的配合下花了将近一个月的时间完成核心业务案例的设计，然后每日执行一次案例全集的场景测试。待项目组看到智能一体化测试的实施效果后，将工作交接到项目组，由项目组逐步补充案例，实现最终的推广目标。
●海外新核心
从推广团队对项目组测试团队进行培训开始，将近3个月时间基本没有什么进展。推广延期的主要原因是项目组人力资源有限，没有人来实施智能一体化测试。
最终为了启动智能一体化测试，项目组招聘了一名专职人员来负责智能一体化测试的实施工作，目前正在推广实施中。预估接下来还得投入半年左右的时间，部分关键系统能够实施智能一体化测试。
5.5.3 适应测试平台变革
引入智能一体化测试后，需要在观念上和研发流程上进行改变。推广过程中发现很多时候大家还是习惯用以前的思维来进行测试，主要体现在两个方面：一是不愿意引入测试平台，即使原有的测试工具效率低下也不愿意更换；二是仍然按照以前的思维来进行测试。
在客户安全平台的推广过程中，由于项目组已经有了早期开发团队提供的半自动化测试工具，测试人员已经习惯使用，不愿意投入成本来转移案例。通过与项目组反复沟通与分析，使项目组看到智能一体化测试平台可以在执行效率方面带来大幅提升，终于接受采用新的平台来进行测试。
在测试观念上，感觉适应新的测试流程与规范需要一个过程。例如刚使用智能一体化测试平台时，很多测试人员仍然期望设置每次的执行范围。实际由于测试平台可以极速执行测试案例，因此每次测试时应该尽可能执行已有案例的全集，除非案例不具备执行条件。对于观念的更新，需要不断地积极推广才能深入人心。
5.5.4 推广过程遇到问题
智能一体化测试理论是一种全新的理论，基于该理论实现的智能一体化测试平台也是一个全新的平台，理论与平台都需要一个接受的过程。在测试平台推广过程中，开发与测试人员转变传统测试思想，理解并接受新的测试理论、接纳和使用新的测试平台，都无疑会遇到各种各样的问题，这些都将会影响推广进度。
下面是实际推广过程中遇到的挑战：
●新测试理论的接受
问题描述：
大部分测试人员还意识不到接口功能、性能一体化测试的重要性，错误地认为通过界面做一些业务功能测试即可涵盖接口的功能测试，待功能稳定后再做性能测试即可。有些项目经理、测试经理甚至也不容易转变思想，认为接口测试可有可无，只顾眼前利益，不愿意花费人力资源增加接口测试环节。
解决策略：
（1）通过不断开展智能一体化测试理论的培训，逐步使开发和测试人员理解新理论的重要性。
（2）逐步形成规范的测试流程，在流程中增加接口测试环节，从而增强开发测试人员对于智能一体化测试理论的理解。
（3）运用智能一体化测试理论，使测试流程平台化，扩大测试理论的受众，引导开发与测试人员接受新测试理论。
●新测试平台的适应
问题描述：
部分功能测试人员熟练于在界面上进行功能测试，认为学习新的测试工具耗费时间，对于新事物存在一定的恐惧心理；部分没有界面的后台系统测试人员，可能已经习惯于使用Soap UI等工具，先入为主，使用新工具的意愿不是那么强烈。
解决策略：
（1）首先从开发层面不断收集用户需求，增加工具的功能性和易用性。智能一体化测试工具经过不断优化与改进后，与传统接口测试工具对比能够体现出自身特有的优势。
（2）不断开展工具使用培训，形成文档、视频、最佳实践等教学内容，使用户感到轻松易学，方便上手操作。
（3）为每一个项目制作接口案例的自动化测试典型案例，并协助调试通过，引导用户积极主动地使用新的测试平台。
（4）用事实案例来说话。通过已推广项目组借助智能一体化测试工具带来效率大幅提升的案例，增加新用户的使用意愿。
●技术上的挑战
问题描述一：
银行IT系统复杂繁多，涉及各类通信协议，例如：Web Service、Socket、SAP、类FIX等。智能一体化测试平台需要支持以上各类协议的接口测试，每个独立的协议都需要不同的解析和处理技术，而且可能会不断地增加新的协议。
解决策略一：
平台的设计要充分考虑未来的可扩展性，通过利用抽象和多态技术，采用模块化的设计理念，便于新协议加入时的快速组装和应用。
问题描述二：
对于Web Service协议接口，由于不同项目组的开发能力不同，因此存在一部分接口的标准化、规范化较差，导致智能一体化测试平台需要具备较高的容错性。
解决策略二：
对于一般的标准化问题，可以加强智能一体化测试平台对Web Service解析和处理相关代码的容错能力，不断地收集各种异常情况，加强程序的自动化处理，增加平台的健壮性；对于较为严重的规范化问题，由测试人员上报缺陷，要求项目组优化代码，提高规范性。
问题描述三：
对于Socket协议接口，由于无统一的规范标准，因此各个项目组会按照自己制定的规范进行设计和开发，给智能一体化测试平台的Socket协议处理模块带来了较大的挑战。
解决策略三：
通过不断积累各类基于Socket协议系统的接口设计特点，抽象出公共部分，形成配置项，例如：抽象出报文头中的“数据包长度”、“数据包长度是否包含其自身长度”等属性，从而增加通用性，对于差异化的部分，通过代码进行个性化处理。
问题描述四：
对于类FIX协议接口，由于其规范复杂，报文拼装烦琐，报文中存在不可见ASCII字符，例如<SOH>（0x01，即报头开始）字符，因此用户进行报文值的设置和拼装难度较大，容易出错，易用性较差。
解决策略四：
加深对FIX协议的理解，通过设置配置项完成通用配置；通过在代码中进行复杂格式的解析，屏蔽对用户的难点部分，展示给用户的仅仅是字段值的简单填写，复杂的拼装和不可见字符的添加、报文长度等的计算都由后台完成，从而降低使用门槛，提升用户体验。
问题描述五：
接口频繁变更，导致接口模板要不断地更新，已编写的案例不能自动调整适应。
解决策略五：
智能一体化测试平台增加案例自适应模块，对于模板的变化进行智能分析。例如对于系统新增或删除了某些字段或结构体，字段名称的大小写变化等，分析完毕后自动调整案例进行来适应接口，用户在此基础上进行案例更新，可以节省大量工作量。
问题描述六：
接口自动化测试案例执行后，主要通过返回报文中的成功标识字段来判断案例是否成功，这种方式并不能充分保证一些特定案例在内部业务逻辑上是否真的成功。
解决策略六：
智能一体化测试平台通过增加表达式验证功能模块，为用户提供表达式设置界面。用户可根据业务逻辑，设置特定表达式来验证这类案例的执行情况。例如：原始金额－取款金额＝余额。案例执行过程中，不仅验证返回成功与否的标识，还对表达式进行验证，从而提高案例的有效性。
●报文获取方式
问题描述：
推广中，发现部分测试人员，对于如何为接口字段赋值比较苦恼；单纯的通过接口文档，进行报文的填写，那么如何保证填写的值有效？例如填写了一个数据库中根本不存在的用户信息，必然导致查询失败；某些接口字段繁杂，报文字段的赋值和拼装耗时耗力。
解决策略：
（1）通过在前台页面按照接口对应的业务功能进行操作，从系统后台查看日志，找到对应的输入报文，将报文中对应的字段值填写到智能一体化测试平台即可。
（2）对于部分不能熟练查看日志的测试人员，为其定制开发一些报文抓取小工具，协助其自动来获取报文。
5.5.5 形成新的研发流程
对于一个新开发的后台系统，基于智能一体化测试平台形成新的研发流程，从而有效控制测试成本、提升产品质量、加快投产进度才是最终目标。实际推广过程中，往往遇到各种挑战。
以分布式新核心系统为例，在推广过程遇到如下问题：由于测试环境的硬件资源有限，无法大规模并行执行测试案例，因此调用服务/接口过程设置了大量延迟时间，结果导致初期设计的2000多条案例需要二十多分钟才能执行完成。同时开发前期系统功能也不是特别稳定，每次测试通过率90%左右。测试人员分析问题要耗费大量时间，开发人员同样不能做到当日解决问题。推广前期智能一体化测试平台只能做到每周执行一次案例全集的测试，这无疑大幅降低了效率。
因此对于新开发的后台系统，应该更早介入测试。系统的服务/接口不断开发完成并发布，可执行的测试案例也会逐步增加，系统的功能也会逐步稳定，可以做到开发与测试当日发现和解决问题。最终会形成一个高效率的研发流程。
5.6智能一体化测试推广情况
自2016年以来，智能一体化平台在民生银行已经累计推广了八个系统，如图5-10所示。到2017年3月17日为止，总共设计了测试场景200个、测试案例4421个，累计完成42万多次服务调用。
图5-10智能一体化测试推广统计
5.7本章小结
本章主要结合作者推广智能一体化测试的实际经验，深入介绍了智能一体化测试的实施方案。尽管智能一体化测试平台属于组织内部开发的产品，但推广一套基于新测试理论的平台，仍然是一项非常有挑战的工作。
结合作者所在银行的实际推广经验，本章详细地介绍了智能一体化测试的实施目标、实施策略、实施原则、实施流程等关键实施要素，最后还分析了实施过程的重点与难点。
每个组织往往各有特色，推广智能一体化测试平台时一定结合团队和IT产品的特点来制订推广方案，逐步完成推广目标。当智能一体化测试的价值逐步显现后，其推广与实施的道路将会越来越宽！
本文选自《大型IT系统智能一体化测试》第五章，本站经电子工业出版社和作者的授权。
版权声明：51Testing软件测试网获电子工业出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
