Software Testing 软件测试基本概念课件

ⅠPART软件测试基本概念ⅠPART软件测试几个术语（1）错误（error）、过错（mistake）

-扩散缺陷（defect/bug）、故障（fault） －错误的结果/表现失效（failure）-当缺陷执行时会发生失效事故（incident）-警告用户注意所出现的失效几个术语（1）错误（error）、过错（mistake）几个术语（2）测试（test）-处理错误、缺陷、失效和事故 －采用测试用例执行软件的活动 －两个目的：找出失效或演示正确的执行测试用例（testcase）-输入：测试数据和操作步骤

-输出：预期结果

-测试环境：系统环境设置几个术语（2）测试（test）一个测试生命周期需求规格说明设计缺陷分类缺陷解决缺陷隔离测试编码错误错误错误错误修复事故缺陷缺陷缺陷一个测试生命周期需求规设计缺陷分类缺陷解决缺陷隔离测试编码错软件缺陷软件未达到产品描述标明的功能；软件出现了产品描述指明不会出现的错误；软件功能超出产品描述指明范围；软件未达到产品描述虽未指出但应达到的目标；软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。软件缺陷软件未达到产品描述标明的功能；根据严重程度分类的缺陷轻微 词语拼写错误中等 误导或重复信息使人不悦 被截断的名称，0.00美元账单影响使用 有些交易没有处理严重 丢失交易非常严重 不正确的交易处理极为严重 经常出现“非常严重”的错误无法忍受 数据库破坏灾难性 系统停机容易传染 扩展到其他系统的系统停机根据严重程度分类的缺陷轻微 词语拼写错误软件缺陷产生的主要原因（1）技术问题算法错误、语法错误、计算和精度问题、接口参数传递不匹配导致模块集成出现问题团队工作对客户需求不明确、与用户沟通存在困难、不同阶段的开发人员理解不一致软件本身文档内容不正确、未考虑大量数据引起的负载问题、对程序逻辑路径或数据范围的边界考虑不周全、未考虑系统崩溃后的备份恢复等、硬件或系统软件上存在的错误、软件开发标准或过程上的错误软件缺陷产生的主要原因（1）技术问题软件缺陷产生的主要原因（2）软件缺陷产生的主要原因（2）软件缺陷产生的主要原因（3）用户和开发人员的沟通存在较大困难，对要开发的产品功能理解不一致；由于软件尚未设计构造，完全靠想象去描述系统的实现结果，对系统特性不够清晰；需求变化的不一致；对需求规格说明书不够重视；没有在整个开发团队中对需求规格说明书进行充分沟通。软件缺陷产生的主要原因（3）用户和开发人员的沟通存在较大困难软件缺陷的修复成本软件缺陷的修复成本软件测试员的目标发现软件缺陷；找出软件缺陷，尽可能早一点；找出软件缺陷，尽可能早一点，并确保其得以修复。以最少的时间和人力找出软件中潜在的各种错误和缺陷。软件测试员的目标发现软件缺陷；软件测试的目的（1）基于不同的立场，存在着两种完全不同的测试目的。从用户角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。从软件开发人员角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的需求，确立人们对软件质量的信心软件测试的目的（1）基于不同的立场，存在着两种完全不同的测试软件测试的目的（2）G.J.Myers把软件测试的目的简单概括为：软件测试是为了发现错误而执行程序的过程。一个好的软件测试用例能够在第一时间发现程序中存在的错误。一个好的测试是发现至今尚未发现的错误的测试。软件测试的目的（2）G.J.Myers把软件测试的目的简单软件测试的定义1979：测试是为了发现错误而执行程序的过程。1983：测试是由人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。2002：测试是为了度量和提高被测系统的质量，对测试件进行工程设计、实施和维护的整个生命周期进程。软件测试的定义1979：测试是为了发现错误而执行程序的过程。软件测试ST和软件质量SQ的关系计算机产品质量检验员（软件测试工程师）ST是SQ的手段之一，是高SQ的必要非充分条件。软件的高质量是分析设计出来的，而不是靠测试修补出来的。软件测试是软件质量保证的关键环节，是对软件需求分析、设计说明和编码结果进行最终审查。软件测试ST和软件质量SQ的关系计算机产品质量检验员软件质量特性ISO9126功能性：充分性、互操作性、正确性和安全性可靠性：成熟度、故障容限、可恢复性可用性：易懂易学、可操作、易接受、符合标准、惯例、风格向导或用户界面规定效率可维护性：可分析性、可变更性、稳定性以及易测性、可移植性：适应性、易安装、一致性和可交换性软件质量特性ISO9126功能性：充分性、互操作性、正确软件质量保证SQASQA：为确保软件开发过程和结果符合预期要求而建立的一系列规程，以及依照规程和计划采取的一系列活动及其结果评价。餐厅：老板-当班经理-主厨-厨师-检验员监督员项目：老板-项目经理-系统架构师-程序员-测试员

SQA（独立于项目组之外的第三方监督机构）软件质量保证SQASQA：为确保软件开发过程和结果符合预期要软件测试的原则（1）1应该尽早地和不断地进行软件测试；2测试用例应该由测试输入预置条件和与之对应的预期输出结果两部分组成，测试之前应根据测试要求正确选取需要执行的测试用例3程序员应该避免检查/测试自己的程序；4在设计测试用例时，应该包括合理的输入条件和不合理的输入条件；5充分注意程序测试中的群集现象；软件测试的原则（1）1应该尽早地和不断地进行软件测试；软件测试的原则（2）6严格执行测试计划，排除测试的随意性；7应对每一个测试结果做全面检查；8妥善保存测试计划、测试用例、出错统计和最终分析结果，为维护提供方便；9所有的测试应该追溯到用户需求；10测试应该从“小规模”开始，逐步向“大规模”即渐增式build测试软件测试的原则（2）6严格执行测试计划，排除测试的随意性；软件测试的对象软件=程序+文档+服务软件测试≠程序测试软件测试应贯穿于软件开发的整个期间需求分析、概要设计、详细设计以及编码各阶段所得到的文档. －需求规格说明书 －概要设计说明书 －详细设计说明书 －源程序软件测试的对象软件=程序+文档+服务验证和确认（V&V）（1）为把握软件开发各个环节的正确性，需要进行各种确认和验证工作。验证(Verification)，是指在软件生成的各个阶段保证软件正确地实现了某一特定功能的一系列活动，以及阶段间的逻辑协调性、完备性和正确性。（Areyoubuildingtheproductright?是否正确地构造软件？）验证和确认（V&V）（1）为把握软件开发各个环节的正确性，需验证和确认（V&V）（2）有效性确认(Validation)，是保证软件的实现满足用户需求的一系列的活动和过程。（Areyoubuildingtherightproduct?是否构造正确的软件？）需求规格说明的确认概要设计说明的确认详细设计说明的确认程序的确认(静态确认、动态确认)验证和确认（V&V）（2）有效性确认(Validation)验证和确认（V&V）（3）验证和确认（V&V）（3）软件测试的误区如果发布出去的软件有质量问题，那是软件测试人员的错。软件测试技术要求不高，至少比编程容易多了。有时间就多测试一些，来不及就少测试一些。软件测试是测试人员的事，与开发人员无关。根据软件开发瀑布模型，软件测试是开发后期的一个阶段。软件测试的误区如果发布出去的软件有质量问题，那是软件测试人员软件测试的特征完全测试程序是不可能的软件测试具有一定的风险软件缺陷的寄生虫性软件测试的不修复原则Pareto原则软件测试的特征完全测试程序是不可能的完全测试是不可能的假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上运行。若X、Y取整数，按黑盒方法进行穷举测试：可能采用的测试数据组：

