呵呵，群上的高手们在谈测试的培训，我不是做培训的，但我也参加过培训和招聘到测试培训的人。针对培训的效果这里不说了。我想说说测试的自动化。

首先，究其自动化火爆的原因，我想有以下几个，首先，觉得自动化了可以减少人工工作量。其次，自动化后可以让领导看到测试部门的直接成效。还有，自动化可能让个人觉得更有成就感。毕竟，天天重复的手工测试和自动化给人带来的满足感是不可同日而语的。

但实际上呢？自动化真正减少了你的工作量吗？自动化让领导看到了成效了吗？自动化让你的价值提高了吗？

第一个。自动化减少了手工的工作量了吗？

　　　首先，你要理解自动化也是软件开发，是软件开发就要有投入，有投入就要计算一下你的投入和回报。你可能听了很多微软的培训，自动化细到某一个函数，但微软的某自动化，实现后未来的１０年都在用（微软的老师说的），而你的自动化呢？？　未来的一年，两年？还是一个月，两个月？　　如果你是项目型，并且随着市场或需要的变化，程序需要不断变更的情况下，你的自动化开发和维护会占用多长时间？　你的自动化完成后，能节省你的工作量吗？　还是让你陷入了另一个痛苦：天天抱怨开发这儿又改了，那儿又改了。

　　　所以在你考虑自动化前，先计算一下投入产品比吧。　我个人觉得，如果你把测试流程做好了，把开发生命周期中的前期的评审做好了，产品的质量会有很大的改善的，而不是把精力花费在自动化测试上。

第二个。自动化让领导看到测试部有技术积累，显的有成效。

　　　我觉得领导认为你的测试部技术比较差，或者说测试没有什么效果，和你实现了自动化是没有关系的。　可能领导说，你的测试连个自动化也没有，人家很多公司都有了。所以我们也搞一个。　呵呵，如果你想讨好领导，那没有问题啊，做吧！！　　如果自动化让你的前途更光明，那还犹豫什么呢？　　问题是你想过没有？　当你的自动化某一天不再能够运行，或者你的自动化对产品的质量没有什么大的改善的情况下，你又怎么对领导交待当初你做自动化的动机呢？难道你就说，领导让做就做啊，现在没有什么用也不关我事。

可我觉得，这关你事的。　首先，领导对可能测试不了解。他想到做什么就做什么。但做为专业的测试人员不应该这么想。提高软件测试部门的威信有很多种方式。实现自动化是一种，但不是唯一。请你在做自动化之前行想想：自动化能帮助提高产品的质量吗？能增加测试的深度或广度吗？让增加领导或开发部门对测试部门的认同度吗？想好了你再做吧。

第三个。自动化能让自己的价值提高。　呵呵。我觉得完全错误。　外国的思维、理念传到中国就成了有特色的了。　很多外面的企业是实现了自动化，也写了很多书，包括最佳实践之类的。但人家是有基础的。而传到中国，就变成手工测试是低下的，自动化测试是高尚的了。　说到底没有测试的基础，理论，没有测试分析的能力，自动化不就是一个初级程序员吗？难道懂得录制回放，就高人一等了？？　虽然这样说有点偏激，但有一些人就是有这样的想法。　招聘也一样，一年测试经验，刚刚学会填写BUG，就要求会用自动化工具。殊不知，会用是一个概念，而在实际中能用又是一个概念。　找个高中山，培训两天都知道录制，回放和基本的参数化。真不知道技术含量在哪里？　

　而且，自动化测试最强调的是架构，没有架构，就写脚本，简直是象没有设计，就盖房子一样，如果不倒那是奇迹了。

　而且，我并不认为手工测试是低下的工作。　BUG的发现是靠想象力和创造力的。不是只懂得0和1的计算机可以替代的。

　呵呵，一通胡说。乱七八糟。

一、     什么是意识？

意识是生物和非生物共同具有的一般规定和本质。是人脑从生物和非生物的行为和存在中抽取出来的普遍性规定，是存在于世界万物之中的绝对抽象事物。

意识和本能的最大区别在于，前者是在物质作用下形成的，后者不需要物质作用是先天具有的。我们在刚出生的时候，就知道吃、喝、拉、撒、睡这五件事，并没有外界作用。

