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. 结构化的

  3. 共享的

  4. 数据驱动的

  5. 关键字驱动的

  线性脚本的编写方法是使用简单的录制回放的方法,测试工程师使用这种方法来自动化测试系统的流程或某些系统测试用例。它可能包含某些多余的、有时候并不需要的函数脚本。

  结构化脚本编写方法在脚本中使用结构控制。结构控制让测试人员可以控制测试脚本,或测试用例的流程。在脚本中,典型的结构控制是使用“if-else”,“switch”,“for”,“while”等条件状态语句来帮助实现判定、实现某些循环任务、调用其他覆盖普遍功能的函数。

  共享脚本编写方法是把代表应用程序行为的脚本在其他脚本之间共享。这意味着把被测应用程序的公共的、普遍的功能的测试脚本独立出来,其他脚本对其进行调用。这使得某些脚本按照普遍功能划分来标准化、组件化。这种脚本甚至也可以使用在被测系统之外的其它软件应用系统。

  数据驱动脚本编写方法把数据从脚本分离出去,存储在外部的文件中。这样,脚本就只包含编程代码了。这在测试运行时要改变数据的情况下时是需要的。这样,脚本在测试数据改变是不需要修改代码。有时候,测试的期待结果值也可以跟测试输入数据一起存储在数据文件中。

  关键字驱动脚本编写方法把检查点和执行操作的控制都维护在外部数据文件。因此,测试数据和测试的操作序列控制都是在外部文件中设计好的,除了常规的脚步外,还需要额外的库来翻译数据。关键字驱动脚本编写方法是数据驱动测试方法的扩展。

  总结起来看,对于开发的成本来说,随着脚本编写方法从线性倒关键字驱动的改变而不断地增加;对于维护成本来说,随着脚本编写方法从线性倒关键字驱动的改变而在下降。对于编程技能要求来讲,随着脚本编写方法从线性倒关键字驱动的改变,对一个测试员的变成熟练程度的要求在增加。对于设计和管理的需要来说,随着脚本编写方法从线性倒关键字驱动的改变,设计和管理自动化测试项目的要求在增加。因此,应该合理地选择自动化测试脚本开发方法,在适当的时候,使用适当的脚本开发方法。

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

posted @ 2011-06-14 14:49 51testing 阅读(149) | 评论 (0) | 编辑 收藏
 
如何在软件测试阶段有效的提高软件质量

  摘要:软件质量是软件产品的灵魂。软件设计技术,软件测试等都是提高软件质量的有效方法。从提高软件产品质量的可实施性、投资回报率等方面考虑,保证软件质量的最显著的方法是实施有效的软件测试,提高软件测试的效率。本文从软件测试工作的角度全面介绍了如何在软件测试阶段来提高软件质量。

  关键词:软件质量;软件测试;软件产品

  随着信息技术的快速发展,企事业单位对IT软件的需求越来越强烈,软件质量已成为开发商和用户共同关注的焦点,同时软件项目的规模和复杂程度也在不断增加。对于软件质量管理人员来说,提高软件开发质量的重要手段是把质量管理的理论和方法落实到工作实践中去。

  软件质量要达到国家标准软件质量的功能性、可靠性、易用性、效率、可维护性、可移植性等六个方面的要求,就必须对软件开发过程中各个环节进行全过程的质量管理,从需求分析、设计、编码、测试到上线验收进行控制。本人主要是从软件测试工作方面来阐述在测试过程如何确保提高软件质量。

  一、必须正确理解用户需求

  软件产品质量应该和用户满意度划上等号。考虑一个产品是否满足质量要求就是考虑一个产品是否满足用户的要求。

  软件需求需要关注客户和用户。简单的来说,客户是真正能够决定是否购买软件的人,而用户是实际使用软件的人。了解这类区别后,我们可在分析需求的重要性和在产品质量验证的时候根据需要做出不同的权衡。另一方面我们在考虑用户需求的时候,往往只考虑了实际使用软件的人员,而忽略了其它一些人员对软件的要求或对软件造成的潜在竞争,包括维护人员、系统管理人员、软件上下游人员的要求、先前版本的情况、竞争对手的软件情况。为保证软件产品的质量,我们必须准确把握软件需求。软件开发项目的提出,应由迫切的业务需求来驱动。软件项目业务需求的迫切性、技术实现的成熟性、经济效益的可行性等方面的因素,都是软件项目考虑的要素,将对项目的成败产生直接影响。

  软件版本管理

  目前的软件开发技术更新迅速,开发人员流动频繁,因此对软件版本的管理就显得尤其重要。为了最大限度地满足客户的需要和适应应用的要求,软件在其生命周期中会频繁地被修改和不断推出新的版本,新版本的软件会添加一些新的功能或者在软件功能上产生某些变化。随着软件的改变,以及时间的推移,开发人员对自己机器上的不同版本间的差异就会模糊不清,导致代码版本和现场版本混乱现象。另外可能由于软件开发工期的压力,开发人员只将注意力集中在设计和编码上,未将文档纳入到版本控制中。为了解决这些问题,软件质量监督就要注意跟踪记录整个软件的开发过程。通过应用软件版本管理的工具软件实现对源代码和整个项目的管理,从而建立正常的软件版本管理机制。

  二、软件测试

  软件测试是保证软件质量的重要方法。软件测试是否充分、有效,直接影响到软件产品的质量。随着软件开发规模的增大、复杂程度的增加,以寻找软件中的错误为目的的测试工作就更加复杂和困难。不足的测试势必使软件带着一些未揭露的隐藏错误投入运行,这将意味着更大的危险让用户承担。为了保证软件的开发质量,软件测试应贯穿于软件定义与开发的整个过程。因此,对分析、设计和实现等各阶段所得到的结果,包括需求规格说明、设计规格说明及源程序都应进行软件测试。对于测试过程的质量来说,应该从以下几个方面来着手:

  (一)目标——本次活动要达成什么样的目标(测试标准),什么样的情况下可以开始,什么样的情况可以视为结束?测试通过的准则是什么?在活动策划时这些都应明确下来。

  (二)计划——有了目标后,就需要开始定制计划了,要包括测试过程的时间,什么时候开始,什么时候结束,本期要分几次迭代,有几个时间点,可以按照项目的需要制定这个测试过程需不需要裁剪或增加哪些过程的迭代,并且建议在各时间点期间都要经过评审,还有测试所需资源、工具、测试工作所需的配置管理和保证方案、初始的测试策略、任务划分等等。

  (三)执行——测试执行期间需要跟踪其执行效率,随时根据需要调整测试策略,以及从缺陷的产生到结束的生命周期管理过程,收集测试过程中产生的各种有效数据,分析并评估问题对用户和系统的影响等等。

  (四)检查——对上述过程需要随时跟踪以便于及时发现测试期间发现的问题并着手解决问题。

  (五)行动——当测试结束后,需要对测试工作进行分析与总结,测试报告里要有两个方面的分析,一种是对测试产品的质量分析和评估,一种是对测试工作过程自身的分析与评估,因为只有有效的过程才能保证有效的输出结果,同时总结经验与教训,对下一次测试活动的过程进行改进。

  总的来说,软件质量、软件测试和配置管理都逐渐被各软件公司重视起来,软件测试的方法、技术和标准都还在探索阶段。国内软件行业普遍规模偏小,缺乏大型软件产品经验,开发过程不够规范,这决定了国内软件质量和测试行业,必须根据国内行业现状,确定软件质量目标和测试策略方法。“软件质量保证并不能够保证软件的质量”,但是我们可以把提高软件的质量作为我们从事软件质量保证工作的目标。

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

