绩效评估毫无乐趣可言。相反，它往往令人感到十分懊恼，因为经理人的绩效评估方式总是十分愚蠢，甚至把这一个对每个人来说都非常重要的一件事全都搞砸了。

　　第1种愚蠢行为：把太多的时间浪费在绩效评估上，而不是花在绩效计划或持续不断的绩效交流上。绩效评估是一个随时都在进行的过程的最后一个环节。一个基于经理人与员工之间的良好沟通的环节。所以，我们应该把更多的时间用于预防可能影响绩效的问题，而不应该集中在年终来评估绩效。如果经理人懂得细水长流，那么，评估过程可能很简单，而且也可能十分愉快，因为这样的评估结果往往不会出人意料。

　　第2种愚蠢行为：将员工进行比较。想破坏感情、挫伤士气、破坏团队、互相猜忌吗?那就给员工排名次，或对员工进行比较吧!这方法准行。此外，经理人不仅在员工之间制造了种种磨擦，而且可能成为众矢之的。这就是经理人所获得的奖赏。

　　第3种愚蠢的行为：忘了评估的目的在于提高，而不在于批评。进行绩效评估的目的是为了提高绩效，而不是找一个典型，进行批评。忘记这一点的经理人最后培养出来的员工可能不再信任他们，或者无法忍受他们。那是因为批评是毫无意义的，而且也于事无补。如果说绩效评估有什么意义的话，那就是让经理人和员工携起手来，共同前进。

　　第4种愚蠢行为：认为某种评估表是客观的、不偏不倚的工具。许多公司利用评估表(比如，分为5等)来评估员工。他们之所以乐意这么做，恐怕是因为这是这种方法特别快，但它未必就是正确的方法。一旦经理人觉得这种等级划分是“正确的”，或是客观的，那么问题就出现了，因为这种评估充其量只能是主观的、不正确的。比方说，你让两个人来评估同一名员工，你就会发现，评估结果很可能相去甚远。这就是主观评估的表现。你应该不断地提醒自己：划分等级是主观的、评估表是主观的、评估表是不可行的。

　　第5种愚蠢行为：如果个人工资与绩效评估脱钩的话，就停止评估。这种现象相当普通。经理人之所以进行绩效评估往往是为了将其结果作为加薪的依据。当员工工资达到顶点时，或者说工资已经和评估与绩效脱钩时，经理人就提不起兴趣。多么愚蠢的想法啊!绩效评估是为了提高绩效，而不仅仅是为了加工资(虽然有些人的确这么认为)。再者，无论有钱还是没钱，每个人都希望人们对他们的工作作出反馈，。

　　第6种愚蠢行为：经理人相信自己可以精确地评估员工.经理人自欺欺人地认为，他们可以精确地评估员工的绩效，事实上，他们可能根本没有见过员工工作的过程，甚至没有见过员工工作的效果。因此，准确评估是根本不可能的。大多数的经理人都不可能为了准确评估员工而长时期地监督员工工作。然而，经理人又喜欢这么做，或者有充裕的时间这么做。同时，有哪些员工希望经理居高临下地观察自己的一举一动呢?所以，在评估的过程中，我们希望经理和员工能齐心协力。

　　第7种愚蠢行为：取消或推迟评估会议。这类事情经常发生。我猜想这是因为评估根本就不深入人心，所以，经理人只好一拖再拖了。为什么取消或推迟评估会议会产生巨大的负面影响呢?它可能会给员工造成这么一种印象：评估是不重要的、虚假的。如果经理人不愿意举行评估，那么，他们就不必评估了。员工不是傻瓜，经理人到底会不会重视评估，他们一看就知道。

　　第8种愚蠢行为：衡量或评估小事。生活就是如此：最容易衡量，最容易评估的就是工作中的琐事。经理人热衷于把客户服务定义为 “电话铃响三声内接电话”，或诸如此类的规定。如果你希望这样评估的话，那太容易不过了。真正不容易评估的是服务的整体质量，那些能够吸引客户、留住客户的服务的整体质量。衡量全面客户服务质量是困难的，所以许多经理人并不希望这么做，而希望评估琐事。

　　第9种愚蠢行为：在评估的过程中让员工措手不及。你希望真正浪费时间，希望产生不足取的绩效吗?试试这种方法一定错不了。一整年都没见经理人和员工交谈。员工搞得一团糟的时候，没有出面管管，而是暂时搁置一旁，默记在心。而后，到了评估会议上，经理人将过去收集起来的一切一股脑地拌了出来，让员工措手不及。事实上，这只能让人看清谁是老板而已。

　　第10种愚蠢行为：认为所有的员工、所有的工作都应该通过同样的程序、按照完全一致的方法来评估。所有的员工都需要同样的方法来提高自身的绩效吗?当然不是。有些人需要具体的反馈，有些人则不需要;有些人需要更多的沟通，有些人则不要。当然，工作都是不相同的。你想，我们可以用同样的方法来评估福特汽车公司的CEO和车间清洁工吗?当然不能。所以，为什么经理人坚持要用同样的工具和同样的标准来评估接待员和民建工程师呢?

　　这是愚蠢的。同样的标准不可能放诸四海皆准。那么，经理人为什么会这么做呢?很可能是因为人事部或人力资源部要求他们这么做。这是可以理解的，但是，这并不能改变这样一个事实：那就是，它还是愚蠢的。

　　素质的培训不是一朝一夕的事情，但是针对素质进行培训却是十分重要的事情。目前从中学开始，就开设有素质教育方面的课程，但基本属于知识传授的 范畴。一个人素质的发展，与其成长环境的文化和个人经历有着很大的关系。鉴于软件测试工作往往是在不确定标准的情况下进行检验，而软件产品又有着艺术与技 术结合的特点，所以，要作好软件测试工作，不论是新员工还是老员工，不论是测试的操作人员还是管理人员，都有必要不断地提升自己的素质。

　　2.团队的能力

　　团队能力有多种描述方法。一种通俗的说法是，团队能力是指团队所有员工的能力整合所形成的能力。团队能力的构成来自于三方面：员工能不能做，员工想不想做，以及这个团队的整体架构、流程、规划，是不是让员工容易做到。

　　团队能力不是个人能力的简单叠加，而是与个人能力互相影响，相辅相成。团队在知识、技能和素质导向方面的积累，会对团队能力产生巨大的影响。这 种积累是必然发生的，而且是不断持续的。对这种积累的过程进行正确的引导和有计划的部署与实施，将对打造学习型组织，快速提高团队能力有着十分积极的作 用。团队能力应与个人能力相互强化，即个人能力的一个方面就是对团队能力的高效应用，而团队能力的一个方面就是使得个人能力得到高效发挥。

　　对于银行业的软件测试团队来说，目前各行都在快速发展的初期，团队能力正在快速形成和升华的过程中。建立优秀的企业文化，建立软件测试资产库，都将对团队能力形成发挥产生巨大的影响。

　　二、提高能力的几点浅见

　　能力的提高过程既是人才培养的过程，也是团队不断成长的过程。尽管在不专门关注的情况下，个人能力和团队能力也会不断地成长和提高，但是有可能出现弯路，也有可能出现与使命、目标不符的情况。为此，建议应该从如下几个方面注重能力的提高。

　　1.各级经理人以身作则

　　不论软件测试团队分为几级管理架构，处于管理架构不同层面的管理人员，不仅都要高度重视能力的培训，更要以身作则，引导培训的方向。任何一级经理人不重视能力培训，都会导致能力培训不能落到实处之后果。

　　能力培训要得到各级经理人的重视，首先要解决两个方面的问题。一是理念问题，破除“教会徒弟，饿死师傅”的陈旧观念，代之以德鲁克提出的“没有 任何一个能干的下属会伤害上司”的观念，使对能力培训的安排由被动变为主动。二是资源问题，能力培训不仅仅是理论教学，更重要的是真正的实践。在这些学习 和实践过程中，既需要人力、环境、知识等资源，更需要时间。如果各级经理人在制订工作计划时未能考虑到培训所需要的资源因素，则会形成即使有培训的意愿也 难以实施的格局。

　　因为团队能力在其建设和发展的过程中，需要投入资源更大，且会对各级经理人的工作模式产生影响，所以更需要引起各级、尤其是高级经理人的关注。 要使团队能力与个人能力能够结合产生增益效应，就要在团队能力的建设过程和个人能力的培养过程中，妥善处理好相互的关系，使得团队能力成为个人能力依托的 基础，而个人能力的一个方面就是发挥团队能力。

