最近自动化工作的收获-- API之assertText、谓语ancestor用法补充、框架运用的进一步认识

  在这段时间实现自动化的过程中有一些小小的收获，在这里记录一下，为了以后为自己和朋友们提供借鉴。一般在设计自动化测试时，我们都会添加对预期结果的断言以验证系统功能是否符合需求要求。自动化测试的目的是为了减少人力投入，进而将人力投入到更需要的地方，而非完全代替人力，所以在添加断言时就要求细致全面。

 

  首先说一下assertText这个API，说到assertText就不得不说assertTextPresent这个API，先说说这两个API的不同中说起。对于文本信息的验证一般是以assertTextPresent和assertTextNotPresent，但有些时候还是不够的，需要进一步完善。在最近的工作中，为了验证一个数据的某个特定元素的文本用到了assertText这个API。assertText和assertTextPresent很像但有很大不同。assertTextPresent只关心文本是否存在，所以对于页面上唯一出现的文本验证比较方便；另外，assertTextPresent也不关心文本所在位置。而assertText则不同，对于页面上可能多次出现的文本我们可以根据一些辅助元素进行判断是否与预期相符，例如，某个页面信息的文本内容是否是xxx，即与辅助元素在位置上存在间接关联性。这个时候assertText则更具有针对性，对自动化测试验证点的覆盖自然更加全面。

 

  由此，为了更全面的验证需要对xpath的用法谙熟于心，理解并运用。在之前关于Selenium xpath中说明了一些谓语的用法，类似的有following,preceding等等，这次遇到了ancestor又有了一些体会，在这里分享给大家。在xpath的教程中提到过xpath有个格式--谓语::轴形式。之前在用following这些谓语的时候，对轴的概念没有特别深刻的体会，就觉得是子元素的一个标签。在这次用到ancestor的时候，才深刻体会到这个轴是一个定位点，向上找祖先节点到某个节点结束，再往下找匹配的子节点。这样说有点乱，还是直接上图上真相吧，呵呵。

可能大家觉得这个例子并不贴切，这里只是为了说明轴就是我们要找的一个参考节点，以这个节点再去定位最后要找的的元素。那这个节点必定和之前的和之后的节点存在着某种关系，或父子或兄弟，这个就要看实际情况了。在实际使用时体会一下应该会更有帮助吧，呵呵。

 

  最后，说一下框架，在之前的一次中提到了用到过的两个不同框架，一个是用java code写类selenium的语句，当然这其中会用到封装；另一个是在htm中写tr/td由框架进行解析，解析成selenium中的action进行操作。在上一篇中感觉通过框架解析的方法很好，简单易用，但随着业务逻辑的深入发现这种框架很难达到对业务逻辑的验证，只能验证页面元素的存在或正确，如果页面上的几个值存在一定业务关系，这种框架是无从验证的，在html中无法对这些数据进行操作去验证是否符合预期。相反的，用java code的代码就可以达到对页面上数据进行一些业务验证的可能性。我们可以用selenium API(例如storeValue)获得数据，通过java code进行比较，再通过if/else比判断是否符合业务逻辑。这样从页面的角度也验证了部分业务逻辑，不仅仅是“死板”的页面验证，无疑这样对自动化测试的覆盖又提高了一块儿。

 

  3点小小的体会，工作中的总结吧，拿出来和大家分享，希望有帮助。