软件文档写作第7讲管理文档完整

1、编辑课件1编辑课件27.1 7.1 管理文档概述管理文档概述 工程化的软件生产方式是软件业界始终在不懈追求的目标。工程化的软件生产方式是软件业界始终在不懈追求的目标。软件项目管理方法适用与否，对软件项目的成败有着举足轻重的软件项目管理方法适用与否，对软件项目的成败有着举足轻重的作用。而软件项目管理方法改进的途径之一，就是建立行之有效、作用。而软件项目管理方法改进的途径之一，就是建立行之有效、可操作性强的软件管理文档。可操作性强的软件管理文档。软件管理文档软件管理文档项目开发计划项目开发计划测试计划测试计划测试分析报告测试分析报告开发进度报告开发进度报告开发总结报告开发总结报告管理文档的组成：管

2、理文档的组成：管理文档有以下几个方面的作用：管理文档有以下几个方面的作用：维护人员维护人员软件开发软件开发管理人员管理人员软件开发人员软件开发人员软件操作软件操作人员人员用户用户软件管软件管理文档理文档编辑课件3 管理文档的作用主要体现在三个方面 是软件开发各阶段工作成果的体现是软件开发各阶段工作成果的体现 把软件开发过程中的一些把软件开发过程中的一些“不可见不可见”的事物转换成的事物转换成“可可见见”的文字资料的文字资料 提供了管理人员、开发人员、操作人员和用户之间相互提供了管理人员、开发人员、操作人员和用户之间相互沟通、协调的窗口沟通、协调的窗口编辑课件47.2 7.2 项目开发计划项目开

3、发计划 项目开发计划又称软件定义文档，是和软件本身一样重要的项目开发计划又称软件定义文档，是和软件本身一样重要的知识资产，是项目启动后第一件最重要的工作。知识资产，是项目启动后第一件最重要的工作。 项目开发计划一般包括资源需求、工作分解、工作目标、开项目开发计划一般包括资源需求、工作分解、工作目标、开发团队及人员安排、进度安排、内外接口约定、风险分析以及软发团队及人员安排、进度安排、内外接口约定、风险分析以及软件质量控制机制等。件质量控制机制等。1. 1. 项目开发计划书项目开发计划书 项目开发计划书的具体内容随着项目和开发机构类型的不同而不同，一般项目开发计划书的具体内容随着项目和开发机构类

4、型的不同而不同，一般都会包括以下几个部分：都会包括以下几个部分： 项目目标项目目标。简述项目目标，并列出影响管理的约束条件，如预算、时间。简述项目目标，并列出影响管理的约束条件，如预算、时间 开发团队及人员安排开发团队及人员安排。阐述团队组织方式、人员构成及分工。阐述团队组织方式、人员构成及分工 软硬件资源需求软硬件资源需求。分析和列出所需资源，注明估算的资源需要时间及价格。分析和列出所需资源，注明估算的资源需要时间及价格 工作分解工作分解。分解项目为一系列活动，确定项目里程碑及可交付文档。分解项目为一系列活动，确定项目里程碑及可交付文档 项目进度项目进度。描述项目各活动之间的依赖关系、到达里

5、程碑的时间等。描述项目各活动之间的依赖关系、到达里程碑的时间等 风险分析风险分析。分析项目可能存在的风险、发生的可能性及应对风险的策略。分析项目可能存在的风险、发生的可能性及应对风险的策略 监控机制监控机制。制定详细、可操作的项目监控机制，明确管理报告的递交时间。制定详细、可操作的项目监控机制，明确管理报告的递交时间 开发估算开发估算。包括规模、工作量、成本等的估算，要求依据并积累历史数据。包括规模、工作量、成本等的估算，要求依据并积累历史数据编辑课件5 制定项目开发计划的过程被称为项目策划。制定项目开发计划的过程被称为项目策划。 由于计划所具有的在时间上的提前性，项目开发由于计划所具有的在时

6、间上的提前性，项目开发计划通常会经常性的修正，有些部分甚至会频繁的改计划通常会经常性的修正，有些部分甚至会频繁的改变！变！ 而部分内容的变化，会影响开发计划的正确性和而部分内容的变化，会影响开发计划的正确性和符合性，使其越来越偏离项目实际，最后变得没有价符合性，使其越来越偏离项目实际，最后变得没有价值。如随着项目需求的逐渐明确引起的项目计划细化、值。如随着项目需求的逐渐明确引起的项目计划细化、项目可提供资源变化引起的项目计划的变化等。项目可提供资源变化引起的项目计划的变化等。 所以，在实际工作中，需要有明确的责任人和操所以，在实际工作中，需要有明确的责任人和操作原则，来对项目计划实施维护，并对

