2011年软考软件测评师自动化测试汇总

楠族开心果

在WinRunner中识别Delphi控件

# 制作环境：

# WinRunner 7.0 Build 7211

# Delphi 6.0

# 方法发现：XXX

# 制 作： XXXX

# 使用方法：

# Step 1 拷贝本文档中所有内容

# Step 2 打开WinRunner\lib\vbinit中的script文件

# Step 3 将内容粘贴在段落“

# VisualBasic 4.0 Standart controls”之前

# Step 4 重新运行WinRunner

# Step 5 启动时装载VB Addin

# TBitBtn

set_class_map（“tbitbtn”， “push_button”）;

set_record_attr（“tbitbtn”， “class label x y”， “MSW_id”， “location”）;

# TButton

set_class_map（“tbutton”， “push_button”）;

set_record_attr（“tbutton”， “class label x y”， “MSW_id”， “location”）;

# TCheckBox

set_class_map（“tcheckbox”， “check_button”）;

set_record_attr（“tcheckbox”， “class label x y”， “MSW_id”， “location”）;

# TComboBox

set_class_map（“TComboBox”， “combobox”）;

db2inst1 set_record_attr（“TComboBox”， “class attached_text x y”， “MSW_id”， “location”）;

# TDateTimePicker

set_class_map（“tdatetimepicker”， “sysdatetimepick32”）;

set_record_attr（“tdatetimepicker”， “class attached_text x y”， “MSW_id”， “location”）;

# TEdit

set_class_map（“tedit”， “edit”）;

set_record_attr（“tedit”， “class attached_text x y”， “MSW_id”， “location”）;

# TGroupButton

set_class_map（“tgroupbutton”， “radio_button”）;

set_record_attr（“tgroupbutton”， “class label x y”， “MSW_id”， “location”）;

# TListBox

set_class_map（“TListBox”， “listbox”）;

set_record_attr（“TListBox”， “class attached_text x y”， “MSW_id”， “location”）;

# TListView

set_class_map（“TListView”， “syslistview32”）;

set_record_attr（“TListView”， “class attached_text x y abs_x”， “MSW_id”， “location”）;

# TMaskEdit

set_class_map（“TMaskEdit”， “edit”）;

set_record_attr（“TMaskEdit”， “class attached_text x y”， “MSW_id”， “location”）;

# TMemo

set_class_map（“tmemo”， “edit”）;

set_record_attr（“tmemo”， “class attached_text x y”， “MSW_id”， “location”）;

# TMonthCalendar

set_class_map（“TMonthCalendar”， “sysmonthcal32”）;

set_record_attr（“TMonthCalendar”， “class attached_text x y”， “MSW_id”， “location”）;

# TRadioButton

set_class_map（“TRadioButton”， “radio_button”）;

set_record_attr（“TRadioButton”， “class label x y”， “MSW_id”， “location”）;

# TRickEdit

set_class_map（“TRichEdit”， “edit”）;

set_record_attr（“TRichEdit”， “class attached_text x y”， “MSW_id”， “location”）;

# TPageControl

set_class_map（“tpagecontrol”， “systabcontrol32”）;

set_record_attr（“tpagecontrol”， “class attached_text x y”， “MSW_id”， “location”）;

# TStaticText

set_class_map（“TStaticText”， “object”）;

set_record_attr（“TStaticText”， “class regexp_MSW_class label”， “attached_text MSW_id MSW_class”， “location”）;

# TTreeView

set_class_map（“ttreeview”， “systreeview32”）;

set_record_attr（“ttreeview”， “class attached_text”， “MSW_id”， “location”）;

楠族开心果

tsl脚本命令

Winrunner Context Sensitive命令列表

1.ActiveBar_combo_select_item （ band_tool ， item_name ）;选择下拉菜单某一项，例如：

set_window（“Form1”， 1）;

ActiveBar_combo_select_item（“Format;Font”， “Arial”）;

In the following example， WinRunner selects the third item in the Format:Font tool.

set_window（“Form1”， 1）;

ActiveBar_combo_select_item（“Format;Font”， “#3”）;

2.ActiveBar_dump （ file_name ）;存储活动工具栏信息，包括标题、名称、ID等。

file_name 参数包括路径，例如：

set_window（“Form1”， 1）;

ActiveBar_dump （“d:Bardump.txt”）;

3、ActiveBar_select_menu （ band_tool ［， events_only ］ ） ;选择菜单某一项，例如：

in the following example， WinRunner selects the Cut menu item in the Edit toolbar.

set_window（“Form1”， 1）;

ActiveBar_select_menu （“Edit;Cut”，TRUE）;

4、ActiveBar_select_tool （band_tool ［， events_only ］ ） ;选择工具栏里某一项，例如：

set_window（“Form1”， 1）;

ActiveBar_select_tool（“Format;Center”， TRUE）;

5、win_check_bitmap （ window， bitmap， time ［， x， y， width， height ］ ）;比较窗口位图，

6、obj_check_bitmap （ object， bitmap， time ［， x， y， width， height］ ）;比较对象位图，

7、button_check_info （ button， property， property_value ）;检查按钮属性的值

8、button_check_state （ button， state ）;检查单选框或复选框的状态

9、button_get_info （ button， property， out_value ）;返回按钮属性的值

10、button_get_state （ button， out_state ）;返回单选框或复选框的状态

11、button_press （ button ）;点击按钮

12、button_set （ button， state ）;设置单选框或复选框的状态

13、button_wait_info （ button， property， value， time ）;等待按钮的属性值变化

14、calendar_activate_date （ calendar， date ）;双击日历某个日期

15、db_check （ checklist， expected_results_file ［ ， max_rows ［ ， parameter_array ］ ］ ）;比较当前数据库数据和期待的数据库数据

16、db_connect （ session_name， connection_string ）;建立一个数据库session并建立odbc连接

17、db_disconnect （ session_name ）;断开连接结束session

18、db_execute_query （ session_name， SQL， record_number ）;执行sql语句返回记录集

19、db_get_field_value （ session_name， row_index， column ）;返回数据库特定区域的值

20、db_get_headers （ session_name， header_count， header_content ）;返回数据库session的列的数量及列的内容并以tab分组

21、db_get_last_error （ session_name， error ）;返回最后一条数据库session错误信息

22、db_get_row （ session_name， row_index， row_content ）;返回特定行内容

23、db_record_check （ ChecklistFileName ， SuccessConditions， RecordNumber ）; Compares information that appears in the application under test during a test run with the current values in the corresponding record（s） in your database.

24、db_write_records （ session_name， output_file ［ ， headers ［ ， record_limit ］ ］ ）;把结果记录集写到一个文本文件

25、ddt_close （ data_table_name ）;关闭数据表文件

26、ddt_close_all_tables（）;关闭全部数据表

27、ddt_export （ data_table_namename1， data_table_namename2 ）;把一个数据表信息导到另一个数据表文件

28、ddt_get_current_row （ data_table_name， out_row ）;返回数据表当前所在行

29、ddt_get_parameters （ table， params_list， params_num ）;返回数据表的参数和参数的个数

30、ddt_get_row_count （ data_table_name， out_rows_count ）;返回数据表行数

31、ddt_is_parameter （ data_table_name， parameter ）;返回一个参数是否在数据表里有效

32、ddt_next_row （ data_table_name ）;指向数据表中到当前行的下一行

33、ddt_open （ data_table_name ［ ， mode ］ ）;打开或创建一个可以访问的数据表

34、ddt_report_row （ data_table_name ）;报告当前行到测试结果

35、ddt_save （ data_table_name ）;保存数据表信息

36、ddt_set_row （ data_table_name， row ）;设置当前行为第几行

37、ddt_set_val （ data_table_name， parameter， value ）;插入parameter列一个新值value

38、ddt_set_val_by_row （ data_table_name， row， parameter， value ）;插入特定行的parameter列一个新值value

39、ddt_show （ data_table_name ［ ， show_flag ］ ）;显示或隐藏数据表，1是显示，0是隐藏

40、ddt_sort （ table_file， row1， col1， row2， col2， sort_by_rows， key1 ［ ， key2， key3 ］ ）;根据关键字将数据表特定区域的值排序，sort_by_rows 参数1是按行，0是按列

41、ddt_update_from_db （ data_table_name， file， out_row_count ［ ， max_rows ］ ）;从数据库往数据表里导数据;

42、ddt_val （ data_table_name， parameter ）;返回数据表当前行的参数的值

43、ddt_val_by_row （ data_table_name， row_number， parameter ）;返回数据表特定行的参数的值

44、date_age_string （ date， years， month， days， new_date ）;将日期相应改变返回新值

45、date_align_day （ align_mode， day_in_week ）;指定特定的日期给某天

46、date_calc_days_in_field （ field_name1， field_name2 ）;计算两个日期间的天数

47、date_calc_days_in_string （ string1， string2 ）;计算字符串格式的日期间的天数

48、edit_check_info （ edit， property， property_value ）;检查对象属性的值

49、edit_check_selection （ edit， selected_string ）;检查选择的字符串是否存在

50、edit_check_text （edit， text， case_sensitive ）;检查编辑对象的文本内容

51、edit_delete （ edit， start_column， end_column ）;删除编辑对象的文本内容

52、edit_delete_block （ edit， start_row， start_column， end_row， end_column ）;删除文本区

53、edit_get_block （ edit， start_row， start_column， end_row， end_column， out_string ）;返回文本区

54、edit_get_info （ edit， property， out_value ）;返回编辑对象的属性值

55、edit_get_row_length （ edit， row， out_length ）;返回编辑对象里行的长度

56、edit_get_rows_count （ edit， out_number ）;返回编辑对象里行数

57、edit_get_selection （ edit， out_string ）;返回编辑对象的选定字符串

58、edit_get_selection_pos （ edit， out_start_row， out_start_column， out_end_row， out_end_column ）;返回选定区域的开始和结束位置

59、edit_get_text （ edit， out_string ）;返回编辑对象的文本

60、edit_insert （ edit， text， columnI ）;在编辑对象第一行插入文本

楠族开心果

WinRunner脚本标准格式

目录结构

存放目录要求：

1、根目录与项目名称相同，如江西移动BOSS 测试目录为JXBOSS。

2、根目录下应该是按子项目存放，如SALES、ACCOUNT。如果有公共脚本，存放在Share 目录下面。

3、子项目下面应该根据功能/TestCase 来存放，如果有公共脚本也应该存放在Share 目录下。

4、为存取及备份方便，目录不能使用中文。使用的名称应该尽量与开发保持一致。

5、GUI 文件应该存放在脚本的同一目录，并且名称相同。

6、正确性测试（使用完全正确数据来检查程序功能是否完成）目录名称规定为validity。

以下是一个目录例子：

