软件测试教案(共55页).doc

《软件测试教案(共55页).doc》由会员分享，可在线阅读，更多相关《软件测试教案(共55页).doc（55页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、精选优质文档-倾情为你奉上第一章 软件及其开发过程教学目的1、理解软件的含义2、了解软件开发过程教学内容11软件的含义1、软件概念 能够完成预定功能和性能的、可执行的指令(计算机程序)； 使得程序能够适当地操作信息的数据结构； 描述程序的操作和使用的文档。 软件 = 程序 + 数据 （库） + 文档 + 服务 2、软件组成 客户需求 - Customer Requirements 市场需求文档 - MRD (Marketing Requirement Document) 软件规格说明书 - Specifications 技术设计文档 Technical Design Docs 测试文档 Tes

2、t Documents 在线帮助 - Online help 产品发布注释 - Release Notes / Read Me 产品软件包 - Release packages 3、软件特征软件是逻辑的、知识性的产品集合，是对物理世界的一种抽象，或者是某种物理形态的虚拟化。 软件是硬件的灵魂，硬件是软件的基础 软件，是智慧和知识的结晶 软件不会“磨损”，而是逐步完善 .12软件开发过程的特性121软件开发的基本过程 需求分析: 根据客户的要求，清楚了解客户需求中的产品功能、特性、性能、界面和具体规格等，然后进行分析，确定软件产品所能达到的目标。 设计: 根据需求分析的结果，考虑如何在逻辑、程序

3、上去实现所定义的产品功能、特性等，可以分为概要设计和详细设计，也可分为数据结构设计、软件体系结构设计、应用接口设计、模块设计、界面设计等。 编程: 将设计转换成计算机可读的形式。 测试: 对设计、编程进行验证和用户需求确认的过程 维护：维持软件运行，修改软件缺陷、增强已有功能、增加新功能、升级等。 122软件开发过程模型瀑布模型 原型模型 快速应用开发(RAD)模型 改进的V模型 螺旋模型 增量模型和迭代模型 构件组装模型 并发模型 XP模型13软件测试的重要性131软件所带来的悲剧1、千年虫（缺陷问题） 2、迪斯尼的圣诞节礼物（软件兼容性问题） 3、美国航天局火星登陆事故（未进行集成测试）为

4、什么会发生这些问题？没有足够测试 缺乏测试平台 不正确的测试环境 缺少集成测试 缺少性能测试 缺少强度测试 缺少可靠性测试 132测试的重要性“程序测试是为了发现错误而执行程序的过程”。测试的目的是发现程序中的错误，是为了证明程序有错，而不是证明程序无错。在软件开发过程中，分析、设计与编码等工作都是建设性的，惟独测试是带有“破坏性”，测试可视为分析、设计和编码3个阶段的“最终复审”，在软件质量保证中具有重要地位。第二章 软件测试的基本概念和方法教学目的1、理解软件测试的基本概念2、理解软件测试在软件开发过程中的重要性3、理解软件测试的意义4、理解软件测试的基本方法和测试分类教学内容21软件质量

5、软件质量就是客户满意度211软件质量的内涵1、构成： 软件产品的质量，即满足使用要求的程序 软件开发过程的质量，即能否满足开发所带来的成本、时间、风险等要求 软件在其商业环境中所表现出的质量即就品质的软件应该是相对的无产品缺陷或只有极少量的缺陷，能够准时递交给客户，所花费用在预算内，并且满足客户需求，是可维护的。2、特性：可说明性、有效性、易用性。广义的软件质量由产品质量、过程质量、商业环境质量三者决定。22软件缺陷（bug）软件缺陷：计算机系统或者程序中存在的任何一种破坏正常运行能力的问题、错误、或者隐藏的功能缺陷、瑕疵。缺陷会导致软件产品在某种程序上不能满足用户的需要。IEEE1983 O

6、F IEEE Standard729中对软件缺陷的定义：从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背软件缺陷的主要类型：功能特性没有实现或部分实现 设计不合理，存在缺陷 实际结果和预期结果不一致 运行出错 数据结果不正确、精度不够 用户不能接受的其它问题，如存取时间长，界面不美观等。软件缺陷严重性级别： 致命的（fatal）:致命的错误，造成系统或应用程序崩溃、死机、系统悬挂，或造成数据丢失、主要功能完全缺失 严重的（critical）：严重的错误，指功能或特性没有实现 ，主要功能部分缺失，次要功能完全缺失

