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

软件测试基本功之----WinRunner篇

前段时间公司需要实施WinRunner来进行回归测试，包括制定一套方案和一套标准脚本，通过实施起来真的是学到了很多东西，还是赶快总结出来，久了可能又忘记了。
先说我和我们老大共同制定的一套方案(也是结合网上很多资料制订的)，欢迎大家看了后给点意见，不要像上2篇那样，看的人比较多，但留言的一个都没，伤心啊,可能是我水平问题，相信以后会越来越好的。
自动化测试方案：
1.1. 自动化框架整体流程
制定测试计划
设计测试
实施测试
执行测试
评估测试
回归测试

每个测试环节的具体阐述如下：
1， 制定测试计划的目的是确定和描述要实施和执行的测试。这是通过生成包含测试需求和测试策略的测试计划来完成的。可以制定一个单独的测试计划，用于描述所有要实施和执行的不同测试类型，也可以为每种测试类型制定一个测试计划。
2， 设计测试的目的是确定、描述和生成测试过程和测试用例。
3， 实施测试的目的是实施（记录、生成或编写）设计测试中定义的测试过程。输出工件是测试过程的测试脚本。
4， 执行测试的目的是确保整个系统按既定意图运行。系统集成员在各迭代中编译并链接系统。每一迭代都需要测试增加的功能，并重复执行以前版本测试过的所有测试用例（回归测试）。
5， 评估测试的目的是生成并交付测试评估摘要。这是通过复审并评估测试结果、确定并记录变更请求，以及计算主要测试评测方法来完成的。测试评估摘要以组织有序的格式提供测试结果和主要测试评测方法，用于评估测试对象和测试流程的质量。
1.2. WinRunner测试流程
· 创建GUI Map文件：WinRunner可以通过它来识别被测试应用程序中的GUI对象。
· 创建测试脚本：通过录制，编程，或两者的组合创建。在录制测试脚本时，在你想检查被测试应用程序响应的地方插入验证点。
· 调试脚本：用调试（Debug）的模式运行测试脚本以确保它们可以平稳地运行。还可以使用WinRunner提供的Step, Step Into, Step out功能来调试脚本。
· 运行测试：用验证（Verify）的模式运行测试脚本来测试你的应用程序。当WinRunner在运行中碰到验证点时，它会将被测应用程序中的当前数据和以前捕捉的期望数据进行比较，如果发现了任何不匹配，WinRunner将会把目前的情况捕捉下来作为真实的结果。
· 检查结果：确定测试脚本的成功或是失败。在每次测试脚本运行结束之后，WinRunner会将结果显示在报告中。它描述了所有在运行中碰到的重要的事件，例如验证点，错误信息，系统信息或是用户信息。如果发现在运行中有任何不匹配的验证点，你可以在测试结果窗口中查看期望的和实际的结果。
· 提交缺陷：如果一个测试脚本是由于所测试应用程序中的缺陷而导致失败的，你可以直接从测试结果窗口中提取缺陷的相关信息。
1.3. 计划进度

1.4. 测试管理
1.4.1. 整体框架管理

整体框架如下：
自动化
GUI文件
测试报告
测试模块1
测试模块2
测试模块1
测试模块2
测试支撑库
测试脚本
测试数据
平台支撑
产品
1支撑
产品
2支撑
产品
1

产品
2
产品
3
测试脚本
测试模块1
测试模块2

目录结构

      存放目录要求：
1、 产品的脚本与产品的支撑分开放置，将支撑脚本统一管理；支撑统一放到share目录，下面有平台支撑目录，各个产品的支撑脚本目录；
2、 每个产品目录下都可分为TestGUI、TestReport、TestScrip；分别用于管理产品测试脚本、测试报告、测试用到的GUI
3、 测试脚本中每个模块的测试用例一个目录，每个模块的脚本可以不放置在同一个脚本文件中，但是要求能做到自动调用，每个模块的测试脚本中，还包括测试的数据资源准备；
4、 GUI 文件存放在产品的GUI文件夹；统一管理，要求做到与测试脚本的名称相同；
5、 为存取及备份方便，目录不能使用中文。使用的名称应该尽量与开发保持一致

