软件测试知识总结

1、测试驱动开发（TDD）测试在先，编码在后的开发方法（详见书本12页）

2、软件质量：功能、性能、可靠性（书本15页）

3、软件测试的工作范畴：测试的组织与管理(PDCA)、测试计划、测试用例、测试的实施、测试结果分析、测试评

审与报告（书本29页小结中）

第三章

4、白盒测试（设计测试用例看书说明）

（又称逻辑驱动测试,结构测试)的意思是把程序看成装在一个透明的白盒子里，测试人员知道程序的结构和处理算法,按照程序内部的逻辑进行测试，检测程序中的主要执行通路是否都能按预定要求正确工作，利用白盒测试法进行动态测试时，不需测试软件产品的功能。白盒测试主要用于单元测试。（详见书本31页）（1）语句覆盖

设计若干测试用例，运行被测试用例，使程序中的每个可执行语句至少被执行一次。

（2）判定覆盖：设计若干测试用例，运行被测试用例，使程序中每个判断的取真分支和取假分支至少经历一次。（针对每次判断，又称分支覆盖）

（3）条件覆盖：设计若干测试用例，运行被测试用例，使程序中每个判断中每个条件的可能取值至少满足一次。（针对每次判断中的每一个条件）

（4）判定-条件覆盖

（5）条件组合覆盖：每个判定结果至少出现一次，每个条件的所有可能至少出现一次。

（6）路径覆盖：设计所有的测试用例，来覆盖程序中的所有可能的执行路径。

（7）基本路径测试法：（根据流程图判断）

独立路径：所谓独立路径，是指至少包含一条新边的路径，也就是包含一些前面的路径未包含的语句，

当所有的语句都包含了，基路径集就够了。

5、黑盒测试（设计测试用例案例）

（又称功能测试或者数据驱动测试）黑盒测试法把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。也就是说，黑盒测试是在程序接口进行的测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接收输入数据并产生正确的输出信息，程序运行过程中能否保持外部信息的完整性。

（1）等价划分（见书本40页）

有效等价类和无效等价类

①输入条件规定了取值范围或者个数的情况下，则可以确立一个有效等价类和两个无效等价类。

②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和

一个无效等价类。

⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类

(从不同角度违反规则)。（参考40页实例）

（2）边界值分析

如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值以及刚刚超越这个范围边界的值作为测试输入数据。

如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。

如果程序规格说明中提到的输入或输出是个有序的集合，应该注意选取有序集的第一个和最后一个作为测试用例。

（3）正交试验

正交表具有两条性质：(1)每一列中各数字出现的次数都一样多。(2)任何两列所构成的各有序数对

出现的次数都一样多。所以称之谓正交表。（见书本48页）

（4）错误推测表

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

6、主动测试与被动测试

主动测试：测试人员主动向被测试对象发送请求，验证被测试对象的反应和输出结果。一般在测试环境下进行，测试人员需要设计若干测试用例，设法输入各种数据。

被动测试：为了解决产品在线测试问题。在被动测试方法中，软件产品运行在实际环境中，测试人员不干预产品的运行，而是被动地监控产品的运行，通过一定的被动机制来获取系统运行的数据，测试人员不需要设计测试用例。

7、基于风险的测试

指评估测试的优先级，先做高优先的测试，如果时间或者精力不足，低优先级的测试可以暂时先不做。影响测试优先级主要因素：对用户的影响、出错的概率

第四章

8、V模型（RAD模型快速应用开发模型）书本66页

V模型大体可以划分为以下几个不同的阶段步骤:需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。

原理：在瀑布模型的基础上，通过开发和测试同时进行的方式来缩短开发周期，提高开发效率

适用条件：明确需求、需求变化不大

V模式是一种传统软件开发模型，一般适用于一些传统信息系统应用的开发，而一些高性能高风险的系统、互联网软件，或一个系统难以被具体模块化的时候，就比较难做成V模式所需的各种构件，需要更强调迭代的开发模型或者敏捷开发模型。

优缺点：（详见瀑布模型的优缺点）

V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。

9、软件质量体系标准

（1）CMM 针对软件产品的质量管理和质量保证标准

CMM全称为(Capability Maturity Model),中文名称为能力成熟度模型

CMM划分为五级:级别越高表明该企业在提供合格软件产品方面的能力越强

（2）CMMI

为了整合不同模型的最佳实践,建议统一模型,覆盖不同领域,供企业进行整个组织的全面过程改进,并于2001年正式发布了能力成熟度集成模型(CMMI)。

（3）ISO 9000 原本是硬件标准（见书本83页）

