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