嵌入式软件的测试方法       手机软件测试       手机现在在社会上应用很广，同时针对手机上的功能增加也非常快，例如，蓝牙，例如，短信，例如，信息下载，手机游戏等，这说明在未来发展中，手机将人们带在一个孤独的社会中去。
       简单回想，我们的上辈人开始用手机，那是后简单的目的：就是通讯，而且还必须在既定范围内，价格高昂等，这些只有很富有的人才能染指的东西现在在社会中的每个角落都可能。放羊的。。。。
       那么手机软件怎么测试呢？测试什么呢？怎么组织呢？
       那么我做简单的分析：首先确定手机软件是嵌入式软件，那么我们抛开IC测试，抛开盲区，耐久性，耐碰撞性测试不提，就软件本身测试需要考虑的内容。
       我们说了这么多，我们整理出来手机软件测试的核心是数据的时效性，怎么理解呢？不能说我发了个短信，对方一天都无法收到？或者我打电话，对方没有任何反映，这就说明有问题。
       在例如，通过手机的红外线，能把地址薄中的资料传送的电脑中，如果在传送的过程中出错，或者对操作系统有要求，或者在传输的过程造成数据丢失，导出来的数据是无法识别的格式等，都会造成该功能无效。
       再如，手机信息的存储问题，因为手机本身有自己的系统，有自己处理信息的方式和格式，那就牵掣到的问题和外界信息交互的问题，外界需要了解其格式，阅读其格式，就需要和外界有比较信任的通讯。      
       其次，是测试本身的功能，例如，能够正常拨打电话，能够正常编辑信息，能够正常保存朋友电话，能够有历史记录，能够正常闹钟和各种设置，能够正常有提示信息等。
       我再举个例子，手机中游戏软件的测试，我们先了解手机中游戏开发语言Java，其次，由于手机中的内存大小优先，所以游戏的大小以及运行的各种指标都很小，所以用KJava。还有一个特点，手机中的游戏是回合制，所以类似的同步要求不是很高，所以测试重点就有所改变。
       那么像手机游戏的测试点在那里呢？了解这个方面的测试，需要了解几个问题，运营商对产品的要求：
运营商对开发商提出的要求，一般情况有这么几种。第一，应用程序的大小；第二，应用程序的命名规则；第三，应用程序版本控制规则；第四，明确提出所支持的机器的类型；第五，采用的编码格式UTF _8的编码还是其他的编码；第六，外部中断的处理逻辑；第七，比对压缩后的文件和先前文件的比较。
       上面我提出了手机软件测试的七个重点，下面我逐步添加详细介绍各个部分的细节。
第一，应用程序的大小。由于应用程序在被下载时百宝箱会根据需要插入5K的程序代码，因此要求SP提交的应用程序其大小不能超过手机最大下载尺寸减5K，下表列出了目前市场上部分JAVA手机对JAR文件下载的字节数限制情况（未列入机型请SP咨询手机厂家）

手机型号	最大可下载JAR文件大小	百宝箱限制JAR文件大小	备注
Nokia 60系列	无限制	无限制	目前由于WAP网关不能下载超过100K的JAR文件，因此对于WAP方式下载应用的手机（T720除外），百包箱限制JAR文件大小不能超过95K。
Nokia 40系列	64K	59K
Motorola T720	无限制	无限制
Motorola 388	无限制	无限制
Motorola 388C	无限制	无限制
Siemens 3118/2128/S57/M55	无限制	无限制
NEC N800	60K	55K

其次，由于应用程序在被下载时百宝箱会根据需要插入程序代码，这段代码在手机上执行时要占用10K左右的堆内存，因此要求SP提交的应用程序在运行时要预留至少10K的堆内存。
第二，应用程序的命名规则。应用程序的命名规则的字符长度不能超过12个字符长度，而且命名有一定的规则，需要SP和提供商商定，但是必须依照行业标准。另外，在提交的时候，需要了解一些要求，由于各个SP开发商开发环境，编译环境等问题，所以运营商都提出严格的打包要求。
SP递交应用程序打包要求：
1.    JDK使用1.3.1版本（国际版）；
2.    打包工具使用SUN公司提供的J2ME Wireless Toolkit (midp1.0版本，1.0.3或1.0.4)；
由于SUN公司的WTK只支持标准的midp1.0，不支持各手机扩展的API，需要SP对所使用的WTK进行扩充才可以支持手机扩展的API，方法是：将扩展API加到D:\WTK104\lib\midpapi.zip（假设WTK安装在D:\WTK104目录下）中即可。
3.    不做扰码或使用RetroGuard进行扰码，不得使用别的扰码工具。
说明：1. SP在开发时仍然可以使用原来的工具进行开发，但递交应用时请使用SUN公司的WTK进行打包；
2. 如果SP不按照要求进行打包，出现百宝箱不能识别API的情况时将按照测试未通过的情况处理。
第三，版本控制要求是，版本控制的格式x.x.x，应该严格遵守这个规则。
       MP3软件测试通用软件的测试方法       办公类产品测试办公类产品的延续性相对较长，所以部分模块有利于自动化测试。我在这里介绍办公类产品的测试重点在那里？
       办公类产品的特点是人们在办公中经常要用到，频率很高，所以简单，易用，方便操作容易理解成为办公类产品的首要要求。
       其次办公类产品考虑的机器的硬件配置，例如显卡，打印机等外设
       第三，办公类产品还需要测试兼容性，因为自身延续性长的特点。
       第四，办公类产品需要保证数据安全
       第五，办公类产品本身的功能逻辑
那么怎么才能做好办公类软件的测试呢？
       首先办公软件的核心是办公，日常生活中要用到，那么按照各种排版格式自己去排版就好了，在这个过程中详细得出一些结论：第一可操作性；第二，各个模块的使用逻辑，例如：在文件中插入对象，对象能否体现出来，设置对象的绕排方式，能否设置成功，能否体现，设置对象是否打印；第三，存盘，数据安全考虑，看存盘后对象是否保存，各种字体设置是否保存，绕排方式是否保存等。第四，兼容性，因为用户使用的办公类软件很多，需要文件共享兼容。其次是本身高低版本的兼容性，需要着重考虑。第五，文件大小和不同文件格式的存盘信息。第六，各种性能指标，包括启动速度，占用磁盘大小，在使用的过程中CPU的占有情况；第七，快捷键的设定和检查，不要和系统的快捷键冲突，并且支持系统的各种设置支持系统剪贴板功能；第八，支持网络传输，能够自由的通讯和共享，能够支持协同工作，能够充分体现修改数据的同步信息。
       杀毒类产品测试       杀毒类软件是一种工具类软件，随着网络的普及，杀毒软件也越发显得重要，那么杀毒软件的测试重点是：
       能够发现病毒
       操作系统检查
       能够正确的报告并且查杀病毒
       占有的CPU占有情况
       查杀病毒的内存使用情况  
       数据安全
       软件冲突
       病毒库升级
       自动更新      
那么在杀毒软件的时候，还有一个重要的东西，就是用户的数据安全，当杀毒软件能够清除含毒文件中的毒的时候，一定要包含用户文件的可靠性。
ERP软件的测试方法验证测试测试管理工作       我没有读过管理方面，只是看了一些书而已，在几个团队中应用，效果还可以，所以拿出来和大家交流。
       其实无论是开发管理和测试管理，其核心应该是“理”，如果理都不通，那么管只能是强制性质，那么在软件行业，创造性的企业中，可能不能维持的很久，所以需要先“理”清楚了，然后我们来管，到那个时候也就不用管了，因为理顺了，所以大家都知道该怎么样做，什么时候做了。
       那么谈到“理”，我们需要理什么呢？理事情，把要做的事情理清楚；理目标，把要达到的目的说清楚；理思路，把做事情的思路和方法理清楚；理资源，把合理的资源调配到合适的位置上，让兴趣和能力结合。我觉得从大的方面就需要先将这些事情理清楚了，才可能使得一个团队具有非常的战斗力。
       其次，还需要和善的沟通，做到无所不晓，因为在一个团队中，气氛非常重要，也许一个人的今天心情不好，造成跟他配合的几个人都无法工作顺心，也许是感应。所以需要和大家开诚布公，把能讲的问题，能讲的事情讲清楚，让大家觉得你可以依靠，可以把心思告诉你，你尽力为大家解决后患问题，让他们能够开心踏实的做事情。
       另外，需要换位思考，充分让大家提出意见，因为如果一个团队要发展，是需要大家一起努力的，这是大家都熟知的道理，但是做起来很难。避免一言堂，让大家充分参与到设计中，在其中找到自我的感觉，找到这里没有他是不可以的，这样每一个人才能关心项目的每一个角落，而不是为了工作而工作了。
       其二，需要在“理”的基础上帮助大家总结，大家在什么地方容易犯错误，犯什么类型的错误，犯错误的原因是由于我们的思想老化了，需要改进做事情的方式，还是由于工作能力或者经验的问题。那么就需要对各种错误进行统计，以找到问题的根本原因。就问题而讨论问题，问题的实质出在那里，然后帮大家改进，自己同时也会进步。 给大家讲我现实中的例子吧，我曾经带的一个测试组，大家做事情都很卖力，而且成绩也非常显著，但是在做的过程中总是会有问题发生，问题到底出在那里呢？后来找到了原因，就是由于工作环节中出现问题了，所以他总是在那里犯错误，因为他是把工作当成工作来做了，所以他就改这个地方，我后来找到他，也找到了问题的原因，一起把问题解决了。后来我就告诉他们，如果谁在同一个地方犯同样的错误，我们的结论是他不懂，教他，共同学习，直到他告诉我可以了；如果第二次犯错误，那么我们给的结果是，他忘记了，好再学，直到他告诉我，他可以了；第三次犯同样的错误，我们给的结论是故意犯错误的，那么就要全组请喝可乐一灌。
       这个例子在现实生活中很多，主要是引导，因为如果把工作当成工作来作，可能不会用“心”，因为如果是用“心”工作他会找窍门，会找方法，否则他会厌烦；如果把工作当成自己未来的事业来做，那么就会用心工作，这样就需要我们正确的引导。
