小思功能自动化测试框架

发表于:2015-08-27来源:uml.org.cn作者:不详点击数: 标签:
谈到测试框架,很多人都趋之若鹜,本人也不例外。但最近发现自己对测试框架的理解一直存在误解。很长时间对框架的理解,一直存在于如何组织脚本,如何写出高质量的脚本这个层

  谈到测试框架,很多人都趋之若鹜,本人也不例外。但最近发现自己对测试框架的理解一直存在误解。很长时间对框架的理解,一直存在于如何组织脚本,如何写出高质量的脚本这个层次,整个框架好像就是针对脚本这个层面。其实这个理解很局限也很片面。一个好的测试框架,应该包括整个测试活动的各个方面,以及对各个环节的规范、管理等等,所以脚本只是框架当中的一个环节,不应把脚本看的很重(当然不是说不重要)。脚本是用工具写的,工具永远是工具,整个测试过程起关键作用的还是人。

  一个合理的框架应该包括流程、团队、技术这三个基本要素,再用管理把这三个要素协调起来。

  如图,这三个要素是相辅相成互相依赖。

  流程

  首先谈一下流程。这个要素,在整个测试活动周期中是用时最长的一个,大部分的测试活动都是在流程中进行。一个好的流程可以节约成本,缩短进度,提高测试质量。设计流程,不能为了自动化自动化,要结合项目情况、目前测试部门发展情况来规划功能自动化测试流程。

  流程的规划应该覆盖自动化测试分析,业务流程的分析与组织,脚本的设计与开发

  拿到项目任务书后,首先要进行的就是自动化测试分析。这时要结合手上有的测试资源,如待测系统,测试需求测试用例库,功能说明等等,对系统来个综合分析。这些作为分析阶段的输入。有输入就要有输出,也就是分析结果了。分析过程就是对业务的分析,对怎么规划脚本的分析。对业务的分析最终要得出本次或本论测试需要测试范围、内容,以及测试内容对需求的覆盖情况等内容,最终形成业务跟踪表,作为输出。对于规划脚本,就是要确定哪些功能可以做自动化,哪些不能做;哪些功能需要单独作为一个脚本来写,哪些功能适合合并成一个脚本来写;参数的定义,主要是针对多个脚本都要用到的变量给出定义;其他可以定义一些脚本的相关信息。最终也要形成脚本分析跟踪表,作为分析阶段的输出,纳入测试资产统一管理。有了这些作为基础,可以最大限度保证后续工作在可控范围内进行。

  做完分析工作,就可以继续业务的组织和脚本的开发工作了,这两个可以并行开展。把分析阶段的输出做为输入,有序开展后续活动。

  对于业务的分析组织,主要参与者是熟悉系统业务的人员。现在的应用系统越来越复杂,如果没有业务人员参与进来恐怕很难把测试做到位。这个过程就是由熟悉业务的人员来组织需要测试内容。包括测试功能点,业务逻辑,业务范围等等。同时针对特殊业务规则,数据规则提出相应的需求,协调其他资源满足特殊需求。这个过程也是组织测试案例、测试数据的过程,为测试执行做准备工作。这个过程的输出就是测试内容的跟踪表了。

  与业务并行开展的就是脚本的设计与开发了。它不会受限与测试流程、测试逻辑的限制,完全可以按照分析过程的跟踪表进行脚本的开发。这个过程脚本的设计和开发是两个独立的过程,设计是以文档的方式展现脚本,包括脚本信息、输入/输出参数、调用说明、脚本流程图等内容,这样做可以让团队成员之间很好的协作,避免出现混乱、失控的状态。而且脚本的设计人员不用考虑具体的业务逻辑,只要按照既定规则把划分好的脚本设计好就完成了任务。然后脚本的开发人员严格按照设计文档进行开发,最终形成脚本集,供其他环节调用。

  以上各个活动都会有管理或是QA参与,进行活动的评审,确保各个环节都是按照规范进行的,保证自动化实施过程是在可控范围内进行的活动,避免某个环节的随意性。

  技术

  技术角度,主要是决定采用什么样的工具,脚本开发工具,配置管理工具。还有就是要制定针对在工具的使用过程中要遵循的规范,如何让工具之间配合,发挥最大的作用。

  功能自动化测试用的最多的莫过于QTP了,由于它的简单、易用,容易上手很是受大家的追捧。当然还有它能够破解,这也为它广泛推广打下很好的基础。

  技术环节需要对脚本的开发做出明确的说明。底层函数的定义,功能函数的开发,函数库的规划,参数、脚本的开发规范等这些都要形成文档。最后脚本的运行也是一个很关键的环节,包括运行的稳定性,效率,日志,失败的处理这些都是需要处理的问题。如果条件允许可以自己开发工具来解决这些问题,但相应带来的成本也是非常高的。这样做的公司都是有单独的团队来维护测试工具这一块的,所以在人力、技术资源很有限的情况下不要轻易尝试这种方式。同行用的最多的好像就是用Excel来组织,然后通过读取Excel来控制脚本的运行,这种方式简单,易行,但对于过于复杂的系统不适用。还有一种方式就是用QTP+QC的方式,QC有单独的模块来管理,组织这些内容。并且会自动记录执行日志,结果文件等。这种方式是最方便,成本最低的一种方式,维护起来也很容易,而且没有不兼容的情况,很容易见到效果。如果公司不打算组建专门的测试开发团队,用这个是最有效的一种方式。缺点是在组织数据时的灵活性欠佳。

原文转自:http://www.uml.org.cn/Test/2009040910.asp

...