自动化测试技巧之结果验证

　自动到了京城，已经两月没有好好整理下自己的思路了，也没有好好的写一些东西了。现在，真应该回归了。因为有的东西，不吐不快。
　　---------------------------------------------------------------
　　在这里整理下关于自动化测试技巧中的结果验证的一些东西吧，这块也是我当年一个一个坑走出来的，虽然现在还有很多坑在等着我。
　　在我们编写测试脚本的过程中，很多时候总会不知道该怎么去判断我们的结果是否正确。因为有一些操作涉及图形、一些操作涉及页面窗口变化、一些则涉及数据库、系统事件等，从而导致我们无处下手，很多失败的自动化测试也是因为测试结果的不准确判断造成的，所以，在此要慎重选择。
　　首先来说说文本的验证吧。这也是目前最简单也是最有效的判断条件之一了。
　　一般文本验证的做法是：1. 获取当前页面上要验证的文本字符串并赋值给一个变量；2. 读取预期结果的文本字符串；3. 进行比较
　　在这里需要注意的一些问题有：
　　1) 字符串前后的空格。因为有些时候我们获取到的一些字符串总会在前后出现一些非正常的空格，尤其是url；所以在对这些进行判断的时候，我们需要进行预处理，即去掉前后的空格。vbs中可以使用trim函数；
　　2) 文本的特殊字符；
　　3) web上有一些提示内容，如账号密码输入错误和非空的提示信息，都是很多条显示在同一个位置的，并且显示的方式为webelement.show()、webelement.hind()，对于这种文本的判断，最好结合web本身的一些方法来写方法实现，尽量避免过多依赖于测试工具，如qtp、winrunner；
　　再来说下页面和窗口变化的验证，这类也是很常见的验证方式了。
　　不过，即使是千里马也有马失前蹄的时候，所以，我还是尽可能的整理总结下我所遇到的和想到的东西吧。
　　页面跳转一般分为页面内跳转和页面外链接，其中页面内跳转属于同步操作，需要等待执行完成才能进行下一步操作；页面外链接则属于异步操作，只要发送出打开浏览器，访问地址的操作就可以尽心下一步操作，不用等待链接的地址是否正确响应。因为实现机制的不一样，所以测试时候的判断方式也有一些区别。
　　页面内跳转的在click元素后需要执行一个等待同步操作，常见的web等待同步有Browser.sync、while oIE.busy:wend、while oIE.state <> 4 :wend，如果不加等待时间，则测试脚本会在忽略加载时间直接往下执行。这时候，如果你的网速够坚挺，那么一切好说，如果不坚挺，那就会报错了。页面外链接除了需要等待页面加载之外，还必须对浏览器窗口进行定位，一般定位的方法主要有hwnd、index、name、title等，定位方案不选好，遇到稍微奇怪点的情况就会悲剧。
　　窗口变化一般表现在全屏/非全屏，大小、窗体元素改变等地方。这些都可以通过获取窗体的属性来进行判断。不过全屏的判断方式比较特殊，因为很多窗体没有提供全屏的属性值，在这里我们可以通过获取当前窗体的宽高，然后和当前屏幕的availableScreen进行比较，切记，窗体的全屏指的是可用屏幕，就是除掉工具导航栏外的部分，不要真以为全屏就是满屏幕了。而浏览器的全屏则指的是浏览器显示区域大小为全部屏幕，就是除掉浏览器工具菜单栏的部分占了屏幕的全部显示区域。
　　再来说说数据变动部分的测试验证。
　　数据变动一般分为在本地数据库和服务器数据库改变、本地数据文件改变和服务器数据改变。对于这种数据的改变，通常的做法都是先获取数据内容，然后再和预期内容进行比较。在测试数据相关的功能时，很多人都会有种感觉，不穷尽数据组合很难完全保证是否正确。然而事实上，涉及数据变动的功能在测试时一般都是分为两部分，即数据测试和功能测试。
　　举例子来说：一个出生地选择的功能，有省市县三个下拉列表，为三级联动。那么在测试的时候，就需要先对三级联动这个功能进行测试；确保功能没问题之后，再对数据进行测试；最后在进行一个整合的随机测试。这样就能够保证在短时间内保证这个功能和所有涉及到的数据完全正确了。在设计自动化测试脚本的时候，也可以分别针对功能和数据进行设计编写，以便于我们在遇到错误时进行定位。
　　最后，来说说系统事件的验证技巧。
　　系统事件的测试验证，首先我们得知道系统事件到底做了哪些操作和修改，并针对这些系统级的操作和修改进行验证，以避免只依赖于被测程序的提示，从而提高测试脚本的准确性。
　　获取系统事件，可以利用安装测试工具（如InstallWatch）来进行跟踪。跟踪之后的验证就比较简单了，只需要读取修改的内容和预期结果进行比较就可以了。但是有一些系统文件，我们无法直接读取到里面的内容，并且这些文件也不需要或者不给我们开放一些权限去读取文件内容，那该怎么办呢？通常的解决方法有：1. 先对该系统事件进行单独的测试，以确保该功能正常；2. 对被测程序的操作进行测试，以确保被测程序能够正常操作系统事件；3. 设计测试脚本在被测程序和系统级分别进行验证，其中被测程序验证系统事件的提示信息，系统级则获取系统文件的最近修改事件和修改者，并与当前操作事件进行对比，如果一致，则可以认为这个操作是正常执行完成了的。
　　好了，结果验证就到这里。
最新内容请见作者的GitHub页：http://qaseven.github.io/