JxBoss

-Sales

--ChangeSimCard

--validity

--CheckSimNoExistAnIdError

--Share

--Share

-Account

脚本要求

注释要求

脚本创建及修改说明注释

每个脚本的开头注释格式如下：

#脚本名称：文件名称

#创建人：创建人

#创建日期：格式为YYYY/MM/DD

#功能：脚本完成的功能描述。

#运行前要求：运行前的要打开的窗口及状态要求、数据库中的数据要求、被测试程序运行目录等。

#参考文档：描述录制代码是参考的有关设计测试文档。

#修改历史：

# 修改人：

# 修改时间：格式为YYYY/MM/DD

# 主要修改内容：

注意创建人及修改人必须是中文完整姓名，不允许使用其它任何名称。运行前的要求一定要描述清楚。

子功能注释：

在各小段功能前应该加入功能注释，注意不能只是WinRunner 自己产生的注释。

如：

# insert a record

# Flight Reservation

set_window （“Flight Reservation”， 1）;

obj_mouse_click （“Button”， 13， 16， LEFT）;

obj_type （“MSMaskWndClass”，“101002”）;

list_select_item （“Fly From：”， “London”）; # Item Number 2;

list_select_item （“Fly To：”， “Paris”）; # Item Number 3;

obj_mouse_click （“FLIGHT”， 56， 22， LEFT）;

注释可以使用英文或中文。

修改代码说明注释。

在具体修改的代码附近应该加入如下注释：

#修改人

#修改日期

#修改原因/增加功能

注释可以放在一行中，简单修改可以忽略“修改原因/增加功能”，复杂修改应该不能忽略（简单及复杂标准待定）代码要求。

路径要求

代码中使用的路径都应该使用相对路径，不允许出现类似“d：\\”、“\\”下的代码，应该使用类似“。.\\。.\\”的代码。

在Script 里面打开和关闭GUI。

各Script 的GUI 的文件应该分开保存在与Script 保存在同一个目录，应该使用用GUI_load 在SCRIPT 开始以前就装载GUI，在SCRIPT 开始增加：

if （GUI_load（“。\\login.gui”）！=0）

{

pause （“Can‘t load login.gui”）;

texit;

}

在SCRIPT 完毕的时候加入：

GUI_close（“。\\login.gui”）;

关闭GUI，注意代码中的路径一定要使用相对路径。

错误报告

在使用错误报告的时候，应该注意包括出错的脚本文件名称，这样当脚本文件被其他脚本调用时候，也能很清楚在什么地方没有通过。Report_msg 的参数格式定义为“文件名称：错误描述”。同时鉴于WinRunner 的Check 函数不能提供清楚的错误报告，要求错误报告使用以方式：

if （ win_check_bitmap（“Flight Reservations”， “Img1”， 1）！=E_OK）

{

report_msg（“DateCheck：月份输入错误提示不对！”）;

}

附件：一个完整的例子。

#脚本名称：DateCheck

#创建人：***

#创建日期：2002/09/08

#功能：检查FLIGHTA 程序在输入错误月份的时候提示是否正确。

#运行前要求：要求FLIGHA 进入定票窗口（New_Order 状态）且无任何数据输入。

# 或者FLIGHTA 没有运行，这时候要求FLIGHTA。EXE 位。

# 于E：\\Program Files\\Mercury

Interactive\\WinRunner\\samples\\flight\\app\\flight1a.exe

#参考文档：无

#修改历史：

# 修改人：***

# 修改时间：2002/09/09

# 主要修改内容：不采用位图方式，改为直接判断字符串内容。

#load gui file

#Flight Reservation

if （GUI_load（“。\\DateCheck.gui”）！=0）

{

report_msg （“DataCheck:Can’t load 。\\DateCheck.gui”）;

texit;

}

#Check windows exists ，if don‘t exist ，call login to open it.

# Flight Reservation

if （win_exists（“Flight Reservation”）！=E_OK）{

#pause （“Windows Flight Reservation don’t exist”）;

#texit;

call “。.\\login\\login”（）;

}

#input error month

win_activate （“Flight Reservation”）;

set_window （“Flight Reservation”， 3）;

obj_mouse_drag （“Button_4”， 17， 6， 17， 7， LEFT）;

obj_type （“MSMaskWndClass”，“301212”）;

list_select_item （“Fly From：”， “Denver”）; # Item Number 0;

#check message bitmap

# Flight Reservations_1

set_window （“Flight Reservations”， 3）;

#2002/09/09 ***

#if （ win_check_bitmap（“Flight Reservations”， “Img1”， 1）！=E_OK）

#static_check_info（“Invalid month Entered.The month must be greater than 01 and less than

12.（static）”，“enabled”，1）;

if （static_check_info（“CheckMessage”，“label”，“Invalid month Entered.The month must be

greater than 01 and less than 12.”）！=E_OK）

#2002/09/09 ***修改结束

{

report_msg（“DateCheck：月份输入错误提示不对！”）;

}

button_press （“确定”）;

#close gui file

GUI_close（“。\\DateCheck.gui”）;

楠族开心果

软件测试工具集

1、 从测试功能上分

（1） 单元测试 ： 针对不同语言，如JUNIT

（2） 功级测试

E—Test：功能强大，由于不是采用POST URL的方式回放脚本，所以可以支持多内码的测试数据（当然要程序支持），基本上可以应付大部分的WEB SITE。

MI公司的WINRUNNER

COMPUWARE的QARUN

RATIONAL的SQA ROBOT

（3） 压力测试

MI公司的WINLOAD

COMPUWARE的QALOAD

RATIONAL的SQA LOAD

（4） 负载测试

LOADRUNNER

RATIONAL VISUAL QUANTIFY

（5） WEB测试工具

MI公司的ASTRA系列

RSW公司的E—TEST SUITE等

（6） WEB系统测试工具

WORKBENCH

WEB APPLICATION STRESS TOOL（WAS）

（7） 数据库测试工具

TESTBYTES

（8） 回归测试工具

RATIONAL TEAM TEST

WINRUNNER

（9） 嵌入式测试工具

ATTOLTESTWARE。是ATTOLTESTWARE公司的自动生成测试代码的软件测试工具，特别适用于嵌入式实时应用软件单元和通信系统测试。

CODETEST是AppliedMicrosystemsCorp.公司的产品，是广泛应用的嵌入式软件在线测试工具。

GammaRay。GammaRay系列产品主要包括软件逻辑分析仪GammaProfiler、可靠性评测工具GammaRET等。

LogiScope是TeleLogic公司的工具套件，用于代码分析、软件测试、覆盖测试。

LynxInsure++是LynxREAL-TIMESYSTEMS公司的产品，基于LynxOS的应用代码检测与分析测试工具。

MessageMaster是ElviorLtd.公司的产品，测试嵌入式软件系统工具，向环境提供基于消息的接口。

VectorCast是VectorSoftware.Inc公司的产品。由6个集成的部件组成，自动生成测试代码，为主机和嵌入式环境构造可执行的测试架构。

（10） 系统性能测试工具

Rational Performance

（11） 页面链接测试

Link Sleuth

（12） 测试流程管理工具

Test Plan Control

（13） 测试管理工具

TestDirector 微创tcm

Rational公司的Test Manager

Compuware公司的QADirector

TestExpert：是Silicon Valley Networks公司产品的测试管理工具，能管理整个测试过程，从测试计划、测试例程、测试执行到测试报告。

（14） 缺陷跟踪工具

TrackRecord等

（15） 其他测试工具包

TestVectorGenerationSystem是T—VECTechnologies公司的产品。提供自动模型分析、测试生成、测试覆盖分析和测试执行的完整工具包，具有方便的用户接口和完备的文档支持。

TestQuestPro是TestQuest公司的非插入码式的自动操纵测试工具，提供一种高效的自动检测目标系统，获取其输出性能的测试方法。

TestWorks是SoftwareResearch.Inc公司的一整套软件测试工具，既可单独使用，也可捆绑销售使用。

2、 从测试的方法上分：

（1） 白盒测试工具

白盒测试工主要有：Numega、PuRe、软件纠错工具（Rational Purify）。

内存资源泄漏检查：

Numega中的BounceChecher

Rational的 Purify等。

代码覆盖率检查：

Numega的TrueCoverage

Rational的PureCoverage

TeleLogic公司的LogiScope

Macabe公司的Macabe

代码性能检查：

Numega的TrueTime

Rational的Quantify等。

代码静态度量分析度量检查工具：LogiScope和Macabe等。

黑盒测试工具主要有：QACenter、SQATeamTest、Rational Visual Visual Test。

QACenter：QACenter帮助所有测试人员创建一个快速、可重用的测试过程。这些测试工具自动帮助管理测试过程、快速分析和调试程序，包括针对回归、强度、单元、并发、集成、移植，容量和负载建立测试用例，自动执行测试和产生文档结果。QACenter主要包括以下几个模块：

QARun：应用的功能测试工具。

QALoad：强负载下应用的性能测试工具。

QADirector：测试的组织设计和创建以及管理工具。

TrackRecord：集成的缺陷跟踪管理工具。

EcoTools：高层次的性能监测工具。

3、部分具体测试工具的介绍

（1） 性能优化工具EcoScope

EcoScope是一套定位于应用（即服务提供者本身）及其所依赖的所有网络计算资源的解决方案。EcoScope可以提供应用视图，并标出应用是如何与基础架构相关联的。这种视图是其他网络管理工具所不能提供的。EcoScope能解决在大型企业复杂环境下分析与测量应用性能的难题。通过提供应用的性能级别及其支撑架构的信息，EcoScope能帮助IT部门就如何提高应用性能提出多方面的决策方案。

EcoScope的应用主要表现在以下几个方面：

确保成功部署新应用

维护性能的服务水平

加速问题检测与纠正的高级功能

定制视图有助于高效地分析数据

（2） 数据库测试数据自动生成工具——TestBytes

在数据库开发的过程中，为了测试应用程序对数据库的访问，应当在数据库中生成测试用例数据，我们可能会发现当数据库中只有少量数据时，程序可能没有问题，但是当真正投入到运用中产生了大量数据时就出现问题了，这往往是因为程序的编写没有达到，所以一定及早地通过在数据库中生成大量数据来帮助开发人员完善这部分功能和性能。

TestBytes是一个用于自动生成测试数据的强大易用的工具，通过简单的点击式操作，就可以确定需要生成的数据类型（包括特殊字符的定制），并通过与数据库的连接来自动生成数百万行正确的测试数据，可以极大地提高数据库开发人员、QA测试人员、数据仓库开发人员、应用开发人员的工作效率。

（3） PC—LINT

