51Testing软件测试网

 
 

常用链接

  • 我的随笔
  • 我的评论
  • 我参与的随笔

留言簿(3)

  • 给我留言
  • 查看公开留言
  • 查看私人留言

随笔档案

  • 2021年6月 (1)
  • 2021年3月 (1)
  • 2020年9月 (1)
  • 2020年3月 (1)
  • 2020年1月 (2)
  • 2019年12月 (3)
  • 2019年11月 (5)
  • 2019年10月 (1)
  • 2019年9月 (2)
  • 2019年8月 (14)
  • 2019年7月 (20)
  • 2019年6月 (15)
  • 2019年5月 (12)
  • 2019年4月 (19)
  • 2019年3月 (20)
  • 2019年2月 (9)
  • 2019年1月 (16)
  • 2018年12月 (17)
  • 2018年11月 (21)
  • 2018年10月 (16)
  • 2018年9月 (20)
  • 2018年8月 (22)
  • 2018年7月 (3)
  • 2018年6月 (1)
  • 2018年5月 (7)
  • 2018年4月 (1)
  • 2018年3月 (3)
  • 2018年2月 (6)
  • 2018年1月 (2)
  • 2017年9月 (8)
  • 2017年8月 (28)
  • 2017年7月 (3)
  • 2016年11月 (1)
  • 2016年6月 (1)
  • 2016年4月 (1)
  • 2016年2月 (2)
  • 2015年7月 (1)
  • 2015年5月 (1)
  • 2015年4月 (2)
  • 2015年3月 (1)
  • 2015年2月 (2)
  • 2015年1月 (6)
  • 2014年12月 (3)
  • 2014年11月 (3)
  • 2014年10月 (3)
  • 2014年9月 (2)
  • 2014年8月 (8)
  • 2014年7月 (16)
  • 2013年12月 (5)
  • 2013年11月 (1)
  • 2013年10月 (3)
  • 2013年9月 (2)
  • 2013年8月 (2)
  • 2013年7月 (3)
  • 2013年5月 (1)
  • 2013年4月 (2)
  • 2013年3月 (2)
  • 2013年2月 (3)
  • 2013年1月 (4)
  • 2012年12月 (4)
  • 2012年11月 (4)
  • 2012年10月 (3)
  • 2012年9月 (4)
  • 2012年8月 (3)
  • 2012年7月 (4)
  • 2012年6月 (2)
  • 2012年5月 (2)
  • 2012年4月 (1)
  • 2012年3月 (2)
  • 2012年2月 (2)
  • 2012年1月 (1)
  • 2011年12月 (3)
  • 2011年11月 (2)
  • 2011年10月 (1)
  • 2011年9月 (4)
  • 2011年8月 (3)
  • 2011年7月 (2)
  • 2011年6月 (4)
  • 2011年5月 (4)
  • 2011年4月 (2)
  • 2011年3月 (4)
  • 2011年2月 (4)
  • 2011年1月 (7)
  • 2010年12月 (7)
  • 2010年11月 (5)
  • 2010年10月 (4)
  • 2010年9月 (7)
  • 2010年8月 (7)
  • 2010年7月 (3)
  • 2010年6月 (3)
  • 2010年5月 (4)
  • 2010年4月 (4)
  • 2010年3月 (5)
  • 2010年2月 (3)
  • 2010年1月 (4)
  • 2009年12月 (3)
  • 2009年11月 (3)
  • 2009年10月 (1)
  • 2009年9月 (3)
  • 2009年8月 (2)
  • 2009年7月 (3)
  • 2009年6月 (1)
  • 2009年5月 (2)
  • 2009年4月 (4)
  • 2009年3月 (5)
  • 2009年1月 (1)
  • 2008年11月 (2)
  • 2008年7月 (5)
  • 2008年6月 (4)

文章分类

  • 行业资讯(45) (rss)
  • 软件业务知识(43) (rss)
  • 软件开发知识(33) (rss)
  • 软件测试工具(39) (rss)
  • 软件测试技术(157) (rss)
  • 软件测试管理(40) (rss)
  • 软件测试职业发展(57) (rss)

51testing软件测试网

搜索

  •  

