步骤：（以下内容在WORD2003中操作，其它版本WORD略有差别，但大同小异。）

点击查看/下载大图（68K）

点击查看/下载大图（74K）

　　2．出现右边的一条“样式格式”栏，这里面主要就是用到标题1，标题2，标题3。把标题1，标题2，标题3分别应用到文中各个章节的标题上。例如：文中的“第一章 制冷概论”我们就需要用标题1定义。而“1.1制冷技术的发展历史”就用标题2定义。如果有1.1.1×××那就用标题3来定义。

点击查看/下载大图（74K）

点击查看/下载大图（70K）

　　4．用标题1，2，3分别去定义文中的每一章节。定义时很方便，只要把光标点到“第一章 制冷概论”上，然后用鼠标左键点一下右边的标题1，就定义好了；同样方法用标题2，3定义1.1；1.1.1；依此类推，第二章，第三章也这样定义，直到全文节尾。

点击查看/下载大图（67K）

　　5．当都定义好后，我们就可以生成目录了。把光标移到文章最开头你要插入目录的空白位置，选[插入]--[引用]--[索引和目录]

点击查看/下载大图（76K）

点击查看/下载大图（66K）

点击查看/下载大图（70K）

　　7．当你重新修改文章内容后，你需要更新一下目录，方法是：在目录区域内，点右键，选[更新域]

点击查看/下载大图（72K）

要求：
1）了解软件测试计划的重要性
2）了解软件测试计划的编写过程和主要内容
3）了解软件需求应该具有的特征
4）了解如何对软件需求进行静态测试
5）学会确定测试策略
6）学会定义测试环境
7）对软件测试管理工作有所了解

测试计划内容和要点
　　一个软件项目的测试计划是一份描述软件测试工作的目标、范围、策略、方法和重点的文档。测试计划的准备过程是思考检查并确认一个软件产品的可接受性的一个有用方法。
在测试计划中应当关注以下内容：测试需求、测试策略、测试资源、风险和意外。

测试计划中应该定义下列内容：
·测试活动进度综述，可供项目经理产生项目进度时参考。
·测试方法，包括测试工具的使用。
·测试工具，包括如何和何时获取工具。
·实施测试和报告结果的过程。
·系统测试进入和结束准则。
·设计、开发和执行测试所需的人员。
·设备资源，需要什么样的机器和测试基准。
·恰当的测试覆盖率目标。
·测试所需的特殊软件和硬件配置。
·测试应用程序策略。
·测试哪些特性，不测试哪些特性。
·风险和意外情况计划。

测试计划制定过程
步骤：
分析和测试软件需求－＞定义测试策略－＞定义测试环境－＞定义测试管理－＞编写和审核测试计划

1．分析和测试软件需求：在软件需求阶段，软件测试人员就需要加入到软件开发过程中。在这个阶段，测试人员需要对需求有完整的理解，还需要对需求文档进行测试，以确保软件需求文档的清晰性、无二义性。
2．定义测试策略：所谓测试策略，指的是总体的测试范围、测试活动的进入/退出标准、自动化测试工具的选择、测试文档的选择、测试软件的编写等。
3．定义测试环境：根据被测软件的不同，测试环境也有不同的组成。测试环境包括了软件运行的硬件平台、软件平台、数据，有时候也包括一些特殊的外围设备。
4．定义测试管理：要确定测试中每个阶段的目标，确定每项工作的工作量，评估风险，确定测试管理平台，确定开发人员和测试人员的沟通、协作方式，定义不同角色的职责。
5．编写计划文档：上述几项工作完成后，就需要编写测试计划文档。另外测试计划文档不是一成不变的，它需要根据情况的变化进行相应的更新。

分析和测试软件需求
需求分析过程：
需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有效性需求。简单地说需求分析就是准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。因此需求分析阶段必须清楚地理解所要解决的问题，完整地获取用户需求。

做需求分析的步骤：
（1）收集用户需求　可以通过客户访谈等途径收集客户需求。
（2）编写需求分析文档　从客户获得需求，整理并写成需求定义文档中是所有通过客户访谈获取需求的一个列表。它表示与开发组织之间的一个认可，需求定义编写采用自然语言，使用户易于阅读理解。
（3）编写软件功能说明
（4）编写软件需求跟踪矩阵　一旦需求被定义和说明，需要编写需求跟踪矩阵，其目的是跟踪每一个需求以确保其被实现和测试。
（5）审核软件需求文档

末完待续......

软件测试基础知识复习（一）

