小组软件开发过程9

1、第九章第九章 集成和系统测试集成和系统测试n本章主要内容：n测试原则n测试策略n测试计划n测试的度量与追踪n制作用户文档时要考虑的东西nTEST1和TESTn草案9.1 测试原则测试原则n在TSPi中，测试的目的是为了评估产品，测试的目的是为了评估产品，而不是为了修正它。而不是为了修正它。n在测试阶段以前你应该已经发现和修正了几乎全部的缺陷。n当对质量差的产品进行测试时，测试时间会急剧变长，而且你可能发现不了大多数的剩余缺陷。9.1 测试原则测试原则靠基于测试的质量策略让小系统相当可靠地工作要用去大量的时间。 9.1 测试原则测试原则n一个产品的质量是在它被开发时决定的。有无可辩驳的证据可以证

2、明，使用标准软件开发方法的工程师即使很有能力，也总是制作质量差的程序。结果，当对这些程序进行测试时，测试就要用去大量的时间，而且没法发现所有的问题。通常，当你测试一个质量差的产品时，测试之后你得到的仍是质量差的产品。9.1 测试原则测试原则它的测试用了6年。最后的10个严重缺陷是在经过了288个星期的测试之后才被发现的。这个过程比五年还要长。 9.2 TSPi测试策略测试策略n在TSPi中，目标就是对优质程序进行测试。然后，在测试中，你验证这个产品是否是高质量的。n主要的TSPi测试活动如下n（1）使用已开发的单元测试过的部分来建立系统。 建立建立n（2）集成测试这个系统来验证它是否被很适当地

3、建立起来了，所有的部分是否都存在，以及它们是否能共同工作。 集成测试集成测试n（3）系统测试这个产品来确认它满足了系统需求。 系统测试系统测试n在随后的开发周期中，回归测试回归测试也是必需的。9.2 TSPi测试策略测试策略n做以上这些的同时，你应进行以下活动。n（1）确认质量差的模块或部件，并将它们返还给质量/进度监督经理来进行评估和去除缺陷。n（2）确认那些除去缺陷之后仍令人头疼的质量差的部件，并将它们返还给质量/进度监督经理来进行返工或替换。9.3 建立和集成策略建立和集成策略n建立过程的目的是保证已存在所有需要的部分，装配好了一个工作系统，而且为这个系统提供好集成测试和系统测试。n集成

4、测试应该只检查所有的部件是否存在以及它们的调用和交互是否起作用。n不应该测试部件的功能。那些是在系统测试中做的。9.3 建立和集成策略建立和集成策略n9.3.1 Big-Bang策略策略n将所有的部分放在一起来观察它们是否能工作。n需要最少的测试开发。n然而，它很少成功，特别是对质量差的系统来说。n在集成测试中每KLOC发现10个或更多的缺陷就是不正常的，而修正在集成测试中发现的每个缺陷平均要花5到10小时。通常，系统越大、越复杂，用于诊断和修正每个缺陷的时间就越长。n除非你有非常高质量的部分，否则Big-Bang策略不是一个好主意。9.3 建立和集成策略建立和集成策略n9.3.2 每次一个策

5、略每次一个策略n每次添加一些部分。n相当快地让你发现问题原因。这个策略的不利之处在于要求更多的测试开发工作。9.3 建立和集成策略建立和集成策略n9.3.4 平面系统策略平面系统策略n建立一个平面系统首先集成所有最高层次部分，然后并行的一层层向下钻研。你可以一次测试所有的新部分或者一次加入一个部件。n这个策略的好处是你能在早期发现系统范围的问题。靠迅速建立系统的梗概，你能有最大程度的适应性。n平面系统策略的主要问题是，它通常要求大量的存根或特殊的框架提供对所有未得到的功能的空返回。9.3 建立和集成策略建立和集成策略n没有哪个集成策略是对所有系统都适用的。最好的方法是考虑所有的选择，选择出看来

