软件测试当中根据TFS中Priority定义的4级错误级别的规定：

一级(P1：Critical)：不能完全满足系统要求，基本功能未完全实现；系统崩溃或挂起等导致系统不能继续运行，应尽快(或立刻)修复

包括以下各种错误：

1.  黄页

2.  功能或特性没有实现

3.  整个模块或大功能不工作,影响大量的case不能执行的

4.  严重的安全性问题主要功能错误

5.  业务流程不正确

6.  功能实现不完整，如删除时没有考虑数据关联

二级(P2：High)：虽然不影响系统的使用，但没有很好地实现产品的功能，或者功能的实现和需求不符合,没有达到预期效果，或用户界面差、操作时间长,一些大的逻辑性问题,一般的安全性问题

包括以下各种错误：

1.  打印内容、格式错误（只影响报表的格式或外观，不影响数据显示结果的错误）

2.  简单的输入限制未放在前台进行控制，例如页面中textbox的输入的最大长度，字段的输入类型等没有验证等

3.  虽然正确性不受影响，但系统性能和响应时间受到影响

4.       数据显示不正确但detail页面正确

三级(P3：Medium): 界面结构布局错误、显示风格错误、文字描述错误、常用控件使用规范错误

包括以下各种错误：

1.  鼠标（光标）定位错误，光标跳转设置不好

2.  长时间操作未给用户提示

3.       可输入区域和只读区域没有明显的区分标志

4.       必填项与非必填项没加以区别

三级(P3：Low): 出现机率很低的罕见错误，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题

包括以下各种错误：

1.  界面不规范不能有横竖滚动条

2.  提示信息不精确

3.  提示窗口文字未采用行业术语

4.  不明显的对齐问题

5.       建议性问题

进继续教育组已经快半年了，有些疲了，慢慢的就习惯了为了工作而工作。

个人心得体会：

1.测试计划一定要订，不一定执行，虽然计划总是不适合，并且总是处于变化之中，还是需要计划，大的小的，都是要订一个的。

2.不要指望开发人员能帮你进行测试，有这个想法还不如让他们做单元测试。

3.不同的测试阶段测试的重点是不同的。在项目最开始，主要保证流程能走通。流程走通了以后再进行功能的完整测试，包括界面，一些不影响功能使用的，以及边界等方面。

4.测试的过程中尽量多和项目经理或者开发人员交流测试的情况，有什么问题，可以让他们出出主意想想办法。往往他们总会给你提出有建设性的意见。

5.和开发人员之间有什么矛盾，不要憋在心里，要直接交流，虽然有一些聊天或者联系的工具，还是以直接交流比较好，前提是不影响他工作的情况，以及在不频繁的情况下。（有时对一些开发人员的做法很是恼火，但是如果心里压抑着，做事就会很郁闷，所以强迫自己去和开发人员交流 。比如,有一个开发人员，把我提交的问题，全部都以不可再现的解决方式提交，我大为恼火，哪那么多不可再现的，具体情况，你具体备注一下，什么都没有标识就全部不可再现。再加上当时和他关系有点说不清楚（总感觉他对我有意见），所以那时我很郁闷，想了好久，还是决定直接和他说说，哪些是不可再现的，哪些是不属于他的功能，哪些是不需要修改的问题。和他说的时候，其他开发人员也都在，大家在一起笑笑，然后说说，事情就这么给解决了。我重新打开这些bug，他重新提交一下问题解决的方式。后来有什么不懂或者有异议的他都直接和我交流，这样大家做事又恢复了和谐。）

6.多进行交流。无论是和开发人员，还是和测试人员。流程这东西，交流的越多你就理解的越多。有时候交流了才知道，原来他们是这么实现的，于是你就知道自己该如何设计测试。交流的时候，一定要多听听别人的想法，不能想当然，但是也要把握自己的立场。

处理不好的问题：

1.有些开发人员，写出来的代码质量很差，导致修改的时候，一而再，再而三的出现问题，双方都很恼火的时候，该如何解决这样的情况，还不是很有办法。一方面，要考虑他的心情，改的次数太多，他要疯了。而我，因为每次流程走不下来，也快崩溃了。所以有的时候还是尽量以开玩笑的方式对待这些，既不让自己郁闷，也不让他觉得你是故意刁难他。结果就是，他的问题改了很多遍才勉强能使用。让项目经理或者小组组长去批评他？我感觉这样适得其反。现在的年轻人，脾气都大的很。万一不爽，走人。怕怕，得罪不起。

2.总感觉测试受开发人员的制约太严重。有的时候，明明感觉任务很紧很重，可就是力不从心。你加班的时候，开发人员不加班。流程走不下去，根本没办法。我想还是跟公司的测试以及开发的环境有关系。记得有一个贴子说是公司测试部要先进行一个预测试，通过了才提交到测试人员手里。而我们这边是测试人员直接使用开发工具把程序弄过来进行测试，根本不存在什么版本控制以及预测试的说法。这也不是我一个人能说了算的。哎。

     Always: 这类bug所要做到的就是如何把bug描述清楚

1． 察看当前和bug相关的条件并列出
2． 按照bug出现的步骤重复做3次以上以此来寻找最短的路径，尽量把不必要的过程过滤，当然不确定的步骤一定不能过滤
3． 描述的时候尽量做到每个步骤最多2个动作
4． 尽量用主动的英语句型，在遇到许多动作可以产生这个bug的时候，可以适当用被动句型，把最好重现bug的那个步骤写出来其他可放在括号中
5． Bug现象的说明一定要描述详细，不要放在步骤中
6． 发现bug之后的操作最好也做几个步骤(如果可以接着做的话)，这样更容易发现周围的bug，同时对开发人员解bug也是有帮助
7．尽量把bug的周围情况描述的详细些，不需要总是等到开发人员问了我们再去做

     Usually：这类bug和always一样重点就是把步骤描述全面详细且不冗杂

     Sometimes：这类bug在遇到的时候可以先和开发人员描述一下然后共同推测路径，如果可以转化为always或usually，解决就容易些了,实在重现不出来可以把自己所做的若干步骤都描述出来

     Once： 这类bug，开发人员解起来更难