posted @ 2011-06-02 14:45 51testing 阅读(115) | 评论 (0) | 编辑 收藏
 
面向对象软件测试技术研究

  摘要:软件测试在整个软件项目开发过程中有着举足轻重的地位,软件测试技术的发展对于缩短测试周期、降低成本、提高质量都有着十分重要的意义。本文介绍了软件测试的关键技术,并对面向对象软件测试技术进行了深入研究。

  关键词:软件测试;关键技术;软件项目开发

  一、引言

  软件测试是伴随着软件的产生而产生的。软件危机的频繁出现促使了软件测试的地位得到了大幅提升。软件测试已经不仅仅是局限于软件开发过程中的一个阶段,它已经开始贯穿于整个软件开发过程,成为软件产品质量控制与质量管理的重要手段之一。

  软件测试技术作为软件工程学科的一个分支,是保证软件质量和可靠性的关键,因此它也是软件开发过程中的一个重要环节。它的核心思想是:对于输入域的特定输入,观察软件的执行结果,验证该结果与期望结果是否一致,然后根据结果作相应的纠错和调整。在测试过程中,测试用例的选择决定测试的有效性,这也就直接影响到成本,是软件测试的关键和难点。目前,软件测试技术的发展还不是很成熟,测试人员在选择测试用例时通常根据直觉和经验进行,给测试带来很大的盲目性,最终导致的后果是使软件后期维护的费用在成本中居高不下。科学生成测试用例对提高软件质量不仅重要而且必要。

  随着面向对象软件开发技术的广泛应用和软件测试自动化的要求,特别是基于的软件开发技术的逐渐普及,基于模型的软件测试逐渐得到了软件开发人员和软件测试人员的认可和接受。它是一种新兴的测试用例生成技术。有优于以前的测试技术的方面。其中模型以其定义良好、功能强大、普遍适用的优点,为基于模型的测试提供了非常好的契机。

  二、面向对象特征对软件测试的影响

  面向对象技术是一个全新的开发模式,具有以下特点:

  (1)它要综合考虑软件开发过程所有阶段。

  (2)在软件开发的整个生存周期中,每个阶段之间是连续的。

  (3)开发过程分为面向对象分析(00A)、面向对象设计(OOD)、面向对象编程(OOP)、面向对象测试(OOT)四个连续的部分。

  Coad和Yourdon给面}向对象的概念下了一个定义:

  面向对象=对象+类+继承+通信

  如果一个软件系统是使用这样4个概念设计和实现的,则认为这个软件系统是面向对象的。一个而向对象的程序的每一个组成部分都是对象,计算是通过对象和对象之间的通信来执行的。

  面向对象技术的本质是定义了类的抽象,将变量和与作用于它的操作封装到一块。然后用不同的类和方法组合成一个对象系统。面向对象软件将传统软件中的一个过程或一个方法内的复杂性转移到对象之间的交互中。面向对象语言一些本质特征形成了如下的一些新的故障、错误风险。

  1、基本功能模块

  在面向对象系统中,系统的基本构造单元是封装了数据和方法的类和对象,而不再是一个个能完成特定功能的功能模型。每个对象有自己的生存期,有自己的状态。消息是对象之间相互请示或协作的途径,是外界使用对象方法及获取对象状态的唯一方式。对象的功能是在消息的触发下,由对象所属类中定义的方法与相关对象的合作共同完成,并且对象在不同状态下对消息的响应可能完全同。

  工作过程中,对象的状态可能被改变,产生新的状态,即发生状态的转移。对象中的数据和方法是一个有机的整体,在软件测试过程中,不能仅仅检查输入数据产生的输出结果是否与预期结果相吻合,还要考虑对象的状态变化。因此,除了要对对象的状态与方法间的相互影响进行测试,还要进行状态测试。

  2、系统的功能实现

  在面向对象系统中,系统的功能体现在对象间的协作上,而不再是简单的过程调用关系。面向对象程序的执行实际上是执行一个由消息连接起来的方法序列,方法的实现与所属对象本身的状态有关,各方法之间可能有相互作用。为实现某一特定的功能,可能要激活调用属于不同对象类的多个成员函数,形成成员函数的启用链。因此,基于功能分解的自顶向下或自底向上的集成测试策略不适用于面向对象软件系统的测试。

  ......

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