ISO9000不是指一个标准，而是一类标准的统称。ISO 9000族标准是用来提供一个通用的质量体系标准

的核心，适用于广泛的工业行业和经济部门。

测试分类：单元测试、集成测试、系统测试、验收测试

第五章单元测试

10、单元测试（见书本97页）：单元测试是对软件基本组成单元进行的测试

为什么要进行单元测试？

?尽早发现错误

错误发现越早,成本越低.

开发人员过于自信,后期复杂度高,发现解决BUG困难.

?检查代码是否符合设计和规范

目标：（1）主要目标：确保各单元模块被正确地编码

（2）确保代码在结构上可靠且健全，能够在各种条件下给予正确的响应

概括起来，单元测试是对代码对单元的代码规范性、正确性、安全性和性能等进行验证。

内容（任务）：单元中所有独立执行路径、数据结构、接口、边界条件、容错性等测试。

（详见ppt单元测试）

10、走查和审查（见104页表5-1）

静态测试三部曲：走查、审查、评审

（1）走查

采用讲解、讨论和模拟运行的方式进行的查找错误的活动。

?引导小组成员在走查前通读设计和编码。

?限时，避免跑题。

?发现问题适当记录，避免现场修改。

?检查要点是代码是否符合标准和规范，是否有逻辑错误。

（2）审查

采用讲解、提问方式进行，一般有正式的计划、流程和结果。主要方法采用缺陷检查表。

?以会议形式，制定会议目标、流程和规则，结束后要编写报告。

?按缺陷检查表逐项检查。

?发现问题适当记录，避免现场修改。

?发现重大缺陷，改正后会议需要重开。

?检查要点是缺陷检查表，所以该表要根据项目不同不断积累完善。

走查审查

准备通读设计和编码应准备好需求描述文档、程序设计文档、程序的源

代码清单、代码编码标准和代码缺陷检查表形式非正式会议正式会议

参加人员开发人员为主项目组成员包括测试人员

主要技术方法无缺陷检查表

注意事项限时、不要现场修改代码限时、不要现场修改代码

生成文档会议记录静态分析错误报告

代码标准规范，无逻辑错误

目标代码标准规范，无逻

辑错误

12、驱动程序与桩程序（在黑盒测试中）

驱动程序：也称驱动模块，用以模拟被测模块的上级模块，能够调用被测模块。在测试过程中，驱动模块接受测试数据，调用被测模块并把相关数据传送给被测模块，启动被测模块，并打印出相应的结果。

桩程序：也称桩模块，用以模拟被测模型工作过程中所调用的下级模块。桩模块由被测模块调用，它们一般只进行很少的数据处理。

第六章集成测试与系统测试

13、集成测试模式

（1）非渐增式测试模式

先分别测试每个模块。再把所有模块按设计要求放在一起结合成所要的程序。如：大棒模式

概括地说，非增量式测试就是采用一步到位的方法构造测试，即对所有模块进行单元测试后，按照程序结构图将所有模块连接起来，进行整体测试.

其明显缺点是容易出现混乱，判断出错的原因和位置比较困难，因为测试时可能出现很多错误，并且在修正一个错误的同时，可能会引入新的错误。

（2）渐增式测试模式

把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。

具体优缺点详见书本126页

14、自顶向下与自底向上集成方法

（1）自顶向下：从主程序开始，沿着软件的控制层次向下移动，从而逐渐把各个模块结合起来。在组装过程中，可以使用深度优先或者宽度优先的策略。

?逐步集成和逐步测试是按照结构图自上而下进行

深度优先的集成是先集成一个主控路径下的所有模块，主控路径的选择是任意的；

广度优先的集成首先是沿着水平方向，把每一层中所有直接属于上一层的模块集中起来，直到最底层。

集成测试的整个过程主要由3个步骤完成：

1）主控模块作为测试驱动器；

2）根据集成方式，下层的桩模块依次被替换为真正模块；

3）每个模块集成时，进行单元测试。

（2）自底向上：从原子模块开始集成以进行测试。

（3）改进的自顶向下：基本使用“自顶向下”，但在早期，使用自底向上测试少数关键模块。

混合法：对软件结构中较上层，使用的是“自顶向下”法；对软件结构中较下层，使用的是“自底向上”法，两者相结合

15、改进的三明治集成方法

三明治方法：

采用三明治方法的优点是：它将自顶向下和自底向上的集成方法有机地结合起来，不需要写桩程序因为在测试初自底向上集成已经验证了底层模块的正确性。采用这种方法的主要缺点是：在真正集成之前每一个独立的模块没有完全测试过。

改进的三明治集成方法：