作为测试人员，所能做的就是除了上述bug的描述之外需要更加注意的：

1． 尽量做到及时和开发人员沟通

2． 立刻检查当前状态并做记录

3． 把和当前bug相关的一切信息全部描述

4． 和当前bug可能相关的信息可以放在note中，一定要详细

此外，如果连续发生好几个bug，需要把每个bug的频率标注好，如果有外部网络或者设备等影响的尽量把这些外部环境也描述清楚，这样有助于开发人员解决问题。 

 我们的目的：“做到质量更好的同时效率更高，我们不但要发现问题还要帮助开发人员解决问题“

每个工作三五年的人多少都会遇到瓶颈，要么是技术，要么是管理。没有一条路是可以既定的，都是摸索着前进，网上有专家的介绍，也有前辈们的总结。

对软件测试这样一个新兴行业，在以前是算在软件开发一类的，现在大多公司都会独立出测试部门了，也就有了专职软件测试人员。职业规划一个很重要的点还要看社会环境，在中国大陆做软件开发的都是被认为吃青春饭，很多企业的职位也或多或少都如此设定，大多技术牛人最后都走向项目管理，虽然也许他不喜欢也不擅长，但为了未来为了薪水待遇很多时侯是必然之路。

[软件测试质量保证]书上看来，也算世界通用的：

1～2年，测试技能：熟悉整个测试过程及产品业务领域，学习和掌握自动化测试工具，学习测试自动化编程技术；开发和执行测试脚本，承担系统测试实施任务；掌握编程语言、操作系统、网络与数据库方面的技能。

3～4年，测试过程：深入了解测试过程，掌握测试过程设计及改进，参与软件工作产品的同行评审；进一步了解产品业务领域，改进测试自动化编程技术；能指导初级测试工程师；加强编程语言、操作系统、网络与数据库方面的技能。

4～5年，测试组织工作：管理1～3名测试工程师，担任任务估算、管理及进度控制；进一步培养在软件项目管理及支持工具方面的技能。

5～6年，技术管理：管理4～8名测试工程师，提高任务估算、管理及进度控制能力，完成测试规划并制定测试计划；研究测试的技术手段，保持使用项目管理及支持工具的技能；用大量时间为其他测试工程师提供技术及过程方面的指导；开始与客户打交道并做演示推介。

6～12年，测试管理：管理8名以上测试工程师，负责一个或多个项目的测试工作；与客户打交道并做演示推介；保持使用项目管理及支持工具的技能。

//这个不适应于国内，也许适合老美他们。不过我们可以从中了解软件测试人员需要具备哪些能力。国内最重要的是第一步你入了哪一行业，业务是什么？软件测试也如此，web测试？手机测试？手工还是自动？…

废话一堆之后来摸索软件测试，主要还是寻找自己的未来道路，但要记住的是好职业不是规划出来的，顾问们都是参谋者，总结者也仅是经验，自己的人生规划是自己的选择和实践的过程，需要适时代、市场变化而变化的。可以分步做

Step1:分析自己的优劣势，包括自己的专业技能以及语言能力，业务能力，管理能力

Step2:发掘自己的兴趣，喜欢和人打交道还是喜欢和机器打交道，这只是个偏向问题，人的沟通表达能力是最起码的

Step3:分析市场需求，看看市场上需要什么样的人才以及未来需要什么人才

Step4:结合自己的优劣势给自己定位，设定目标，大公司还是小公司，国企还是外企....

Step5:为自己的目标努力，记住最重要是坚持!

国外优秀测试站点(转)

对于一个测试人员来说测试用例的设计编写是一项必须掌握的能力。但有效的设计和熟练的编写却是一个十分复杂的技术，它需要你对整个软件不管从业务还是从功能上都有一个明晰的把握。

一、问题：
许多测试类书籍中都有大幅的篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图等。但实际应用中这些理论却不能给我们很明确的行为指导，尤其是业务复杂，关联模块紧密，输入标准和输出结果间路径众多时，完全的遵循这些方法只能让我们在心理上得到一种满足，而无法有效的提高测试效率。有时我们只有依靠以前项目的用例编写经验（或习惯），希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例设计上以前存在的问题现在依旧。
当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地：
 从此几乎很少被执行
 已经与程序的实现发生了冲突（界面变动，功能变动）
 执行用例发现的bug很少
 根本没有时间为新的功能需求增补用例
 有时间补充，但用例结构越来越乱，
 特性的用例与通性用例之间联系不明确（以新增需求为主线列出所有涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化）
 知道怎样执行这个用例，但它要说明什么呢？（多数用例给我们的感觉是只见树木，不见森林，只对某一功能，无法串起）

通过上面的一系列问题可以看到，似乎测试用例给我们带来的问题远多于益处，也正是因为在实际过程中遇到的问题积累，导致我们有很充分的理由忽视或拒绝用例的应用。
但没有用例或简略用例的编写我们又会舒服很多么？不言自明，谁也不想倒退发展吧。

二、原因：
事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现，究其原因我认为有如下几点：

1、没有适合的规范
“适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题，通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、书本上的定义，但它适合我们当前的项目么？
每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语，进入公司或项目组后也会进一步学习相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好？
在测试论坛中常能看到介绍用例编写方法的帖子，而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范？于是我们只得选择从书本或之前的用例中复制，不管是结构还是方式都依赖于以往•的经验，我并不是说这样就是错误的，但不能总结成文的经验无法给予测试更多帮助。
我们有太多经验，但却没有形成适合的规范。

