自动化测试的使用场景及区别
发表时间：2023-09-16 14:01:14
文章来源：炫佑科技
浏览次数：158
菏泽炫佑科技
自动化测试的使用场景及区别
1. 自动化测试的使用场景
目前自动化测试更多集中在冒烟测试和回归测试； 冒烟测试执行主要功能点的用例。 回归测试执行全部或部分测试用例。 其主要目的是验证问题，而不是发现问题。 因此，自动化的设计主要关注功能的正确性。
其他：
1）冒烟测试：
冒烟测试是在正式测试之前对产品或系统的每个版本或每次需求变更后进行的简单验证性测试。 冒烟测试的目的是在正式测试前验证产品或系统的主要需求或预设条件是否存在Bug。 如何进行冒烟测试？ *好的方法是设计一个自动化测试脚本，并在每次版本更新后执行该脚本进行验证。
2）回归测试：
也就是说，在软件生命周期中，只要软件发生变化，就可能给软件带来问题； 因此，每当软件发生变更时，我们必须重新测试现有的功能，以确定修改是否达到了预期的目的。自动化测试的使用场景及区别，检查修改是否破坏了原有的正常功能。
2. 手动测试用例和自动化测试用例的区别
在自动化测试过程中，关键点是自动化测试设计，包括测试用例设计、测试脚本架构和测试组织。
1）手动测试用例：
A。 可以通过人的逻辑判断来验证当前步骤的功能实现是否正确。 能够更好的处理异常场景。
b. 测试用例的执行具有一定的跳跃能力。
C。 手动测试可以一步步跟踪分析，详细定位问题。
d. 主要用于发现产品缺陷。
2）自动化测试用例：
A。 所有的判断验证都需要通过编写脚本来实现。
b. 测试用例步骤之间需要存在关联。
C。 主要用于保证产品的主要功能正确、完整，使测试人员从繁琐、重复的工作中解放出来。
d. 目前的自动化测试阶段定位于冒烟测试和回归测试。
3. 自动化测试用例设计原则
1）设计误区：
A。 直接编写测试脚本，无需编写测试用例。
b. 直接使用手动测试用例编写自动化测试脚本。
2）设计原则：
A。 测试用例是一个完整的场景。 从用户登录系统到用户退出系统。
b. 测试用例仅验证一个功能点。 不要尝试在用户登录然后注销后验证所有功能点。
C。 测试用例应该尽可能只进行正逻辑验证。 前进是指脚本能够实现什么而不是主观操作。 逆向逻辑的情况较多，验证比较复杂，需要编写大量脚本，投资成本比较高。
d. 测试用例之间不应存在相关性。 也就是说，每个测试用例都是独立的，不能依赖或影响其他测试用例。 要求高内聚、低耦合。
e. 测试用例需要更加关注功能逻辑的实现，而不必担心某些领域的限制。
F。 测试用例的上下文必须有一定的顺序并且能够相互关联； 并且前提条件必须明确。
G。 测试用例中检查点的设置（根据测试用例的重点设置检查点、全面设置检查点、灵活设置检查点）。
H。 测试用例需要恢复修改后的数据。
我。 测试用例必须是可回归的。
4. 手动测试用例和自动化测试用例的组合规则
1）自动化测试用例选择原则：
A。 并非所有手动测试用例都需要转换为自动化测试用例。
b. 考虑到脚本开发的成本，不要选择流程过于复杂的用例。 如有必要，请考虑将流程拆分为多个用例来实现脚本。
C。 所选用例*好构建到场景中。 例如，一个功能模块被分为n个用例，这n个用例使用相同的场景。
d. 选择的用例可以是有目的的，比如这部分用例是冒烟测试，那部分是回归测试等等。当然，会有重叠的关系。 如果当前用例不能满足需求，唯一的选择就是修改用例以适应脚本和需求。
e. 所选用例可以是你认为重复且繁琐的部分，例如字段验证、提示信息验证等。 这部分适合回归测试。
F。 选定的用例可以是主要流程，烟雾测试适合这部分。
2）自动化测试用例改造原则：
A。 当前测试用例预配置信息必须写清楚。
b. 每一步都必须紧密相连。 如果出现问题，脚本必须抛出异常。
C。 每一步应该做什么、应该验证什么自动化软件开发，都要写清楚、具体。 有时候你只需要看一个检查点，但脚本却需要写很多代码来验证，这是不可行的。
d. 用例之间不应存在相关性。 自动化测试开发也是一个软件开发项目，脚本编写也提倡高内聚、低耦合的理念。
e. 并非每个步骤都需要验证点。
F。 不要在多个地方重复相同的验证。 脚本很忙！ 我很忙。 当然，除非有必要。
G。 开门时记得关门，并将配置信息返回原点，否则脚本会丢失。