6、最适合你的特定工程的一个。n几乎任何逻辑集成策略都将有用。n通常来说，请试着以适当小的增量来加入新代码。9.4 系统测试策略系统测试策略n在系统测试中，你要为四个问题寻找答案。n系统是否展示了其被要求具有的功能？n系统是否达到了它的质量目标？n在正常情况下系统是否能适当地运作？n在非正常情况下系统是否能适当地动作？9.4 系统测试策略系统测试策略n你可以首先测试系统每一个预期的功能。然后，你在重点条件下检查操作，评价可用性，以及最后衡量其执行。n这是最普通的系统测试策略。n用TSPi你应该有一个高质量的系统，而且应该能够进行更广泛的系统测试。n但对于广泛测试，功能第一的策略可能不是有效的。用仔

7、细设计的测试计划，你能用每个测试来评估几个产品特性。9.4 系统测试策略系统测试策略n第二种策略关注选出来的功能区，在进行到下一个功能区之前，这个功能区包含了每个区域的每个方面。n例如，你以测试正常和非正常情况下的数值运算、可用性、执行以及质量为开端。这种策略很大程度上消除了测试的重复，但它没有强调整体系统行为。仅在微观层次上测试的话，你可能没有充分地检查系统整体的执行情况。9.4 系统测试策略系统测试策略n第三种策略n将以上两种策略结合了起来。n开始对正常、非正常和重点行为下低层次的功能进行测试。n随后，进入高一点的层次，再测试功能结合后的情况，以保证它们能协同工作。n然后再一次在正常、非正

8、常和重点条件下检查它们。持续进行逐渐增高层次的测试，直至覆盖整个系统。n这种策略对于质量差的系统是必需的，因为许多系统功能最初完全不起作用。n对于大系统来说这种策略的不利之处在于它要花长时间来循序渐进地测试所有的重要功能的结合。9.4 系统测试策略系统测试策略n第四种策略：n最初，你要对最高层次的功能测试，n然后逐步向下，一次次进行正常和重点测试。n此处，你必须要靠一系列的操作轮廓，使用情形或测试草案来测试系统。尽管这种策略最快地包含了系统问题，但它仅对高质量的产品有效。通常你能从你的部件数据和建立与集成测试数据来决定产品质量。通常在集成之后，你应尽可能快地进入系统层次的测试。n如果你碰到了质

9、量问题，把出现问题的部件返还给质量经理进行修改或替换。9.5 测试计划测试计划n在TSPi过程中，有几处制作了测试计划。n如同在PSP中，首先制作一个概念性的测试计划，用来估计要开发的测试材料的大小，以及测试的开发和测试工作将用多长时间。n你需要有进行建立，集成测试和系统测试活动的测试计划。尽管建立和集成计划应该是简单的，但在你做之前对测试做计划仍是重要的。 9.5 测试计划测试计划n完整的测试计划描述了:n你计划运行什么测试，n以什么顺序运行它们，n以及每个测试所需的测试材料。n一个完整的计划应能够展示各个需求怎样被测试以及测试草案或脚本是怎样覆盖需求区域的。你还应该知道那些需求区域已被详细

10、测试过，那些还没有被详细测试。9.5 测试计划测试计划n此外，你应对每个预期的测试命名，定义它应该产生的结果，以及预测它可能运行多长时间。你还要估计在每个测试阶段发现的缺陷数，总共的修改缺陷时间，以及预测它可能运行多长时间。然后你要估计需要的测试材料的大小。除了LOC的大小估计外，你将可能需要对交互测试和测试数据的测试草案。对某些系统，测试数据的准备可能比测试情形的开发要求更多的工作。9.5 测试计划测试计划n在结束测试计划时，你应有：在结束测试计划时，你应有：n所有要执行的测试步骤清单；n每个测试所需要的支持材料；n测试产生的结果；n估计每个测试的无缺陷运行时间，发现的缺陷数，以及总时间；n