1.4.2. 脚本管理
1， 录制脚本要分开，根据测试用例的流程，拆分为几个小流程，对每个小流程分别录制成不同的脚本。
2， 每个测试脚本运行后都要进行清理数据，保持数据库和环境的干净。
3， 录制完各单个测试用例的子脚本后，要写一个主脚本进行各子脚本的主次调用处理
4， 所有脚本放在一个统一的文件夹下，并且每个脚本名称要和功能相关，如登陆：Login
5， 对某个模块的脚本归类到一起
1.4.3. GUI管理
1， 使用Global GUI Map File Mode模式录制GUI文件，然后把GUI文件统一的放到一个文件夹里，使用gui_load(xxx.gui)这样载入GUI文件，可以把这句写到自定义工具栏，换一个脚本，在加这一句时，就会比较方便了。同时把GUI文件名命名的清楚一点，可以节约自己维护的时间，也能让其他人看的明白。
2， 保证干净的测试环境，使用invoke函数启动待测试程序，对需要启动多个应用程序的情况尤其显得重要。（invoke_application ( file, command_option, working_dir, show );）
3， 命名GUI对象时，在对象名上加上他所在窗体的名字（或者容易懂的窗体名字简称），这个对菜单、按钮等对象比较有意义。这会在以后的维护中减少阅读工作量，特别是被测试程序版本变化后，对象名称发生变化的情况。
4， 建议在用户工具栏添加建立虚拟控件的按钮（learn virtual object），对于少量可以做成按钮识别的控件，可以用虚拟控件做
1.4.4. 测试报告管理
1， 测试报告统一放到一个测试报告的文件夹，每一个模块的测试报告形成一个文档，并且对于每一个用例的测试报告形成一个文档；
2， 测试报告采用HTML 的格式，每个模块的报告通过超链接访问每个用例的测试记录
3， 测试报告命名与测试的模块名相同
4， 每次测试完成后，将测试报告打包整理；
PS：这个是我们的重点。
1.4.5. 测试数据管理
1， 测试用例中需要的数据放在各个测试脚本目录下，可通过数据驱动调用
2，测试数据也可通过对数据库进行操作来使用
1.5. 测试设计阶段
1.5.1. 自动化测试需求
书写出各个需要自动化测试的需求，对各个模块进行前期测试需求，比如登陆模块你希望测试的是
1， 正常帐号正常登陆
2， 异常帐号异常登陆
3， 正常帐号异常登陆
4， 正常帐号登陆后，删除该帐号，再登陆
等，这些前期的测试需求应该清楚。
1.5.2. 自动化测试用例
根据测试需求为每个模块，功能设计测试用例，再通过EXCEL输入数据给脚本调用。
自动化测试用例设计原则：
1， 设计相互独立的测试用例，测试用例的独立性能够保证一个测试用例不依赖另一个测试的成功完成来运行（不依赖于前一个测试用例的结果）。它也确保了即使在无人干预的情况下，自动化测试套件也能得出结果。如果不独立，随后的实验可能无法执行，分离失败的原因变的困难。
2， 设计自包含式的（self-contained）测试用例， 具有基准数据库这样基本状态的需求，基本状态消除了测试用例之间的线性依赖。
3， 设计基于出发点的（home-based）测试用例。如果每个测试用例都是从一个己知点开始而目结束后会进行清理．这样做可以确保每个脚本都与先前测试脚本一样开始于同样的条件．有助于保证测试脚本是独立的。
4， 设计无重叠的测试用例
1.5.3. 测试脚本
1． 使用基于框架的脚本设计
2． 实现数据驱动控制
3． 使用脚本编写规格
4． 从功能上分解脚本
5． 构建主脚本和子脚本
6． 脚本中注释
7． 脚本中使用的ODBC数据源名称统一命名为WR
1.5.4. 测试脚本
1． 对测试脚本，测试数据和备份计划存储库进行控制
2． 对GUI文件进行控制
3． 对测试报告进行控制
1.6. 测试实现阶段