最新评论

  • 1. re: 淘宝后台技术大揭秘,不看这篇你双十一要损失几个亿!
  • 关注官方公众号“Atstudy网校”,点击中间菜单栏“双11”,领取双十一技术内幕资料。
  • --51testing
  • 2. re: 软件测试流程的一点感悟
  • 提交缺陷时只需要描述现象即可,过多的分析可能会误导开发
  • --凡客诚品
  • 3. re: 软件测试流程的一点感悟
  • 阿达宿建德江阿斯顿
  • --凡客礼品卡
  • 4. re: 手机软件测试的经验总结
  • 很好啊~不错
  • --乐蜂网
  • 5. re: 手机软件测试的经验总结
  • 很好啊~
  • --罗莱家纺

阅读排行榜

  • 1. 软件测试流程的一点感悟(1091)
  • 2. 5年经验之谈:月薪3000到30000,测试工程师的变“行”记!(940)
  • 3. 测试自动化及软件测试工具的比较(857)
  • 4. 银行线上信贷系统如何做好接口测试?手把手教你接口工具Postman(825)
  • 5. 软件为什么要做异常测试?测试员必知的22个测试点总结!(806)

评论排行榜

  • 1. 软件测试流程的一点感悟(4)
  • 2. 软件测试的原则和经验 (4)
  • 3. 嵌入式软件测试技巧(2)
  • 4. 手机软件测试的经验总结 (2)
  • 5. 常用软件测试工具的分析与比较(1)

Powered by: 博客园
模板提供:沪江博客
IT博客 | 首页 | 发新随笔 | 发新文章 | 联系 | 聚合 | 管理

软件测试工程师的职业素质

  记得以前面试过一个女孩,她认为软件测试就是点击网页,囧,作为一名软件测试工程师,我当时真是无地自容啊。相信很多人都把这个职业想象的非常简单,作为软件测试工程师的我,是有必要普及一下软件测试的童鞋都需要在哪些方面提高自己的。

  1.分析能力。软件测试的核心其实应该就是设计测试用例了(具体啥样的用例设计,请参见《什么样的测试用例是好的》),而设计测试用例,就是依赖与分析能力了。这里我们不说那些常用的设计方法,从一个稍高的层面上来讲,可以说就是怎么将一个复杂的系统进行抽象,分析拆成几个不同的维度,结合维度可能出现的情况进行有选择的组合,以最小成本获取最大的收益。无法将一个复杂系统拆解成简单的维度,是没法做好用例设计的

  2.编程语言。语言其实就像说话一样,只不过我们常说的英语日语之类是与人沟通,计算机语言就是与计算机进行沟通的。对于测试工程师来说,精通一门语言,熟悉其它几门语言是有必要的。对于不同语言编写的被测程序,是有不同特点的,如果对实现的语言不了解,无法进行白盒测试,没法看代码diff(结合代码diff做测试)来提高效率。对于特点不了解,可能也会导致自己漏掉部分内容。

  3.设计能力。不要认为设计能力就是开发工程师的事情,拥有好的设计能力,就可以在设计评审的时候多提意见,促进开发工程师使用好的设计,不仅对开发有好处,对测试也是很有好处的。这样才能防患于未然,不仅自己的劳动力,也节省团队的劳动力。

  4.对业务的理解。对业务的理解越充分,就越能够理解最终用户的需求,促进产品设计使用好的方式,促进产品成功。难道你想做一大堆不成功的项目么,那样是多么没有成就感的一件事啊。

  5.自动化相关的考虑。随着项目越来越多,系统的测试项目也会积累的越来越多,每次有新功能了,难道要用手工来回归一下原有的case么。自动化测试是提高回归测试效率的唯一解决方案(如果你说还有解决方案就是不回归,我…),以高效率促进高质量,才是一个良性循环的发展方式啊。

  嗯,以高效率促进高质量,我觉得很有很有道理。

本文转载自51Testing软件测试网,原文链接:

http://www.51testing.com/html/36/n-220536.html

posted @ 2010-09-26 14:04 51testing 阅读(167) | 评论 (0) | 编辑 收藏
 
