ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 测试蓝本

测试蓝本

原创 Linux操作系统 作者:habug 时间:2009-01-08 09:07:11 0 删除 编辑


测试介绍

测试现在被普遍认为“保证产品质量”这个笼统的说法下,而测试本身是什么呢?今天我们就测试本身跟大家一起讨论。
测试是在研发产品的整个过程中的一个跟踪活动,他在各个阶段报告给人们当前项目的状况,能够督促和提示项目经理或者高层经理对项目的关注点.
国内的测试的定义,一般是在产品的研发后期,对产品的功能进行验证的一个系列活动。
国外的测试已经发展比较成型了,而国内的测试现在还处于摸索阶段,至于超着那个方向去发展,我觉得大家目前还是处于比较迷茫的阶段。
        主要原因是:国内软件产业起步晚,而且质量意识不强,造成了软件工业发展缓慢,配套行业(测试发展缓慢),我觉得这个很正常,因为从人类历史发展的角度来看,这个是必须经历的阶段,从有这个概念到摸索,目前国内的测试应该处于沉思期,主要是没有一个全套的指导思想,另外一个原因是行业发展方向不明朗。
国内存在对测试的误解,所以造成了测试现在成了大家进入企业的跳板,要么就是觉得自己的能力还不够,目前只能从事测试,要么就没有编写程序的能力,但是同类产品比较了解,所以做测试。
       我对这个问题我有自己的看法,我觉得在企业发展的同时,个人要发展,那么个人怎么发展呢?(我说的是测试人员),在国内,对应的测试的技术总结的相对很少,并且现在国内的企业测试都是把测试过同类产品当成了经验。我个人觉得这并不是错,但是我个人觉得有点偏颇。因为真正从事测试行业的人都知道,测试是需要一定的技术功底的,在国内虽然对测试这么要求,是因为国内的大环境有质量的意识形态所导致,对质量的意识还只是停留在理解和使用上,不是从设计或者原理或者其他方面保证质量的。如果我们说对测试的定义是对某类产品的经验上,那么这个人是对和他合作过的程序员和设计师比较了解,而且能够总结出来某些人在那些方便容易出错,但是当更换环境以后,这些经验是否还能有用呢?
如果我们把测试的方法整理成技术,那么他形成一个规则或者说是一个标尺,我们只是分析什么样产品的需要用什么方法来测试,而且需要了解的知识架构是什么?怎么把这些知识穿插起来,那么积累就不会被约束,但是不能撇开经验,因为经验本身是设计出好的案例的基础,但不是唯一的基础。
              我们再来看看测试案例的设计,测试案例的设计在国内现在是一些刚刚入行的不会写程序或者程序功底比较差的人在写案例,那么这些人设计出来的案例只是包含了整个测试过程中功能测试的一部分案例而已,因为他们不懂得或者不理解程序,不是从原理上去分析产品,不是从逻辑上去分析产品,而是从用户使用的角度去分析产品,这样设计出来的案例的可行性和可信度多大呢?大家可想而知了。所以我们在整个引导大家的过程中,从技术和方法,结合具体实例和针对不同类型的产品的测试方法进行跟踪和描述。    
首先,什么叫测试?测试干什么?
测试,是在开发过程中的一种活动,它是分白盒测试和黑盒测试。在不同的阶段不同的人所承担着测试这个角色,我们把整个活动统称为测试。
测试的工作内容主要包含了设计测试计划,设计测试案例,执行测试,进行测试总结。
执行测试是在产品开发的整个过程中进行的,包括了单元测试,系统测试,集成测试,系统测试和验收测试,那么不同的阶段测试的重点不同。
单元测试的重点是函数级,包括需求,包括算法,包括接口预留等内容。
集成测试是指把小模块结合起来,测试的重点是输入输出数据,参数的处理,错误预处理,接口规范,参数约束等测试内容。
系统测试的重点是功能性质,它的测试重点是按照需求来对照测试, 主要是功能实现的情况,包括功能使用逻辑和操作逻辑,操作系统,兼容性(软件和硬件)等内容。
验收测试,主要是合同性质而言的,在国外现在软件外包情况比较多,那么双方按照合同规定履行自己的职责,把功能按照合同约定的形式条条比对。这是主要方面,那么在企业内部,验收测试是除了功能验收以外,还包括易用性,软件的亲和度等方面的内容。
测试市场情况给大家做一个简单介绍,使得大家无论是从发展还是从市场方面,充分感受到测试行业的潜力。
在设计和编码软件外包领域,一些中国软件外包企业已经与印度同行展开了短兵相接的较量,但是经常感到对手的功力深厚,而自己略显步履蹒跚。与此同时,另一些中国软件外包企业暗渡陈仓,另辟蹊径,从为客户提供多语言、多形式的软件外包测试服务做起,近两年在日本、美国和欧洲等全球主要外包市场不断攻城掠寨,探索出了一条软件外包服务的新路。正所谓“外包测试,风景这边独好”。
   避免正面竞争
   2005年全球和中国的软件外包继续呈现高速发展的态势。CCID的数据显示,到2009年,中国软件外包市场的规模将达到45.60亿美元。