开发方面
       开发分析       因为我们是第一次做MP3的产品，所以从技术上还处于摸索阶段，第二我们对产品的质量意识还存在一点问题，第三，四方沟通或者说回馈不够.
问题分析目前存在的问题进度问题       四方配合问题，因为在任何一家公司做嵌入式软件的企业，存在硬件、软件开发，市场开发，测试准备四个方面的组织需要开展工作，所以那个组织的进度耽误都会严重影响产品的发布周期，在现在竞争日益剧烈的市场中，必须把握市场机会，所以需要对进度进行把握。
       建议采用作战图的形式，对各个阶段点进行有利的把握，以给各个方面赢取更多的时间，明确职责范围，则权利的有利结合，激发各个方面的积极性。采用利益共同体的原则，将各个方面合理的结合，让开发关心测试工作，让测试关心开发工作，这样形成一个有利的整体，让市场及时反馈信息，使得项目顺利进展。
沟通问题       SPEC设计完成后，各个方面在限定的时间内做出反馈，以及时跟进，以便对产品有个明确的定位，各个方面对方案认可后，切实执行，如果出现技术问题，及时通知有关人士，以便进度和方案进行合理的修改和微调。在产品开发阶段，需要及时的总结可能遇到的问题和对问题的解决方案，通知相关人士，使得项目组的人有一种归宿感觉。
       开发需要给每个Bug做出合理的解释，或者对我们的测试人员进行相关培训，以便测试人员能够深切的理解产品，能够对产品进行合理严格的测试。
       这里提出一个建议,在测试人员提出Bug以后,知道表现,一定要弄清楚问题发生在那里,是什么导致这个Bug发生,才能有效的分析结构,有效的进行案例的补偿和测试.
跟踪问题       跟踪问题牵扯到Bug的跟踪和进度跟踪，Bug的跟踪需要一套流程，及时的出来Bug,使得发现Bug和解决问题形成一个完整的流程。
       进度跟踪的方法，建议采用阶段点产品，定义明确的时间点，明确各个时间点上完成的功能点，保证产品可以编译，可以抽查，可以运行以完成的相关功能。这样使得大家在各个时期能够看到大家都在进步，产品在进步，有利于整个团队的士气。
版本控制问题       定制严格的产品发布流程，降低由于时间问题，压缩测试时间，给产品发布带来的风险。建议采用的方法，由项目组定制编译计划，然后有相关人士进行讨论，各个方面达成共识之后，坚决执行。
       版本控制和进度控制密切相关。
       进行严格的代码管理，以保证公司机密资料，在代码Check in 和Check Out的时候建议由专人进行审核后方能入库，以免误操作或者敌意的操作造成代码冲刷。控制版本有几个好处和优点。
       关于Bug的回馈优点
第一、  开发方面回馈速度快
第二、  解决速度快
关于测试情况的总结
第一、  涵盖情况
第二、  Bug的质量问题
开发体系问题
第一、  设计的分析做吗？技术难度？设计的合理行，进度的可行性？
第二、  单元测试做了吗？
第三、  CVS的Check In控制了吗？
第四、  进度风险预估了吗？
第五、  进度控制如何进行的？

产品方面：
       产品分析：整个产品在开发前期，市场已经找到了市场切入点，但是在现在产品要发布了，我们不能或者说很难用一系列的数据做说明，告诉高层这个产品可以发布了或者说不能发布，因为分析的数据太少了。因为数据是说明问题的基础，但是现在定了产品发布的标准，只是一个现存数据，没有预估分析可能性，对产品投入市场可能存在风险。
       建议：
第一、  案例执行率
第二、  案例发现bug率
第三、  重复bug率
第四、  KLOC
第五、  产品日测试汇总图（察看历史曲线）

对产品研发整体改进思路

第一步、增强开发质量意识       做法：这个是个长远任务，但是我们可以做具体的事情，例如：检查开发单元测试情况或者单元测试代码等活动
       对设计的模块案例检查回馈情况，把质量和开发邦定，不要让测试单独承担这个压力。
活动方式：宣讲，制度，执行，邦定
第二步、增强测试本身素质       做法：因为测试不成型，这是现状，所以我们通过提供一些数据来提高案例设计的能力或者说告诉测试人员我们的缺陷在那里。这个是长远的事情，因为需要人力去做这个事情。提供如下数据：重复报告率，案例和Bug的比率等。加强程序概念的培训或者框架的了解，尽力从程序的概念上理解产品，尽量避免例冗余。
活动方式：培训，数据，比较
第三步、对产品开发过程中版本编译的控制       做法：CVS库权限控制，所有的Check in和Check out需要控制，检查代码后方可入库。另外需要制订完整的开发计划和编译计划，使得项目跟踪超向正规。
活动方式：专人控制，以面冲掉原来的代码
第四步、进度控制做法：在产品开发周期中定制完整的编译计划，对阶段性产品进行测试或者抽查。以保后期测试时间的争取和质量的保证。
活动方式：认可，执行，调整
第五步、控制进度问题       做法：明确开发模式，列举详细的开发进度，详细提出开发的功能情况，树立作战详细进度表或者叫作战牌，以鼓舞士气，让每个参与者了解进度
活动方式：承诺，监督，跟踪
16   做法：统一平台，统一流程，统一做事方式，实现任务单跟踪
活动方式：准则，平台，优化。

提高案例设计水平            明确了解现在目前流行切实用的几种案例设计的方法，因为在不同的产品不同的要求有不同的设计手段，我们需要不断的学习和总结，在为了测试领域中，许多新鲜的词语都会出现。
       这种方法类似与工业领域的随即抽取统计分析法，但是工业性质牵扯到损坏或者人为原因，统计出来存在这偏差，但是应用与软件方面，虽然存在着偏差，但是不可能象硬件那么偏差很高。
       等效法       明确测试的目标，一般适合用到的范围是，制定被测试的对象是在满足某个条件的区间内的所有的所有数据。
案例设计方法：从其中区间数据段中选择任意一个或者两个数据，只要这个数据满足了，那么其他的数据就是满足的。
我现在举一些例子，来说明等效法在测试过程中如何应用的。
范例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进行交易的情况下，Ａ从自己的物品箱中拿出物品，拖放到B的物品箱中，那么A和Ｂ在还没有确定的情况下，需要确信两点（A,和Ｂ相同，只不过一个提供金钱，一个提供物品）
１、        Ａ当前的物品是可以更换的
２、        Ａ拖放到交易物品栏中的物品是不能被其他人产看的
３、        在A放弃交易的情况下，此物品还应该回到物品栏
第二.     点击确定后测试设计的重点
１、        点击确定后，双方的交易请求就会到服务器处理的队列中，等待服务器重新计算
２、        当A或者Ｂ断线情况下，怎么处理？
３、        当服务器宕机怎么处理？
４、        当请求队列中等待的时间超过了心跳的时间，怎么处理？
第三.       正常交易后的测试设计重点
１、        物品数据（金钱数据的检查）
２、        物品属性检查
３、        物品是否能够正常交易和使用
第四.       交易过程可能出现的情况
１、        不是一对一的交易
２、        在没有确认的情况下把一个物品托动到箱子后，等对方付钱后，故意断线或者更换物品
３、        锁定物品后，不和Ｂ交易，同时也不关闭交易对话框，角色的交易标志是否被清除

A玩家

B玩家

请求交易

ＤＢ数据库记录玩家的数据

       边界数值分析法       在测试案例执行的过程中，所有调节的数据都需要考虑到边界数值的测试方法，这里我就不在赘述。但是需要注意，边界数值的测试不是枚举，只是抽样的方法。
逃避测试的误区       市场需求引导产品质量测试是为了验证需求，保证产品质量，无论如何你都不可能做成100%的测试，不可能做成No Errors。所以我们针对不同的产品，不同的市场定位，确定不同的测试方针。
       因为企业面对的是客户，面对是企业长远利益，那么我们不可能仓促的推出产品为了迎合市场，而是需要研究，调查市场的真正需求，把用户所关心的功能提供给用户，使得其更加完善，更加稳定。
       我们从企业来分析，首先任何一家企业要生存，必须需要市场空间的支撑，目的是为了盈利，我觉得没有必要说的那么冠冕堂皇，这是事实，但是在把握产品质量和市场需求的时候，我相信很多企业会选择市场需求的，因为这是机会，是把握企业生存的机会，特别是对于发展性企业来说。（企业原因）
       我们从开发来分析，因为在开发的过程中，由于软件行业的高流动行和知识更新快的特点，风险加大，使得开发周期很难把握，这样使得产品测试时间很难控制。因为开发的进度包括市场提出需求的技术风险都很难把握。（开发的原因）
       我们从测试来分析，测试在很多企业中是没有的，那么开发人员自己来做，如果有测试人员，那测试也是随意性非常强，造成产品上市后预留很多无法预估的风险，为企业的形象蒙上了面纱（测试模式）