posted @ 2011-05-30 13:12 51testing 阅读(134) | 评论 (0) | 编辑 收藏
 
自动化测试可以走得更远

  今天我和大家探讨的主题是自动化测试,我把它命名为“自动化测试可以走得更远”,进入这个主题前我还想跟大家交流一些想法,自动化测试我们知道它的提出实际上是和我们传统的测试是一个不对立的概念,也就是说我们国内在2003年之前,绝大多数的测试工作主要是集中在传统的人工测试上,2003年之后我们可以看到自动化的测试工具,从事自动化测试的工程师逐渐的如雨后春笋般的出现,自动化测试在我们业界有一个共识,就是采用自动化测试可以提高我们的测试质量,控制我们的进度,有的时候也可以规避我们的测试风险,降低一些成本等等。但是,自动化测试在国内的应用状况并不是太好。

  我举两个例子,第一,不管我们的中小型企业还是国内的大型企业,自动化测试程度都非常低,自动化测试开展得不是很好,有一些中小型企业的测试人员根本没有接触过自动化测试,大企业里自动化测试人员也都不是专职的,有一些相关的开发工作,任务重的就交给开发人员去做,没有专职的测试开发人员,这是一个例子。

  另一个我想说一下现在在自动化测试领域里我们离不开的是工具,这些工具国内自主研发的很少,基本上都是购买国外商品化工具的多。所以,从这两点可以看出来我们自动化程度并没有走出多远,应该说我们还可以走得更远。

  首先我先跟大家探讨一个比较传统的基础的话题,就是我们测试的模型,这里我们展现的是一个W模型,也就是说在这个模型里我们可以看到我们要求测试和开发同步进行,也就是说以前我们认为产品要上线,系统要上线,赶紧抓紧时间做测试,这是一个大好的时机,对于保证产品的质量至关重要,实际上现在我们可以看到,W模型是两个V模型的组合,显示绿色的V模型是开发的生命周期,显示黄色的V模型是一个测试的生命周期,我们可以看到,实际上在开发的不同阶段,都有可能引入缺陷,这个时候如果说我们对这些缺陷视而不见,等到上线前再去诊断它,再去修复它,我们将会投入的成本很高,甚至很多的缺陷是没有办法再去修复的。所以,我们说现在的测试实际上是和开发紧密配合的一个测试,也就是说比如说我们在做需求分析的时候,我们就应该引入一些需求分析的评估方法,架构设计的时候就应该引入一些架构设计评估的方法,到了编码阶段就应该采取一些单元和集成测试,等等。所以,我们自动化测试技术首先是建立在W模型之上的。根据这个模型我们现在就搭建了这么一个自动化测试的框架,这个框架它其实包含了三个层次,第一个层次我们强调的是我们的测试应该覆盖开发的整个生命周期,大家可以看到,我们有相关的需求和架构,也有到最后执行的运维的测试,刚才刘总谈到的像奥运票务系统已经上线了,但是承受不了大量的负载,宕机之后还得接着卖票,怎么办?我们只能进行运维测试,在生产环节优化,让它满足下一阶段的售票需求,这叫运维测试,也是比较有中国特色的一类测试。

  接下来为了满足全生命周期的策略,我们产生了不同的测试方法和技术,这个方法在测试发展这么多年变化不大,还是我们理解的白盒子黑盒子方法,这个技术是百花齐放,比如有我们熟悉的功能测试,也有性能测试,还有近些年开展起来的一些可靠性测试,安全测评,稳定性网络测试等等,测试技术还是发展非常快的。在这些技术里,大部分也都实现了自动化的方法,有的自动化程度低一些,比如大家熟悉的功能测试,自动化程度大家知道基本上还是靠我们人工在做,工具起的作用非常小,但是有一些自动化程度很高,比如我们经常提到的负载压力测试,我们的代码测试,它的自动化程度都达到了90%以上。现在我们这里列了一些目前新兴的自对化测试的类型,我们可以看到上面自动化功能测试的框架,刚才我谈到了虽然功能测试的自动化程度低,但是我们并没有放弃这块领域,很多人在这个方向在研究自动化的框架,很多企业也勇敢的去尝试怎么能搭建起适合于自己的框架,把我们的测试人员从传统的人工测试解放出来,更大程度去使用自动化测试。

  还有我们右侧展示的比如软构建的自动化测试技术,SaaS测试技术,以及宽带无线的测试技术,这都是在近一两年之内提出的一些新型的测试技术,也是发展到现在我们看来未必还特别完善的一些自对化测试技术,还是需要大家在这个方向共同努力,投入很多资源的一项测试技术。

  也有一些测试技术经过这些年发展以后,从不成熟逐渐发展为成熟,就是左侧展示的,比如可靠性测试,安全攻防测试,以及一些嵌入式测试技术,还有中间展示的下一代互联网技术,就是我们谈到的网络的仿真模拟技术。下面我就想就一些主流的测试技术跟大家共同交流一下目前自动化测试我们可以利用自动化测试能实现哪些目标。

  首先,谈一下自动化功能测试,自动化功能测试,我们大家知道传统的测试方法是工程师画出要测试的业务流程,然后根据这个业务流程设计用例,工程师给用例配上测试数据就开始人工的界面进行测试。自动化功能测试现在我们是将我们要测试的案例把它通过录制的方式转化成测试脚本,就是大家右下角看到的,这个测试脚本实际上是一种面向对象的编程方法,大家可以看到脚本里包含了被操作对象,操作的动作以及相关的操作值。这是我们提到的自动化功能测试技术里的关键字驱动技术,右侧的环态图是完整的测试流程,从最左侧的测试需求开始,我们一般的要经历这么几个过程,测试需求的制订,测试案例的设计,测试的执行,最后我们对我们测得的缺陷要分析和挖掘。整个的测试过程实际上我们现在已经用自动化的测试的技术和管理把它串起来了。这个时候我们可以看到自动化测试不仅仅替代手工测试,它可以在测试过程的每个环节都体现它的价值。这里面大家看到不光有技术,也有一些管理的因素在里面。

  这个时候我们可以看到刚才我们说到在整个测试里有几个关键的里程碑阶段,比如我们举个例子,关于用例,大家知道做功能测试我们都需要设计用例,这个时候我们就可以不但利用工具来自动化的设计用例,而且可以讲用例和用例相关的数据管理起来,这里涉及到用例对象的管理,逻辑关系管理,我们数据的自动生成,数据的自动组合生成,等等,这些都已经实现了自动化的方法。同时,我们用例如果我们需要用用例来构成更复杂的业务场景的话,我们也可以在管理工具里来进行不同场景的配置。

  这个时候有的人就说为什么自动化功能测试走得不远,用得不多呢?主要原因是这么两个情况。左侧展示的一个我们可以看到我们的手工测试人员居多,因为我们的很多测试人员是不具备开发能力的,这是一个。另一个我们国内信息系统发展的一个特点是需求变化的频率很快,这样的话,用自动化方法导致我们维护脚本的工作量很大,这是两个很现实的问题。现在我们怎么来解决这个问题呢?就是右侧这个矩形框展示的一方面我们可以研究和搭建设计框架,把底层的代码技术封装起来,让不熟悉代码的工程师可以绕开这一关,直接使用自动化测试技术,另外一方面,我们用动态脚本来代替静态脚本,来应对这个案例随着需求要不断变化和需求,这么一种现状。这是这样一个情况。

  ......

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

