[译]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，可以看到国外第三方支付的公司列表。
链接：
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