7、项目计划的变作原则，来对项目计划实施维护，并对项目计划的变更实施必要的控制。更实施必要的控制。 另一个重要的方面是，在组织文档时，就要考虑另一个重要的方面是，在组织文档时，就要考虑到这种频繁变更的需要，使得当变更发生时，文档的到这种频繁变更的需要，使得当变更发生时，文档的相应部分能够容易替换。相应部分能够容易替换。编辑课件62. 2. 工作分解结构工作分解结构 工作分解结构工作分解结构(work breakdown structure, WBS)(work breakdown structure, WBS)是对整个是对整个项目工作的分级描述，是项目计划开发的第一步。分解示意如项目工作的分级描述

8、，是项目计划开发的第一步。分解示意如下图所示。下图所示。目标目标活动活动活动活动活动活动活动活动活动活动活动活动1 1级级2 2级级m m级级工作包工作包任务任务1 1任务任务2 2任务任务3 3 任务任务n n活动活动工作分解结构设计一工作分解结构设计一般可以采用般可以采用2 2种方法：种方法：- - 自上而下自上而下的方法。的方法。从项目的目标开始，从项目的目标开始，逐步分解，直到具逐步分解，直到具体任务体任务- - 自下而上自下而上的方法。也的方法。也称集思广益法。即称集思广益法。即从底层开始，逐层从底层开始，逐层集成，最后汇合后集成，最后汇合后完成目标完成目标编辑课件7工作分解工作分解

9、结构主要有结构主要有4 4个用途个用途： 思路工具思路工具：可以描述项目的整体思路，是一个计划和设：可以描述项目的整体思路，是一个计划和设计的工具；计的工具； 结构设计工具结构设计工具：是项目工作的结构图，可以清晰表达项：是项目工作的结构图，可以清晰表达项目各项工作间的相互关系；目各项工作间的相互关系； 计划工具计划工具：能够展示项目全貌，说明为完成项目所需完：能够展示项目全貌，说明为完成项目所需完成的各项活动；成的各项活动；1.1. 项目状态报告工具项目状态报告工具：可以作为项目状态报告的框架。随：可以作为项目状态报告的框架。随着低一级项目活动的完成，项目由下而上不断整合，某着低一级项目活动

10、的完成，项目由下而上不断整合，某一项工作的完成将成为里程碑，所以，工作分解结构就一项工作的完成将成为里程碑，所以，工作分解结构就定义了里程碑事件。定义了里程碑事件。编辑课件83. 3. 项目里程碑与阶段性文档项目里程碑与阶段性文档 由于软件产品是无形的，因此，管理者需要通过文档的形式由于软件产品是无形的，因此，管理者需要通过文档的形式获得信息，了解软件的开发状况，以作出管理的决定。获得信息，了解软件的开发状况，以作出管理的决定。 里程碑的建立，可以描述软件开发活动一个过程的终结。在里程碑的建立，可以描述软件开发活动一个过程的终结。在每个里程碑，都有一个正式的可以提交给管理层的阶段性结果。每个里

11、程碑，都有一个正式的可以提交给管理层的阶段性结果。比如，一份报告。比如，一份报告。 里程碑报告的内容不拘，以能清楚说明阶段性结果为标准，里程碑报告的内容不拘，以能清楚说明阶段性结果为标准，应能代表项目中一个特定逻辑意义上的阶段的终结。应能代表项目中一个特定逻辑意义上的阶段的终结。 要建立里程碑，软件过程就一定要分解成一系列相关的基本要建立里程碑，软件过程就一定要分解成一系列相关的基本活动，而每个基本活动都要有相应的输出结果。如下图，是一个活动，而每个基本活动都要有相应的输出结果。如下图，是一个需求描述中的活动，其中每个活动都有主要输出。需求描述中的活动，其中每个活动都有主要输出。可行性研究可行

12、性研究需求分析需求分析原型开发原型开发设计研究设计研究需求描述需求描述可行性报告可行性报告用户需求用户需求估算报告估算报告体系结构设计体系结构设计系统需求系统需求编辑课件94. 4. 项目进度项目进度 项目管理者要求估算完成各项活动所需的时间和资源，并将它们严密的组织起来，以安排项目进度。不同的项目，具有不同的项目开发进度。 初始的项目进度安排往往是不精确的，但随着项目进展信息的不断增多，进度安排也会越来越接近项目实际进度，因此，必须不断更新项目进度。 项目进度包括将一个项目分解为若干独立的活动，以及判断完成这些活动所需的时间。通常，有些活动是可以并行的，项目管理者应组织并协调这些并行的工作。

13、项目进度过程见下图：识别活动识别活动识别活动识别活动依赖关系依赖关系估算活动估算活动的资源的资源为活动分为活动分配资源配资源创建项目创建项目图表图表软件需求软件需求活动图表及条形图活动图表及条形图编辑课件10 在进度估算时，管理者需要有一定的余量。在进度估算时，管理者需要有一定的余量。 如项目难度大，则花费的时间也会较多。又如，项目个别如项目难度大，则花费的时间也会较多。又如，项目个别开发人员可能发生的变动，硬件环境的变化等，都是在估算开发人员可能发生的变动，硬件环境的变化等，都是在估算项目进度时必须考虑的因素。项目进度时必须考虑的因素。 除了时间和人员、环境的变化，资源和预算也需要考虑适除了