2、功能与业务的分离
我们知道怎样列举一个输入框的用例，但却很少考虑说明这个输入框是用来做什么的，如果仔细分析不难发现，用例中这种功能与业务的分离越来越普遍也越来越明显。
边界值、等价类划分、因果图，这些用例方法是一种高度提纯的方法，本身就很偏向于功能及代码，所以怎样编写业务的用例我们就从理论上失去了参考。
复杂的业务会贯穿于整个软件，涉及众多功能点，里面组合的分支更不可胜数。测试用例务求简洁、明确，这一点也与业务“格格不入”。功能用例依赖程序界面，业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例，列举出众多的边界值、等价类。流程的操作只有凭借经验和理解，这时测试出的bug是最多的，但我们却无法使这个bug对应到一个用例中（点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体）。正因为我们没有很好的积累业务上的用例，才使得我们感到执行用例时发现的bug不多。
用例结构的划分一定程度上也造成了功能和业务的分离，依照界面模块建立文件夹，并在其中新建不同用例，这使得用例从结构上就很难联通起来。

3、测试未能跟上变化
变化！想象一下，当我们越来越多的听到开发人员在那里高呼“拥抱变化”“敏捷开发”的时候，测试又有什么举措呢？当地区特性，软件版本越来越多的时候，测试是否在积极响应呢？变化是我们面临的最大挑战，我认为测试未能跟上变化是造成测试过程中遇到种种问题和矛盾的主要原因。
对需求和程序的变化测试人员的感受是非常深的，测试总是跟在需求和开发后面跑，使得所有风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些“不必要”的工作：尽快投入测试，尽快发现bug，而非从整体把握软件的质量情况，统筹策略。
疲于应对的直接影响就是程序质量无法准确度量，进度无法控制，风险无法预估。用例与程序脱节，新增用例混乱和缺少。长此以往我们只得放弃修改、增补用例，甚至放弃之前积累的所有成果。用例变为程序变更的记录摘要，没有测试数据的保留，测试步骤和重点无法体现，新加功能与原来的程序逐渐“脱离”，可能还会出现相互违背的情况，但这我们却无法很快发现。
永远是变化决定我们的下一步工作，这也是混乱的开始。

三、可能的解决办法：
在这里我希望以探讨的方式提出一些可能的解决办法，因为上面的问题也许在成熟的公司和项目组内很少遇到，而遇到问题的也需根据不同的情况单独考虑。不用拘泥形式，最适合的就是最好的。

1、测试驱动开发，用例指导结果，数据记录变化
“测试驱动开发”（TDD）是一个比较新的概念，在网上可以看到很多介绍文章，它主要讨论如何让开发的代码更奏效（Work）更洁净（Clean），“测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码”。可以看到，TDD是建立在“代码”级别的驱动，但目前我们需要探讨的问题是怎样在黑盒测试中做到“测试驱动开发”。
首先我们需要纠正一个态度，很多人认为黑盒测试的技术含量不高，可思考可拓展的内容不多，主要的工作就是用鼠标在那里瞎点，于是很多“高级”的技术方法都试图与黑盒测试划清界限。但测试人员发现的bug有80％以上都是黑盒测试发现的，手工操作软件仍是目前检验软件质量最有效的一种方法。
如何在黑盒测试中做到测试驱动开发？我认为可以从用例级别做起，以业务用例指导过程和结果。
开发人员通常比较关注技术，对于业务上的理解容易忽视并出现偏差，而需求文档又不会很明确的指出应该实现怎样的结果，这使得从业务到功能出现一个“阅读上的障碍”，如果最后程序错误了还需返工，这样耗费的人力物力就非常大了。使用业务用例驱动开发，就是一个比较好的方法，同样这也需要运用测试中的各种方法，列举出业务流程里数据的等价类和边界值。
业务用例的构造要先于程序实现，与需求和开发人员沟通一致，并以此作为一个基准，保证程序实现不会错，还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面，但一定要有数据的支持。这就是测试主导变化的另一点“数据记录变化”。
我们不仅要应对变化，还要记录变化，使测试用例成为对程序持续性的监控，数据可以作为最基本、最简单的支持。当一个业务很复杂时可以拆分成段（业务段与程序中以窗体或页面的划分是不一样的），使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享，最理想的情况就是建立一个“数据库”，每个业务用例都从“数据库”中取得输入数据和预期结果，这个数据只是针对业务入口和出口的，当程序内部设计变更时，保留的数据不会因此而作废。举一个例子，例如我的程序要从某种文件中读取数据并计算结果，一段时间后程序内部字段增加了，如果是以保存的文件附件方式提供数据，则现在程序很可能就打不开这个文件了。使用“数据库”指导测试人员可以在变化的程序里直接针对业务输入，而不关心程序内部结构。
再进一步的话“数据库”就开始涉及到程序内部的接口了，这需要开发人员的配合。

2、为用例标明时间（版本）和优先级
为测试用例标明时间或版本可以起到一种基准的作用，标明项目进度过程中的每一个阶段，使用例直接和需求基线、软件版本对应。同样这需要规范流程，也是对变更的一种确认和控制。或者可以为用例增加一个状态，指明这个用例目前是否与程序冲突，当程序变更时改变用例的状态，并更新用例版本。
为测试用例标明优先级可以指出软件的测试重点、用例编写的重点，减少用例回归的时间，增加重点用例执行的次数，帮助项目组新人尽快了解需求，在自动化测试的初期也可以参考这个优先级录制脚本。

3、功能用例与业务用例分开组织
将功能用例与业务用例分开组织，按照不同关注点列举执行路径。业务用例应在开发前或同期编写，帮助测试人员和开发人员明确业务，了解正确流程和错误流程。功能用例更依赖于程序界面的描述，但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug，也许与业务无关，但用户往往很容易这样操作（例如登录名，你是否考虑到很长的名字，或者用户的键盘有问题，总是敲入n多空格在里面，这与业务无关，但程序将会怎样处理？）。

