1、软价质量保证

1.1 软件质量

质量控制QC：QUALITY CONTROL

• 定义：审查产品相关的各个方面质量的过程
• 内容：
  1. 元素:过程控制、作业管理等；
  2. 能力:知识、技能、经验和资历等；
  3. 软要素:人员廉正、文化、团队合作等
• 目标：建立体系井确保体系按要求运作,以提供内外部的信任。

质量保证QA:QUALITY ASSURANCE

• 定义：系统监控和评估工程的各个方面，最大限度提高质量最低标准
• 内容：原料、文档、产品和组件，以及涉及产品的管理、生产和检测过程等质量管理
• 目标：
  1. 适合用途：该产品应符合预期的目标
  2. 一次成功：错误应该被淘汰

质量成本

追求质量过程或在履行质量有关活动中引起的费用以及质量不佳引起的下游费用等所有费用。分为：

1. 预防成本：质量计划和协调等管理活动；需求、设计模型开发成本；测试计划的成本；相关培训成本
2. 评估成本：技术审查成本；数据收集和度量估算成本；测试和调试成本
3. 失效成本：内部失效成本，交付前发现错误的成本，返工、修复故障模式分析；外部失效成本，交付后发现缺陷的成本；投诉、退换、帮助作业支持、保修。

软件质量

明确表示是否符合功能和性能要求，明确地记载开发标准和所有专业开发软件的期望的隐性特点。关键点如下：

1. 符合明确规定的功能和性能要求；
2. 符合明确的开发标准；
3. 符合所有软件开发专业的共性、隐性标准，如易用性、可维护性等。

软件质量保证

软件质量保证(SQA)：遵照一定的软件生产标准、过程和步骤对软件质量进行评估的活动。

1. 审查。评审既定标准是否得到遵守。如IEEE、ISO、GBTT等。
2. 监督。对比文档中描述的执行和实际操作步强，确保执行过程采取适当步骤和操作方式。
3. 审计。确保开发过程使用了恰当的质量控制措施，以符合相应的标准或过程。
   

1.2 软件评审

一个过程或会议期间进行的软件产品的审核，由项目人员、管理人员，用户客户、用户代表或其他有关各方对一个软件产品进行评论或批准。
软件评审常见形式：

1. 同行评审。同行评估产品技术的含量和质量。
2. 管理评审。管理人员代表评估当前工作，决定后续安排。
3. 审计评审。外部人员评估软件产品的规范性、标准化程度、合同履行情况等。

1.3 软件可靠性

软件可靠性是指在给定时间内，特定环境下软件无错运行的概率。

2、软件测试

2.1 软件测试过程模型

软件测试策略

软件测试策略：为软件开发人员、质量保证组织、和客户提供一个路线图。规定了测试的主要步骤。
为保证可行性，须考虑人力成本、时间和资源。故应结合：测试计划、测试用例设计、测试执行、测试结果数据的收集和分析。

• 要求
  1. 灵活性：由足够的可塑性来应付所有的大软件系统。
  2. 严格：保证对项目进程进行合理的计划和跟踪管理。

软件测试策略V模型

V模型非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间个阶段对应关系。

1. 单元测试。主要目的是验证软件模块是否按详细设计的规格说明正确运行。
2. 集成测试。主要目的是检查多个模块间是否按概要设计说明的方式协同工作。
3. 系统测试。主要目的是验证整个系统是否满足需求规格说明。
4. 验收测试。从用户的角度检查系统是否满足合同中定义的需求，以及以确认产品是否能符合业务上的需要。

回归测试

回归测试可以在所有的测试级别执行，并应用于功能和非功能测试中。可应用于：

1. 缺陷再测试：重新运行所有发现故障的测试，而新的软件版本已经修正了这些故障。
2. 功能改变的测试：测试所有修改或修正过的程序部分。
3. 新功能测试：测试所有新集成的程序。
4. 完全回归测试：测试整个系统。

软件测试策略原则

