集成测试 单元测试 系统测试 集成测试 集成测试是继单元测试之后的软件测试过程的第二级。在此测试中，软件的单元或单个组件在一组中进行测试。集成测试级别的重点是在集成组件或单元之间交互时暴露缺陷。 单元测试使用模块进行测试，这些模块在集成测试中组合和测试。本软件由多个软件模块开发而成，这些模块由不同的编码员或程序员编写。集成测试的目标是检查所有模块之间通信的正确性。 一旦所有组件或模块都独立工作，那么我们需要检查依赖模块之间的数据流，这称为集成测试。 让我们看一个银行应用程序的示例，如下面的金额转账图片所示。 首先，我们将作为用户P登录进行金额转账并发送Rs200金额，确认信息应显示在屏幕上，金额转账成功。现在以 P 身份注销并以用户Q登录并转到金额余额页面并检查该帐户中的余额 = 当前余额 + 已收余额。因此，集成测试是成功的。 此外，我们检查 P 用户帐户中的余额是否减少了 200 卢比。 单击交易，在 P 和 Q 中，应显示有关金额转移的数据和时间的消息。 集成测试指南 只有在应用程序的每个模块上完成功能测试后，我们才会进行集成测试。 我们总是通过逐个模块选择模块来进行集成测试，以便遵循正确的顺序，并且我们不会错过任何集成场景。 首先，确定可以根据测试数据准备可执行测试用例的测试用例策略。 检查应用程序的结构和体系结构，确定要首先测试它们的关键模块，并确定所有可能的场景。 设计测试用例来详细验证每个接口。 选择用于测试用例执行的输入数据。输入数据在测试中起着重要作用。 如果我们发现任何错误，则将错误报告传达给开发人员并修复缺陷并重新测试。 执行正面和负面的集成测试。 这里的正测试意味着，如果总余额为 15 卢比，则 000 美元，我们正在转移 1500 卢比并检查金额转移是否正常。如果是这样，那么测试将通过。 和负测试装置，如果总的平衡是缴15卢比就有，000和如果发生与否量传递我们正在传送RS20，000和检查时，如果不发生的，该测试是一通。如果发生这种情况，则代码中存在错误，我们会将其发送给开发团队以修复该错误。 注意：这个世界上的任何应用程序都会强制进行功能测试，而只有在模块相互依赖时才会进行集成测试。每个集成场景都必须有源→数据→目的地。只有将数据保存在目标中，任何场景都可以称为集成场景。 例如：在 Gmail 应用程序中，Source可以是Compose，Data可以是Email，Destination可以是Inbox。 集成测试示例 让我们假设我们有一个Gmail应用程序，我们在其中执行集成测试。 首先，我们会做功能测试上的登录页面，其中包括各种组件，如用户名，密码，提交和取消按钮。那么只有我们才能进行集成测试。 不同的集成场景如下： 场景1： 首先，我们以P用户身份登录并单击Compose邮件并对特定组件执行功能测试。 现在我们点击Send并检查Save Drafts。 之后，我们向Q发送邮件，并在P的Send Items文件夹中进行验证以检查发送邮件是否在那里。 现在，我们将以P 身份注销并以 Q 身份登录，然后移至收件箱并验证邮件是否已到达。 Secanrios2：我们还对垃圾邮件文件夹执行集成测试。如果特定联系人已被标记为垃圾邮件，则该用户发送的任何邮件都应进入垃圾邮件文件夹而不是收件箱。 注意：我们将对所有功能进行功能测试，例如发送项目、收件箱等。 如下图所示，我们将对所有文本字段和每个功能进行功能测试]。然后我们将对相关功能进行集成测试。我们首先测试添加用户、用户列表、删除用户、编辑用户，然后搜索用户。 笔记： 有一些特性，我们可能只执行功能测试，还有一些特性，我们根据特性的要求执行功能和集成测试。 优先排序是必不可少的，我们应该在所有阶段都执行它，这意味着我们将打开应用程序并选择首先需要测试的功能。然后转到该功能并选择必须首先测试的组件。转到这些组件并确定要首先输入哪些值。 并且不要在任何地方应用相同的规则，因为测试逻辑因功能而异。 在执行测试时，我们应该完全测试一个功能，然后只进行另一个功能。 在这两个功能中，我们必须只进行正面集成测试或正面和负面集成测试，这也取决于功能需求。 集成测试背后的原因 虽然软件应用的所有模块都已经在单元测试中进行了测试，但由于以下原因，错误仍然存在： 每个模块由个别软件开发人员设计，其编程逻辑可能与其他模块的开发人员不同；集成测试对于确定软件模块的工作至关重要。 检查软件模块与数据库的交互是否有误。 可以在模块开发时更改或增强需求。这些新需求可能不会在单元测试级别进行测试，因此集成测试成为强制性的。 软件模块之间的不兼容可能会产生错误。 测试硬件与软件的兼容性。 如果模块之间的异常处理不足，则可能会产生错误。 集成测试技术 任何测试技术（黑盒、白盒和灰盒）都可以用于集成测试；下面列出了一些： 黑盒测试 状态转换技术 决策表技术 边值分析 全对测试 因果图 等价分区 错误猜测 白盒测试 数据流测试 控制流测试 分支覆盖测试 决策覆盖测试 集成测试的类型 集成测试可以分为两部分： 增量集成测试 非增量集成测试 增量方法 在增量方法中，模块按升序一个一个或根据需要添加。所选模块必须在逻辑上相关。通常，添加两个或两个以上的模块并进行测试以确定功能的正确性。该过程一直持续到所有模块测试成功。 OR 测试中，依赖模块之间存在很强的关系。假设我们采用两个或更多模块并验证它们之间的数据流是否正常工作。如果是，则添加更多模块并再次测试。 例如：假设我们有一个 Flipkart 应用程序，我们将进行增量集成测试，应用程序的流程是这样的： Flipkart→登录→首页→搜索→添加购物车→付款→注销 增量集成测试通过进一步的方法进行： 自上而下的方法 自下而上的方法 自上而下的方法 自顶向下的测试策略处理的是用较低级别的模块测试较高级别的模块，直到成功完成所有模块的测试的过程。由于首先测试了关键模块，因此可以及早发现和修复主要设计缺陷。在这种方法中，我们将逐个或逐个添加模块，并按照相同的顺序检查数据流。 在自上而下的方法中，我们将确保我们添加的模块是前一个模块的子，就像子 C 是子 B 的子等等，如下图所示： 优点： 缺陷的识别是困难的。 一个早期的原型是可能的。 缺点： 由于存根数量较多，因此变得相当复杂。 较低级别的模块测试不充分。 首先测试关键模块，以减少出现缺陷的机会。 自下而上的方法 自下而上的测试策略处理低级模块与高级模块一起测试的过程，直到成功完成所有模块的测试。顶级关键模块最后进行测试，因此可能会导致缺陷。或者我们可以说我们将从下到上添加模块并以相同的顺序检查数据流。 在自底向上的方法中，我们将确保我们添加的模块是前一个模块的父模块，如下图所示： 优点 识别缺陷很容易。 无需等待所有模块开发完毕，节省时间。 缺点 关键模块最后进行测试，因此可能会出现缺陷。 没有早期原型的可能性。 在这方面，我们有一种额外的方法，称为混合测试。 混合测试方法 在这种方法中，自上而下和自下而上的方法结合起来进行测试。在这个过程中，顶层模块与底层模块同时测试，底层模块与高层模块同时测试。由于每个模块接口都经过测试，因此发生缺陷的可能性较小。 好处 混合方法提供自下而上和自上而下方法的特征。 这是最省时的方法。 它提供了对所有模块的完整测试。 缺点 由于该过程同时在两个方向上进行，因此该方法需要更高的浓度。 复杂的方法。 非增量集成测试 当数据流非常复杂并且很难找到谁是父母谁是孩子时，我们将采用这种方法。在这种情况下，我们将在所有其他现有模块的任何模块中创建数据并检查数据是否存在。因此，它也被称为大爆炸法。 大爆炸法(Big Bang Method) 在这种方法中，测试是通过一次集成所有模块来完成的。它对于小型软件系统来说很方便，如果用于大型软件系统识别缺陷是困难的。 由于此测试可以在所有模块完成后进行，因为测试团队执行此过程的时间较少，因此很容易遗漏内部链接的接口和高风险的关键模块。 好处： 这对于小型软件系统很方便。 缺点： 识别缺陷很困难，因为找到错误的来源是一个问题，而且我们不知道错误的来源。 小模块容易遗漏。 用于测试的时间非常少。 我们可能会错过测试某些接口。 让我们看一些示例，以更好地理解非增量集成测试或大爆炸方法： 示例 1 在下面的示例中，开发团队开发应用程序并将其发送给测试团队的 CEO。然后 CEO 将登录应用程序并生成用户名和密码并向经理发送邮件。之后，CEO 会告诉他们开始测试应用程序。 然后经理管理用户名和密码并生成用户名和密码并将其发送给测试负责人。而测试导线将其发送给测试工程师进行进一步的测试目的。从 CEO 到测试工程师的这个命令是自上而下的增量集成测试。 同样，当测试工程师完成测试后，他们将报告发送给测试负责人，然后测试负责人将报告提交给经理，经理将报告发送给CEO。这个过程被称为自底向上增量集成测试，如下图所示： 注意：增量集成测试 (IIT) 和非增量集成测试的组合称为三明治测试。 例2 下面的示例演示了Gmail 收件箱的主页，我们在其中单击收件箱链接，我们将移至收件箱页面。这里我们必须做非增量集成测试，因为没有父子概念。 笔记 存根和驱动程序 该存根是接收数据并创建大量可能的数据的虚设的模块，但它执行像一个真正的模块。当一个数据从模块 P 发送到 Stub Q 时，它在没有确认和验证的情况下接收数据，并为给定的数据产生估计的结果。 驱动程序的功能用于验证来自 P 的数据并将其发送到 stub 并检查来自 stub 的预期数据并将其发送到 P。 该驱动程序是一个集合了测试环境和也需要通信，评估结果的照顾，并发送报告。我们在测试过程中从不使用存根和驱动程序。 在白盒测试中，自下而上的集成测试是理想的，因为可以编写驱动程序。在黑盒测试中)，没有优先考虑任何测试，因为它取决于应用程序。 单元测试 系统测试
