成熟的软件测试是确保软件质量的一种重要手段，自动化测试技术的出现，对于提高测试单位绩效比起了重要作用，被广泛应用于回归测试中，但是由于被测试系统的不确定性和复杂性，使得软件自动化测试变得异常困难。本文基于商业工具结合实际项目，分析自动化测试实施期间出现的各种问题，以提高大家对自动化测试项目的真正认识与理解。

现在自动化测试工具很多，商业的或者开源的，以对象识别为基础的或者以语言特性为基础的等等。在挑选的时候，首先我们要明确被操作软件的范畴和特性，可预知风险，培训潜在成本及是否具备被虚拟化等一系列问题，这些问题可制成标准检查列表，以便确定一个解决一个。在本次自动化测试实施中，首先可知的是被测试软件属于行业金融软件，使用Borland C++Builder语言开发，测试范畴锁定在软件前台需配对后台数据验证，前台由RedHat Linux服务端、自研发中间件和Oracle数据库支撑。一般来说，这种软件应用架构比较清晰，但是GUI层使用了大量的非标准第三方控件，有可能会导致部分对象无法捕获造成实施困难，所以在进入真正的实施前作充分、快速的实验性评估是非常重要的。

职业化的自动化测试团队，应当非常熟悉当前主流的商业或者开源测试工具，这种团队的定义是：技术让位与成本控制，快速实施且能快速递交，精确控制每12周为一周期，项目延时误差小于2天。考虑到脚本会被移交给其他团队执行，所以我们选择了目前在国内应用范围比较广、相关技术资料比较丰富的HP Winrunner和HP QuickTestPro。第一个被评估的是QuickTestPro 9.5版本不带任何插件，结果大量的GUI对象无法被捕捉，不能捕捉意味着不能被操作，所以团队快速转换到Winrunner 9.2版本不带任何插件，实验结果是基本可以正确识别和捕获我们所要操作的GUI对象，满足了对工具的需求。其实QuickTestPro 9.5版本带Delphi插件也可大大增加捕获率，但是使用插件违反了团队定义的工具应用管理规范，也不符合“有对象即可操作”的强硬编程作风。

在工具定义后，需要立刻选择2组典型业务进行试验性测试，这时需要业务专家和脚本专家一起工作。带GUI界面软件测试用例的设计核心问题是：需要精确区分正常测试用例和异常测试用例，按照先异常后正常的实际执行方式，组织最终的测试数据存放关系，一般合适的比例控制在异常75%—正常25%范围内。脚本专家需要快速处理对象识别库，如果涉及到重定义则需要在指定文件中加以注明，因为这部分工作可被复用到后续的项目实施中，避免造成人力成本重复投入。通常实验性阶段主要产生的问题是：

● 该阶段是否会产生脚本框架?答案是否定的，首先自动化测试不一定要有框架，框架产生的唯一目的就是牺牲一部分脚本性能，而对测试数据进行高效、有序的管理。不过在试验性阶段可以考虑这个问题，如果框架是个平台，那么我们可以在这个平台上放置一些我们需要的单位脚本性能监视器或者其他一些东西。由于 Winrunner的描述性编程机能不够，那么在后续正常项目实施中，框架更多被定位于为可测量、可伸缩、可动态、可智能解析测试数据的执行管理。

● 该阶段是否需要考虑测试数据存放问题?答案是否定的，没有必要浪费太多的时间在这种地方，一个文本文件或者干脆不要文件的数据存放形式都可以，关键是成本。

该阶段对于人员的要求是什么?答案是人员需要精干，一个业务专家，一个脚本专家，一个统计专家足够，自动化测试实施非常注重绩效比，绩效比不够根本没必要执行后续的项目，你必须通过实验性测试得出一个准确的结论，就是重复执行多少次脚本，总绩效才可以由负转正。

● 该阶段是否需要考虑环境的问题?答案是的，在这之前就应该安装好虚拟系统了，如果脚本专家的一边开着即时通讯工具一边录制脚本，我们认为这是非常不专业的。系统环境的清洁程度如同医院的手术室，需要提前对各种必须的软件(例如杀毒软件，网管软件等)做好适应性选择，有干扰的，或者影响系统机能的坚决卸载掉。

● 该阶段的硬件是怎么规划的?前端的测试主机需要有同时承受开2—3个虚拟系统的准备，不能产生明显的切换和操作停顿甚至系统假死。虽然 32位的 Windows XP系统不支持4G物理内存，但是经验告诉我们内存容量多多益善，至于CPU和显卡处于正常水平即可。后端使用的硬件需要稳定，因为不是性能测试所以不作太多要求，一切为了成本。

● 该阶段的管理模式和输出是什么?答案是没有太复杂的管理模式，实验性评估一般都会在1周内被关闭，唯一重要的就是实施评估报告，报告内容大致包含：周期定义、工具定型描述、应用软件描述、系统框架描述、可能采用的框架描述、可能递交工件描述、可加入业务列表、预测脚本规模、

