当前位置：文档之家 › 精品课件-软件工程实践与项目管理-第11章

精品课件-软件工程实践与项目管理-第11章

  • 格式：ppt
  • 大小：4.77 MB
  • 文档页数：121

下载文档原格式

  / 121

合集下载

《软件工程》教学课件 第11章 软件项目管理

《软件工程》教学课件 第11章 软件项目管理

式为组织型、半独立型或嵌入型。
下 表 是 根 据 63 个 项 目 的 数 据 统 计 结 果 ， 按 照 基 本 的 COCOMO模型估算的工作量和进度。
总体类型 组织型
半独立型 嵌入型
工作量 MM=10.4（KLOG）1.05 MM=3.0（KLOG）1.12 MM=3.6（KLOG）1.20
进度 TDEV=10.5（MM）0.38 TDEV=10.5（MM）0.35 TDEV=10.5（MM）0.32
i1
其中:ai — 估计的最小行数 bi — 估计的最大行数 mi — 最可能的行数
将估算的源代码行数，乘以根据经验推算的每行源代 码所需成本，即为该软件的成本。
IBM 估算模型
1977年由Waiston 和 Felix 总结了IBM联合系统 分部（FSD）负责的６０个项目的数据，利用最小二 乘法拟合，得到如下估算公式：
PERT（Program evaluation & review technique)计 划评审技术或CPM（Critical path method）关键路径法， 都是采用网络图来描述项目的进度安排。如图描述了开发 模块A、B、C的任务网络图。各边上所标注的数字为该任 务所持续的时间，数字结点为任务的起点和终点。
70
任务
月份 １ 2 3 4 5 6 7 8 9 10 11 12
60
需求分析 ▲ ▲ ▲
50
总体设计
▲ ▲▲
40
详细设计
▲▲
30
编码 软件测试
▲ ▲▲
20
10
▲▲▲
0 一月
二月
三月
四月
五月
六月
进度表
2.甘特图（Gantt Chart）
《软件工程与项目管理》课件_第11章

《软件工程与项目管理》课件_第11章

(Class)、接口(Interface)、协作(Collaboration)、用例(Use Case)、 主动类(Active Class)、构件(Component)和结点(Node)。
(2) 行为事物(Behavioral Thing)。UML中的行为事物包括交互 (Interaction)和状态机(State Machine)。
(3) 系统设计，并设计类及其行为。 设计阶段由结构设计和详细设计组成。 (1) 结构设计是高层设计，其任务是定义包(子系统)， 包括包间的依赖关系和主要通信机制。包有利于描述系统的 逻辑组成部分以及各部分之间的依赖关系。 (2) 详细设计就是要细化包的内容，清晰描述所有的类， 同时使用UML的动态模型描述在特定环境下这些类的实例 的行为。
(1) 单元测试使用类图和类规格说明。 (2) 集成测试使用部件图、合作图。 (3) 系统测试使用用例图来验证系统的行为。 (4) 验收测试由用户进行，以验证系统测试的结果是否 满足在分析阶段确定的需求。
11.1.5 基于UML的设计过程 运用UML进行面向对象的系统分析设计，其过程通常由以下
三个部分组成： (1) 识别系统的用例和角色。首先对项目进行需求调研，依
第11章 统一建模语言(UML)
11.1 概述 11.2 UML概念模型 11.3 UML的静态建模机制 11.4 UML的动态建模机制 11.5 UML面向实现机制 11.6 UML建模工具 11.7 UML建模实例 11.8 实战训练
11.1 概 述
11.1.1 什么是UML UML是Unified Modeling Language(统一建模语言)的简称，是
系统，具有很宽的应用领域。其中最常用的是建立软件系统 的模型，但它同样也可以用于描述非软件领域的系统，如机 械系统、企业机构或业务过程，以及处理复杂数据的信息系 统、具有实时要求的工业系统或工业过程等。总之，UML 是一个通用的标准建模语言，可以对任何具有静态结构和动 态行为的系统进行建模。
《软件工程项目实践教程》教学课件—项目8 软件工程项目管理

《软件工程项目实践教程》教学课件—项目8 软件工程项目管理

