Category Archives: 软件测试

best payday loans 缺陷工作流程和缺陷报告

最近在读《How We Test Software at Microsoft》 其中的缺陷和测试用例管理,发现很多思路和做法跟目前我们在进行的也颇为相似,总结如下: 缺陷管理和用例管理是一个软件测试项目的必备,无论是数千人的国际化大企业,还是三五人的小软件作坊。这都是测试队伍的两大工作成果。其中,测试用例描述测试 过程的意图,缺陷则描述这些测试用例的结果。,今天谈谈缺陷工作流程。 best online payday loans 缺陷工作流程为: 文字描述如下: 产品代码-》运行测试用例-》创建缺陷报告-》三方会审讨论缺陷 如果缺陷没有批准-》把缺陷当作不修正来解决-》关闭缺陷 如果缺陷批准了要调查-》研究是代码错误还是设计错误 如果是代码错误,提议修正代码错误-,在提交三方会审-》如果修正批准了-》修改代码-》解决缺陷-》重现缺陷-》通过了则关闭缺陷;不通过,则重新激活-》重新调查是代码错误还是设计错误 如果是设计错误,修正错误直到批准-》再进行三方会审。其他后续流程和以前类似。 在这里需要注意的是,有些缺陷需要综合考虑优先级别,产品发布周期等因素,标注为不予修复。也就是说虽然承认该缺陷,但不会修正,或者决定推迟修正,即该缺陷会在未来的版本修正。这些不予修正的缺陷应该在release notes中予以注明。 这里所说的三方会审,一般意义上指的是开发测试和项目管理。 缺陷报告中应该经常避免的几个错误: 1.电子邮件讨论 电子邮件和缺陷系统是大多数的工程师常用的工具,所以很多时候两者被混用就不足为怪了。然后除了开发工程师和测试工程师之外,缺陷报告还有其他的广泛用途,所以和缺陷不直接相关的信息不应该被写入报告。 2.缺陷渐变 缺陷渐变是说在同一个缺陷的报告中,缺陷从一个问题演变成另外一个不相关的问题。这种现象有时候发生很快,有时候过几天或者几个月。不管怎么样,都要极力避免缺陷渐变。对于已经变形的缺陷,通常很难分析其中根本原因,产品支持工程师在搜索相关问题时候还会发生混淆。如果一个缺陷报告开始演变,要及时停止,并就新问题重新报告一个新的缺陷。 3.对个缺陷 如果测试人员很忙碌,他们可能会相关的缺陷记录放在一个缺陷报告中。尽管我们尽力避免这类问题,在一个缺陷报告中报告几个问题从来就不是好主意。这会带来一系列的问题,比如: (1)缺陷的优先级别不能单独设置 (2)缺陷的决定不能单独设置,比如立即修复还是推迟到下一版本 (3)虽然缺陷在类似领域,但是可能需要分配给不同的开发工程师 (4)在分析产品缺陷的根本原因时候,同一缺陷报告中的每个缺陷可能有不同的错误根源。 关于缺陷报告的时候 这似乎是管理层最喜欢干的事情,这些报告发掘和代表了各种各样的数据。比如下面的一些度量: (1)修复的缺陷/所有解决了的缺陷:可以衡量缺陷修正和其他决断的比例 (2)缺陷发现率 (3)缺陷修正率:当缺陷会审标准提高时候,修正的百分比下降 (4)每个组件的缺陷数:根据功能排序可以影响哪些领域需要更多的测试 … Continue reading

Posted in 软件测试 | Tagged | Leave a comment

StAREAST and STARWest