PC—LINT 主要进行更严格的语法检查功能，还完成相当程度的语义检查功能。可以这样认为：PC—LINT是一个更加智能、更加严格的编译器。PC—LINT在实现语法和某些语义规则检查时，是通过参数配置完成的，它的选项就有数百个之多，因此，在使用PC—LINT过程中，了解选项的含义也很重要。

（4） TCL

TCL是Tool Command Language的缩写，它是一种很流行的脚本解释器，尤其在测试领域，它的最大特点是可移植性好，接口简单，方便，可以很容易地嵌入到软件中，作为自己的解释器使用。

TCL提供两种接口：编程接口和用户接口。编程接口是通过LIB或DLL形式提供的，提供了一些函数（命令）供调用，包括：分配一个解释器指针（对象）;初始化解释器（指针）;注册扩展函数等。用户接口很简单，即编写的脚本，脚本里面包含对扩展命令的调用。

（5） VB测试工具：VB Watch

（6）Java 程序的测试工具

1）Bean—Test

2）EJBQuickTest

3）JStyle

4）JTest

5）HttpUnit

6）JUnit

（7） 覆盖测试

C—Cover

C—Cover是一个测试工具软件，用来找出没有被测到的代码，并报告测试的覆盖率。

C—Cover

只支持C/C++的代码覆盖率分析，其它语言不支持。但不受OS的限制。

===============================================

单元测试方面：（对开发人员比较有用） J-Unit工具。

功能测试方面：E-test是个不错的选择，功能很强大，由于不是采用Post URL的方式回放脚本，所以可以支持多内码的测试数据（当然要程序支持）。基本上可以应付大部分的Web Site。

如果只是利用脚本回放代替手工劳动，或者做对页面响应数的性能测试，Microsoft Web Application Stress Tool是个不错的选择。

另外，在性能测试方面，PureLoad也是一个不错的工具，完全用Java写成，可以测试各种C/S程序， 如SMTP Server等。 这两个工具都是使用Post URL的方法测试Web Application的。对大量使用JavaScript的页面不太适合。 当然，如果程序在Unix，linux下面运行的话，可以直接编写Shell脚本程序，更加方便。

另外，还有很多专门的工具，比如说Linkbot是专门作页面链接测试的。

另外，测试流程管理工具也有不少，个人用过也一直在用的是Test Plan Control，短小精悍，不错。 至于WinRunner和LoadRunner之类，因为没有License，所以都没怎么用过，惭愧。不过我看过一篇英国人评价英国测试市场上最流行的五个软件的文章。WinRunner得分最高。

测试工具从测试的方法上可以分为两种：白盒测试和黑盒测试 白盒测试工具主要有：

内存资源泄漏检查：Numega中的bouncechecker，Rational的Purify等。

代码覆盖率检查：Numega中的truecoverage，Rational的Purecoverage，Telelogic公司的logiscope， Macabe公司的Macabe等 。

代码性能检查：Numega中truetime，Rational的Quantify等 。

代码静态度量分析质量检查工具：logiscope和Macabe等。

黑盒测试工具主要有： 客户端功能测试：MI公司的winrunner，compuware的qarun，Rational的SQA robot等等。

服务器端压力性能测试： MI公司的winload，compuware的qaload，Rational的SQA load等等 。

Web测试工具：MI公司的Astra系列，rsw公司的e-test suite等等。

测试管理工具：rational的test manager，compuware的qadirector等等，此外还有缺陷跟踪工具 trackrecord等。

数据库测试工具：TestBytes

黑盒测试工具：QACenter、SQATeamTest，Rational Viaual Test。

回归测试工具：Rational TeamTest，WinRunner（MI公司）

WEB系统测试工具：TEST，Workberch，Web Appication Stress Tool（WAS）

白盒测试工具：Numega 、PuRe、软件纠错工具（Rational Purity）。

嵌入式测试工具：Logiscope（静态测试工具）、CodeTest。

系统负荷测试工具：RationalPerformance

涵盖测试工具范围评估工具

软件性能测试工具：LoadRunner（MI产品）、Rational Visual Qantify

测试管理工具： TestDirector（MI产品支持整个生命周期中测试流程管理）

IBM-testmanage ;　compureware-trackrecord

微创的TCM

嵌入软件测试工具：codetest

楠族开心果

随着软、硬件技术的发展，计算机的应用领域越来越广，而其中软件的功能也越来越强大，软件也越来越复杂。这就使保证软件的质量，保证软件的高度可靠性，面临巨大的挑战。特别是诸如军事、航空航天、通讯、交通医疗等行业，软件的微小瑕疵就可能造成对生命安全、天文数字的巨额财产、甚至对国家安全严重威胁。

因此，对软件产品质量的度量、评估和保证，成了用户和项目承揽公司都十分关注的问题。基于这些原因，国际上的标准化和认证组织已经制定出了一些软件标准（在ISO-9001以及SEI CMM框架中）。对于软件的开发过程即可通过这些标准进行约束和度量。

为了确保软件的质量，达到软件工程的度量标准，软件测试是非常必要的。我们通过对国内外知名软件提供商和系统集成商的调查了解，在软件产品的测试方面均使用软件工程中提出的两种方法进行测试，即白盒和黑盒测试。白盒是已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否已经通过检查。白盒测试又叫结构测试。黑盒是已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求，黑盒又叫做功能测试，它不仅应用于开发阶段的测试，更重要的是在产品测试阶段及维护阶段必不可少。

太平洋软件（中国）有限公司（PTS）自1995年引进第一个测试工具以来，涉足测试领域已有多年，对当今流行的测试软件、测试理论和方法都有深入的研究和理解，在此基础上，开展了为用户提供测试方法培训和测试专业服务的业务。通过服务，我们力求能够帮助用户有效地、有步骤地调整其现有软件生产过程，帮助企业通过ISO9001 认证，提高开发队伍的CMM 等级，最终达到提高软件产品质量，加强企业竞争力促进企业发展的目的。

以下是PTS推出的测试方法和测试工具解决方案。


一、 白盒测试的实施方案

在开发阶段

要保证产品的质量，产品的生产过程应该遵循一定的行业标准。软件产品也是同样，没有标准可依自然谈不上质量的好坏。所有关心软件开发质量的组织、单位，都要定义或了解软件的质量标准、模型。其好处是保证公司实践的均匀性，产品的可维护性、可靠性以及可移植性等。

在测试阶段

与软件产品的开发过程一样，测试过程也需要有一定的准则，来指导、度量、评价软件测试过程的质量。

定义测试准则

为控制测试的有效性以及完成程度，必须定义准则和策略，以判断何时结束测试阶段。准则必须是客观的，可量化的元素，而不能是经验或感觉。

根据应用的准则和项目相关的约束，项目领导可以定义使用的度量方法，和要达到的覆盖率。

度量测试的有效性、完整性

对每个测试的测试覆盖信息和累计信息，用图形方式显示覆盖比率，并根据测试运行情况实时更新，随时显示新的测试所反映的测试覆盖情况。

允许所有的测试运行依据其有效性进行管理，用户可以减少不适用于非回归测试的测试的过程。

优化测试过程

在测试阶段的第一步，执行的测试是功能性测试。其目的是检查所期望的功能是否已经实现。在测试的初期，覆盖率迅速增加。象样的测试工作一般能达到70%的覆盖率。但是，此时要再提高覆盖率是十分困难的，因为新的测试往往覆盖了相同的测试路径。在该阶段需要对测试策略做一些改变：从功能性测试转向结构化测试。也就是说，针对没有执行过的路径，构造适当的测试用例来覆盖这些路径。

在测试期间，及时地调整测试策略，并检查分析关键因素，以提高测试效率。

在维护阶段

有一点认识越来越为大多数人所认可：应用系统的维护费用与初始的开发费用基本相等，而在维护过程中，在对应用结构、逻辑、运行的理解上花费的时间，要用去50%的时间。

由于系统维护人员很可能不是开发人员本人，再加上人员的流动、团队内部的交流的不足，都需要对应用系统的理解。

理解应用系统

将应用系统的设计，以文件形式（部件文件间的关系）和调用图的形式（函数和过程间的关系）可视化。

函数的逻辑结构以控制流图的形式显示，在控制流图上选定一个节点，即可得到相对应的代码。

应用系统可以在不同的抽象层上进行分析，不同层次间的导航关联，促进对整体的理解。

对应用按其资源的使用进行检测，由此促进对函数之间（参数传递）的信息流、数据间的关系，以及其它资源的理解。

安全地修改软件

维护软件意味着修改软件，修改后的程序确认需要大量的工作。因为，看起来很小的修改，都可能会滚雪球似的导致数十处甚至上百处的修改。这种后继的修改需求，越早发现越好，最好是在编译前就发现并做出修改，最坏的情况是在调试和非回归测试期间发现。


二、黑盒测试的实施方案

传统系统的编程语言和逻辑全是过程式的。这种逻辑顺序只有当数据中的值引起不同的循环或控制顺序改变时才会发生变化。

客户机/服务器和图形用户界面系统不是过程式的。它们是事件驱动的。这意味着计算机针对发生的事件执行相应的程序。这里的事件是指用户采取的行为，象键盘活动，鼠标移动，鼠标击键动作和按键的动作，都是事件的例子。因为事件发生的顺序不能预先知道，事件驱动系统相对来说更难测试。开发人员不可能知道用户下一次要选中哪个按钮或菜单项。实际上，应用程序必须在任何时候对所有发生和可能发生的事件作好正确处理的准备。

另外，随着RAD（快速应用开发方式）的引入，导致应用的实现速度很快，但这种方式也有它的不足。一个重要的缺点是项目规划经常漏掉重要的测试阶段。测试象在传统开发项目中一样，经常被忽视，并且给予很不现实的少量时间和资源。对于这一点，测试RAD方式下提交的应用并保证软件质量是测试团队的首要工作。

黑盒测试在实施时又分为客户端的测试和服务器端的性能测试。客户端的测试主要关注应用的业务逻辑，用户界面，功能测试等;服务器端的测试主要关注服务器的性能，衡量系统的响应时间、事务处理速度和其他时间敏感的需求。在应用系统最终被交付之前保证这两方面的测试没有缺陷。

由于测试并不是进行一次就可以完成的个过程，而是需要根据产品版本的变化生成不同的测试过程，如果这一过程仅通过手工方式完成是很难达到的。需要通过工具的帮助，从而简化测试的复杂程度，降低在测试成本上的开销，缩短投放市场的时间。还有一个突出的特点就是应用程序的回归测试，这是手工方式完成不了的过程，只有通过工具才能实施。而回归测试在测试阶段是很重要的过程，通过回归测试可以发现很多隐含的缺陷和错误。

在服务器端的测试主要以模拟合法用户活动给系统的负载，负载测试的统计结果被用来预测用户将体验到的性能和响应时间。这都需要在客户机/服务器系统发行之前都要进行的。

