软件测试方法和技术及质量保证与测试策略课件

软件测试方法和技术

-Ch.3质量保证与测试策略Zhu.Kerry@朱少民KerryZhu软件测试方法和技术

-Ch.3质量保证与测试策略Zhu1第二章回顾Zhu.Kerry@软件质量就是客户的满意度软件缺陷(Bug)是什么软件测试的基本方法

-白盒/黑盒，静态/动态，自动化/手工，…软件测试的分类和阶段

-单元、集成、系统（性能、适用性、兼容性…）、验收测试软件测试的工作范畴

-策略、计划、设计、执行、报告、评估…第二章回顾Zhu.Kerry@软件质量就是2第三章质量保证与测试策略Zhu.Kerry@3.1软件质量保证3.2测试策略3.3测试计划3.4软件质量的可靠性评估第三章质量保证与测试策略Zhu.Kerry@gmail.c33.1软件质量保证（SQA）SQA概述SQA活动SQS与软件测试的关系Zhu.Kerry@3.1软件质量保证（SQA）SQA概述Zhu.Kerry4什么是SQA?软件质量保证是通过对软件产品和活动有计划的进行评审和审计来验证软件是否合乎标准的系统工程活动.

Zhu.Kerry@确保SQA活动要自始至有计划的进行审查软件产品和活动是否遵守适用的标准、规程和要求并得到客观验证。SQA的活动和结果要保证全员参与，沟通顺畅。逐级解决不符合问题什么是SQA?软件质量保证是通过对软件产品和活动有计划的5SQA活动技术方法的应用正式技术评审的实施软件测试标准的执行修改的控制度量质量记录和记录保存Zhu.Kerry@SQA活动技术方法的应用Zhu.Kerry@gmail.co6SQA活动的影响因素知识结构：专业的技术，例如质量管理与控制知识、统计学知识等。经验依据：如果没有这些标准，就无法准确地判断开发活动中的问题，容易引发不必要的争论，因此组织应当建立文档化的开发标准和规程。全员参与：全员参与至关重要，高层管理者必须重视软件质量保证活动。把握重点：一定要抓住问题的重点与本质，尽可能避免陷入对细节的争论之中。Zhu.Kerry@SQA活动的影响因素知识结构：专业的技术，例如质量管理与控制7SQA策略SQA策略主要分三个阶段：以检测为重：产品制成之后进行检测，只能判断产品质量，不能提高产品质量。以过程管理为重：把质量的保证工作重点放在过程管理上，对制造过程中的每一道工序都要进行质量控制。以新产品开发为重：在新产品的开发设计阶段，采取强有力的措施来消灭由于设计原因而产生的质量隐患。Zhu.Kerry@SQA策略SQA策略主要分三个阶段：Zhu.Kerry@gm8SQA与软件测试有什么关系和区别？

Zhu.Kerry@SQA与软件测试有什么关系和区别？Zhu.Kerry@gm9SQA与软件测试的关系

SQA

是管理工作、审查对象是流程、强调以预防为主测试是技术工作、测试对象是产品、主要是以事后检查SQA指导测试、监控测试测试为SQA提供依据Zhu.Kerry@SQA与软件测试的关系SQA是管理工作、审查对象是流程、10测试策略的概念测试策略通常是描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试（如单元测试、集成测试、系统测试）以及每个阶段内进行的测试种类（如功能测试、性能测试、压力测试等），以确定合理的测试方案使得测试更有效。

Zhu.Kerry@测试策略的概念测试策略通常是描述测试工程的总体方法和目标。描11影响测试策略的因素1、测试完成的标准标准的高低对策略确定有着重要的影响。比如该软件的应该用场合为军用，这将对软件的可靠性、安全性要求非常高，但如果是用于小型商场的收费系统由于是内部使用，主要考虑其计算的准确与精度及复杂统计与报表生成等方面准确性与易用性。2、资源状况

参与测试的人、测试中所需要的软件平台（如操作系统甚至会涉及到第三方的一些应用软件）及测试可能用到的相关硬件设备（如计算机，网络硬件其它外设等）