4、审核用例，结对编写
测试组长或经理对用例进行审核可以做到用例的补充和校对，但一般情况下是很难做到的，我们可以采用另一种方法，就是结对编写测试用例（前提是你有两个以上的测试人员），内部审核。
测试用例不是一个人编写一个人执行，它需要其他测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”，同时也能拓展思维，加强测试重点的确认，小组内部达到统一。一定程度上结对编写也可以减少组长或经理对用例的管理，提高组员的参与积极性。

四、发展
上面的这些解决方法只是一种建议，具体怎样实施到项目中还需根据情况而定。可以看到测试的发展方向是很多很广的，传统的黑盒测试并不是毫无新意，测试工作怎样适合我们而发展，将给予我们更多的思考。

以上是在CSDN网站发现的,以前在做测试的时候总是会遇到类似的问题,导致测试用例没有时间也很难去modified,设计的测试用例也只是功能测试用例,似乎与业务流出脱离了.以后要再能做测试,必须好好学习了

1.    开场白
　　首先，作为一个一直在网络和电信设备测试领域工作了几年的老油条，我想把我这几年的工作经历以及在我身边看到的故事与大家分享。希望能帮助一些刚进入测试的朋友能更好的从学生角色转换为一个职业人，少一些刚毕业时的迷茫。
　　我在大学时代学的是计算机，在毕业前对网络的认识也就是学校开设的两门课计算机网络以及计算机网络与通信课程，让我印象最深的是学了一大堆与高数有关的数学公式，例如什么香农公式这类。毕业前连IP子网都算不清，也就大概知道TCP,UDP的区别。我更多的时间和精力都放在了程序的开发上,曾用Delphi独立开发了一个全省系统的MIS系统，用Linux+Gcc+Gdb＋UDP开发了一个模拟QQ原理的即时聊天软件。

　　一晃到了大四找工作，我当时找工作的想法是：一定要进大公司，工资要高。我至今仍清晰的记得那句从此影响了我职业选择的话：“我们开发都要研究生，对测试是否有兴趣”。当时想了想测试没做过，可以先试试。再加上这家公司当年在成都地区非常火，在成都给本科生开得工资是最高的。所以，就抱着先试试的感觉应聘了测试。也许是我大学时代动手实习的经验较多，在没有笔试的情况下，成功应聘进了这家M公司。也是在大四的第二学期，我参加了M公司的第三期企业文化培训，这期参加培训的上百名研究院的新同事中本科生一共10人左右，而且来自成都高校的本科生才4人。说实话，我很庆幸自己的幸运。

　　1.“阴差阳错”
　　在随后2个月的网络知识培训中，我第一次见到路由器、交换机、VOIP网关、电信设备，在稀里糊涂的状态下进行着配置练习。我们那时真是魔鬼式培训，从早上8点半开始，一直持续到晚上11点。有一次还持续到了晚上12点。每天上午第一件事就是考试，将头天的学习内容进行笔试考试，基本上TCP/IP详解中每一个协议的报文结构都默写过。笔试成绩每天公布分数和排名。下午从1点开始一直到晚上11点就是上机操作。做完一个练习就做下一个练习，反正就是一直要做到晚上11点才下班回家。就这样一直维持了2个月的培训，每天都是新的理念知识，新的上机练习。压力非常大也非常累，进步也非常快。
　　七月分配产品线，我来到了最不愿意去的电信产品线。因为在培训期间，电信产品线的理念最难理解，也最难完成上机练习，远比TCP/IP详解难的多，所以几乎没有一个人愿意来到电信产品线。我和另3名同事都来到了电信产品线，没办法再难也只有蒙着头冲了。

　　八月我再一次被迫接受了不愿意的工作分配，电信产品线的测试经理将FrameRelay协议（因为这是一个老协议，所以我一直最不愿意测试这个协议）给我负责，并要求在半年内必须独挡一面，意思是以后公司遇到任何关于FrameRelay协议的问题都将由我来解决，就是公司这个协议的专家。对于一个刚毕业2个月的学生，面对这样一个要求，既感到压力也感到了一种挑战。在必须成为公司内该协议的专家且没有任何退路的情况下。

　　随后半年里，对于该协议无论理论还是任何实际问题我都以几乎十全十美的态度来学习或解决。不但对该协议的每一个细节，每一个bit的组合意义烂熟于心，更对该协议在产品中从FPGA到HDLC到驱动的所有实现原理进行了深入学习。再通过对实验室里和市场上各种问题的分析，最终在半年内渐渐做到了可以独挡一面，可以独立面对和解决任何与FrameRelay协议有关的市场技术问题。

　　“坚定信念，一定还有bug”
　　也就在这半年时间里，我对测试的看法发生了两次大的变化。第一次变化，在进行手工测试3个月后，我心中还是认为开发比测试有意义，有挑战。而测试则是简单，无聊的工作，让我做测试就是大材小用。在这时，我内心开始讨厌测试工作，因为自己从心里看不起测试。有一次我测试了5天FrameRelay协议，没有发现一个bug，之前我已发现了这个协议上百个bug。正当我沮丧时，一位老员工的一句话改变了我对测试的认识“想想办法，肯定还有bug”。于是，我怀着半信半疑的态度，利用周末梳理了自己的思路。从自己已发现bug的方式和现象，到FrameRelay协议的所有实现原理，最后自己又提出了10个新的测试方法。周一上班，只用了4个新方法就发现了一个一级bug，一个二级bug。从此以后，在我心中对测试的看法发生了根本性的改变，不再认为测试只能由能力差的人去做。测试同样具有很强的挑战性和成就感，测试是一个必须需要创造性的工作，而且是每天都会用到创造性能力的工作。
　　当你发现不了bug的时候，请相信这句话：“一定还有bug”。只要你坚定这个信念，一定会发现bug的。“坚定信念”成为了我以后鼓励新员工时最爱用的一句话。对于测试人员，每天的工作都是对自己潜能的一次挑战。昨天，自己还认为没有bug了，今天通过自己坚定的信念和创造性的劳动，又发现了新的bug。这不证明好的测试态度能让测试成为一份非常有挑战、创造性和成就感的工作吗？
　　在其后1年的工作中，因为我同时具有开发和测试的能力，公司希望让我做测试工具开发工作，但我拒绝了这个调岗，同期也拒绝了华为（不是慧通）邀请我从事测试工具开发工作的offer。我选择了测试。测试不但让我每天都能感受到自我挑战带来的成就感，进行创造性思考所带来的快乐。更能让我比普通的开发者用更短的时间了解到更多产品或功能实现的细节，能对系统了解的更广更多，让自己不但看到树枝，更能看到整个森林。这也是我只用短短3年

