基本进度计划要说明哪些工作必须于何时完成和完成每一任务所需要的时间，但最好同时也能表示出每项活动所需要的人数。常用的制定进度计划的方法有以下几种：

①关键日期表

这是最简单的一种进度计划表，它只列出一些关键活动和进行的日期。

②甘特图

也叫做线条图或横道图。它是以横线来表示每项活动的起止时间。甘特图的优点是简单、明了、直观，易于编制，因此到目前为止仍然是小型项目中常用的工具。即使在大型工程项目中，它也是高级管理层了解全局、基层安排进度时有用的工具。

在甘特图上，可以看出各项活动的开始和终了时间。在绘制各项活动的起止时间时，也考虑它们的先后顺序。但各项活动上间的关系却没有表示出来，同时也没有指出影响项目寿命周期的关键所在。因此，对于复杂的项目来说，甘特图就显得不足以适应。

③关键路线法（Critical Path Method，简称CPM）。

④计划评审技术（Program Evaluation and Review Technique，简称PERT）。

CPM 和PERT是50年代后期几乎同时出现的两种计划方法。随着科学技术和生产的迅速发展，出现了许多庞大而复杂的科研和工程项日，它们工序繁多，协作面广，常常需要动用大量人力、物力、财力。因此，如何合理而有效地把它们组织起来，使之相互协调，在有限资源下，以最短的时间和最低费用，最好地完成整个项目就成为一个突出的重要问题。CPM和PERT就是在这种背景下出现的。这两种计划方法是分别独立发展起来的，但其基本原理是一致的，即用网络图来表达项目中各项活动的进度和它们之间的相互关系，并在此基础上，进行网络分析，计算网络中各项时间多数，确定关键活动与关键路线，利用时差不断地调整与优化网络，以求得最短周期。然后，还可将成本与资源问题考虑进去，以求得综合优化的项目计划方案。因这两种方法都是通过网络图和相应的计算来反映整个项目的全貌，所以又叫做网络计划技术。

此外，后来还陆续提出了一些新的网络技术，如GERT（Graphical Evaluation and Review Technique，图示评审技术），VERT（Venture Evaluation and Review Technique，风险评审技术）等。

很显然，采用以上几种不同的进度计划方法本身所需的时间和费用是不同的。关键日期表编制时间最短，费用最低。甘特图所需时间要长一些，费用也高一些。CPM要把每个活动都加以分析，如活动数目较多，还需用计算机求出总工期和关键路线，因此花费的时间和费用将更多。PERT法可以说是制订项目进度计划方法中最复杂的一种，所以花费时间和费用也最多。

应该采用哪一种进度计划方法，主要应考虑下列因素：

①项目的规模大小。很显然，小项目应采用简单的进度计划方法，大项目为了保证按期按质达到项目目标，就需考虑用较复杂的进度计划方法。

②项目的复杂程度。这里应该注意到，项目的规模并不一定总是与项目的复杂程度成正比。例如修一条公路，规模虽然不小，但并不太复杂，可以用较简单的进度计划方法。而研制一个小型的电子仪器，要很复杂的步骤和很多专业知识，可能就需要较复杂的进度计划方法。

③项目的紧急性。在项目急需进行，特别是在开始阶段，需要对各项工作发布指示，以便尽早开始工作，此时，如果用很长时间去编制进度计划，就会延误时间。

④对项目细节掌握的程度。如果在开始阶段项目的细节无法解明，CPM和PERT法就无法应用。

⑤总进度是否由一、两项关键事项所决定。如果项目进行过程中有一、两项活动需要花费很长时间，而这期间可把其他准备工作都安排好，那么对其他工作就不必编制详细复杂的进度计划了。

⑥有无相应的技术力量和设备。例如，没有计算机，CPM和PERT进度计划方法有时就难以应用。而如果没有受过良好训练的合格的技术人员，也无法胜任用复杂的方法编制进度计划。

此外，根据情况不同，还需考虑客户的要求，能够用在进度计划上的预算等因素。到底采用哪一种方法来编制进度计划，要全面考虑以上各个因素。

软件开发项目过程中的风险管理研究[1]

软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。软件项目风险会影响项目计划的实现，如果项目风险变成现实，就有可能影响项目的进度，增加项目的成本，甚至使软件项目不能实现。如果对项目进行风险管理，就可以最大限度的减少风险的发生。但是，目前国内的软件企业不太关心软件项目的风险管理，结果造成软件项目经常性的延期、超过预算，甚至失败。成功的项目管理一般都对项目风险进行了良好的管理。因此任何一个系统开发项目都应将风险管理作为软件项目管理的重要内容。

　　在项目风险管理中，存在多种风险管理方法与工具，软件项目管理只有找出最适合自己的方法与工具并应用到风险管理中，才能尽量减少软件项目风险，促进项目的成功。

　　项目风险管理

　　项目风险管理是指为了最好的达到项目的目标，识别、分配、应对项目生命周期内风险的科学与艺术。项目风险管理的目标是使潜在机会或回报最大化，使潜在风险最小化。风险管理涉及的主要过程包括：风险识别，风险量化，风险应对计划制定和风险监控，如图1所示。风险识别在项目的开始时就要进行，并在项目执行中不断进行。就是说，在项目的整个生?

（1）需求风险

　　①需求已经成为项目基准，但需求还在继续变化；

　　②需求定义欠佳，而进一步的定义会扩展项目范畴；

　　③添加额外的需求；

　　④产品定义含混的部分比预期需要更多的时间；

　　⑤在做需求中客户参与不够；