Zhu.Kerry@影响测试策略的因素1、测试完成的标准Zhu.Kerry@gm12制定测试策略

全面细致地了解产品的项目信息:应用领域,测试范围,市场需求,产品的特点和主要功能,技术架构基于模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素对产品的影响,公正客观地开展测试计划根据程序的重要性和一旦发生故障将造成的损失,来确定它的测试等级和测试重点认真研究测试策略,以便能使用尽可能少的有效测试用例,发现尽可能多的程序错误,因为一次完整的软件测试过后,如果程序中遗漏的错误过多并且很严重,则表明本次测试是失败的,是不足的;而测试不足意味着让用户承担隐藏错误带来的危险.同时反过来说,如果过度测试,则又会浪费许多宝贵的资源.找到一个最佳平衡点。Zhu.Kerry@制定测试策略全面细致地了解产品的项目信息:应用领域,测试范13测试范围的确立优先级最高的需求功能新功能和编码改动较大(提高性能表现)的旧功能运用有效的测试技术去提高测试效果经常容易出现问题部分的功能一些经常被用户使用的功能和配置Zhu.Kerry@测试范围的确立Zhu.Kerry@14测试持续阶段的确定当测试任务明确后,测试计划将依赖于测试小组的人力资源而最终确定.

Task1/11/81/151/201/292/52/122/202/28需求分析-----设计审查

-------------

测试计划准备工作

-----------------

设计测试用例

--------------------

功能测试

------------

集成&系统测试

--------------------

第一轮测试

------------

第二轮测试

----------

确认测试

------

测试结束

-

Zhu.Kerry@测试持续阶段的确定当测试任务明确后,测试计划将依赖于测试小组15通过/失败的标准单个的测试通过/失败

测试用例全部产品测试通过/失败

每个阶段的通过/失败Zhu.Kerry@通过/失败的标准Zhu.Kerry@16测试周期MRD/PRD/UISign-offEng.PlanSign-offEng.SpecSign-offTestPlanSign-offProductReviewCodeFreezeTestCaseSign-offCodeCompleteER验收测试QA创建

TestPlanQAQA创建

TestCases功能测试写/审查Spec系统测试单元测试PRD/UI审查QAZhu.Kerry@测试周期MRD/PRD/UISign-offEng.Pl17阶段通过/失败的标准

项目经理和测试组长已经全部按计划到位?所有相关的信息已经传达到QA?QA.开始了测试设计?需求阶段设计审查所有设计中及文档中的问题都已经被解决?技术设计和测试设计已经结束?最高优先级的功能要求已经实现?新功能已经实现?所有的功能是按照设计来实现的?代码完成?功能验证确认测试回归测试完成与否?是不是完全按测试计划完成了所有的测试?没有严重的缺陷?达到产品发布的标准?测试环境的检查?所有严重问题是不是都已测出?功能测试,压力测试,安全测试,兼容性测试,易用性测试是否都已完成?有没有阻碍产品发布的缺陷？系统测试Zhu.Kerry@阶段通过/失败的标准项目经理和测试组长已经全部按计划到位?18风险评估

测试小组开始项目测试时,硬件资源没有按时配备或仍然不足开始项目测试时,软件产品编码没有按计划完成开始项目测试时,测试用例没有准备好缺少按计划参加项目测试的测试人员在项目测试过程中,需求总是不停地改动当项目测试进行时,在设计说明书中被定义的功能总是不停地被修改Zhu.Kerry@风险评估Zhu.Kerry@19测试评估

里程碑的定义和跟踪可以帮助项目管理者掌握项目的进行状态

里程碑

日期

测试计划完成---1/15

测试用例完成---1/29

功能验证完成器

---2/5

代码冻结前完成系统测试--2/20

版本发布前完成确认测试