合理利用2/8原则测试是列举，不是枚举，所以设计案例的时候全面是不可能的，那么需要灵活的运用2/8原则，使得测试重点清楚，容易控制。
       基于产品在开发过程中的种种风险，我们在有限的人力和资源的情况下，合理的利用2/8原则，如何把握2/8原则？首先需要了解产品的特点，让所有参与测试的人员能够了解产品的特点，这样使得工作具有针对性，至于产品的噱头，我们可以进行充足的测试，因为只是我们的产品立足市场的点。
       在时间有限的情况下，把常用的功能测试保证了，不要摊全，摊宽，这样到最后都无法总计产品的质量概念了。
       以上这么说，是一种概况，在实际的工作中大家需要总结，把进度，时间，质量等进行权衡，以保证产品的顺利发布。
回归测试的概念测试次数不是轮回，测试的不同次数不是轮回，而是为了验证问题，那么什么时候适合安排一轮测试，需要定义标准，否则耗时耗力。
回归测试是不可缺少的环节，在一个产品测试完成后，直接到用户手头的时候，需要千万小心，需要进行一次彻底的回归测试，这个时候包括所有的功能以及所有已经修正的问题。避免版本出现问题。
       其实在不同的资料中对回归测试有不同的解释，我就不在这里赘述。我想表明我的观点是，依照不同的开发模式，回归测试所在的时间段也不相同；当前的开发模式有瀑布型和迭代型，例如，在瀑布型的开发模式中，所有的测试活动（手工测试，系统测试，部分集成测试）都在最后进行的，而切所理解的回顾测试是为了保证在新的版本中测试修改后的问题，其实这个测试只是保证了其中一部分工作
测试的概念测试不是为了验证问题，而是为了发现以前设计中没有发现的问题。
自动测试只是测试的一种手段，目的是为了提高工作效率
测试工具只是利用，不能依靠，因为工具本身没有智能的判断是否会有问题发生，自动测试不是利于测试工具，而是需要编写或者利于测试平台，编写适合自己的测试工作进展。   
如何调整团队的作战能力建议性质：因为曾经带过四个团队，而且这个经验最少在我身上是成功的。
形式分析测试团队，测试团队在现在国内来说在慢慢的得到重视，之所以原来不重视是因为整个行业处于摸索期，不知道采用什么方法，什么技术，作什么事情等的情况下，使得测试员好像是一些没有能力人的集合（宣讲，不听的宣讲）。
目标计划引导测试技术和未来发展规划，因为任何人的发展需要目标，那么一个人的发展目标假如它和这个行业相关，那么它会付出一切，努力的工作，所以需要大家认可一个目标，并且让大家认为是可行的，然后我们分步骤一步步的去实现它。让他或者大家能够看到自己所喜欢或者从事行业的发展方向。
过过老师瘾因为在做任何事情的时候，每个人都有自己的想法或者步骤，讲出来就好，这就需要开始的时候我们以任务的形式下达，我相信，到后来大家愿意自己站出来讲了，我告诉你原因。因为人本身有羞怯感，怕几个方面，怕讲错，怕人多，怕提问。
那么如果把这几个问题都解决了，是否羞怯感就没有了呢？
如何解决个人怕的问题：引导，因为一个人如果不能把自己的想法和思路讲出来，那么不可能把事情做的很好，其二，就是如果你把你的想法说出来，别人可能会指出你思路中走弯路的地方，对个人来说可以跳高工作效率，使得思路更加完善。
其三，如果大家都把自己的思路说出来了，你不就节省的很多学习时间吗，另外你想过没有，当别人形成这个想法的时候，需要一定的积累，那是他的心血，这不就轻轻松松让你学到了吗？如果固步自封，那么你的思路有可能是错的，有可能是对的，但是你的知识面就只能局限在你所考虑的范围内，对个人发展不利。
定学习目标在软件行业里面，要有发展，就需要不停的学习，不停的进步，不停的总结，才可能有长远发展，所以需要定义在这个行业阶段行的学习目标，让人感觉这个行业现有的水平只是维持，要发展，需要学习。
       在工作中学习的方法，除了自学以外，就是“偷”了，所谓偷，就是要学会问问题，把你想知道的东西刨根问底，当别人回答你问题的时候，他一定是用他知道的东西的精华来总结，那么这样你在很短的时间内，把他总结的精华全给你了。
       在学习的过程中，需要学会总结，把能总结的都整理出来，第一是经验的积累，第二呢能够做到分门别类，逐类旁通，使得相同或者类似的错误不要重范。
兴趣和爱好       一个人工作有两种情况，第一中是真正的工作，完成就算完成了，自己也在不断的学习，不断的总结，但是缺乏激情。第二中是把工作当成自己的事业，渴望自己在这个方面成为权威或者说业界能够说话的人，也是在不断学习，不断的总结，培养职业性，培养和引导大家的兴趣和爱好，因为只有你了解了兴趣和爱好，才能更融洽的调和整个工作组的气氛，这对测试行业的领导者来说是个挑战。
歪曲理论推理              “测试人员是由于技术不过硬，才去做测试的。”针对这个观点，我说说自己的看法。好，我给测试说几句，测试水平不过硬成立，假设成立，那么这是相对的，相对开发来说的，而且这种论调都是从开发那里扩散或传播出来的，测试在后期发现问题后，开发也许心理很痛苦，但是他不愿意暴露在脸上，使得有些问题越发变的严重，不得不修改。那么在产品后期暴露那么多问题，说明了什么呢？这么低水平的测试都能考虑到你程序设计的种种漏洞，那么说明了程序水平开发有待提高。
在IT现在的行业中，开发的流程，模式，以及各种约定成俗
的东西越来越多，而且相对稳定，而测试是一个全新的行业，它需要大家摸索支持，需要大家共同建立起来。
        其实，在原来的开发模式中，商家为了适应市场，为了保证利润的最大化，为了使得产品能够顺利的适应市场，那么采用各种方法，使得产品质量的定位淡薄，而现在随着人们的要求越来越高，商家的意识越来越强，各个公司或者组织渴望成立测试部门，保证产品的质量，使得测试这个行业在最近几年才发展起来。
正确理解自动测试       首先，自动化测试是测试行业是技术，但是不是说用了自动化测试了就能发现更多的问题,它只是提高了工作效率而已.
       自动化的概念是人们在工业生产的过程中，为了提高工作效率，不断的对操作方法或者技术或者工具进行改进，减少人们普遍的手工劳动，节省时间和成本。
       而软件行业的自动化测试同样也有节约成本，提高效率的需求。所以所有的改进需要考虑到成本的问题。
       自动化测试的大前提:
第五.       产品本身特征具有长期可维护性
第六.       产品本身非紧迫的大项目
第七.       产品结构相对复杂
第八.       资源投入相对充裕
       那么作为成本，需要从几个方面去考虑，第一实现成本，第二，人力成本，第三，新技术的风险，第四，节省的成本，第五，被自动化的功能是否需要大量的手工劳动。
       所以我们理解自动化一定从成本的概念上考虑， 最少从自动化测试概念的起步应该从这个方面考虑。那么自动化测试的重点就在于他节省人力，节省时间，得到的数据更精确些，而且操作的可重复性和Bug的可重现性更强一些。
       下面我就对自动化测试做一个详细的解释，跟大家分享。