根据赛迪顾问数据统计,在2005年中国软件外包服务发包市场结构中,日本、美国、欧洲等地区的市场比例如图2所示。预计2005~2009年,随着中国对欧美软件外包市场开拓力度的加大,美国发到中国的软件外包项目市场规模年复合增长率将高达50.5%,欧洲为50.2%;日本市场则相对稍低,为48.7%。
基于上述的数据资料,目前我国软件外包服务的现状可以归结为:在日本市场的外包优势较为明显,在欧美市场实现了局部突破,但是要占据更大的份额仍然任重道远。
   尽管我国软件外包在日本外包市场取得了显著成功,但是日本的软件外包项目通常报价较低,而且日本软件规模不大,只占全球的10%。占全球65%且外包利润丰厚的美国市场却被印度所控制。我国要想在欧美等高端外包市场取得实质性突破,关键是深入研究外包服务的内容特征,充分发挥我们的技术和市场优势,尽量避免与印度和爱尔兰等正面竞争,从而吸引更多的欧美外包客户发包到中国市场。
   最佳切入点
   随着软件全球化竞争的日益加剧,客户对软件质量的要求水涨船高。为了提高软件质量,降低软件开发成本,分散软件外包风险,软件测试外包成为发展迅速的分支之一。
   据资料显示,国外大型软件测试已经占整个软件项目成本的40%以上,因此软件测试外包服务的收入非常可观。软件测试是人员规模化和密集型技术工作,软件测试和软件开发人员的最佳比例应该是1∶1左右,而当前大多数软件公司都还是1∶8左右。
   我国具有众多的掌握软件技术的各类测试人才,已培养了近60万名软件专业人员,转行从事软件测试的社会人员每年都在增加,来自海外的留学生和国外大型软件公司的人数也呈增长态势。这种初、中、高级别的人力资源优势,加上市场优势和技术管理优势,为我国发展软件外包测试服务提供了坚实的基础,软件外包测试服务的发展潜力无限。
   深入分析软件外包测试的特点,软件外包测试包含了非常丰富的内容。从测试的软件类型看,它包含了操作系统、通用办公软件、垂直行业软件等的外包测试。我国已经成为全球最大的生产和制造中心,在行业软件中,以手机和家电嵌入式软件为代表的通信行业软件和汽车、电子行业的中间件的发展迅速,成为具有潜力的软件外包领域。
   当前欧美市场的外包软件大多数属于国际化软件。细分这些国际化软件外包测试的具体类型,包括软件核心功能特性测试、国际化测试和本地化测试。软件核心功能特性测试又分为单元测试、集成测试、系统测试和验收测试;国际化测试包括国际化能力测试和本地化能力测试;本地化测试包括本地化功能测试、用户界面测试和语言质量测试。由此可见,软件外包测试并不局限于单一英语软件的测试,而是多语种、多类型、多内容的立体外包测试。
   软件国际化的最高境界就是本地化。随着国际化和本地化需求的深入发展,大型国际化软件经常需要发布几十种语言的本地化版本,因此多语言的软件本地化测试具有较大的发展潜力。可喜的是,我国的一些软件本地化公司凭借10年前为美国软件公司(例如微软和IBM等)提供中文软件本地化服务,已经与客户形成了互相信赖的客户关系,完善了符合外包测试要求的技术流程,而且具有比较明显的外包价格优势,已经开始为美国软件客户同时提供十几种语言的软件本地化测试。
   软件本地化的要求之一就是为目标市场和最终用户“量身定做”软件功能,例如对于东亚和东南亚市场用户而言,软件必须能够支持双字节字符集的输入、显示和输出,这是软件本地化必需的功能之一。我国在处理双字节字符集的软件支持能力方面具有天然的优势,不但中文是我们的母语,而且我国与日本、韩国等一衣带水,国内有很多精通日语和韩语的语言人员,还有众多来自日、韩的留学生和工作人员,东亚区域语言优势非常明显。反观印度软件外包业,他们单纯以单字节字符英语作为外语,与我国相比具有天然的劣势,处理双字节字符集文字是他们的技术“短板”,这恰好是我们的长处。
   软件外包测试是投入回报率高而风险很低的服务领域,根据北京软件外包测试服务公司透露的信息,从事欧美大型软件公司的软件外包测试的净利润都在20%到35%左右,甚至更高。而面向国内市场的软件项目,由于国内不规范的价格竞争,国内软件企业的利润空间急剧缩小,甚至净利润下降到5%以下,已经威胁到国内软件公司的生存。
   探索我国软件外包产业的发展道路,必须分析国际软件外包的市场特点,发挥我们的技术和市场优势,找准在全球外包服务行业的自身定位,从某一个具有显著优势的外包领域入手,不断打造中国外包服务的品牌。因此,从技术定位角度考虑,虽然软件外包测试的技术含量不太高,但对现阶段的中国软件外包企业却是最适合的,可以在欧美日等全球市场率先实现全面突破。
   三个跨越
   对于准备承接软件外包服务的公司而言,要加入外包测试服务队伍,至少需要在三个方面实现跨越:提升国际客户信任度、完善外包测试业务流程、汇聚大量专业人才。
   第一个跨越是赢得国际软件客户的信赖。中国软件业在空间巨大、利润丰厚的欧美高端市场迟迟未能实现外包突破,几乎成了很多软件业人士永远的痛。目前在软件外包测试方面,中国软件外包服务公司已经率先取得突破,但要赢得更多全球客户的信赖,还需要不断探索和实践。
   第二个跨越是完善外包测试服务流程。现代外包测试几乎贯穿软件项目生命周期的各个环节,需要分布在世界各地的不同公司(软件开发公司、外包测试服务公司等)的人员组成一个项目团队,并进行有效交流。因此制订满足软件外包测试的科学流程并得到客户的认可,才能满足国际软件外包测试的要求。
   第三个跨越是汇聚大量外包专业人才。外包测试属于为客户提供技术和质量服务的中间环节,符合软件外包测试服务的各类人才包括软件测试工程师、测试组长、测试经理、高级管理人员等。尽管我国具有较多的初级测试技术人员,但是比较缺少精通技术,擅长管理,熟悉欧美市场,能与欧美客户有效沟通的高级专业外包人才,这需要软件企业和高校培养、引进和留住优秀高级专业人才。
 

我是一个充满激情的人,我把所有的激情投入到生活的每一个空间。
我是一个不停折腾的人,因为生活在不停的折腾我。
我是一个不服输的人,因为我知道这个社会不会同情弱者,只有不停的折腾,才有可能把握自己的命运。
我是一个傲慢的人,因为我把自己已经当成是行业的开拓者。
我是一个平和的人,因为我和不同的角色在对话
我是一个开放的人,我会将我知道的或者了解的用无私的信鸽传播
我把所有的精力给了我所爱的职业,让这个爱心浇灌下的花供大家欣赏的同时,能把爱心种子繁衍。
测试蓝本(初稿)
王振刚(2004-4-14)
 