---2/28Zhu.Kerry@测试评估Zhu.Kerry@20测试计划的创建和评审MRD/PRDreview测试策略知识传递日程测试范围反馈讨论分析FormalReviewmeeting问题QAdraftofTestPlanUpdatedTestPlanFinalTestPlan测试方法任务UpdatedTestPlan资源Pear-to-PearorInternalReviewChecklistZhu.Kerry@测试计划的创建和评审MRD/PRD测试策略知识传递日程测试21测试计划内容构成测试计划制定的第一步就是将软件分解较小而且相对独立的功能模块，写成测试需求。测试需求有很多分类方法，最普通的一种就是按照功能分类：测试需求是测试设计和开发测试用例的基础，分解功能模块可以更好地进行设计；详细的测试需求是用来衡量测试覆盖率的重要指标；测试需求包括各种测试实际和开发以及所需资源。一个测试计划应包括：产品基本情况、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等。Zhu.Kerry@测试计划内容构成测试计划制定的第一步就是将软件分解较小而且相22测试计划标准格式-116componentsofTestPlan(IEEE,1983)Testplanidentifier（测试计划标识)Instruction(引言）TestItems（定义或主题词)Featurestobetested（需要被测试的功能)Featuresnottobetested(无需被测试的功能)Approach(方法和途径）Itemspass/failcriteria（测试通过、失败的标准)Suspensioncriteriaandresumptionrequirements（延迟的标准和再恢复的要求)Testdeliverables(测试交付的内容)TestingTasks(测试任务Zhu.Kerry@测试计划标准格式-116componentsofTe23测试计划标准格式–216componentsofTestPlan(IEEE,1983)Environmentalneeds（必备的环境)Responsibilities(职责)Staffingandtrainingneeds(人员和必需的培训)Schedule(时间进度表)Riskandcontingencies(风险和相关费用）Approvals（批准)模板：中文

测试计划

和英文Zhu.Kerry@测试计划标准格式–216componentsofT243.4软件质量的可靠性评估3.4.1软件可靠性评估的概述3.4.2软件可靠性模型3.4.2可靠性评估过程Zhu.Kerry@3.4软件质量的可靠性评估Zhu.Kerry@gmail.25软件可靠性评估的概述软件可靠性评估（SoftwareReliabilityAssessment）指根据软件系统可靠性结构（单元与系统间可靠性关系）、寿命类型和各单元的可靠性试验信息，利用概率统计方法，评估出系统的可靠性特征量。软件可靠性评估的要素

1）规定的时间2）规定的环境条件3）规定的功能Zhu.Kerry@软件可靠性评估的概述软件可靠性评估（SoftwareRel26软件可靠性模型

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

用时间定义的软件可靠性数据可以分为四类：失效时间数据，记录发生一次失效所累积经历的时间；失效间隔时间数据，记录本次失效与上一次失效间的间隔时间；分组数据，记录某个时间区内发生了多少次失效；分组时间内的累积失效数，记录某个区间内的累积失效数。这四类数据可以互相转化。测试时间；含有测试用例的测试计划或测试说明；所有与测试有关的测试结果，包括所有测试时发生的故障；参与测试的个人身份。可靠性评估报告Zhu.Kerry@可靠性评估过程可靠性数据收集Zhu.Kerry@gmail28作业Zhu.Kerry@第三章2、3作业Zhu.Kerry@第三章2、329Q&AZhu.Kerry@Q&AZhu.Kerry@30软件测试方法和技术

-Ch.3质量保证与测试策略Zhu.Kerry@朱少民KerryZhu软件测试方法和技术

-Ch.3质量保证与测试策略Zhu31第二章回顾Zhu.Kerry@软件质量就是客户的满意度软件缺陷(Bug)是什么软件测试的基本方法

-白盒/黑盒，静态/动态，自动化/手工，…软件测试的分类和阶段

-单元、集成、系统（性能、适用性、兼容性…）、验收测试软件测试的工作范畴

-策略、计划、设计、执行、报告、评估…第二章回顾Zhu.Kerry@软件质量就是32第三章质量保证与测试策略Zhu.Kerry@3.1软件质量保证3.2测试策略3.3测试计划3.4软件质量的可靠性评估第三章质量保证与测试策略Zhu.Kerry@gmail.c333.1软件质量保证（SQA）SQA概述SQA活动SQS与软件测试的关系Zhu.Kerry@3.1软件质量保证（SQA）SQA概述Zhu.Kerry34什么是SQA?软件质量保证是通过对软件产品和活动有计划的进行评审和审计来验证软件是否合乎标准的系统工程活动.