而意识的形成一定要有外界的作用，意识可以分为深层意识（潜意识）和浅层意识（表意识）。 表意识在你接触到外界事务时，会进行确认、分析、决定，是一个思考的过程；而潜意识在我们使用的时候，我们甚至都不会注意到它的存在。就象天生就会一样。

二、     什么是测试意识？

首先，测试意识是一种意识，需要外界的作用，测试不是一种本能。

而当你拿到一个待测试软件后，你一般会对软件进行分析、思考、行动一系列的过程，是你的表意识在起作用。而一般人们说的，高手一眼就能看出问题来，让他自己说为什么？他却不知道，这就是潜意识在起作用了。那我们下面说的测试意识就是指测试的潜意识。

三、     测试意识可以通过学习掌握吗？

人们通过表意识进行学习和思考，所获得的新知识和新技能也首先表现为表意识，但如果同一种学习过程重复不断地进行（这样的过程叫做“强化训练”），那么大脑对所获得的新知识和技能的运用就从表意识就转化成了潜意识，即形成了条件反射

所以潜意识是可以学习和修炼的。不过这是一个比较深层次的修炼。它对我们的学习和成长非常重要。只要有决心，有毅力学习，就一定会达到目标的。不是那个人天生就是测试专家，每个专家的成长都必须经过学习和实践，然后不断地总结、升华，然后才有可能达成自己的目标，或者更上一层楼。

四、     测试潜意识的表现

1、用户思维

   在我们初做测试的时候，很多时候在站在开发的角度，或者是测试的角度来找BUG的。但实际上，测试要求的是以用户为中心，一切以用户为前提。那么在你做测试的时候，会有意识地站在用户的角度去考虑，这个提示是否合理，是否人性化。这个界面，是否符合用户的使用。久而久之，就形成了潜意识。看到软件，就是站在用户的角度上思考，去找出软件中与用户习惯，用户思维不一致的地方，这就是用户思维。

2、只要是软件，就有错误的意识

    你刚学测试的时候，看到软件，尤其是高手写的软件，并不觉得里面就一定有BUG。但只要是软件，就有错误的，因为软件是人写的，因为是人都会犯错误。这种观念被灌输多了，看到软件，立即就想找BUG了

3、测试方法意识

你刚学习测试时，对于回归测试，就要对照一下回归测试的方法，一点一点分析要测试哪些相关的范围，测试到怎样的程度。如果有了回归测试方法的意识，一看到开发的修改，马上就说，这个BUG可能影响那些功能，影响有多大。你把XX几个用例重新跑一下就行了。

五、     怎么获得测试意识？

1、学习；2、实践；3、总结；4、升华

首先，学习是获取知识的一个重要过程，如果通过学习获取了知识，当遇到问题时，虽然你一下子想不出怎么解决，但你可以想一下，你学习到的方法，参照学习过的东西去得出一个解决方案。此时，只是表意识在起作用。

在通过不断的实践后，你将你的知识运用到实践中解决了问题，那些这些知识在你的意识里更加牢固。但此时，你可能只是具备解决同样或类似问题的能力。如在某个测试工具中遇到了一个问题解决了，但在另一个测试工具中遇到问题，你却不知道如何处理。

总结就是将你的经历沉淀，成为经验。也许一些人经历到一个问题后，就不会在同一个地方跌倒。而另一些人遇到同样的问题时，却没有更好的解决方法。这就是总结的能力不同。所以我们说经验，并不是说你经历过多少个项目，而是说你经历过了项目，从项目中学到了多少东西，成为你自己的能力。

升华：从量变到质变。  量是你的积累，就是你的经验。质变，就是你整个能力的提升。需要多少量的积累，才能上升到质的变化。这要看你的努力，以及你的目标是否明确、专注。这在职业生涯规划中也有体现。如果你的职业规划不明确，或者在你中间与职业目标有偏离，都无法在你的职业中加上重的砝码，这就是有些人几年就可能成功，有些人却总在一个平台上绕圈。  升华还表现在，你对本质的抽象。如测试管理工具，不论是QC、TESTLINK、还是其它的测试管理工具，只要软件测试的过程没有重要的变化，那么所有的这些工具就都是相类似的。 测试方法也一样，你测试软件和你测试一根铅笔并没有什么本质的不同。所以建议下次面试别人的同事，就不用拿来搞个出其不意了。