楠族开心果

三、相关工具

在我们了解了测试所涉及的内容之后，测试方法和采用相对应的自动化测试工具是至关重要的。自动化的测试工具意味着在测试活动中减少相当部分开销，真正的含义是它参加了测试的很大部分活动;同时，有些测试活动是靠手工方式难以实现，难以度量的。我们在对自动化的测试工具做成本效益分析时，应当考虑到项目的预期时间和人工消耗，一些测试用手工来做可能由几个人需要几个星期甚至更长时间来完成，而采用自动化的测试工具可能只需要几个小时或者几分钟;象基于Client-Server的负载测试或者是基于Web系统的测试如果要用手工测试来完成是很困难和不现实的。所以，在测试活动中选择自动化的测试工具是非常必要的。

下面我们就相应工具进行简要的介绍。

嵌入式软件测试工具

LOGISCOPE 是一组嵌入式软件测试工具集。它贯穿于软件开发、代码评审、单元/集成测试、系统测试、以及软件维护阶段。它面向源代码进行工作。LOGISCOPE 针对编码、测试和维护。因此，LOGISCOPE 的重点是帮助代码评审（Review ）和动态覆盖测试（Testing ）。

LOGISCOPE对软件的分析，采用基于国际间使用的度量方法（Halstead、McCabe等）的质量模型，以及从多家公司收集的编程规则集，可以从软件的编程规则，静态特征和动态测试覆盖等多个方面，量化地定义质量模型，并检查、评估软件质量。

LOGISCOPE 在开发阶段，查找可寻找潜在的错误。

在代码评审阶段，LOGISCOPE 定位那些具有80%错误的程序模块。

通过对未被测试代码的定位，LOGISCOPE 帮助找到隐藏在未测试代码中的缺陷。

项目领导和质量工程师用LOGISCOPE 定期地检查整个软件的质量。

在各个阶段用LOGISCOPE ，改进软件工程的实践，训练程序员的编写良好的代码和测试活动，确保系统易于维护，减少风险。

在有合同关系时，合同方可以用LOGISCOPE 明确定义验收时质量等级和执行测试。承制方可以用LOGISCOPE 演示其软件的质量。

LOGISCOPE 获取ISO/IEC9126 定义的“Quality Characteristics ”;

LOGISCOPE 为ISO-9001提供需求（test acceptance criteria and qulity records ）

LOGISCOPE 为开发者提供SEI/CMM在第2 级（Repeatable ）所要求的软件质量跟踪等关键实践的要求，推进开发组织尽快达到SEI/SMM 的3 级。

1）LOGISCOPE 用于开发阶段

定义质量模型

RuleChecker 预定义了50 个的编程规则：名称约定（如：局部变量用小写等）;表示约定（如：每行一条指令）; 限制（如：不能用GOTO 语句，不能修改循环体中的计数器等）。用户可以从这些规则中选择，也可以用Tcl 、脚本和编程语言定义新的规则。此外，还提供50 个面向安全-关键系统的编程规则。

Audit 以ISO9126 模型作为质量评价模型的基础。质量评价模型描述了从Halstend 、McCabe 的度量方法学和VERILOG 引入的质量方法学中的质量因素（可维护性、可重用性、等）和质量准则（可测试性、可读性、等）。

工程项目领导或质量管理人员可以根据准则、应用软件的生存周期、合同需求等，挑选并采纳适用于项目需求的质量模型。

验证、评审和改进代码

RuleChecker 用所选的规则对源代码进行验证。指出所有不符合编程规则的代码，并提出改进源代码的解释和建议。RulrChecker 通过文本编辑器直接访问源代码并指出需要纠正的位置。

Audit 将被评价的软件与规定的质量模型进行比较，用图形形式显示软件质量的级别，因此，质量人员可以把精力集中到需要修改的代码部分。对度量元素和质量模型不一致的地方作出解释并提出纠正的方法。

2）LOGISCOPE 用于测试阶段

定义测试准则

LOGISCOPE 推荐对指令（IB）、逻辑路径（DDP）和调用路径（PPP）的覆盖测试。此外对安全-关键软件还提供了MC/DC 的覆盖测试。

测试的有效性

TestChecker 产生每个测试的测试覆盖信息和累计信息。用直方图显示覆盖比率，并根据测试运行情况实时在线更改。随时显示新的测试所反映的测试覆盖情况。

TestChecker 允许所有的测试运行依据其有效性进行管理。用户可以减少那些用于非回归测试的测试。

测试的优化

在测试阶段的第一步，执行的测试是功能性（黑箱）测试。其目的是检查所期望的功能是否已实现。在测试初期，覆盖率会迅速增加。象样的测试工作一般能达到70%的覆盖率。但是，要提高此比率是十分困难的。主要是由于测试用例覆盖了相同的测试路径。这时，需要对测试策略做一些改变。执行结构化（白箱）测试，即，要检测没有执行过的逻辑路径，定义新的测试用例覆盖这些路径。

在执行测试期间，当测试策略改变时，综合的运用TestChecker 检测关键因素以提高效率。将TestChecker与Audit 配合使用能够帮助用户分析未测试的代码。

用户可以显示所关心的代码，并通过对执行未覆盖的路径的观察得到有关的信息。信息以图形（控制流图）和文本（伪代码和源文件）的形式提交，并在其间建立导航关联。

TestChecker 管理系统声明新的测试、生成有关文档、定义启动命令、以及自动执行的方法。

3）LOGISCOPE 用于维护阶段

人们广泛的认识到应用系统的维护费用与开发费用基本相等。经验表明50%的软件维

护时间化在对结构、逻辑和运行的理解上。LOGISCOPE 可以大大的减少对未知系统的理解所需的时间。

Audit 将应用系统的框架以文件形式（部件文件间的关系）和调用图的形式（函数和过程间的关系）可视化。函数的逻辑结构以控制流图的形式显示。在控制流图上选定一个节点，即可得到相对应的代码。可以在不同的抽象层上对应用系统进行分析，不同层次间的导航，促进对整体的理解。

4）对嵌入式领域的支持

LOGISCOPE 支持多种测试方式。特别是对嵌入式领域软件的支持。

众所周知，嵌入式系统软件的测试是最为困难的。因为，它的开发是用交叉编译方式进行的。在目标机（Target）上，不可能有多余的空间记录测试的信息。必须实时地将测试信息通过网线/串口传到宿主机（Host）上，并实时在线地显示。因此，对源代码的插装和目标机上的信息收集与回传成为问题的关键。

LOGISCOPE 很好地解决了这些技术，成为嵌入式领域测试工具的佼佼者。它支持各种实时操作系统（RTOS）上的应用程序的测试，也支持逻辑系统的测试。Logiscope 提供VxWorks 、pSOS 、VRTX 实时操作系统的测试库。

5）对航空/航天/国防/核电站领域的支持

在航空/航天领域，安全是最关键的问题。因此，欧美的航空/航天制造厂商和使用单位联合制定了RTCA/DO-178B。LOGISCOPE 通过对

和“Structural Coverage Analysis ”能够使开发的软件达到RTCA/DO-178B 标准的A 、B 、C 三个系统级。

是第一个提供MC/DC（Modified Condition/Decision Coverage）测试的工具。

6）软件文档和测试文档的自动生成

Logiscope 提供了文档自动生成工具。使用者可以将代码评审的结果和动态测试情况实时生成所要求的文档，这些文档忠实地记录代码的情况和动态测试的结果。文档的格式可以根据用户的需要定制，如，GJB-438A。

支持的主机平台：

UNIX：Sun OS/Solaris， HP 700 HP-UX， RS6000 AIX， Power PC， DEC UNIX;

IBM Mainframe MVS环境;

PC Windows/NT。

支持的语言：

目标机环境：支持嵌入式实时操作系统VxWorks，PSOS。

楠族开心果

白盒工具

这是一组白盒测试工具，主要是用于代码开发阶段，检查应用的可靠性和稳定性。它提供了先进的错误检查和调试解决方案，充分地改善生产力和开发团队的软件开发质量。NuMega产品线是一个全面的SmartDebugging工具包，自动地检查企业级或Internet级用多语言创建的组件和应用中出现的软件错误和性能问题，并能很快地给予解决。

NuMega DecPartner Studio满足在软件开发过程中每一个开发人员的需求，无论我们是使用一种或多种语言，NuMega产品都能够帮助我们提高生产力。它的产品主要有自动地错误检测、性能分析、代码覆盖分析等功能，分别用于捕获、定位错误，抽取代码执行频度，以及抽取代码覆盖率等数据，产品包括：

程序员在开发过程中可能会经常遇到这样的问题：调试时语法没有问题，代码也没有错误，但应用程序运行就是不正常甚至死机，其实这有可能是由于逻辑错误引起的内存溢出或资源泄露等问题，这些错误一般是不容易被检测出来的。而这类错误就是BoundsChecker错误检测范围之一。

通过对被测应用程序的操作，BoundsChecker提供清晰的、详细的程序错误分析，自动查明静态的堆栈错误及内存/资源泄露，并能够迅速的定位出错的源代码，即使在没有源代码的情况下也可检查第三方组件的错误。

BoundsChecker错误检测范围主要包括：

指针和泄露错误

接口泄露

内存泄露

资源泄露

未分配的指针错误

内存错误

动态存储溢出

无效的句柄被锁定

句柄没有被锁定

内存分配冲突

栈空间溢出

静态存储溢出

API和OLE错误

API函数返回失败

API函数未执行

无效的变量（包括指针变量、字符串变量等）

OLE接口方法的变量无效

OLE接口方法失败

线程调用库函数错误

BoundsChecker支持的语言和主机平台

在开发过程中，对一个应用程序通过手工测试，总会有一部分代码功能没有被检测到，或者说逐个检测每一个函数的调用是相当费时间的;未被检测的代码我们不能保证它的可靠性，以后程序的失败可能往往就是由这部分未检测的代码造成的。现在我们可以用TrueCoverage来帮助我们解决这些问题，我们在测试程序时，每完成一次应用话路，TrueCoverage就能够列出在这次对话中所有函数被调用次数、所占比率等，并可以直接定位到源代码，当然我们也可以合并多个应用话路来进行检测。所以说TrueCoverage能通过衡量和跟踪代码执行及代码稳定性，帮助开发团队节省时间和改善代码可靠性。

TrueCoverage支持的语言和主机平台