232×232＝264

如果测试一组数据需要1毫秒，一年工作365×24小时，完成所有测试需?年。

(5亿)完全测试是不可能的假设一个程序P有输入量X和Y及输出量Z。在测试工作量完全测试不可能测试工作量开销在25%-50%依赖于应用风险的评估根据风险确定测试的广度和深度选择正确的测试规程测试用例爆炸和有限的资源测试工作量完全测试不可能软件测试是有风险的行为

如果决定不去测试所有的情况，那就是选择了风险。软件测试是有风险的行为如果决定不去测试所有的情况，那软件缺陷的寄生虫性找到的软件缺陷越多，就说明软件缺陷越多，其原因在于：程序员的疲倦程序员往往犯同样的错误某些软件的缺陷其实是大灾难的征兆软件缺陷的寄生虫性找到的软件缺陷越多，就说明软件软件测试的不修复原则并非所有软件缺陷都能修复，其原因在于：没有足够的时间不算真正的软件缺陷修复的风险太大不值得修复软件测试的不修复原则并非所有软件缺陷都能修复，其原因在于：Pareto原则

Pareto原则暗示着测试发现的错误中的80%很可能起源于程序模块中的20%。Pareto原则Pareto原则暗示着测试发现的错误中测试与软件开发各阶段的关系软件开发过程是一个自顶向下逐步细化的过程。系统规划阶段定义项目范围系统分析阶段建立数据域、功能和性能需求、约束等系统设计阶段建立物理设计蓝图系统构造阶段把物理设计蓝图用某种程序设计语言转换成程序代码测试过程是依相反顺序安排的自底向上逐步集成的过程。测试与软件开发各阶段的关系软件开发过程是一个自顶向下逐步细化软件测试过程模型软件测试由一系列活动组成，软件测试过程模型用于定义软件测试的流程和方法。正如开发过程的质量决定软件质量一样，测试过程的质量将直接影响测试结果的准确性和有效性。软件测试专家通过实践总结出一些测试过程模型，这些模型对测试活动进行抽象，并与开发活动有机地进行结合。软件测试过程模型软件测试由一系列活动组成，软件测试过程模型用V模型A版本（1）V模型A版本（1）V模型B版本（2）需求规范说明系统功能设计系统技术设计组件规格说明编程验收测试系统测试集成测试组件测试V模型B版本（2）需求规范说明系统功能设计系统技术设计组件规V模型C版本（3）用户需求需求分析概要设计详细设计编程验收测试系统测试集成测试单元测试V模型C版本（3）用户需求需求分析概要设计详细设计编程验收测V模型（4）V模型：PaulRook在20世纪80年代后期提出，最具有代表意义的测试模型，是软件开发瀑布模型的变体，反映了测试活动与分析和设计的关系。两个特点：展示了动态测试的全过程，并定义了动态测试与开发之间的关系。动态测试的行为与开发过程的行为相对应，测试基础是对应开发阶段的文档。V模型（4）V模型：PaulRook在20世纪80年代后期V模型（5）三个缺点：测试与开发文档之间很少有完美的一对一关系。完全没有提及静态测试，忽略了代码审查、需求规格说明审查等重要的测试手段。软件测试时间经常由于前期开发阶段进度的拖延而被挤占，甚至取消，从而使得测试质量得不到保证。V模型（5）三个缺点：W模型（1）W模型（1）W模型（2）W模型：PaulHerzlich在1993年提出，对V模型的改进，表明测试与开发的并行关系，充分体现测试贯穿于整个开发过程。两个特点：W是V的发展，强调测试应在整个开发周期进行。W和V一样，开发行为与测试行为一一对应，但W并不主张动态测试必须要与开发阶段对应起来，W也不限制动态测试行为必须严格地基于开发行为产生的单一文档W模型（2）W模型：PaulHerzlich在1993年提W模型（3）缺点：在W模型中，需求、设计、编码等活动是串行的，测试和开发活动也保持一种线性的前后关系。只有上一个阶段完成之后，才能正式开始下一个阶段工作，从而无法支持迭代的开发模式。W模型（3）缺点：H模型（1）H模型（1）H模型（2）H模型：将测试活动视为一个完全独立的活动，具有独立的包括测试准备活动和测试执行活动的流程。只要测试准备就绪，就可以开始测试执行活动。在整个开发周期内，存在多个这样独立的测试流程。体现“尽早准备、尽早执行”的思想，并且不同测试活动可以按照合理的顺序进行。H模型（2）H模型：将测试活动视为一个完全独立的活动，具有独软件测试过程模型选取策略（1）V强调整个开发中需要经历不同的测试阶段，但忽略了测试对象不应该仅仅是程序。W弥补了V的不足，但并没有将一个完整测试过程抽象出来，成为一个独立的流程，不适合于广泛应用的迭代模型。H明确指出了测试的独立性，只要测试条件成熟，就可以展开测试。要根据不同测试任务要求，综合各模型对项目有实用价值的方面。软件测试过程模型选取策略（1）V强调整个开发中需要经历不同的软件测试过程模型选取策略（2）一个建议策略：以W模型为基本框架，从开发过程一开始就介入，并与开发过程同步开展相应的测试工作，同时灵活运用H模型独立测试的思想，只要满足就绪条件就进行独立的测试，并对测试工作进行迭代，直至完成测试目标。体现了尽早测试、全面测试、独立迭代测试的思想。软件测试过程模型选取策略（2）一个建议策略：建议的模型建议的模型软件测试阶段需求规格说明书审查设计说明书和代码审查单元测试集成测试功能测试确认测试系统测试验收测试安装测试软件测试阶段需求规格说明书审查软件测试方法从测试是否针对系统的内部结构和具体实现算法的角度可以分为黒盒测试和白盒测试。从测试是否需要执行被测软件的角度可以分为静态测试和动态测试。从测试执行时是否需要人工干预的角度可以分为人工测试和自动测试。软件测试方法从测试是否针对系统的内部结构和具体实现算法的角度黒盒测试（1）这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。黑盒测试又叫做功能性测试或数据驱动测试。黒盒测试（1）这种方法是把测试对象看做一个黑盒子，测试人员完黒盒测试（2）黑盒测试在程序接口和用户界面进行测试，主要是为了发现以下错误:

是否有不正确或遗漏了的功能?

在接口上，能否正确接受输入数据，能否输出正确的结果?

是否有数据结构错误或外部信息(例如数据文件)访问错误?

性能上是否能够满足要求?界面是否错误，是否不美观？

是否有初始化或终止性错误?黒盒测试（2）黑盒测试在程序接口和用户界面进行测试，主要是为白盒测试（1）此方法把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构性测试或逻辑驱动测试。白盒测试（1）此方法把测试对象看做一个透明的盒子，它允许测试白盒测试（2）软件人员使用白盒测试方法，主要想对程序模块进行如下的检查：对程序模块的所有独立的执行路径至少测试一次；对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次；在循环的边界和运行界限内执行循环体；测试内部数据结构的有效性。白盒测试（2）软件人员使用白盒测试方法，主要想对程序模块进行静态测试静态分析，对模块的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和仿真运行，采用人工检测和计算机辅助静态分析手段进行检测。静态测试包括对各阶段的软件产品进行审查。静态测试静态分析，对模块的源代码进行研读，查找错误或收集一些动态测试通过观察代码运行时的动作，来提供执行跟踪、测试覆盖率方面的信息。通过有效的测试用例，对应的输入/输出关系来分析被测程序的运行情况。动态测试通过观察代码运行时的动作，来提供执行跟踪、测试覆盖率软件评审30％－70％的缺陷是通过软件评审发现.起源于20世纪50－60年代，由管理人员对文档进行的较简单的阅读和审批的质量控制实践.但是只抽查部分文档的评审不能引起开发人员对质量问题的深刻注意，故召集有关人员就文档开评审会议用于提高质量.1976年IBM开始采用软件评审方法，取得很好的效果.软件评审30％－70％的缺陷是通过软件评审发现.软件评审的优点（1）早发现错误早纠正，从而降低开发成本.除了开发人员参加外，用户也要参与，这样可以兼容各家之长，从不同的视角考虑问题发现的缺陷较显见，而软件测试是从迹象判断缺陷存在（实际输出与预期输出不符），再根据各种现象分析，才能判断造成缺陷的原因，这是一个困难的过程.软件评审的优点（1）早发现错误早纠正，从而降低开发成本.软件评审的优点（2）测试需对各个缺陷分别进行分析定位再纠正，而软件评审往往可以成批发现缺陷，同时也可以成批纠正缺陷，效率较高.测试时发现缺陷，程序人员往往急于纠正，而不能冷静考虑修正方案，会导致错上加错.而软件评审在早期，软件开发人员往往能够从容对待，全面衡量选择修改方案.软件评审的优点（2）测试需对各个缺陷分别进行分析定位再纠正，通用的评审过程计划概述准备评审会议返工跟踪通用的评审过程计划规格说明书审查需求分析规格说明书是否完整、正确、清晰是软件开发成败的关键。测试人员要参与系统需求分析，认真阅读用户需求分析文档，真正理解用户需求，检查规格说明书对产品描述的准确性、一致性等。规格说明书审查需求分析规格说明书是否完整、正确、清晰是软件开高级审查设身处地为用户着想研究现有的标准和规范1、公司惯用语和约定2、行业要求3、国家标准4、硬件和网络标准5、图形用户界面（GUI）审查和测试同类软件高级审查设身处地为用户着想低级审查属性检查清单完整、准确、精确、一致、贴切、合理、代码无关、可测试术语检查清单是否有绝对、肯定和切实认定的叙述，针对其设计用例比较模糊的用语，某些、有时·····功能清单是否有等等、诸如此类、依此类推，无法测试的词汇在性能上不确定的说法隐藏大量需要说明的功能如果·····那么·····（没有否则）低级审查属性检查清单设计说明书和代码审查软件设计是基于对用户需求的理解基础上，采用计算机技术，将用户的需求转换成计算机软件表示的过程，设计的结果用系统结构、数据输入、详细处理过程、数据存储模式、数据输出表示。可以按照需求规格说明书对系统结构的合理性、处理过程的正确性进行评价，利用关系数据库的模式理论对数据库模式进行审查。静态白盒测试方法：在不执行的条件下有条理地仔细审查软件设计和代码。设计说明书和代码审查软件设计是基于对用户需求的理解基础上，采静态白盒测试：选择要审查代码模块的准则对于正确操作产品起关键作用的模块；复杂度较高的模块；与过去发生错误率较高的模块功能类似的模块；相对较新的或缺乏经验的软件程序师编写的模块.静态白盒测试：选择要审查代码模块的准则对于正确操作产品起关键静态白盒测试：桌前检查是一种传统的方法，由程序员检查自己编写的程序，程序员在程序通过编译之后进行单元测试之前，对源代码进行分析、检验并补充相关的文档，目的是发现程序中的错误.检查项目包括：检查变量的交叉引用表；检查子程序、宏、函数；常量检查；标准检查；风格检查；比较控制流；选择、激活路径；对照程序的模块设计书；补充文档。静态白盒测试：桌前检查是一种传统的方法，由程序员检查自己编写静态白盒测试：代码评审（1）由若干个程序员和测试员组成一个评审小组，通过阅读、讨论和争议，对程序进行静态分析的过程.代码评审分两步:小组负责人提前把设计规约、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为评审的依据.小组成员在充分阅读材料后召开程序审查会.静态白盒测试：代码评审（1）由若干个程序员和测试员组成一个评静态白盒测试：代码评审（2）会前，给评审小组每个成员准备一份常见的错误清单（检查表）：列出程序中可能发生的各种错误，并进行分类.代码评审之后，需要完成以下事情：把发现的错误登记造表，并交给程序员；若发现错误较多，或发现重大错误，则在改正之后再次组织代码评审；对错误登记表进行分析、归类、精练以提高审议效果.静态白盒测试：代码评审（2）会前，给评审小组每个成员准备一份静态白盒测试：走查基本同代码评审，过程分为两步：将材料分发给走查小组每个成员，先认真研究程序；开会.不同的是不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当”计算机.静态白盒测试：走查基本同代码评审，过程分为两步：常见的错误类型数据引用错误数据声明错误计算错误比较错误控制流程错误子程序参数错误输入/输出错误其他检查常见的错误类型数据引用错误数据引用错误

指使用未经正确初始化用法和引用方式的变量、常量、数组、字符串或记录而导致的软件缺陷.是否引用了未初始化的变量？数组和字符串的下标是整数值吗？是否在应该使用常量的地方使用了变量？变量是否被赋予不同类型的值？为引用的指针分配内存了吗？一个数据结构是否在多个函数或者子程序中引用，在每一个引用中明确定义结构了吗？数据引用错误 指使用未经正确初始化用法和引用方式的变量、数据声明错误 指不正确地声明或使用变量和常量.所有变量都赋予正确的长度和类型了吗？变量是否在声明的同时进行了初始化？存在声明过、但从未引用或者只引用过一次的变量吗？在特定模块中所有变量都显示声明了吗？数据声明错误 指不正确地声明或使用变量和常量.计算错误