不仅自两头向中间集成，还保证了每个模块得到单独的测试，使测试进行的比较彻底。

16、持续集成

（1）持续集成（Continuous Integration，CI）是持续地编译、测试、检查和部署源代码的过程。

（2）优点：持续集成可以减少集成阶段"Bug"消耗的时间，从而最终提高软件开发的质量和效率。

（3）持续集成测试的原理

持续集成，是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。

17、回归测试

（1）概念：指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

（2）方法: 再测试全部用例、基于风险选择测试、基于操作剖面选择测试、再测试修改的部分。

（3）目的：

所做的修改达到了预定的目的，如错误得到了改正，新功能得到了实现，能够适应新的运行环境等；

不影响软件原有功能的正确性。

18、非功能测试（设计测试用例主要看课件）

（1）性能测试

性能测试的目的：为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。

性能测试指标的来源：用户对各项指标提出的明确需求；如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。（需求+经验）

主要的性能指标：服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间

（2）压力测试（累积效应）

压力测试是在一种需要反常数量、频率或资源的方式下，执行可重复的负载测试，以检查程序对异常情况的抵抗能力，找出性能瓶颈。

压力测试总是迫使系统在异常的资源配置下运行。

（4）容量测试

容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。

（5）安全性测试

安全性测试是检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。

（6）可靠性测试

可靠性（Reliability）是产品在规定的条件下和规定的时间内完成规定功能的能力，它的概率度量称为可靠度。软件可靠性是软件系统的固有特性之一，它表明了一个软件系统按照用户的要求和设计的目标，执行其功能的可靠程度。软件可靠性与软件缺陷有关，也与系统输入和系统使用有关。理论上说，可靠的软件系统应该是正确、完整、一致和健壮的。

（7）容错性测试

容错性测试是检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。如当系统出错时，能否在指定时间间隔内修正错误并重新启动系统

压力测试、容量测试和性能测试的测试目的虽然有所不同，但其手段和方法在一定程度上比较相似，通常会使用特定的测试工具，来模拟超常的数据量、负载等，监测系统的各项性能指标，如CPU和内存的使用情况、响应时间、数据传输量等。

19、（1）α测试.β测试

α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。

经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。

（2）文档测试：

非代码的文档测试主要检查文档的正确性、完备性和可理解性。

?验证正确性

?验证完备性

?验证可理解性

软件驱动的文档还得像程序一样运行起来测试。

第八章面向对象软件测试

20、分层与增量原理（160页）

类C和其派生类D间的增量变化能够用来帮助确定需要在D中测试什么。由于D是C的子类，那么所有的用于C的基于规范的测试用例也都适用于D。引入术语“继承的测试用例”来代表从父类测试用例中选取出来的、用于子类的测试用例。可以通过简单的分析来确定继承的测试用例中哪些适用于测试子类、哪些在测试子类时不必执行。

21、分类测试要点（泛化）与组装结构（聚合）

分类测试：体现了问题空间实例中的一般与特殊的关系

组装结构：体现了问题空间实例中整体与局部的关系

第九章基于应用服务器的测试

21、解释下列故障名称及原理

数据库并发能力: 多个应用请求的并发处理过程.

并发主要考虑的几个方面:（详见书本196页）

（1）数据丢失（解释）

（2）不可重复数据（解释）

（3）读脏数据（解释）

（4）数据库的锁

第十章软件本地化测试

22、翻译错误测试方法

翻译错误：(1) 产生原因：

1) 翻译人员不熟悉翻译要求。

2) 翻译人员工作疏漏。

3) 用户界面的翻译与标准词汇表不一致。

(2) 表现特征：

1) 应该翻译而没有翻译的英文字符。

2) 不应该翻译而翻译的中文字词。

3) 错误翻译的字词。

4) 只在本地化版本中存在该类型错误。

5) 较多隐含在对话框各控件以及帮助文档中。

(3) 测试要求：

1) 明确需要翻译和不需要翻译的内容。

2) 明确正确的翻译方式。

3) 根据术语表，确认术语翻译的正确性与一致性。

(4) 测试方法：

1) 主要同时打开中英文版本，执行相同的操作。

2) 结合标准界面词汇翻译表，参照对比。

(5) 说明：1) 对于对话框，如果含有下拉列表框，要打开列表框查看全部项。

23、布局错误测试方法

(1) 产生原因：1) 软件本地化后，由于源语言和本地化语言的表达方式不同，本地化后的字符数与源语言不同，每个字符所占空间尺寸不同，使得在英文版本正确显示的控件字符，可能在本地化版本显示不正确。