代码运行缓慢是开发过程中一个重要问题。一个应用程序运行速度较慢，程序员不容易找到到底是在哪里出现了问题，如果不能解决应用程序的性能将降低并极大的影响应用程序的质量，于是查找和修改性能瓶颈是调整整个代码性能的关键。如何快速的查找性能瓶颈呢？TrueTime的出现就使这个问题变得很容易了。当我们在测试程序时，每完成一次应用话路，TrueTime都能提供这次对话中函数的调用时间，提供详细的应用程序和组件性能的分析，并自动定位到运行缓慢的代码。这样就能帮助程序员尽快地调整应用程序的性能。

TrueTime支持的语言和主机平台

作为一名Visual Basic的开发人员，在开发的过程中经常会遇到许多问题难以解决，包括象隐藏的run-time错误、Windows API函数在Visual Basic中正确使用的问题、一些组件的错误等等，它们很难被定位到具体的代码中，令开发人员花费大量时间去寻找并解决。SmartCheck就是能很快地查找到这些问题的一个自动化的工具，它是对于Visual Basic来说最好的run-time调试工具，它检测所有的Windows API函数调用、内存分配以及其它一些重要的程序错误。SmartCheck检错的种类包括泄露、接口方法失败、存储错误、程序和函数失败和Visual Basic的Runtime错误等，它能够将检测到的错误快速地定位到源代码。使用SmartCheck将会极大地提高VB开发人员的工作效率。

SmartCheck 支持的语言和主机平台

FailSafe是用于Visual Basic开发的一个自动错误处理和恢复系统。VB开发人员经常能够遇到程序执行时意外地终止，但是对于为什麽出现错误只提供了简短的、模糊的出错信息，使开发人员不能方便地发现错误的根源。如果使用了FailSafe，它将插入额外的代码对你的程序进行插装，当程序执行时，FailSafe通过这些插装的代码捕获、记录执行时程序和系统的重要信息，直接指出错误发生时程序和系统的状态，这些丰富的信息使开发人员能够快速且正确的解决问题。

FailSafe 支持的语言和主机平台

对于Visual Basic开发人员来说，CodeReview是最好的自动源代码分析工具，它对应用程序的组件、逻辑、Windows和Vb自身潜在的数百个问题进行严格地源代码检查。CodeReview分析的类型包括Y2K问题，逻辑错误，应用程序性能和可用性问题，Windows API调用和标准一致性问题等。CodeReview可以检测整个的VB工程或指定的模块，并能定制检错的种类;对检测的结果有详细的说明，提供帮助和推荐解决方案，而且能够直接的链接到源代码。

CodeReview系统还提供了两个子模块，一个是Metrics：通过对VB工程（vbp）的执行，计算出代码的长度、复杂度、理解度、语言的使用等级、出错的可能性等数据;另一个是Namer：它调用一个VB工程，自动并规则地对其中的对象重新命名，并备份原来没有规则命名的工程文件，使开发人员对程序能够有条理地管理。

可以这麽说：CodeReview是Visual Basic开发人员必不可少的顾问。

CodeReview 支持的语言和主机平台

JCheck对于Java开发人员来说是一个功能强大的图形化的线程和事件分析工具，它提供了一个生动的图形化的方法来表现程序的线程的状态信息以及和Windows线程、同步对象、线程组等的交互作用信息，使开发人员能够直观地分析Java Applet或Application：通过这些形象化的图形显示，可以确定runtime错误，对执行和逻辑错误进行分析，立刻发现线程问题如死锁、活锁、资源缺乏和系统失败，诊断线程同步和时间选择问题，分析程序执行流程;而后JCheck对于那些错误可以定位和显示详细的信息并能定位到源代码。Jcheck极大地减少了程序的调试时间，改善了软件开发生产力。

JCheck 支持的语言和主机平台：

Microsoft Visual J++

Windows NT， Windows95/98

楠族开心果

黑盒工具

QACenter帮助所有的测试人员创建一个快速，可重用的测试过程。这些测试工具自动帮助管理测试过程，快速分析和调试程序，包括针对回归，强度，单元，并发，集成，移植，容量和负载建立测试用例，自动执行测试和产生文档结果。QACenter主要包括以下几个模块：

ˉ QARun：应用的功能测试工具。

ˉ QALoad：强负载下应用的性能测试工具。

ˉ QADirector：测试的组织设计和创建以及管理工具。

ˉ TrackRecord：集成的缺陷跟踪管理工具。

ˉ EcoTools：高层次的性能监测工具。

功能测试工具

在QACenter测试产品套件中，QARun组件主要用于客户/服务器应用客户端的功能测试。在功能测试中主要包括对应用的GUI（图形用户界面）的测试及客户端事物逻辑的测试。而现在的RAD（快速应用开发）方式开发的应用，由于开发的速度比较快，可支持用户多变的需求而不断的调整应用，所以要求对软件要有更严格的测试。有人可能存在这样的疑问：基于GUI的测试及客户端事物逻辑的测试，用手工的方式也可以进行，工具在这方面又能给我们一些什么帮助呢？在这里由于不断变化的需求将导致应用不同版本的产生，每一个版本都需要对它测试，因为是每一个被调整的内容往往最容易隐含错误，所以回归测试是测试中最重要的阶段，而回归测试通过手工方式是很难达到的，工具在这方面可以大大的提高测试的效率，使测试更具完整性。

QARun组件的测试实现方式是通过鼠标移动、键盘点击操作被测应用，即而得到相应的测试脚本，对该脚本可以进行编辑和调试。在记录的过程中可针对被测应用中所包含的功能点进行基线值的建立，换句话说就是在插入检查点的同时建立期望值。在这里检查点是目标系统的一个特殊方面在一特定点的期望状态。通常，检查点在QARun提示目标系统执行一系列事件之后被执行。检查点用于确定实际结果与期望结果是否相同。

性能测试工具

QALoad是企业范围的负载测试工具，该工具支持的范围广，测试的内容多，可以帮助软件测试人员，开发人员和系统管理人员对于分布式的应用执行有效的负载测试。负载测试能够模拟大批量用户的活动，从而发现大量用户负载下对C/S系统的影响。

1）操作简便

测试人员只需操作被测应用，执行性能关键的事物处理，然后在QALoad脚本中通过服务器上应用调用的需求类型开发这些事物处理。每个交易成为它自己的脚本。QALoad Script Development Workbench很容易创建完整的功能脚本。QALoad的测试脚本开发是由捕获会话，转换捕获会话到脚本，以及修改和编译脚本一系列的过程组成。一旦脚本编译通过后，使用 QALoad的组织分配把脚本分配至测试环境中相应的机器上，驱动多个play agent模拟大量用户的并发操作，实施应用的负载测试，完全减轻了以往大量的人工工作，节省了时间，提高了效率。

2）广泛的适用性

QA Load支持：DB2，DCOM，ODBC，ORACLE，NETLoad，Corba，QARun，SAP，SQLServer，Sybase，Telnet，TUXEDO，UNIFACE，WinSock，WWW等等。

应用可用性管理工具

在应用的性能测试完成之后，对应用的可用性状况如何实施分析？很多因素能够影响应用的可用性。用户的桌面，网络，应用的服务器，数据库环境和他们的各种各样的子组件都链接在一体。任何一个组件可能引起整个应用对最终用户不可用。

EcoTOOLS是EcoSYSTEM组件产品的基础--解决应用可用性中计划，管理，监控和报告的挑战。EcoTOOLS提供一个广泛范围的打包的Agent和Scenarios，可以立即在测试或生产环境中激活，计划和管理以商务为中心应用的可用性，EcoTOOLS支持一些主流成型的应用，SAP，PeopleSoft，Baan，Oracle，UNIFACE和LotusNotes，以及定制的应用。EcoTOOLS与QALoad集成为所有加载测试和计划项目需求能力提供全面的解决方案。

EcoTOOLS对于应用的可用性进行管理

EcoSCOPE优化应用性能

用EcoTOOLS监控服务器性能

QALoad 对于在服务器上设置加载和极微小的服务器性能问题是一个极好的测试工具，但不承担诊断问题的工作。而QALoad与EcoTOOLS集成则为所有加载测试和计划项目需求能力提供全面的解决方案。

EcoTOOLS包括数百个Agents可以监控服务器资源。尤其是它包括监控Windows NT， UNIX 系统， Oracle，Sybase， SQL Server， 和其他应用包。通过使用QALoad 与EcoTOOLS ，可以在系统生成一个负载，同时监控资源的利用问题。

与 EcoTOOLS集成允许在图形中查看EcoTOOLS资源利用数据，可以使用QALoad的分析组件创建。在使用EcoTOOLS和QALoad之前，需要做下列事情：

安装EcoTOOLS监控服务器加载

如果希望与QALoad 集成EcoTOOLS NT 数据，设置一个ODBC数据源存储关于怎样连接EcoTOOLS 的信息。

配置QALoad，从EcoTOOLS NT 和/或 EcoTOOLS UNIX抽取资源利用数据。

一旦设置EcoTOOLS 监控服务器，它将定时地搜集资源利用数据。当执行一个加载测试，QALoad用EcoTOOLS同步并运行测试。在完成测试之前，QALoad需要EcoTOOLs在测试期间搜集的资源利用数据。可以使用QALoad的分析组件展示这一数据。

QALoad与EcoTOOLS和EcoSCOPE服务层管理能力集成，端到端的测试网络应用。同时，这些产品分发至关重要的信息和必要的详细问题分析分解端到端响应时间并调整应用，数据库和网络彻底地优先地配置应用--并且帮助满足客户/服务器系统性能标准。

应用性能优化工具

EcoSCOPE是一套定位于应用（即服务提供者本身）及其所依赖的所有网络计算资源的解决方案。EcoSCOPE可以提供应用视图，并标出应用是如何与基础架构相关联的。这种视图是其它网络管理工具所不能提供的。EcoSCOPE能解决在大型企业复杂环境下分析与测量应用性能的难题。通过提供应用的性能级别及其支撑架构的信息，EcoSCOPE能帮助IT部门就如何提高应用性能提出多方面的决策方案。

贯穿整个应用生命周期的性能分析

EcoSCOPE使用综合软件探测技术无干扰地监控网络，可自动发现应用、跟踪在LAN/WAN上的应用流量、采集详细的性能指标。EcoSCOPE将这些信息关联到一个交互式用户界面（Interactive Viewer）中，自动识别低性能的应用、受影响的服务器与用户、性能低下的程度。Interactive Viewer允许你以一种智能方式访问大量的EcoSCOPE数据，所以能很快地找到性能问题的根源，并在几小时内解决令人烦恼的性能问题，而不是几周甚至几月。另外，EcoSCOPE的长期（long-term）数据采集能使我们通过预先趋势分析和策略规划预测到未来的问题。

确保成功布署新应用

