软件功能自动化测试之我见(2)

　　模块业务逻辑测试，确保各个业务流程畅通

　　5.4设计测试用例

　　通过分析测试需求，设计足够多能够覆盖所有需求点的测试用例，形成专门的测试用例文档。并不是所有的测试用例都能用自动化来执行，所以需要将能够执行自动化测试的用例汇总成自动化测试用例。必要时，要将登录系统的用户、密码、产品、客户等参数信息独立出来形成测试数据，便于脚本开发。

　　5.5搭建测试环境

　　自动化测试人员在用例设计工作开展的同时即可着手搭建测试环境。因为自动化测试的脚本编写需要录制页面控件，添加对象。测试环境的搭建，包括被测系统的部署、测试硬件的调用、测试工具的安装和设置、网络环境的布置等等。

　　5.6编写测试脚本

　　根据自动化测试用例和问题的难易程度，采取适当的脚本开发方法编写测试脚本。一般先通过录制的方式获取测试所需要的所有页面控件，然后再用结构化语句控制脚本的执行，插入检查点和异常判定反馈语句，将公共普遍的功能独立成共享脚本，必要时对数据进行参数化。当然还可以用其他高级功能编辑脚本。脚本编写好了之后，需要反复执行，不断调试，直到运行正常为止。脚本的编写和命名要符合管理规范，以便统一管理和维护。

　　5.7执行自动测试

　　测试脚本调试好之后，自动化测试者即可调用这个脚本，验证软件功能，执行回归测试、流程测试等，以替代机械重复性的手工测试工作。自动测试执行过程中，应关注脚本的运行情况，如果遇到错误，不要轻易中止运行。先分析运行出错是不是延时引起的，如果是，只要再试一次即可。如果是系统功能有问题，应及时记录系统问题。根据不同的需要，测试者可以选择批量运行测试脚本。

　　5.8分析测试结果

　　美科林公司的功能测试工具(QTP)能很好地与测试管理工具(QC)集成。执行测试后的结果报告会自动传递给QC，从而能够统计分析测试通过与没通过的情况，生成各种样式的报表。

　　在没有启用测试管理工具的情况下，则需要根据测试工具记录的结果撰写自动化测试分析报告。自动化测试分析报告应根据项目的需要编制，没有必要为每个脚本的执行结果都编写测试分析报告。

　　5.9记录测试问题

　　一般来讲，测试脚本中的检查点以及其他异常判断的信息都应写入测试工具的测试报告，测试脚本执行完毕之后，即可查看测试工具的测试报告，然后将没有通过的地方提取出来，描述成BUG，反馈给开发人员。

　　5.10跟踪测试BUG

　　测试记录的BUG要记录到测试管理工具中去，以便定期跟踪处理。开发人员修改后，需要对此问题执行回归测试，就是重复执行一次该问题对应的脚本，通过则关闭，否则继续修改。如果问题(BUG)的修改方案与客户达成了一致，但与原来的需求有所偏离，那么回归测试前，还需对脚本进行必要的修改和调试。

　　6自动化测试的策略论

　　自动化测试的难点在于实现测试工具、测试管理规范、测试人员之间的平衡。如果实现不了三者的平衡，那么测试工具就发挥不了应有作用，管理规范形同虚设，测试人员在自动化面前无能为力。

　　测试工具：最好选择支持标准语言的测试工具，如QTP(VB Script)，避免去熟悉厂商特定的语言。另外，测试工具必须能够支持新平台、个性化控件。

　　管理规范：建立科学统一的管理规范，增强脚本的可读性、可重用性、可维护性。

　　测试人员：加强学习，采用合适的开发方法按照规范编写测试脚本，必要时与开发人员协商解决自动化测试问题。做好配置管理，系统的重构和调整都导致大部分脚本的修改。

　　自动化测试的目的是弥补手工测试的不足，保证软件质量，提高客户满意度。在为项目做自动化测试前，必须对项目做个评估，评估自动化测试是否确实对项目的进度、覆盖率、风险带来积极的影响，评估自动化测试所依赖的测试环境、人力资源、硬件资源和数据资源能否在短时间内得到满足。

原文转自：http://www.uml.org.cn/Test/200906255.asp