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博客 | 首页 | 发新随笔 | 发新文章 | 联系 | 聚合 | 管理

嵌入式软件测试技巧

嵌入式软件开发过程中,一般来说,花在软件测试和花在代码编码的时间比为3:1(实际上可能更多)。这个比例随着你的编程和软件测试技术水平的提高而不断下降,但不论怎样,软件测试对一般人来讲很重要。很多年前,一位开发人员为了在对嵌入式有更深层次的理解,向Oracle询问了这样的一个问题:我怎么才能知道并懂得我的系统到底在干些什么呢? Oracle面对这个问题有些吃惊,因为在当时没有人这么问过,而同时代的嵌入式开发人员问的最多的大都围绕“我怎么才能使程序跑的更快”、“什么编译器最好”等肤浅的问题。所以,面对这个不同寻常却异乎成熟的问题,Oracle感到欣喜并认真回复了他:你的问题很有深度很成熟,因为只有不断地去深入理解才有可能不断地提高水平。并且Oracle为了鼓励这位执着的程序员,把10条关于嵌入式软件开发测试的秘诀告诉了他:

1.懂得使用工具

2.尽早发现内存问题

3.深入理解代码优化

4.不要让自己大海捞针

5.重现并隔离问题

6.以退为进

7.确定测试的完整性

8.提高代码质量意味着节省时间

9.发现它,分析它,解决它

10.利用初学者的思维

这十条秘诀在业界广为流传,使很多人受益。本文围绕这十条秘诀展开论述。

1.懂得使用工具

通常嵌入式系统对可靠性的要求比较高。嵌入式系统安全性的失效可能会导致灾难性的后果,即使是非安全性系统,由于大批量生产也会导致严重的经济损失。这就要求对嵌入式系统,包括嵌入式软件进行严格的测试、确认和验证。随着越来越多的领域使用软件和微处理器控制各种嵌入式设备,对门益复杂的嵌入式软件进行快速有效的测试愈加显得重要。

就象修车需要工具一样,好的程序员应该能够熟练运用各种软件工具。不同的工具,有不同的使用范围,有不同的功能。使用这些工具,你可以看到你的系统在干些什么,它又占用什么资源,它到底和哪些外界的东西打交道。让你郁闷好几天的问题可能通过某个工具就能轻松搞定,可惜你就是不知道。那么为什么那么多的人总是在折腾个半死之后才想到要用测试工具呢?原因很多,主要有两个。一个是害怕,另一个是惰性。害怕是因为加入测试工具或测试模块到代码需要技巧同时有可能引入新的错误,所以他们总喜欢寄希望于通过不断地修改重编译代码来消除bug,结果却无济于事。懒惰是因为他们习惯了使用printf之类的简单测试手段。下面来介绍一些嵌入式常用的测试工具。

源码级调试器[Source-level Debugger]

这种调试器一般提供单步或多步调试、断点设置、内存检测、变量查看等功能,是嵌入式调试最根本有效的调试方法。比如VxWorks TornadoII提供的gdb就属于这一种。

简单实用的打印显示工具[printf]

printf或其它类似的打印显示工具估计是最灵活最简单的调试工具。打印代码执行过程中的各种变量可以让你知道代码执行的情况。但是,printf对正常的代码执行干扰比较大(一般printf占用CPU比较长的时间),需要慎重使用,最好设置打印开关来控制打印。

本文转载自51Testing软件测试网(查看全文):http://www.51testing.com/html/33/n-78033.html

posted @ 2009-08-11 10:46 51testing 阅读(464) | 评论 (2) | 编辑 收藏
 
软件测试技术常见的十一种问题

一、软件测试技术常见问题

1、 单元测试主要内容是什么?单元测试大多数由开发人员来完成,软件测试人员技术背景较好或者开发系统软件时可能会安排测试人员进行单元测试,大多数进行的单元测试都是开发人员调试程序或者开发组系统联合调试的过程。讨论这个问题主要是扩充一下读者的视野。

单元测试一般包括五个方面的测试:

(1)模块接口测试:模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下,其他测试才有意义。模块接口测试也是集成测试的重点,这里进行的测试主要是为后面打好基础。测试接口正确与否应该考虑下列因素:

输入的实际参数与形式参数的个数是否相同;

输入的实际参数与形式参数的属性是否匹配;

输入的实际参数与形式参数的量纲是否一致;

调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同;

调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配;

调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致;

调用预定义函数时所用参数的个数、属性和次序是否正确;

