软件文档写作管理文档.pptx

《软件文档写作管理文档.pptx》由会员分享，可在线阅读，更多相关《软件文档写作管理文档.pptx（40页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

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

2、几个方面的作用：管理文档有以下几个方面的作用：维护人员维护人员软件开发软件开发管理人员管理人员软件开发人员软件开发人员软件操作软件操作人员人员用户用户软件管软件管理文档理文档第1页/共40页管理文档的作用主要体现在三个方面是软件开发各阶段工作成果的体现把软件开发过程中的一些“不可见”的事物转换成“可见”的文字资料提供了管理人员、开发人员、操作人员和用户之间相互沟通、协调的窗口2第2页/共40页37.2 7.2 项目开发计划项目开发计划 项项目目开开发发计计划划又又称称软软件件定定义义文文档档，是是和和软软件件本本身身一一样样重重要要的的知识资产，是项目启动后第一件最重要的工作。知识资产，是项目

3、启动后第一件最重要的工作。项项目目开开发发计计划划一一般般包包括括资资源源需需求求、工工作作分分解解、工工作作目目标标、开开发发团团队队及及人人员员安安排排、进进度度安安排排、内内外外接接口口约约定定、风风险险分分析析以以及及软软件质量控制机制等。件质量控制机制等。1.1.项目开发计划书项目开发计划书 项项目目开开发发计计划划书书的的具具体体内内容容随随着着项项目目和和开开发发机机构构类类型型的的不不同同而而不不同同，一一般般都会包括以下几个部分：都会包括以下几个部分：项目目标项目目标。简述项目目标，并列出影响管理的约束条件，如预算、时间。简述项目目标，并列出影响管理的约束条件，如预算、时间

4、开发团队及人员安排开发团队及人员安排。阐述团队组织方式、人员构成及分工。阐述团队组织方式、人员构成及分工 软硬件资源需求软硬件资源需求。分析和列出所需资源，注明估算的资源需要时间及价格。分析和列出所需资源，注明估算的资源需要时间及价格 工作分解工作分解。分解项目为一系列活动，确定项目里程碑及可交付文档。分解项目为一系列活动，确定项目里程碑及可交付文档 项目进度项目进度。描述项目各活动之间的依赖关系、到达里程碑的时间等。描述项目各活动之间的依赖关系、到达里程碑的时间等 风险分析风险分析。分析项目可能存在的风险、发生的可能性及应对风险的策略。分析项目可能存在的风险、发生的可能性及应对风险的策略 监

5、控机制监控机制。制定详细、可操作的项目监控机制，明确管理报告的递交时间。制定详细、可操作的项目监控机制，明确管理报告的递交时间 开发估算开发估算。包括规模、工作量、成本等的估算，要求依据并积累历史数据。包括规模、工作量、成本等的估算，要求依据并积累历史数据第3页/共40页4 制定项目开发计划的过程被称为项目策划。制定项目开发计划的过程被称为项目策划。由由于于计计划划所所具具有有的的在在时时间间上上的的提提前前性性，项项目目开开发发计计划划通通常常会会经经常常性性的的修修正正，有有些些部部分分甚甚至至会会频频繁繁的的改改变！变！而而部部分分内内容容的的变变化化，会会影影响响开开发发计计划划的的正

6、正确确性性和和符符合合性性，使使其其越越来来越越偏偏离离项项目目实实际际，最最后后变变得得没没有有价价值值。如如随随着着项项目目需需求求的的逐逐渐渐明明确确引引起起的的项项目目计计划划细细化化、项目可提供资源变化引起的项目计划的变化等。项目可提供资源变化引起的项目计划的变化等。所所以以，在在实实际际工工作作中中，需需要要有有明明确确的的责责任任人人和和操操作作原原则则，来来对对项项目目计计划划实实施施维维护护，并并对对项项目目计计划划的的变变更实施必要的控制。更实施必要的控制。另另一一个个重重要要的的方方面面是是，在在组组织织文文档档时时，就就要要考考虑虑到到这这种种频频繁繁变变更更的的需需要

7、要，使使得得当当变变更更发发生生时时，文文档档的的相应部分能够容易替换。相应部分能够容易替换。第4页/共40页52.2.工作分解结构工作分解结构 工工作作分分解解结结构构(work(work breakdown breakdown structure,structure,WBS)WBS)是是对对整整个个项项目目工工作作的的分分级级描描述述，是是项项目目计计划划开开发发的的第第一一步步。分分解解示示意意如如下图所示。下图所示。目标目标活动活动活动活动活动活动活动活动活动活动活动活动1 1级级2 2级级m m级级工作包工作包任务任务1 1任务任务2 2任务任务3 3 任务任务n n活动活动工工作作

