软件测试方法和技术软件测试方法和技术 - Ch.3质质量保量保证证与与测试测试策略策略第二章回顾软件质量就是客户的满意度软件质量就是客户的满意度软件缺陷软件缺陷(Bug)是什么是什么软件测试的基本方法软件测试的基本方法- 白盒/黑盒，静态/动态，自动化/手工，软件测试的分类和阶段软件测试的分类和阶段- 单元、集成、系统（性能、适用性、兼容性）、验收测试软件测试的工作范畴软件测试的工作范畴- 策略、计划、设计、执行、报告、评估第三章第三章 质质量保量保证证与与测试测试策略策略3.1 软件质量保证软件质量保证3.2 测试策略测试策略3.3 测试计划测试计划3.4 软件质量的可靠性评估软件质量的可靠性评估3.1 软件质量保证软件质量保证（SQA）SQA 概述概述SQA 活动活动SQA 与软件测试的关系与软件测试的关系什么是什么是 SQA ?软件质量保证是通过对软件产品和活动有计划的进行软件质量保证是通过对软件产品和活动有计划的进行软件质量保证是通过对软件产品和活动有计划的进行软件质量保证是通过对软件产品和活动有计划的进行评审和审计来验证软件是否合乎标准的系统工程活动评审和审计来验证软件是否合乎标准的系统工程活动评审和审计来验证软件是否合乎标准的系统工程活动评审和审计来验证软件是否合乎标准的系统工程活动. . p确保确保SQA活动要自始至有计划的进行活动要自始至有计划的进行p审查软件产品和活动是否遵守适用的标准、规程和要求并得审查软件产品和活动是否遵守适用的标准、规程和要求并得到客观验证。到客观验证。pSQA的活动和结果要保证全员参与，沟通顺畅。的活动和结果要保证全员参与，沟通顺畅。p逐级解决不符合问题逐级解决不符合问题SQA活动活动p技术方法的应用技术方法的应用p正式技术评审的实施正式技术评审的实施p软件测试软件测试p标准的执行标准的执行p修改的控制修改的控制p度量度量p质量记录和记录保存质量记录和记录保存SQA活动的影响因素活动的影响因素n知识结构：知识结构：专业的技术，例如质量管理与控制知识、统计学知识等。n经验经验n依据：依据：如果没有这些标准，就无法准确地判断开发活动中的问题，容易引发不必要的争论，因此组织应当建立文档化的开发标准和规程。n全员参与：全员参与：全员参与至关重要，高层管理者必须重视软件质量保证活动。n把握重点：把握重点：一定要抓住问题的重点与本质，尽可能避免陷入对细节的争论之中。SQA策略策略nSQA策略主要分三个阶段：策略主要分三个阶段：n以检测为重：产品制成之后进行检测，只能判断产品质量，不能提高产品质量。n以过程管理为重：把质量的保证工作重点放在过程管理上，对制造过程中的每一道工序都要进行质量控制。n以新产品开发为重：在新产品的开发设计阶段，采取强有力的措施来消灭由于设计原因而产生的质量隐患。SQA与软件测试有什么关系和区别？与软件测试有什么关系和区别？ SQA与软件测试的关系与软件测试的关系 nSQA 是管理工作、审查对象是流程、强调以预防为主n测试测试是技术工作、测试对象是产品、主要是以事后检查nSQA指导测试、监控测试n测试为SQA提供依据测试策略的概念测试策略的概念测试策略通常是描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试（如单元测试、集成测试、系统测试）以及每个阶段内进行的测试种类（如功能测试、性能测试、压力测试等），以确定合理的测试方案使得测试更有效。 影响测试策略的因素影响测试策略的因素1 1、测试完成的标准、测试完成的标准标准的高低对策略确定有着重要的影响。比如该软件的应该用场合为军用，这将对软件的可靠性、安全性要求非常高，但如果是用于小型商场的收费系统由于是内部使用，主要考虑其计算的准确与精度及复杂统计与报表生成等方面准确性与易用性。2 2、资源状况、资源状况参与测试的人、测试中所需要的软件平台（如操作系统甚至会涉及到第三方的一些应用软件）及测试可能用到的相关硬件设备（如计算机，网络硬件其它外设等） 制定测试策略制定测试策略p 全面细致地了解产品的项目信息全面细致地了解产品的项目信息:应用领域,测试范围,市场需求,产品的特点和主要功能,技术架构p 基于模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素对产品的影响因素对产品的影响, ,公正客观地开展测试计划公正客观地开展测试计划p 根据程序的重要性和一旦发生故障将造成的损失,来确定它的测试测试等级和测试重点等级和测试重点p 认真研究测试策略,以便能使用尽可能少的有效测试用例用尽可能少的有效测试用例, ,发现尽可发现尽可能多的程序错误能多的程序错误, ,因为一次完整的软件测试过后,如果程序中遗漏的错误过多并且很严重,则表明本次测试是失败的,是不足的;而测试不足意味着让用户承担隐藏错误带来的危险.同时反过来说,如果过度测试,则又会浪费许多宝贵的资源. 找到一个最佳平衡点。测试范围的确立测试范围的确立p优先级最高的需求功能p新功能和编码改动较大(提高性能表现)的旧功能p运用有效的测试技术去提高测试效果p经常容易出现问题部分的功能 p一些经常被用户使用的功能和配置测试持续阶段的确定测试持续阶段的确定当测试任务明确后当测试任务明确后, ,测试计划将依赖于测试小组的人力资测试计划将依赖于测试小组的人力资源而最终确定源而最终确定. . Task /Time 1/1 1/8 1/15 1/20 1/29 2/5 2/12 2/20 2/28 需需 求求 分分 析析 - 设设 计计 审审 查查 - 测测 试试计划准备工作计划准备工作 - 设设 计计测试用例测试用例 - 功功 能能 测测 试试 - 集集 成成&系统测试系统测试 - 第第一轮测试一轮测试 - 第第二轮测试二轮测试 - 确确 认认 测测 试试 - 测测 试试 结结 束束 - 通过通过/失败的标准失败的标准v单个的测试通过单个的测试通过/ /失败失败 测测试试用例用例v全部产品测试通过全部产品测试通过/ /失败失败 每每个阶段的通过个阶段的通过/ /失败失败测试周期测试周期MRD/PRD/UI Sign-offEng. Plan Sign-offEng. Spec Sign-offTest Plan Sign-offProduct ReviewCode FreezeTest Case Sign-offCode CompleteER验收测试验收测试QA 创建创建 Test PlanQAQA创建创建 Test Cases功能测试功能测试写写/审查审查Spec系统测试系统测试单元测试单元测试PRD/UI审查审查QA阶段通过阶段通过/失败的标准失败的标准 项目经理和测试组长已经全部按计划到位?所有相关的信息已经传达到QA? QA.开始了测试设计?需求阶段设计审查所有设计中及文档中的问题都已经被解决?技术设计和测试设计已经结束?最高优先级的功能要求已经实现 ? 新功能已经实现 ?所有的功能是按照设计来实现的? 代码完成?功能验证确认测试回归测试完成与否?是不是完全按测试计划完成了所有的测试?没有严重的缺陷?达到产品发布的标准?测试环境的检查?所有严重问题是不是都已测出?功能测试, 压力测试,安全测试,兼容性测试,易用性测试是否都已完成? 有没有阻碍产品发布的缺陷？系统测试风险评估风险评估 pp测试小组开始项目测试时测试小组开始项目测试时测试小组开始项目测试时测试小组开始项目测试时, , , ,硬件资源没有按时配备或仍硬件资源没有按时配备或仍硬件资源没有按时配备或仍硬件资源没有按时配备或仍然然然然不足不足不足不足pp开始项目测试时开始项目测试时开始项目测试时开始项目测试时, , , , 软件产品编码没有按计划软件产品编码没有按计划软件产品编码没有按计划软件产品编码没有按计划完成完成完成完成pp开始项目测试时开始项目测试时开始项目测试时开始项目测试时, , , , 测试用例没有准测试用例没有准测试用例没有准测试用例没有准备好备好备好备好pp缺少按计划参加项目测试的测试缺少按计划参加项目测试的测试缺少按计划参加项目测试的测试缺少按计划参加项目测试的测试人员人员人员人员pp在项目测试过程中在项目测试过程中在项目测试过程中在项目测试过程中, , , , 需求总是不停地需求总是不停地需求总是不停地需求总是不停地改动改动改动改动pp当项目测试进行时当项目测试进行时当项目测试进行时当项目测试进行时, , , , 在设计说明书中被定义的功能总在设计说明书中被定义的功能总在设计说明书中被定义的功能总在设计说明书中被定义的功能总是不停地被修改是不停地被修改是不停地被修改是不停地被修改测试评估测试评估 里程碑的定义和跟踪可以帮助项目管理者掌握项目的进行里程碑的定义和跟踪可以帮助项目管理者掌握项目的进行状态状态n n 里里里里程碑程碑程碑程碑 日期日期日期日期n n 测试计划完成测试计划完成 - 1/15n 测试用例完成测试用例完成 - 1/29n 功能验证完成功能验证完成 - 2/5n 代码冻结前完成系统测试代码冻结前完成系统测试 - 2/20n 版本版本发布前完成确认测试发布前完成确认测试 -2/28测试计划的创建和评审测试计划的创建和评审MRD/PRDreview测试策略测试策略知识传递知识传递日日 程程测试测试 范围范围 反馈反馈 讨论分析讨论分析Formal Review meeting问题问题QA draft of Test PlanUpdated Test PlanFinal Test Plan测试方法测试方法任务任务Updated Test Plan资资 源源Pear-to-Pear or Internal ReviewChecklist测试计划内容构成测试计划内容构成测试计划制定的第一步就是将软件分解较小而且相对独立的功能模块，写成测试需求。测试需求有很多分类方法，最普通的一种就是按照功能分类：p 测试需求是测试设计和开发测试用例的基础，分解功能模块可以更好地进行设计；p 详细的测试需求是用来衡量测试覆盖率的重要指标；p 测试需求包括各种测试实际和开发以及所需资源。一个测试计划应包括：产品基本情况、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等。测试计划标准格式测试计划标准格式 -1n16 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.Suspension criteria and resumption requirements （延迟延迟的标准和再恢复的要求的标准和再恢复的要求)9.Test deliverables (测试交付的内容测试交付的内容)10.Testing Tasks (测试任务测试任务测试计划标准格式测试计划标准格式 2n16 components of Test Plan (IEEE,1983)11.Environmental needs （必备的环境必备的环境)12.Responsibilities (职责职责)13.Staffing and training needs (人员和必需的培训人员和必需的培训)14.Schedule (时间进度表时间进度表)15.Risk and contingencies (风险和相关费用）风险和相关费用）16.Approvals （批准批准)模板：模板：中文中文 测试计划测试计划 和和 英文英文3.4 软件质量的可靠性评估软件质量的可靠性评估n3.4.1软件可靠性评估的概述n3.4.2软件可靠性模型n3.4.2可靠性评估过程软件可靠性评估的概述软件可靠性评估的概述软件可靠性评估软件可靠性评估（Software Reliability Assessment）指根据软件系统可靠性结构（单元与系统间可靠性关系）、寿命类型和各单元的可靠性试验信息，利用概率统计方法，评估出系统的可靠性特征量。软件可靠性评估的要素软件可靠性评估的要素 1）规定的时间2）规定的环境条件3）规定的功能软件可靠性模型软件可靠性模型 软件可靠性模型软件可靠性模型（Software reliability model）是指为预计或估算软件的可靠性所建立的可靠性结构和数学模型。建立可靠性模型是为了将复杂系统的可靠性逐级分解为简单系统的可靠性，以便于定量预计、分配、估算和评价复杂系统的可靠性。1）可靠性结构模型可靠性结构模型，是依据系统结构逻辑关系，对系统的可靠性特征及其发展变化规律做出可靠性评价。2）可靠性预计模型，可靠性预计模型，是用来描述软件失效与软件缺陷的关系，借助这类模型，可以对软件的可靠性特征做出定量的预计或评估。依据软件缺陷与运行剖面数据，利用统计学原理建立二者之间的数学关系，获取开发过程中可靠性变化、软件在预定工作时间的可靠度、软件在任意时刻发生的失效数的平均值以及软件在规定时间间隔内发生失效次数的平均值。 可靠性评估过程可靠性评估过程可靠性数据收集可靠性数据收集 用时间定义的软件可靠性数据可以分为四类：n失效时间数据，记录发生一次失效所累积经历的时间；n失效间隔时间数据，记录本次失效与上一次失效间的间隔时间；n分组数据，记录某个时间区内发生了多少次失效；n分组时间内的累积失效数，记录某个区间内的累积失效数。这四类数据可以互相转化。n测试时间；n含有测试用例的测试计划或测试说明； n所有与测试有关的测试结果，包括所有测试时发生的故障；n参与测试的个人身份。 可靠性评估报告可靠性评估报告Q & AZhu.Kerrygmail.com