　　⑥缺少有效的需求变化管理过程。

　　（2）计划编制风险

　　①计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；

　　②计划是优化的，是"最佳状态"，但计划不现实，只能算是"期望状态"；

　　③计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上；

　　④产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大；

　　⑤完成目标日期提前，但没有相应地调整产品范围或可用资源；

　　⑥涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。

　　（3）组织和管理风险

　　①仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长；

　　②低效的项目组结构降低生产率；

　　③管理层审查决策的周期比预期的时间长；

　　④预算削减，打乱项目计划；

　　⑤管理层作出了打击项目组织积极性的决定；

　　⑥缺乏必要的规范，导致工作失误与重复工作；

　　⑦非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。

　　（4）人员风险

　　①作为先决条件的任务(如培训及其他项目)不能按时完成；

　　②开发人员和管理层之间关系不佳，导致决策缓慢，影响全局；

　　③缺乏激励措施，士气低下，降低了生产能力；

　　④某些人员需要更多的时间适应还不熟悉的软件工具和环境；

　　⑤项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低；

　　⑥由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；

　　⑦不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性；

　　⑧没有找到项目急需的具有特定技能的人。

（5）开发环境风险

　　①设施未及时到位；

　　②设施虽到位，但不配套，如没有电话、网线、办公用品等；

　　③设施拥挤、杂乱或者破损；

　　④开发工具未及时到位；

　　⑤开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具；

　　⑥新的开发工具的学习期比预期的长，内容繁多。

　　（6）客户风险

　　①客户对于最后交付的产品不满意，要求重新设计和重做；

　　②客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做；

　　③客户对规划、原型和规格的审核决策周期比预期的要长；

　　④客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更；

　　⑤客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长；

　　⑥客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。

　　（7）产品风险

　　①矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作；

　　②开发额外的不需要的功能(镀金)，延长了计划进度；

　　③严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；

　　④要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作；

　　⑤在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题；

　　⑥开发一种全新的模块将比预期花费更长的时间；

　　⑦依赖正在开发中的技术将延长计划进度。

　　（8）设计和实现风险

　　①设计质量低下，导致重复设计；

    一、质量需求或产品的特性理解不准确，造成测试范围分析的误差，结果某些地方始终测试不到或验证的标准不对；
    二、测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏；
    三、需求的临时/突然变化，导致设计的修改和代码的重写，测试时间不够；
    四、质量标准不都是很清晰的，如适用性的测试，仁者见仁、智者见智；
    五、测试用例设计不到位，忽视了一些边界条件、深层次的逻辑、用户场景等；
    六、测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差；
    七、有些缺陷出现频率不是百分之百，不容易被发现；如果代码质量差，软件缺陷很多，被漏检的缺陷可能性就大；
    八、回归测试一般不运行全部测试用例，是有选择性的执行，必然带来风险。

    前面三种风险是可以避免的，而四至七的四种风险是不能避免的，可以降到最低。最后一种回归测试风险是可以避免，但出于时间或成本的考虑，一般也是存在的。
    针对上述软件测试的风险，有一些有效的测试风险控制方法，如：

    ·测试环境不对可以通过事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查； 
    ·有些测试风险可能带来的后果非常严重，能否将它转化为其他一些不会引起严重后果的低风险。如产品发布前夕，在某个不是很重要的新功能上发现一个严重的缺陷，如果修正这个缺陷，很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大，对策是去掉(Diasble)那个新功能，转移这种风险； 
    ·有些风险不可避免，就设法降低风险，如“程序中未发现的缺陷”这种风险总是存在，我们就要通过提高测试用例的覆盖率（如达到99.9%）来降低这种风险；

    为了避免、转移或降低风险，事先要做好风险管理计划和控制风险的策略，并对风险的处理还要制定一些应急的、有效的处理方案，如：

    ·在做资源、时间、成本等估算时，要留有余地，不要用到100%； 
    ·在项目开始前，把一些环节或边界上的可能会有变化、难以控制的因素列入风险管理计划中； 
    ·对每个关键性技术人员培养后备人员，作好人员流动的准备，采取一些措施确保人员一旦离开公司，    项目不会受到严重影响，仍能可以继续下去； 
    ·制定文档标准，并建立一种机制，保证文档及时产生； 
    ·对所有工作多进行互相审查，及时发现问题，包括对不同的测试人员在不同的测试模块上相互调换； 
    ·对所有过程进行日常跟踪，及时发现风险出现的征兆，避免风险。

    要想真正回避风险，就必须彻底改变测试项目的管理方式；针对测试的各种风险，建立一种“防患于未然”或“以预防为主”的管理意识。与传统的软件测试相比，全过程测试管理方式不仅可以有效降低产品的质量风险，而且还可以提前对软件产品缺陷进行规避、缩短对缺陷的反馈周期和整个项目的测试周期。

由于WR没有定时自动运行脚本 的功能，但与TD结合便可以实现。使用的WR版本为7.0，具体实现如下：

1、设置WR与TD连接。

 1.1启动WR，在settings-->general options菜单下的environment中勾选"Allow TestDirector to run tests remotely"，之后保存。

 1.2选择菜单功能tools-->TestDirector Connection,进行设置，指定TD服务器，连接指定的project。具体设置如图

2、TD相关操作

 2.1下载XRunnerTestDirector.exe插件。

 2.2登陆TD，在test plan页面中新加一个测试 用例，修改type为WR-AUTOMATED.之后点到test scrīpt页签，点击copy from，选择脚本，导入。脚本就成功的导入了。其中脚本调用了其它两个子脚本，WR会跟据所指路径自动去读取，并且在脚本中已添加了加载map的语句。

 2.3切到test lab页面，新建test,然后执行"Add Tests to Test Set"功能如图wrltd6.jpg