图形化概要，通用技术，易于理解； 中小型项目一般不超过30项活动； 有专业软件支持，无须担心复杂计算和分析。
8.5 开发计划与进度管理
图8-1 甘特图样例
8.5 开发计划与进度管理
甘特图具有简单、醒目和便于编制等特点，在企业管理工作中被广泛应用。甘特图按反 映的内容不同，可分为计划图表、负荷图表、机器闲置图表、人员闲置图表和进度表等五种 形式。
8.5 开发计划和进度管理
针对上述问题，人们提出用软件系统的功能数目来表示软件系统的规模。1979年ibm的 albrecht提出了计算功能点的方法。该方法需要对软件系统的二个方面进行评估，即评估软 件系统所需的内部基本功能和外部基本功能，然后根据技术复杂度因子对这二个方面的评估 结果进行加权量化，产生软件系统功能点数目的具体计算值。具体的，以下是软件系统功能 点的计算公式。
8.4 软件的成本管理
1 成本管理的过程
成本管理的过程包括： 资源计划，包括决定为实施项目活动需要使用什么资源（人员、设备和物资）以及每种 资源的用量。其主要输出是一个资源需求清单。 成本估算，包括估计完成项目所需资源成本的近似值。其主要输出是成本管理计划。 成本预算，包括将整个成本估算配置到各单项工作，以建立一个衡量绩效的基准计划。 其主要输出是成本基准计划。 成本控制，包括控制项目预算的变化。其主要输出修正的成本估算、更新预算、纠正行 动和取得的教训。
fp = ct× (0.65 + 0.01×sfi) （i=1..14） 其中，ct是5个信息量的“权和”fi是14个因素的“杂性调节值”i =1..14），0.65和 0.01是经验常数。
8.5 开发计划和进度管理
8.5 开发计划和进度管理
8.5 开发计划和进度管理
第11章_质量概念

第11章_质量概念


对软件工程工作产品进行技术审查的成本。 数据收集和度量估算的成本。 测试和调试的成本。
质量成本
失效成本是那些如果在将产品发给客户之前或 之后没有错误就不会存在的费用。失效成本可分 为内部失效成本和外部失效成本。 内部失效成本发生在当你在发货之前发现错误 时，内部失效成本包括：



为纠正错误进行返工所需的成本。 返工时无意中产生副作用，必须对副作用加以缓解而发生的 成本。 组织为评估失效的模型而收集质量数据，由此发生的相关成 本。
质量成本

质量成本包括追求质量过程中或在履行质 量有关的活动中引起的费用以及质量不佳 引起的下游费用等所有费用。为了解这些 费用，一个组织必须收集度量数据，为目 前的质量成本提供一个基准，找到降低这 些成本的机会，并提供一个规范化的比对 依据。质量成本可分为预防成本、评估成 本和失效成本。
质量成本

ISO 9126质量因素(6个)
功能性：软件满足已确定要求的程度，由以下子属性表 征：适合性、准确性、互操作性、依从性和安全保密性。 可靠性：软件可用的时间长度，由以下子属性表征：成 熟性、容错性和易恢复性。 易用性：软件容易使用的程度，由以下子属性表征：易 理解性、易学习性和易操作性。 效率：软件优化使用系统资源的程度，由以下子属性表 征：时间特性和资源利用特性。 维护性：软件易于修复的程度，由以下子属性表征：易 分析性、易改变性、稳定性和易测试性。 可移植性：软件可以从一个环境移植到另一个环境的容 易程度，由以下子属性表征：适应性、易安装性、符合 性和易替换性。

Garvin的质量维度
耐久性。是否能够对软件进行维护或改正，而 不会粗心大意地产生料想不到的副作用？随着时 间的推移，变更会使错误率或可靠性变得更糟吗？ 适用性。软件能在可接受的短时期内完成维护 和改正吗？技术支持人员能得到所需的所有信息 以进行变更和修正缺陷吗？ 审美。美的东西具有某种优雅、特有的流畅和 醒目的外在，这些都是很难量化的，但显然是不 可缺少的。美的软件具有这些特征。 感知。在某些情况下，一些偏见将影响人们对 质量的感知。
软件项目管理方法与实践终版ppt课件

软件项目管理方法与实践终版ppt课件