1. 简介
本文关注于一个实施自动化测试框架的组织的主要方面和影响。本文的意图是提供一些能够成功的实施自动化测试的指导方针。
2. 测试自动化的神话
有很多关于自动化测试的神话。其中的一些是真实的，而其他的一些是不正确的设想，这些不正确的设想会严重的威胁到实施自动化测试的成功。
2.1. 我们在时间上是紧迫的 － 项目已经落后了 － 让我们使用自动化测试吧！这种情况将不能成为现实。实际上，正确的思想应该是 － 我们时间急迫 － 我们决不应该使用自动化测试。
如果项目已经陷入到了麻烦之中，不建议实施自动化的功能测试。项目很可能因为需要大量的测试框架的准备和实施会被托跨。我饿建议将重点放在以下的事情上：
优化测试的过程。调查并建议在目前工作基础上的测试方法和过程。建议借鉴 RUP的相关思想和过程。引进或者使单元/组件测试正式化。这是我们能够快速获得受益的很好的方法。如果正式的组件测试被使用，我建议可以使用 Rational PurifyPlus 进行单元或者组件测试。根据我的经验尽早的使用 Rational PurifyPlus 是非常值得的。在一个引入和 Rational PurifyPlus 的项目中，通常会在组件的级别得到 百分之三十的性能提升。仅仅在项目团队能够对 下列问题的回答是"Yes"时：项目能够被适当的推延。存在能够通过实施自动化测试被达到的精确的目标。项目具备建立适当的测试框架的必要条件。
那么，你可以在一个时间紧迫的项目中适当的实施测试自动化。但是根据经验这种情况是很难发生的。总而言之，我只能说"对不起，银弹根本不存在"。
2.2. 测试自动化就是捕获和回放
在过去的日子中，自动化的测试工具只是被看作是一种捕获和回放的工具。当前这个神话仍然在很多测试人员的思想中。而事实上自动化测试已经远不止捕获和回放这么简单了。按照成熟度自动化的测试可以被划分为 5 个级别。
2.2.1. 级别 1：捕获和回放
这是使用自动化测试的最低的级别，同时这并不是自动化测试最有用的使用方式。优点：自动化的测试脚本能够被自动的生成，而不需要有任何的编程知识。缺点：你会拥有大量的测试脚本，同时当需求胡子和应用发生变化时相应的测试脚本也必须被重新录制。用法：当测试的系统不会发生变化时 － 小规模的自动化。
2.2.2. 级别 2：捕获、编辑和回放
在这个级别中，你使用自动化的测试工具来捕获你想要测试的功能。将测试脚本中的任何写死的测试数据，比如名字、帐号等等，从测试脚本的代码中完全删除，并将他们转换成为变量。优点：测试脚本开始变得更加的完善和灵活，并且可以大大的减少脚本的数量和维护的
工作。缺点：需要一定的编知识。频繁的变化可能会引起"意大利面条式的代码"，并且变更和维护几乎是不可能的。用法：当进行回归测试时，被测试的应用有很小的变化，比如仅仅是针对计算的代码变
化，但是没有关于 GUI 界面的变化。你能够使用这种技术通过快速的编制一些测试脚本以检验你的想法来探索你的预定的测试设计。当我在没有任何象需求或者设计模型这样的文档的情况下第一次操作一个产品时和我需要获得一系列内部构建版本的稳定性的第一印象时，我使用过这种技术。通常如果适当的软件配置管理（SCM）与良好的内建设计相结合时，使用级别 2 的技术已经足够了。
2.2.3. 级别 3：编程和回放
这个级别是面对多个构建版本的有效使用测试自动化的第一个级别。你需要在实际的投资开始显现之前确保团队和客户对项目的安全感。如果没有对测试自动化工具的适当的培训测试人员将不具备到达这个级别的能力。在自动化测试工具中的所有测试功能都必须被很好的理解，并且要掌握测试脚本语言的知识。好处：你确定了测试脚本的设计。适当的设计是必要的。编码的习惯必须是适当的。使用与开发中相同的编码习惯是非常好的。这将开始搭建起测试和开发之间的桥梁。在项目的早期就可以开始自动化的测试。你能够在项目的早期就开始进行测试脚本的设计。与开发人员交并调查他们认为可能会存在问题的区域。确保了开发人员关注在获得能够被测试的方案上。缺点： 要求测试人员具有很好的软件技能，包括设计、开发等。用法：大规模的测试套件被开发、执行和维护的专业自动化测试。级别 3 使你能够使用自动化测试并构建不同的回归测试（重用已有的自动化测试
用例）。根据我的经验在看到更多切实的回报之前，为了达到这个级别，有大量的工作和影响项目的活动必须被做。因此快速的建立和证明自动化测试的价值是至关重要的。找到乏味的测试（例如，边缘测试和特定的功能测试用例是首先进行自动化测试的良好候选者）。首先创建少量的能够测试一些基本功能（比如，登陆和创建用户等）的测自动化测试用例。
2.2.4. 级别 4：数据驱动的测试
对于自动化测试来说这是一个专业的测试级别。你现在要利用测试工具提供的所有的测试功能。你拥有一个强大的测试框架，这个测试框架是基于能够使你根据被测试系统的变化快速创建一个测试脚本的测试功能库的。维护的成本相对是比较低的。你在你的测试中会使用到大量真实的数据。优点：你能够维护和使用良好的并且有效的模拟真实生活中数据的测试数据。缺点：软件开发的技能是基础，并且需要访问相关的测试数据。用法：大规模的测试套件被开发、执行和维护的专业自动化测试。级别 4 要求一些非常良好的测试数据。一个测试人员必须要花费一些时间来识别在哪里收集数据和收集哪些数据。使用现实生活中的数据是最基本的以从测试中得到完全的回报。使用适当的数据将为你提供通常仅仅在项目的后期才会发现的或者是有客户发现的错误的能力。现在你能够通过使用现实的数据开运行大量的测试。
2.2.5. 级别 5：使用动作词的测试自动化
这是自动化测试的最高级别。主要的思想是将测试用例从测试工具中分离出来。这个级别要求有一个具有高技能测试人员测小的团队，这些测试人员能够将测试工具的非常深层次的知识与他们具备的较深的编程能力结合起来。这个团队负责在测试工具中生成并维护测试的功能性，能够使测试工具从外部的来源，比如 excel 表或者数据库中执行测试用例。这种测试概念最初是由 CMG 开发的。与 CMG 方案相比，其他的可能的开放源码的方案有被 Carl Nagle 和SAS Institute 开发的DDE。使用 DDE 的概念，关注点是当在Excel表中创建测试用例的时候，放置使用包括被使用的特定动作词语的一些类型的模板。执行的过程是从 Excel 表中读取测试用例，并将测试用例转换成为测试工具能够理解的形式，然后使用不同的测试功能来执行测试。这个概念变得越来越流，因为测试与用例一起使用是非常有用的。优点：测试用例的设计被从测试工具中分离了出来 － 关注在设计良好的测试用例上。允许快速的测试用例的执行和基于用例的更好的估计。缺点：需要一个具有工具技能和开发技能的测试团队，以提供并维护测试工程（框架）。用法：专业的测试自动化将技能的使用最优化的结合起来如果工具不具备使用内建的对象映射的可能性，那么这个方案对于消除与 GUI 相关的大部分维护成本是优秀的。在一些组织中已经创建了这种方案，并且他们其中的一些已经实现了高度的自动化（60%），并且他们都得到了巨大的回报。如果测试框架是适当的，我们能够使用 excel 来生成实际的测试用例。这个级别对于那些按照正规基础使用用例的组织或者项目来说是非常优秀的。有多少测试用的估计是被需要的，并且当用例适当时需要做的工作也是非常简单的。你可以集中时间来生成第一个包含被需要的"对象映射"的测试用例（主流程）。依靠被测试应用的复杂程度，通常这会花费大约半天到一天的时间。后续的被需要的每一个测试用例大概会花费 15 到 20 分钟的时间，因为通常多数的测试用例可以复制已有的测试用例，并对其进行必要的修改，通常这种修改是有限的。动作词语框架能够通过使用用例使紧密的并行测试用例的开发变得可能。
2.3. 我们不需要培训！
我们所有的人都在某一些方面具有一定的经验，我们没有时间能够花费在使用新工具的培训上。当一个对自动化工具还不是很熟悉的组织或者项目团队开始实施自动化测试时，培训和指导是至关重要的。如果我们允许组织或者项目团队在没有关于应该如何做的任何知识的情况下实施自动化的测试，那将肯定会以失败告终。用于实施自动化测试方案的预算会被超出，测试会被延误并且更坏的情况是自动化测试将被放弃。组织和项目团队需要尽量避免一些认识上的缺陷，尤其是自动化测试的维护成本和当测试人员尝试和确认工具如何工作时产生的挫败感。你需要确保你的测试过程是适当的 － 如果测试过程是不合理的，引入自动化测试只会给软件组织或者项目团队带来更大的混乱。因此，我建议希望实施自动化测试方案的组织或者项目团队应该在实施之前建立"训练营"，并将重点放在培训测试团队能够很好的利用一个原型的项目上。为第一个原型项目制定一个实施计划，下面包括原型项目的最小化的描述：当先状态我们希望实现什么 － 建立成功的因素期待的回报（第一次自动化测试工作被期望验证什么）找到一个"简单的"测试的痛处并尽力的通过自动化测试解决它，这可以被作为在同一时间上使测试运行在多个平台上的样例说明被需要的资源和时间......
一开始你就要大声的说出成功的信心 － 让人们了解你所展示的进展。这将吸引更多的关注和资源。
2.4. 我们必须 100% 的自动化
从管理的角度来说，100% 的自动化目标只是一个从理论上可能达到的，但是实际上达到 100% 的自动化的代价是十分昂贵的。一个 40-60% 的利用自动化的程度已经是非常好的了。达到这个级别以上将增加测试相关的维护成本。由于对每一个构建版本的需求变化的复杂度，你将花费更多的时间在变更测试用例上以使他们能够正确的运行。在这种情况下，通过告知管理层100% 的自动化目标是相当昂贵的来确立一个合理的期望值才是明智之举。对于决定自动化一个测试用例的一般规则是这个测试用例必须被运行 4 次以上。这个数字是基于用户对测试工具有良好的技能并且有一个良好的测试框架的。如果情况不是这样的化，整个数字能够是 10-20次或者更高。一个例子，在一个项目中测试人员花费和两周的时间将手工测试的 23天的任务转换成了自动化测试的用例。在完成使，项目能够在 4 个小时在多个平台上运行相同数量的测试用例。
2.5. 测试框架
测试框架对于产生成功的测试自动化的适当基础是重要的。很多考虑必须被解决以使测试自动化更加有效地被使用。重点必须在：维护成本维护成本是成功的使用自动化测试的最重要的问题之一。维护成本直接联系到前面已经提到过的自动化测试的成熟度。组织或者项目必须至少要在成熟度的 3 级使用高度的测试库才能使维护和更新测试功能变得容易。
测试数据
什么样类型的数据将被使用？要为每一个测试用例生成测试数据还是使用在被测试应用中已有的数据。在很多的情况下一个测试数据被创建了，删除他们是不可能的。
可测试性
自动化测试方案能够有效的测试吗？例如，被适当命名的对象（不仅仅是索引Id）。一个简单的例子是所有的对话框都有相同的 ＃id 和相同的标题，所不同的仅仅是显示的文字信息。当测试应该覆盖多种语言的方案时，对话框的测试就是一个挑战。
测试人员的技能
被包括在自动化测试的创建中的人员应该具有什么样的技能呢？如果他们具有良好的开发背景，那么成熟度 3 级是足够了。如果他们有很少的或者根本没有开发的经验，我们被迫使找到或者培训一个自动化测试专家的小组，并直接到达成熟度 5级，在成熟度 5 级测试的创建与实际的测试执行被分离开。
一个好的构建过程
自动化测试的引入在"构建团队"上加入了一些约束。为了实现自动化测试的高利用率（回归测试），要求具有一个高的构建频率。每周仅仅运行自动化的测试不是好的自动化测试的使用率。将回归测试增加到每天一次将帮助快速的发现新的问题并使开发人员更加容易的发现问题的根源，因为对测试的反馈时间是比较短的（开发人员能够记住他们昨天做了什么）。所有权不同的测试库的所有权的定义是重要的。一个好的方案会将测试库的组织划分为三个级别：
级别 1 － 全局的
这个一个通常的级别。被存储在这个级别的测试功能能够被所有的项目访问。通用的和通常的功能象登陆、创建一个用户都是这个级别很好的候选者。
级别 2 － 项目
在这个级别的测试功能是与特定的测试项目相关的，但是通常在项目中有用的比一定在项目外是有用的。通常级别 2 是级别 1 的功能的提供者。
级别 3 － 脚本
功能被直接关联到特定的测试脚本。 I在这个级别中，通常一个测试功能的第一个版本是被开发的。在新的测试脚本的创建期间已有测试功能的重用性被发现，并被移到了级别 2 中。在这个级别上尽量最小化功能的数量，因为它将增加维护工作量。还有很多有关测试框架的问题，但是这里所提及的是一些基本的要被解决的问题。
3. 在哪里使用自动化测试
有很多的情况下使用自动化的测试可以降低测试成本。我将尽量的突出在自动化测试中的不同的测试技术技术 描述 备注单元测试/组件测试 这个测试工作通常是开发人员的职责，很多不同的方法能够被使用，比如"测试先行"，它是一个测试框架，开发人员在编写代码前编写不同的单元测试。当测试通过时，代码也被完成了。 通过使用正式的单元测试，不仅能够帮助开发人员产出更加稳定的代码而且能够是软件的整体质量更加的好。冒烟测试 冒烟测试是一般验证别测试系统的功能性测试用例的集合。冒烟测试背后的思想是确保基础是可以工作的，以便"大的"测试工作能够开始。 在构建过程能够确保构建已经为测试准备好时，冒烟测试通常是自动化的运行。功能/集成测试 这里测试的工作关注在验证在不同的组件之间的集成上。 这些类型的测试通常是被测试系统的更加复杂测试的基础，大量的边缘测试被合并以制造出不同的错误处理测试。系统测试 － 用例测试 这种测试是通过执行用户场景模拟真实用户使用系统以证明系统具有被期望的功能的测试。 这里不需要进行自动化的测试。安装测试、安全性测试通常是有手工完成的，因为系统的环境是恒定不变的。回归测试 回归测试实际上是重复已经存在的测试。通常如果是手工完成的化，这种测试只在项目的结尾执行执行一到两次。 这里完全有潜力应用自动化的测试。你能够在每次构建完成后执行自动化的回归测试，以验证被测试系统的改变是否影响了系统的其他功能。性能测试 性能测试包括以下不同测试形式：
- 负载测试
- 压力测试
- 并发测试
-.....
如果没有自动化的测试工具，你将不能执行通过模拟用户的负载实现的高密集度的性能测试。
4. 什么时候使用自动化测试
我对什么时候应该使用自动化测试和什么时候应该使用手工测试进行了一个概要的总结：使用自动化测试 使用手工测试项目没有严格的时间压力具有良好定义的测试策略和测试计划你直到要测试什么
你知道什么时候测试对于自动化测试你拥有一个能够被识别的测试框架和候选者能够确保多个测试运行的构建策略多平台环境需要被测试你拥有运行测试的硬件你拥有关注在自动化过程上的资源
被测试系统是可自动化测试的 没有适当的测试过程没有一个测试什么，什么时候测试的清晰的蓝图在一个项目中，你是一个新人，并且还不是完全的理解方案的功能性和或者设计你或者整个项目在时间的压力下在团队中没有资源或者具有自动化测试技能的人没有硬件如果你正在从事自动化测试，那么一定要记住要关注将自动化测试与手工测试结合起来使用。首先，对于自动化测试率的目标是 10/90 （10% 的自动化测试和 90%的手工测试）。当这些目标都实现了，可以将自动化测试的使用率提高。记住创建自动化测试的测试用例要比创建手工测试的测试用例花费更多的时间。不要将你所有的测试时间都用在自动化的测试用例上。同时也要记住在测试期间对每一个被发现的错误都要花费一定的时间去处理。
5. 自动化测试的好处如果你正在你的组织中引入自动化测试，记住有很多不同的方面被包含了进了。今天在测试工作如何被进行上有很多不同的视图。为了能够成功的实施自动化测试你应该提出这些问题：
测试覆盖什么？－ 我们没有覆盖什么？
由于遗漏的测试我们没有发现的"bug"会带来什么样的成本？由于不好的测试，破坏已有功能性的成本是多少？如果"琐碎的"测试被每天的运行，对于你的项目意味着什么？如果我们能够每天向开发人员提供他们最近代码变更相关的反馈，对项目有怎样的影响？这些问题都能够被自动化测试满足。你必须从自动化测试成熟度的级别 1 或者 级别 2 开始，并开始测量结果。根据我的经验快速的向开发人员反馈并每天运行测试对于向自动化测试成熟度的级别 4或者 级别 5 是非常有好处的。
自动化测试有以下的贡献：
降低风险 － 你知道你测试了什么和没测试什么测试能在项目的早期开始并随着时间一直扩展快速的反馈 － 自动化测试用例能够随时的运行在多个平台上的测试能够同时进行
更好的估计 － 你能够对测试进度和被使用的时间有更好的了解优秀人员的集中 － 你能够得到一个专家的团队，并将他们的知识传播给其他的项目喜悦 -你和你的团队正获得着成功
测试工具介绍下面我介绍市面上相对比较广泛的测试软件，Rational中的Robot和MI公司的WinRunner的具体的用法。
       Robot，俗称机器人。它有几个特点，第一，Robot它的语法相对简单，是一种类似于VB的语法，所以上手快；第二，Robot的脚本组织结构类似于C的结构，相对容易理解；第三，Robot运行环境和可参数化，所以容易维护；第四，要求的机器配置相对较低；第五，Rantional系统集成的很多产品很优秀，而且适合面很广；第六，相对价格比较低廉。
       WinRunner的功能相对Robot相对来说有一下几个特点。