　　1.多时间就对很多网络和电信协议的应用及设备原理有了比较系统的了解。结合我自己的特点，我喜欢在适度深度的基础上，希望能对网络尽可能宽广的了解和掌握。而不喜欢一个点或是几个点一路走下去，掌握每一个细节。所以，我喜欢测试比开发更多一点。

　　2.“测试误解”
　　那么测试人员的水平怎么体现出差异呢？
　　我的看法是：不是你发现的bug数量多就很厉害，也不是你会写自动化脚本就比做手工测试的厉害，更不是你会用的测试工具多，你就厉害。好的测试人员应该首先具有严密的逻辑思路，同时还要有很强的发散性思维，能经常创造性的提出新的测试方案，并且具有非常强的分析问题、定位问题的能力。只要具备了很强的分析问题定位问题的能力和创造力，即使你所负责的模块是一个小模块，你也能发现很多严重的bug。
　　在测试中有些同事常有这样的误解：

　　情形1：有的同事所负责的模块是个老模块，小模块，所以发现新bug的数量很少。这时很多人常常就容易松懈，认为这个模块没bug了，再认真测试是浪费时间。

　　我的看法是：1、任何模块永远都有bug，只是还没找到触发条件。 2、一般人的常规思路用完了，这时正是你挖掘自身创造力的好机会。如果你这时能在自己思路严密分析的基础上提出一系列新测试方案，发现了新bug。你的领导一定会对你刮目相看，而自己的自信心一定会得到大大的提高。

　　情形2：有的同事所负责的模块是个新模块，大模块，随便乱搞也能发现许多bug。同样，这时测试者也很容易松懈，而不会进行有意识的分析和创造性的思考。
　　我的看法是：1、虽然你发现了很多bug，但是是否你能通过严密的分析，使得找 出的一级、二级bug数能占到每轮测试所发现bug数的大部分。不要总是在产品快要release市场发布前，忽然发现许多一级、二级bug。2、 只有通过自己严密的分析和创造力

　　发现的bug，才比乱测试所发现的bug更具价值。对于产品的质量才更有真正的保障，对于测试者的水平提高才有意义。否则，测试者自身能力得不到提高，公司产品更是留下了许多隐患的bug。

　　1.总结赠言
　　最后送大家几句我关于测试的看法：
　　1、 坚定信念，一定还有bug。
　　2、 测试是一份依赖严密思路分析和创造力的工作。
　　3、 测试能让你每天挑战自己。
　　4、 测试能让你的自信心不断得到提高。
　　5、 测试能锻炼你的创造力。
　　6、 测试能锤炼力你的性格，让你成为一个不易轻易放弃的人。
　　7、 测试能让你比普通开发者更快的了解到系统。

以上文章是转摘的,觉得后面的7大赠言值得学习!!!!,希望跟大家一起分享