1， 制定自动化设计标准：如测试脚本编写规格等
2， 自动化脚本计划：对脚本进行级别划分，确定那些测试用例不能用于自动化测试
3， 测试自动化库：定义一些可重用的脚本放在公共库中，以便重用
4， 自动化脚本创建：把脚本创建划分到小组或个人
5， 自动化脚本评审：保证开发的脚本符合制定的标准。
6， WinRunner和VSS使用此阶段，测试脚本由WinRunner生成。测试数据根据测试用例来制定，然后通过调用EXCEL或者数据库SQL生成。通过VSS将测试脚本与测试需求连接起来以便跟踪和监测测试覆盖。
1.7. 测试执行阶段
安装了WinRunner测试工具的操作系统为测试执行平台，测试结果会被捕获并显示出来，可通过在WinRunner自带的格式输出，也可输出为HTML格式的结果。
自动化测试总结：
通过进行自动化测试操作，在其中学习到了很多脚本设计上，技巧上的方法，现总结如下：
1， 首先编写测试脚本前，考虑产品可以分为那几个模块，模块中分为那个步骤，测试模块中的那些点，最好是先写一个简单的列表，这样在编写脚本时就比较清晰整体的架构和逻辑。例：在做企业版V2前就是因为没有对整体预先进行设计，导致后面很多地方进行修改，如在设计测试报告输出方面就没考虑到以那种形式进行输出，开始是对整个报告输出到一个HTML文件中，后面改成先有一正个模块的报告来显示那些用例通过，那些失败，然后通过点击通过的或者失败的就可以查看用例测试的详细信息。
2， 对于每一个输入条件都要进行判断，判断是否正确，不正确就把不正确的信息写入测试报告中，然后根据需要是否退出整个测试。如加载GUI_PATH路径就要进行判断，判断不存在就输出错误信息并退出测试。
3， 所有关于路径方面的变量都应该是相对路径，不能是绝对路径，不管是输出还是输入。如函数库路径LIB，应该这样写（比如static lib_path = getvar("testname") & "\\..\\..\\..\\share\\lib";），就是通过getvar("testname")获取到当前脚本的路径，然后在后加上LIB所在文件夹路径，其他的变量也是一样，最好不要用绝对路径（如：c:\abd\aaa\lib），绝对路径对后期维护很差，而且当脚本转移到其他电脑上，放的路径和以前不相同，则测试脚本将跑不成功。
4， 脚本中尽量在最前面进行变量定义，然后在脚本中进行调用变量，这样维护脚本就只需要修改变量中定义的值，而不需要去脚本中到处修改。
5， 变量名字定义尽量通俗易懂，看到就大概知道定义的什么
6， 脚本定义格式：
1， 测试模块名称
2， 创建日期
3， 创建版本
4， 修改记录
5， 创建人
6， 被测程序用的语言
7， 测试目的
8， 参数
9， 返回值
7， 注释：定义的变量，测试的步骤都必须进行注释说明
8， 函数定义：函数尽量定义成多用，只接受外面传来的参数，在函数中不要进行过多操作。
9， 函数格式：
1， 函数名称
2， 函数目的
3， 函数参数
4， 函数返回值
10， 脚本中加载函数后，在测试结束必须用UNLOAD释放
11， GUI整理：
1， 可以对某GUI的Logical Name进行修改，修改为易懂的名称
2， 对GUI的Physical Description进行模糊匹配（一般把MSW_class: *这个去掉）
3， 对GUI进行通配符，如
{
class: window,
label: "[已连接]127.0.0.1"
}
可以修改为
{
class: window,
label: "!\\[已连接\\].*"
}
PS：[ ] 是WR中进行通配符中的，所有当要对带有[ ]进行通配符的话，如上面。其他的符号也是一样
4， 每个模块的GUI生成一个GUI文件
12， 进行脚本调试时多用PAUSE进行调试