EcoSCOPE允许使用从运行网络中采集到的实际数据来创建一个测试环境。利用此环境，可以在不影响其它应用的情况下，测量新应用在已存架构中的适应性（即网络能力），还可测量出与网络共享资源的可交互性。它能揭示性能问题，如低伸缩性或瓶颈，能调整应用和定位基础架构上的缺陷。一旦性能得到了提高，EcoSCOPE可以重新评估，验证应用是否达到了预期目的。这些指标数据可用来作为布署应用的基准，以确保达到预期目标。

维护性能的服务水平

EcoSCOPE性能评分卡（scorecard）能很容易地显示出关键应用每时每刻是如何运行的，以及它们是否达到了预期的服务水平。对于必须满足服务水平协议（SLAs）的应用，EcoSCOPE能为之设置性能要求，并监控是否有偏离。如果一个应用超出了性能的上下限，EcoSCOPE将认为服务水平异常，并根据受影响用户的数量和性能降低的时间长短细分问题的严重程度。这些信息使你的IT维护人员能优先关注对业务影响最大的的应用问题。

EcoSCOPE的scorecard以图形方式按时间周期显示响应时间和流量，以及受应用影响的关键服务器和最终用户。在scorecard中，能通过比较和关联这些信息，确定应用使用量、响应时间、特定的最终用户和服务器之间的因果关系。在业务被阻碍前，跟踪每天的变化趋势，控制性能波动。 快速找出性能瓶颈

一旦EcoSCOPE发现性能低下的应用，它将提供详细信息来隔离造成瓶颈的来源。EcoSCOPE图形化界面使你交互地观察单个受影响的工作站、服务器及网段。EcoSCOPE提供的大量信息有助于进行问题根源的分析，确定问题扩散的原因、受影响的服务器和用户及其性能受损是否有共性。

EcoSCOPE对瓶颈的分析不限于网络基础架构和资源，而且包括其它关键计算资源，如桌面和服务器。

加速问题检测与纠正的高级功能

完善的EcoSCOPE技术被动地监视网络，能收集到关于应用与协议的独特信息，不只包括IP与IPX流量，可以更好地分析与排除应用的性能问题。EcoSCOPE可自动发现几百种打包的内部应用，如SAP/R3、MS Exchange、Oracle、SNA LU2与LU6.2、Web、IPX/SPX和UNIX NOS。不象其它产品需要预先配置才能识别应用，EcoSCOPE跟踪LAN/WAN架构中的应用流量，并显示出应用使用的流量最大的路径及某个服务器的特定路径。

EcoSCOPE通过收集三类指标数据提供应用性能的完全视图：会话层响应时间、业务交易响应时间和应用流量。

EcoSCOPE的内置智能技术可识别组成业务交易的Oracle与SQLServer谓词的不同独特标志，并跟踪它的响应时间。

定制视图有助于高效地分析数据

EcoSCOPE将信息关联起来并显示到一个单一的交互式用户界面上。这个界面允许按应用或用户来灵活地创建定制的逻辑数据视图，能以最有用和有效的方式来分析信息。这就可以用多种视图显示来自于跨越地理和部门界限的大企业的数据。

EcoSCOPE能把历史信息导出到建模和仿真工具，如CACI、NetMaker。这些工具可描绘发展趋势和模拟未来的增长。这将使你能明白未来的瓶颈在哪里，更重要的是，什么时候它将威胁应用的服务水平。

数据库测试数据自动生成工具

在数据库开发的过程中，为了测试应用程序对数据库的访问，应当在数据库中生成测试用数据，我们可能会发现当数据库中只有少量的数据时程序可能没有问题，但是当真正投入到运用中产生了大量数据就出现问题了，这往往是程序的编写没有达到一些功能，所以一定及早地通过在数据库中生成大量数据来帮助开发人员尽快完善这部分功能和性能。但是如何生成大量测试数据呢？长期以来这些工作是靠手工来完成的，要占用有经验的开发和测试人员大量宝贵时间。

TESTBytes是一个用于自动生成测试数据的强大易用的工具，通过简单的点击式操作，就可以确定需要生成的数据类型（包括特殊字符的定制），并通过与数据库的连接来自动生成数百万行的正确的测试数据，可以极大地提高数据库开发人员、QA测试人员、数据仓库开发人员、应用开发人员的工作效率。

TESTBytes支持的平台：

Windows NT， Windows95/98 ，Windows 3.x

楠族开心果

软件测试自动化的一些具体做法

因为软件测试的工作量很大（40% 到60% 的总开发时间），而又有很大部分适于自动化，因此，测试的改进会对整个开发工作的质量、成本和周期带来非常显著的效果。

首先，谈谈在测试自动化的情况下，带有图形界面的产品的测试用例的设计问题。因为图形界面的输出显示不是很容易做到测试结果自动化比较，所以一般的做法是把图形界面输出的部分单独建立测试用例，以手工运行。而所有非图形输出则可进行自动测试。

下面举出一些测试自动化的例子：

测试个案（test case ，或称为测试用例）的生成

用编程语言或更方便的剧本语言（script language 例如Perl等）写出短小的程序来产生大量的测试输入（包括输入数据与操作指令）。或同时也按一定的逻辑规律产生标准输出。输入与输出的文件名字按规定进行配对，以便控制自动化测试及结果核对的程序易于操作。

这里提到测试个案的命名问题，如果在项目的文档设计中作统一规划的话，软件产品的需求与功能的命名就应该成为后继开发过程的中间产品的命名分类依据。这样，就会为文档管理和配置管理带来很大的方便，使整个产品的开发过程变得更有条理，更符合逻辑。任何新手半途加入到开发工作中也会更容易进入状态。

测试的执行写控制

单元测试或集成测试可能多用单机运行。但对于系统测试或回归测试，就极有可能需要多台机在网络上同时运行。记住一个这样的原则，在开发过程中的任何时候，如果你需要等候测试的运行结果的话，那就是一个缩短开发时间的机会。

对于单个的测试运行，挖潜的机会在测试的设置及开始运行和结果的对比及显示。有时候，需要反复修改程序，重新汇编和重新测试。这样，每一个循环的各种手工键入的设置与指令所花费的时间，加起来就非常可观。如果能利用make或类似的软件工具来帮助，就能节省大量的时间。

对于系统测试或回归测试这类涉及大量测试个案运行的情况，挖潜的的机会除了利用软件工具来实现自动化之外，就是怎样充分利用一切硬件资源。往往，就算是在白天的工作时间内，每台计算机的负荷都没有被充分利用。能够把大量测试个案分配到各台机器上去同时运行，就能节省大量的时间。另外，把大量的系统测试及回归测试安排到夜间及周末运行，更能提高效率。

如果不购买商品化的工具的话，应当遵从正规的软件开发要求来开发出好的软件测试自动化工具。在实践中，许多企业自行开发的自动化工具都是利用一些现成的软件工具再加上自己写的程序而组成的。这些自己开发的工具完全是为本企业量身定做的，因此可用性非常强。同时，也能根据需要随时进行改进，而不必受制于人。当然，这就要求有一定的人力的投入。

在设计软件自动测试工具的时候，路径（path）控制是一个非常重要的功能。理想的使用情况是：这个工具可以在任何一个路径位置上运行，可以到任何路径位置去取得测试用例，同时也可以把测试的结果输出放到任何的路径位置上去。这样的设计，可以使不同的测试运行能够使用同一组测试用例而不至于互相干扰，也可以灵活使用硬盘的空间，并且使备份保存工作易于控制。

同时，软件自动测试工具必须能够有办法方便地选择测试用例库中的全部或部分来运行，也必须能够自由地选择被测试的产品或中间产品采作为测试对象。

测试结果与标准输出的对比

在设计测试用例的时候，必须考虑到怎样才能够易于对此测试结果和标准输出。输出数据量的多少及数据格式对比较的速度有直接影响。而另一方面，也必须考虑到输出数据与测试用例的测试目标的逻辑对应性及易读性，这将会大大有利于分析测试所发现的不吻合，也有利于测试用例的维护。

许多时候，要写一些特殊的软件来执行测试结果与标准输出的对比工作，因为可能有部分的输出内容是不能直接对比的（比如，对运行的日期时间的记录，对运行的路径的记录，以及测试对象的版本数据等），就要用程序进行处理。

不吻合的测试结果的分析、分类、记录和通报

上一点所谈到的，用于对测试结果与标准输出进行对比的特殊软件，往往也同时担任对不吻合的测试结果进行分析、分类、记录和通报的任务。

“分析”是找出不吻合的地方并指出错误的可能起因。“分类”包括各种统计上的分项，例如，对应的源程序的位置，错误的严重级别（提示、警告、非失效性错误、失效性错误;或别的分类方法），新发现的还是已有记录的错误，等等。“记录”，是按分类存档。“通报”，是主动地对测试的运行者及测试用例的“负责人”通报出错的信息。

这里提到测试用例的“负责人”的概念。是用以指定一个测试用例运行时发现的缺陷，由哪一个开发人员负责分析（有时是另外的开发人员引进的缺陷而导致的错误）及修复。在设立测试用例库时，各用例均应有指定的负责人。

最直接的通报方法是由自动测试软件发出电子邮件给测试运行者及测试用例负责人。邮件内容的详细程度可根据需要灵活决定。

总测试状况的统计，报表的产生

这些都是自动测试工具所应有的功能。目的是提高过程管理的质量，同时节省用于产生统计数据的时间。

产生出来的统计报表，最好是存放到一个约定的路径位置，以便任何有关人员都知道怎样查阅。同时，可按需要用电子邮件向适当的对象（如项目经理，测试经理和质量保证经理）寄出统计报表。

自动测试与开发中产品每日构建（build ）的配合

自动测试应该是整个开发过程中的一个有机部分。自动测试要依靠配置管理来提供良好的运行的环境，同时它必须要与开发中的软件的构建紧密配合。

在开发中的产品达到一定程度的时候，就应该开始进行每日构建和测试。这种做法能使软件的开发状态得到频繁的更新，以及及早发现设计和集成的缺陷。

为了充分利用时间与设备资源，下班之后进行自动的软件构建，紧接着进行自动测试（这里多数指的是系统测试或回归测试），是一个非常行之有效的方法。如果安排得好，到第二天上班时，测试结果就已经在各人的电子邮箱里面面了，等待着新的一天的开发工作。

楠族开心果

主流测试工具的测试流程

========winrunner========

1.启动时选择要加载的插件

2.进行一些设置（如录制模式等）

3.识别应用程序的GUI，即创建map（就是学习被测试软件的界面）

4.建立测试脚本（录制及编写）

5.对脚本除错及调试（保证能够运行完）

6.插入各种检查点（图片，文字，控件等）

7.在新版应用程序中执行测试脚本

8.分析结果，回报缺陷

=========quicktestpro========

1.准备录制

打开你要对其进行测试的应用程序，并检查QuickTest中的各项设置是否适合当前的要求。