　　2.进行学习能力分析

　　按照德鲁克的分析，人在学习方面分为四种类型，即听、说、读、写。这四种类型并不是绝对的，往往是四种方式兼用，但是在不同的方式下获取的信息 权重和信息量不一样。例如阅读型学习的人，也可能会以倾听作为第二信息获取的手段，以写（例如学习笔记）作为第三学习手段；而比较特别的写作型，则只有在 写作的过程中，才能对以前通过阅读或者倾听获得的信息产生真正的理解，进而产生深入了解相关信息的欲望。

　　另一方面，每个人能够集中精力专注于某项事情的时间是不一样的，对于超过专注时间的内容，则往往表现为听不进，即走神；是否容易造成走神，与需要专注的内容、表达方式等还有很大的关系。对于知识的记忆，尽管一般来说符合艾宾浩斯曲线，但每个人也有着相当的差异。

　　要在个人能力培训方面获得较好的收益，应进行学习能力培训的试点。投入适当的人力资源，确定可能实现的工作目标，进行学习能力的分析指标、分析方法、工作目标、培训方法等等方面的研究和探索，并通过对知识和技能的考核来确定培训的成果。

　　3.建立测试资产库

　　测试团队能力应具有全面、协调和可持续发展的特征。要做到这一点，建立测试资产库，逐步实现测试人员工作过程利用资产库，工作成果丰富资产库，是十分有效的一种方法。

　　测试资产库具有指导工作如何进行和可复用两大特点。资深员工的一项重要工作，就是对资产库的更新、维护和推广；即使需要他们进行一线测试工作，他们也应考虑到所进行的工作入库的可能性和价值。这其实也是衡量一个员工是否具有资深资格的重要方面。

　　很多标准化、规范化的工作，都可以与资产库的建设、维护过程结合进行。在资产库的建设上，以结构化的内容为主，以非结构化的内容为辅。这样，标准化、规范化的工作也易于落到实处。

　　建立资产库是一个复杂、持续、不断调整的过程，对资产库的内容来源、资产库的组织方法、资产库的实现工具、资产库可能发挥的作用和应用资产库的培训，不同的测试团队应结合自身的情况积极的进行探索。

　　4.注重素质的培训

　　世界观和价值观是一个人素质的决定性因素。树立和改造世界观、价值观不是一件容易的事情，但是在积极的思想引导下，逐步地改变习惯却是可能的， 并且会对素质的提升带来显著的影响。史蒂芬.柯维所著的《高效能人士的七个习惯》就是在这方面的一部影响十分广泛的著作。柯维讲述的“积极心态、目标明 确、要事第一、双赢思维、知彼解己、统合增效、不断更新”七个习惯，既包括了对自己的高效工作、生活的习惯，也包括了妥善处理人际关系的习惯，并被中国软 件评测中心列为软件测试人员应具有的素质。对于测试的各级管理者，应加强对将科学发展观以及党的思想路线落实到工作中的学习，并应学习德鲁克等现代管理理 论，针对知识工作者的特点，进行有效管理。

　　5.细分测试岗位所需的个人知识与技能

　　根据被测对象的不同，软件测试人员所需要的知识和技能也不同。在前面分析的基础上，应针对不同的测试对象、考虑到实际的测试流程，将测试人员分 为不同的知识技能组，对测试人员所需的知识和技能进行分级分类，以便能够更好地深入了解被测对象支撑的业务和所采用的技术，确定测试人员使用资产库的最低 阈值，使个人能力和团队能力真正实现相得益彰。

最近几天一直泡在论坛上，看到很多人都认为“手工测试没有技术含量”，“做测试，还是自动化测试，性能测试比较有前途”等等。

首先，我想的是，什么是“技术含量”。我觉得，一般指的有“技术含量”的，就是你能做别人不能做，或者你完成目标比别人快的多的事情，如果随便一个人很快能上手完成你所做的工作，就不算有技术含量。就好像只把伪代码转换为语言的程序员，有多少“技术含量”？从这个角度上看，很多人觉得“手工测试没有技术含量”就不足为奇了，因为如果按照用例去执行，给出明确的预期结果，谁都应该知道用例执行是通过还是没有通过。那如果不是用例的执行而是去设计，而是编写用例呢？给出一个功能点，每个人是否都能快速的设计出有效的测试用例呢。答案一般是否定的，最少同一个公司，有的人写的快，有的人写的慢；有的人考虑的周全，思路很清楚，有的人写用例和不写用例一样，想到哪写哪。测试用例的设计总该算是有“技术含量”了吧，不懂业务的，熟悉业务要很长时间，不晓得逻辑方法的，肯定先要把逻辑弄清楚。

再次，不管什么工作，什么事情，只要能持续的做的深入，总会有能力上的提升。（个人认为，能力包含技术，还有技术以外的东西）对于测试来说，如何定位一个问题，就可以做的很深。上次参加那个交流会，会上某公司的主管就说了一个例子：“假设我们测邮箱发送4M的附件发送失败，一种做法是直接把附件给开发，说这个附件不能发送；还有一种做法就是将问题进行细化，是文件格式的原因，文件大小的原因，还是最后只是文件里包含了不合法的字符。”如果是后一种，问题解决起来也快，开发也愿意配合，自己也能提升技能。的确，一开始细化问题的时候，会很费力，但是“火车刚发明的时候比马还慢”，当你能力提升了以后，会发现处理问题会越来越顺手。（如果碰到无法理解的问题，肯定要给开发，不能自己转牛角尖，但是开发修正后，可以去问是什么问题，怎样修复的。）说句比较考张的话，把平凡的测试变为不平凡的分析去做~

最后，说其他方面的成长。我们肯定很明白一点，测试不是凭想象，想怎么测，就怎么测的，总是在开始测试之前，先把思路理清楚，测试的策略想清楚，于是锻炼了思维。我们总是在描述bug的时候，担心开发看不懂，每次以他人的眼光来审视写的bug，是否有歧义，复现的步骤是否更直白，语句是否更简练而清楚，顺带着，是否有截图和图上重点的标示，于是锻炼了文字描述。我们总是会和需求人员确认需求，和客服人员确认客户问题，和开发确认缺陷问题，于是我们锻炼了沟通。也许有人会不认同这也是一种收获，那可以问问自己，我们有没有测试到一半，发现漏了功能点，重新回头进行测试的情况；我们有没有写bug后，开发看不明白，打回的情况；我们有没有根本没有了解到客户的真正问题，就马上去解决的情况。。。。

任何工作，当想有没有前途前，想想自己为此付出了多少。如果做自动化或性能，只会简单的入门，而不去深入，我想也不会有“前途”吧。

现在单位有越来越多的实习研究生，这些研究生们很努力聪明（挑选过），很多半年不到就能做一个不错的测试执行人员（能写自动化脚本，各种测试工具也掌握了用法，环境搭建也麻利了），甚至有的也开始写测试用例。有些工作2－3年的同事感觉到有些危机感了。觉得自己所做的工作内容，只需一年就能被新人替代。为此，我给部分同事进行了一定的鼓励，在此与大家分享，希望大家一起讨论。

“1、如果你做2－3年测试的优势只是对自己的这个被测产品很了解，而对测试本身了解很少，那么你的优势是在产品知识而不是测试，你要巩固自己的不可替代性的方法是把产品知识理解的更深更系统，这样新人至少也还需要1－2年才能赶上你现在的产品知识。可是公司一旦砍掉了这个产品，你在新产品项目中还有优势吗？”

“2、虽然你在写测试用例、新人也在写测试用例。但是就像苹果手机一样，如果你写用例的质量是山寨质量，那么你很容易被其它山寨所替代。如果你测试分析的质量和写的用例集质量是专业水平，山寨很难在专业质量上替代你。你是山寨还是专业？你自己是否平时针对被测对象的分析是随意的，没有持续提升的，那么你的确有可能写用例的水平也就停留在测试专业半年的质量水准。所以不要怕其它人做和你一样的工作内容，只要你平时一直严格要求自己的测试用例编写质量，每次做测试分析设计都比上次更好，那你就能做到专业级。这种能力需要等量时间和经验积累才可能拥有。”

