质量保证与测试策略工作

1、软件测试方法和技术软件测试方法和技术- Ch.3质量保证与测试策略质量保证与测试策略第二章回顾Zhu.软件质量就是客户的满意度软件质量就是客户的满意度软件缺陷软件缺陷(Bug)是什么是什么软件测试的基本方法软件测试的基本方法- 白盒/黑盒，静态/动态，自动化/手工，软件测试的分类和阶段软件测试的分类和阶段- 单元、集成、系统（性能、适用性、兼容性）、验收测试软件测试的工作范畴软件测试的工作范畴- 策略、计划、设计、执行、报告、评估第三章第三章 质量保证与测试策略质量保证与测试策略Zhu.3.1 软件质量保证软件质量保证3.2 测试策略测试策略3.3 测试计划测试计划3.4 软件质量的可靠性评估

2、软件质量的可靠性评估3.1 软件质量保证软件质量保证（SQA）Zhu.什么是什么是 SQA ? Zhu.p确保确保SQA活动要自始至有计划的进行活动要自始至有计划的进行p审查软件产品和活动是否遵守适用的标准、规程和要求并得审查软件产品和活动是否遵守适用的标准、规程和要求并得到客观验证。到客观验证。pSQA的活动和结果要保证全员参与，沟通顺畅。的活动和结果要保证全员参与，沟通顺畅。p逐级解决不符合问题逐级解决不符合问题SQA活动活动p 技术方法的应用技术方法的应用p 正式技术评审的实施正式技术评审的实施p 软件测试软件测试p 标准的执行标准的执行p 修改的控制修改的控制p 度量度量p 质量记录和

3、记录保存质量记录和记录保存Zhu.SQA活动的影响因素活动的影响因素知识结构：知识结构：专业的技术，例如质量管理与控制知识、统计学知识等。经验经验依据：依据：如果没有这些标准，就无法准确地判断开发活动中的问题，容易引发不必要的争论，因此组织应当建立文档化的开发标准和规程。全员参与：全员参与：全员参与至关重要，高层管理者必须重视软件质量保证活动。把握重点：把握重点：一定要抓住问题的重点与本质，尽可能避免陷入对细节的争论之中。Zhu.SQA策略策略 SQA策略主要分三个阶段：策略主要分三个阶段： 以检测为重：产品制成之后进行检测，只能判断产品质量，不能提高产品质量。 以过程管理为重：把质量的保证工

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

5、（如功能测试、性能测试、压力测试等），以确定合理的测试方案使得测试更有效。Zhu.影响测试策略的因素影响测试策略的因素1 1、测试完成的标准、测试完成的标准标准的高低对策略确定有着重要的影响。比如该软件的应该用场合为军用，这将对软件的可靠性、安全性要求非常高，但如果是用于小型商场的收费系统由于是内部使用，主要考虑其计算的准确与精度及复杂统计与报表生成等方面准确性与易用性。(降落伞99.9%)2 2、资源状况、资源状况参与测试的人、测试中所需要的软件平台（如操作系统甚至会涉及到第三方的一些应用软件）及测试可能用到的相关硬件设备（如计算机，网络硬件其它外设等）Zhu.制定测试策略制定测试策略p 全

6、面细致地了解产品的项目信息全面细致地了解产品的项目信息:应用领域,测试范围,市场需求,产品的特点和主要功能,技术架构p 基于模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素对产品的影响因素对产品的影响, ,公正客观地开展测试计划公正客观地开展测试计划p 根据程序的重要性和一旦发生故障将造成的损失,来确定它的测试测试等级和测试重点等级和测试重点p 认真研究测试策略,以便能使用尽可能少的有效测试用例用尽可能少的有效测试用例, ,发现尽发现尽可能多的程序错误可能多的程序错误, ,因为一次完整的软件测试过后,如果程序中遗漏的错误过多并且很严重,则表明本次测试是失败的,是不足的;而测试不足

7、意味着让用户承担隐藏错误带来的危险.同时反过来说,如果过度测试,则又会浪费许多宝贵的资源. 找到一个最佳平衡点。Zhu.测试范围的确立测试范围的确立p 优先级最高的需求功能p 新功能和编码改动较大(提高性能表现)的旧功能p 运用有效的测试技术去提高测试效果p 经常容易出现问题部分的功能 p 一些经常被用户使用的功能和配置Zhu.测试持续阶段的确定测试持续阶段的确定当测试任务明确后当测试任务明确后, ,测试计划将依赖于测试小组的人力资测试计划将依赖于测试小组的人力资源而最终确定源而最终确定. . Task 1/1 1/8 1/15 1/20 1/29 2/5 2/12 2/20 2/28 需需