不管你是一个测试新手还是一个经验丰富的测试专家，都有不少有益的东西需要牢记在心。
1、你是一个检查者，你不需要为质量负责很多测试人员误入歧途，不明白他们是评测产品的而不是控制产品的。这两者之间有着天壤之别。例如，一个测试团队花费好几周时间测试并发现很多缺陷，只是为了看着管理层决定发布一个有已知严重缺陷的产品。测试团队经常会感到士气受挫，置疑他们测试的目的。
　　我询问团队中的成员他们是否被支付薪水了，通常得到的回答都是“是”。我又询问他们是否尽力去做工作了，再一次，通常得到的回答都是“是”。我于是告诉他们，“你们做了你们的工作。你们尽力测试，发现了缺陷并进行了上报。那么现在可以回家休息了。实际上，作为一名测试人员唯一失败的地方是不上报一个已知的缺陷。”
　　这不会提高士气，但却有助于事情向正确的方向发展，特别是能让人不用每天晚上都在家接着办公。
　　很多测试人员，包括我，当我们刚开始测试工作时，似乎会觉得自己对我们所测试的系统应用的质量负责。尽管这个工作的出发点是让人钦佩的，可实际上我们测试人员对于产品的质量基本没有控制能力。也是由于这个原因，测试人员不为质量负责。现在问题是管理层并不总是能看到这种区别。所以经常看见管理层提出类似于“我们付钱给这些人不是为了获得高质量的软件吗？”的问题。
2、缺陷都是有价值的每一个缺陷都是深入了解和提高的机会。我们可能只有一次机会观察到一个缺陷，所以我总是告诉测试人员始终保持高度注意力，不要为测试的乏味所折磨。
　　缺陷信息可能是可获取的项目数据中最有效的资源之一。但是这都取决于我们能多好的捕捉和传达我们所发现的缺陷的相关信息。
　　每个缺陷都会花费整个组织的金钱。如果我们不能从中更进一步了解产品，我们会浪费大量时间和金钱。当我们把一个错误转换成一次深入了解的机会时杠杆作用就出现了。让我们面对它――有些教训只能通过经历来学习的。
　　由于一个缺陷而责备谁不会有任何好的作用。责备只会让士气低落、沟通中断。这就像不断鞭打一匹死马希望它能活过来一样。
3、你报告第一个问题之前一切都是美好的这就是一个测试人员所面对的现实。你可以计划测试，获取所需要的资源，看起来所有人都站在你这边。可当你报告第一个问题之后，事情就开始变得紧张了。
　　出现这种态度上的突然变化的原因是现在你在批评某些人的工作了。自尊心使得自我收到伤害，关系变得紧张。有些情况下自尊心是值得期盼的，只要知道当你开始发现问题的时候态度有可能变化就可以了。
　　我经常建议测试人员做的一件事是读一读一些你过去写的缺陷报告，假设自己是接收缺陷报告的人。你会发现自己需要更老练一些。写一个没有任何挖苦语句的缺陷报告可能没什么乐趣，但它的确有助于和开发人员之间保持一个好的关系。
4、只能测试你能观察的你可能总想测试一些真正有创造性的用例，但如果你没有办法观察到结果，那有什么意义？尽管有些应用让你能观察到很多，但仍然有你没办法接近的，例如结构、隐藏的对象、后台进程等。
5、别忘记你是怎样到一个地方的我不是在谈论知道为什么你走进一个房间，而是在测试时执行的步骤。对于测试新手常见的是发现了一个重大的缺陷，但却无法复现它以便定位解决。这样你只会觉得不舒服，不知道自己到底是真发现了一个缺陷，还是说仅仅是错误的使用了应用。
　　你能用来跟踪你的测试步骤的方法有测试脚本、测试记录、敲键记录器如Spector和屏幕视频捕捉工具如Hypercam。
6、标准和流程是你的朋友尽管标准和流程让一些人觉得受限，但它们为你的工作提供了有价值的指导。不要拒绝标准因为它们是详细的、具体的。因此用它们指导自己更快、更一致的完成自己的工作。
7、没有足够的时间用于测试几乎每一个测试人员都抱怨没有足够的时间用于测试，但实际情况是测试任何东西到完整的程度都是不可能有充足时间的。当你充分考虑软件的特性如可用性、安全性、兼容性、互操作性等时这一点尤其正确。
　　不要再抱怨缺少时间，学会根据风险来进行优先级排序，把注意力都放在对管理层很重要的应用目标上。有时候我们测试的内容超出了我们需要测试的，因为我们的目标偏离了产品的价值。
8、你不可能发现所有的缺陷如果你测试的东西后来有缺陷被发现，不要变得气馁。你可能已经做了非常全面的工作，获得了高水平的缺陷移除，但都是不可能的目标。
9、保持幽默感和对前景充满信心经常微笑、保持健康可能是你最好的生存方式。如果你正处在困难条件下，请相信，这一切都将过去。
10、争取做到最好而不是完美测试新手经常会陷入追求完美的过程中，认为的正确才是标准。我曾经也是受害者之一，但要为自己辩护的是，我以前深受80年代后期类似于“99.9%还不够好”的TQM帖子和文章的影响。
　　追求完美的问题在于它会让测试进程变慢，将担心引入你所做的一切，使得你对别人更挑剔，而且通常会让你的朋友和家人感到失望。
　　当然，没人愿意犯错误，但他们稍不注意就出现了。想不犯错误就是否认现实。争取做到最好是一种好的习惯，表明你对工作的态度和投入程度。如果你想努力做到最好，你就会往前再多走一点。
　　根据我的观察，大多数人看到错误或者经历失误时都是很宽容的。人们最关心的是你对待问题的反应。
11、开发人员不是敌人需要整个项目团队的努力才能递交高质量的产品。有时候似乎开发人员不太关心质量，这个时候事情背后可能存在隐情。这时候你需要更好的和开发人员合作而不是反对他们。要始终牢记良好的交流是一个项目成功的关键因素。当你和开发人员站到对立面时，交流就停止了，你测试所需的很多信息也无法获取了。
12、建立和维护一个私人的交际网你的私人和工作关系是一个很重要的资产。无论时当你有工作时还是当你没工作时他们都是一个很好的支持系统。找一个好的指导者，而当你学到足够的东西时成为别人的指导者。
13、持续锻炼自己的技能你的技能把你和别人区分开。始终通过参加专业会议、获取认证、阅读专业资料等来不断学习。我给自己制定的目标是每周至少读一本和个人发展以及职业发展相关的书（测试、领导艺术、商业、IT等）。
　　一个个人发展方面的专家说过如果你每天在任何特定的主题上花费30分钟进行阅读，五年之内你肯定能成为这个主题方面的专家。这一点对我是起作用的――你也可以试试。
　　另一种让自己始终内行并建立网络的好的方式是活跃在一些QA或者测试论坛上。
14、当前进变得困难，懒惰就需要创造力了当我第一次成为一个测试团队负责人时，我用这句话做了一个字条挂在我的桌上。它不断提醒我把创造力作为我解决问题的一个杠杆。
　　学着从一个新的有创造性的方式来看待问题。你可能有一个好的测试计划，但你如何应付各种变化呢？弹性是一个优秀的问题解决负责人的关键特性。
15、简单并不总是很容易我们测试中做的很多工作看起来都很简单。但是，挑战在于保持努力的连贯性。
　　有些解决问题的方式刚开始看起来很简单，但不要由于它简单和明显就丢弃任何一种想法。同样，不要低估实现一个简单想法所需要付出的努力。
　　一些看过我和William E.Perry合著的书“Surviving the Top Ten Challenges of Software Testing”评论说这些挑战都很简单且很容易解决。这就让我奇怪为什么人们还在年复一年的提出“人的问题”。我认为在大脑中产生想法比实际实现出来要简单的多。
　　结论智慧比知识更重要。你可能已经学习了大量测试技术，但如果你没有足够的智慧判断什么时候采用它们，没有从整体上理解它们，你应用它们的能力将受到很大限制。对任何都有涉猎的你存在的一个问题是“你不知道什么你不知道”。智慧帮助你明白你需要知道哪些东西才能成功。
　　上面罗列的这些都是我希望我刚开始测试时都已经完全认识到的。我希望它们对你有帮助。
软件测试经验与教训
第一章　测试员的角色
    测试员要在项目中起什么作用?这是本章要讨论的问题。像有关测试的很多问题一样，这个问题初看起来答案很明显、很平凡，但其实不然。
    一个角色就是一种关系。这意味着人们不能控制自己的角色，但是可以协商。别人期望从测试员那里得到的可能并不合理。当测试员由于低质量的产品而受到指责时(这种事时有发生)，不管是谁指责，可能都存在分不清角色的问题。也许他们认为测试员的工作，就是在产品交付之前使用“质量魔术棒”敲打产品、他们也许认为测试员敲打得还不够狠。
    当测试员清楚了自己的角色之后．在协商角色内容时，就有了在可能出现的任何情况下确立对自己预期的基础。但是，即使是清晰和恰当的测试角色也是一种苛求。