软件开发过程及软件质量保证
1.软件开发过程的几个主要阶段：
1）定义。明确开发的目标，软件的需求。
2）计划。制订软件开发所涉及到的计划。
3）设计。设计、编码、编写文档等，完成要求的软件特性。
4）稳定化。主要是测试和缺陷修复，确保软件的质量。
5）安装。安装、提交完成的软件，为客户提供运行环境。
2.几种常用的软件生命周期模型：
1）瀑布模型。
2）原型模型。
3）增量模型。
4）螺旋模型。
从软件测试人员的角度来看软件开发过程，需要注意的是：测试贯穿在整个开发过程中，而不是在某个阶段集中地做一下测试而其它阶段不用理会测试工作。

一个软件之所以被认为为质量优秀，是它内在具备了这样一些特性：
满足用户的需求；
合理进度、成本、功能关系；
具备扩展性和灵活性，能够适应一定程度的需求变化；
能够有效地处理例外的情况；
保持成本和性能的平衡。

软件质量保证(Software Quality Assurance-----SQA)是为了确保软件开发过程和结果符合预期的要求而建立的系列规程，以及依照规程和计划采取的一系列活动及其结果评审。

软件质量保证的活动主机包括：
技术方法的就用；
正式技术评审的实施；
软件测试；
标准的执行；
修改的控制；
度量；
记录和记录保存。

软件错误的定义：软件错误是软件产品中存在的导致期望的运行结果和实际结果间出现差异的一系列问题，这些问题包括故障、失效、缺陷。

软件测试：
软件测试就是为了发现软件中存在的错误而分析或执行程序的过程。具体地说，软件测试是分析程序或根据软件开发各阶段的规格说明和各程序的内部结构而精心设计出一批测试用例，并利用测试用例来运行程序，以发现程序错误的过程。

软件测试有两个基本的功能：验证(Verification)和确认(Validation)。
验证指保证软件正确地实现了特写功能的一系列活动。
确认指保证最终的产品满足系统需求。
通俗的说：验证保证产品的正确性；确认保证生产了正确的产品。

软件测试人员应该至少具备以下两个关键领域方面的知识：
1）软件测试技术；
2）被测应用程序及其相关应用领域知识。

理解以下的描述：
测试能提高软件的质量，但是提高质量不能依赖测试；
测试只能证明错误存在，不能证明错误不存在；
测试的主要困难是不知道该如何进行有效地测试，也不知道什么时候能够放心的结束测试；
每个程序员都应当测试自己的程序（份内事），但不能作为程序已通过测试的依据（所以项目需要独立的测试人员）；
80-20原则：80%的错误聚集在20%的模块中，经常出错的模块改错后还是会经常出错；
测试应当循序渐进，不要企图一次性做完。"欲速则不达"。

测试人员的目标和主要工作：
目标：（1）.基本目标是发现软件错误；
（2）.要尽可能早的找出软件错误；
（3）.必需确保找出的软件错误得以关闭。

主要工作：
1）规划测试任务
2）设计测试（包括编写测试用例等等）
3）建立一个合适的测试环境
4）评估、获取、安装和配置自动测试工具
5）执行测试
6）撰写适当的测试文档

软件测试的分类
1．从是否需要执行被测试软件的角度分：有静态测试和动态测试。
2．从测试是否针对软件结构和算法的角度分类分：白盒测试和黑盒测试。
3．从测试的不同阶段分：单元测试、集成测试、系统测试和验收测试四个阶段。
其中系统测试有：功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试等等。

针对某些功能作用的测试：
回归测试：指错误被修正后或软件功能、环境发生变化后进行的重新测试。
功能测试：测试软件的功能是否符合功能性需求，通常采用黑盒测试方式。
负载测试：测试软件系统的最大负载，超出此负载软件有可能会失常。
压力测试：与负载测试差不多，叫法不同。
易用性测试：测试软件是否易用，主观性比较强。一般要根据用户的反馈信息来评价。
安装与反安装测试：测试软件在"全部、部分、升级"等状况下的安装/反安装过程。
恢复测试：测试系统从故障中恢复的能力。
安全性测试：测试系统防止非法侵入的能力。
兼容性测试：测试系统与其它软件、硬件兼容的能力。
内存泄漏测试：测试软件在运行过程中是否会造成内存泄漏。
比较测试：通过与同类产品比较，考察该产品的优点、缺点。
Alpha测试：一种先期的用户测试，此时系统刚刚开发完成。
Beta测试：一种后期的用户测试，此时系统已经通过内部测试，大部分错误已经改正，即将正式发行。同Alpha测试一样都由用户进行，场地不同，Alpha测试一般是把用户请到开发方的场地来测试，Beta测试是指在一个或多个用户的场所进行测试。

测试工作的主要步骤：
1）测试计划：测试人员要首先对需求进行分析，最终定义一个测试集合。
2）测试设计与开发：根据软件需求、说明书完成测试用例设计并编写必要的测试驱动程序。
3）执行测试：需要做的工作是，建立测试环境；根据前面编写的测试计划和测试用例运行测试；记录测试结果；报告软件缺陷；跟踪软件缺陷直至其被处理；分析测试结果

