测试用例
下面一个步骤是把我们的方法从模块转化成自动化测试的用例，在这里，自动化测试工程师有一个架构较好的手工测试用例，去把他变为脚本，创建重用模块。目标是有条不紊的创建一个可重用的模块，行动-响应的测试用例演化为可重用模块的脚本。测试用例一般决定可重用模块的粒度，这个模块包含一个行动-响应。这个对于判定自动化项目的范围和成本来说是比较重要的。一个单独的可重用模块需要一到三个小时去做成脚本和做一些单元测试，自动化测试一般需要二三十个可重用模块。
在这种模式下创建的自动化测试用例是一个可预测的结构，一个优点是可以在提早在测试生命周期中开始创建自动化系统。
结构化的测试用例格式
结构化的测试用例是一种动态的自动化测试用例，包含了一系列的行动-响应。
测试用例举例
测试用例id：客户01
功能：新加一个用户
数据假设：客户数据库已经恢复
概述：
增加一个新的用户通过用户的屏幕，需要确定这个新增加的用户在所有的用户屏幕上显示的都是正确的。
| 操作 | 初始化屏幕 | 数据 | 期望结果 |
| 1、通过windows桌面图标启动Salse系统 | 项目经理 | 无 | 显示销售程序的首页面 |
| 2、在页面中选择用户 | 销售选择首页面 | 无 | 客户页面正确显示 |
| 3、单击所有用户 | 客户页面 | 无 | 客户窗口正确显示，名称为所有用户 |
| 4、单击增加按钮 | 客户—所有客户 | 无 | 增加客户页面显示 |
| 5、输入数据增加新的用户，单击增加按钮 | 增加用户 | 姓名：john doe 地址：123main st. 城市：san Francisco （来源于data-sheet） |
数据显示在显示区域 （和data-sheet中定义的一样） |
优点
1、 易于自动化-所有的都有一样的框架
2、 数据都需要明确的定义
3、 精确的导航
4、 每一步骤的期望结果都很明确-没有需要猜测的结果
可预测的架构
下一步，我们举例说明什么是可预测的架构，所有测试用例的屏幕名字都指向一个包含可重用模块的文件。例如：如果这个应用程序有三十个不同的屏幕，那么测试系统就会有三十个文件名字相同的可重用模块对应于每一个屏幕。通过执行命令去显示特定的屏幕，第一个测试用例的操作是确定屏幕是否通过桌面打开，（屏幕启用和焦点-取决于正在测试的具体内容），这个是通过索引文件调用重用模块，那么，这个确定的新的屏幕就是我们文件的第一个模块。这个可重用模块知道怎样去1）利用多级动态验证方法动态的确定屏幕的文件名，2）如果验证失败指定一个错误级别3）向日志文件里面写错误信息。注：我建议创建两个日志文件，一个详细日志，另一个日志只记录通过/失败信息。
下面是一个例子一个索引的客户文件调用可重用文件去判断customer screen是不是正确显示的，这个索引是“VALIDATE”。
相关阅读：