项目整体管理启动启动规划规划执行执行监控监控收尾收尾制订项目章程制订项目章程制订项目管理计划制订项目管理计划指导与管理项目执行指导与管理项目执行监控项目监控项目实施整体变更实施整体变更结束项目或阶段结束项目或阶段制订一份正式批准项目或阶段的文件并记录能反映干系人需要和期望的初步要求对定义编制整合和协调所有子计划所必需的行动进行记录为实现目标而执行项目计划中所确定的工作的过程跟踪审查和调整项目进展以实现项目管理计划中确定的绩效目标审查所有变更请求批准变更管理对可交付成果组织过程资产项目文件和项目管理计划的变更完结所有项目管理过程组的所有活动以正式结束项目或阶段制定项目管理计划范围管理计划进度管理计划成本管理计划风险管理计划采购管理计划沟通管理计划质量管理计划人员配置管理计划里程碑清单过程改进计划成本基准质量基准范围基准资源日历进度基准风险登记册项目范围管理启动启动规划规划执行执行监控监控收尾收尾收集需求收集需求定义范围定义范围创建wbs创建wbs核实范围核实范围控制范围控制范围为实现目标而定义并记录干系人的需求制订项目和产品的详细描述将项目可交付成果和项目工作分解为较小的更易于管理的组成部分正式验收项目已完成的可交付成果监督项目和产品的范围状态管理范围变更项目范围管理收集需求用户需求用户需求想法产品规格产品范产品规格产品范项目需求项目需求项目范围说明项目范围说明工作范围分解案例飞行系统飞行系统飞行器飞行器支持设备支持设备设施设施测试与评价测试与评价项目管理项目管理培训培训数据数据系统工程管理支持性项目管理活动设备培训设施培训服务培训技术命令工程数据管理数据实物模型运作测试开发测试基地大楼维护设施层次的组织层次的层次的中间层次的补给站补给站层次机身引擎通信系统导航系统消防系统工作范围分解案例家庭装修家庭装修设施设施结构结构墙体墙体地板地板门窗门窗厨房厨房厕所厕所洗浴洗浴空调空调照明照明通讯通讯洁具洁具风机风机垃圾垃圾橱柜橱柜水池水池上水管上水管下水道下水道龙头阀门龙头阀门过滤网过滤网工作范围分解案例文艺演出文艺演出节目节目剧务剧务后勤后勤经营经营策划策划编导编导排练排练表演表演化妆化妆道具道具灯光灯光音响音响交通交通就餐就餐住宿住宿安全安全广告广告销售销售票务票务财务财务项目时间管理启动启动规划规划执行执行监控监控收尾收尾定义活动定义活动排列活动顺序排列活动顺序估算活动资源估算活动资源估算活动持续时间估算活动持续时间
软件工程 第4版 第11章 软件工程管理

软件工程 第4版 第11章 软件工程管理


本章内容
11.1 软件工程管理概述 11.2 软件开发成本估算 11.3 软件工程人员组织 11.4 软件配置管理 11.5 软件质量保证 11.6 软件开发风险管理 11.7 软件工程标准与软件工程文档
这种估算方法的优点是，由于各个任务单元的成本 可交给该任务的开发人员去估计，因此估计结果比较准 确。缺点在于，由于具体工作人员往往只注意到自己职 责范围内的工作，而对涉及全局的成本。
11.2.3 COCOMO2 模型
COCOMO2 模型分为如下3 个模型，在估算软件开发工作量时，对软件细节问题考虑的详 尽程度逐渐增加。
OPTION
软件开发人员一般分为项目负责人、系统分析员、高级程序员、程序员、初级程序员、资 料员和其他辅助人员。
项目负责人需要对项目的需求和团队人员有全面的了解
系统分析员需要有概括能力、分析能力和社交活动能力
程序员需要有熟练的编程能力等 资料员和其他辅助人员负责及时登记软件工程每个阶段的文档等资料
11.3 软件工程人员组织
11.1 软件工程管理概述
02 软件工程管理的重要性
OPTION
基于软件本身的复杂性，软件工 程将软件开发划分为若干个阶段，每 个阶段完成不同的任务、采取不同的 方法。
如果软件开发管理不善，造成的 后果会很严重。因此软件工程管理非 常重要。
11.1 软件工程管理概述
03 软件工程管理的内容
OPTION
02 组织机构
OPTION
软件开发团队不能只是一个简单的集合，要求具有良好的组织机构，要具有合理的人员分 工和有效的通信，共同高效率地完成任务。
按项目划分的模式
按职能划分的模式
矩阵型模式
11.3 软件工程人员组织
软件工程项目管理ppt

