人生在世如身处荆棘林中,心不动则人不妄动,不动则不伤; 如心动则人妄动,则伤其身痛其骨,于是体会到世间诸般痛苦

測試分類:

上一篇 / 下一篇  2010-06-08 15:21:45 / 个人分类:概念理解

单元测试        
       单元测试是在测试过程中的最小粒度,它在执行的过程中紧密的依照程序框架对产品的函数和模块进行测试,包含入库和出口的参数,输入和输出信息,错误处理信息,部分边界数值测试。
           这个部分的测试工作在国内现在是开发人员进行的。我相信未来的发展应该是测试工程师来做这个事情。那么需要测试人员需要深刻的理解程序,理解需求,理解设计,这样才能发现问题。
           还有一种在国内先在操作的方法,就是当一个模块给某个开发工程师以后,需要他给大家讲解他要完成这个模块或者函数的整体流程和思路,进行统一评审,使得问题能够暴露的更充分些,这样做的目的有以下个,第一,使得大家对设计者的思路明晰的理解,以便以后调用或者配合的时候能够真切的提出需求或者相对完美配合。第二,在评审的过程中,如果发现问题,那么大家可能没有犯过,这样就会更加提高警惕,如果犯过,就会回想当时自己怎么解决的或者规避的,使得大家能够在错误的过程中快速提高。第三,可以对平常犯错误进行一个积累,我觉得这是生动的教科书,可以使得新的人员在新上手的时候遇到这样的问题以后,我们就可以给他一个解决问题的方法或者方向。
           回顾,我们上面给大家介绍了两种方法,第一种就是通过在开发的过程种进行测试,由开发(测试)工程师写测试代码,对所编写的函数或者模块进行测试,第二种就是通过代码互评发现问题,将问题进行积累,形成知识积累库,以便使得新人在同样的方面不至于再犯错误。
           单元测试非常重要,因为他影响的范围和宽度比较大,也许由于一个函数或者参数问题,造成后面暴露出很多表象问题出现。而且如果单元测试做不好,使得集成测试或者后面系统测试的压力很大,而且项目的费用和进度可能就会飚升。
           对单元测试,现在用CPPUnit的比较多,市场上也有其他对应的产品,他们在不同的软件单位不同的阶段。正确的理解单元测试的重要性是意识,需要在过程改进种不停的总结,慢慢的积累,将质量意识渗透到整个开放过程中的各个环节。
           保证单元测试顺利进行,需要渗透软件工程的很多思想,把CMM和跟踪机制建立起来,问题的分类、跟踪,如果把软件环节整个活动都渗透了,那么产品质量的意识自然就增强了。
           COM思想现在在大的项目现在体现的淋漓尽致,因为如果不采用COM机制,维护和升级以及修改测试的成本很大,所以现在大型项目基本上都采用COM的组织形式。
           说了这么多,单元测试做什么呢?单元测试主要是做一下几个事情:
第一,           模块或者函数的设计稿
第二,           代码规范,其中包含代码书写规范,对齐方式
第三,           代码的注释。非常重要
第四,           参数类型,数据长度,指针,数组长度大小
第五,           输入输出参数和结果
第六,           创建对象后是否删除了,如果在这里没有删除,请注明在那里删除
第七,           是否应用了没有初试化的变量,如果是,请指明该变量在那里初始化
第八,           变量是否声明,声明是否按照要求进行
第九,           调用此函数需要的满足条件需要注明
第十,           在此函数或者模块中用到了系统或者其他第三方插件函数,需要满足的系统条件
上面我只是列举了一些在测试过程中发现或者隐藏的问题,我想可能还有很多情况引发问题,请大家补充,以便在工作中有操作性。
        集成测试      
    集成测试是在保证单元测试进行后进行的一个动作,能否集成的标志不是所有的代码编译通过了就算是可以集成了,而是所有的能够在这个虚拟环境下能够正常运转。
           在集成测试种一般采用的方法是数据驱动或者桩驱动,因为集成测试不能看到产品的表象,因为他是一些数据流的中间段,我们渴望能够对中间数据进行分析,就可以知道或者就渴望知道流程或者算法中有什么不妥当的地方。
           集成测试比较适合做成自动化测试,当然首先我们分析了适合做自动化的条件是满足的,我这里就不讲详细的方法,到后面的自动化测试介绍中,我会提到这个方面的问题。下面和大家一起揭开测试自动化的神秘面纱以及给大家讲一些构建冒烟的概念。
           冒烟测试的出处是,由于生活习惯等原因,人们会定期的做某个事情,就像人们会约定成俗的认为12:00是吃饭下班的时间。那个时候大家都会做饭,哈哈,自然会从烟囱冒烟。在软件行业里面的约定是当产品到达某个阶段之后,为了验证产品的各个部分的衔接程度,为了验证项目的进展程度,为了验证产品的(已完成)功能的全面稳定程度,由测试主导的一种测试方法,主要的操作就是,在产品开发计划定制完成以后,依照开发计划指定完整的编译计划,按照开发计划和编译计划,各个单位按照要求完成自己的作业,然后在编译点上验证完成程度。
           集成测试也是不可缺少的一个部分,很多单位为了赶进度,会将这个部分省略掉,就甩手给测试小组,如果没有对应的测试小组,就会是程序员进行简单的使用后就交付市场,危险,这是个定时炸弹。因为他时刻有可能产生市场对企业影响的额度,以及企业本身的声誉问题。
           集成测试是在单元测试完成后进行的测试环节中的一个测试,主要是测试各个模块和函数之间的相互衔接情况,互动情况,输入输出情况。所以集成测试也很重要。
           那么集成测试一般采用什么方法呢?集成测试一般采用桩驱动的方法,因为在单元测试我们检查的相对比较详细,那么在集成测试的重点其实要保证逻辑上了。我简单的介绍桩驱动的实现方法。