posted @ 2011-05-24 13:37 51testing 阅读(124) | 评论 (0) | 编辑 收藏
 
软件测试方法的分析与研究

  摘要:开发过程中一次性开发成功或者无错误发生的几率为零,因此在软件的开发过程中需要不断的完善,而这个不断完善修改的过程就是软件测试的过程。软件测试也代表了了设计、编码的最终复审。着重论述了目前软件工程中普遍存在的一些测试问题,并对其产生的原因进行了详细的分析。介绍了软件测试的本质,同时对目前流行的测试方法进行了研究,提出了不同类型的软件最佳的测试方案。

  关键词:软件可靠性;软件质量;软件测试;测试用例

  1、概述

  信息技术的飞速发展,使软件产品应用到社会的各个领域,软件产品的质量自然成为人们共同关注的焦点。软件开发商为了占有市场,必须把产品质量作为企业的重要目标之一,以免在激烈的竞争中被淘汰。用户为了保证自己业务的顺利完成,总是希望选用优质的软件。质量不佳的软件产品不仅会使开发商的维护费用和用户的使用成本大幅增加,还可能产生其他的责任风险,在一些关键应用,如民航订票系统、银行结算系统、证券交易系统等中使用质量有问题的软件,还可能造成灾难性的后果。

  软件危机曾经是软件界甚至整个计算机界最热门的话题,为了解决这个危机,软件从业人员、专家和学者做出了大量的努力。现在人们已经逐步认识到所谓的软件危机实际上仅是一种状况,那就是软件中有错误,正是这些错误导致了软件开发在成本、进度和质量上的失控。有错是软件的属性,而且是无法改变的。因为软件是由人来完成的,所有由人做的工作都不会是完美无缺的。问题在于应该如何去避免错误的产生和消除已经产生的错误,使程序中的错误密度达到尽可能低的程度。

  软件工程学出现后,软件开发被视为一项工程,以工程化的方法来进行规划和管理软件的开发。事实上,不论采用什么技术和什么方法,软件中出现错误总是难免的。采用新的语言、先进的开发方式、完善的开发过程,可以减少错误的引入,但是不可能完全杜绝软件中的错误,这些引入的错误需要测试来找出。测试是软件开发的重要部分。统计表明,在典型的软件开发项目中,软件测试工作量往往占软件开发总工作量的40%以上。而在软件开发的总成本中用在测试上的开销要占30%到50%。如果把维护阶段也考虑在内,讨论整个软件生存时期时,测试的成本比例也许会有所降低,但实际上维护工作相当于二次开发,仍至多次开发,其中必定还包含有许多测试工作。系统的问题越早发现,改正成本越低,破坏性越小,所以,在系统发布前要尽量多地把系统问题找出来,其手段就是有计划、有组织地进行充分的测试。

  软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一组测试数据,并利用这些测试数据运行程序,以发现程序错误的过程。根据测试数据设计方法,软件测试可分为结构测试和功能测试。在结构测试过程中,测试者对程序的语句、分支和逻辑路径进行各种覆盖测试,可以在不同点检查程序的状态,以确定实际状态与预期状态是否一致。软件测试的目的是发现错误,而不是确认其正确性,而对已进行的测试过程的程度进行评估。

  2、测试方法

  2.1 软件测试实质

  软件测试是一项逻辑性强、且极具条理的工作,也是具有风险性的行为。由于软件的输入量、输出结果、软件实现途径都很多,而且软件产品说明书没有客观的标准,导致从不同的角度看,软件缺陷的标准不同,因而无法对软件实施完全测试,这样,就无法通过软件测试显示隐藏的软件缺陷,只能尽量查找软件缺陷,找到的软件缺陷越多,说明软件本身的缺陷就越多,况且还有一些是未发现、不能断定的缺陷,这就是软件测试的局限性。

  所有的软件测试都有2个关键的问题组成:建立能测试应用程序的环境,并在该环境中测试软件能力。测试员必须理解和重新生成软件所在的复杂软件环境,并运用其能力确保正常的测试。

  2.2 软件测试手段

  从测试是否针对系统的内部结构和具体实现算法的角度来看,可分为白盒测试和黑盒测试。

  2.2.1 黑盒测试

  黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能情况下,通过测试来检测每个功能是否都能正常使用。在测试时,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息并且保持外部信息(如:数据库或文件)的完整性。黑盒法着眼于程序外部结构,不考虑内部逻辑结构,只针对软件界面和软件功能进行测试,它主要用于软件验收测试。黑盒法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。测试情况实际上有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。

  2.2.2 白盒测试

  白盒测试也称结构测试或逻辑驱动测试,它是在已知产品内部工作过程情况下,通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都能按预定要求正确工作,而不顾它的功能。白盒测试的主要方法有逻辑驱动、基路测试等,白盒法是穷举路径测试,主要用于软件验证。

  ......

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