PS　测试工程师职业素质
1）责任心
2）学习能力
3）怀疑精神
4）沟通能力
5）专注力
6）洞察力
7）团队精神
8）注重积累

2006-4-14笔记 By Pop

文章来源：AKA杂志

本文主要目的是加强项目组和测试中心之间的相互了解，分享一些测试人员在工作中的经验和成果， 从而使项目组和测试中心的配合更加默契，共同把握住产品的质量要素。

一、 测试的目的和原则
1、测试概念的范畴

　　广义上讲，测试是指软件产品生存周期内所有的检查、评审和确认活动。如：设计评审、系统测试。

　　狭义上讲，测试是对软件产品质量的检验和评价。它一方面检查软件产品质量中存在的质量问题，同
时对产品质量进行客观的评价。

2、测试的目的

　　简单地说，就是替用户受过，测试的最终目的是确保最终交给用户的产品的功能符合用户的需求，把
尽可能多的问题在产品交给用户之前发现并改正。

.......

             每每想多发一些文章在BLOG上，但是苦于没时间，所以这上面更新的很慢。希望朋友们能体谅我苦衷，有大家的鼓励我会更努力的发布一些自己对于测试的心得，信望能和大家多多交流。

======================================

1，  语句覆盖：程序中每个语句必须执行一次

浅谈GUI测试，我的毕业设计

       毕业设计终于做完了，感觉还不错。对WR的使用也更加熟练了，现在才明白很多问题只要集中精力去做也不会很难。由于作者水平有限，所有还有很多错误之处，如果有那请多多指教，感激不尽！在网上能找到WR的资料无非就这结果资料（WinRunner 7.6 Tutorial、WinRunner(CHI)、WinRunner使用说明书、使用WinRunner的几点建议、WinRunner使用说明第二版、WinRunner_脚本标准格式），但是对于更详尽的资料就更少了，所以下定决心学了WR之后一定要写个东西让新手学习起来更简单。我会持续修改，直到自己觉得还看的过去为止。

     还有就是建议初学者最好看看Oldsidney学习笔记，也就是WinRunner 7.6 Tutorial，看了之后收益匪浅。

     WR是做功能测试，而很多人都说功能测试我照样做！亲身体验之后才觉得功能测试自动化也是必不可少，比如说严整Windows_XP计算器9*9乘法口诀表手否正确，如果人工去按1*1=1，1*2=2 ……  9*9=81，你认为手工去执行这个 过程你用多少时间能执行完呢？30分钟？1小时？如果比这更大，数据驱动比这更多呢？时间是无穷近吧！但是使用WR做这个功能测试，首先，录制个脚本，建立数据驱动，修改脚本，回放脚本，验证结果。熟手做这个不会超过30分钟吧！而且TestWare（测试件）你也可以复用。那以下就说下学习的过程吧！

     如何说起呢？首先说下WR执行测试过程：1.创建GUI map2.创建测试3.调试测试4.执行测试5.查看测试结果6.报告发现错误。

   那就先说下GUI map，录制map 也有2种模式GUI map file per test和Global GUI map file。Global GUI map file是默认录制模式，而且可以多个脚本同时利用GUI map file per test模式的GUI map。GUI map file per test则不能让多个脚本共享。我的建议是从开始用WR的时候就要习惯使用Global GUI map file,而且GUI map最好要合并。

    现在TSL的录制吧！TSL脚本的录制也有两种模式Context Sensitive和Analog。WR默认是Context Sensitive模式。两种模式主要不同就是Analog 会录制鼠标轨迹，如果你是测试绘图软件之类的那就的选择Analog，其他的就选择Context Sensitive。建议脚本要分开，如果有错误，便于发现脚本错误；反之如果脚本合并之后错误很不好找，而且很费时间，对于这点感触颇多呀。

    对于同步点，和检查点、数据驱动的建立 参照Oldsidney学习笔记，上面很详细，按照上面写的做一次之后记忆应该很深刻了。

    脚本的三种运行模式： update（用于更新）,verify（正式运行，执行测试）,debug(调试模式) 

    这些WR基本的功能点虽然很简单，但尽量多做，使自己多熟悉，方便以后的使用。

    TSL脚本的使用，TSL是一个使用起来很简单的脚本，语法类似C，对于TSL的使用我也没很多的去研究，只是在遇到问题的时候查找tsl online help。

    这里附加一个TSL例子_计算器乘法功能测试（乘法表）//过程是论文指导老师王老师编写的

     过程如下：

1.      录制两个数相乘的基本脚本；