测试的分类

       单元测试

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

       集成测试

       集成测试是在保证单元测试进行后进行的一个动作,能否集成的标志不是所有的代码编译通过了就算是可以集成了,而是所有的能够在这个虚拟环境下能够正常运转。
       在集成测试种一般采用的方法是数据驱动或者桩驱动,因为集成测试不能看到产品的表象,因为他是一些数据流的中间段,我们渴望能够对中间数据进行分析,就可以知道或者就渴望知道流程或者算法中有什么不妥当的地方。
       集成测试比较适合做成自动化测试,当然首先我们分析了适合做自动化的条件是满足的,我这里就不讲详细的方法,到后面的自动化测试介绍中,我会提到这个方面的问题。下面和大家一起揭开测试自动化的神秘面纱以及给大家讲一些构建冒烟的概念。
       冒烟测试的出处是,由于生活习惯等原因,人们会定期的做某个事情,就像人们会约定成俗的认为12:00是吃饭下班的时间。那个时候大家都会做饭,哈哈,自然会从烟囱冒烟。在软件行业里面的约定是当产品到达某个阶段之后,为了验证产品的各个部分的衔接程度,为了验证项目的进展程度,为了验证产品的(已完成)功能的全面稳定程度,由测试主导的一种测试方法,主要的操作就是,在产品开发计划定制完成以后,依照开发计划指定完整的编译计划,按照开发计划和编译计划,各个单位按照要求完成自己的作业,然后在编译点上验证完成程度。
       集成测试也是不可缺少的一个部分,很多单位为了赶进度,会将这个部分省略掉,就甩手给测试小组,如果没有对应的测试小组,就会是程序员进行简单的使用后就交付市场,危险,这是个定时炸弹。因为他时刻有可能产生市场对企业影响的额度,以及企业本身的声誉问题。
       集成测试是在单元测试完成后进行的测试环节中的一个测试,主要是测试各个模块和函数之间的相互衔接情况,互动情况,输入输出情况。所以集成测试也很重要。
       那么集成测试一般采用什么方法呢?集成测试一般采用桩驱动的方法,因为在单元测试我们检查的相对比较详细,那么在集成测试的重点其实要保证逻辑上了。我简单的介绍桩驱动的实现方法。
 

桩模块(函数)
在单元测试已经作过详细的测试
关联模块或者函数1
关联模块或者函数2
关联模块或者函数3
关联模块或者函数4
关联模块或者函数6
关联模块或者函数5

请大家看上面的图,这个一定是一个有意义的组合。是函数间形成一个简单的逻辑关系。
  从上面的图上我们可以看到,如果中间的模块或者函数是经过我们进行过详细的测试,基本上可以保证没有什么错误,那么如果这个逻辑出去,导致出错,一定是输入的过程或者接收了输出参数处理出错了。使得我们问题很好的定位。
       我们可以定义很多个桩,使得测试效率提高。
我们把上面的内容进行简单的总结:集成测试就是测试各个组件之间的配合情况。所以集成测试是为系统测试提供了一些基本保证,但是不要完全依赖。
采用的方法给大家介绍了,这样可以采用测试或者程序编码的形式实现测试。

       系统测试

       系统测试是测试过程中的一个转折点,因为在现在国内的企业中,不同的产品面对不同的用户群体,所以有的企业经过第三方产品的验收测试,有的企业则没有通过验收,而是一些工具类或者通用类的产品,那么他的验收测试是经过广大的用户群来做的,也就是说凡是通用类产品的系统测试必须严谨测试以后,才可以投放到市场。但是对于对企业或者其他专业性单位定制的产品我们必须进行验收测试。
        系统测试工作是一个重复老动很多的工作,需要在工作种把握几个重点,系统测试是保证系统能够正常运转,包括了功能,易用性,健壮性,压力,边界数值设定等各个方面的内容。要想在这个阶段的工作种找到乐趣,就要不停的摸索,找出能够将机器代替人的所有的东西,找工作的快感。
       系统测试需要有广泛的知识面,对测试工程师的要求需要了解和掌握很多方面的知识,需要了解问题可能出现的原因,已经出现这个问题可能是由于什么原因造成的,以便我们能够及时的补充测试案例,保证或者降低产推出的风险。
       目前软件测试行业发展还不成熟,大多数系统测试都在测试组做,而且测试组几乎到系统测试测试阶段才会接触到产品。我们也把系统测试简单的说明一下。
       目前系统测试基本上采用黑盒测试方法,而且基本上局限在手公测试上面。

被测试的软件