2) 本地化人员调整程序资源不当引起，例如，对话框及其控件高度或宽度的不正确调整。

(2) 表现特征：

1) 控件相互重叠或排列不均匀。

2) 控件中字符显示不完整。

3) 主要出现在本地化版本的对话框中。

(3) 测试要求：

1) 对话框中控件布局均匀，字符显示完整正确。

2) 对话框中控件数量相等，没有多余或丢失的控件(4) 测试方法：

1) 执行将要打开对话框的菜单或工具栏按钮，观察打开对话框中的控件布局。

2) 对比检查源语言软件和本地化软件对应的对话框中控件的数量

(5) 说明：1) 可能在执行不同的操作后，如选择了不同单选或复选按钮后，编辑框显示重叠等。

第十一章软件测试自动化

24、测试自动化

（1）概念：自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。

（2）与手工测试的辩证关系

测试自动化能：

?显著降低重复手工测试的时间

?建立可靠、重复的测试，减少人为错误

?增强测试质量和覆盖率

测试自动化不能：

?完全替代手工测试和手工测试工程师

?保证100%的测试覆盖率

软件测试自动化(TA)虽然具有很多优点，但只是对手工测试的一种补充，TA绝不能代替手工测试，有各自的特点：?在系统功能逻辑测试、验收测试等多采用黑盒测试的手工测试方法；

?系统性能、稳定性、可靠性测试等比较适合采用TA；

?对那种不稳定软件的测试、开发周期很短的软件、一次性的软件等不适合测试自动化

?工具本身并没有想象力和灵活性，根据经验报道，自动测试只能发现15%的缺陷，而手工测试可以发现85%的缺陷；TA工具在进行功能测试时，其准确的含义是回归测试工具，因为工具不能发现更多的新问题，但可以保证对已经测试过部分进行测试的准确性和客观性

（3）黑盒测试的主要步骤

（自动化测试有哪些主要步骤？）

录制测试过程成为自动化测试脚本

增强和改进录制的自动化测试脚本

执行自动化测试脚本完成自动化测试

（4）性能测试测什么？

各种操作的响应速度、最大并发用户数

最大数据容量

（5）单元测试、集成测试、系统测试的区别与联系

单元测试：

单元测试是对软件基本组成单元（软件设计的最小单位）进行正确性检验的测试工作，如

函数、过程(function,procedure)或一个类的方法(method)。

集成测试：

集成测试是在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统，

验证组装后功能以及模块间接口是否正确的测试工作。集成测试也叫组装测试、联合测试、

子系统测试或部件测试。

系统测试：

系统测试是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬

件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际使用环境下，

对计算机系统进行一系列的组装测试和确认测试的工作。

测试阶段测试方法测试内容评估基准对应阶

段

单元测试白盒测试单元内部的数据结构，逻辑控制，异常处理等逻辑覆盖率详设集成测试灰盒测试模块间接口以及模块组合后的整体功能接口覆盖率概设

系统测试黑盒测试整个系统对需求的符合度测试用例对需求的覆盖率需求

第十三章部署测试环境（设计测试环境）

25、测试环境重要性（详见书本289页）

使用错误的测试环境，可能引起下列一系列问题：

得出错误结果

与实际误差很大

忽略了实际使用可能出现的严重错误

导致项目返工，成本加大

导致项目延期

26、（1）测试环境5要素

?硬件

?软件

?数据准备

?网络环境

?测试工具

（2）数据准备（需要理解透彻）

数据准备包括数据量和真实性两个方法。（详见书本294页）

第十五章报告所发现的缺陷

27、（1）软件缺陷

软件缺陷指的是系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。如果在执行中遇到一个缺陷，可能引起系统的失效。那么准确有效的定义和描述软件缺陷，可以使软件缺陷得以快速修复，节约了软件测试项目的成本和资源，提高产品质量。

（2）软件缺陷描述的基本要求

软件缺陷的描述是软件缺陷报告中测试人员对问题的陈述的一部分并且是软件缺陷报告的基础部分。同时，软件缺陷的描述也是测试人员就一个软件问题与开发小组交流的最初且最好的机会。一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。

?单一准确

?可以再现

?完整统一

?短小简练

?特定条件

?补充完善

?不做评价

28、分离和再现缺陷原理

开发人员有时可以根据相对简单的错误信息就能找出问题所在。因为开发人员熟悉代

码，因此看到症状、测试用例步骤和分离问题的过程时，可能得到查找软件缺陷的线索。一个软件缺陷的分离和再现问题有时需要小组的共同努力。如果软件测试人员尽最大努力分离软件缺陷，也无法表达准确的再现步骤，那么仍然需要记录和报告软件缺陷。

