软件质量保证——概述

笔记内容及图片整理自XJTUSE “软件质量保证” 课程ppt，仅供学习交流使用，谢谢。

软件缺陷

软件开发问题

1）需求发生变动

2）模块未集成

3）维护困难

4）缺陷发现较晚

5）用户体验差

6）负载下性能差

7）团队协调性差

8）构建和发布问题

软件工程实践

软件工程实践之间相辅相成，它们通过解决问题的根本原因来指导软件开发。

类型

1）迭代开发

2）管理需求

3）使用组件架构

4）UML可视化建模

5）持续验证质量

6）管理变更

软件工程进程

软件工程进程负责实施软件工程实践，它能为高质量的软件开发提供指导方针，降低风险，增加可预测性，促进共同愿景和文化，并将软件工程实践制度化。

软件工程进程指导团队在何时以及如何做什么，它也为实施软件工程实践提供背景和支持。

软件缺陷有关术语

错误（Error）

指人们在开发软件过程中发生的过错，这是一种人为的过程，对于软件本身来讲是一种外部行为，且在全生命周期的任何一个环节都可能出错。

1）客户未完全描述清楚他的意图

2）分析人员未完全理解客户的需求从而编写出不完善的需求文档

3）设计人员未完全弄清楚需求文档描述的问题;

4）实现人员受限于自身能力及工作状态编写出不完善的程序

缺陷（Defect）

指错误在程序中的表现，这存在于软件(文档、数据及程序)之中的那些不希望或不可接受的偏差，其结果是当缺陷被激活时，便会发生软件故障。缺陷是造成软件故障甚至发生失效的内在原因，也即我们常说的“Bug”。

故障（Fault）

指软件运行过程中出现的不希望或不可接受的内部状态，这是一种状态行为，通常代表软件丧失在规定的限度内执行功能的能力。故障可能动态导致外部失效，是软件缺陷的内在表现。

失效（Failure）

软件运行时产生的不希望/不可接受的外部行为结果;

系统行为对用户预期的偏离;

失效是软件缺陷的外在表现，只有运行中的软件才可能发生失效

失效可能会带来事故

人为错误——软件缺陷—（运行）—内部故障+外部失效

软件缺陷判定规则

1）软件未实现需求规格说明书要求的功能

2）软件出现了需求规格说明书指明不应该出现的错误

3）软件实现了需求规格说明书中未提到的功能

4）软件未实现需求规格说明书虽未明确提及但应该实现的功能

5）软件难以理解、不易使用、运行缓慢等，即用户体验不佳

软件缺陷产生原因

1）需求规格说明书问题——大多数的软件缺陷来自于需求规格说明书

2）团队协作问题——现代软件规模大、开发周期端、干系人众多，不可避免导致协作问题

3）未考虑复杂应用场景——只保证软件基本操作，未考虑特殊情况

4）技术方面问题——开发人员技术局限、技术不成熟、需求难以满足……

软件质量与质量保证

软件质量

质量：反映实体（可单独描述和研究的事物，如活动、组织、产品、人以及它们的任何组合）满足明确和隐含需求能力的特性组合，是一个与用户有密切关系的复杂多维度概念。

质量维度：功能性、易用性、可靠性、性能、可支持性

软件质量：软件产品中能满足规定的和隐含的与需求有关的全部特征和特性，具体由用户所关注的质量特性来决定。

软件质量保证

软件质量保证是确保软件产品自诞生起到消亡止的全生命周期的质量活动，即确定、达到和维护需要的软件质量高而进行的所有有计划的系统性管理活动。

目标

1）保证软件及其维护符合功能与技术需求

2）保证软件及其维护符合管理需求，时间和费用都在预算内

3）组织一些活动来改进软件开发效率和维护效率，并进一步优化SQA活动

方面

1）项目前的质量活动——确认用户需求、资源需求、项目规划、开发计划、质量计划等

2）软件生命周期中的质量活动——开发阶段和运维阶段的评审、软件测试、软件维护等

3）基础设施方面的质量活动——需要工作模板、检查清单、员工培训等基础设施做支撑

4）管理方面的质量活动——贯穿软件项目生命周期的进度管理、人员管理、成本维护等

5）基于软件质量标准——采用相关专业国际标准以保证项目成功且易被其他组织所接受

6）基于SQA自身考虑——贯穿生命周期用质量保证来尽量软件产品能够满足用户要求

软件测试概念

狭义上，软件测试是为了发现错误而执行程序的过程。

