测试基础二

测试的分类       单元测试       单元测试是在测试过程中的最小粒度，它在执行的过程中紧密的依照程序框架对产品的函数和模块进行测试，包含入库和出口的参数，输入和输出信息，错误处理信息，部分边界数值测试。
       这个部分的测试工作在国内现在是开发人员进行的。我相信未来的发展应该是测试工程师来做这个事情。那么需要测试人员需要深刻的理解程序，理解需求，理解设计，这样才能发现问题。
       还有一种在国内先在操作的方法，就是当一个模块给某个开发工程师以后，需要他给大家讲解他要完成这个模块或者函数的整体流程和思路，进行统一评审，使得问题能够暴露的更充分些，这样做的目的有以下个，第一，使得大家对设计者的思路明晰的理解，以便以后调用或者配合的时候能够真切的提出需求或者相对完美配合。第二，在评审的过程中，如果发现问题，那么大家可能没有犯过，这样就会更加提高警惕，如果犯过，就会回想当时自己怎么解决的或者规避的，使得大家能够在错误的过程中快速提高。第三，可以对平常犯错误进行一个积累，我觉得这是生动的教科书，可以使得新的人员在新上手的时候遇到这样的问题以后，我们就可以给他一个解决问题的方法或者方向。
       回顾，我们上面给大家介绍了两种方法，第一种就是通过在开发的过程种进行测试，由开发（测试）工程师写测试代码，对所编写的函数或者模块进行测试，第二种就是通过代码互评发现问题，将问题进行积累，形成知识积累库，以便使得新人在同样的方面不至于再犯错误。
       单元测试非常重要，因为他影响的范围和宽度比较大，也许由于一个函数或者参数问题，造成后面暴露出很多表象问题出现。而且如果单元测试做不好，使得集成测试或者后面系统测试的压力很大，而且项目的费用和进度可能就会飚升。
       对单元测试，现在用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年）
第三，  独立组件的重用率非常高