8、分分解解结结构构设设计计一一般可以采用般可以采用2 2种方法：种方法：-自自上上而而下下的的方方法法。从从项项目目的的目目标标开开始始，逐逐步步分分解解，直直到到具具体任务体任务-自自下下而而上上的的方方法法。也也称称集集思思广广益益法法。即即从从底底层层开开始始，逐逐层层集集成成，最最后后汇汇合合后后完成目标完成目标第5页/共40页6工作分解工作分解结构主要有结构主要有4 4个用途个用途：1.1.思路工具思路工具：可以描述项目的整体思路，是一个计划和设：可以描述项目的整体思路，是一个计划和设计的工具；计的工具；2.2.结构设计工具结构设计工具：是项目工作的结构图，可以清晰表达项：是项目工作的

9、结构图，可以清晰表达项目各项工作间的相互关系；目各项工作间的相互关系；3.3.计划工具计划工具：能够展示项目全貌，说明为完成项目所需完：能够展示项目全貌，说明为完成项目所需完成的各项活动；成的各项活动；4.4.项目状态报告工具项目状态报告工具：可以作为项目状态报告的框架。随：可以作为项目状态报告的框架。随着低一级项目活动的完成，项目由下而上不断整合，某着低一级项目活动的完成，项目由下而上不断整合，某一项工作的完成将成为里程碑，所以，工作分解结构就一项工作的完成将成为里程碑，所以，工作分解结构就定义了里程碑事件。定义了里程碑事件。第6页/共40页73.3.项目里程碑与阶段性文档项目里程碑与阶段性

10、文档 由由于于软软件件产产品品是是无无形形的的，因因此此，管管理理者者需需要要通通过过文文档档的的形形式式获获得信息，了解软件的开发状况，以作出管理的决定。得信息，了解软件的开发状况，以作出管理的决定。里里程程碑碑的的建建立立，可可以以描描述述软软件件开开发发活活动动一一个个过过程程的的终终结结。在在每每个个里里程程碑碑，都都有有一一个个正正式式的的可可以以提提交交给给管管理理层层的的阶阶段段性性结结果果。比比如如，一份报告。一份报告。里里程程碑碑报报告告的的内内容容不不拘拘，以以能能清清楚楚说说明明阶阶段段性性结结果果为为标标准准，应应能代表项目中一个特定逻辑意义上的阶段的终结。能代表项目中

11、一个特定逻辑意义上的阶段的终结。要要建建立立里里程程碑碑，软软件件过过程程就就一一定定要要分分解解成成一一系系列列相相关关的的基基本本活活动动，而而每每个个基基本本活活动动都都要要有有相相应应的的输输出出结结果果。如如下下图图，是是一一个个需需求求描述中的活动，其中每个活动都有主要输出。描述中的活动，其中每个活动都有主要输出。可行性研究可行性研究需求分析需求分析原型开发原型开发设计研究设计研究需求描述需求描述可行性报告可行性报告用户需求用户需求估算报告估算报告体系结构设计体系结构设计系统需求系统需求第7页/共40页84.4.项目进度项目进度 项目管理者要求估算完成各项活动所需的时间和资源，并将

12、它们严密的组织起来，以安排项目进度。不同的项目，具有不同的项目开发进度。初始的项目进度安排往往是不精确的，但随着项目进展信息的不断增多，进度安排也会越来越接近项目实际进度，因此，必须不断更新项目进度。项目进度包括将一个项目分解为若干独立的活动，以及判断完成这些活动所需的时间。通常，有些活动是可以并行的，项目管理者应组织并协调这些并行的工作。项目进度过程见下图：识别活动识别活动识别活动识别活动依赖关系依赖关系估算活动估算活动的资源的资源为活动分为活动分配资源配资源创建项目创建项目图表图表软件需求软件需求活动图表及条形图活动图表及条形图第8页/共40页9 在进度估算时，管理者需要有一定的余量。在进

13、度估算时，管理者需要有一定的余量。如如项项目目难难度度大大，则则花花费费的的时时间间也也会会较较多多。又又如如，项项目目个个别别开开发发人人员员可可能能发发生生的的变变动动，硬硬件件环环境境的的变变化化等等，都都是是在在估估算算项目进度时必须考虑的因素。项目进度时必须考虑的因素。除除了了时时间间和和人人员员、环环境境的的变变化化，资资源源和和预预算算也也需需要要考考虑虑适适当的余量。当的余量。恰恰当当的的估估算算方方法法是是采采用用“理理想想实实际际”方方式式。即即先先估估算算理理想想值值，然然后后逐逐步步加加入入预预计计出出现现的的状状况况、偶偶然然因因素素致致成成的的状状况况、项目开发人员