广义上，软件测试是一个过程或一系列过程，贯穿软件开发过程中的所有评审、确认、检验等活动，旨在确保计算机代码执行其设计目的，而不会做其他意外的事情。

进一步讲，软件测试是由特定测试团队执行的正式过程，其中通过在计算机上运行测试程序来检验一个软件单元、多个集成的软件单元或整个软件包。所有测试工作均按照预先计划的测试过程来执行计划的测试用例。

广义上的软件测试更关注产品，软件质量保证更关注过程，目的都是全面改进软件质量。

软件测试模型

V模型

V模式即快速应用开发模型，是瀑布模型的变种，反映了测试活动与分析设计等开发活动的关系。其中测试活动被分成单元测试、集成测试、系统测试和验收测试。

单元测试对应详细设计，主要针对源码测试，通常由开发人员执行检查自己编写的程序。

集成测试对应概要设计，涉及多个单元综合在一起测试，重点检查单元间接口是否一致。

系统测试对应需求分析与系统设计，针对整个软件系统测试，检验其是否满足用户需求。

验收测试对应用户需求，通常是由用户主导的测试以检验软件表现是否符合用户的预期。

W模型

W模型也称双V模型，将开发过程和测试过程分别细化为V模型。它基于尽早地和不断地进行测试的原则，在软件开发各个阶段增加了验证和确认活动，相比V模型测试更早介入。

验证是指开发人员是否在正确地做事情，强调过程的正确性，不仅检验当前阶段是否正确，还检验当前阶段是否与上一阶段相一致。

确认是指开发人员是否在做正确的事情，强调结果的正确性，不仅检验当前阶段是否正确，还检验当前阶段的工作是否与用户的需求相一致。

软件测试分类

按设计方法分类

黑盒测试——依据软件需求规格说明书，不关心软件代码的编程语言和组织结构

白盒测试——也称为透明盒测试，基于程序代码

灰盒测试——黑盒测试与白盒测试相结合，不仅关注程序输入输出，也关注程序内部表现，比如使用黑盒开发测试用例，再使用白盒开发补充测试用例

按阶段分类

单元测试——针对单个程序单元，以白盒为主

集成测试——针对多个通过单元测试的程序单元综合在一起测试，以黑盒为主，白盒为辅

系统测试——针对通过集成测试的所有程序单元综合在一起测试，基本是黑盒测试

验收测试——用户主导的测试，目的是检验所交付成果是否满足最终需求，基本是黑盒测试

按是否运行软件分类

静态测试——不需要执行被测软件而进行的测试活动，往往能发现大量基本错误

动态测试——实际执行软件的测试活动，通常能发现一些难以被静态测试发现的深层次错误

按测试执行者分类

人工测试——测试工作由人逐个完成，效率低下但能执行探索性测试等计算机无法执行的

自动化测试——测试工作由计算机自动完成，效率较高但不具备思维能力和探索能力

按需求分类

功能性测试——基于软件需求规格说明书进行测试，验证其是否实现了所期望的每个功能

非功能性测试——除功能性测试之外的其他系统级别的测试

按测试对象分类

1）桌面程序测试

2）嵌入式软件测试

3）Web程序测试

4）移动App测试

软件测试用例及原则

软件测试用例

穷尽性测试考虑软件所有的输入组合或考虑程序所有的执行路径，当所有的输入组合或执行路径被确认无误后，便能认为软件是高质量的。

然而现实中实现穷尽性测试并不现实，无论穷尽性黑盒还是穷尽性白盒，比如黑盒中自变量是double类型的三角函数无法完成穷举，白盒中20次循环便能最多带来约1万亿条路径。

软件测试原则

1）尽早且持续测试——错误可能在软件项目全生命周期的任何环节被引入

2）全面测试——除了测试程序的代码，还要测试文档和数据

3）测试用例应该包括输入和预期输出两部分——输入和预期输出结合起来才能检验正确性

4）程序员及开发团队应避免测试自己的程序——人类思维具有盲点，他人测试更有效客观

5）Pareto原则——群集现象：80%错误可能存在20%代码中，对错误倾向高的模块严格测试

6）既要测试程序是否完成了该做的，还要确定程序是否做了不该做的——应对异常情况

7）穷尽性测试不现实——需要设计合适且充分的测试用例尽可能达成穷尽性测试的效果

8）全面检查每个测试结果——多人认真检查便于尽可能多的发现软件中存在的缺陷

9）妥善保存测试资产——测试资产可能被多次使用，妥善保存维护它们能提高测试效率

10）测试是一项富有挑战性的工作——测试人员要采用不同方法和技术发现程序中的缺陷