1. 在着手开始测试之前，要对产品的需求进行量化。
2. 明确指出测试目标。
3. 为每类用户建立描述交互场录的用例。
4. 建立一个强调“快速循环测试”的测试计划。
5. 设计一个能够测试自身是否“强壮”的软件。
6. 在进行测试之前，对软件进行有效的正式技术审核。
7. 使用正式技术审核来评估测试策路和测试用例本身
8. 为测试过程建立一种持续的改进方法。
9. 应尽早并不断地进行测试。
10. 测试工作应该避免由原开发软件的人或小组承担。
11. 设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期输出结果。
12. 测试时还需要包含不合理、失效的输入数据。
13. 测试时不仅需要验证程序能做什么事，还需要确定程序不能做什么事。
14. 严格按照测试计划进行，避免测试的随意性。
15. 妥善保管测试计划、测试用例，作为软件文档的组成部分，为维护提供方便。
16. 测试用例都是精心设计的，可以为重新测试或追加测试提供方便。

软件测试策略基本步骤

软件测试工具

测试管理者、启示器、文件比较器、报告生成器、动态分析器、模拟器

2.2 单元测试

单元内涵：不同环境含义不同，面对过程：函数、过程等；面对对象：类、类中成员函数等。
单元测试：针对软件设计的最小单位：程序模块，进行正确性检验的测试工作。
测试方法：单元测试需要从程序的内部结构出发设计测试用例（测试的项目，需要测试的具体对象）。多个模块可以平行地独立进行单元测试。
主要依据：详细设计。

进入和退出条件（什么时候进行单元测试）

1. 被测代码编译链接通过
2. 被测代码静态检查工具检查通过
3. 已完成至少一轮代码检视或走读
4. 单元测试用例的检视通过
5. 单元测试代码写完并通过检测
6. 所用测试用例执行通过
7. 单元测试覆盖率达到预定要求
8. 单元测试未被执行的代码进行正式审查

测试内容

单元测试主要内容：模块接口、局部数据结构、边界条件、独立路径和出错处理。

测试用例设计

测试环境搭建

2.3 集成测试

含义：将软件集成起来后进行测试。别名：子系统测试、组装测试、部件测试等。
目的：检查诸如两个模块单独运行正常，但集成起来运行可能出现问题的情况。
主要方法：自顶向下的集成方法、自底向上的集成方法、SMOKE方法

自顶向下的集成方法

基本思想：该集成方式将模块按系统程序结构，沿控制层次自顶向下进行集成。

自底向上的集成方法

基本思想：从软件结构最底层的模块开始，按照接口依赖关系逐层向上集成以进行测试。

优点：每个模块调用其他底层模块都已经测试，不需要桩模块；
缺点：必须编写驱动模块；缺陷的隔离和定位不如自顶向下；
适用：底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。

实际工作中，常综合使用:自底向上、自顶向下。如:按进度选择优先测试已经完成的模块；if被测模块所调用的模块未完成，用自顶向下，打桩测试。if被测模块的上层模块未完成，用自底向上，模拟根模块。

SMOKE方法

• 基本思想：将已经转换为代码的软件构件集成为构造(build)。一个构造包括所有的数据文件、库、可复用的模块以及实现一个或多个产品功能所需的工程化构件。
• 目标：设计暴露影响构造正确地完成其功能的错误的测试。以发现极标自有可能造成项目延迟的业务阻塞错误。
• 方法：每天将该构造与其他构造，及整个软件产品集成，冒烟测试。两种方法:自顶向下，自底向上，均可。

测试用例的设计

失效性测试：边界值法、错误猜测法、因果图法、状态图法等；
通过性测试：等价类划分法、场景分析法、状态图法等；
覆盖率：接口覆盖率、接口路径覆盖率等；
注意接口：显性接口（函数调用API）接口，隐形接口（消息、网络协议等）

2.4 系统测试