软件测试流程之我所见

  做了这么久的测试工作了,想谈下我对测试流程的一些观点和看法。

  软件测试在短短的几年时间,发展比较迅速,还记得当时毕业那会,对软件测试这个行业还真的很陌生,当时有同学找到工作,是做软件测试的,当时就感觉很奇怪,还有这个行业,只听过做研发的,没听过做测试的,但是短短的5年时间,让我亲身体会到了软件测试发展之迅速,也让我从门外汉慢慢的对软件测试有了比较深刻的理解。刚开始以为测试也就是简单的运行下被测试的系统(当时就认为是软件),看看有啥问题没有,对于测试计划、测试用例简直是一窍不通。一个偶然的机会,让我有机会到一家大公司做了软件测试,这个起点也对我以后的工作有一个比较大的影响,下面就这些年得测试工作,谈下我对软件测试流程的一些看法吧。

  1)测试需求分析

  首先接到一个需求,不光是开发介入,还需要测试介入,这样测试工作才不会这么被动,被开发推着走,不能遇到什么需求,开发都做得差不多,要提交测试了,测试的才知道,这样测试准备肯定不充分,测试工作也不会开展的很顺利,很容易测试工作做的不深入,会遗留一些隐藏的bug。接到需求后,测试人员进行测试需求分析,提炼出我们的主要测试功能模块。然后根据需求分析,估算下测试的工作量,做一下大概的计划。

  2)测试设计

  测试设计包括:方案设计和用例设计

  根据需求分析结果,进行测试设计工作,测试设计,分为测试方案的设计和测试用例的设计。测试方案的设计一些公司直接和测试用例设计合并到一起来做。或者直接就省略掉了这个环节。我觉得测试方案设计省略掉可能会导致测试用例设计不够完善,功能点覆盖不够全面。为什么呢?首先看下,什么是测试方案?测试方案就是把需求分析后提炼的东西再进行整理,划分出被测系统的功能模块和数据流走向,以及每个模块的测试点。测试方案是测试用例设计的输入,测试方案也方便对系统不了解的人快速的了解被测试系统。对一个新员工来说,通过方案可以很容易了解所要测试的系统,从而很快加入测试队伍开展测试工作。测试用例呢,说白了,就是对测试方案的细化,测试方案确定了被测试系统的测试点,但是没有确定测试的输入和输出,测试用例,就是来确定测试的输入和输出。如要测试一个登陆系统,那么测试方案会描述登录系统的功能、登录系统的数据流走向、登录系统的测试点(正确输入、错误输入,两种输入对应的输出),而测试用例,就要把登陆系统进行细化,正确的输入是什么,输出是什么,错误的输入是什么,输出是什么。好的用例,就是一个输入对应唯一一个输出,而不是多个不同的输出。

  3)测试准备

  测试准备工作一般包括:测试数据准备、测试脚本准备、测试环境准备

  4)测试执行

  5)测试评估

本文转载自51Testing软件测试网,查看全文:

http://www.51testing.com/html/28/n-99328.html

posted @ 2010-09-20 13:58 51testing 阅读(131) | 评论 (0) | 编辑 收藏
 
软件测试的三重境界

  当我看到王国维先生在《人间词话》中所谈到人生三种境界,我就会有一个问题,软件测试这项工作的三种境界又是什么?软件测试的最高境界是什么?先让我们复习一下人生的三种境界:

  Ⅰ.“昨夜西风凋碧树,独上高楼,望尽天涯路。”,有远大志向,不同一般人的志向,高瞻远瞩。

  Ⅱ.“衣带渐宽终不悔,为伊消得人憔悴。”,为了自己的远大志向,孜孜以求,努力、勤奋地工作,无怨无悔。

  Ⅲ.“众里寻他千百度,蓦然回首,那人却在,灯火阑珊处。”,反复追寻、研究,专注、下足功夫,自然会豁然贯通、功到自然成。

  三种境界可以看成是一个完整的、成功的人生过程,宏伟目标、奋斗、收获。

  联想到测试,这样的境界也是适用的。但是,如果更具体地看到这个问题,那么如何定义其三种境界呢?

  软件测试简单地说就是发现软件中的缺陷,所以从找缺陷的境界看,软件测试的三重境界是:

  Ⅰ.测试过程中,一直渴望发现缺陷,看到别的工程师发现了不少缺陷,但自己就是发现不了缺陷,比较迷茫。

  Ⅱ.有了更多的测试经验和技巧,对客户需求也有较好的理解,测试有针对性,能够有效地发现缺陷,并能举一反三,找到更多的缺陷。

  Ⅲ.当水平到了炉火纯青的地步,只要缺陷出现在面前,绝对逃脱不了,而且知道什么地方会存在缺陷,手到擒来,有缺陷想不发现都难。

  当然,软件测试不局限于“找bug”,还要跟踪缺陷、分析缺陷,而且要不断提高测试效率,如引入自动化测试等。从更全面的角度去看,软件测试的境界又如何描述呢?在描述之前,需要说明一下,境界和功能是不一样的,虽然它们之间有关系。能力是掌握了实实在在的知识、技术和工具的程度,而境界更多体现在抽象的形态上,包括心态、思想境界以及处理问题的习惯、自然方式等。下面就讨论一下软件测试的三层境界。

  第一境界:测试和人是分离的。测试仅仅是一份工作,做测试是被动的,测试工作往往停留在表面上,别人说什么就什么,容易受产品设计人员、开发人员等左右。虽然也会学习一些软件测试知识,但不够深入,不会主动多问自己几个“为什么”。测试过程中很难发现缺陷,发现的缺陷也是比较肤浅的缺陷。发现了缺陷后,也只是报告出来,不会追究下去,不会举一反三。也不会主动配合开发人员工作——挖掘缺陷产生的根本原因。

  第二境界:测试和人靠得比较近。喜欢测试,测试工作中有很强的主动性,开始钻研测试的方法。测试过程中,理解用户的需求,从用户需求出发来指导自己的测试,对实现的功能有自己的理解,不再被开发工程师左右。测试过程中,针对性更强,善于思考,能够采用不同的测试手段来完成测试任务,包括使用测试工具。开发测试脚本来执行测试,提供测试效率。

  第三境界:测试盒人融合在一起。把测试视为自己的一生事业,全身心致力于测试,真正理解了测试真谛。测试不再只是发现缺陷,而是对产品质量的评估,发现产品产生的根本原因,帮助整个开发团队预防缺陷。在工作中,主动和产品设计人员讨论用户需求,帮助开发人员建立设计规范、代码规范,督促开发人员遵守规范。建立良好的自动化测试框架,不仅使测试工作更轻松、有趣,还能助开发人员的单元测试一臂之力。利用业余时间钻研测试,重新思考现有的软件测试思想,树立一套自己认可的思想体系,努力在测试方法上有所创新。这时候,测试不仅出现在工作中,而且出现在生活中,碰到任何一个产品,都会不自觉地检查它,找到它的不足。对生活中的任何对象,都有一种审视的态度,一种积极的看待问题办法,包括提出如何改进产品的建议。生活还是乐观、积极的,而不是抱怨、挑剔,只是看待问题的角度不同,或不会错过任何“测试(审视)”的机会。