8、求求 分分 析析 - 设设 计计 审审 查查 - 测测 试试计划准备工作计划准备工作 - 设设 计计测试用例测试用例 - - 功功 能能 测测 试试 - 集集 成成&系统测试系统测试 - 第第一轮测试一轮测试 - 第第二轮测试二轮测试 - 确确 认认 测测 试试 - - 测测 试试 结结 束束 - - Zhu.通过通过/失败的标准失败的标准v 单个的测试通过单个的测试通过/ /失败失败 测试用例测试用例v 全部产品测试通过全部产品测试通过/ /失败失败 每个阶段的通过每个阶段的通过/ /失败失败Zhu.测试周期测试周期MRD/PRD/UI Sign-offEng. Plan Sign-offE

9、ng. Spec Sign-offTest Plan Sign-offProduct ReviewCode FreezeTest Case Sign-offCode Complete验收测试验收测试QA 创建创建 Test PlanQAQA创建创建 Test Cases功能测试功能测试写写/审查审查Spec系统测试系统测试单元测试单元测试PRD/UI审查审查QAZhu.签字 sign offPRD（Product Requirement Document）， 产品需求文档 .PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术

10、化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。MRD，英文全称Market Requirement Document，市场需求文档。该文档在产品项目中是一个“承上启下”的作用，“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工作的方向说明和工作指导。作用是：产品项目由“准备”阶段进入到“实施”阶段的第一文档，其作用就是“对年度产品中规划的某个产品进行市场层面的说明”，这个文档的质量好坏直接影响到产品项目的开展，并直接影响到公司产品战略意图的实现。BRD，英文全称为：Business Requirement Document； 商业需求描述。基于商业目标

11、或价值所描述的产品需求内容文档（报告），其核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据。BRD是产品生命周期中最早的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是供决策层们讨论的演示文档，一般比较短小精炼，没有产品细节。User Interface(用户界面) 阶段通过阶段通过/失败的标准失败的标准项目经理和测试组长已经全部按计划到位?所有相关的信息已经传达到QA? QA.开始了测试设计?需求阶段设计审查所有设计中及文档中的问题都已经被解决?技术设计和测试设计已经结束?最高优先级的功能要求已经实现 ? 新功能已经实现 ?所有的功能是按

12、照设计来实现的? 代码完成?功能验证确认测试回归测试完成与否?是不是完全按测试计划完成了所有的测试?没有严重的缺陷?达到产品发布的标准?测试环境的检查?所有严重问题是不是都已测出?功能测试, 压力测试,安全测试,兼容性测试,易用性测试是否都已完成? 有没有阻碍产品发布的缺陷？系统测试Zhu.风险评估风险评估Zhu.测试评估测试评估里程碑的定义和跟踪可以帮助项目管理者掌握项目的进行里程碑的定义和跟踪可以帮助项目管理者掌握项目的进行状态状态测试计划完成测试计划完成 - 1/15 测试用例完成测试用例完成 - 1/29 功能验证完成器功能验证完成器 - 2/5 代码冻结前完成系统测试代码冻结前完成系

13、统测试 - 2/20 版本版本发布前完成确认测试发布前完成确认测试 -2/28Zhu.测试计划的创建和评审测试计划的创建和评审MRD/PRDreview测试策略测试策略知识传递知识传递日日 程程测试测试 范围范围 反馈反馈 讨论分析讨论分析Formal Review meeting问题问题QA draft of Test PlanUpdated Test PlanFinal Test Plan测试方法测试方法任务任务Updated Test Plan资资 源源Pear-to-Pear or Internal ReviewChecklistZhu.测试计划内容构成测试计划内容构成测试计划制定的第

14、一步就是将软件分解较小而且相对独立的功能模块，写成测试需求。测试需求有很多分类方法，最普通的一种就是按照功能分类：p 测试需求是测试设计和开发测试用例的基础，分解功能模块可以更好地进行设计；p 详细的测试需求是用来衡量测试覆盖率的重要指标；p 测试需求包括各种测试实际和开发以及所需资源。一个测试计划应包括：产品基本情况、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等。Zhu.测试计划标准格式测试计划标准格式 -1 16 components of Test Plan (IEEE,1983)Test plan identifier （测试计划标识测试计划

