Month: December 2023

什么是集成测试？

集成测试解释：集成测试是一种软件测试类型，集成测试技术是将软件模块从逻辑上集成并将其作为一个组进行测试。一个典型的软件项目是由多个软件模块组成，而这些软件模块又是由不同的程序员编码而成。集成测试的任务是在这些软件模块集成时暴露它们交互中的缺陷。集成测试的侧重点是检查这些模块之间的数据通信。因此，集成测试也叫做“I&T”（集成和测试）、“字符串测试（String Testing）”，有时也称为“线程测试- Thread Testing”。

为什么进行集成测试？

虽然每个软件模块在这之前都经过了单元测试，但由于以下各种原因缺陷仍然存在：

• 每个模块通常都是由软件开发人员独立设计的，且每个开发人员的理解和编程逻辑会与其他程序员有所不同。集成测试作用便是验证软件模块是否能统一工作。
• 在模块开发时期，客户的需求很有可能会发生变化。这些新需求可能没有经过单元测试，因此系统集成测试就变得极其重要。
• 软件模块与数据库的接口可能出现错误
• 如果系统有外部硬件接口，为了避免可能存在的错误，也需要进行测试
• 异常处理不当可能会导致问题的出现

集成测试用例 示例

集成测试用例与其他测试用例的不同之处在于，集成测试主要测试的是模块之间的接口、数据流和信息流。这里优先考虑的是集成连接，而不是已经测试过的单元功能。

以下是集成测试用例举例说明：假设一个应用程序有三个模块，分别是“登录页”、“邮箱”和“删除电子邮件”，每个模块都是由逻辑形式集成的。这里我们不太关注界面测试，因为那已经在单元测试中完成了。我们需要检查的是登录界面是如何链接到邮箱页面的。

邮箱登录测试：检查邮箱登录入口与删除邮件模块的集成程度。

测试用例ID	测试用例目标	测试用例描述	预期结果
1	检查登录界面和邮箱模块之间的接口链接	输入登录凭据并单击“登录”按钮	定向到邮箱
2	检查邮箱和删除邮件模块之间的接口链接	从邮箱列表中选择电子邮件并单击删除按钮	所选电子邮件应显示在“已删除/垃圾箱”文件夹中

---

集成测试策略有哪些？

集成测试主要测试方法：  

软件工程定义了执行集成测试的各种策略，集成测试的方法有三种：

• Big Bang Approach :    大爆炸集成测试
• Incremental Approach：增量集成测试
  1. 自上而下集成测试
  2. 自下而上集成
• 三明治集成方法

（一）大爆炸测试方法的优点和缺点：

Big Bang测试是一种集成测试方法，是将所有组件或模块一次性集成在一起作为一个单元进行测试。在测试时，集成组合的组件将被视为一个实体。如果单元中还有未完成的组件，那么集成流程将不会被执行。

这也是最简单的集成测试模式，集成测试的流程是将所有模块组合在一起，并在完成单个模块测试后验证其功能。简单地说，测试人员会将系统的所有模块都简单地组装成一个系统进行测试。不过这种方法仅适用于非常小的系统。如果在集成测试期间发现任何错误，定位起来就比较困难，因为这个错误可能属于已经被集成的任何模块。因此，要修复在BigBang集成测试期间报告的调试错误费用是非常高的。

大爆炸集成策略是一种软件测试方法，在Bigbang测试方法中，软件应用程序的所有组件或模块都被合并并同时进行测试。当软件组件的相互依存度较低时，或者当开发环境中存在阻止测试单个组件的约束条件时，才会使用这种方法。大爆炸集成测试的目的是验证系统的整体功能，并识别组件组合时出现的任何集成问题。虽然爆炸测试技术在某些情况下很有用，但它也具有高风险，因为系统的复杂性和组件之间的交互次数会使识别和诊断问题变得困难。

