摘要：
经常看到网上有些文章讨论测试人员的工作有没有技术含量，似乎很有一些人，包括测试从业人员，认为测试的技术含量比较低，觉得学不到东西，从而产生前途迷茫的想法。或者反过来，拼命举一些例子，比如自动化测试，性能测试啊，以来说明测试需要的技术要求还是挺高的，来为测试人员辩护。但这么来辩论，潜意识已经承认一个观点了，即技术能力就是评价一个测试人员最重要的指标。我觉得要理解这个问题，首先要看一下技术的定义，然后再看一下这么想的背后原因。From wiki:Technology is the making, usage, and knowledge of tools, machines, techniques 阅读全文
摘要：
What is Tool Robogenerator? Test Data generator for `Robot Framework <http://www.robotframework.org>` What is the tool’s purpose? You know those ugly bugs that users report that somehow were missed ... 阅读全文
摘要：
现在大家对探索性测试讨论得很热门，在自动化测试大行其道的今天，探索性测试似乎是唯一一块测试人员更能体现自己专业性的领域。甚至我还看到有人在讨论如何通过探索性测试来达到较高的代码覆盖率。 个人以为，如果你真的对覆盖到代码的每个分支更感兴趣，或者说希望测到哪怕是一些比较细节的用户行为，通过探索性测试的方法来做也许并不是一个很推荐的做法。 我这里想介绍一种基于模型的测试，通过它，我们可以对软件的功能达到... 阅读全文
摘要：
项目背景介绍： 最近在给一个团队做测试用例的重构，重构最主要的原因是由于不同team的测试执行了相同的操作，但是却有不同的检查点。偏偏这些操作又是非常耗时的，所以从整个部门的角度看，这些测试的效率就是不高的。然后我们又在做持续集成，自然对测试的效率有极高的要求，所以就决定做测试用例的重构，PO分配了一些有经验的测试工程师来做这个事情，我帮助他们解决自动化测试上的问题。 问题介绍： 涉及到的软件模... 阅读全文
摘要：
之前讨论到似乎自动化的程度挺高的，从自动装包（Automatic deployment),自动执行（Automatic Execution),自动上传结果(Automatic Uploading),自动生成结果报告（Automatic Reporting)，自动化测试的各个阶段都已经实现了。套用一句话，看起来挺美的。可是，真的是这样吗？毛主席教育我们要从群众中来，到群众中去。我们还是应该听听，一线测试人员以及team的反应，他们说：自动化测试还是不能帮助我们发现太多的问题，与此同时，我们投入地还是太多。测试人员普遍不愿意持续地来维护CRT，感觉持续地做这个事情，学习的地方不多。自动化测试的误报 阅读全文
摘要：
后记：在做了一段时间的推广自动化测试的工作，情不自禁地想把自己的眼光放得更远一些，究其原因，我很清楚地认识到，测试的最终目的是还是为了提高软件的质量，而无论是自动化测试，还是Continous Integration，都还是是软件的外部看问题。但软件为什么一直有解决不完的Bug，如果不对软件的内部有更好的了解，恐怕是没有办法想明白这个问题的，更不要说解决这个问题了。就我自己而言，也不希望自己到时候做了一辈子软件测试，对软件中的bug是怎么产生的，软件中的bug到底是怎么回事还搞不清楚，所以，我又来到了一个Team，作为一个测试人员的身份加入他们。在更好地熟悉软件开发的实战的过程的同时，也希望能 阅读全文
摘要：
Precondition: You use WinXP (other windows version may also works, but I have not tried it) you mainly use your PC to execute test automation case but notto use it as ftp client to transfer large files You test automation case need to frequent interaction with your DUT(Device Under Test), that is a 阅读全文
摘要：
我先是自己来调试原来一直跑不起来的case，发现之所以前面的case失败了，会影响后面的case，其实是由于case之间的独立性不好引起的。为了能解决这个问题，我还和team一起设计了一个复杂的环境恢复的keyword，里面判断了不同情况下，如果有板子没有起来，应该怎么恢复的问题。用了这个方法，case执行的稳定性逐渐提高了。大概过了1-2个月左右，case执行的通过率从原来的在40-50%徘徊，而且也不能发现比较有意义的问题，提高到了90%以上，而且失败的那些case，虽然不能说都是由于软件bug引起的，但至少可以说也是软件的相关问题引起的。后来这批case经过测试人员的持续优化，帮助相关领 阅读全文
摘要：
在中国的软件行业，如果工作时间稍微长一点的话，应该都是从瀑布开发模式成长起来的，包括现在，很多公司其实还是采用瀑布开发的模式。当然，敏捷转型也是软件行业一个很热的topic。作为一个在传统的软件测试行业工作了8年多，在敏捷开发模式也工作了3年多的一个测试行业的老兵，很想从测试自动化的角度看两种开发模式的不同，以及测试自动化在其中的差异。先从传统模式说起吧，传统模式下，软件开发和测试人员分属不同的team，之间其实是有很多隔阂的。特别当时我们和开发人员还属于不同的site，沟通上面更加不是那们遍利。记得那时公司要推测试自动化，我给其中的一个基站测试部门介绍一个我们新开发出来的工具，可以模拟手机打 阅读全文
摘要：
现在对于自动化测试与CI往往有一些很常见的谬见，包括一些专门从事相关工作的人都未必清楚。在实际的工作中感触颇深，所以想撰文讨论一下。第一，自动化测试就是给CI服务的，或者自动化测试不太能发现问题。持有这种观点的人，建议他们去看看Google或者Microsoft的相关测试研究的文章，或者GTAC（ Google Test Automation Conference),也许可以拓宽我们考虑这个问题的思路。他们的测试对象是搜索引擎，海量的数据库信息，或者提供的各种服务，比如Google Map，Navigation。他们研究的是搜索引擎对于海量的数据库处理起来是否有效，搜索结果是否准确 。下面举几 阅读全文
摘要：
有很多测试仪器都只提供了基于Tcl的library，比如SmartBits， Ixia， AX4000。在网络通信测试上，它们都是很常用的通信测试仪器，但是目前的Robot只支持Python，所以就会碰到一个问题，如果来控制这些测试设备，来完成自动化测试呢？目前我能找到的，主要是两种做法，两种方法的优缺点分析：1.第一种方法要求执行自动化测试的机器本地必须安装Tcl以及测试仪器的控制library，有时候，如果对每台客户端都这么要求的话，可能会有点麻烦。优点应该是执行速度比较快，而且可以直接拿到 Tcl liabrary里面函数的返回值2.第二种方法应该是用起来比较简单，写完的自动化测试脚本， 阅读全文