易栈网-膘叔

虽然不懂，但先备份着。
这段时间在学习object-c开发，但是我对很多资料都不熟，不过看到有测试类的文章还是先备份下来再说了。
原文来自：http://qa.taobao.com/?p=13737
        无线客户端的发展很快，特别针对是android和ios两款无线操作系统的客户端应用，相应的测试工具也应运而生，这里主要给大家介绍一些针对iPhone App的自动化测试工具。

         首先，我们把这些测试框架分为三大类：接口测试工具、注入式UI测试工具、录放式UI测试工具。

        一、接口测试工具，主要在iphone SDK提供的单元测试框架的基础上，完成代码的接口功能测试。

                 这类工具用的比较多的是SDK本身提供的test unit，以及google的google-toolbox-for-mac工具。google的GTM工具是在test unit上做了一层封装，可以简单、快速的完成测试脚本编写，提供完善的测试日志和报告，并提供部分简单的UI测试功能。

                 详细的文档可以参考这里：http://code.google.com/p/google-toolbox-for-mac/wiki/iPhoneUnitTesting

         二、注入式UI测试工具，可以完成对被测应用的UI功能测试，需要在源代码中加入一些必须的测试代码。优点是可以模拟用户的操作，测试被测应用的相关功 能，可以覆盖比较全的应用功能。缺点是因为在源代码中插入了必须的测试代码，而这些应用发布时需要去除，引入了被测应用和发布应用不一致的风险。

                  UISpec,提供了用例运行前的准备和运行的恢复功能，UIQuery功能，以及较为完善的校验功能，但该工具的使用比较复杂，脚本的编写也很繁琐，虽然对UI可以query，但无法方便、清晰、直观的查看应用控件的属性。

                  详细的文档可以参考这里：http://code.google.com/p/uispec/wiki/Documentation

                  Bromine,脚本编写简单，对控件的操作，完全模拟touch事件实现，但控件的定位通过对控件重画，并插入定位需要的信息，xpath的描述串也稍显复杂，校验功能相对较弱。

                  详细的文档可以参考这里：http://code.google.com/p/bromine/

         三、录放式UI测试工具，主要通过录制用户的操作行为，通过回放来完成对被测应用的功能测试，这类工具对UI的功能测试相对是比较弱的。

                  比较常用的有Instrument、FoneMonke 。

                  Instrument，是iOS提供的主要用于分析应用的性能和用户行为的工具，利用它可以完成对被测应用的简单的UI测试。

                  FoneMonke，是国外提供的一个开源的，免费的录制/回放工具。网站：http://www.gorillalogic.com/fonemonkey

          以上是了解的一些针对iPhone App的自动化测试工具，大家感兴趣的可以了解了解，欢迎交流、学习！

-----------
仅作备份。不过感觉好象针对代码测试的工具还是一般般。但还是可以推荐给我们的QA进行阅读了。

本文来自于淘宝QA，这是第一次看到有这样的贴子，是测试cache的贴子。虽然他不是测试cache本身，但从文中的测试要点来说，还是有借鉴意义的。像他说的：触发点、何时使用cache等都是一个要点。
众所周知，任何一个程序，为了效率，总有部分资料是需要被缓存的。比如，系统配置，这玩意一旦设定，很可能就再也不会修改了（或者说，修改的频率非常低），如果每次都查询数据库，那效率也太低了。所以它应该是被缓存的对象之一。
分类也是应该能够被缓存的，谁TMD有事没事去修改分类、删除分类？一个成熟的网站，分类定下来后，基本也就定下来了，除非更改业务方向，增加业务范围，才会去修改分类。当然还有一种情况，那就是为了促销，人为修改（但这应该不属于分类了啦）所以，分类也应该是被缓存的对象之一。。。

好了不说废话了，看测试是怎么说的吧：
原文：http://rdc.taobao.com/blog/qa/?p=3434

        前段时间做了一个cache相关的接口测试，这里要说的并不是测试cache本身，而是测试一个使用了cache的业务系统，该业务系统通过调用另一个专 门提供cache服务的系统来实现数据的cache。也就是说cache服务本身对于我来说是黑盒的。那么在这种情况下，我们应该从哪些方面来考虑测试， 才能够保证业务系统对cache服务的调用是正确的呢？我是从以下几方面考虑的：

一．Cache的触发点

        如果一个系统使用了cache，那么它就一定会有cache的触发点，所谓触发点就是会触发cache缓存数据或者更新数据的事件。这些事件往往就是对某 些接口的调用。例如查询数据的时候，如果缓存里没有该数据应该会触发cache来缓存该数据。更新数据的时候，如果缓存里有该数据，应该会触发cache 删除该数据的缓存等等。我们必须要掌握每一个触发点才能够知道如何来设计针对cache的测试，因为我们的目的就是要验证所有的触发点是否都正确的触发了 我们所期望的缓存事件。