14、的素质和经验项目开发人员的素质和经验 作作为为经经验验数数据据，一一般般在在最最初初估估算算的的基基础础上上增增加加30%30%作作为为实实际际可可能能发发生生的的状状况况值值，再再预预留留20%20%的的估估算算值值给给所所谓谓不不可可预预见见的其它问题，则进度估算的结果会较符合实际。的其它问题，则进度估算的结果会较符合实际。第9页/共40页任任 务务持续时间持续时间(天数天数)依依 赖赖 关关 系系T1T18 8T2T21515T3T31515T1(M1)T1(M1)T4T41010T5T51010T2T2，T4(M2)T4(M2)T6T65 5T1T1，T2(M3)T2(M3)T7T72

15、020T1(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)105.5.运用图和表描述项目进度运用图和表描述项目进度 项目进度可以采用图表工具更直观的表示任务分解、活动依赖关系和人员分配情况等。下表是一个“任务的持续时间及其依赖关系”的例子。第10页/共40页11甘特图法(Gantt Chart)的例子tw12345678ABCD当前进度当前进度优点：简单，能动态地反映优点：简单，能动态地反映

16、开发进程开发进程缺点：难以反映多个任务间的缺点：难以反映多个任务间的逻辑关系逻辑关系条形图和活动网络图是表示项目进度的两种图形表示法。(1)条形图。又称甘特图法(Gantt Chart)，可以表示面向活动的负责人是谁，以及活动的开始和结束时间。如下图所示的例子。第11页/共40页12012345678 codingA testingA debuggingAB coding understandingC modifyingC testingB testingC debuggingB debuggingC testingABC012356789 codingA testingA debugging

17、A understandingC modifyingC testingB testingC debuggingB debuggingC testingABC4 debuggingAB coding 例：开发三个模块A、B、C。A为公用模块，B、C的测试须等A的调试完成后进行。A的编码需6天，测试8天，调试6天。B的编码需7天，测试8天，调试6天。C利用已有的模块，须先理解原模块8天，再修改8天，测试9天，调试7天。最后三模块集成测试需5天完成。(2)活动网络图。又称网络计划法 表示构成一个项目的不同活动之间的依赖关系。是用网状图表安排与控制各项活动的方法。最适合反映多个工作之间的逻辑关系。第1

18、2页/共40页13持续时间持续时间Lasting Time机动时间机动时间Slack Time编编号号EarliestStart TimeLatestStart Time012345678941363029222014126006142082028293641(0)(0)(15)(4)(2)(4)(0)(2)(0)(2)(0)(0)686678886975(1)标出标出 Lasting Time(2)标出标出 EST:=从起点始，所有进从起点始，所有进入事件的入事件的 EST+LT 中最大的中最大的(3)标出标出 LST:=从终点从终点(EST=LST)始，所有离开事件的始，所有离开事件的 L

19、ST LT 中最小的中最小的(4)标出标出 ST:=终点终点LST 起点起点EST LT(5)标出标出Key Path：即即EST=LST的的所有事件组成的路径所有事件组成的路径通常，甘特图适合按开发阶段安排，以作项目总体进度控制。网络计划法便于在细节上安排人力，适合按开发阶段或子项目的工作步骤安排。第13页/共40页风风 险险风险类型风险类型风风 险险 描描 述述职员跳槽职员跳槽项目项目有经验的职员未完成项目就跳槽有经验的职员未完成项目就跳槽管理层变更管理层变更项目项目不同的管理层考虑、关注的事情会不同不同的管理层考虑、关注的事情会不同硬件缺乏硬件缺乏项目项目项目所需的基础硬件没有按期交付项

20、目所需的基础硬件没有按期交付需求变更需求变更项目和产品项目和产品软件需求与预期的相比，将会有较大变化软件需求与预期的相比，将会有较大变化描述延迟描述延迟项目和产品项目和产品有关主要接口的描述未按期完成有关主要接口的描述未按期完成低估了系统规模低估了系统规模项目和产品项目和产品过低估计了系统的规模过低估计了系统的规模CASECASE工具性能较差工具性能较差产品产品支持项目的支持项目的CASECASE工具达不到要求工具达不到要求技术变更技术变更业务业务系统的基础技术被新技术取代系统的基础技术被新技术取代产品竞争产品竞争业务业务系统还未完成，其它有竞争力的产品就已经上市了系统还未完成，其它有竞争力的