从上面简单的图形可以看出来,我们不知道被测试软件是怎么实现的,做了什么事情,我们只知道我们要它做什么,我们想得到什么,至于程序内部怎么实现,我们并不关心,我们只是关心结果。这是一种纯粹黑盒的测试。
        这个阶段是测试发现问题的主要阶段,最少从目前市场上的产品情况来看是这样的。在这个阶段60%的问题会暴露出来,如果不进行单元测试和集成测试,这个阶段的测试量和测试点很重要。
       黑盒测试的核心是需要找到测试的重点在那里?测试的切入点在那里。系统测试重复的工作量比较大,而且如果是一个大型的项目,涉及的内容相对比较多,而且如果组织不好,或者没有找到重点,需要一遍遍的重复。所以需要自动化测试的需要合理的设计,使得我们的重复工作尽量减少,以提高工作效率。
              其实系统测试在软件开发环节中不可缺少的一部份,这里的重点工作是如何提升自己的设计能力,在系统测试的或者说集成测试的时候,所有的对测试工作来说,都是一个挑战。那么如何提升我们自己的设计能力呢?推荐已往工作中的经验,积累的方法有几种,第一,把bug描述清楚,这个bug描述可能在大家看来就是步骤清晰,其实在我认为,描绘一个场景其实并不是那么简单,其中包含了营造环境,包含了bug出现的方法,彻底减少程序开发人员的猜测,这样就能够有足够的时间积累我们的技术;第二,描述bug后,能够根据现在bug的情况,做一个简单的分析,其中包含了现象,从结构上分析可能是什么原因,然后跟开发沟通,错不怕,怕的是不想;第三,设计合适的案例,现在有很多人一提起案例,就是遍历,把所有的功能或者数据遍历,在测试的角度和进度的角度几乎不可能的,那么如何才能设计发现问题的案例,使得案例有效呢?那就需要吃透整个设计的逻辑,然后设计出经典案例,否则劳神费功夫;第四,询问,我一直以为是最好的学习方法,当发现一个bug的时候,如果你能分析,并且能够让开发人员纠正或者从结构上帮助你把分析问题的着力点找到,那设计能力和效率也同样会提高。
        

       验收测试

       验收测试类似于客户验证产品的质量,在软件行业发展的过程中,各种承包项目类似于国外的外包项目将会不断的出现,那么外包项目的质量问题需要大家共同讨论。
       外包项目的操作流程是当承包方提出具体的需求,然后有承包商来按照需求来开发项目,包括单元测试,系统测试,集成测试等各个方面的测试,经过被承包商测试后的产品提交给外包商的时候,需要进行验收测试,验收测试可以是外包商本身提供一套测试方案,然后对照具体的需求,进行产品验证测试。也可以是双方找一个共同的第三方,进行产品的验证测试。
       验收测试的测试重点主要是产品是否按照需求开发的,而不从针对功能进行的测试。所以验收测试基本上不需要多少专业水平,也可以是承包商找到使用该产品的用户,来体验该产品是否能够满足使用要求。这样以来使得双方可以有一个共同的平台,避免商业矛盾的产生。
       验收测试的测试手段目前来说还是靠用户体验。对照合同的需求进行测试,是第三方按照双方达成的共识来跟踪和测试软件是否能达成的需求。

测试方法

       黑盒测试

       顾名思义,黑盒就是外面不知道盒子里面在作什么,怎么作,只知道我的输入他需要有反应,无论是正确的还是错误的,都需要有回馈信息。黑盒测试需要懂产品的使用方法,操作方法,把尽可能多的情况暴露出来,通过这种方法进行测试。
       黑盒测试的随机性比较大,在大部分案例执行完成以后,大概能够测试40%的功能,据美国一个官方的数据说,20%的问题是在开发过程中发现的,80%的问题是在系统测试和集成测试过程中发现的,其中80%的比例我们还是需要在细分,20%的是使用的问题,20%是程序的问题,5%逻辑问题,剩下的都是莫名其妙的问题,这样的数据对测试的一个引导是:要想发现更多的问题,需要更多的思考,更多的组合。这样无畏的增加了很多工作量,人们在疲惫的执行着测试案例,渴望从中发现新的问题。
       这样的案例设计思想使得我们在开发一个大型的产品或者延续性产品的时候,整个测试案例的延续性很差,重用性也很差。所以我们在这里需要纠正一个概念,黑盒测试不简单的使用,案例设计也不是无谓的组合。
       那么如何设计好的测试案例呢?如何在开发过程中很好的结合2/8原则呢?当前包括以后,不可能出现一个积极完美的产品,一个错误也没有,但是我们作为软件工程师,肯定渴望自己参与开发的产品稳定,易用,人们寄予无限的称赞,这是一种奢望,那么我们把这种奢望修改一下,就是渴望我们参与的产品,能够满足当前大多数人的需求,稳定是否更合理呢?      

       白盒测试

       白盒测试是一种高技能的测试,它是一种基于源代码下的测试,这种测试要求对程序的要求很高,需要了解程序的构架,具体需求,以及一些编写程序的技巧,能够检查一些程序规范,指针,变量,数组越界等问题,使得问题在前期就暴露出来。
       一般程序所容易犯的错误,没有定义变量,无效引用,野指针,超过数组下标,内存分配后没有删除等,无法调入循环体,函数本身没有析构,导致循环实效或者死循环.参数类型不匹配,调用系统的函数没有考虑到系统的兼容性等.
       白盒测试一般是以单元或者模块为基础的。目前的做法是把他归结为开发的范畴,用转人或者兼职的人去看代码或者利用部分工具,例如Rational系列,Boundchecker等工具,他们可以帮助人为的发现变量没有初始化,指针错误等。大大的减少了人力。
       我下面讲讲BoundChecker最实用的东西。
例如:我们发现一个现象:有个软件再Win98下运行不起来,或者总是出现莫名其妙的错误,再Win2000下或者更高系统下运行正常。
上面是一个现象,是我们再日常测试中经常遇到的现象,我们分析可能导致出错的原因:操作系统本身出错的原因,导致软件无法再此系统下运行,另外一个原因:软件中用到了某些函数不支持此操作系统。还有一个原因,软件运行的硬件环境再此系统下不能满足

       灰盒测试

       灰盒测试是介于黑盒测试和白盒测试之间的一种测试.这个阶段的测试重点是各个组件之间的逻辑,这个时期的测试重点是各个DLL文件的参数和逻辑是否正确,测试的重点是DLL本身.然后采用桩驱动,把各个DLL或者函数按照一定的逻辑串起来,达到在产品还没有界面的情况下能看到一种既定情况下的结果输出.
       灰盒测试的要求相对白盒测试来说要求相对较低,对测试案例的要求也相对较低,只要求能够检测DLL处理输入和输出的能力,异常情况下的处理而已.
       灰盒测试是处于部分代码的逻辑测试,需要验证程序接收和处理参数的能力,接收到参数后的判断条件的能力。灰盒测试的重点在于程序的处理能力和健壮性。包括逻辑处理和错误处理。
       灰盒测试重点在核心模块,他投入相对黑盒测试的时间少,而且从维护量上和产出比上比黑盒测试得出的数据更加有效,相对于白盒测试,他需要付出的要少,而且白盒测试需要一些功力比较深的人才能从根本上发现和解决问题,他的结果可能会影响到算法,发现问题快,而且从根本上发现,所以更彻底,灰盒测试有自己的优势,投入少,见效快。
       下面谈谈如何操作。
       需要先建立一个测试工程,在这个工程中,需要包含测试的工程文件,需要建立对应该工程的测试的cpp或者vb的文件,完成以后,先Load对应的测试文件,然后按照对应的调用方法和参数,输入相关的测试点,把输出的处理结果进行分析,作为处理后下一个接受方要处理的初始参数。
       下面我给大家提供一个我们所做的一个组件的测试案例设计表格,大家可以看这个表格理解,做组建测试都应该设计那些内容,测试的重点在哪里,对我们未来从事测试工作的人是一个参考。
