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

软件测试需求的分析方法

  软件测试需求是开发测试用例的依据,测试需求分解的越详细精准,表明对所测软件的了解越深,对所要进行的任务内容就越清晰,对测试用例的设计质量的帮助越大。详细的测试需求还是衡量测试覆盖率的重要指标,测试需求是计算测试覆盖的分母,没有详细的测试需求就无法有效的进行测试覆盖计算。

  软件测试执行阶段是由一系列不同的测试类型的执行过程组成的,每种测试类型都有其具体的测试目标和支持技术,每种测试类型都只侧重于对测试目标的一个或多个特征或属性进行测试,准确的测试类型可以给软件测试带事半功倍的效果。

  现有的软件测试分析技术不太成熟,对测试需求和测试类型的分析,所采用的方法主要是根据经验进行收集、整理,该方法依赖于测试设计人员的测试经验,由此方法得出的测试需求、测试类型往往导致测试用例设计不充分,测试覆盖度低,测试目的性不强,容易遗漏等缺陷。

  可见,如何对测试需求进行细致的整理分析,明确测试执行时的测试类型,是一个亟待解决的问题。

  有鉴于此,本方法的主要目的在于提供一种软件测试需求的分析方法,可以方便、详尽的获取测试需求,明确测试执行时需要实施的测试类型。

  为实现上述目的,本方法提供了一种软件测试需求分析的方法,包括以下步骤:

  a)列出软件开发需求中具有可测试性的开发需求;

  b)对步骤a)列出的每一条开发需求,形成可测试的分层描述的测试需求;

  c)对步骤b)形成的每一条测试需求,从GB/T 16260.1-2006《软件工程 产品质量 第1部分:质量模型》中定义的软件内部/外部质量模型来确定软件产品的质量需求;

  d)对步骤c)所确定的质量需求,分析测试执行时需要实施的测试类型;

  e)建立测试需求跟踪矩阵,对测试需求进行管理。

  具体实施方式:

  下面结合附图及实施例对本方法做详细的说明。

  建立开发需求列表,参见图2。将每一条软件需求对应的开发文档及章节号作为软件需求标识,使用软件需求的简述作为原始测试需求描述,没有文档来源的开发需求可用隐含需求或遗漏需求进行标识,标明软件需求获取的来源信息,如开发文档、相关标准、与用户或开发人员的交流等。

  由于在提取的开发需求中可能存在重复和冗余,需要进行整理,通过以下方法整理开发需求:

  1)删除:删除原开发需求列表中重复的、冗余的含有包含关系的开发需求描述;

  2)细化:对太简略的开发需求描述进行细化;

  3)合并:如果有类似的开发需求,在整理时需要对其进行合并。

  在图2表中,对于每一条开发需求,从测试角度来考虑,形成可测试的分层描述的测试需求。具体地,通过分析每条开发需求描述中的输入、输出、处理、限制、约束等,给出对应的验证内容;通过分析各个功能模块之间的业务顺序,和各个功能模块之间传递的信息和数据,对存在功能交互的功能项,给出对应的验证内容。

  对每一条测试需求,从GB /T16260.1定义的软件质量子特性角度出发,确定所对应的质量子特性。即,从适合性、准确性、互操作性、保密安全性、成熟性、容错性、易恢复性、易理解性、易学性、易操作性、吸引性、时间特性、资源利用性、易分析性、易改变性、稳定性、易测试性、适应性、易安装性、共存性、易替换性和依从性方面的定义出发,确定每一条测试需求所对应的质量子特性。

  软件测试可以划分为以下测试类型:功能测试、安全性测试、接口测试、容量测试、完整性测试、结构测试、用户界面测试、负载测试、压力测试、疲劳强度测试、恢复性测试、配置测试、兼容性测试、安装测试等。

  不同的质量子特性可以确定出不同的测试内容,这些测试内容可以通过不同的测试类型来实施。例如,从易安装性方面考虑,测试内容包括测试软件安装的工作量、安装的可定制性、安装设计的完备性、安装操作的简易性、是否容易重新安装,这对应了测试类型中的安装测试,通过安装测试可以验证这些测试内容。

  本方法的一个实施例是建立一个质量子特性与测试类型的关系表,参见图3,该对应表给出了质量子特性与测试类型的对应关系。对所确定的质量子特性,可以使用该对应表来确定测试类型。

  建立测试需求跟踪矩阵,参见图4。将上述步骤分析、确定的开发需求、测试需求、测试类型填入测试跟踪需求矩阵。

  ......

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