“3、你可以这样衡量自己工作的不可替代性：假设有一个同样的工作目标，对A软件进行测试分析设计，输出测试用例集。公司找10个实习生一起合作用同样的时间也做不到我输出测试用例集的质量。公司会选择我，这里面就有我很多的不可替代性在里面。可如果是同一个目标，10个实习生一起能在更短的时间内完成你的任务，且质量不比你低，那么你就要考虑在这个方向上你是否容易构造起你的核心竞争力。”

“4、有同事说他在开发部干了3年转过来的，所以在测试部有不可替代性。如果你不能在测试领域比其它测试同事把被测对象分析的更系统和透彻，输出的测试用例比其它人都更全面高效，那你依然没有不可替代性。因为只用3年时间公司就可以产生大量代替你的人，招一批实习同学先去写3年代码再转测试，你就被替代了。所以，即使干过3年开发转来测试，对你而言也要踏实虚心的在测试知识上不断学习实践。在测试部不是比编码能力，而是比测试技术质量、比计算机基础体系知识。”

居安思危，才能久保平安。大家都来讨论一下吧：我们如何树立在测试职场的不可替代性？也许讨论清楚了，我们也找到了后续个人的努力方向了。

　　简单点说资深软件测试工程师仅需要掌握测试技术和行业技术就足够了。但细品起来好像也不完全像上面说得那样简单，怎样做才能掌握高超的测试技术，怎样做又才能成为行业技术专家，怎样做才能将这两者结合在一起呢？

　　举个例子要求测试报表的工程师去检测一次性水杯，针对这个题目写出可行的测试用例。看了这个题目，很多测试工程师都会感觉头疼，这样的测试用例怎么写啊？先别急，让我们来考虑一个小问题“什么叫测试，测试应该从什么地方开始着手？”如果能将这个问题想明白，测试水杯的思路也就逐渐清晰了。比如，首先要考虑杯子是用来盛水的，那就要求它不会漏水。如果有人喜欢喝热开水，作为盛水的工具它应该满足沸点水温的要求，如果有人喜欢喝冰水，零度以下的要求也应该能够实现。然后再考虑一下杯子的软硬程度，如果太软拿不住，持杯子的人还会喝到水吗？如果杯子太硬是不是造价又会太高呢？接着再考虑在多长时间内杯子不会被水泡开，如果一个装了水的杯子，在两分钟后就被泡开了，那肯定是不合格的产品了，消费者是不会为如此短命的水杯买单的。沿着这个思路走下去，你会发现需要检测的内容太多了，杯子是不是会散发异味，是否满足食用器皿的卫生标准，杯壁上是否有异物，装满一杯水后杯子是否会损坏，杯子表面的图案会不会掉色，花样是否美观，装一些固体物体时杯子的可用性等等，基本功能测试、稳定性测试、压力测试、关联性测试就这样逐一而出。很神奇是吗？继续这个题目完成它，测试用例也就出来了。

　　上面的小例子是灵活运用测试理念的一个典型，从这个例子中不难看出测试的广博，一个好的测试工程师能够像万金油那样，运用到方方面面的测试中，对事物的认知都可以从测试的角度来分析。尝试从身边的一些小事物开始，培养测试的兴趣和眼光，慢慢的就能从中体会到测试的意义了。比如对钢笔、桌椅板凳等做做测试，你会不会发现自己正逐渐的像质检员那样专业？在测试取得成功的同时，想想测试的过程，对测试对象高度认知不就是测试成功的基础吗？也就是说在测试之前你已经掌握了测试对象的特征，并且这些信息以不可察觉的速度在头脑中建立了测试的方向，所以才会得心应手。这个对特性认知并建立起测试方向的过程就是测试理念日趋成熟的过程。

　　再举个例子，让手机软件的测试工程师来测试网络软件，结果通常是以失败而告终。有些人就不明白了，为什么测试桌椅都能成功，同样也是测试软件却失败了呢？那是因为在进行这个题目的时候我们忽略了非常重要的一点“行业技术”，桌椅等日常用品因为太过熟悉所以很容易掌握其特性，但是网络软件却因为其高度的领域性不被普遍认知。测试手机软件的工程师也许对各类型的手机操作系统非常熟悉，但是对网络知识的了解却很少。所以这种盲目的使用软件的过程，并不能构成系统的测试过程，最终导致题目执行的失败。

　　解决这种问题最好的方法就是培养广泛的兴趣，学习一些行业知识，从当前项目所需要的行业技术开始，适当的增加对其他领域的了解，比如游戏软件、杀毒软件、文字编辑软件等等。艺多不压身，如果哪天你所在的项目组改变了业务方向，你还会紧张吗？

　　不要将眼光局限在一小块地方，从另一种角度用动态的眼光去看待软件测试，当你发现测试无处不在的时候，才能说是真正深入到了这个领域。

　　一：性能测试工具模型

　　广义地说，性能测试工具是指性能测试过程中使用到所有工具，但是我们习惯上把“性能测试工具”定位于LoadRunner、SilkPerformer一类的工具。

　　关于性能测试的几个误区：

　　1、认为性能测试就是使用性能测试工具进行测试。

　　性能测试工具只能帮助你实施性能测试，并不能帮助你完成性能测试的需求、设计和分析。

　　2、认为性能测试工具可以完成性能测试结果分析工作。

　　性能测试工具只是能够根据你的要求以各种方式提供报表，这些报表可以被您用来分析系统性能状况。

　　3、不清楚性能测试工具的录制/回放与功能测试工具的录制/回放的区别。

　 　功能测试工具的录制/回放一般是针对GUI的操作录制，脚本中记录的是用户对控件的操作，例如按下了“确认”按钮或是在“姓名文本框”中输入了ABCD 等内容，这时因为功能测试工具主要是通过操作和数据来验证功能的正确性，评价的主要标准是GUI的正确性（界面内容的正确性）。而性能测试工具录制的是服 务端和应用之间的通信数据，而不是应用的GUI操作。^_^^_^理解了这一点，就不难明白为什么在进行性能测试脚本录制的时候，需要首先选择录制的协议 了。

　　4、不清楚何时选择何种协议。

　　选择何种协议取决于应用和客户端之间的通信协议。

　　二：性能测试工具架构

　　1、虚拟用户脚本产生器（Virtual User Generator）：通过一个Proxy作为客户端和服务器之间的中间人。

　　2、压力产生器(Player)：压力器扮演着“产生负载”的角色。

　 　3、用户代理(Agent)：运行在负载机(LoadMachine)上的进程，该进程于产生负载压力的进程或是线程写作完成“产生负载”的功能。如一 台PC可以顺利运行200个左右的VU，但对需要1000个VU的情况显然很难指望一台PC，这时就需要通过多台及其进行协作，“用户代理“就帮助产生” 步调一致“的VU。

　　4、压力调度和监控系统(Conductor)：直接与用户交互的主要内容，压力调度可以根据用户的场景要求，设置各种不同脚本的VU数量，设置同步点等，而监控系统则可以对各种数据库，应用服务器、服务器的主要性能计数器进行监控。

　　5、压力结果分析工具(Analysis)：用来辅助进行测试结果的分析。

　　三：性能测试脚本录制时的协议类型

　　^_^^_^不要想当然地根据开发语言来决定协议的选取，这样子极有可能导致录制后的脚本不能回放成功。

　　几点说明的内容：

　　1、使用Socket协议可以对任何类型的应用通信进行录制，但这种录制生成的脚本很可能没有任何意义。

　　2、在对应用间的通信进行录制生成脚本后，对脚本进行回放，有时会出现回放无法继续的情况（停留在某个步骤无法进行下去），此时应该考虑是否使用了合适的协议。

　　——————————————协议选择参考方案——————————————————————

　　1、Web应用：应用特点：采用J2EE或是dontNet结构，HTTP/HTTPS协议。

　　2、C/S应用：

　　a、客户端程序以ADO、OLEDB方式连接后台数据库，选择后台数据库类型选择相应的协议。

　　b、客户端程序以ODBC方式连接后台数据库，ODBC协议。

　　c、其他协议，根据具体协议类型进行分析。

　　3、组件：a、COM/DCOMcom/dcom协议。

　　b、EJB，EJB协议。

　　4、服务：

　　a、WebService，WebService协议。

　　b、Mail服务器，SMTP/POP3协议。

　　c、FTP服务器，FTP协议。

　　5、应用服务器：