计算无法得到预期结果.计算中是否使用了不同数据类型的变量？计算中是否了解和考虑到编译器对类型或长度不一致的变量的转换规则？在数值计算过程中是否可能出现溢出？除数/模是否可能为零？变量的值是否超过有意义的范围？对于包含多个操作数的表达式，求值的次序是否混乱，运算优先级对吗？计算错误 计算无法得到预期结果.比较错误

比较和判断错误很可能是边界条件问题.比较得正确吗？存在分数或者浮点值之间的比较吗？如果有，精确问题会影响比较吗？每一个逻辑表达式都正确表达了吗？逻辑计算如期进行了吗？求值次序有疑问吗？逻辑表达式的操作是逻辑值吗？比较错误 比较和判断错误很可能是边界条件问题.控制流程错误

编程语言中循环等控制结构未按预期方式工作，通常由计算或者比较错误直接或间接造成.如果程序包含begin…end和do…while等语句组，end是否对应？程序、模块、子程序和循环能否终止？可能存在永远不停的循环吗？循环可能从不执行吗？控制流程错误 编程语言中循环等控制结构未按预期方式子程序参数错误 来源是软件子程序不正确地传递参数.子程序接受的参数类型和大小与调用代码发送的匹配吗？如果子程序有多个入口点，引用的参数是否与当前入口点没有关联？常量是否当作形参传递，意外在子程序中改动？子程序参数错误 来源是软件子程序不正确地传递参数.输入/输出错误

包括文件读取、接受键盘或鼠标输入以及向打印机或者屏幕等输出设备写入错误.软件是否严格遵守外部设备读写数据的专用格式？文件或者外部不存在或者未准备好的错误情况有处理吗？软件是否处理外部设备未连接、不可用，或者读写过程中存储空间占满等情况？软件以预期方式处理预计的错误吗？检查错误提示信息的准备性、正确性、语法和拼写了吗？输入/输出错误 包括文件读取、接受键盘或鼠标输入以及向打印其他检查软件是否使用其他外语？是否处理扩展ASCII字符？是否需要用统一编码取代ASCII？软件是否要移植到其他编译器？是否考虑了兼容性，以使软件能够运行于不同数量的可用内存，不同的内部硬件？程序编译是否产生“警告”或“提示”信息？其他检查软件是否使用其他外语？是否处理扩展ASCII字符？是单元测试对系统的最小单元模块或组件进行测试，在编码阶段进行，主要使用白盒测试方法，从程序的内部结构出发设计测试用例，检查模块或组件已实现的功能与定义的功能是否一致，编码是否存在错误。多个模块平行、独立地测试，通常需要编写驱动模块和桩模块。一般由编程人员和测试人员共同完成，除了采用动态测试方法之外，还会采取代码走查、静态分析等辅助手段。是为了发现编码和详细设计阶段产生的错误。单元测试对系统的最小单元模块或组件进行测试，在编码阶段进行，集成测试在单元测试的基础上，将模块按照设计要求组装起来同时进行测试，主要目的是发现与接口有关的模块之间的问题。集成方式（将模块组装起来形成一个可运行的系统）直接影响测试成本、测试计划、测试用例的设计、测试工具的选择等。常用的两种集成方式是一次性和增值式。是为了发现概要设计阶段产生的错误。集成测试在单元测试的基础上，将模块按照设计要求组装起来同时进功能测试一般在集成测试完成后进行，针对应用系统进行测试。基于产品功能说明书，在已知产品所应具有的功能，从用户角度来进行功能验证，以确定每个功能是否都能正常使用。测试时，不考虑程序内部结构和实现方式，只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，保持外部信息（数据库或文件）的完整性。包括用户界面测试、各种操作测试、不同的数据输入、数据输出和存储等。功能测试一般在集成测试完成后进行，针对应用系统进行测试。确认测试目的是向未来的用户表明系统能够按照预定的要求工作，验证软件的有效性，即软件的功能和性能是否达到用户合理的期待。在模拟的环境下（开发环境），应用黒盒测试方法，验证所测试的软件是否满足需求规格说明书列出的需求和用户的需求。是为了发现需求分析阶段产生的错误。确认测试目的是向未来的用户表明系统能够按照预定的要求工作，验系统测试软件最终要与系统中其他部分配套运行，将软件放在整个计算机环境中，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试，包括恢复测试、安全测试、强度测试和性能测试等。系统测试软件最终要与系统中其他部分配套运行，将软件放在整个计验收测试验收测试是由用户通过试用系统而进行的测试。目的是从用户的角度实际操作运行软件系统而检验系统的可用性及与用户配合的程度。经过上述的测试过程对软件进行测试后，软件基本满足开发的要求，这时测试基本结束，将软件提交给用户。验收测试验收测试是由用户通过试用系统而进行的测试。目的是从用安装测试按照软件产品安装手册或相应的文档，在相当于用户使用的环境中，进行一步一步安装的同时所做的测试。主要进行以下三个方面的测试：环境的不同设置或配置安装文档的正确性安装的媒体制作是否有问题安装测试按照软件产品安装手册或相应的文档，在相当于用户使用的基本测试过程计划和控制分析和设计实现和执行测试出口准则的评估后期测试活动基本测试过程计划和控制测试计划（1）PDCA模型Plan：设定可以达到的目标，决定哪些事需要完成，哪些事可以做，哪些资源可以利用。Do：计划之后就要去实施，以执行计划中已定义的各种任务。Check：对所做的结果进行检查，以确认是否达到预期的结果，从而发现计划或执行中的问题。Action：若检查发现问题，就要采取措施纠正错误，从而在指定下一步计划中有所改善，使得计划会更合理。测试计划（1）PDCA模型测试计划（2）制定测试计划要与软件开发活动同步进行，在需求分析阶段完成验收测试计划，并与需求规格说明一起提交评审；在概要设计阶段完成和评审系统测试计划；在详细设计阶段完成和评审集成测试计划；在编码实现阶段完成和评审单元测试计划。测试计划（2）制定测试计划要与软件开发活动同步进行，在需求分测试计划（3）明确要完成的测试活动，评估完成活动所需要的时间和资源，设计测试组织和岗位职权，进行活动安排和资源分配，安排跟踪和控制测试过程。主要包括制定测试策略、确定测试范围、测试用例的设计方法和要点、所需资源和日程安排。制定测试策略主要分析测试的目标和指标，确定测试的对象和依据，明确测试的重点和所采用的方法。测试计划（3）明确要完成的测试活动，评估完成活动所需要的时间测试信息流（1）测试信息流（1）测试信息流（2）软件配置：软件需求规格说明、软件设计规格说明、源代码等；测试配置：测试计划、测试用例、测试环境、测试驱动程序等；测试工具：用于测试分析的测试对象分析工具、测试代码分析工具、缺陷分析工具、测试评估分析工具；用于测试设计的测试构架工具和测试用例设计工具等；用于测试实现的测试数据生成工具、测试脚本生成工具等；用于测试执行的系统功能测试工具、系统性能测试工具；用于测试管理的测试任务管理工具、测试用例管理工具等。测试信息流（2）软件配置：软件需求规格说明、软件设计规格说明测试信息流（3）测试结果分析：比较实测结果与预期结果，评价错误是否发生。排错(调试)：对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。修正后的文档再测试：直到通过测试为止。通过收集和分析测试结果数据，对软件建立可靠性模型。测试信息流（3）测试结果分析：比较实测结果与预期结果，测试信息流（4）利用可靠性分析，评价软件质量：