11、估计每个测试计划中要求开发的每个条款所需的工作的估计；9.5 测试计划测试计划n你还需要一个清单：你还需要一个清单：n所有需要的测试支持材料和它们支持的测试；n每个测试的目标；n期望这些材料是多大；n它们的开发可能要用多长时间；n由谁开发每个测试的支持条款；n这些开发任务何时完成。9.5 测试计划测试计划n最后，开发测试材料。最后，开发测试材料。n如果你计划一个重要的测试程序，你可能还要想自检的测试情形。它们依据设计的程序自动检查实际测试结果，而且提供一个输出，指示结果是否是正确的。对这样的测试情形，你能运行大量的测试，而且仅在最后看一下那些测试就能发现缺陷。通常，如果你缺乏一系列完整的测试工

12、具，开发自检的测试是没用的。9.6 跟踪和度量测试跟踪和度量测试n如果你预期运行许多测试，你将要关于测试有效性的数据。即是，作为运行时间的一个函数，每个测试揭示出多少个缺陷。n然后，你能使用这些缺陷/小时数据作为选择测试的标准，它包含反复测试的地址。根据经验包括先前已发现的缺陷所有测试的查复地址，以及验证最近开发周期内被修改的先前测试系统范围内的所有测试。9.6 跟踪和度量测试跟踪和度量测试n因为在每个TSPi开发周期中你将运行一个完整的测试集，所以有一些测试的度量是有用的。除了你记录在LOGD和LOGT中的数据外，你还需要回答下列问题。n远行这个测试要花多长时间？n它发现了多少个缺陷？n它是

13、否要求人工干涉，或它是否能与其它测试成批？n它是否自检？n为回答这些问题，你应记录关于测试运行时、发现缺陷数目和测试环境的数据。将这些数据保存在测试日志上是一种方便的方式。9.6 跟踪和度量测试跟踪和度量测试9.6.1 测试日志测试日志n以下是记录在测试日志中的几种信息。n测试运行的日期。n进行这个测试的人的姓名。n测试的运行，名字和/或编号。n被测试的产品和配置。n每个测试开始运行的时间。n每个测试结束运行的时间。n发现缺陷的数量，使用LOGD引用和编号。n测试结果。9.6 跟踪和度量测试跟踪和度量测试9.6.1 测试日志测试日志9.6 跟踪和度量测试跟踪和度量测试9.6.1 测试日志测试日

14、志n此外，你可能想包含下列几种信息。n被测试的系统配置。n任何使用了的特殊工具和设施。n操作员的干涉是否需要，需要多少。n记录基本的信息最简单的方式是记录在按时间顺序排列的日志中，它很时间记录日志。9.6 跟踪和度量测试跟踪和度量测试9.6.2 有缺陷倾向的模块有缺陷倾向的模块n大的IBM产品的样品质量表示在图9.3中。X轴表示开发测试中在每个部件上所发现的缺陷，y轴代表由顾客发现的缺陷。这意味着在测试中部件有很多缺陷时，在测试之后它可能仍有很多缺陷。换句话说，在测试中你发现的缺陷越多，那么你没有发现的缺陷也就越多。9.6 跟踪和度量测试跟踪和度量测试9.6.2 有缺陷倾向的模块有缺陷倾向的模

15、块n这指导人们能使用测试数据来评估有一或更多有缺陷倾向部分的系统风险。n为完成这个工作，要将模块的缺陷数据排序来发现每次测试中那个模块有最多的缺陷。n典型地，有最多缺陷的模块可能在测试之后仍有最多的缺陷。n如果一些模块看来特别差，应暂时停止来检查。这样做你常常能节约大量的测试时间，还能生产出高质量的产品。在继续测试以前，再检查和修正这些有缺陷倾向部件。 9.6 跟踪和度量测试跟踪和度量测试9.6.3 模块缺陷数据模块缺陷数据nTPSi工具提供两种方式来检查模块缺陷数据。nSUMDR表在左边的栏目中列出了模块名称和模块号码，在右边的栏目中列出了某阶段排除的缺陷数量。n你能制作一个对单个模块给出了