本文转载自51Testing软件测试网:http://www.51testing.com/html/39/n-219939.html

posted @ 2010-09-15 14:35 51testing 阅读(126) | 评论 (0) | 编辑 收藏
 
也谈测试用例

  【摘要】 测试用例英文名叫Test case,测试用例是开展测试工作的重要一项,测试用例是否完善、质量高低以及执行的情况如何是影响软件测试结果的一个重要方面。可以说测试用例是软件测试中一个举足轻重的因素。本文就有关问题进行阐述。

  【关键词】测试用例

  概述

  测试用例(checklist),是关于具体测试步骤的文档,它描述了测试的输入参数、条件及配置、预期的输出结果等,以判断被测软件的工作是否正常。从表现形式上而言,测试用例可以是纯文本的说明文档,也可以是用脚本语言或高级语言编写的一段代码。

  测试用例文档由简介和测试用例两部分组成。简介部分编制测试目的、测试范围、定义术语以及测试背景等。测试用例部分逐一列示各测试用例,测试用例应当包括测试标识、测试用例名称、目标、测试条件、测试设置、输入数据要求、步骤、以及预期的结果等。

  好测试用例的特点

  1.完整

  完整性是对测试用例最基本的要求,尤其是一些基本功能项上,如果有遗漏,那将是不可原谅的。完整性还体现在中断测试、临界测试、压力测试、性能测试等方面,这方面测试用例也要能够涉及到。

  2.准确

  测试者按照测试用例的输入一步步测试完成后,要能够根据测试用例描述的输出得出正确的结论,不能出现模糊不清的语言。

  3.简洁

  好的测试用例每一步都应该有响应的作用,有很强的针对性,不应该出现一些冗繁无用的操作步骤。测试用例不应该太简单,也不能够太过复杂,最大操作步骤最好控制在10-15步之间。

  4.清晰

  清晰包括描述清晰,步骤条理清晰,测试层次清晰(由简而繁,从基本功能测试到破坏性测试)。清晰简洁对测试用例编写者的逻辑思维和文字表达能力提出了较高的要求。

  5.可维护性

  由于软件开发过程中需求变更等原因的影响,常常需要对测试用例进行修改、增加、删除等,以便测试用例符合相应测试要求。测试用例应具备这方面的功能。

  6.适当性

  测试例应该适合特定的测试环境以及符合整个团队的测试水平,如纯英语环境下的测试用例最好使用英文编写。

  7.可复用性

  要求不同测试者在同样测试环境下使用同样测试用例都能得出相同结论。

  8.其他

  如可追朔性、可移植性也是对编写测试用例的一个要求。

  ......