15、标识)Instruction (引言）引言）Test Items （定义或主题词定义或主题词)Features to be tested （需要被测试的功能需要被测试的功能)Features not to be tested (无需被测试的功能无需被测试的功能)Approach (方法和途径）方法和途径）Items pass/ fail criteria （测试通过、失败的标准测试通过、失败的标准)Suspension criteria and resumption requirements （延迟的标准延迟的标准和再恢复的要求和再恢复的要求)Test deliverables (测试交付的内

16、容测试交付的内容)1. Testing Tasks (测试任务测试任务Zhu.测试计划标准格式测试计划标准格式 2 16 components of Test Plan (IEEE,1983)Environmental needs （必备的环境必备的环境)Responsibilities (职责职责)Staffing and training needs (人员和必需的培训人员和必需的培训)Schedule (时间进度表时间进度表)Risk and contingencies (风险和相关费用）风险和相关费用）Approvals （批准批准)模板：模板：中文中文 测试计划测试计划 和和 英文英

17、文Zhu.3.4 软件质量的可靠性评估软件质量的可靠性评估 3.4.1软件可靠性评估的概述 3.4.2软件可靠性模型 3.4.2可靠性评估过程Zhu.软件可靠性评估的概述软件可靠性评估的概述软件可靠性评估软件可靠性评估（Software Reliability Assessment）指根据软件系统可靠性结构（单元与系统间可靠性关系）、寿命类型和各单元的可靠性试验信息，利用概率统计方法，评估出系统的可靠性特征量。软件可靠性评估的要素软件可靠性评估的要素 1）规定的时间2）规定的环境条件3）规定的功能Zhu.软件可靠性模型软件可靠性模型软件可靠性模型软件可靠性模型（Software reliabi

18、lity model）是指为预计或估算软件的可靠性所建立的可靠性结构和数学模型。建立可靠性模型是为了将复杂系统的可靠性逐级分解为简单系统的可靠性，以便于定量预计、分配、估算和评价复杂系统的可靠性。1）可靠性结构模型可靠性结构模型，是依据系统结构逻辑关系，对系统的可靠性特征及其发展变化规律做出可靠性评价。2）可靠性预计模型，可靠性预计模型，是用来描述软件失效与软件缺陷的关系，借助这类模型，可以对软件的可靠性特征做出定量的预计或评估。依据软件缺陷与运行剖面数据，利用统计学原理建立二者之间的数学关系，获取开发过程中可靠性变化、软件在预定工作时间的可靠度、软件在任意时刻发生的失效数的平均值以及软件在规

19、定时间间隔内发生失效次数的平均值。 Zhu.可靠性评估过程可靠性评估过程可靠性数据收集可靠性数据收集 用时间定义的软件可靠性数据可以分为四类：失效时间数据，记录发生一次失效所累积经历的时间；失效间隔时间数据，记录本次失效与上一次失效间的间隔时间；分组数据，记录某个时间区内发生了多少次失效；分组时间内的累积失效数，记录某个区间内的累积失效数。这四类数据可以互相转化。测试时间；含有测试用例的测试计划或测试说明； 所有与测试有关的测试结果，包括所有测试时发生的故障；参与测试的个人身份。 可靠性评估报告可靠性评估报告Zhu.白盒测试白盒测试 白盒测试也称结构测试或逻辑驱动测试，白盒测试也称结构测试或逻

20、辑驱动测试，它是按照程序内部的结构测试程序，通过它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。每条通路是否都能按预定要求正确工作。 白盒测试方法的分类白盒测试方法的分类语句覆盖，语句覆盖法的基本思想是设计若语句覆盖，语句覆盖法的基本思想是设计若干测试用例，运行被测程序，使程序中的干测试用例，运行被测程序，使程序中的每个可执行语句至少被执行一次每个可执行语句至少被执行一次判定覆盖，判定覆盖法的基本思想是设计若判定覆盖，判定覆盖法

21、的基本思想是设计若干用例，运行被测程序，使得程序中每个干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足即判断真假值均曾被满足条件覆盖，条件覆盖的基本思想是设计若干条件覆盖，条件覆盖的基本思想是设计若干测试用例，执行被测程序以后，要使每个测试用例，执行被测程序以后，要使每个判断中每个条件的可能取值至少满足一次。判断中每个条件的可能取值至少满足一次。 黑盒测试黑盒测试 黑盒测试也称功能测试，它是通过测试来黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。检测每个功能是否都能正常使用。 黒盒测试方法的分类：黒盒测试方法的分类：等价类划分法，分为有效