14、时间和人员、环境的变化，资源和预算也需要考虑适当的余量。当的余量。 恰当的估算方法是采用恰当的估算方法是采用“理想实际理想实际”方式。即先估算理方式。即先估算理想值，然后逐步加入预计出现的状况、偶然因素致成的状况、想值，然后逐步加入预计出现的状况、偶然因素致成的状况、项目开发人员的素质和经验项目开发人员的素质和经验 作为经验数据，一般在最初估算的基础上增加作为经验数据，一般在最初估算的基础上增加30%30%作为实作为实际可能发生的状况值，再预留际可能发生的状况值，再预留20%20%的估算值给所谓不可预见的估算值给所谓不可预见的其它问题，则进度估算的结果会较符合实际。的其它问题，则进度估算的结果

15、会较符合实际。编辑课件11任任 务务持续时间持续时间( (天数天数) )依依 赖赖 关关 系系T1T18 8T2T21515T3T31515T1(M1)T1(M1)T4T41010T5T51010T2T2，T4(M2)T4(M2)T6T65 5T1T1，T2(M3)T2(M3)T7T72020T1(M1)T1(M1)T8T82525T4(M5)T4(M5)T9T91515T3T3，T6(M4)T6(M4)T10T101515T5T5，T7(M7)T7(M7)T11T117 7T9(M6)T9(M6)T12T121010T11(M8)T11(M8)5. 5. 运用图和表描述项目进度运用图和表描述

16、项目进度 项目进度可以采用图表工具更直观的表示任务分解、活动依赖关系和人员分配情况等。 下表是一个“任务的持续时间及其依赖关系”的例子。编辑课件12甘特图法(Gantt Chart)的例子tw12345678ABCD当前进度当前进度优点：简单，能动态地反映优点：简单，能动态地反映开发进程开发进程缺点：难以反映多个任务间的缺点：难以反映多个任务间的逻辑关系逻辑关系条形图和活动网络图是表示项目进度的两种图形表示法。(1) 条形图。又称甘特图法(Gantt Chart)，可以表示面向活动的负责人是谁，以及活动的开始和结束时间。如下图所示的例子。编辑课codingA test

17、ingA debuggingAB coding understandingC modifyingC testingB testingC debuggingB debuggingC testingABC012356789 codingA testingA debuggingA understandingC modifyingC testingB testingC debuggingB debuggingC testingABC4 debuggingAB coding 例：开发三个模块A、B、C。 A为公用模块，B、C的测试须等A的调试完成后进行。A的编码需6天，测试8天，调试6天。B的编码需7天

18、，测试8天，调试6天。C利用已有的模块，须先理解原模块8天，再修改8天，测试9天，调试7天。最后三模块集成测试需5天完成。(2) 活动网络图。又称网络计划法 表示构成一个项目的不同活动之间的依赖关系。是用网状图表安排与控制各项活动的方法。最适合反映多个工作之间的逻辑关系。编辑课件14持续时间持续时间Lasting Time机动时间机动时间Slack Time编编号号EarliestStart TimeLatestStart Time012345678941363029222014126006142082028293641(0)(0)(15)(4)(2)(4)(0)(2)(0)(2)(0)(0)

19、686678886975(1) 标出标出 Lasting Time(2) 标出标出 EST: = 从起点始，所有进从起点始，所有进入事件的入事件的 EST+LT 中最大的中最大的(3) 标出标出 LST: = 从终点从终点(EST = LST)始，所有离开事件的始，所有离开事件的 LST LT 中最小的中最小的(4) 标出标出 ST: = 终点终点LST 起点起点EST LT(5) 标出标出Key Path：即即EST = LST的的所有事件组成的路径所有事件组成的路径通常，甘特图适合按开发阶段安排，以作项目总体进度控制。网络计划法便于在细节上安排人力，适合按开发阶段或子项目的工作步骤安排。编

20、辑课件15风风 险险风险类型风险类型风风 险险 描描 述述职员跳槽职员跳槽项目项目有经验的职员未完成项目就跳槽有经验的职员未完成项目就跳槽管理层变更管理层变更项目项目不同的管理层考虑、关注的事情会不同不同的管理层考虑、关注的事情会不同硬件缺乏硬件缺乏项目项目项目所需的基础硬件没有按期交付项目所需的基础硬件没有按期交付需求变更需求变更项目和产品项目和产品软件需求与预期的相比，将会有较大变化软件需求与预期的相比，将会有较大变化描述延迟描述延迟项目和产品项目和产品有关主要接口的描述未按期完成有关主要接口的描述未按期完成低估了系统规模低估了系统规模项目和产品项目和产品过低估计了系统的规模过低估计了系统