话说刘姥姥虽然听说过很多次性能测试，但一直没有机会到性能测试园子里转转，结识一下性能测试园的哥儿们，姐儿们。 今天好不容易有机会，就想着来开开眼见，长长进识。想自己活了这么大年纪了，终于有机会认识一下那含玉而生的公子哥儿，更是眼口鼻都快凑一块儿了。

  哇，园子这么大，哥儿们姐儿们这么多，刘姥姥有点心慌，把自己念叨了一路的问题怯生生地说了出来，生怕哪们哥儿姐儿一嗤鼻儿，把自己给踢出园去。

刘姥姥09:19:15

请把tomcat的优化设置逐项列出来，形成正规文档。

开发让列TOMCAT优化内容

  宝玉09:19:17

强啊

  刘姥姥09:19:49

什么强?? 我都不参加测试,怎么知道如何优化呢?

  宝玉09:20:22

可以的

  宝玉09:20:30

我还巴不得我们这边的开发提这样的需求

  刘姥姥09:20:52

这也算需求? 你测试的时候自己调就行了

  宝玉09:21:41

那不行

  刘姥姥09:21:50

除了JVM,和连接数,还要调整什么啊? 我不太清楚

  宝玉09:21:53

测试就是测试，我可以告诉你怎么调，但我不能直接调

  刘姥姥09:22:27

这是第三方验证要求开发提供的.开发不会,直接让我去调.  

  刘姥姥09:22:53

而我认为这个东西不是死的,一定调到多少就是最优化的,那我怎么给个确定的值呢?

  宝玉09:22:59

测试啊

  宝玉09:23:04

通过测试来确定

  宝玉09:23:10

这个东西肯定不是死的

  刘姥姥09:23:18

我给了值,人家第三方做完性能测试,就定论了

  宝玉09:23:26

性能最优就是各个部分达到平衡

  刘姥姥09:23:28

那有我再调整的机会呢

  宝玉09:23:39

那就得你测试呀

  宝玉09:23:54

通过测试定出个最优的值来，然后再交给第三方验收啊

  刘姥姥09:23:55

不是我测试啊,是第三方机构测试啊

  宝玉09:24:03

晕了

  宝玉09:24:07

不知道你们是个什么关系

  宝玉09:24:17

第三方是个验收吧

  刘姥姥09:24:24

第三方测试

  宝玉09:24:29

但你们给出去的东西要保证是最好的是吧

  刘姥姥09:24:50

我们给出的东西,2月份测试过,有问题,但还是给出去了,

  刘姥姥09:25:39

象JVM,我都不知道服务器有多少内存,怎么知道要给JVM多少呢?   开发就一句话.我就空写吗?

  宝玉09:26:12

那怎么测试的

  刘姥姥09:26:13

我自己内部测试过,但环境相差太远,没有什么参考价值了

  刘姥姥09:28:02

现在就是,第三方测试,结果不好.开发就说TOMCAT没有调优.第三方就说,那你说吧,改成什么?我们再测

  刘姥姥09:45:55

给个参考吧.不要说一定调成多少.就说哪些能调,大致的范围是怎么样

  秦钟09:47:00

你写个很学术的东西

比如说影响JAVA程序性能的原因，以及各参数影响到哪些

  刘姥姥09:49:18

我就写TOMCAT的就行了吧.其它不理它

  秦钟09:49:27

然后就说，JAVA性能调优是一个系统的、复杂的工作，需要根据软件在具体硬件上的具体表现来调整

  宝玉09:49:34

是的

  秦钟09:49:35

调整可能需要进行多次

  宝玉09:49:45

不可能给一个确定的值的

  宝玉09:50:04

这个要跟你的硬件，其它的组件相关的

  刘姥姥09:50:04

真是高难度啊

  宝玉09:50:07

很明显是这样的

  秦钟09:50:48

本来就跟硬件和你的软件架构（主要是调用关系，以及内存申请、释放……）有关

所以说是一个系统的工作嘛

  刘姥姥11:01:50

TOMCAT的参数调整:

首先TOMCAT的调整的前提是程序没有问题。

一、       调整JVM

Sun的JVM应该是多数情况下的第一选择。在满足项目要求的前提下可以选用版本较高的JVM版本，一般来说高版本产品在速度和效率上比低版本会有改进。

由 于Jvm系统垃圾收集机制的存在，在高负载情况下如果能根据系统的具体要求有效的调整最优化堆的大小，也可以起到一定优化作用。