是否存在与当前入口点无关的参数引用;

是否修改了只读型参数;

对全程变量的定义各模块是否一致;

是否把某些约束作为参数传递。

如果模块功能包括外部输入输出,还应该考虑下列因素:

文件属性是否正确;

OPEN/CLOSE语句是否正确;

格式说明与输入输出语句是否匹配;

缓冲区大小与记录长度是否匹配;

文件使用前是否已经打开;

是否处理了文件尾;

是否处理了输入/输出错误;

输出信息中是否有文字性错误。

局部数据结构测试;

边界条件测试;

模块中所有独立执行通路测试;

(2)局部数据结构测试:检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确,局部功能是整个功能运行的基础。重点是一些函数是否正确执行,内部是否运行正确。局部数据结构往往是错误的根源,应仔细设计测试用例,力求发现下面几类错误:

不合适或不相容的类型说明;

变量无初值;

变量初始化或省缺值有错;

不正确的变量名(拼错或不正确地截断);

出现上溢、下溢和地址异常。

本文转载自51Testing软件测试网(查看全文):http://www.51testing.com/html/36/n-79736.html

posted @ 2009-07-21 11:02 51testing 阅读(193) | 评论 (0) | 编辑 收藏
 
软件测试配置管理

软件测试配置管理一般应用过程方法和系统方法来建立软件测试管理体系,也就是把软件测试管理作为一个系统,对组成这个系统的各个过程加以识别和管理,以实现设定的系统目标。同时要使这些过程协同作用、互相促进,从而使它们的总体作用大于各过程作用之和。软件测试配置管理的主要目标是在设定的条件限制下,尽可能发现和排除软件缺陷。测试配置管理是软件配置管理的子集,作用于测试的各个阶段。其管理对象包括软件测试计划、测试方案(用例)、测试版本、测试工具及环境、测试结果等。

目标

1、控制和审计测试活动的变更;

2、在测试项目的里程碑建立相应的基线;

3、纪录和跟踪测试活动变更请求;

4、相应的软件测试活动或产品(work products)被标识、控制、并是可用的

承诺执行

承诺1:每个测试项目的配制管理责任明确;

承诺2:配置管理贯穿项目的整个测试活动;

承诺3:配置管理应用于所有的测试配置项,包括支持工具;

承诺4:建立配置库和基线库(Baseline);

承诺5:定期评审基线库内容和测试配置项活动

需要纳入配置管理的项

项目测试过程中会产生许许多多的工作成果,例如测试计划文档、测试用例以及自动化测试执行脚本和测试缺陷数据等,他们都应当被保存起来,以便查阅和修改。这些纳入配置管理范畴的工作成果统称为配置项(Configuration Item,CI),每个配置项的主要属性有:名称、标识符、文件状态、版本、作者、日期等。

查看全文:http://www.51testing.com/html/83/n-73583.html

posted @ 2009-07-10 11:02 51testing 阅读(192) | 评论 (0) | 编辑 收藏
 
UI自动化测试与软件测试开发工程师所面临的挑战

对于任何一个需要开发有持久生命力软件的组织来说,软件测试至关重要,同时,自动化测试技术也显得必不可少。比如像Windows这样的产品,通常的生命周期可以长达10年以上。试想一下,没有软件测试的质量保证,没有自动化测试技术的话,任何一次的产品改动、升级、补丁、导致的成本有多大?

之所以说自动化测试是尖端技术,原因在于自动化测试的技术难度,特别是UI测试自动化。 跟软件产品一样,自动化测试程序也讲究性能、稳定性、可伸缩性等指标。测试程序除了要实现目标程序一样的功能才能够进行结果检验以外,测试程序还要实现额外的功能去观察目标程序的行为。比如要自动化测试 “dir C:\*.txt” 这个命令,测试程序除了要实现跟dir一样的文件读取,通配符展开的功能外,还需要读取dir命令的输出结果才能够进行结果的比对。同时也要支持跟dir命令一样的灵活性和扩展性。这使得自动化测试在实现起来有可能比其测试目标的实现更加困难。而对于UI产品的自动化,实现起来就牵涉到读取GUI的图像输出(比如检查是否正确弹出了MessageBox),模拟用户的鼠标键盘输入(比如模拟用户在保存文件的时候选择正确的保存路径),同步测试产品和用户的交流等等。这些技术门槛使得自动化测试成为一把双刃剑,成败不在于是不是去做它,而是有没有能力把它做好。接下来的介绍会让你对微软的UI测试自动化和软件测试开发工程师(Software Development Engineer in Test以下简称SDET)有更深入详细的了解。

