系统测试

系统测试包括对完全集成的软件系统的测试。通常，计算机系统是由软件集成的（任何软件都只是计算机系统的单个组成部分）。软件是按单元开发的，然后与其他软件和硬件接口，形成一个完整的计算机系统。换句话说，计算机系统由一组软件组成，用于执行各种任务，但仅凭软件无法执行任务；为此，软件必须与兼容的硬件进行接口。系统测试是一系列不同类型的测试，目的是根据需求对集成的软件计算机系统的完整运行进行演练和检查。

检查应用程序或软件的端到端流程（如同用户一样）被称为系统测试。在此过程中，我们遍历（浏览）应用程序的所有必要模块，并检查最终功能或最终业务是否运行正常，并将产品作为一个整体系统进行测试。

这是端到端测试，其中测试环境与生产环境类似。

软件测试有四个级别：单元测试、集成测试、系统测试和验收测试，都用于测试目的。单元测试用于测试单个软件；集成测试用于测试一组软件单元；系统测试用于测试整个系统；验收测试用于测试业务需求的可用性。我们在这里讨论的是系统测试，它是测试级别的第三个级别。

测试级别层次结构

软件测试主要有两种广泛使用的方法：一种是白盒测试，它使用内部编码来设计测试用例；另一种是黑盒测试，它使用 GUI 或用户视角来开发测试用例。

• 白盒测试
• 黑盒测试

系统测试属于黑盒测试，因为它包括对软件外部功能的测试。测试遵循用户的视角来识别细微的缺陷。

系统测试包括以下步骤。

• 验证应用程序的输入功能，以测试其是否产生预期的输出。
• 通过包含外部外围设备来测试集成软件，以检查各种组件之间的交互。
• 对整个系统进行端到端测试。
• 通过用户体验对应用程序进行行为测试

系统测试示例

假设我们打开一个应用程序，例如www.rediff.com，在那里我们可以看到主页顶部显示一个广告，它会停留几秒钟然后消失。这些类型的广告由广告管理系统 (AMS) 完成。现在，我们将对这种类型的字段执行系统测试。

下面的应用程序按以下方式工作

• 假设 Amazon 希望在 1 月 26 日上午 10:00 在 Rediff 的主页上为印度国家显示促销广告。
• 然后，销售经理登录网站，创建一个针对上述日期的广告请求。
• 他/她会附加一个文件，可能是广告的图片文件或视频文件，然后提交。
• 第二天，Rediffmail 的 AMS 经理登录应用程序并验证待处理的广告请求。
• AMS 经理将检查 Amazon 的广告请求是否正在等待，然后他/她将检查特定日期和时间是否有可用空间。
• 如果空间存在，那么他/她会评估在每秒 15 美元的价格投放广告的成本，10 秒的总广告成本约为 150 美元。
• AMS 经理点击付款请求，并将估算金额连同付款请求发送给 Amazon 经理。
• 然后 Amazon 经理登录到广告状态并确认付款请求，他/她会按照所有详细信息进行付款，然后点击提交和付款。
• 一旦 Rediff 的 AMS 经理收到款项，他/她就会在 Rediffmail 的主页上为特定日期和时间设置广告。

各种系统测试场景如下

场景 1：第一个测试是一般场景，如上所述。测试工程师将对 Amazon 经理创建广告请求并在特定日期和时间使用该广告的底层情况进行系统测试。

场景 2：假设 Amazon 经理认为广告空间太贵并取消了请求。同时，Flipkart 请求在 1 月 26 日上午 10:00 的广告空间。那么 Amazon 的请求已被取消。因此，Flipkart 的促销广告必须安排在 1 月 26 日上午 10 点。

毕竟，请求和付款都已完成。现在，如果 Amazon 改变主意，他们愿意支付 1 月 26 日上午 10 点的费用，那么应该给予，因为 Flipkart 已经使用了那个空间。因此，必须为 Amazon 打开另一个日历来进行预订。

场景 3：在此场景中，我们首先以 AMS 经理身份登录，然后点击“设置价格”页面，并将注销页面的广告空间价格设置为每秒 10 美元。

然后以 Amazon 经理身份登录，选择要在 Rediffmail 注销页面上投放广告的日期和时间。10 秒广告的费用应为 100 美元。

注意：通常，每个测试工程师只对其分配的模块进行功能、集成和系统测试。

正如我们在下图中所见，我们有三个不同的模块，如贷款、销售和透支。这些模块将由其指定的测试工程师进行测试，因为如果这些模块之间存在数据流或场景，我们需要弄清楚数据流向哪个模块，并且该测试工程师应检查该内容。