经验１　测试员是项目的前灯
    一个项目就像是一次陆上旅行。有些项目很简单、很平常，就像是大白天开车去商店买东西。但是大多数值得开发的项目更像是夜间在山里开越野卡车。这些项目需要前灯，而测试员要照亮前面的道路，使程序员和经理尽管还在拿着地图争吵，但是至少可以看清他们在哪儿，要从什么样的路面上开过去，离悬崖峭壁有多远。每个公司测试团队的具体使命都不尽相同．不过在这些细节背后的要素都是一样的。测试就是要找到信息，有关项目或产品的关键决策都是根据这些信息做出的。
经验2  测试员的使命决定要做的一切
   测试员的使命，可能要取决于自己的行业、公司、项目或团队的个性．测试项目也干差万别。把测试作为一种工艺发展的挑战，一直是建立测试实践对话所面临的困难，这种测试实践要跨越我们之间的文化和技术差异。这些差异中的很多内容，决定了测试团队的不同使命。例如，在有些测试机构中，测试计划只是用来为测试员提供帮助的工具。测试计划可能写在餐巾纸上，且仍然有效。而另一些机构作为产品来编写测试计划，必须随软件一起交付。他们的测试计划必须遵循严格的格式和内容要求。
   以下任何要求都可能决定测试员的使命。读者期望的是哪种要求呢？
•快速找出重要软件问题。
•对产品质量提出总体评估。
•确认产品达到某种具体标准。
•帮助客户改进产品质量和可测试性。
•保证测试过程能够达到可分清责任的标准。
•就测试和与测试员协作方式培训客户。
•采用特定的方法集或遵循特定的规则集。
帮助预测和控制支持成本。
•帮助客户改进其过程。
•以最小化成本、时间或尽可能减少副作用的方式，完成自己的工作。
•为满足特定客户要求，完成所有必要的工作。
如果测试员将时间和精力都投入到客户并不关心的需求上，就会冒做无关工作或生产率低的风险，测试员要与自己的经理协商使命问题，并明确使命。如果不能就使命达成一致意见，就不会有做任何工作的好基础。
    如果测试员不知道该做什么怎么办?一种回答是评审使命？这样做可以找出自己的核心问题。如果测试员明确自己的测试使命，就可以为自己的工作辩护，并明确地确定下一步要做什么。测试员还可以用简单的描述，向其他人解释自己的角色。如果由于某种原因不能完成自己的使命，应该立即把这个问题汇报给管理层。
    如果测试员确切地知道要做什么该怎么办?经常重新考虑自己的使命，保证自己的计划不会由于过于偏重测试问题的一个方面，而忽略其他方面。
经验３　测试员为很多客户服务
    测试是一种服务角色，要乐于接受这种角色，因为测试员提供的服务是至关重要的。服务就意味着有客户，即要被服务的人。测试员是否成功，主要是看其是否很好地满足了客户的要求和最佳利益。这不会太难，不过测试会有很多客户，这些客户都有自己的需要，而且他们的各种需要不一定一致。
*项目经理。项目经理有资格了解测试员的工作进展并施加影响。测试员根据要求向其报告工作状态，迅速报告重要问题。并不要成为项目的瓶颈，从而为项目经理提供服务。指挥项目是项目经理的特权。测试员的责任就是告诉项目经理自己能做什么，不能做什么，有关项目的决策和条件会对测试产生什么影响。
*程序员。通过尽可能迅速地提供好的错误报告，使得程序员的工作更容易一些。努力提高自己的技能并了解产品，以免用错误的或用毫无意义的报告浪费程序员的时间。如果测试员可以做到这一点，就可以赢得更多的信任，而这种信任又可以转化为支持和影响。
*技术文档编写员。与测试员一样，负责编写文档和在线帮助的技术文档编写员也不能得到产品的完整信息。测试员可以帮助他们理解产品到底怎样发挥效能，并为其指出文档中的错误。技术文档编写员也会帮助测试员。当技术文档编写员研究产品，以及必须阅读文档的用户会怎样使用产品时，会了解到一些测试员不知道的信息。如果测试员与技术文档编写员有很好的关系，编写员就会告诉测试员有关产品的新特性、新用法、测试计划中的漏洞和他们所发现的软件问题。这些问题中的一部分永远也不会被报告，除非某个文档编写员知道哪个测试员关心这些程序问题。
*技术支持员。遗留在产品中的任何问题都会为技术支持员带来负担。测试员通过告诉技术支持员可能会给用户带来麻烦的产品问题，向其提供服务。如果测试员在开发期间与技术支持员一起工作，有时技术支持员会帮助测试员找出应该更正的软件问题。测试员也应该通过研究现场发现的难题，为技术支持员提供帮助。通过这种方式，能够把测试员与技术支持员拉得更近，进而与客户也更近了。
*市场开发员。市场开发员需要了解产品中任何与产品应该提供给客户的关键利益不一致的地方。对于程序员来说是很小的程序问题，对于市场开发员来说可能会是至关重要的问题。他们也许能意识到这种程序问题会使客户较难完成某种重要任务。此外，通过评审市场开发计划文档或描述，测试员可以帮助市场开发员对产品能力有更精确的认识。
*管理层和项目相关人员。测试员服务于公司业务，这也是为什么测试员必须小心，不要像个质量狂，而不是通信达理的人的原因。特别是到了项目要结束的时候，测试员要以兼顾公司短期和长期利益的方式完成自己的职责。要以明确、简洁的词汇编写测试状态报告，以便执行经理能够感到有做出决策的依据。
*用户。在测试员的心中，要想着将要使用该产品的人。当然，用户的满意是项目的最高利益。但是还要考虑满足主要用户对项目团队的特殊要求。
    以上列出的各条没有什么特别顺序，不过在实际项目中可能有一定顺序，因此要认真研究，找出对项目最重要的入，找出要服务的人。这是做好测试工作的第一步。