举一个十分具体的UI自动化的例子:

1. 启动计算器程序(calc.exe)

2. 模拟用户进行菜单输入,从普通模式切换到科学模式

3. 模拟用户计算(4+6/2)的阶乘

4. 检查计算结果是否正确

要求:

1. 整个流程的执行在4秒以内完成

2. 能够适应于不同分辨率和语言 (不同语言的菜单项文字是不同的!)

3. 能够稳定执行,若非产品本身的确有bug,该序列不允许失败

4. 如果下一版本的calc.exe修改UI风格 (Win7中已经修改了),或者改为WPF实现,要求现有的测试代码仅做简单修改即可继续使用

对于刚入职的SDET来说,其实现难度已经足够大得让其宁愿去写一个calc.exe程序本身。无论是学校的教学还是课外的研究,针对UI自动化的资料几乎是零。上诉功能和需求,需要工程师结合已知的知识和技能,研究出解决问题的最佳办法。

UI自动化其实是一种进程与进程之间的通信。测试程序需要跟目标程序通过某种进程通信方式来获取目标程序的信息,包括UI元素的位置,显示的文字内容,然后再模拟用户的操作比如在特定位置点击鼠标。就进程之间通信方式来说,Windows平台上有很多选择,比如管道,TCPIP,Windows消息,共享文件,RPC等等。对于UI自动化,最容易想到的解决方案是Windows消息。通过Windows消息以及跟Windows相关的API可以获取计算器窗口,菜单和按钮位置。但真正开始用Windows消息来实现UI自动化测试的时候,就会发现Windows消息的一些不足,比如Windows消息无法用于WPF程序,无法获取Excel或者IE里面的UI子元素。

所以,除了Windows消息外,工程师还需要更深入地考虑其它技术。其间就需要研究微软内部的各种UI Test Framework,了解不同Framework的实现技术,优劣以及和测试目标的匹配程度。在进行不断的摸索,尝试,原代码分析后,工程师才会对微软平台各种技术有深入的了解,整个过程是把基础的理论知识转换为产品相关的生产力的过程。

UI自动化对于SDET来说有两层含义。其一,对该技术的熟悉程序决定测试工作的质量。另外,由于UI自动化涵盖的技术范围和深度,使得该技术是锻炼 SDET的一个很好的平台。微软对工程师的技术技能要求不是限制在某一固定领域的,而是要求工程师锻炼能够通用的核心竞争力。比如,作为SDET,通过2 年的努力,在Visual Studio的界面测试上取得了90分的成功,那么,如果该工程师愿意换一个项目做SDE(Software Development Engineer,即软件开发工程师)的话,比如到SQL Server开发存储过程的图形化设计,他在前两年所积累的技术技能,要能够确保他在新的项目和职位上,取得同级别的90分。而UI自动化,对于锻炼这样的核心竞争力是一个非常好的平台,因为它至少包括了:

1. 精通微软通用的开发工具和技术,比如C#,NET Framework,多线程。把开发技巧运用到实际的项目中。

2. 熟悉Windows平台的系统知识,比如进程间通信,Win32消息机制。站在微软工程师的角度,通过具体的项目和代码充分了解Windows平台。

3. 锻炼在压力环境下解决实际问题的能力,比如深入分析COM/DCOM,研究UI Automation Framework的底层实现来解决技术上的细节问题。

4. 熟练掌握调试技巧。UI自动化的开发过程牵涉到测试程序和目标程序,在调试的时候需要处理两者的同步问题。同时,UI自动化的稳定性是比较难解决的问题。调试一个偶尔发生的错误是一个非常有挑战性的任务。

5. 在自动化测试的开发过程中熟悉微软的项目流程,最后,给SDET带来的不仅仅是测试技能的飞跃,同时也让工程师更加熟悉所测试的产品,更好地保证产品质量。

当一个SDET经历了UI自动化测试,武装上了上述技能,就意味着他熟知微软平台的开发技巧,体验过程序开发过程中通常是如何犯错,如何调试,工程师在怎样的情况下容易做出错误的判断和假设,那么,他就能够很轻松地破坏别人的程序,找出漏洞。这不仅仅对测试工作来说是一个很好的起点,这样的坚实技术背景还能够让工程师学习和发展其它技能的时候事半功倍。换言之,自动化测试对微软的产品来说,是保证其可以持续成功的重要技术;对于优秀的SDET来说,是一项必不可少的重要的技能;对于刚入职的工程师来说,亲身体验和研究自动化测试,特别是UI自动化,能够让你实现学生生涯到职业生涯的转变。

