测试现在被普遍认为“保证产品质量”这个笼统的说法下，而测试本身是什么呢？今天我们就测试本身跟大家一起讨论。
测试是在研发产品的整个过程中的一个跟踪活动,他在各个阶段报告给人们当前项目的状况,能够督促和提示项目经理或者高层经理对项目的关注点.
国内的测试的定义,一般是在产品的研发后期,对产品的功能进行验证的一个系列活动。
国外的测试已经发展比较成型了，而国内的测试现在还处于摸索阶段，至于超着那个方向去发展，我觉得大家目前还是处于比较迷茫的阶段。
主要原因是：国内软件产业起步晚，而且质量意识不强，造成了软件工业发展缓慢，配套行业（测试发展缓慢），我觉得这个很正常，因为从人类历史发展的角度来看，这个是必须经历的阶段，从有这个概念到摸索，目前国内的测试应该处于沉思期，主要是没有一个全套的指导思想，另外一个原因是行业发展方向不明朗。
国内存在对测试的误解，所以造成了测试现在成了大家进入企业的跳板，要么就是觉得自己的能力还不够，目前只能从事测试，要么就没有编写程序的能力，但是同类产品比较了解，所以做测试。
如果我们把测试的方法整理成技术，那么他形成一个规则或者说是一个标尺，我们只是分析什么样产品的需要用什么方法来测试，而且需要了解的知识架构是什么？怎么把这些知识穿插起来，那么积累就不会被约束，但是不能撇开经验，因为经验本身是设计出好的案例的基础，但不是唯一的基础。
我们再来看看测试案例的设计，测试案例的设计在国内现在是一些刚刚入行的不会写程序或者程序功底比较差的人在写案例，那么这些人设计出来的案例只是包含了整个测试过程中功能测试的一部分案例而已，因为他们不懂得或者不理解程序，不是从原理上去分析产品，不是从逻辑上去分析产品，而是从用户使用的角度去分析产品，这样设计出来的案例的可行性和可信度多大呢？大家可想而知了。所以我们在整个引导大家的过程中，从技术和方法，结合具体实例和针对不同类型的产品的测试方法进行跟踪和描述。
首先，什么叫测试？测试干什么？
测试，是在开发过程中的一种活动，它是分白盒测试和黑盒测试。在不同的阶段不同的人所承担着测试这个角色，我们把整个活动统称为测试。
测试的工作内容主要包含了设计测试计划，设计测试案例，执行测试，进行测试总结。
执行测试是在产品开发的整个过程中进行的，包括了单元测试，系统测试，集成测试，系统测试和验收测试，那么不同的阶段测试的重点不同。
单元测试的重点是函数级，包括需求，包括算法，包括接口预留等内容。
集成测试是指把小模块结合起来，测试的重点是输入输出数据，参数的处理，错误预处理，接口规范，参数约束等测试内容。
系统测试的重点是功能性质，它的测试重点是按照需求来对照测试， 主要是功能实现的情况，包括功能使用逻辑和操作逻辑，操作系统，兼容性（软件和硬件）等内容。
验收测试，主要是合同性质而言的，在国外现在软件外包情况比较多，那么双方按照合同规定履行自己的职责，把功能按照合同约定的形式条条比对。这是主要方面，那么在企业内部，验收测试是除了功能验收以外，还包括易用性，软件的亲和度等方面的内容。
测试的分类
单元测试
单元测试是在测试过程中的最小粒度，它在执行的过程中紧密的依照程序框架对产品的函数和模块进行测试，包含入库和出口的参数，输入和输出信息，错误处理信息，部分边界数值测试。
这个部分的测试工作在国内现在是开发人员进行的。我相信未来的发展应该是测试工程师来做这个事情。那么需要测试人员需要深刻的理解程序，理解需求，理解设计，这样才能发现问题。
还有一种在国内先在操作的方法，就是当一个模块给某个开发工程师以后，需要他给大家讲解他要完成这个模块或者函数的整体流程和思路，进行统一评审，使得问题能够暴露的更充分些，这样做的目的有以下个。
第一，使得大家对设计者的思路明晰的理解，以便以后调用或者配合的时候能够真切的提出需求或者相对完美配合。
第二，在评审的过程中，如果发现问题，那么大家可能没有犯过，这样就会更加提高警惕，如果犯过，就会回想当时自己怎么解决的或者规避的，使得大家能够在错误的过程中快速提高。
第三，可以对平常犯错误进行一个积累，我觉得这是生动的教科书，可以使得新的人员在新上手的时候遇到这样的问题以后，我们就可以给他一个解决问题的方法或者方向。
回顾，我们上面给大家介绍了两种方法，第一种就是通过在开发的过程种进行测试，由开发（测试）工程师写测试代码，对所编写的函数或者模块进行测试，第二种就是通过代码互评发现问题，将问题进行积累，形成知识积累库，以便使得新人在同样的方面不至于再犯错误。
单元测试非常重要，因为他影响的范围和宽度比较大，也许由于一个函数或者参数问题，造成后面暴露出很多表象问题出现。而且如果单元测试做不好，使得集成测试或者后面系统测试的压力很大，而且项目的费用和进度可能就会飚升。
对单元测试，现在用CPPUnit的比较多，市场上也有其他对应的产品，他们在不同的软件单位不同的阶段。正确的理解单元测试的重要性是意识，需要在过程改进种不停的总结，慢慢的积累，将质量意识渗透到整个开放过程中的各个环节。
保证单元测试顺利进行，需要渗透软件工程的很多思想，把CMM和跟踪机制建立起来，问题的分类、跟踪，如果把软件环节整个活动都渗透了，那么产品质量的意识自然就增强了。
COM思想现在在大的项目现在体现的淋漓尽致，因为如果不采用COM机制，维护和升级以及修改测试的成本很大，所以现在大型项目基本上都采用COM的组织形式。
说了这么多，单元测试做什么呢？单元测试主要是做一下几个事情：
第1， 模块或者函数的设计稿
第2， 代码规范，其中包含代码书写规范，对齐方式
第3， 代码的注释。非常重要
第4， 参数类型，数据长度,指针，数组长度大小
第5， 输入输出参数和结果
第6， 创建对象后是否删除了，如果在这里没有删除，请注明在那里删除
第7， 是否应用了没有初试化的变量，如果是，请指明该变量在那里初始化
第8， 变量是否声明，声明是否按照要求进行
第9， 调用此函数需要的满足条件需要注明
第10， 在此函数或者模块中用到了系统或者其他第三方插件函数，需要满足的系统条件
上面我只是列举了一些在测试过程中发现或者隐藏的问题，我想可能还有很多情况引发问题，请大家补充，以便在工作中有操作性。
集成测试
集成测试是在保证单元测试进行后进行的一个动作，能否集成的标志不是所有的代码编译通过了就算是可以集成了，而是所有的能够在这个虚拟环境下能够正常运转。
在集成测试种一般采用的方法是数据驱动或者桩驱动，因为集成测试不能看到产品的表象，因为他是一些数据流的中间段，我们渴望能够对中间数据进行分析，就可以知道或者就渴望知道流程或者算法中有什么不妥当的地方。
集成测试比较适合做成自动化测试，当然首先我们分析了适合做自动化的条件是满足的，我这里就不讲详细的方法，到后面的自动化测试介绍中，我会提到这个方面的问题。下面和大家一起揭开测试自动化的神秘面纱以及给大家讲一些构建冒烟的概念。
冒烟测试的出处是，由于生活习惯等原因，人们会定期的做某个事情，就像人们会约定成俗的认为12:00是吃饭下班的时间。那个时候大家都会做饭，哈哈，自然会从烟囱冒烟。
在软件行业里面的约定是当产品到达某个阶段之后，为了验证产品的各个部分的衔接程度，为了验证项目的进展程度，为了验证产品的（已完成）功能的全面稳定程度，由测试主导的一种测试方法，主要的操作就是，在产品开发计划定制完成以后，依照开发计划指定完整的编译计划，按照开发计划和编译计划，各个单位按照要求完成自己的作业，然后在编译点上验证完成程度。
集成测试也是不可缺少的一个部分，很多单位为了赶进度，会将这个部分省略掉，就甩手给测试小组，如果没有对应的测试小组，就会是程序员进行简单的使用后就交付市场，危险，这是个定时炸弹。因为他时刻有可能产生市场对企业影响的额度，以及企业本身的声誉问题。
集成测试是在单元测试完成后进行的测试环节中的一个测试，主要是测试各个模块和函数之间的相互衔接情况，互动情况，输入输出情况。所以集成测试也很重要。
那么集成测试一般采用什么方法呢？集成测试一般采用桩驱动的方法，因为在单元测试我们检查的相对比较详细，那么在集成测试的重点其实要保证逻辑上了。我简单的介绍桩驱动的实现方法。
我们可以定义很多个桩，使得测试效率提高。
我们把上面的内容进行简单的总结：集成测试就是测试各个组件之间的配合情况。所以集成测试是为系统测试提供了一些基本保证，但是不要完全依赖。
采用的方法给大家介绍了，这样可以采用测试或者程序编码的形式实现测试。
系统测试
系统测试是测试过程中的一个转折点，因为在现在国内的企业中，不同的产品面对不同的用户群体，所以有的企业经过第三方产品的验收测试，有的企业则没有通过验收，而是一些工具类或者通用类的产品，那么他的验收测试是经过广大的用户群来做的，也就是说凡是通用类产品的系统测试必须严谨测试以后，才可以投放到市场。但是对于对企业或者其他专业性单位定制的产品我们必须进行验收测试。
系统测试工作是一个重复老动很多的工作，需要在工作种把握几个重点，系统测试是保证系统能够正常运转，包括了功能，易用性，健壮性，压力，边界数值设定等各个方面的内容。要想在这个阶段的工作种找到乐趣，就要不停的摸索，找出能够将机器代替人的所有的东西，找工作的快感。
系统测试需要有广泛的知识面，对测试工程师的要求需要了解和掌握很多方面的知识，需要了解问题可能出现的原因，已经出现这个问题可能是由于什么原因造成的，以便我们能够及时的补充测试案例，保证或者降低产推出的风险。
目前软件测试行业发展还不成熟，大多数系统测试都在测试组做，而且测试组几乎到系统测试测试阶段才会接触到产品。我们也把系统测试简单的说明一下。
目前系统测试基本上采用黑盒测试方法，而且基本上局限在手公测试上面。
我们不知道被测试软件是怎么实现的，做了什么事情，我们只知道我们要它做什么，我们想得到什么，至于程序内部怎么实现，我们并不关心，我们只是关心结果。这是一种纯粹黑盒的测试。
这个阶段是测试发现问题的主要阶段，最少从目前市场上的产品情况来看是这样的。在这个阶段60%的问题会暴露出来，如果不进行单元测试和集成测试，这个阶段的测试量和测试点很重要。
黑盒测试的核心是需要找到测试的重点在那里？测试的切入点在那里。系统测试重复的工作量比较大，而且如果是一个大型的项目，涉及的内容相对比较多，而且如果组织不好，或者没有找到重点，需要一遍遍的重复。所以需要自动化测试的需要合理的设计，使得我们的重复工作尽量减少，以提高工作效率。
验收测试
验收测试类似于客户验证产品的质量，在软件行业发展的过程中，各种承包项目类似于国外的外包项目将会不断的出现，那么外包项目的质量问题需要大家共同讨论。
外包项目的操作流程是当承包方提出具体的需求，然后有承包商来按照需求来开发项目，包括单元测试，系统测试，集成测试等各个方面的测试，经过被承包商测试后的产品提交给外包商的时候，需要进行验收测试，验收测试可以是外包商本身提供一套测试方案，然后对照具体的需求，进行产品验证测试。也可以是双方找一个共同的第三方，进行产品的验证测试。
验收测试的测试重点主要是产品是否按照需求开发的，而不从针对功能进行的测试。所以验收测试基本上不需要多少专业水平，也可以是承包商找到使用该产品的用户，来体验该产品是否能够满足使用要求。这样以来使得双方可以有一个共同的平台，避免商业矛盾的产生。
验收测试的测试手段目前来说还是靠用户体验。对照合同的需求进行测试，是第三方按照双方达成的共识来跟踪和测试软件是否能达成的需求。
测试方法
黑盒测试
顾名思义，黑盒就是外面不知道盒子里面在作什么，怎么作，只知道我的输入他需要有反应，无论是正确的还是错误的，都需要有回馈信息。黑盒测试需要懂产品的使用方法，操作方法，把尽可能多的情况暴露出来，通过这种方法进行测试。
黑盒测试的随机性比较大，在大部分案例执行完成以后，大概能够测试40%的功能，据美国一个官方的数据说，20%的问题是在开发过程中发现的，80%的问题是在系统测试和集成测试过程中发现的，其中80%的比例我们还是需要在细分，20%的是使用的问题，20%是程序的问题，5%逻辑问题,剩下的都是莫名其妙的问题，这样的数据对测试的一个引导是：要想发现更多的问题，需要更多的思考，更多的组合。这样无畏的增加了很多工作量，人们在疲惫的执行着测试案例，渴望从中发现新的问题。
这样的案例设计思想使得我们在开发一个大型的产品或者延续性产品的时候，整个测试案例的延续性很差，重用性也很差。所以我们在这里需要纠正一个概念，黑盒测试不简单的使用，案例设计也不是无谓的组合。
那么如何设计好的测试案例呢？如何在开发过程中很好的结合2/8原则呢？当前包括以后，不可能出现一个积极完美的产品，一个错误也没有，但是我们作为软件工程师，肯定渴望自己参与开发的产品稳定，易用，人们寄予无限的称赞，这是一种奢望，那么我们把这种奢望修改一下，就是渴望我们参与的产品，能够满足当前大多数人的需求，稳定是否更合理呢？
白盒测试
白盒测试是一种高技能的测试，它是一种基于源代码下的测试，这种测试要求对程序的要求很高，需要了解程序的构架，具体需求，以及一些编写程序的技巧，能够检查一些程序规范，指针，变量，数组越界等问题，使得问题在前期就暴露出来。
一般程序所容易犯的错误,没有定义变量,无效引用,野指针,超过数组下标,内存分配后没有删除等,无法调入循环体,函数本身没有析构,导致循环实效或者死循环.参数类型不匹配,调用系统的函数没有考虑到系统的兼容性等.
白盒测试一般是以单元或者模块为基础的。目前的做法是把他归结为开发的范畴，用转人或者兼职的人去看代码或者利用部分工具，例如Rational系列，Boundchecker等工具，他们可以帮助人为的发现变量没有初始化，指针错误等。大大的减少了人力。
我下面讲讲BoundChecker最实用的东西。
例如：我们发现一个现象：有个软件再Win98下运行不起来，或者总是出现莫名其妙的错误，再Win2000下或者更高系统下运行正常。
上面是一个现象，是我们再日常测试中经常遇到的现象,我们分析可能导致出错的原因：操作系统本身出错的原因，导致软件无法再此系统下运行，另外一个原因：软件中用到了某些函数不支持此操作系统。还有一个原因，软件运行的硬件环境再此系统下不能满足
灰盒测试
灰盒测试是介于黑盒测试和白盒测试之间的一种测试.这个阶段的测试重点是各个组件之间的逻辑,这个时期的测试重点是各个DLL文件的参数和逻辑是否正确,测试的重点是DLL本身.然后采用桩驱动,把各个DLL或者函数按照一定的逻辑串起来,达到在产品还没有界面的情况下能看到一种既定情况下的结果输出.
灰盒测试的要求相对白盒测试来说要求相对较低,对测试案例的要求也相对较低,只要求能够检测DLL处理输入和输出的能力,异常情况下的处理而已.
