摘要: 我先是自己来调试原来一直跑不起来的case,发现之所以前面的case失败了,会影响后面的case,其实是由于case之间的独立性不好引起的。为了能解决这个问题,我还和team一起设计了一个复杂的环境恢复的keyword,里面判断了不同情况下,如果有板子没有起来,应该怎么恢复的问题。用了这个方法,case执行的稳定性逐渐提高了。大概过了1-2个月左右,case执行的通过率从原来的在40-50%徘徊,而且也不能发现比较有意义的问题,提高到了90%以上,而且失败的那些case,虽然不能说都是由于软件bug引起的,但至少可以说也是软件的相关问题引起的。后来这批case经过测试人员的持续优化,帮助相关领 阅读全文
posted @ 2012-03-01 00:51 blue_energy 阅读(387) 评论(0) 推荐(0)
摘要: 在中国的软件行业,如果工作时间稍微长一点的话,应该都是从瀑布开发模式成长起来的,包括现在,很多公司其实还是采用瀑布开发的模式。当然,敏捷转型也是软件行业一个很热的topic。作为一个在传统的软件测试行业工作了8年多,在敏捷开发模式也工作了3年多的一个测试行业的老兵,很想从测试自动化的角度看两种开发模式的不同,以及测试自动化在其中的差异。先从传统模式说起吧,传统模式下,软件开发和测试人员分属不同的team,之间其实是有很多隔阂的。特别当时我们和开发人员还属于不同的site,沟通上面更加不是那们遍利。记得那时公司要推测试自动化,我给其中的一个基站测试部门介绍一个我们新开发出来的工具,可以模拟手机打 阅读全文
posted @ 2012-03-01 00:48 blue_energy 阅读(1271) 评论(0) 推荐(0)
摘要: 现在对于自动化测试与CI往往有一些很常见的谬见,包括一些专门从事相关工作的人都未必清楚。在实际的工作中感触颇深,所以想撰文讨论一下。第一,自动化测试就是给CI服务的,或者自动化测试不太能发现问题。持有这种观点的人,建议他们去看看Google或者Microsoft的相关测试研究的文章,或者GTAC( Google Test Automation Conference),也许可以拓宽我们考虑这个问题的思路。他们的测试对象是搜索引擎,海量的数据库信息,或者提供的各种服务,比如Google Map,Navigation。他们研究的是搜索引擎对于海量的数据库处理起来是否有效,搜索结果是否准确 。下面举几 阅读全文
posted @ 2012-03-01 00:41 blue_energy 阅读(607) 评论(0) 推荐(0)
摘要: 有很多测试仪器都只提供了基于Tcl的library,比如SmartBits, Ixia, AX4000。在网络通信测试上,它们都是很常用的通信测试仪器,但是目前的Robot只支持Python,所以就会碰到一个问题,如果来控制这些测试设备,来完成自动化测试呢?目前我能找到的,主要是两种做法,两种方法的优缺点分析:1.第一种方法要求执行自动化测试的机器本地必须安装Tcl以及测试仪器的控制library,有时候,如果对每台客户端都这么要求的话,可能会有点麻烦。优点应该是执行速度比较快,而且可以直接拿到 Tcl liabrary里面函数的返回值2.第二种方法应该是用起来比较简单,写完的自动化测试脚本, 阅读全文
posted @ 2012-03-01 00:39 blue_energy 阅读(1411) 评论(0) 推荐(0)