21、产品就已经上市了146.6.风险管理风险管理 由于绝大多数软件项目都存在不确定性，因此，风险管理对软件项目而言就尤为重要。根据产生的影响不同，一般将风险分为三类：项目风险、产品风险和业务风险。下表给出了一些典型风险：第14页/共40页风险类型风险类型可可 能能 的的 风风 险险技术技术系统使用的数据库的处理速度不够快系统使用的数据库的处理速度不够快要复用的软件组件有缺陷，限制了项目的性能要复用的软件组件有缺陷，限制了项目的性能人员人员招聘不到符合项目技术要求的职员招聘不到符合项目技术要求的职员在项目的非常时刻，关键职员生病，无法发挥作用在项目的非常时刻，关键职员生病，无法发挥作用职员所需的培训

22、跟不上职员所需的培训跟不上机构机构重新进行机构调整，由不同的管理层负责这个项目重新进行机构调整，由不同的管理层负责这个项目开发机构的财务出现问题，必须削减项目预算开发机构的财务出现问题，必须削减项目预算工具工具CASE工具产生的编码效率低工具产生的编码效率低CASE工具不能被集成工具不能被集成需求需求需求发生变化，主体设计要返工需求发生变化，主体设计要返工客户不了解需求变更对项目造成的影响客户不了解需求变更对项目造成的影响估算估算低估了软件开发所需要的时间低估了软件开发所需要的时间低估了缺陷的修补率低估了缺陷的修补率低估了软件的规模低估了软件的规模15下图是风险管理过程示意图风险识别风险识别风

23、险分析风险分析风险规划风险规划风险监控风险监控潜在的风险潜在的风险列表列表优先级高的优先级高的风险列表风险列表风险规避和风险规避和应急计划应急计划风险评估风险评估(1)(1)风险识别风险识别 风风险险识识别别是是风风险险管管理理的的第第一一阶阶段段，其其目目的的是是发发现现可可能能的的风风险险。右右表表给给出出了了可可能能的的风风险及风险类型的实例。险及风险类型的实例。这这些些风风险险将将可可能能影影响响到到软软件件产产品品、过过程程或业务。或业务。第15页/共40页16(2)风险分析 风险分析就是对每一个已经识别的风险，对其出现的可能性和影响的严重性作出判断。风险出现可能性的评估大致可以有：

24、非常小(75%)。风风 险险出现的可能性出现的可能性后果后果开发机构的财务出现问题，必须削减项目预算开发机构的财务出现问题，必须削减项目预算小小灾难性灾难性招聘不到符合项目技术要求的职员招聘不到符合项目技术要求的职员大大灾难性灾难性在项目的非常时刻，关键职员生病在项目的非常时刻，关键职员生病中等中等严重严重要复用的软件组件有缺陷，限制了项目的性能要复用的软件组件有缺陷，限制了项目的性能中等中等严重严重需求发生变化，主体设计要返工需求发生变化，主体设计要返工中等中等严重严重开发机构调整，由不同的管理层负责这个项目开发机构调整，由不同的管理层负责这个项目大大严重严重系统使用的数据库的处理速度不够快

25、系统使用的数据库的处理速度不够快中等中等严重严重低估了软件开发所需要的时间低估了软件开发所需要的时间大大严重严重CASE工具不能被集成工具不能被集成大大可容忍可容忍客户不了解需求变更对项目造成的影响客户不了解需求变更对项目造成的影响中等中等可容忍可容忍职员所需的培训跟不上职员所需的培训跟不上中等中等可容忍可容忍低估了缺陷的修补率低估了缺陷的修补率中等中等可容忍可容忍低估了软件的规模低估了软件的规模大大可容忍可容忍CASE工具产生的编码效率低工具产生的编码效率低中等中等可忽略可忽略 风险影响大小的评估，可能的结果有：灾难性的、严重的、可以容忍的和可以忽略的。右表是对上表已识别风险分析后得出的结果

26、作成的表格：这个表格的内容应随着项目的进展而更新。经过风险分析和排序，就可以判断哪些风险是最重要需要优先关注的，以有利于项目的顺利开展。第16页/共40页风风 险险策策 略略机构的财务风险机构的财务风险拟一份简短报告，提交高层管理者，说明这个项目将对业务目标有重大贡献拟一份简短报告，提交高层管理者，说明这个项目将对业务目标有重大贡献职员招聘风险职员招聘风险稳定已有职员，加紧招聘工作，加紧已有低层职员的培训、培养稳定已有职员，加紧招聘工作，加紧已有低层职员的培训、培养职员生病风险职员生病风险重新对团队进行组织，使更多工作可以并发和重叠，员工可以了解他人工作重新对团队进行组织，使更多工作可以并发和