• 含义：从用户使用的角度进行测试，将完成了集成测试的系统放在真实的运行环境下进行。软件开发过程必不可少的一环，软件质量保证的最重要环节。
• 目的：功能确认和验证。
• 测试方法：黑盒测试。
• 系统测试主要内容：功能测试、性能测试、压力测试、恢复测试、安全测试、配置测试、兼容性测试、本地化测试、文档测试和易用性测试等。

功能测试

性能测试

压力测试

• 压力测试:在系统运行环境不正常乃至发生故障的情况下，系统可以运行到何种程度的测试
• 测试方法：
  1. 把输入数据速率提高一个数量级，确定输入功能将如何响应
  2. 设计需要占用最大存储量或其它资源的测试用例进行测试。
  3. 设计出在虚拟存储管理机制中引起“颠簸”的测试用例进行测试。
  4. 设计出会对磁盘常驻内存的数据过度访问的测试用例进行测试。

敏感性测试：压力测试的一个变种。在程序有效数据界限内一个小范围内的一组数据可能引起极端的或不平稳的错误处理出现，或者导致极度的性能下降。

恢复测试

• 恢复测试:是要证实在克服硬件故障后，系统能否正常地继续进行工作，并不对系统造成任何损害。
• 手段:人工干预等
• 测试方法
  1. 错误探测功能–系统能否发现硬件失效与故障;
  2. 设备故障时，能否切换或启动备用的硬件;
  3. 故障发生时，能否保护正在运行的作业和系统状态;
  4. 系统恢复后，能否从最后记录下来的无错误状态开始继续执行作业等，
  5. 掉电测试:电源中断时，能否保护当时的状态且不毁坏数据，然后在电源恢复时从保留的断点处重新进行操作。

安全性测试

• 安全性测试:是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用，有无漏洞。
• 主要攻击方法：
  1. 攻击正面、侧面或背面攻击系统中易受损坏的那些部分;
  2. 以系统输入为突破口，利用输入的容错性进行正面攻击;
  3. 申请和占用过多的资源压垮系统，以破坏安全措施，从而进入系统;
  4. 故意使系统出错，利用系统恢复的过程，窃取用户口令及其它有用的信息;
  5. 通过浏览残留在计算机各种资源中的垃圾(无用信息)，以获取如口令，安全码，译码关键字等信息;
  6. 浏览全局数据，期望从中找到进入系统的关键字;
  7. 浏览逻辑上不存在，但物理上还存在的各种记录和资料等。

2.5 验收测试

时间节点：系统的有效性测试及软件配置审查通过之后；
人员组织：以用户为主，开发人员，质量保证人员；
测试数据：实际生产数据；
测试内容：功能和性能外可移植性、兼容性、可维护性、错误的恢复功能等。

验收测试过程

验收测试形式

• $\alpha$测试
  • 含义：用户在开发环境、模拟用户在实际操作环境下的测试。
  • 目的：评价FLURPS特性（功能、局域化、可使用性、可靠性、性能和支持），尤其界面和特色
  • 原因：交付后，用户的实际使用程序是无法预测的
  • 开始时间：编码结束后；模块（子系统）测试完成后；系统测试过程中产品达到一定的稳定和可靠程度后。
• $\beta$测试
  • 测试人员：多个用户在实际使用环境下进行测试，这些用户返回有关错误信息给开发者。
  • 测试形式：开发者通常不在测试现场，开发者无法控制的环境下进行的软件现场应用。
  • 测试步骤：用户记录所有问题(真实的、主现的)，定期向开发者报告。
  • 测试自标：产品的FLURPS，着重产品的支持性(文档、客户培训和支持产品生产能力）
  • 开始条件：a测试达到一定的可靠程度时开始，测试的最后阶段，所有手册文本此阶段完全定稿。

测试停止标准

• 测试团队：开发团队；开发团队中配备测试人员；项目团队中若干测试团队；独立测试专家；单独测试部门。
• 测试人员：测试经理；测试设计人员；测试自动化人员；测试管理员；测试人员。