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)测试对象的逻辑路径和测试输入数据的组合几乎是无穷的,而穷尽测试是不可能的。

  即使是规模很小的软件或者软件产品,其逻辑路径和输入数据的组合也几乎是无穷的。假如测试人员想对测试对象进行完全的检查和覆盖,那基本上是不可能的,这就是国际软件测试认证委员会ISTQB大纲中提到的一条测试基本原则:穷尽测试是不可能的。

  面对测试对象中几乎无限的逻辑路径和软件输入数据的组合,如何有效选择和确定测试用例且满足测试覆盖率要求,是测试人员在测试设计过程中面临的一类重要问题。针对测试设计而言,该类问题主要表现在:

  ◆ 如何有效减少测试用例的数目?

  ◆ 如何避免测试用例之间的冗余?

  ◆ 如何满足测试覆盖率的要求?

  2)不同利益相关者对软件或者软件产品的质量要求是不同的。

  尽早和尽量多的发现软件或者软件产品中的缺陷,是测试的重要目的之一。开发人员或者其他利益相关者修复缺陷,并经过测试人员的确认测试和回归测试,就可以不断的提高软件产品的质量。但是,在测试过程中没有发现缺陷,并不代表测试对象就是高质量的软件产品,或者用户/客户就会接受该产品。

  根据Jerry Weinberg对质量的描述:“Quality is the value to some person(质量是可以为某人提供的价值)”,从中可以看出质量是带有内在主观性质的:对于同一个产品,不同的利益相关者对质量的理解和要求是不一样的。因此,测试人员在软件测试过程中,需要站在不同的利益相关者的角度,对测试对象的质量进行检查和验证。

  通常而言,软件产品的利益相关者在测试过程中扮演着有不同的角色,例如:项目经理、产品经理、客户/用户、操作员等。测试人员如何在测试过程中尽量多的考虑不同利益相关者对软件产品质量的要求和理解,是他们面临的另一类问题。针对测试设计而言,该类问题主要表现在:

  ◆ 如何获取利益相关者的不同质量要求?

  ◆ 如何设计测试用例以满足不同的质量要求?

  ◆ 如何分析和评估最终软件产品的质量?

  ◆ 如何提高客户对软件产品的满意度?

  3)测试时间和测试资源总是非常有限的。

  在实际的测试过程中,测试人员面对的测试范围和测试用例数目通常都是非常庞大的,而测试时间和测试资源却都非常有限。多年的测试实践经验表明,测试团队往往很难获得测试计划中预留的测试时间,当软件开发和测试的时间发生冲突的时候,测试团队常常被要求压缩测试时间;同时,测试过程中的测试资源限制,例如:测试平台、测试人员的限制,使得测试团队只能在有限的条件下开展测试活动。

  在这种情况下,如果没有良好的测试思想和技术的支撑,想要有效开展测试活动总是显得力不从心。针对测试设计而言,该类问题主要表现在:

  ◆ 如何有效的选择测试重点?

  ◆ 如何确定测试优先级?

  ◆ 如何有效的配置测试资源?

  ◆ 如何分析和评估测试的有效性?

  4)测试人员面对的需求经常是不完善的、经常变更的。

  软件或者软件产品的需求规格说明是测试人员进行测试设计和执行的基础,需求规格说明的准确性、完备性、可测试性等特性对成功进行测试非常重要。而实际的测试过程中,测试人员面对的需求规格说明常常是不全的、经常变更的,甚至没有任何需求文档。

  测试人员不能因为需求不完善之类的问题,就拒绝测试,或者仍旧保持这样的测试理念:测试仅仅依赖于需求规格说明,测试人员只要按照需求规格说明进行测试用例设计和执行,并覆盖了所有的需求条目,即认为达到了需求的覆盖率。相反,测试人员在面对此类问题的时候,必须查找有效的测试技术和手段继续进行测试,以保证测试的有效性和测试质量。针对测试设计而言,该类问题主要表现在:

  ◆ 如何获取尽量多的显现需求和隐现需求?

  ◆ 如何利用已有的经验有效设计测试用例?

  ◆ 如何应对需求的不断变更?