posted @ 2011-05-11 15:28 51testing 阅读(149) | 评论 (0) | 编辑 收藏
 
《51测试天地》第二十一期电子杂志下载



《51测试天地》第二十一期电子杂志下载通道:http://www.51testing.com/html/39/n-234539.html

● 自己动手写一个可重用的登录测试程序..................................................5
● 【淘测试专栏】Senlon开源系统白盒测试..........................................17
● 性能测试分析目标函数法浅谈 .............................................................24
● 自动化测试框架实例研究及解决方案...................................................28
● 浅谈基于Selenium的Web自动化测试框架 ........................................38
● 测试估算,我们了解多少? ..................................................................43
● LoadRunner中检查点的重要性.............................................................45
● 让我们和开发人员一起成长....................................................................50

  流年似水,季节变迁,在寒冬将尽,春色已闻的季节,《51测试天地》第二十一期与您见面了。

  风雨五载,我们一直前行,感谢所有参与投稿的朋友,也热切期望更多的软件测试领域的朋友们前来投稿,让我们用胸中的热情与手中的笔,谱写未来美好的篇章!与《51测试天地》共同搭建这个学习交流的平台,帮助自己、同行及中国软件测试领域更快、更好的发展!

  测试估算是进行测试计划的基础,除了这个,我们对测试估算,还了解多少?作为测试人员,打交道最多的就是开发人员,如何跟他们更好的合作?如何让我们一起成长?《51测试天地》第二十一期为你揭晓。更多精彩内容等待您的阅读......

  四月的春天,桃红柳绿,暖日晴风,感谢各位亲爱的朋友一直陪伴着《51测试天地》,你们的支持与鼓励,你们的信任与理解,只有最好的服务,才能回报。在此,《51测试天地》向所有支持关心我们的广大测试朋友致以衷心的感谢和最诚挚的祝福。

  《51测试天地》作为沟通的桥梁,承载着我们的梦想,让知识的传播实现人生的目标;本着真诚服务态度,感受你们发自内心的满意。

  汇聚每个测试人点滴的力量,共同提高中国软件测试技术水平。