添加刚才test plan中指定的test.添加成功后如图wrltd7.jpg

 2.4设置执行时间。见图wrltd7.jpg切到Execution Flow页签，设置时间。如图wrltd5.jpg.

 2.5点击wrltd5.JPg中的RUN按钮，弹出窗口"Execution of...窗口",点击run按钮,所有操作到这儿就完成了.如图wrltd6.jpg所示状态，脚本处于等待状态，等到设定的时间，TD会自动打开WR程序，并开始执行脚本。

　　第一步：把需要加到共享对象库中的各个用例脚本的对象库，分别导出成．tsr文件．

　　操作方法:先用QTP打开已经录制完毕的脚本后，选择Resources－－＞ Object Repository ．

　　然后file-->export....取名导出文件．如下图：

　　第二步：把需要加入到共享对象库中的各个用例脚本的对象库，合并对象及对象属性，形成一个大的共享对象库．

　　操作方法:打开Resources－－＞Object Repository Manager．找到Tools菜单，然后选择打开Object Repository merge tool.选择两个要合并的对象库文件，进行对象合并．一次只能合并两个．所以如果这里你要合并多个对象库文件的话，先合并两个后，保存成一个新的．tsr文件．然后再重复上面的操作，选择这个新的．tsr文件和另一个准备好的对象库合并．如下图：

　　合并的时候，你会发现，在两个对象库文件中，相同的对象合并成一个，不同的对象，全部被完整增加进去．然后形成一个大的对象库．现在只要保存这个共享对象库．如果以后有新增的对象，可以重复上述操作．

　　第三步：调用上面保存好的共享对象库．给新的脚本使用．

　　操作步骤：Resources－－＞Associate Repository．选择上面保存好的共享对象库的．tsr文件．加入到Associate Repository中．如下图：

　　完成这一步后，其实整个共享对象库的操作已经完成．你在对象库中可以看到以后的对象．在录制新脚本的时候，如果对象已经存在，就不会再被记录，只有在这个对象库中没有的对象才会被记录进去．回放脚本，对象识别成功．

（注：此操作只适合与装有QTP9.0的版本．对于8.2版本不适合）

附：8.2版本中的共享对象库操作

目的

本工具向导说明了如何在 Rational Robot^TM 中设置测试环境。

相关的 Rational Unified Process 活动：

• 活动：实施测试中的“记录或通过编程创建测试脚本”部分
• 活动：执行测试中的“执行测试过程和/或测试脚本”部分

概述

本工具向导适用于 Microsoft Windows 95/98/NT 4.0。

要使用 Robot 来设置测试环境，请执行以下步骤：

1. 设置测试环境以进行记录、编辑或测试脚本回放。
2. 设置 GUI 脚本记录选项。
3. 设置 GUI 脚本回放选项。

1. 设置测试环境以进行记录、编辑或测试脚本回放

Windows 环境和您所测试的应用程序的状态会影响脚本的回放。如果所记录的环境和回放环境之间存在差异，回放就会出现问题。

在记录或编辑测试脚本之前，确保您所测试的应用程序和所有其他软件（在测试环境中）都处于适当的初始状态。另外，在执行测试（回放测试脚本）之前，请保证所测试的应用程序和所有其他软件都处于记录/编辑该测试脚本时所处的初始状态。当您开始回放脚本时，记录脚本时处于打开、激活或显示状态的所有应用程序和窗口应该仍处于打开、激活或显示状态。此外，确保所有相关的网络设置、现用数据库和系统内存处于同记录脚本时相同的状态。

回放测试脚本时，确保您设置了适当的回放选项，其中包括 Robot 应该如何处理意外活动窗口以及如何从脚本命令错误中恢复（请参见下一部分）。

2. 设置 GUI 脚本记录选项

GUI 脚本记录选项指示 Robot 在记录测试脚本时，应如何处理某些对象、鼠标拖动、窗口设置、对象内容和 Robot 窗口。

要设置 GUI 脚本记录选项，请执行以下步骤：

1. 执行以下操作之一来显示 GUI Record Options 对话框：

• 开始记录之前，请单击 Tools > GUI Record Options。
• 单击工具栏上的 Record Script 按钮，开始记录。在 Record 对话框中，单击 Options。

2. 设置每个选项卡上的选项。有关各选项卡的详细信息，请参见 Using Rational Robot 手册中的 Setting GUI Record Options 一章或参见 Robot 联机帮助。

General - 指定 Robot 如何确定/识别列表和菜单内容，以及不支持的鼠标拖动。另外，在此选项卡中，您还可以指定：用于脚本自动命名的前缀、是否让 Robot 来保存和恢复活动窗口的大小和位置、是否记录思考时间、是否记录按下回车键后的延迟。Robot Window - 指定记录测试脚本时 Robot 窗口的显示方式。该选项卡还使用户可以指定热键，用来隐藏/重新显示 Robot 窗口，以及在面向对象的记录模式和低层记录模式之间进行切换。Object Recognition Order - 用于在记录之前或记录过程中，改变个别对象类型的对象识别方法优先级。

有关如何记录脚本的详细信息，请参见工具向导：使用 Rational Robot™ 创建测试脚本。

3. 设置 GUI 脚本回放选项

GUI 脚本回放选项指示 Robot 如何回放 GUI 脚本。您既可以在回放之前，也可以在回放过程开始时设置这些选项。