posted @ 2010-11-29 11:53 51testing 阅读(152) | 评论 (0) | 编辑 收藏
 
黑盒测试中如何保证需求的覆盖度

  软件测试如何达到一定的覆盖度是个非常重要的问题,它是我们软件测试分析和测试设计工作的基础和出发点。在白盒测试中,我们可以用逻辑覆盖(语句覆盖、分支覆盖、条件覆盖、路径覆盖)等来指导我们的测试分析和设计,并用来评价我们软件测试工作的充分性,但在黑盒测试中,我们所追求的是需求要达到一定的覆盖度,那么如何衡量需求被覆盖的程度呢?又如何保证去达到一定的需求覆盖呢?请结合您的思考和实践,畅所欲言,希望各种观点在碰撞中产生火花。

  主要要做好测试需求分析测试需求分析分两步:

  1,测试需求的获取需求的来源:

  显式需求

  (1)原始需求说明书

  (2)产品规格书

  (3)软件需求文档

  (4)有无继承性文档

  (5)经验库

  (6)通用的协议规范隐式需求:用户的主观感受,市场的主流观点,专业人士的评价分析

  2,需求的分析 ,产生测试需求文档将不同的需求来源划分成一个个需求点,针对每一点进行测试分析

  (1)界定测试范围

  (2)利用各种测试设计的方法产生测试点。

  目前测试对需求的覆盖程度已经作为判断测试质量的一个标准,但不同的测试类型和需求类型如何判断测试的覆盖程度?

  1、一般来说,非功能性测试的覆盖程度比较好判断,如性能和压力测试,可根据需求中明确的性能指标进行测试分析和设计,另外也可通过分析系统在生产中实际使用情况,来分析一些隐含的需求,如系统是否需要连续运行、系统故障后恢复的级别、并发访问的程度等。

  2、功能性测试的覆盖程度是比较难判断的,用例数不能完全说明对需求的覆盖,因为用例数和测试点的力度划分相关,测试点划分的越细,用例数量越大,但不能说明覆盖程度高。

  我们的做法一般是先根据用户需求确定测试优先级,重点需求测试点划分的比较详细,测试用例要覆盖所有的情况,如正常值、边界值、特殊值等;一般性需求测试用例覆盖所有的正常等价类;测试用例设计上划分为单功能测试用例和测试场景设计,单功能测试覆盖的需求中的功能点,测试场景覆盖需求中的业务逻辑;另外测试设计全面与否,很大程度取决于需求的质量,取决用户是否真正明白自己想让系统做什么。

  看了上面高手的分析,真是受益匪浅啊~!~我也同意首先要透彻理解需求文档,把不明白的地方与开发人员、设计人员沟通。

  理解完需求后,我们就得开始写测试需求了,在测试需求了,我们将对软件或项目进行庖丁解牛的手法,将其功能模块细分出来,然后将模块中的功能点分解出来,我们得保证最后的功能点为最小分子,不能再进行下一步分解拉。(当然我们可以借助一些测试需求编写工具拉)测试需求细分出来后,剩下的就是编写测试用例了。每个最小分子需求对应写一个测试用例,用例中要将能想到的方法步骤全部写出来,大家开会讨论,不漏掉。执行“不抛弃任何一个方法、不放弃任何一个idea”。至于相关联的功能模块之间,我们也得考虑设计测试用例。(这些只针对黑盒测试的功能测试)
  
  ......

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

posted @ 2010-11-24 13:38 51testing 阅读(197) | 评论 (0) | 编辑 收藏
 
软件测试过程中的BUG管理