《51测试天地》编辑部

上海博为峰软件技术有限公司

二〇一一年四月

posted @ 2011-05-06 11:52 51testing 阅读(118) | 评论 (0) | 编辑 收藏
 
浅谈软件开发阶段的测试

  随着软件开发技术的发展,软件测试技术也开始得到人们越来越多的重视,但人们普遍的观念认为软件测试活动是在软件开发的中后期才需要介入的研发步骤,有的开发人员甚至认为软件测试活动不属于研发过程,而仅仅是软件开发完成后依赖黑盒测试…来保证软件产品质量的一个过程。事实证明,软件测试是软件开发过程中的重要阶段,是确保软件质量的关键,尤其越是早期的测试活动,对软件产品质量的影响越是事半功倍。因此,软件开发阶段的测试活动是软件开发中不容忽视的一个重要环节。

  一、软件测试的概念

  软件测试是发现错误的过程。或者说,软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例j,利用这些测试用例去运行程序,以发现程序错误的过程。

  从实际测试过程来看,软件测试过程是由一系列不同的测试阶段所组成。软件开发阶段的测试可分为:需求分析审查、设计审查、代码审查、单元测试、集成测试和系统测试等。需求分析审查、设计审查、单元测试中的代码评审及各阶段测试用例的评审都是通过对相关文档或代码的走读活动来实现的,这种评审活动称之为静态测试。静态测试能发现文档中存在的问题(也只能通过静态测试实现),通过对文档存在问题的分析或其他软件评审方法来发现需求分析、软件设计等中的问题。它能有效地检查代码是否具有可读性和可维护性,是否遵守编程规范,包括代码风格、变量/对类的命名、注释行等。静态测试已被当做一种自动化的、主要的代码校验方法,它的查错和分析功能是其他方法所不能替代的。

  单元测试、集成测试及系统测试等是通过运行软件来检验软件的动态行为和运行结果正确性的测试方法,它们称之为动态测试。

  二、测试活动在软件开发各个阶段的应用与目标

  1.需求分析审查

  需求分析是对用户需求进行确认和整理后对用户的需求进行性能、安全性、可维护性等项的划分,并将其细化为多个实现点,将用户的需求与软件的设计目标进行关联,生成需求规格说明书。它不仅是系统测试和用户文档的基础,也是所有子系统项目规划、设计和编码的基础。因此,它描述的准确性至关重要,对其评审即静态测试活动是不可掉以轻心的。软件需求规格说明书的评审是由评审专家组在对其仔细研读的基础上,站在各自的角度全方位地查找缺陷的过程。主要看其是否尽可能完整地描述系统预期的外部行为和用户的可视化行为;在功能点的描述上是否具有二义性;在实现上是否具有可行性;通过会议方式将缺陷确认、整理、修改到评审专家组认可。

  2.设计审查

  软件设计分为概要设计和详细设计,它依据需求规格说明书对系统的具体实现进行描述。概要设计是站在较高的层面上将整个系统进行模块划分,并将各功能项尽可能合理地安排在各个模块中来实现;根据系统的复杂度,可在每个模块中再进行下一级子模块的划分。详细设计则深入到每一级子模块当中,涉及到每个功能的具体实现流程、使用的数据结构乃至函数级的具体实现流程。它不但要考虑是否能更好地完成需求规格中向用户承诺的性能,还要兼顾其可靠性等质量保障。对软件设计的审查是通过评审专家对设计文档进行预审后,在评审会议上与设计人员将问题一一确认来实现。评审专家依据需求规格说明书审查设计是否覆盖到用户提出的每个功能点,对每个函数流程或伪代码进行逻辑与语句的审查,更重要的、也是最容易忽视的是要求评审专家要以自己的经验,重点对设计中使用的数据结构、函数执行效率、资源访问冲突风险等进行合理评估,以便尽早地把这些对系统开发有着颠覆性影响的问题在编码及单元测试之前排除。

  3.代码审查

  代码审查是通过代码走读的方式来实现的。代码走读是开发人员在对某个模块的代码(必须编译通过)依据设计说明书完成编码后,进行的代码评审活动。代码走读前要在内部统一标准,明确质量目标。评审中,除了看编码是否紧扣设计外,走读还应兼顾三个层面:第一个层可称之为单元走读,关注的是“单元”,一般是一个方法或一个类,需要查找代码层面的错误,比如数据库网络资源的回收、一些异常的捕捉、空指针的检查及关键字的使用是否正确等;第二个层面可称之为集成走读,关注的是接口和流程,包括传人的参数检查、返回值检查及流程能否顺利地进行和正确串联等;第三个层面可称之为系统走读,关注的是功能层面和业务逻辑,这时发现更多的应该是逻辑错误和功能缺陷。当然,在走读过程中这三个层面不是截然分开的,很多时候是并行的、互相交织和渗透的。代码走读的另一个重要内容是看代码是否遵守编程规范引,是否具有可读性和可维护性,注释是否充足等。按编程规范编码对提高代码的可读性以及降低编码的出错率至关重要,在大型项目中,具备可读性、规范性的代码更是日后进行有效维护的保障。因此,代码走读不仅可以保证代码的质量,更能有效地促进整个项目的编码水平。

  ......

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