第一，      WinRunner的语法结构是类似于C的语法，理解相对容易；
第二，      WinRunner的脚本组织形式是以目录的形式组织的，所以相对来说比较好管理；
第三，      WinRunner支持当前市面上的很多系统；
第四，      可以随时Update检查点的内容，使得脚本的维护量减少
第五，      机器配置相对要求高些；
第六，      集成了很多优秀的组件。
下面我就尝试写一个Robot的脚本。
题目：请检查各种我们规定的字符是否过滤掉了，如果那些词语没有过滤掉请记录下来。我们先看测试这个功能的逻辑关系图应该如下：

我们创建的测试案例：准备很多需要过滤的词语

程序处理模块

输出处理结果T_FilterWord

打开过滤词文件 T_OpenTestFile

测试脚本：
Function T_OpenTestFile(Filename as string)as integer
{

。。。。。。。。。。。。。

}
Funciton T_FilterWord(getword as string)as integer
{

。。。。。。。。。。。。

}
以上是两个SBL文件，相当于C中的函数实体
那么我们要建立一个SBH，相当于C中的头文件，红色的部分类似于一个类库，我们把相关的或者具有相似属性的操作或者函数定义在同一个类库中。
Declare Function T_OpenTestFile Basiclib T_FileOpertion(filename as string) as integer
Declare Function T_FilterWord Basiclib T_FileOpertion(getword as string) as integer
我们现在建立一个脚本文件REC
＃include T_FileOpertion.sbh
Main()
{

。。。。。。。

}
在此脚本中就可以调用上面那两个函数了。在以后的测试中，我们只需要维护过滤词文件库就可以了。这样提高了工作效率，保证了测试的正常进行。
      下面我就举个例子，来尝试用WinRunner的使用方法，其实例子相对很简单，主要是想告诉大家这种语言脚本的组织方法是怎么样的？
    压力测试工具的功能挖掘使用。
一、为什么采用插件脚本开发

性能测试过程中，最耗费经历的就是编写性能测试脚本的过程，在大部分的测试工具中都是采用录制的方式，通过录制产生脚本，然后根据需要进行修改，以及参数化。有些时候为了能够完成某一个功能的脚本，需要将录制下来的脚本进行大手术，例如将一些逻辑以脚本的形式写在LR里面，给编写脚本的人带来了很大的麻烦。目前部门的大部分业务在性能测试过程中都是采用录取请求信息包的模式来模拟请求。
其实LoadRunner是提供了COM组件的调用的（图一），你甚至可以在引用了LoadRunner的组件，继承相应的接口后，重写LoadRunner的很多方法，比如我们熟悉的lr_start_transaction、lr_rendezvous等方法。


（图一 LoadRunner提供的COM组件）

