2.1.2适合自动化测试的情况自动化测试之所以能在很多大公司实施起来，就是有它适合自动化测试的特点和高的投资回报率。 产品型项目。产品型的项目，每个项目只改进少量的功能，但每个项目必须反反复复的测试那些没有改动过的功能。这部分测试完全可以让自动化测试来承担， 同时可以把新加入的功能的测试也慢慢地加入到自动化测试当中。 增量式开发、持续集成项目。由于这种开发模式是频繁的发布新版本进行测试，也就需要频繁的自动化测试，以便把人从中解脱出来测试新的功能。 能够自动编译、自动发布的系统。要能够完全实现自动化测试，必须具有能够自动化编译，自动化发布系统进行测试的功能。 当然，不能达到这个要求也可以在手工干预的情况下进行自动化测试。 回归测试。回归测试是自动化测试的强项，它能够很好的验证你是否引入了新的缺陷，老的缺陷是否修改过来了。在某种程度上可以把自动化测试工具叫做回归测试工具。 多次重复、机械性动作，将烦琐的任务转化为自动化测试。自动化测试最适用于多次重复、机械性动作，这样的测试对它来说从不会失败。比如要向系统输入大量的相似数据来测试压力和报表。 需要频繁运行测试。在一个项目中需要频繁的运行测试，测试周期按天算，就能最大限度的利用测试脚本，提高工作效率。
2.2编写Test case和Test level 分析Test Case的业务，将Test Level services function 的颗粒从Test Case中识别出来，尽量做到用少的Service function来实现测试业务。
2.3搭建测试框架依据测试框架，在下一节中提到。依次填入测试框架的内容。
2.4执行测试并记录bug 这时就可以开始执行测试。测试结果应该自动被记录在测试报告中，而不应该一遇到BUG就停止——除非必须停止。这里注意以下几点 测试报告功能应该在Common level中实现，这样所有的测试都可以共用。 测试框架应该具有一定的判断功能，一旦某个测试失败。测试框架可以决定停止测试，或者转入不受影响的新测试用例，Test suite分类也应该注意这一点，因为同一个Test suite一般来说是互相影响的。 测试框架可以具有某种还原测试环境的功能——即测试结束清理的功能，这样就可以自动恢复到不受影响的测试环境中。
2.5维护测试脚本这是一项工作量很大的工作。维护脚本的难度很大程度上与团队活动有关，相关信息参考第4节。
3 测试框架的构想
3.1Test Driver 测试框架的核心叫Test driver，它具有以下一些东西 全局参数。 所要测试的用例集，也许叫Test suite集更合适；包括测试所要用到的参数。 对于用例的描述。 lib and tsr。 能够判断测试结果，并且决定是否调用其它的测试用例，或者停止测试。 自动生成测试报告。以及需要输出的路径。 每个测试脚本的初始设置路径
4 团队开展自动化测试要点单人自动化测试与团队开展自动化测试有很大不同，因为不同的对象名、不同的函数会造成每个人的测试脚本不同，并难以合并成一个完整、统一的脚本。为了解决这个问题，应该注意以下几点： 团队成员在编写脚本时应该多使用对象库，尽量少使用描述性编程。 统一对象名称，规定网页元素对象命名的统一规定，这样才可能在合并对象库时统一。 统一函数命名规定。 统一函数书写格式。 统一对同一类型操作的处理方式——应该定期举行会议，沟通各种操作的处理方法，共同提高对系统的认识水平。
5 测试配置测试配置应该尽量自动完成，减少工作量。测试配置包括如下内容： 测试工具的配置 测试环境，如数据、数据库结构
6 测试初始设置一些测试用例相互依赖，本应该把它们合成一个测试用例；但是如果单个测试用例颗粒很大，那么在回归测试或再现缺陷时就会使人发疯，并且浪费了大量的测试时间。最好最可靠的解决办法看来只有一种，那就是将颗粒大的测试用例分离出来，同时为这个测试用例预备测试初始设置——将客户端所需要的数据库结构和数据库备份，并且作为测试初始设置保存管理。这里的测试初始设置并非只针对自动化测试，手工测试也被包括进来。
6.1测试初始设置的命名办法 TE+测试用例编号如测试用例为TC1.2，则TE为TE1.2
6.2测试初始设置的保存测试初始设置应保存在单独的文件夹内，初始设置的路径被链接到Test driver上。
文章来源于领测软件测试网 https://www.ltesting.net/
