第12章-软件验证和确认

第12章软件验证和确认2软件危机„软件危机实际上源于软件中的错误„正是这些错误导致了软件开发在成本、进度和质量上的失控32013-04-02基本术语（补充）„错误（Error）„错误是指导致系统可能包含故障的人的行为，如输入错误、需求错误、设计错误等。„缺陷（Defect，Bug）„缺陷是错误的表现，包括过错缺陷和遗漏缺陷。„故障（Fault）„故障是指系统的规格说明与其行为之间的偏差，通常由一个或多个缺陷引起。42013-04-02定义软件错误的规则（补充）①软件未达到产品说明书标明的功能；②软件出现了产品说明书指明不会出现的错误；③软件功能超出了产品说明书指明的范围；④软件未达到产品说明书虽未指出但应达到的目标；⑤软件测试人员认为软件难以理解、不易使用、运行速度缓慢、或者昀终用户不满意。52013-04-02为什么要有验证和确认活动？„尽管软件活动的每个阶段一般均经过严格的技术审查，以尽可能早地发现并纠正错误，但经验表明阶段审查并不能发现所有错误，新的活动还会引入新的错误。„有错是软件的属性，而且是无法改变的。„关键在于如何避免错误的产生和消除已经产生的错误，使程序中的错误密度达到尽可能低的程度。„Solution:进行验证和确认活动612.1验证和确认„验证和确认（Verification&Validation，简称V&V）工作是在整个软件生命周期中对软件的规范性评估活动，以保证软件开发各个环节的正确性。„系统开发完毕后再测试的观念是错误的。„如果早期开发中出现的错误不能及时发现和解决，将带到设计、编码、测试等各阶段，影响会逐步扩大。72013-04-02验证与确认的活动模型（补充）82013-04-02„验证和确认是两个相互独立但却相辅相成的活动，二者很容易混淆„验证（Verification）„Arewebuildingtheproductright“（我们是否在正确地制造产品？）„软件验证试图证明在软件生存周期的各个阶段，软件产品或中间产品是否能够满足客户需求，包括逻辑协调性、完备性和正确性。„确认（Validation）„Arewebuildingtherightproduct“（我们是否在制造正确的产品？）„软件确认是一系列的活动和过程，其目的是保证软件产品能够符合其描述的要求。12.1验证和确认912.1验证和确认„确认（Validation）：包括需求规格说明的确认和程序的确认„程序的确认又分为静态的确认和动态的确认。„静态的确认一般不在计算机上实际执行程序，而是通过人工分析或程序正确性证明来确认程序的正确性„动态确认主要通过动态分析和程序测试来检查程序的执行状态，以确认程序是否有问题102013-04-0212.1验证和确认„验证强调对于过程的检验！„确认强调对于结果的检验！11验证与确认的技术„分类方法：„静态技术和动态技术„软件审查和软件测试12验证与确认的技术„在V&V过程中，可以使用软件审查和软件测试两种系统检查和分析技术„软件审查：是对系统的各种表示形式，如需求文档、设计图和程序源代码等，进行分析和检查。„这个过程贯穿软件开发过程的所有阶段。„审查活动可以辅之一些能对系统源文本和相关联的文档的自动分析。软件审查和自动分析是一种静态V&V技术，不需要系统的执行。„软件测试是使用测试数据对软件的实现进行运行检查，查看系统的输出内容以及运行行为是否符合要求。„测试是V&V过程中的动态技术，需要让系统运行起来以观察其动态行为。1312.1验证和确认„其中软件审查技术„程序审查(12.2.1)、自动化的源代码分析(12.2.2)和形式化检验„静态的软件审查只能检查程序及其描述之间的吻合程度，不能够说明软件真是有用的，而且也不能检验软件的非功能特性，如性能和可靠性等。„程序测试仍然是起决定作用的软件验证和确认技术。1412.2软件审查„软件审查则是一个不需要运行程序的过程，因此，可以在程序完成之前就进行。„软件审查是针对系统各阶段产生的文档和代码开展的发现错误和缺陷的活动„审查对象包括需求描述、系统设计模型和定义、数据结构设计、测试计划、用户文档、程序代码等。1512.2软件审查„软件审查通常比软件测试更有效（一种观点）„首先，在检查过程中能发现很多不同的缺陷。程序测试通常一次只能发现一个错误。„其次软件审查人员可以复用领域和程序语言知识。一般来说，软件审查人员对某一种编程语言中常发生的错误类型和某一种应用中常发生的错误类型都比较了解，由此他们有可能在分析过程中特别注意这些问题，因此很容易检出错误。1612.2软件审查„软件审查能够检出很多的错误，却并不能完全替代软件测试（程序测试仍然是起决定作用的软件验证和确认技术）„软件审查的作用应该是在初始的检验过程中发现绝大多数程序缺陷。„软件审查能发现软件的实现是否符合对它的定义和描述，但却不能验证系统动态行为有效性。„另外，对于由若干个不同的子系统构成的系统而言，对整个系统的审查较难实现。而软件测试则是在系统层次上的V&V技术1712.2.1程序审查„软件审查涉及文档和程序的审查„程序审查即对所实现的程序源代码审查，其审查的目标是评审和检出程序中的错误和缺陷，„可能是逻辑上的错误„也可能是错误的条件设置或是与机构和项目定义的标准不相符。1812.2.1程序审查„程序审查的过程是一个正式的过程，由至少4个人组成的一个小组来实行，包括程序作者、代码阅读者、测试者仲裁者。„审查小组应系统地分析代码并指出可能的缺陷„审查过程如图12.2所示。1912.2.2自动静态分析„因此根据软件的逻辑特性，人们开发了静态程序分析器支持软件审查高效的开展。„静态程序分析器是一个软件工具„通过扫描程序源代码，检查代码间的逻辑关系，分析可能存在的缺陷和不规则之处„采用静态程序分析器并不需要去执行被审查的程序„变量没有初始化、变量未曾使用、变量值越界等。„静态程序分析器可以弥补语言编译器错误检测能力的不足，并可极大提高程序审查效率和质量。202013-04-0212.3软件测试„软件测试的定义：„传统：测试是一种旨在评估一个程序或系统的属性或能力，确定它是否符合其所需结果的活动。„Myers：测试是为了发现错误而执行一个程序或系统的过程。„IEEE：测试是使用人工和自动手段来运行或检测某个系统的过程，其目的在于检验系统是否满足规定的需求或弄清预期结果与实际结果之间的差别。212013-04-0212.3.1软件测试的目的和原则„测试的目的：„测试是为了发现程序的错误，而不是证明程序无错误；„一个好的测试用例在于能够发现至今未发现的错误；„一个成功的测试是发现了至今未发现的错误的测试。牢记这三句话！222013-04-0212.3.1软件测试的目的和原则„用户和软件开发者的测试观点：„从用户的角度出发„普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。„从软件开发者的角度出发„希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。„一种正确的态度„测试的目的应从用户角度出发。„测试只能证明程序中错误的存在，但不能证明程序中没有错误。因为即使实施了昀严格的测试，仍然可能还有尚未被发现的错误或缺陷存在于程序当中，因而测试不能证明程序没有错误，但可能查出程序中的错误。2312.3.1软件测试的目的和原则„软件测试的原则1.把“尽早地和不断地测试”作为开发者的座右铭2.程序员应避免检查自己的程序3.设计测试用例时，应包括合理的和不合理的输入及各种边界条件，测试极端状态和意外状态4.对测试结果一定要全面检查5.制定严格的测试计划，排除测试的随意性6.注意回归测试的关联性，往往修改一个错误会引起更多错误7.程序中尚未发现的错误数量通常和该程序中已经发现的错误数量成正比。8.妥善保存一切测试过程文档（测试计划，测试规范，测试用例，出错统计和昀终分析报告），测试重现往往要靠测试文档。242013-04-02„TestCase:一组数据输入和所期望结果„“输入”是对被测软件接收外界数据的描述„“期望结果”是对于相应输入软件应该出现的输出结果的描述„测试用例还应明确指出使用具体测试案例产生的测试程序的任何限制。„测试用例可以被组织成一个测试系列，即为实现某个特定的测试目的而设计的一组测试用例。„例如，一部分测试用例用来测试系统的兼容性，另一部分是用来测试系统在特定的环境中，系统的典型应用是否能够很好地运作。软件测试文档-测试用例(补充)252013-04-0212.3.2单元测试软件测试过程（图12.3）262013-04-0212.3.2单元测试软件测试过程（图12.3续）通常软件测试过程活动有4个，即单元测试、集成测试、系统测试和确认测试。272013-04-0212.3.2单元测试„又称“组件测试”„昀小的程序设计单元（软件组件或模块）进行测试，单元测试需要从程序的内部逻辑结构出发设计测试用例，在单元测试阶段，多个组件可并行进行。„一般由编写该单元代码的开发人员执行，该人员负责设计和运行一系列的测试以确保该单元符合需求。„单元测试的目的„验证代码是与设计相符的„跟踪需求和设计的实现„发现设计和需求中存在的错误„发现在编码过程中引入的错误282013-04-0212.3.2单元测试29（1）接口测试„由于模块接口是数据出入模块的通道。接口不正常，其他测试则无从进行，所以在其他测试开始之前，首先要对通过模块接口的数据进行测试。„接口测试应做如下考虑：„模块接收实际参数个数是否与模块形式参数个数一致，实际参数与形式参数的属性是否匹配，实际参数与形式参数的单位是否一致；„调用其他模块时，所给的实际参数的个数是否与被调用模块的形参个数相等，实际参数的属性是否与被调模块的形参属性匹配，实际参数的单位是否与被调模块的形参单位匹配；„调用内部函数所用参数的个数、属性和次序是否正确；„……….30（1）接口测试„若一个模块需要完成外部的输入或输出时，还应检查下述各点：„文件属性是否正确；„OPEN/CLOSE语句是否正确；„格式说明与I/O语句是否匹配；„缓冲器大小与记录长度是否匹配；„文件是否先打开后使用；„文件结束的条件是否处理过；„I/O的错误是否处理过；„输出信息中是否有正文的错误；31（2）局部数据结构测试„检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源。32（3）重要的执行路径测试„对模块中每一条独立的执行路径进行测试„保证模块中每条语句至少执行一次，„方法：设计测试用例发现因错误计算、不正确的比较和不适当的控制流造成的错误。„基本路径测试和循环测试是昀常用、昀有效的测试技术33（4）异常处理测试„一个好的设计应能预见各种出错条件，并预设各种出错处理通路。出错处理通路同样需要认真测试，测试应着重检查下列问题：„错误描述难以理解；„错误提示与实际错误不相符；„在程序自定义的出错处理段运行之前，系统已介入；„对错误的处理不正确；„提供的错误信息不足，无法确定错误位置和差错。34（5）边界测试„边界测试是单元测试步骤中的昀后一步，也是昀重要的一项任务。„原因：软件通常容易在边界上失效„方法：采用边界值分析技术，针对边界值及其左、右值设计测试用例，很有可能发现新的错误。352013-04-0212.3.2单元测试„单元测试环境（图12.4）„驱动模块：模拟被测模块的上一级模块„桩模块：模拟被测单元需调用的其他函数接口„单元测试的动态环境：生成测试数据362013-04-02单元测试举例：编写MyClass的桩模块„三种方式„main()函数„MyClass的静态成员函数„负责实现测试用例的单独驱动类372013-04-02MyClass的测试驱动382013-04-02MyClass的测试驱动392013-04-0212.3.3集成测试„IntegrationTesting„集成测试也称组装测试，综合测试„在单元测试的基础上，将所有模块按照总体设计的要求组装成为子系统或系