摘要:BUG的产生是由于不规范的代码编写,那么发现BUG一般靠的是测试。本文将简单讨论软件测试过程中的BUG管理问题。

  测试是软件开发过程中必不可少的一个阶段,大家的着重点可能都在测试人员如何发现BUG以及开发人员如何解决BUG,而很少去关注BUG自身的管理。在这里,想介绍一下我们在开发中如何进行BUG的流程管理,更重要的是想了解一下大家都是如何进行相关的工作,希望能与大家深入的交流。

  首先,需要介绍一下BUG的管理工具,这个应该做开发和测试的朋友都接触过,如Bugzilla,BugFree等,我们没有单独使用BUG的管理工具,而是使用TRAC,利用其中的TICKET来做BUG的管理与控制。TRAC中的TICKET自身有状态的工作流定义,我们使用的0.11版本,TICKET状态如下所示:

  然后,我介绍一下我们如何对BUG的流程进行控制:

  开发人员编码结束后,发布一个0.1的软件版本提供测试。测试人员对该版本进行测试,一但测出BUG,就在TRAC中新建一个TICKET,对BUG的情况进行描述,并指定哪位开发人员接收这个TICKET。同时,也指明该BUG是针对哪一个版本的软件。

  开发人员在接收到TRAC的邮件通知后,登录上TRAC,查看属于自己的TICKET列表。如果这个TICKET属于自己的修改范围,就accept下来,如果不是,就reassign给别的开发者。接下来的工作就是修复BUG,修复完成以后,将TICKET的状态更改为resolve as “fixed”。如果BUG不需要修改,或者根本不是BUG,可以选择resolve as “wontfix”和resolve as “invalid”。开发人员在将所有BUG都处理完一遍之后,可以BUILD出一个新的软件版本0.2。

  测试人员进行第二轮的测试,首先,他们需要把第一轮报的TICKET全部检查一遍,如果开发人员把BUG修复了,那么可以把TICKET的状态改为”verifed”,如果发现根本没有改完,而开发人员就把TICKET标成了已修复,那么测试人员可以把TICKET做一个reopen的操作。同时,把该TICKET的指定软件版本改为0.2。然后,继续测试,报出新的BUG。

  如此循环下去,直到测试人员测不出BUG,或者剩下暂进不改的BUG,开发人员的修复工作停止。测试人员提交测试报告。报告包括每一轮测试中测出的总BUG数,已修复的BUG数等。

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

http://www.51testing.com/html/74/n-223474.html

posted @ 2010-11-18 11:48 51testing 阅读(148) | 评论 (0) | 编辑 收藏
 
软件测试人员面试题、面试技巧全攻略

  编者语:软件测试面试题是一种经过组织者精心设计,在特定场景下,以笔试或面对面交谈与观察为手段,由表及里测评考生的知识、能力、经验等有关素质的一种考试活动。软件测试面试题是公司挑选测试职工的重要环节。面试给公司和应招者提供了进行双向交流的机会。软件测试人员该如何战胜测试面试题,找到自己心仪的工作呢?为此,小编从51Testing网站中,对与软件测试面试题相关的一系列文章进行整理,以便大家查看,进而希望能给大家一点启发和帮助。

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

查看专题请点击:http://www.51testing.com/zhuanti/interview/interview.html

posted @ 2010-11-08 11:53 51testing 阅读(154) | 评论 (0) | 编辑 收藏
 
《51测试天地》第十九期电子杂志下载

  冬养,春种,夏发,秋天收获。秋季是收获的季节。历经蒙特卡洛申博成功的喜悦、600天筹博的辛劳、150多天办博的兴奋,如今,上海世博会到了收获的季节。

  播种,不易;收获,也不易。干测试,也是同样道理。播种是“投入”和开创,收获是“产出”和延伸。有投入,必有产出,有开创还得有延伸;“投入”有智慧,“产出”也不能“坐等”。软件测试的“收获期”也有许多事情等着我们去做,从每次的测试中得到“延伸”、启发和借鉴,方方面面都要有思考。

  怎样提高测试能力?如何超越普通的测试者?《51测试天地》第十九期将为你揭晓秘密工具的神奇力量……更多精彩内容等待您的阅读。

  在此,《51测试天地》编辑部所有成员感谢所有参与杂志征稿的朋友,将他们的测试经验、心得、体会用文字表达出来与大家共享。在这个美丽的季节,你们是播种者,将你们的知识经验播撒;你们更是收获者,自我能力提升的同时收获来自所有关心软件测试发展的朋友的最诚挚的谢意!同时感谢所有读者朋友的支持和关注,你们见证了《51测试天地》的成长,是我们不断进步、不断延续的力量源泉。

  真挚的希望每一位业界的朋友能从《51测试天地》中得到一份收获。请点击此处下载杂志:http://www.51testing.com/html/07/n-221707.html

  希望广大会员继续支持本站,共同期待《51测试天地》第二十期。

  原创文章投稿请发邮件至editor#51testing.com(请将#改成@)

  译文征稿活动详情请查阅http://bbs.51testing.com/thread-86083-1-1.html。

  真诚欢迎您对《51测试天地》电子杂志提出宝贵意见和建议,请发邮件至editor#51testing.com(请将#改成@)。