posted @ 2011-04-07 13:23 51testing 阅读(120) | 评论 (0) | 编辑 收藏
 
软件测试之随机测试

  在软件测试中除了根据测试用例和测试说明书进行功能测试外,还需要进行随机测试(Ad-hoc testing),随机测试是没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行测试用例的重要补充手段,是保证测试覆盖完整性的有效方式和过程。

  随机测试主要是对被测软件的一些重要功能进行复测,也包括测试那些当前的测试样例(TestCase)没有覆盖到的部分。另外,对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug,进行再次测试,可以结合回归测试(Regressive testing)一起进行。

  随机测试主要是对被测软件的一些重要功能进行复测,也包括测试那些当前的测试用例没有覆盖到的部分。另外,对于软件更新和新增加的

  功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug,进行再次测试,可以结

  合回归测试(Regressive testing)一起进行。

  理论上,每一个被测软件版本都需要执行随机测试,尤其对于最后的将要发布的版本更要重视随机测试。随机测试最好由具有丰富测试经验的熟悉被测软件的测试人员进行测试。对于被测试的软件越熟悉,执行随机测试越容易。只有不断的积累测试经验,包括具体的测试执行和对缺陷跟踪记录的分析,不断总结,才能提高。

  客户端随机测试思想

  随机测试是根据测试者的经验随机的选取功能点对软件进行有针对性的测试。 这种测试没有用例的指导,完全根据测试员自己的经验和相关知识来测试。

  一、作随机测试之前的一些前提条件

  1)熟悉产品的各项功能和产品的逻辑结果

  2)熟悉测试用例

  3)完整的执行过测试用例

  4)熟悉在用例测试阶段所发现的缺陷和缺陷的分布情况

  5)测试人员具备一定的测试经验,对缺陷有敏锐的洞察力。

  二、随机测试功能点的选取

  1)根据用例测试阶段对产品的了解选取缺陷比较密集的功能模块。

  在发现很多缺陷的地方,一定可以发现更多的缺陷。我们在做随机测试的时候,首先会先统计一下,之前哪些模块被发现的缺陷最多,那么接下来一定要重点的在那个模块里发掘一下缺陷。

  2)根据发现的一次性缺陷或重现率比较低的缺陷涉及的功能点选取随即测试功能点。

  缺陷产生的过程一定可以重现,重现率比较低的缺陷是隐藏比较深的缺陷,这些缺陷可能正是导致软件无法上线的原因。因此重现这些隐藏缺陷是十分重要的工作。

  3)与开发人员沟通了解软件的缺陷。

  首先可以了解到程序本身哪些地方最复杂,最薄弱,这些地方最容易发生什么错误,其次可以了解程序员最容易在哪些地方犯哪些错误。前者通过对程序的熟悉可以比较好的掌握,后者可以通过对缺陷的分析得到。

  4)根据经验选取功能点。积累了一定的测试经验以后,有时测试就是一种感觉。

  5)随机选取功能点。经过上述四种情况对功能点进行筛选后,剩下的功能点可以随机的选取。随机选取功能点只是在随机测试中选取功能点的一个方面,更多的时候还是要有针对行的选取功能点。

  ......

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

posted @ 2011-04-01 15:46 51testing 阅读(242) | 评论 (0) | 编辑 收藏
 
【专题】软件测试缺陷管理大揭秘

编者按:

  Bug一词的原意是“臭虫”或“虫子”。但是现在,在电脑系统或程序中,如果隐藏着的一些未被发现的缺陷或问题,人们也叫它“bug”。中文常称BUG为“缺陷”。而且,“缺陷”一词更能反映事情的本质。因为“臭虫”是从外面飞进去的,并非程序本身有问题。

  软件的Bug,狭义概念是指软件程序的漏洞或缺陷,广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。

文章精选,点击查看:

  软件缺陷管理基本概念:http://www.51testing.com/html/51/n-66651.html

  软件测试中BUG的定义:http://www.51testing.com/html/68/n-72768.html

  Bug相关知识全覆盖:http://www.51testing.com/html/72/n-223072.html

  Bug管理的一般流程:http://www.51testing.com/html/62/n-7662.html

  软件测试新手如何快速找出软件中的Bug:http://www.51testing.com/html/24/n-227624.html

  软件测试Bug和bug生命周期中的各种状态:http://www.51testing.com/html/30/n-106230.html

  测试人员容易遗漏一些隐藏的缺陷:http://www.51testing.com/html/99/n-87899.html

  测试新手提交Bug时的注意点:http://www.51testing.com/html/66/n-216666.html

  软件缺陷的严重性和优先级:http://www.51testing.com/html/76/n-7776.html

  如何写软件测试缺陷管理的报告:http://www.51testing.com/html/00/n-90800.html  ......