• 大爆炸测试方法的优点有哪些—爆炸测试技术适用于小型系统；

● 大爆炸测试方法的缺点：

a、定位故障存在困难 b、集成测试需要测试的接口数量较多，有可能会出现漏测一些需要测试的接口链接的情况。 c、由于集成测试只有在“所有”模块设计完成后才能开始，因此留给测试团队在测试阶段执行测试的时间将减少。 d、由于所有模块都是一次性测试的，因此高风险关键模块并没有被隔离以及优先进行测试，且与用户界面交互的外围模块也没有被隔离或被优先测试。

（二）增量式测试

在增量测试方法中，测试是通过集成两个或多个逻辑上相互关联的模块来完成的，主要测试应用程序是否正常运行。然后其他相关模块会被逐步集成，该过程会持续进行直到所有逻辑相关模块被成功集成和测试。

增量测试的方式有两种：1）、自下而上；2）、自上而下

• 自下而上模式：自底向上集成测试是一种先测试较低级别模块的策略。这些已被测试的模块被进一步用于帮助完成更高级别模块的测试。该过程会持续进行直到所有顶层模块都被测试。一旦较低级别的模块经过测试和集成，那么就形成了较高一层级别的模块。

自下而上集成方式的特点：

优点	a、定位故障较为容易 b、与爆炸测试技术不同，它不必浪费时间等待所有模块都被创建才能执行
缺点	a、控制应用程序流程的关键模块（该模块位于软件体系结构的顶层）是最后测试的，容易出现缺陷。 b、无法建立初始原型

• 自上而下测试：

自上而下的集成测试是一种按照软件系统的控制流程从上到下进行集成测试的方法。集成测试过程是首先测试较高级别的模块，其次测试和集成较低级别的模块来检查软件功能。如果某些模块还没有准备就绪，则可以使用存根模块进行测试。

优点	a、故障定位变得容易 b、可以实现早期原型的创建工作 c、优先测试关键模块便于很快发现并修复主要的设计缺陷。
自上而下集成的缺点	a、需要许多存根 b、较低级别的模块不能得到充分测试。

（三）三明治测试方法：

三明治测试法是一种策略。在三明治测试策略，顶层模块与底层模块的测试是一同的，二者共同集成为一个系统进行测试。它是自上而下预测和自下而上预测方法的结合，因此被称为混合集成测试。它既利用了存根程序，也利用了驱动程序。

存根程序和驱动程序：存根程序和驱动程序是集成测试中的伪程序，有利于软件测试活动。这些程序可以替代测试中缺失的模型。它们不执行软件模块的整个编程逻辑，但在测试时会通过调用模块来模拟它们之间的数据通信。

存根程序/Stub	由被测模块调用
驱动程序/Driver	调用要测试的模块

---

怎么进行集成测试？

集成测试步骤包括：

• 识别组件：识别应用程序中需要集成的各个组件。这包括前端、后端、数据库和任何第三方服务插件。
• 创建测试计划：制定一个包括测试场景和测试用例在内的测试计划，并执行相应的测试以验证不同组件之间的集成点。其中包括测试数据流、通信协议和错误处理。
• 设置测试环境：设置一个尽可能接近生产环境的测试环境。这会使得集成测试的结果更加准确可靠。
• 执行测试：执行列出的测试计划，从最关键和最复杂的场景开始。确保记录集成测试过程中遇到的任何缺陷或问题。
• 分析测试结果：分析集成测试的结果，以确定需要解决的任何缺陷或问题。这可能涉及到与开发人员一起修复错误或对应用程序架构进行更改。
• 重复测试：缺陷修复后，重复集成测试的流程，以确保更改成功以及应用程序仍按预期工作。

集成测试的进入退出方法

集成测试的进入步骤：

• 所有组件/模块要完成单元测试；
• 修复并关闭所有高优先级错误；
• 所有模块都要完成代码编写并成功集成；
• 集成测试计划、测试用例、测试场景都要经过批准并作记录；
• 部署集成测试所需的测试环境。