　　a、OracleApplicationServer,OracleApplicationServer协议。

　　b、SAP，SAP协议。

　　c、Tuexdo,Tuexdo协议。

　　四：性能测试工具的选择与评估

　　这个问题通常会有两个层面的意义：第一，创建还是购买？第二，如果购买，如何选择一种商业工具？

　　1、创建还是购买？

　　总而言之，”购买“的方式可以以较低的总体成本快速获得可用的软件，但如果被测试对象本身有一定的特殊需求，最好使用”创建“的方式构建适合的测试工具。

　　2、测试工具的评估和选择过程。

　　（1）列出需要的工具功能列表

　　（2）工具比较

　　（3）成本分析

此次培训，不同于理论知识的讲解，更多的是微软测试思想、方法与技巧的传达。通过培训，了解了微软的测试思想及过程，很多思想、方法值得我们学习。

1          对软件测试的理解

1)        测试的目的

Ø  不仅是为了将测试做好，更是为了将项目做好

Ø  测试不仅仅是发现bug, 测试的最高境界是建立起一套软件测试质量体系，使得项目按照既定的方向（进度）和标准（如质量）前进

Ø  开发过程中的质量，不仅仅最终代码存在质量，开发的工作方式、过程中的方法、产物同样是质量

思考：微软是没有QA的，微软人人都是QA，质量意识是微软人最基本的素质，由测试人员制定项目轨道，并在过程中执行推进。重要的一点：该踩刹车时要及时刹车

      我们目前有专业的QA团队，负责项目过程中的质量管控，QC负责工程产物的质量，由两个角色来达成该目标，按国内软件企业的现状，由两个角色，专业化分工，开展起来确实更为有效。

2)        测试的原则：尽早的、不间断的进行测试

Ø  尽早的测试

ü  测试人员在需求阶段就介入，在项目前期预防和纠正需求及设计问题，做好缺陷的预防

ü  开发阶段：尽快的、尽可能的、极早的告诉开发代码是有效的

思考：

a)       目前我们已经做到了测试人员在需求阶段就参与，参与需求、设计文档的评审，但参与的效果还有待提升。

b)      “不明确的需求是项目效率的第一杀手”，测试设计人员应更多的从上游发力，加深自己对业务、对客户实际需求的理解，从实际应用、用例设计的角度参与业务需求、设计文档的评审，预防缺陷的发生。

c)       以前我们经常到项目后期了又发现重大BUG，这时给项目带来的极大风险，往往就是项目延期，再严重点的导致质量不可控，如何“尽快、极早的告诉开发代码是有效的”这是我们应该追求的目标，测试的依据是测试用例，还是应从测试用例设计上下功夫。

Ø  不间断的测试：微软采用“每日构建、自动化测试”的方式

ü  微软建立了一套自动化测试平台（据讲师介绍微软全部是自己开发的测试工具，花了5年多时间，各类工具有40多种，再由总控平台统一控制）

ü  采用自动化测试后，任何时候都执行所有用例（微软亚洲工程院的项目每天对3万多条测试用例重复开展自动测试，产生300万条测试结果）

思考：

a)       我们目前全是手工测试，不可能做到任何时候执行所有用例。项目过程中分为多个测试工序，不同测试工序选取不同级别的测试用例执行，手工执行重复测试容易疲劳，带来的风险是修复BUG引起的新BUG可能被遗漏，或对未修改功能产生的影响被忽视。对影响点的识别与评估是我们需要加强的。

b)      微软的“任何时候执行所有用例”是一种理想状态，虽然自动化测试是行业的发展趋势，但我们不可能做到100%覆盖，可挑选出基本用例开发自动化，做到每日构建的基本用例验证，避免最基本、最不可接受的程序BUG。

 2          测试计划与用例设计

1)        制定计划的原则

Ø  将项目切分为多个里程碑，分别进行管理。

ü  确保当前盖的这层楼是想清楚、明确后再去盖的

ü  确保已完成的是绝对可靠的

Ø  提前定好项目标准

ü  在每个里程碑节点完成后进行回顾

ü  最终标准达成后即发布

ü  微软的发布评估标准（Release Criteria）：

○          95%的测试用例通过率，且持续时间>5天。

（不是累计达到95%，而是5天每天达到95%）

○          允许有5%的case不通过，但级别不能是重要的case..

○          代码覆盖率>85%（指测试用例执行的代码覆盖率）

○          ZBB零bug边界，保持5天

（微软在ZBB后，会安排全员大扫除，连续5天时间未发现BUG，才可发布）

Ø  关注模块间的依赖

ü  确保每个模块及所有边界都有人测试，避免重复和无人测的情况

ü  边界出存在小范围重复测试是允许的

2)        制定测试计划中，发现人员不充分，经验不足怎么办？

Ø  从工程的角度考虑问题，不仅仅是要求测试人员之间分享经验，还需要有效的标准

ü  将有经验成员的能力转化为形式：将有能力者的思维方式形成模板

ü  一个好的模板，是节约人力成本的好办法。还能弱化对每个人的依赖度。

ü  重视过程文档：写文档，重在思考的过程。强调起清楚，再干活

ü  新老员工之间产物的区别，应转化为中间评审打回返回次数的区别，最终文档的质量应该是完全一致的

ü  文档质量的高低：50%取决于作者，50%取决于对该文档抓质量的程度

Ø  检查需求细不细

ü  避免主观语句（性能高，响应速度快等这样的形容词），速度响应快，快到多少秒。

ü  一定要量化需求，而不是主观感受。

Ø  凡事以数据说话，这样才能有说服力。

思考：

    目前我们的流程、体系，与上面的大部分原则不谋而合，有些点我们现在是做了，但还做的不到位，应彻底落实。

a)       微软的发布标准是非常清晰，且完全是用数据说话，从中可以看出微软对质量的重视程度。我们目前的发布标准虽然也会依据质量目标的达成，但标准较为模糊，更多的还是测试团队的感知，测试人员测到最后阶段，也都很疲劳希望能够尽快发布了。这也是导致我们产品发布后立即频繁发补丁的原因之一。

如何清晰定义发布标准，使用有效的数据说话，是我们需要改进点之一。

b)      一直没太搞清楚 “代码覆盖率”用什么方法来测算，现在我们只能测算到对功能点的覆盖率（颗粒度太粗），如果能够测算对代码的覆盖率会更准确，有助于用例设计覆盖率、测试质量的有效提升。

老师介绍一种方法是在代码中所有分支处设置数字标识，测试执行时验证该分支就会弹出标识，最终检查是否所有分支标识均进行了验证。这对开发人员要求较高，有一次与金碟的同行交流，他也提到他们会在代码里埋探针，来检测执行的代码覆盖率。不太清楚这样做会给开发带来多少工作，在我们团队中是否可行？

c)       我们对模块间的关系影响也有考虑，但对影响的识别、评估能力欠缺，对系统间的边界识别容易遗漏，计划中没有明示对边界的处理。

在设计阶段，会对所有接口进行梳理，进行接口设计。测试人员在设计用例前，也应对系统与系统间、模块与模板间的边界进行分析识别、统一梳理，并落实至具体计划中。

3)        如何提高测试用例的编写水平

Ø  积累测试素材：建立内部的测试素材库

比如对于文本框的验证，一般都是验证那几项，有效数值，无效数值，空格，空等等，这些测试用例在每个项目中都可以反复使用。

Ø  任何情况下都必须使用边界值分析法

这种方法设计测试用例发现程序错误的能力最强

Ø  必要时用等价类划分方法补充一些测试用例

Ø  用错误推测法再追加一些测试用例

Ø  不要因为实现的困难程序而影响设计用例

Ø  测试方法的复用

对于有继承性的项目来说，用之前编写的测试脚本或自动化测试工具以达到测试方法的复用

Ø  自动生成测试用例

依据用例设计的常用方法，找出规律，用技术实现思维

思考：

a)       目前专业的设计方法非常多：等价类、边界值、因果图、判定表、正交法等，但真正设计用例时，不是挑选一种设计方法就能设计出好的用例，也没有时间去依据这些方法的步骤进行一步步分析，更多的是一种牢记于心的设计思想，需要测试人员依据设计思想直接编写用例。

b)      当然，对于核心业务、复杂功能必须先进行设计分析，设计分析时主要是对客户应用场景的分析，再结合用例设计方法补充各类分支、异常场景。

