概要（包含但不限于）
- 软件测试的基本概念、目的、意义、方式方法等基础概念
1.1基本概念：
- [IEEE]软件测试是使用人工或自动手段来运行或测定某个系统的过程，检验它是否满足规定的需求或者弄清预期结果与实际结果之间的差别。
- 测试是程序的执行过程
- 软件测试是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。
1.2目的：
*最终目的是建立一个高可靠性的软件系统的一部分。
测试是程序的执行过程，目的在于发现错误；
测试是为了证明程序有错，而不是证明程序无错误。
一个好的测试用例在于能发现至今未发现的错误；
一个成功的测试是发现了至今未发现的错误的测试。
- 站在不同的立场，软件测试的目的也不同。
从用户角度出发，希望通过软件测试暴露软件隐藏的错误和缺陷，从而考虑是否可接受该产品。
从软件开发者角度出发，希望表明软件产品不存在错误，验证该软件能正确地实现用户需求，确立人们对软件质量的信心。
从软件管理者角度出发，希望花费有限的资源达到该软件用户的质量要求
- 总目标是充分利用有限的人力和物力资源，高效率、高质量地进行测试。
1.3意义：
测试是程序的执行过程，目的在于发现错误（猜的）
1.4方式方法：
1. 静态方法和动态方法
2. 黑盒测试、白盒测试和灰盒测试
3. 基于软件开发阶段的测试方法：需求测试、单元测试、集成测试、性能测试、压力测试、容量测试、配置测试、回归测试、安装测试、安全性测试
4. 自动化：白盒测试工具、功能测试工具、负载压力测试工具、测试管理工具
1.5软件测试有哪些：
按测试技术
软件测试可分为白盒测试和黑盒测试两种。
按测试方式
软件测试可分为静态测试与动态测试两种。
按测试阶段
软件测试可以分为单元测试、集成测试、确认测试、系统测试和验收测试。
按测试内容
按照测试内容可以分为功能测试、压力测试、性能测试、可靠性测试、安全性测试、兼容性测试、安装测试、灾难性恢复测试、回归测试等。
2.1定义
定义1（ISO）：
反映实体（可单独描述和研究的事物，如活动、过程、产品、组织、体系或人，以及它们各项的任何组合）满足明确和隐含需要能力的特性组合。
定义2（IEEE）：
a) 系统、部件或者过程满足规定需求的程度。
b) 系统、部件或者过程满足顾客或者用户需要或期望的程度。
c) 该定义相对客观，强调了产品（或服务）和客户/社会需求的一致性。
2.2从不同的层面或角度对质量就有着不同的理解。
从用户出发的质量观：质量是产品满足使用目的的程度。
以产品为中心的质量观：质量是软件的内在特征。
生产者的质量观：质量是产品性能符合规格要求的程度。
以价值为基准的质量观：质量依赖于顾客愿意付给产品报酬的数量
质量核心是：满足用户需求
2.3影响软件质量的因素：人、过程和技术
2.4软件质量因素
功能性：软件实现的功能达到要求的和隐含的用户需求以及设计规范的程度，
可靠性：软件在指定条件和特定时间段内维持性能的能力程度，
易使用性：用户使用该软件所付出的学习精力，
效率：在指定条件下，软件功能与所占用资源之间的比值，
可维护性：当发现错误、运行环境改变或客户需求改变时，程序能修改的容易程度，
可移植性：将软件从一种环境移入另一种环境的容易程度。
2.5补充：
外部用户是实际使用者，内部用户是下一道工序的接收者
- 软件质量保证的相关内容与定义、能力成熟度模型
3.1相关内容：
- 软件质量保证目的是使软件过程对于管理人员来说是可见的。
- 通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。
- （2.1.2）（1）SQA过程；
（2）具体的质量保证和质量控制任务（包括技术评审和多层次测试策略）；
（3）有效的软件工程实践（方法和工具）；
（4）对所有软件工作产品及其变更的控制；
（5）保证符合软件开发标准的规程（当适用时）；
（6）测量和报告机制。
在恰当的时间以正确的方式做正确的事情
3.2定义：
- 软件质量保证（SQA）是一种应用于整个软件过程的保护性活动，包括：一种质量管理方法、有效的软件工程技术（方法和工具）、在整个软件过程中采用的正式技术复审、一种多层次的测试策略、对软件文档及其修改的控制、保证软件遵从软件开发标准的规程、度量和报告机制。
- [IEEE]软件质量保证（SQA）是：
一种有计划的，系统化的行动模式，它是为项目或者产品符合己有技术需求提供充分信任所必需的。也可以说软件质量保证是设计用来评价开发或者制造产品过程的一组活动，这组活动贯穿于软件生产的各个阶段即整个生存周期。
设计用来评价开发或者制造产品的过程的一组活动，与质量控制有区别。
- 软件质量保证是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。
- 软件质量保证（Software Quality Assurance，SQA）和一般的质量保证一样，是确保软件产品从诞生到消亡为止的所有阶段的质量的活动，即确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动。
3.3目的：
目的是使软件过程对于管理人员来说是可见的。
3.4CMM（能力成熟度模型）：
3.4.1定义
是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述
3.4.2CMM的核心
是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。
- 软件度量与可靠性的概念，软件重用的概念
4.1软件度量相关概念：
4.1.1.定义
测量使得管理者和开发者能够改善软件过程；辅助软件项目的计划、跟踪及控制；评估产生的产品（软件）的质量。
4.1.2软件过程度量概念：
软件过程度量是对软件过程进行度量的定义、方法、活动和结果的集合。
软件过程度量不是单一的活动而是一组活动的集合，它本身也是一个系统的过程。
4.1.3软件度量作用：
通过软件度量增加理解；
通过软件度量管理软件项目，主要是计划和估算、跟踪和确认；
通过软件度量指导软件过程改善，主要是理解、评估和包装。软件度量对于不同的实施对象，具有不同的效用。
4.1.4软件过程度量活动：
选择和定义度量、制定度量计划、收集数据、执行度量分析、评估过程性能、根据评估结果采取相应措施
4.5可靠性相关概念：
4.5.1定义：
在规定的条件下，在规定的时间内，软件不引起系统失效的概率。该概率是系统输入和系统使用的函数，也是软件中存在的错误的函数；系统输入将确定是否会遇到已存在的错误（如果错误存在的话）；
注：
软件可靠性是指在规定的条件下和规定的时间内，软件不引起系统故障的能力。
软件可靠性不但与软件中存在的缺陷有关，而且与系统输入和系统使用有关。
软件可靠性是软件质量特性中重要的固有特性和关键因素。
软件可靠性反映了用户的质量观点。
4.6软件重用概念：
软件重用不仅仅是指软件本身，也可以是软件的开发思想方法、文档，甚至环境、数据等，包括三个方面内容的重用：
开发过程重用，指开发规范、各种开发方法、工具和标准等。
软件构件重用，指文档、程序和数据等。
知识重用，如相关领域专业知识的重用。
- 黑盒与白盒测试的基本概念、方法
5.1黑盒测试
5.1.1定义：
- 黑盒测试又称为数据驱动测试、基于规格的测试、输入/输出测试或者功能测试。
- 黑盒测试基于产品功能规格说明书，从用户角度针对产品特定的功能和特性进行验证活动，确认每个功能是否得到完整实现，用户能否正常使用这些功能。
5.1.2方法：
等价类的划分、边界值分析、因果图（鱼骨图）、决策表
5.2白盒测试
5.2.1定义：
- 白盒测试把测试对象看做一个透明的白盒子，允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序内部的变量状态、逻辑结构、执行路径进行测试。
- 白盒测试又称为结构测试、逻辑驱动测试或基于代码测试。
5.1.2方法：
各种逻辑覆盖、过程测试
- 软件测试中各阶段测试的基本概念、使用测试方法的原则
6.1基本概念
软件测试可以分为单元测试、集成测试、确认测试、系统测试和验收测试。
单元测试：单元测试就是验证软件单元的实现是否和该单元的说明完全一致的相关联的测试活动组成的。
集成测试：集成测试是在单元测试的基础上，将多个模块组合在一起进行测试的过程，主要检查各个软件单元之间的相互接口是否正确。
确认测试：又称为合格性测试，用来检验软件是否符合用户的需求。
系统测试：系统测试是指将通过集成测试的软件系统，作为计算机系统的一个重要组成部分，与计算机硬件、外设、某些支撑软件的系统等其他系统元素组合在一起所进行的测试，目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或矛盾的地方。
验收测试：验收测试主要根据用户的需求而建立，是整个测试过程中的最后一个阶段。
6.2原则：
- 在整个开发过程中要尽早地和不断地进行软件测试。
- 在开始测试时，不应默认程序中不存在错误。
- 设计测试用例时，要给出测试的预期结果。
- 测试工作应避免由系统开发人员或开发机构本身来承担。
- 对合理的和不合理的输入数据都要进行测试。
- 重点测试错误群集的程序区段(缺陷集群性)。
- 除检查程序功能是否完备外，还要检查程序功能是否有多余。
- 用穷举测试是不可能的。
- 长期完整保留所有的测试用例和测试文件，直至该软件产品被废弃为止。
- 杀虫剂悖论
- 测试依赖于测试背景
- 没有失效就是有用系统是一种谬论
- 全面质量管理的概念，方法，相关技术。
7.1相关概念：
全面质量管理（Total Quality Management，TQM）是一个组织以质量为中心，以全员参与为基础，目的在于通过让顾客满意和本组织所有成员及社会受益而达到长期成功的一种质量管理模式。
核心思想（全员性、全过程性、全面性）
7.2方法：
全面质量管理最重要的方法是PDCA循环，最早由美国质量管理专家戴明提出来的，所以又称为“戴明环”。P（Plan）计划；D（Do)执行；C（Check)检查；A（Action)处理，它反映了质量工作过程的4个阶段，通过4个阶段循环不断地改善质量。
七种工具是指在质量管理中广泛应用的统计分析表、分层法、散布图、因果图、控制图、直方图、帕累托图。大多使用数理统计方法，以从生产中收集到的数据为依据，适于过程的分析和控制。
7.3相关技术：
软件质量控制技术是为解决软件的实际问题而产生的。列出一系列由买主或客户及开发者在软件质量控制过程中经常遇到的一些问题及解决问题涉及的质量控制技术。
1.全面软件质量控制技术
2.在此基础上，介绍了6σ管理和零缺陷，并介绍了6σ设计流程和主要设计工具。6σ管理法是一种统计评估法，核心是追求零缺陷生产，防范产品责任风险，降低成本，提高生产率和市场占有率，提高顾客满意度和忠诚度。
- 软件缺陷的定义，类型，管理方法等
8.1定义：
软件缺陷是指从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背（IEEE729）。
8.2类型：
-
- 功能错误：以需求说明书为参照，未达到或未完成需求说明书所描述的功能即为功能错误。
- 编码错误：在系统运行中出现各类系统报错以及死机、不能工作、没有反应的现象即为编码错误。
- 数据错误：系统中各类查询数据、插入数据、更新数据时出现的数据库中表结构、视图、索引等不正确引起的错误。
- 可操作性错误：可操作性、应用方面的错误。
- 界面问题：窗口个控件布局、字体显示等不美观，界面、信息提示不友好、不准确等。
- 组件错误：测试创建组件产生的错误。
- 其它错误：各类文档、帮助的错误。
8.3管理方法：
- 处于CMM一级（或称为初始级）的软件组织，对软件缺陷的管理无章可循。工程师们只是在发现缺陷后，修改相应的软件。而且，只有在下一轮测试中才有可能知道那些所谓己被纠正了的缺陷是否真的被纠正了，更重要的是纠正过程是否引入了新的缺陷。所以这样的软件组织的项目交货期表现出强烈的不可预测性。并且，为了获得一个高质量的软件产品（如果能够的话），通常要在测试上花费大量的人力。
- 在 CMM 二级（或称为可重复级）的软件组织中，软件项目会从自身的需要出发，制定本项目的缺陷管理过程。
一个完备软件缺陷管理过程通常会包括如下几个方面：提交缺陷、分析和定位缺陷；提请修改相应的软件；修改相应的软件；验证修改。
项目组会完整地记录开发过程中的缺陷，监控缺陷的修改过程，并验证修改缺陷的结果。
- CMM 三级（或称为己定义级）的软件组织会汇集组织内部以前项目的经验教训，制定组织级的缺陷管理过程。并且，要求项目根据组织级的缺陷管理过程定制本项目的缺陷管理过程。
- 从而，整个软件组织中的项目都遵循类似的过程来管理缺陷。
- 好的缺陷管理实践成为所有项目的实践，而教训也为所有项目所了解。
更重要的是，随着组织的不断发展完善，组织的过程会得到持续性的改进，所有项目的过程也都会相应的改进。
- 定量管理级
- 持续优化级
- 报告软件缺陷
一个完整的软件缺陷信息除了包含软件缺陷类型、等级和优先级外还需要其它一些属性，如缺陷标识、缺陷产生可能性、缺陷来源等。
- 软件配置管理的概念
9.1定义：
软件配置管理是贯穿于整个软件过程中的保护性活动，它被设计来：
标识变化；
控制变化；
保证变化被适当地实现；
向其他可能有兴趣的人员报告变化。
软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性。
9.2基本目标
软件配置管理的各项工作是有计划进行的。
被选择的项目产品得到识别，控制并且可以被相关人员获取。
已识别出的项目产品的更改得到控制。
使相关组别和个人及时了解软件基准的状态和内容。
- 评审的几种形式（静态测试技术）
10.1定义：
评审（Review）是指对产品或产品状态进行评估，以确定与计划的结果所存在的误差，并提供改进建议。
10.2软件评审的主要好处：
尽早发现和修改软件缺陷、改善开发能力、缩短开发时间、缩减测试成本和时间、减少产品生命周期成本、减少软件缺陷以及改善和开发人员之间的沟通等。评审可以在工作产品中发现一些遗漏的、冗长的内容，这在动态测试中是很难发现的。
10.3评审的几种形式：
按照评审过程的正式程度、严格程度可以将评审分为非正式评审和正式评审。
非正式评审包括桌面审查、走廊聊天、伙伴测试或者结对编程等；
正式评审又可以分为管理评审、技术评审、审查、走查和审计等
- 等价类、边界值、决策表与因果图
11.1等价类
- 等价类划分法是一种黒盒测试的技术，不考虑程序的内部结构，是把所有可能的输入数据，即程序的输入域划分成尽可能少的若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。
- 该方法是一种重要的，常用的黑盒测试用例设计方法。
- 每个子域构成输入域的一个划分，每个子域称为一个等价类
11.2边界值
11.3决策表
决策表又称为判定表，用于分析多种逻辑条件下执行不同操作的技术。
11.4因果图
因果图，也称作依赖关系模型，主要用于描述软件输入条件（即“原因”）与软件输出结果（即“结果”）之间的依赖关系。因果图可以直观地表示各种依赖关系。
- 各种逻辑覆盖，路径测试
12.1逻辑覆盖
语句覆盖：在测试时首先设计若干个测试用例，然后运行被测程序，使程序中的每个可执行语句至少执行一次。这里所谓“若干个”，自然是越少越好。
判定覆盖：设计若干测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断的真假值均曾被满足
条件覆盖：设计若干测试用例，执行被测程序后，使每个判定中每个条件的可能取值至少满足一次。
判定-条件覆盖：要求设计足够的测试用例，使得判定中的每个条件的所有可能的结果至少出现一次，并且每个判定的所有可能的结果至少执行一次
条件组合覆盖（多重条件覆盖）：设计足够多的测试用例，使得判定中每个条件的所有可能组合至少出现一次。要求这些结果的所有可能组合都至少出现一次。
路径覆盖：设计足够多的测试用例要求覆盖程序中所有可能的路径。
从底向上由弱到强：
12.2路径测试
12.2.1 DD路径（Decision to Decision Paths）是决策到决策的路径。所谓决策，是指一个序列语句，其开始位置是一个判定（决策）语句的开始，结束位置是下一个判定（决策）语句的开始，并且序列语句没有分支。
12.2.2基路径测试
基路径是指将所有程序的路径作为一个集合。在这些路径当中必然存在一个最小路径的集合
详细步骤
步骤1：以详细设计或源代码作为基础，画出标准的流程图，然后导出程序的控制流图。
步骤2：计算控制流图G的圈复杂度V(G)。
步骤3：确定基（独立）路径的集合，即确定线性无关的路径的基本集。
步骤4：生成测试用例，确保基本路径集中每条路径的执行。
控制流图G的圈复杂度V( G)定义为：
方法1：V(G) =E -N+2，其中，E是控制流图G中边的数量，N是控制流图G中节点的数量。
方法2：将圈复杂度定义为控制流图G中的区域数。
方法3：V(G)=P+1，P是流图G中判定（谓词）节点的数量。
到此这篇软件质量保证与测试期末复习整理_软件质量保证与测试知识点的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/csyzlbz/7949.html