让我们假设在这里我们正在对利息估算进行系统测试，其中客户是首次以及第二次使用透支。

在此特定示例中，我们有以下场景

场景 1

• 首先，我们将以用户 P 的身份登录，申请 15000 卢比的透支，点击申请，然后退出。
• 之后，我们将以经理的身份登录并批准 P 的透支，然后退出。
• 再次以 P 的身份登录并检查透支余额；应存入 15000 卢比，然后退出。
• 将服务器日期修改为接下来的 30 天。
• 以 P 的身份登录，检查透支余额为 15000 + 300 + 200 = 15500，然后退出
• 以经理身份登录，点击存款，并存入 500 卢比，然后退出。
• 以 P 的身份登录，偿还透支金额，并检查透支余额，该余额为零。
• 申请相当于两个月工资的透支。
• 由经理批准，金额已入账，并且对于首次办理，将收取处理费。
• 登录用户 → 主页 [贷款、销售、透支] → 透支页面 [透支金额、申请透支、偿还透支] → 申请
• 登录经理 → 主页 [贷款、销售、透支] → 透支页面 [透支金额、申请透支、偿还透支、批准透支] → 批准页面 → 批准申请。
• 以用户 P 身份登录 → 主页 [贷款、销售、透支] → 透支页面 [透支金额、申请透支、偿还透支] → 已批准透支 → 透支金额
• 以用户 P 身份登录 → 主页 [贷款、销售、透支] → 透支页面 [透支金额、申请透支、偿还透支] → 偿还透支 → 包含手续费 + 利息金额。

场景 2

现在，我们测试替代场景，其中银行提供一项优惠，即首次申请 45000 卢比透支的客户将不收取手续费。当客户第三次选择另一笔透支时，将不退还手续费。

我们必须测试第三个场景，其中客户首次申请 45000 卢比的透支，并验证在申请第三次透支后，透支偿还的余额。

情况 3

在此场景中，我们将反映出该应用程序被所有客户普遍使用，突然银行决定将新客户的处理费降至 100 卢比，我们必须测试新客户的透支，并检查它是否仅接受 100 卢比。

但随后我们遇到了需求冲突，假设客户申请 15000 卢比的透支，当前手续费为 200 卢比。在经理批准之前，银行将手续费降至 100 卢比。

现在，我们必须测试待处理客户的透支将收取什么手续费。测试团队不能做任何假设，他们需要与业务分析师或客户沟通，找出他们在这些情况下的需求。

因此，如果客户提供了第一组需求，我们必须提出尽可能多的场景。

系统测试的类型

系统测试分为 50 多种类型，但软件测试公司通常使用其中的一些。它们列在下面

回归测试

回归测试在系统测试下执行，以确认和识别系统中是否存在由于系统其他部分修改而引起的缺陷。它确保在开发过程中所做的任何更改都没有引入新缺陷，并保证；随着时间的推移添加新软件，旧缺陷将不会存在。

有关回归测试的更多信息，请参阅以下链接

regression-testing

负载测试

负载测试在系统测试下执行，以弄清楚系统是否能在实际负载下工作。

功能测试

对系统进行功能测试，以查找系统中是否存在任何缺失的功能。测试人员列出系统中应有的关键功能，这些功能可以在功能测试期间添加，并应提高系统的质量。

恢复测试

系统恢复测试在系统测试下执行，以确认系统的可靠性、可信度、责任制，所有这些都依赖于系统的恢复能力。它应该能够成功地从所有可能的系统崩溃中恢复。

在此测试中，我们将测试应用程序以检查它在崩溃或灾难后的恢复能力。

恢复测试包含以下步骤

• 软件崩溃时，不应消失，而应写入崩溃日志消息或错误日志消息，其中应提及崩溃的原因。例如：C://Program Files/QTP/Cresh.log
• 在消失之前，它应该自行终止进程。例如，在 Windows 中，我们有任务管理器来显示正在运行的进程。
• 我们将引入错误并使应用程序崩溃，这意味着有人会告诉我们应用程序何时以及如何崩溃。或者通过经验，在参与产品工作几个月后，我们可以了解应用程序何时以及如何崩溃。
• 重新打开应用程序；应用程序必须以之前的设置重新打开。