IBatchDownloadExecutor
 
1) SetDownloadConfig(IDownloadConfig * pDownloadConfig)
 
输入/动作
期望的输出/相应
实际情况
(进程外)
实际情况
 
典型值…
CMyDownLoadConfig  myconfig
SetDownloadConfig( & myconfig);
程序无反映
程序无反映
程序无反映
异常值…
SetDownloadConfig( NULL);
程序无反映
程序无反映
程序无反映
 
2 SetVersionControler(IVersionControler * pVersionContro
输入/动作
期望的输出/相应
实际情况
(进程外)
实际情况
(进程外)
典型值…
IVersionControler* PVersionCrl;
GetTenioComponent(&PVersionCrl);
pDownload->SetVersionControler(PVersionCrl;);
程序无反映,正常
程序无反映,正常
程序无反映,正常
异常值…
SetVersionControler ( NULL);
程序无反映,正常
程序无反映,正常
程序无反映,正常
 
3) SetTaskID(int nTaskID) GetTaskID()同时测试
输入/动作
期望的输出/相应
实际情况
(进程外)
实际情况
 
典型值…
SetTaskID(5)
int a=pDownload->GetTaskID()
返回5
返回5
返回5
边界值
SetTaskID(0)
int a=pDownload->GetTaskID()
返回0
返回0
返回0
异常值…
SetTaskID(-10)
int a=pDownload->GetTaskID()
返回-10
返回-10
返回-10
 
4) SetResourceList(PREQUESTFILELIST pRequestFileList)
输入/动作
期望的输出/相应
实际情况
(进程外)
实际情况
典型值…
prequest->nFileCount=2;
strcpy(prequest->szServerFileNameList[0],"http://210.22.12.74/dlltest/ag.txt");
strcpy(prequest->szLocalFileNameList[0],"E:\\ag.txt");
strcpy(prequest->szServerFileNameList[1],"http://210.22.12.74/dlltest/aga.txt");
strcpy(prequest->szLocalFileNameList[1],"E:\\aga.txt");
程序正常,无反映
程序正常,无反映
程序正常,无反映
异常值…
NULL
程序正常,无反映
程序正常,无反映
程序正常,无反映
 
5) Execute()
 
输入/动作
期望的输出/相应
实际情况
(进程外)
实际情况
典型值…
用例1:在调用SetDownloadConfig ,SetResourceList ,SetVersionControler和SetTaskID进行正确设置之后,调用Execute();
提示下载成功
提示下载成功
提示下载成功
异常值…
1
分别用SetDownloadConfig ,SetResourceList ,SetVersionControler和SetTaskID进行错误的设置之后,调用Execute();
提示下载失败
提示下载失败
提示下载失败
2
对上上述用例,重复多次(即连续多次点击按纽)
提示下载失败
提示下载失败
大多数情况下提示失败, 有些情况下程序出错,
 
总结: 类 IBatchDownloadExecutor中, 除了再连续多次调用Execute()函数时候,程序会出错,其他接口测试都跟预期的结果相符合
 
       其实在现在的测试工作中,测试人员在想着各种方法,把测试思路从原来面对产品提前到面对一个公用的组件,这个使得后续的工作的风险会减少到最少。那么什么样的产品适宜做组件测试呢,我表述自己的观点。
       他们都有一下几个特点。
第一,  这个项目很复杂,但是单个组件功能相对独立,而且跟具体的业务不相关
第二,  这个项目周期长(1到2年)
第三,  独立组件的重用率非常高
第四,   
 
 

测试方面

       案例设计问题
       分析:因为现在从总体上看,案例设计很细,但是重复和不必要的东西太多了,个人认为原因有三个:
第二、       案例的设计没有一个反馈,涵盖情况不知
第三、       开发产品质量意识淡薄,测试压力太大
第四、       测试人员的素质分析没有,我们看不清问题出现在那里
进度问题
第一、       测试的整体计划里面没有重复考虑风险,时间问题紧迫
第二、       回归测试无法保证
结合开发模型,跟大家一起分析各个时期要作的时期

所有工作准备就绪,开始执行
需求
概要设计
详细设计
编码
通透的理解需求,补充开发此类产品测试所需要的知识和资料
开始设计测试案例,研讨测试方法
开始实施方法,进行测试前的准备和试验工作

大家可以看到这个图和一般的书本上描述的不太相同,这是我结合具体的业务来分析。

需求
阅读需求

怎么样阅读需求呢?
        我们在测试的时候,我们需要通篇的阅读需求,那么怎么阅读需求呢?需要了解什么内容呢?实际的可操作的在那里呢?
        我详细说我的认识,需求我们需要了解我们需要做什么类型的产品,这种产品需要什么样的基础知识,我们应该补充学习那些基础知识,市面上是否有同类型的或者相似的产品,他们曾经出了那些问题等,把自己先充实了,这是看需求的主要目的和重要目的。
       

测试改进方案

 
以上对存在的问题进行了分析,我们需要找到自己的弱项在那里,那么从现在看来,我们现在测试队伍没有建立,没有形成相应的体制。主要表现在一下几个方面:

测试工作需要回馈

 

回顾一,测试案例执行跟踪和统计不明确。
问题:如果测试案例不进行跟踪,无法证明或者检测我们案例设计的好坏,无法改进工作方法或者改善我们的思路,所以需要通过这里把自身问题看清楚,这样有利于工作的开展。
       在我们日常的生活中,存在这一种现象,因为这种现象导致了测试一些列的发展。大家普遍认为,测试的含金量不高,导致了测试工作就是一些不愿意做开发或者没有能力做开发的人来做,其二,他们对测试设计的测试案例从不认真的审查,认为就那么回事情。出现这种问题的愿意是由于开发还没有清楚的认识到测试是一个服务部门,是为他们服务的,从私利的角度来讲,我们抛开项目的关系,测试的主要工作是为了帮助开发将自己写的代码更实用一些,让市场更认可一些,让开发人员的成就感强一些。