在后续的文章中,我打算介绍自动化测试和手动测试的比较,看看自动化测试所达到的效果是否等同于手动测试的录制和重复。同时,也会具体介绍UI自动化测试开发的有趣细节。

本文转载自51Testing软件测试网:

http://www.51testing.com/html/07/n-130907.html

posted @ 2009-07-01 11:13 51testing 阅读(163) | 评论 (0) | 编辑 收藏
 
软件测试工具与自动化测试技术

   软件测试是程序的一种执行过程,目的是尽可能发现并改正被测试软件中的错误,提高软件的可靠性,它是软件生命周期中一项非常重要非常复杂的工作。在目前的情况下对软件可靠性保证具有极其重要意义的,仍然是软件测试。但如何进行测试,如何提高软件测试的质量和效率,从而确保软件产品的质量和可靠性,仍是令人深感困惑的问题。本文根据笔者的一些粗浅的体会,简要介绍软件测试的基本过程,以及一些常用的技术手段、测试策略和准则,并介绍一个在工作中用到的Rational(现已被IBM收购)自动化软件测试工具Visual Test。运用这种自动化软件测试工具可以省去很多手工运行的麻烦,而且准确获得测试数据和结果。通过本文介绍,以期使愈来愈多的人在认识到软件测试重要性的同时,能够更进一步了解应如何正确地选择和有效地运用各种各样的测试方法、技术以及自动化软件测试工具提高软件的质量和可靠性。

  软件测试的基本过程

  软件测试是一个极为复杂的过程。一个规范化的软件测试过程通常须包括以下基本的测试活动 :①拟定软件测试计划 ;②编制软件测试大纲 ;③设计和生成测试用例 ;④实施测试 ;⑤生成软件问题报告。

  实际上,软件测试过程与整个软件开发过程基本上是平行进行的。测试计划早在需求分析阶段即应开始制定,其他相关工作,包括测试大纲的制定、测试数据的生成、测试工具的选择和开发等也应在测试阶段之前进行。充分的准备工作可以有效地克服测试的盲目性,缩短测试周期,提高测试效率,并且起到测试文档与开发文档互查的作用。

  此外,软件测试在每个测试周期中,测试工程师将依据预先编制好的测试大纲和准备好的测试用例,对被测软件进行完整的测试。测试与纠错通常是反复交替进行的。

  软件测试工具

  软件测试的目的是用尽可能少的时间和人力发现并改正软件中潜在的各种故障及缺陷,并能以更快的速度和更低的成本开发出高质量的应用程序,这就使测试人员的工作比以往任何时候都更加困难。在很多项目中,测试人员的所有任务大多是由手动处理的,而实际上有很大一部分重复性强的测试工作是可以独立开来,自动实现的。在大型项目中测试团队和其他团队之间没有足够的合作,无法促进彼此的交流。实施测试自动化可以提高测试工作效率,使用工具的目的只是为了减少部分手工测试,将更多人力资源投入到更有价值的工作中。

一些受软件开发人员欢迎的软件测试工具为软件测试提供了强有力的支持。本文将介绍美国 Rational 公司(现已被IBM收购)的著名套装软件Rational Visual Test。它的一个重要特点是可以自动驱动被测程序的运行。并且可以自动记录和重放程序执行过程,从而实现了对测试进行“复查”的自动化。由于测试是一个需要反复进行的过程,常常要数十次甚至数百次地重复。因此,这一特性大大地提高了软件“再测试”(Re-Test)和“回归测试 ”(Regression)的自动化程度,把测试人员从繁杂的、重复性的手工测试中解脱出来,从而显著地提高软件测试效率。除了这个最基本的自动录放功能外,它还提供了一系列的辅助支持功能,比如被录制的程序执行过程可以被自动转换成具有良好可读性的高级语言程序,从而使这个测试驱动程序可以由测试人员根据测试需要进行必要的修改,甚至完全用手工方式编制。自动记录和分析比较测试的执行结果。

本文转载自51Testing软件测试网(查看全文):http://www.51testing.com/html/87/n-130887.html

posted @ 2009-06-11 11:33 51testing 阅读(681) | 评论 (0) | 编辑 收藏
 
