成熟的软件测试是确保软件质量的一种重要手段，自动化测试技术的出现，对于提高测试单位绩效比起了重要作用，被广泛应用于回归测试中，但是由于被测试系统的不确定性和复杂性，使得软件自动化测试变得异常困难。本文基于商业工具结合实际项目，分析自动化测试实施期间出现的各种问题，以提高大家对自动化测试项目的真正认识与理解。
现在自动化测试工具很多，商业的或者开源的，以对象识别为基础的或者以语言特性为基础的等等。在挑选的时候，首先我们要明确被操作软件的范畴和特性，可预知风险，培训潜在成本及是否具备被虚拟化等一系列问题，这些问题可制成标准检查列表，以便确定一个解决一个。在本次自动化测试实施中，首先可知的是被测试软件属于行业金融软件，使用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周内被关闭，唯一重要的就是实施评估报告，报告内容大致包含：周期定义、工具定型描述、应用软件描述、系统框架描述、可能采用的框架描述、可能递交工件描述、可加入业务列表、预测脚本规模、
文章来源于领测软件测试网 https://www.ltesting.net/