如果大家都从这个角度考虑问题,那就可能缓解或者解决上面的第二个问题。
       关于测试含金量不高的说法,我不赞成这个说法,在目前国内的大环境下,测试是这样的,但是它在朝自己预想的发展。而开发的发展除了新的语言在发展以外,思想或者体系我们能增加或者能设想的空间已经不多了,而对于测试是一个全新的行业,他发展首先需要支持,需要理解,我相信国内测试在5~10年以后,发展更加迅猛。因为就算是现在很小的软件企业,已经开始重视测试了。
回顾二,测试需要和开发有共同语言
       当你开心或者兴奋的发现问题以后,你能告诉我这个问题发生的原因吗?当你发现问题以后,你能告诉我问题可能在那个环节发生的?你能告诉我类似于此类问题可能在那里还会发生。
       所以,当你进行测试的时候,渴望测试人员完全了解被测试对象的架构,然后针对此类软件需要补充基础知识,把自己补充起来,不至于开发人员给你讲任何事情,你不理解,或者很难理解,那么如果真的是这样,我对你个人设计的测试案例会打一个问号。
       靠自己的基础知识,详细拜读设计稿件,从设计稿件中如果能发现问题或者风险,你就有长足的进步了。
回顾三,补充测试案例
       我相信大家都有这个体会,在设计案例的过程中,大家想到这里,想到那里,总之想的很详细,但是在真正做测试工作的时候,总是发现一些bug与我们设计的测试案例无关。
       怎么会发生这样的事情呢?因为我们设计案例是寄予自己的经验和对软件的理解去设计案例,势必会造成这样的局面。现在我推进一种方法。就是在设计测试案例的时候,渴望每个人把自己负责的模块划个流程图出来,包括所有的出口和入口,包括信息流怎么流转的,如果把这张图形能够完全的划出来,说明你的理解要深一步,那么设计的案例含金量会高。
       案例的设计绝对不是堆砌,而是雕塑,因为案例设计的水平牵扯到很多方面的问题,第一,客户可能面临的问题,第二,如果规避这些问题,第三,执行的时间

测试工作需要总结

测试的总结机制没有
                                i.            测试案例的执行情况
                               ii.            测试案例发现问题情况
                              iii.            测试案例的冗余情况
                             iv.            测试周期内的曲线项目进展情况

需要交流平台和形式

信息交流平台和积累
                               v.            资源共享
                             vi.            信息共享
                            vii.            提高自己在开发中的信心,不要总是喊狼来了
                           viii.            人和人之间需要沟通和认同,团体也一样
  测试人员交流什么呢?
        在一个组织中,应该让所有的人熟悉每个模块的设计思路和测试思想,让每个设计的人告诉大家,宣讲出来,这样大家在看这块的时候,就知道那里容易出问题,出了那些问题。如果进行测试是最有效的,如果设计案例能抓住问题的核心。在设计阶段,如果把设计的案例给开发人员看看,能规避一些设计上的缺陷。
       在应该团体中大家都应该有共享的概念,我个人推荐的学习方法,是偷,我别人学了很多年的思想精华部分,在很短的时间内接受并吸收,这样会提高整个团队的素质。如果每个人都在共享,那么每个人都在进步,所以需要交流,包括思想,包括方法等。

采用的方法

让别人给服务说话,清楚认识自己

让开发人员说话,让对应开发人员给我们的测试案例提出相应的意见,保证测试案例的覆盖面,以把握重点。
在整个开发过程中,由需求,开发,测试完整的团队,准确的说还有市场部分,我们都把它归结为需求的搜索和定义部分。那么在整个产品研发的过程中,各个部分需要完整的配合,否则整个产品都不能按时上市。作为为开发和需求服务的测试部分,应该摆正自己的位置,我们是一个团队中的一部分,是不可以缺少的一部分。
人贵有自知,也难有自知。只有在认识自己的基础上才能选择好自己的生活道路。首先要认清自己的能力。人的能力可以有天壤之别,但只要不辜负自己这块材料,也就可以问心无愧了。认识自己尤忌自大,这会使你为自己订立高不可攀的奋斗目标,到头来高不成、低不就。其次要认识自己的本性。心理学家把人分成六个类型:经济型、理论型、社会型、审美型、宗教型和权力型。要选择一个适合自己本性的生活目标。
看清楚了自己,就可以很好的改善,也能把自己的事情做好,同时呢,才能更好的服务。

自己回头看

让执行测试案例的人员反馈给我们数据,说明案例的冗余情况,这样会慢慢提高自己的设计水平。
因为人们习惯于谈成绩,问题在成绩中可以淡化,我不同意此观点。
其实在现实生活中,大家都经历了很多事情,都学会了总结,可是同样的错误在现实中会多次出现,为什么呢?是因为回头了多次,没有总结,总结了没有执行,执行了没有改变方式,改变方式了但是没有认真考虑,还是错的。
把自己犯的错误列举出来,然后找出出现问题的真正原因,才是自己最大的进步。如果淡化错误,将来可能就会将成绩磨灭掉,所以积累,回头是工作中需要重视的问题。
还有一种论点,说公司多么多么重视开发,不重视测试,我对这种论调积极反感,这只是个人感觉。为什么这么说呢?
对公司来说,要靠项目和产品维持生存,对吗?从这个方面来说开发重要,产品质量不重要吗?这个问题很多人问我,我回答说,重要,非常重要,那为什么测试的价值体现不出来呢?主要是两个方面的原因,一个是公司引导不正确,各个部分的同事为这个项目负责,而不是开发为这个项目负责,其二呢,主要是因为我们是维护,而不是创造,如果你告诉老板,这个产品我们改变测试策略,能够提高工作效率,这个产品可以提前2个月发布,而且我保证质量。我相信你的价值也即体现出来了,如果不可以,说明还是没有找到合适的方法。

