进化的测试

云计算是当今的一个热点，也是一个潮流，那么软件测试能否借助云计算的威力而更上一层楼呢？最近看了几个号称云测试的网站，有感，记录一下。 第一个网站是Cloud Testing。这个公司能提供多种平台，多种浏览器的平台，一般的用户在本地用Selenium把自动化测试脚本编写好，然后上传到他们网站，然后就可以在他们的平台上运行Selenium脚本了。他们的优点是：平台和浏览器覆盖得广，按需付费。不过我自己对这样的服务有以下的疑问： 基于UI的自动化测试通常都会遇到一些不稳定的问题，本地编辑好的自动化脚本是否也能够在他们的平台上正常运行 如果出现错误，有没有办法进行调试。究竟这个错误是SUT的错误，还是测试脚本的错误，如何区分 用户自己开发的插件能否在这个云测试平台上使用（我觉得是不行的） 总得来说Cloud Testing是一个基于UI自动化测试的云测试平台，但是我认为这样的平台并没有太多的优势，一般做互联网的公司产品发布都是比较快的，根本是不可能有时间和资源去覆盖所有的浏览器和平台，根据80/20原则，在中国搞互联网，只要搞定Windows下的IE6和IE7基本上就万事大吉了，一般好一点的前端TEAM都是在Firefox下进行开发的，所以Firefox的兼容应该是不成问题，最后在Chrome和Safari上过一下关键流程，差不多了。再说，现在虚拟化技术日渐流行，自己搭建多个平台也不是非常耗费资源。 第二个是keynote公司的kite，这个感觉比Cloud Testing更加弱一点，kite有自己的浏览器，然后用户在这个浏览器上录制脚本，然后上传，然后可以在keynote公司不同的可用地点中运行测试，查看结果。这个平台给我的感觉更多的是关注终端用户性能，里面有一个页面元素下载的timeline，用户可以查看那些页面资源下载花费多少时间，DNS查询时间等等…… 这个平台的问题有： 可用的节点不多，现在为止只有北美地区的几个节点可用 专门的工具，可能对测试的结果有影响 估计是keynote公司的一个实验性产品。 第三个是SOASTA。这个公司不单只提供了功能测试，而且还有性能测试。感觉上性能测试应该是利用云计算的一个非常重要而且有意义的点。貌似这个公司不是那么开放，没有太多公开的资料，所以不知道他们是怎么运作的。看他们的网站的一些成功案例，说的挺好，不过这样相对于在公网做性能测试，不知道会不会有问题： 带宽问题，例如云那段设定的带宽是1Mb，那么云和端之间的带宽是否能真正达到1Mb呢 安全问题，这些性能测试的脚本不会日后成为攻击的工具吧 突然觉得，现在做CDN的公司，其实他们可以兼营性能测试，因为他们的服务器分布的跟真实情况最接近的，而且也有足够多的服务器资源和带宽。

James Whittaker，两个月前还是微软Visual Studio的一个产品经理，好像是负责VSTS 2010的最新产品Lab Managment。现在已经跳槽到Google做测试总监了。 若干个月前他在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 [...]

对于从事Web开发和测试的工程师来说，Firefox是一个优秀的浏览器；因为基于Firefox的插件有很多，这些插件都极大地方便了开发和测试的工作。其中有著名的FireBug，FireCookie，Web Developer等，今天要介绍的是另外几个名气没那么大的Firefox插件，他们分别是FlagFox、Remove Cookie(s) for Site、Screengrab。 1. FlagFox 这是一个可以将网站服务器所在国家的国旗显示在状态栏上的插件。它通过查询扩展内建的IP地址库，同时通过维基和Geotool获得更多信息。可以参考下图，当我们浏览一个网站的时候在浏览器地址栏的最右边会有一个中国国旗，因为该网站的服务器就在中国；然后把鼠标挪过去放在国旗上面，就会出现该网站的IP，这里就是60.28.210.209。 其实我知道IP所在的国家对于测试没什么帮助，我只想知道我所访问的网站的IP。因为大家都知道做测试的时候经常需要配HOST，重启浏览器，但是有时候 配好了HOST重启完了还不一定生效；又或者HOST文件太大，有时候一个域名给配上了若干个IP（这是一个失误啦~）；又或者是一个域名下有多台测试 机。我想在测试的过程中清楚地知道我现在究竟在访问哪台测试机。这就是FlagFox能起到的作用了

昨天Check in了几行代码，部署到了生产环境，一切正常，这个是我第一次把代码提交到生产环境。今天早上看到一篇文章“Who fixes the bugs?”。这篇文章是讲述了一个测试工程师是否应该去深入到代码，然后自己把发现的BUG修复，这样的一个事情。很有趣，我刚做完这样的事情，就看到一篇文章讲述同样的问题。 读完那篇文章以后会发现，软件测试真的是一件跟上下文（Context）联系的特别紧密的事情。所以在做某一件事，或者讨论某一件事情的时候，最好先把上下文先弄清楚，然后再下判断。下面阐述一下文章的观点。 作为一个团队里面的成员，每个人都有义务和责任去提高产品的质量。 测试工程师来修复BUG这样的行为虽然不会京城在传统的软件行业里面发生，但是也不能以这个为理由去打击它。 你不必要去创造一个敏捷的过程来规定测试工程师可以修复BUG。 上面这三点非常模棱两可的观点，在我看来就是作者让读者知道，我们在充分了解上下文的前提下来进行判断。对于我现在所处的公司的环境下，昨天我做的事情是没啥问题的。 公司没有严格的流程或者指引，规定了Tester不能往生产的代码库中check-in代码 现在公司的Developer不是很多，有时候能帮的地方尽量帮助，自己也能学到东西 对于我测试过的代码，熟悉起来还是会比较快 我也需要对代码的质量负责 那么这样做会有什么问题呢？ 变相地成了自己测试自己的代码，不推荐 对于测试小组来说，比较难留住人才（那篇文章的观点，也是一个现实） 在多数情况下，测试工程师的工作就是不断地折磨那个被测软件，不断地向被测系统提问题；然后等待被测系统的答案，从这些答案里面获得尽可能多的信息，软件测试在开发生命周期活动里面扮演一个服务者的作用，给开发经理，开发工程师，各个stakeholder们提供信息，所以软件工程师甚少去修BUG。而且在大多数非常正规的企业中，测试工程师设置没机会看到代码，所以也没有办法能修复BUG。软件工程师可以修复BUG吗？可以，不过不常见。