集成测试的退出机制：

• 成功测试集成的应用程序；
• 记录执行的测试用例；
• 修复并关闭所有高优先级错误；
• 提交技术文件之后发布说明。

集成测试原则

1. 首先，确定可以选用的集成测试策略，再根据相应的测试策略准备测试用例和测试数据；
2. 研究应用程序的体系结构从而确定关键模块，优先测试这些关键模块；
3. 从体系结构团队那里获得接口设计，并创建测试用例来详细验证所有接口信息。必须详细测试系统与数据库/外部硬件/软件应用程序交互的接口；
4. 在完成测试用例之后，测试数据开始发挥关键作用；
5. 在执行集成测试之前准备好模拟数据。但在执行测试用例时不要选择测试数据。

软件测试英语词汇

登录界面英文	Login Interface
优先测试英文	Priority testing

单元测试的定义

单元测试是软件测试类型的一种，主要测试的是软件的单个单元或组件。单元测试的目的是验证软件代码的每个单元是否按预期执行。单元测试是在编码阶段完成的，方法是隔离一段代码并验证其正确性。一个单元可以是一个单独的功能、方法、进程、模块或对象。

在SDLC、STLC、V模型中，单元测试是在集成测试之前进行的第一级测试。单元测试是一种白盒测试方法，通常由开发人员执行。然而在实际工作中，由于时间关系或开发人员的推诿，很多时候单元测试都是由QA工程师执行的。

单元测试的目的和意义

单元测试的意义：

单元测试之所以很重要是因为软件开发人员有时会为了节省时间做最小的单元测试，而这有一定的风险，因为不健全的单元测试会增加在系统测试、集成测试以及应用程序构建后的Beta测试（一种验收测试）阶段的缺陷修复成本。如果单元测试在早期开发阶段执行得当，那么就会在很大程度上节省时间和金钱。

以下是在软件工程中执行单元测试的主要目的：

• 单元测试有助于在软件开发周期的早期修复错误以达到节省成本的效果。
• 单元测试有助于开发人员理解测试代码库，并帮助他们快速做出更改
• 良好的单元测试可作为项目文档模板
• 单元测试有助于代码重用。将代码和测试迁移到新项目中，经过调整后的代码就可以再次运行测试。

如何执行单元测试

为了执行单元测试，开发人员会编写一段代码来测试软件应用程序中的特定功能。开发人员还可以隔离此函数来进行更严格的测试，从而揭示被测试的函数和其他单元之间不必要的依赖关系并加以消除。开发人员通常使用UnitTest框架原理来开发可用于单元测试的自动化测试用例。单元测试类型有两种：

• 手动单元测试
• 自动单元测试

单元测试通常是自动化执行的，也可以通过手动执行来完成。软件工程并不偏爱其中一种，但自动化是首选。单元测试的手动操作可以采用循序渐进的指导文档。

以下是单元测试自动化测试方法：

• 开发人员会在应用程序中编写一段代码来测试功能。他们稍后会注释掉该段代码（使其暂时不运行），并最终在部署应用程序时删除测试代码。
• 开发人员还可以隔离该函数，对其进行更严格的测试。这是一种更彻底的单元测试实验，涉及到将代码复制并粘贴到本地测试环境中而不是真实自然环境中。隔离代码有助于揭示正在测试的代码与产品中的其他单元或数据空间之间的不必要的依赖关系，从而消除这些依赖关系。（本地测试环境-是在自己电脑上配置一个运行网站的虚拟空间, 主要用于测试程序,测试数据,开发程序或者开发模板等）
• 程序员通常使用UnitTest框架来开发自动化测试用例。开发人员使用自动化框架将标准编码编到测试中，目的是验证代码的正确性。在测试用例的执行过程中，单元测试框架会记录失败的测试用例。而且，许多自动化测试框架还会自动标记这些失败的测试用例并将其生成报告。最后会根据故障的严重程度，框架可能会停止后续测试。
• 单元测试的测试流程是: a、创建测试用例、b、审查/返工、c、设计测试用例基线（/基础测试用例）、d、执行测试用例。