2.      使用数据驱动wizard助手建立数据驱动的数据录入，数据表中只有三列数据，第一列为乘数，第二列为被乘数，第三列为前两列相乘的积；

3.      用数据表中的数替换乘数和被乘数进行累乘；

4.      取结果框中的值，与数据表中的结果相比，看是否正确；

脚本如下

      在于测试的话：

     1，风险评估（就是对应可行性分析吧），就是评估下你的技术，资金等等;但是现在的项目都是前面开发了，你难道说你不测吗？就算技术不到位，立刻学也要把项目做了；就像接项目时，Market的人 把项目接回来难道你技术部不开发。所以这个多于是个形式吧；但可以把自己评估下，把自己认识更清楚。

     2，测试计划，这个好象就像需求分析吧；搞清楚测试的目标；测试资源（硬件，软件，人力资源）的安排；还有就是BUG管理的规范（包含BUG等级的划分和BUG优先等级……）；还有就是进度的安排。

     3，测试设计，这个对应概要设计和详细设计；主要就是TC的设计了。其实我会觉得这步烦的很

     4，测试开发，这个对应了编码吧。测试设计之后要把TC做成数据驱动，以及测试脚本的开发了（这些都是可以复用进行二次开发的）

     5，测试的实施，（这个有点对不上了哈）前面这些工作都做好之后，可以实施了，就是将准备好的数据驱动和测试脚本进行测试了。

     6，最好当然要测试总结了，看下预期结果和实际结果的差别。

软件测试流程粗析

        说实在的，我真的很同情他，也很同情他现在的处境。作为一个新上任的测试经理，自然会有一股子劲头，恨不能一夜之间就让部门面貌焕然一新，恨不能让所有的员工一夜之间突飞猛进……，可惜，罗马不是一天建成的，部门管理的问题也绝对不会解决得那么轻易。

        管理是一种艺术，对测试团队的管理更是一种需要小心的艺术。测试工程师一般都敏感且自尊，他们有发现缺陷的能力，自然也能轻易发现你在管理工作中的疏忽；他们能够评价应用系统，评价你的管理工作对他们来说也不是难事。

        那么，真的就那么难建立一个高效的测试团队吗？实际上，管理工作的核心是“人”，作为测试部门的负责人，只要抓住了这点，就能很顺利地把整个团队调动起来。我在不同的公司经历过不同的测试团队，在我的感觉中，测试工程师其实都是很好相处的人。测试工程师不是纯粹的技术人员，他们一般来说都敏锐、有耐心、有责任心、能承受工作压力，也具有比较好的沟通能力。但是，“测试工程师”这个对他们的统称掩盖了太多他们之间的不同。

        回到我们在文章最初的例子，当我问那位新测试经理“你觉得你理想中的测试工程师是什么样子的呢？”这个问题的时候，他的回答是“我希望他们都能有上进心、积极进取、有高的技术水平，同时能够承担工作压力。”我想，他的回答可能是用对自己的要求来要求部门所有的测试工程师了。一个全是将军的团队绝对不会比一个分工明确、高效协作的团队更加有战斗力。

        那么，究竟如何来建立一个高效的测试团队呢？这个问题，一定是“仁者见仁，智者见智”的问题。不过在这里，我不揣冒昧，说一些自己的看法。

1    测试团队中的“人”

        首先，高效的测试团队需要不同角色的“人”。根据我的经历，一般来说，测试团队中经常都有些这样类型的员工：

1.1   不同类型的员工

l         老虎

        测试部门的老虎是那些有活力、有冲劲的人。他们聪明、能干、敏锐、不惧怕压力。每个我见过的测试经理都期望能找到这样的人才，可惜，这样的人才并不多见，而且，这样的人才大多都是依靠测试组织自己培养出来的，一只“外来的”虎不一定能在新的组织中也发挥虎的威力。

        不过，即使在部门中有了老虎的存在，还必须为老虎创造出适合他的空间。很多测试经理都会为部门中能人的离去而烦恼，但在烦恼的同时，你有没有想过为什么他要离去？纯粹为了薪酬待遇？——实际上，老虎是很有上进心的，一旦他发觉自己只能在一个固定的环境中做固定的事情，他就会选择离开。要想留住这种类型的人才，必须为他创造一个时刻充满挑战的环境——让他开拓一片天地，让其他角色来“守城”，最可能是最合适的搭配。

l       牛

        牛是最勤勤恳恳的，踏实、勤劳、敬业是牛最好的写照。这样的员工能完成你交给他的明确的任务，把明确的任务交给他是最让人放心的。但美中不足，这样的员工往往缺少主动的创造性，明明他对业务很熟悉，明明他经验很丰富，但一旦要他跳出自己习惯的工作氛围和角色，创造性地完成一些工作，他们就束手无策了。这种类型的员工让人又爱又恨，爱的是他勤勤恳恳的态度，恨的是他不肯进取的心态。