posted @ 2010-11-02 13:43 51testing 阅读(224) | 评论 (0) | 编辑 收藏
 
IBM Rational 软件创新论坛六城市巡展即刻启程!

  IBM Rational 软件创新论坛已于 2010年 8月分别在深圳和北京盛大开幕。今年,IBM 围绕“智慧地球”的美好愿景,更加突出发挥软件的创造力,为开发找准创新着力点,全面提高企业产品市场竞争力。

  现在,为了把软件开发的创新理念带给更多的开发者,IBM Rational 软件创新论坛六城市巡展即刻启程!届时,我们将请来在深圳和北京峰会现场出席的重量级嘉宾,走进您所在的城市精彩开讲。

  巡展演讲主题尝鲜:

  智慧方式●CALM(应用生命周期管理)介绍

  应用生命周期管理(ALM, Application Lifecycle Management)将软件开发生命周期中的各种活动包括需求、建模、开发、构建和测试整合在一起,能够有效地解决业界研发团队中普遍存在的人员、流程和工具的一个个孤岛问题。因为有了 Jazz 这一突破性技术,IBM Rational 为业界提供了开放的、具有强大协作能力的 ALM 平台,即:C/ALM(collaborative ALM)。本演讲详细地向大家介绍了 C/ALM 相关的技术原理和产品组合,并展示平台灵活且强大的集成能力和典型应用场景。

  智慧管理●敏捷项目管理

  立足于真正的团队和高效团队的主要特点,探讨敏捷开发环境中项目经理的主要角色转变,以及项目经理如何智慧的平衡和使用敏捷开发团队的管理文化基因,建立高效的敏捷项目团队。同时,从实战的角度向各位介绍 IBM Rational 的敏捷转型故事,分享 IBM Rational 敏捷项目管理的最佳实践和最新成果。

  智慧应用●应用安全测试的“白+黑”解决方案

  随着互联网应用的快速发展,越来越多的应用部署在 Internet 上或者企业内部网络上,这些应用的安全性和稳定性也面临着来此内部,外部的众多挑战;

  黑客攻击,漏洞扫描,非法入侵,这些名词也越来越频繁地出现。你面临着这些威胁?防火墙等在内的众多的铜墙铁壁起到了作用?如何用一支矛检测这些盾牌的作用?我们将一起从应用安全测试的原理,来分析这些威胁,讨论如何完善我们的检测手段;从内部代码到外部应用,从白盒到黑盒。

 

日程
西安站>>
时间:2010年11月5日(星期五)
地点:西安凯悦(阿房宫)酒店
地址:西安市东大街158号

上海站>>
时间:2010年11月12日(星期五)
地点:上海龙之梦万丽酒店
地址:上海市长宁路1018号

成都站>>
时间:2010年11月19日(星期五)
地点:成都香格里拉
地址:成都锦江区滨江东路9号

南京站>>
时间:2010年11月26日(星期五)
地点:南京索菲特银河大酒店
地址:南京市鼓楼区山西路9号

武汉站>>
时间:2010年12月3日(星期五)
地点:武汉香格里拉
地址:武汉市汉口建设大道700号

 

联系电话:021-64471599-8017

本次大会免费报名参与,欢迎大家踊跃报名!

报名请点击:http://bbs.51testing.com/redirect.php?tid=322441&goto=lastpost#lastpost

posted @ 2010-10-28 13:44 51testing 阅读(113) | 评论 (0) | 编辑 收藏
 
