自动化测试用例的原子性
原子性测试
为了使自动化框架都成功，此概念对于您理解至关重要：原子自动化测试用例不应模仿端到端自动化用例。
取而代之的是，自动化检查应形成一个不可拆分的单元，一个用例只能测试一个功能点。由于测试的颗粒度非常小，这与编写单元测试非常相似。
原子性的测试用例应该是这样的：
- 该测试用例尽可能少地断言，通常只有一个或两个断言。
- 测试避免与UI界面交互，最多只能在两个页面上进行。
在通常情况下，测试颗粒度越小。测试用例就会越复杂，但是将测试设计得尽可能小有很多优点。
原子性测试用例的优点
精准反馈
编写原子性测试可以快速执行得到测试结果。测试报告的反馈是迅速而针对性的。检查功能状态的时间一般都是几秒钟内完成。
对于测试报告中的错误信息，很快能够复现且排查BUG的根源，并迅速解决它。
缩短测试链
如果平均单个测试用例执行的时间能够缩短一半，那么测试效率会提升两倍以上。因为测试的时间越长，误报的可能性越大，随着干扰因素的不断累计，失败的可能也越大。
编写原子测试用例可减少脆弱性，因为它减少了该测试中可能出现的断裂的数量。原子性测试用例能够减少大量误报，这又会促进出现问题的排查时间。
这是一个例子：
- 打开网页主页
- 断言页面已打开
- 断言某个元素存在
- 打开搜索页面
- 搜索文章
- 断言该文章存在
使用自动化测试时，每一个步骤都有概率出现错误。例如，定位器或交互机制可能已更改而同步策略可能已过期。
因此一个自动化测试用例中的步骤越多，测试就越有可能中断并产生误报。
更高的测试覆盖率
编写原子测试的第三个好处是，如果原子测试用例失败，它们将不会阻断其他功能用例的测试。
换句话说，自动化测试用例可以对业务功能进行更全面的检查，而不用担心测试链断裂导致后面的功能无法覆盖。
参考上面提到的测试：如果在步骤断言元素存在中失败，则可能永远无法检查搜索页面或搜索功能是否正常。
若是在回归测试场景中，运行大规模测试用例的时候，原子性的测试用例将减少测试范围。编写原子测试用例的另一个巨大好处是，它们在运行时会更快，因为完全可以进行并行化处理。参考：
通过分布式和多线程技术使用，测试用例执行时间大大减少，测试套件的执行时间可以成倍减少。
拆分UI自动化用例
你可能想知道如何拆分端到端测试用例为原子性用例，这是一个很困难的挑战，特别是对UI测试来讲。参考：所谓UI测试
这是一个简单的场景：
- 打开购物网站首页
- 断言页面打开
- 搜索商品
- 断言已找到商品
- 加入购物车
- 断言已添加商品
- 订单信息补充
- 结算
- 断言订单成功
许多自动化工程师认为这个测试用例必需完整执行整个测试链的流程。例如必须在搜索之前必需打开首页之前，依此类推。原因是，如果购物车中没有商品，又如何才能进入结帐流程？
注入数据
自动化测试最佳实践方法是在UI交互之前注入数据以填充应用程序的状态。
这将极大地帮助测试过程。例如：
您可以通过几个选项控制应用程序的状态：
- 使用
API测试框架的方法将应用程序设置为特定状态 - 使用
JavaScript修改页面 - 将数据注入数据库以将应用程序设置为特定状态
- 使用
cookie信息
如果可以在应用程序的接缝之间插入数据，则可以隔离每个步骤并对其进行单独测试。
要考虑的一些选项：
- 发送网络请求以生成新的测试用户
- 发送网络请求以填充购物车中的商品
- 使用
Selenium打开浏览器到购物车页面 - 使用网络自动化执行结帐
- 之后清理所有测试数据
使用HTTP接口
使用API测试与在每个测试步骤中使用自动化的GUI相比，它的功能更加强大且速度更快。
例如，一个HTTP请求可以在大约几十毫秒内执行。
这意味着前置步骤中的需求只需不到一秒钟即可完成。
测试用例需要完成的唯一步骤是使用Selenium（实际要测试的唯一部分）完成结帐过程。
使用JavaScript
登录页面是测试最常见的障碍之一，而且大多数应用程序都有必需经过这一步才能进入系统。
那么，如何从测试中删除它，使测试用例可以是原子性的？
这是一个例子：
在某一个带有登录屏幕的页面：
- 使用GUI测试工具打开Web应用
- 执行JavaScript脚本
- 登录成功
现在，使用GUI自动化测试工具 执行要测试的单个原子测试用例。
无法注入数据进行Web应用程序测试吗？
如果无法注入数据进行测试怎么办？
很多开发在进行软件开发时候，根本不会考虑应用程序的可测试性。
如果无法注入数据进行测试，大概有两个选项以供选择：
- 与软件开发人员合作以使应用程序更具可测试性。
- 放弃。
沟通对于长期测试的成功至关重要
果应用程序不是测试友好型，不要自动化。