27、重叠，员工可以了解他人工作有缺陷的组件有缺陷的组件购买更可靠、稳定的组件，替代有潜在缺陷的组件购买更可靠、稳定的组件，替代有潜在缺陷的组件需求变更需求变更导出可追溯信息来评估需求变更带来的影响，把隐藏在设计中的信息扩大化导出可追溯信息来评估需求变更带来的影响，把隐藏在设计中的信息扩大化机构调整机构调整拟一份简短报告，提交高层管理者，说明这个项目将对业务目标有重大贡献拟一份简短报告，提交高层管理者，说明这个项目将对业务目标有重大贡献数据库的性能数据库的性能研究购买高性能数据库的可能性研究购买高性能数据库的可能性低估开发时间低估开发时间再次估算开发时间，对要使用的组件、开发环境的效用进行检查，明确

28、资源再次估算开发时间，对要使用的组件、开发环境的效用进行检查，明确资源17(3)风险规划 风险规划过程就是对已识别的每一个重大风险，确定相应的处理策略。制定风险管理计划同样需要项目管理者的判断和经验。下表给出了处理上表中严重和灾难性风险的可能的策略。风险规划的策略有三类：风险规划的策略有三类：-规避策略规避策略：采用这些策略会降低风险出现的概率。如：采用这些策略会降低风险出现的概率。如“有缺陷的组件有缺陷的组件”-最低风险策略最低风险策略：采用这些策略会减少风险影响。如：采用这些策略会减少风险影响。如“职员生病风险职员生病风险”-应急计划应急计划：用以应对最严重的情形出现，以防万一。如：用以应

29、对最严重的情形出现，以防万一。如“机构财务问题机构财务问题”第17页/共40页风险类型风险类型潜在的特征潜在的特征技术技术硬件或支持软件延迟交付，暴露出现许多技术问题硬件或支持软件延迟交付，暴露出现许多技术问题人员人员职员工作士气低靡，团队成员之间关系不协调，工作分配不当职员工作士气低靡，团队成员之间关系不协调，工作分配不当机构机构机构内说三道四，缺乏资深管理人员机构内说三道四，缺乏资深管理人员工具工具团队成员不愿使用工具，抱怨团队成员不愿使用工具，抱怨CASE工具，需要更强大的工作站工具，需要更强大的工作站需求需求很多需求变更请求以及客户怨言很多需求变更请求以及客户怨言估算估算跟不上双方协商

30、的进度，无法除掉暴露出来的缺陷跟不上双方协商的进度，无法除掉暴露出来的缺陷18(4)风险监控 风险监控就是要对每一个识别的风险及其策略执行情况进行定期评估，从而确定风险出现可能性的变化趋势以及风险影响的后果是否有所改变。通常，这类信息是不可能直接观察到的，需要综合其它因素。应该指出的是，风险监控应该是一个持续不断的过程，在每一次对风险管理进行评估时，每一个重大的风险都应该进行单独的讨论和评估。下表列举了一些典型因素的例子，可能会对评这些估风险类型有帮助。第18页/共40页197.3 7.3 软件测试计划和测试报告软件测试计划和测试报告 软件测试是软件开发完成，投入运行前，对软件需求、设计规格说

31、明和编码的最终复审，软件质量保证的关键步骤，在软件开发的整个过程中，占有极为重要的位置。软件测试文档主要包括：测试规划、测试策略、测试手段和测试结果。由于测试工作的重要性，而人工测试又特别困难，因此，测试过程自动化会是测试技术发展的方向。1.1.软件测试、软件检查和调试软件测试、软件检查和调试 我我们们已已经经知知道道软软件件测测试试的的目目的的是是尽尽可可能能多多的的发发现现系系统统存存在在的的错错误误。所以，软件测试包括软件检查与软件测试。所以，软件测试包括软件检查与软件测试。-软软件件检检查查：对对系系统统的的各各种种表表达达形形式式，如如文文档档、设设计计图图和和程程序序源源代代码码等

32、等进行分析、检查，这一工作应贯穿整个开发过程。进行分析、检查，这一工作应贯穿整个开发过程。-软软件件测测试试：使使用用测测试试数数据据对对软软件件的的实实现现进进行行运运行行检检查查，查查看看系系统统的的输输出及运行行为是否符合设计要求。出及运行行为是否符合设计要求。第19页/共40页20下图表示了软件检查和软件测试在软件过程中的位置软件检查软件检查需求描述需求描述高层设计高层设计形式化描述形式化描述详细设计详细设计程程 序序原原 型型软件测试软件测试 从图中可以看出，软件检查贯穿整个软件过程，而软件测试仅对原型或软件程序。软件调试是一个对缺陷定位和修改的过程，同时也是一项技巧性很强的工作。软