本文转载自51Testing软件测试网,查看更多:http://www.51testing.com/html/news.html

posted @ 2011-03-08 11:30 51testing 阅读(164) | 评论 (0) | 编辑 收藏
 
LoadRunner基础知识问答

  问题1:LoadRunner响应时间是什么?

  答:响应时间就是客户端发送请求,服务器返回最后(或者第)一个字节的时间。LoadRunner的事务函数功能是  度量客户端和服务器之间交互时间的。事务函数最后在分析图表里有,比如你在前边开发脚本的时候你在登陆功能中添加了事务函数,那么controller中运行1000个用户之后,在分析 图表中你就会看到1000个用户登录功能所消耗的时间(平均,其中1000个用户用的最多的时间,10000个用户用的最少的时间)。

  问题2:页面点击数与页面浏览数什么概念,页面点击数过高会对系统的性能产生什么影响?

  答:页面点击数:又名“hits”,它包括了点击了某个网页后,浏览器为了显示此网页而附带来的所有图片等支持文件的数量。“点击数”往往被用来衡量网站服务器的工作负载,也是衡量网站服务器性能的标准之一。文件数量的增多,会增加网络流量。

  页面浏览量(页面量):又名“PageView”,它是指实际被点击的网页数量。“页面浏览量”往往被用来衡量网站内容的受欢迎程度和被访问情况。

  问题3:在LoadRunner中有个Anget,这个Anget具体起什么作用啊?在讲Robot的架构的时候好像也提到过,但是没有讲Anget具体作用,是不是LR与Robot中Anget作用一样的呢?

  答:Agent 的作用是提供一个宿主环境提供虚拟用户运行,在LoadRunner中叫做Load Generator。

  问题4:这个章节中讲到了“响应时间”、“页面点击数”、“吞吐量”这几个概念,我想问一下,“响应时间”越快是不是就越好?“页面点击数”越少是不是就越好?“吞吐量”越大是不是就越好?

  答:性能是寻找执行效率与功能之间的平衡。这些不过是性能分析所关注的。不是越大越好。

  问题5:loadrunner如何选择协议?

  答:首先要熟悉应用程序的架构,采用什么协议进行通讯的.因为LoadRunner主要是通过捕获客户端与服务器之间的数据通讯包,根据这些数据包来生成脚本的.所以,如果协议选择不正确的话,LoadRunner就无法捕获客户端与服务器之间的数据通讯包。

  问题6:在脚本的录制过程中,怎么样去增强脚本,在这里我说一下,为什么要添加事务、集合点、参数化数据?

  答:添加事务是为了知道一个具体操作比如:登陆一个系统,服务器的响应时间。集合点:主要是为了模拟真实用户使用的并发情况的一种操作。

  参数化:主要是模拟真实用户的使用,输入提供不同的输入数据。

  问题7:指定代理设置,通过端口映射来限制特定端口发送的消息,不知道这样的设置起什么作用?为什么要指定协议的映射?

  答:这是因为具体的系统开发的问题,有些系统就是特定端口处理,你需要针对指定的端口进行处理,否则程序没办法处理

  问题8:什么是监控器?

  答:监控器就是在Controller中的一些图表。

  ......

本文转载自51Testing软件测试网,查看全文:http://www.51testing.com/html/15/n-228915.html

posted @ 2011-03-03 16:05 51testing 阅读(200) | 评论 (0) | 编辑 收藏
 