常用软件测试工具的分析与比较

  软件测试是保证软件质量的重要手段,它在整个软件开发过程中占据了将近一半的时间和资源。在软件测试过程中合理的引入软件测试工具,能够加快测试进度,提高软件测试质量,实现更快、更好的开发软件产品的目标。本文对常用的软件测试工具进行了分析和比较,希望对大家有所帮助。

  工具名称:WinRunner

  来源:Mercury公司

  类型:功能性测试

  功能概要:Winrunner 最 主要的功能是自动重复执行某一固定的测试过程,它以脚本的形式记录下手工测试的一系列操作,在环境相同的情况下重放,检查其在相同的环境中有无异常的现象 或与实际结果不符的地方。可以减少由于人为因素造成结果错误,同时也可以节省测试人员大量测试时间和精力来做别的事情。功能模块主要包括:GUI map、检查点、TSL 脚本编程、批量测试、数据驱动等几部分。

  工具名称:LoadRunner

  来源:Mercury公司

  类型:性能与负载压力

  功能概要:LoadRunner是一种预测系统行为和性能的工业标准级负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题,LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ,企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。LoadRunner 是一种适用于各种体系架构的自动负载测试工具,它能预测系统行为并优化系统性能。LoadRunner 的测试对象是整个企业的系统,它通过模拟实际用户的操作行为和实行实时性能监测,来帮助您更快的查找和发现问题。此外,还能支持广范的协议和技术,为您的特殊环境提供特殊的解决方案。

  工具名称:QuickTest Pro

  来源:Mercury公司

  类型:功能测试和回归测试

  功能概要:QTP是一个B/S系统的自动化功能测试的利器,软件程序测试工具。Mercury的自动化功能测试软件QuickTest Professional ,可以覆盖绝大多数的软件开发技术,简单高效,并具备测试用例可重用的特点。Mercury QuickTest Pro 是一款先进的自动化测试解决方案,用于创建功能和回归测试。它自动捕获、验证和重放用户的交互行为。 Mercury QuickTest Pro为每一个重要软件应用和环境提供功能和回归测试自动化的行业最佳解决方案。

  工具名称:TestDirector

  来源:Mercury公司

  类型:测试管理

  功能概要:基于WEB的测试管理工具,他能够让你系统地控制整个测试过程,并创建整个测试工作流的框架和基础,使整个测试管理过程变得更为简单和有组织。他能够帮助你维护一个测试工程数据库,并且能够覆盖你的应用程序功能性的各个方面。T并且还为你提供了直观和有效的方式来计划和执行测试集、收集测试结果并分析数据。还专门提供了一个完善的缺陷跟踪系统。并可以同Mercury公司的测试工具、第三方或者自主开发的测试工具、需求和配置管理工具、建模工具的整合功能。你可以通过他进行需求定义、测试计划、测试执行和缺陷跟踪,即整个测试过程的各个阶段。

本文转载自51Testing软件测试网(查看全文):http://www.51testing.com/html/91/n-130091.html


posted @ 2009-05-26 11:43 51testing 阅读(618) | 评论 (1) | 编辑 收藏
 
