软件开发项目过程中的风险管理研究[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