自动化测试用例如何编写

自动化测试用例编写包括：1. 设计原则；2. 选型原则；3. 转型原则。其中，测试用例是一个完整的场景。从用户登录系统到用户退出。测试用例只验证一个功能点。不要试图用户登录后验证所有的功能点再退出。

一、自动化测试用例编写

1. 设计原则

a、测试用例是一个完整的场景。从用户登录系统到用户退出。

b、测试用例只验证一个功能点。不要试图用户登录后验证所有的功能点再退出。

c、测试用例尽量只做正向的逻辑验证，正向是指脚本可实现的而非主观操作。逆向逻辑的情况很多，验证比较复杂，需要编写大量的脚本，投入成本比较高。

d、测试用例之间不要产生关联，也就是说每个测试用例是独立，不能依赖或影响其他测试用例，要求高内聚低耦合。

e、测试用例需要更多的关注功能逻辑的实现，而不必纠结某些字段的限制。

f、测试用例的上下文必须有一定的顺序性，要能够互相连接起来；并且前置条件要清楚。

g、测试用例中检查点的设置（根据测试用例的侧重点设置检测点、设置检测点要全面和设置检测点要灵活）。

h、测试用例要对修改的数据进行还原操作。

i、测试用例必须是可回归的。

2. 选型原则

a、不是所有的手工用例都要转为自动化测试用例。

b、考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分多个用例来实现脚本。

c、选择的用例较好可以构建成场景。例如一个功能模块，分n个用例，这n个用例使用同一个场景。

d、选择的用例可以带有目的性，例如这部分用例是用例做冒烟测试，那部分是回归测试等，当然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。

e、选取的用例可以是你认为是重复执行，很繁琐的部分，例如字段验证，提示信息验证这类。这部分适用回归测试。

f、选取的用例可以是主体流程，这部分适用冒烟测试。

3. 转型原则

a、当前的测试用例前置配置信息要写清楚。

b、每一个步骤都要衔接好，错了，脚本要抛出异常。

c、每一个步骤要做什么，验证什么要写清楚，写具体。有时一个检查点，你只需看一眼，但是脚本要写一堆代码去验证，这样的做法是不可行的。

d、用例之间不要有关联性，自动化测试开发同样是软件开发工程，脚本编写同样提倡高内聚低耦合的理念。

e、不是每一个步骤都需要验证点。

f、别在多个地方重复相同的验证。脚本很忙！我没空。当然，除非有必要。

g、开门记得要关门，配置信息要回归原点，否则脚本要迷路。

延伸阅读：

二、冒烟测试

这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。

以上就是关于自动化测试用例的内容希望对大家有帮助。

最后建议，企业在引入信息化系统初期，切记要合理有效地运用好工具，这样一来不仅可以让公司业务高效地运行，还能最大程度保证团队目标的达成。同时还能大幅缩短系统开发和部署的时间成本。特别是有特定需求功能需要定制化的企业，可以采用我们公司自研的企业级低代码平台：织信Informat。 织信平台基于数据模型优先的设计理念，提供大量标准化的组件，内置AI助手、组件设计器、自动化（图形化编程）、脚本、工作流引擎（BPMN2.0）、自定义API、表单设计器、权限、仪表盘等功能，能帮助企业构建高度复杂核心的数字化系统。如ERP、MES、CRM、PLM、SCM、WMS、项目管理、流程管理等多个应用场景，全面助力企业落地国产化/信息化/数字化转型战略目标。 版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们微信：Informat_5 处理，核实后本网站将在24小时内删除。