软件开发+软件测试

lmnnnnnlin3

已于 2024-09-12 20:40:41 修改

阅读量1k

点赞数 18

文章标签：单元测试测试用例集成测试模块测试功能测试笔记

于 2024-09-12 20:37:09 首次发布

本文链接：https://blog.csdn.net/weixin_64449292/article/details/142173087

版权

测试方法：等价类划分法、边界值分析法、判定表/因果图法、正交实验法

一、软件开发的基本概念

1、什么是软件

软件是计算机系统中与硬件相互依存的一部分，包括程序、数据、与其相关文档的完整结合。

软件 = 程序 + 数据 + 文档

2、软件的分类

　按照功能划分：

　　　　系统软件：如操作系统、数据库管理系统，各种驱动软件等

　　　　应用软件：如Office、金山词霸、QQ等

　　按照技术结构划分：

　　　　单机版本：如Office，画图工具等

　　　　C/S结构软件：如QQ、MSN等

　　　　B/S结构软件：如新浪、搜狐、google等

　　按照用户划分：

　　　　产品软件：Office、财务处理软件、金山毒霸等

　　　　项目软件：如为企业定制的OA系统等

3、软件的生命周期及常见的开发模型

软件的生命周期——指软件产品从计划到软件交付使用，直到最终退出为止的过程。

包括计划阶段、分析阶段、实现阶段、测试阶段、运行维护阶段。

软件开发模型：

① 瀑布模型：严格遵循软件生命周期各阶段的固定顺序，一个阶段完成再进入另一阶段，适用于结构化开发方法。瀑布模型是文档驱动的。

传统的瀑布模型过于理想化了，瀑布模型是一种线性的开发模型，具有不可回溯性。

实际的瀑布模型是带“反馈环”的，如图所示：

瀑布模型适用于以下特征的软件开发项目：

（1）在软件开发的过程中，需求不发生或发生很少变化，并且开发人员可以一次性获取到全部需求。否则，由于瀑布模型较差的可回溯性，在后续阶段中需求经常性的变更需要付出高昂的代价。

（2）软件开发人员具有丰富的经验，对软件应用领域很熟悉。

（3）软件项目的风险较低。瀑布模型不具有完善的风险控制机制。

② 快速原型模型：开发人员对用户提出问题进行总结，就主要需求达成一致意见，快速地建立一个原型系统并运行，然后对原型进行反复修改，使之完善。

快速原型模型适用于具有以下特征的软件开发项目：

（1）已有产品或产品的原型( 样品)，只需客户化的工程项目。
（2）简单而熟悉的行业或领域。
（3）有快速原型开发工具。
（4）进行产品移植或升级

③ 增量模型：增量模型也称为渐增模型。增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。开发人员可以分批次将软件产品提交给用户。

增量模型适用于具有以下特征的软件开发项目:
（1）软件产品可以分批次地进行交付。

（2）待开发的软件系统能够被模块化。

（3）软件开发人员对应用领域不熟悉，难以一次性地进行系统开发。

（4）项目管理人员把握全局的水平较高。

④ 螺旋模型：螺旋模型是一种用于风险较大的大型软件项目开发的过程模型。该模型将瀑布模型与快速原型模型结合起来，并且加入了风险分析。它把开发过程分为制定计划、风险分析、实施工程、客户评估。

⑤ 喷泉模型：喷泉模型是一种过程模型，同时也支持面向对象开发。分析模型和设计模型采用相同的符号标示体系，各阶段之间没有明显的界限，而且常常重复、迭代地进行（“喷泉”一词体现了面向对象方法的迭代和无间隙性）。迭代是指各阶段需要多次重复，无间隙性是指各个阶段之间没有明显的界限，并常常在时间上互相交叉，并行进行。

4、软件的开发流程

需求分析、概要设计、详细设计、编码、测试

5、软件设计和开发方法

软件的设计原则：高内聚，低耦合

软件的设计工具：UML图：用例图、类图、协作图、顺序图、状态图、活动图

软件的开发方法：

结构化的方法

面向数据流的方法——概要设计阶段
面向数据结构的方法——详细设计阶段
面向对象的方法——系统设计、对象设计

二、软件测试的基本概念

1、什么是软件测试

使用人工或自动的手段，来运行或测试软件系统的过程，目的是检验软件系统是否满足规定的需求，并找出与预期结果之间的差异。(标准定义IEEE )

软件测试就是“验证（Verification）”和“有效性确认（Validation）”活动构成的整体，即软件测试V&V 。(标准观点)

概括起来，软件测试就是贯穿整个软件开发生命周期，对软件产品（包括阶段性产品）进行验证和确认的活动过程，其目的是尽快尽早地发现在软件的缺陷。

2、软件测试的目的

从用户角度看的目的：通过软件测试发现隐藏的错误和缺陷，考虑是否可以接受该产品。

