系统测试 集成测试 性能测试 系统测试 系统测试包括对完全集成的软件系统的测试。通常，计算机系统是由软件集成而成的（任何软件都只是计算机系统的一个元素）。软件以单元为单位进行开发，然后与其他软件和硬件接口，形成一个完整的计算机系统。换句话说，一个计算机系统由一组执行各种任务的软件组成，但只有软件不能执行任务；因为该软件必须与兼容的硬件接口。系统测试是一系列不同类型的测试，目的是根据要求练习和检查集成软件计算机系统的完整工作。 以用户身份检查应用程序或软件的端到端流程称为系统测试。在此，我们导航（通过）应用程序的所有必要模块并检查最终功能或最终业务是否正常工作，并将产品作为整个系统进行测试。 它是端到端测试，其中测试环境类似于生产环境。 软件测试有四个级别：单元测试、集成测试、系统测试和验收测试，都用于测试目的。单元测试用于测试单个软件；集成测试用于测试一组软件单元，系统测试用于测试整个系统，验收测试用于测试业务需求的可接受性。这里我们讨论的是系统测试，它是测试级别的第三级。 测试级别的层次结构 主要有软件测试两种广泛使用的方法，一种是白箱测试使用内部编码来设计测试用例，另一个是黑盒测试，它使用GUI或用户的角度来开发测试用例。 白盒测试 黑盒测试 系统测试属于黑盒测试，因为它包括对软件外部工作的测试。测试遵循用户的观点来识别小缺陷。 2.9M SQL 中的触发器（印地语） 系统测试包括以下步骤。 验证应用程序的输入功能以测试它是否产生预期的输出。 通过包括外部外围设备来测试集成软件，以检查各种组件之间的交互。 对整个系统进行端到端测试。 通过用户体验对应用程序进行行为测试 系统测试示例 假设我们打开一个应用程序，比如**www.rediff.com**，我们可以看到主页顶部显示了一个广告，并且在它消失之前停留了几秒钟。这些类型的广告由广告管理系统 (AMS) 完成。现在，我们将对此类字段进行系统测试。 以下应用程序按以下方式工作： 假设亚马逊希望在 1 月 26 日上午 10:00 在 Rediff 的主页上显示印度国家/地区的促销广告。 然后，销售经理登录网站并创建日期为上述日期的广告的请求。 他/她附上可能是广告的图像文件或视频文件的文件并适用。 第二天，Rediffmail 的 AMS 经理登录到应用程序并验证等待的广告请求。 AMS 经理将检查那些亚马逊的广告请求是否处于待处理状态，然后他/她将检查特定日期和时间的空间是否可用。 如果有空间，那么他/她以每秒 15 美元的价格评估投放广告的成本，10 秒的总体广告成本约为 150 美元。 AMS 经理点击付款请求，并将估计值与付款请求一起发送给亚马逊经理。 然后亚马逊经理登录广告状态并确认付款请求，他/她根据所有详细信息付款并点击提交和付款 Rediff 的 AMs 经理一拿到金额，他/她就会在 Rediffmail 的主页上设置特定日期和时间的广告。 各种系统测试场景如下： 场景 1：第一个测试是一般场景，正如我们上面所讨论的。测试工程师将对亚马逊经理创建广告请求并且该广告在特定日期和时间使用的基本情况进行系统测试。 场景2：假设亚马逊经理觉得AD空间太贵，取消请求。同时，Flipkart 在 1 月 26 日上午 10 点请求广告空间。然后亚马逊的请求就被取消了。因此，Flipkart 的促销广告必须安排在 1 月 26 日上午 10 点。 毕竟，请求和付款已经完成。现在，如果亚马逊改变主意并且他们觉得他们准备好在 1 月 26 日上午 10 点付款，这应该是因为 Flipkart 已经使用了那个空间。因此，必须为亚马逊打开另一个日历才能进行预订。 场景3：这里，首先我们以AMS管理器的身份登录，然后点击Set Price页面，在logout页面设置AD空间的价格为10$每秒。 然后以亚马逊经理的身份登录并在注销页面上选择要放置和广告的日期和时间。Rediffmail 注销页面上的广告 10 秒的付款应为 100 美元。 注意：一般来说，每个测试工程师只对他们分配的模块进行功能、集成和系统测试。 如下图所示，我们有三个不同的模块，如Loans、Sales 和 Overdraft。这些模块将由他们指定的测试工程师进行测试，因为如果数据在这些模块或场景之间流动，那么我们需要明确它在哪个模块中运行，并且该测试工程师应该检查那个东西。 让我们假设在这里我们正在对利息估计执行系统测试，其中客户第一次和第二次透支。 在这个特定的例子中，我们有以下场景： 场景1 首先，我们将以用户身份登录；看P，申请透支Rs15000，点击申请，退出。 之后，我们将以Manager身份登录并批准P的透支，然后注销。 我们将再次以 P 身份登录并检查透支余额；应存入 Rs15000 并注销。 将服务器日期修改为接下来的 30 天。 以P登录，查看透支余额为15000+300+200=15500，然后退出 以经理身份登录，单击存款，然后存款 Rs500，退出。 以 P 身份登录，偿还透支金额，并检查透支余额，即零卢比。 提前申请透支作为两个月的工资。 经经理批准，金额贷记及利息将计入第一次手续费。 登录用户→首页【贷款、销售、透支】→透支页面【金额透支、申请透支、还款透支】→申请 登录管理器→首页【贷款、销售、透支】→透支页面【金额透支、申请透支、还款透支、批准透支】→批准页面→批准申请。 用户P登录→首页【贷款、销售、透支】→透支页面【额度透支、申请透支、还款透支】→批准透支→额度透支 用户P登录→首页【贷款、销售、透支】→透支页面【金额透支、申请透支、还款透支】→还款透支→手续费+利息金额。 场景2 现在，我们测试银行提供报价的替代方案，即首次将 Rs45000 用作透支的客户将不收取流程费。客户第三次选择其他透支时，手续费不予退还。 我们要测试第三个场景，客户第一次透支Rs45000，还要验证透支在第三次申请透支后还清余额。 场景3 在此，我们将反映该应用程序正在被所有客户普遍使用，突然银行决定将新客户的处理费降低到Rs100，并且我们已经为新客户测试了透支并检查它是否接受只需 100 卢比。 但是我们在要求中遇到了冲突，假设客户已经申请了 15000 卢比作为透支，当前的手续费为 200 卢比。在经理尚未批准之前，银行将手续费降至 100 卢比。 现在，我们必须测试对未决客户的透支收取的手续费是多少。测试团队不能假设任何事情；他们需要与业务分析师或客户沟通，并找出在这些情况下他们想要什么。 因此，如果客户提供第一组需求，我们必须想出最大可能的场景。 系统测试的类型 系统测试分为 50 多种，但软件测试公司通常会使用其中的一些。下面列出了这些： 回归测试 回归测试是在系统测试下进行的，以确认和识别系统中是否存在由于系统任何其他部分的修改而导致的任何缺陷。它确保在开发过程中所做的任何更改都不会引入新的缺陷并提供保证；随着时间的推移，随着新软件的添加，旧的缺陷将不复存在。 负载测试 负载测试是在系统测试下进行，以明确系统是否可以在实时负载下工作。 功能测试 执行系统的功能测试以查找系统中是否存在任何缺失的功能。测试人员列出系统中应该存在的重要功能，并且可以在功能测试期间添加这些功能，并可以提高系统的质量。 恢复测试 系统的恢复测试是在系统测试下进行的，以确认系统的可靠性、可信度、可问责性，所有这些都取决于系统的恢复技能。它应该能够成功地从所有可能的系统崩溃中恢复。 在此测试中，我们将测试应用程序以检查它从崩溃或灾难中恢复的情况。 恢复测试包含以下步骤： 每当软件崩溃时，它不应消失，而应写入崩溃日志消息或错误日志消息，其中应提及崩溃原因。例如：C://Program Files/QTP/Cresh.log 它应该在它消失之前终止它自己的程序。就像在 Windows 中，我们有任务管理器来显示正在运行的进程。 我们将引入错误并使应用程序崩溃，这意味着有人会引导我们了解应用程序如何以及何时崩溃。或者根据经验，经过几个月的产品工作后，我们可以了解应用程序将如何以及何时崩溃。 重新打开应用程序；必须使用较早的设置重新打开应用程序。 例如：假设我们正在使用谷歌浏览器，如果电源关闭，那么我们打开系统并重新打开谷歌浏览器，我们收到一条消息，询问我们是要开始新会话还是恢复以前的**会话**会话。对于任何开发的产品，开发人员都会编写一个恢复程序，描述软件或应用程序崩溃的原因，是否写入了崩溃日志消息等。 迁移测试 执行迁移测试是为了确保如果系统需要在新的基础设施中进行修改，那么它应该在没有任何问题的情况下进行修改。 可用性测试 此测试的目的是确保系统对用户非常熟悉，并且满足其应该执行的目标。 软件和硬件测试 该系统测试旨在检查硬件和软件的兼容性。硬件配置必须与软件兼容才能正常运行。兼容性通过提供硬件和软件之间的交互来提供灵活性。 为什么系统测试很重要？ 系统测试可以百分百保证系统性能，因为它涵盖了系统的端到端功能。 它包括对系统软件架构和业务需求的测试。 即使在生产之后，它也有助于减轻实时问题和错误。 系统测试同时使用现有系统和新系统，在两者中提供相同的数据，然后比较新增功能和现有功能的功能差异，以便用户了解系统新增功能的好处。 测试任何应用程序 在这里，我们将测试Gmail应用程序以了解功能、集成和系统测试的工作原理。 假设，我们就来测试各种模块，如登录，撰写，草稿，收件箱，已发送邮件，垃圾邮件，聊天，帮助，退出的Gmail的应用。 我们首先对所有模块进行功能测试，然后才能进行集成测试和系统测试。 在功能测试中，至少我们有一个模块来执行功能测试。所以在这里我们有 Compose 模块，我们在其中执行功能测试。 撰写 Compose 模块的不同组件是To、CC、BCC、Subject、Attachment、Body、Sent、Save to Draft、Close。 首先，我们将对To进行功能测试 输入 结果 正输入 迈克@gmail.com 接受 Mike12@gmail.com 接受 Mike@yahoo.com 接受 负输入 Mike@yahoocom 错误 Mike@yaho.com 错误 对于CC和BCC组件，我们将采用与To 组件相同的输入。 对于主题组件，我们将采用以下输入和场景： 输入 结果 正输入 输入最大字符 接受 输入最小字符 接受 空格处 接受 网址 接受 复制粘贴 接受 负输入 交叉的最大位数 错误 粘贴图像/视频/音频 错误 最大字符数 最小字符 Flash 文件 (GIF) 微笑 格式 空白的 复制粘贴 超链接 签名 对于 附件 组件，我们将借助以下场景测试该组件。 最大文件大小 不同的文件格式 文件总数 同时附加多个文件 拖放 没有附件 删除附件 取消上传 查看附件 浏览器不同位置 附加打开的文件 对于Sent组件，我们将编写整个字段并单击Sent按钮，以及确认消息；必须显示成功发送的消息。 对于Saved to Drafts组件，我们将写入整个字段并单击aved to drafts，并且必须显示确认消息。 对于取消组件，我们将写入所有字段并单击取消按钮，窗口将关闭或移动以保存到草稿或必须刷新所有字段。 完成对 compose 模块的功能测试后，我们将对 Gmail 应用程序的各个模块进行集成测试： 登录 首先，我们将输入用于登录应用程序的用户名和密码，并在主页上检查用户名。 撰写 撰写邮件，发送并在已发送项目[发件人]中查看邮件 撰写邮件，发送并检查收件人[收件箱]中的邮件 撰写邮件，发送并查看自己的邮件[收件箱] 撰写邮件，单击另存为草稿，然后签入发件人草稿。 撰写邮件，发送无效 ID（有效格式），并检查未送达的邮件。 撰写邮件、关闭和签入草稿。 收件箱 选择邮件、回复并签入已发送邮件或收件人收件箱。 在收件箱中选择要回复的邮件，另存为草稿并签入草稿。 选择邮件然后将其删除，并在垃圾箱中签入。 发送项目 选择邮件、已发邮件、回复或转发，并在已发邮件或收件人收件箱中签入。 选择邮件、已发送项目、回复或转发、另存为草稿，并在草稿中进行验证。 选择邮件，删除它，然后检查垃圾箱。 草案 选择电子邮件草稿，转发并检查已发送项目或收件箱。 选择电子邮件草稿，删除并在垃圾箱中验证。 聊天 与保存在接收者收件箱中的离线用户聊天。 与用户聊天并在聊天窗口中进行验证。 与用户聊天并查看聊天记录。 注意：在测试过程中，我们需要等待一段特定的时间，因为系统测试只有在所有模块都准备好并进行功能和集成测试后才能进行。 集成测试 性能测试
