各种测试用例简要模板
0 . 文档介绍
提示：请用户根据项目的实际测试状况，裁剪本测试用例模板。
0.1 文档目的
0.2 文档范围
0.3 读者对象
0.4 参考文献
提示： 列出本文档的所有参考文献（可以是非正式出版物），格式如下：
[ 标识符 ] 作者，文献名称，出版单位（或归属单位），日期
例如：
[ AAA ] 作者，《立项建议书》，机构名称，日期
[ SPP-PROC-ST ] SEPG，系统测试规范，机构名称，日期
0.5 术语与缩写解释
缩写、术语 解 释
SPP精简并行过程， Parallel Process
…
1 . 接口－路径测试用例
1 .1 被测试对象（单元）的介绍
1.2 测试范围与目的
1 . 3 测试环境与测试辅助工具的描述
1.4 测试驱动程序的设计
1.5 接口测试用例
接口A的函数原型
输入/动作期望的输出/相应实际情况
典型值…
边界值…
异常值…
接口B的函数原型
输入/动作期望的输出/相应实际情况
典型值…
边界值…
异常值…
…
1.6 路径测试的检查表
检查项 结论
数据类型问题
（1）变量的数据类型有错误吗？
（2）存在不同数据类型的赋值吗？
（3）存在不同数据类型的比较吗？
变量值问题
（1）变量的初始化或缺省值有错误吗？
（2）变量发生上溢或下溢吗？
（3）变量的精度不够吗？
逻辑判断问题
（1）由于精度原因导致比较无效吗？
（2）表达式中的优先级有误吗？
（3）逻辑判断结果颠倒吗？
循环问题
（1）循环终止条件不正确吗？
（2）无法正常终止（死循环）吗？
（3）错误地修改循环变量吗？
（4）存在误差累积吗？
内存问题
（1）内存没有被正确地初始化却被使用吗？
（2）内存被释放后却继续被使用吗？
（3）内存泄漏吗？
（4）内存越界吗？
（5）出现野指针吗？
文件I/O问题
（1）对不存在的或者错误的文件进行操作吗？
（2）文件以不正确的方式打开吗？
（3）文件结束判断不正确吗？
（4）没有正确地关闭文件吗？
错误处理问题
（1）忘记进行错误处理吗？
（2）错误处理程序块一直没有机会被运行？
（3）错误处理程序块本身就有毛病吗？如报告的错误与实际错误不一致，处理方式不正确等等。
（4）错误处理程序块是“马后炮”吗？如在被它被调用之前软件已经出错。
…
2. 功能测试用例
2 .1 被测试对象的介绍
2 .2 测试范围与目的
2. 3 测试环境与测试辅助工具的描述
2 .4 测试驱动程序的设计
2 .5 功能测试用例
功能A描述
用例目的
前提条件
输入/动作期望的输出/相应实际情况
示例：典型值…
示例：边界值…
示例：异常值…
功能B描述
用例目的
前提条件
输入/动作期望的输出/相应实际情况
……
3. 健壮性测试用例
3 .1 被测试对象的介绍
3 .2 测试范围与目的
3. 3 测试环境与测试辅助工具的描述
3 .4 测试驱动程序的设计
3 .5 容错能力 / 恢复能力测试用例
异常输入/动作容错能力/恢复能力造成的危害、损失
示例：错误的数据类型…
示例：定义域外的值…
示例：错误的操作顺序…
示例：异常中断通信…
示例：异常关闭某个功能…
示例：负荷超出了极限…
4 . 性能测试用例
4 .1 被测试对象的介绍
4 .2 测试范围与目的
4. 3 测试环境与测试辅助工具的描述
4 .4 测试驱动程序的设计
4 .5 性能测试用例
性能A描述
用例目的
前提条件
输入数据期望的性能（平均值）实际性能（平均值）
性能B描述
用例目的
前提条件
输入数据期望的性能（平均值）实际性能（平均值）
……
5 . 图形用户界面测试用例
5 .1 被测试对象的介绍
5 .2 测试范围与目的
5. 3 测试环境与测试辅助工具的描述
5 .4 测试驱动程序的设计
5 .5 测试人员分类
类别特征
A类
B类
……
5.6 用户界面测试的检查表
检查项测试人员的类别及其评价
窗口切换、移动、改变大小时正常吗？
各种界面元素的文字正确吗？（如标题、提示等）
各种界面元素的状态正确吗？（如有效、无效、选中等状态）
各种界面元素支持键盘操作吗？
各种界面元素支持鼠标操作吗？
对话框中的缺省焦点正确吗？
数据项能正确回显吗？
对于常用的功能，用户能否不必阅读手册就能使用？
执行有风险的操作时，有“确认”、“放弃”等提示吗？
操作顺序合理吗？
有联机帮助吗？
各种界面元素的布局合理吗？美观吗？
各种界面元素的颜色协调吗？
各种界面元素的形状美观吗？
字体美观吗？
图标直观吗？
…
6. 信息安全性测试用例
6 .1 被测试对象的介绍
6 .2 测试范围与目的
6. 3 测试环境与测试辅助工具的描述
6 .4 测试驱动程序的设计
6 .5 信息安全性测试用例
假想目标A
前提条件
非法入侵手段是否实现目标代价－利益分析
……
假想目标B
前提条件
非法入侵手段是否实现目标代价－利益分析
……
7. 压力测试用例
7 .1 被测试对象的介绍
7 .2 测试范围与目的
7. 3 测试环境与测试辅助工具的描述
7 .4 测试驱动程序的设计
7 .5 压力测试用例
极限名称A 例如“*并发用户数量”
前提条件
输入/动作输出/响应是否能正常运行
例如10个用户并发操作
例如20个用户并发操作
…
极限名称B
前提条件
输入/动作输出/响应是否能正常运行
…
8. 可靠性测试用例
8 .1 被测试对象的介绍
8 .2 测试范围与目的
8. 3 测试环境与测试辅助工具的描述
8 .4 测试驱动程序的设计
8 . 5 可靠性测试用例
任务A描述
连续运行时间
故障发生的时刻故障描述
……
统计分析
任务A无故障运行的平均时间间隔（CPU小时）
任务A无故障运行的最小时间间隔（CPU小时）
任务A无故障运行的*时间间隔（CPU小时）
任务B描述
连续运行时间
故障发生的时刻故障描述
……
统计分析
任务B无故障运行的平均时间间隔（CPU小时）
任务B无故障运行的最小时间间隔（CPU小时）
任务B无故障运行的*时间间隔（CPU小时）
9. 安装 / 反安装测试用例
9 .1 被测试对象的介绍
9 .2 测试范围与目的
9. 3 测试环境与测试辅助工具的描述
9 .4 测试驱动程序的设计
9 . 5 安装 / 反安装测试用例
配置说明
安装选项描述是否正常使用难易程度
全部
部分
升级
其它
反安装选项描述是否正常使用难易程度
附录：评审意见
想快速又简单地编写测试用例？看这里！
本文适用对象
初级软件测试人员，或想开拓思路拓展测试范围、提高测试覆盖率的所有测试人员等等。
本文目的
讲述如何快速、简单、有效、有条理地编写一条测试用例，并帮助测试人员从测试用例角度拓展测试思路。
如何简单、快速地
描述（编写）一个测试用例
测试用例的目的在于指导、帮助测试人员按照既定的计划步骤执行测试，并比对测试结果与预期结果是否一致。
对于中大型软件公司而言，测试用例的管理都有既定的规范和工具，如表格管理用例、测试管理软件管理用例（如下图1所示为测试管理软件用例编写页面）等。
但总而言之，测试用例的内容主要不外乎3个部分：前置条件、步骤、预期结果。
那么，对于没有明确地测试管理软件的小型软件公司，或者对于测试人员而言，需要暂时快速地编写一个测试用例或记录测试过程的时候，可以怎么做呢？
推荐一个临时性的用例编写模板：GIVEN...WHEN…THEN。
让我们套用GIVEN…WHEN…THEN的模式来描述下编写用例的大致步骤：
有没有觉得很简单？
让我们再用实际案例，描述下如何用GIVEN…WHEN…THEN模板编写真实用例。以测试访问 链接这个用例为例1：
使用GIVEN…WHEN…THEN能够简单呈现用例前置条件、执行步骤和预期结果间的逻辑关系，并能清晰地表述一个用例。
那么，什么地方可以用GIVEN…WHEN..THEN这个模板呢？这个模板较之文档用例更为简洁，如下图2所示，对于测试用例提交故障，阐述引发故障的操作方法或故障复现方法，以及故障修复后的验证时都可以使用。
如何使用探索式场景联想法
衍生测试用例
探索式测试更多的是一种测试风格和测试思想，要求测试人员在测试过程中不断思考、发散思维，记录、修改和更新测试方法和测试用例。
场景法则是要求测试人员认真分析测试需求，了解用户使用场景，根据不同的场景进行测试。
而本文讨论的 探索式场景联想法，则是将探索式测试方法、场景法和联想法相结合，在已有测试用例的基础上衍生更多的测试用例。
那么，如何使用探索式场景联想法衍生测试用例呢？
由上一节可知，测试用例是指导测试人员在xx预知条件（场景）下，执行xx步骤，预期得到xx结论。
显而可见，通过改变测试用例的预知条件和操作步骤，则可以衍生出不同的测试用例。而这些测试用例包含不同的测试场景和不同的测试步骤。
如下图3所示，为探索式场景联想法衍生测试用例的结构脑图。
改变前置条件
测试用例的前置条件基本包括：硬件资源和软件系统两个部分。
改变前置条件可以从这几方面入手。
以上节的访问 链接用例1为例，改变前置条件衍生新的测试用例。由于该用例的前置条件较简单，改变前置条件只需改变浏览器类型和版本即可。
由此，衍生的部分测试用例可如下所示：
改变操作步骤
改变用例操作步骤可以从以下几方面入手：插入步骤、删除步骤、改变步骤和重复步骤。
插入步骤
如图3所示，插入步骤又可以分为插入相关联步骤和不相关联步骤。并在插入步骤中增加用户输入。
同样以用例1为例，插入步骤衍生的测试用例可如下：
删除步骤
删除步骤可以分为删除部分步骤或者删除部分步骤中的部分操作。删除部分步骤，又可以分为删除关键步骤和非关键步骤。
例如，以例1为例，删除关键步骤“点击键盘回车键“衍生新的测试用例如下所示：
改变步骤
改变步骤主要涉及步骤顺序的改变和步骤内容的改变。当测试用例具有多个步骤，且步骤间具有关联性和顺序性的时候，改变步骤顺序则会变得很有意义。改变步骤内容主要是改变步骤中用户的输入（包括数据输入、用户操作等）。
以用例1为例，改变步骤内容衍生的用例如下所示：
重复步骤
对于大多测试人员来说，衍生测试用例时更多关注点在于操作步骤的变化。
但是，对于不同的测试场景，重复相同的测试步骤，仍然具有很大的测试意义。重复步骤进行测试能够挖掘不同前置条件（场景）下的故障，亦能挖掘软件在多个重复步骤操作下潜藏的故障。
以用例1为例，重复步骤衍生的用例如下所示：
测试结论衍生测试用例
除了通过改变前置条件和操作步骤衍生测试用例外，还可以根据测试结论中的异常信息，逆推测试场景，衍生新的测试用例。
这个部分更多的需要测试人员掌握探索式测试方法，对测试过程中的软件资源监控信息、错误日志等保持警惕性，挖掘错误信息中的内容，逆推产生错误信息的原因，构建新的测试用例。
小结
本文阐述了一种可以在提交测试故障信息和验证测试故障时使用的快速测试用例编写模板，快速记录测试场景、测试步骤等关键信息。
并在此基础上，简单讲解了基于探索式场景联想法的测试用例衍生方法，可以帮助测试人员借助已有的测试用例拓展新的测试用例，扩大测试范围，提高覆盖率，挖掘更多场景下的软件故障。
转自公众号投稿：
2021年Web前端工程师的学习建议
今天小编要跟大家分享的文章是关于2021年web前端工程师的学习建议。毫无疑问，前端开发将成为2021年技术领域最热门的*之一。
以前，前端空间的开发人员只要了解一些HTML，CSS，也许还有jQuery来创建交互式网站，就足够了。但是今天，他们面临着广泛且不断变化的开发技能生态系统;掌握的工具，库和框架;并且需要不断投资于个人教育。
最近几年，我们使用为主要的Web应用程序提供了强大的新库和框架，例如ReactJS，VueJS和Svelte。想要学习web前端知识的小伙伴们来和小编一起看一看吧!
1.框架
2021年，我们可能会看到Facebook的ReactJS与社区驱动的VueJS之间的对决。目前，React在GitHub上拥有140,000星，而Vue则拥有153,000星。例如，Angular只有53,000个恒星。
在2021年，React(蓝线)，Vue(红线)，Angular(黄线)和Svelte(绿线)的搜索量支持此假设-Vue略高于React。Angular在搜索量方面无法跟上，Svelte在此比较中绝对不起作用。
因此，对于2021年，使用或希望使用框架的前端开发人员应将React和Vue作为他们的主要选择。如果您正在处理大型企业项目，则Angular是有效的选择。
2.静态网站生成器
静态站点生成器结合了服务器端渲染的功能(对于SEO非常重要，而且还具有初始加载时间)和单页应用程序。
如今，许多项目即使不需要服务器端渲染也选择了SSG，因为Next或Nuxt之类的解决方案具有便捷的功能，例如模块捆绑器，集成测试运行器等。
如果您认真对待前端开发，则应仔细研究以下项目，并尝试获得一些实践经验：
·Next(基于React)
·Nuxt(基于Vue)
·Gatsby(基于React)
·Gridsome(基于Vue)
3.JAMstack
术语JAMstack代表(在客户端上运行-例如，React，Vue或VanillaJS)，API(服务器端进程通过通过HTTPS抽象并访问)和标记(在部署时预先构建的模板标记)。。
这是一种构建网站和应用程序以提高性能的方法-降低扩展成本，提供更高的安全性并提供更好的开发人员体验。
尽管这些术语本身并不是什么新鲜事物，但它们的共同点是相同的-它们并不依赖于Web服务器。因此，依赖于Ruby或Node.js后端或使用服务器端CMS(例如Drupal或WordPress)构建的网站的单片应用程序不是使用JAMstack构建的。
如果要使用JAMstack，有一些*实践：
整个项目都在CDN上提供服务
由于不需要服务器，因此整个项目都可以通过CDN进行服务，从而释放出无与伦比的速度和性能。
一切都存在于在Git中
每个人都应该能够从Git存储库克隆整个项目，而无需数据库或复杂的设置。
自动化构建
您可以完美地自动构建，因为所有标记都是预先构建的，例如使用webhooks或云服务。
原子部署
为了通过在大型项目中重新部署数百或数千个文件来避免出现不一致的状态，原子部署将等待所有文件上传，然后再进行更改。
即时缓存失效
当站点上线时，必须确保CDN可以处理即时缓存清除，以使更改可见。
像Netlify或Zeit这样的著名主机都支持JAMstack应用程序，大公司使用它们为用户提供出色的体验。
4.PWA
渐进式Web应用程序(PWA)无疑将在2021年成为现实。越来越多的公司选择PWA取代本机应用程序，以便为用户提供丰富的移动体验。
PWA可靠(即时加载，无需连接互联网即可工作)，快速(流畅的动画，对用户交互的快速响应)和吸引人的体验(本机应用程序的感觉，出色的用户体验)。
他们利用服务人员提供脱机功能，并利用Web应用清单文件提供全屏体验。
构建渐进式Web应用程序的原因有：
·可以从浏览器添加到用户的主屏幕
·即使没有互联网也能正常工作
·支持网络推送通知以增强用户参与度
·利用Google的功能
5.GraphQL
GraphQL是当前最热门的主题之一，并且绝对是您在2021年需要学习或改进的东西。
尽管REST通过提供无状态服务器之类的出色概念一直被认为是设计WebAPI的事实上的标准，但在跟上快速变化的客户端访问RESTful
API时，却越来越不灵活。
GraphQL由Facebook开发，旨在解决开发人员在处理时面临的确切问题。
使用RESTAPI，开发人员可以通过从具有特定目的的多个端点(例如/users/端点或/tours//
location端点)中获取数据来收集数据。
使用GraphQL，这将以不同的方式工作。开发人员会将查询与他们的数据要求一起发送到GraphQL服务器。然后，服务器将返回带有所有相应数据的JSON对象。
使用GraphQL的另一个好处是它使用了强类型系统。GraphQL服务器上的所有内容都是使用GraphQL模式定义语言(SDL)通过模式定义的。创建架构后，前端开发人员和后端开发人员都可以彼此独立地工作，因为他们知道已定义的数据结构。
6.代码编辑器/IDE
与2021年一样，微软的VSCode将在2021年成为大多数前端工程师的*编辑器。
它提供几乎类似于IDE的功能，例如代码自动完成和语法高亮显示，并且可以通过其扩展市场进行几乎无限的扩展。
特别是市场使VSCode如此出色。以下是您作为前端开发人员的一些出色扩展：
·(ES6)代码段
·npm
·beautify
·CSS速览
·ESLint
·LiveSass编译器
·Chrome调试器
这些是很酷的例子。在VSCode中还有很多可以发现的地方，因此，如果您尚未使用它，我建议您尝试一下。
7.测试
未经测试的代码不应找到它的生产方式。
在您的个人项目中似乎没有任何测试似乎很方便，但在商业和企业环境中工作时必须进行测试。因此，对于任何开发人员而言，*尽可能将测试集成到开发工作流程中。
可以区分以下测试用例：
单元测试
隔离测试单个组件或功能。
整合测试
测试组件之间的交互。
端到端测试
在浏览器中测试功能完善的用户流。
有更多测试方法，例如手动测试，快照测试等。如果您想升任高级开发人员职位或打算在拥有某些开发标准的大型公司工作，则应尝试进行测试技能。
8.干净的代码
能够编写干净的代码是一项很棒的技能，许多组织都对此提出了很高的要求。如果您想从开发人员的位置升级为高级开发人员的位置，则应真正学习干净代码的概念。
简洁的代码应优雅且易于阅读。它应该重点突出，您应该注意这一点。所有测试均以纯净代码运行。它们不应包含重复项，应尽量减少使用实体(例如类，方法和函数)。
干净代码开发人员应做的一些事情是：
·为变量，类，方法和函数创建有意义的名称
·函数应该很小并且参数应尽可能少
·根本不需要注释-代码应该说明一切
如果您想了解有关干净代码检查的更多信息，请阅读RobertC.Martin的书籍和帖子。
9.Git
毫无疑问，Git是当今Web开发中版本控制的标准。对于每个前端工程师而言，了解基本的Git概念和工作流程以在各种规模的团队中有效工作都是非常重要的。
这是您应该知道的一些流行的Git命令：
gitconfig
gitinit
gitclone
gitstatus
gitadd
gitcommit
gitpush
gitpull
gitbranch
知道这些命令可以提高工作效率总是很高兴的，但是前端工程师还应该学习Git的基本概念。
10.软技能
对于开发人员来说，经常被忽视但确实非常重要的是获得软技能。
虽然有助于了解事物的技术方面，但了解如何在团队中进行交流也同样重要。如果您对技术职业很认真，并且/或者打算升任高级职位，则应该从事以下软技能方面的工作：
同情
沟通
团队合作
平易近人和乐于助人
忍耐
开放的思想
解决问题
责任心
创造力
时间管理
永远记住：开发人员最重要的交付物是高级开发人员。(提升你自己)
结论
在本文中，小编向您展示了前端开发人员应在2021年尝试学习，改进或掌握的10项重要内容。想要了解更多web前端相关知识记得关注北大青鸟web前端培训官网，*祝愿小伙伴们工作顺利，成为一名优秀的web前端工程师。
如何设计一个完整的测试用例
测试用例的设计一般从分析需求设计说明书开始，了解开发人员设计这个项目的思路、设计的要求、实现的功能等（*有use case，这样看起来更清晰）。软件测试的W模型，就要求测试与开发同步，在开发设计需求设计说明书的时候就开始测试流程，一般情况下，讨论需求设计的时候需要测试主管或者组员的参与，了解这个项目设计的总体情况。事实上，测试用例的编写一般是在需求设计说明书定下来之后才真正的开始的。因为测试用例的内容要以需求设计说明书为依据，设计说明书上没体现的功能，不需要在测试用例中体现。编写测试用例（这里指功能测试用例的编写），首先要做的就是设计测试用例的模板。每个公司都有适合自己公司用例编写的模板，各有各的特点。测试用例的格式包括，测试用例摘要、测试用例需求编号（一个需求设计说明书可以分好几个用例编写）、编写用例的日期、编写人员、编写日期、前置条件、准备数据等等。格式没有固定的要求，可以根据自己测试用例设计的思路，对测试用例的格式作相应的改变。下面以一个登陆窗口为例，说说我设计登陆界面的思路和方法。我把这个测试用例分为三层结构，表单测试、逻辑判断、业务流程。*层，表单测试为*层（最基础的）。这部分的测试用例是对登陆窗口这个界面的输入框、按钮功能、界面等最基本功能的测试。一般来说登陆用户名和登陆用户密码是输入框的形式体现，那么，我们需要的是针对这两个输入框进行功能的测试。这时，我们只要考虑这个输入框的功能，而不需要考虑业务方面的内容。这样，我们考虑就是这个输入框的长度限制是多少？能否输入特殊字符？能否输入全角字符？当然，登陆窗口还有其他按钮，例如登陆按钮、退出按钮、界面设计等，这一层的测试用例只对他们最简单的功能的测试。我觉得这一层的测试用例对新开发项目很重要，也必须执行，因为这些是最基本的功能保证，当项目进入维护阶段后，如果没有修改就不需要执行这部分的测试了或者说把这层的用例优先级置为*，时间不充足的情况就不用去执行。第二层，逻辑判断层。根据需求的设计，各功能之间的简单逻辑联系。以登陆窗口为例，账号登录，账号和密码必须对应才能登录，否则登录失败。根据这一点，我们就可以从这个要求设计这一层测试用例。例如，账号和密码不一致时；账号为空时；密码为空时；账号密码对应时等等情况。输入这些情况时，程序是作怎么样的逻辑控制的？控制是否正确？是否有相应的提示信息？我觉得，这一层的用例时最常规的一层，平时使用这个软件用经常碰到的一些情况，在常规测试或修改这部分的功能之后，这一部分的测试用例也必须执行。第三层，业务流程层。这部分不关心软件的本身的基本功能，而是关心这个软件的业务有没有实现，不同的需求就有不同的业务需求。以登陆窗口为例，就可能有不同的需求，可能用户要求停用的账号能够登录系统（可能要求登录后不允许进行其他操作），也可能用户直接要求停用的用户账号不准登录系统。根据不同的业务需求，就有不同的业务流程。这样这层的测试用例，我们就只要考虑业务需求，仍然以登录窗口为例，我们就只要考虑删除的用户能否登录？停用的用户能否登录？超级用户是如何登录的？普通用户是何种方式登录的？简单的说，这层的用例只描述业务流程，不关心具体这个业务是怎么实现的，执行这部分用例时，不要考虑哪个输入框控制了多少长度，能否输入空格等其他功能，因为这部分的测试需要基于上面两层的测试用例都已经测试通过了，所以在项目维护阶段或者说时间很紧迫的阶段，我们只需要执行这部分的用例，保证业务能够通畅的完成。其实个人觉得在执行这部分用例时，对包含了对基本功能的测试，一些明显的问题应该能被发现，虽然严格来说测试覆盖率很低，但是基本能达到要求。这三层的组合起来才是一个完整的测试用例。这是我个人对测试用例设计的一个思路和方法。真正设计这个测试用例的时候，可能会使用到黑盒测试用例的方法，例如等价类划分、边界值分析、错误猜测法（主要是个人经验）、正交分解等方法针对具体情况设计测试用例。分层测试用例的思路主要来自对自动测试实现的考虑。因为我觉得，如果需要实现自动化测试就必须对测试用例进行细分，划分得越细就越有利于自动化的实现。以上三层的划分也并不是很全面，需要在实践中不断完善，例如可以增加对数据库的部分功能的数据校验的分析。总之，测试用例写的细致、全面、步骤清晰，那么无论是用手工测试的方法还是用自动化测试的方法实现，只要能完整的跑完整个测试用例，就达到了测试的目标了。
Katalon Studio之web自动化（二）---创建测试用例
测试使用的用户肯定一般不止一个，可通过参数来传递，方便后续可以通过输入不同的用户信息登录。
在Variables页面添加变量，选择变量类型，并填入变量的默认值即可
点击输入框，跳出对话框，选择value_type为Variable，然后在Value选择相应的变量即可
在测试用例中添加item时，通过add,选择call test case
添加测试用例后，默认展示默认值
通过点击输入，修改变量的输入值
当然可以进行多次调用，例如用户A、B有不同的操作，不同的测试用例，就可以创建很多公用的登录用例login_A或login_B，引用时直接引用login_A或login_B即可，这样方便后续修改用户A的密码或者切换用户A1执行与A相同的用例时，就可以直接修改login_A的输入值即可，就不需要修改每个用例的用户名和密码了。
在调用用例后，系统会自动往下执行。
当需要在不同用例间传参时，可以使用全局变量。
1.增加全局变量
在Profiles下的default中，添加全局变量即可。
2.引用全局变量
关键字可参考官方文档： [WebUI] Accept Alert | Katalon Docs
Katalon Studio支持 控制语句 （如 If / Else ， for / while 或 Try / Catch …）来决定执行的逻辑流程，具体也可以参考官方文档： Control | Katalon Docs
断言语句包含一个 布尔表达式 ，其中此条件必须为true才能继续执行测试。因此，断言的执行导致对 布尔表达式 的求 值， 并且如果表达式的求值为 false， 则会报告 错误 。
Assert | Katalon Docs
“ 测试侦听器” 是根据您自己的条件创建的测试步骤，将在条件匹配时执行。
Test Listeners (Test Hooks) | Katalon Docs
至此 ，可以完成基本的测试用例，其他可以继续参考文档学习。