手机软件测试简介

  1、手机软件测试背景

  我国的手机测试技术从总体上说属于刚刚起步阶段,近几年经历了从无到有的过程。现在的水平基本上能满足手机测试的要求,但是同发达国家的先进生产厂商的差距是全方位的,无论是从实现技术上,流程的规范性与合理性,还是从对测试概念的理解上都有相当的距离。又加上手机产业的巨大发展潜力,所以,手机测试技术在我国手机开发行业中必将面临着更加激烈的竞争和强大的挑战。

  测试伴随在整个手机软件开发的各个阶段中。测试的成功与否,测试的覆盖性好坏与测试质量的高低直接关系到手机软件的可用性,友好性,可靠性。直接影响到产品能否如期上市,关系到手机厂商的切身利益与长期的市场竞争力。可以说,测试环节是手机软件开发的重要环节,是整个开发过程的“中枢神经”。同时,测试用例的设计在测试过程中是非常重要的一个环节,是重中之重。

  2、测试用例的常见分类

  2.1 基本功能测试

  基本功能是指手机软件向手机用户提供的最小的、可以进行的所有简单操作的集合。对基本功能的测试是指测试工程师在被测试的手机上进行实际操作,来验证操作是否可行,操作的结果是否满足设计的要求,如果不满足,就要报告错误,由开发者来改正错误。

  具体的操作例如:接一个电话,打一个电话,发送一条普通短信,接收一条普通短信,发送一条彩信,接收一条彩信,播放一首静态音乐文件(mp3),播放一段视频文件,照一张像片,录制一段录像,接收电子邮件,用浏览器上网浏览网页,设置一个闹钟,使用计算器,通过蓝牙接收数据,等等。

  2.2 交互测试

  所谓交互测试是指当手机不同的两个或者多个功能之间有交互的时候,对手机所应该处的状态或者行为进行测试,被测手机的状态或者行为应该与需求设计中的要求相一致。如果有错误,同样应该由开发人员来进行改正。

  具体的操作例如:打电话时接收短信息,看短信内容时候进来一个电话,听音乐时候浏览新短信,听音乐时候进来一个电话,上网浏览时进来一个电话,接电话时候闹钟报警,等等。

  2.3 临界测试

  所谓的临界测试是指当手机的某些可用资源达到或者超过理论允许的极大值时,在手机上继续进行某种操作时候的测试。此时手机的行为应该是友好的,可被使用者接收的,应该与需求分析的要求相符合。

  具体的操作例如:内存满时候拨打电话,内存满时候启动浏览器,内存满时候启动音乐播放器,数据库满时候拨打电话,数据库满时候启动浏览器,数据库满时候启动音乐播放器, 地址本满时候继续添加记录,短信收件箱满时候继续收新短信,等等。

  2.4 压力测试

  压力测试一般是指在比较短的一段时间内,被测手机执行比较多的任务或者操作,来检测被测手机承受压力的能力。具体的操作例如:在短时间内发送大量的短信,同时并接收大量的短信,发送和接收的数量都在50 条以上。短信的群发(包括超长短信),查看接收和发送的成功率,接通一个电话并且保持很长一段时间(大于10 个小时),等等。

  ......

本文转载自51Testing软件测试网,查看全文:http://www.51testing.com/html/42/n-230742.html

posted @ 2011-02-28 15:26 51testing 阅读(192) | 评论 (0) | 编辑 收藏
 
如何提高软件测试效率?

  先说如何衡量软件测试人员的效率,我还是倾向于用测试数据说话,虽然我上一次写过一篇关于软件测试人员考核的文章(如何有效的对软件测试人员进行业绩考核?),我提倡全部用数据说话,被N多网友批判,甚至卖烧烤的鱼也觉得我的考核办法太数据化了。即便如此,我还是坚持认为对于软件测试人员的效率还是用数据说话,当然也有其他的主观指标。

  衡量一个测试人员的效率一般从如下几个方面:

  第一,编写文档的速度,主要用在测试前期准备中,编写测试计划或者测试用例的速度。这个只能用页数/小时衡量了。

  第二,执行用例的速度*用例执行准确率。在测试执行期间,效率体现在执行速度上,但是还要考虑一个用例执行准确率,有的公司有这项指标,就是在执行过的用例中有一个抽查,看认真执行的准确率。

  第三,平均每天提交bug的数量和质量,这个指标应该是加权的,譬如(A级bug权值*数量+B级bug权值*数量+……)/总天数。

  第四,被测软件的总体质量,这个意思很清楚,如果测试时间很短,但是软件发布之后客户反馈一堆bug,也不能说测试效率高。所以,软件发布之后的质量也是一个考评因素。

  第五,bug发现的周期,如果测试前期发现bug很少,而大批量的bug留到项目后期才发现,说明前期的效率是有问题的。

  那么如何提升测试效率呢?我按照个人的实践给出一些建议:

  第一,最重要的是测试计划中任务要细化,并且每一项子任务都要有check。一个不具备执行性的计划往往是项目delay的最大原因。

  第二,合理配置测试资源。在什么阶段作什么最好,哪些事情提到前面作比较好,哪些事情放到后面比较好,某某任务的前置任务是什么,都要搞清楚。规划好的计划,不至于出现任务A等任务B的窝工现象。

  第三,合理使用工具。注意我说的不是自动化测试工具,而是在测试过程中合理使用可以提高效率的小工具,当然在回归测试中可以使用自动化测试工具。总之,我们的原则是机器自己能做的就让机器代劳。

  第四,引入自动构建,即自动编译。个人使用心得,很不错,节省不少时间。

  第五,找一款比较好的bug管理工具以及用例管理工具,古人说,公欲善其事,必先利其器,就是这个道理。

  第六,提高送测质量,以免bug推来推去,非常影响效率。

  其他就不再赘述,希望对大家有点帮助。