今天介绍一下这两个非常有名的测试行业的权威组织,STAREAST 和 STARWEST。 顾名思义,这是分别在美国东部和西部举行的测试行业的一个高端盛会。这两个会议自从2000年开始举行,到今年已经是第十个念头了,每次的会议大概持续6天。前面五天是一些测试的主题演讲和技术展示,介绍的是测试行业的最新的技术,方法,工具等。而演讲嘉宾也都是行业的大师级别的人物。最后一天是一个软件测试和质量领导人论坛。 今年的STAREAST,也就是东部的盛会已经于4月25到30日在东部城市奥兰多闭幕,详细情况参考这里 2010年的STARWEST也筹备结束,将于2010年9月26-10月1日在美丽的西海岸城市加州的圣地亚哥举行。 下面是STAREAST今年6天中的第二天的演讲内容,其中包论的内容十分广泛,包括风险驱动的测试,测试设计技术,移动终端的测试自动化技术等等,当然也包括如今比较热门的敏捷测试等话题。今年的全部日程参考这里 《日程格式太乱,就不贴了,大家去原链接查看》 另外,这个会议的演讲者也是可以自己申请的(申请2011的演讲),忠心希望能有一天国内的测试同行有机会站在这样的国际会场上。分享我们自己的对于测试的理解和经验。 其实我第一次听过这个会议是2004年,我当时的Test Manager Rosa参与了STARWEST并带回了大量精彩现场的演讲的PPT,并指导我们当时的公司和团队顺利的从无到有成功的开展了自动化测试,最终在企业范围内搭建了一个自动化测试平台,并组建了一支强竞争力的自动化测试团队。早在2004,2005年的时候我们就完成了这一个在现在看来都十分了不起的成就,即便不是第一个,也是当时为数不多的比较成功的自动化测试的案例。 几句题化话: 我们当时的成功很大程度上归功于Rosa的丰富的测试经验和强有力的领导以及执行力。后来他虽然也离开了我们回到了美国,但是一直都有保持联系。

Posted in 软件测试 | Tagged | Leave a comment

用户界面测试的颠覆性技术-Sikuli

Sikuli绝对是一种颠覆性的技术,至少对于GUI的测试技术来说,是质的突破,比如它彻底解决了在这之前GUI自动化测试工具上的关键点-对象识别。 技术来自于从麻省理工学院计算机和艺术智能实验室的一个用户界面设计小组的研究项目,Sikuli脚本和Sikuli开发平台基于MIT License发布,是开源的。 什么是Sikuli ======== Sikuli是一种利用图片(快照)去搜索和自动化GUI的视觉技术,Sikuli的第一个release包含Sikuli脚本,也就是为Jython编写的一种视觉脚本API,同时包含了Sikuli IDE,一个可以非常容易的用快照书写视觉脚本的集成开发环境。Sikuli脚本可以自动化你在屏幕上看到的一切,而这不需要内部API的支持。你可以编程控制一个页面,一个运行在Windows/Linux/Mac OS X上的桌面应用程序,甚至于一个运行在模拟终端的iphone的应用程序。 Sikuli的必杀技 ======== 自动化所有你看到的一切 利用快照进行自动化 工作在Java平台(意味着可移植) Sikuli安装和使用 =========== 下载安装了一下,在Windows上需要JDK1.6以上环境,这里有一个简单的视频介绍(看不到youtube的同学翻墙吧)。 不会翻墙的地同学请从如下视频观看: 继续阅读论文 ========= GUI Testing Using Computer Vision Sikuli: Using GUI Screenshots for Search and Automation MIT news介绍图像驱动计算 一个例子快照 ========= 拭目以待!

Posted in 测试工具 | Tagged | 9 Comments

测试如何同开发搞好关系

测试跟开发是一对死对头。 你还在用这样的观点看待测试人员和开发的关系吗? 你已经out了。 测试人员跟开发的关系一直是一个矛盾的话题,如何处理和测试跟开发的关系,保持步调一致,把过程中的矛盾和对立统一到共同为提高产品质量这个主题和最终目标上来,是一个体力活,更是一门艺术。 这篇文章总结的不错,因为比较浅显易懂,就不一一翻译了,最终作者总结了四点: Tip #1: Don’t editorialize the bugs you find. 要理解开发人员,他们有时候也面临很大的压力,有时候犯一些低级的错误是难免的,要学会宽容。 Tip #2: Stay in sync with the development cadence 要跟开发保持同步,有时候你提交的bug得不到反馈并不是他们没看到,也不一定是问题不重要,要保持沟通,步调一致。 Tip#3: Isolate bugs effectively 提交bug之前要对bug进行初步的分析和简单的有效的定位,而不是发现问题立即就提交,最好能够问自己几个问题: 1)是否已经发现了能够重现问题的最简单的路径(Ricky注:很多时候发现一些测试人员提交bug的时候描述步骤是做了a, b, c, d, e … f, g, h 然后问题出现,其实经过追踪,发现问题出在f-g这一步,前面的一些都是无关的操作,要学会简单的定位问题,这不仅仅节省了开发人员的时间,而且节省了自己的时间) 2)是否弄错的程序的版本(Ricky注:很多时候,我们发现问题,往往是因为拿错了程序的版本或者问题在被测的版本中是已知的,这就要求在测试之前特别是提交bug之前,首先检查下版本信息和known … Continue reading

