质量保证与测试策略工作

质量保证与测试策略工作Zhu.软件质量就是客户的满意度软件缺陷(Bug)是什么软件测试的基本方法

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

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

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

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

Zhu.SQA与软件测试的关系

SQA

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

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

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

Zhu.制定测试策略

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

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

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

测试计划准备工作

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

设计测试用例

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

功能测试

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

集成&系统测试

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

第一轮测试

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

第二轮测试

----------

确认测试

------

测试结束

-

Zhu.通过/失败的标准单个的测试通过/失败

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

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

TestPlanQAQA创建

TestCases功能测试写/审查Spec系统测试单元测试PRD/UI审查QAZhu.签字signoffPRD（ProductRequirementDocument），

产品需求文档.PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。MRD，英文全称MarketRequirementDocument，市场需求文档。该文档在产品项目中是一个“承上启下”的作用，“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工作的方向说明和工作指导。作用是：产品项目由“准备”阶段进入到“实施”阶段的第一文档，其作用就是“对年度产品中规划的某个产品进行市场层面的说明”，这个文档的质量好坏直接影响到产品项目的开展，并直接影响到公司产品战略意图的实现。BRD，英文全称为：BusinessRequirementDocument；商业需求描述。基于商业目标或价值所描述的产品需求内容文档（报告），其核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据。BRD是产品生命周期中最早的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是供决策层们讨论的演示文档，一般比较短小精炼，没有产品细节。UserInterface(用户界面)阶段通过/失败的标准

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

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

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

日期

测试计划完成

---1/15

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

功能验证完成器

---2/5

代码冻结前完成系统测试

--2/20

版本发布前完成确认测试

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

测试计划

和英文Zhu.3.4软件质量的可靠性评估软件可靠性评估的概述软件可靠性模型可靠性评估过程Zhu.软件可靠性评估的概述软件可靠性评估（SoftwareReliabilityAssessment）指根据软件系统可靠性结构（单元与系统间可靠性关系）、寿命类型和各单元的可靠性试验信息，利用概率统计方法，评估出系统的可靠性特征量。软件可靠性评估的要素

1）规定的时间2）规定的环境条件3）规定的功能Zhu.软件可靠性模型

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

用时间定义的软件可靠性数据可以分为四类：失效时间数据，记录发生一次失效所累积经历的时间；失效间隔时间数据，记录本次失效与上一次失效间的间隔时间；分组数据，记录某个时间区内发生了多少次失效；分组时间内的累积失效数，记录某个区间内的累积失效数。这四类数据可以互相转化。测试时间；含有测试用例的测试计划或测试说明；所有与测试有关的测试结果，包括所有测试时发生的故障；参与测试的个人身份。可靠性评估报告Zhu.白盒测试白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。

白盒测试方法的分类语句覆盖，语句覆盖法的基本思想是设计若干测试用例，运行被测程序，使程序中的每个可执行语句至少被执行一次判定覆盖，判定覆盖法的基本思想是设计若干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经