JVM有两个参数：

参数       描述      

-Xms<size>    JVM初始化堆的大小  

-Xmx<size>    JVM堆的最大值  

如果堆设置较大，则GC次 数变少，但每次花费较长时间，从而导致系统处理能力抖动较大；如果堆设置较小，则GC变得频繁，虽然对系统性能影响较小，但频繁的GC也会耗费系统资源。

而堆的最大值受限于系统使用的物理内存。一般使用数据量较大的应用程序会使用持久对象，内存使用有可能迅速地增长。当应用程序需要的内存超出堆的最大值时虚拟机就会提示内存溢出，并且导致应用服务崩溃。因此一般建议堆的最大值设置为可用内存的最大值的80%。

二、       调整线程数：

属性名    描述      

maxThreads    Tomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数。

acceptCount   指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。   

connnectionTimeout     网络连接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。      

minSpareThreads   Tomcat初始化时创建的线程数。     

maxSpareThreads 一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。 

线程数可以大致上用 “同时在线人数*每秒用户操作次数*系统平均操作时间” 来计算。

最好的方式是多设置几次并且进行测试，观察响应时间和内存使用情况。在不同的机器、操作系统或虚拟机组合的情况下可能会不同，而且并不是所有人的web站点的流量都是一样的，因此没有一刀切的方案来确定线程数的值。

  刘姥姥11:02:24

线程数可以大致上用 “同时在线人数*每秒用户操作次数*系统平均操作时间” 来计算。

这个怎么算的?

  宝玉11:04:40

就这样算啊，有问题吗

  刘姥姥11:04:53

系统平均操作时间是什么意思?

  宝玉11:06:25

就是处理的平均时间吧，不可能给得很准确，只是大致的估算

  宝玉11:06:32

最好的方法还是通过测试来确定

  刘姥姥11:07:15

每秒用户操作次数是什么?

  宝玉11:07:40

就是每秒的连接吧

操作tomcat主要就体现在连接数上

  刘姥姥11:08:30

那不直接看看测试结果,连接数有多少不就行了

  宝玉11:09:15

你不是想确定这个线程数设多少好吗

  刘姥姥11:09:22

是啊,

  宝玉11:09:26

我就说了，通过测试的方式来确定是最好了

  刘姥姥11:09:34

好,

我就这样写

OH，有点醒悟了。

 原来啊！TOMCAT调优是要达到平衡，不能只往一处死劲调。

         JAVA性能调优是一个系统的、复杂的工作，需要根据软件在具体硬件上的具体表现来调整。不能乱给确定值的，刘姥姥一直以为象种南瓜一样呢？到那里种都差不多。

         还要通过测试的方式确定连接数，不断地进行调整。真是和种南瓜有点不一样呢。

尤其是那个秦钟，不但教我怎么调，还教我怎么写文档，主子才会喜欢。是啊，想想，这次带的南瓜只是用麻袋装着，是有点难看了。下次得在麻袋上绣几朵花。

刘姥姥觉得不仅解决了自己的难题，还学会了做人的道理，心里想：到底是性能测试园，就是不一样，不过今天那些姐儿们都没有搭理自己，是问题不够专业？还是自己家种的南瓜不好吃？ 看来下次要带点别的来。

某公司测试环境规划方案（全是瞎编的）

假设1：目前测试部门共有20名测试人员，分为三个小组，其中功能测试小组15人、性能测试小组2人，兼容性/界面测试小组3人。

假设2：未来3年，测试部门的扩大比例为50%，到30人。其中功能测试人员23人，性能测试人员3人，兼容性/界面测试人员4人。

假设3：公司的项目有CS架构，也有BS架构。目前的项目有80%是CS结构，有20%是BS结构。未来的发展趋势要全部转为BS结构。

假设4：项目关注的测试有：功能、性能、兼容；其它类型的测试也要包含，但不考虑单独申购机器，可以在总预算上预留一部分进行。

假设5：只考虑机器的数量，以最大程序地节约成本，但不考虑机器硬件配置导致的价格差异。

假设6：兼容性只考虑WINDOWS平台，包括WIN2K、WINXP、WIN2003、VISTA。浏览器：IE5.5、IE 6.0 、IE7.0、遨游、FIXFOX（不考虑版本）。其它如果项目临时需要考虑，可以借用其它机器完成。

一、硬件需求：

