软件工程 06 质量保证

软件工程第六章质量保证软件质量保证1小结4软件测试技术3软件测试策略2本章学习目标123了解质量保证活动在软件工程中的重要作用和意义掌握软件测试的常用方法理解质量保证的概念、软件测试的概念软件质量保证软件质量•定义o明确表示是否符合功能和性能要求，明确记载的开发标准和所有专业开发的软件期望的隐性特点关键点1、软件需求是软件质量测量的基础，与需求不一致就是质量不高。2、指定的标准定义了一组指导软件开发的准则，如果没有遵守这些准则，几乎肯定会导致质量不高3、通常，有一组没有显式描述的隐含需求（如期望软件是容易维护等）。如果软件满足明确描述的需求，但却不满足隐含的需求，那么软件的质量仍然是值得怀疑的。质量控制QC•定义o是审查产品相关的各个方面质量的过程•内容o元素，如控制、作业管理、明确和完善的管理过程、性能和完整性的标准、确认和记录等o能力，如知识、技能、经验和资历等o软要素，如人员廉正、信任、组织文化、激励、团队合作精神、与品质的关系•目标o建立体系并确保体系按要求运作,以提供内外部的信任质量保证QA•含义o系统地监测和评估一个工程的各个方面，以最大限度地提高正在由生产过程中实现的质量的最低标准•内容o原料、文档、产品和组件，以及涉及产品的服务、管理、生产和检测过程，上述内容的质量管理•原则o“适合用途”：该产品应符合预期的目的o“一次成功”：错误应及早发现并清除质量成本•范围o追求质量过程中或在履行质量有关活动中引起的费用以及质量不佳引起的下游费用等所有费用。包括：o预防成本o评估成本o失效成本质量计划和协调等质量管理活动为开发完整的需求模型和设计模型所增加的技术活动成本测试计划的成本与这些活动有关的所有培训成本技术审查成本数据收集和度量估算成本测试和调试成本失效成本是指如果在将产品发给客户之前或者之后没有错误就不会存在的成本。失效成本包括内部失效成本和外部失效成本内部失效成本－发生在交付之前发现错误时，包括：返工修复故障模式分析外部失效成本－在产品交付之后发现缺陷的相关成本，包括解决投诉产品退货和更换帮助作业支持保修工作•问题修正越到后期成本越高—需要软件质量保证SQA活动•遵照一定的软件生产标准、过程和步骤对软件质量进行评估，一般活动如下：•审查o评审既定标准是否得到遵守。如IEEE、ISO、GB/T等•监督o对比文档中描述的执行和实际操作步骤，确保执行过程采取适当步骤和操作方式•审计o确保开发过程使用了恰当的质量控制措施，以符合相应的标准或过程。SQA各阶段活动1•软件概念和启动阶段o编写和审查管理计划，确保这些进程、程序和标准是适当的，明确的，具体的，可审核•软件需求阶段o要求是完整的，可测试的，功能可靠，性能，和接口需求•软件体系结构（初步）设计阶段o确保遵守管理计划中经审批的设计标准o确保所有的软件需求分配给软件组件o保证测试验证方法存在，并且不断更新o保证接口控制文档和标准中指定的内容一致o检查PDR（概要设计评审）文件和确保所有行动项目得到解决o确保已批准的设计被置于配置管理之下SQA各阶段活动2•软件的详细设计阶段o确保经批准的设计标准得到遵守o保证每个分配的模块都进行了详细设计o审查CDR（关键设计评审）文件，确保所有行动项目得到解决•软件实施阶段o与在软件开发计划中的设计活动一致的编码结果o所有交付项目的状态o配置管理活动和软件开发库o不符合项报告和纠正措施SQA各阶段活动3•软件集成和测试阶段o确保为所有交付项目进行测试o确保所有测试根据测试计划和测试方案运行，任何不符合项都要报告和解决o保证测试报告是完整和正确的o已经完成验证测试，准备交付软件和文件o验收交付前再审，并保证所有相关内容已完成•软件验收和交付阶段o最低要求是保证最终产品的性能，并保证所有材料已经准备交付。•软件支持工程和操作阶段o使用较短周期来升级和更正软件软件可靠性•定义o是指在给定时间内，特定环境下软件无错运行的概率•内容1、可靠性o指能够避免或者检测重大错误的能力o度量：平均失效时间、平均维修时间2、可用性o系统实际运行时间在应该运行时间中的占比o度量：失效在维护中所占比重3、软件安全o避免违法访问、安全规则自定义、经受攻击等提高可靠性的方法•加强测试•软件复用•建立以可靠性为核心的质量标准•采用合适的软件开发方法和开发工具ISO9000质量标准•由国际标准化组织质量管理和质量保证技术委员会（ISO/TC176）制定的所有国际标准•历程o1987年版本ISO9000:1987o1994年版本ISO9000:1994o2000年版本ISO9000:2000oISO9001：2008标准的变化不大软件测试策略软件测试策略•描述将要进行的测试步骤，以及这些步骤计划和执行的时机以及需要的工作量、时间和资源。•软件测试策略为软件开发人员、质量保证组织、和客户提供了一个路线图。•测试策略必须和测试计划、测试用例设计、测试执行、还有测试结果数据的收集与分析结合在一起•测试策略还应当具备足够的灵活性，这样在必要的时候它能够有足够的可塑性来促进测试方法的定制•测试策略还必须保证足够的严格，这样才能保证对项目的整个进程进行合理的计划和跟踪管理软件测试的过程模型软件测试V模型V模型V模型非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段应关系：•1、单元测试的主要目的是验证软件模块是否按详细设计的规格说明正确运行。•2、集成测试主要目的是检查多个模块间是否按概要设计说明的方式协同工作。•3、系统测试的主要目的是验证整个系统是否满足需求规格说明。•4、验收测试从用户的角度检查系统是否满足合同中定义的需求，以及以确认产品是否能符合业务上的需要。软件测试策略中应注意的问题•在着手开始测试之前，要对产品的需求进行量化。•明确指出测试目标。•为每类用户建立描述交互场景的用例。•建立一个强调“快速循环测试”的测试计划。•设计一个能够测试自身是否“强壮”的软件。•在进行测试之前，对软件进行有效的正式技术审核。•使用正式技术审核来评估测试策略和测试用例本身。•为测试过程建立一种持续的改进方法。测试的基本步骤单元测试、集成测试和系统测试的步骤：•计划与准备阶段o制定计划o编写与评审测试用例o编写测试脚本和准备测试环境•执行阶段o搭建环境、构造测试数据o执行测试并记录问题o和开发人员一起确认问题o撰写测试报告•返工与回归测试阶段单元测试•单元测试又称模块测试，是针对软件设计的最小单位─程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。•单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。•单元的内涵：不同环境含义不同，面向过程：函数、过程等，面向对象：类、类中成员函数等。•单元测试的主要依据：详细设计单元测试的进入和退出条件•进入条件：o被测代码编译链接通过o被测代码静态检查工具检查通过o已完成至少一轮代码检视或走读o单元测试用例的检视通过o单元测试代码写完并通过检测•退出条件：o所用测试用例执行通过o单元测试覆盖率达到预定要求o单元测试未被执行的代码进行正式审查单元测试的主要内容单元测试主要内容模块接口测试•在单元测试的开始，应对通过被测模块的数据流进行测试。测试项目包括：o调用本模块的输入参数是否正确；o本模块调用子模块时输入给子模块的参数是否正确；o全局量的定义在各模块中是否一致；模块接口测试（续）•在做内外存交换时要考虑：o文件属性是否正确；oOPEN与CLOSE语句是否正确；o缓冲区容量与记录长度是否匹配；o在进行读写操作之前是否打开了文件；o在结束文件处理时是否关闭了文件；o正文书写／输入错误，oI／O错误是否检查并做了处理。局部数据结构测试•不正确或不一致的数据类型说明•使用尚未赋值或尚未初始化的变量•错误的初始值或错误的缺省值•变量名拼写错或书写错•不一致的数据类型•全局数据对模块的影响路径测试•选择适当的测试用例，对模块中重要的执行路径进行测试。•应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。•对基本执行路径和循环进行测试可以发现大量的路径错误。错误处理测试•出错的描述是否难以理解•出错的描述是否能够对错误定位•显示的错误与实际的错误是否相符•对错误条件的处理正确与否•在对错误进行处理之前，错误条件是否已经引起系统的干预等边界测试•注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。•如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。单元测试用例的设计•在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。单元测试的环境•模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。o驱动模块(driver)：接收测试数据，传送数据给待测模块，从待测模块获取返回数据，输出结果。o桩模块(stub)──存根模块：替代被测模块调用的模块，功能简单、隔离缺陷。集成测试•集成测试就是将软件集成起来后进行测试。又称为子系统测试、组装测试、部件测试等。•集成测试主要可以检查诸如两个模块单独运行正常，但集成起来运行可能出现问题的情况。•集成测试是一种范围很广的测试，当向下细化时，就成为单元测试。集成测试的主要方法•自顶向下的集成方法•自底向上的集成方法•SMOKE方法自顶向下的集成方法•这种组装方式将模块按系统程序结构，沿控制层次自顶向下进行集成。从属于主控模块的按深度优先方式（纵向）或者广度优先方式（横向）集成到结构中去。•自顶向下的集成方式在测试过程中能够较早的证主要的控制和判断点。•缺点是桩的开发量较大•适用：控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产口控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。AS1S2S3ABCDS4S5ABCDEF（1）（2）（3）广度优先方式ABCDEFABCDEFAS1S2S3ABS2S3EABCS3E（1）（2）（3）（4）深度优先方式自底向上的集成方法•自底向上集成方法是从软件结构最底层的模块开始，按照接口依赖关系逐层向上集成以进行测试。•由于是从最底层开始集成，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经集成并测试完成，所以不再需要使用桩模块进行辅助测试。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。•自底向上的集成方法的优点是每个模块调用其他底层模块都已经测试，不需要桩模块；•缺点是每个模块都必须编写驱动模块；缺陷的隔离和定位不如自顶向下。•适用：底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成自底向上的集成方法ABCDEFd2Cd1Ed3Fd4BEd5FDABCDEF•值得注意的是，在实际工作中，常常是综合使用自底向上和自顶向下的集成方法。•例如，按进度选择优先测试已经完成的模块o如果已完成的模块所调用的模块没有完成，就采用自顶向下的方法，打桩进行测试o如果已经完成模块的上层模块没有完成，可以采用自底向上集成方式。SMOKE方法(冒烟测试)•将已经转换为代码的软件构件集成为构造（build）。一个构造包括所有的数据文件、库、可复用的模块以及实现一个或多个产品功能所需的工程化构件。•设计一系列测试以暴露影响构造正确地完成其功能的错误。其目的是为了发现极有可能造成项目延迟的业务阻塞（showstopper）错误。•每天将该构造与其他构造，以及整个软件产品集成起来进行冒烟测试。这种集成方法可以是自顶向下，也可以自底向上。集成测试用例的设计•首先应考虑为通过性测试设计用例，用来验证需求和设计是否得到满足、软件功能是否得到实现。可以考虑等价类分法、场景