关于评价测试用例的好坏

  leveret:

  现在大家在写测试用例的时候每个人都有自己的特点,但是什么样的一个测试用例才是一个比较好的用例,这是一个比较真实的现象,有这样几个问题大家可以交流一下自己的心得(如果愿意交流的朋友):系统测试的用例要如何设计才能验证需求?有时候不知道结果的情况下如何预测结果,测试用例应该在不同的阶段下实施的时候应该是独立的。一般在设计测试用例的时候要包括合理输入,不合理输入,预测结果,一般常用的测试用例的设计主要用到:等价类划分,边界值分析法,错误推测法,但是这些都是理论方面的概念,我们在实际设计当中往往并不是按照这些去做的。大家在设计测试用例的时候应该都有自己的心得,如果愿意,可以把自己的观点分享出来大家来讨论。

  seanhe:

  我感觉测试用例没有什么好坏之分:)当初的那句话,能发现最多错误的,发现至今为止没有发现的bug的用例就是好的用例,我认为是错误的。

  因为,测试不是解决问题,测试用例的好坏不是指单个的用例,而是用例的覆盖度,单个用例再好,所有用例的覆盖度不够,那测试工作还是失败的。所以测试的关键不是用例设计,而是测试范围的圈定,使用的方法,用例的设计只是自然而然的事情。

  再说说一开始的用例怎么写,开始肯定有很多不清楚所以用例中很多的内容无法填写,所以我们应该默认用例的书写是个迭代的过程,不同阶段完成不同的内容,执行之前全部完成就可以了。

  leveret:

  用例的覆盖率也应该是从单个开始的,而且很多时候发现用例在很多输入输出方面的设计基本都是雷同的,至于测试范围的圈定,在系统设计阶段我们能考虑周全吗?考虑的出发点呢?根据测试的类别来考虑还是根据需求方面呢?不过对你所说的用例的书写的迭代过程比较赞同,我们一般测试正式开始之前会对用例有一个评审过程,明白了这个道理之后我想应该会比较轻松的。对设计测试用例的同行来说。欢迎大家分享自己的观点

  jackei:

  下面列举了我的一些看法:

  01.对于“有时候不知道结果的情况下如何预测结果”,个人觉得这个问题比较明确,如果需求无法明确,或者说需求不够明确,则对于该需求的测试用例设计应该推迟,并及时同需求人员进行交流,尽快将需求准确的定义下来。

  02.一般在系统测试阶段考虑的测试方法是黑盒测试,这时对于测试用例的设计如何使用那几种方法呢?个人认为可以先使用等价划分的方法划分出等价类,然后使用边界分析法确定下测试数据,最后通过自己以往的测试经验或者其他的经验来进行错误推测,增补一部分用例。对于这个问题,个人对于现在市面上的很多测试书籍都有负面的看法,很多书提到的一些用例设计的例子都是用windows计算器或者其他单纯用几个数字来作为例子——比如输入域是0-100,让你设计用例。很多时候我们在进行用例设计时看到的并不是很明显的数字,这些东西都是隐含在业务规则中的,感觉我们现在很多初学测试的朋友这种分析业务规则的能力还是比较欠缺,看不到深层的测试需求。当然这些方法也就应用的很有限了。

  03.对于“测试用例应该在不同的阶段下实施的时候应该是独立的”,我也比较赞成。个人认为关键要搞清楚测试用例的作用。作为开发过程,是先有需求人员进行需求的收集,然后是系统分析员对需求整理分析,形成用例或者软件需求规格说明书,之后由系统架构人员进行架构设计,开发人员完成详细设计和编码工作——当然这也未必是一成不变的,但是大体的任务都是这么多。同样,我们看一下RUP中对于测试工作的流程介绍,为什么要把测试设计同测试实现以及测试执行明确的区分开来呢?因为测试工作现在同开发工作已经越来越相似,包括测试需求的整理、测试用例的设计以及测试用例的实现。我们现在很多同行所在的公司可能从人力资源或者从公司的流程上无法保证完全按照这个规范来操作,但是我们可以从RUP中明确测试用例的作用。用例本身就是用来指导实现的,用例实现的时候可以是自动化脚本也可以是手工操作的具体步骤。测试用例是可以同具体的应用程序实现完全独立的,可以不受应用程序具体实现变动的影响。至于为什么我将在下面说明......

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

http://www.51testing.com/html/51/n-220351.html

posted @ 2010-10-20 14:21 51testing 阅读(189) | 评论 (0) | 编辑 收藏
 