33、件调试，从软件测试的结果开始。如图所示。测试结果测试结果描描 述述测试用例测试用例定位错误定位错误设计修复设计修复修复错误修复错误回归测试回归测试第20页/共40页212.2.软件测试的成本软件测试的成本 由于测试不可能穷尽，因此，就有了软件测试的一个致命缺陷，即测试的不完全、不彻底性。因此，对于任何程序只能进行少量的测试。当发现错误，可以说明程序有问题，而未发现错误，却不能声称程序没有错误。根据软件工程的基本原理，当测试标准越高，则将要投入的人力、财力也越高。左图反映了测试成本的变化规律。为在软件质量和投入之间取得需求平衡，可以采用著名的“进度、成本、质量”三角公式。如下右图，即只要确定了其

34、中两项，就可以确定第三项。因此，在编制软件测试计划时，必须考虑三者之间的关系。测试的程度测试的程度未未发发现现的的隐隐藏藏错错误误数数不足测试不足测试测试成本测试成本过度测试过度测试最佳测试点最佳测试点进度进度质量质量成本成本第21页/共40页223.3.软件测试的原则软件测试的原则测试时，如果成功地实施了测试计划和方案，就能够发现系统中尽量多的错误。测试的一个附带收获是，能够证明软件的功能和性能是与需求说明相符的。要达成上述要求，就需要遵守以下原则：(1)(1)测试规划应包含测试工作的全部内容测试规划应包含测试工作的全部内容。即不仅是程序测试，还包括文档。即不仅是程序测试，还包括文档(2)(

35、2)测试应贯穿软件开发的整个过程测试应贯穿软件开发的整个过程。即坚持各个阶段的评审，杜绝隐患。即坚持各个阶段的评审，杜绝隐患(3)(3)测试用例应包括输入和预期输出测试用例应包括输入和预期输出。(4)(4)设计测试用例时，输入应包括合理的和不合理的数据设计测试用例时，输入应包括合理的和不合理的数据。(5)(5)功能测试应由独立第三方完成功能测试应由独立第三方完成。但调试仍应由开发者自己完成。但调试仍应由开发者自己完成。(6)(6)充分注意并利用测试中的群集现象充分注意并利用测试中的群集现象。(7)(7)严格执行测试计划，排除测试随意性严格执行测试计划，排除测试随意性。计划应明确规定，不随意解释

36、。计划应明确规定，不随意解释(8)(8)应当对每一个测试结果做全面检查应当对每一个测试结果做全面检查。仔细分析测试结果，防止错误遗漏。仔细分析测试结果，防止错误遗漏(9)(9)妥善保存测试计划、测试用例、出错统计和最终分析报告等测试文档妥善保存测试计划、测试用例、出错统计和最终分析报告等测试文档。第22页/共40页234.4.软件测试过程软件测试过程从程序测试的角度看，测试分为两个阶段。如图从程序测试的角度看，测试分为两个阶段。如图单元单元(构件构件)测试测试集成集成(组件组件)测试测试软件开发者完成软件开发者完成独立测试团队承担独立测试团队承担程序测试过程的目的是尽可能多的发现并改正错误，提

37、高软件质量。程序测试过程的目的是尽可能多的发现并改正错误，提高软件质量。测试过程的每一个阶段也都会对前一阶段有反馈信息。因此，测试过测试过程的每一个阶段也都会对前一阶段有反馈信息。因此，测试过程是一个不断修正和进化的过程。其阶段划分如下图所示程是一个不断修正和进化的过程。其阶段划分如下图所示测试计划测试计划测试设计测试设计测试准备测试准备测试执行测试执行测试评估测试评估修正修正修正修正修正修正修正修正测试过程需要下面三个基础数据和资料的支持：测试过程需要下面三个基础数据和资料的支持：-软件配置软件配置：软件正常运行的环境配置。：软件正常运行的环境配置。-测试配置测试配置：软件测试运行的环境配置

38、，是软件配置的子集。：软件测试运行的环境配置，是软件配置的子集。-测试工具测试工具：为提高测试效率、降低测试劳动强度、保证测试质量使用的工具：为提高测试效率、降低测试劳动强度、保证测试质量使用的工具第23页/共40页内内 容容说说 明明测试过程测试过程描述测试过程的主要阶段描述测试过程的主要阶段需求跟踪需求跟踪用户最关心系统能否目要求，测试计划应包含对每项需求的单独测试用户最关心系统能否目要求，测试计划应包含对每项需求的单独测试测试项目测试项目软件需求测试的内容都应在此定义软件需求测试的内容都应在此定义测试时间安排测试时间安排给出总的时间安排和相应的资源分配给出总的时间安排和相应的资源分配测试