要设置 GUI 回放选项，请执行以下步骤：

1. 执行以下操作之一来显示 GUI Playback Options 对话框：

• 开始回放之前，请单击 Tools > GUI Playback Options。
• 单击工具栏上的 Playback Script 按钮，开始回放。在 Playback 对话框中，单击 Options。

2. 设置每个选项卡上的选项。有关各选项卡的详细信息，请参见 Using Rational Robot 手册中的 Setting GUI Playback Options 一章或参见 Robot 联机帮助。

   Playback - 指定命令和击键之间的延迟、是否使用记录的思考时间和键入延迟、是否跳过核实点、是否显示确认结果对话框，以及回放过程中 Robot 窗口中出现的内容。有关详细信息，请单击对话框中的 Help 按钮。Log - 指定日志中保存的结果、回放后是否显示日志、是否要在覆盖日志之前得到提示、以及是使用默认日志信息还是使用您提供的信息。

   Caption Matching - 指定 Robot 如何匹配记录过程中所记录的窗口标题和回放过程中发现的标题。有关详细信息，请单击对话框中的 Help 按钮。

   Wait State

   - 指定回放时的默认重试和超时值。

   Unexpected Active Windows

   - 指定 Robot 应该如何响应意外的活动窗口。

   Error Recovery

   - 指定在脚本回放时，Robot 如何从脚本命令错误和核实点故障中恢复。

   Trap

   - 指定 Trap 实用程序应该记录的有关回放过程中常见保护故障的信息和恢复方法。
3. 单击 OK。

   有关如何回放脚本的详细信息，请参见工具向导：使用 Rational Robot™ 执行测试。

　　需求定义（Specify Requirements）：分析应用程序并确定测试需求。

　　测试计划（Plan Tests）：基于测试需求，建立测试计划。

　　测试执行（Execute Tests）：创建测试集（Test Set）并执行测试。

　　缺陷跟踪（Track Defects）：报告程序中产生的缺陷并跟踪缺陷修复的全过程。

　　贯穿测试的每一个阶段，你能够通过产生详细的报告和图标对数据进行分析。

1.2需求定义（Specify Requirements）
　　分析应用程序并确定测试需求。

　　定义测试范围（Define Testing Scope）：检查应用程序文档，并确定测试范围——测试目的、目标和策略。

　　创建需求（Create Requirements）：创建需求树（Requirements Tree），并确定它涵盖所有的测试需求。

　　描述需求（Detail Requirements）：为“需求树”中的每一个需求主题建立了一个详细的目录，并描述每一个需求，给它分配一个优先级，如有必要的话还可以加上附件。

　　分析需求（Analyze Requirements）：产生报告和图表来帮助你分析测试需求，并检查需求以确保它们在你的测试范围内。

1.3测试计划（Planning Tests）
　　基于已定义的测试需求，创建相应的测试计划。

　　定义测试策略（Define Testing Strategy）：检查应用程序、系统环境和测试资源，并确认测试目标。

　　定义测试主题（Define Test Subject）：将应用程序基于模块和功能进行划分，并对应到各个测试单元或主题，构建测试计划树（Test Plan Tree）。

　　定义测试（Define Tests）：定义每个模块的测试类型，并为每一个测试添加基本的说明。

　　创建需求覆盖（Create Requirements Coverage）：将每一个测试与测试需求进行连接。

　　设计测试步骤（Design Test Steps）：对于每一个测试，先决定其要进行的测试类型（手动测试和自动测试），若准备进行手动测试，需要为其在测试计划树上添加相应的测试步骤（Test Steps）。测试步骤描述测试的详细操作、检查点和每个测试的预期结果。

　　自动测试（Automate Tests）：对于要进行自动测试的部分，应该利用MI、自己或第三方的测试工具来创建测试脚本。

　　分析测试计划（Analyze Test Plan）：产生报告和图表来帮助你分析测试计划数据，并检查所有测试以确保它们满足你的测试目标。

1.4测试执行（Running Tests）
　　创建测试集（Test Set）并执行测试。

　　创建测试集（Create Test Sets）：在你的工程中定义不同的测试组来达到各种不同的测试目标，他们可能包括，举个例子，在一个应用程序中测试一个新的应用版本或是一个特殊的功能。并确定每个测试集都包括了哪些测试。

　　确定进度表（Schedule Runs）：为测试执行制定时间表，并为测试员分配任务。

　　运行测试（Run Tests）：自动或手动执行每一个测试集。

　　分析测试结果（Analyze Test Results）：查看测试结果并确保应用程序缺陷已经被发现。生成的报告和图表可以帮助你分析这些结果。

1.5缺陷跟踪（Tracking Defects）
　　报告程序中产生的缺陷并跟踪缺陷修复的全过程。

        添加缺陷（Add Defects）：报告程序测试中发现的新的缺陷。在测试过程中的任何阶段，质量保证人员、开发者、项目经理和最终用户都能添加缺陷。

　　检查新缺陷（Review New Defects）：检查新的缺陷，并确定哪些缺陷应该被修复。

　　修复打开的缺陷（Repair Open Defects）：修复那些你决定要修复的缺陷。

　　测试新构建（Test New Build）：测试应用程序的新构建，重复上面的过程，直到缺陷被修复。

　　分析缺陷数据（Analyze Defect Data）：产生报告和图表来帮助你分析缺陷修复过程，并帮助你决定什么时候发布该产品。

