[译]36 Days of Web Testing(三)

Day 14: Automate the tedious

Why ?

有些时候，web测试仍是蛮单调乏味的，在开始测试前，你可能要必须跳转到一个特定的表单页面，或则为了获得一个特定的页面（或配置），你必须准备不少数据。

这种场景下，我发现经过selenium IDE进行UI测试的录制、回放，经过一些简单的SQL脚原本造数据，可使测试准备工做特别有高效。

经过这些工具，能够很简单、快速的，来到你想测试的点（test point）

PS：这个感同身受啊，举个实际工做中的例子，好比我要测试退款业务（test point为退款），但在申请退款前，这笔订单必须已经支付、清算完成

How?

Selenium IDE是Firefox的一个插件，如何使用这个插件录制UI自动化脚本，能够查看官方的在线文档。

能够录制你在访问站点时所作的操做，页面跳转，后续若是须要，就能够回放这些步骤了。

举个例子，我须要测试多用户场景下的Cookies管理，这时候就须要以不一样的用户不断的作“退出”和“登入”操做。

这种状况下，我写了个自动化脚原本实现，一个用户的“登出”和另外一个用户的“登入”。

若是手动作的话，就须要重复的机械点鼠标。须要注意的是，我并无用Selenium来测试，只是用selenium来作测试准备工做的自动化，和帮我点鼠标，Cookie管理的校验，我来test的。

建议

若是学会了如何在Selenium IDE里Debug自动化脚本，就能够更快的录制和回放脚本了。

有一点须要注意，若是你但愿经过录制UI自动化脚本，并依靠这些来作回归测试，你要想清楚。大多数状况下，这是不靠谱的。

另一点，你能够经过SQL脚原本作测试前的数据准备工做。

连接：

SQLYog Tool - http://www.webyog.com/en/downloads.php
SQL Learning at W3 Schools - http://www.w3schools.com/sql/default.asp
Selenium Debugging - http://seleniumhq.org/docs/02_selenium_ide.html#debugging
Selenium - http://seleniumhq.org/

Day 15: Soap Testing

Why ?

若是你的应用使用了Web services,那么它就可能正在使用SOAP协议

下面是维基百科对SOAP的定义：

简单对象访问协议（SOAP，全写为Simple Object Access Protocol）是交换数据的一种协议规范，使用在计算机网络Web服务（web service）中，交换带结构信息。SOAP为了简化网页服务器（Web Server）从XML数据库中提取数据时，节省去格式化页面时间，以及不一样应用程序之间按照HTTP通讯协议，听从XML格式执行资料互换，使其抽象于语言实现、平台和硬件

网上有不少关于SOPA封装,编码规则,但最基本的它如何传递消息的.

你能够只关注UI层面的测试,而忽略底层的SOAP交互, 但在UI下面,有更多值得你探究的东西.甚至, 测试时均可以不须要UI, 直接测试web services。

你能够直接和web servcice交互，测试全部的点。传递一个脏数据、损坏的数据（corrupt date），无效数据，传递不少数据，较少数据。你甚至能够写一个自动化脚本以你指望的方式整夜的绑定web services

How ?

测试SOAP服务最简单的方法就是使用一个SOAP UI工具，它的UI界面很整洁，有不少在线文档提供直观的帮助。

SOAP UI的具体指令能够查看它的官方文档，但最基本的包括，链接一个web service,查看这个web service提供的元素，接着你就能够想一些测试点了。

建议：

和Http services同样，SOAP UI也是RESTful的。

连接：

SOAP UI - http://www.soapui.org

Day 16: See the source 查看页面源代码

Why ?

页面源代码是发现bugs的好地方，能够对感兴趣的代码块进行深刻探究，看有没有潜在的安全漏洞，或则信息泄露。

我所说的源码是指你所测试的页面的源代码。源码能够看出你的应用是如何和页面组合在一块儿的。

页面源码可能会包含注释、用户名和密码，经过蛛丝马迹能够看出所引用的方法，后台实现，从安全角度来看这些信息可能会有帮助。页面源码里还可能包含对公司、用户各类赞美、挖苦、讽刺的注释，设置有些注释里还会有一些笑话，或则提到一些部分实现的功能。

页面源码里还可能有安全URLs和证书等。

How ?

在浏览器里打开你的页面，点击工具栏的“查看”按钮，选择“查看页面源码”。