Zhu.Kerry@确保SQA活动要自始至有计划的进行审查软件产品和活动是否遵守适用的标准、规程和要求并得到客观验证。SQA的活动和结果要保证全员参与，沟通顺畅。逐级解决不符合问题什么是SQA?软件质量保证是通过对软件产品和活动有计划的35SQA活动技术方法的应用正式技术评审的实施软件测试标准的执行修改的控制度量质量记录和记录保存Zhu.Kerry@SQA活动技术方法的应用Zhu.Kerry@gmail.co36SQA活动的影响因素知识结构：专业的技术，例如质量管理与控制知识、统计学知识等。经验依据：如果没有这些标准，就无法准确地判断开发活动中的问题，容易引发不必要的争论，因此组织应当建立文档化的开发标准和规程。全员参与：全员参与至关重要，高层管理者必须重视软件质量保证活动。把握重点：一定要抓住问题的重点与本质，尽可能避免陷入对细节的争论之中。Zhu.Kerry@SQA活动的影响因素知识结构：专业的技术，例如质量管理与控制37SQA策略SQA策略主要分三个阶段：以检测为重：产品制成之后进行检测，只能判断产品质量，不能提高产品质量。以过程管理为重：把质量的保证工作重点放在过程管理上，对制造过程中的每一道工序都要进行质量控制。以新产品开发为重：在新产品的开发设计阶段，采取强有力的措施来消灭由于设计原因而产生的质量隐患。Zhu.Kerry@SQA策略SQA策略主要分三个阶段：Zhu.Kerry@gm38SQA与软件测试有什么关系和区别？

Zhu.Kerry@SQA与软件测试有什么关系和区别？Zhu.Kerry@gm39SQA与软件测试的关系

SQA

是管理工作、审查对象是流程、强调以预防为主测试是技术工作、测试对象是产品、主要是以事后检查SQA指导测试、监控测试测试为SQA提供依据Zhu.Kerry@SQA与软件测试的关系SQA是管理工作、审查对象是流程、40测试策略的概念测试策略通常是描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试（如单元测试、集成测试、系统测试）以及每个阶段内进行的测试种类（如功能测试、性能测试、压力测试等），以确定合理的测试方案使得测试更有效。

Zhu.Kerry@测试策略的概念测试策略通常是描述测试工程的总体方法和目标。描41影响测试策略的因素1、测试完成的标准标准的高低对策略确定有着重要的影响。比如该软件的应该用场合为军用，这将对软件的可靠性、安全性要求非常高，但如果是用于小型商场的收费系统由于是内部使用，主要考虑其计算的准确与精度及复杂统计与报表生成等方面准确性与易用性。2、资源状况

参与测试的人、测试中所需要的软件平台（如操作系统甚至会涉及到第三方的一些应用软件）及测试可能用到的相关硬件设备（如计算机，网络硬件其它外设等）

Zhu.Kerry@影响测试策略的因素1、测试完成的标准Zhu.Kerry@gm42制定测试策略

全面细致地了解产品的项目信息:应用领域,测试范围,市场需求,产品的特点和主要功能,技术架构基于模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素对产品的影响,公正客观地开展测试计划根据程序的重要性和一旦发生故障将造成的损失,来确定它的测试等级和测试重点认真研究测试策略,以便能使用尽可能少的有效测试用例,发现尽可能多的程序错误,因为一次完整的软件测试过后,如果程序中遗漏的错误过多并且很严重,则表明本次测试是失败的,是不足的;而测试不足意味着让用户承担隐藏错误带来的危险.同时反过来说,如果过度测试,则又会浪费许多宝贵的资源.找到一个最佳平衡点。Zhu.Kerry@制定测试策略全面细致地了解产品的项目信息:应用领域,测试范43测试范围的确立优先级最高的需求功能新功能和编码改动较大(提高性能表现)的旧功能运用有效的测试技术去提高测试效果经常容易出现问题部分的功能一些经常被用户使用的功能和配置Zhu.Kerry@测试范围的确立Zhu.Kerry@44测试持续阶段的确定当测试任务明确后,测试计划将依赖于测试小组的人力资源而最终确定.