经验４　测试员发现的信息会“打扰”客户
    测试团队的使命包括(或应该包括)根据客户对价值的定义，通知客户有关威胁产品价值的任何信息。如果发现即使产品能够按意图运行，但是仍然达不到所要求的价值，则测试员有责任报告。如果客户忽视报告，那是他们的权力
经验５　迅速找出重要程序问题
    测试员的使命很可能包括找出重要的(与无意义相反)程序问题，而且要迅速找出。如果是这样，那么这对测试员所执行的测试意味着什么呢?
•首先测试经过变更的部分，然后测试没有变化的部分。修改和更新都意味着新的风险。
•首先测试核心功能，然后测试辅助功能、测试产品所完成的关键和常用功能，测试完成产品基本任务的功能。
•首先测试能力，然后测试可靠性。先测试每个功能是否完全能用、然后再深入检查任何一个功能在很多不同条件下表现如何。
•首先测试常见情况，然后测试少见情况。使用常用的数据和使用场景。
首先测试常见威胁，然后测试罕见威胁。用最有可能出现的压力和错误情况进行测试。
•首先测试影响大的问题，然后测试影响小的问题。测试在出现失效的情况下会产生大量破坏的产品部件。
•首先测试最需要的部分，然后测试没有要求的部分。测试对团队其他人有重要意义的任何部分的任何问题。
  测试员如果对产品、产品必须与之交互的软件和硬件以及将使用软件的人越了解，越有可能更快地找出重要问题。应好好研究这些方面的内容。
经验６，跟着程序员走
   为程序员提供支持，很可能是测试员使命的关键部分。在测试员测试程序员正在编写或刚刚完成的程序时，测试员的反馈有助于提高程序员的工作效率。程序员交付软件后，应该马上测试；程序员修改代码后，应该马上测试所做的变更。尽可能建立最短、最快的反馈环路。当程序虽正在苦苦地思索测试员刚刚发现的程序问题时，测试员又开始寻找更多的程序问题。对于测试员来说，理想情况是，程序员为了修改测试员找出的程序问题忙得团闭转，使程序员（而不是测试员）成为项目的瓶颈。
经验７，询问一切，但不一定外露
    不问问题当然可以测试，但是不可能测试得好。问问题是测试员对项目发挥作用的基础。不问问题．测试就没有目标，就是呆板、机械的。不过很直白的问题会刺激别人，常常使人产生顾虑。
    问题就像是一剂猛药，最好采用低剂量，或与饭一起吃(即结合其他沟通形式)。幸运的是，这样问问题的价值并不低于直白地发问。测试员所想到的任何问题都会有助于启发自己的思想，最终产生对问题的至关重要的认识。
    如果测试员在测试时发现对产品提不出问题，那么还是先停下来。
经验８，测试员关注失效，客户才能关注成功
    测试是项目团队中唯一不直接关注成功的角色。其他所有人都在创造什么，或创造性地指导创造。但测试员却是消极的。测试会是一种沉闷的工作，几乎像希腊神话所说：“测试者在孤岛上，注定要不停地寻找不会存在、也不应该存在的东西，深信成功会为神带来不幸。”
    重新定义比较积极的测试员使命是错误的，例如确认程序正常。即使“确认程序正常”作为使命交给测试员，测试员也要忠告客户，这样的确认是不可能的。这种确认成本极高。除非运行所有可能的测试，否则就不能证明程序正常。测试员只能够说：“就我所执行的测试来说，没有发现产品不正常。”但是反过来的确认就非常经济了：只需一个测试，就可以说明产品不正常。
    测试员关注失效，是因为这可以增加发现失效的机会。用自己全部的创造力和技能，寻找产品中的关键问题。如果测试员没有找到关键问题，程序员就不能改正，以后用户可能会替测试员找到。通过发现程序中客现存在的问题，测试员能够帮助项目团队更加了解自己的技能和产品风险，帮助他们将产品做得更好，更具可支持性，在市场中有可能更成功。
经验９，不会发现所有程序问题
    测试员的任务就是找出并报告重要的程序问题，但是不会发现所有的程序问题。为了发现全部程序错误，测试员必须检查所有可能有问题的地方，要在所有可能发生的不同条件下观察这些地方，还需要一种十分可靠的方法，当所有类型的程序错误发生时，都能够识别出来。如果测试员认为自己能够做到这些，那么要么产品非常简单，要么测试员的想像力太差。
    知道并承认自己不能做所有的事之后，测试员必须选择如何使用自己的时间。
经验１０，当心“完备的”测试
    有一些测试员承认自己不知道是否发现了产品中的全部问题，但仍然不准确地讨论结束测试的含义。“对这个产品我需要测试