39、记录测试记录测试所得到的结果、测试过程、执行情况等必须系统地记录测试所得到的结果、测试过程、执行情况等必须系统地记录软硬件需求软硬件需求列出测试所要使用的软件工具和测试环境列出测试所要使用的软件工具和测试环境约束约束需要考虑和预料的影响测试过程的约束需要考虑和预料的影响测试过程的约束245.5.测试计划的导出与结构测试计划的导出与结构测试计划应该从系统描述和设计中导出。下图是测试计划从系统描述和设计中导出示意图需求描述需求描述系统描述系统描述系统设计系统设计详细设计详细设计单元代码单元代码测试测试验收测验收测试计划试计划系统集成系统集成测试计划测试计划子系统集成子系统集成测试计划测试计划服服

40、务务验收测试验收测试系统集成系统集成测试测试子系统集子系统集成测试成测试 测测试试计计划划的的主主要要组组成成部部分分如如右右表表所所示示第24页/共40页256.6.几种常见的测试用图表工具几种常见的测试用图表工具(1)检查表 检查表是一张标明了所要检查项目和内容的表格，可以用来突出重点和总结整个过程的关键点。优点是简洁、清晰。典型的检查表如需求检查表、系统结构检查表、代码结构检查表、共性缺陷检查表等。检查表因其重要性，目前已实现了自动化和智能化。如IBM Rochester软件开发中的PTF(program temporary fix，程序临时修补)检查表。(2)Pareto图 一个按下降

41、次序排列的频率竖条图。通常，X轴表示缺陷产生的原因，Y轴表示缺陷数。下图就是一个软件产品缺陷原因的Pareto图。5040302010缺缺陷陷数数原因原因数据初始化数据初始化接口接口复杂逻辑复杂逻辑民族语言民族语言地址地址数据定义数据定义第25页/共40页26(3)直方图 是一种样本或总体的频率计数的图形表示。X轴自左至右按上升序列出某一个参数的单位间隔，Y轴为频率计数。直方图常用来表示某一参数的分布特性。如下图是一个软件产品按不同严重程度的缺陷频率和缺陷报告提交的天数直方图。10080604020总总缺缺陷陷数数的的%SEV2SEV1SEV3SEV4严重级别10080604020总总缺缺陷陷

42、数数的的%8141715212228293536+缺陷报告提交的天数第26页/共40页277.7.设计软件测试设计软件测试(1)缺陷测试设计 下图是缺陷测试的一般模型。其中，需要设计测试用例，给出测试预期结果。测试用例是对测试需要的输入和当前测试内容的描述，运行结果需要和测试预期结果比较，以获得测试是否通过的结论。测试用例测试用例测试数据测试数据测试结果测试结果测试报告测试报告设计测设计测试用例试用例准备测准备测试数据试数据用测试数据用测试数据运行程序运行程序将结果与测将结果与测试预期比较试预期比较 理想的测试是使每个可能的程序运行顺序都能无遗漏的得到测试，然而这是不可能的。因此，测试需要基于

43、一个可能的测试用例子集，制定和设计一个测试子集的选择策略。第27页/共40页输输 入入 数数 据据预期输出结果预期输出结果运行输出结果运行输出结果结果是否正常结果是否正常期望的期望的非期望的非期望的正常测试输入数据正常测试输入数据1n导致反常的输入数据导致反常的输入数据1m28 黑盒测试 黑盒测试是将系统作为一个黑盒子，只通过系统输入，观察其相应的输出，来确定系统功能是否符合需求规格说明书的定义。因此，黑盒测试又称功能测试或数据驱动测试。黑盒测试的系统模型如下图。正常测试正常测试输入数据输入数据期望的输期望的输出结果出结果暴露缺陷的暴露缺陷的输出结果输出结果导致反导致反常的输常的输入数据入数据

44、系系统统 黑盒测试方法即适合功能构成的系统，也适合对象构成的系统。测试的关键是要设计出有极大可能落在导致系统反常的输入数据集合中的那些输入。使用下表可以组织黑盒测试方法的输入和输出。第28页/共40页输入条件输入条件有效等价类有效等价类无效等价类无效等价类29 等价划分 黑盒测试的一种方法。等价划分的测试方法就是把程序的输入域划分成若干不同性质得到的集合，在这些集合中，程序有基本一致的行为表现，然后从每个集合中选取少量有代表性的数据作为测试用例。下图就是等价划分测试的模型。系系统统无效输入无效输入有效输入有效输入输出输出 等价划分方法测试用例的设计要经历划分等价类和选取测试用例两步。等价类的划

