在讲解Wait和Exception中，隐隐体现出来使用WebDriver还是蕴含一些小窍门和注意事项，既然知道了这些，我们自然而然地想是不是应该将这些窍门和技巧运用到我们日常的编写用例上，这时候顺水推舟的会出现一个词“封装”。当然，“封装”也是我们程序员最喜欢干的事情。当然开发WebDriver的程序员们在设计了这么多秘技的同时，也为我们提供了一些封装思想，方便我们在日常编写用例过程中更加轻松，高效，易用，可维护和可拓展。
这里我们就引入“Bot Style Test”，它的核心思想：他是对Selenium API进行行为导向的抽象操作封装，以便提供一种命令行式的用例编写方法，同时便于后期解决一些Selenium存在的问题及提供一些Selenium不支持功能。
从我们前面讲Wait和Exception的时候，已经指出，在没有适当使用Wait和Exception时，可能我们一个简单的点击或者输入操作，都有可能出现一定概率的失败情况。这里我们可以粗浅的任务，WebDriver基础的点击和输入操作是存在缺陷的，那么为了解决这些存在的问题，我们可以同Bot Style Test的思想进行封装，让我们在使用的时候更加简单方便。
接下来我们以点击和输入操作作为一个例子分析一下：
入门实战
前面我们分析过，如果一个元素是在不能点击的状态下进行点击操作，会报InvalidElementStateException异常，那么我们是不是可以在点击操作执行之前，进行条件为检查元素是否可以被点击的Wait操作。等元素可以被点击的时候，再进行操作。这样我们是否就可以避免因为在不可点击的状态下进行元素点击而产生用例不必要的执行失败了？
进阶实战
我们前面，介绍过了，如果被点击元素被其他元素遮挡的情况下，我们会发生WebDriverException，原因可能是JAVA执行速度远快于JAVAScript，那么我们为何不在这里增加重试来保证点击成功呢？当然重试还是会失败，我们需要捕捉处理。如上图，我们通过捕捉WebDriverException，当其中的message中包含"Other element would reccive the click"来判定是否被其他元素遮挡。如果遮挡，则进行重试，重试次数到达后，如果还是失败，则我们主动抛出异常。
总结
以上2个点击例子只是冰山一角的缩影，实际过程中可能为了提高我们的点击操作的稳定性，易用性等会有其他一系列符合“Bot Style Test”思想等处理。在保证操作是简单的单行命令的同时，高度集成各种异常捕获，同时只能处理，以便达到用例操作本身的稳定性，可以让我们把精力核心放在业务逻辑的思考，及BUG的跟踪定位，而不是在排查WebDriver不当使用而导致出现各类偶发问题。