c)       测试素材的积累，我们目前已经梳理了通用测试用例，但执行并未到位，测试过程中往往忽略了通用用例的执行，通用用例都是有规律可循，要考虑用技术手段实现通用用例的自动执行。

d)      我们目前的测试用例只描述到特征，不会编写测试数据，不同经验的测试人员执行相同用例结果会出现不一致，差异在于实际使用的测试数据不一致，有经验人员使用的一组测试数据更容易发现程序问题。特征与业务、设计相关，不具备通用性，但可以考虑依据特征自动生成测试用例数据，并不断完善生成的规则，将经验转化为技术。单字段的测试数据易实现，难点在于组合数据的生成，输入之间存在各类业务逻辑、控制，虽然很难，后续在自动化测试层面还是值得做一些尝试，实现自动化的前提是要有清晰的输入、输出数据，手工准备测试数据的工作量是相当巨大的。

杜拉拉职场上升轨迹(原著)

27岁  进入DB 行政秘书  月薪3000元

29岁  销售总监秘书  月薪6000元

30 岁  HR主管  月薪12000元

33岁  HR经理  月薪25000元

股市好的时候，上班炒股、手机炒股的景象屡见不鲜，还有人辞去了工作呆在家里天天炒股。在一些人的心目中，获取更高的投资回报就是理财的重点。投资固然有必要，但把致富的桥梁局限在投资上则有失偏颇。对正值壮年的人而言，最重要、最大的资产，不是那每月存下用于投资的几千块，而是他每月的赚钱能力。

在电影《杜拉拉升职记》中，徐静蕾在几年的时间里，从外企普通小白领，成长为一个专业干练的HR经理。观众们想必也留意到了杜拉拉工资的快速增长。

相信吗？杜拉拉通过几年的努力，获得了工资的大幅提升，为她带来了接近 560万的潜在个人资产。

想知道560万是怎么来的，让我们通过运算把杜拉拉的赚钱能力数量化。

在企业估值上有一种现金流折算法，指一个公司的当前价值等于它在“未来”能带给投资人的现金流之和。我们也同样可以从这个角度来估算人的“价值”。

假设杜拉拉将会在55岁退休。为计算简便起见，每个阶段都不考虑未来可能的工资增长，同时也不考虑通胀等因素带来的折现率。

27岁的杜拉拉，退休前可以工作28年，年收入36,000元。这28年间她的工资收入总共有1,008,000元，这就是此时杜拉拉所拥有的赚钱能力带来的价值。

等到她33岁升任外企HR经理后，月薪达到25000元的水平。在接下来的22年里，她的工资收入增长到了6,600,000元。

有兴趣的朋友不妨自行计算一下，用当前开始到退休的年限乘以自己的年收入，验证下这个数字是不是比你的房子、车子、存款以及股票等资产加起来还要多？

关心如何投资并没错，但千万不要忘记：你自己可能就是投资组合中最重要、最值钱、也最值得开发的资产类别。股票账户中的几十万，同你自己现金价 (1239.00,-6.60,-0.53%)值的几百万相比，如何管理好后者更为重要。

投资VS工资

理财的相关讨论中，常有一种“死薪水，活投资”的论调。认为光靠薪水难以致富，要努力投资才有可能成为富人。 “投资”时钱丢在那里就会自动“增长”的轻松愉快，对比上班烦重的压力，让这种说法更容易获得人们的心理认同。也因此，用“轻松赚”、“快速赚”、“狠赚”做噱头标题的理财书籍或新闻，以及一些赞扬被动收入的言论大行其道。

在强调理财的重要性时，个别媒体和理财专家习惯于突出长期投资和复利效应下的高回报。其实，除了投资之外，职业规划也是个人理财的重要一环。复利再神奇，也无法掩盖踏实挣钱的重要性，对于正值壮年的人而言尤为如此。

为什么这么说？

对于大部分人而言， 工资收入是基础。27岁的杜拉拉，说不定省吃俭用也只拿得出几百块用来投资；33岁的杜拉拉，1个月用于投资的钱能达到1-2万。投资必须要有资金积累，除非你是富二代，否则只能通过努力挣钱来为投资做准备。每月工资能用于投资的比率是变动的，通常情况下，收入越高，消费支出占收入的比例就越低。

工资是确定性的收入，投资要承担更多的不确定性。牛市里投资一年翻倍甚至翻几倍也不罕见。问题在于，能够通过长期稳定的获取投资回报并非易事，在最近几年股市的跌宕起伏中，能赚大钱的依然是极少数人。投资充满了不确定性，投入的精力与回报没有绝对的关系。工资收入则不然，只要方法恰当，社会总是会为努力且有能力的人，给予更多的报酬。

工资收入不是一成不变的。通过自身的努力，杜拉拉的工资从3000增长到25000，超过8倍。在一线城市，30岁以下月薪达到2、3万的人也不是稀有物种。金融、IT等行业更是催生出大量的年轻金领。值得注意的是，过去20年间北京职工的平均工资收入年化增长率超过了18%。

财富的天平

对于年轻或者正值壮年的人来说，人力资本所能带来的报酬，才是他最大的资产。

投资和工资都很重要，《钱经》建议读者根据自身情况来决定投入精力的多少。想象自己有这样一个财富的天平，一端是个人已有资产，另一端是工作到退休带来的潜在收入。衡量孰重孰轻，将更多的精力投入在重要的方面，

例如一个45岁的人，将自己拥有的股票、存款和房产等资产加总后减去房贷等负债，计算出净资产共值600万，未来十年的工资收入正好也是600 万。那此时就面临了一个临界点，可以看作天平刚好平衡，此时在工作和投资上投入的精力应当相近。

人力资本会随着年纪增加而减少，而累积的资产净值则一般而言会随着年纪增长而增加。所以，年轻人的理财主要是提升人力资本，增加自己的工作收入；中年时随着资产的增加，逐渐加大对投资的重视；老年时在于保本与享用一生的成果。

要想达到富爸爸作者罗伯特  清崎所倡言的“财务自由”，不是一蹴而就的。清崎自己也花了30多年才达到财务自由，他很早便开始学习财务知识与其他相关技能(营销、管理、财会等)。比别人更努力，付出更多，才让他有今日的地位。投资理财是达成财务自由的桥梁而非天梯。

如何理性的进行取舍，在不同阶段有不同的侧重，需要引入个人财务生命周期的概念。

图一反映了个人资产随年龄变化的一种情况。在理财规划中，通常把一个人的财务生命周期划分为三个阶段：累积阶段、巩固阶段和支出阶段。

累积阶段是从大学毕业到35岁左右的时候，这是你开始有收入并积累资金的阶段。这一时期里，应该把理财的主要精力投入到工作上，股票等投资在保证工作的前提下作为兴趣涉猎，为将来做准备。由于离退休尚早，工资的提升会带来个人现金价值的较大改变。此外，这段时期是个人职业生涯成型和快速上升阶段，投入财力和精力的产出比极高。以一个25岁年轻人为例，月薪增加一千，就意味工资的现金价值增加了36万。由于缺乏积累，这一期间很难有大笔资金用于投资，“定投”这种“懒人投资法”尤其适合这一阶段，既起到了强制储蓄的作用，又能够享有长期复利带来的回报。

第二阶段是巩固阶段，从35至55岁左右退休。你的收入不断上升达到最高峰，由于财富的不断积累，收入远远超过支出并开始获得大量财产性收入。你的债务开始减少直至最后全部清偿，你的资产净值在不断增长。随着年龄的增长，天平开始不断倾斜，在这一阶段里个人精力的投入需要逐渐从工作转向投资上。工作年限不断减少，多数人的事业也开始触及到天花板，工资的提升空间越来越小。其他资产随着年龄的增长逐渐积累，客观上要求投入更多的精力去打理。

退休之后，工资收入不再需要投入精力关注。这一期间主要是安排好资产组合，并且制订退休后的支出计划。

所以说，牛市是老年人的盛宴，拥有的可投资资产越多，投资带来的影响越大。

7条改变你的“薪情”

1、审视下现在从事的工作是否适合自己。

结合自身情况，在可从事的行业中选择工资较高，或者工资增长较快的行业。据北京统计局2009年年鉴，采矿业2008年平均工资为60045，比上年增长 45.6%；IT行业平均工资为94362，增长22.1%；金融业为178322，增长37.2%。

