软件测试的科学和艺术

发表于:2009-05-20来源:作者:点击数: 标签:软件测试艺术科学
、微软的 测试人员 微软的 软件测试 人员分为两类: 测试工具 软件 开发 工程师(Software Development Engineer in Test, 简称SDE/T) 和 软件测试工程师( Software Test Engineer,简称STE)。 测试工具软件开发工程师:负责写测试工具代码,并利用测试工具对软
、微软的测试人员

        微软的软件测试人员分为两类:测试工具软件开发工程师(Software Development Engineer in Test, 简称SDE/T) 和软件测试工程师(Software Test Engineer,简称STE)。

        测试工具软件开发工程师:负责写测试工具代码,并利用测试工具对软件进行测试;或者开发测试工具为软件测试工程师服务。产品开发后的性能测试(Performance Test) 、提交测试(Check-in Test) 等过程,都有可能要用到SDE/T 开发的测试工具。由于SDE/T和SDE 的工作都是写代码,具有相通的地方,所以两者之间互相转换的情况比较多。但需注意的是,两者写出来的代码用途是不一样的,SDE 写的是产品的代码,而SDE/T 写的代码只用于测试产品。 

        软件测试工程师:负责理解产品的功能要求,然后对其进行测试,检查软件有没有错误(Bug),决定软件是否具有稳定性(Robustness) ,并写出相应的测试规范和测试用例。除此之外,在一个软件产品的研发和销售过程中,还会需要负责给产品打补丁(Service Pack)的快速修正工程师(Quick Fix Engineer) ,通常曲SDE 来担任,通过电话方式向用户提供售后技术支持的支持工程师(Support Engineer),销售和市场(Sales and Marketing)人员,研究员和研究工程师(Researchers & Research SDE) 。在进行产品开发的时候,主要是由前面三类人员(项目经理、开发人员及测试人员)组成产品开发团队来进行的。在微软内部,软件测试人员与软件开发人员的比率一般为1.5-2.5 左右,这可能远远超出了大家对测试人员的理解,但微软软件开发的实践过程已经证明了这种人员结构的合理性。下图中显示了上述两个产品的微软软件开发人员的一般配置图。 
           下面以微软Exchange2O0O 和Windows2000 为例介绍一下微软产品团队的人员结构(这里只分析三类主要的人员,即项日经理、开发人员及测试人员),如下表所示。
           

二、测试时应考虑的几个问题

(1)测试最重要的一件事就是要考虑到所有的出错可能性。同时,还要做一些不是按常规做的、非常奇怪的事。 

       说起来可能不太好听,测试的过程就像黑客(Hacker) 的攻击过程那样。可以这么说,像黑客这样的人是最好的软件安全测试员。他们专门找软件的漏洞,从而破坏这个软件,这样就可以修复这些漏洞来保证软件的性能。如果找不到这种漏洞,那就说明该软件质量己经很好了。

(2) 除了漏洞之外,测试还应该考虑性能(Performance) 问题,也就是一定要保证软件运行得很好,非常快,没有内存泄漏,不会出现那种越来越慢的情况。 

       我们可以在不关机的情况下,与其他软件一起持续运行一个多月,看看是否会出现越来越慢的情况(当然必须保证其他软件是没有问题的)。我们在做IE 的时候,就是让它72 小时连续不停地打开不同的网页,处理几万个不同的网页,而且速度不能减慢。有许多软件,当只有一两个人用的时候,可能感觉不到什么问题,而当几百个用户一起用的时候,有的网站就出现各种各样的异常,这就是测试工作还比较欠缺的缘故。

(3) 另外,测试还要考虑软件的兼容性(Compatibility) 。一般来说,一个软件是由许多小软件构成的,如果其中一个小软件与它的前一版本不兼容,那么这个软件就会出现错误。这种错误需要通过测试来发现和解决。 

       许多人认为写代码的人一定能找出错误来。其实开发人员在写代码的时候,如果有错误,他可以意识到了,可是写出来的错误,他不一定能想得到。我自己也编过程序,在编程序的时候很自信,觉得不会有错,可事实上,即使是我编的小程序也有错误,但要自己找出来,却要费很大劲。因为我一直认为自己不应该出错,但常常错误就出现在我认为最有把握的地方。我是学数学的,是一个很细心的人,可是--样还是会出错,但要找出自己的错误却要花费很长的时间。后来我写的代码让我的师弟帮我看,结果他很快就找到许多问题,可是我自己花一个月时间可能都找不到。所以,开发人员和测试人员完全不一样,开发人员确实可以找到一些Bug,但是有更多的Bug 是他意识不到的。在一般的开发团队中,并不需要测试人员定位Bug 的具体位置,所以,对测试人员的要求并不高。只要你愿意学,测试工作是非常容易做的。但是,我当年所在的IE 团队(IE 4.0)就不同,因为当时正在与另一个公司的产品竞争,所以微软就要求尽量找到一流的开发人员和一流的测试人员,尽快开发出新产品,打败对手。所以,当时对我们测试人员的要求非常严格,不仅要找出Bug,而且要定位引起此Bug 的代码行。然后将这些信息交给开发人员,后者就可以很快更正,省去了他们找错误出处的时间。因此,当时IE 的开发速度非常快,一年之内就发布了一个新版本,而且几乎役有任何大Bug,大大超越了竞争对手。 三、关于Bug 

       Bug 的定义很广泛,在软件使用过程中所出现的任何一个可疑问题,或者导致软件不能符合设计要求或满足消费者需要的问题都是Bug,即使这个Bug 在实践中是可行的。有时候,Bug 并不是程序错误。例如,软件没有按照一般用户的使用习惯来运行,此时也可以把这个问题看成是该软件的一个Bug。通常,对Bug 的跟踪过程如图所示。 
       

原文转自:http://www.ltesting.net