7、，或致命的错误声明。 一般的（ major）：不及严重的错误，不影响系统的基本使用，但没有很好地实现功能，没有达到预期的效果。 微小的（ minor）：小问题，对功能几乎没有影响 建议（suggestion）软件缺陷的状态： 激活状态 己修正状态 关闭或非渡海状态222软件缺陷的产生 技术问题 团队工作 软件本身223软件缺陷的构成图2-1软件缺陷构成示意图图2-2软件缺陷存在不同阶段分布图2-3 软件缺陷随着时间带来越来越大的成本图2-4 软件缺陷随着时间引起的成本曲线23软件测试的基本方法231软件测试的原则P29232白盒测试和黑盒测试根据测试是针对系统的内部结构还是针对具体实现算法的角

8、度，分为白盒测试和黑盒测试1、 黑盒测试（black-box-texting）(功能测试/数据驱动测试)不管程序内部结构是什么，从用户出发，根据产品应该实现的实际功能和巳经定义好的产品规格验证产品所应该具有的功能是否实现，每个功能是不都能正常使用，是否满足用户的要求。图2-5黑盒测试方法示意图功能；用于软件确认测试 是否有不正确或遗漏了功能 在接口上，能否正确地接受输入数据，能否产生正确的输出信息 访问外部信息是否有错 性能上是否满足要求 界面是否错误，是否不美观 初始化和终止错误方法：等价类划分、边界值分析、错误推测法、因果图等2、 白盒测试（white-box-texting）(结构测试或

9、逻辑驱动测试)已知产品内部工作过程，清楚最终产生软件产品的计算机程序的结构和语句，按照程序内部的结构测试程序，测试程序内部的变量状态、逻辑结构、运行路径等，检验程序中的每条通路是否按规定正常进行。功能：用于软件验证方法：逻辑覆盖（语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖）、基本路径测试、循环覆盖等思考：通过白盒测试的软件是否一定没有错误？原则： 保证每个模块中所有独立路径至少被使用一次 对所有逻辑值均测试为真假值 在上下边界及可操作范围内运行所有循环 检查内部数据结构以确保其有效性233静态和动态的方法根据程序是否运行，测试可以分为静态和动态测试静态测试：对模块的源

10、泉代码进行研读，查找错误或悼念一些度量数据，并不需要对代码进行编译和仿真运行。 用人工检测 计算机辅助静态分析测试包括对软件产品的设计规格说明书的审查、对程序代码的阅读、审查动态测试：通过观察代码运行时的动作，来提供执行跟踪、时间分析，以及测试覆盖度方面的信息。234验证和确认（verification&validation）1、验证检验软件是否已经正确地实现了产品规格说明书所定义的系统功能和特性2、有效性确认保证所生产的软件可追溯到用户需求的一系列活动。确认过程提供证据表明软件是否满足系统需求，并解决相应问题3、 两者区别验证：是否正确构造了软件，检验软件是否与设计规格说明书一致确认：是否构

11、造了正确的软件，是否满足用户的真正需求235 ALAC测试ALAC（act-like-a-cusomer）基于客户使用产品的知识开发出来的测试方法。用于功能测试图2-6 ALAC测试方法的原理示意图ALAC测试方法适合特别的场合，如演示版、开发预算低，开发计划日程表紧等情况，降低测试成本，缩短测试时间，缺陷查找和改正针对客户最容易遇到的错误236自动化测试和随机测试自动化测试：通过工具自动动执行软件的测试可完成负载测试、性能测试、可靠性测试随机测试：模拟客户操作的随意性，进行大量的、自动化的随机测试，来发现今后用户可能会碰到的问题。237软件测试的误区 如果说发布出去的软件有质量问题，那是软件

12、测试人员的错。 软件测试技术要求不高，至少比编程容易多。 有时间就多测试一些，来不及就少测试一些 软件测试是测试人员的事，与开发人员无关 根据软件开发瀑布模型，软件测试是开发的最后期的一个阶段24软件测试的分类和阶段241软件测试的分类1、按测试范围分类 单元测试 组件测试 集成测试 系统测试 验收测试 安装测试2、按测试目的分类 正确性测试n 白盒测试n 黑盒测试 性能测试 可靠性测试n 强壮性测试n 异常处理测试n 负载测试 安全性测试3、按测试对象分类 单元测试 组件测试 模块测试 程序测试 系统测试 文档测试4、 按测试过程分类 需求阶段的测试 设计阶段的测试 程序阶段的测试 测试结果