首先：功能测试，其使用的机器都在自己的测试机，为了保证测试环境的干净，每位测试人员都会有一台工作机和一台测试机（理想状况，如果没有机子可以使用虚拟机进行）。所需数15――23台。

 其次：兼容性测试，根据公司的产品性质，对兼容性的考虑，需要5－10台，如果5台机的话，每台机需要安装2个操作系统（估算的）。

性能测试：（应该有专门的规划）。CS结构假设需要支持200个并发（多数项目如此），而每个客户端发起的请求数是100个，则需要2台服务器，1台控制机（服务器）， 1台数据库服务器，1台应用服务器，共4台。

BS结构的并发是5000个，每个客户端（服务器）支持1000个并发，则需要5台服务器，1台控制器（服务器），1台数据库服务器，1台应用服务器，共8台。

  考虑如果两类项目不会同时进行测试的话，所需要的机器数量（满足BS就行）： 8台服务器，如果项目有并发的情况，需要的机器为12台服务器。 基于成本考虑，可以购买10台服务器。如果有项目并行进行性能测试时，可以临时借用功能测试机来完成。（服务器配置下面再谈。）

总结：20台台式机+7台服务器（最小配置）

      33台台式机+12台服务器（最大配置）

  推荐配置：30台台式机+10台服务器。

其它需求（要问相关部门），：能放这么多台式机的空间最好是单独的房间，能承受重量、隔音、隔潮，安装2匹的空调，UPS电源。 机架（不知道需要多少）。。。 这些找别人考虑吧。

二、台式机和硬件服务器配置

  台式机：2G内存。 双CPU(2.3以上)，200G空间

  服务器：8G内存。 8颗CPU（2.3以上），200G空间

具体配置是多少不知道，不过最好保持一致。

三、软件（如果要正版的话）

  如：WIN2K+SP2   两套

      ORALCE10G   一套

      LR 8.1        一套

。。。。。。。。。。。

四、环境管理

  1）需要相应的文档，如环境管理办法

  2）如果可能，做一个软件来实现

  3)  可能还需要一个环境管理员

五、预算

   做个表格，看看共有多少钱，就OK

报名参加了某测试认证的培训和考试，我觉得都不错，只是一点，觉得考试题目比较变态。

我看了某测试认证的样例试题，是比较标准化的，岐义也少，问题在大纲中都能找到答案，但样例题目比较少，也没有办法看出整个试题的水平的，猜想一下，应该是不错的。

而在中国的考试是中国人自己出的题目，不象PMP是从英语翻译过来的。可能是由于版权的问题吧。不管是因为什么，也不能说明出题老师的水平高低，只是我对试题有一些个人的看法吧。

看法1：题目全是单选题目，但实际上，我看到的80%都是多选，就是给出1、2、3、4、5.。。最后的试题选项是A:1\2\3  B:2、3、4之类的。 更多地象中国考试的多项选择题。 这没有什么问题，只是感觉不爽，呵呵

看法2：给出的答案在大纲中找不到依据。象一题目，交付客户阶段的测试是什么？我觉得是确认测试或验收测试，但答案中没有这个选项，那么在系统测试和回归测试二者之间你会选择哪一个呢？

    答案是回归测试。 但回归测试是每个阶段都会做的，包括单元测试也会进行回归，你能认为它与答案更加相近吗？ 如果是系统测试后的回归测试才比较可能吧。

    这个题目存在的问题是：1）大纲中没有答案，也就是大纲中明确的确认测试答案中没有。2）可能出题者理所当然地认为回归测试就是系统测试后的回归。这与大纲相违背。

看法3：一些答案是错误的。 如风险，答案是：可能产生负面的影响在项目中出现的问题或隐藏的问题。 这里面存在两个问题。1）负面的影响，我们知道，风险会产生正面的或者负面的影响，不能单单是负面，当然，我们一般管控的是负面的风险，这个可以接受。那么第2点就不能接受了。 2）项目中出现的问题还算是风险吗？？