专题入口:http://www.51testing.com/zhuanti/bug/bug.htm

posted @ 2011-03-24 11:42 51testing 阅读(145) | 评论 (0) | 编辑 收藏
 
探讨:企业测试自动化的策略、过程与误区

  本文主要分为四个部分:“梦想和现实——测试自动化理想与现状”、“冲出迷雾——真实的测试自动化及发展趋势”、“拨云见日——建立企业的测试自动化体系”和“过犹不及——谨防测试的过度自动化”。在这四个部分的介绍中,我们首先讨论自动化测试的现状,然后介绍测试自动化的过去和现在,在接下来的部分中,我们介绍在企业中建立测试自动化体系的具体方法,并用几个案例和大家分享这方面的经验,在最后一个部分中,我们讨论如何预防测试过度自动化。

  在介绍自动化测试之前,我们先看看“什么是测试”。简单来说,测试的目标是两个:“发现系统中存在的问题”和“证明系统能够满足用户的需求”。就“发现系统中存在的问题”来说,其主要的工作是“寻找一个最小的测试集合,使其能够发现大多数问题”。

  那么,如何评价一个已有的测试呢?一般来说,可以从四个方面对一个测试进行评价:“测试能否发现问题或是证明系统功能的正确性?”、“测试的覆盖如何(能够测试多个行为)?”、“测试执行、分析、调试的开销如何?”、“测试的维护开销如何?”。一个好的测试,就是能够发现问题或是证明系统功能正确性、能够良好覆盖需求、具有较少的测试执行、分析、调试,以及维护开销的测试。

  接下来我们看看自动化测试。第一个问题是,为什么需要自动化测试?Boris Beizer在《黑盒测试:软件和系统功能测试技术》中有一段经典的描述:“我看到的最悲哀的景象之一就是一个人在键盘上手动操作一些可以自动运行的东西。这是悲哀的但也是有趣的。”为什么说是悲哀的?——对于从事这件重复的冗余的事情来工作者说,日复一日的重复工作是悲哀的;为什么又说是有趣的?——对旁观者来说,一个人用一些机械的手工工作来完成本可以用自动化测试工具完成工作,有时候也是一件有趣的事情。

  那么,自动化测试到底能给我们带来什么呢?首先,自动化测试是建立在测试的基础上的,因此我们不能指望自动化测试能解决我们所有的问题——至少,一个设计不出来的测试自动化测试也对此无能为力。自动化测试能够带来的好处主要是两个方面:减少测试的维护开销,以及减少测试的执行、分析和调试开销。对于其他的两个评价测试的方面,自动化测试也不能比手工测试做得更好。

  曾经有个测试工程师向我描述过他对于“自动化测试”的梦想:“一个宽大的控制台,控制台上有一个闪烁着红光的按钮,只要轻轻一按这个按钮,一阵喀嚓喀嚓声音之后,一张完整的报告就出现在面前”——很美好的梦想,可惜,这个梦想距离现实还很有些距离。

  自动化测试的现状究竟如何呢?其实就目前来说,自动还测试还远远不能达到完全不需要测试工程师干预的程度。我们都知道,软件测试可以被划分成软件测试需求、软件测试计划、软件测试设计、软件测试执行和软件测试评估总结这几个阶段,自动化测试仅仅能够在软件测试设计、执行和评估总结的阶段发挥有限的作用,因此,我们通常把测试自动化理解为“测试的部分过程的部分自动化”

  那么,测试自动化究竟是什么呢?要回答这个问题,我们先看看“测试自动化不是什么”。

  测试自动化不是录制回放——更准确的说,测试自动化不仅仅是录制回放;通过录制回放方式的确可以进行一些简单的自动化测试工作,但这种纯粹的录制回放存在相当多的问题——首先是对结果的验证方式,纯粹的录制回放缺乏对结果的验证支持;其次,如果有多组不同的数据需要进行测试,纯粹的录制回放也很难应付。

  测试自动化不仅仅是测试工具的应用——一说起测试自动化,很多人头脑中立刻反映出来的就是测试工具,当然,测试自动化一定需要工具的支持,但测试自动化不仅仅是测试工具的堆积,就好像在原始社会,有了汽车,那也不能就说明进入了现代社会,测试自动化是一个系统的工程。

  测试自动化不是自发的冲动——在有些组织中,测试自动化是一些测试工程师自发的行为,甚至这些组织还会认为,只要这些工程师足够聪明,他们就能逐渐鼓捣出一个适合公司的自动化测试体系来,这种认识显然是不对的。

  测试自动化不是发现问题的最佳手段——很容易理解,由于测试自动化是建立在手工测试的基础上的,因此测试自动化最合适的是用在验证性质的回归测试阶段,而不能指望它去发现最多的错误。

  因此,我们可以明显地看到,测试自动化具有明显的约束。那么,测试自动化具有这么多的约束,那么它到底能做什么呢?接下来我们就看看“真实的测试自动化及发展趋势”。

  ......

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

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