13、的评估 安装测试 验收测试 测试变化5、 其它测试技术和方法 回归法 压力法 恢复测试 安全测试 兼容性测试242测试的阶段图2-7 软件测试阶段示意图25软件测试的工作范畴软件测试工作范畴 软件测试工作的组织与管理制定测试策略、测试计划、确认所采用的测试方法与规范、控制测试进度、管理测试资源 测试工作的实施编制符合标准的测试文档，研制测试环境，与开发组织协作实现各阶段的测试活动软件测试工作的六个方面 测试组织和管理 测试计划PDCA模型：计划plan,执行do,检查check,措施action图2-9 软件开发流程改进模型PDCA示意图 制定测试策略分析测试的目标和指标、确定测试的对象和依据

14、、明确测试的重点和所要采用的方法 确定测试范围 所需资源和日程安排资源：计算机硬件、软件、人力资源资源安排：项目经理、组长、系统工程师、测试设计工程师、资深测试工程师、一般测试工程师等，定义每个人的工作内容和责任日程安排：设置整个测试周期的项目进程，有产品设计规格说明书审查结束时间，测试计划初稿完成时间、设计测试用例的时间、测试计划/用例审查结束时间、单元测试完成的日期、系统测试完成的日期、测试全部完成的日期等。 设计测试用例测试用例是按一定顺序执行的，与测试目标相关的测试活动的描述，是确定怎样测试。包括测试环境、输入值、期望结果或标准测试用例的特性：可复用性、有效性、可管理性、继承性、基础性

15、 测试实施 测试结果分析 测试评审与报告第三章质量保证与测试策略教学目的1、理解软件质量保证体系2、理解测试3、理解测试计划的重要性及其内容4、了解软件质量的可靠性评估教学内容31软件质量保证（ software quality assurance, SQA）311 SQA概述1、SQA：通过对软件产品有计划的进行评审和审计来验证软件是否合乎标准的系统工程2、活动原则： 确保SQA活动要自始至有计划的进行 审查软件产品和活动是否遵守适用的标准、规程和要求并得到客观验证。 SQA的活动和结果要保证全员参与，沟通顺畅。 逐级解决不符合问题312 SQA活动 技术方法的应用 正式技术评审的实施 软件

16、测试 标准的执行 修改的控制 度量 质量记录和记录保存1、 SQA活动效果的影响因素 知识结构：专业的技术，例如质量管理与控制知识、统计学知识等。 经验 依据：如果没有这些标准，就无法准确地判断开发活动中的问题，容易引发不必要的争论，因此组织应当建立文档化的开发标准和规程。 全员参与：全员参与至关重要，高层管理者必须重视软件质量保证活动。 把握重点：一定要抓住问题的重点与本质，尽可能避免陷入对细节的争论之中。2、 SQA活动 提出软件质量需求 确定开发方案 阶段评审 测试管理 文档化管理 验证产品与相应文档和标准的一致致性 建立测量机制 记录并生成报告SQA策略 以检测为重：产品制成之后进行检

17、测，只能判断产品质量，不能提高产品质量。 以过程管理为重：把质量的保证工作重点放在过程管理上，对制造过程中的每一道工序都要进行质量控制。 以新产品开发为重：在新产品的开发设计阶段，采取强有力的措施来消灭由于设计原因而产生的质量隐患SQA与软件测试有什么关系和区别 SQA 是管理工作、审查对象是流程、强调以预防为主 测试是技术工作、测试对象是产品、主要是以事后检查 SQA指导测试、监控测试 测试为SQA提供依据32测试策略321测试策略的概念测试策略通常是描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试（如单元测试、集成测试、系统测试）以及每个阶段内进行的测试种类（如功能测试、性能测试

18、、压力测试等），以确定合理的测试方案使得测试更有效。 322影响测试策略的因素1、测试完成的标准标准的高低对策略确定有着重要的影响。比如该软件的应该用场合为军用，这将对软件的可靠性、安全性要求非常高，但如果是用于小型商场的收费系统由于是内部使用，主要考虑其计算的准确与精度及复杂统计与报表生成等方面准确性与易用性。2、资源状况参与测试的人、测试中所需要的软件平台（如操作系统甚至会涉及到第三方的一些应用软件）及测试可能用到的相关硬件设备（如计算机，网络硬件其它外设等） 323测试策略的确定p 全面细致地了解产品的项目信息:应用领域,测试范围,市场需求,产品的特点和主要功能,技术架构p 基于模块、功