软件的质量和可靠性达到可以接受的程度；

所做的测试不足以发现严重的错误；如果测试发现不了错误，可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。测试信息流（4）利用可靠性分析，评价软件质量：软件测试的理解规格说明（预期的）程序（观察的）SP软件测试的理解规格说明程序SP软件测试用例的理解7规格说明（预期的）程序（观察的）SPT8215643测试用例（已检验）软件测试用例的理解7规格说明程序SPT8215643测试用例功能性测试（1）规格说明（预期的）程序（观察的）SP测试用例功能性测试（1）规格说明程序SP测试用例功能性测试（2）基本观点：任何程序都可以看做是将输入定义域取值映射到输出值域的函数。测试依据：软件的需求规格说明优点：与软件如何实现无关，若实现发生变化，测试用户仍有用测试用例设计可以与实现并行进行，可压缩总的项目开发时间缺点：测试用例之间可能存在严重的冗余可能有未测试的软件漏洞功能性测试（2）基本观点：任何程序都可以看做是将输入定义域取结构性测试（1）规格说明（预期的）程序（观察的）SP测试用例结构性测试（1）规格说明程序SP测试用例结构性测试（2）基本观点：实现是已知的测试依据：内部实现细节优点：可以严格描述要测试的确切内容测试覆盖指标的定义和使用，提供明确描述软件测试项范围的方法，有利于测试管理缺点：不能表示没有编码实现的行为结构性测试（2）基本观点：实现是已知的功能性测试和结构性测试的比较两种方法单独使用都是不充分的。明智的组合会带来功能性测试的置信，以及结构性测试的度量。如果知道容易犯什么错误，并且知道在被测软件中可能存在什么类型的缺陷，就可以利用这种知识运用更恰当的测试用例标识方法，而正是这一点使得测试真正成为一种工艺。功能性测试和结构性测试的比较两种方法单独使用都是不充分的。练习和思考在千年虫例子中，程序员有错误吗？仅仅测试程序是否按照预期方式运行有何错误？判断是非：好的测试人员不懈追求完美。假定无法完全测试某一程序，在决定是否应该停止测试时需要考虑哪些问题？为什么说软件产品规格说明书是软件缺陷的最大来源？假如周一测试软件的某一功能，每小时发现一个新的软件缺陷，你认为周二将会以什么频率发生软件缺陷？练习和思考在千年虫例子中，程序员有错误吗？ⅠPART软件测试基本概念ⅠPART软件测试几个术语（1）错误（error）、过错（mistake）

-扩散缺陷（defect/bug）、故障（fault） －错误的结果/表现失效（failure）-当缺陷执行时会发生失效事故（incident）-警告用户注意所出现的失效几个术语（1）错误（error）、过错（mistake）几个术语（2）测试（test）-处理错误、缺陷、失效和事故 －采用测试用例执行软件的活动 －两个目的：找出失效或演示正确的执行测试用例（testcase）-输入：测试数据和操作步骤

-输出：预期结果

-测试环境：系统环境设置几个术语（2）测试（test）一个测试生命周期需求规格说明设计缺陷分类缺陷解决缺陷隔离测试编码错误错误错误错误修复事故缺陷缺陷缺陷一个测试生命周期需求规设计缺陷分类缺陷解决缺陷隔离测试编码错软件缺陷软件未达到产品描述标明的功能；软件出现了产品描述指明不会出现的错误；软件功能超出产品描述指明范围；软件未达到产品描述虽未指出但应达到的目标；软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。软件缺陷软件未达到产品描述标明的功能；根据严重程度分类的缺陷轻微 词语拼写错误中等 误导或重复信息使人不悦 被截断的名称，0.00美元账单影响使用 有些交易没有处理严重 丢失交易非常严重 不正确的交易处理极为严重 经常出现“非常严重”的错误无法忍受 数据库破坏灾难性 系统停机容易传染 扩展到其他系统的系统停机根据严重程度分类的缺陷轻微 词语拼写错误软件缺陷产生的主要原因（1）技术问题算法错误、语法错误、计算和精度问题、接口参数传递不匹配导致模块集成出现问题团队工作对客户需求不明确、与用户沟通存在困难、不同阶段的开发人员理解不一致软件本身文档内容不正确、未考虑大量数据引起的负载问题、对程序逻辑路径或数据范围的边界考虑不周全、未考虑系统崩溃后的备份恢复等、硬件或系统软件上存在的错误、软件开发标准或过程上的错误软件缺陷产生的主要原因（1）技术问题软件缺陷产生的主要原因（2）软件缺陷产生的主要原因（2）软件缺陷产生的主要原因（3）用户和开发人员的沟通存在较大困难，对要开发的产品功能理解不一致；由于软件尚未设计构造，完全靠想象去描述系统的实现结果，对系统特性不够清晰；需求变化的不一致；对需求规格说明书不够重视；没有在整个开发团队中对需求规格说明书进行充分沟通。软件缺陷产生的主要原因（3）用户和开发人员的沟通存在较大困难软件缺陷的修复成本软件缺陷的修复成本软件测试员的目标发现软件缺陷；找出软件缺陷，尽可能早一点；找出软件缺陷，尽可能早一点，并确保其得以修复。以最少的时间和人力找出软件中潜在的各种错误和缺陷。软件测试员的目标发现软件缺陷；软件测试的目的（1）基于不同的立场，存在着两种完全不同的测试目的。从用户角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。从软件开发人员角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的需求，确立人们对软件质量的信心软件测试的目的（1）基于不同的立场，存在着两种完全不同的测试软件测试的目的（2）G.J.Myers把软件测试的目的简单概括为：软件测试是为了发现错误而执行程序的过程。一个好的软件测试用例能够在第一时间发现程序中存在的错误。一个好的测试是发现至今尚未发现的错误的测试。软件测试的目的（2）G.J.Myers把软件测试的目的简单软件测试的定义1979：测试是为了发现错误而执行程序的过程。1983：测试是由人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。2002：测试是为了度量和提高被测系统的质量，对测试件进行工程设计、实施和维护的整个生命周期进程。软件测试的定义1979：测试是为了发现错误而执行程序的过程。软件测试ST和软件质量SQ的关系计算机产品质量检验员（软件测试工程师）ST是SQ的手段之一，是高SQ的必要非充分条件。软件的高质量是分析设计出来的，而不是靠测试修补出来的。软件测试是软件质量保证的关键环节，是对软件需求分析、设计说明和编码结果进行最终审查。软件测试ST和软件质量SQ的关系计算机产品质量检验员软件质量特性ISO9126功能性：充分性、互操作性、正确性和安全性可靠性：成熟度、故障容限、可恢复性可用性：易懂易学、可操作、易接受、符合标准、惯例、风格向导或用户界面规定效率可维护性：可分析性、可变更性、稳定性以及易测性、可移植性：适应性、易安装、一致性和可交换性软件质量特性ISO9126功能性：充分性、互操作性、正确软件质量保证SQASQA：为确保软件开发过程和结果符合预期要求而建立的一系列规程，以及依照规程和计划采取的一系列活动及其结果评价。餐厅：老板-当班经理-主厨-厨师-检验员监督员项目：老板-项目经理-系统架构师-程序员-测试员

