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