页面源码就会在浏览器窗口打开，简单浏览下，而后对你感兴趣的代码块进行深刻阅读。

建议：

也能够在浏览器窗口，右击，选择“查看页面源码”。

连接：

Andréas Prins article on Hidden Treasures - http://www.thetestingplanet.com/2010/12/hidden-treasures-foreveryone/
Firefox Extension to visualise page source - https://addons.mozilla.org/en-US/firefox/addon/view-source-chart/

Day 17: Explore the competition  竞争对手研究

Why ?

看看规范手册、声明文档，研究下用户在使用你的系统前还用过那些系统，作下竞争对手研究，这些均可以帮着想出更多的测试点。

研究下竞争对手的产品和服务，这样的学习将有助于你的测试

在测试行业，有个话题一直讨论的很激烈：一个测试工程师对于所测试的站点，有没有必要提出改进性的意见或建议。

个人答案是，Yes ，绝对应该。

我认为，若是一个测试工程师依据本身的知识、看法能够提出使得产品变得更好的方案，若是他不提的话，这将会使他错失增加本身看法的机会。

测试并非快乐的道路检查，贴着标记的盒子，不是预先肯定好的路。在测试过程当中，须要应用到你的判断、看法、经验和掌握的知识。

这些观点，看法，若是有助于提高产品，那么就应该提出来，相互沟通，交流。

若是有机会改进这个软件，使它更好用，在市场上更具竞争力，最终成为一个成功的产品，难道不就是增长了产品的价值吗

不要想着，已经有其余人在研究竞争对手了，也不要以为以前的人已经考虑到了用户习惯。

经过比较产品获得的信息，将有助你想出新的测试点，想出改善产品功能的办法，想出使你的产品脱颖而出的办法。这是一个很好的，可以帮助你提高的测试技能。

若是单纯是模仿竞争对手，这并非一个很好的商业策略。

你能够经过从他们产品信息中收集使用案例开始，并以新的思路来考虑本身的产品。

同时，这也能加深你对所从事领域的理解。

How ?

在网上能够很快地搜索到竞争对手的网站，你能够读读他们的marketing材料，注册下载试用版，对他们的产品和领域有更深刻了解。

建议：

可能你会发现你的产品或站点在“二选一”站点的列表中，好比http://alternativeto.net/。这些站点会列出可供对比选择的产品，这是一个很好的途径来看你的竞争对手在作些什么？人们是怎么评价他们的产品的。 PS，在这网站尚未alipay的信息。输入paypal，能够看到国外第三方支付的公司列表。

连接：

www.alternativeto.net

Day 18 : 规范和声明

Why ?

在产品的发布流程中，一般会将产品的附属文档整合起来，这些文档会解释这产品有哪些功能？好在何处？

这些文档会包含关于产品功能、性能的声明，以及产品遵照了哪些行业规范的说明。

做为一名测试工程师，今早去发现这些文档声明了些什么，并将这些声明和规范说明罗列到你的用户故事，或测分文档里。虽然这些声明，规范的说明并非产品团队起草的，但仍是须要关注。

一旦你了解了这些声明，那么你就能够开始针对这些声明进行测试了。

举个例子来说啊：

• 产品遵照了X标准  <- 真的是这样吗
• 咱们的产品是市面上最快的？ <-  真的吗? 如何证实？ 数据是从哪来的？
• 个人产品绝对安全 < – Really?

How ?

对着每一条声明和规范，记录下你头脑中闪现的问题。就这些问题，和产品/市场/管理团队进行沟通，也能够研究下相关的法律法规。

可能你全部的问题、疑虑都没有被采纳，这种状况下，你能够依据这些声明和规范来测试你的产品，找到证据来证实你的产品不符合这些声明。

将你的发现交给关心这些的人(法务会比较关心),但首先你要判断下，你在这些上面花费时间是否是最值得

建议：

若是你在测试这些标准，或法律声明时遇到了疑惑，你也能够一些论坛上提问，或则在一些社交媒体上求助，好比Twitter（Ps:国内能够试试“知乎”）

毋庸置疑，在这个领域有不少资深人士，他们的一些看法可能会帮助到你。

连接：

http://curioustester.blogspot.co.uk/2009/12/claims-testing.html
http://www.bettertesting.co.uk/content/?p=613