16、所有的质量测试的SUMQ表。n有了这些数据，你应该能很快确定有缺陷倾向的模块。n但要注意，在检查之时，你应该看一下每个产品开发周期的每一个清除缺陷阶段。然后你能确定一个模块问题开始出现的那个阶段。9.6 跟踪和度量测试跟踪和度量测试9.6.4 追踪缺陷数据追踪缺陷数据 n为追踪和分析有缺陷倾向的模块，你需要每个测试的有关每个缺陷的数据。n在每个星期的会议上，你还要和整个小组复核在建立、集成测试和系统测试中发现的缺陷。这些缺陷逃过了整个开发过程，所以它们的数据能为将来发现预防近似的缺陷提供重要的线索。以下是一些你能使用这些数据回答的问题。n缺陷逃过了那个过程的步骤？n你能怎样改变这些步骤以免缺陷

17、不再发生？n你能怎样修改开发过程来预防将来发生这些缺陷？n在系统的那里能存在未发现的类似缺陷？n现在你怎样发现这些缺陷并修改它们？9.6 跟踪和度量测试跟踪和度量测试9.6.4 追踪缺陷数据追踪缺陷数据 n在测试之后，质量/进度监督经理应带领整个小组复核建立、集成测试和系统测试的所有缺陷。然后让几名工程师寻找并修正你认为存在于系统中的未发现的缺陷。此外，用你确认的变化更新这个过程。9.7 文档文档n当情形牵涉了软件过程许多其它的部分时，文档是值得作为一门专门的课程的大标题。n本章包含了有关于软件文档的一些要点，为本标题的课本提供了参考。如果你学过科技写作课程，现在是一个学以致用的好机会。如果你

18、还没有学过那样的课程，现在是开始考虑这个重要标题的好机会。9.7 文档文档n在TSPi的测试阶段，小组部分成员起草并复核用户文档，而另一部分成员进行测试。尽管商业系统通常需要广泛的包括安装、维护、培训和市场需求的文档，但在TSPi中我们仅强调基本的用户文档。n分配给测试和文档的小组成员的比例根据产品的质量和功能内容变动。在最初的开发周期中，最好多分配一些工程师来测试。在以后的周期中，增加分配给文档的工程师数目。在以后的周期中，对测试开发的需求应降低。而文档工作量将可能随着产品附加功能的增多而增加。9.7 文档文档9.7.1 文档的重要性文档的重要性n文档是每个软件产品的必需部分。在许多方面，文

19、档比程序代码更重要。n把一个功能文档化的最佳时机是在设计完它之后。n如果你在完成设计之前制作了文档，你可能要做出很多改变。n另一方面，如果你将文档化工作推迟了太久，相对于设计思想在你的思想中还是新鲜时制作文档而言，这个工作将用去更长的时间。n因此TSPi包含了测试阶段的文档开发工作。对于较大的系统，这项工作应该开始得更早，并且持续到测试阶段。实际上，将测试用户文档作为系统测试的一部分是个好主意。9.7 文档文档 9.7.2 文档的设计文档的设计n书写有用的和有帮助的用户手册对软件工程师是充满了挑战性的。n注意避免：你只写了你做了什么，而没有写读者需要的。9.7 文档文档 9.7.2 文档的设计

20、文档的设计n决定手册质量的有用向导是看内容表。n如果手册是围绕着产品设计而组织，这本手册是一本差的文档。n一本精心设计的手册应关注读者的需求，而不是产品的结构。n通常，第一部分应该强调用户首先需要知道的：如何启动。然后，你可以解释用户功使用这个产品能做什么。最后，使人们容易查找他们所想知道的。 9.7 文档文档 9.7.2 文档的设计文档的设计n以下是一些建议：n使用词汇表来定义不在标准词典中的条款。n包含关于缺陷消息、故障检修步骤和恢复步骤的一节。n有一个关键论题的索引。n提供一个内容的细节表。9.7 文档文档 9.7.3 9.7.3 文档的提纲文档的提纲n文档化的第一步是制作详细提纲，从一