l       猴子

        猴子是聪明的代名词，这种类型的员工聪明、大胆、活跃。在部门里，这类员工总是在鼓捣各种新工具、新技术、新名词。他们是工具引入的主要建议者和新技术采用的主要倡导者。这类员工对新事物有执着的热情，愿意去了解每一种他们所能接触到的新东西。对于解谜，这类员工有着天生的爱好，他们最大的兴趣就是从谜团一样的系统中找到能证明自己聪明的证据。然而，这类员工的缺点几乎和优点一样明显——缺乏持之以恒的耐心，一旦他们不得不长期进行一些重复性强的工作（例如，手工的回归测试），他们就会表现出不耐烦和由此因为疏忽产生错误。

l       长颈鹿

        长颈鹿在这里并不是“迟钝”的同义词。长颈鹿通常是一个部门中最有前瞻能力的人。他们具有对软件测试深入的理解和认识，能够对测试部门的发展提出非常好的建议（而不仅仅是意见），唯一的问题是，对细节上他们总是缺乏关注，能够给出漂亮的流程图或是建议书，但如果由他来执行，则一定是一场灾难。

l       狐狸

        测试部门中也会存在一些狡猾的人，我们可以把他们称为“狐狸”。狐狸这种类型的员工总是整个部门看上去最为忙碌的一个——他们为自己揽下一个又一个的工作，却用一个工作去掩饰在另一个工作上投入的无效劳动。每当你问起这类员工“A事情进行得如何？”，他们总能用“我正在忙着B事情（或是C事情）”这样的回答搪塞你。最终的结果是，经过几个月时间的忙碌，他们可能拿不出任何有效的工作成果。

l       鼹鼠

        当然，这种类型的员工可能是我们都不希望见到的。他们永远都想没有睡醒一样，更多时候看到的是他们茫然的眼神。交给他的任何工作都可能没有理由地失败，而且，更可怕的是，他们很少能够从失败中学习到教训。

        对这些不同类型员工来说，重要的不是改变他们的性格类型，而是要了解他们的性格类型，再根据他们的性格类型为他们分配不同的工作，让他们能够在一个能顺利施展自我和自我前进的环境中工作。

1.2    不同类型员工的对策

l         老虎——给他挑战，把部门最重要的、最困难的工作交给他，你只需要充分发挥他的主动性，定期让他汇报工作的进展就可以。让老虎觉得最安全的方法是让他能够充分证明自己的能力。当然，要注意的是，如果一个团队中有几只老虎，合理分配他们的工作（负责不同的方面）可能是一个好主意。

l         牛——让他做自己最擅长的事情。牛会很高兴自己在某个方面可以一直发展，直到成为这方面业务或是实施方面的专家。让他接手老虎开拓的工作范围，做一个好的执行者对组织是最有利的。当然，牛有时候也会提出想要一些“挑战”，这时候最好先为他准备好退路。

l         猴子——部门新技术研究的不二人选。无路是在测试自动化、测试工具引入、新的测试方法和测试技术引入方面，都可以仰仗猴子。不过，最大的风险来自于他们的不确定性和其天生地乐观心态，因此，如果让他们主导某个项目（例如，测试工具引入项目），要他们更加频繁地汇报工作进展和为他们规划细节。

l         长颈鹿——参谋。在规划部门发展的时候，可以多听听他们的意见，但最好不要让他们去完全承担部门测试过程改进的任务，在执行方面，他们可能并不会照顾到太多的细节。

l         狐狸——拿掉他用来隐藏自己的“多任务”。明确交给他一个任务，例如“完成某项目的测试”，时刻关注他们在任务进行过程中的报告，一旦发现他们主动承担不属于自己的任务，就要立刻分析，看他们是否又犯了老毛病。

l         鼹鼠——怎么说呢？给他一个机会吧。可能是他并不真正热爱这个工作，也或者是他有些心理上的疙瘩没有解开，不管怎么说，找出他这样糟糕表现的原因，如果真的没有办法改变他的工作，很可能只能选择让他离开现在的团队了。

1.3      团队成员的默契

        没有一个测试团队可以依靠一个人取得成功，成功必然是大家共同努力的结果。在短时间内建立一支成功的团队非常困难，因为你必须按照部门的规划去了解每个团队成员、对他们进行培训、在必要的时候重新培训等等。

        然而，由于种种原因，一个团队不可能总保持在建立之初的状态，有老成员的离开、也有新成员的加入。团队规模可能在变化，团队承担的职责也可能在发生变化。那么，在这些变化的同时，我们怎样让一个团队始终保持人员上相对的成功呢？答案就是“默契”。

        一个团队必须依靠制度才能建立这种默契。比如，建立员工之间的定期的沟通会、强制的培训和接受培训的机制、人员的定期轮换、岗位角色的互相备份等等。这方面没有定式可以遵循，每个人都可以按照自己团队的特点来建立体系，但必须要有这样的体系，才能将团队的成果和发展以某种形式固定下来。