软件工程项目管理ppt


Enter your main title
Disruptive technologies such as artificial intelligence and big data are changing the world of work. Retail jobs are
项目团队建设
标题内容
标题内容
单击此处可编辑内容,根据您的需要自由拉伸文本框大小
单击此处可编辑内容,根据您的需要自由拉伸文本框大小
单击此处可编辑内容,根据您的需要自由拉伸文本框大小
单击此处可编辑内容,根据您的需要自由拉伸文本框大小
项目成本控制
单击此处添加文字阐述添加简短问题说明文字，单击此处添加文字阐述添加简短问题说明文字
标题内容
There is one kind of job though, that is both indispensable and
TEXT HERE
There is one kind of job though, that is both indispensable and
信息传递流程
There is one kind of job though, that is both indispensable and
项目质量控制
单击此处添加文字阐述，添加简短问题说明文字，具体添加文字
单击此处添加文字阐述，添加简短问题说明文字，具体添加文字
单击此处添加文字阐述，添加简短问题说明文字，具体添加文字
TEXT HERE
There is one kind of job though, that is both indispensable and
Disruptive technologies such as artificial intelligence and big data are changing the world of work. Retail jobs are disappearing in the US while the online sellers supplanting them fill their warehouses with robots instead of human workers.
《软件项目管理原理与实践》 课件 第11章 软件项目管理软件

《软件项目管理原理与实践》 课件 第11章 软件项目管理软件

（9）关闭Excel并且不保存可视报表。 （10）单击“关闭”，关闭可视报表对话框。
29
11.1.5 创建新项目计划
项目计划，本质上是你为参与的实际项目的某几 方面内容（你预想会发生的以及希望发生的，二 者最好差别不大）构建的模型。
此模型关注实际项目的某些（不是全部）方面，即任务、资源、时 间框架及其相关成本。
27
可视报表对话框
（5）接下来创建一个可视报表以便仔细查看总的资源工作量及其在项 目生命周期中的可用性。
此要求计算机上安装有微软 Office Excel 2013或更高版本，如果没有，请跳至最后步骤。
（6）单击“报表”菜单中的“可视报表”，显示可视报表对话框，其 中列出了Project中所有预定义的可视报表
项目管理软件有助于制定项目计划和跟踪项目计划的执行 。
人工维护项目管理数据，通常是很麻烦的。 利用项目管理软件，数据资源的任何更改都会自动反映到网络图表、成本
表、资源图表这些项目文件中。 凭借优秀的项目管理软件，可以解决以下问题：
要取得项目的可交付成果，必须执行什么任务，以何种顺序执行？ 应于何时执行每一个任务？ 谁来完成这些任务？成 本是多少？ 如果某些任务没有按计划完成，该怎么办？ 对那些关心项目的人而言，交流项目详情的最佳方式是什么？
“网络图”视图中的每个框或节点显示某个 任务的详细信息，框之间的线表示任务间的 关系。
和“日历”视图一样，“网络图”视图没有表结构，整 个视图就是一个图。
项目包含两种类型的报表：表格报表用于打 印，可视报表用于将Project数据输出到Excel 和Visio。
可视报表使用Project中的Excel和Visio模板，来生成设 计美观的图表。
同时，又能与资源和其他项目干系人交流。 （6）使用外观和操作类似桌面程序的应用来管理项目。
《软件工程与项目管理》第10章-软件项目管理

《软件工程与项目管理》第10章-软件项目管理


项目收尾过程
要点一
验收项目成果
组织相关干系人对项目成果进行验收，确保项目目标已实 现。
要点二
总结经验教训
对项目执行过程中的经验教训进行总结，为今后的项目提 供借鉴和改进依据。
04
软件项目管理工具与技术
项目管理软件工具
微软Project
Trello
一款功能强大的项目管理软件，提供 项目计划制定、任务分配、进度跟踪 等功能。
进度与Hale Waihona Puke 本的控制进度与成本控制挑战
软件开发过程中，进度延误和成本超 支是常见问题。
解决方案
制定详细的项目计划，合理分配资源 ，加强项目监控和调整，确保项目按 计划进行并控制成本。
质量保证与测试
质量保证与测试挑战
软件质量是软件项目的核心要求之一，但质量保证与测试过程中可能存在疏漏 和不足。
解决方案
Extreme Programming
一种敏捷开发方法，强调编程实践和持续集成，适合需求变化频繁 的项目。
统一过程方法
统一建模语言（UML）
一种用于软件工程的标准化建模语言，支持从需求分析 到系统设计的全过程。
统一过程（UP）
一种结构化的软件开发过程，包括初始阶段、细化阶段 、构建阶段和交付阶段。
保证按时交付
降低风险
通过有效的进度管理和时间安排，可以确 保软件按时交付给客户。
项目管理有助于识别和评估软件开发过程 中可能出现的风险，并采取相应的措施来 降低或消除这些风险。
软件项目管理的历史与发展
20世纪60年代
软件工程的概念开始出现， 人们开始意识到软件开发需 要系统化的管理方法。
20世纪80年代
预测完成项目所需的总成本。
《软件工程项目实践教程》教学课件—项目8 软件工程项目管理