21、个高层提纲入手，然后进入细节。在开始书写文本之前，检查提纲来确认它包含用于建立所有关键的用户脚本。唯一的例外是那些在随后的开发周期中将要改变的脚本，现在描述它们可能是时间的浪费。n当你完成了提纲之后，和制作测试计划的工程师一起复核它，以确信你们以同样的方式理解同一个功能，而且没有人漏掉重要的东西。这种简单的检查常能发现群体本身不能发现的系统缺陷。文档和测试计划与设计所有使用的视角是不同的。实际上，小组常在文档和测试计划时比测试时发现更多的缺陷。9.7 文档文档 9.7.4 9.7.4 书写风格书写风格n通常：n应书写短句，n使用易懂的词和短语，n以及大量的清单和标准的条款。 9.7 文档文档

22、9.7.4 9.7.4 书写风格书写风格n例如，当解释一个类似于在TEST1草案中测试开发的一个程序时，应如下书写。测试开发 开发经理或其他人领导测试开发。测试小组成员执行他们的测试开发任务。 他们将测试开发任务分配给测试小组。 定义任何需要的建立的过程和程序。 开发集成测试程序和设施。 开发系统测试程序和设施。 估量每个测试的大小和运行时间。 复核测试材料和纠正缺陷。 9.7 文档文档 9.7.4 9.7.4 书写风格书写风格n避免以如下的段落形式书写清单。n开发经理或其替代者领导测试开发。测试小组的成员进行他们的测试开发计划。他们将测试开发任务分配给测试小组成员，定义任何需要的建立过程和程

23、序，开发集成测试程序和设施，开发系统测试程序和设施，对每个测试估量大小和运行时间，复核测试材料，还要修改缺陷。 9.7 文档文档 9.7.4 9.7.4 书写风格书写风格n文档质量文档必须是可读懂的文档，能够容易理解。若不是则必须重写。9.7 文档文档 9.7.5 文档的复核文档的复核n在复核中应检查的条款如下：n文档的组织：文档的组织：文档是围绕用户将做什么还是围绕产品内容而组织？用户文档强调用户的需要，而不应该是产品的结构或内容。n文档术语：文档术语：文档是否假定用户具有相关的知识？软件工程师常使用专业术语，即便作品是面向于不懂专业术语的人。任何在数据词典没有的词都应该被定义。n文档内容：

24、文档内容：文档是否包含了所有需要的材料？n准确性：准确性：方法和程序实际是否如所描述的那样有用？n可读性：可读性：文档是否易于阅读？大声地读它，看读所写的内容时是否感到舒适？n易懂性：易懂性：非专业的人是否能理解？这个问题通常是最难以回答的。最好的测试是招募一些先前不了解这个系统的人，要求他（或她）遵循用户手册来使用系统，然后观察你的主题的反应，记录下问题，对文档重新返工来强调这些问题。9.8 TSPi测试草案测试草案9.8.1 开始条件开始条件9.8 TSPi测试草案测试草案9.8.2 测试的开发测试的开发n在测试开发期间制作的几个条款。n（1）建立完整性测试。集成测试的第一步是检查系统是否

25、被建立，所有计划的部件是否被包含。把这个测试当作一个点名式的测试，测试是为了验证每个部件是否存在。应把这做成一个尽可能简单的测试包。对于小的系统，它甚至可能是一个人工程序。9.8 TSPi测试草案测试草案9.8.2 测试的开发测试的开发n在测试开发期间制作的几个条款。n（2）测试在正常和错误条件下的所有界面的集成程序。这些测试验证了建立是否产生了准备好系统测试的系统。从建立的完整性测试中，你知道了所有的部件是否被展示了。现在你要确信这个己建立的系统能够启动、运行，而且所有的部件能够调用其它部件，所有的系统界面是适配的，起作用的。这不是一个广泛的测试，它仅演示界面的匹配和功能的适当。9.8 TS