19、能、整体、系统、版本、压力、性能、配置和安装等各个因素对产品的影响,公正客观地开展测试计划p 根据程序的重要性和一旦发生故障将造成的损失,来确定它的测试等级和测试重点p 认真研究测试策略,以便能使用尽可能少的有效测试用例,发现尽可能多的程序错误,因为一次完整的软件测试过后,如果程序中遗漏的错误过多并且很严重,则表明本次测试是失败的,是不足的;而测试不足意味着让用户承担隐藏错误带来的危险.同时反过来说,如果过度测试,则又会浪费许多宝贵的资源. 找到一个最佳平衡点。 测试范围的确立p 优先级最高的需求功能 p 新功能和编码改动较大(提高性能表现)的旧功能 p 运用有效的测试技术去提高测试效果 p

20、经常容易出现问题部分的功能 p 一些经常被用户使用的功能和配置 测试持续阶段的确定当测试任务明确后,测试计划将依赖于测试小组的人力资源而最终确定.通过/失败的标准v 单个的测试通过/失败 测试用例 v 全部产品测试通过/失败 每个阶段的通过/失败 阶段通过/失败的标准风险评估 测试小组开始项目测试时,硬件资源没有按时配备或仍然不足 开始项目测试时, 软件产品编码没有按计划完成 开始项目测试时, 测试用例没有准备好 缺少按计划参加项目测试的测试人员 在项目测试过程中, 需求总是不停地改动 当项目测试进行时, 在设计说明书中被定义的功能总是不停地被修改测试评估里程碑的定义和跟踪可以帮助项目管理者掌

21、握项目的进行状态 n 里程碑 日期 n 测试计划完成 - 1/15n 测试用例完成 - 1/29n 功能验证完成器 - 2/5n 代码冻结前完成系统测试 - 2/20n 版本发布前完成确认测试 -2/2833测试计划331测试计划内容构成测试计划制定的第一步就是将软件分解较小而且相对独立的功能模块，写成测试需求。测试需求有很多分类方法，最普通的一种就是按照功能分类：p 测试需求是测试设计和开发测试用例的基础，分解功能模块可以更好地进行设计；p 详细的测试需求是用来衡量测试覆盖率的重要指标；p 测试需求包括各种测试实际和开发以及所需资源。一个测试计划应包括：产品基本情况、测试需求说明、测试策略和

22、记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等。测试计划标准格式 n 16 components of Test Plan (IEEE,1983)1. Test plan identifier （测试计划标识)2. Instruction (引言）3. Test Items （定义或主题词)4. Features to be tested （需要被测试的功能)5. Features not to be tested (无需被测试的功能)6. Approach (方法和途径）7. Items pass/ fail criteria （测试通过、失败的标准)8. Suspensi

23、on criteria and resumption requirements （延迟的标准和再恢复的要求)9. Test deliverables (测试交付的内容)10. Testing Tasks (测试任务11. Environmental needs （必备的环境)12. Responsibilities (职责)13. Staffing and training needs (人员和必需的培训)14. Schedule (时间进度表)15. Risk and contingencies (风险和相关费用）16. Approvals （批准) 34软件质量的可靠性评估341软件可靠性

24、评估的概述软件可靠性评估（Software Reliability Assessment）指根据软件系统可靠性结构（单元与系统间可靠性关系）、寿命类型和各单元的可靠性试验信息，利用概率统计方法，评估出系统的可靠性特征量。软件可靠性评估的要素 1）规定的时间2）规定的环境条件3）规定的功能342软件可靠性模型软件可靠性模型（Software reliability model）是指为预计或估算软件的可靠性所建立的可靠性结构和数学模型。建立可靠性模型是为了将复杂系统的可靠性逐级分解为简单系统的可靠性，以便于定量预计、分配、估算和评价复杂系统的可靠性。1）可靠性结构模型，是依据系统结构逻辑关系，对系

