全国咨询热线：136-9172-9932
不管是市场需求还是测试效率而言，自动化测试都是作为测试工程师需要掌握的一门技术，并且在公司能够逐步的应用到常规的测试中，如回归测试。自动化测试的价值在于它能够有效的检测被测对象的质量并且能够给出有价值的结果信息，而且这个结果需要具备权威性，不需要太多人为的参与与干预。自动化测试最小颗粒度是测试用例，那么我们可以通过这个点来进行切入。在编写的自动化测试用例中需要注意的事项以及测试用例的规范，下面详细阐述这部分。
一、准确性
每个自动化测试用例都必须得有断言并且每个测试用例只验证一个测试场景，没有测试断言的自动化测试用例是没有价值的，也不是一个有效的测试用例。不管是从功能测试角度还是自动化测试角度，这句话都是适用的。对于不同形式的自动化，测试断言的策略是一样的，只不过验证的维度是不一样的。
二、独立性
业务之间是有关联关系的，但是编写的自动化测试用例都必须是独立的，测试用例与测试用例之间不要相互依赖，一旦设计成相互依赖，导致的结果是一个测试用例执行失败，导致后续所有的测试用例执行失败。保持测试用例的独立性遵守如下几个约束。
每个测试用例都测试场景的闭环
每个测试用例都需要考虑初始化操作与清理操作
千万不要刻意的设计具体的测试用例去依赖其他测试用例的业务步骤
根据如上的约束，结合一个具体的案例来说明这部分，假设一个用户管理的系统，具备增删改查的业务功能，并且用户昵称是唯一且不可重复的。编写的测试用例是查询用户信息，初始化与清理操作很好理解，就是添加用户与删除用户，关于第一点完成场景的闭环指的是不管是查询用户还是修改用户的信息，测试用例执行完成后都需要删除用户，这样的目的是不管是QA环境还是线上环境，测试用例执行结束后，都做到没有对系统造成任何的垃圾数据，同时也保持系统的干净性。
三、动态性
特别是在API的测试中由于业务关联性的特点，导致业务流转过程中会有很多的动态数据，这些动态数据在每次业务操作的过程中都是动态变化的，很难使用静态的数据来完成业务的闭环测试。如最常见的是登录认证授权以及业务流转过程中涉及增加数据这部分，它的ID都是数据都是动态性的。
四、完整性
端到端的自动化测试解决方案还是API自动化测试，都需要站在业务驱动模式的基础上来达到测试业务的完整性，这样可以达到两个目的：业务质量保障与测试效率提升。所以针对业务完整性以及业务的覆盖率是非常重要的。这就涉及一个度量，其实针对度量这部分在每个组织都是有各自的考量，核心的是只要这个组织认可这个衡量的标准就可以了。比如经常会被问到的一个话题是自动化测试业务覆盖率是多少?这个就不是自动化测试用例个数多少来衡量，自动化测试用例个数多不代表覆盖率多，那么衡量的标准是什么呢?比如覆盖率=已经实现场景数/总的场景数，这也是度量的一种策略与方式，只要团队认可就可以按照这种策略去执行。