软件测试工具与测试思想孰重孰轻

  本篇文章为黄昏自己写的,呵呵...

  软件测试工具近来在测试人员间刮起了一阵旋风,在我们群内也不可避免地掀起了一阵软件测试工具热。我不是支持无工具软件测试,因为这是一种愚蠢行为。但对当前出现的厚此薄彼思想,说说我对软件测试思想与软件测试工具的认知。在此诚邀各路英雄过来参与讨论与拍砖。最理想的目的是让我们对软件测试有一个不会偏离得太远的好的认知。

  有不少软件测试员目前把软件测试工具与软件测试思想的学习分为两个相反方向,重视工具的使用学习而忽略了测试思想的煅练。这不利于测试能力的提升和提高我们的测试技能,如仅仅是工具的使用,就好巧妇难为无米之炊,而这"米"指的正是软件测试思想。

  软件测试工具只是一个辅助工具,帮助我们进行一些手工测试不能完成的测试内容,但它不能替代软件测试思维。该测什么,要怎么测还是要以测试思想为基础,然后才是借用工具帮我们实现。就算我们精通Rational、Mercury等一系列的工具,如果心中没有测试用例,我们也不知对着一个需要测试的软件,要对它进行怎样的测试项,作为一个软件测试人员,我们不应当只是一个执行者,更应该是一个设计者,怎样设计一个合理有效的用例去完成对产品质量的控制,在这个基础上才是怎样去达到对这个产品质量的检验。而测试用例,是测试思想的集中体现。先煅练思想再在此基础上进行使用辅助工具的提升,我们的测试才能做得更好。这也不是说一定要有了测试思想再学习工具,因为思维与工具都是测试的技能点,最好是一并重视,把测试思维的学习与测试工具的学习调至一个方向。

  如果把测试比喻成树的话,那么测试基础是主干,工具是支干和叶子,支干和叶子的茂盛使树显得更强盛,但如果少了主干的支撑,支干也就无扬展的空间。

  后来想想,新接触软件测试的许多同行比较注重工具的学习,很多是由于现在招聘企业的对测试工具要求比对测试思维要求更多,对测试行业产生了误导。

  软件测试人员本身对测试基础与测试工具的偏重度问题,希望能分层次讨论测试所有知识与技术,此举是希望能给新接触这个行业并且不太了解这个行业的同行们一个循序渐进的讨论主题,利于测试发展。

  另外软件测试技能的煅练不仅仅是思维与工具,还包括行业知识,因为大多数测试员从事的都是针对某一行业的产品,对所属行业有了了解,我们的测试才更有针对性。

  下面是我当时的回复

  赞同黄昏的观点。

  从必要性上来看,如果有软件测试工具是不是所有的软件都能测试?反过来如果有软件测试思想是不是能进行所有软件测试?从覆盖率来看,相信有测试思想的测试范围要广些。

  举个例子,比如做手术,你会各种工具的使用,一定就知道什么时候该用哪种工具吗?呵呵,想来都是思想来指导我们行动的...

  本文转载自51Testing软件测试网(查看全文):http://www.51testing.com/html/61/n-19361.html

posted @ 2009-05-07 10:45 51testing 阅读(150) | 评论 (0) | 编辑 收藏
 
感悟软件测试

  曾经对软件测试很轻视,因为我那时很无知,只是一名普通的中国程序员,这也是那时绝大多数程序员的心态,那时中国程序员最讲究“编程才是硬道理”。如今却非常热爱软件测试,包括软件测试工具,方法,理论,技术。因为我在3年的软件测试工作中,深刻体会到软件测试的重要性和趣味性。此时,我已经跳出了“小程序员”的圈子,以软件系统工程的更大视角审视软件测试这项工作。

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

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

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

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

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

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

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

  软件测试是个可以很快入门的职业,门槛不高,但是,不要认为什么人都可以做好软件测试。因为会做和做好是两个概念。软件测试人员最好具有软件开发经验,理解软件工程的知识。这是提高软件测试能力的基础。对于刚刚毕业的学生,如果希望今后从事软件开发,那么,先从事一段时间的测试可能更有利于今后的编程。而对于具有多年编程经验的程序员,如果改行做测试,更容易提高技术。软件测试不是孤立的活动或过程,需要开发和市场人员的参与和交流,需要软件质量保证人员SQA的积极配合和沟通。

  软件测试的技术不断进步,与具体测试技术相比,掌握测试的核心思想比具体技术更重要!测试的最高境界在于运用最简单有效的测试技术,最大限度的发现软件缺陷!

  应当承认,目前国内的软件测试工程师的地位和待遇仍然很低,而且不少测试人员存在浮躁的心态(我甚至感到整个软件行业始终存在着浮躁的泡沫)。如何改变这种局面,这应该是个漫长的过程。当整个IT业真正以客户为上帝时,当软件质量成为决定企业生存和发展的决定因素时,当软件测试工程师的测试工作给软件企业带来更大的经济效益时,软件测试工程师才会得到应有的尊重!

  软件开发是一项复杂的、创造性的协作式游戏。作为游戏它自然存在着乐趣,所以程序员们才会乐此不疲,前仆后继。首先、这种快乐源于一种创造事物的快乐。其次、这种快乐来自于一种开发出对别人有用的东西时所带来的满足感。第三、快乐源自开发过程中,亲眼看到软件按自己预先设想的那种效果运行时所带来的迷人魅力。第四、快乐源自开发过程中持续学习的快乐。最后、快乐源自开发过程中,我们能象诗人一样,仅凭自己的想像,来建造自己的城堡时带来的快乐。编程的快乐在于它不仅满足了我们内心深处进行创建的渴望,而且还唤醒了每个人内心的情感。不幸的是,同样作为游戏它也有苦恼的一面:首先、苦恼来自追求完美主义。其次、苦恼来自总是由他人来设定目标、供给资源、提供信息。第三、苦恼来自于寻找琐碎的BUG却是一项枯燥的、重复性的活动。第四、人们通常希望在项目接近结束时,能收敛得快一些,然而,情况却是越接近完成,收敛得越慢。最后、苦恼来自当投入大量的辛苦劳动后,产品发布时却面临着陈旧过时的危险。作为软件开发者,我们别无选择,只有适应它们,就这样痛并快乐着地面对每一天。

  来自领导的信息只有25%被下级知道并正确理解,从下到上的反馈信息不超过10%,平等交流的信息则可达到90%以上。平等造就信任,信任增进交流。有效地进行适当的意见交流,对一个组织的气候和生产力会产生有益和积极的影响。使顾客满意并和他们面对面地交流,才是蠃得市场的关键。

  管理是一种控制性游戏,在游戏面前,你只有二种选择:或者,你确信自己能蠃,于是投入足够多的能量来蠃得一切;或者,你不进行这个游戏,放弃它。然而,作为软件项目管理者,你也应该知道,早投入、高风险才会有高回报。逃避风险是致命的,因为这也会让你得不到与风险同在的利益,久而久之,你就会面临着被市场淘汰的危险。风险是“遭受损失的可能性”,由条件、结果以及周围的环境构成。风险和问题的区别在于:风险是尚未发生的问题,而问题是业也成真的风险,昨天的风险可能会是今天的问题。风险管理主要包括下面几个方面(点击下文链接查看更多内容)。 

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