2.进行录制

打开QuickTest的录制功能，按测试用例中的描述，操作被测试应用程序。

3.编辑测试脚本

通过加入检测点、参数化测试，以及添加分支、循环等控制语句，来增强测试脚本的功能，使将来的回归测试真正能够自动化。

4.调试脚本

调试脚本，检查脚本是否存在错误。

5.在回归测试中运行测试

在对应用程序的回归测试中，通过QuickTest回放对应用程序的操作，检验软件正确性，实现测试的自动化进行。

6.分析结果，报告问题

查看QuickTest记录的运行结果，记录问题，报告测试结果。

========TestDirect=========

安装好后，先进入站点管理

1.创建域及工程

2.添加用户

3.编辑licenses及本服务器

4.编辑数据库

--TD

1.选择新建的工程进行定制（列表，用户，组，版本等）

2.在require中增加需求

3.把需求转化为plan

4.在testlab中由计划新建测试具体用例与执行

5.发现bug，在defect中提交

（每一部分都可以相对独立地使用）

======loadrunner======

1.制定负载测试计划

（分析应用程序， 确定测试目标，计划怎样执行LoadRunner）

2.开发测试脚本

（录制基本的用户脚本，完善测试脚本）

3.创建运行场景

（选择场景类型为Manual Scenario，选择场景类型，理解各种类型，场景的类型转化）

4.运行测试

5.监视场景

（MEMORY 相关，PROCESSOR相关，网络吞量以及带宽，磁盘相关，WEB应用程序 ，IIS5.0，SQL SERVER，NETWORK DELAY等

6.分析测试结果

（分析实时监视图表，分析事务的响应时间，分解页面，确定WEBSERVER的问题，其他有用的功能）

楠族开心果

主流测试工具介绍

Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。

企业级应用可能包括Web应用系统，ERP系统，CRM系统等等。这些系统在发布之前，升级之后都要经过测试，确保所有功能都能正常运行，没有任何错误。如何有效地测试不断升级更新且不同环境的应用系统，是每个公司都会面临的问题。

如果时间或资源有限，这个问题会更加棘手。人工测试的工作量太大，还要额外的时间来培训新的测试人员等等。为了确保那些复杂的企业级应用在不同环境下都能正常可靠地运行，你需要一个能简单操作的测试工具来自动完成应用程序的功能性测试。

轻松创建测试

用WinRuuner创建一个测试，只需点击鼠标和键盘，完成一个标准的业务操作流程，WinRunner自动记录你的操作并生成所需的脚本代码。这样，即使计算机技术知识有限的业务用户轻松创建完整的测试。你还可以直接修改测试脚本以满足各种复杂测试的需求。WinRunner提供这两种测试创建方式，满足测试团队中业务用户和专业技术人员的不同需求。

插入检查点

在记录一个测试的过程中，可以插入检查点，检查在某个时刻/状态下，应用程序是否运行正常。在插入检查点后，WinRunner会收集一套数据指标，在测试运行时对其一一验证。WinRunner提供几种不同类型的检查点，包括文本的、GUI、位图和数据库。例如，用一个位图检查点，你可以检查公司的图标是否出现于指定位置。

检验数据

除了创建并运行测试，WinRunner还能验证数据库的数值，从而确保业务交易的准确性。例如，在创建测试时，可以设定哪些数据库表和记录需要检测;在测试运行时，测试程序就会自动核对数据库内的实际数值和预期的数值。WinRunner自动显示检测结果，在有更新/删除/插入的记录上突出显示以引起注意。

增强测试

为了彻底全面地测试一个应用程序，需要使用不同类型的数据来测试。WinRunner的数据驱动向导（ Data Driver Wizard）可以让你简单地点击几下鼠标，就可以把一个业务流程测试转化为数据驱动测试，从而反映多个用户各自独特且真实的行为。

以一个订单输入的流程为例，你可能希望把订单号或客户名称作为可变栏，用多套数据进行测试。使用Data Driver Wizard，你可以选择订单号或客户名称用数据表格文件中的哪个栏目的数据替换。你可以把订单号或客户名称输入数据表格文件，或从其它表格和数据库中导入。数据驱动测试不仅节省了时间和资源，又提高了应用的测试覆盖率。

WinRunner还可以通过Function Generator增加测试的功能。使用Function Generator可以从目录列表中选择一个功能增加到你的测试中以提高测试能力。例如，你可以选择”calendar”，然后从日历功能的下属目录中选择，如Calendar_select_date（），然后你可以直观地输入参数，把这个功能插入到你的测试中。

针对相当数量的企业应用里非标准对象，WinRunner提供了Virtual Object Wizard来识别以前未知的对象。使用Virtual Object Wizard，你可以选择未知对象的类型，设定标识和命名。在录制使用该对象的测试时，WinRunner会自动对应它的名字，从而提高测试脚本的可读性和测试质量。

运行测试

创建好测试脚本，并插入检查点和必要的添加功能后，你就可以开始运行测试。运行测试时，WinRunner会自动操作应用程序，就象一个真实的用户根据业务流程执行着每一步的操作。测试运行过程中，如有网络消息窗口出现或其它意外事件出现，WinRunner也会根据预先的设定排除这些干扰。

分析结果

测试运行结束后，你需要分析测试结果。WinRunner通过交互式的报告工具来提供详尽的、易读的报告。报告中会列出测试中发现的错误内容、位置、检查点和其它重要事件，帮助你对测试结果进行分析。这些测试结果还可以通过Mercury Interactive的测试管理工具TestDirector来查阅。

维护测试

随着时间的推移，开发人员会对应用程序做进一步的修改，并需要增加另外的测试。使用WinRunner，你不必对程序的每一次改动都重新创建你的测试。WinRunner可以创建在整个应用程序生命周期内都可以重复使用的测试，从而大大地节省时间和资源，充分利用你的测试投资。

每次记录测试时，WinRunner会自动创建一个GUI Map文件以保存应用对象。这些对象分层次组织，既可以总览所有的对象，也可以查询某个对象的详细信息。一般而言，对应用程序的任何改动都会影响到成百上千个测试。通过修改一个GUI Map文件而非无数个测试，WinRunner可以方便地实现测试重用。

帮助你的应用程序为无线应用作准备

随着无线设备种类和数量的增加，你的应用程序测试计划需要同时满足传统的基于浏览器的用户和无线浏览设备，如移动电话、传呼机和个人数字助理（PDA）。

无线应用协议是一种公开的、全球性的网络协议，用来支持标准数据格式化和无线设备信号的传输。

使用WinRunner，测试人员可以利用微型浏览模拟器来记录业务流程操作，然后回放和检查这些业务流程功能的正确性。

工业标准级负载测试工具

LoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。

目前企业的网络应用环境都必须支持大量用户，网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢，系统崩溃等问题。这些都不可避免地导致公司收益的损失。Mercury Interactive 的 LoadRunner 能让企业保护自己的收入来源，无需购置额外硬件而最大限度地利用现有的IT 资源，并确保终端用户在应用系统的各个环节中对其测试应用的质量，可靠性和可扩展性都有良好的评价。

LoadRunner 是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner 的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的查找和发现问题。此外，LoadRunner 能支持广范的协议和技术，为您的特殊环境提供特殊的解决方案。

轻松创建虚拟用户

使用LoadRunner 的Virtual User Generator，您能很简便地创立起系统负载。该引擎能够生成虚拟用户，以虚拟用户的方式模拟真实用户的业务操作行为。它先记录下业务流程（如下订单或机票预定），然后将其转化为测试脚本。利用虚拟用户，您可以在Windows ，UNIX 或Linux 机器上同时产生成千上万个用户访问。所以LoadRunner能极大的减少负载测试所需的硬件和人力资源。另外，LoadRunner 的TurboLoad 专利技术能。

提供很高的适应性。TurboLoad 使您可以产生每天几十万名在线用户和数以百万计的点击数的负载。

用Virtual User Generator 建立测试脚本后，您可以对其进行参数化操作，这一操作能让您利用几套不同的实际发生数据来测试您的应用程序，从而反映出本系统的负载能力。以一个订单输入过程为例，参数化操作可将记录中的固定数据，如订单号和客户名称，由可变值来代替。在这些变量内随意输入可能的订单号和客户名，来匹配多个实际用户的操作行为。

LoadRunner 通过它的Data Wizard 来自动实现其测试数据的参数化。Data Wizard 直接连于数据库服务器，从中您可以获取所需的数据（如定单号和用户名）并直接将其输入到测试脚本。这样避免了人工处理数据的需要，Data Wizard 为您节省了大量的时间。

为了进一步确定您的Virtual user 能够模拟真实用户，您可利用LoadRunner 控制某些行为特性。例如，只需要点击一下鼠标，您就能轻易控制交易的数量，交易频率，用户的思考时间和连接速度等。

创建真实的负载

Virtual users 建立起后，您需要设定您的负载方案，业务流程组合和虚拟用户数量。用LoadRunner 的Controller，您能很快组织起多用户的测试方案。Controller 的Rendezvous 功能提供一个互动的环境，在其中您既能建立起持续且循环的负载，又能管理和驱动负载测试方案。

而且，您可以利用它的日程计划服务来定义用户在什么时候访问系统以产生负载。这样，您就能将测试过程自动化。同样您还可以用Controller 来限定您的负载方案，在这个方案中所有的用户同时执行一个动作---如登陆到一个库存应用程序----来模拟峰值负载的情况。另外，您还能监测系统架构中各个组件的性能---- 包括服务器，数据库，网络设备等----来帮助客户决定系统的配置。

LoadRunner 通过它的AutoLoad 技术，为您提供更多的测试灵活性。使用AutoLoad ，您可以根据目前的用户人数事先设定测试目标，优化测试流程。例如，您的目标可以是确定您的应用系统承受的每秒点击数或每秒的交易量。

定位性能问题

LoadRunner 内含集成的实时监测器，在负载测试过程的任何时候，您都可以观察到应用系统的运行性能。这些性能监测器为您实时显示交易性能数据（如响应时间）和其它系统组件包括application server， web server，网路设备和数据库等的实时性能。这样，您就可以在测试过程中从客户和服务器的双方面评估这些系统组件的运行性能，从而更快地发现问题。

再者，利用LoadRunner 的ContentCheck TM ，您可以判断负载下的应用程序功能正常与否。ContentCheck 在Virtual users 运行时，检测应用程序的网络数据包内容，从中确定是否有错误内容传送出去。它的实时浏览器帮助您从终端用户角度观察程序性能状况。

楠族开心果

让loadrunner走下神坛