《软件工程项目实践教程》教学课件—项目8 软件工程项目管理


8.3 软件项目的人员管理
1 项目团队建设类型
项目团队从一般意义上讲可分为四种类型： （1）问题解决型团队 （2）自我管理型团队 （3）多功能型团队 （4）虚拟型团队
8.3 软件项目人员管理
2 项目团队组建
（1）项目团队要有共同的愿景与目标 （2）项目经理的选择，项目的选择一般有以下三种方式：
① 由企业高层领导委派；② 由企业和用户协商选择；③ 竞争上岗。 （3）项目团队成员选择，项目团队成员选择主要分为内部招聘和外部招聘两种形式，
8.4 软件的成本管理
2 软件开发成本管理过程中的主要问题
（1）项目成本预算和估算的准确度差。 由于客户的需求不断变化，使得工作内容和工作量不断变化。一旦发生变化，项目经理 就追加项目预算，预算频频变更，等到项目结束时，实际成本和初始计划偏离很大。此外， 项目预算往往会走两个极端：过粗和过细。预算过粗会使项目费用的随意性较大，准确度降 低；预算过细会使项目控制的内容过多，弹性差，变化不灵活，管理成本加大。 （2）缺乏对软件成本事先估计的有效控制。 在开发初期，对成本不够关心，忽略对成本的控制，只有在项目进行到后期，实际远离 计划出现偏差的时候，才进行成本控制，这样往往导致项目超出预算。 （3）缺乏成本绩效的分析和跟踪。
8.4 软件的成本管理
3 成本管理方法的改进
目前常用的软件项目管理工具都侧重于某一方面的功能，如微软的 Project2000侧重管 理、规划任务，并在项目执行过程中跟踪这些任务，偏向于进度安排与跟踪控制；RUP侧重于 用户需求的描述；PVCS侧重于软件变更管理。这些软件项目管理工具都在不断的完善其功能， 虽然也有成本管理的功能，但总的来说大多数都不能用来进行软件成本估计，缺乏事先成本 控制，不能和估计数据自动化协调，不能自动化地利用历史数据库中的数据。当前的项目管 理工具并不能满足成本管理的需要。
《软件工程与项目管理》课件_第9章

《软件工程与项目管理》课件_第9章