posted @ 2009-04-28 11:22 51testing 阅读(113) | 评论 (0) | 编辑 收藏
 
测试自动化及软件测试工具的比较

    1、软件测试自动化实现到何种程度为好

    (1)、软件测试自动化的程度再高都不可能取代手工测试,即软件测试工具不可能取代软件测试人员;

    (2)、一般来讲,测试自动化在整个软件测试过程中只能占到30%左右;

    (3)、实现、运用自动化的程度还取决于各方面的资源,特别是软件的行业规范性和软件开发的稳定性;

    (4)、对于部分白盒测试可以使用软件测试工具,如对代码性能分析等;

    2、如何实现软件测试自动化的计划

    (1)、首先将测试的基本管理形成自动化,如BUG管理等;

    (2)、然后利用软件测试自动化工具来实现一些手工无法进行的测试活动,如:压力,并发,强度测试等;

    (3)、接着利用测试自动化工具来完成回归测试中的缺陷跟踪测试;

    (4)、再往后就可以利用测试自动化工具来记录两个版本的异同,以找出缺陷;

    (5)、最后将整个回归测试都用自动化脚本保存,以完成每次的回归测试;

    (6)、而对于白盒测试则可以引入测试工具进行代码分析;

    3、对软件测试工具的使用现状及分析

    (1)、目前,软件测试方面的工具很多,主要有MercuryInteractive(MI)、Segue、Rational、 Compuware和Empirix等公司的产品,而MI公司的产品占了主流。以下就各种常用测试工具进行简要对比:

    主要厂商及其软件测试工具如下表:

    Mercury Interactive Winrunner、loadrunner、TestDirector、Astra QuickTest

    Rational Rational Purify (测试时用,检查运行时内存错误)

    Rational Quantify (性能检测工具,查出系统瓶颈以便改进运行速度)

    Rational TestManager (测试管理)

    Robot (软件测试用,通过Script自动模拟输入输出)

    LoadTest

    TestFactory (软件测试用)

    Compuware QACenter、Perfromance Edition、EcoScope、TrackRecord

    Segue SilkTest

    Empirix eTest Suite

    以下从常见软件测试工具功能、使用范围、目前市场情况、应用前景等方面做简要比较:

    工具名称 功能范围

    WinRunner-----功能:

    1.插入检查点;

    2.检验数据;

    3.增强测试;

    4.分析结果;

    5.维护测试;

    6.为无线应用作准备。

    范围:功能测试、生成测试用例、分析测试结果、维护测试用例、回归测试。

    LoadRunner-----功能:

    1.松创建虚拟用户;

    2.创建真实的负载;

    3.定位性能问题;

    4.分析结果以精确定位问题所在;

    5.重复测试保证系统发布的高性能;

    6.Enterprise Java Beans的测试;

    7.支持无线应用协议;

    8.支持Media Stream应用;

    9.完整的企业应用环境的支持。

    范围:性能测试、压力测试、模拟多用户、定位性能瓶颈。

本文转载自51Testing软件测试网—软件测试工具(查看全文):http://www.51testing.com/html/50/n-82550.html