从开发者角度看的目的：表明软件产品不存在错误，验证软件实现了所有用户的要求。

从测试人员角度看的目的：发现错误，预测错误，提供软件可靠性错误，对软件做出评价。

①　帮助开发人员、测试工程师发现问题、分析问题。

②　减少软件的缺陷数目或者降低软件缺陷的密度。

③　提高软件的可靠性

④　评估软件的性能指标。

⑤　增加用户对软件的信心。

⑥　测试的最终目的是尽快尽早地发现在软件中的缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。

3、软件测试的原则

所有的测试都应追溯到用户需求
应该尽早地和不断地进行软件测试——只要测试在生命周期中进行得足够早，就能够提高被测软件的质量，这就是预防性测试的基本原则
完全测试是不可能的，测试需要终止
测试不能显示软件潜在的缺陷
充分注意测试中的集群现象（二八定理）
程序员应避免检查自己写的程序
尽量避免测试的随意性

二八定理：一般情况下，80%软件缺陷出现在20%的功能区域，在测试过程中，投入主要的人力和精力重点测试这20%的功能区域。

4、软件测试的分类

每种测试的具体定义可以参考这篇博客：软件测试（理论基础） - LangZXG - 博客园 (cnblogs.com)

这里就简单列举出来。

5、软件测试的流程与阶段、

测试流程：需求分析、制定测试计划、编写测试用例、执行测试、编写测试报告

测试阶段：需求验证、单元测试、集成测试、确认测试、系统测试、验收测试

确认测试：检验所开发的软件是否满足SRD(System Requirement Document)中定义的需求、性能要求，以及软件配置是否完全正确。

6、测试用例

测试用例（TC）：

在测试执行之前设计的一套详细的测试方案，是描述输入实际值和预期输出行为或者结果的文档，同时也标识了测试过程、结果与约束。

编写测试用例的唯一标准就是用户需求，具体的参考资料是《需求规格说明书》。

测试用例的八大要素：

用例编号，所属模块，测试标题，重要级别，前置条件，测试输入，操作步骤，预期结果

测试用例的四个基本属性：

代表性：能够代表并覆盖各种合理的和不合理合法的和不合法的、边界的和越界的以及极限的输入数据、操作等。
针对性：对程序中的可能存在的错误有针对性地测试。
可判定性：测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。
可重现性：对同样的测试用例，系统的执行结果应当是相同的。

7、白盒测试

白盒测试又称为结构测试或逻辑驱动测试，它是把测试对象看成一个透明的盒子，它允许测试人员利用程序内部的逻辑结构设计测试用例，对程序所有逻辑路径进行测试。

采用白盒测试方法必须遵循以下原则：

保证一个模块中的所有独立路径至少被测试一次。
对所有的逻辑判定均需测试取真和取假两种情况。
在上下边界及可操作范围内运行所有循环。
检查程序的内部数据结构，保证其结构的有效性。

测试方法：静态测试方法、动态测试方法

静态测试：不要求在计算机上实际执行所测试的程序，主要以一些人工的模拟技术对软件进行分析和测试，如代码检查法、静态结构分析法等；

动态测试：是通过输入一组预先按照一定的测试准则构造实际数据来动态运行程序，达到发现程序错误的过程。白盒测试中的动态分析技术主要有逻辑覆盖法和基本路径测试法。

这里我们重点介绍动态测试。

动态测试

① 逻辑覆盖法

以程序内部的逻辑结构为基础来设计测试用例的测试技术，通过对程序内部的逻辑结构的遍历来实现程序的覆盖。

6种覆盖标准：

语句覆盖（SC）

设计足够的测试用例，使得被测程序中每条语句至少执行一次。又称行覆盖、段覆盖、基本块覆盖，它是最常见的覆盖方式，是一种弱覆盖

判定覆盖（DC）

又称为分支覆盖，其原则是设计足够的测试用例，使得程序中每个判定语句的取真和取假分支至少被执行一次。

条件覆盖（CC）

指的是设计足够的测试用例，使判定语句中的每个逻辑条件取真值与取假值至少出现一次。

条件分支覆盖的状态下仍旧不能满足判定覆盖

判定-条件覆盖（CDC）

设计足够的测试用例，使得判定语句中所有条件的可能取值至少出现一次，同时，所有判定语句的可能结果也至少出现一次。

条件组合覆盖（MCC）

设计足够的测试用例，使得每个判定中条件的各种可能组合都至少执行一次。

路径覆盖

设计足够的测试用例，使得程序中的每一条可能组合的路径都至少执行一次。

② 基本路径测试法

路径测试就是从一个程序的入口开始，执行所经历的各个语句的完整过程。从广义的角度讲，任何有关路径分析的测试都可以被称为路径测试。

完成路径测试的理想情况就是做到路径覆盖，但对于复杂性较大的程序要做到所有的路径覆盖（测试所有可执行路径）是不可能的。