版权声明:本文出自godn_1981的51Testing软件测试博客:http://www.51testing.com/?1592

原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。

本文转载自51Testing软件测试网,查看更多:http://www.51testing.com/html/news.html

posted @ 2011-02-22 11:31 51testing 阅读(241) | 评论 (0) | 编辑 收藏
 
明星软件测试工程师的10种特质

  现在,越来越多的IT企业重视软件测试,从软件创业公司到投机性投资公司、制药巨头和媒体巨头,它们都越来越多地注重软件的质量问题。代码质量不仅成为了一个必需品,更成为了一个竞争优势。因为众多公司围绕软件而竞争,检测软件的人——软件测试工程师正显得越发重要。但是,你该如何发现那种百里挑一的软件测试员呢?在本文中,我们简明扼要地列出了明星软件测试工程师的10种特质。

  1. 热爱搞破坏

  发现缺陷是测试过程中的主要目的之一,因此,测试人员对被测产品要有破坏精神,有能力打破一些东西并且感觉不错。由于测试的工作是要发现缺陷,测试人员必须对发现

  别人工作中的缺陷感到满意。很难想象,缺乏破坏精神的测试人员能够有效地发现软件产品中的缺陷,从而达到尽量多地发现缺陷这样的目标。在静态测试过程中(例如:评审),无论是系统的需求规格说明还是设计规格说明,测试人员都应该以破坏的态度去对它们进行分析和评估;在动态测试过程中,也同样需要搞破坏精神,这样才能更有效地发现缺陷。

  2. 完成事情

  有很多测试人员只谈论软件而不一步一步执行(只说不做型)。而伟大软件测试工程师会真正去执行,这也是他们最为重要的品质之一。优秀软件测试工程师应当会问:解决手头问题的最简单方法是什么?

  3. 善于表达

  能够表达导致问题的事件发生次序和系统配置。这包括能够清楚地编写过程和结果文档,以及能够与开发人员、其他测试人员和管理层进行口头沟通。

  4. 脸皮要厚

  能够提出批评和接受批评(例如,能够向开发人员解释缺陷,以便让缺陷最终能被修正)。

  5. 抗压力强

  能够承受无休止的压力(测试工作位于开发过程的后半段,将处在一种充满压力环境中)。

  6. 善用网络

  网上有很多共享资源和别人的智慧结晶,说善用网络会让你升级更快。

  7. 专注可用性

  有些时候,一些软件工程师过于投入,反而忘记所编写的程序/软件,是供他人使用,不是做给自己看的“艺术品”。所以,在软件测试过程中,一直要把这些“艺术品”挑剔出来,把“用户”放在心中。无论用户是企业还是个人,无论是为消费型的软件公司还是投资银行,需要关注的都是可用性。用户如何和系统交互?系统是否提供一种简单、直接和平稳的操作体验?有种说法,因为测试工程师是技术人员,他/她和“用户如何与系统交互”没有关联,这种说法严重错误。优秀测试工程师努力工作是为了什么?不正是让系统简单并易于使用。

  8. 足够的耐心

  耐心-能够根据需要反复执行测试,直到问题被解决,然后再反复执行,以验证问题已被修正并且不再出现。

  9. 能用任何语言编程

  优秀的软件测试工程师应该有自己一门特别钟爱的编程语言,但从不会执迷于当中。如今已有很多优秀的编程语言,也就是说,如果你只会使用其中一门语言,说明你缺乏多样性。

  10. 知晓基本的计算机科学知识

  最后,但肯定不是优秀测试工程师最不重要的特质就是:扎实的基础。优秀的测试工程师或许并没有计算机科学的学位,但他/她必须知道基础——数据库和算法。如果不知道SQLServer、Oracle,你如何去检测一款大型的软件?