2、不断充电。

英语、MBA、学位以及职业资格都是众所周知的途径。这会为你的加薪提供砝码。

3、发一封简短的联系邮件。

是不是有一些业内人士，你最近没有与他们保持联系？给他们发封电子邮件，让他们知道你的近况，并且问一问，他们最近在做些什么。说不定他们刚好能够提供给你一个对你的事业来说很好的机会。

4、为工作场所里一直没有解决的问题提供解决方法。

并非仅仅关注企业范围内的大型问题，关心小事也是尤为必要的。尽量把你的解决方法考虑的周全，这样你的老板就能够意识到，你发现了问题、思考过如何去解决，而且自行的提出了解决方案。

5、努力提高语言能力

你的工作场所中所使用的语言是你的母语么？如果不是的话，花一些空闲的时间，去提高语言技能。此外，良好的口头表达能力也很重要，“会说话”给你(或者将要给你)带来的提升比你想象的更大。

6、润色你的简历

任何时候都可以考虑润色一下你的简历。确保上面包含大量详细记录你的工作成果的文字和文件。事实上，你的个人工作记录，是扮靓简历的一种绝好材料。

7、努力做出成果，记下它们并在适当的时候让别人知道。

要让自己的事业继续向上攀升，首先要做出不一样的事情，然后要让老板和同事知道。加班、高效的完成任务、做出更好的业绩、提升自己的能力，并且自己将它们记下来。这不是为了自我满足，而是让你的工作报告或者简历更好看。

很多人关心LR在C/S架构上如何实施性能测试，我想根本原因在于两个方面，一是很多时候脚本无法录制，即LR无法成功调用被测的应用程序，二是测试脚本即使录制下来，可读性不强，往往不能运行通过，调试时无从下手，像音视频、电子地图类的测试差不多也是这个问题。
　　根据我以往的项目经验，LR是可以做到的，因为它提供了Windows Sockets协议，解决方案实施起来简单但需要足够的细心以及一定的判断力、想象力，可参考如下步骤进行：
　　1、通过抓包工具捕捉客户端与服务器之间的所有通讯。
　　关键点：IP过滤，端口过滤，报文类型过滤
　　目的：弄清楚业务操作过程中，客户端向服务器提交的请求原型，以及服务器对我们请求所做的正确响应
　　2、将过滤后的报文整理成测试脚本。
　　关键点：Socket的建立与关闭，send buf的整理，receive buf的整理
　　目的：将抓包获得的报文转成LR测试脚本（提示：选取合适的抓包工具，使得报文能被保存成文档格式；开发小工具，通过报文中的各个关键字抽取报文中 Data Area中的部分作为buf 区的内容，根据IP字段，端口号等特征完成lrs_send,lrs_receive语句的填写。这部分看上去挺难，但只要对报文做好分析，把握规律，编程的事随便拉个开发都可以轻松搞定）
　　3、调试脚本
　　关键点：定位错误，添加校验点
　　目的：使脚本真正可以拿来进行压力测试
　　这是最难的一个环节，耐心、细心、判断力都体现在此处。每个人处理问题的方式的不同，我只能提供自己的一点经验。
　　将脚本RUN-TIME SETTINGS中的扩展日志全部打上钩，并且将脚本拿到controller中单用户执行，注意设置好日志路径。
　　脚本出错后，用EDIT PLUS或其他的文本工具打开log,找到出错行，然后向上逐一对比服务器返回的数据与录制过程中抓包获得的报文。
　　在这里，我用了一个小技巧，生成buf内容时，使buf的编号与该buf在抓包获得的报文中编号保持一致，比较起来很方便。
　　如果服务器返回的buf与抓包时的原始数据一致，自然表示该步骤回放成功，如果不一样，则需要具体情况具体对待。就我的经验来说，往往是因为数据唯一性问题或者是关联的问题造成某一步骤返回的BUF为0或-1，从而导致最终脚本失败。
　　找到第一个出错的地方后，参数化，关联等手段都可以用上了，这里可能需要重复两次抓包过程，先行比较自己发送的报文是否有区别。
　　总体思路便是如此，写了一堆，也不知道对大家是否有帮助，对于此类问题，网络上的协助很难派上用场，事情还是要在现场才有可能得到解决啊。本来有意将这东西工具化，甚至产品化，但几个项目实施下来发现变数较多，特别是最后一个环节，完全依赖于测试工程师的自身能力，只好就此作罢

    备注：另外使用Socket方式时，一定不要使用localhost本地环路来访问Server端，即使你的C-S都在一台机器上，也不能这样访问，一定要使用机器名或IP地址，LR才能侦测到C-S之间的交互数据，才能录制到脚本。

    转自：作者：tttrrryyy

　　根据我以往的项目经验，LR是可以做到的，因为它提供了Windows Sockets协议，解决方案实施起来简单但需要足够的细心以及一定的判断力、想象力，可参考如下步骤进行：

　　1、通过抓包工具捕捉客户端与服务器之间的所有通讯。

　　关键点：IP过滤，端口过滤，报文类型过滤

　　目的：弄清楚业务操作过程中，客户端向服务器提交的请求原型，以及服务器对我们请求所做的正确响应

　　2、将过滤后的报文整理成测试脚本。

　　关键点：Socket的建立与关闭，send buf的整理，receive buf的整理

　　目的：将抓包获得的报文转成LR测试脚本（提示：选取合适的抓包工具，使得报文能被保存成文档格式；开发小工具，通过报文中的各个关键字抽取报文中 Data Area中的部分作为buf 区的内容，根据IP字段，端口号等特征完成lrs_send,lrs_receive语句的填写。这部分看上去挺难，但只要对报文做好分析，把握规律，编程的事随便拉个开发都可以轻松搞定）

　　3、调试脚本

　　关键点：定位错误，添加校验点

　　目的：使脚本真正可以拿来进行压力测试

　　这是最难的一个环节，耐心、细心、判断力都体现在此处。每个人处理问题的方式的不同，我只能提供自己的一点经验。

　　将脚本RUN-TIME SETTINGS中的扩展日志全部打上钩，并且将脚本拿到controller中单用户执行，注意设置好日志路径。

　　脚本出错后，用EDIT PLUS或其他的文本工具打开log,找到出错行，然后向上逐一对比服务器返回的数据与录制过程中抓包获得的报文。

　　在这里，我用了一个小技巧，生成buf内容时，使buf的编号与该buf在抓包获得的报文中编号保持一致，比较起来很方便。

　　如果服务器返回的buf与抓包时的原始数据一致，自然表示该步骤回放成功，如果不一样，则需要具体情况具体对待。就我的经验来说，往往是因为数据唯一性问题或者是关联的问题造成某一步骤返回的BUF为0或-1，从而导致最终脚本失败。

　　找到第一个出错的地方后，参数化，关联等手段都可以用上了，这里可能需要重复两次抓包过程，先行比较自己发送的报文是否有区别。

　　总体思路便是如此，写了一堆，也不知道对大家是否有帮助，对于此类问题，网络上的协助很难派上用场，事情还是要在现场才有可能得到解决啊。本来有意将这东西工具化，甚至产品化，但几个项目实施下来发现变数较多，特别是最后一个环节，完全依赖于测试工程师的自身能力，只好就此作罢。

对C/S架构下的软件性能测试依然在摸索中，故借鉴一下别人的总结经验，谢谢那个作者了。

　　1. UT

　　单元测试的对象是LLD中所划分定义的程序单元或模块，它也是单元测试用例设计中可测试的最大单元。该测试对象可能由一个或多个函数或者类组成，测试设计就是对测试对象进行测试用例设计。

　　UT的目的，是通过函数运行来检查模块代码对于LLD文档的顺从性，验证每个函数的输入输出响应，与它在详细设计文档中预先定义的是否一致。函数是产品开发实现的最基本单位，下一个实现单位是模块，从测试的角度看，希望UT完成后，每个函数都牢固可靠，下一步的IT测试将聚焦在函数之间配合能否实现分配需求，而不用担心函数本身的输入输出响应问题。

　　单元测试比较适合开发人员做。

　　2. IT

　　集成测试是指把若干个经过单元测试的单元组装到一起而进行的测试，集成测试应依据HLD，主要发现接口、依赖中的错误或不完善的地方。集成测试的对象为若干个单元测试对象的组合，至少为两个。