在不能做到所有路径覆盖的情况下，如果某一程序的每一个独立路径都被执行到，那么就可以认为程序中的每个语句都已经检验过了，即达到了语句覆盖。这种测试方法就是通常所说的基本路径测试法。

基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径的集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。

基本路径测试法包括以下4个步骤：

以详细设计或源代码作为基础，绘制程序的控制流图。
计算得到的控制流图G的环路复杂性V（G）。
确定独立路径的集合。通过程序控制流图导出基本路径集，列出程序的独立路径。所谓独立路径，是指至少包含一条新边的路径，也就是包含一些前面的路径未包含的语句，当所有的语句都包含了，基路径集就够了。（线性无关路径）
设计测试用例，确保基本路径集中每条路径的执行。

8、黑盒测试

黑盒测试又称为功能测试，它是通过测试来检验程序的每个功能是否能正常使用。在测试中，将程序看成一个不能打开的黑盒子，在完全不考虑内部结构的情况下，在 程序接口进行测试，检查程序是否能适当的接受输入数据从而产生正确的输出信息。

黑盒测试主要针对 功能测试 和 软件界面测试 。

测试方法：等价类划分法、边界值分析法、判定表/因果图法、正交实验法

9、缺陷管理

软件缺陷

指存在于软件（程序、数据、文档）中的那些不符合用户需求的问题。

缺陷的基本概念

（1）缺陷（defect）：存在于软件之中的偏差，可被激活，以静态的形式存在于软件内部，相当于bug;
　　（2）故障（Fault）：软件运行中出现的状态，可引起意外情况，若不加处理，可产生失效，是一个动态行为；
　　（3）失效（Failure）：软件运行时产生的外部异常行为结果，表现与用户需求不一致，功能能力终止，用户无法完成所需要的应用。

软件缺陷的发现手段

同行评审、测试、管理评审、QA发现、项目组内部发现、客户反馈

为了便于缺陷的定位、跟踪和修改，要对所发现的缺陷，按照缺陷的严重程度、优先级、发现阶段、修复阶段、缺陷的性质、所属功能模块、系统环境等方面进行分类和统计。

缺陷密度

基本的缺陷测量是以每千行代码的缺陷数(个/KLOC)来测量的，其测量单位是defects／KLOC。

软件缺陷报告内容

1、缺陷标题/简单描述
　　对测试执行过程中实际出现的问题的描述，尽量要简单概要。
2、重现步骤/详细描述
　　（1）描述问题的基本环境，包括操作系统、硬件环境、网络环境、被测试软件的运行环境；
　　（2）简单概括的描述清楚软件出现异常时，测试人员的操作步骤和使用数据；
　　（3）缺陷原因的分析；比如说：因为不支持字符集，而导致的乱码...
　　（4）要写清楚，重复操作了多少次，这个bug依然出现。（不能操作一次就提交bug,因为有可能是自己操作失误。）
　　（5）相关附件：为了让开发人员更好的了解Bug。（如果从GUI界面上可以反映出软件的异常，可以截取界面，粘贴在问题单上或者日志、数据包）；
　　（6）属性（在下面详细说明）：缺陷报告中除了对缺陷的基本描述外，我们还要对其属性进行说明。

软件缺陷的相关属性

1、缺陷发现人

2、缺陷发现时间

3、缺陷状态

New	缺陷的初始状态
Open	开发人员开始修改缺陷
Fixed	开发人员修改缺陷完毕
Closed	回归测试通过
Reopen	回归测试失败
Postpone	推迟修改
Rejected	开发人员认为不是程序问题，不用修改
Duplicate	与已提交的 Defect 重复
Abandon	被 Reject 和 Duplicate 的 Defect，测试人员确认后的确不是问题，将 Defect 置为此状态

New--Open--fixed--closed这个状态是一个比较理想的缺陷流程，也就是测试人员提交问题，开发人员接受并修改问题，然后测试人员进行回归测试通过

4、缺陷严重程度（Severity）

致命的软件缺陷(Fatal)	造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等。
严重错误的软件缺陷（critical）	系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件。
一般错误的软件缺陷（major）	次要功能没有完全实现但不影响使用。如：提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等。
较小错误的软件缺陷（Minor）	使操作者不方便或遇到麻烦，但它不影响功能性的操作和执行，如错别字、界面不规范（字体大小不统一，文字排列不整齐，可输入区域和只读区域没有明显的区分标志），辅助说明描述不清楚。
建议问题的软件缺陷（Enhancemental）	由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。

5、缺陷的优先级（Priority）

6、缺陷的类型

7、缺陷所属版本

8、缺陷修改日期

参考文章：

https://blog.csdn.net/weixin_69884785/article/details/130970377

软件测试（理论基础） - LangZXG - 博客园 (cnblogs.com)

https://blog.csdn.net/qq_42944594/article/details/121907540