本文转载自51Testing软件测试网,查看更多:http://www.51testing.com/html/news.html

posted @ 2011-02-17 10:52 51testing 阅读(176) | 评论 (0) | 编辑 收藏
 
《51测试天地》第二十期电子杂志下载

  2010是十一五规划收官之年,回首过去5年,国家实现宏观经济平稳运行、产业结构优化升级、资源利用效率显著提高......而软件测试在国内发展却相对滞后,2005年劳动部才正式将计算机软件产品检验(即软件测试工程师)列为第四批新职业,不过,经过几年的成长,软件测试已然成长为一匹实力惊人的“黑马”,开创着属于它的辉煌。

  2011年是国家实施十二五规划的第一年,是开创新局面的一年;对于软件测试来说同样也是开创新局面、迎接挑战的一年。

  感谢所有参与投稿的朋友,也热切期望更多的软件测试领域的朋友们前来投稿,与《51测试天地》共同搭建这个学习交流的平台,帮助自己、同行及中国软件测试领域更快、更好的发展!

  “一元复始山河美,万象更新锦绣春”,在这新的一年里,我们将展开新的篇章,新的篇章里注定有苦涩、有艰辛,但这些困扰注定是我们前进的动力!有你们的大力支持,我们定会勇往直前,创造一个华丽的篇章,与你我共享!在此,《51测试天地》向所有支持关心我们的广大测试朋友致以衷心的感谢和最诚挚的祝福。

  51Testing软件测试网第二十期《51测试天地》电子杂志已经发布,赶快来下载吧!

  下载地址:http://www.51testing.com/html/02/n-227802.html

  查看更多软件测试内容:http://www.51testing.com/html/index.html

posted @ 2011-02-12 10:41 51testing 阅读(145) | 评论 (0) | 编辑 收藏
 
软件测试专家于涌谈行业前景与测试人员成长

  软件测试,真火还是假火?

  近日有媒体报道“软件测试行业人才需求缺口20万”,在如今 “就业难”的大环境下,尤其是在经济危机席卷全球,大批企业裁员降薪的情况下,软件测试行业是否真的逆势而上,有如此巨大的人才需求呢?

  于涌认为国内软件测试行业的对人才的需求的确很大。他举例“也曾有媒体报道过,国内开发人员与测试人员的比例是8∶1,而国际公认的行业标准实际上是1∶1,这一点上国内测试行业与国外的差距比较大。实际上,为了保证软件质量,从项目开始测试人员就要介入,要了解客户需求,参与项目评审,把握测试要点。如果测试人员数量少,软件质量是得不到保证的。因此测试行业的确需要大量人才,尤其是性能测试,自动化测试和有丰富测试经验的人才更加稀缺。”

  言谈间于涌对国内软件测试行业的发展充满信心,但在求职者中间也流传着这样一种说法,软件测试之所以火,是因为这个行业起点低,进入容易,工作压力小,对于这种观点,于涌表示,“现在的确存在这样一个误区,认为什么也不会也可以做测试。其实不是这样,测试包含很多知识,比如懂得用例的规则,边界值,因果关系图等等。要是不懂就很难发现问题,只能停留在表面,发现简单的功能错误。”

  于涌补充道:“现在国内的软件测试行业仍处于发展阶段,但是,从长远发展角度来看,测试还是需要高端人才。据我了解,有些学校已经开设了软件测试专业,比如北方交大。随着测试行业将越来越规范,未来需要的也将是一支专业的队伍,没有良好测试技能的人将被淘汰。”

  另外,在实际工作中也存在这样一种现象:有不少测试人员感到测试团队在整个项目团队中不受重视,常常感觉比开发人员低一头,针对这种现象,于涌道出了个中原因,“一是开发人员使软件从无到有,有很大的成就感。二是管理上的问题,目前测试行业处于发展阶段,高端人才的确较少,不能有效定位到深层次的问题。三是高层更看重研发、销售,而不重视测试。”

  对于如何改善这一现状,于涌老师同样给出三点建议:一是测试人员自身要提高综合能力,多积累经验,定位深层次的问题;二是要取得高层领导的支持;三是要用事实说话,严把产品质量关。关于开发团队和测试团队之间的关系,于涌老师做了一个十分生动的比喻,“开发团队和测试团队就像软件的父母一样,都希望孩子优秀,他们的目标其实是一致的。所以并不存在谁比谁低一头的问题,更不存在根本矛盾。”

  ......

