最近发现自己对测试框架的理解一直存在误解。我对测试框架的理解很长时间内，一直存在于如何组织脚本，如何写出高质量的脚本这个层次，整个框架好像就是针对脚本这个层面。现在发现这个理解很局限也很片面。
一个好的测试框架，应该包括整个测试活动的各个方面，以及对各个环节的规范、管理等等，所以脚本只是框架当中的一个环节，不应把脚本看的很重(当然不是说不重要)。脚本是用工具写的，工具永远是工具，整个测试过程起关键作用的还是人。
一个合理的框架应该包括流程、团队、技术这三个基本要素，再用管理把这三个要素协调起来。
如图，这三个要素是相辅相成互相依赖。
流程
首先谈一下流程。这个要素，在整个测试活动周期中是用时最长的一个，大部分的测试活动都是在流程中进行。一个好的流程可以节约成本，缩短进度，提高测试质量。设计流程，不能为了自动化而自动化，要结合项目情况、目前测试部门发展情况来规划功能自动化测试流程。
流程的规划应该覆盖自动化测试分析，业务流程的分析与组织，脚本的设计与开发。
拿到项目任务书后，首先要进行的就是自动化测试分析。这时要结合手上有的测试资源，如待测系统，测试需求，测试用例库，功能说明等等，对系统来个综合分析。这些作为分析阶段的输入。有输入就要有输出，也就是分析结果了。分析过程就是对业务的分析，对怎么规划脚本的分析。对业务的分析最终要得出本次或本论测试需要测试范围、内容，以及测试内容对需求的覆盖情况等内容，最终形成业务跟踪表，作为输出。对于规划脚本，就是要确定哪些功能可以做自动化，哪些不能做;哪些功能需要单独作为一个脚本来写，哪些功能适合合并成一个脚本来写;参数的定义，主要是针对多个脚本都要用到的变量给出定义;其他可以定义一些脚本的相关信息。最终也要形成脚本分析跟踪表，作为分析阶段的输出，纳入测试资产统一管理。有了这些作为基础，可以最大限度保证后续工作在可控范围内进行。
做完分析工作，就可以继续业务的组织和脚本的开发工作了，这两个可以并行开展。把分析阶段的输出做为输入，有序开展后续活动。
对于业务的分析组织，主要参与者是熟悉系统业务的人员。现在的应用系统越来越复杂，如果没有业务人员参与进来恐怕很难把测试做到位。这个过程就是由熟悉业务的人员来组织需要测试内容。包括测试功能点，业务逻辑，业务范围等等。同时针对特殊业务规则，数据规则提出相应的需求，协调其他资源满足特殊需求。这个过程也是组织测试案例、测试数据的过程，为测试执行做准备工作。这个过程的输出就是测试内容的跟踪表了。
文章来源于领测软件测试网 https://www.ltesting.net/