桩模块(函数)
在单元测试已经作过详细的测试
关联模块或者函数1
关联模块或者函数2
关联模块或者函数3
关联模块或者函数4
关联模块或者函数6
关联模块或者函数5
请大家看上面的图,这个一定是一个有意义的组合。是函数间形成一个简单的逻辑关系。
  从上面的图上我们可以看到,如果中间的模块或者函数是经过我们进行过详细的测试,基本上可以保证没有什么错误,那么如果这个逻辑出去,导致出错,一定是输入的过程或者接收了输出参数处理出错了。使得我们问题很好的定位。
  我们可以定义很多个桩,使得测试效率提高。
我们把上面的内容进行简单的总结:集成测试就是测试各个组件之间的配合情况。所以集成测试是为系统测试提供了一些基本保证,但是不要完全依赖。
采用的方法给大家介绍了,这样可以采用测试或者程序编码的形式实现测试。
        系统测试          
系统测试是测试过程中的一个转折点,因为在现在国内的企业中,不同的产品面对不同的用户群体,所以有的企业经过第三方产品的验收测试,有的企业则没有通过验收,而是一些工具类或者通用类的产品,那么他的验收测试是经过广大的用户群来做的,也就是说凡是通用类产品的系统测试必须严谨测试以后,才可以投放到市场。但是对于对企业或者其他专业性单位定制的产品我们必须进行验收测试。
        系统测试工作是一个重复老动很多的工作,需要在工作种把握几个重点,系统测试是保证系统能够正常运转,包括了功能,易用性,健壮性,压力,边界数值设定等各个方面的内容。要想在这个阶段的工作种找到乐趣,就要不停的摸索,找出能够将机器代替人的所有的东西,找工作的快感。
       系统测试需要有广泛的知识面,对测试工程师的要求需要了解和掌握很多方面的知识,需要了解问题可能出现的原因,已经出现这个问题可能是由于什么原因造成的,以便我们能够及时的补充测试案例,保证或者降低产推出的风险。
       目前软件测试行业发展还不成熟,大多数系统测试都在测试组做,而且测试组几乎到系统测试测试阶段才会接触到产品。我们也把系统测试简单的说明一下。
       目前系统测试基本上采用黑盒测试方法,而且基本上局限在手公测试上面。
被测试的软件
从上面简单的图形可以看出来,我们不知道被测试软件是怎么实现的,做了什么事情,我们只知道我们要它做什么,我们想得到什么,至于程序内部怎么实现,我们并不关心,我们只是关心结果。这是一种纯粹黑盒的测试。
        这个阶段是测试发现问题的主要阶段,最少从目前市场上的产品情况来看是这样的。在这个阶段60%的问题会暴露出来,如果不进行单元测试和集成测试,这个阶段的测试量和测试点很重要。
       黑盒测试的核心是需要找到测试的重点在那里?测试的切入点在那里。系统测试重复的工作量比较大,而且如果是一个大型的项目,涉及的内容相对比较多,而且如果组织不好,或者没有找到重点,需要一遍遍的重复。所以需要自动化测试的需要合理的设计,使得我们的重复工作尽量减少,以提高工作效率。
       其实系统测试在软件开发环节中不可缺少的一部份,这里的重点工作是如何提升自己的设计能力,在系统测试的或者说集成测试的时候,所有的对测试工作来说,都是一个挑战。那么如何提升我们自己的设计能力呢?推荐已往工作中的经验,积累的方法有几种,第一,把bug描述清楚,这个bug描述可能在大家看来就是步骤清晰,其实在我认为,描绘一个场景其实并不是那么简单,其中包含了营造环境,包含了bug出现的方法,彻底减少程序开发人员的猜测,这样就能够有足够的时间积累我们的技术;第二,描述bug后,能够根据现在bug的情况,做一个简单的分析,其中包含了现象,从结构上分析可能是什么原因,然后跟开发沟通,错不怕,怕的是不想;第三,设计合适的案例,现在有很多人一提起案例,就是遍历,把所有的功能或者数据遍历,在测试的角度和进度的角度几乎不可能的,那么如何才能设计发现问题的案例,使得案例有效呢?那就需要吃透整个设计的逻辑,然后设计出经典案例,否则劳神费功夫;第四,询问,我一直以为是最好的学习方法,当发现一个bug的时候,如果你能分析,并且能够让开发人员纠正或者从结构上帮助你把分析问题的着力点找到,那设计能力和效率也同样会提高。            
       验收测试      
       验收测试类似于客户验证产品的质量,在软件行业发展的过程中,各种承包项目类似于国外的外包项目将会不断的出现,那么外包项目的质量问题需要大家共同讨论。
       外包项目的操作流程是当承包方提出具体的需求,然后有承包商来按照需求来开发项目,包括单元测试,系统测试,集成测试等各个方面的测试,经过被承包商测试后的产品提交给外包商的时候,需要进行验收测试,验收测试可以是外包商本身提供一套测试方案,然后对照具体的需求,进行产品验证测试。也可以是双方找一个共同的第三方,进行产品的验证测试。
      验收测试的测试重点主要是产品是否按照需求开发的,而不从针对功能进行的测试。所以验收测试基本上不需要多少专业水平,也可以是承包商找到使用该产品的用户,来体验该产品是否能够满足使用要求。这样以来使得双方可以有一个共同的平台,避免商业矛盾的产生。
     验收测试的测试手段目前来说还是靠用户体验。对照合同的需求进行测试,是第三方按照双方达成的共识来跟踪和测试软件是否能达成的需求。

TAG:

 

评分:0

我来说两句

Open Toolbar