21、的规模CASECASE工具性能较差工具性能较差产品产品支持项目的支持项目的CASECASE工具达不到要求工具达不到要求技术变更技术变更业务业务系统的基础技术被新技术取代系统的基础技术被新技术取代产品竞争产品竞争业务业务系统还未完成，其它有竞争力的产品就已经上市了系统还未完成，其它有竞争力的产品就已经上市了6. 6. 风险管理风险管理 由于绝大多数软件项目都存在不确定性，因此，风险管理对软件项目而言就尤为重要。 根据产生的影响不同，一般将风险分为三类：项目风险、产品风险和业务风险。下表给出了一些典型风险：编辑课件16风险类型风险类型可可 能能 的的 风风 险险技术技术系统使用的数据库的处理速度不

22、够快系统使用的数据库的处理速度不够快要复用的软件组件有缺陷，限制了项目的性能要复用的软件组件有缺陷，限制了项目的性能人员人员招聘不到符合项目技术要求的职员招聘不到符合项目技术要求的职员在项目的非常时刻，关键职员生病，无法发挥作用在项目的非常时刻，关键职员生病，无法发挥作用职员所需的培训跟不上职员所需的培训跟不上机构机构重新进行机构调整，由不同的管理层负责这个项目重新进行机构调整，由不同的管理层负责这个项目开发机构的财务出现问题，必须削减项目预算开发机构的财务出现问题，必须削减项目预算工具工具CASE工具产生的编码效率低工具产生的编码效率低CASE工具不能被集成工具不能被集成需求需求需求发生变化

23、，主体设计要返工需求发生变化，主体设计要返工客户不了解需求变更对项目造成的影响客户不了解需求变更对项目造成的影响估算估算低估了软件开发所需要的时间低估了软件开发所需要的时间低估了缺陷的修补率低估了缺陷的修补率低估了软件的规模低估了软件的规模下图是风险管理过程示意图风险识别风险识别风险分析风险分析风险规划风险规划风险监控风险监控潜在的风险潜在的风险列表列表优先级高的优先级高的风险列表风险列表风险规避和风险规避和应急计划应急计划风险评估风险评估(1) (1) 风险识别风险识别 风险识别是风险管风险识别是风险管理的第一阶段，其目理的第一阶段，其目的是发现可能的风险。的是发现可能的风险。右表给出了可能

24、的风右表给出了可能的风险及风险类型的实例。险及风险类型的实例。 这些风险将可能影这些风险将可能影响到软件产品、过程响到软件产品、过程或业务。或业务。编辑课件17(2) 风险分析 风险分析就是对每一个已经识别的风险，对其出现的可能性和影响的严重性作出判断。 风险出现可能性的评估大致可以有：非常小(75%)。风风 险险出现的可能性出现的可能性后果后果开发机构的财务出现问题，必须削减项目预算开发机构的财务出现问题，必须削减项目预算小小灾难性灾难性招聘不到符合项目技术要求的职员招聘不到符合项目技术要求的职员大大灾难性灾难性在项目的非常时刻，关键职员生病在项目的非常时刻，关键职员生病中等中等严重严重要复

25、用的软件组件有缺陷，限制了项目的性能要复用的软件组件有缺陷，限制了项目的性能中等中等严重严重需求发生变化，主体设计要返工需求发生变化，主体设计要返工中等中等严重严重开发机构调整，由不同的管理层负责这个项目开发机构调整，由不同的管理层负责这个项目大大严重严重系统使用的数据库的处理速度不够快系统使用的数据库的处理速度不够快中等中等严重严重低估了软件开发所需要的时间低估了软件开发所需要的时间大大严重严重CASE工具不能被集成工具不能被集成大大可容忍可容忍客户不了解需求变更对项目造成的影响客户不了解需求变更对项目造成的影响中等中等可容忍可容忍职员所需的培训跟不上职员所需的培训跟不上中等中等可容忍可容忍

26、低估了缺陷的修补率低估了缺陷的修补率中等中等可容忍可容忍低估了软件的规模低估了软件的规模大大可容忍可容忍CASE工具产生的编码效率低工具产生的编码效率低中等中等可忽略可忽略 风险影响大小的评估，可能的结果有：灾难性的、严重的、可以容忍的和可以忽略的。 右表是对上表已识别风险分析后得出的结果作成的表格： 这个表格的内容应随着项目的进展而更新。 经过风险分析和排序，就可以判断哪些风险是最重要需要优先关注的，以有利于项目的顺利开展。编辑课件18风风 险险策策 略略机构的财务风险机构的财务风险拟一份简短报告，提交高层管理者，说明这个项目将对业务目标有重大贡献拟一份简短报告，提交高层管理者，说明这个项目