SQA（独立于项目组之外的第三方监督机构）软件质量保证SQASQA：为确保软件开发过程和结果符合预期要软件测试的原则（1）1应该尽早地和不断地进行软件测试；2测试用例应该由测试输入预置条件和与之对应的预期输出结果两部分组成，测试之前应根据测试要求正确选取需要执行的测试用例3程序员应该避免检查/测试自己的程序；4在设计测试用例时，应该包括合理的输入条件和不合理的输入条件；5充分注意程序测试中的群集现象；软件测试的原则（1）1应该尽早地和不断地进行软件测试；软件测试的原则（2）6严格执行测试计划，排除测试的随意性；7应对每一个测试结果做全面检查；8妥善保存测试计划、测试用例、出错统计和最终分析结果，为维护提供方便；9所有的测试应该追溯到用户需求；10测试应该从“小规模”开始，逐步向“大规模”即渐增式build测试软件测试的原则（2）6严格执行测试计划，排除测试的随意性；软件测试的对象软件=程序+文档+服务软件测试≠程序测试软件测试应贯穿于软件开发的整个期间需求分析、概要设计、详细设计以及编码各阶段所得到的文档. －需求规格说明书 －概要设计说明书 －详细设计说明书 －源程序软件测试的对象软件=程序+文档+服务验证和确认（V&V）（1）为把握软件开发各个环节的正确性，需要进行各种确认和验证工作。验证(Verification)，是指在软件生成的各个阶段保证软件正确地实现了某一特定功能的一系列活动，以及阶段间的逻辑协调性、完备性和正确性。（Areyoubuildingtheproductright?是否正确地构造软件？）验证和确认（V&V）（1）为把握软件开发各个环节的正确性，需验证和确认（V&V）（2）有效性确认(Validation)，是保证软件的实现满足用户需求的一系列的活动和过程。（Areyoubuildingtherightproduct?是否构造正确的软件？）需求规格说明的确认概要设计说明的确认详细设计说明的确认程序的确认(静态确认、动态确认)验证和确认（V&V）（2）有效性确认(Validation)验证和确认（V&V）（3）验证和确认（V&V）（3）软件测试的误区如果发布出去的软件有质量问题，那是软件测试人员的错。软件测试技术要求不高，至少比编程容易多了。有时间就多测试一些，来不及就少测试一些。软件测试是测试人员的事，与开发人员无关。根据软件开发瀑布模型，软件测试是开发后期的一个阶段。软件测试的误区如果发布出去的软件有质量问题，那是软件测试人员软件测试的特征完全测试程序是不可能的软件测试具有一定的风险软件缺陷的寄生虫性软件测试的不修复原则Pareto原则软件测试的特征完全测试程序是不可能的完全测试是不可能的假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上运行。若X、Y取整数，按黑盒方法进行穷举测试：可能采用的测试数据组：

232×232＝264

如果测试一组数据需要1毫秒，一年工作365×24小时，完成所有测试需?年。

(5亿)完全测试是不可能的假设一个程序P有输入量X和Y及输出量Z。在测试工作量完全测试不可能测试工作量开销在25%-50%依赖于应用风险的评估根据风险确定测试的广度和深度选择正确的测试规程测试用例爆炸和有限的资源测试工作量完全测试不可能软件测试是有风险的行为

如果决定不去测试所有的情况，那就是选择了风险。软件测试是有风险的行为如果决定不去测试所有的情况，那软件缺陷的寄生虫性找到的软件缺陷越多，就说明软件缺陷越多，其原因在于：程序员的疲倦程序员往往犯同样的错误某些软件的缺陷其实是大灾难的征兆软件缺陷的寄生虫性找到的软件缺陷越多，就说明软件软件测试的不修复原则并非所有软件缺陷都能修复，其原因在于：没有足够的时间不算真正的软件缺陷修复的风险太大不值得修复软件测试的不修复原则并非所有软件缺陷都能修复，其原因在于：Pareto原则