单元测试技术分类

单元测试技术主要分为三个部分：黑盒测试-测试用户界面的输入输出功能；白盒测试-测试软件应用程序的功能行为；灰盒测试-用于执行测试套件、测试方法、测试用例和执行风险分析。单元测试中使用的代码覆盖技术如下所示：

• Statement Coverage- 语句覆盖率
• Decision Coverage- 判定覆盖测试
• Branch Coverage- 分支覆盖率测试
• Condition Coverage-条件覆盖测试
• Finite State Machine Coverage- 有限状态机覆盖率

单元测试用例：模拟对象

单元测试依赖于创建模拟对象来测试一段尚未成为完整应用程序一部分的代码。模拟对象填补了程序中缺失的那部分。例如，你有一个函数需要使用尚未创建的变量或对象。在单元测试中，这部分缺失将以模拟对象的形式进行说明，而该模拟对象仅为该代码段进行单元测试而创建。

单元测试的测试工具

自动化测试中用于实现单元测试的工具是：

• Junit: Junit是一个免费的测试工具，适用于Java编程语言。它使用断言（assertion）来识别测试方法。Junit工具首先测试数据，然后再将其导入代码段中。
• NUnit:  NUnit是被所有.net语言广泛使用的单元测试框架。它是一个开源工具，允许测试人员手动编写脚本，还支持可以并行运行的数据驱动测试。
• JMockit: JMockit是一个开源的单元测试工具。它是一个代码覆盖率工具，允许使用记录和验证语句来模仿API。JMockit测试框架提供了线路覆盖、路径覆盖和数据覆盖。
• EMMA: 代码覆盖率工具EMMA是一个开源工具包，用于分析和报告由Java语言编写的代码。Emma支持的覆盖类型有方法、线、语句块（basic block）。它是基于Java的，因此没有外部库依赖项，并且可以访问源代码。
• PHPUnit: PHPUnit是PHP程序员的单元测试工具。它获取被称为单元的代码的一小部分，并分别测试其中的每一段。该工具还允许开发人员使用预定义的断言方法来断言系统以某种方式运行。

测试驱动开发TDD

TDD测试驱动开发中的单元测试涉及了对测试框架的广泛使用。单元测试框架用于创建自动化的单元测试。单元测试框架并不是TDD独有的，但却是对测试驱动开发至关重要的。下面我们来看看TDD帮助单元测试项目实现了些什么：

• 测试用例是在编写代码之前编写的
• 极度依赖测试框架
• 应用程序中的所有类（classes）都经过了测试
• 实现了快速简便的集成

软件测试知识点：

• SDLC全称：Software Development Life Cycle/软件生命周期
• STLC: Software Testing Life Cycle/软件测试生命周期

决策表设计测试用例的步骤

决策表测试用例条件:

让我们以某个应用程序的登录界面为例。登录要求规定如果用户提供了正确的用户名和密码，则会被指引到主页面。如果出现任一输入错误，屏幕上将会显示一条错误消息。

例 1：

条件	Rule 1/TC1	Rule 2/TC2	Rule 3/TC3	Rule 4/TC4
邮箱(输入)	T	T	F	F
密码 (输入)	T	F	T	F
行为(输出)	H	E	E	E

在以上的例子中，T代表输入正确的邮箱ID/密码；F代表输入错误的邮箱ID/密码；H代表向用户显示了主页；E代表向用户显示了错误信息；TC代表测试用例。

接下来，让我们根据以上提供的输入值（电子邮件ID和密码）来看一下决策表测试用例怎么写。

