第一个网站是Cloud Testing。这个公司能提供多种平台，多种浏览器的平台，一般的用户在本地用Selenium把自动化测试脚本编写好，然后上传到他们网站，然后就可以在他们的平台上运行Selenium脚本了。他们的优点是：平台和浏览器覆盖得广，按需付费。不过我自己对这样的服务有以下的疑问：

1. 基于UI的自动化测试通常都会遇到一些不稳定的问题，本地编辑好的自动化脚本是否也能够在他们的平台上正常运行
2. 如果出现错误，有没有办法进行调试。究竟这个错误是SUT的错误，还是测试脚本的错误，如何区分
3. 用户自己开发的插件能否在这个云测试平台上使用（我觉得是不行的）

总得来说Cloud Testing是一个基于UI自动化测试的云测试平台，但是我认为这样的平台并没有太多的优势，一般做互联网的公司产品发布都是比较快的，根本是不可能有时间和资源去覆盖所有的浏览器和平台，根据80/20原则，在中国搞互联网，只要搞定Windows下的IE6和IE7基本上就万事大吉了，一般好一点的前端TEAM都是在Firefox下进行开发的，所以Firefox的兼容应该是不成问题，最后在Chrome和Safari上过一下关键流程，差不多了。再说，现在虚拟化技术日渐流行，自己搭建多个平台也不是非常耗费资源。

第二个是keynote公司的kite，这个感觉比Cloud Testing更加弱一点，kite有自己的浏览器，然后用户在这个浏览器上录制脚本，然后上传，然后可以在keynote公司不同的可用地点中运行测试，查看结果。这个平台给我的感觉更多的是关注终端用户性能，里面有一个页面元素下载的timeline，用户可以查看那些页面资源下载花费多少时间，DNS查询时间等等……

这个平台的问题有：

1. 可用的节点不多，现在为止只有北美地区的几个节点可用
2. 专门的工具，可能对测试的结果有影响

估计是keynote公司的一个实验性产品。

第三个是SOASTA。这个公司不单只提供了功能测试，而且还有性能测试。感觉上性能测试应该是利用云计算的一个非常重要而且有意义的点。貌似这个公司不是那么开放，没有太多公开的资料，所以不知道他们是怎么运作的。看他们的网站的一些成功案例，说的挺好，不过这样相对于在公网做性能测试，不知道会不会有问题：

1. 带宽问题，例如云那段设定的带宽是1Mb，那么云和端之间的带宽是否能真正达到1Mb呢
2. 安全问题，这些性能测试的脚本不会日后成为攻击的工具吧

突然觉得，现在做CDN的公司，其实他们可以兼营性能测试，因为他们的服务器分布的跟真实情况最接近的，而且也有足够多的服务器资源和带宽。

No related posts.

若干个月前他在utest有一个讲座，题目是《5 Ways to Revolutionize Your QA》，今天早上我又翻出这个文档仔细看了看，觉得真是受益匪浅，推荐推荐，在这里可以下载《5 Ways to Revolutionize Your QA》。

主要讲了5条：

Insight 1:  There are two types of code and they require different types of tests
Insight 2:  Take your testing down a level from features to capabilities
Insight 3:  Take your testing up a level from test cases to techniques
Insight 4:  Improving development is your top priority
Insight 5:  Testing without innovation is a great way to lose talent

其中我个人对第一条和最后一条感触比较深，第一条里面提到了当年Vista就是过分信任自动化测试，结果……大家都能看到；第五条就解释了为什么在测试这个行业，大牛那么少，而牛人又经常转做开发或者别的工作去了。

James Whittaker在微软的博客

James Whittaker现在偶然会在Google Testing Blog（哎，要翻墙才能看）发表文章

Related posts:

1. 如何成为一名优秀的测试工程师
2. 《Software Testing》第二十一章 – 软件质量保证
3. 敏捷测试只是手段不是目的

1. FlagFox

这是一个可以将网站服务器所在国家的国旗显示在状态栏上的插件。它通过查询扩展内建的IP地址库，同时通过维基和Geotool获得更多信息。可以参考下图，当我们浏览一个网站的时候在浏览器地址栏的最右边会有一个中国国旗，因为该网站的服务器就在中国；然后把鼠标挪过去放在国旗上面，就会出现该网站的IP，这里就是60.28.210.209。

其实我知道IP所在的国家对于测试没什么帮助，我只想知道我所访问的网站的IP。因为大家都知道做测试的时候经常需要配HOST，重启浏览器，但是有时候 配好了HOST重启完了还不一定生效；又或者HOST文件太大，有时候一个域名给配上了若干个IP（这是一个失误啦~）；又或者是一个域名下有多台测试 机。我想在测试的过程中清楚地知道我现在究竟在访问哪台测试机。这就是FlagFox能起到的作用了

如图，我把www.myspace.cn配上了10.60.0.13这台机子，然后访问。这时候由于是一个内网IP，所以国旗变成了一个网络驱动器的图片，把鼠标放上去那个驱动器上，能看到现在www.myspace.cn所对应的服务器地址就是10.60.0.13。

2. Remove Cookie(s) for Site

这个插件可以通过工具栏按钮或者菜单实现当前网站Cookie的一键清除。有时候站点的一些新功能会根据某个COOKIE的值来进行bucket test，而落到这个bucket里面的几率比较低，需要在测试的过程中频繁地清除COOKIE，然后刷新页面获取一个新的COOKIE，虽然已经有很多方式可以清除COOKIE，例如用Web Developer，FireCookie。但是这个Remove Cookie(s) for Site小巧方便，只需要右键展开菜单，然后左键一点就搞定了。

3. Screengrab

这个插件可以截取网页屏幕，包括截取当前窗口、选定区域，或是滚动截取网页的全部内容。这对测试人员来说非常方便，而且可以直接save成为文件，不过如果是要在图片上加点说明，画个圈什么的，就要用其他图像编辑器了。我个人比较喜欢用那个滚屏抓图。

No related posts.

• 作为一个团队里面的成员，每个人都有义务和责任去提高产品的质量。
• 测试工程师来修复BUG这样的行为虽然不会京城在传统的软件行业里面发生，但是也不能以这个为理由去打击它。
• 你不必要去创造一个敏捷的过程来规定测试工程师可以修复BUG。

上面这三点非常模棱两可的观点，在我看来就是作者让读者知道，我们在充分了解上下文的前提下来进行判断。对于我现在所处的公司的环境下，昨天我做的事情是没啥问题的。

1. 公司没有严格的流程或者指引，规定了Tester不能往生产的代码库中check-in代码
2. 现在公司的Developer不是很多，有时候能帮的地方尽量帮助，自己也能学到东西
3. 对于我测试过的代码，熟悉起来还是会比较快
4. 我也需要对代码的质量负责

那么这样做会有什么问题呢？

1. 变相地成了自己测试自己的代码，不推荐
2. 对于测试小组来说，比较难留住人才（那篇文章的观点，也是一个现实）

在多数情况下，测试工程师的工作就是不断地折磨那个被测软件，不断地向被测系统提问题；然后等待被测系统的答案，从这些答案里面获得尽可能多的信息，软件测试在开发生命周期活动里面扮演一个服务者的作用，给开发经理，开发工程师，各个stakeholder们提供信息，所以软件工程师甚少去修BUG。而且在大多数非常正规的企业中，测试工程师设置没机会看到代码，所以也没有办法能修复BUG。软件工程师可以修复BUG吗？可以，不过不常见。

No related posts.