45、分可以使用等价类表描述。确定测试用例则需要根据等价类表，按以下确定测试用例则需要根据等价类表，按以下3 3个步骤进行：个步骤进行：-为每个等价类规定唯一编号为每个等价类规定唯一编号-设计一个测试用例，使其尽可能多的覆盖尚未覆盖的有效等价类，重复该步设计一个测试用例，使其尽可能多的覆盖尚未覆盖的有效等价类，重复该步-设计测试用例，逐一覆盖所有无效等价类设计测试用例，逐一覆盖所有无效等价类第29页/共40页30 结构化测试 结构化测试是一种根据软件结构知识和实现知识所进行的测试方法。结构化测试也成为白盒测试。结构化测试的过程如下图所示。测试数据测试数据测试输出测试输出组件代码组件代码导出导出测试测

46、试 结构化测试除了用于单元测试外，一般适合用于相对较小的程序，如一个子程序或对象的一个操作等。结构化测试是通过代码分析来估计需要多少测试用例，以保证测试过程中，程序或组件中所有语句都至少遍历一遍。路径测试 是结构化测试的一种策略。即在程序控制流程图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。而设计出的测试用例要保证在测试中程序的每一个可执行语句都能至少执行一次。在面向对象的程序开发过程中，路径测试在测试对象中的方法时，常会用到。程序中的路径数量通常与程序的长度成正比。第30页/共40页31(2)集成测试设计 集成测试开始于系统组件、子系统或完整系统的组装完

47、成时，其目的是发现组件交互中的问题。集成测试的主要困难是在测试过程中对发现的错误的定位。一个好的方法是采用所谓的增量法。即先从一个集成度最小的系统配置开始测试，完成后一个增量一个增量的增加配置，然后逐步完成系统完整配置的测试。下图就是增量化集成测试的例子。ABT1T2T3a.a.测试序列1ABT1T2T3CT4b.b.测试序列2ABT1T2T3c.c.测试序列3CDT4T5第31页/共40页32 自顶向下的和自底向上的测试是两种不同的测试策略 在自顶向下的集成测试中，系统的高层组件在系统设计和实现完成之前进行集成和测试。如下图所示1 1级级1 1级级2 2级级2 2级级2 2级级测试序列测试序

48、列 在自底向上的集成测试中，低层组件在高层组件开发出来之前进行集成和测试。如下图所示N N 级级N N 级级N N 级级N N 级级N N 级级N-1N-1级级N-1N-1级级N-1N-1级级测试驱测试驱动程序动程序测试驱测试驱动程序动程序测试测试序列序列第32页/共40页33 接口测试 当模块或子系统被集成时，就有一个事先定义的接口供其它组件调用。接口测试的目的就是检测因接口错误或对接口进行的无效假设而造成的系统缺陷。下图就是对接口测试的示意图。测试用例测试用例ABC 图中，指向方块边界的箭头表示测试用例不是只针对单个组件的，而是对组件构成的整个子系统的。接口错误是对象之间交互的结果，而不是

49、出于单个对象的行为。因此，接口错误是不可能通过对单个对象的测试发现的。这种测试形式非常适合面向对象的系统。强度测试 系统被完全集成后，就可以进行总体性能测试了。为性能测试所设计的测试用例要保证能够测试到系统的正常负荷。通常，要设计出一系列的测试，使得系统的测试负荷能稳步上升，直到系统达到性能极限。然后，强度测试继续使用测试用例测试，直到系统失败。这类测试有两个作用：检查系统的柔性；可能模拟到正常情况下的不寻常组合，以暴露系统正常情况下不会暴露的缺陷。第33页/共40页34(3)面向对象的测试 尽管前面介绍的测试方法能够用于面向对象程序的测试，但是面向对象的测试还具有自己的另外一些特点。面向对象

50、的单元测试 以往单元测试的方法可继续沿用，实际测试类成员函数。对象的完全覆盖测试应包括：-对象中所有操作被单独隔离的测试 -对象中所有属性的设置和访问的测试 -对象中所有可能状态的测试 如果使用了继承，则对类的测试应延伸到所有子类所继承的操作。第34页/共40页35 面向对象的集成测试 由于面向对象程序中，类相互依赖极其紧密，根本无法在编译不完全的程序上对类进行测试。所以，面向对象的集成测试通常需要在整个程序编译完成后进行。此外，面向对象程序具有动态特性，程序的控制流往往无法确定，因此也只能对整个编译后的程序做基于黑盒的集成测试。面向对象的集成测试能够发现相对独立的单元测试无法检出的那些类相互