27、将对业务目标有重大贡献职员招聘风险职员招聘风险稳定已有职员，加紧招聘工作，加紧已有低层职员的培训、培养稳定已有职员，加紧招聘工作，加紧已有低层职员的培训、培养职员生病风险职员生病风险重新对团队进行组织，使更多工作可以并发和重叠，员工可以了解他人工作重新对团队进行组织，使更多工作可以并发和重叠，员工可以了解他人工作有缺陷的组件有缺陷的组件购买更可靠、稳定的组件，替代有潜在缺陷的组件购买更可靠、稳定的组件，替代有潜在缺陷的组件需求变更需求变更导出可追溯信息来评估需求变更带来的影响，把隐藏在设计中的信息扩大化导出可追溯信息来评估需求变更带来的影响，把隐藏在设计中的信息扩大化机构调整机构调整拟一份简短

28、报告，提交高层管理者，说明这个项目将对业务目标有重大贡献拟一份简短报告，提交高层管理者，说明这个项目将对业务目标有重大贡献数据库的性能数据库的性能研究购买高性能数据库的可能性研究购买高性能数据库的可能性低估开发时间低估开发时间再次估算开发时间，对要使用的组件、开发环境的效用进行检查，明确资源再次估算开发时间，对要使用的组件、开发环境的效用进行检查，明确资源(3) 风险规划 风险规划过程就是对已识别的每一个重大风险，确定相应的处理策略。制定风险管理计划同样需要项目管理者的判断和经验。 下表给出了处理上表中严重和灾难性风险的可能的策略。风险规划的策略有三类：风险规划的策略有三类：- - 规避策略规

29、避策略：采用这些策略会降低风险出现的概率。如：采用这些策略会降低风险出现的概率。如“有缺陷的组件有缺陷的组件”- - 最低风险策略最低风险策略：采用这些策略会减少风险影响。如：采用这些策略会减少风险影响。如“职员生病风险职员生病风险”- - 应急计划应急计划：用以应对最严重的情形出现，以防万一。如：用以应对最严重的情形出现，以防万一。如“机构财务问题机构财务问题”编辑课件19风险类型风险类型潜在的特征潜在的特征技术技术硬件或支持软件延迟交付，暴露出现许多技术问题硬件或支持软件延迟交付，暴露出现许多技术问题人员人员职员工作士气低靡，团队成员之间关系不协调，工作分配不当职员工作士气低靡，团队成员之

30、间关系不协调，工作分配不当机构机构机构内说三道四，缺乏资深管理人员机构内说三道四，缺乏资深管理人员工具工具团队成员不愿使用工具，抱怨团队成员不愿使用工具，抱怨CASE工具，需要更强大的工作站工具，需要更强大的工作站需求需求很多需求变更请求以及客户怨言很多需求变更请求以及客户怨言估算估算跟不上双方协商的进度，无法除掉暴露出来的缺陷跟不上双方协商的进度，无法除掉暴露出来的缺陷(4) 风险监控 风险监控就是要对每一个识别的风险及其策略执行情况进行定期评估，从而确定风险出现可能性的变化趋势以及风险影响的后果是否有所改变。通常，这类信息是不可能直接观察到的，需要综合其它因素。 应该指出的是，风险监控应该

31、是一个持续不断的过程，在每一次对风险管理进行评估时，每一个重大的风险都应该进行单独的讨论和评估。 下表列举了一些典型因素的例子，可能会对评这些估风险类型有帮助。编辑课件207.3 7.3 软件测试计划和测试报告软件测试计划和测试报告 软件测试是软件开发完成，投入运行前，对软件需求、设计规格说明和编码的最终复审，软件质量保证的关键步骤，在软件开发的整个过程中，占有极为重要的位置。 软件测试文档主要包括：测试规划、测试策略、测试手段和测试结果。 由于测试工作的重要性，而人工测试又特别困难，因此，测试过程自动化会是测试技术发展的方向。1. 1. 软件测试、软件检查和调试软件测试、软件检查和调试 我们

32、已经知道软件测试的目的是尽可能多的发现系统存在的错误。我们已经知道软件测试的目的是尽可能多的发现系统存在的错误。所以，软件测试包括软件检查与软件测试。所以，软件测试包括软件检查与软件测试。- - 软件检查软件检查：对系统的各种表达形式，如文档、设计图和程序源代码等：对系统的各种表达形式，如文档、设计图和程序源代码等进行分析、检查，这一工作应贯穿整个开发过程。进行分析、检查，这一工作应贯穿整个开发过程。- - 软件测试软件测试：使用测试数据对软件的实现进行运行检查，查看系统的输：使用测试数据对软件的实现进行运行检查，查看系统的输出及运行行为是否符合设计要求。出及运行行为是否符合设计要求。编辑课件

33、21下图表示了软件检查和软件测试在软件过程中的位置软件检查软件检查需求描述需求描述高层设计高层设计形式化描述形式化描述详细设计详细设计程程 序序原原 型型软件测试软件测试 从图中可以看出，软件检查贯穿整个软件过程，而软件测试仅对原型或软件程序。 软件调试是一个对缺陷定位和修改的过程，同时也是一项技巧性很强的工作。软件调试，从软件测试的结果开始。如图所示。测试结果测试结果描描 述述测试用例测试用例定位错误定位错误设计修复设计修复修复错误修复错误回归测试回归测试编辑课件222. 2. 软件测试的成本软件测试的成本 由于测试不可能穷尽，因此，就有了软件测试的一个致命缺陷，即测试的不完全、不彻底性。因