Pareto原则暗示着测试发现的错误中的80%很可能起源于程序模块中的20%。Pareto原则Pareto原则暗示着测试发现的错误中测试与软件开发各阶段的关系软件开发过程是一个自顶向下逐步细化的过程。系统规划阶段定义项目范围系统分析阶段建立数据域、功能和性能需求、约束等系统设计阶段建立物理设计蓝图系统构造阶段把物理设计蓝图用某种程序设计语言转换成程序代码测试过程是依相反顺序安排的自底向上逐步集成的过程。测试与软件开发各阶段的关系软件开发过程是一个自顶向下逐步细化软件测试过程模型软件测试由一系列活动组成，软件测试过程模型用于定义软件测试的流程和方法。正如开发过程的质量决定软件质量一样，测试过程的质量将直接影响测试结果的准确性和有效性。软件测试专家通过实践总结出一些测试过程模型，这些模型对测试活动进行抽象，并与开发活动有机地进行结合。软件测试过程模型软件测试由一系列活动组成，软件测试过程模型用V模型A版本（1）V模型A版本（1）V模型B版本（2）需求规范说明系统功能设计系统技术设计组件规格说明编程验收测试系统测试集成测试组件测试V模型B版本（2）需求规范说明系统功能设计系统技术设计组件规V模型C版本（3）用户需求需求分析概要设计详细设计编程验收测试系统测试集成测试单元测试V模型C版本（3）用户需求需求分析概要设计详细设计编程验收测V模型（4）V模型：PaulRook在20世纪80年代后期提出，最具有代表意义的测试模型，是软件开发瀑布模型的变体，反映了测试活动与分析和设计的关系。两个特点：展示了动态测试的全过程，并定义了动态测试与开发之间的关系。动态测试的行为与开发过程的行为相对应，测试基础是对应开发阶段的文档。V模型（4）V模型：PaulRook在20世纪80年代后期V模型（5）三个缺点：测试与开发文档之间很少有完美的一对一关系。完全没有提及静态测试，忽略了代码审查、需求规格说明审查等重要的测试手段。软件测试时间经常由于前期开发阶段进度的拖延而被挤占，甚至取消，从而使得测试质量得不到保证。V模型（5）三个缺点：W模型（1）W模型（1）W模型（2）W模型：PaulHerzlich在1993年提出，对V模型的改进，表明测试与开发的并行关系，充分体现测试贯穿于整个开发过程。两个特点：W是V的发展，强调测试应在整个开发周期进行。W和V一样，开发行为与测试行为一一对应，但W并不主张动态测试必须要与开发阶段对应起来，W也不限制动态测试行为必须严格地基于开发行为产生的单一文档W模型（2）W模型：PaulHerzlich在1993年提W模型（3）缺点：在W模型中，需求、设计、编码等活动是串行的，测试和开发活动也保持一种线性的前后关系。只有上一个阶段完成之后，才能正式开始下一个阶段工作，从而无法支持迭代的开发模式。W模型（3）缺点：H模型（1）H模型（1）H模型（2）H模型：将测试活动视为一个完全独立的活动，具有独立的包括测试准备活动和测试执行活动的流程。只要测试准备就绪，就可以开始测试执行活动。在整个开发周期内，存在多个这样独立的测试流程。体现“尽早准备、尽早执行”的思想，并且不同测试活动可以按照合理的顺序进行。H模型（2）H模型：将测试活动视为一个完全独立的活动，具有独软件测试过程模型选取策略（1）V强调整个开发中需要经历不同的测试阶段，但忽略了测试对象不应该仅仅是程序。W弥补了V的不足，但并没有将一个完整测试过程抽象出来，成为一个独立的流程，不适合于广泛应用的迭代模型。H明确指出了测试的独立性，只要测试条件成熟，就可以展开测试。要根据不同测试任务要求，综合各模型对项目有实用价值的方面。软件测试过程模型选取策略（1）V强调整个开发中需要经历不同的软件测试过程模型选取策略（2）一个建议策略：以W模型为基本框架，从开发过程一开始就介入，并与开发过程同步开展相应的测试工作，同时灵活运用H模型独立测试的思想，只要满足就绪条件就进行独立的测试，并对测试工作进行迭代，直至完成测试目标。体现了尽早测试、全面测试、独立迭代测试的思想。软件测试过程模型选取策略（2）一个建议策略：建议的模型建议的模型软件测试阶段需求规格说明书审查设计说明书和代码审查单元测试集成测试功能测试确认测试系统测试验收测试安装测试软件测试阶段需求规格说明书审查软件测试方法从测试是否针对系统的内部结构和具体实现算法的角度可以分为黒盒测试和白盒测试。从测试是否需要执行被测软件的角度可以分为静态测试和动态测试。从测试执行时是否需要人工干预的角度可以分为人工测试和自动测试。软件测试方法从测试是否针对系统的内部结构和具体实现算法的角度黒盒测试（1）这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。黑盒测试又叫做功能性测试或数据驱动测试。黒盒测试（1）这种方法是把测试对象看做一个黑盒子，测试人员完黒盒测试（2）黑盒测试在程序接口和用户界面进行测试，主要是为了发现以下错误:

是否有不正确或遗漏了的功能?

在接口上，能否正确接受输入数据，能否输出正确的结果?

是否有数据结构错误或外部信息(例如数据文件)访问错误?

性能上是否能够满足要求?界面是否错误，是否不美观？

是否有初始化或终止性错误?黒盒测试（2）黑盒测试在程序接口和用户界面进行测试，主要是为白盒测试（1）此方法把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构性测试或逻辑驱动测试。白盒测试（1）此方法把测试对象看做一个透明的盒子，它允许测试白盒测试（2）软件人员使用白盒测试方法，主要想对程序模块进行如下的检查：对程序模块的所有独立的执行路径至少测试一次；对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次；在循环的边界和运行界限内执行循环体；测试内部数据结构的有效性。白盒测试（2）软件人员使用白盒测试方法，主要想对程序模块进行静态测试静态分析，对模块的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和仿真运行，采用人工检测和计算机辅助静态分析手段进行检测。静态测试包括对各阶段的软件产品进行审查。静态测试静态分析，对模块的源代码进行研读，查找错误或收集一些动态测试通过观察代码运行时的动作，来提供执行跟踪、测试覆盖率方面的信息。通过有效的测试用例，对应的输入/输出关系来分析被测程序的运行情况。动态测试通过观察代码运行时的动作，来提供执行跟踪、测试覆盖率软件评审30％－70％的缺陷是通过软件评审发现.起源于20世纪50－60年代，由管理人员对文档进行的较简单的阅读和审批的质量控制实践.但是只抽查部分文档的评审不能引起开发人员对质量问题的深刻注意，故召集有关人员就文档开评审会议用于提高质量.1976年IBM开始采用软件评审方法，取得很好的效果.软件评审30％－70％的缺陷是通过软件评审发现.软件评审的优点（1）早发现错误早纠正，从而降低开发成本.除了开发人员参加外，用户也要参与，这样可以兼容各家之长，从不同的视角考虑问题发现的缺陷较显见，而软件测试是从迹象判断缺陷存在（实际输出与预期输出不符），再根据各种现象分析，才能判断造成缺陷的原因，这是一个困难的过程.软件评审的优点（1）早发现错误早纠正，从而降低开发成本.软件评审的优点（2）测试需对各个缺陷分别进行分析定位再纠正，而软件评审往往可以成批发现缺陷，同时也可以成批纠正缺陷，效率较高.测试时发现缺陷，程序人员往往急于纠正，而不能冷静考虑修正方案，会导致错上加错.而软件评审在早期，软件开发人员往往能够从容对待，全面衡量选择修改方案.软件评审的优点（2）测试需对各个缺陷分别进行分析定位再纠正，通用的评审过程计划概述准备评审会议返工跟踪通用的评审过程计划规格说明书审查需求分析规格说明书是否完整、正确、清晰是软件开发成败的关键。测试人员要参与系统需求分析，认真阅读用户需求分析文档，真正理解用户需求，检查规格说明书对产品描述的准确性、一致性等。规格说明书审查需求分析规格说明书是否完整、正确、清晰是软件开高级审查设身处地为用户着想研究现有的标准和规范1、公司惯用语和约定2、行业要求3、国家标准4、硬件和网络标准5、图形用户界面（GUI）审查和测试同类软件高级审查设身处地为用户着想低级审查属性检查清单完整、准确、精确、一致、贴切、合理、代码无关、可测试术语检查清单是否有绝对、肯定和切实认定的叙述，针对其设计用例比较模糊的用语，某些、有时·····功能清单是否有等等、诸如此类、依此类推，无法测试的词汇在性能上不确定的说法隐藏大量需要说明的功能如果·····那么·····（没有否则）低级审查属性检查清单设计说明书和代码审查软件设计是基于对用户需求的理解基础上，采用计算机技术，将用户的需求转换成计算机软件表示的过程，设计的结果用系统结构、数据输入、详细处理过程、数据存储模式、数据输出表示。可以按照需求规格说明书对系统结构的合理性、处理过程的正确性进行评价，利用关系数据库的模式理论对数据库模式进行审查。静态白盒测试方法：在不执行的条件下有条理地仔细审查软件设计和代码。设计说明书和代码审查软件设计是基于对用户需求的理解基础上，采静态白盒测试：选择要审查代码模块的准则对于正确操作产品起关键作用的模块；复杂度较高的模块；与过去发生错误率较高的模块功能类似的模块；相对较新的或缺乏经验的软件程序师编写的模块.静态白盒测试：选择要审查代码模块的准则对于正确操作产品起关键静态白盒测试：桌前检查是一种传统的方法，由程序员检查自己编写的程序，程序员在程序通过编译之后进行单元测试之前，对源代码进行分析、检验并补充相关的文档，目的是发现程序中的错误.检查项目包括：检查变量的交叉引用表；检查子程序、宏、函数；常量检查；标准检查；风格检查；比较控制流；选择、激活路径；对照程序的模块设计书；补充文档。静态白盒测试：桌前检查是一种传统的方法，由程序员检查自己编写静态白盒测试：代码评审（1）由若干个程序员和测试员组成一个评审小组，通过阅读、讨论和争议，对程序进行静态分析的过程.代码评审分两步:小组负责人提前把设计规约、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为评审的依据.小组成员在充分阅读材料后召开程序审查会.静态白盒测试：代码评审（1）由若干个程序员和测试员组成一个评静态白盒测试：代码评审（2）会前，给评审小组每个成员准备一份常见的错误清单（检查表）：列出程序中可能发生的各种错误，并进行分类.代码评审之后，需要完成以下事情：把发现的错误登记造表，并交给程序员；若发现错误较多，或发现重大错误，则在改正之后再次组织代码评审；对错误登记表进行分析、归类、精练以提高审议效果.静态白盒测试：代码评审（2）会前，给评审小组每个成员准备一份静态白盒测试：走查基本同代码评审，过程分为两步：将材料分发给走查小组每个成员，先认真研究程序；开会.不同的是不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当”计算机.静态白盒测试：走查基本同代码评审，过程分为两步：常见的错误类型数据引用错误数据声明错误计算错误比较错误控制流程错误子程序参数错误输入/输出错误其他检查常见的错误类型数据引用错误数据引用错误

