软件测试

最近在读《软件测试》 一书,对叫这个名字的书多,我读的是Ron Patton 写的那本,对!2002年的中文版,已经十年了,虽然没《软件测试的艺术》那么经典,那么有深度,但绝对也是一本不错的好书。读到第三章“软件的实质”,觉得确实不错,这里摘录分享与大家分享。

  实质,哲学中把本质,又称为“实质”是指某一对象或事物本身所必然固有的。说的通俗点也就是说软件测试的本来的面目。

  软件缺陷的定义

  来看一下Ron Patton 为我们的软件缺陷所下的定义。

  1、软件没有实现产品的说明书所描述的功能。(个人觉得“描述”比“宣称”更贴切)

  2、软件实现了产品说明书描述不应有的功能。

  3、软件执行了产品说明书没讲的操作

  4、软件没有实现产品说明书没讲但应该实现的功能。

  5、从软件测试员的角度来看,软件难以理解、不易使用、运行缓慢,或者最终用户认为不对。

  为什么一个定义要这么多条来描述?这个“缺陷”的定义有这么复杂么?不,它其实并不复杂,作者只是想更加全面的来给缺陷下定义。下面我们来以建一栋房子为例,来说明一下每一条定义的意思。需要说明的是没有十分完美而且一成不变的产品说明说,而且在实际项目中,它可能非常简陋,模棱两可,甚至经常变动。

  1、软件没有实现产品说明书的描述的功能。房子的主要希望有一个落地的大窗户,让阳光更好的照进屋子里,而且他特意在房子的设计图纸中画出来,并且还加以说明。结果,他看到的是四面全是墙壁,只有一个小门的房子。那么对于测试人员来说,他就是一个缺陷。

  2、软件实现了产品说明书中描述的不应有的功能。由于房子的主人生活在南方,天气温暖,而请来的泥瓦匠是北方的,结果给主人建造的房子具然有一个大大的取暖的烟筒,而且主要主要特意在房子的设计图纸中说明,自己的房子不要烟筒。那么对于测试人员来说,这也是个缺陷。

  3、软件执行了产品说明书没讲的操作。与第二条类似,不同的是第二条是主人已经明确说了自己不要烟筒,而这一条强调的是在主人没说的情况下。泥瓦匠自作聪明的加了一个烟筒上去。对于测试人员来说,画蛇添足的功能同样被视为缺陷。

  4、软件没有实现产品说明书没讲但应该实现的功能。房子的主要对屋子的高度、格局,材料,颜色描述的非常清楚。泥瓦匠在建造房子的时候发现,主人没有提地基这回事,为了使房子牢固,所以,所有的房子都是必须要先打地基的,虽然主人没有说,但地基的功能必须要做。如果因为没有描述没有去做,但这又一件必须去做的事。对于测试人员来说,也可以视其这缺陷。

  6、从软件测试员的角度看,软件难以理解、不易使用、运行缓慢,或者最终用户认为不对。软件测试员是软件除了测试软件运行的缺陷,同样是作为一个用户在再对软件进行使用。如果感觉自己都很难使用,或软件效率非常低且界面丑陋等情况,也可以认为其存在缺陷。或者是最终用户拿到产品时发现这根本不是自己想要的东西,也可以现其为缺陷。当然,用户说不是自己想要的东西,也不能凭借一面之词,可以拿合约,产品说明书来评估。

  Ok ,上面分析一下缺陷的定义,如何去判定一个缺陷。下面来看一下测试的原侧,我们可以视其为软件测试过程中的“交通规则”。它会有助于我们更好的进行软件测试的工作

  全完测试程序的可能性

  初做软件测试者可能认为拿到软件后就可以进行完全测试了,找出所有软件缺陷,并使软件完美。遗憾的是这是不可能的,我们无法对一个软件进行完全测试,即使最简单的程序也不行。主要原因如下:

  ● 输入量太大

  ● 输出结果太多

  ● 软件实现的途径太多

  ● 软件说明书没有客观标准。从不同的角度看,软件缺陷的标准不同。

 这样说有些耸人听闻,又不能全部测试,不测试又会漏掉软件缺陷。软件终归要分布的,此时测试就要停止,但是如果这么快停止下来,还有测试没做。怎么办?

  如上图所示,纵轴是表示缺陷的数量,横轴表示测试工作量。缺陷的数量随着测试工作的进展在不段减少;但测试有费用也随着工作量在不段提高。

  也就是说要想发现更多的缺陷就必须投入更多费用(这个费用包括时间、人才,物力), 对一个新项目,我们前提可能1天发现10个缺陷。到后面可能10天发现1个缺陷,或者发现一个缺陷所需要的时间更长,我们有必要是去为发现一个缺陷而继续增加费用么?本来就不存在完美的产品,我们的目标是找到最合适的测试量,使投入(测试费用)与回报(修复缺陷数)达到最优。

  测试无法显示潜在的软件缺陷

  仔细理解一下这个标题。当测试人员对一个软件进行测试时,他发现了很多缺陷,功能的,界面的,兼容性能。然后,测试人员可以好不忧郁的说,这个软件存在缺陷。

  当又测试人员又对另一个软件进行测试时,他用尽各种测试方法,测遍所有功能(当然,这是不可能,上面已经说了无法完全测试),他投入了大量的时间和精力却最终没有发现一个缺陷。那么测试人员不能保证这个软件是没缺陷的,当然,他更无法去报告这些潜伏的缺陷。也就是说测试人员只能报告已经发现的缺陷,对于未知的谁也不能肯定。

  (这也是测试人员遭受质疑的地方,你既然不能保证软件的质量,要你何用。测试人员可以提高软件的质量,至于能提高多少,全凭测试人员的能力决定了。不像开发人员对于一个功能的实现,能或不能是很明确的两个答案。)

  找到的软件缺陷越多,就说明软件的缺陷越多

  我们先来体会下面两句话。

  “找到的软件缺陷越多,说明软件遗留的缺陷越少”

  “找到的软件缺陷越少,说明软件遗留的缺陷越少”

  不管是开发还是测试,我们期望软件遗留的缺陷少。但是上面的两句话都不成产。我们发现缺陷的多少和最终软件遗留的缺陷多少毫无关系。那么为什么会有上面两种推断呢?

  “找到的软件缺陷越多,说明软件遗留的缺陷越少”这种情况,假设缺陷在一定数量的情况下,测试人员业务非常精通,测试极其认真,发现越多的缺陷 ,说明还遗留的缺陷就越少。那么,我也可以假设随便这么一测,就发现这么多缺陷,那这个软件应该还有很多。

  “找到的软件缺陷越少,说明软件遗留的缺陷越少”这种情况,假设经验非常丰富,而且工作非常认少,测试人员花费了很大的时间和精力都不能找到缺陷,说明软件本身的质量很少,也就是说其本身遗留的缺陷越少。那么,我也可以假设为,是不是我对业务不够熟悉,经验不够丰富,为什么发现不了缺陷。那么可能软件遗留的缺陷还有很多,只是我没有发现。

  更严谨说法,或者更准确的说法是“找到的软件缺陷越多,就说明软件的缺陷越多。”我们发现有缺陷越多,只能说明软件的缺陷多。并无法正明软件还遗留的缺陷的多少。

  当然,也并不是无法评估软件遗留缺陷的多少,我们可以根据开人员的工作经验与技术能力,测试人员的工作经验,测试技能,对业务的熟悉程度以及后以往完的成项目质量进行评估。

  并非所有软件缺陷都能修复

  “每一个测试人员都一颗追求完美的心”,当我们发现了一个缺陷时,我们希望它能够被修复,我们不能容忍被发现的缺陷眼睁睁的存在着而无法得到修复。在软件测试中,令人沮丧的现实是,即使拼尽全力,也不是所有的软件缺陷都能修复。

  这并不意味着软件测试员未达到目的,或者项目小组将发布质量有缺陷的产品。其真正的含义是要软件测试员具备本文开头(缺陷的定义)中所描述的测试的素质---进行良好的判断,搞清楚在什么情况下不能追求完美。项目小组需要每对一个软件缺陷进行取舍,根据风险决定哪些要修复,哪些不要。

  不需要修复软件缺陷的原因:

  * 没有足够的时间。在任何一个项目中,通常是软件功能较多,而代码编写人员和软件测试人员较少,而且在项目进度中没有编制和测试留出足够的空间。

  * 不算真正的缺陷。或者有人说,这不算缺陷,而是一项新的功能。在某些特殊场合,错误理解、测试错误或说明书变更会把软件缺陷当作附加功能来对待。

  * 目前技术无法解决。你不会相信,人类有丰富的想象力,很多时候是受制于技术上无法实现。

  * 修复的风险太大。这种情况非常常见。软件本身是脆弱的、难以理清头绪。修复一个软件缺陷可能导致其它软件缺陷出现。在紧迫的产品发布进度压力之后,修复软件将冒引入更多缺陷的情况下。我们只能不去理睬现有的缺陷。

  * 修复成本太高,当我们使用一种技术去完成一项工作,当技术将要完成的时候发现一个缺陷无法解决,需要换用另一个技术才能有效规避这个缺陷。那这个修复成本将非常高。迫于时间与成本的压力。我们需要暂时不去理会。

  * 不值得修复。虽然有些不中听,但这是真的。不常出现的软件缺陷和在不常用的功能中出现的缺陷,或都出现也不会造成什么影响,那么就不值得去修复。这些都要归结为商业风决策。

  软件说明书不断变化

  软件开发者面临一个难题。整个行业变化太快,去年还很时髦的产品今年就过时了,同时,软件变得更庞大、更复杂,功能越来越多,导致软件开发周期不断变长。这两种反作用力形成了矛盾,结果是产品说明书一变再变。

  除了紧跟变化没有其他方法。假定我们的产品有一个不得更改的最终产品说明书。经过两年按部就班的开发快要完工时,结果竞争对也手发布了一个产品,结果从功能性能用户体验都要优于我们即将完工的产品。我们是继续完成一个失去竞争力的产品,还是重新讨论产品功能,重写产品需求,并开发修订产品?明智的选择是后者。

  软件测试员必须要想到产品需求可能改变。未曾计划的特性会增加,经过测试并报告软件缺陷的特性可能发生变化甚至被删除。这些者是可能的。