25、统的可靠性特征及其发展变化规律做出可靠性评价。2）可靠性预计模型，是用来描述软件失效与软件缺陷的关系，借助这类模型，可以对软件的可靠性特征做出定量的预计或评估。依据软件缺陷与运行剖面数据，利用统计学原理建立二者之间的数学关系，获取开发过程中可靠性变化、软件在预定工作时间的可靠度、软件在任意时刻发生的失效数的平均值以及软件在规定时间间隔内发生失效次数的平均值。 343可靠性评估过程可靠性数据收集 用时间定义的软件可靠性数据可以分为四类：n 失效时间数据，记录发生一次失效所累积经历的时间；n 失效间隔时间数据，记录本次失效与上一次失效间的间隔时间；n 分组数据，记录某个时间区内发生了多少次失效；n

26、 分组时间内的累积失效数，记录某个区间内的累积失效数。这四类数据可以互相转化。n 测试时间；n 含有测试用例的测试计划或测试说明； n 所有与测试有关的测试结果，包括所有测试时发生的故障；n 参与测试的个人身份。 可靠性评估报告第四章 软件测试依据和规范教学目的1、了解软件测试依据和规范教学内容41软件质量标准411ISO质量体系标准简介 ISO 9000 的由来 ISO 9000 总休思想 ISO 9000体系结构1、ISO 软件质量标准ISO (International Standardization Organization, 国际标准化组织) TC/176技术委员会制定的所有国际 标

27、准p 质量保证标准（ISO9001/2/3）p 质量管理标准（ISO9004) p TC176即ISO中第176个技术委员会，成立于1980年，全称是“质量保证技术委员会”，1987年又更名为“质量管理和质量保证技术委员会”。TC176专门负责制定质量管理和质量保证技术的标准 2、ISO 软件质量标准思想控制思想，即对产品形成的全过程进行控制。任何事物都是由一个或多个过程活动的结果，只要对产品形成的全过程进行控制并达到过程质量要求，最终产品的质量就有了保证预防的思想。通过对产品形成的全过程进行控制以及建立并有效运行自我完善机制达到预防不合格，从根本上减少或消除不合格品412ISO软件质量体系标

28、准ISO9000系列标准的主体部分分为两组： p “需方对供方要求质量保证”的标准ISO90019003p “供方建立质量保证体系”的标准ISO9004 ISO9001：设计/开发、生产、安装和服务中质量保证模式； ISO9002：生产和安装中的质量保证模式； ISO9003：最终检验和测试中的质量保证模式； ISO9004：质量管理和质量体系要素导则。1、 ISO软件质量体系结构2、 ISO9000与GB/T19000的关系GB/T(国标推荐) Idt(等同于) ISO标准 GB/T 6583-1994 idt ISO 8402:1994 GB/T 19000.1-1994 idt ISO

29、9000-1:1994 GB/T 19000.2-1994 idt ISO 9000-2:1994 GB/T 19000.3-1994 idt ISO 9000-3:1994 GB/T 19001-1994 idt ISO 9001:1994 GB/T 19002-1994 idt ISO 9002:1994 GB/T 19003-1994 idt ISO 9003:1994 GB/T 19004.1-1994 idt ISO 9004-1:1994 GB/T 19004.2-1994 idt ISO 9004-2:1991 GB/T 19004.3-1994 idt ISO 9004-3:1

30、993 GB/T 19004.4-1994 idt ISO 9004-4:1993 GB/T 19021.1-1993 idt ISO 10011-1:1990 GB/T 19021.2-1993 idt ISO 10011-2:1991 GB/T 19021.3-1993 idt ISO 10011-3:1993 GB/T 19022.1-1994 idt ISO 10012-1:1994 413ISO9000-3介绍ISO9000-3其实是ISO质量管理和质量保证标准在软件开发、供应和维护中的使用指南，并不作为质量体系注册/认证时的评估准则，主要考虑软件行业的特殊性制定。参照ISO9001

31、质量体系 设计、开发、生产、安装和服务的质量保证模式，并引用ISO 8402质量管理和质量保证术语，使得ISO9000系列标准应用范围得以拓展 ISO9000-3标准n 软件开发、供应、维护中应用ISO9001的指南n 是指南，不是标准n 依然困惑：依然强调的是供应商和顾客的关系，不是工程师该如何做ISO 9000-3 体系结构 合同评审 需方需求规格说明 开发计划 质量计划 设计和实现 测试和确认 验收 复制、交付和安装 维护42软件测试规范421概述软件测试规范就是对软件测试的流程过程化并对每一个过程元素进行明确的界定，形成完整的规范体系。 422软件测试规范规范本身的详细说明,比如规范目

