软件测试基础理论知识1.doc

软件测试基础理论知识软件测试分类按测试方式分类手工测试自动测试按是否执行被测软件分类静态测试动态测试按内部结构和算法分类白盒测试(结构测试/逻辑驱动测试)黑盒测试(功能测试/数据驱动测试)灰盒测试(届于白盒、黑盒之间，考虑一部分内部结构)按测试阶段分类单元测试 集成测试系统测试验收测试按测试性质分类功能测试性能测试(负载测试、压力测试（区别）？、冒烟测试)安全测试配置测试兼容性测试一定进行的测试回归测试确认测试静态测试与动态测试的区别：配置测试白盒测试/结构测试软件测试静态测试动态测试黑盒测试单元测试集成测试系统测试验收测试性能测试安全测试兼容性测试灰盒测试/白、黑之间确认测试负载测试压力测试冒烟测试功能测试静态测试静态测试定义指无须执行被测代码。而是借助专用的软件测试工具评审软件文档或程序，度量程序静态复杂度，检查软件是否符合编程标准，借以发现编写的程序的不足之处，减少错误出现的概率。静态测试在主机上完成，不需目标系统支持，测试的主要内容有编程标准验证、数据流分析技术、质量度量信息、代码结构可视化显示、测试外壳的创建。由此看出，静态测试只是对代码进行扫描分析，检测它的语法规则复杂度等是否符合要求，主要是为软件的质量保证提供依据，以提高软件的可靠性和易维护性。专用的测试工具：AutomatedQA AQtime：能实时/静态地分析软件的执行效率和代码性能，发现软件项目客户端和服务器段的瓶颈所在、内存泄漏、消耗资源的代码及未经验证的算法。能够分析Delphi/BCB/VC/VB/GCC等工具开发的软件产品，此外，它有专门For VS.NET的版本。AQTime是专业开发者在开发过程中消除臆测的完全方案，使开发者在完成项目时开发出坚如磐石的程序。通过AQTime无可匹敌的报告系统和测试分析架构，开发这不仅可以得知其项目中确实存在bug和瓶颈，而且会知道具体到哪个模块、类、线程、代码行出了问题，从而快速消除错误静态测试具有以下特点 1、静态测试不必动态地运行程序，也不必进行测试用例设计和结果判断等工作； 2、静态测试可以由人工进行，充分发挥人的逻辑思维优势； 3、静态测试实施不需要特别的条件，容易开展。 静态测试内容 一、代码检查：1、代码审查 - Code Inspection 或 Code Review 用人工审查被测试的程序。评测人员把这种方法称为“穿越程序沙漠”，因为面对动辄是数万行的代码，要求测试人员不但要读懂、“吃”透，更要查出错误2、代码走查 - Walkthrough 是以小组为单元进行代码阅读的，同样也是一系列规程和错误检查技术的集合。一般是由三至五人组成，其中一人扮演“协调人”；一人担任秘书角色，负责记录所有查处的错误；还有一人担任测试人员。与代码审查就是参与者“使用了计算机”。被指定为测试人员的那个人会带着一些书面的测试用例（程序或模块具有代表性的输入集及预期的输出集）来参加会议。且在会议期间，每个测试用例都在人们头脑中进行推演，即：把测试数据沿程序的逻辑结构走一遍，并把程序的状态（如变量的值）记录在纸张或白板上以供监视。3、桌面检查 对程序执行情况进行人工模拟，用逐步检查源代码中有无逻辑或语法错误的办法来检测故障代码检查内容：1、检查代码和设计的一致性；2、检查代码对标准的遵循、可读性；3、检查代码的逻辑表达的正确性；4、检查代码结构的合理性等方面。代码检查目的：1、发现违背程序编写标准的问题；2、发现程序中不安全、不明确和模糊的部分；3、找出程序中不可移植部分、违背程序编程风格的问题。变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。 代码检查前提：1、需求描述文档；2、程序设计文档； 3、程序的源代码清单、代码编码标准；4、代码缺陷检查表。代码检查优缺点：优点：1、能快速找到缺陷，发现30%70%的逻辑设计和编码缺陷；2、检查看到的是问题本身而非征兆。缺点：1、代码检查非常耗费时间；2、需要知识和经验的积累。 二、技术评审1、软件需求分析；需求分析的具体内容： 业务需求反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。 用户需求描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。 功能需求定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。 非功能性的需求描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。 需求分析报告报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。2、设计评审。 三、静态分析：静态分析 主要是以图形的方式表现程序的内部结构1、函数调用关系图；函数调用关系图以直观的图形方式描述一个应用程序中各个函数的调用和被调用关系2、函数内部控制流图。控制流图显示一个函数的逻辑结构，它由许多节点组成，一个节点代表一条语句或数条语句，连接结点的叫边，边表示节点间的控制流向四、代码质量度量ISO/IEC 9126国际标准所定义的软件质量包括六个方面：功能性、可靠性、易用性、效率、可维护性和可移植性。软件的质量是软件属性的各种标准度量的组合。动态测试动态测试定义被测代码在相对真实环境下运行，从多角度观察程序运行时能体现的功能、逻辑、结构等行为，以发现其中的错误现象。动态测试分为黑盒测试和白盒测试。 动态测试具有以下特点 1、实际运行被测试程序，取得程序运行的真实情况、动态情况，进而进行分析。 2、生成测试数据来运行程序，测试质量依赖于测试数据。 3、生成测试数据、分析测试结果工作量大，使开展测试工作费时、费力、费人。 4、动态测试中涉及多方面工作，人员多、设备多、数据多，要求有较好的管理和工作规程。 动态测试包括的核心内容功能确认与接口测试 这部分的测试包括各个单元功能的正确执行、单元间的接口，内容包括：单元接口、局部数据结构、重要的执行路径、错误处理的路径和影响上述的边界条件等内容。覆盖率分析 主要对代码的执行路径覆盖范围进行评估，各种覆盖都是从不同要求出发，为设计测试用例提出依据的。其中覆盖包括：语句覆盖、判定覆盖、条件覆盖、条件/判定覆盖、修正条件/判定覆盖、基本路径覆盖等性能分析 代码运行缓慢是开发过程中一个重要问题。一个应用程序运行速度较慢，程序员不容易找到是在哪里出现了问题?如果不能解决应用程序的性能问题，将降低并极大地影响应用程序的质量，于是查找和修改性能瓶颈成为调整整个代码性能的关键。目前性能分析工具大致分为纯软件的测试工具、纯硬件的测试工具（如逻辑分析仪和仿真器等）和软硬件结合的测试工具三类。内存分析 内存泄漏会导致系统运行的崩溃，尤其对于嵌入式系统这种资源比较匮乏、应用非常广泛，而且往往又处于重要部位的，将可能导致无法预料的重大损失。通过测量内存使用情况，我们可以了解程序内存分配的真实情况，发现对内存的不正常使用，在问题出现前发现征兆，在系统崩溃前发现内存泄露错误；发现内存分配错误，并精确显示发生错误时的上下文情况，指出发生错误的原由。生成测试数据 这个策略有黑盒测试和白盒测试，他们构成动态测试技术的基本内容。执行程序与验证程序的输出结果。 黑盒测试 黑盒测试定义黑盒测试(Black-box Testing) 是功能测试或数据驱动测试,已知产品的测试设计规格，可以进行测试证明每个实现了的功能是否符合要求。是一种按照需求规格说明设计测试数据的测试方法。测试人员通过各种输入和观察软件的各种输出结果来发现软件的缺陷，而不关心程序具体如何实现。如：它无需顾及程序内部结构和编码结构，也不需考虑程序中的语句及路径，测试者只需了解程序输入和输出之间的关系，或是程序的功能，完全依靠需求规格说明确定测试数据，判定测试结果的正确性。即所依据的只是程序的外部特性。黑盒测试是从程序需求规格说明出发， 设计测试数据进行测试， 借以发现程序的错误， 验证程序是否符合预定的需求。 黑盒测试考察程序的输入输出特性， 而输入输出都可以抽象为数据或描述， 因此黑盒测试技术重点在于对外数据进行分析和选择， 是一种数据驱动的测试。 黑盒测试在单元测试、组装测试、确认测试及系统测试中都发挥着重要作用， 尤其在确认测试和系统测试中， 其作用是其他测试方法无法取代的。 黑盒测试规划根据用户的规格说明，即针对命令、信息、报表等用户界面及体现它们的输入数据与输出数据之间的对应关系，特别是针对功能进行测试 。 黑盒测试特点 优点：能站在用户立场上进行测试缺点：1、不能测试程序内部特定部位；2、规格说明有误，则无法发现错误黑盒测试主要是为了发现以下几类错误 1、是否有不正确或遗漏的功能？ 2、在接口上，输入是否能正确的接受？能否输出正确的结果？ 3、是否有数据结构错误或外部信息（例如数据文件）访问错误？ 4、性能上是否能够满足要求？ 5、是否有初始化或终止性错误？黑盒测试内容 功能测试 “内部控制制度功能测试”的简称。“符合性测试”的一种，是为了查明内部控制制度各项控制措施是否能充分发挥作用和实现预期目标所进行的测试。如材料采购要有批准的材料采购计划为依据，材料采购费支付要有经材料供应部门审核的凭证为依据等内部控制措施，是为了确保这些业务的合法性。复核加总金额和费用分配表，是为了计算的正确性。这些控制功能是内部控制制度正常运转的基本条件，如检查材料采购费支出凭证发现多数未经材料供应部门审核，就说明该项措施的控制功能不健全，不能过多地依赖这种内部控制制度来保证材料采购费开支的真实性、正确性和合法性。等价类划分划分等价类-确立测试用例-设计用例边值测试通过分析，考虑如何确立边界情况错误推断法靠经验和直觉来推测程序中可能存在的各种错误，从而有针对性地编写用例。可以列举出可能的错误和可能发生错误的地方，然后选择用例。因果图通过画因果图，在图上标明约束和限制，转换成判定表，然后设计测试用例。这适合于检查程序输入条件的各种组合情况。强度测试随机测试基于需求规格说明的测试白盒测试 白盒测试定义白盒测试(White-box Testing) 是结构测试，是一种按程序内部的逻辑结构和编码结构设计测试数据的测试方法。测试者可以看到被测试的内部结构，并根据其内部结构设计测试数据，使程序中的每个语句、每个条件分支、每个控制路径都在程序测试中受到检验。白盒测试可以不考虑程序的需求规格说明，有时需要设计说明作为补充，但必须从程序源代码出发设计测试数据，分析结果。白盒测试方法从考察程序的结构和逻辑出发验证所构造的程序是否符合设计要求。它可以构造使程序特定部分得到测试的数据，而黑盒测试则不能做到这一点。白盒测试规划根据程序的内部结构，如语句的控制结构，模块间的控制结构以及内部数据结构等进行测试白盒测试特点优点：能够对程序内部的特定部位进行覆盖测试缺点：1、无法检测程序的外部特性；2、无法对未实现规格说明的程序内部欠缺部分进行测试白盒测试主要是对程序模块进行如下检查 1、对程序模块的所有独立的执行路径至少测试一遍。 2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。 3、在循环的边界和运行的界限内执行循环体。 4、测试内部数据结构的有效性，等等。白盒测试内容1、语句覆盖：程序总每条语句至少被执行一次。 2、分支覆盖：程序中的每一个分支至少通过一次，即每一条分支语句的真值执行一次，假值也执行一次。 3、条件覆盖：使判定中的每个条件获得各种可能的结果。 4、条件组合覆盖：使每个判定条件中条件的各种组合至少出现一次。 5、路径覆盖：使程序沿所有可能的路径执行。6、循环测试。7、模块接口测试。 白盒测试技术白盒测试主要技术为：控制流测试和数据流测试。 控制流测试依据作为程序结构模型的控制流程图产生测试用例。通过对不同控制结构成分的测试逐步验证程序的控制结构。 顺序结构和分支结构是构成程序结构的基本元素，通过这两种结构的组合，形成程序路径。 验证某种控制结构是使这种控制结构得到一次执行，也称覆盖。基于覆盖考察对程序结构测试的完备性，称为测试覆盖准则。说明无论黑盒测试还是白盒测试，都不可能对程序进行完整的彻底的测试。黑盒测试从考虑输入数据出发验证功能，除非进行穷举，否则不可能进行完全测试。白盒测试从程序结构出发，由于程序结构的复杂性，路径数本身有时是不能确定的，所以要测试程序的全部结构也是不现实的。 单元测试 单元测试定义针对每个模块进行的测试，可从程序的内部结构出发设计测试用例，多个模块可以平行地对立地测试。通常在编码阶段进行，必要的时候要制作驱动模块和桩模块。单元测试集中在检查软件设计的最小单位-模块上，通过测试发现实现该模块的实际功能与定义该模块的功能说明不符合的情况，以及编码的错误。由于模块规模小、功能单一、逻辑简单，测试人员有可能通过模块说明书和源程序，清楚地了解该模块的I/O条件和模块的逻辑结构，采用结构测试（白盒法）的用例，尽可能达到彻底测试，然后辅之以功能测试（黑盒法）的用例，使之对任何合理和不合理的输入都能鉴别和响应。高可靠性的模块是组成可靠系统的坚实基础。 单元测试 在软件测试中，尽早进行软件测试发现软件中存在的问题，可减轻系统测试的任务，明显地降低测试成本，单元测试在软件开发哪一个环节进行，是一个值得探讨的问题，因为这关系到软件测试的效率和测试成本。从经济上和开发效率上考，单元测试尽可能在软件开发周期中完成，并在主机系统中进行，这就是说单元测试最好划归研发中心处理，而不全权由测试中心完成单元测试即对每一个单元模块进行测试.然后把测试过的模块组装起来进行集成测试,主要是对软件体系结构的构造进行测试.接着进行确认测试,检查软件是否满足了各种需求,以及配置是否合理安全.最后是系统测试,即把经确认测试后的软件放到实际运行环境中,与系统的其他构件一起进行测试.单元测试时,有时需要为测试的模块编写辅助模块:驱动模块和桩模块. 前者是用来调用被测模块;后者用来代替被测模块调用的子模块。单元测试步骤1、人工静态检查这个阶段工作主要是保证代码算法的逻辑正确性（尽量通过人工检查发现代码的逻辑错误）、清晰性、规范性、一致性、算法高效性。并尽可能的发现程序中没有发现的错误。 2、设计测试用例执行待测程序来跟踪比较实际结果与预期结果来发现错误。经验表明，使用人工静态检查法能够有效的发现30%到70%的逻辑设计和编码错误。但是代码中仍会有大量的隐性错误无法通过视觉检查发现，必须通过跟踪调试法细心分析才能够捕捉到。所以，动态跟踪调试方法也成了单元测试的重点与难点。人工检查通常在人工检查阶段必须执行以下项目的活动：第一、 检查算法的逻辑正确性；确定所编写的代码算法、数据结构定义（如：队列、堆栈等）是否实现了模块或方法所要求的功能。第二、 模块接口的正确性检查；确定形式参数个数、数据类型、顺序是否正确；确定返回值类型及返回值的正确性。第三、 输入参数有没有作正确性检查；如果没有作正确性检查，确定该参数是否的确无需做参数正确性检查，否则请添加上参数的正确性检查。经验表明，缺少参数正确性检查的代码是造成软件系统不稳定的主要原因之一。第四、 调用其他方法接口的正确性；检查实参类型正确与否、传入的参数值正确与否、个数正确与否，特别是具有多态的方法。返回值正确与否，有没有误解返回值所表示的意思。最好对每个被调用的方法的返回值用显湿代码作正确性检查，如果被调用方法出现异常或错误程序应该给予反馈，并添加适当的出错处理代码。第五、 出错处理；模块代码要求能预见出错的条件，并设置适当的出错处理，以便在一旦程序出错时，能对出错程序重做安排，保证其逻辑的正确性，这种出错处理应当是模块功能的一部分。若出现下列情况之一，则表明模块的错误处理功能包含有错误或缺陷：出错的描述难以理解；出错的描述不足以对错误定位，不足以确定出错的原因；显示的错误信息与实际的错误原因不符；对错误条件的处理不正确；在对错误进行处理之前，错误条件已经引起系统的干预等。第六、 保证表达式、SQL语句的正确性；检查所编写的SQL语句的语法、逻辑的正确性。对表达式应该保证不含二义性，对于容易产生歧义的表达式或运算符优先级（如： 、=、 、 &、|、+、 -等）可以采用扩号“（）”运算符避免二义性，这样一方面能够保证代码的正确可靠，同时也能够提高代码的可读性。第七、 检查常量或全局变量使用的正确性；确定所使用的常量或全局变量的取值和数值、数据类型；保证常量每次引用同它的取值、数值和类型的一致性。第八、 表示符定义的规范一致性；保证变量命名能够见名知意，并且简洁但不宜过长或过短、规范、容易记忆、最好能够拼读。并尽量保证用相同的表示符代表相同功能，不要将不同的功能用相同的表示符表示；更不要用相同的表示符代表不同的功能意义。第九、 程序风格的一致性、规范性；代码必须能保证符合企业规范，保证所有成员的代码风格一致、规范、工整。例如对数组做循环，不要一会儿采用下标变量从下到上的方式（如:for(I=0;I+；I0)；应该尽量采用统一的方式，或则统一从下到上，或则统一从上到下。建议采用for循环和While循环，不要采用dowhile循环等。第十、 检查程序中使用到的神秘数字是否采用了表示符定义。神秘的数字包括各种常数、数组的大小、字符位置、变换因子以及程序中出现的其他以文字形式写出的数值。在程序源代码里，一个具有原本形式的数对其本身的重要性或作用没提供任何指示性信息，它们也导致程序难以理解和修改。对于这类神秘数字必须采用相应的标量来表示；如果该数字在整个系统中都可能使用到务必将它定义为全局常量；如果该神秘数字在一个类中使用可将其定义为类的属性（Attribute）,如果该神秘数字只在一个方法中出现务必将其定义为局部变量或常量。第十一、 检查代码是否可以优化、算法效率是否最高。如：SQL语句是否可以优化，是否可以用1条SQL语句代替程序中的多条SQL语句的功能，循环是否必要，循环中的语句是否可以抽出到循环之外等。第十二、 检查您的程序是否清晰简洁容易理解。注意：冗长的程序并不一定不是清晰的。第十三、 检查方法内部注释是否完整；是否清晰简洁；是否正确的反映了代码的功能，错误的注释比没有注释更糟；是否做了多余的注释；对于简单的一看就懂的代码没有必要注释。第十四、 检查注释文档是否完整；对包、类、属性、方法功能、参数、返回值的注释是否正确且容易理解；是否会落了或多了某个参数的注释，参数类型是否正确，参数的限定值是否正确。特别是对于形式参数与返回值中关于神秘数值的注释，如：类型参数 应该指出 1.代表什么，2.代表什么，3.代表什么等。对于返回结果集(Result Set)的注释，应该注释结果集中包含那些字段及字段类型、字段顺序等。一个模块或一个方法（Method）并不是一个独立的程序，在考虑测试它时要同时考虑它和外界的联系，用些辅助模块去模拟与所测模块相联系的其他模块。这些辅助模块分为两种：1. 驱动模块（driver）:相当于所测模块的主程序。它接收测试数据，把这些数据传送给所测模块，最后再输出实际测试结果。2. 桩模块（stub）:用于代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不容许什么事情也不做。驱动模块和桩模块的编写会给测试带来额外的开销。因为它们在软件交付时不作为产品的一部分一同交付，而且它们的编写需要一定的工作量。特别是桩模块，不能只简单地给出“曾经进入”的信息。为了能够正确的测试软件，桩模块可能需要模拟实际子模块的功能，这样桩模块的建立就不是很轻松了。单元测试覆盖区域1. 单元执行的计算/操作的正确性。 2. 低级性能问题（如在重复调用单元及其功能时观察到的性能瓶颈）。 3. 低级可靠性问题（如在重复和扩展调用单元及其功能时观察到的内存不足）。 4. 屏幕/窗口的内容及导航（对于GUI单元来说），包括窗口的外观的一致性，热键、功能键和键盘快捷键的使用。 5. 报告报表的内容、布局和计算。 6. 文件/记录的创建、更新及删除。 7. 互操作单元间的通信。 单元测试方法1、 确定如何调用某个给定单元以及每次调用时该单元的响应2、 确定单元的状态以及单元如何在这些状态间转换3、 确定单元的每个状态的预期结果，以及确认这些结果所必需的内容4、 考察测试应用的需求规格说明文档及被测试的单元，确认以前的步骤已识别出了所有可能测试条件，如有必要可以增加附加条件（考虑数据初始化、边界值、错误条件以及被零除等情况）5、 确定测试该单元的先决条件（如从其他单元的输出，需要的测试辅助程序，或者特定的手工制作的测试数据）6、 使用上述信息生成一套该单元的测试用例，并将其合并为测试脚本，详细介绍测试中遵循的步骤单元测试的数据需求 使用的数据不可能是真实的数据，原因1、 有破坏商业重要的信息或业务关键信息的风险2、 真实数据可能包含敏感信息（如商业或个人详细信息）3、 数据可能包含保密性信息（如用户口令）单元测试输入1. 具有必要的文档（需求和设计信息），使得测试人员可以操作系统和判断正确行为：需求规格说明文档、原型软件、设计文档 2. 单元测试计划 3. 单元测试规范、指南 4. 单元测试方案/用例 5. 空白的测试结果记录表格（书面 或 电子形式如TD） 6. 合适的重用包，如从以前单元测试得到的重用包 单元测试输出1. 完整的被测试过的单元 2. 修正的测试方案和测试用例 3. 完成的测试结果记录表格（书面 或 电子形式如TD） 4. 单元测试重用包 5. 单元测试总结报告 6. 单元测试日志 7. 归档的测试数据 单元测试停止标准1. 在单元测试中发现的缺陷(bug)已经得到修改、定位，各级缺陷修复率达到单元测试计划或规范中关于单元测试所规定的标准（如A类Bug的修改率为100%，B类Bug的修改率为95%，C类Bug的修改率为90%，D类Bug的修改率为85%） 2. 达到了单元测试计划或规范中关于单元测试所规定的语句覆盖率的要求（如80%） 3. 按照测试计划完成了所有规定单元的测试 4. 单元测试方案用例全部执行 5. 软件单元功能与需求、设计一致，可以进行后续测试工作 集成测试 集成测试定义集成测试是将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的问题。在单元测试的基础上，将所有模块按照设计要求组装成为系统，必须精心计划，应提交集成测试计划、集成测试规格说明和集成测试分析报告如数据穿过接口时可能丢失；一个模块与另一个模块可能有由于疏忽的问题而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有错误等。 集成测试 软件集成也可在主机环境上完成,在主机平台上模拟目标环境运行,当然在目标环境上重复测试也是必须的,在此级别上的确认测试将确定一些环境上的问题,比如内存定位和分配上的一些错误。在主机环境上的集成测试的使用,依赖于目标系统的具体功能有多少.有些嵌入式系统与目标环境耦合的非常紧密,若在主机环境做集成是不切实际的.一个大型软件的开发可以分几个级别的集成.低级别的软件集成在主机平台上完成有很大优势,越往后的集成越依赖于目标环境集成测试,又叫组装测试,分为两种:一次性组装和增殖式组装.一次性组装方式即把经单元测试后的模块一次性的组装成系统进行测试.增殖式组装方式即在模块组装的过程中,边组装边测试,每增加一个或几个模块就测试一次,最后组装成最后的系统,它又分为:自顶向下的增殖,自底向上的增殖,混合增殖等几种方式.确认测试过程要做的工作包括:有效性测试,软件配置复审,验收测试和安装测试.在验收测试中常用的有测试和测试.测试时,开发者坐在用户旁边,随时记录用户发现的问题.测试则开发者不在测试现场,故是在开发者无法控制的环境下进行的测试,通常是由软件开发者向用户散发版软件,然后收集用户的意见。另外软件测试除了源程序外,还应包括软件开发各阶段的文档,如:需求规格说明书,概要设计规格说明,详细设计规格说明等。集成测试方法需要覆盖的区域包括：1、 从其他互操作模块调用一个模块2、 在互操作模块间正确传输数据3、 兼容性（即检查引入一个模块不会对其他模块的功能或性能有不好的影响）4、 非功能测试（如模块间接口的可靠性）执行集成测试应遵循下面的方法：1、 识别组成一个完整系统的模块间的关系2、 评审模块间的交互和通信需求，识别出模块间的接口3、 使用上述信息产生一套测试该模块的测试用例并将他们放入测试脚本中，测试脚本详细介绍了测试过程的步骤4、 当依次将模块加入到（扩充）系统并新合并后的系统时应采用增量测试（应考虑使用重用包） 集成测试输入1. 需求规格说明文档、原型软件、设计文档 2. 集成测试计划 3. 集成测试规范、指南 4. 集成测试方案/用例 5. 空白的测试结果记录表格（书面 或 电子形式如TD） 6. 合适的重用包，如单元测试重用包 集成测试输出1. 完整的被测试和集成过的模块 2. 修正的测试方案和测试用例 3. 完成的测试结果记录表格（书面 或 电子形式如TD） 4. 集成测试重用包 5. 简短的集成测试总结报告 6. 集成测试日志 7. 归档的测试数据 集成测试停止标准1. 在集成测试中发现的缺陷(bug)已经得到修改、定位，各级缺陷修复率达到集成测试计划或规范中关于集成测试所规定的标准（如A类Bug的修改率为100%，B类Bug的修改率为95%，C类Bug的修改率为90%，D类Bug的修改率为85%） 2. 按照集成构建计划及增量集成策略等完成了所有规定模块的集成和测试 3. 集成测试方案用例全部执行 4. 集成工作版本满足设计定义的各项功能、性能要求，各模块对接、交互正常 5. 软件整体流程已完整，可以进行后续测试工作 确认性测试确认测试定义检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准确认测试的结果有两种可能：一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。确认测试的重要环节配置复审。复审的目的在于保证软件配置齐全、分类有序，并且包括软件维护所必须的细节系统测试 系统测试定义系统测试是将通过确认测试的软件，作为整个基于计算机系统的一个元素,与计算机硬件,外设,操作系统,数据和人员结合在一起,在实际运动的环境下对计算机系统进行一系列的集成测试和确认测试由此可知，系统测试必须在目标环境下运行，当单元测试和集成测试完成之后，系统测试功用则在于评估系统环境下软件的性能，发现和捕捉软件中潜在的BUG系统测试的目的是通过测试建立被测应用将被它的用户接受的自信，即它将通过验收测试。在系统测试过程中，将证明系统的功能和结构的稳定性，以及如性能和可靠性等的非功能需求。系统测试方法1、 评审系统需求2、 识别被测应用与其他系统通信的需求及通信的手段3、 考察将要运行真实系统的计算环境，以便找出该系统与其他系统的互操作性或兼容性问题4、 检查对测试系统过程、系统文档、帮助信息以及恢复、备份和归档的需求5、 使用上述信息生成一套测试用的测试用例，并将其