软件测试术语

  准确与精确

  关于软件准确与精确之间是存在区别的。我的理解在保证准确的基础上求精确。拿一个计算器来做例子。我最喜欢拿一个计算器来输入10除以3 ,如查等于3.0(四舍五入)了,那么它就不够准确。如果计算的结果是3.3 那么要我看他的小数点后面有几个3 ,3越多表示越精确。(个人认为在软件测试中,这个用到的不多)

  验证和合法性检查

  虽然验证和合法性检查常常互换使用,但是他们有不同的定义。其中的差别对软件测试很重要。

  验证是保证软件符合产品需求的过程。合法性检查是保证软件满足用户要求的过程。

  验证更多的是站在产品需求的角度去测试软件,合法性(或叫“合理性”合适)是站在用户的角度是测试软件,当他们发生冲突时,就需要对产品时行衡量。但我偏向于用户角度,因为产品的最终目的是给用户使用,而不是为了符合需求文档。

  质量和可靠性

  质量解释为“优秀程度”或者“超越同类的”。如果说软件产品质量高,就是指它能够满足客户要求。客户会感到该产品性能卓越,优于其他产品。

  如果在测试过程一直稳定、可靠,就会认为这是高质量的产品。这样理解错误。可靠性只是质量的一个方面。那么产品在各种机型上是否一样运行稳定。是否有技术支持,是否使用方便且性能优秀,这些灰是质量的组成部分。

  测试与QA

  软件测试人员的目标是找出软件的缺陷,尽可能早的发现并确定修复缺陷。

  QA的主要职责是创建和加强促进软件开发并防止软件缺陷的标准和方法。