• 测试用例 1– 电子邮件ID和密码都是正确的。因此用户应该被指引到网站的主页;
• 测试用例 2-电子邮件ID正确，但密码错误。因此用户会收到一条错误消息，提示“密码不正确”;
• 测试用例 3- 电子邮件ID错误，但密码正确。因此用户会收到一条错误消息，提示“电子邮件ID不正确”;
• 测试用例 4- 电子邮件ID和密码都不正确。因此用户会收到一条错误消息，提示“电子邮件ID不正确”。

在以上的测试用例中，我们将所有可能的输入条件和测试用例都包括在内了，测试团队可以参考此决策表来创建适合自己产品的测试用例，以便在软件测试级别上发现可能出现的错误。

---

决策表测试场景有哪些？

例 2：现有一个对话框要求用户上传文件，规格要求：该文件应为.png格式；文件的大小应小于25kb；文件分辨率必须为132*170px。

我们使用决策表法设计测试用例如下：

条件	Rule 1/TC1	Rule 2/TC2	Rule 3/TC3	Rule 4/TC4	Rule 5/TC5	Rule 6/TC6	Rule 7/TC7	Rule 8/TC8
格式(Input)	.png	.png	.png	.png	Not.png	Not.png	Not.png	Not.png
大小(Input)	<25kb	<25kb	>=25kb	>=25kb	<25kb	<25kb	>=25kb	>=25kb
分辨率(Input)	= 132*170px	!= 132*170px	=132*170px	!= 132*170px	=132*170px	!= 132*170px	=132*170px	!= 132*170px
输出值(Output)	成功上传了.png 格式的文件	报错：分辨率不匹配	报错：大小不匹配	报错：大小不匹配	报错：格式不匹配	报错：格式不匹配	报错：格式不匹配	报错：格式不匹配

基于上述决策表数据，为了全面覆盖决策表列出的测试规范，我们创建了八个不同的测试用例：

• 测试用例 1：点击上传，添加一个格式为“.png”类型的文件，文件小于25kb，分辨率为132*170px。预期输出结果是照片成功上传;
• 测试用例 2：点击上传，添加一个格式为“.png”类型的文件，文件小于25kb，分辨率小于132*170px。预期输出结果是显示“文件分辨率不匹配，用户无法上传文件”字样的报错信息；
• 测试用例 3：点击上传，添加一个格式为“.png”类型的文件，文件大于25kb，分辨率为132*170px。预期输出结果显示“文件大小不正确，用户无法上传文件”字样的报错信息；
• 测试用例 4：点击上传，添加一个格式为“.png”类型的文件，文件大于25kb，分辨率小于132*170px。预期结果显示“文件大小不正确，用户无法上传文件”字样的报错信息；
• 测试用例 5：点击上传，添加一个格式不是“.png”类型的文件，文件小于25kb，分辨率为132*170px。预期输出结果显示“文件格式不匹配，用户无法上传文件”字样的报错信息；
• 测试用例 6：点击上传，添加一个格式不是“.png”类型的文件，文件小于25kb，分辨率大于132*170px。预期结果显示“文件格式不正确，用户无法上传文件”字样的报错信息；
• 测试用例 7：点击上传，添加一个格式不是“.png”类型的文件，文件大小为25kb，分辨率为132*170px。预期结果显示“文件格式不正确，用户无法上传文件”字样的报错信息;
• 测试用例 8：点击上传，添加一个格式不是“.png”类型的文件，文件大于25kb，分辨率小于132*170px。预期结果显示“文件格式不正确，用户无法上传文件”字样的报错信息。

从以上两个例子我们可以得出结论：为了找到决策表的所有可能条件的数量，可以使用2^n公式，其中n表示输入的数量；在示例1中，输入的数量为2个（一个是电子邮件ID，另一个是密码），那么套用公式：

• 可能的测试条件数量=2^输入条件数量 （2^=2的n次方）
• 可能的试验条件数量=2^2=4