看法4：有岐义的问题。如引入自动化工具次要考虑的。  1）我们认为，引入自动化工具前期测试的时候，会根据公司的实际情况去判断哪些是主要考虑因素？哪些是次要因素？

 而答案在两个有疑问的地方：1、工具使用的二次开发代码；2、工具后期提供的售后支持。

 是所有的公司都必须这样吗？我有超强的C语言开发人员，为什么不会先考虑工具支持的语言呢？并且工具后期提供的售后支持如果是昂贵的，可能直接就不考虑了。

   2） 什么是次要的考虑因素呢？ 你在引入自动化工具是要这样选择吗？三个主要，一个次要。 我个人认为只有二个是主要，二个是次要也可以啊！！

  并且大纲中介绍引入工具，也只是建议列出考虑因素，按照公司的实际情况考虑吧。

 所以整个试题的感觉，比较怪，觉得不合情理，用一句不好听的话来说：比较变态。

  当然，不是对培训机构或考试机构或出题老师不满意，只是感觉如此。呵呵，所以发泄一下

１、起源

探索性测试被认为最先由 Cem Kaner et. al. 在 Testing Computer Software [KAN99] 中定义，此后其他人（包括 James Bach）的工作使它得以普及。

 为什么叫探索性测试，因为是一边测试一边探索。

２、定义：探索性测试是一个交互式的过程。在某种意义上讲是一个自由形式的测试过程，与人们说的游击式测试，直觉性测试有些相类似的地方。但探索性测试包含指定的任务、目标、交付物，所以与游击式测试又不同，而是形成了一个系统化的过程。

３、包含的五元素：

产品探索（Product Exploration）。探索和记录产品的目的和功能，数据类型，潜在的不稳定域。执行探索的能力依赖于你对技术的理解，你对产品信息和它潜在的用户的掌握，以及你花费了多少时间做这项工作。

测试设计（Test Design.）。决定操作、观察和评估产品的战略。

测试执行（Test Execution）。操作产品，观察产品的行为，使用这些信息构建产品如何运作的假定。

启发（Heuristics）。是帮助你决定要测试什么，如何测试的一系列指引或规则。

可检查的结果（Reviewable Results）。探索式测试是一个结果导向的过程。一旦你产生的交付物满足了特定的需求，测试就结束。对于测试测试结果是可以检查的、并能够与标准对比，这点尤为重要。

　　作为测试人员，你必须准备从任何角度向测试经理解释你的工作，并且展示它是怎么样满足已文档化的需求的。

４、优点：

　１）在某些情况下，它的效率比脚本测试高出很多个数量级。

　２）节省很多工作。尤其是前期的文档工作。

５、缺点（我认为）

　１）效率高，测试质量不一定好。要看性价比了。

　２）可能适用于某些项目，如项目工期紧张，需求不明白、变更太频繁等。。

　３）主要依赖于测试员的技能和知识来指导测试。人是最不可靠的。

   一个测试同行问起我对测试培训的理解，呵呵，聊了很久，自己介绍了一些自己的算法，也颇有些感触。

    测试培训是很晚才发展起来的，我在2000年的时候做测试，那会儿还看不到几本测试的书籍，也看不到几家测试的论坛。上海有

51testing,北京的测试时代，广州的测试管理，那会都还不成气候，我记得我在测试管理当了一段时间的版主，后来朋友懒的更新程序，我也

懒的去讲解问题，慢慢也就作罢了。

    这几年随着客户对质量的要求越来越高，外包测试越来越多，CMM/CMMI的引入，都为测试提供了大好的机会，所以，测试的书籍一下子多

的让人眼花缭乱，测试培训也慢慢多了起来，测试的论坛更是一个又一个，尤其是51testing，渐渐成了气候。

    随着市场的需求越来越大，有越来越多的同事加入到测试行业，更加带动了测试培训事业的发展，测试培训行业的前景如何呢？就我个人

理解，是前途光明，但对做培训的企业或个人来说，不见的是路路畅通。

    1、培训的对象： 个人用户和企业用户

         其中，个人用户培训的目的可能是为了增加知识，也可能是就业的敲门砖，或者就是为了一纸证书，提高MONEY。在国内的教育不能

满足市场的情况下，培训显的更加可口。
  
        而企业客户可能更多的专注于提高测试团队的能力，建立测试过程，或者是某一种专业技术/某一特定领域的测试培训，当然也有用来

提高口碑和竞标时的实力的。

     2、培训的内容:  入门（职）培训，某一种技术培训，流程培训
  
        入门培训：多是针对新手或者是其它行业、希望从事测试行业的人。因为测试是一种较看重经验的职业，所以没有经验的人找工作很