　　IT的目的，是根据模块设计对模块的分解，从已验证的函数开始，逐层向上集成，得到一个可运行的模块。

　　IT可以由开发人员做，也可以由测试人员做。

　　不难看出，UT是面向每一个单元的测试，IT是测试单元之间的接口，可以把UT/IT归为“单元级”测试。

　　3. ST

　　CMM定义的系统测试：系统测试是针对软件项目组所承担开发的软件系统进行的整体测试，将软件系统作为整体运行或实施明确定义的软件行为子集的测试。主要采用的测试方法是黑盒测试，即不管程序内部的实现逻辑，以检验输入输出信息是否符合规格说明书中有关需求规定的测试方法。可见ST的测试对象是规格说明书，更确切的说，是模块需求规格说明书，所以一般也称为MST。模块SRS文档给出了模块的输入输出的相应要求。MST后，每个模块是牢固可用的。

　　4. BBIT

　　BBIT为模块间接口测试，验证模块之间的接口能不能配合，有时和联调混在一起，其实目的并不相同。BBIT的目的，是根据系统设计对系统的分解，从已通过验证的模块开始，逐层向上集成，得到一个可运行的系统。而联调一般涉及软件、硬件或者不同产品间的配合测试。MST和BBIT可以归到“模块级” 的测试，一个验证模块，一个验证模块间的接口。

　　以上UT/IT/MST/BBIT一般由开发人员完成，系统基本可以运行起来了，测试人员可以开展SDV、SIT、SVT了。

　　5. SDV

　　SDV虽然属于测试人员开展的系统测试，但是有点偏灰盒测试，因为SDV验证各子系统的配合是否满足设计需求（DR），对内部的实现还是关注的，验证多个模块集成以后是否满足设计需求。

　　6. SIT

　　SIT也是验证设计需求是否得以满足，与SDV不同的是，SIT完全把系统当作一个黑盒来测试，不关心内部具体的实现。实际应用中，SDV和SIT 虽然都属于系统一级的测试，往往由不同项目组（子系统）的测试人员分别测试，他们只关注各自的子系统，所以还是把SDV和SIT归为“子系统级”的测试比较好。

　　7. SVT

　　SVT是验收测试，其测试对象是产品包需求OR。产品包需求给出了产品的范围，从产品可能的应用环境的角度刻画系统，SVT的目的就是确认（或验收）产品包需求给出的各种应用场景产品均能满足。

　　产品包需求不考虑内部实现的差异，SVT也是从整个系统的角度考虑包需求的各种应用场景，属于“系统级”的测试。

　　各个级别的测试描述完毕，回头再看看这个分层测试的模型图，不难发现以下几个特征：

　　1）基于系统架构的分解结构（系统－子系统－模块－单元），开发按照自顶向下的顺序逐层设计，测试按照自底向上的顺序逐层验证，这个分解结构在每一层或每一个阶段，将开发和测试过程统一起来。

　　2）在每一层，测试的对象是开发相应阶段设计的输出（包括需求和这个阶段的设计文档），测试的目的与开发相应阶段设计的思路是相辅相成的，所以决定每个阶段的测试如何开展、评价一个测试过程时，如果离开开发过程，只谈测试自身的话，是不系统、不全面的。

　　3）除了“系统级”的SVT测试以外，其他各层的测试均包含两个方面：一是对这个层每个构件的测试，有n个构件就要测试n次，二是这n个构件之间接口的测试。例如：nSDV（每个测试项目组的SDV是一个SDV）和SIT、nMST（每个开发项目组的MST是一个MST）和BBIT、nUT和IT。

转自:http://www.51testing.com/html/99/n-211399.html

[原创]我答51testing每周一问？软件测试过程改进的内容和注意事项

   软件开发过程的质量决定了软件系统的质量，同样软件测试过程改进的质量决定了测试的质量和效率。其中，测试技术解决了测试采用的方法和技术问题，测试管理保证各项测试活动的顺利开展。然而，对于一个工程而言，过程也就是生命周期，也会至关重要地影响着生产效率和软件质量。测试工作有其本身的周期。测试过程从产品的需求阶段开始，此后，与整个开发过程并行开展，换句话说，伴随着开发过程的每一个阶段，都有一个重要的测试活动。

软件测试过程改进实施步骤。
1确定测试过程改进目标:：确定在一段时间内达到的测试过程改进目标；
2对比分析测试过程改进差异点： 把所要改进的测试过程要达到的目标与目前的测试过程作比较，找出存在的差距。

3制定软件测试过程改进计划：俗语说“凡事预则立，不立则废“。制定测试过程改进亦是如此！
4建立跟踪控制机制：测试过程的改进的需要建立相应跟踪，最好应由专人来负责，定期定时定点输出相应记录信息！
5 实施测试过程改进策略：制定了测试过程改进计划，应去执行具体的流程操作。然后要注意评审和验证，定期定时定点监控，采集测试过程改进度量数据。
6反馈总结再总结：总结测试过程实施过程中的经验，然后修改调整项目计划及实施改进的策略。

软件测试过程改进的内容，对于此问题，由于不同的公司软件研发力量，人员配置等不仅相同，所以用下图所示列出了一个提纲，可以给大家参考：

软件测试过程改进注意事项：

1 获得管理部门支持；

2 确定测试过程“基线”，明确度量的参考数据；

3 制定合量的度量指标；

4 考虑测试过程改进范围大小，应结合公司实际情况；

5 监控过程的并进行改进；

6 相关培训及支持工作；

7 “持之以恒”，过程改进的效果通常都是需要一定时间及数据才能说明问题。

原始链接：http://www.cnblogs.com/mayingbao/archive/2008/10/08/1306530.html

转自：http://www.51testing.com/index.php?uid-124415-action-viewspace-itemid-131362

这段文章是我导师在入职伊始发给我的，指引着我快乐的去做技术。

假设你的名字叫小不点，你住在一个大院子里，你的邻居有很多小伙伴，在门口传达室还有个看大门的李大爷，李大爷就是你的网关。当你想跟院子里的某个小伙伴玩，只要你在院子里大喊一声他的名字，他听到了就会回应你，并且跑出来跟你玩。
但 是你不被允许走出大门，你想与外界发生的一切联系，都必须由门口的李大爷（网关）用电话帮助你联系。假如你想找你的同学小明聊天，小明家住在很远的另外一 个院子里，他家的院子里也有一个看门的王大爷（小明的网关）。但是你不知道小明家的电话号码，不过你的班主任老师有一份你们班全体同学的名单和电话号码对 照表，你的老师就是你的DNS服务器。于是你在家里拨通了门口李大爷的电话，有了下面的对话：
小不点：李大爷，我想找班主任查一下小明的电话号码行吗？
李大爷：好，你等着。（接着李大爷给你的班主任挂了一个电话，问清楚了小明的电话）问到了，他家的号码是211.99.99.99
小不点：太好了！李大爷，我想找小明，你再帮我联系一下小明吧。
李大爷：没问题。（接着李大爷向电话局发出了请求接通小明家电话的请求，最后一关当然是被转接到了小明家那个院子的王大爷那里，然后王大爷把电话给转到小明家）就这样你和小明取得了联系。
至于DHCP服务器嘛，可以这样比喻：
你家院子里的居民越来越多了，传达室李大爷那里的电话交换机已经不能满足这么多居民的需求了，所以只好采用了一种新技术叫做DHCP，居民们开机的时候随机得到一个电话号码，每一次得到的号码都可能会不同。
你家门口的李大爷：就是你的网关
你的班主任：就是你的DNS服务器
传达室的电话交换机：就是你的DHCP服务器
同上，李大爷和王大爷之间的对话就叫做路由。
另：如果还有个小朋友叫做小暗，他住的院子看门的是孙大爷，因为小暗的院子刚盖好，孙大爷刚来不久，他没有李大爷和王大爷办公室的电话（李大爷和王大爷当然也没有他的电话），这时会有两种情况：
1、居委会的赵大妈告诉了孙大爷关于李、王两位大爷的电话（同时赵大妈也告诉了李、王关于孙的电话），这就叫静态设定路由
2、赵大妈病了，孙大爷自己到处打电话，见人就说：“我是小暗他们院子管电话的”，结果被李、王二位听到了，就记在了他们的通讯录上，然后李、王就给孙大爷回了个电话说：“我是小明（小不点）他们院子管电话的”，这就叫动态设定路由