Posted in 软件测试 | Tagged | 3 Comments

测试工程师是否需要懂开发

.!. 这是测试界的一个永恒的话题:测试工程师是否需要懂开发(或者叫会编码) 文中论述的十分充分,最后的结论是 it depends,我在很大程度上十分同意文中的观点。我的观点是“测试工程师不一定要懂开发,但是懂开发可能对你的测试职业发展有很大的帮助” 原文地址 Am I a Tester or a Programmer? Who am I? Abhijit Navindgikar: “I am having one question regarding software testing. Currently I am working as a software tester. I am having 3 years of … Continue reading

Posted in 软件测试 | Tagged | 1 Comment

开源数据库性能测试工具HammerOra介绍

.!. 前段时间发现了这个工具,并粗略研究了一下,工具是基于TCL(Tool Command Language)语言的(我之前用Tcl工作过好几年,之前自动化框架就是基于Tcl来开发的,Tcl是非常优秀的自动化脚本语言) 首先HammerOra 是一款负载测试工具 其次HammerOra目前支持Oracle, MySQL和HTTP应用(web应用) 然后HammerOra是开源的,框架有点类似于商业工具LoadRunner 因为HammerOra是基于Tcl语言的,所以天生就是可移植的,可以运行于Windows平台和Linux平台。 HammerOra内嵌了两套标准测试脚本 tpc-c and tpc-h,当然你也可以自己开发和扩充测试脚本,开发语言是Tcl HammerOra包含三个部分(这点有点类似于LoadRunner)创建测试脚本(打开build-in的tpc-c or tpc-h)然后可以进行调试;配置并创建虚拟用户,并设置虚拟用户的策略,比如持续时间,用户迭代,rumpup原则等,然后控制场景运行;最后是监控事物计数器。对应于LoadRunner分别是VUGen, Controller and Analysis HammerOra的工作原理就是捕捉Oracle的trace文件,并生成相应的SQL脚本进行回放,所以对用户的场景模拟程度是非常高的。HammerOra跟Oracle的接口是也是利用一个Tcl的package OraTcl来完成的。(之前我们在开发测试平台时,后台驱动Oracle数据库操作也是通过这个package来完成的;记得我面试oracle第一个职位的时候,美国的同事还问到关于这个Package的几个问题) HammerOra的安装非常简单,一种是源码安装,还是就是安装包安装,就不多做介绍了,可以参考官方文档。 如果你要对数据库进行性能测试,预算有限的话,可以考虑这款优秀的开源工具。 脚本界面: 场景界面: 结果界面:

Posted in 测试工具 | Tagged , | Leave a comment

庆祝51Testing软件测试网成立五周年

真快啊,不知不觉,都已经五年了。 首先祝福51testing生日快乐。 虽不是51最早的一批注册会员,但是从事测试这个行业也超过5年了,而且也算国内比较早专职作自动化测试的团队和成员了,关于这段光荣史,有空还要好好续一下。 这5年可以说是国内测试行业迅速发展的5年,依靠这5年的努力,51testing早已经是国内测试行业的一块金子招牌了。 frida dvdrip 祝贺老李和老周,也期待51接下去有更大的发展,成为真正的中国测试行业的黄埔军校。 不知道看我blog的朋友有没有不知道51testing的,如果不知道的话,网址在下面。 51Testing软件测试网 :http://www.51testing.com

Posted in 软件测试 | Tagged | Leave a comment

Automate your Web Application with Oracle ATS

Oracle Application Test Suite (Oracle ATS)是基于Oracle收购的e-Test Suite技术而构建的企业自动化测试解决方案,也是Oracle Enterprise Manager的一部分, 随着更多的工具被集成到Oracle EM中来,这个Oralce的策略性产品也在变的越来越强大,最新的EM版本已经是10.2.0.5了,免费下载地址如下:下载地址 今天重点介绍一下Oracle EM中的ATS,以后Ricky会陆续关注EM中的其他组件。 Web application quality and performance issues can have major impact on your bottom line – impacting revenue, customer loyalty and satisfaction and your company’s reputation. However, even … Continue reading

Posted in 测试工具 | Tagged | Leave a comment