本文转载自51Testing软件测试网,查看全文:http://www.51testing.com/html/06/n-228706.html

posted @ 2011-01-30 11:54 51testing 阅读(179) | 评论 (0) | 编辑 收藏
 
【专题】软件测试框架学习与实践

  在软件测试领域,我们经常会听到测试框架。什么是软件测试框架?在软件测试中它起到怎样的作用?要认识测试框架,首先要对所谓框架有概念。框架(Framework)是整个或部分系统的可重用设计,表现为一组抽象构件及构件实例间交互的方法;另一种定义认为,框架是可被应用开发者定制的应用骨架。前者是从应用方面、而后者是从目的方面给出的定义。测试框架也是如此,测试框架出现的最终目的是花少量的资源来完成尽可能多的测试任务,所以测试框架的建立以及框架的重用性方面是最值得测试人员深入探究的地方。Java测试框架、.Net测试框架、自动化测试框架、单元测试框架、集成测试框架,你是不是已经被这些名称弄晕了?如何实现测试框架用于特殊场合?本专题将就以上问题对测试框架进行全面详解,从测试框架入门和类别,到常用框架应用和自己动手实现框架。

  什么是测试框架:

  测试框架是一组自动化测试的规范、测试脚本的基础代码,以及测试思想、惯例的集合。可用于减少冗余代码、提高代码生产率、提高代码重用性和可维护性。 测试框架的好处在于:提高开发速度,提升测试代码的执行效率;提高软件代码质量,同时引入重构概念,让代码更干净和富有弹性;提升系统的可信赖度,作为回归测试的一种实现方法支持修复后“再测试”,确保代码的正确性。常用的测试框架分类包括自动化测试框架和单元测试框架。根据所用开发平台不同,也可使用不同的测试框架展开测试。

本文转载自51Testing软件测试网,查看专题:http://www.51testing.com/zhuanti/testFramework/testFramework.htm

posted @ 2011-01-26 11:26 51testing 阅读(169) | 评论 (0) | 编辑 收藏
 