34、此，对于任何程序只能进行少量的测试。当发现错误，可以说明程序有问题，而未发现错误，却不能声称程序没有错误。 根据软件工程的基本原理，当测试标准越高，则将要投入的人力、财力也越高。左图反映了测试成本的变化规律。 为在软件质量和投入之间取得需求平衡，可以采用著名的“进度、成本、质量”三角公式。如下右图，即只要确定了其中两项，就可以确定第三项。 因此，在编制软件测试计划时，必须考虑三者之间的关系。测试的程度测试的程度未发现的隐藏错误数未发现的隐藏错误数不足测试不足测试测试成本测试成本过度测试过度测试最佳测试点最佳测试点进度进度质量质量成本成本编辑课件233. 3. 软件测试的原则软件测试的原则测试时

35、，如果成功地实施了测试计划和方案，就能够发现系统中尽量多的错误。测试的一个附带收获是，能够证明软件的功能和性能是与需求说明相符的。要达成上述要求，就需要遵守以下原则：(1) (1) 测试规划应包含测试工作的全部内容测试规划应包含测试工作的全部内容。即不仅是程序测试，还包括文档。即不仅是程序测试，还包括文档(2) (2) 测试应贯穿软件开发的整个过程测试应贯穿软件开发的整个过程。即坚持各个阶段的评审，杜绝隐患。即坚持各个阶段的评审，杜绝隐患(3) (3) 测试用例应包括输入和预期输出测试用例应包括输入和预期输出。(4)(4) 设计测试用例时，输入应包括合理的和不合理的数据设计测试用例时，输入应包

36、括合理的和不合理的数据。(5) (5) 功能测试应由独立第三方完成功能测试应由独立第三方完成。但调试仍应由开发者自己完成。但调试仍应由开发者自己完成。(6) (6) 充分注意并利用测试中的群集现象充分注意并利用测试中的群集现象。(7) (7) 严格执行测试计划，排除测试随意性严格执行测试计划，排除测试随意性。计划应明确规定，不随意解释。计划应明确规定，不随意解释(8)(8) 应当对每一个测试结果做全面检查应当对每一个测试结果做全面检查。仔细分析测试结果，防止错误遗漏。仔细分析测试结果，防止错误遗漏(9)(9) 妥善保存测试计划、测试用例、出错统计和最终分析报告等测试文档妥善保存测试计划、测试用

37、例、出错统计和最终分析报告等测试文档。编辑课件244. 4. 软件测试过程软件测试过程从程序测试的角度看，测试分为两个阶段。如图从程序测试的角度看，测试分为两个阶段。如图单元单元( (构件构件) )测试测试集成集成( (组件组件) )测试测试软件开发者完成软件开发者完成独立测试团队承担独立测试团队承担程序测试过程的目的是尽可能多的发现并改正错误，提高软件质量。程序测试过程的目的是尽可能多的发现并改正错误，提高软件质量。测试过程的每一个阶段也都会对前一阶段有反馈信息。因此，测试过测试过程的每一个阶段也都会对前一阶段有反馈信息。因此，测试过程是一个不断修正和进化的过程。其阶段划分如下图所示程是一个

38、不断修正和进化的过程。其阶段划分如下图所示测试计划测试计划测试设计测试设计测试准备测试准备测试执行测试执行测试评估测试评估修正修正修正修正修正修正修正修正测试过程需要下面三个基础数据和资料的支持：测试过程需要下面三个基础数据和资料的支持：- -软件配置软件配置：软件正常运行的环境配置。：软件正常运行的环境配置。- - 测试配置测试配置：软件测试运行的环境配置，是软件配置的子集。：软件测试运行的环境配置，是软件配置的子集。- - 测试工具测试工具：为提高测试效率、降低测试劳动强度、保证测试质量使用的工具：为提高测试效率、降低测试劳动强度、保证测试质量使用的工具编辑课件25内内 容容说说 明明测试

39、过程测试过程描述测试过程的主要阶段描述测试过程的主要阶段需求跟踪需求跟踪用户最关心系统能否目要求，测试计划应包含对每项需求的单独测试用户最关心系统能否目要求，测试计划应包含对每项需求的单独测试测试项目测试项目软件需求测试的内容都应在此定义软件需求测试的内容都应在此定义测试时间安排测试时间安排给出总的时间安排和相应的资源分配给出总的时间安排和相应的资源分配测试记录测试记录测试所得到的结果、测试过程、执行情况等必须系统地记录测试所得到的结果、测试过程、执行情况等必须系统地记录软硬件需求软硬件需求列出测试所要使用的软件工具和测试环境列出测试所要使用的软件工具和测试环境约束约束需要考虑和预料的影响测试