了解同类产品

让市场人员反馈同类产品的问题以及市场对我们产品的需求。测试过程是反映当前产品的质量,为什么要研究竞争对手的产品呢?
首先,测试中包含易用性测试,测试什么内容呢?就是测试怎么好用,客户是怎么用的,我们怎么设计更贴近用户,那么不研究竞争对手,我们怎么可能占领上风。
其次,了解竞争对手的产品,有利于测试工作捕捉重点,使得工作开展有利有节。
可谓知己知彼,百战不殆,所以在现在的市场竞争中,了解同类产品才可能发现对方的缺点,给以打击,发现对方的优点,快速学习,闭门造车必定失败。

提高自身素质

从程序的概念理解产品,这样测试案例可以设计的比较有针对性。
常言说得好,“识重于才”,而见识却往往是生活阅历造就的。对于一个初出茅庐的人,智者的指点是至关重要有时甚至是决定性的。回想我十年来的经历,很多失败其实是没有人指点而造成的。要寻找一个精神上的导师,他可以是你的父母,也可以是其他师长。他阅历丰富而又不拘泥于自己的老经验;他能在紧要关头给予你原则上的指导和精神上的支持。有时候仅仅是他失败的经验就会使你受益匪浅。

如何提高程序能力

耳濡目染

让开发或者设计人员在讨论开发方案的时候参与旁听,耳濡目染。其实这只是一种辅助的手段。
电视剧《霍元甲》播出以后,得到大家的欣赏。原因是因为他本人身体虚弱,所以父亲从小不让练武功,而生长在那样的环境中,他天天可以看到兄弟们在练功,招式已经记忆在心理,但是苦在没有练功的机会,他利用体力劳动的过程中,改变劳动方式,趁机练功,后来发展到独创“迷综拳”。
程序设计和开发是一个硬功夫,也是一个长远的事情,它是一个积累的过程,不能一蹴而就,需要苦心练,多些理解,多些思考。
面对程序开发,不要有太多的压力,因为程序开发就跟你学说话一样,因为语言本身有很多通性,高级语言和低级语言本质上差别不大,所以扎实的从基础的东西学起,这样才能完全的积累下来。
计算机发展速度很快,各种概念,各种语言发展都很快,掌握实质,不断学习,才能把握。所以还是需要多看,多想,多练。

自己练内功

从自身做起,了解程序架构和开发模式,努力提高理解和产品的单元测试或者组件测试能力,这样以来可以了解程序的很多算法,使得在产品的开发过程中就能把问题发现并且能够得到及时的解决。
其次能够提高大家参与到项目的荣誉感,因为在测试本身是一个服务性的行业,那么服务行业的特点是不停的改变思路,改变服务模式,提高服务质量,当服务做好了,那么在整个研发中就可以找到自己也是其中一个分子的感觉。
其三,练好内功,为自己将来提高工作效率,进行一些自动测试以及从程序架构的概念上设计测试案例提供了技术保障。
以上是自己练好内功的用途。
在过去社会中,有很多擂台赛,目的是切磋技艺,弘扬中华武术,各个门派直接交流和学习的过程,为了在擂台赛中取的很好的成绩,我们需要努力练功,其次是多学本门派和其他门派的武功,或者自创武功,在擂台上能够发挥的淋漓尽致,因为武功的最高境界就是没有招式,要达到这个境界,需要内功深厚,避免走火入魔,需要毅力,需要创新。
理论就是理论,无论在那里看到的理论都是一定的基础的,因为所有的理论基础需要一个证明此理论的平台或者条件,所有一定要看,想,用。看别人是怎么用的,在什么情况下用的,用的目的是解决什么问题,在什么样的环境下能够做出来,需要什么样的支撑;想自己现在目前是否有这个环境,就目前的环境能够做什么,如果要搭建对方的环境需要多长时间,这个做法中存在什么不托的地方,有什么需要改进的地方;在自己工作的环节中找找看,看自己是否适合用这个东西,如果适合,怎么用,用到什么程度,如果非常认可别人的做法,需要衡量需要多少资源和时间,努力找自己的结合点。
千万不要再我们看到一个理论或者方法的时候就去推动它,或者原理实践过一个什么思想就想在新的环境下实践他,都是不可取的。好的事情或者好的做事方式他需要一些条件支撑,一旦硬套,就可能出现问题。

实践中检验

尝试做一些灰盒测试部分(目前暂时是想法,但是还不完善)。灰盒测试是界与白盒测试和黑盒测试之间的一种临街状态。

测试发展

测试在国内还是处于摸索阶段,在过去的发展阶段,大家只是初步针对不同的软件产生了不同的测试方式,但在操作方法,操作流程等方面还需要继续摸索。对潜入式软件来说,行业内始终认为潜入式软件是最难进行测试的,因为他需要很广的知识面,需要对各个点的设计原理进行分析和测试。
在目前国内开发眼中的测试还没有形成概念,我们需要不断的改变形象,加深他们对测试的印象,以便我们获取更多的帮助和协助。
测试未来发展需要两条腿走路,这样能够在各个环节保证产品的质量。
第一步,系统测试继续练内功,将案例设计的能力提高
第二步,需要进行灰盒测试,对产品进行代码级的测试
第三步,需要进行部分白盒测试或者由开发人员进行执行
要达到一定的认同和发展,测试人员需要努力学习,打下扎实基础,这样才能一步步的成功.

如何提高测试

       提高测试需要从几个方面着手,其实只是自己的一些感觉,不一定就需要按部就班,需要找自己适合的点。

       制定完备的测试计划

              清楚的认识测试计划,测试计划是一个文档,能够保证整个研发过程中顺利执行的一个指导性文档,它描述了几个方面的问题。
第一、  描述了项目的目的
第二、  描述了项目的开发周期
第三、  描述了在测试中遇到的技术
第四、  描述了测试案例的设计周期
第五、  描述测试案例的执行周期
第六、  描述了测试过程中用到的工具或者技术
第七、  描述了测试过程中用到的资源情况
第八、  描述了测试过程中可能遇到的风险以及规避方法