因此，在示例1的情况下，我们涵盖了四个测试用例。

在示例2的情况下，有3种不同类型的输入：文件格式、大小和文件分辨率。代入相同的2^n公式：

• 可能的测试条件数量=2^输入条件数量
• 可能的试验条件数量=2^3=8   

因此，在示例2的情况下，我们就涵盖了八个测试用例。

决策表软件测试

在软件测试行业里，有一句话是这么说的想要追求“彻底的测试是不可能的”。许多不同类型的软件测试技术都有自身的优缺点。测试人员需要根据项目需求和产品需求来选用一种更合适的测试技术来帮助他们明智地选择测试用例以及确保所有测试场景都能被覆盖。

根据ISTQB体系，软件测试技术分为两大类：

1. 静态测试技术：在不运行软件产品的情况下，仅在规范或执行级别上测试组件或系统，例如，测试不同类型的计划、项目启动会议、准备工作等。
2. 动态测试技术：需要测试软件产品或系统的运行。

动态测试技术再次细分为三类：

• 基于规范的测试技术/黑盒测试技术/行为测试技术
• 基于结构的测试技术/白盒测试技术/结构测试技术
• 基于经验的测试技术

基于规范的测试技术是一种根据对规范的分析来推导或选择测试用例的过程，可以是对组件或系统执行的功能性测试也可以是非功能性测试，但不考虑内部结构。简而言之，测试人员更专注于软件的用途，而不是它如何工作。

再往下细分，有四种基于规范的设计技术：等价类划分法、边界值分析法、决策表法、状态转换测试法。等价划分法和边界值法通常更侧重于对用户界面的测试，而决策表法和状态转换测试方法则更侧重于对业务逻辑或业务规则的测试。

决策表的概念

决策表测试的定义是：“决策表”是一种简明的视觉表示，用于明确规定按照既定条件或输入条件需要执行哪些操作。这些算法的输出（是指算法在执行过程中或终止前）是一组操作。这些操作可以进一步被应用于设计测试用例。

决策表测试是一种黑盒测试设计技术，其中测试用例被设计为执行决策表中列出的输入组合。软件测试决策表是测试输入组合的好方法。决策表法测试方法有时也称为“因果”表。因为它包含一种被称为“因果图”的相关逻辑图解技术，有时还会被用于帮助推导决策表。

决策表可以用于自动化操作吗？

如上所述，决策类型测试是一种基于系统或组件的输入和输出相结合来设计测试用例的技术。决策表分析有助于覆盖所有可能的场景，并减少测试冗余和复杂性。不过，手动创建和执行决策表测试是非常耗时且容易出错。使用自动化决策方式可以给我们带来以下几个优势：

• 节省时间和精力
• 提高测试覆盖率，提升测试质量。
• 提高可维护性和可扩展性，促进团队间的沟通与协作。
• 测试用例自动生成并自动执行消除了人为错误
• 更新测试用例变得很容易，在不同的场景中重复使用测试用例可以提升流程效率。

这就是测试人员需要使用一些工具或技术来实现自动化决策表测试的原因。

决策表适用于什么场景  

决策表使用条件：使用决策表的第一个任务是识别一个合适的功能或子系统，观察其行为是否会根据输入组合或事件组合做出相应的响应。我们以任一应用程序的登录界面为例，这其中包含如用户名、密码、双因素身份验证等不同的输入，以及如无效密码不允许登录、只有授权的用户名和正确的密码才能登录应用程序等不同的操作/输出。

此外，务必确保不要有太多的输入数据，否则组合数量会变得繁琐和难以管理。如果你必须处理批量的输入条件，建议先把它们划分成子集，一次处理一个子集。一旦你确定了需要组合的方面，可以将它们放入一个表中，列出每个条件的True和False的集合。在下一篇的两个例子中，我们将了解如何在不同的软件项目中应用决策模型。