本文转载自51Testing软件测试网,查看全文:

http://www.51testing.com/html/40/n-6440.html

posted @ 2010-09-10 15:24 51testing 阅读(141) | 评论 (0) | 编辑 收藏
 
一个软件测试工程师的学习体验

  【摘要】 软件质量越来越受到人们的关注,软件测试作为新兴行业有很多不完善的地方。很多从事软件测试工作的同行处于迷茫之中,如何提高,如何解决测试工作中的实际问题,困惑着每一个人。本文总结了一下个人经验,希望对大家有帮助。

  【关键词】 软件测试 软件 测试学习软件测试工程师

  我最初参加测试工作的时候,不知道什么是软件测试,集成测试和系统测试的概念经常混淆, CMM 是什么就更加不知道了。那时候最简单的开关机也是通过直接拔插电源完成,安装系统对我来说简直是有史以来人类的最高技能,对于那些拿着螺丝刀安装机器的人就认为是宇内超级高手,身具杀人于无形之绝世秘技。拿破仑说不想当将军的士兵不是好士兵,我最初的梦想就是想成为软件测试的高手,傲视天下。所以不断偷师,总结经验,自认为掌握了成为高手的几个秘技,这几年混迹 “ 江湖 “ 还算无往而不利。不敢独享,望与吾辈测试人员切磋,早日总结成功密技之大成,助新进人员早日入门,也算不愧对东北活雷锋的称号。

  第一招学会利用网络

  刚参加工作面对浩瀚的网络世界,当时如刘姥姥进大观园,什么都新奇,什么都想要,从网上下载很多源程序的代码,软件技术文档之类,恨不得把所有的好东西收集到手中,其实有些在他人看起来就是垃圾一堆。当时觉得有了这些 “ 武林秘籍 “ ,成为高手指日可待。最初参加工作由于自己工作努力有幸转为开发,加入项目组后我的习惯还是没有改,反而变本加厉,手中的资源更加多,上网的时间更加频繁。

  一次项目经理分配任务,觉得依靠手中的秘籍加上自己的 “ 聪明才智 “ 很快会完成,不料短短的时间,所有的一切变成了马奇诺防线。解决问题很慢,思路不清晰,项目经理在对我施压的过程中教会了我终身难忘的一招,学会利用网络寻找要解决问题的答案,从此 Google 成了我的最爱,关键字成了我变化的招数。在软件测试工作中,他帮我解决了很多疑难问题,解答了很多令我迷惑的地方。也是我帮助测试同行解决问题手段之一,很多软件测试新手,甚至老手都没有意识到自己手上就握有 “ 无敌秘籍 “ ,所以只要你耐心找,答案就在身边。

  这里总结一下利用网络搜索引擎的技巧:

  ● 组合搜索

  每次搜索某个文件,如果只给出一个单词进行搜索,经常会出现成千上百万计的匹配网页。然而如果再加上一个单词,那么搜索结果会更加切题。

  ● 选择表述内容的词组

  一般我在网页搜索引擎的时候,选择一些可以表达我要查找内容的关键词组,用来缩小搜索范围,从而找到搜索结果是最好的办法。运用词组搜索涉可以先先简单地输入一个问题作为词组搜索,如果仍然找不到合适的,那就用多个可以表达要查询内容的关键字进行查询。

  ● 定位信息来源

  有的时候用词组搜索不到或者无法准确表达所需信息。可以用另一种方法直接到信息源,就是直接到到提供某种信息的站点去。可以用公式 “www. 公司名 .com” 去猜测某一组织的特点。从而得到所要搜索的信息的主要词组

  其实网络上还有很多关于搜索技巧的文章,大家可以自行学习。千万要记住搜索引擎是帮助你成功的有力武器。

  ......

本文转载自51Testing软件测试网,查看全文:

http://www.51testing.com/html/45/n-6545.html

posted @ 2010-09-07 13:23 51testing 阅读(125) | 评论 (0) | 编辑 收藏
 