提高案例设计水平    

       明确了解现在目前流行切实用的几种案例设计的方法,因为在不同的产品不同的要求有不同的设计手段,我们需要不断的学习和总结,在为了测试领域中,许多新鲜的词语都会出现。
       这种方法类似与工业领域的随即抽取统计分析法,但是工业性质牵扯到损坏或者人为原因,统计出来存在这偏差,但是应用与软件方面,虽然存在着偏差,但是不可能象硬件那么偏差很高。

       等效法

       明确测试的目标,一般适合用到的范围是,制定被测试的对象是在满足某个条件的区间内的所有的所有数据。
案例设计方法:从其中区间数据段中选择任意一个或者两个数据,只要这个数据满足了,那么其他的数据就是满足的。
我现在举一些例子,来说明等效法在测试过程中如何应用的。
范例1:在登陆某系统需要验证用户名,要求是长度是最小是6位,最长是14位,名字中可以包含数字,但是不能以数字开头,可以包含各种符号,不能包含中文。
1、随意字母组合成一个12位的姓名,测试是否可以通过验证。
2.、随意生成一个长度12位的姓名,测试是否可以通过验证
3、测试以任意一个数字打头12位的姓名,测试是否可以通过验证
4、测试姓名长度位12位且包含中文情况,测试是否可以通过验证
5、测试长度不满足条件情况下,是否通过验证
6、如果长度不满足,是以数字开头的,提示信息验证
7、如果长度不满足,姓名中包含中文的,提示信息验证
                     ………….
(注:)这个可能比较简单,但是说明一个问题:为什么随意生成一个12位姓名的,其实你选择8位姓名长度或者10位姓名长度是一样的,所以这种情况下考虑采用等效方法比较合适。
范例2:有这么一个需求,要求选择1~12之间进行调整,手机的背光就会随着数值的变化而变化。总体的是数值越大越暗。
以上需求是大家经常可以看到的。
测试案例设计:清晰记忆1的情况,然后随意调整一个数值,因为要求是变化了,至于变化成什么样子,变暗到什么程度才正确,没有明确的指标数值,所以只需要记住临街点1的情况,然后随意调整一个数据,然后和当前调整后的数据进行比较。
(注:)没有明确的说明,只是含糊的结果,但是总体的结果是在变化,那么这个时候比较适合使用等效法。

因果分析法

       需要有一定的程序基础,了解程序的架构,就是当问题发生以后,能够有效的补充相关的案例或者筛选相关的案例。因果分析的核心是从自己的理解去分析问题所在的真正原因。
       范例1:删除磁盘上某个文件失败,分析原因:如果是管理员权限,那么可以随意删除,无论这个文件的属性是只读的还是存档的,那么如果不能删除磁盘文件,除非是坏道上的文件。分析完成以后,使得测试案例设计有针对性,而不是盲目的将所有的文件格式都去尝试一次。
       范例2假设我们用Excel作一个计算,结果和我们用计算器计算的结果不同。
       分析:Excel的计算函数单独运算没有错误,然后插入一行,结果错误了,说明插入行导致计算错误,那么插入一行怎么会引起函数计算错误呢?原因是由于插入行后,导致传给计算函数的区域没有更新,所以造成计算结果错误,那么这个Bug就很明确了。
       范例3:假设我们平常在做讲座的时候发现在某台机器上就会死机。这是一种现象。
       分析:为什么在这台机器上死,在其他机器上不死。原因有两个,第一个先找系统原因,是否是我们的产品在当前这个系统下有Bug,经过验证没有,那问题出在那里?
       其实演示产品需要的是硬件的支持,那就是显卡,如果显卡内存不够大,可能导致某些演示文件死。
(注)因果分析需要有广泛的知识面,使得我们在分析的时候能够拓宽面积,模糊的定位问题。
范例4:用户给我发送一个文件,打印的时候发现是乱码。后来逼迫无奈,就让用户将这个文件传真给我。这是现象。
分析:为什么打印出现乱码?问题基本定位,系统字库不够,系统下打印驱动问题,打印虚拟内存问题,操作系统问题,软件本身问题?最后问题经过验证,最终归结为在此操作系统下,打印驱动程序有问题,使得文件不能正常打印。
(注:问题需要先框定范围,不要乱了套路。)

       逻辑分析法

       在逻辑分析方面,也需要有一定的程序理解能力。从程序逻辑和日常常识去判断问题。逻辑分析法其实就一堆假设的罗列,推论出系列结果的假设,然后将假设反推翻,问题就可以暴露出来。无论那种方法都是通过表现去分析问题的实质的。
范例1:我们在做MP3播放器快进和快退测试中,要考虑的同步问题,就是我们液晶显示屏上出现的歌词进度,时间进度和我们耳朵听到的进度不同。我们分析一下,为什么出现不同步现象,为什么其他的能同步,就某一个或者某几个不能同步。
       首先我们了解同步的算法:快进和快退是按照当前歌曲的数据流来计算应该到那里,它是以当前歌曲的数据流为系数,然后进行的一些调整,那么出现不同步的原因是由于系数不同造成的,所以考虑到同步问题,我们需要找不同格式不同数据流的歌曲,这样问题容易暴露,容易清楚的定位问题的真正原因。
       范例2
       我们来分析网络游戏中的交易系统,就是在游戏两个人进行物品和金钱的交易。
       怎么设计这里的案例呢?我们先梳理一下交易的逻辑关系图。
我们一起来分析下面的逻辑关系图,在玩家进行交易之前,数据库中记录了两个玩家各自的数据,然后玩家A向玩家B发送请求,当玩家B不同意的情况下,检查各自的物品个数就可以了,这种测试相对比较简单。下面我们分析当玩家B同意的情况下的测试重点在那里?
第一.当B同意和A进行交易的情况下,A从自己的物品箱中拿出物品,拖放到B的物品箱中,那么A和B在还没有

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14780873/viewspace-531802/,如需转载,请注明出处,否则将追究法律责任。

下一篇: 单元测试浅析
请登录后发表评论 登录
全部评论