电信IT系统的动化测试实施.docVIP

电信IT系统的自动化测试实施 2011年10月24日Quick Test Professional (以下简称QTP)，探讨实现电信IT产品功能测试自动化的可行性。 QTP简介 QTP软件主要针对界面型的功能测试和回归测试识别WEB应用的对象元素自动捕获、验证和重放行为 由图可知， CRM后台送OSS和OSS竣工返回CRM中间的流程状态需连接数据库查看，这些环节手动实现更快捷有效。 而在CRM前台受理和档案查询模块中则可以考虑自动化测试，包括自动化验证档案信息，需要在前台受理时记录操作要点信息以及订单受理生成的业务号码或订单流水号等。然后，利用数据库检查点对主要信息进行检查比对。 为了排除外系统不可控因素的干扰，确保QTP自动化测试结果的准确性和有效性，建议CRM项目组采取多机多时段的方式运行测试脚本。 比如：预备A、B、C三台测试机，设定A测试机定时启动测试时间为18：00和24：00；设定B测试机定时启动测试时间为20：00和2：00；设定C测试机定时启动测试时间为22：00和4：00。次日对比六个测试任务结果，选取相对完整可靠的测试结果进行分析。 2）管理支撑系统自动化测试实施 以下对电信MSS（管理支撑系统）中的审计管理系统自动化测试实施进行说明。限于篇幅本文仅针对分析结果做简单描述。 审计管理系统主要管理的是审计流程配置后的文件流转，其流程配置千变万化，但每一流程中操作对象范围是相对固定的，我们可以把测试对象库固定下来，最大化实现所有可配置对象的操作脚本；同时可采用流程中某一条标准通路为单位形成基本用例集，并根据实际需要组合用例形成不同通路的用例集。 如果要达到全自动化测试的理想状态，应该是上一流程步骤执行完成后，通过VB编程实现对下一个流程步骤的自动判断和用例调用，但维护成本将超过实际带来的收效。因此最终必须在工作量和回归测试的频度之间加以平衡。 3）IBS（集中计费系统）的自动化测试实施 以下对电信IBS（集中计费系统）自动化测试实施进行说明。限于篇幅本文仅针对分析结果做简单描述。 集中计费系统同样是电信IT运营的核心系统，但对于IBS系统，其前台逻辑较为简单，主要依靠数据库后台程序对话务进行计费处理，因此后台构造数据的工作量占了测试工作的大部分，因此其前台固话界面的自动化测试实施并不能造成效率的大幅提升。 测试脚本的管理和维护 随着项目的进展，一方面测试用例和脚本量会越来越多；另一方面，被测程序的不断更新，也需要同步更新相应的测试脚本。如果没有合理的脚本管理机制，每次程序的变动都会给脚本维护人员带来诸多脚本管理上的问题。 QTP测试脚本的不断增多后，可能需要用多台测试服务器分别运行QTP脚本，这时需要考虑各服务器上测试脚本的版本统一，这个问题建议通过在测试管理工具TestDirect(以下简称TD)上保存QTP测试脚本的方式来解决。但是，TD只能保存最新版本，要随时获取历史版本，建议采用版本控制管理工具SVN进行脚本版本的管控。另外，在测试脚本管理维护中，我们必须采用统一的脚本架构和命名规范，对脚本添加必要的注释，增强测试脚本的可读性。 QTP的缺陷 QTP毕竟只是一个缺乏智能的工具，本身也存在一些缺陷，如： QTP本身并无想象力，对超出设计的意外没有智能的判断和解决能力； 在使用过程中经常发现一些小问题，如：并非所有的动作录制后都能回放，某些对象无法被QTP准确无误的识别等； 要全部实现自动化，其代码的开发量也是相当大的，同时还可能引入新的BUG。 综上，我们认为电信IT系统的手工测试是不可能被完全取代的；测试自动化的进程主要是使自动化测试在整体工作中所占比率逐步、有效的提高，尤其是针对那些界面化、重复化得简单功能逻辑，要尽快采用自动化测试手段。 另外在应用QTP工具的过程中会遇到各种问题，建议测试人员可以把问题抛出来共同讨论解决。同时还可以充分利用网络论坛上的资源，积极寻求解决问题的思路和方法。对于已解决的问题可以形成文档记录，供测试人员交流共享。 结束语 目前电信IT系统的自动化测试应用还处于起步阶段，可能会因为熟练程度不足导致与手工测试相比耗时长、产出低；尤其对于周期短项目。我们要避免将自动化测试和测试人员等同起来，不要对自动化测试要求过高。我们要对自动化测试树立一个正确的观感，清醒地认识到自动化测试是人工测试的有力补充，而无法取代测试人员的地位。　 “罗马城不是一天建成的”自动化测试也是一个积累经验、循序渐进的过程，不期望在短期内实现所有测试的自动化。成功的自动化测试需要制定相应的自动化测试计划，好的自动化测试策略是自动化测试实施是否成功的第一步。只有充分考虑到自身实施自动化测试的风险、资源和目标后，才能制定出适合自己的自动化测试策略，并最终达到提高测试效率降低测试成本的目的。 项