(4) 绝大多数软件在设计时没有考虑将来的修改问题。 (5) 追踪软件的建立过程非常困难，或根本做不到。 (6) 软件维护可以说是一项毫无吸引力的工作。之所以 形成这样一种观念，一方面是因为软件维护工作量大，看不 到什么“成果”，更主要的原因是维护工作难度大，又经常 遭受挫折，且从事这项工作缺乏成就感。 上述种种问题在现有的没有采用软件工程思想开发出来 的软件中，都或多或少地存在着。而软件工程部分地解决了 与维护有关的各种问题。
维护工作量可以分成生产性活动(如分析评价、修改设 计和编写程序代码等)和非生产性活动(如理解程序代码的功 能，解释数据结构、接口特点和性能限度等)。
维护工作量的计算表达式如下：
M=P+K×e (c – d)
其中：M——维护中消耗的总工作量； P——生产性工作量； K——经验常数； c——复杂程度(非结构化设计和缺少文档都会增加软件
因为没有测试方面的文档，所以不可能进行回归测试 (即为了保证所做的修改没有在以前可以正常使用的软件功 能中引入错误而重复过去做过的测试)。
图9.1 结构化维护与非结构化维护的对比
(2) 结构化维护。结构化维护的软件配置完整，维护工 作从评价设计文档开始，确定软件重要的结构特点、性能特 点以及接口特点；估计要求的改动将带来的影响，并且计划 实施途径。结构化维护首先修改设计并且对所做的修改进行 仔细复查，接下来编写相应的源程序代码，使用在测试说明 书中包含的信息进行回归测试，最后将修改后的软件再次交 付使用。
9.3 软件维护的类型
根据软件维护的不同原因，软件维护可以分成改正性维 护、适应性维护、完善性维护和预防性维护四种类型。
1．改正性维护(corrective) 因为软件测试不可能暴露出一个大型软件系统所有潜藏 的错误，所以必然会有第一项维护活动：在任何大型程序的 使用期间，用户在某些特定的使用环境下必然会发现这些潜 藏的程序错误，并且把他们遇到的问题报告给维护人员。诊 断和改正错误的过程称为改正性维护。

精品课件-软件工程实践与项目管理-第10章

文档：测试计划、测试方案、测试用例、测试日志、测试总结 报告、测试工具等。
第10章 软 件 测 试
10.4 静 态 测 试
软件测试方法分白盒测试和黑盒测试；从计算机运行状态 分为动态测试和静态测试。
动态测试通过运行被测程序，输入有效的测试用例，验证 功能是否达到软件需求从而找出程序缺陷。
静态测试时计算机并不真正运行被测试的程序，它只对被 测程序的数据流和控制流等信息进行分析，找出系统的缺陷， 做出测试报告，因此静态测试又称为“静态分析”。
第10章 软 件 测 试
静态测试的目的是检查代码与设计的一致性、代码的可读 性、代码和算法的正确性、代码结构的合理性等。例如：
(1) 检查程序风格的一致性、规范性； (2) 检查算法的逻辑正确性，确定算法是否为最佳算法并 实现了所要求的功能； (3) 检查模块接口的正确性，形参的个数、数据类型、顺 序是否正确，确定返回值类型及返回值的正确性； (4) 检查程序输入参数的合法性； (5) 检查程序有无适当的异常处理模块； (6) 检查程序常量或全局变量、表达式、语句是否正确， 是否含有二义性； (7) 检查程序代码是否可以优化。
测试达到的标准； ·确定所需的测试资源，并对测试的工作量进行估计。
第10章 软 件 测 试
2 测试范围 列出软件需要进行的测试工作范围和不需要进行的测试工 作范围；对于不实施某种测试，应该陈述具体的理由。例如， “将不实施安装测试，该项目将不提供安装版本”。 3 测试的策略与方法 测试人员采用的测试方法，如回归测试、功能测试、自动 测试等。 4 测试通过/不通过的标准 测试是否通过的界定标准以及没有通过时的处理方法。
第10章 软 件 测 试 10.2 案例：图书借阅系统的功能函数
1. 图书借阅系统功能分解 通过分析，系统具有如下功能：① 图书卡的注册、注销 和信息查询；② 图书借阅；③ 图书信息的查阅：按照作者姓 名查阅、按照书名查阅；④ 图书返还。 图书借阅系统的模块设计如图10-1所示。
  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
图11-3所示。
图11-3 VuGen主界面
第11章 软件测试工具LoadRunner (3) 选择菜单File/New…项，进入创建脚本的功能界面，
如图11-4所示。
图11-4 创建脚本
第11章 软件测试工具LoadRunner (4) 选择New Single Protocol Script项，协议是一个客
第11章 软件测试工具LoadRunner (5) 了解通信装置(网卡、路由器等)的吞吐量，每个通信
装置能够处理的并发用户数。 (6) 了解该系统最常用的功能，确定需要优先测试的功能。 (7) 了解系统角色以及系统角色的数量、每个角色的地理
分布情况，从而预测最高峰情况下的负载值。
第11章 软件测试工具LoadRunner 2. 确定测试参数 在录制脚本的过程中会遇到很多参数问题。例如，不同的
第11章 软件测试工具LoadRunner 用VuGen建立测试脚本后，用户可以对其进行参数化操作，
这一操作能让用户利用几套不同的实际发生数据来测试其应例， 参数化操作可将记录中的固定数据，如订单号和客户名称，由 可变值来代替。在这些变量内任意输入可能的订单号和客户名， 来匹配多个实际用户的操作行为。
第11章 软件测试工具LoadRunner (1) 从菜单中选择Vuser/Start Recording(见图11-7)或者
单击工具栏中Start Recording按钮，弹出图11-8所示窗口。
图11-7 准备进行用户活动的录制
第11章 软件测试工具LoadRunner 图11-8 输入Web地址
用户有不同的使用数据；对于负载测试，首先要考虑数据量和 用户量；对于强度测试，需要确定用户的极限并发量峰值、数 据量峰值等因素。
第11章 软件测试工具LoadRunner 11.3 创建测试脚本
运行LoadRunner的方法：依次点击“所有程序/Mercury LoadRunner / LoadRunner”，进入LoadRunner主界面，如图 11-1所示。
户端用户进行通信的语言。接下来选择Category/All Protocols/Web(HTTP/HTML)类型来建立单个协议通信。如图115所示。
第11章 软件测试工具LoadRunner 图11-5 单协议脚本的选择
第11章 软件测试工具LoadRunner (5) 点击OK按钮，建立一个空的Web脚本，如图11-6所示。
第11章 软件测试工具LoadRunner 图11-1 运行LoadRunner
第11章 软件测试工具LoadRunner 1. 建立脚本 1) 创建虚拟用户 使用VuGen(虚拟用户产生器)生成虚拟用户，以虚拟用户的
方式模拟真实用户的业务操作行为。它先记录下业务流程，然 后将其转化为测试脚本。利用虚拟用户，可以在Windows 或者 UNIX机器上同时产生成千上万个用户访问。所以LoadRunner能 极大地减少了负载测试所需的硬件和人力资源。
第11章 软件测试工具LoadRunner (2) 在此可以输入：
http://localhost:1080/mercuryWebTours/，然后单击OK按钮。 这时进入Record into Action对话框，选择Action项，单击OK 按钮。
图11-6 空的Web脚本
第11章 软件测试工具LoadRunner 2) 录制用户的活动 LoadRunner通过记录一个业务进程来建立脚本，模拟系统
真实的负载。在录制程序运行的过程中，VuGen自动生成了包含 录制过程中实际用到的数值的脚本。
在具体测试时，LoadRunner通过录制一个真实用户使用业 务系统而跟踪业务系统的处理过程。具体方法是：
LoadRunner包含很多组件，其中最常用的有Visual User Generator(虚拟用户产生器，以下简称VuGen)、 Controller(控制器)、Analysis(分析器)。
第11章 软件测试工具LoadRunner 使用LoadRunner进行测试的过程分为如下五个步骤： (1) 分析测试需求； (2) 创建测试脚本(或脚本)； (3) 创建运行场景； (4) 运行测试脚本； (5) 分析与监视负载测试。 另外需注意：LoadRunner软件需要占用至少500 MB的磁盘
空间。
第11章 软件测试工具LoadRunner 11.2 分析测试需求
分析测试需求一般情况下需要两个步骤：① 分析应用需 求；② 确定测试参数。
1. 分析应用需求 分析应用需求要求测试人员对应用系统的软/硬件以及配 置情况非常熟悉，这样才能保证创建的测试环境真实地反映实 际运行的环境。
第11章 软件测试工具LoadRunner
第11章 软件测试工具LoadRunner
第11章 软件测试工具LoadRunner
11.1 LoadRunner的测试流程介绍 11.2 分析测试需求 11.3 创建测试脚本 11.4 测试实例 11.5 创建运行场景 11.6 运行测试脚本 11.7 分析以及监视场景 本章小结 习题
第11章 软件测试工具LoadRunner 11.1 LoadRunner的测试流程介绍
第11章 软件测试工具LoadRunner (1) 首先需要建立一个空脚本来记录事件。打开
LoadRunner，单击Load Testing菜单,如图11-2所示。
图11-2 Load Testing功能界面
第11章 软件测试工具LoadRunner (2) 单击Create/Edit Scripts项，进入VuGen主界面，如
分析时主要考虑下面几个问题： (1) 了解系统的软件结构。要搞清楚软件结构是C/S 结构 还是B/S结构，如果是B/S结构，还应搞清采用何种应用服务器 和采用何种数据库等问题。 (2) 估计连接到应用系统的并发用户数。 (3) 客户机的配置情况(硬件、内存、操作系统、软件工具 等)。 (4) 客户机和服务器之间的通信方式。