Mercury Quality Center™ 提供了基于 Web 的系统，可在广泛的应用环境下自动执行软件质量测试和管理。仪表盘技术使您可以了解验证功能和将业务流程自动化，并确定生产中阻碍业务成果的瓶颈。Mercury Quality Center 使 IT 团队能够在开发流程完成前就参与应用程序测试。这样将缩短发布时间表，同时确保最高水平的质量。

利用 Mercury Quality Center，您可以：

Mercury Quality Center 产品

Mercury Quality Center 包括自动化软件测试产品，例如 Mercury TestDirector®、Mercury QuickTest Professional™、Mercury WinRunner™、Mercury Business Process Testing™ 和 Mercury Service Test™。Mercury Quality Center 还提供了基于最佳实践的服务，用于内部部署或通过我们的 Mercury Managed Services 进行部署。

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

Software Trial	Download	||
Mercury QuickTest Professional Web Services Add-in
Mercury Diagnostics Profiler for .NET
Mercury TestDirector for Quality Center Starter Edition
Mercury QuickTest Professional for VisualAge Evaluation
Mercury QuickTest Professional for Stingray Evaluation
Mercury QuickTest Professional for Peoplesoft Evaluation
Mercury QuickTest Professional for Java Evaluation
Mercury QuickTest Professional for Oracle Evaluation
Mercury QuickTest Professional for .Net Evaluation
Mercury QuickTest Professional for SAP Evaluation
Mercury QuickTest Professional Terminal Emulator Add-in Evaluation
Mercury QuickTest Professional for Siebel Evaluation
Introduction to Quality Center 8.0 - Using TestDirector: Computer-Based Training (CBT) Course
Introduction to QuickTest Professional 8.0 Computer-Based Training (CBT) Course
Mercury QuickTest Professional Free 14-Day Trial

正则表达式语法

通过正则表达式，QuickTest 可以使用不同的值来标识对象和文本字符串。可以在下列三种情况下使用正则表达式：一是定义对象属性和参数方法时；二是对某步骤进行参数化时；三是使用不同值创建检查点时。

正则表达式是指定复杂搜索短语的字符串。使用特殊字符，如句点 (.)、星号 (*)、插字号 (^) 和方括号 ([ ])，可以定义搜索条件。有关正则表达式语法的详细信息，请参阅《QuickTest Professional 用户指南》。

使用正则表达式

在本教程中，将针对一个日期文本字符串创建文本检查点，该字符串随选定的航班日期而变化。可以将该日期定义为正则表达式，这样，检查点将检查捕获的文本字符串是否与期望的格式匹配，而不是检查准确的文本。

为此，您将使用一个正则表达式创建文本检查点，该表达式将与已定义范围内的某一单个字符相匹配。

启动 QuickTest 并打开“Recording”测试。

如果 QuickTest 尚未打开，请选择“开始”>“程序”>“QuickTest Professional”>“QuickTest Professional”。

如果“欢迎使用”窗口打开，请单击“打开现有测试”。
如果 QuickTest 打开时未显示“欢迎使用”窗口，请选择
“文件”>“打开”，或单击“打开”按钮 。

在“打开测试”对话框中，找到并选择“Recording”测试，然后单击“打开”。

将该测试另存为“RegExpression”。

选择“文件”>“另存为”。将该测试另存为“RegExpression”。

确认是否已启用“Active Screen”选项。

如果在 QuickTest 窗口底部看不到 Active Screen，请单击“Active Screen”按钮或选择“查看”>“Active Screen”。

选择要为其创建检查点的文本。

在关键字视图中，单击 (+) 展开“Welcome:Mercury:Tours”，然后单击“Select a Flight:Mercury”页。该页将显示在 Active Screen 中。

在 Active Screen 中向上滚动，然后突出显示出发航班 New York to San Francisco (12/29/2004)。右键单击突出显示的字符串，然后选择“插入文本检查点”。将打开“文本检查点属性”对话框。

对于要检查的文本，输入正则表达式。

在“已检查的文本”区域中，单击“常量值选项”按钮 。将打开“常量值选项”对话框。





在“值”框中，用 [0-1][0-9]/[0-3][0-9]/200[0-9] 替换当前日期。这将指示 QuickTest 检查选定文本中的每个字符与正则表达式定义的数字范围格式是否匹配。该表达式检查以下格式：MM/DD/200Y。

选择“正则表达式”复选框。将出现一个消息框，提示您在每个特殊字符之前插入反斜杠字符。单击“否”。

注意： 单击“是”会使 QuickTest 将特殊字符 ([)、(-) 和 (]) 作为文本字符而不是正则表达式处理。

单击“确定”接受其他默认设置，然后关闭“常量值选项”对话框。将打开“文本检查点属性”对话框。





单击“确定”关闭“文本检查点属性”对话框。

QuickTest 将向您的测试中添加文本检查点。该检查点在关键字视图中的“Select a Flight:Mercury”页显示为检查操作。

保存测试。

选择“文件”>“保存”，或单击“保存”按钮 。

使用正则表达式运行并分析测试

在本练习中，您将运行测试并对检查点结果进行检查。

运行“RegExpression”测试。

单击“运行”按钮 ，或选择“测试”>“运行”。将打开“运行”对话框。

选择“新建运行结果文件夹”并接受默认的结果文件夹名。

单击“确定”。当完成测试运行时，将打开“测试结果”窗口。

对检查点结果进行检查。

在结果树中，单击 (+) 展开“Test RegExpression Summary”>“RegExpression Iteration 1 (Row 1)”>“Action1 Summary”>“Welcome: Mercury Tours”>“Select a Flight:Mercury”

