软件测试毕业设计.doc

阜阳师范学院本科毕业设计题目：班级管理系统的测试 学 号：姓 名：年 级：系 别： 专 业：完成日期： 指导老师： 班级管理系统的测试姓名： 学号： 指导教师： 摘要 在软件生命周期的各个阶段，都有可能会产生差错。虽然在每个阶段结束之前都有严格的复审，以期望能尽早的发现错误，但是经验表明审查并不能发现所有差错。如果在软件投入生产性运行之前，没有发现大部分错误，则这些错误迟早会在运行过程中暴露出来，甚至造成严重的后果，等到那时去改这些错误的代价会很高。测试的目的就是在软件投入生产性运行之前，尽可能地发现软件中的错误，测试是对软件规格说明、设计和编码的最后复审，所以软件测试贯穿在整个软件开发期的全过程。要对软件进行测试首先要明白软件要实现的功能，否则无法对软件进行测试。本文在分析软件测试的方法、目的、流程图等基本概念的基础上，重点介绍了对自己开发的班级管理系统的测试。关键词：安装测试、功能测试、性能测试、单元测试1. 软件测试的概念 1.1软件测试的定义 软件测试（Software testing）是软件生存期（Software life cycle）中的一个重要阶段，是软件质量保证的关键步骤。通俗地讲，软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码进行最终复审的活动。1983年IEEE提出的软件工程术语中给软件测试下的定义是：“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。这个定义明确指出：软件测试的目的是为了检验软件系统是否满足需求。从用户的角度来看，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，所以软件测试应该是“为了发现错误而执行程序的过程”。或者说，软件测试应该根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误或缺陷。1.2 软件测试的目的、原则、基本要求1.2.1 测试的目的1.检验开发出来的软件是否符合用户的需求。2.尽可能多地发现程序中的错误和缺陷。1.2.2 基本要求(测试人员)1.了解软件的总体设计思路和详细设计过程2.对整套软件的数据流程要十分清晰1.2.3 测试用例由测试数据和相应的预期结果构成。在测试之前，一定要设计好测试数据和相应的预期结果，这是测试用例的基本原则和进行有效测试的最好途径之一1.2.4 测试原则1. 根据测试数据来确定预期的输出结果。2. 彻底检查每个测试结果(正确的、错误的),并对测试结果进行认真和仔细的分析。3. 对非法的和非预期的输入数据也要像合法的和预期的输入数据一样编写测试用例。4. 以挑剔的眼光来看待每个程序模块,不要设想程序中不会出现错误。程序做了它不该做的事情,即使是正确的,我们也应该把它视为错误。5. 程序模块经测试后,残存的错误数目一般与已发现的错误数目成正比例。也就是说,一个模块中发现的错误越多,那么它可能残存的错误数目也就越多,对这样的程序模块,一定要进行严格和更彻底的测试。6. 要保存测试用例。2. 软件测试的方法 21 软件测试的基本方法软件测试的方法和技术是多种多样的。对于软件测试技术，可以从不同的角度加以分类：从是否需要执行被测软件的角度，可分为静态测试和动态测试。从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测试。2.1.1 黑盒测试 黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边界值分析、因果图、错误推测等，主要用于软件确认测试。 “黑盒” 法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒” 法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。2.1.2 白盒测试白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。2.1.3 ALAC(Act-like-a-customer)测试软件有好多错误图ALAC测试客户通常会遇到错误只占很小比例改进测试的有效性，使测试针对哪些客户最容易遇到的错误图（1）ALAC测试是一种基于客户使用产品的知识开发出来的测试方法。ALAC测试是基于复杂的软件产品有许多错误的原则。最大的受益者是用户，缺陷查找和改正将针对哪些客户最容易遇到的错误。 2.2 单元测试的基本方法单元测试的对象是软件设计的最小单位模块。单元测试的依据是详细设计描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试。 2.2.1 单元测试任务单元测试任务包括：1 模块接口测试；2 模块局部数据结构测试；3 模块边界条件测试；4 模块中所有独立执行通路测试；5 模块的各条错误处理通路测试。模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。测试接口正确与否应该考虑下列因素：1. 输入的实际参数与形式参数的个数是否相同和属性是否匹配；2. 输入的实际参数与形式参数的量纲是否一致；3. 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；4. 调用其他模块时所给实际参数的属性是否与被调模块的形参的属性是否匹配；5. 调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；6. 调用预定义函数时所用参数的个数、属性和次序是否正确；7. 是否存在与当前入口点无关的参数引用；8. 是否修改了只读型参数；9. 对全程变量的定义各模块是否一致；10.是否把某些约束作为参数传递。如果模块内包括外部输入输出，还应该考虑下列因素：1. 文件属性是否正确；2. OPEN/CLOSE语句是否正确；3. 格式说明与输入输出语句是否匹配；4. 缓冲区大小与记录长度是否匹配；5. 文件使用前是否已经打开；6. 是否处理了文件尾；7. 是否处理了输入/输出错误；8. 输出信息中是否有文字性错误； 检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：1. 不合适或不相容的类型说明；2. 变量无初值；3. 变量初始化或缺省值有错；4. 不正确的变量名（拼错或不正确地截断）； 5. 出现上溢、下溢和地址异常。除了局部数据结构外，如果可能，单元测试时还应该查清全局数据对模块的影响。在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括：1. 误解或用错了算符优先级；2. 混合类型运算；3. 变量初值错；4. 精度不够；5. 表达式符号错。比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误： 1. 不同数据类型的对象之间进行比较；2. 错误地使用逻辑运算符或优先级；3. 因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；4. 比较运算或变量出错；5. 循环终止条件或不可能出现；6. 迭代发散时不能退出；7. 错误地修改了循环变量。 一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列问题：1. 输出的出错信息难以理解；2. 记录的错误与实际遇到的错误不相符；3. 在程序自定义的出错处理段运行之前，系统已介入；4. 异常处理不当；5. 错误陈述中未能提供足够的定位出错信息。边界条件测试是单元测试中最后，也是最重要的一项任务。众所周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。2.2.2 单元测试过程一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。应为测试模块开发一个驱动模块（driver）和（或）若干个桩模块（stub）,下图显示了一般单元测试的环境。驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，“主程序”打印“进入-退出”消息。驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用。若驱动和桩模块比较简单，实际开销相对低些。遗憾的是，仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用下面讨论的综合测试方法。提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。图（2）2.3 综合测试的基本方法时常有这样的情况发生，每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作。主要原因是，模块相互调用时接口会引入许多新问题。例如，数据经过接口可能丢失；一个模块对另一模块可能造成不应有的影响；几个子功能组合起来不能实现主功能；误差不断积累达到不可接受的程度；全局数据结构出现错误，等等。综合测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行综合测试以便发现与接口有关的各种错误。某设计人员习惯于把所有模块按设计要求一次全部组装起来，然后进行整体测试，这称为非增量式集成。这种方法容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是增量式集成方法，程序一段一段地扩展，测试的范围一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。下面讨论两种增量式集成方法。2.3.1 自顶向下集成自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。深度优先策略首先是把主控制路径上的模块集成在一起，至于选择哪一条路径作为主控制路径，这多少带有随意性，一般根据问题的特性确定。以图（3）为例，若选择了最左一条路径，首先将模块M1，M2，M5和M8集成在一起，再将M6集成起来，然后考虑中间和右边的路径。广度优先策略则不然，它沿着控制层次结构水平地向下移动。仍然以下图为例，它首先把M2、M3和M4与主控模块集成在一起，再将M5和M6 和其他模块集成起来。自顶向下综合测试的具体步骤为：1. 以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际 模块替代；2. 依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块； 3. 每集成一个模块立即测试一遍；4. 只有每组测试完成后，才着手替换下一个桩模块；5. 为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。 图（3）从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕。上图（3）中，实线表示已部分完成的结构，若采用深度优先策略，下一步将用模块M7替换桩模块S7，当然M7本身可能又带有桩模块，随后将被对应的实际模块一一替代。自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验，因此较早地发现错误。缺点是在测试较高层次模块时，低层处理采用桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，因此测试并不充分。解决这个问题有几种办法，第一种是把某些测试推迟到用真实模块替代桩模块之后进行，第二种是开发能模拟真实模块的桩模块；第三种是自底向上集成模块。第一种方法又回退为非增量式的集成方法，使错误难于定位和纠正，并且失去了在组装模块时进行一些特定测试的可能性；第二种方法无疑要大大增加开销；第三种方法比较切实可行，下面专门讨论。2.3.2 自底向上集成自底向上测试是从“原子”模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。自底向上综合测试的步骤分为： 1. 把低层模块组织成实现某个子功能的模块群（cluster）； 2. 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出； 3. 对每个模块群进行测试；4. 删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。从第一步开始循环执行上述各步骤，直至整个程序构造完毕。图(4)说明了上述过程。首先“原子”模块被分为三个模块群，每个模块群引入一个驱动模块进行测试。因模块群1、模块群2中的模块均隶属于模块Ma，因此在驱动模块D1、D2去掉后，模块群1与模块群2直接与Ma接口，这时可对Ma、D3被去掉后，M3与模块群3直接接口，可对Mb进行集成测试，最后Ma、Mb和 Mc全部集成在一起进行测试。 自底向上集成方法不用桩模块，测试用例的设计亦相对简单，但缺点是程序最后一个模块加入时才具有整体形象。它与自顶向综合测试方法优缺点正好相反。因此，在测试软件系统时，应根据软件的特点和工程的进度，选用适当的测试策略，有时混和使用两种策略更为有效，上层模块用自顶向下的方法，下层模块用自底向上的方法。此外，在综合测试中尤其要注意关键模块，所谓关键模块一般都具有下述一或多个特征：对应几条需求；具有高层控制功能；复杂、易出错；有特殊的性能要求。关键模块应尽早测试，并反复进行回归测试。图（4）2.4 确认测试的基本方法 通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步确认测试即可开始。确认测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。2.4.1 确认测试标准实现软件确认要通过一系列黑盒测试。确认测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，目的在说明软件与需求是否一致。无论计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。 确认测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。2.4.2 配置复审确认测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序，并且包括软件维护所必须的细节。2.4.3 、测试事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解，等等。因此，软件是否满足用户要求，应由用户进行一系列“验收测试”。验收测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为、测试的过程，以期望发现那些似乎只有最终用户才能发现的问题。测试是指软件开发组织内部人员模拟各类用户行对即将面市软件产品（称为版本）进行测试，试图发现错误并修正。测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。经过测试调整的软件产品称为版本。紧随其后的测试是指软件开发组织各方面的典型用户在日常工作中实际使用版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对版本进行改错和完善。2.5 系统测试的基本方法 计算机软件是基于计算机系统的一个重要组成部分，软件开发完毕后应与系统中其它成分集成在一起，此时需要进行一系列系统集成和确认测试。对这些测试的详细讨论已超出软件工程的范围，这些测试也不可能仅由软件开发人员完成。在系统测试之前，软件工程师应完成下列工作：（1） 为测试软件系统的输入信息设计出错处理通路；（2） 设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助；（3） 参与系统测试的规划和设计，保证软件测试的合理性。系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能够正常工作并完成所赋予的任务。下面简单讨论几类系统测试。2.5.1 恢复测试恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。2.5.2 安全测试安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。2.5.3 强度测试强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。 2.5.4 性能测试对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一个测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。3. 软件测试的误区 随着软件规模的不断扩大，软件设计的复杂程度不断提高，软件开发中出现错误或缺陷的机会越来越多。同时，市场对软件质量重要性的认识逐渐增强。所以，软件测试在软件项目实施过程中的重要性日益突出。但是现实情况是与软件编程比较，软件测试的地位和作用，还没有真正受到重视，对于很多人（甚至是软件项目组的技术人员）还存在对软件测试的认识误区，这进一步影响了软件测试活动的开展和真正提高软件测试质量。3.1 误区之一：软件开发完成后进行软件测试人们一般认为，软件项目要经过以下几个阶段：需求分析，概要设计，详细设计，软件编码，软件测试，软件发布。因此，认为软件测试只是软件编码后的一个过程。这是不了解软件测试周期的错误认识。软件测试是一个系列过程活动，包括软件测试需求分析，测试计划设计，测试用例设计，执行测试。因此，软件测试贯穿于软件项目的整个生命过程。在软件项目的每一个阶段都要进行不同目的和内容的测试活动，以保证各个阶段的正确性。软件测试的对象不仅仅是软件代码，还包括软件需求文档和设计文档。软件开发与软件测试应该是交互进行的，例如，单元编码需要单元测试，模块组合阶段需要集成测试。如果等到软件编码结束后才进行测试，那么测试的时间将会很短，测试的覆盖面将很不全面，测试的效果也将大打折扣。更严重的是如果此时发现了软件需求阶段或概要设计阶段的错误，如果要修复该类错误，将会耗费大量的时间和人力。3.2 误区之二：软件发布后如果发现质量问题，那是软件测试人员的错这种认识容易打击软件测试人员的积极性。软件中的错误可能来自软件项目中的各个过程，软件测试只能确认软件存在错误，不能保证软件没有错误，因为从根本上讲，软件测试不可能发现全部的错误。从软件开发的角度看，软件的高质量不是软件测试人员测出来的，是靠软件生命周期的各个过程中设计出来的。出现软件错误，不能简单地归结为某一个人的责任，有些错误的产生可能不是技术原因，可能来自于混乱的项目管理。应该分析软件项目的各个过程，从过程改进方面寻找产生错误的原因和改进的措施。3.3 误区之三：软件测试要求不高，随便找个人都行很多人都认为软件测试就是安装和运行程序，点点鼠标，按按键盘的工作。这是由于不了解软件测试的具体技术和方法造成的。随之软件工程学的发展和软件项目管理经验的提高，软件测试已经形成了一个独立的技术学科，演变成一个具有巨大市场需求的行业。软件测试技术不断更新和完善，新工具，新流程，新测试设计方法都在不断更新，需要掌握和学习很多测试知识。所以，具有编程经验的程序员不一定是一名优秀的测试工程师。软件测试包括测试技术和管理两个方面，完全掌握这两个方面的内容，需要很多测试实践经验和不断学习精神。3.4 误区之四：软件测试是测试人员的事情，与程序员无关开发和测试是相辅相成的过程，需要软件测试人员、程序员和系统分析师等保持密切的联系，需要更多的交流和协调，以便提高测试效率。另外，对于单元测试主要应该由程序员完成，必要时测试人员可以帮助设计测试用例。对于测试中发现的软件错误，很多需要程序员通过修改编码才能修复。程序员可以通过有目的的分析软件错误的类型、数量，找出产生错误的位置和原因，以便在今后的编程中避免同样的错误，积累编程经验，提高编程能力.3.5 误区之五：项目进度吃紧时少做些测试，时间富裕时多做测试这是不重视软件测试的表现，也是软件项目过程管理混乱的表现，必然会降低软件测试的质量。一个软件项目的顺利实现需要有合理的项目进度计划，其中包括合理的测试计划，对项目实施过程中的任何问题，都要有风险分析和相应的对策，不要因为开发进度的延期而简单的缩短测试时间、人力和资源。因为缩短测试时间带来的测试不完整，对项目质量的下降引起的潜在风险，往往造成更大的浪费。克服这种现象的最好办法是加强软件过程的计划和控制，包括软件测试计划、测试设计、测试执行、测试度量和测试控制.4. 软件测试的流程图 随着软件规模的不断扩大，软件设计的复杂程度也不断提高，软件开发过程中出现错误或缺陷的机会越来越多。因此，软件测试在软件项目实施过程中的重要性日益突出，而软件测试是一种繁琐的工作仅仅借助于人工测试是远远不够的，还必须依靠软件流程图，才能更好的软件测试活动的开展和真正提高软件测试质量。 设计&编码阶段测试工作流程上一阶段需求相关文档概要设计评 审详细设计单元测试方案编 码单元测试测试抽检单元测试报告进入下一阶段集成测试方案自动测试方案抽象出验证标准以模块为单位，不断循环5. 软件测试的实施和软件测试报告 5.1单元测试1）单元是软件系统的组成部分，它具有以下特点： 它是由程序员负责完成工作。 有一份详细的说明书，它包括：输入定义，输出定义，数据库定义，接口说明。 它是一个可识别的和可见的程序组成部分，并容易结合程序。 能单独编译、汇编、测试。 它是程序的必要部分。2）私有单元与公开单元从概念上可将单元分为私有单元与公开单元两类。私有单元是非正式的、变化的、模糊的、不完整的、混乱的、独立的、不协调的。公开单元是正式的、固定的、具体的、完整的、条理的、联系的、协调的。单元是私有的即未经过严格测试，尚未交付的使用单元。单元是公开的即已经严格测试及确认，可以与别的单元结合或调用的单元。单元测试的目的和效果是将私有单元转化公有单元，且使用最少的费用和最有效的方法完成从私有到公有的转化。3）单元测试的目标单元测试的目标是证明程序有错误，而不是证明程序没有错误。测试可以由程序员自己进行，也可以由进行独立测试，即由非程序员进行测试。但独立测试对单元级测试会有一定困难，还要制定具体的目标和方法。如在目标制定时，还可分为主要目标，次要目标和辅助目标以及程序员和他们的保证部门共同实施对单元的测试。 主要目标：是否实现说明书的要求，文档是否完整而有意义，测试计划的遵守是否严格，错误是否完全改正了。 次要目标：设计风格是否保持统一。 辅助目标：如错误类型统计，方法有效性，它们会为管理员提供信息。4）单元测试组织单元测试是程序或软件测试的基层工作，因为单元是整个程序的基础组成，其质量直接影响程序的更大成份甚至全局。在单元测试时应首先提供下列文档并按步进行： 提供正式说明书。 制定单元测试计划和文件。 先测试可测试代码。 程序员先测试私有单元再进行正式单元测试。 验收和条件验收（进度和质量间的冲突）。单元测试后可进行程序元素测试，即对由单元组成的各种程序进行测试。5）单元测试环境单元测试是在一定环境下进行的，这些环境可以是真实的也可以是模拟的。 真实环境。真实环境是单元程序实际使用的，这只有在极少数的环境情况下能提供，如单元程序属于一类嵌入性模块。 模拟环境。模拟环境是单元测试常用的，模拟环境可以在程序开发的早期进行，并利用工具对单元程序进行测试和排错，工具本身也是一种模拟环境。但全部采用模拟方法对单元进行测试，存在的缺点是某些真实的难以实现，从而失去真实性，可采用的方法进行回归测试，从而发现单元测试模拟方法可能出现的不准确，甚至错误之处。6）单元测试的方法 静态测试。采用人工阅读、分析、检验程序源代码的方式，来发现程序的错误，它依据提供单元测试对象的文档，从功能和结构两方面来对程序进行检查，并且着重于程序结构的检查。在静态文档是重要的依据，但在检查程序的同时也是对文档实行检查的过程，在继续对程序的检查中又会发现文档中存在的问题和不确切，甚至错误之处。 动态测试 采用机器运行实例方式来发现程序的错误。它依据提供单元测试对象的文档，从功能和结构两方面来对程序进行检查，并着重于程序功能检查。还可尽量利用辅助测试工具，进行语法检查、报表生成、数据结构、算法正确性等的检查。通常采用静态测试和动态测试相互结合、互相补充对单元测试是必要的，特别不要轻视静态测试，它有利于提高人们的程序设计水平和严谨的工作的态度。 复审。复审是保证测试质量的重要手段，由程序员参加的复审小组对文档、测试过程和结果应进行按计划的检查并验证其正确性，因此应事先制定复审计划，规定审查内容和方式。复审的方式和级别亦可以根据情况和需要有所区别5.2 集成测试 集成测试又称整体测试或结合测试，是软件测试的中的一个重要环节。 集成测试的任务集成测试是已完成程序元素级测试的条件下证实程序元素间的一致性。集成是指取出一组程序元素，把它们集成为一个更大的自身无矛盾的元素。而整体测试就是要检验结合的过程中的错误，证实程序元素的一致性。整体测试不同于对一般元素的测试，是对正在结合元素测试，即对结合过程的测试。 集成测试的条件集成测试前提是：(1) 全部被结合的子元素已经过测试，子元素自身一致的和正确的。 (2) 研究子元素间直接或间接的一致性。(3) 测试和排错交替进行，获得一个互相一致的子元素结合。(4) 对新元素进行测试。(5) 重复上述过程，直到完成整个系统的测试和结合。 集成测试技巧集成测试将对结合元素间的调用关系、数据依赖和元素接口进行测试，它可以应用下述技术：（1） 调用图/树的准备。包括每个元素和每个更低元素所做的各次调用，并且用图型表示出来，以便于了解元素间的调用关系。（2） 数据依赖图的准备。全部数据分析是整体测试的一部分，它利用数据字典，确定数据依赖关系。为了测试全程数据，可利用所谓数据依赖图，它描绘出程序元素所引用各种数据，并扩大到该元素的下层元素的影响数据，以说明程序元素与数据元素之间的依从关系。（3） 加工依赖图。研究加工对数据对象的改变，加工依赖图包括了各种加工对所有元素的操作关系。（4） 接口和接口标准。接口控制文档记录了元素之间的接口信息，它应遵守严格的接口标准。接口标准规定：数据项的传送方式、数据对象按类型的调用顺序规定、元素格式规定以及其它规定。 集成测试的内容（1） 程序元素中的数据项的相容性，它包括了数据项的表示范围的相容性、类型的相容性、表示方式的一致性、重要数据量的范围或个数的相容性、数据对象顺序的正确性、传递方法的正确性、参数使用合理性等。（2） 对调用图的使用中，应准确记录相关信息，以检验对调用图的路径覆盖情况。（3） 在尽量避免设计多入口和多出口的程序元素的同时，应对此类元素进行认真测试，检查多入口元素的每个入口点，并验证选取入口的正确和路径覆盖。多出口有时是有必要的，但是也应在整体测试中对其进行测试。 集成测试策落集成测试可以采用如下：（1） 自顶向下。自顶向下集成测试是从程序顶部开始，把顶部元素作为单元进行测试，它所调用的子程序可设成虚元素，即一种简单的替代元素，当测试完成后，再以真实元素加入，并重新进行对加入后的整个元素的测试；重复上述过程，直到全部测试完成加入元素及其整体为止。（2） 自底向上。自底向上的集成测试是从程序结构的底层开始，把被集成的元素逐层进行合并测试，直到顶层元素。（3） 随机测试。 随机测试是对系统进行整体测试的一种方法，但不是唯一的办法，它是在事先未做周密分析和计划的条件下，运行和执行某一类程序，或利用现成的随手可得的程序加载到系统并执行，从而进行随机测试，以求发现程序的某些错误，这种测试是正式测试前的先导性测试，当发现某些错误并排除后再进行正式的测试。随机测试有利于确定整体程序的框架，如测试程序是否能完成输入、存储、控制和输出的基本功能。5.3 系统测试系统测试是软件测试中的最后的、最完整的测试，它是在元素级测试和整体的基础上进行的，它是从全局来考虑软件系统的功能和性能要求。（1） 系统测试的任务。（2） 完成系统的功能验证。它由软件人员和质量保证人员共同研究进行。（3） 完成系统的验收测试。它由用户或用户代表在正式制定验收测试计划的情况下进行。（4） 系统测试计划。测试计划的制定是执行功能测试和验收测试的基本保证，它们必须有正式的测试文档，没有正式的文档就不会有正式的测试。测试文档应该是有规范的且内容丰富的资料，一般包含三大部分：A 部分：综述部分，包括：词汇集，各种说明书，测试设计标准和约定，测试运行次序、方法、图表等。B 部分：测试数据库和代码部分，包括测试数据库文档和交叉引用索引，测试数据库生成程序，驱动程序和装配生成程序，测试配置说明书，测试硬件和软件工具，验证硬、软件，支持性工具等。测试计划应自顶向下设计，并且文档化。 C 部分：实际测试说明书，包括：测试结构与范围组成，典型测试集组成，预测试的设计和记录，测试计划和生产率。系统测试实施系统测试的实施一般按下述步骤进行：（1） 功能测试。通过大量的精心的测试实例对系统的功能做全面系统的测试。（2） 性能测试。用特定的测试实例验证系统的性能要求。（3） 背景测试。用实际负载代替无负载的情况的测试，即真实运行环境的测试。（4） 配置测试。提供全部逻辑式物理设备，在指令的设备组合情况下，实现全部功能的测试。（5） 繁忙测试。系统全部资源处于高度繁忙情况下的一种“破坏”性测试，以验证系统的可靠性。（6） 恢复测试。测试系统对故障恢复能力，测试故障后整体和控制的可恢复性。（7） 安全性测试。测试系统对错误的操作或非法的用户的恶意破坏的安全保证的可靠程度。其中功能测试、性能测试和繁忙测试对于所有系统都是必要的，其它的测试同样也是需要的，但根据系统的不同要求，可能会更有侧重。系统测试包括功能测试和验收测试两种测试，其中功能测试是一种按测试计划和测试文档严格进行的过程，而验收测试则是一种具有合同执行和法律意义的活动。为顺利进行系统测试通常需要在测试文档的指导下，先进行必要的测试，并在测试前组织测试人和见证人班子，测试的指挥人和见证人是测试的关键人员。软件测试是软件开发的重要组成环节，没有测试就没有合格和高质量的软件，而软件测试的投入，包括人员和资金投入是巨大的，而且具有很高的组织管理和技术难度，如何组织测试人员队伍和如何设计和积累测试实例等，但又是必须进行和完成的重要工作。5.4 测试报告测试报告是测试阶段工作的总结，测试报告的内容主要包括：引言。 介绍测试的目的、范围、测试角度和标准、测试结果概要。测试计划和配置。包括系统配置、运行配置、测试标准和评价等。接口测试。描述对系统接口的测试和结果。功能测试。描述对系统各种功能的测试和结果。开发测试。包括正常数据和过载数据的测试，以及在错误数据下的测试和结果。交付使用的准备。包括交付使用的软件目录，留待解决的问题，质量的检验结果，对测试结果进行归纳，给出系统可接受的程度。附录。包括参考文献、异常状况小结、测试数据等。6. 班级管理系统的测试 我们对软件进行测试首先明白软件要实现的功能，按照软件测试文档进行否则无法对软件进行测试。班级管理系统实现功能：1)学生信息管理，包括： 学生信息的录入、修改、删除。 学生信息的查询：学号、姓名。2)学生成绩管理，包括： 学生成绩的查询、添加、修改、删