40、过程的约束需要考虑和预料的影响测试过程的约束5. 5. 测试计划的导出与结构测试计划的导出与结构测试计划应该从系统描述和设计中导出。下图是测试计划从系统描述和设计中导出示意图需求描述需求描述系统描述系统描述系统设计系统设计详细设计详细设计单元代码单元代码测试测试验收测验收测试计划试计划系统集成系统集成测试计划测试计划子系统集成子系统集成测试计划测试计划服服 务务验收测试验收测试系统集成系统集成测试测试子系统集子系统集成测试成测试 测试计划的主测试计划的主要组成部分如右表要组成部分如右表所示所示编辑课件266. 6. 几种常见的测试用图表工具几种常见的测试用图表工具(1) 检查表 检查表是一张标

41、明了所要检查项目和内容的表格，可以用来突出重点和总结整个过程的关键点。优点是简洁、清晰。 典型的检查表如需求检查表、系统结构检查表、代码结构检查表、共性缺陷检查表等。 检查表因其重要性，目前已实现了自动化和智能化。如IBM Rochester软件开发中的PTF(program temporary fix，程序临时修补)检查表。(2) Pareto图 一个按下降次序排列的频率竖条图。通常，X轴表示缺陷产生的原因，Y轴表示缺陷数。下图就是一个软件产品缺陷原因的Pareto图。5040302010缺陷数缺陷数原因原因数据初始化数据初始化接口接口复杂逻辑复杂逻辑民族语言民族语言地址地址数据定义数据定义

42、编辑课件27(3) 直方图 是一种样本或总体的频率计数的图形表示。X轴自左至右按上升序列出某一个参数的单位间隔，Y轴为频率计数。直方图常用来表示某一参数的分布特性。如下图是一个软件产品按不同严重程度的缺陷频率和缺陷报告提交的天数直方图。10080604020总缺陷数的总缺陷数的%SEV2SEV1SEV3SEV4严重级别10080604020总缺陷数的总缺陷数的%8141715212228293536+缺陷报告提交的天数编辑课件287. 7. 设计软件测试设计软件测试(1) 缺陷测试设计 下图是缺陷测试的一般模型。其中，需要设计测试用例，给出测试预期结果。测试用例是对测试需要的输入和当前测试内容

43、的描述，运行结果需要和测试预期结果比较，以获得测试是否通过的结论。测试用例测试用例测试数据测试数据测试结果测试结果测试报告测试报告设计测设计测试用例试用例准备测准备测试数据试数据用测试数据用测试数据运行程序运行程序将结果与测将结果与测试预期比较试预期比较 理想的测试是使每个可能的程序运行顺序都能无遗漏的得到测试，然而这是不可能的。因此，测试需要基于一个可能的测试用例子集，制定和设计一个测试子集的选择策略。编辑课件29输输 入入 数数 据据预期输出结果预期输出结果运行输出结果运行输出结果结果是否正常结果是否正常期望的期望的非期望的非期望的正常测试输入数据正常测试输入数据1n导致反常的输入数据导致

44、反常的输入数据1m 黑盒测试 黑盒测试是将系统作为一个黑盒子，只通过系统输入，观察其相应的输出，来确定系统功能是否符合需求规格说明书的定义。因此，黑盒测试又称功能测试或数据驱动测试。黑盒测试的系统模型如下图。正常测试正常测试输入数据输入数据期望的输期望的输出结果出结果暴露缺陷的暴露缺陷的输出结果输出结果导致反导致反常的输常的输入数据入数据系系统统 黑盒测试方法即适合功能构成的系统，也适合对象构成的系统。测试的关键是要设计出有极大可能落在导致系统反常的输入数据集合中的那些输入。使用下表可以组织黑盒测试方法的输入和输出。编辑课件30输入条件输入条件有效等价类有效等价类无效等价类无效等价类 等价划分

45、 黑盒测试的一种方法。等价划分的测试方法就是把程序的输入域划分成若干不同性质得到的集合，在这些集合中，程序有基本一致的行为表现，然后从每个集合中选取少量有代表性的数据作为测试用例。下图就是等价划分测试的模型。系系统统无效输入无效输入有效输入有效输入输出输出 等价划分方法测试用例的设计要经历划分等价类和选取测试用例两步。等价类的划分可以使用等价类表描述。确定测试用例则需要根据等价类表，按以下确定测试用例则需要根据等价类表，按以下3 3个步骤进行：个步骤进行：- - 为每个等价类规定唯一编号为每个等价类规定唯一编号- - 设计一个测试用例，使其尽可能多的覆盖尚未覆盖的有效等价类，重复该步设计一个测

