软件测试考试重点总结

软件工程要点软件是程序+数据+文档。软件危机产生的具体原因：需求不明确、缺乏理论指导、软件开发规模和复杂度不断增大。为了消除软件危机，引入了软件工程的概念，即使用系统化、规范化、数量化等工程化的方法和原则进行软件开发和维护。越早发现软件缺陷，修复缺陷的花费就越少，尤其是在需求和设计阶段。软件工程三要素：方法（如何开发软件）、工具（提高效率）和过程（将方法和工具结合，规定方法使用的顺序、每个阶段交付物等）。软件工程框架：目标、过程和原则。目标：生产具有正确性、可用性、开销适宜、进度保障并且项目成功的软件产品。过程：生产一个成功软件产品的步骤，包括开发过程、运作过程和维护过程，这些过程覆盖需求、设计、编码、测试、维护等一系列活动。原则：在生产软件产品的过程中要遵循一些原则，比如选择适宜的开发模型、合适的设计方法等。软件生命周期（人有生命周期，软件也存在生命周期）：定义（项目计划、需求分析等）设计（概要设计+详细设计）、实施（编码）、测试和维护等活动。这种按时间、按阶段划分任务是软件工程一种思想。软件生命周期模型瀑布模型、迭代模型、快速原型模型、增量模型、螺旋模型、敏捷开发、软件构件概念：让软件开发像机械制造工业一样，可以用各种标准和非标准的零件来进行组装。好处：降低成本、构件复用。软件重用：可以原封不动的拿来用或进行修改后在使用。SOA(Service-OrientedArchitecture）,也叫面向服务的体系结构或面向服务架构)是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。重点是S服务和A架构。QA是针对过程进行质量管理，Tester是针对软件进行测试。软件项目管理内容包括需求管理、项目估算与进度管理、配置项管理、风险（潜在的问题）管理、项目质量管理、项目资源管理（资金、财物等）。软件项目管理的根本目的是通过对成本、人员、进度、质量、风险等进行分析和管理，使软件项目的整个生命周期都能在有效的控制下，按照预定的成本、进度、质量顺利完成。配置管理是对产品进行标识、存储和控制，以维护其完整性、可追溯性以及正确性的学科。最终目标是实现软件产品的完整性、一致性、可控性，使产品极大程度地与用户需求相吻合，它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理功能。软件配置项：操作手册、服务、软件包、协议等，即在软件开发过程中产生的文档、数据、程序等。我们通过配置管理（控制、记录、追踪）将配置项管理起来。比如，需求阶段的配置项有需求文档、设计阶段有概要设计文档、详细设计文档。配置项通常会有一个基线，如果后期有变更，需要更新基线。V模型软件测试基础引起缺陷的原因：人自身原因、时间压力、复杂的外部系统、技术的革新、复杂的代码、复杂的系统架构，主要体现在程序和文档中。软件测试立场不同，测试的目的不同。开发者角度确认软件已正确地实现了用户的要求，证明软件中不存在错误，建立对软件质量的信心；用户角度发现软件中隐藏的错误和缺陷，以考虑是否可接受该产品。软件测试目的：发现缺陷，提高质量；验证是否满足需求；建立软件质量的信心。软件测试原则：（1）测试显示缺陷的存在；（2）穷尽测试是不可能的；（3）测试尽早介入；（4）缺陷集群性（80-20原则）；（5）杀虫剂悖论；（6）测试活动依赖于测试背景；（7）不存在缺陷的谬论。质量度量是为了改进软件测试的质量，提高测试效率，改进测试过程的有效性。软件测试工作流程：测试计划、测试需求分析和用例设计、实现和执行测试用例、测试出口准则和报告、测试活动结束，其中控制贯穿整个测试工作流程。基于生命周期的软件测试1、软件测试与软件开发一样，都是一个过程。包括测试流程和方法，及管理测试项目的进度、质量和成本，还有一系列覆盖整个测试阶段的任务。2、全生命周期测试意味着测试与开发并行，有利于尽早的发现缺陷，缩短项目开发的周期。3、生命周期各阶段测试工作划分：需求、设计、编程、测试、安装/集成、维护，不同的阶段测试重点不同。需求阶段重点是定义的需求要符合客户的要求；（需求阶段是非常重要的，需求没有做好，后期工作会很难开展）设计和编程阶段重点是验证设计和程序实现了需求；（是否实现了用户提出的需求）测试和安装阶段重点是检查实现的系统是否符合系统说明书；维护阶段重点重新测试系统改变的部分和未改变部分能正常工作。扩展：项目的概念：包含起始点和结束点，属于范围的范畴。通常维护阶段是在项目结束之后，一般不属于项目的范畴。4、测试计划是描述要进行的测试活动的范围、方法、资源和进度的文档。测试计划最关键的一步就是将软件分解成单元，写成测试需求。5、测试的准入和准出条件P1036、基于风险的软件测试风险就是潜在的问题，风险的级别是由两方面（维度）决定的，即出现不确定事件的可能性和出现后所产生的影响。比如地震出现的可能性和影响跟地理位置有关。如何处理风险？什么都不做，接受风险；转移风险；减轻风险；避免风险。基于风险的软件测试是指首先评估被测软件的风险，然后根据不同的风险采用不同力度的测试。步骤：（1）列出风险列表（2）评估每个风险的级别（3）进行考察每个风险的测试（4）当风险消失而新的风险出现时，重新调整测试策略。基于风险的测试是一种有效的测试方法，在什么情况下可以使用？测试任务面临时间压力（测试时间不够）、系统需求质量不高或不完整、风险级别。基于风险的软件测试的活动实践：（1）根据风险确定测试优先级（2）根据风险情况确定测试完备性，例如风险越大需要测试更充分和完备（3）确定测试资源的分配（4）及时监控测试进度（5）加速测试信心提升。7、生命周期各个阶段的测试要求需求阶段：需求阶段测试目标是保证需求分析的正确性和充分性。设计阶段：设计阶段要根据需求分析详细定义要交付的产品。之后要对交付物进行评审。编码阶段：编码阶段首要问题是编码是否和设计一致，因为编码是根据设计进行的。这个阶段要输出编码说明书、程序文档、可执行程序、流程图等。测试阶段：在全生命周期的测试中，需求、设计、编码都进行了测试，这里测试主要是第三方的确认测试，来检验所开发的系统是否按照用户提出的要求运行。测试阶段会经过一系列的测试活动，比如功能测试、性能测试、强度测试等，最终需要生成测试报告。安装阶段：安装阶段测试准备有安装计划、安装流程图、安装文件和程序清单、安装的预期结果以及安装过程中出现问题的应对措施、用户手册等。验收阶段：首先定义用户角色，定义验收的标准，编制验收计划，执行验收计划，填写验收结论。维护阶段：维护阶段重点是测试和培训（维护阶段由运维人员完成，我们需要培训相关人员正确使用软件）评审的目的是发现问题，并非找缺陷。评审在测试的各个阶段都要进行。软件测试分类与分级1、软件配置项是为独立的配置管理而设计的且能满足最终用户要求的一组软件，简称软件配置项。即我们在软件开发过程中，产生的所有信息，包括代码（目标代码和源代码）、文档（需求文档、设计文档等）、报告（测试报告等）。要成为配置项必须经过审核。比如，新生成的需求分析文档，需要经过审核，审核通过才能成为配置项，如果增加需求，就需要提交变更申请，经过需求变更委员会CCB的审核，进行变更。2、软件配置管理就是来管理这些配置项的投放和变更，即项目过程中，不断产生新的信息，就需要记录并报告配置的状态和变更要求，验证配置的完整性、正确性和一致性。3、基线是指受配置管理控制的某个研制阶段的结束点时软件成分的技术状态，是已经经过正式审核和同意，它是下一步软件开发的基础。在产生新的配置项后，需要对其进行评审，一旦评审通过，该配置项就可以成为基线。4、软件测试分类：从不同的角度，分类不同。是否关心内部结构：白盒、黑盒、灰盒测试；开发过程级别：单元、集成、系统、验收测试；是否执行程序：静态测试、动态测试；执行过程是否需要人工干预：手工测试、自动化测试；测试实施组织：开发测试、用户测试、第三方测试。5、基于CSCI的软件测试分类，共有6大特性，13个测试内容。并非所有的测试内容都需要测试，要根据需求说明有选择的测试。6、根据不同的情况对软件测试的分级也会有所不同，常关注的分级主要有生命周期测试的分级、错误及其对软件测试通过影响的分级、完整性测试的分级、测试用例的分级等。7、单元测试主要发现组件内部的功能性和非功能性的问题，其中功能性包括：逻辑错误和功能丢失；非功能性包括：语法错误、缺少注释、代码不具有良好结构性、空指针、数组越界等。（这里单元可以使单独的模块、也可以使程序或者功能）。集成测试主要对接口进行测试以及检查与系统其它部分相互作用的测试。系统测试强调测试环境，测试环境不是生产环境，需要接近用户的真实环境。在需求规格说明书中每一个功能描述可能会有一个或者多个需求。测试策略用于描述某项特定测试工作的方法和目标。系统测试要交付的文档：系统测试计划、系统测试计划评审报告、系统测试用例、系统测试用例评审报告、系统测试脚本、系统测试脚本评审报告、系统测试报告、系统测试报告评审报告、缺陷跟踪记录等。软件错误分级分为两方面：错误分类和错误级别划分。错误分类按软件生命周期分类有用户需求错误、产品需求错误、设计错误、编码错误、数据错误、发行错误。按软件使用分类有功能错误、性能错误、界面错误、流程错误、数据错误、提示错误（能够正确提示信息）、常识错误等。按GB/T15532-2008分类有程序问题、文档问题、设计问题等。错误级别划分大致分为5级，第1级是严重缺陷（死机、死循环等）、第2级是较严重缺陷（重要功能无法使用等）、第3级是一般性缺陷、第4级是较小缺陷、第5级是其他缺陷。通常前两级或前三级的缺陷是必须修复的。注：以上错误分类根据不同公司要求会有变化。软件缺陷管理1、任何软件都存在缺陷，软件缺陷包括检测缺陷（交付给用户之前检测出的缺陷）和残留 缺陷（软件发布之后存在的缺陷）。软件缺陷主要体现在3方面，即软件错误、软件失效和软件故障。其中软件失效指软件功能的能力丧失、程序操作背离了程序需求。软件故障是软件没有表现出人们所期待的正确结果（常指发布之后使用中出现的问题），软件故障属于残留缺陷，危害较大。2、判断缺陷的5条原则：（1）软件未实现产品说明书要求的功能（2）软件出现了产品说明书指明不应该出现的错误（3）软件实现了产品说明书中未提到的功能（4）软件未实现产品说明书虽未明确提及但应该实现的目标（5）软件难以理解、不易使用、运行缓慢或者从测试员的角度看最终用户认为不好。例如：（1）计算器产品规格说明书规定能够进行加法运算，但测试过程中按下加法按钮没有反应。（2）产品规格说明书还可能规定计算器不会死机，或者停止反应。如果随意敲键盘导致计算器死机或停止反应。（3）如果使用计算器进行测试，发现除了加、减、乘、除之外还可以求平方根，但是产品规格说明没有提及这一功能。（4）在测试计算器时若发现电池没电会导致计算不正确，而产品说明书是假定电池一直都有电的。（5）测试发现按钮太小、界面不美观等。3、缺陷产生的原因？（1）需求定义不完善（2）客户与开发之间没有良好的沟通（3）对软件需求的故意偏离（4）逻辑设计错误（5）编码错误（6）不符合文档编制与编码规定（7）测试过程不足（8）规程/标准错误（9）文档编制错误4、经过对以上原因的调查分析，发现缺陷主要产生在需求分析阶段和设计阶段。其中在需求阶段，会产生软件需求规格说明书，说明书中规定了软件应该实现的功能、不应该出现的功能、功能模块是如何操作的、软件要满足哪些性能要求等。需求规格说明书经过评审（属于静态测试）后就成配置项。需求阶段会生成需求跟踪矩阵RTM，在后期各个阶段通过对比RTM，获得需求覆盖程度。5、我们的目的是找出缺陷，但是有很多缺陷难以找出，主要的原因有：（1）缺陷很难看到（2）缺陷看到了很难抓到（3）抓到了无法修改或很难修改（4）人们随时都会犯错，造成软件中存在缺陷。6、缺陷的描述即当我们发现缺陷后，如何记录缺陷并把它描述出来，就需要描述如下信息：（1）可追踪信息，即缺陷ID，具有唯一性；（2）缺陷的基本信息，包括缺陷标题、严重程度、紧急程度等；（3）缺陷的详细描述，主要包括缺陷产生的情况、缺陷重现步骤等；（4）测试环境说明，即在什么环境下进行的测试，有助于缺陷重现；（5）必要的附件，例如发生缺陷时的截图等。（6）统计信息7、在缺陷描述的基础上，还要对缺陷进行分类，在分类之前我们首先需要知道缺陷的属性，缺陷的属性包括属性名称描述、缺陷标识、缺陷类型、严重程度、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷根源等。并非严重程度越高修复缺陷的优先级就越高，因为有些项目时间紧迫，并且修改这一缺陷会涉及项目其他各个模块，在这种情况下，该缺陷可能会遗留下来。在测试过程中会产生很多缺陷，因此我们需要对缺陷进行分类，分成哪些类型？目前有很多组织制定缺陷分类标准，书上列出的有5中分类法，这里不再列出。通常情况下，不同的公司对缺陷的分类是不同的，会根据一些标准制定适合本公司的缺陷分类。8、实际应用中缺陷分类通常是按照以下几种形式：按缺陷的表现形式（功能、赋值、接口等）、按严重程度划分（非常严重、严重、中等、微小、其他）、按修复优先级划分（高、中、低）、按起源（需求、设计、编码及测试阶段发现的缺陷）和来源（文档、代码等）划分、按根源（造成缺陷的根本性因素）划分9、在缺陷生命周期（缺陷从提出到解决，并通过复查）过程中，不同角色有不同的工作内容：测试人员（发现缺陷）：初始化new再修正reopen关闭close开发人员（修复缺陷）：待修正open拒绝reject修正fixed项目经理（对项目负责，对产品质量负责）：待修正open待分配评审委员会（当测试与开发存在分歧时，通常由需求人员决定）：待修正open关闭close不同的公司对缺陷管理的流程也不同，角色也可能有其他分工，但大致都是以上内容。10、缺陷分析步骤：记录缺陷、缺陷分类、缺陷分析、编写缺陷分析报告。11、缺陷报告是软件测试过程中重要的文档，记录了缺陷发生的环境、缺陷的处理过程和状态、反应了测试的相关过程和状况。12、报告缺陷的基本原则：（1）尽快报告软件缺陷（缺陷发现越晚修复缺陷的成本就越高，是非线性的关系）（2）有效的描述软件缺陷（描述要短小精悍、单一、使用业界表达术语和表达方式、明确指出错误类型）好的缺陷描述能够帮助开发人员重现bug（3）在报告软件缺陷时不做任何评价（4）确保缺陷可以重现（写清楚重现步骤或者附加bug出现的图片）13、写好缺陷报告的5C原则：描述准确、语言简洁、表述清晰、内容完整、格式一致14、缺陷报告的主要内容：（1）问题报告的名称；（2）缺陷严重程度；（3）缺陷的紧急程度；（4）缺陷的提交人；（5）缺陷的提交时间；（6）缺陷所属项目或模块；（7）缺陷指定解决人；（8）缺陷指定的解决时间；(9)缺陷处理人；（10）缺陷处理结果描述；（11）缺陷处理时间；（12）缺陷验证人；（13）缺陷验证结果描述；（14）缺陷验证时间。（其中标题、bugid、严重程度、重现步骤、测试结果、附加信息）软件测试过程及测试过程管理1、软件测试是一个过程，或者需要将过程抽象成模型，该过程定义了软件测试的流程和方法，由一组有序的测试活动组成。2、常用的软件测试模型V模型：由开发模型瀑布模型变种而来，它明确了测试过程中存在不同类型、不同级别的测试，同时描述了这些测试与开发过程各个阶段的对应关系。V模型的局限性是测试进行的较晚，在编码之后进行，容易使人理解为软件开发的最后一个阶段，且主要是针对程序找缺陷，使得对需求分析阶段、设计阶段等隐藏的问题一直到后期的验收测试才发现。W模型特点：（1）尽早地和不断地进行软件测试的原则（2）增加了软件各开发阶段中应同步进行的验证和确认活动（3）W模型是双V，开发是V，测试也是与此并行的V。V模型和W模型局限性：整个活动是串行过程，无法适应需求变更等调整、无法有效支持迭代、无法体现完整测试过程。H模型，它将测试独立出来，当某个测试时间点准备完毕后，就可以进入测试阶段，适合第三方做测试。H模型也体现了分层概念，不同层次的测试按照某个次序先后进行，也可以重复进行。运用场景：V模型：需求明确，阶段明确，W模型：尽早测试，需求不足时可以先设计原型系统，通过不断与客户沟通完善需求和系统改进。测试过程中的活动及内容阶段对应阶段测试活动对应阶段的产物需求验证和确认需求说明书并制定测试计划测试需求、组织团队、测试计划设计验证和确认设计文档、模型等，测试设计及评审测试计划完善、方案、测试用例等编码代码、评审、搭建环境、单元测试测试用例及缺陷等测试执行测试、缺陷管理缺陷报告和测试报告安装安装测试、确认产品安装程序、安装文档、用户手册等维护培训、维护、变更管理、测试维护手册、测试报告等软件测试过程中关键活动提取测试需求、制定测试计划、制定测试策略和方法、开展测试设计、执行测试用例、分析测试结果CMMI软件成熟度模型，共五个级别：初始级、可重复级、定义级、管理级、优化级。CMMI提供用于过程改进的框架。测试过程主要工作内容项目启动—确定项目组长，进行项目的前期准备。测试需求分析—以软件开发需求为基础，形成可测试的内容。制定测试计划—确定测试范围、测试策略和方法，以及对风险、日程表、资源等进行分析和评估。测试设计和开发—制定测试的技术方案、设计测试用例、选择测试工具、写测试脚本等，并且进行评审。测试实施和执行—建立或设置相关的测试环境，准备测试数据，执行测试用例，并提交发现的缺陷。测试结果的审查和分析—分析测试结果，确定产品质量，提供发布依据。软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。测试计划编写内容：测试目的、测试环境（软硬件）、测试策略、测试阶段划分、功能描述及功能覆盖说明、测试用例清单（测试计划与测试用例及需求有关联）、准入准出条件、风险等。测试需求的收集（来源）：被测系统相关资料文档、客户与需求分析员的沟通、相关背景、正式与非正式培训、其他等。测试策略：测试策略描述当前测试的目标和所采用的测试方法，包括测试方式（手动/自动）、测试工具、测试量、测试策略还要描述测试不同阶段（单元测试、集成测试、系统测试）的测试对象、范围和方法以及每个阶段内所要进行的测试类型（功能测试、性能测试、压力测试等）测试文档：需求说明书、测试计划文档、测试用例文档、缺陷报告等软件静态测试1、静态测试概念：不执行程序代码而寻找代码中可能存在的错误或评估程序代码的过程。2、静态测试对象：项目开发过程中产生的相关产物，例如文档、源程序等。3、静态测试特点：不用运行程序、可以人工进行、不需要特别的条件，容易开展、测试人员要求高4、静态测试主要包括：各阶段的评审、代码检查、程序分析、软件复杂性分析、软件质量度量等。7.1各阶段评审5、一般评审主要包括：培训评审、预备评审、同行评审（需求阶段的规格说明书是评审的重要内容）6、同行评审：由开发软件产品作者以外的其他人检查工作产品，以发现缺陷并寻找改进的机会。7、同行评审类型包括：审查、小组评审、走查、桌面评审、临时评审，正式程度由强到弱，审查最正式，但也是花费较高的，通常被评审对象较重要或风险较高采用的评审类型越正式。8、审查比较正式，因此有一系列流程，包括计划、总体会议、准备、会议、返工、跟踪、因果分析。9、规格说明书的详细评审：完整性；精确性；准确性；一致性；相关性；可行性；代码无关性和可测试性7.2代码检查10、代码检查：以组为单位阅读代码，是一系列规程和错误检查技术的集合。代码检查属于静态白盒测试。主要检查代码和设计的一致性、代码对标准的遵循、代码的可读性、代码的逻辑表达正确性、代码结构的合理性。11、代码检查的内容：完整性检查；一致性检查；正确性检查；可修改性检查、可预测性检查、健壮性检查；可理解性检查；可验证性检查；结构性检查；可追溯性检查；代码标准符合性检查。12、代码检查方式：技术评审、代码审查、代码走查、桌面检查。13、代码审查的内容：代码和设计的一致性；代码执行标准的情况；代码的逻辑表达正确性；代码结构的合理性；代码的可读性。（步骤：准备、程序阅读、审查会、编写报告）11、代码审查和代码走查都是由若干程序员和测试员组成小组进行，审查更为正式，走查非正式，大多数项目团队以审查为主。12、技术评审是最正式的代码检查类型，有高度的组织化，要求每个参与者都具有较好的经验。13、代码走查主要有文档和源程序代码、检查功能、检查界面、检查流程、检查提示信息、函数检查、数据类型和变量检查、条件判断检查、循环检查、输入输出检查、注释检查、程序（模块）检查、数据库检查、表达式检查、接口分析、函数调用关系图及模块控制流程图等17项检查14、代码安全性就是你的代码在运行时，或被别人调用时产生错误的容易程度。15、代码安全性检查或静态错误分析主要用于确定在源程序是否有某类错误或“危险/不安全”的结构。一般可借助工具对代码进行安全性检查。7.3软件复杂性分析16、软件危机产生的最直接原因：软件复杂性已远远超出人们对复杂性控制的能力。17、对软件复杂性的度量主要有两种：面向过程度量和面向对象度量。18、软件复杂性由模块复杂性和总体复杂性组成，其中模块复杂性又分为模块内部结构复杂性和模块接口复杂性。19、模块接口复杂性主要体现在模块之间的调用关系上。22、软件复杂性的控制主要包括模块复杂性、模块结构复杂性和总体复杂性。23、软件模块复杂性的控制主要从模块的大小和功能来进行。聚性对模块独立性进行控制，追求高内聚低耦合）、扇入扇出、模块接口来进行。掌握Halstead复杂度计算和McCabe圈复杂度计算的思想，在实际工作中复杂的程序计算通常由测试工具来完成。面向对象度量的特性：局域性；封装性；信息隐藏；继承性；抽象。7.4软件质量模型软件质量理解为：是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。ISO/IEC9126规定，软件质量可以从以下6种特性来评价：功能性、可靠性、可用性、效率、维护性、可移植性。软件质量可用特定的软件质量特性来表示，而软件质量特性反映了软件的本质，通常用软件质量模型来描述影响软件质量的特性。软件质量度量是从整体上对软件质量进行测评在软件开发中，软件度量的根本目的是管理的需要。为什么需要度量？验证策略是否正确提供客观证据，证明我们需要做什么什么是需要做的，即提供目标和指导如果偏离目标需要干预并改进软件动态测试动态测试概念：执行程序，检查运行结果与预期结果的差异。8.1白盒测试1、白盒测试主要是从程序内部逻辑结构和编码结构设计测试数据并完成测试的测试方法，白盒测试把程序看做一个透明盒子，而黑盒测试就是把程序看做黑色的盒子，不考虑程序内容结构。2、调试和白盒测试区别：调试强调发现问题并修正，通常由程序员完成；白盒测试强调发现缺陷，通常由开发该代码的程序员或测试人员完成。3、逻辑覆盖包括：语句覆盖：强调程序中所有语句被执行过，设计的测试用例只要遍历所有语句即可。判定（分支）覆盖：强调程序中所有判定分支被执行过，设计的测试用例只要遍历所有分支即可。条件覆盖：强调程序中所有判定条件真假值被执行过，设计的测试用例只要遍历所有判定条件即可。判定/条件覆盖：上述两种覆盖的组合，即要所有判定分支被执行过，所有判定条件也要执行。条件组合覆盖：强调程序中判定条件以组合的形式被执行过，设计的测试用例只要遍历所有条件组合即可。路径覆盖：强调从程序所有可能路径出发，设计满足遍历所有路径的测试用例。4、基本路径测试步骤：将程序代码结构转换成程序控制流图计算程序控制流图的圈复杂度（设计测试用例的最少数量）列出测试路径针对测试路径设计测试用例圈复杂度的计算方法：（1）V(G)=m(弧数)-n（节点数）+p（分离的数目）判定节点+1强连通程序图在平面上围成的区域个数。8.2黑盒测试黑盒测试通常又称为功能测试或数据驱动测试，把测试对象当作看不见内容的黑盒，在不考虑内部结构和处理过程的情况下，测试人员根据程序功能需求规范考虑确定测试用例和推断测试结果的正确性。黑盒测试可以导出执行程序所有的功能需求的输入条件集，实现功能覆盖。功能覆盖中最常见的是需求覆盖。2、黑盒测试的目的是为了进行功能测试，然后找出功能点，然后再设计测试用例。3、黑盒测试方法主要有等价类划分、边界值分析、因果图、猜测法、随机测试。4、等价类划分，其中等价类，把所有可能的输入数据,即程序的输入域划分成若干部分；划分，从每一部分中选取少数有代表性的数据做为测试用例，代表性数据等同于该类中的其他值。5、边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法,稍高于其边界值及稍低于其边界值的一些特定情况，选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据的方法。例如，5<x<10一个范围，设计用例取4.9、5、5.1、7、9.9、10、10.16、边界值分析是等价类划分方法的补充，所有测试阶段都可使用7、因果图是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，该方法充分考虑了输入情况的各种组合及输入条件之间的相互制约关系。因果图产生是因为等价类法、边界值法分析着重考虑输入条件，未考虑输入条件之间的关系。8、确认测试、系统测试、验收测试都采用黑盒测试。8.3灰盒测试1、灰盒测试是一种综合性测试，结合了白盒测试与黑盒测试，既要能了解代码（可以没有开发经验），也要掌握黑盒测试常用方法。2、灰盒测试的思想：基于程序运行时的外部表现同时又结合程序内部逻辑结构来设计用例，执行程序并采集程序路径执行信息和外部用户接口结果的测试技术，其目的是验证软件满足外部指标以及软件的所有通道或路径都进行了检验。因此，在测试阶段中灰盒测试主要用在集成测试阶段。8.4测试用例设计一个好的测试用例是指可能发现迄今为止尚未发现的错误的测试。高质量测试用例的特点：正确性（要符合需求规格说明书要求）、完整性（不仅仅体现在功能测试的完整性上，还应涉及性能测试、安全测试等）、准确（开发人员执行测试步骤应能正确得到描述缺陷）、清晰简洁（测试用例描述要少而精，避免口语化）、可维护性（测试用例可以修改、删除）、适应性（符合特定测试环境或符合测试团队测试情况）、可重用性（类似测试可以修改测试用例后直接使用）、其他。测试用例的覆盖内容：正确性测试、容错性（健壮性）测试、完整（安全）性测试、接口测试、数据库测试、边界值测试、压力测试、等价划分测试、错误推测、效率、可理解（操作）性测试、可移植性测试、回归测试、比较测试。针对不同的测试类型和测试阶段，测试用例编写的侧重点不同，并非以上内容都要覆盖。测试用例主要元素：测试环境、测试数据、测试步骤、测试结果。测试用例编写要素：标识ID、标题、描述、环境、步骤、预期结果、实际结果、备注。测试用例的注意事项功能检查面向用户考虑数据处理软件流程测试测试用例的设计步骤测试需求分析：分析需求文档，明确测试对象业务流程分析：不仅仅要明确功能测试，还需要对整个业务逻辑和处理流程有清晰的认识测试用例设计测试用例评审：有利于查出测试用例存在的缺陷和漏洞，增强测试用例的正确性测试用例更新完善测试用例分级：重要性和优先级（高、中、低）测试用例的误区。8.5单元测试1、单元测试又称模块测试是开发者编写的一段测试代码，用来检测被测代码的一个很小的、很明确的功能是否正确。2、单元测试由于涉及代码和程序内部逻辑结构，主要以白盒测试为主，黑盒测试为辅。3、单元测试主要5方面内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试4、单元测试是在编码、编译、静态分析和代码审查后进行的。5、在项目开发中，通常情况下一些模块会先被开发完毕，但跟这些模块存在关联的其他模块还没有开发完毕，这时对其进行测试就需要我们自己编写驱动模块和桩模块来代替未开发完的模块。6、驱动模块相当于所测模块的主程序，例如c语言中的main函数，我们传入用例参数通过驱动模块来调用需要测试的模块。7、桩模块相当于未开发出的模块，属于被测模块的下级模块，代替由被测模块所调用的模块的功能。8、由驱动模块、被测模块和桩模块就构成了一个完成的环境。驱动模块用于模拟被测模块的上层模块，测试执行时由驱动模块调用，桩模块模拟被测模块执行过程中所调用的模块，测试执行时，桩模块使被测模块能完整闭合地运行。9、单元测试中的驱动模块和桩模块不属于要交付的产品，因此在开发结束后就不使用了，所以在设计时要尽量简单。10、单元测试步骤：构造测试用例环境（准备好驱动模块和桩模块）、设计黑盒测试用例（主要验证该模块实现的功能）、设计白盒测试用例（找出单元内部控制结构和数据使用可能存在的问题）。8.6集成测试集成测试又称组装测试或联合测试，是单元