软件测试修炼之道

  软件测试发展到今天,已经逐渐形成一门学科,但是还不够系统。

  初学者面对铺天盖地的资料应该如何选取?应该从哪里入手?如何迅速的掌握各种业务各项测试技能以便开展工作?在保证测试质量的前提下,一日内编写或执行1000个测试用例是不是梦想?

  入行多年者面对复杂的业务逻辑,海量的测试需求,如何在最短的时间内进行测试?如何尽可能更早的开展测试?如何对系统架构进行测试?如何全面提高测试质量与测试效率?如何百尺竿头更进一步?

  本文将针对这些问题进行初步解答,主要阐述解决这些问题应该具备哪些能力及如何锻炼这些能力,至于实际工作中解决问题的具体操作步骤本文不做表述,可关注后续文章。前两章主要探讨一名合格的测试工程师应该具备哪些能力,对列举的能力将会做简要说明。第三章重点说明应该如何锻炼这些能力,此为本文的重点。最后一章是笔者对软件测试虚无缥缈杂乱无章的一些想法。

  本文的读者群涵盖所有对软件测试感兴趣的朋友。

  下面,我们开始。

  第一章 综合素质

  笔者以为,作为一名合格的测试工程师,综合素质是最重要的,综合素质也就是我们常说的软技能,它代表着一个人的潜力有多大,未来发展有多宽广。核心素质有以下五点:沟通、分析、组织、学习、心态,下面将会分别阐述。

  沟通

  作为一名软件测试工程师,优先加强的应该是哪方面的沟通能力?是文字沟通能力。试想,如果连缺陷描述都无法准确清晰的用文字表达出来,还有开发愿意和你合作吗?特别是随着异地开发的项目越来越多,文字沟通的场景也会越来越多。

  当然,口头沟通也很重要,通过面对面或者电话语音交流是很直接的方式,这也是为什么许多鼓吹敏捷开发的团队喜欢坐在一起的原因,认为这样会降低沟通成本。但事实上,真的在任何时刻都能降低成本吗?无效冗长的会议大家都参与过,这里不做深入讨论。

  不知道其他人有没有这种体验,笔者偶尔在查阅测试用例库或阅读工作邮件的时候会忍不住哈哈大笑,语句不通错别字也就罢了,写的像聊天记录一样尽是口头语就让人很无奈了。

  所以,这里首先强调的是提高文字表达能力,其次才是口头沟通能力。

  另外要特别注意的是,沟通能力包含两方面,一方面是说(写),一方面是听(读),表达与聆听同等重要。笔者发现很多测试工程师表达能力不错,但聆听能力很差,有时候甚至忽略聆听。对方话没讲完就急匆匆的打断,即使听了两句也马上反驳对方,这是恶习,比抽烟喝酒打老婆还要恶虐。

  分析

  早期我们认为测试的唯一工作就是发现问题,在很多文献资料上均有类似描述。但笔者以为,测试发展到今天,单纯的发现问题已不再是测试工作的全部,测试工作应包含发现问题、分析问题、解决问题三个方面。发现问题以测试人员为主开发人员为辅,分析问题开发测试共同完成,解决问题以开发人员为主测试人员为辅。

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

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

posted @ 2010-10-14 15:43 51testing 阅读(92) | 评论 (0) | 编辑 收藏
 
测试用例设计要求

  测试团队中来了新的同事,触发我去想“测试用例到底应该达到什么样的要求呢?”。个人认为可以从以下4个方面来把握测试用例设计的要点,而每个方面又可以对应基本要求和进阶要求。

  1、理解并覆盖需求v.s.质疑/补充/建议需求

  2、从自己的角度解释需求v.s.用多样化的形式展现需求

  3、从用户的角度测试v.s.更准确地模拟用户操作

  4、及时更新测试用例v.s.不断完善测试用例

  基本要求

  1、测试用例中不能遗漏需求

  a)test case与需求文档有追溯关系并实现完全覆盖(注意需求文档可能的更新)

  b)对数据字典等需求文档中细小的逻辑不要忘记

  c)各个影响的地方(入口)都要涉及

  2、在测试用例中用自己的话去解释需求而不要照抄需求。正着说,反着说,顺着说,倒着说,不论怎么说,核心是想换一种说法来确认是否大家对需求的理解真的是一致的。

  3、站在用户的角度做完整的、有效的测试用例设计

  a)如保存的最后一个步骤不是系统告知保存成功,而是重新查询出来看到确实保存成功。

  b)如接口测试需要做端到端的验证而非单个系统内部逻辑的验证。

  c)想象自己是用户,对可用性方面提出建议/意见。

  ......

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