2       测试团队的“规则”和“氛围”

        除了人员之外，最重要的就是团队的“规则”，也就是团队赖以生存的规范土壤了。一个团队的战斗力更多地体现在“令行禁止”上，因此，对成功的测试团队而言，必须要有明确的角色分工和明确的团队规则。

        另外，“氛围”也是测试团队的一个重要因素。所谓测试团队的氛围，就是一种置身其中的感受，一个高效的测试团队，必然有良好的氛围。

2.1      学习和交流的氛围

        一个高效的团队必然是一个持续学习的团队。测试团队中每个测试工程师其实都会对自己的未来有自己的规划，也会希望自己能够在团队中学习到更多的知识和技能。高效团队依赖团队中的每一个人来达到“高效”的目的，也要求每个团队成员都具有良好的技能，因此，学习的氛围是高效的测试团队必不可少的。

        但是，要建设学习型组织，并不是一件轻易的事情。组织不可能把学习作为一个任务来下达，因此学习必须要与工作进行结合；另外，如何调动组织中“能者”带动“暂时不能者”进行学习，也是很有技巧的事情。

l         部门讲师制度

        部门讲师制度是一种比较有效的制度。在我的实践中，部门讲师是一种权利，也是一种责任：“部门讲师”认证是获得“高级测试工程师”级别的必要条件；同时，要保留住“部门讲师”的认证，必须保证每月至少4个小时的内部课程，而且，内部课程获得的评价要大于平均8分。

        除此之外，每年评选一次年度的“最佳内部讲师”，每年对内部讲师进行一次重新认证，内部讲师可以优先获得一些外部交流的机会等等，这些都进一步将内部讲师变成了一种荣誉，从而使更多的成员愿意为整个团队奉献自己的知识和经验。

l         专题研究

        测试工程师都知道，测试工作最容易陷入的一种不好的工作状态就是“事件驱动”——测试工程师整天忙于处理临时的突发事件，而忽略了自身技能的提升和部门长远的目标。这种状态一旦持续下去，形成惯性，测试团队的成员很容易产生厌倦和倦怠的情绪，失去目标和方向，而这种没有目标和方向的氛围又很容易影响到整个团队的士气，乃至于导致人员的流失。

        我在工作中会采用一种“专题研究”的指导方式。实际上，在测试团队中，可以进行的研究和提高工作是非常多的，我们正好可以利用测试工作的“间歇性”特点，在不是很紧张的时候进行一些针对性的研究工作。之所以采用专题的方式进行研究，是因为要确定研究的目标，否则，研究工作没有目标的指引，很容易就会被忽略。而且，这种专题研究不要设置过大的专题，最好是能够在短时间内可以看到一定成果的专题。

l         重总结的气氛

        及时对自己的工作进行总结是一个非常良好的提升个人和组织能力的机会，一定要在组织内建立这种“重视总结”的氛围。总结并不仅仅是描述做了哪些事，更重要的是，要总结得失——“我们在这次的工作/项目中得到了什么？哪些地方有失误？能不能做得更好？”总结的目的不是为了惩罚某个人，而是为了让团队成员都能看到工作中的成绩和不足，总结出好的地方形成流程或是规范，从而提升个人能力和组织的能力。

2.2    用制度和流程形成团队的战斗力

l         制度流程先行

        “没有规矩，不成方圆”。一个高效的测试团队同时也一定是一支纪律严明的队伍。我们团队的每一个新入职者，不是首先去学习业务知识和测试技能，而是首先用一个月的时间学习我们的测试流程和工作规范，因为这些才是团队最直接的经验总结和提炼。

l         知识不止是个人的，更是团队的

        人员的交替对测试团队来说很很正常的事情，但无论人员如何变化，测试团队必须要能够保证团队不会由于某个人的离去而不能正常运转。我们在前面提到了“人员备份”的概念，除了“人员备份”之外，还必须通过一定的制度来保证人员的经验和知识能及时转化成团队的知识和经验。

Ø     “项目总结”制度可以保证在每个测试项目结束时，项目成员的经验能够体现为组织的经验；