32、的、范围、文档结构、词汇表、参考信息、可追溯性、方针、过程/规范、指南、模板、检查表、培训、工具、参考资料等等。制定测试规范需要考虑的内容 角色的确定 进入的准则 输入项 活动过程 输出项 验证与确认 退出的准则 度量 43CMM思想和结构体系CMM即软件能力成熟度模型（Capability Maturity Model）是向软件组织提供如何增加对其开发和维护软件过程的控制能力。设计并实施CMM是为了指导软件组织： 通过确定当前过程的成熟度等级和识别出对软件质量和过程改进至关重要的问题，来选择其过程改进策略。 通过关注一组有限的活动，并为实现它们而积极工作，组织能稳步地改善其软件过程，使其软件

33、过程能力持续不断地增长。431CMM的历史CMM分阶段的体系结构源于己有60多年历史的产品质量原理。ITT的Philip Crosby在其书“Quality is Free”（Crosby 79）中首先提出将质量原理改编为成熟度框架的思想。Humphrey的成熟度框架早期版本发表在SEI技术报告（Humphrey 87a，Humphrey 87b）、文章（Humphrey 88）和书“Managing the software Process”（Humphrey 89）中。基于CMM模型的过程改进-软件过程改进的方法论-IDEAL 432 CMM的五个等级CMM的五个等级及关键过程域关键过程域

34、（KEY AREAS）433CMM与ISO9001思想及结构体系的关系44建立软件测试管理和评判体系1、为什么要建立管理与评判体系n 监视和测量软件产品 n 识别和控制不符合要求的产品n 验证产品设计和开发 n 监视和测量软件过程2、测试管理和评判体系发展现状n 美国质量保证研究所对软件测试的研究结果表明:越早发现软件中存在的问题，开发费用就越低;在编码后修改软件缺陷的成本是编码前的10倍，在产品交付后修改软件缺陷的成本是交付前的10倍;软件质量越高，软件发布后的维护费用越低。另外，根据对国际著名IT企业的统计，它们的软件测试费用占整个软件工程所有研发费用的50% 以上。 n 中国软件企业在软

35、件测试方面与国际水准仍存在较大差距。首先，认识上重开发、轻测试，没有认识到软件项目的如期完成不仅取决于开发人员，更取决于测试人员；其次，管理上随意、简单，没有建立有效、规范的软件测试管理和评判体系；另外，缺少自动化工具的支持，大多数企业在软件测试时并没有建立软件测试管理与评判体系。 3、 如何建立测试管理与评判体系第五章 单元测试教学目的1、了解单元测试的内容、定义2、掌握静态测试技术的运用3、掌握动态测试技术的运用4、了解单元测试的过程与文档管理教学内容51什么是单元测试测试的4个阶段： 单元测试集成测试 系统测试验收测试 按阶段进行测试是一种基本的测试策略511单元测试的定义定义: 单元测

36、试是对软件基本组成单元进行的测试。时机: 一般在代码完成后由开发人员完成,QA人员辅助.概念: 模块, 组件, 单元512为何要进行单元测试 尽早发现错误错误发现越早,成本越低.开发人员过于自信,后期复杂度高,发现解决BUG困难. 检查代码是否符合设计和规范52单元测试的目标和任务目标: 单元模块被正确编码n 信息能否正确地流入和流出单元；n 在单元工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互关系不发生错误，也包括全局变量在单元中的处理和影响。 n 在为限制数据加工而设置的边界处，能否正确工作。 n 单元的运行能否做到满足特定的逻辑覆盖。 n 单元中发生了错误，其中的

37、出错处理措施是否有效。 任务：任务1：模块接口测试检查模块接口是否正确Checklist:n 输入的实际参数与形式参数是否一致。p 个数、属性、量纲n 调用其他模块的实际参数与被调模块的形参是否一致。p 个数、属性、量纲n 全程变量的定义在各模块是否一致。n 外部输入、输出p 文件、缓冲区、错误处理n 其它任务2： 模块局部数据结构测试检查局部数据结构完整性Checklist:n 不适合或不相容的类型说明。 n 变量无初值。n 变量初始化或默认值有错。n 不正确的变量名或从来未被使用过。 n 出现上溢或下溢和地址异常。 n 其它任务3： 模块边界条件测试检查临界数据处理的正确性Checklis