例如：假设我们正在使用 Google Chrome 浏览器，如果停电了，那么我们打开系统并重新打开 Google Chrome，我们会收到一条消息，询问我们是否要开始新会话或恢复上一会话。对于任何已开发的产品，开发人员都会编写一个恢复程序，描述软件或应用程序崩溃的原因，是否写入了崩溃日志消息等。

迁移测试

执行迁移测试以确保在需要将系统迁移到新基础设施时，应无问题地完成迁移。

可用性测试

此测试的目的是确保系统对用户非常熟悉，并且能够实现其预期目标。

有关可用性测试的更多信息，请参阅以下链接

usability-testing

软件和硬件测试

此系统测试旨在检查硬件和软件的兼容性。硬件配置必须与软件兼容才能无问题地运行。兼容性通过硬件和软件之间的交互提供灵活性。

为什么系统测试很重要？

• 系统测试提供了对系统性能的百分之百保证，因为它涵盖了系统的端到端功能。
• 它包括对系统软件架构和业务需求的测试。
• 它有助于在生产后减轻现场问题和错误。
• 系统测试使用现有系统和新系统将相同的数据输入到两者中，然后比较新增功能和现有功能的差异，用户就可以了解系统中新增功能的优势。

测试任何应用程序

在这里，我们将测试Gmail应用程序，以了解功能测试、集成测试和系统测试是如何工作的。

假设我们需要测试Gmail应用程序的登录、撰写、草稿、收件箱、已发送邮件、垃圾邮件、聊天、帮助、注销等模块。

我们首先对所有模块进行功能测试，然后才能执行集成测试和系统测试。

在功能测试中，我们至少有一个模块用于执行功能测试。所以在这里我们有撰写模块，我们在其中执行功能测试。

撰写

撰写模块的不同组件是收件人、抄送、密送、主题、附件、正文、发送、保存到草稿、关闭。

• 首先，我们将对收件人进行功能测试

• 对于CC和BCC组件，我们将使用与收件人组件相同的输入。
• 对于主题组件，我们将输入以下输入和场景

• 最大字符数
• 最小字符数
• Flash 文件 (GIF)
• 表情符号
• 格式
• 空白
• 复制粘贴
• 超链接
• 签名

• 对于附件组件，我们将借助以下场景来测试该组件。
  • 最大文件大小
  • 不同的文件格式
  • 文件总数
  • 同时附加多个文件
  • 拖放
  • 无附件
  • 删除附件
  • 取消上传
  • 查看附件
  • 浏览器不同位置
  • 附加已打开的文件
• 对于发送组件，我们将填写整个字段并点击发送按钮，并且必须显示确认消息；消息已成功发送。
• 对于保存到草稿组件，我们将填写整个字段并点击保存到草稿，并且必须显示确认消息。
• 对于取消组件，我们将填写所有字段并点击取消按钮，窗口将关闭或移动到保存到草稿，或者所有字段都必须刷新。

完成撰写模块的功能测试后，我们将对 Gmail 应用程序的各个模块进行集成测试

登录

• 首先，我们将输入用户名和密码登录应用程序，并在主页上检查用户名。

撰写

• 撰写邮件，发送，并在已发送邮件中（发件人）检查邮件
• 撰写邮件，发送，并在收件人（收件箱）中检查邮件
• 撰写邮件，发送，并在自己（收件箱）中检查邮件
• 撰写邮件，点击保存到草稿，并在发件人草稿中检查。
• 撰写邮件，发送到无效 ID（有效格式），并检查未送达的消息。
• 撰写邮件，关闭，并在草稿中检查。

收件箱

• 选择邮件，回复，并在已发送邮件或收件人收件箱中检查。
• 选择收件箱中的邮件进行回复，保存为草稿，并在草稿中检查。
• 选择邮件，然后删除它，并在垃圾箱中检查。

已发送邮件

• 选择邮件，已发送邮件，回复或转发，并在已发送邮件或收件人收件箱中检查。
• 选择邮件，已发送邮件，回复或转发，保存为草稿，并在草稿中验证。
• 选择邮件，删除它，并在垃圾箱中检查。

草稿

• 选择电子邮件草稿，转发，并在已发送邮件或收件箱中检查。
• 选择电子邮件草稿，删除，并在垃圾箱中验证。

聊天

• 与收件人收件箱中保存的离线用户聊天。
• 与用户聊天，并在聊天窗口中进行验证。
• 与用户聊天，并在聊天记录中进行检查。

注意：在测试期间，我们需要等待一定的时间，因为只有当所有模块都准备就绪并执行了功能和集成测试后，才能进行系统测试。