选择“检查点`[0-1][0-9]/[0-3][0-9]/200[0-9]'”。





由于文本以正则表达式指定的格式显示，因此该检查点通过。

退出“测试结果”窗口。

选择“文件”>“退出”关闭“测试结果”窗口。

软件开发和使用的历史已经留给了我们很多由于软件缺陷而导致的巨大财力、物力损失的经验教训。这些经验教训迫使我们这些测试工程师们必须采取强有力的检测措施来检测未发现的隐藏的软件缺陷。

生产软件的最终目的是为了满足客户需求，我们以客户需求作为评判软件质量的标准，认为软件缺陷（ Software Bug ）的具体含义包括下面几个因素：

•  软件未达到客户需求的功能和性能；

•  软件超出客户需求的范围；

•  软件出现客户需求不能容忍的错误；

•  软件的使用未能符合客户的习惯和工作环境。

考虑到设计等方面的因素，我们还可以认为软件缺陷还可以包括软件设计不符合规范，未能在特定的条件（资金、范围等）达到最佳等。可惜的是，我们中的很多人更倾向于把软件缺陷看成运行时出现问题上来，认为软件测试仅限于程序提交之后。

在目前的国内环境下，我们几乎看不到完整准确的客户需求说明书，加以客户的需求时时在变，追求完美的测试变得不太可能。因此作为一个优异的测试人员，追求软件质量的完美固然是我们的宗旨，但是明确软件测试现实与理想的差距，在软件测试中学会取舍和让步，对软件测试是有百益而无一弊的。

下面是一些软件测试的常识，对这些常识的理解和运用将有助于我们在进行软件测试时能够更好的把握软件测试的尺度。

•  测试是不完全的（测试不完全）

很显然，由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素，哪怕是一个极其简单的程序，要想穷尽所有逻辑路径，所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子，比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我们将整个正整数域的数字进行一番测试的话，从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的，即便某一天我们能够穷尽该程序，只怕我们乃至我们的子孙都早已作古了。为此作为软件测试，我们一般采用等价类和边界值分析等措施来进行实际的软件测试，寻找最小用例集合成为我们精简测试复杂性的一条必经之道。

•  测试具有免疫性（软件缺陷免疫性）

软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ，测试人员对其采用的测试越多，其免疫能力就越强，寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的，则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。照此推算，软件存在 500 个缺陷时，我们查找一个软件缺陷需要 X 小时，当软件只存在 5 个错误时，我们每查找一个软件缺陷需要 100X 小时。实践证明，实际的测试过程比上面的假设更为苛刻，为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试应该尽可能的多采用多种途径进行测试。

•  测试是 “ 泛型概念 ” （全程测试）

我一直反对软件测试仅存在于程序完成之后。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷，记住 “ 软件缺陷具有生育能力 ” 。软件测试应该跨越整个软件开发流程。需求验证（自检）和设计验证（自检）也可以算作软件测试（建议称为：需求测试和设计测试）的一种。软件测试应该是一个泛型概念，涵盖整个软件生命周期，这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估（信息系统审计和软件工程监理），即测试本身也应当被测试，从而确保测试自身的可靠性和高效性。否则自身不正，难以服人。

另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件，软件测试是提高产品质量最直接、最快捷的手段，但决不是一个根本手段。

•  80-20 原则

80% 的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们，如果你想使软件测试有效地话，记住常常光临其高危多发 “ 地段 ” 。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。

80-20 原则的另外一种情况是，我们在系统分析、系统设计、系统实现阶段的复审，测试工作中能够发现和避免 80% 的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的 80% ，最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。

80-20 原则还能反映到软件测试的自动化方面上来，实践证明 80% 的软件缺陷可以借助人工测试而发现， 20% 的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分，因此尚有 5% 左右的软件缺陷需要通过其他方式进行发现和修正。

•  为效益而测试

为什么我们要实施软件测试，是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价值和意义。一般说来，在软件测试中我们应该尽量地保持软件测试简单性，切勿将软件测试过度复杂化，拿物理学家爱因斯坦的话说就是： Keep it simple but not too simple 。

•  缺陷的必然性

软件测试中，由于错误的关联性，并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的软件缺陷。很多软件缺陷之间是相互矛盾的，一个矛盾的消失必然会引发另外一个矛盾的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何况在缺陷的修复过程中，我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围，选择一个折中的方案或是从非软件的因素（比如提升硬件性能）考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。

•  软件测试必须有预期结果

没有预期结果的测试是不可理喻的。软件缺陷是经过对比而得出来的。这正如没有标准无法进行度量一样。如果我们事先不知道或是无法肯定预期的结果，我们必然无法了解测试正确性。这很容易然人感觉如盲人摸象一般，不少测试人员常常凭借自身的感觉去评判软件缺陷的发生，其结果往往是把似是而非的东西作为正确的结果来判断，因此常常出现误测的现象。

•  软件测试的意义 - 事后分析

软件测试的目的单单是发现缺陷这么简单吗？如果是 “ 是 ” 的话，我敢保证，类似的软件缺陷在下一次新项目的软件测试中还会发生。古语说得好， “ 不知道历史的人必然会重蹈覆辙 ” 。没有对软件测试结果进行认真的分析，我们就无法了解缺陷发生的原因和应对措施，结果是我们不得不耗费的大量的人力和物力来再次查找软件缺陷。很可惜，目前大多测试团队都没有意识到这一点，测试报告中缺乏测试结果分析这一环节。

结论：

软件测试是一个需要 “ 自觉 ” 的过程，作为一个测试人员，遇事沉着，把持尺度，从根本上应对软件测试有着正确的认识，希望本文对读者对软件测试的认识有所帮助。

设计开发脚本如下：

第一步录制脚本如下
Browser("智能变电巡检仪系统 4.0").Page("智能变电巡检仪系统 4.0").WebEdit("txtLoginName").Set "吕巍"
Browser("智能变电巡检仪系统 4.0").Page("智能变电巡检仪系统 4.0").WebButton("登 录").set ""
Browser("智能变电巡检仪系统 4.0").Page("Page").Syn
Browser("智能变电巡检仪系统 4.0").Close

以上为录制的正确的用户名,下边录制错误的用户名
Browser("智能变电巡检仪系统 4.0").Page("智能变电巡检仪系统 4.0").WebEdit("txtLoginName").Set "xx"
Browser("智能变电巡检仪系统 4.0").Page("智能变电巡检仪系统 4.0").WebButton("登 录").set ""
出现错误提示“该用户不存在”

第二步 增强脚本

现在需要设计的是一套脚本驱动所有的测试数据，这样可以驱动所有的用例数据，qtp中提供了datatable。
但是有数据驱动也要做一个事情就是如何处理错误的用户名和正确的用户名，如何结合起来呢？
这里我把datatable看作存放测试用例的地方，里面放入测试数据，还放入测试的预期结果。这样我的设计已经出现雏形了。
我把datatable设计为三列

username  password status
吕x               
xxx       xxxx     该用户不存在

第三列放入最后执行的结果,我设计的是空为成功登陆,如果有信息就用实际运行的结果和这一列对比.好了万事俱备只欠东风了

修改脚本如下：
Dim iStatus

Browser("智能变电巡检仪系统 4.0").Page("智能变电巡检仪系统 4.0").WebEdit("txtLoginName").Set DataTable("username", dtLocalSheet)
Browser("智能变电巡检仪系统 4.0").Page("智能变电巡检仪系统 4.0").WebButton("登 录").set DataTable("password", dtLocalSheet)
iStatus = DataTable("status", dtLocalSheet)

If   iStatus=""  Then
  Browser("智能变电巡检仪系统 4.0").Close
End If

If   iStatus="该用户不存在"    Then
     Reporter.ReportEvent micFail, "登陆", "登陆失败."
End If

Browser("智能变电巡检仪系统 4.0").Close

第三步，设置脚本运行过程

打开 tests-〉settings
设置RUN TAB页面下 Datatable iterations中 Run On all rows

这样就完成了整个脚本的设计工作，以上通过一个简单例子吧脚本的设计和软件的功能结合起来，达成脚本的设计效果。

本文来自51testing博客，转载请注明出处
原始链接：http://blog.51testing.com/?85168/action_viewspace_itemid_1139.html
 

  中国软件评测中心的测试原则，就是从用户和开发者的角度出发进行软件产品测试的。

  为了达到上述的原则，需要注意以下几点：

  1.应当把“尽早和不断地测试”作为开发者的座右铭。

  2.程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。

  3.设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。

  4.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。

  5.对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。

  6.制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

  7.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。

  8.妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档

尽早、尽可能多地发现 Bug, 并负责跟踪和分析产品中的问题，对不足之处提出质疑和改进意见。

零缺陷(Zero-Bug) 是一种理念，足够好（ Good-Enough ）是测试的基本原则。

在软件测试过程中，应注意和遵循的具体原则，可以概括为十大项：

1. 所有测试的标准都是建立在用户需求之上。正如我们所知，软件测试的目标就是验证产品的一致性和确认产品是否满足客户的需求，所以测试人员要始终站在用户的角度去看问题、去判断软件缺陷的影响，系统中最严重的错误是那些导致程序无法满足用户需求的缺陷。
2. 软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间要服从质量。质量的理念和文化（如零缺陷的“第一次就把事情做对”）同样是软件测试工作的基础。
3. 事先定义好产品的质量标准。有了质量标准，才能依据测试的结果对产品的质量进行正确的分析和评估，例如，进行性能测试前，应定义好产品性能的相关的各种指标。同样，测试用例应确定预期输出结果，如果无法确定测试结果，则无法进行校验。
4. 软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。在代码完成之前，测试人员要参与需求分析、系统或程序设计的审查工作，而且要准备测试计划、测试用例、测试脚本和测试环境，测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后开始。应当把“尽早和不断地测试”作为测试人员的座右铭。
5. 穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数量也非常大，因此，在测试中不可能运行路径的每一种组合，然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。
6. 第三方进行测试会更客观，更有效。程序员应避免测试自己的程序，为达到最佳的效果，应由第三方来进行测试。测试是带有 ”挑剔性” 的行为，心理状态是测试自己程序的障碍。同时对于需求规格说明的理解产生的错误也很难在程序员本人测试时被发现。
7. 软件测试计划是做好软件测试工作的前提。所以在进行实际测试之前，应制定良好的、切实可行的测试计划并严格执行，特别要确定测试策略和测试目标。
8. 测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。除了检查程序是否做了应该做的事，还要看程序是否做了不该做的事；不仅应选用合理的输入数据，对于非法的输入也要设计测试用例进行测试。
9. 不可将测试用例置之度外，排除随意性。特别是对于做了修改之后的程序进行重新测试时，如不严格执行测试用例，将有可能忽略由修改错误而引起的大量的新错误。所以，回归测试的关联性也应引起充分的注意，有相当一部分最终发现的错误是在早期测试结果中遗漏的。
10. 对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大。错误集中发生的现象，可能和程序员的编程水平和习惯有很大的关系。

在一般的软件开发中，组织是基于项目，产品或两者兼有。

In general software development organizations are project based, product based and both.

通常，测试组被划分为更小的组以支持多个项目。

Generally, Test group is divided into smaller groups to support multiple projects.

基于测试组的结构，测试人员的背景（功能和技术能力），组织的成熟度，所测产品的质量等等，主要有三种在组织中定位测试自动化服务的方法。

There are mainly three ways of positioning test automation services in an organization based on the construction of a test group, background of the testers (Functional & Technical abilities), maturity of the organization, Quality of the products under test etc.

没有哪一个模型比其他的模型更出众，它们中的每一个都有其自身的利弊。这完全取决于你的具体情况和需要。。。

No model is superior to the other, each of them has its own advantages and disadvantages. It all depends on your situation and needs…

1 ．   独立式 Independent

2 ．   合并式 Merged

3 ．   顾问式 Consultancy

让我们看看上述的那些模型并分析它们的错综复杂之处及其利弊。

Let us look at the above-mentioned models and analyze intricacies of those models, advantages and disadvantages.

Independent:

在这个场景中，一个‘核心的测试自动化组’拥有为测试自动化项目全部生命周期活动的责任。这个小组要做从设计测试自动化包到巩固之前期间里的每件事情。

In this scenario there is a ‘core test automation group’ available which owns the responsibility for all the life cycle of activities of test automation project. This team does everything from the Design of the test automation suite till consolidation.

a. 优点 Advantages:

1. 清晰的责任和统一的方法 Clear responsibilities and uniform approach

2. 最适合‘维护型的测试’来帮助‘手工的回归测试’ Suits best for ‘Maintenance testing’ to assist ‘Manual Regression testing’

3. 最小化和‘手工测试人员’之间的协调 Minimal co-ordination with ‘Manual testing crew’

4. 集中测试自动化的活动 Centralization of test automation activities

5. 最适宜手工测试人员是纯粹的‘非技术’人员的情况 Suits well if the Manual testing crew is purely ‘Non-Technical’

b. 缺点 Disadvantages:

1. 开支太大 Overhead

2. 低‘品质’的测试套件（缺乏所测试产品的功能性和技术性知识） Low ‘Quality’ test ware (Lack of Functional (or) Technical knowledge of the product under test)

3. 冗余（手工测试人员和核心测试自动化组都要同步有关所测应用程序的知识） Redundancy (Synchronization of the knowledge of the application under test for both manual testing crew and core test automation group)

5. 在‘核心的测试自动化组’和‘手工测试人员’之间没有协同配合 No synergy between ‘core test automation group’ and ‘manual testing crew’

6. 需要强有力的管理支持以持续投资测试自动化 Demands strong management support for continuing investments in test automation

Merged:

在这个案例中，有一位专门的测试自动化工程师被分配到每个测试项目中和 ' 手工测试人员 ' 一起工作。 测试自动化工程师们散布在多个测试组里。手工测试工程师和测试自动化工程师共同分担着测试自动化项目的相关活动。

In this case there is a dedicated test automation engineer(s) allocated for each test project that works along with ‘manual testing crew’. Test automation engineers are spread over multiple test groups. Manual test engineer and Test Automation engineer share test automation project activities.

 a. 优点 Advantages:

1. 通过共同分担工作量为尽力达到最高生产率的合作方式 Collaborative way of working for maximum productivity through workload sharing

2. 理想的协同合作 Perfect synergy

3. 能够做更多的事情 Ability to do more

4. 最适合将开发测试自动化包作为软件开发生命周期的一部分的情况 Suits best for developing test automation suites as a part of the software development life cycle

5. 自动化恰当内容的概率是很高的 Probability of automation the right content is high

 b. 缺点 Disadvantages:

1. 沟通的结构 Communication structure

2. 强有力的合作 Strong cooperation

3. 不同的主人 ‘Different’ owners

4. 不统一的方法 Non-uniform approach

5. 在测试脚本开发过程中的不一致 Inconsistency in the development of test scripts

6. 重新创造测试自动化知识的轮回 Re-inventing the wheel of test automation knowledge

Consultancy:

这个测试自动化服务的服务完全是基于 ' 咨询 ' 。 测试自动化组为测试自动化活动担任起了一个专家中心的角色。它负责给手工测试工程师培训关于测试工具，测试方法的知识并为执行和巩固活动提供基础设施。手工测试组是测试自动化项目的主人，并且对测试自动化项目的所有活动负责。

Services of test automation services are purely ‘consultancy’ based. Test automation group acts as an expert center for test automation activities. It is responsible for education manual test engineers about test tools, methodology and providing infrastructure for execution and consolidation. Manual testing group is the owner of the test automation project and is responsible for all the activities of test automation project.

a. 优点 Advantages:

1. 清晰的责任和角色 Clear responsibilities and roles

2. 最小限度的协作 Minimal co-ordination

3.‘Dedicated’ people available for sustaining knowledge about test automation

4. 最好地产出测试自动化包 Best of breed test automation suites

5. 统一的方法和测试套件的可重用性（如果适用的话） Uniform approach and re-usability of the test ware (If applicable)

b. 缺点 Disadvantages:

1. 活动彼此之间不连接 Activities not geared up to each other

2. 强硬的合作 Strong cooperation

3. 手工测试人员在技术上是要可以胜任的 Manual testing crew is technically competent

4. 要求成熟的软件开发组织 Demands matured software development organization