项目中测试工具的应用

  随着企业越来越重视软件质量,软件测试的地位逐步提高,测试的重要性逐步显现,测试工具的应用已经成为了普遍的趋势。目前用于测试的工具已经比较多了,这些测试工具一般可分为白盒测试工具、黑盒测试工具、性能测试工具,另外还有用于测试管理(测试流程管理、缺陷跟踪管理、测试用例管理)的工具。(AutoRunner,TestCenter,TAR)

  总的来说,测试工具的应用可以提高测试的质量、测试的效率。但是在选择和使用测试工具的时候,我们也应该看到,在测试过程中,并不是所有的测试工具都适合我们使用,同时,有了测试工具、会使用测试工具并不等于测试工具真正能在测试中发挥作用。因此,本文拟从测试工具的选择和使用方面着手,讲述一点本人的心得。

  1、 应用测试工具的目的

  应用测试工具的目的很明确,一般而言,在测试过程中应用测试工具主要为了以下几个目的:

  a) 提高测试质量;

  b) 减少测试过程中的重复劳动

  c) 实现测试自动化

  在测试中应用测试工具,可以发现正常测试中很难发现的缺陷(例如,Numega的DevPartner工具就可以发现软件中的内存方面的问题)

  2、 测试工具的分类和选择

  一般而言,我们将测试工具分为白盒测试工具、黑盒测试工具、性能测试工具、测试管理工具几个大类。

  a) 白盒测试工具

  白盒测试工具一般是针对代码进行测试,测试中发现的缺陷可以定位到代码级,根据测试工具原理的不同,又可以分为静态测试工具和动态测试工具。

  i. 静态测试工具

  静态测试工具直接对代码进行分析,不需要运行代码,也不需要对代码编译链接,生成可执行文件。静态测试工具一般是对代码进行语法扫描,找出不符合编码规范的地方,根据某种质量模型评价代码的质量,生成系统的调用关系图等。

  静态测试工具的代表有Telelogic公司的Logiscope软件、PR公司的PRQA软件。

  ii. 动态测试工具

  动态测试工具与静态测试工具不同,动态测试工具的一般采用“插桩”的方式,向代码生成的可执行文件中插入一些监测代码,用来统计程序运行时的数据。其与静态测试工具最大的不同就是动态测试工具要求被测系统实际运行。

  动态测试工具的代表有Compuware公司的DevPartner软件、Rational公司的Purify系列。

  b) 黑盒测试工具

  黑盒测试工具适用于黑盒测试的场合,黑盒测试工具包括功能测试工具和性能测试工具。黑盒测试工具的一般原理是利用脚本的录制(Record)/回放(Playback),模拟用户的操作,然后将被测系统的输出记录下来同预先给定的标准结果比较。黑盒测试工具可以大大减轻黑盒测试的工作量,在迭代开发的过程中,能够很好地进行回归测试。

  黑盒测试工具的代表有Rational公司的TeamTest、Robot,Compuware公司的QACenter,另外,专用于性能测试的工具包括有Radview公司的WebLoad、Microsoft公司的WebStress等工具。

本文转载自51Testing软件测试网,查看全文:

http://www.51testing.com/html/42/n-87342.html

posted @ 2010-09-02 13:34 51testing 阅读(140) | 评论 (0) | 编辑 收藏
 
软件测试工具的认识误区

  软件测试工具可以提高测试效率,减少测试执行时间,提高测试效率。但是测试工具不是万能的,过分强调测试工具的作用,极力追求各种软件测试工具,是软件测试本末倒置的表现。遗憾的是不少初入测试行业的新手,对软件测试工具的作用存在很多片面的认识误区。

  认识误区之一:利用工具能发现软件中的全部或大部分的缺陷

  实际上,测试过程中80%以上的缺陷是手工测试发现的,仅有不到20%的缺陷是自动测试发现的,而且这20%的发现要求测试人员合理的运用工具。

  认识误区之二:软件测试工具可以放之四海而皆准

  工具都是针对解决某些特定的问题而开发的,所以必然有其局限性。软件测试工具自身同时也是软件,因此也会存在软件兼容性等不可避免的软件通病。而且测试工具只能解决某一方便的问题,应用范围狭窄软件测试工具的不足。

  认识误区之三:运用软件测试工具后测试工作马上减轻,进度马上缩短

  由于在测试过程中增加了新的元素,必然增加了测试过程的复杂度。因此在使用工具的初期通常会使工作量、消耗时间等各项成本较手动测试增加25%--50%,而不是象多数人想象的那样可以很快降低成本。

  认识误区之四:测试工具可以很快上手,不需要专门培训和学习

  许多厂商试图通过夸大工具易于使用来宣传兜售其产品,指出工具能够简单的录制就可以用于回放。实际上有效的自动化不是那么简单, 录制期间工具生成的测试脚本必须人工修改,这需要工具脚本知识,从而使脚本健壮、可重用并可维护。

  测试人员必须掌握工具与脚本语言。因此,要使用任何新测试工具需要专业的培训与学习,并且在测试项目中不断实践应用,才能不断掌握。

  认识误区之五:通过工具我们可以达到100%的测试覆盖率

  工具可以增加测试覆盖的深度和广度,但是即使面对有限的功能点,依靠工具也仍然无法进行100%的测试。

  总之,是否使用测试工具,取决于测试的具体要求。选用什么样的测试工具,取决于测试的具体要求,而且测试工具并不能买来就用,需要参加专门的培训,并且不断学习;市场上能买到的测试工具可能并不能完全满足当前测试项目的要求。如果在时间、资源、技术许可的情况下,最好公司内部开发专用测试工具。