http://www.51testing.com/html/70/n-220870.html

posted @ 2010-10-09 14:15 51testing 阅读(107) | 评论 (0) | 编辑 收藏
 
软件测试人员到底该如何提高自己的能力?

  在软件测试中软件测试人员到底该如何提高自己的能力?再次迷茫!

  在对软件测试的要求和期望越来越高,而软件测试的方法和工具没有长足发展的情况下,全面提升软件测试团队和测试人员的能力,就成为了进行有效测试并尽可能提高测试效率的重要基础。

  一、关于能力的浅析

  测试团队的能力由个人能力和团队能力两个方面构成,两者相辅相成。为了有效提高能力,首先对个人能力和团队能力进行一些浅显的分析。

  1.个人能力

  (1)个人能力的概念

  中国大百科全书《心理学分册》说,能力是“作为掌握和运用知识技能的条件并决定活动效率的一种个性心理特征”。通俗地说,我们可以认为个人能力是达到优异绩效所需的知识、技能和素质的组合,这里的素质包含了大百科全书所说的个性心理特征,是比较难以量化衡量的。

  (2)个人能力培养现状浅析

  ●对知识的培训

  软件测试工作来说,所需专业知识可分为基础工作知识和专门工作知识两类。基础工作知识包括软件测试的基本技术和方法、软件测试的文档规范等在专业内通用的知识,一般可使用专门教材进行培训。这些培训可以由内部专家完成,也可以由外部专家完成。相对来说,学习的成果也比较容易客观衡量。

  专门工作知识是在更小的范围、特定的时间内适用的知识。很多知识往往是处于经验的积累阶段,且具有时效性。例如对于开发中的应用系统的认识和了解,在目前业界文档编制、评审和版本管理的状况下,一般只能通过“师父带进门,修行在个人”的方法进行培训。在这样的情况下,如果测试人员有比较深厚的IT和业务经验,将缩短专门工作知识培训的周期,提高培训的效率。如果测试人员是新学生,则培训的难度较大。

  ●对技能的培训

  技能在很多场合也被称为“动手能力”,对于软件测试来说,技能的培训也很复杂。对于原来具有业务背景和软件开发、维护背景的人员来说,在软件测试工作中,肯定会优先使用已经掌握的技能,这样能够使得测试工作比较快地上手。了解业务、了解技术实际上是对被测对象不同角度的了解,是软件测试技能的重要组成部分,只有结合了专业的软件测试技能,才能够实现全面、协调、可持续的软件测试效果。仅仅从技术和业务角度进行测试,则往往在测试的彻底性、测试的效率和回归测试等等方面难以达到银行业软件测试发展的要求。

  根据目前我国IT人员和金融财会人员学历教育情况,本科生的技能与银行业软件测试的实际需要相比显薄弱。研究生在学历教育期间会有不同程度的培训,但是由于我国银行IT系统及其使用状况的复杂与庞大,学生较少有机会在类似的环境中接受相应技能的培训。

  以往对技能的培训,往往与专业工作知识培训采取相同的做法。很多情况下,专业工作知识与技能的培训是交织在一起的。实际上,很多人是通过自己的领悟了解到了工作的方法,但也形成了对于技能只能意会、不能言传的状况。

  ●对素质的培训

  素质可以通过多个方面展现,例如演绎思维、归纳思维、进取精神、人才培养意识和能力、灵活性、主动性、人际理解能力、人际影响能力、合作能力等。归根到底,就是一个人的世界观、价值观和处事哲学、基本习惯在各个方面的展现。实际上,素质对于高质量地完成软件测试工作,往往比知识和技能占据了更重要的位置。

  ......

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

  http://www.51testing.com/html/21/n-220421.html

posted @ 2010-09-29 15:37 51testing 阅读(171) | 评论 (0) | 编辑 收藏
 
仅列出标题
共55页: First 43 44 45 46 47 48 49 50 51 Last