====================================分割线================================

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-10-01 01:45:02

软件测试的相关文章

软件测试员----面试,你准备好了么?

  最近有机会做一些面试工作,主要负责面试软件测试人员招聘的技术面试.   之前一直是应聘者的角色,经历了不少次的面试之后,多少也积累一点面试的经验,现在发生了角色转变.初次的面试就碰到个工作年限比我长的,也没有时间仔细了解对方的简历,再加上应聘者比较"强势".面试情况是比较糟糕的. 有同学会说,唉!不就失去了一个应聘者嘛.多面几个就好了!这不单单是失去应聘者,面试者对面试官的印象更重要.面试官的能力与表现对于初次面试者来说往往代表的是公司的,更具体点是测试团队的能力. 如果面试官都很

软件测试-linux代码覆盖率测试工具gcov的一些疑问?

问题描述 linux代码覆盖率测试工具gcov的一些疑问? 鄙人是做软件测试的,最近在使用gcov来检查代码覆盖率,我已经成功生成了一份关于touchscreen测试代码的gcov文件,但是领导说这不是他想要的...所以我想请教一下大家:1. 如果我想测试平台上的touchscreen模块,那么目的肯定是这样:首先我要看下我写的测试code是否存在多余的根本跑不到的代码,如果有,那我肯定要优化我的测试代码:其次,我肯定也要看我写的代码在linux kernel里面的覆盖情况,如果我写的测试代码在

一个软件测试员的工作与学习(三)

在开始讲述这一年多的经历的过程之间,我又回顾了之前的经历,以便把比较好的把故事的衔接,需要说明的是,我并没什么高大上的经历来吹牛皮,只是做为一个普普通通的软件测试员,来记录自己的经历而已.     关于学历                                          应该是在入职新公司前报考的自考,学历一直是我的硬伤,所以,就想通过自考的方式来弥补,对于搞技术的来说,尤其已经在这个行业混了几年的人来说,学历真有还很重要么?这得看公司.有些公司不在意学历,有些公司没有就是不行