26、Pi测试草案测试草案9.8.2 测试的开发测试的开发n在测试开发期间制作的几个条款。n（3）集成测试材料。即使每一个测试都是简单的，但界面测试要求准备。因为你不得不在广泛的条件和参数值下测试许多界面，因此你可能想要一个简单的自动程序来进行测试，指示它们是否成功地结束。但对于小系统，手动驱动的界面测试就足够了。9.8 TSPi测试草案测试草案9.8.2 测试的开发测试的开发n在测试开发期间制作的几个条款。n（4）系统测试材料。这些材料应该测试在正常情况和系统资源紧张时所有的系统功能。它们还应该检查：在安装、升级、操作或恢复期间如何使用系统。系统测试还应该考虑可用性，执行，日期异常，以及数学纠正和

27、精度。因为这个产品的建立经过了几个周期，所以如果可能，你应该在第一周期就指导可用性和性能测试。在产品刚被建立之后修正性能和可用性问题是困难的。如果主要的变化被需要，它们必须在下一个开发周期得到最高优先权。9.8 TSPi测试草案测试草案9.8.2 测试的开发测试的开发n在测试开发期间制作的几个条款。n（5）每个测试期望结果的清楚说明。如果可能，使系统测试材料自包含。正如以前所标注的一样，不管结果是否正确，一个自包含的测试事件应列出实际结果。当你运行一大群测试时，这种能力允许你快速地检查那里是否有问题。使测试自包含可能要求额外的工作，但这常是一种好的投资，特别是对于你希望使用在下一个回归测试系统

28、建立中的测试。但如果你没有一个广泛的测试工具，提供自检能力的额外努力可能是不值得的。9.8 TSPi测试草案测试草案9.8.3 建立建立n建立的步骤：n（1）检查所有需要的部件以确保手边有它们，还要满足它们的依赖性需要。此处，部件依赖性是在基准系统中要求有用来支持部件的功能。例如数据库，缺陷处理能力以及设计支持在部件需要的功能得不到时，就需要专门的测试驱动或存根：检查它们是不是己计划了并可获得。这里可能也有其它的依赖性，诸如缺陷修补。例如因为界面错误，一个部件在先前的开发周期中被遗漏了。应检查那样的缺陷是否己被修正。9.8 TSPi测试草案测试草案9.8.3 建立建立n建立的步骤：n（2）复核

29、用于建立和确认遗漏部分的条款。确信系统在缺乏这些部分时仍能建立起来，还要确信这些需要在集成计划和测试开发期间同样被提出了。n（3）检查提议的对一致性和完整性的建立。这是最后一次对每个人工作的文件检查，以确认所有要求的部分都被包含，以及这些部件的建立是完全适合于集成测试的。n（4）建立产品。对于小的产品，这是由编译和链结系统部件，在测试日志（LOGTEST）中记录时间和在产品所有者的LOGD表中记录问题这些步骤构成。9.8 TSPi测试草案测试草案9.8.3 建立建立n如果缺陷在建立期间被发现，要决定是继续建立还是将一些部件返回给开发者修改。在LOGD表上报告缺陷，并要求质量/进度监督经理帮助你决定走那条路。如果修改能快速完成，你可以来重建。否则，你可能不得重新安排建立。9.8 TSPi测试草案测试草案9.8.4 集成集成n集成任务有以下几种。n检查已建立产品的完整性，对建立运行完整性检查，以检验所有这些需要的部分是否存在于建立中。n运行集成测试。运行计划的集成测试。n 对于这些测试