指使用未经正确初始化用法和引用方式的变量、常量、数组、字符串或记录而导致的软件缺陷.是否引用了未初始化的变量？数组和字符串的下标是整数值吗？是否在应该使用常量的地方使用了变量？变量是否被赋予不同类型的值？为引用的指针分配内存了吗？一个数据结构是否在多个函数或者子程序中引用，在每一个引用中明确定义结构了吗？数据引用错误 指使用未经正确初始化用法和引用方式的变量、数据声明错误 指不正确地声明或使用变量和常量.所有变量都赋予正确的长度和类型了吗？变量是否在声明的同时进行了初始化？存在声明过、但从未引用或者只引用过一次的变量吗？在特定模块中所有变量都显示声明了吗？数据声明错误 指不正确地声明或使用变量和常量.计算错误

计算无法得到预期结果.计算中是否使用了不同数据类型的变量？计算中是否了解和考虑到编译器对类型或长度不一致的变量的转换规则？在数值计算过程中是否可能出现溢出？除数/模是否可能为零？变量的值是否超过有意义的范围？对于包含多个操作数的表达式，求值的次序是否混乱，运算优先级对吗？计算错误 计算无法得到预期结果.比较错误

比较和判断错误很可能是边界条件问题.比较得正确吗？存在分数或者浮点值之间的比较吗？如果有，精确问题会影响比较吗？每一个逻辑表达式都正确表达了吗？逻辑计算如期进行了吗？求值次序有疑问吗？逻辑表达式的操作是逻辑值吗？比较错误 比较和判断错误很可能是边界条件问题.控制流程错误

编程语言中循环等控制结构未按预期方式工作，通常由计算或者比较错误直接或间接造成.如果程序包含begin…end和do…while等语句组，end是否对应？程序、模块、子程序和循环能否终止？可能存在永远不停的循环吗？循环可能从不执行吗？控制流程错误 编程语言中循环等控制结构未按预期方式子程序参数错误 来源是软件子程序不正确地传递参数.子程序接受的参数类型和大小与调用代码发送的匹配吗？如果子程序有多个入口点，引用的参数是否与当前入口点没有关联？常量是否当作形参传递，意外在子程序中改动？子程序参数错误 来源是软件子程序不正确地传递参数.输入/输出错误

包括文件读取、接受键盘或鼠标输入以及向打印机或者屏幕等输出设备写入错误.软件是否严格遵守外部设备读写数据的专用格式？文件或者外部不存在或者未准备好的错误情况有处理吗？软件是否处理外部设备未连接、不可用，或者读写过程中存储空间占满等情况？软件以预期方式处理预计的错误吗？检查错误提示信息的准备性、正确性、语法和拼写了吗？输入/输出错误 包括文件读取、接受键盘或鼠标输入以及向打印其他检查软件是否使用其他外语？是否处理扩展ASCII字符？是否需要用统一编码取代ASCII？软件是否要移植到其他编译器？是否考虑了兼容性，以使软件能够运行于不同数量的可用内存，不同的内部硬件？程序编译是否产生“警告”或“提示”信息？其他检查软件是否使用其他外语？是否处理扩展ASCII字符？是单元测试对系统的最小单元模块或组件进行测试，在编码阶段进行，主要使用白盒测试方法，从程序的内部结构出发设计测试用例，检查模块或组件已实现的功能与定义的功能是否一致，编码是否存在错误。多个模块平行、独立地测试，通常需要编写驱动模块和桩模块。一般由编程人员和测试人员共同完成，除了采用动态测试方法之外，还会采取代码走查、静态分析等辅助手段。是为了发现编码和详细设计阶段产生的错误。单元测试对系统的最小单元模块或组件进行测试，在编码阶段进行，集成测试在单元测试的基础上，将模块按照设计要求组装起来同时进行测试，主要目的是发现与接口有关的模块之间的问题。集成方式（将模块组装起来形成一个可运行的系统）直接影响测试成本、测试计划、测试用例的设计、测试工具的选择等。常用的两种集成方式是一次性和增值式。是为了发现概要设计阶段产生的错误。集成测试在单元测试的基础上，将模块按照设计要求组装起来同时进功能测试一般在集成测试完成后进行，针对应用系统进行测试。基于产品功能说明书，在已知产品所应具有的功能，从用户角度来进行功能验证，以确定每个功能是否都能正常使用。测试时，不考虑程序内部结构和实现方式，只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，保持外部信息（数据库