46、试用例，使其尽可能多的覆盖尚未覆盖的有效等价类，重复该步- - 设计测试用例，逐一覆盖所有无效等价类设计测试用例，逐一覆盖所有无效等价类编辑课件31 结构化测试 结构化测试是一种根据软件结构知识和实现知识所进行的测试方法。结构化测试也成为白盒测试。结构化测试的过程如下图所示。测试数据测试数据测试输出测试输出组件代码组件代码导出导出测试测试 结构化测试除了用于单元测试外，一般适合用于相对较小的程序，如一个子程序或对象的一个操作等。 结构化测试是通过代码分析来估计需要多少测试用例，以保证测试过程中，程序或组件中所有语句都至少遍历一遍。 路径测试 是结构化测试的一种策略。即在程序控制流程图的基础上，

47、通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。而设计出的测试用例要保证在测试中程序的每一个可执行语句都能至少执行一次。 在面向对象的程序开发过程中，路径测试在测试对象中的方法时，常会用到。程序中的路径数量通常与程序的长度成正比。编辑课件32(2) 集成测试设计 集成测试开始于系统组件、子系统或完整系统的组装完成时，其目的是发现组件交互中的问题。 集成测试的主要困难是在测试过程中对发现的错误的定位。一个好的方法是采用所谓的增量法。即先从一个集成度最小的系统配置开始测试，完成后一个增量一个增量的增加配置，然后逐步完成系统完整配置的测试。下图就是增量化集成测试的例子。ABT

48、1T2T3a.a. 测试序列1ABT1T2T3CT4b.b. 测试序列2ABT1T2T3c.c. 测试序列3CDT4T5编辑课件33 自顶向下的和自底向上的测试是两种不同的测试策略 在自顶向下的集成测试中，系统的高层组件在系统设计和实现完成之前进行集成和测试。如下图所示1 1级级1 1级级2 2级级2 2级级2 2级级测试序列测试序列 在自底向上的集成测试中，低层组件在高层组件开发出来之前进行集成和测试。如下图所示N N 级级N N 级级N N 级级N N 级级N N 级级N-1N-1级级N-1N-1级级N-1N-1级级测试驱测试驱动程序动程序测试驱测试驱动程序动程序测试测试序列序列编辑课件3

49、4 接口测试 当模块或子系统被集成时，就有一个事先定义的接口供其它组件调用。接口测试的目的就是检测因接口错误或对接口进行的无效假设而造成的系统缺陷。下图就是对接口测试的示意图。测试用例测试用例ABC 图中，指向方块边界的箭头表示测试用例不是只针对单个组件的，而是对组件构成的整个子系统的。 接口错误是对象之间交互的结果，而不是出于单个对象的行为。因此，接口错误是不可能通过对单个对象的测试发现的。 这种测试形式非常适合面向对象的系统。 强度测试 系统被完全集成后，就可以进行总体性能测试了。 为性能测试所设计的测试用例要保证能够测试到系统的正常负荷。通常，要设计出一系列的测试，使得系统的测试负荷能稳

50、步上升，直到系统达到性能极限。然后，强度测试继续使用测试用例测试，直到系统失败。这类测试有两个作用：检查系统的柔性；可能模拟到正常情况下的不寻常组合，以暴露系统正常情况下不会暴露的缺陷。编辑课件35(3) 面向对象的测试 尽管前面介绍的测试方法能够用于面向对象程序的测试，但是面向对象的测试还具有自己的另外一些特点。 面向对象的单元测试 以往单元测试的方法可继续沿用，实际测试类成员函数。对象的完全覆盖测试应包括： - 对象中所有操作被单独隔离的测试 - 对象中所有属性的设置和访问的测试 - 对象中所有可能状态的测试 如果使用了继承，则对类的测试应延伸到所有子类所继承的操作。编辑课件36 面向对象

51、的集成测试 由于面向对象程序中，类相互依赖极其紧密，根本无法在编译不完全的程序上对类进行测试。所以，面向对象的集成测试通常需要在整个程序编译完成后进行。此外，面向对象程序具有动态特性，程序的控制流往往无法确定，因此也只能对整个编译后的程序做基于黑盒的集成测试。 面向对象的集成测试能够发现相对独立的单元测试无法检出的那些类相互作用时才会产生的错误。具体设计测试用例，可参考以下步骤：- 选定检测的类，列出类的状态、行为、传递的消息，及输入/输出的界定等- 利用结构关系图确定待测类的所有关联，确定覆盖标准- 根据程序中类的对象构造测试用例，确认输入、服务和期望产生的行为等编辑课件378. 8. 软件测试计划文档软件测试计划文档 测试计划起到测试工作过程框架结构的功能，是好的测试工作的基础。一个测试计划的基本内容包括：基本情况分析、测试需求说明、测试策略和记录、测试资源配置、问题跟踪报告、测试计划的评审等。 基本情况分析。包括系统运行平台、应用领域、特点和主要功能模块等。分析要点有：测试目的和侧重点、系统适合于测试的内容/操作划分、测试的潜在风险、系统与测试相关的资料说明。 测试需求说明。列出测试功能项，规定应该测试的具体内容。 测试策略和记录。描述如何开展测试，规定测试记录的内容。必要时，应给出测试记录