这样有什么好处呢？
能够更有效的、更灵活的构建可被LoadRunner调用的脚本或者压力测试程序
我们可以定义自己的调用类及方法、比如自己封装好的socket类、而对于不同的业务只需要传送不同的调用参数而已，避免了每次的测试过程都要去录取烦琐的脚本再在脚本中更改，而且执行效率要高于录制的脚本（直接录制的脚本是解释执行）
生成的脚本可以突破LoadRunner本身的很多限制
我们知道的LoadRunner在应用的时候是有很多限制的，比如：C/S 协议的license的个数限制、负载生成机器单台最大只能运行1000个虚拟用户，而采用插件脚本开发的形式可以突破这些限制
可以抛开第三方的工具、自己实现压力测试工具
插件开发脚本实际上是生成了Virtual User Generator的功能，但只要增加并发调用的程序，就可以实现了Controller的功能，如果是采用.net(C#)开发语言就可以构建线程安全的并发生成工具
二、插件在IED环境中的使用
利用Loadrunner Add_In的方式进行脚本的开发，如果想采用这种方式是需要有几个前提条件的：
􀁺要有被测试程序的源代码
􀁺被测试程序的架构要清晰，对于一些分层不够好的产品，不太适宜用这种方法。
􀁺编写脚本的人员要了解Loadrunner的使用
使用：…\Additional Components\IDE Add-ins\MS Visual Studio .NET ，安装文件：
LRDotNetIDEAddInSetup.exe

在开发环境中会产生新的菜单项 如图二


（图二 IDE中的Vuser）
菜单中会多出一项【Vuser】的菜单。这个菜单就是我们主要使用的内容。另外，在对象库中也会增加loadrunner相应的对象。这些对象的使用和软件中其他对象的使用没有什么分别。这些对应都是可以被loadrunner所识别的，同时也是可以并发安全的

这样就可以新建LoadRunner工程了


增加必要的内容：
框架生成后，我们就需要根据测试的内容增加相关的代码了，下面介绍的函数都是以c#为例进行介绍的，其他的语言与此差不太多。
我们假设一个场景：要测试100个用户同时登录系统的情况。后面都将围绕着这个主题进行。
首先，无论使用什么内容都要先进行对象的创建：
LoadRunner.LrApi lr;
lr = new LoadRunner.LrApi();
1、 事务
事务是测试最核心的单元，所以事务的创建非常重要，下面是一个事务的定义过程。
LoadRunner.LrApi lr;
lr = new LoadRunner.LrApi();
lr.start_transaction("syslogin"); //事务开始,事务名称为syslogin
//×××××此处添加事务syslogin的程序，例如：××
Client_syslogin(“servername”,”Username”,”userpassword”,”2005-1-12”);
lr.end_transaction("syslogin", lr.PASS);// 事务结束
事务的开始和结束与VU Generator工具的脚本基本上是一样的。
具体的使用不做详细阐述了，网上也有相关的教程
三、举个实际测试的例子

InSoket类是封装好的SOCKET请求类 包括异步连接、异步发送请求以及异步接收数据等


Vuser类 是具体的请求调用 包括一些请求方法及重载、事件委托
以上只是对方法可行性做了研究 具体业务的封装要复杂些。
示例代码如下：


           还有一个实际例子，就是针对一个业务我们进行的测试，分享给大家。
某金融服务器性能测试方案
测试说明
模块说明tcpsvrd
客户端统一通讯接入前置机，根据server type和server id来识别接入的客户端，如果type是Client则id为uin，如果是内部server则同一个type和id只能建立一条TCP连接，若有多余连接则会拒绝其接入。
financesvrd
目前暂时只测试3条消息，Deposit（存款）、Consume（消费）、Query（查询）。Deposit和Consume会直写DB，Query则先会查询Cache，再查DB。
Test Server
       可以是LoadRunner的Controller，也可以是自行开发的TestServer，主要负责控制各个TestClient启停。

Test Client
       可以是LoadRunner的VUser，也可以是自行开发的TestClient，主要负责开多线程快速发送消息。
工具说明
LoadRunner
两种方案：
       用Web协议加载DLL
       License有10000个，并发时每50个VUser启动1个进程50个线程建立一条TCP连接共同向一个端口发包，运行时必定会采用同步机制来竞争资源（这种方式和单线程+延时+循环发包的压力效果是否类似？是否做到了真正的并发？）因此最多只能建立10000/50=200条TCP连接。如果要测试向tcpsvrd建立大量连接显然是不行的，只能测试向tcpsvrd发送大量请求。
用Windows Socket加载DLL
       受100个License限制，并发时每个VUser均会启动1个线程建立一条TCP连接发包。在License数量无法增加的情况下，很难做压力测试。
       从目前的调试结果来看，用LoadRunner加载DLL的方法来测试C/S架构不太乐观，存在着一定风险。
ethereal/sniffer
       测试准备阶段用于调试脚本、测试程序
       测试执行阶段通过在服务器端抓包，来分析整个加压过程。（如果测试时间长时，抓包文件会很大，增加数据分析的难度）。
       另外，也可以用于协议测试。（不知道开发做了没有，做到什么程度？我们是否可以介入？）

统计工具和脚本
服务器统计工具sonicmao已经提供financetool –s0/s1 (复位/统计)，能够统计客户端发送消息数目，Cache命中率，数据库的处理时间等性能指标。
       服务器性能指标分析工具，沿用joeqiu提供的rstatd
目前缺少数据库的记录插入/复位工具（由开发完成？还是自己解决），后台日志的查看只能通过人工分析日志文件，是否提供相应日志分析工具？（此需求重要级别：低）
测试程序
首先要开发一个TClient作消息发送器（难度不大，容易实现），要想加入控制功能还需要开发一个TServer的控制器，用于控制各个TClient的启/停，接收各TClient的上报消息。（关键是如何设计，做到最大限度的复用，此需求重要级别：中）。
       最好是服务器为TServer定义service type和service id，直接允许其接入，由我们来定义测试消息，通过发送查询消息直接搜集服务器的当前信息（取代后台统计工具financetool），这样就可实时监控服务器当前的业务处理性能。（此需求重要级别：低）
测试内容
tcpsvrd
单台服务器最大承受接入连接数
目的：测试不同硬件配置下tcpsvrd的接入能力，得出结论XX配置下可以承受XX个接入
方法：用测试程序模拟n个Client接入tcpsvrd，按正常使用频率（需要和开发协商做一个大致的估算，如果不能确认，则只统计结果）在10-30分钟内定时向financesvrd发送固定消息（消息类型个人觉得应该是查询消息）。
数据记录表格（参考）

No.

测试时长

消息类型

接入客户端数目

消息发送频率(次/秒)

发送消息总数

转发消息总数

处理消息总数

业务处理成功率（%）

CPU占用率Max/Min/Avg（每n分钟查看一次）

Load BalanceMax（每n分钟查看一次）

Mem Use （每n分钟查看一次）

其它异常记录

1

2

机器配置：…

测试通过条件：CPU占用率Max<70%，LoadBalanceMax<2，MemUser<1G (需讨论或查找相关资料)

单台服务器最大承受消息数（峰值压力）
目的：测试tcpsvrd在业务高峰期转发消息的能力，得出结论tcpsvrd当消息速度达到XX个请求/秒（或流量达到XXkbps）时，需要进行在网络设备上进行流量控制。
       方法：用多台机器向tcpsvrd连续发包，持续时间5-20分钟（服务端的峰值压力如何计算？如果用tcpdump抓包可能会影响服务器的业务处理能力）
数据记录表格（参考）

No.	测试时长	消息类型	发送消息总数	转发消息总数	处理消息总数	业务处理成功率（%）	CPU占用率Max/Min/Avg（每n分钟查看一次）	峰值压力（TPS或kbps）	Load Balance Max（每n分钟查看一次）	Mem Use （每n分钟查看一次）	其它异常记录
1
2
机器配置：…

测试通过条件：与2.1.1类似

单台服务器长时间承受消息数
目的：测试tcpsvr长时间运行所能承受的消息数，得出结论给出tcpsvrd的推荐处理速度，tcpsvrd当消息速度达到XX个请求/秒（或流量达到XXkbps）时，需要在软件上进行流量控制。
方法：用多台机器向tcpsvrd连续发包，发包速度可以参考2.1.2给出，持续时间2小时以上
数据记录表格：与2.1.2类似
测试通过条件：与2.1.2类似
financesvrd
服务器的业务处理能力
在对tcpsvrd进行测试的同时，可以顺便得到。时间允许的话需要对deposit、consume、query全部进行测试。否则只测试query消息。
DB
目的1：测试Cache命中率对其进行调优，得出结论命中率为100%时应该配置多大的Cache，命中率为90%时应该配置多大……
目的2：测试直写数据库时是否会有I/O瓶颈，CPU占用过高？
方法：数据库事先要插入一定数量的记录（具体数量是多少？10w,100w），先配置较小的Cache用多台机器连续发查询包来得到命中率和发包速度的关系，再逐渐调大Cache找到两者的映射关系。
       在发写DB请求时，最好能建立请求速度和CPU占用率/内存使用/负载的经验匹配值。
以下内容在相关技术问题未解决之前先暂时不考虑
测试工具在实际工作中的应用       现在在测试行业说的最多的有两个问题，第一个问题是测试的待遇和地位，第二个问题是自动化问题。我这里不谈测试的地位，只谈自动化测试。
如何做好自动化测试？这里给出几个分析方法，第一，被测试产品是否有延续性？第二，被测试产品的维护频繁度？第三，被测试产品自动化的难度如何？
       其次，如何选择自动化工具，选择容易上手的，测试脚本和测试数据容易维护的，价格低廉的。
       正确的理解测试工具需要我们去引导，我们应该清楚的知道那些应该自动化，那么能自动化，那些自动化程度会更高等。      
工作中的自动化测试的几中方法       数据驱动法       数据驱动是测试中最常用的一种方法，它是在不修改测试程序的情况下或者稍微修改测试程序的情况下，不段的增加测试案例来进行自动测试的一种方法。
举一个具体的例子：例如我们检查登陆验证（用户名称），
       如果我们采用自动化测试，我们只需要在测试配置文件中增加或者删除修改配置文件就可以达到测试的效果了。

测试程序

测试配置文件

被测试程序

输出反馈结果，实际处理结果

预期处理结果

只要将两个文件进行比较，就可以得到被测试程序的处理能力和结果了。
       桩驱动桩驱动也是一种常见的测试方法。这种测试方法是把某个模块假设是正确的，然后把这个模块作为主核心，然后测试他传出的参数和数据给其他模块来处理，查看处理的结果。
我那EXCEL中数据举一个现实的例子，大家都知道，当你输入等号的时候，Excel认为你需要计算，那么处理流程就应该是接受键盘消息，然后处理。如果我们把输入做为一个桩，那么来查看计算结果的话，就可以知道那些信息处理了，那些信息没有处理。
       桩驱动的核心其实很简单,就是首先对桩模块做一个假设和详细测试,认为桩模块是足够健壮的;第二,桩模块是驱动机,能够和很多模块发生调用关系,是核心部件.
       关键字驱动         关键字驱动和桩驱动有些相似的地方，关键字驱动的核心是
网络方面的测试方法       数据库测试要点网络游戏测试要点       下面我和大家探讨网络游戏的测试方法。网络游戏是一个信息相对集中的一个网络产品，它牵扯到客户端和服务端以及客户端之间的通讯。下面我们就结合具体的例子来分析
       我举一个Mmog的例子（注：mmog是大型网络游戏的缩写），大型网络游戏主要是即时战略性质的，所以通讯上采用TCP协议来发送数据包。TCP协议发送数据包的优点是尽量能够减少数据包的丢失，他是对数据包的一个精包装，一般的发送数据包采用实时处理的形式，即采用堵塞式的处理模式，而不是等到一定空间的数据包满了以后才一起发送（非堵塞式的处理模式）。
上面我们只是简单的讲了mmog游戏数据包发送的形式。下面我们分析网络游戏服务端测试的重点。
       网络游戏服务端的主要作用：下发玩家信息，仲裁胜负信息，仲裁装备信息，服务器之间中转信息，状态存盘，玩家信息存盘等。我们来一个个的分析，服务端要处理这么多的事情，在处理什么事情的时候压力最大呢？那肯定是下发玩家信息最大，为什么这么说呢？因为在下发玩家信息的时候，服务端会把每个人的信息和地图上的所有的信息，而且这个信息是当地图上的玩家和元素的增多而增多，当地图上的人越多的情况下，服务器的处理信息的量就很大。那么分析这么多，我们主要测试什么？测试同步消息的传递。就是在很多玩家的情况下，信息能否顺利的通知给各个玩家。
如果做这样的事情呢？根据经验（可以另外想办法），建议编写一个机器人，我们能够操作机器人，这个机器人需要处理什么事情呢？希望机器人能够在以玩家为中心的地方随意走动，能够跟随玩家跨地图，能够按照设定施放技能，能够聊天。通过机器人的每一个动作我们来观察服务的各个性能表现。关心那些性能表现？大家可以参考LoadRunner提供的业界比较官方的指标进行核对。
       网络游戏服务端的测试相对比较复杂，对测试人员的要求比较高，测试人员必须了解用什么协议通讯的，怎么通讯的，服务器都处理了那些事情才能具体的分析测试重点和测试方法怎么做。
       对于客户端的测试应该相对简单些，我这里说的客户端的测试不包含数据平衡部分。客户端主要是验证功能逻辑。例如我举个例子，任务系统，现在每个游戏都有任务系统。如果测试任务系统，我们应该怎么测试？首先完成任务的条件是什么？完成任务需要什么道具？玩家能得到什么道具？道具是否可以交易，拾捡？道具是否可以买卖？玩家跟NPC交付任务断线处理？NPC在不同的状态下所说话的内容？是公共任务还是门派任务？在得到道具过程中储物箱满了会怎么处理？在负重超出了本身能力的情况下怎么处理？等等，把细节的问题考虑清楚了，这样设计案例执行就是了，没有自动化的必要（但是可以在组件测试中进行自动化，系统测试没有必要自动化）。
       客户端还有一个测试点就是地图，因为地图是游戏的门面，所以地图的检查点：绚丽度，整个地图的亮度，不同分辨率下的地图显示，地图的拼接，地图上NPC或者怪物的分布等等。网络游戏的测试是积极具有挑战性，包括能力，耐力，创造力的人奋斗。

GameServer

DB帐号数据库

角色数据库

GameServer

GameServer

网关2

Client客户端2

我们把平常大型网络游戏容易出错的地方整理几个跟大家分享。
举例1
       大家都知道在游戏中，每个玩家都有自己的背包和储物箱，如果知道网络游戏的人应该都了解，这个是玩家存放自己装备或者基础材料的。这个储物箱在游戏中应用非常广泛，所以玩家也在寻求办法，钻设计的漏洞，以便刷物品，使得自己的虚拟物品和价值持续走高。
       关于背包，我们有一款游戏中是这么设计的，收集材料同类的可以叠加，武器类的不可以叠加。
       我们来看这个问题，如果可以叠加，意味着只要有同类的物品，就当你存放的时候叠加到一起。但是
       还有一种是休息类游戏，例如盛大网络的泡泡，客户端之间主要是通过UDP进行通讯。关于UDP通讯的检查和测试我在这里先不做详细描述，以后进行补充。
       网络游戏的核心是什么？网络游戏的核心是构造一个虚拟的社会，让这个社会上的各种职业的人能够生存并附带一定的社会矛盾。那么在这么庞大的项目中，我们测试需要关注的点是什么呢？
C/S结构测试要点       网络游戏现在是C/S架构的一种，但是我们平常所说的C/S是一种类似于银行系统，购物系统等，这种系统要求：服务器处理能力强，反馈及时，但是有一个特点，这种服务器压力是出现在业务繁忙的时候，所以在测试这种软件的时候，需要完全弄清楚业务逻辑，业务点在那里？信息同步在那些方面需要关注？服务端数据处理流程是什么？如果把以上问题搞清楚了，测试的重点也就出来了，这里我不再举具体的例子，因为C/S架构的软件是相通的。
       下面我就举个例子,给大家看看,关于C/S架构的mmog类型的游戏测试,服务器的压力那里,测试的重点在那里?
       请大家看下面的图形,这个图是目前市面上90%以上mmog类型游戏采用的结构.

GameSvr3(游戏服务器)

账号数据库

角色数据库

GameSvr1(游戏服务器)

GameSvr2(游戏服务器)

客户端

客户端

客户端

客户端

我把上述的图形描述一次:
       当客户端要求登陆服务器的时候,通过账号数据库验证,然后取出该账号对应的角色,然后告诉客户端你是我们的用户,然后由网关(我在图上没有体现)把该玩家连接到响应的GameSvr上.
       我们来分析这个图:客户端向服务器发送登陆请求,如果采用非阻塞式,使得各个客户端的请求形成非队列式,那么服务器压力不会很大,如果采用阻塞式,那么客户端感觉服务器处理速度就会很慢,玩家不答应,所以大多采用非阻塞式,处理速度快.而且玩家和账号数据库不是长期保持连接,只是保持一个心跳而已.这样就得出一个结论,用户在登陆的时候,对服务器不会造成多少压力.
       那么什么时候会造成压力呢?
       玩家走路,大家都知道,网络最主要的特点是同步信息,也就是说,当一个玩家走动以后,服务器首先要计算一次,当前玩家指的坐标是否正确,其次,服务器要下发消息,告诉周围的玩家,他现在在那里,怎么样的姿态存在.因为服务器会给一定范围内的玩家通知这些信息,造成服务器压力增多,因为服务器(GaemSvr)和玩家保持的是一个TCP的长连接,如果当前服务器或者一屏(或者说一定范围内的玩家相对比较多)的情况下,服务器要处理当前服务器上类似于上面描述的若干个这样的情况,造成服务器压力巨大.
       除了走路,还有什么会造成服务器压力大呢?
聊天,为什么说聊天会造成服务器压力比较大呢?因为当A对B说话,服务器需要寻找,当前B在那里,然后通知A,B在,你可以说话给他,这个时候A才可能和B说话.如果人相对比较多的话,可能造成服务器压力大.
       跨服务器行走,也会造成服务器压力巨大?
       因为当你从一个服务器跨到另外一个服务器的时候,服务器需要把第一个服务器上玩家的数据拷贝的另外一个服务器,然后初始化一个实体,然后再告诉DB,把这个人的数据存盘一次,然后再尝试跨服务器,如果跨不成功,如果成功,则把该数据初始化给本玩家,如果不可以,则另外处理,这样造成服务器的压力大.
       总上所述,不是所有的C/S结构的产品,我们以上来就模拟人多的情况怎么样,而是要分析,那块的压力真正的大,压力大的情况下会影响到游戏逻辑和数据在那里?需要冷静的分析这些情况,才可能有效的执行测试.
综上所述,我们知道网络的测试重点是相同通讯,数据同步和存储,那么在进行测试的时候,需要熟悉的了解各个部分相互通讯的模式是TCP还是UDP模式,那么各个模式有各个模式的特点.
       TCP是通讯协议是把数据包进行精包装,然后在网络链路中进行发送,它需要进行三次握手才可以确定数据包的发送与否,丢包的几率很小,但是自身有补偿机制,使得包数据传输的过程中可靠性大大加强但是缺点是速度相对很慢.
       UDP通讯是另外一种数据包传送模式,这种方式的特点是传送速度快,但是容易造成数据包丢弃.
       所以除了了解各个部分的通讯协议之外还需要了解,当丢包了以后,对数据包进行补偿的两种方法,第一种方法是把从丢失的第一个包到当前包作为一个整体的包,进行包的重播,这样的方法会使得从客户端看到通常我们在游戏中所出现的”卡”现象,还有另外一种补偿机制,就是把前面的数据包丢弃,然后播放最后一个数据包信息,这样就会在其他的客户端看到一些莫名其妙的现象.
网络游戏还有一个测试点，任务系统的测试，在网络游戏中，任务系统是贯穿整个世界的，他反映了玩家在各个时期所能面临的挑战。任务系统的测试要点
Ø       任务逻辑
Ø       任务性价比
Ø       任务系统奖励的条件
Ø       任务系统放弃的条件
Ø       任务系统接收物品的条件
Ø       跨等级交接任务
Ø       满足接或者交的任务的条件中其中的一个
Ø       任务描述，任务记事本的描述和状态，任务道具的各种操作
为什么把任务系统单独提出来说，是因为在游戏中任务和交易是游戏中最容易出错的地方，而且最容易导致整个游戏中所谓刷钱的地方，如果游戏中通货膨胀，就可能造成整个游戏数据无法跟踪或者跟踪没有意义。
箱子也是重点测试之一，所谓箱子，主要是指玩家的储物想，交易时候玩家的背包，为什么把这两个单独提出来，这两个在几中情况下最容易出错。
Ø       给箱子存东西，然后断线（考虑存储速度）
Ø       给箱子存东西后，然后不关闭箱子，背着箱子跑（触发存储状态的条件）
Ø       交易的时候，来回切换server，在两个server之间进行（寻找数据同步的错误）
Ø       在存储物品以后，马上断线，然后在server和client保持ping的过程中，重新连上（考虑TCP/IP的特点）
Ø       在存储物品的时候，不关闭储物箱，可以背着箱子乱跑（箱子其实计算到了玩家的负重了）
以上是存储和交易时候必须测试的点，这是每一款网络游戏都容易犯错误的地方。
在做压力测试的时候大家都知道很多概念，但是在实际的工作中怎么分解，了解得人还不是很多。我下面给大家做一个简单的介绍，因为我们在做压力测试的时候，如果在公司内部构建和我们产品运营时候相同的网络环境，相同的硬件支持的话，开销非常大，有些开销是无谓的，所以就出现了现在有的作压力测试的时候，得出结论是现在环境是否可以承受或者说能够承受到什么程度，关于压力测试的分解工作几乎没有，为什么做这些压力，这些数据对你以后有什么分析价值等我们做过透彻分析。
         很多人在使用诸如"容量评估"，"容量计划"，"趋势分析"和"预测" 等术语时，并没有真正理解这些词汇的含义。当有人提起"容量计划"时，通常是指他们的应用不能满足解决方案，而将被迫购买更多的硬件。
       我们需要针对具体业务做一个实际的例子，可能大家能够看的更加明白。
业务描述：   
硬件基本情况（服务器和未来上线的不同）
我们就分析一个业务，它是一个标准的C/S结构，我们从他的业务逻辑上分析它的压力点在哪里？然后结合实际情况，我们总结分析设计这些压力测试的点的方案。

那么根据业务本身，看来登陆的压力肯定是最大的，因为当登陆上去以后，玩家根据业务和本身需求，可以把各个服务器的压力减少进行调整，那么如何做和登陆服务器的压力测试呢，我们在开始工作之前需要获得几个数据：
第一，      按照原来服务器的设计，最多能容纳多少用户并发请求
第二，      对服务器性能占有率多少是能够接受的
第三，      对信息的处理方式是采用什么方式的（阻塞还是非阻塞）
第四，      单台服务器的处理能力和效率
接下来我们要做的事情就是：
第一，      准备测试数据
第二，      设计测试方案
第三，      总结测试数据进行分析
如何准备测试数据才能使得本次测试的有效性呢，主要分析我们的业务类型，以上图这个例子，我们只要发送一个合理的登陆请求，只要是一个合法的帐号就可以了，我们按照协议类型，开始制造测试数据，制造完成后我们来分析我们如何加压，假如我们的按照目前的规模服务器的处理能力是20000，按照5台来计算，那么单台服务器的处理能力是4000,那我们就开始利用单线程多进程的方法或者利用多台单客户端的形式伪造数据，然后让这些请求数据按照阻塞模式同时发送，可以制造同等压力，在这个过程中我们需要做的事情
第一，      我们需要观察服务器的I/O,内存，CPU
第二，      我们需要观察服务器对信息的处理能力（需要通过客户端对发出信息后得到服务端信息的反馈进行累积统计），长时间观察这个数据的变化，例如1个小时
第三，      慢慢减少压力，看看效率情况
如果在我们加压过程中服务器的cpu和内存持续增高，说明有漏内存，如果我们请求响应速度持续变慢，说明server队信息的处理能力可能有问题，如果在减少压力的过程中仍然表现不出来server的处理效率提高，说明server没有释放资源。
其实服务器的压力测试，在我看来，无非要做两个事情，你需要清楚的了解此类业务的服务请求，其次，你需要清楚地了解各个数据分析的过程。

WEB测试要点       Web测试的要点其实很多，但是Web测试的着力点其实不多，因为基于Web现在有两个重点，一种是基于平面的静态的，只是更新新闻，那么这个的测试点相对简单，主要是各个链接正确性，服务器浏览量等，还有另外一种就是基于Web的P To P的通讯，需要注册，牵扯到用户信息，那么这些测试重点在于P To P通讯的顺畅性，数据的可靠性。
       我还是举例子说明问题。1999年网络在中国起步并风靡，它丰富了人们的生活，提供了更多的咨询信息。各种基于互联网的业务也相继展开。那么这些业务上线面临着什么?
就web测试点来说，有一些特别需要注意的，url地址，看似一个连接地址，非常重要，重要在那里，因为URL是包含了用户请求的信息的跳转，所以URL包含了部分用户的信息。
测试的时候需要注意几个问题
²       URL所有包含用户信息的牵扯到用户隐私的需要加密
²       URL中包含用户信息切牵扯到双方数据交互的需要完全信赖的确认信息
²       URL需要过滤一些通用的字符，例如”.”,”.\”等，以免对服务端目录造成伤害
²       在页面中需要检查的内容：页面中所有的编辑框中需要跟内容匹配，有人恶意在里面输入SQL的语句，使得其他的信息就暴露在外面
²       删除server系统下的bak文件，原因是商家一般会做一些市场活动，那么会暂时的生成一些页面，到活动结束后，把正式文件删除掉了，但是备份文件没有删除，所以就会造成用户还可以访问被废除的活动页面。
²       有关验证的内容，建议服务断和客户断双重检查，以免有些伪装数据欺骗客户端代码，造成server不经过验证的情况下提供数据
²       需要对Cookie中的数据加以包含，一般的用户对这个数据不注意，也无法意识到他的重要性，所以经常被别人利用，所以商家需要保护消费者的数据安全。
²       在接收传递过来的服务端程序对数据类型需要进行判断，包括长度和类型，以免出现“string overflow”。
       我下面就说几条：
第一，      性能，性能测试什么呢？
性能主要是指网络吞吐量，响应时间（单用户单独和单服务器能承载用户上满情况下单用户相应），IO量的大小，数据库查询速度。
包括一下几个方面：
第一，      单个用户发送单步请求到处理完成所花费的时间；
第二，      单个用户发送请求整个流程所需要的时间
第三，      在服务器负荷达到单个服务器处理能力情况下单步请求响应时间
第四，      在服务器负荷达到最高的情况下，整个流程处理请求处理的响应时间
第五，      在请求达到负荷的情况下IO量的大小，知道输入输出量的大小，以及写磁盘的频率

修改产品构思

创建/修改场景

修正性能指标

验证和确认模型

评估性能风险

确定关键案例

选择关键性能场景

建立性能目标

构造性能模型

增加软件资源需求

增加硬件资源需求

性能评估模型

第二，      安全性
安全性主要包括当前用户的安全性，总体用户的安全性，提交过程数据的安全性，用户数据的死锁现象等。
现在我们分析基于Web形式，用户发送请求，在发送过程中有可能出现什么问题呢？用户的数据在以网络包传输的过程中和在队列中等待处理出现问题？基于web的特性，我们平常所能触到的就几种做法（普通，非高手），第一，分析和修改URL地址，导致真正的请求被修改；第二，拦截数据包，修改数据包信息，导致真正的请求被修改；第三，攻击服务器，使得等待队列中的请求信息被修改。

用户请求

形成服务器处理队列

服务器处理业务

第三，      操作合理性
²       操作过程是否合理，包括操作流程，操作的易用性等多多考虑。
²       人性化，包括页面的层次重要信息页面的引导，页面的跳转
²       内容链接，内容的更新频率包括排版

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