无疑是一个强大有力的压力测试工具。它的脚本可以录制生成，自动关联;测试场景可以面向指标，多方监控;测试结果图表显示，拆分组合。相信有人这样想象过：拿着一张性能指标标准列表和测试数据相比较，如同PH试纸一样，遇碱则蓝，遇酸则红，一目了然，之后就可以大声地喊道：我找到了软件系统的性能瓶颈！

然而，我们无论在loadrunner前面加多少个“强大”、“智能”的形容词，别忘了其最终修饰的只是一个名词-“工具”。《大话西游》中也有相当精辟的论断：官兵？最多也只是个长了痔疮的官兵！把loadrunner比喻成长了痔疮的官兵有点粗俗，但loadrunner它是个工具，那么是否能够找到性能瓶颈就取决于使用工具的人，而不是工具本身。要做一个成功的性能测试，仅读懂和精通了loadrunner的使用手册是不够的，还需要对被测软件系统的方方面面都要有了解，比如软件体系构架，网络拓扑等知识。这就如同一个技艺高超的木匠，并不是因为他背熟了凿子，锤子的说明书，而是他能结合木材的质地和尺寸，用凿子和锤子这些工具做出一把精巧的椅子来。那么在性能测试中，人的智慧活动体现在哪里呢？

一、首先性能测试也是测试的一种，这就意味着做性能测试也要写测试案例。你所作的性能测试能不能足以支持找出性能测试瓶颈，和你在初期设计的测试案例关系甚为重要。我曾写过对一个软件系统的不下十个性能测试场景案例，等后来运行时却发现我必须增补几个案例才能找到瓶颈，而原来十多个案例其实重复甚多。如果你要写出好的不重复的性能测试案例来，你就得对被测软件系统有一定的了解。

在这里，我顺便插一句，在目前测试界总在争论测试人员需不需要懂编程，需不需要有开发经验这种问题，这完全是本末倒置，忘记了测试人员的目标是什么，测试目标就是写出好的测试案例，好的测试案例就是发现了一个原来未曾发现的软件bug。那么一个测试人员知识体系是否够用的标准就是能不能写出一个好的测试案例。而针对不同类型的测试，所需的知识深度是不一样的，有的是不需编程知识，比如界面测试;有的是必须有开发经验的，比如接口测试，不能一概而论。

对于性能测试来讲，我个人认为，测试人员倒不一定非要有开发经验，但是应该有一个对软件体系结构了解全面的知识。为什么呢？做性能测试时，如果从客户端施压一次就符合性能指标，碰到这种情况您就偷着乐吧，因为在你的指标场景下，软件系统中就不存在性能瓶颈，您也就不用费心去找了。但是大多数情况下，我们在做性能测试时，都不能顺利达到性能指标，可能server响应超时了，也可能是用户死掉了，在日志里抛出了一堆error，这种情形是非常常见，所以在我们在一开始设计性能测试方案时，就应该考虑为寻找性能瓶颈而设计测试案例。这时我们就需要知道在整个软件系统中，有哪些节点，在哪些地方可能存在瓶颈，比如一个B/S系统就有IE client→物理网络→web server→app server→DB这样的一个压力流串。每个节点的每个模块都有可能成为瓶颈。瓶颈的产生可能由于模块配置引起，也可能由于模块本身引起。这都需要我们设计测试案例来发现的。一般地，我自己常用的感觉也比较方便的方法是，设计一组性能测试案例来验证一个节点是否存在瓶颈，这组case中尽量保持其他节点不变，来改变这个节点的配置，并监控此节点的各种指标。这里说起来就有很多话了，不是一言两语能说得清的。以后有时间可以找个专题来慢慢跟大家讨论。

二、使用loadrunner的VU生成脚本。脚本的生成方式就两种，一种是自写或嵌入源代码，一种是录制生成。常常听见有人说，这两种方式中首选录制生成脚本，因为它简单且智能化。但我个人总觉得手写脚本要好一些，因为：

1 。可读性好，流程清晰，检查点截取含义明确。业务级的代码读起来总比协议级的代码更易让人理解，也更容易维护，必要时可建立一个脚本库。而录制生成的代码大多没有维护的价值，现炒现卖。

2 。手写的程序相比录制的脚本更能真实地模拟应用运行。因为录制的脚本是截获了网络包，生成了协议级的代码，而略掉了client端的处理逻辑。举个例子，用VU录制一个运行script和applet的IE行为，它只会生成http协议的API，在IE中运行的applet和script不会被模拟到，这就不是一个完整的系统。

3 。手写程序相比录制脚本更能增加测试人员的技术含量。开发和测试能力双重提高，何乐而不为呢？loadrunner提供了java user，vb user，c user等语言类型的脚本，就是给我们开发脚本用的，而不是录制用的。

脚本不管录制也好，还是手写也好，选择的时候应该以脚本模拟程序真实有效为准，结合项目进度，开发难易程度等因素考虑。

在这里我想要说的是，开发一个好的脚本是成功性能测试的必要条件。一个好的脚本应该能够最大程度再现client程序行为。如上面那个例子，脚本只模拟了client端的部分行为，有一些没有模拟到，那么client的瓶颈就有可能被忽略了。我曾吃过一个亏，自己写了一个java socket脚本去联server，但是忽略了client端的界面下的业务逻辑，用我的脚本做性能测试通过，全部OK，但是真实用户一上线，client终端界面接受了大量的server信息，导致client进程死掉了。痛哉，痛哉。

三、组建并执行性能测试场景。

从VU运行成功到controller运行成功，一般需要以下几个步骤（我也是从英文论坛上看到的，觉得不错，拿出来共享）：

1. 确认在VU里SUSI（单用户单循环次数single user & single iteration）

2. 确认在VU里SUMI（单用户多循环次数single user & multi iteration）

3. 确认在controller中MUSI（多用户单循环次数multi user & single iteration）

4. 确认在controller中MUMI（多用户多循环次数 multi user & multi iteration）

做这样一个步骤划分是有道理的，第一步骤是验证脚本编写的正确，第二步骤可以验证数据池是否正常运作。第三步骤验证并发功能，第四步骤是最终目的，验证软件系统的性能。在论坛上看到一些朋友提的问题，有一些就是于此的，在controller中运行场景时出现问题，首先得保证VU中运行成功，这是一个显然的逻辑。软件工程中把软件开发的种种行为都要制定一个proccess，即过程，性能测试也是如此，按照过程来调试脚本和场景，能及早发现问题和定位问题。除非是高手，烂熟于心中，才能超越proccess而不出问题。

场景是把虚拟用户和交易数按一定规则组织起来去模拟真实世界的业务行为。这其实是把单个用户的行为复制，连接。场景的组织通常和真实世界的业务规则有很大关系。

做个如下可能并不恰当的比喻：

脚本像演员，场景就像表演的舞台，而测试工程师是导演，多少个演员，怎么在舞台上演出，都由导演说了算，而剧情又不能离谱，脱离现实，否则就要砸锅了。注意，导演的职责不光是确保演出能顺利结束，而且还要同时观察和收集观众的反馈信息，以确认这次演出是否成功。

同样的也是，性能测试人员不光是看场景是否得到顺利的执行，同时还要收集各个server的反馈信息，以确认软件系统的性能表现是否正常。

在真实世界中的用户业务规则要转换到可操作的性能指标是需要分析和计算的。当然这通常是市场需求分析人员干的活，但我觉得测试人员应该在做性能测试时，对这些指标进行理解，知道为什么要这样做。有时有的性能指标并不清楚和准确，还需要测试人员来分析。比如一个性能指标：要求软件系统支持每分钟700用户的登陆行为。这对于测试人员来说，其实是一个不确切的性能需求。这指的是瞬时并发用户700，在一分钟的响应时间要求下登陆系统？还是在一分钟内陆续有700个用户登入软件系统即可？这两种场景其实对软件系统的压力是不同的，第一种显然大，第二种要小一些。甚至有的性能需求就是支持50000注册用户，这种需求就更需要分析了，还要引入一些业务发生概率算法模型来做。这已经不是性能测试人员的职责了，但由于目前有不少软件公司流程不规范，或者有流程没执行，这些工作都要测试人员来做了，不过也好，正好是锻炼的机会。

四、分析结果数据，找到软件系统性能瓶颈

上面说了，做了那么多，就是为了本步骤-寻找软件系统性能瓶颈。

个人认为寻找性能瓶颈是一个非常有挑战性的工作，毛主席曾经说过：一个优秀的指战员就是能够根据已有的客观形势，制定作战计划，然后在作战过程中，发现计划与执行不符的地方，分析，然后调整作战计划，缩小计划和战势的误差。简明一句：就是一个理论和实践结合的过程，一个人的主观思想和客观现实的结合过程（注明：本人是毛主席老人家的忠实fans）。

在性能测试中，测试方案就是我们的作战计划，执行性能测试就是我们的作战战场。在性能测试中，可能会发现种种意想不到的问题。当然一个经验足够丰富的性能测试专家可能会在测试之前就能考虑全面，使测试方案吻合测试执行实际情况，并一举找出性能瓶颈。我sunshinelius不是专家水平，当然就要匆忙应对和分析性能测试中出现的问题，并有可能会修改测试方案，增加必要的test case，删除没用的test case。总之，性能测试是一个不断修改测试方案，反复执行test case的过程，直至越来越逼近性能瓶颈。在此过程中，需要了解很多的知识，知识了解得越多，就越接近软件系统运行的真相，也就能找出性能瓶颈了。

比如：loadrunner要是调用程序员的程序，服务器资源占用情况可能是追查瓶颈的一个线索，但如果是标准中间件，那就没那么简单了，比如oracle数据库的某项参数设得不对，照样会造成数据库瓶颈，应用程序调用数据库的API写法不对，比如未使用软解析变量，也有可能导致数据库瓶颈。这些瓶颈都不会反映在cpu，内存使用量上等指标上的。

对于这种情况，一方面需要对中间件有一定的了解，知道哪些参数有什么作用，怎么可调的，另外还可能使用中间件的专有监测工具，来分析。lr的性能计数器是不够用的。

个人体会，查找瓶颈的难易程度，由易到难

服务器硬件瓶颈-〉网络瓶颈-〉应用瓶颈-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）

记忆比较深刻的一次，用lr做了两天性能测试，指标上不去，后来使用oracle数据库的图形化性能检测工具才发现某个表的查询处理时间超长，原来索引创建得不合理，把表的索引改了之后，性能稍有提高，但还是上不去。再次排查，发现应用中有一个sql语句写得有问题，长而且耗时，改了之后，测试指标还是上不去

经过至少四轮的排查，才大功告成，最后一个除掉的瓶颈是操作系统问题（开始没有想到它，后来看系统消息，才发现已经有错误报出）

五、每个系统的性能测试都是一个全新的挑战！

愚人

开心果要将考试进行到底了……