【软件测试】质量保证与测试策略

1.软件质量保证（SQA）

 

 

1.1   什么是SQA ？

 

软件质量保证是通过对软件产品和活动有计划的进行评审和审计来验证软件是否合乎标准的系统工程活动. 

 

 

• 确保SQA活动要自始至有计划的进行
• 审查软件产品和活动是否遵守适用的标准、规程和要求并得到客观验证。
• SQA的活动和结果要保证全员参与，沟通顺畅。
• 逐级解决不符合问题

 

1.2  SQA活动

 

• 技术方法的应用
• 正式技术评审的实施
• 软件测试
• 标准的执行
• 修改的控制
• 度量
• 质量记录和记录保存

 1.3  SQA活动的影响因素

 

• 知识结构：专业的技术，例如质量管理与控制知识、统计学知识等。
• 经验
• 依据：如果没有这些标准，就无法准确地判断开发活动中的问题，容易引发不必要的争论，因此组织应当建立文档化的开发标准和规程。
• 全员参与：全员参与至关重要，高层管理者必须重视软件质量保证活动。
• 把握重点：一定要抓住问题的重点与本质，尽可能避免陷入对细节的争论之中。

1.4  SQA 策略

 

SQA策略主要分三个阶段：

1. 以检测为重：产品制成之后进行检测，只能判断产品质量，不能提高产品质量。
2. 以过程管理为重：把质量的保证工作重点放在过程管理上，对制造过程中的每一道工序都要进行质量控制。
3. 以新产品开发为重：在新产品的开发设计阶段，采取强有力的措施来消灭由于设计原因而产生的质量隐患。

 

1.5  SQA与软件测试的关系

• SQA 是管理工作、审查对象是流程、强调以预防为主
• 测试是技术工作、测试对象是产品、主要是以事后检查
• SQA指导测试、监控测试
• 测试为SQA提供依据

 

 

2. 测试策略

 

2.1  测试策略的概念

 

 

测试策略通常是描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试（如单元测试、集成测试、系统测试）以及每个阶段内进行的测试种类（如功能测试、性能测试、压力测试等），以确定合理的测试方案使得测试更有效。 

 

 

2.2  影响测试策略的因素

 

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


2、资源状况

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

 

 

2.3  制定测试策略

1.  全面细致地了解产品的项目信息:应用领域,测试范围,市场需求,产品的特点和主要功能,技术架构
2.  基于模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素对产品的影响,公正客观地开展测试计划
3.  根据程序的重要性和一旦发生故障将造成的损失,来确定它的测试等级和测试重点
4.  认真研究测试策略,以便能使用尽可能少的有效测试用例,发现尽可能多的程序错误,因为一次完整的软件测试过后,如果程序中遗漏的错误过多并且很严重,则表明本次测试是失败的,是不足的;而测试不足意味着让用户承担隐藏错误带来的危险.同时反过来说,如果过度测试,则又会浪费许多宝贵的资源. 找到一个最佳平衡点。

 

2.4  测试范围的确立

 

• 优先级最高的需求功能
• 新功能和编码改动较大(提高性能表现)的旧功能
• 运用有效的测试技术去提高测试效果
• 经常容易出现问题部分的功能 
• 一些经常被用户使用的功能和配置

 

2.5  测试持续阶段的确定

 

 

当测试任务明确后,测试计划将依赖于测试小组的人力资源而最终确定.

 

2.6 通过/失败的标准

 

• 单个的测试通过/失败  ---> 测试用例
• 全部产品测试通过/失败  --->     每个阶段的通过/失败

2.7  测试周期

 

2.8   阶段通过/失败的标准 

 

2.9  评估

 

2.9.1  风险评估

 

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

 

2.9.2  测试评估

 

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

•   里程碑                    日期
•   测试计划完成            --- 1/15
•   测试用例完成            --- 1/29
•   功能验证完成器           --- 2/5
•   代码冻结前完成系统测试    -- 2/20
•   版本发布前完成确认测试    ---2/28

 

 

3.  测试计划

 

3.1  测试计划的创建和评审

 

 3.2  测试计划内容构成

 

测试计划制定的第一步就是将软件分解较小而且相对独立的功能模块，写成测试需求。
测试需求有很多分类方法，最普通的一种就是按照功能分类：

•  测试需求是测试设计和开发测试用例的基础，分解功能模块可以更好地进行设计；
•  详细的测试需求是用来衡量测试覆盖率的重要指标；
•  测试需求包括各种测试实际和开发以及所需资源。

一个测试计划应包括：产品基本情况、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等。

 

3.3  测试计划标准格式 

 

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 (测试任务
11. Environmental needs （必备的环境)
12. Responsibilities (职责)
13. Staffing and training needs (人员和必需的培训)
14. Schedule (时间进度表)
15. Risk and contingencies (风险和相关费用）
16. Approvals （批准)

4.软件质量的可靠性评估

 

4.1  软件可靠性评估的概述

 

 

软件可靠性评估（Software Reliability Assessment）指根据软件系统可靠性结构（单元与系统间可靠性关系）、寿命类型和各单元的可靠性试验信息，利用概率统计方法，评估出系统的可靠性特征量。


软件可靠性评估的要素 
1）规定的时间
2）规定的环境条件
3）规定的功能

 

4.2  软件可靠性模型 

 

软件可靠性模型（Software reliability model）是指为预计或估算软件的可靠性所建立的可靠性结构和数学模型。建立可靠性模型是为了将复杂系统的可靠性逐级分解为简单系统的可靠性，以便于定量预计、分配、估算和评价复杂系统的可靠性。


1）可靠性结构模型，是依据系统结构逻辑关系，对系统的可靠性特征及其发展变化规律做出可靠性评价。

2）可靠性预计模型，是用来描述软件失效与软件缺陷的关系，借助这类模型，可以对软件的可靠性特征做出定量的预计或评估。依据软件缺陷与运行剖面数据，利用统计学原理建立二者之间的数学关系，获取开发过程中可靠性变化、软件在预定工作时间的可靠度、软件在任意时刻发生的失效数的平均值以及软件在规定时间间隔内发生失效次数的平均值。 

 

4.3  可靠性评估过程

 

可靠性数据收集 
用时间定义的软件可靠性数据可以分为四类：

• 失效时间数据，记录发生一次失效所累积经历的时间；
• 失效间隔时间数据，记录本次失效与上一次失效间的间隔时间；
• 分组数据，记录某个时间区内发生了多少次失效；
• 分组时间内的累积失效数，记录某个区间内的累积失效数。这四类数据可以互相转化。

1. 1. 测试时间；
   2. 含有测试用例的测试计划或测试说明； 
   3. 所有与测试有关的测试结果，包括所有测试时发生的故障；
   4. 参与测试的个人身份。