可实施技术分析、评估人/时分析、预测实际人/时分析、评估脚本价值、预测实际脚本价值、可能遇到的问题警告等，这些条目都必须一一做出详实而且准确的描述。

实验性评估结束后，需要确定自动化测试实施项目的时间及周期里程碑，我们采用12周为一个周期里程碑，快速发布快速递交的方式以确保整个测试项目的实施成功。在开始的1周内，管理专家需要快速定义对象控制表、项目跟踪表、需求跟踪表、周/发布项目进度、日/问题跟踪表、配置管理须知，脚本专家需要快速定义代码规范、脚本设计维护手册、数据作用说明及填写规范，环境专家需要快速定义虚拟环境配置手册、维护与复制手册，培训专家需要制定实施阶段课程培训体系等，专家都是角色可复用，工作都是实打实的，需要认真对待，缺一不可。

我们通常将项目在快要接近380个可操作对象或者脚本代码接近25000行的时候称之为一个“混乱点”，之所以称为“混乱点”完全是这种项目执行过程中的必然现象，如同飞机速度超过音速时产生的音障一样，正确的对待和处理有助于后续项目实施的健康成长，否则后果不堪设想。

● 经典问题一、文档混乱了。这里的文档混乱并非指文档丢失、残缺或者缺少维护这些低级错误，事实上这里的文档混乱是多个文档内产生了部分内容相同的冗余数据，且这些冗余数据在可控制范围内。“冗余即懒惰”，所以对应的解决方案就是将所有文档转交EPG团队，由专人看管做日终处理，只要不增加本团队的成本我们是非常乐于这么做的。

● 经典问题二、培训热度过高。为了确保脚本周递交转移速度，我们在每周末需要对接应团队做一定培训，很多人(非合作团队)都想增加自己在这方面的知识，所以原来的2小时培训时间被延长到4小时，原来一场25人小团队培训被扩展为二场各180人的培训，很累。直接造成的后果就是很多人要内部转岗来我们团队，这也违背了“简单既是美”。

● 经典问题三、脚本的增加突出了性能的缺失。一旦对象突破380 个(不包含描述性对象)，脚本突破25000行(不包含注释及空行)，不优化，那么在一台机器上的综合运行时间超过了4个小时，所以对代码优化的工作在后续几周的实施中急待解决。对于脚本性能调优，需要综合考虑语言特性、数据结构、外调和对象识别处理，这里需要对TestPackage – TestSuite – TestCase的组合模式进行事务级的时间分析，精确到毫秒。调优的处理有多种，每个团队的方法各不一样，经过综合处理，现在我们能做到35532行脚本、451个对象、37个虚拟对象，合计78个综合处理包全部一台机器上运行，时间可控制在2小时之内。继续压缩时间的资源投入大于产出，这不符合成本控制团队的初衷，所以最终放弃。

● 经典问题四、原来工具的函数有BUG。实际上大规模的代码运用对测试工具本身也是一种考验，一切软件皆有问题，随着时间的推移会逐渐暴露出来。我们发现了测试工具部分函数的会在某些特定环境下出现问题，所以替换这些函数是非常必要的。替换的方法是，使用第三方开发工具(例如VC)开发出可被脚本直接调用的函数(例如各种动态库技术)，以替换原自带问题函数，这样既增加了整体代码的稳定性，又提升了团队的研发能力。例如Winrunner偶尔出现的菜单丢失的问题，都可用自研发函数给予解决。

另外测试工具本身提供的语言也可能存在某些局限性，所以测试团队具备自我开发能力也关系着项目是否能被顺利实施。

● 经典问题五、脚本不动了。实际上这是最让人讨厌的问题，可能涉及的方面非常多，例如系统交互、网络环境、本机环境、软件冲突等等，我们总结了一条处理该类型事件的方法，先排除系统本身，排除干扰软件，再分析比和对卡死位置数据，最后分析脚本本身，例如我们发现部分问题跟字符处理函数有关，这对提高脚本本身的健壮，提出了很高的要求。

项目进行到距离里程碑最后一周，大部分的问题列表需要被提前被关闭，相关递交工件需要被整理评审，脚本经过验证被最终集成转交，这里都需要配置管理来提供良好的控制环境。必须指明的是，日脚本构建和测试是贯穿整个项目周期的，这种做法能使脚本的开发状态得到频繁的更新，以及尽早发现设计和集成的缺陷。为了充分利用时间与设备资源，夜晚21点后，脚本的自动执行测试(这里多数指的是系统测试或回归测试)是一个非常行之有效的方法。一切都顺利的话，等到第二天上班时，测试结果就已经在相关人员的邮箱里面了，通过这份报告，你可以知道那些脚本是必须修改的，如果不太清楚还有一份更详细的截图列表辅助定位，准确告诉你当时软件究竟出现了什么现象导致了问题的产生。

最终该项目第一阶段在12周且延长6个小时后被准确的关闭，并且通过了严格的部门验收，6人参与到这个项目中，合计2916个有效工作时。经过计算每行代码价值为1.77元，总的来说还算是成功的，那么接下来第二个阶段里面，我们能否将每行代码价值控制在1元以下，请各位拭目以待。