29、缺陷描述的主要内容

软件缺陷的详细描述，由三部分组成：操作/重现步骤、期望结果、实际结果，有必要再做进一步的讨论：

?“步骤”提供了如何重复当前缺陷的准确描述，应简明而完备、清楚而准确。这些信息对开发人员是关键的，视为修复缺陷的向导，开发人员有时抱怨糟糕的缺陷报告，往往集中在这里；

?“期望结果”与测试用例标准或设计规格说明书或用户需求等一致，达到软件预期的功能。测试人员站在用户的角度要对它进行描述，它提供了验证缺陷的依据。

?“实际结果”测试人员收集的结果和信息，以确认缺陷确实是一个问题，并标识那些影响到缺陷表现的要素。

优秀的缺陷报告

重现步骤:

a)打开一个编辑文字的软件并且创建一个新的文档（这个文件可以录入文字）

b)在这个文件里随意录入一两行文字

c)选中一两行文字，通过选择Font 菜单然后选择Arial字体格式

d)一两行文字变成了无意义的乱字符

期望结果：当用户选择已录入的文字并改变文字格式的时候，文本应该显示正确的文字格式不会出现乱字符显示。

实际结果:它是字体格式的问题，如果改变文字格式成Arial之前，你保存文件，缺陷不会出现。缺陷仅仅发生在Windows98并且改变文字格式成其它的字体格式，文字是显示正常的。

第十七章软件测试项目管理

30、测试目标与准则（详见书本359页）

（1）目标（为什么要进行软件测试）

（2）准则

（3）测试范围

?优先级最高的需求功能

?新功能和编码改动较大(提高性能表现)的旧功能

?运用有效的测试技术去提高测试效果

?经常容易出现问题部分的功能

?一些经常被用户使用的功能和配置

31、测试计划内容（详见书本360页）

测试计划制定的第一步就是将软件分解较小而且相对独立的功能模块，写成测试需求。测试需求有很多分类方法，最普通的一种就是按照功能分类：

?测试需求是测试设计和开发测试用例的基础，分解功能模块可以更好地进行设计；

?详细的测试需求是用来衡量测试覆盖率的重要指标；

?测试需求包括各种测试实际和开发以及所需资源。

附录：

1、正交案例分析：

设计用例：

?1：填写姓名、填写身份证号、填写手机号

?2：填写姓名、不填身份证号、不填手机号

?3：不填姓名、填写身份证号、不填手机号

?4：不填姓名、不填身份证号、填写手机号

?增补测试用例

?5：不填姓名、不填身份证号、不填手机号

2、等价类划分

等价划分（见书本40页）

有效等价类和无效等价类

①输入条件规定了取值范围或者个数的情况下，则可以确立一个有效等价类

和两个无效等价类。

②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可

确立一个有效等价类和一个无效等价类。

⑤在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规

则)和若干个无效等价类(从不同角度违反规则)。（参考40页实例）

3、功能、性能用例设计

性能：请求相应时间

4、简述被动测试的原理及重要性

被动测试：为了解决产品在线测试问题。在被动测试方法中，软件产品运行在实际环境中，测试人员不干预产品的运行，而是被动地监控产品的运行，通过一定的被动机制来获取系统运行的数据，测试人员不需要设计测试用例。

5、测试缺陷报告写作主要有哪些内容

软件缺陷的详细描述，由三部分组成：操作/重现步骤、期望结果、实际结果，有必要再做进一步的讨论：

?“步骤”提供了如何重复当前缺陷的准确描述，应简明而完备、清楚而准确。这些信息对开发人员是关键的，视为修复缺陷的向导，开发人员有时抱怨糟糕的缺陷报告，往往集中在这里；

?“期望结果”与测试用例标准或设计规格说明书或用户需求等一致，达到软件预期的功能。测试人员站在用户的角度要对它进行描述，它提供了验证缺陷的依据。

?“实际结果”测试人员收集的结果和信息，以确认缺陷确实是一个问题，并标识那些影响到缺陷表现的要素。

6、如果测试开始时发现需求分析不合格，你会如何处理?

与客户交流

与开发人员交流协调

基于风险测试

重新确定测试范围与通过标准。

7、简述单元测试的目标

（1）主要目标：确保各单元模块被正确地编码

（2）确保代码在结构上可靠且健全，能够在各种条件下给予正确的响应

单元测试是对代码对单元的代码规范性、正确性、安全性和性能等进行验证。

内容（任务）：单元中所有独立执行路径、数据结构、接口、边界条件、容错性等测试。