二．何时应该使用cache，何时应该使用数据库

         掌握了系统中所有的cache触发点之后我们就可以开始设计如何来验证这些触发点了。一般来说，被缓存起来的数据都是供查询使用的，明确了这点之后，其实 归结起来，我们只需要考虑两个问题：一是何时应该查询cache中的数据，二是何时应该查询数据库中的数据。

         举例来说，一个典型的使用了cache的查询接口应该是这样的，当查询数据的时候，接口会首先去缓存中查找数据，如果缓存中没有数据，再去数据库中查找， 如果在数据库中找到了指定的数据，它会在返回数据的同时，对该数据做缓存处理。了解了这个过程之后，你可以先通过直接插数据库的方式准备一条数据，这个时 候该数据是没有缓存的，因为没有触发缓存数据的事件发生，那你如何来验证这个数据确实没有缓存呢？很简单，直接把该数据从数据库删除掉，再调用查询接口查 询该数据，如果没有查询到，说明该数据确实没有被缓存。另外一方面，你还应该保证如果数据被查询到了，那么它就应该被缓存起来，这个时候你同样可以直接删 除数据库中的数据，再次查询该数据，如果可以查询到，那么就说明它确实是被缓存起来了。总的来说就是了解缓存过程，分解过程，保证过程的每一步结果都是所 期望的，这就有别于通常的接口测试只关注输入和最终的输出结果了。它的思想和切面编程的思想有点类似，也许我们可以把这种测试方法叫做切面测试。

三．多触发点联合测试

         在保证了每个触发点的正确性之后。我们还应该进一步把这些触发点按照实际的业务场景串联起来测试。例如，可能会有这样一个业务场景：生成数据→查询数据→ 编辑数据→查询数据→删除数据→查询数据。值得注意的是对于这样的联合测试除了保证每个步骤的结果都正确的同时，我们应该尽量采用调用业务系统接口的方式 来完成每一步，尽量避免直接操作数据库，因为这样更能模拟出真实的调用场景。

        不同的cache方式会有不同的测试方法，以上仅是我在测试特定cache的时候的一些想法，仅供参考。如果你测试过cache，不妨也来说说你自己的测试方法，如果你没有测试过cache也可以来谈谈自己的想法。

如题，请您把对本站全部打开所耗费的时间做一下评价。谢谢

以便让我可以确定是否选择以目前的线路来继续进行托管。
您的意见对我十分重要，感谢您

由于chrome不支持fck或者说fck不支持chrome，在下面的格式全没有了，不得己，重新编辑了一下。。。

前段时间提到，在mootools上面有一个测试JS速度的网页，因为听说chrome采用了V8引擎，于是又上去测试了一下。不知道是浏览器的问题呢，还是真的是解析的问题。在chrome下面，jQuery的平均分值是最高的。

selectors MooTools 1.2 JQuery 1.2.6 Prototype 1.6.0.2 YUI 2.5.2 Selector beta Dojo 1.1.1
final time (less is better) 138 111 431 425 149

一眼看出，jQuery是得分最高的。。。prototype和YUI对于它根本没有可比性。当然这也和jQuery是轻量级有关，可是prototype为什么分数会最低呢？呵呵

然后测试了一下其他的东西，因为chrome的选项实在太少了，除了在第一次启动的时候提醒我将google的一些设置保存过来之外，我实在看不到有什么好设置的。

然后打开浏览器，拼命的开新窗口，想看看内存占用会如何，不知道是因为我的机器的关系呢？还是什么，第一个打开的窗口占用了60多M的内存，其他每个窗口都占了30M、20M，逐渐递减 ，最好的占用了6M多，这样的话，合计下来，并不低于FF3

顺便提一下，我的fck editor，在chrome下无法显示了。看来要建议fck他们改进了。黑黑

打开网页的速度确实挺快，这点我承认

其他的，没有什么可以吸引我了。。。自带的develop工具感觉还行。
没有菜单真的不太习惯。。。

惊讶一下，在chrome里面，文件选择框变化好大。。。。不再是以往那样有一个框了，只有一个按钮。
刚才使用chrome另存图片的时候，一个向下箭头的图片在屏幕上自上而下的滑落然后隐藏，效果不错，同时在页面底部显示下载列表。。。

我不知道我这篇文章发出去会怎么样，如果格式变化的太利害，还是会用FF打开进行修改。。。，果然被我说中了，汗

最近一直被接口的事所烦恼，接口，测试，测试，接口。为什么要做，要做的目的是什么？

突然看到淘宝的QA上有这篇文章，立刻转摘，希望也能给其他想做接口或者正在做接口的朋友提供点帮助吧。

——END——

颇为感慨