本文转载自51Testing软件测试网:http://www.51testing.com/html/17/n-91717.html

posted @ 2010-08-30 13:50 51testing 阅读(154) | 评论 (0) | 编辑 收藏
 
解析软件测试人才的缺失

  “这软件测试人员都到哪去了!都招了半年了,怎么还没有人?!”经理着急的吼叫还回响在走廊里。“这十几万年薪的诱惑力,不是根本不合格就是伪装着来面试开发的!测试人员怎么就这么缺呢?”

  相信很多IT公司的招聘经理都遭遇过这样的场景。近年来,软件测试人员迅速窜红,是当今最受IT企业青睐的人才,与3G人才、动漫人才等共同成为目前国家重点培养的对象。虽然近几年计算机专业毕业生数量增多了,IT 行业的某些人才已严重过剩。但是,主体职业中软件测试工程师却很受企业欢迎,一直名列“最新需求”前三名。

  缺而复缺

  是什么原因造成了软件测试方面人员持续的短缺呢?人才的严重稀缺,让软件测试人员的工资也水涨船高,通常而言这会引来技术人员的转向,为何我国“测试工程师不足”的局面仍没有改变,缺而复缺?……带着这些问题,记者采访了网迅(中国)软件公司QA高级总监 朱少民先生。

  朱少民认为国内客观因素决定了软件测试人员比较缺乏。在过去二十多年,国内大多数软件公司主要是针对特定客户开发定制的、一次性的软件系统(暂且称为“软件项目开发”),而从事于通用性的软件产品开发的软件公司很少。软件项目开发和软件产品开发,在开发流程上没多大区别,但在开发模式、关注产品质量的程度上有很大差别。项目开发一般都建立在很好的客户关系上,公司的主要精力集中在功能实现上,往往忽视了软件的质量。而通用的软件产品销售或服务,主要靠质量取胜,所以在开发时非常关注质量,在软件测试上的投入自然就会大。“有一个例子说明,过去我公司招进来的几百名测试人员之中,在进入公司之前曾从事过规范的、专业的测试工作的工程师,大概只占5%,95%都是靠自己培养的。”

  人才的严重稀缺,让软件测试人员的工资也水涨船高,通常而言这会引来技术人员的转向,然而我国“测试工程师不足”的局面仍没有改变,缺而复缺。实际上“物以稀为贵”只对富有经验的专业测试人员成立。从平均数看,软件测试人员的工资还是低于软件设计、编程人员的工资。

  造成这种现实的原因有两点:首先是软件企业对人才认识存在误区、偏见,不能在很短的时间内被消除;其次,由于大量外资企业进入中国,互联网第二个春天再现、软件即服务(SaaS)模式的兴起,人才市场上对软件测试人员的需求越来越大,但真正合格的软件测试人员不多、增长不快,大学的计算机教育和实践脱节,所以许多没有软件测试经验的人员被录用来从事软件测试,从而从侧面支持了某些偏见的成立,例如,认为不管什么样的技术人员都可以从事软件测试,似乎进入一个相对的恶性循环,使“合格的测试工程师不足”的局面没有实质性的改变。

本文转载自51Testing软件测试网,查看全文:

http://www.51testing.com/html/96/n-65696.html

posted @ 2010-08-25 13:20 51testing 阅读(134) | 评论 (0) | 编辑 收藏
 
2010 IBM Rational"软件创新论坛"大会报名!

2010 IBM Rational"软件创新论坛"大会报名!