软件测试的核心价值是什么?

  既然是“核心价值”,就应该能用一句话说清楚。关于软件测试的核心价值是什么,各种观点争论了很久,似乎很难得出一个明确的结论。这里有个很重要的原因,就是我们都深陷在软件测试工作的细节里面,没办法看清自己的位置和价值。不识庐山真面目,只缘身在此山中。

  要想搞清楚这个问题,我们必须走出围城来进行分析,如果把软件测试看成一种服务,那么从客户的视角来评判,最合适不过了。下面讲一件真实的事情。

  有一次我回家跟老友一起吃饭,聊起最近的工作。老友的单位是一家大企业,几个月前委托一家软件开发公司,开发了一套很大的企业管理软件。现在软件已经开发完成,进入了验收阶段。现在问题来了,负责验收软件的是信管部,部门老大非常担心软件的质量,希望能在验收签字前,把软件的严重质量问题都找出来,可是又不知道该从哪下手,如果能有一个权威的软件评测机构,对软件进行专业的测试,就最好了。

  “你们淘宝的软件测试,应该做的很专业吧,能不能帮我们来测试一下这个软件?你们接这种业务么?”老友提出这个问题。

  虽然淘宝测试现在还没有这种外接服务,不过这是一个难得的,饶有趣味的话题。

  “那你想要我们来测试哪些东西呢?哪些地方最担心?”

  “主要是性能吧,如果全公司人一起来用,不知道会不会出问题。还有就是数据的安全方面,公司的重要数据一定要绝对安全,不能被挖走。”

  “那软件的功能呢,功能需不需要我们来测一下?”

  “功能就不用了,我让我们部门的人来点点就行了。”

  听到这话我有点觉得不爽,不过想想倒也没必要跟老友去争辩这个问题,其实这确实是很多人对软件测试的看法。后来这个话题被岔开,没有继续谈下去了。

  所以下面的谈话并没有真实发生,是我用推理的方式,把讨论继续了下去,非常有趣。

  “功能测试并不是随便点点这么简单,淘宝的测试非常专业的,因为我们…”

  大家注意,精彩的地方到了,当我说出一个原因,并且能让老友信服,那就说明,这就是软件测试的核心价值了。

  “…我们的工程师对需求理解得很透彻,对业务很精通。”

  “我们部门的人对需求也很清楚的,因为他们就是最终的用户。”在平时的项目里我们也发现,无论需求分析做得多细致,软件交付以后,用户总能提出很多问题和改进意见,这是正常的,大可不必因此责怪测试工程师,因为没有人比用户更了解需求。最重要的是,不要让用户发现既严重又初级的Bug。

  “…我们编写的测试用例、文档非常专业非常完整,能够保证测试的质量。”

  “很好啊,你们很专业,不过这是你们内部的工作方式,我不是很关注的。”这里并不是否定测试文档的作用,只不过测试文档是测试团队的过程产物,无法直接给用户带来价值。

  “…我们对软件的架构设计非常了解,可以提前发现软件设计中的重要缺陷,避免返工。”

  “嗯,这个非常好,不过现在他们已经开发完了,要是在他们编码之前,请你们来对设计方案把把关,就好了。”用户非常希望能控制软件开发的全过程,而软件设计是最重要的里程碑,设计是否合格,直接影响后面的工作。

  ......

本文转载自51Testing软件测试网,查看全文:http://www.51testing.com/html/94/n-227694.html

posted @ 2011-01-21 12:00 51testing 阅读(161) | 评论 (0) | 编辑 收藏
 
