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