难，参加个培训，就是希望自己能迈进了这个门槛；
   
                 这一类的培训多是非常系统的，规范的。所以也有很多工作了一年半载的人去参加，但这种培训又多是不太适用的。因为现

实与理论是相关甚远的。全部把书本上，微软、RUP等规范的流程搬进来，在中国没有几家公司能执行的。也就成了纸上谈兵了。

       技术培训：一般指强化或提高级的。 现在测试的分类越来越细，技术越来越深入，所以针对于某种技术的培训也就越来越多，象性能

测试、安全测试、或者某种工具在测试中的利用等等。
         
                 这一类的测试培训是比较深入的，但培训时间比较短，象性能测试，你没有很多实践的经验，只靠三五天的培训是没有什么

效果的。但如果你已经有了一定的水平，在培训上也许根本学不到什么东西，因为培训要兼顾很多人，而参加培训的人不是每个人都有一定的

水平的。 其实这种最好是买了工具，遇到问题后去问技术支持。效果可能更好些

       流程培训：一般针对企业用户。培训的方式可能是把自己的成功的经验介绍给你，也可能是根据你公司的具体情况定制流程。这种培训是比较有效的。 在你百思不得其解的时候，有醍醐灌顶的功效吧。

     3、开办培训班的背景：成功企业，如微软。知名论坛，象51TESTING。还有专门的技术培训学校，如青鸟。还有一些评测中心，有一部分成功经验。  至于培训的好，坏，那只能留给学员评价了。

     我的观点：老师必须要有经验。还要知理论。

至于我自己,是不去参加的了.因为我有理论,有经验,并且很自大.当然免费的除外. 学习多点当然是好的,不过要花很多钱就心疼了.

参加微软测试培训的收获

1。 高层领导必须查看BUG，以决定BUG的优先级和资源的调配

    前提：必须保证BUG的有效性

2。流程中尽量减少任何的冗余环节。

3。时间或资源不具备的时候，一定有其它的方法解决问题。 但在绕过问题后，一定要想法彻底解决问题。

4。自动化测试难度的根源：IN-PROCESS。 不依赖于前一步，完成的抽象化。

5。从BUG的发现转向BUG的预防。在发布代码前由开发人员先发现BUG并解决。 测试的角色转为测试程序的开发和支持。

6。BUILD中DOA。 Dead on arrive.

7. BUG Bash.

8.自动化测试体系。  数据库+运行平台+管控。 TOP Builder从格式化硬盘开始。

9。测试输入的抽象化--数据驱动（900多种输入）

10。基于模块的测试（全部覆盖）和基于场景的测试（覆盖关键用例）

现象：1、在单脚本执行10次迭代没有问题。2、在Controller中并发执行出现此错误。3、错误总定位在程序是某一行。4、失败的用户的迭代次数都相同。

方法：1、排除了程序问题
    
      2、排除了服务器防火墙、弑毒软件问题

      3、使用IP 欺骗无效。

原因：是参数问题。

      1）、参数是使用EXCEL表，用 micro query生成的。结果小数点后的0被处理成了空值。
     
      2）、而空值在BUFFER里传送给服务器后，服务器程序不识别，连接被强制关闭。

教训啊！无论多少个参数，一定要确认参数无错误。

快速测试读书笔记（一）
分类的软件测量指标示例

分类            软件测试指标

规模             编写的总代码行数
                   注释行数
                   变量声明总数
                   总空行数
                   功能点数
                   对象数

生产效率           花在项目上的工作小时数
                   花在每个对象上的工作小时数
                   每个对象变更的次数 

可维护性           传递给每个对象的参数个数
                   每个对象的方法数
                   使用某个方法的对象个数
                   每个对象中判断点的个数
                   每个对象的控制流复杂度
                   每个对象的代码行数
                   每个对象的注释行数
                   每个对象的数据声明数
                   每个对象中的直接分支数
                   每个对象的输入输出数

    缺陷追踪           每个缺陷的严重性
                       每个缺陷的位置
                       每个缺陷的修正方式
                       每个缺陷的负责人
                       缺陷影响到的代码行数
                       发现一个缺陷所需的时间
                       修正一个缺陷所需的时间
                       修正每个缺陷进行尝试的次数
                       每个缺陷修正导致的新缺陷数
 

    质量               缺陷的总数
                       每个对象中的缺陷数
                       每千行代码中的平均缺陷数
                       平均无故障运行时间
                       编译器发现的缺陷的个数