软件测试的误区

  随着软件测试对提高软件质量重要性的不断提高,软件测试也不断受到重视。但是,国内软件测试过程的不规范,重视开发和轻视测试的现象依旧存在。因此,对于软件测试的重要性、测试方法和测试过程等方面都存在很多不恰当的认识,这将会进一步的影响软件测试活动的开展,并且阻碍软件测试质量的提高。下面简单列举了几种有代表性的对软件测试的认识误区,并作了相应的分析和解释。

  误区1:软件开发完成后才进行测试

  在传统的瀑布模型中,软件项目主要有一下几个阶段组成:用户需求、需求分析、概要设计、详细设计、编码和实现、测试以及运行维护。由于软件测试仅处于运行维护阶段之前,是软件产品交付用户使用之前保证软件质量的重要手段。因此人们一般认为,软件测试只是软件编码后的一个阶段。

  但随着软件测试业的发展,人们越来越认识到:软件测试不应只是软件项目的收尾工作,而应该在软件生命周期的每一阶段中都包含测试。软件测试是贯穿于整个软件开发生命周期的过程活动,包括软件测试计划、软件测试需求分析、软件测试用例设计、软件测试执行、软件缺陷管理、软件测试风险管理以及其他的一些软件测试相关的活动等等组成。在软件项目的每个阶段,都需要进行不同目的和不同内容的测试活动,以保证各个阶段工作产品输出的正确性。软件测试的对象也不仅仅是软件代码,还包括软件需求文档和设计文档等其他所有的软件工作产品。软件开发与软件测试之间应该是交互进行的,比如单元编码之后需要进行单元测试,模块组合之后进行集成测试。

  如果等到软件编码结束之后才进行测试,测试的时间很有限,很难达到测试的覆盖率要求和测试的质量要求。同时,假如在项目开发的后期,发现一些软件需求阶段和概要设计阶段的错误和问题,修改这些缺陷导致的成本将是非常高的。有资料表明:平均而言,如果在需求阶段修正一个错误的代价是1,那么,在设计阶段就是它的3-6倍,在编程阶段是它的10倍,在内部测试阶段是它的20-40倍,在外部测试阶段是它的30-70倍,而到了产品发布出去,这个数字就是40-1000倍。修正错误的代价不是随着时间线性增长的,而几乎是呈指数增长的。因此,应尽早地不断地进行软件测试,发现错误并加以修正,而非软件开发结束后才进行测试。

  误区2:软件发布后发现软件问题,那是测试人员的责任

  许多人认为测试人员需要对发布的软件质量负责,假如软件到用户后,发现很多的问题,那是测试人员的错和责任。这种认识误区非常打击测试人员的积极性。软件中的缺陷可能来自软件开发过程中的任何一个过程,而对于软件测试而言,只能证明软件存在缺陷,而不能保证软件没有错误。通过软件测试,无法发现软件中的所有错误和缺陷。从软件开发的角度看,软件的高质量不是软件测试人员测出来的,而是需要软件生命周期的各个过程共同来保证的。出现软件错误,不能简单地归结为某一个人或某个团队的责任。比如有些错误的产生可能不是技术原因,可能来自于混乱的项目管理;或者客户发现软件某些功能并没有按照原有需求来实现,换言之,软件没有完成客户想做的操作,诸如此类问题很可能是软件设计人员理解需求错误致使设计不当所引起的。

  软件的质量,不仅仅只是测试人员的事情,软件项目参与的所有人员都应该关注软件的质量。软件质量的提高,需要每个项目人员的努力。测试只是提高软件质量的一个重要环节,质量保证应该贯穿于整个软件开发生命周期的所有的开发活动、测试活动、项目管理活动等。同时,采用合适的开发和测试过程,对改进软件质量也能起到重要的作用。除了测试活动外,同时应该分析软件项目的各个过程,从过程改进方面寻找产生错误的原因和改进的措施。

  误区3:测试人员不需要具备很高的技能

  不少软件业人士认为软件测试行业对软件测试人员的技能要求不高。认为测试只是对照产品规格书操作软件,发现软件与规格说明不一致的地方,是没有技术含量的工作。

  这种观点是错误的,或者至少是步恰当的。随着软件测试行业的发展,测试不仅仅是运行软件发现缺陷的一个过程,而是从项目早期,测试人员就开始介入,进行测试需求分析、计划测试等。这要求测试人员有很好的沟通能力、理解能力、分析问题能力,同时还必须对产品开发技术有一定的了解。

  随着软件工程学的发展和软件项目管理经验的提高,软件测试已经形成了一个独立的技术学科,演变成一个具有巨大市场需求的行业。软件测试技术不断更新和完善,新工具、新流程、新测试设计方法都在不断更新,需要掌握和学习很多测试知识。所以,具有编程经验的程序员不一定是一名优秀的测试人员。软件测试包括测试技术和管理两个方面,完全掌握这两个方面的内容,需要很多测试实践经验和测试理论知识,需要我们不断的学习。

  ......

本文转载自51Testing软件测试网,查看全文:http://www.51testing.com/html/20/n-221520.html

posted @ 2011-01-18 11:46 51testing 阅读(180) | 评论 (0) | 编辑 收藏
 
仅列出标题
共55页: First 41 42 43 44 45 46 47 48 49 Last