软件测试毕业设计方案.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. 软件测试方法
2．1 软件测试基础方法
软件测试方法和技术是多个多样。对于软件测试技术，能够从不一样角度加以分类：
从是否需要实施被测软件角度，可分为静态测试和动态测试。从测试是否针对系统内部结构和具体实现算法角度来看，可分为白盒测试和黑盒测试。
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)学生成绩管理，包含：
① 学生成绩查询、添加、修改、删除。
② 计算班级每门课最低分、最高分、平均分、每个学生总分。
③ 计算班级每门课优异率和优异人数（>90）、良好率和良好人数(>75)、不及格率和不及格人数。
3) 课程管理，包含：
① 课程表查询
② 课程添加、删除、修改
现以班级管理系统成绩评定为例进行测试。
6.1 应用程序测试
界面是软件和用户交互最直接层，界面好坏决定用户对软件第一印象。而且设计良好界面能够引导用户自己完成对应操作，起到向导性作用。同时界面如同人面孔，含有吸引用户直接优势。设计合理界面能给用户带来轻松愉悦感受和成功感觉，相反因为界面设计失败，让用户有挫败感，再实用强大功效全部可能在用户畏惧和诸东流。班级管理系统登录界面和主界面就是很友好界面，以下所表示：

6.1.1 易用性测试
按钮名称易懂，用词正确，放弃模楞两可字眼，要和同一界面上其它按钮易于区分，能

望文知意。理想情况是用户不用查阅帮助就能知道该界面功效并进行相关正确操作。如班级管理系统模块成绩评定是一个很易用如上所表示：用户输入学号单击“统计”能够查询自己各科成绩和总分，当选种单选框“科目”一门课和在“等级”单选框能够计算优异人数和优异率、平均分、最