敏捷软件测试常见误区

转自 ThoughtWorks 敏捷软件开发是从1990年代开始逐渐引起广泛关注的一种新型软件开发方法,是能够应对快速变化的需求的一种软件开发能力,它作为一种新型的开发模式,被越来越多地应用到软件项目中. 敏捷软件测试指的是在敏捷软件开发过程中跟质量相关的一系列活动,和传统意义上的软件测试有很多区别,因为敏捷软件测试的概念一直比较模糊,所以经常会有人走入误区,我曾经在瀑布型的软件开发模式下做过几年的测试人员,所以在刚刚接触敏捷项目的时候也曾有过一些误解,但是在敏捷软件开发团队工作将近5年后,对很

全程软件测试实践:从需求到运营

之前一篇文章<软件测试转型之路>介绍过我们转型的一些实践,下文将介绍从2011年3月至今,持续改进的全程软件测试实践活动. 1 全程软件测试图解 传统的软件测试,可以简单描述为下图所示: 图-1-传统交付测试 开发人员完成任务之后,最后交付给测试人员,这种模式下,测试人员不能及早发现需求阶段的缺陷,同时测试工作的开展也滞后了,产品质量得不到有效的过程控制和分析,总体进度可能会由于返工问题造成拖延. 那什么是全程软件测试,如下图所示: 图-2-全程软件测试图

Web软件测试 Checklist 应用系列(1) 数据输入

该系列文章分为以下几个部分: 第 1 部分:数据输入 主要介绍 Checklist 在表格输入.数据验证.数据一致性.日期输入.数字输入.文字字符输入区检查等 多个方面的应用. 第 2 部分:导航和链接 主要介绍在 Web 产品的导航和链接中应用 Checklist,以确保 Web 产品中的所有链接和页面可以正常到达 . 第 3 部分:颜色和字体 Checklist 在 Web 测试中的重要性 Checklist(检查清单)从名字字面意思即可理解,是用于检查 的一系列条目.之所以需要 Check

2009年国内软件测试的十大热点预测

2009年悄悄地来到了,送走了艰难的.折腾的2008年.人们对2009年会充满更多的期望,9是一个吉祥的数字,天长地久,而且农历是牛年,牛年更牛. 到了2009年,该为软件测试写点什么.顺民意,预测一下2009年国内软件测试的十大热点. 基于云的测试将是新的课题,包括测试方法.技术和工具.而且,云环境下的测试也是减少测试成本的一个途径. 基于Web 2.0/Ajax 的软件测试技术还是热点.Java/Javascript技术变化很快,系统开发框架也是层出不穷. 软件测试自动化也还是热点,包括更多

以客户关注为焦点看软件测试

众所周知,在软件测试行业,往往都是以软件 Bug 数量来衡量软件的质量.一个软件被测试团队 发现有大量 Bug 时,该软件的质量被认为处在不高的水平.当较少的 bug 被发现时,软件则被认为 是具有较高质量的.测试的目的是为了发现更多的 Bug,然而测试人员经常会为追求发现更多的 Bug 数量而忽略了软件测试更本质的东西.软件测试的终极目标是给客户提供满意的产品和服务.因此, 只有真正去理解.熟悉.分析客户所关注的业务,包括客户的使用目的.客户的使用预期.客户的部 署环境.客户的数据甚至客户的使

软件测试中的黑天鹅(三) 测试的平均斯坦与极端斯坦

1. 突破性与非突破性 <黑天鹅>里谈到了突破性与非突破性的概念. 这世界上有些职业的 收入是不具突破性的,比如面包师.咨询师.按摩师.牙医等等,其收入受到既定时间内所服务的客人的数量 的限制,这种工作在很大程度上是可以预测的,面包师必须为每一位客户烤出新面包,不论他出售的面包单价 有多贵,其收入总是受到限制的. 而另外一些职业如录音师.电影演员.作家.投机师等等,他们只 需花费单次的投入而不必过多劳动就有可能使得收入后面增加几个零,<哈利·波特>的作者不必每次有读者 想读这本书的

报告软件测试错误的规范

报告软件测试错误的目的是为了保证修复错误的人员可以重复报告的错误,从而有利于分析错误产生 的原因,定位错误,然后修正之.因此,报告软件测试错误的基本要求是准确.简洁.完整.规范.需 要掌握的报告技术归纳如下. 1.描述 (Description),简洁.准确,完整,揭示错误实质,记录缺陷或错误出现的位置 描述要准确反映错误的本质内容,简短明了.为了便于在软件错误管理数据库中寻找制定的测试错误 ,包含错误发生时的用户界面(UI)是个良好的习惯.例如记录对话框的标题.菜单.按钮等控件的名 称. 2.