软件测试基本功---WinRunner.docVIP

软件测试基本功之----WinRunner篇 前段时间公司需要实施WinRunner来进行回归测试，包括制定一套方案和一套标准脚本，通过实施起来真的是学到了很多东西，还是赶快总结出来，久了可能又忘记了。 先说我和我们老大共同制定的一套方案(也是结合网上很多资料制订的)，欢迎大家看了后给点意见，不要像上2篇那样，看的人比较多，但留言的一个都没，伤心啊,可能是我水平问题，相信以后会越来越好的。 自动化测试方案： 自动化框架整体流程 每个测试环节的具体阐述如下： 制定测试计划的目的是确定和描述要实施和执行的测试。这是通过生成包含测试需求和测试策略的测试计划来完成的。可以制定一个单独的测试计划，用于描述所有要实施和执行的不同测试类型，也可以为每种测试类型制定一个测试计划。 设计测试的目的是确定、描述和生成测试过程和测试用例。 实施测试的目的是实施（记录、生成或编写）设计测试中定义的测试过程。输出工件是测试过程的测试脚本。 执行测试的目的是确保整个系统按既定意图运行。系统集成员在各迭代中编译并链接系统。每一迭代都需要测试增加的功能，并重复执行以前版本测试过的所有测试用例（回归测试）。 评估测试的目的是生成并交付测试评估摘要。这是通过复审并评估测试结果、确定并记录变更请求，以及计算主要测试评测方法来完成的。测试评估摘要以组织有序的格式提供测试结果和主要测试评测方法，用于评估测试对象和测试流程的质量。GUI Map文件：WinRunner可以通过它来识别被测试应用程序中的GUI对象。 创建测试脚本：通过录制，编程，或两者的组合创建。在录制测试脚本时，在你想检查被测试应用程序响应的地方插入验证点。 调试脚本：用调试（Debug）的模式运行测试脚本以确保它们可以平稳地运行。还可以使用WinRunner提供的Step, Step Into, Step out功能来调试脚本。 运行测试：用验证（Verify）的模式运行测试脚本来测试你的应用程序。当WinRunner在运行中碰到验证点时，它会将被测应用程序中的当前数据和以前捕捉的期望数据进行比较，如果发现了任何不匹配，WinRunner将会把目前的情况捕捉下来作为真实的结果。 检查结果：确定测试脚本的成功或是失败。在每次测试脚本运行结束之后，WinRunner会将结果显示在报告中。它描述了所有在运行中碰到的重要的事件，例如验证点，错误信息，系统信息或是用户信息。如果发现在运行中有任何不匹配的验证点，你可以在测试结果窗口中查看期望的和实际的结果。 提交缺陷：如果一个测试脚本是由于所测试应用程序中的缺陷而导致失败的，你可以直接从测试结果窗口中提取缺陷的相关信息。 计划进度 测试管理 整体框架管理 整体框架如下： 目录结构? ?? ?存放目录要求：GUI 文件存放在为存取及备份方便，目录不能使用中文。使用的名称应该尽量与开发保持根据测试用例的流程，拆分为几个小流程，对每个小流程分别录制成不同的脚本进行各子脚本的主次调用处理使用Global GUI Map File Mode模式，然后把GUI文件统一的放到一个文件夹里，使用gui_load(xxx.gui)这样载入GUI文件，可以把这句写到自定义工具栏，换一个脚本，在加这一句时，就会比较方便了。同时把GUI文件名命名的清楚一点，可以节约自己维护的时间，也能让其他人看的明白。保证测试环境使用invoke函数启动待测试程序，对需要启动多个应用程序的情况尤其显得重要invoke_application ( file, command_option, working_dir, show );） 命名GUI对象时，在对象名上加上他所在窗体的名字（或者容易懂的窗体名字简称），这个对菜单、按钮等对象比较有意义。这会在以后的维护中减少阅读工作量，特别是被测试程序版本变化后，对象名称发生变化的情况。建议在用户工具栏添加建立虚拟控件的按钮（learn virtual object），对于少量可以做成按钮识别的控件，可以用虚拟控件做自动化测试用例设计原则：设计相互独立的测试用例测试用例的独立性能够保证一个测试用例不依赖另一个测试的成功完成来运行（不依赖于前一个测试用例的结果）。它也确保了即使在无人干预的情况下，自动化测试套件也能得出结果。如果不独立，随后的实验可能无法执行，分离失败的原因变的困难。设计自包含式的（self-contained）测试用例， 具有基准数据库这样基本状态的需求基本状态消除了测试用例之间的线性依赖。设计基于出发点的（home-based）测试用例。如果每个测试用例都是从一个己知点开始而目结束后会进行清理．这样做可以确保每个脚本都与先前测试脚本一样开始于同样的条件．有助于保证测试脚本是独立的。设计无重叠的测试用例脚本中使用的ODBC数据源名称统一命