这部分主要介绍如何基于当前框架创建一个全新的自动化项目，我们约定项目路径在F盘下，项目名称为AutoProject。
　　1.1. 目录创建
　　在路径：“F:自动化测试管理框架使用说明项目初始化模板”下双击“双击生成新项目.vbs”文件，输入【AutoProject自动化测试】点确定。

　　执行初始化后，可以在路径：“F:自动化测试管理自动化测试项目”查看到新增的项目。
　　1.2. 报告数据库配置
　　目前报告服务器的地址为10.35.60.1。账号：hyholine 密码：Aa123456。在数据表【list_project】中添加一条项目的信息。

　　注：如果在此处添加记录，则执行报告结果插入到数据库时会失败。
　　1.3. 新建测试用例脚本
　　在充分阅读需要和测试用例的基础上，安装TD中用例组织的结构，在目录【F:自动化测试管理自动化测试项目AutoProject自动化测试AutoProject】下创建测试集和测试用例。

　　1.4. 配置脚本环境
　　1.4.1. 加载公共函数文件
　　1) 在QTP工具打开菜单项Tools-Options，找到Folder项：在此处添加存在函数库或对象库的文件夹路径。目的是其他配置的文件路径可以使用相对路径，相对路径会在此处配置的路径下搜索匹配的文件。
　　2) 在QTP工具打开菜单项File-Settings，找到Resources项：在此处添加公共函数文件，默认存放在目录【公共函数库】下，如（F:自动化测试管理自动化测试项目AutoProject自动化测试公共函数库）。注：全局函数文件GlobalFunction.vbs存放在目录【Global】下，如（F:自动化测试管理自动化测试项目Global）。

　　1.4.2. 加载公共对象库文件
　　1) 在QTP工具打开菜单项Resources-Associate Repositories，在面板上添加公共对象库文件，并把相应的Action脚本从左侧列表添加到右侧列表中。默认存放在目录【共享对象库】下，如（F:自动化测试管理自动化测试项目AutoProject自动化测试共享对象库）。

　　1.5. 编写脚本
　　根据需求文档和测试用例的要求设计脚本。原则上，在编写脚本之前务必详细阅读需求，在了解需求的基础上，再分析测试用例的设计结构，充分考虑测试的设计结构是否满足脚本的可实现条件。正常情况下，在分析完需求和用例后，脚本的设计雏形在脑海中应该完成了。
　　1.5.1. 分析需求和用例需要考虑如下5点：
　　1) 需求的描述和用例是否一致，是否有遗漏，矛盾，冲突等情况。
　　2) 脚本的设计是否可以使用用例设计的结构（一般是可以的），如果不行，要自己设计用例的脚本实现模式。
　　3) 正常一个功能点会有多个用例来覆盖，因此需要考虑多个用例是否可以整合成为一个脚本来覆盖。
　　4) 脚本的结构要优先考虑通过数据驱动模式，当然，脚本设计的原则是以少的成本完成大的用例覆盖。这里的成本包括当前的设计、编写、调试脚本的时间，也包括后期需要维护的时间。基于这个原则，如果数据驱动模式不容易实现，则采用逐个对应来覆盖。
　　5) 在阅读需求和用例过程中，要充分考虑每一个步骤和检查点在脚本实现上是否可行。因为如果某些步骤无法实现，则应该及时做出判断，不行放弃实现。如果待到脚本编写了一半，才发现关键的功能点无法实现，那么等着自我反省吧。另外，为了防止上述的问题，对于比较复杂的用例，好是自己手工执行一遍，磨刀不误砍柴工！
　　1.5.2. 编写脚本时需要考虑如下7点
　　1) 脚本设计要考虑结构的合理性，例如：重复的业务逻辑，采用循环语句来遍历覆盖；对于可复用的业务动作或检查点要封装成函数；
　　2) 函数封装的原则，先查找现有函数库，存在已实现的用已实现，没有考虑是否有可以扩展的函数，如果也没有自己新建一个函数。
　　3) 新建函数的原则，不要仅仅考虑目前需求，也要考虑可扩展性。多多考虑你设计的这个函数在将来可能会用到的地方，涉及其他功能的调用，在不同场景下的调用。
　　4) 执行测试用例强调思维的发散，即在按照用例设计执行的基础上，发挥自己的想象力，结合需求上功能点进行交叉测试。那么在设计脚本上，也是可以借鉴，在保证基础功能点检查覆盖外，也可以加入自己认为有必要检查点。另外，对于用例中非重要检查点，脚本实现困难时可以选择不覆盖，但是，需要在对于的用例上加以说明。
　　5) 检查自己编写的脚本排版是否美观。
　　6) 对于复杂的步骤需要加以注释说明。
　　7) 创建函数的命名是否符合规则，是否达到见其名知其义。