Ø     “部门讲师制度”可以让个体（讲师）的技能与知识通过文字、语言的方式成为团队的知识和技能；

        最后建立高效的测试团队并不是一个轻松的任务，但也绝对不是“Mission Impossible”，只要团队的管理者能够管好“人”、“制度”、营造良好的“氛围”，相信每个管理者都能营造具有特色的成功高效的团队。

   最近工作一直很忙，也很累，正如那句话说的“疲惫的身体，疲惫的心”。但是那么累，我却过的是那么的开心。前两天在测试时代上看到一些测试的招聘信息，突然让我回忆起测试同行问过我关于测试的招聘与面试怎么知道是真是假，面对多家招聘公司的选择，怎么去判断自己的选择是正确的呢？今天突发奇想，觉的可以记录一些东西，因此便有了这个随笔。

今天记录下面两个问题的分析

1、  怎么从招聘信息分析公司对测试这个职位的了解？

2、  怎么知道所面试的公司是否适合自己？

从招聘测试的招聘信息和面谈可以了解招聘公司对测试工作的理解和态度 .

分析点 :

1)      如果招聘信息要求应聘者了解一些开发流程、测试流程、测试技术（如黑盒测试、白盒测试等等），可见这个公司了解测试这个工作岗位。

2)      在上面第一条的基础上，如果招聘信息要求应聘者熟悉测试工具的使用，可见这个公司在使用自动化技术或者有这个打算。

3)      如果招聘信息要求应聘者要有很好的沟通能力、表达能力、协调能力、适应能力、学习能力，可见这个公司的企业文化比较人文化（大家可以互相交流意见）。

4)      如果招聘信息详细描述包含了两部分：岗位名称和岗位职责，并且招聘信息描述正确、排版美观，说明简洁明了，可见这个公司人事管理规范。

面谈的时候，招聘公司是否重视测试、懂的测试这个职位，从这下面这几个方面就可以有些了解：

NO1 ：测试的领导是否做过测试工作。

很多公司管理者的技术能力是在程序员的时代得到的，这些人走上管理岗位后，如果没有持续的学习，就会根本不了解测试是怎么回事，有什么价值，在他们心目中，只有开发人员做的事情才是重要的，可见的。他们之所以招人做测试是因为软件的质量实在太差，客户的不满让他们无法忍受。面对测试狗屁不通的测试经理或者高级经理做测试工作，后果是：首先，努力得不到肯定，工作成果得不到尊重。接着，会发现成长的机会很少，因为领导既然不懂测试，也就不知道需要提高什么样的技能，既不要求你，也不支持你。你只好自己学习，而且难以获得支持和肯定。

NO2 ：测试的管理是否规范

招聘单位是否重视软件质量，从对待开发、测试的管理、执行是否规范就可以看出。测试在整个项目的介入、测试工作的评审，测试报告、对待严重 bug 的处理；对测试人员的考核、工作职责定位是否合理等等就可以了解这个公司测试大体执行情况。

NO3 ：知己知彼

看看自己目前的能力是否能胜任所应聘的岗位，看看公司的企业文化、办公环境是否能适应，看看公司的福利待遇是否能接受了。正如 testage 论坛上关河发起的讨论“ 测试工程师希望什么样的工作环境？”嘿嘿，我的回答是：

嘿嘿，对于目前的我来说，我希望在下面这样条件的公司做测试工作：

1 、公司的开发流程是按照正规流程走：需求分析 -- 概要设计 -- 详细设计 -- 单元测试 -- 集成测试 -- 系统测试 -- 验收测试，并对每一阶段的成果物进行有效的评审。因为：把时间花在做正确的事情上才是正确有效的工作方式。

2 、公司要重视软件的质量，测试可以参与到开发的整个活动过程，进行软件开发全过程测试。因为：测试对软件开发的过程、进度，对所测试软件产生的原因（即用户需求）以及使用的场景了解（即用户为什么要这么做）越清晰，测试的工作才能是准确、有效和高效的。

3 、公司要有懂的测试工作、理解测试工作的人，特别是测试、开发的领导者。因为：对牛弹琴，牛到死了都不知道你是在干嘛，琴弹的在好都没有办法领悟和理解。

4 、公司有学习氛围、有良好的沟通环境，大家可以互相的交流自己的思想、经验和对工作成果的意见。因为：有些工作，经过交流会得出新的、更好、更合理有效的处理方法。开发人员和测试人员有效、友好的沟通工作建议和经验会使整个团队的研发水平、测试水平、工作效率、工作质量向上发展。

5 、公司对测试人员的绩效考核是正确合理的，既不能用其它工种（如：开发人员、技术支持人员）的绩效考核方式来考核测试人员的工作，绩效考核的目的是激励员工工作的积极性。

6 、公司能够长期生存，公司领导能够规划好整个公司的发展方向、测试部门领导能够很好的规划部门的发展方向。

7 、公司的生意好好的，能接很多的项目进行研发。