Task1/11/81/151/201/292/52/122/202/28需求分析-----设计审查

-------------

测试计划准备工作

-----------------

设计测试用例

--------------------

功能测试

------------

集成&系统测试

--------------------

第一轮测试

------------

第二轮测试

----------

确认测试

------

测试结束

-

Zhu.Kerry@测试持续阶段的确定当测试任务明确后,测试计划将依赖于测试小组45通过/失败的标准单个的测试通过/失败

测试用例全部产品测试通过/失败

每个阶段的通过/失败Zhu.Kerry@通过/失败的标准Zhu.Kerry@46测试周期MRD/PRD/UISign-offEng.PlanSign-offEng.SpecSign-offTestPlanSign-offProductReviewCodeFreezeTestCaseSign-offCodeCompleteER验收测试QA创建

TestPlanQAQA创建

TestCases功能测试写/审查Spec系统测试单元测试PRD/UI审查QAZhu.Kerry@测试周期MRD/PRD/UISign-offEng.Pl47阶段通过/失败的标准

项目经理和测试组长已经全部按计划到位?所有相关的信息已经传达到QA?QA.开始了测试设计?需求阶段设计审查所有设计中及文档中的问题都已经被解决?技术设计和测试设计已经结束?最高优先级的功能要求已经实现?新功能已经实现?所有的功能是按照设计来实现的?代码完成?功能验证确认测试回归测试完成与否?是不是完全按测试计划完成了所有的测试?没有严重的缺陷?达到产品发布的标准?测试环境的检查?所有严重问题是不是都已测出?功能测试,压力测试,安全测试,兼容性测试,易用性测试是否都已完成?有没有阻碍产品发布的缺陷？系统测试Zhu.Kerry@阶段通过/失败的标准项目经理和测试组长已经全部按计划到位?48风险评估

测试小组开始项目测试时,硬件资源没有按时配备或仍然不足开始项目测试时,软件产品编码没有按计划完成开始项目测试时,测试用例没有准备好缺少按计划参加项目测试的测试人员在项目测试过程中,需求总是不停地改动当项目测试进行时,在设计说明书中被定义的功能总是不停地被修改Zhu.Kerry@风险评估Zhu.Kerry@49测试评估

里程碑的定义和跟踪可以帮助项目管理者掌握项目的进行状态

里程碑

日期

测试计划完成---1/15

测试用例完成---1/29

功能验证完成器

---2/5

代码冻结前完成系统测试--2/20

版本发布前完成确认测试

---2/28Zhu.Kerry@测试评估Zhu.Kerry@50测试计划的创建和评审MRD/PRDreview测试策略知识传递日程测试范围反馈讨论分析FormalReviewmeeting问题QAdraftofTestPlanUpdatedTestPlanFinalTestPlan测试方法任务UpdatedTestPlan资源Pear-to-PearorInternalReviewChecklistZhu.Kerry@测试计划的创建和评审MRD/PRD测试策略知识传递日程测试51测试计划内容构成测试计划制定的第一步就是将软件分解较小而且相对独立的功能模块，写成测试需求。测试需求有很多分类方法，最普通的一种就是按照功能分类：测试需求是测试设计和开发测试用例的基础，分解功能模块可以更好地进行设计；详细的测试需求是用来衡量测试覆盖率的重要指标；测试需求包括各种测试实际和开发以及所需资源。一个测试计划应包括：产品基本情况、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等。Zhu.Kerry@测试计划内容构成测试计划制定的第一步就是将软件分解较小而且相52测试计划标准格式-116componentsofTestPlan(IEEE,1983)Testplanidentifier（测试计划标识)Instruction(引言）TestItems（定义或主题词)Featurestobetested（需要被测试的功能)Featuresnottobetested(无需被测试的功能)Approach(方法和途径）Itemspass/failcriteria（测试通过、失败的标准)Suspensioncriteriaandresumptionrequirements（延迟的标准和再恢复的要求)Testdeliverables(测试交付的内容)TestingTasks(测试任务Zhu.Kerry@测试计划标准格式-116componen