38、t:n 普通合法数据的处理。 n 普通非法数据的处理。n 边界值内合法边界数据的处理。n 边界值外非法边界数据的处理。 n 其它任务4： 模块独立执行通路测试检查每一条独立执行路径的测试。保证每条语句被至少执行一次。Checklist:n 算符优先级。 n 混合类型运算。n 精度不够。n 表达式符号。n 循环条件，死循环。n 其它任务5：模块的各条错误处理通路测试预见、预设的各种出错处理是否正确有效。Checklist:n 输出的出错信息难以理解。 n 记录的错误与实际不相符。n 程序定义的出错处理前系统已介入。n 异常处理不当。n 未提供足够的定位出错的信息。 n 其它53静态测试技术的运用

39、静态测试技术是单元测试中最重要的手段之一。静态测试技术： 不运行被测试程序，对代码通过检查、阅读进行分析。三步曲： 走查 （Walk Through） 审查 （Inspection） 评审 （Review）531编码的标准和规范标准：建立起来必须遵守的规则。规范：建议最佳做法，推荐更好方式。实施标准和规范的原因： 可靠性 可读性和可维护性 可移植性。532走查（walk Through）定义：采用讲解、讨论和模拟运行的方式进行的查找错误的活动。注意： n 引导小组成员在走查前通读设计和编码。n 限时，避免跑题。n 发现问题适当记录，避免现场修改。 n 检查要点是代码是否符合标准和规范，是否有逻

40、辑错误。533审查（inspection）定义：采用讲解、提问方式进行，一般有正式的计划、流程和结果。主要方法采用缺陷检查表。注意： n 以会议形式，制定会议目标、流程和规则，结束后要编写报告。n 按缺陷检查表逐项检查。n 发现问题适当记录，避免现场修改。n 发现重大缺陷，改正后会议需要重开。 n 检查要点是缺陷检查表，所以该表要根据项目不同不断积累完善。走查与审查的比较走 查审 查准备通读设计和编码应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表形式非正式会议正式会议参加人员开发人员为主项目组成员包括测试人员主要技术方法无缺陷检查表注意事项限时、不要现场修改

41、代码限时、不要现场修改代码生成文档会议记录静态分析错误报告目标代码标准规范，无逻辑错误代码标准规范，无逻辑错误534评审（review）定义：通常在审查会后进行，审查小组根据记录和报告进行评估。注意： n 充分审查了所规定的代码，并且全部编码准则被遵守。n 审查中发现的错误已全部修改。54 动态测试技术的运用动态测试需要真正将程序运行起来，需要设计系列的测试用例保证测试的完整性和有效性。n 白盒测试 n 黑盒（灰盒）测试541白盒测试方法主要要逻辑驱动法和基本路径法。p 语句覆盖。 p 判定覆盖。p 条件覆盖。p 判定/条件覆盖。p 条件组合覆盖。p 路径覆盖。p 循环覆盖。542黑盒测试方法

42、运行单元程序有时需要基于被测单元的接口，开发相应的驱动模块和桩模块。n 驱动模块（drive）:对底层或子层模块进行测试所编写的调用这些模块的程序。n 桩模块（stub）：对顶层或上层模块进行测试时所编写的替代下层模块的程序。黑盒测试常用方法n 等价类划分法 n 边界值分析法 三种数据：n 错误推测法 - 正常数据n 因果图法 - 错误数据n 功能图法 - 边缘数据另外还得考虑接口测试、性能测试、内存测试 n 性能分析n 内存分析55调试与评估调试与测试的对象及采用的方法有很大程度上的相似，调试还用到断点控制等排错方法，但其目的却完全不同。测试是为了找出软件中存在的缺陷，而调试是为了解决存在的缺陷。 n 软件单元功能与设计需求一致。 n 软件单元接口与设计需求一致。 n 能够正确处理输入和运行中的错误。 n 在单元测试中发现的错误已经得到修改并且通过了测试。 n 达到了相关的覆盖率的要求。 n 完成软件单元测试报告 单元测试检查表见书101页56单元测试的过程和文档管理过程: 1. 在详细设计阶段完成单元测试计划。 2. 建立单元测试环境，完成测试设计和开发。 3. 执行单元测试用例，并且详细记录测试结果。 4. 判定测试用例是否通过。 5. 提交单元测试报告。单元测试的过程单元测试文档： 软件需求规格说明书、软件详细设计说明书 单元测试