测试管理之绩效考核

编写背景：

工作所在的部门启用了新的绩效考核制度，也开始了我参与对测试人员的工作进行绩效考核这一管理活动，第一次的考核结果让我有很多的感想，因此今天把它记录下来，也许突然有一天回头看这一感想，又会是另外一份心情。

思考：给测试人员进行绩效考核的目的是什么？

经过思考，我总结的答案是：

1、  为了了解工作情况，如：工作进度、工作状态。

2、  对每个人的工作进行评比，夸奖好的，批评差的。这个看起来有点像在学校上学时候的考试。

思考：有了这样的绩效考核目的，要用什么样的方式、方法去实现呢？

怎么样的绩效考核方式是最有效的呢？

对于现在的我，在现在这个小公司要想做好这个绩效考核，真是要好好思考。

1、  不同的工种，不能用同一种考核方式。如：测试人员的考核方式就不能和开发人员的考核方式相同。

2、  不同工种的考核结果是没有可比性的。如：测试人员的考核结果和开发人员的考核结果进行对比是没有意义的。

以上这两点不知道我的领导是否认同，还需要等到下一次考核的时候和他沟通沟通。

这是工作以来，第一次站在一个管理角色去思考、去做绩效考核这个工作。这第一次的考核工作让我不知道用什么语言来描述我的感受。

考核的结果是：测试组整体的分数都比开发的低，从排名和等级划分上可以说是包尾了。从分数上看，我的第一感觉是：难受。第二感觉是：生气。在和领导进行一系列沟通后，在回家的路上一直在思考、分析着这个结果，问题出在那里呢？问题出在那里呢？？？？？冷静的思考后，自己安慰自己，原因应该是这些吧：

1、  这次开发人员和测试人员使用的工作考核方式是同一种考核方式。

2、  这次把开发人员的考核分数拿来和测试人员的进行排名对比。

很显然，一直这样下去，测试人员的工作即使在怎么努力、分数超过开发人员的机率会很低很低，这样的对比规则，对测试人员来说，很不公平。这样的对比规则，很没有意义。更让我郁闷的是，面对这样的现象，我想不到很好的解决方法，目前只能鼓励测试人员加强自己的综合能力，自己给自己争气，对我来说，在测试人员的管理工作上，无形中出现了一个困难，只能是乐观面对了。

唉，工作种类不一样，放在一起作对比，永远说不清。

测试人员的工作，开发能作么？开发人员能写好测试需求、测试计划、测试用例、测试分析报告文档么，先不说写好，先说会写么？开发人员知道怎么样去执行测试么？知道发现 bug 应该怎么有效正确的去描述么？怎么快速有效的发现程序的问题么？能把握好整个软件测试的质量和进度么？测试，说的简单，真正做好没有这么简单。就拿黑盒测试举例，测试项有：业务流程测试、功能测试、安全性测试、性能测试、数据测试、用户友好性测试、配测试、兼容性测试。这些测试项所使用的测试方法、测试点，都能想全了、想到重点了么，想到了还只是第一步，真正要去执行测试的时候，测试环境的搭建、测试用例的编写与执行、 bug 的描述以及错误等级的正确划分、 bug 的回归、用测试工具进行测试，对测试工具正确有效使用的把握，这些对开发人员来说，会做么，能做好么？测试工作也有很大的工作压力，面对一个不熟悉的软件，面对一个什么说明文档都没有的大软件，要在最短的时间内，最有效的完成测试，要保证产品在发布后，不出现严重的问题，想尽一切办法的发现严重问题。这种对软件质量上的责任压力是很重的，还有其它我就不举例了。

开发人员的工作，测试能作么？测试能看懂开发人员的代码么？测试能写代码测试开发人员的程序么？测试能明白理解开发人员是怎么开发的么？测试能明白开发人员所说的工作术语么？测试能看明白开发人员的开发成果么？开发人员的工作也有很大的压力，要在最短的时间内编写出质量高的代码，实现功能，还要进行一遍又一遍的调试，需求一变，又要修改代码，自测时，发现问题，要进行调试找原因和解决方法，容易么？不容易。测试人员发现的问题，还要去找原因要想最好的解决方法。容易么？不容易。

我很同情那些把测试和开发放在一起作对比行为的人，因为他们对这两个工作中的其中之一理解有所欠缺从而导致这样的结果。说了那么多，好像扯远了。

最后，我得出这么个结论：这样的绩效考核方式，对测试人员来说，起不到激励作用。如果碰到不能正确心态去理解的测试人员，反而会起反作用，很打击工作积极性。因此领导在问我意见的时候，在不适合的说话时间、说话场合我只能说“无所谓”，心不甘情不愿的无所谓！！！！！！！！！！！！！！