然 后有一天小不点要找小暗，结果自然是小不点给李大爷打电话说：“大爷，我找小暗”（这里省略了李大爷去查小暗电话的过程，假设他知道小暗的电话），李大爷 一找通讯录：“哦，小暗的院子的电话是孙大爷管着的，要找小暗自然先要通知孙大爷，我可以通知王大爷让他去找孙大爷，也可以自己直接找孙，那当然是自己直 接找孙方便了”，于是李大爷给孙大爷打了电话，然后孙大爷又把电话转到了小暗家。
这里李大爷的通讯录叫做路由表。
李大爷选择是自己直接找孙大爷还是让王大爷帮忙转接叫做路由选择。
李 大爷之所以选择直接找孙大爷是有依据的，因为他直接找孙大爷就能一步到位，如果要王大爷转接就需要两步才能完成，这里的“步”叫做“跳数”，李大爷的选择 遵循的是最少步骤（跳数）原则（如果他不遵守这个原则，小不点可能就会多等些时间才能找到小暗，最终结果可能导致李大爷因工作不力被炒鱿鱼，这叫做“延时 太长，选路原则不合理，换了一个路由器”）
当然，事情总是变化的，小不点和小明吵架了，这些天小不点老是给小暗打电话，小明心里想：“操，他是不是在说我坏话啊？”于是小明决定偷听小不点和小暗的通话，但是他又不能出院子，怎么办呢？小明做了这样一个决定：
首 先他告诉自己院里管电话的王大爷说：“你给李大爷打个电话说小暗搬到咱们院子了，以后凡是打给他的电话我来接”，王大爷没反映过来（毕竟年纪大了啊！）就 给李大爷打了电话，说：“现在我来管理小暗的电话了，孙已经不管了”，结果李大爷就把他的通讯录改了，这叫做路由欺骗。
以后小不点再找小 暗，李大爷就转给王大爷了（其实应该转给孙大爷的），王大爷收到了这个电话就转给了小明（因为他之前已经和小明说好了），小明收到这个电话就假装小暗和小 不点通信。因为小明作贼心虚，害怕明天小不点和小暗见面后当面问他，于是通信断了之后，又自己以小不点的名义给小暗通了个电话复述了一遍刚才的话，有这就 叫数据窃听。
再后来，小不点还是不断的和小暗联系，而零落了小明，小明心里嘀咕啊：“我不能总是这样以小暗的身份和小不点通话啊，外一有 一天露馅了怎么办！”于是他想了一个更阴险的招数：“干脆我也不偷听你们的电话了，你小不点不是不给我打电话吗！那我让你也给小暗打不了，哼哼！”，他怎 么做的呢？我们来看：
他联系了一批狐朋狗友，和他们串通好，每天固定一个时间大家一起给小暗院子传达室打电话，内容什么都有，只要传达室 的孙爷爷接电话，就会听到“打雷啦，下雨收衣服啊！”、“人是人他妈生的，妖是妖他妈生的”、“你妈贵姓”等等，听的脑袋都大了，不听又不行，电话不停的 响啊！终于有一天，孙爷爷忍不住了，大喊一声：“我受不了拉！！！！”，于是上吊自杀了！
这就是最简单的DDOS攻击，孙爷爷心理承受能 力弱的现象叫做“数据报处理模块有BUG”，孙爷爷的自杀叫做“路由器瘫痪”。如果是我，就会微笑着和他们拉家常，例如告诉他们“我早就听了天气预报，衣 服10分钟前已经收好了”或者“那你妈是人还是妖”或者“和你奶奶一个姓”等等，我这种健全的心理叫做“健壮的数据报处理，能够抵御任何攻击”
孙爷爷瘫了之后，小不点终于不再给小暗打电话了，因为无论他怎么打对方都是忙音，这种现象叫做“拒绝服务”，所以小明的做法还有一个名字叫做“拒绝服务攻击”。
小明终于安静了几天，...
几天后，小明的院子来了一个美丽的女孩，名字叫做小丽，小明很喜欢她（小小年纪玩什么早恋！）可是小丽有个很帅的男朋友，小明干瞪眼没办法。当然这里还是要遵循上面的原则：小丽是不能出院子的。那个男的想泡小丽自然只能打电话，于是小明又蠢蠢欲动了：
还记得王爷爷是院子的电话总管吗？他之所以能管理电话是因为他有一个通讯录，因为同一个院子可能有2个孩子都叫小明，靠名字无法区分，所以通讯录上每一行只有两项：
门牌 电话
一号门 1234567 （这个是小明的）
二号门 7654321 （这个是小丽的）
......
王 爷爷记性不好，但这总不会错了吧（同一个院子不会有2个“二号门”吧）？每次打电话人家都要说出要找的电话号码，然后通过通讯录去院子里面敲门，比如人家 说我找“1234567”，于是王爷爷一比较，哦，是一号门的，他就去敲一号门“听电话”，如果是找“7654321”，那他就找二号门“听电话”。
这里的电话号码就是传说中的“IP地址”
这里的门牌号就是传说中的网卡的’MAC‘地址（每一块网卡的MAC地址都是不一样的，这是网卡的制造商写死在网卡的芯片中的）
小 明心里想“奶奶的，老子泡不到你也别想泡”，于是他打起了王爷爷通讯录的主意，经过细心的观察，周密的准备，他终于发现王爷爷有尿频的毛病（毕竟是老人 啊...），终于在一个月黑风高的白天，王爷爷去上厕所了，小明偷偷的摸进传达室，小心翼翼的改了王爷爷的通讯录......
过了几天，小丽的男朋友又给小丽打来了电话，对方报的电话是“7654321”，王爷爷一看通讯录，靠：
门牌 电话
一号门 1234567 （这个是小明的）
一号门 7654321 （注意：这个原来是小丽的，但是被小明改了）
......
王爷爷不知道改了啊，于是就去找一号门的小明了，小明心里这个美啊，他以小丽父亲的口吻严厉的教训了那个男的和小丽之间不正当的男女关系，结果那个男的恭恭敬敬的挂了电话。当然小丽并不知道整个事情的发生...
这里小明的行为叫做“ARP欺骗”（因为在实际的网络上是通过发送ARP数据包来实现的，所以叫做“ARP欺骗”），王爷爷的通讯录叫做“ARP表”
这里要注意：王爷爷现在有两个通讯录了，一个是记录每个院子传达室电话的本本，叫做“路由表”，一个是现在说的记录院子里面详细信息的本本，叫做“ARP表”。
有句命言是“人们总是在追求完美的，尽管永远也做不到”（请记住这句话，因为这是一个大名人--也就是我，说的）
王 爷爷的制度中有一条是这么写的“每个月要重新检查一下门牌号和电话的对应本（也就是ARP表）”，这个动作叫做“刷新ARP表”，每个月的时间限制叫做 “刷新ARP表的周期”。这样小明为了让那个男的永远不能找到小丽，之后每个月都要偷偷改一次那个通讯录，不过这样也是不得不做的事啊！
补充一点，小明是很聪明的，如果通讯录（ARP表）被改成了这样：
门牌（MAC） 电话（IP）
一号门 1234567 （这个是小明的）
二号门 1234567 （注意：这个被小明改了，但是他一时头晕改错了）
......
就会是计算机就会弹出一个对话框提示“出现重复的IP地址”，最终会导致王爷爷不知所措，于是通知一号门和二号门，你们的电话重复了。这样小丽就知道有人在破坏她的好事，这个现象叫做“骗局被揭穿了”
小不点知道了小明偷听他和小暗的电话，于是就和小暗约定好了密码。小不点在家里把要说的加密了之后告诉小暗。土豆－〉星期三，地瓜－〉请客，笨蛋－〉小不点家。于是小不点告诉小暗：土豆笨蛋地瓜。小明听了？？？不懂。。。。郁闷了。。。这是加密。
除 此之外，小丽也知道了小明改他家的电话号码了。于是王爷爷就登门一个一个把电话和门牌号记下来。并且藏起来不允许外人修改，只能自己有钥匙（密码）。这是 ip地址和MAC地址绑定。当有人改了电话号码的时候，就得找王爷爷改。麻烦是麻烦了，但是安全了。不过小明偷偷的把王爷爷的钥匙偷配了一把（盗窃密码成 功），于是他还可以修改。这样么，就这样了。