posted @ 2009-04-21 11:23 51testing 阅读(857) | 评论 (1) | 编辑 收藏
 
软件测试工具培训的一些建议
      现在越来越多的公司都购买或开始使用自动化软件测试工具以期来提高软件测试工作的效率。然而尽管购买到了适合自己公司或产品的软件测试工具,却并没有收到预期的效果。这是为什么呢?着其中有很多的原因,本文主要针对在软件测试工具培训中出现的问题提出一些自己的建议,部分内容参考Jose Fajardo的《A Detailed Look at the Idiosyncrasies of Test Tool Training》。

        在购买软件测试工具,工具可用之后,可能由于软件测试人员对新工具或工具的替换,甚至对自动化测试的不了解,软件测试工具的升级,工具对公司产品需要大规模定制等原因,软件测试经理往往应该考虑如何通过培训可以让大家最快的熟悉并能掌握使用工具。

· 打消对软件测试工具不现实的期望

        首先测试经理们应该打消希望软件测试人员在短短2到3天时间里就能迅速掌握测试工具并能快速运用到实际项目中去的期望。一般来说,短期的培训特别是前期的培训只是教大家录制/回放脚本的基本操作,参与培训的人员无法马上就将工具熟练的运用到各种复杂的项目或产品中。针对这种情况建议测试经理为软件测试人员指定一个有经验的导师或软件测试工具专家以解决测试人员在实际使用测试工具时遇到的问题或不断灌输好的自动化测试方法。

        软件测试人员也应该打消在真正使用工具之前对自动化测试工具的一些不切实的的期望,如测试工具可以做替代所有的手工测试,自动化测试就是录制/回放等。这样在碰到问题时可以避免自己钻牛角尖,或对工具的失望。

·甄别软件测试培训师

        测试经理需要慎重的考虑培训师的选择。一些公司会联系外面的培训机构或卖工具给自己的公司。这时测试经理需要问询关于培训师的资历等相关背景资料,特别要注意培训师是否有实际使用工具的经历和时间。

        还有些公司会直接雇用培训师直至项目完成。这时更需要鉴别培训师的资格。

        另外有时在本公司内部可能已经有些测试工具专家,他们已经有了适合公司的培训资料和供应商的通用培训资料。

· 挑选需要参与培训的人员

        并不是所有的人都需要录制或自动化测试脚本,所以最好不要大锅饭似的展开培训。测试经理应该根据项目或人员的配备划分优先级别。需要实际参与或核心的自动化测试人员具有最高的优先级别,其他的测试人员可以参与概念级的工具培训或通过本公司的工具专家提供非正式的培训。

·培训“培训师”

        在外部的培训师离开之后,已经获得培训的人员可能需要对那些没有参与培训的人员提供培训,他们需要将自己获得的知识传递给别人。所以测试经理需要在培训之前就告知第一批参与培训的人员他们以后需要给其他人提供培训的要求,并且在培训之后列出一个计划。

        当然还需要给以后需要提供培训的人员以专业的培训技巧的指导。工具专家不一定就具备可以公开做培训的素质,有些人可能会面临培训时紧张,培训结构不合理,表达不清楚等问题。这些都会阻碍他人接受到正确的信息。

·审核培训资料

        软件测试工具培训资料对于培训来说是非常重要的。培训师通过它来组织自己的培训进程,参与培训的人员通过它来了解培训的内容及以后的回忆。所以培训资料必须能全面的但又简要的反映培训的条目。测试经理最好能亲自或指派其他的人审核培训资料。

·反馈机制

        在培训之后,需要及时收集参与培训人员对培训的意见,并及时改正或改进。还可以通过培训后的小考试来加强培训的效果。

·记录下未解决的问题

        在培训过程中,参与软件测试工具培训的人员可以提出自己的问题,那么培训师就有可能对有些问题暂时无法回答的时候。所有培训师要记录下此类问题并及时给予回复。

        在实际使用软件测试工具时,也会碰到一些工具无法支持或工具的bug等问题。软件测试经理也应该指派专人负责收集此类问题,并从工具商或公司内部征集解决放方案或暂时的权宜方法。它们也是知识库(Knowledge base)的一部分。

本文转载自51Testing软件测试—软件测试工具:http://www.51testing.com/html/82/n-80282.html

posted @ 2009-04-16 11:22 51testing 阅读(285) | 评论 (0) | 编辑 收藏
 
仅列出标题
共55页: First 47 48 49 50 51 52 53 54 55