大会源起
相信您对“创新”一定不陌生,逢人必谈,逢会必说,甚至可能有些审美疲劳!但很多时候“创新”只停留于口号,不注重团队与工作过程,实际工作中无从下手,如代码冗余导致开发量大,程序执行效率低,或沟通效率不高,团队凝聚力不足够,创新无力。直接的反映就是产品竞争力不足,市场反响不佳,业务平平。
这一切将彻底改变,IBM Rational 软件创新论坛Innovate 2010将在深圳(8月24日),北京(8月27日)、盛大开幕。届时,您将了解到IBM Rational平台是如何助您实现包括团队创新、工作创新、结果创新的“全程创新”,为您的开发找准创新着力点,全面提高产品市场竞争力。

大会亮点
作为开发者盛会,将近80名IBM资深专家为您讲解最新技术,历届规模最大,更有诸多亮点不容错过:
●  特别针对电子汽车航空行业的嵌入式系统设立专场;
●  国际技术潮流零距离:来自美国等地的合作伙伴进行增值解决方案的展示,;
●  "软件工程健康诊所"现场办公:自测与专家出诊同时进行;
●  IBM中国实验室的现场演示与体验专区:感受最新技术与产品信息;
●  大会现场将特设热卖场,各种热卖活动,绝对物超所值!

日程
北京站>>
时间:2010年8月27日(星期五)
地点:北京国际饭店国际会议中心
地址:建国门内大街9号
电话:010-65126688

深圳站>>
时间:2010年8月24日(星期二)
地点:深圳福田香格里拉大酒店
地址:中国深圳福田区益田路4088号
电话:0755-88284088

本次大会免费报名参与,同时会有一顿免费自助午餐和一份礼品赠送。欢迎大家踊跃报名!

报名请点击:http://bbs.51testing.com/thread-282779-1-1.html

posted @ 2010-08-20 13:56 51testing 阅读(91) | 评论 (0) | 编辑 收藏
 
用别的眼光去感悟软件测试

  曾经对软件测试很轻视,因为我那时很无知,只是一名普通的中国程序员,这也是那时绝大多数程序员的心态,那时中国程序员最讲究“编程才是硬道理”。

  如今却非常热爱软件测试,包括软件测试工具,方法,理论,技术。因为我在3年的测试工作中,深刻体会到软件测试的重要性和趣味性。此时,我已经跳出了“小程序员”的圈子,以软件系统工程的更大视角审视软件测试这项工作。

  很长时间以来我一直被下面的问题而困惑,有些问题至今仍然只是具有肤浅的认识,而且,我感觉我做的测试项目越多,阅读的测试书籍越多,我越感到我对软件测试理解的越肤浅。因为我越来越感受到软件测试的广度和深度的无限性,它像大海宽广,像宇宙那样深邃。 为什么要进行软件测试?软件测试的前途如何?软件测试的工具和思想谁更重要?软件测试的最高境界是什么?

  软件测试是保证软件质量的重要活动,是软件项目实施的不可缺少的环节。软件测试的直接目的是发现软件中存在的缺陷。此为测试的有效性。

  在软件项目没有结束之前的全部软件缺陷主要由软件开发人员负责,因为软件缺陷来自程序员的编程。软件项目结束后的软件缺陷主要由软件测试人员负责,因为软件测试人员没有在软件发布之前的测试中没有发现隐藏的错误。 但这不是绝对的,因为软件项目是一个系统工程,软件质量牵扯到多个部门和人员,以及需求分析,设计,编码等各个环节和过程。软件测试只能证明软件存在缺陷,不能保证软件没有错误。

  软件测试不是万能的,因为不可能发现全部的软件缺陷,而且软件的功能和性能不是由测试决定的。此为测试的有限性。

  软件测试目前主要以手工测试为主,自动测试工具虽然很多,但实际应用的广度和深度还有很大潜力,自动将有很大的发展空间!。

  软件驱动开发的观点说明了测试与编程的关系,测试应该贯穿于软件开发的整个生命周期,编程只是软件开发的一个环节。但往往大家非常重视软件编程,把测试作为编程后的一个辅助环节。这是典型的本末倒置。 软件测试的缺陷管理流程非常重要,报告的软件缺陷的质量,应该由他人验证,做到责任明确,方法简便可行。

  软件测试技术不断进步,但总体来看,国内的测试重视程度还不够,但已经发展很快。差不多两年之前,国内计算机书店中关于软件测试的书籍非常稀少,如今却琳琅满目,异彩纷呈。
  

  本文转载自51Testing软件测试网,查看全文:

  http://www.51testing.com/html/82/n-18282.html

posted @ 2010-08-17 14:57 51testing 阅读(100) | 评论 (0) | 编辑 收藏
 
仅列出标题
共55页: First 44 45 46 47 48 49 50 51 52 Last