5.模块分解时应遵循的准则
（1）满足信息隐蔽原则。
（2）尽量使得模块的内聚度高，模块间的耦合度低。
（3）模块的大小适中（通常一个模块以50～100个语句行为适宜）。
（4）模块的调用深度不宜过大。一个模块A可以调用另一模块B，模块B还可调用模块C，称模块A直接调用模块B，模块A间接调用模块C，被间接调用的模块还可调其他模块，这样可形成一棵调用树，我们把以某个模块为根结点的调用树的深度称为该模块的调用深度。
（5）模块的扇入应尽量大，扇出不宜过大。一个模块的扇入是指直接调用该模块的上级模块个数。一个模块的扇出是指该模块直接调用的下级模块的个数。扇入大表示模块的复用程度高，扇出大表示模块的复杂度高。
（6）设计单入口和单出口的模块。
（7）模块的作用域应在控制域之内。模块的作用域是指受该模块内一个判定影响的所在模块的集合。模块的控制域是指该模块本身以及被该模块直接或间接调用的所有模块的集合。在设计时，作用域应是控制域的子集，作用域最好是做出判定的模块本身以及它的直属下级模块（直接调用的模块）。
（8）模块的功能应是可以预测的，功能可预测是指对相同的输入数据能产生相同的输出。
三、软件测试
在软件开发的一列活动中，为了保证软件的可靠性，人们研究并使用了很多方法进行分析、设计及编码实现。但是由于软件产品本身无形态，它是复杂的、知识高度密集的逻辑产品，其中不可能没有错误。物理产品在出厂前都要进行严格的检验，软件产品也不例外。软件开发总伴随着软件质量保证的活动，而软件测试是主要活动之一。软件测试代表了需求分析、设计、编码的最终复审。
测试是一项很艰苦的工作，其工作量约占软件开发总工作量的40%以上，特别对一些关系到人的生命安全的软件，共测试成本可能相当于开发阶段总成本的3～5倍。
（一）测试的基本概念1.测试的目的
软件测试的目的是尽可能多地发现软件产品（主要是指程序）中的错误和缺陷。
明确测试的目的是一件非常重要的事，因为在现实世界中对测试工作存在着许多模糊或者错误的看法，这些看法严重影响着测试工作的顺利进行。
有人认为测试是为了证明程序是正确的，也就是说程序不再有错误，事实证明这是不现实的。因为要通过测试来发现程序中的所有错误就要穷举所有可能的输入数据，检查它们是否产生正确的结果。例如，一个需要3个16位字长的整型输入数据的程序，输入数据的所有组合情况大约有3×10 14 种，若每组数据的测试时间为1ms，那么即使一年365天，每天24小时地测试，也大约需要1万年的时间。
2.测试用例
要进行测试，除了要有测试数据（或称输入数据）外，还应同时给出该组测试数据应该得以怎样的输出结果，我们称它为预期结果。在测试时将实际的输出结果与预期结果比较，若不同则表示发现了错误，因此测试用例是由测试数据和预期结果构成的。
为了发现程序中的错误，应竭力设计能暴露错误的测试用例。一个好的测试用例是极有可能发现迄今为止尚未发现的错误的测试用例。一次成功的测试是发现了至今为止尚未发现的错误的测试。
3.测试的原则
基于上述测试目的，我们可以考虑以下有关测试的原则:
（1）确定预期输出结果是测试用例必不可少的一部分。如果只有测试数据而无预期结果，那么就不易判断测试结果是否正确。
（2）程序员应避免测试自己的程序，程序设计机构不应测试自己的程序。这是因为程序中的错误往往是由于程序员对问题说明的误解，由他来测试自己的程序就不易找出因这种误解而产生的错误。此外，开发程序是一项建设性的工作，而测试则是一项破坏性的工作（证明程序有错），这对开发人员或机构来说在心理上是难以容忍的。为了证明自己的程序没有错误或错误很少，他们往往不去选择容易发现错误的测试用例，而选择容易通过的测试用例。当然，这并不意味着程序员都不能测试自己的程序，如单元测试通常就是由程序员自己测试的。
（3）彻底检查每个测试结果。如果不仔细检查测试结果，有些已经测试出来的错误也可能被遗漏掉。
（4）对非法的非预期的输入数据也要像合法的和预期的输入数据一样编写测试用例。
（5）检查程序是否做了应做的事是成功的一半，另一半是看程序是否做了不该做的事。
（6）除了真正没有用的程序外，一定不要扔掉测试用例。因为在改正错误或程序维护后还要进行重新测试。
（7）在规划测试时不要设想程序中不会查出错误。
（8）程序模块经测试后，残存的错误数目往往与已发现的错误数目成比例。实践证明，程序中的大量错误仅与少量的程序模块有关，因此当A模块找出的错误比B模块多得多时，很可能A模块残存的错误仍比B模块残存的错误多多。
4.白盒测试和黑盒测试
测试的关键是测试用例的设计，其方法可分成两类:白盒测试和黑盒测试。
白盒测试是把程序看成装在一只透明的白盒子里，测试者完全了解程序结构和处理过程。它根据程序的内部逻辑来设计测试用例，检查程序中的逻辑通路是否都按预定的要求正确地工作。黑盒测试是把程序看成一只黑盒子，测试者完全不了解（或不考虑）程序的结构和处理过程。它根据规格说明书规定的功能来设计测试用例，检查程序的功能是否符合规格说明的要求。
（二）测试步骤
软件测试的主要步骤有单元测试、集成测试和确认测试。
1.单元测试（unit testing）
单元测试也称模块测试。通常单元测试可放在编码阶段，程序员在编写好一个模块后，总会（也应该）对自己编写的模块进行测试，检查它是否实现了详细设计说明书中规定的模块功能和算法。单元测试主要发现编码和详细设计中产生的错误，通常采用白盒测试。
测试一个模块时需要编写一个驱动模块和若干个桩（stub）模块，如下图所示。驱动模块的功能是向被测试模块提供测试数据，驱动（即调用）被测模块，并从被测模块中接受测试结果。桩模块的功能是模拟被模块所调用的子模块，它接受被测模块的调用，检验调用参数，模拟被
调用的子模块功能，把结果送回给被测模块。在模块结构图中，顶层模块测试时不需要驱动模块，最底层的模块测试时不需要桩模块。
2.集成测试（integration testing）
集成测试也称组装测试，它是对由各模块组装而成的程序进行测试，主要检查模块间的接口和通信。集成测试主要发现设计阶段产生的错误，通常采用黑盒测试。
集成的方式可分成非渐增式集成和渐增式集成。非渐增式集成是先测试所有的模块，然后把这些模块集成在一起对整个程序进行测试。渐增式集成是将单元测试和集成测试合并在一起，它根据模块结构图，按某种次序选一个尚未测试的模块，把它同已经测试好的模块组合在一起对整个程序进行测试，每次增加一个模块，直至所有模块全部集成在程序中。
渐增式集成又可分成自顶向下集成和自底向上集成。自顶向下集成先测试上层模块，再测试下层模块。由于测试下层模块时它的上层模块已测试过，所以可以用其上层模块作为它的驱动模块，而不必另编驱动模块。自底向上集成先测试下层模块，再测试上层模块。同样道理，在自底向上集成时可用下层模块作为上层模块的桩模块，而不必另外编写桩模块。
3.确认测试（walidation testing）
确认测试的任务是检查软件的功能、性能及其他特征是否与用户的需求一致，它是以需求规格说明书（即需求规约）作为依据的测试。确认测试通常采用黑盒测试。
确认测试首先测试程序是否满足需求规格说明书所列的各项要求，然后要进行软件配置复查，特别是文档是否齐全，各方面的质量是否符合要求等。如果一个软件是为某个客户定制的，那么最后由客户来实施验收测试（acceptance testing），以便客户确认该软件是否他所需要的。如果一个软件是作为产品被许多客户使用的话，那不可能为每个客户进行验收测试。大多数软件生产者使用一种Alpha测试和Beta测试的过程，来揭露仅由最终用户才能发现的错误。
Alpha测试是在开发者的现场由客户来实施的，被测试的软件是在开发者从用户的角度进行常规设置的环境下运行的。Beta测试是在一个或多个客户的现场由该软件的最终用户实施的。与Alpha测试不同的是，Beta测试时开发者通常是不在场的。Alpha测试和Beta测试除了进一步发现程序中的错误外，还能发现使用上的问题。经过确认测试后的软件通常就可交付使用了。
