谈到测试框架，很多人都趋之若鹜，自己也不例外。但最近发现自己对测试框架的理解一直存在误解。很长时间对框架的理解，一直存在于如何组织脚本，如何写出高质量的脚本这个层次，整个框架好像就是针对脚本这个层面。其实这个理解很局限也很片面。一个好的测试框架，应该包含整个测试静止的各个方面，以及对各个环节的规范、管理等等，所以脚本只是框架当中的一个环节，不应把脚本看的很重(当然不是说不主要)。脚本是用工具写的，工具永远是工具，整个测试过程起关键作用的还是人。
一个合理的框架应该包含流程、团队、技术这三个基础要素，再用管理把这三个要素谐和起来。
如图，这三个要素是相辅相成互相依赖。
流程
首先谈一下流程。这个要素，在整个测试静止周期中是用时最长的一个，大部分的测试静止都是在流程中进行。一个好的流程能够节约成本，延出息度，提高测试质量。设计流程，不能为了自动化而自动化，要结合项目状态、目前测试部门开展状态来计划功能自动化测试流程。
流程的计划应该掩饰自动化测试分析，业务流程的分析与组织，脚本的设计与开发。
拿到项目责任书后，首先要进行的就是自动化测试分析。这时要结合手上有的测试资源，如待测系统，测试需求，测试用例库，功能说明等等，对系统来个综合分析。这些作为分析阶段的输入。有输入就要有输入，也就是分析效果了。分析过程就是对业务的分析，对怎么计划脚本的分析。对业务的分析最终要得出本次或本论测试需要测试范围、内容，以及测试内容对需求的掩饰状态等内容，最终形成业务跟踪表，作为输入。对于计划脚本，就是要肯定哪些功能能够做自动化，哪些不能做;哪些功能需要单独作为一个脚本来写，哪些功能相宜合并成一个脚本来写;参数的定义，主要是针对多个脚本都要用到的变量给出定义;其他能够定义一些脚本的相关信息。最终也要形成脚本分析跟踪表，作为分析阶段的输入，纳入测试资产统一管理。有了这些作为基础，能够最大限度保证后续责任在可控范围内进行。
做完分析责任，就能够继续业务的组织和脚本的开发责任了，这两个能够并行开展。把分析阶段的输入做为输入，有序开展后续静止。
对于业务的分析组织，主要加入者是熟悉系统业务的人员。现在的应用系统越来越复杂，如果没有业务人员加入进来恐怕很难把测试做到位。这个过程就是由熟悉业务的人员来组织需要测试内容。包含测试功能点，业务逻辑，业务范围等等。同时针对特殊业务规则，数据规则提出相应的需求，谐和其他资源满足特殊需求。这个过程也是组织测试案例、测试数据的过程，为测试执行做准备责任。这个过程的输入就是测试内容的跟踪表了。
与业务并行开展的就是脚本的设计与开发了。它不会受限与测试流程、测试逻辑的限制，完全能够遵循分析过程的跟踪表进行脚本的开发。这个过程脚本的设计和开发是两个独立的过程，设计是以文档的方式展现脚本，包含脚本信息、输入÷输入参数、调用说明、脚本流程图等内容，这样做能够让团队成员之间很好的协作，避免出现紊乱、失控的状态。而且脚本的设计人员不用推敲具体的业务逻辑，只要遵循既定规则把划分好的脚本设计好就完成了责任。然后脚本的开发人员严肃遵循设计文档进行开发，最终形成脚本集，供其他环节调用。
以上各个静止都会有管理或是QA加入，进行静止的评审，确保各个环节都是遵循规范进行的，保证自动化实施过程是在可控范围内进行的静止，避免某个环节的随意性。
技术
技术角度，主要是选择采用什么样的工具，脚本开发工具，配置管理工具。还有就是要制定针对在工具的应用过程中要遵循的规范，如何让工具之间配合，发挥最大的作用。
功能自动化测试用的最多的莫过于QTP了，由于它的简单、易用，随意上手很是受大家的追捧。当然还有它能够破解，这也为它广泛推广打下很好的基础。
技术环节需要对脚本的开发做出清楚的说明。底层函数的定义，功能函数的开发，函数库的计划，参数、脚本的开发规范等这些都要形成文档。最后脚本的运行也是一个很关键的环节，包含运行的稳定性，效率，日志，失败的解决这些都是需要解决的问题。如果条件许可能够自己开发工具来解决这些问题，但相应带来的成本也是非常高的。这样做的公司都是有单独的团队来掩护测试工具这一块的，所以在人力、技术资源很有限的状态下不要随意尝试这种方式。同行用的最多的好像就是用Excel来组织，然后通过读取Excel来控制脚本的运行，这种方式简单，易行，但对于过于复杂的系统不适用。还有一种方式就是用QTP+QC的方式，QC有单独的模块来管理，组织这些内容。并且会自动记录执行日志，效果文件等。这种方式是最方便，成本最低的一种方式，掩护起来也很随意，而且没有不兼容的状态，很随意见到效果。如果公司不希图组建专门的测试开发团队，用这个是最有效的一种方式。缺点是在组织数据时的灵活性欠佳。
文章来源于领测软件测试网 https://www.ltesting.net/
