做完分析工作，就可以继续业务的组织和脚本的开发工作了，这两个可以并行开展。把分析阶段的输出做为输入，有序开展后续活动。
对于业务的分析组织，主要参与者是熟悉系统业务的人员。现在的应用系统越来越复杂，如果没有业务人员参与进来恐怕很难把测试做到位。这个过程就是由熟悉业务的人员来组织需要测试内容。包括测试功能点，业务逻辑，业务范围等等。同时针对特殊业务规则，数据规则提出相应的需求，协调其他资源满足特殊需求。这个过程也是组织测试案例、测试数据的过程，为测试执行做准备工作。这个过程的输出就是测试内容的跟踪表了。
与业务并行开展的就是脚本的设计与开发了。它不会受限与测试流程、测试逻辑的限制，完全可以按照分析过程的跟踪表进行脚本的开发。这个过程脚本的设计和开发是两个独立的过程，设计是以文档的方式展现脚本，包括脚本信息、输入/输出参数、调用说明、脚本流程图等内容，这样做可以让团队成员之间很好的协作，避免出现混乱、失控的状态。而且脚本的设计人员不用考虑具体的业务逻辑，只要按照既定规则把划分好的脚本设计好就完成了任务。然后脚本的开发人员严格按照设计文档进行开发，最终形成脚本集，供其他环节调用。
以上各个活动都会有管理或是QA参与，进行活动的评审，确保各个环节都是按照规范进行的，保证自动化实施过程是在可控范围内进行的活动，避免某个环节的随意性。
技术
技术角度，主要是决定采用什么样的工具，脚本开发工具，配置管理工具。还有就是要制定针对在工具的使用过程中要遵循的规范，如何让工具之间配合，发挥最大的作用。
功能自动化测试用的最多的莫过于QTP了，由于它的简单、易用，容易上手很是受大家的追捧。当然还有它能够破解，这也为它广泛推广打下很好的基础。
技术环节需要对脚本的开发做出明确的说明。底层函数的定义，功能函数的开发，函数库的规划，参数、脚本的开发规范等这些都要形成文档。最后脚本的运行也是一个很关键的环节，包括运行的稳定性，效率，日志，失败的处理这些都是需要处理的问题。如果条件允许可以自己开发工具来解决这些问题，但相应带来的成本也是非常高的。这样做的公司都是有单独的团队来维护测试工具这一块的，所以在人力、技术资源很有限的情况下不要轻易尝试这种方式。同行用的最多的好像就是用Excel来组织，然后通过读取Excel来控制脚本的运行，这种方式简单，易行，但对于过于复杂的系统不适用。还有一种方式就是用QTP+QC的方式，QC有单独的模块来管理，组织这些内容。并且会自动记录执行日志，结果文件等。这种方式是最方便，成本最低的一种方式，维护起来也很容易，而且没有不兼容的情况，很容易见到效果。如果公司不打算组建专门的测试开发团队，用这个是最有效的一种方式。缺点是在组织数据时的灵活性欠佳。
团队
功能自动化测试肯定是一个团队协作的过程，单枪匹马去做自动化是非常不明智的选择。整个团队应该包含几个角色：leader，熟悉业务的人员，脚本设计开发人员，测试执行人员。人员各司其职，互相配合。
根据项目具体情况，酌情增减人员。很理想的情况是公司有很好的测试流程，分工明确，各个岗位都有明确的岗位职责，这样可以是团队成员紧密的配合完成工作。但也有很多不理想的状况，这时作为一个功能自动化测试的实施人员，也要对自己的工作做好规划，什么阶段做什么事情，每个阶段的提交物有一个明确的思路。这样可以使自己很好的控制进度，对上边也有一个交代，让领导知道做了什么。
管理
最后简单说一下管理。这个也是一个重要环节，好的管理可以很好的控制进度，保证质量。管理人员要对测试计划的执行情况进行监督，参与各种成果物的评审，项目的例行会议并保存会议记录，对测试流程的不断改进，对测试方法、技术的不断探索。在团队遇到困难时，也要及时的给出友情支持。这些内容有些属于QA的范围，具体公司具体配备相应人员。
以上只是自己对功能自动化测试的点滴思考，写出来算是自己的一个总结。每一个环节还有待完善，补充的地方，测试的博大精深并不是简单的几行字能写出来。希望在工作当中不断的总结，不断的提高。
严格意义来说，不应该称之为对框架的思考，框架是一个系统，是一个整体，而以上只是对一部分内容做了点滴体会。是与非，看官自己定夺。
文章来源于领测软件测试网 https://www.ltesting.net/
