这一篇内容比较简洁，主要是讲软件测试部门的定位，什么才是好的测试工作。 在以项目为基础的软件开发过程中，大致可分为需求调研，设计，开发，测试几个部分。测试是最后一个部分，而且是要依赖前三个阶段的成果，没有点适应能力是不行的;同时测试生

(1) 测试最重要的一件事就是要考虑到所有的出错可能性。同时，还要做一些不是按常规做的、非常奇怪的事。

说起来可能不太好听，测试的过程就像黑客 (Hacker)的攻击过程那样。可以这么说，像黑客这样的人是最好的软件安全测试员。他们专门找软件的漏洞，从而破坏这个软件，这样就可以修复这些漏洞保证软件的性能。如果找不到这种漏洞，那就说明该软件质量己经很好了。

(2) 除了漏洞之外，测试还应该考虑性能 (Performance)问题，也就是一定要保证软件运行得很好，非常快，没有内存泄漏，不会出现那种越来越慢的情况。

我们可以在不关机的情况下，与其他软件一起持续运行一个多月，看看是否会出现越来越慢的情况 (当然必须保证其他软件是没有问题的 )。我们在做 IE的时候，就是让它 72小时连续不停地打开不同的网页，处理几万个不同的网页，而且速度不能减慢。有许多软件，当只有一两个人用的时候，可能感觉不到什么问题，而当几百个用户一起用的时候，有的网站就出现各种各样的异常，这就是测试工作还比较欠缺的原故。

(3) 另外，测试还要考虑软件的兼容性 (Compatibility)。

一般来说，一个软件是由许多小软件构成的，如果其中一个小软件与它的前一版本不兼容，那么这个软件就会出现错误。这种错误需要通过测试来发现和解决。

许多人认为写代码的人一定能找出错误来。其实开发人员在写代码的时候，如果有错误，他可以意识到了，可是写出来的错误，他不一定能想得到。我自己也编过程序，在编程序的时候很自信，觉得不会有错，可事实上，即使是我编的小程序也有错误，但要自己找出来，却要费很大劲。因为我一直认为自己不应该出错，但常常错误就出现在我认为最有把握的地方。我是学数学的，是一个很细心的人，可是 --样还是会出错，但要找出自己的错误却要花费很长的时间。后来我写的代码让我的师弟帮我看，结果他很快就找到许多问题，可是我自己花一个月时间可能都找不到。所以，开发人员和测试人员完全不一样，开发人员确实可以找到一些 Bug，但是有更多的 Bug是他意识不到的。

在一般的开发团队中，并不需要测试人员定位 Bug的具体位置，所以，对测试人员的要求并不高。只要你愿意学，测试工作是非常容易做的。但是，我当年所在的 IE团队 (IE 4.0)就不同，因为当时正在与另一个公司的产品竞争，所以微软就要求尽量找到一流的开发人员和一流的测试人员，尽快开发出新产品，打败对手。所以，当时对我们测试人员的要求非常严格，不仅要找出 Bug，而且要定位引起此 Bug的代码行。然后将这些信息交给开发人员，后者就可以很快更正，省去了他们找错误出处的时间。因此，当时 IE的开发速度非常快，一年之内就发布了一个新版本，而且几乎役有任何大 Bug，大大超越了竞争对手。

Bug

Bug 的定义很广泛，在软件使用过程中所出现的任何一个可疑问题，或者导致软件不能符合设计要求或满足消费者需要的问题部是 Bug，即使这个 Bug在实践中是可行的。

有时候， Bug并不是程序错误。例如，软件没有按照一般用户的使用习惯来运行，此时也可以把这个问题看成是该软件的一个 Bug。

首先，测试人员根据测试结果来报告他发现的所有 Bug。通常，这项工作还需要用户的参与。微软在正式发布一个软件之前，经常要依次发布 Alpha测试版、 Beta测试版让用户试用，以便用户能够反馈出相关 Bug的信息。但是，现在随着微软测试队伍的扩大及测试水平的提高，越来越多的 Bug都是我们内部的测试人员自己发现的，很少出现外部用户所反馈的 Bug没有被测试人员发现的情况。

然后，开发经理根据这些 Bug的危害性对它们进行排序，确定 Bug的优先级，并安排给相关的开发工程师。

接着，开发人员根据 Bug的轻重缓急依次修复各个 Bug。

最后，测试人员再对开发人员已经修复的 Bug 进行验证， 确认 Bug是否已经被彻底更正。

微软开发一个产品经常会遇到几十万条 Bug。随着测试人员越来越多，测试工作也越来越完善。但是，如何快速有效地追踪并修复 Bug，仍然是摆在软件测试人员面前的一个主要困难。测试产品和追踪 Bug时最重要的是问题的定义，要清楚需要解决什么样问题，确定 Bug的主次关系，挑选出最主要的问题，并先解决它们。例如，有些 Bug可能会导致死机或程序崩溃，这时就要先修复它们，而另一些 Bug可能对软件的运行影响不大，或者出现的机会很少，就可以考虑以后再修复。

可以说，没有任何一个产品没有 Bug，也永远不可能找井修复所有的 Bug。在修复了旧的 Bug的同时，往往又会生新的 Bug。

这个过程就类似于数学中的“极限”的定义，尽管我们知道某个极限值为 0，但是它永远也不可能达到 0。这也就产品的 Bug永远也修复不完的原因。因此，我们在修复 Bug时要注意，一定要记住用户最需要的是什么，然后优先尽力修复那些影响用户使用的 Bug;而对于大部分对用户影很少、甚至根本不影响的 Bug，则可以推迟修复，甚至不修复。

软件测试阶段及其职责

1. 单元测试 (Unit Test): 按照代码的单元组成逐个进行测试。
2. 功能测试 (Function Test)或特性测试 (Feature Test): 按照软件的功能或特性逐个进行测试。例如，在 Exchange中，发送邮件和接收邮件就是两个不同的功能或特性，在测试时就分别对它们进行检查，看是否工作正常。
3. 提交测试 (Check-in Test): 在开发人员对代码做了任何修改，或者修复了某个 Bug时，需要重新 Check-in代码 (即将修改后的代码放大到整个大的系统中 )。这时，开发人员往往也要进行测试，看代码是否工作正常。为了保险起见，开发人员往往要找测试人员帮着一起进行测试 (我们把这种情况称做 Buddy Test)。测试人员和开发人员之间搞好关系是非常重要的，稍后我会专门讲述这一点。
4. 基本验证测试 (Build Verification Test，简称 BVT): 对完成的代码进行编译和连接，产生一个构造，以检查程序的主要功能是否会像预期一样进行工作。这是最简单而又最省时的一种测试方法。每产生一个新的构造时都要进行测试。如果连 BVT部通不过，表明问题很严重，开发人员需要尽快修复出现的问题，测试人员也就不用浪费时间做其他测试了。
5. 回归测试 (Regression Test): 过一段时间以后，再回过头来对以前修复过的 Bug重新进行测试，看该 Bug是否会重新出现。

(2) 使用测试 (Usage Testing)

使用测试是从用户的角度 (即外部 )出发的测试方法。它也包括许多类型。

• 配置测试 (Configuration Test): 从用户的使用出发进行多方面的测试。例如，保证软件不仅能够在 windows/' target='_blank'>Windows 9X下运行，也能够在 windows/' target='_blank'>Windows ME下运行，还能够在 Windows NT/200O/XP下运行 ;或者软件不仅能够在配置高的计算机上运行，也能够在配置很低的计算机上正确地运行。总之，要考虑到用户的多种情况，用多种配置对软件进行测试。
• 兼容性侧试 (Compatibility Test): 主要考虑兼容性问题，比如同一个产品的不同版本 (如 Office 2O00和 Office XP)之间的兼容问题，不同厂家的同一个产品 (如 IE和 Netscape)之间的兼容问题，不同类型软件 (如 IE和 Office)之间的兼容问题等。最难测试的往往就是软件的兼容性问题，往往要投人巨大的人力和物力。一些厂商开发出来的产品在兼容性上做得很不好，就是因为没有足够的人力和物力进行测试。

我在做 SQL Server的 XML测试的时候，为了解决 XML的兼容性问题，用了 6个测试人员和 100台计算机进行测试。正因如此，微软产品的兼容性都非常好。而不像市场上的一些产品，安装以后就导致计算机上的许多其他软件无法使用，或者出现各种各样的问题，这样不仅伤害了其他软件，也伤害了用户。

• 强力测试 (StressTest): 在各种极限情况下对产品进行测试 (如很多人同时使用该软件，或者反复运行该软件 )，以检查产品的长期稳定性。例如，我们在开发 IE 4.0的时候，由于当时有一个非常强的竞争对手，因此我们必须保证 1E4.0要做得非常好。当时，为了测试 IE4.0的长期稳定性，我们专门设计了一套自动测试程序，它一分钟可以下载上千个页面。我们使用这个测试程序对 IE4.0进行了连续 72小时的测试，也没有出现任何问题，如内存泄漏、程序崩溃等。

本项测试可以帮助找到一些大型的问题，如死机、崩损、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩滑。

• 性能测试 (Performance Test): 本项测试是保证程序具有良好的性能。如果别人的产品只需 5秒钟就能得出结果，而你的产品需要 10秒钟才能得出结果，就说明你的产品性能不好。如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着程序的算法不好，结构不好，或者设计有问题。因此在产品开发的开始阶段，就要考虑到软件的性能问题。
• 文档和帮助文件测试 (Documentation and help file Test ): 因为用户通常是通过文档和帮助文件来学习使用产品的，如果文档和帮助文件存在错误，就可能会导致用户无法正常使用产品。这项工作通常在产品即将 Ship(即准备包装发布 )时进行，以避免在修复 Bug的过程中需要反复修改文档，或者忘记修改文档，导致文档与产品的特性不相符。
• lpha和 Beta测试 (Alpha and Beta Test): 在正式发布产品之前往往要先发布一些测试版，让用户能够反馈出相关信息，或者找到存在的 Bug，以便在正式版中得到解决。

还有一种分类方法将测试方法分为如下几种。

(1) 白盒测试 (White Box Testing)

又叫做玻璃盒测试 (Glass Box Testing)。在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，有时候 SDE/T也会辅助开发人员进行测试。

(2) 黑盒测试 (Black Box Testing)

黑盒测试的内容主要有以下几个方面。

1. 接受性测试 (Aclearcase/" target="_blank" >cceptance Testing)：类似于 BVT测试。
2. Alpha/Beta测试 (Alpha/Beta Testing): 在此过程中，产品特征不断地修改。当发现 Bug后，在开发人员修改的同时，项目经理也会对产品计划做出相应的调整，产品计划不是一成不变的
3. 菜单 / 帮助测试 (Menu/Help Testing) ：大家千万不要以为这一项测试不值得进行。其实，在软件产品开发的最后阶段，文档里发现的问题往往是最多的。因为在软件测试过程中，开发人员会修复侧试人员发现的 Bug ，而且可能会对软件的有些功能进行修改，同时项目经理也会根据情况调整软件的特性，因而在软件开发和测试的过程中，所有的功能都不是固定不变的，都会进行调整。所以，一般来说，直到软件 Ship 时才编写软件的帮助文档，这样才能保证帮助文件的内容与软件功能相符，我在做帮助文件测试的时候，总是假装什么都不懂，就按照帮助文件提供的步骤去做，看看该文件是否正确。在实际测试中，我经常能发现帮助文件中的 Bug 。
4. 发行测试 ( Release Testing )：在正式发行前，产品要经过非常仔细的测试。除了专门的测试人员外，还需要几千个甚至几十万其他用户与合作者通过亲自使用来对产品进行测试，然后将错误信息反馈给我们。到了发行测试这一步，如果出现非改不可的 Bug ，就必须推迟软件的发行，有的时候一推就是几个月，期间需要重新对软件产品进行全面的测试，耗费大量的时间和人力物力。
5. 回归测试 ( Regression Testing )：回归测试的目的就是保证以前已经修复的 Bug 在软件 Ship 以前不会再出现。实际上，许多 Bug 都是在回归测试时发现的，在此阶段，我们首先要检查以前找到的 Bug 是否已经更正了。值得注意的是，已经更正的 Bug 也可能有回来了，有的 Bug 经过修改之后可能又产生了新的 Bug 。所以，回归测试可保证已更正的 Bug 不再重现，不产生新的 Bug 。
6. RTM 测试( Release To Manufacture Testing )：为产品真正的 Ship 做好准备所进行的测试。事实上，在这一测试阶段，对每一个 Bug 都需要经过很高职务的人同意才能更正。因为这时候修改软件非常容易产生其他的错误，所以只有那种非修复不可的 Bug 才会被允许进行修改。如果在发行阶段软件还有许多严重的 Bug 的话，恐怕就不能按时发布了。记得有一次一个微软核心产品刚刚完成，准备 Ship 时，我对其进行 RTM 测试时就发现一个 Bug ：只要用该产品打印中文就会导致程序错误。这是一个很严重的 Bug ，浴室开发人员马上修复了该 Bug ，重新 Ship 该产品。

功能及系统测试( Function & System Testing )：这一点是最重要的，他包括了非常多的内容。

• 规范验证 (Specification Verification )
• 正确性 (Correctness )
• 可用性 (Usability )
• 边界条件 (Boundary Condition )
• 性能 (Performance)
• 强力测试 (Stress)
• 错误恢复 (Error Recovery)
• 安全性 (Security)
• 兼容性 (Compatibility)
• 软件配置 (Configuration)
• 软件安装 (Installation)

一、心态的调整

从我成为测试人员到如今已经有两个多年头了，我想从切身的体验来跟大家介绍作为一个测试人员角色定位的问题，以及刚入门需要了解的相关知识和心态方面的问题。

随着公司规模逐渐扩大，测试人员的队伍也逐渐壮大。然而很多刚入门的同仁却开始慢慢对做测试流露出迷茫的眼神，问其原因，很简单，做测试学不到东西，整天就鼠标点点，键盘敲敲，很难学到真正的东西。听了之后我不由得露出理解的笑容，我也是从这样的境遇走过来的。刚进入公司的时候就让做测试，经历了同样的鼠标点点，键盘敲敲的过程。然而正是这样的一些成长经历让我在平淡中明白了很多道理，并且慢慢从因为工作而做测试转化为因为兴趣爱好而继续做测试工作。

测试工作不仅仅是表面看到的这种敲敲点点现象的延续，还有更深层次的内涵，只是我们还没到达这个境界，所以看起来很枯燥。刚开始做测试的朋友很多都在做黑盒测试，而黑盒测试往往对代码编写能力要求不是很高，这样给刚入门的人就造成了一个测试人员不需要太多知识的误解。事实上，测试工作需要很广泛的知识;不仅仅只是专业上的，而且要了解很多开发人员不了解的东西，一个系统里面开发人员可以只了解客户需求，而我们的测试人员需要了解全局;开发人员可以不用太多了解用户的需求，而我们却需要能够准确捕获客户的观点，对很多细节需要非常注意。这样，是不是有点统筹全局的成就感!

二、测试入门工作的误区

很多人在初入测试行业的时候往往非常热衷于测试工具的学习以及使用，其实这并不是很正确。知识的学习是分阶段分层次的。测试表面看来很简单，只是给程序找错误，但是在整个软件开发过程中，我们该如何有效地把测试流程和开发流程结合起来，都需要实践，而这些是测试工具所不能完成的。

对整个测试流程方面的知识我们需要了解很多，而测试工具只是其中一小部分。我们所要学习的不仅仅只是这些表面知识，更需要深入研究测试的流程。包括：1)了解如何制定一个好的测试计划来规划我们的测试时间、测试范围。2)了解如何写一个好的测试用例来覆盖整个测试范围之内的测试实施。3)了解如何保证所测试出来的bug是开发人员的问题而不是因为自己了解不够而出现的问题。4)如何总结Bug分析报告等等。还需要对我们的测试时间进行详细规划，尽量多地考虑各种可能性。这样才可以尽量减少相关的风险。

我认为测试知识的学习可以分为以下三个阶段来进行：

第一个阶段，我们必须明白测试在整个软件工程的重要性，了解测试的相关基础知识，并且在了解这些知识的过程中逐渐挖掘出对测试的兴趣。兴趣爱好是做好一项工作的重要条件。

第二个阶段，要对整个测试流程管理工作有个非常明确的认识。很多时候测试工作都是在团队相互协调的情况下进行的，所以只有熟悉了整个软件开发流程以及测试流程，才能更好地配合工作。在我们对这些都很熟悉并且在工作当中应用很流畅的时候，就可以对测试工具进行相应的学习。同时我们还必须扩充其他相关知识，对客户需求的了解要比开发人员更全面，更深入，这样才能保证我们的测试流程是按照客观正确的方向前进。

第三个阶段，学习测试管理和深入研究测试方法。这个阶段我们需要继续深入研究测试工具的使用及进一步提高自己的测试技能，在实际工作中总结测试经验并最终熟练掌握自动化测试，成为技术专家。

测试人员的职业发展规划

国内一位资深测试人员海松宝曾对测试人员的发展阶段跟发展路径规划画出一个很形象的发展图(如下图)：

从这个图形大家也可以粗略的看出，对于初级测试工程师，这是两个不同的发展方向，但是最终还是发展为一个终点(PM)。从一个初级测试工程师晋升到一个高级测试工程师比较快，但是从一个初级测试工程师发展到一个TeamLeader所需要的时间相对比较长。而从一个高级测试工程师发展到一个资深测试工程师花费时间更长一点，到达资深测试工程师之后就可以很容易做到测试主管了，以后可以发展到PM。当然从初级测试人员到高级、资深测试人员在上面的图中并不是表述为“曲线发展过程”的，很多时候行业经验、行业知识的累积等都很重要，而这点只有深入发展的人才会发现。所以我们做事必须要有耐心，罗马非一日建成。相信明天就要紧紧把握今天。

优秀测试人员具备的素质

测试不顺利的原因之一是测试人员的专业知识不够。所以我们一定要加强我们自身的专业知识的学习。那么，一个真正的测试人员应该具备哪些知识呢?除了应具有相关的专业知识外，我想从大众化的方面来阐述下面几个需要我们注意的地方，这也是作为一个测试人员应该具备的基本素质：

1、我们需要具备很好的沟通能力：我们不仅要与开发人员进行沟通，有时候还要与客户进行沟通。他们是两种不同类型的人，关心问题的侧重点也不同。所以我们沟通的时候需要掌握一定的技巧。由于开发人员与我们思考问题的角度不同，双方自然会引起一些争论、误解，这时候我们应该心平气和把写出来的bug，向开发人员解释清楚，从而双方达到共识。对于客户，我们要从客户关心的问题入手，这样才能从客户那儿得到比较准确的需求。

2、我们需要具备很好的自信心：由于开发人员认为测试人员的开发知识不如他们，因而会轻视测试人员，这个时候我们除了要扩充自己的专业知识外还需要有很强的自信心。。要知道有了一定的专业水平，别人就会尊重你的劳动成果并听取你的见解。当然这种自信心也是建立在心平气和下的沟通，不是完全对立的。

3、我们需要保持一种职业怀疑的精神：我们会经常碰到这样一种情况，我们将发现的bug交给开发人员时他们总是尽他们最大的努力解释每个他们认为不是bug的bug。这时候我们不能轻易下定论，而应持怀疑态度直到自己仔细确认后。

4、我们需要耐心和很好的记忆力：有时候往往一个bug要花费我们大量的时间和精力，这就要求我们要有耐心。如果我们有很好的记忆力，就可以轻松地获得一些类似的bug的资料，。当然，如果记不住的话，，那么相关的文档就是我们最好的查询资料。我们可以在不断的查询过程中修改文档，使文档日臻完善，

5、我们需要一颗安静的心：因为浮躁的人是找不出隐藏在深处的bug的，所以当我们测试的时候应该保持内心的平静，从而凭借很好的洞察力来寻找那些隐藏很深的bug，或者是相关的重点。这点是很重要的。否则你的测试跟流水账没什么区别，只是根据业务流程、用户需求、开发人员的思路，发现一些皮毛的bug。这不是一个优秀的测试人员应该做的。

6、我们还应学会承受压力并排遣压力：我们经常承受着一定的压力，客户在催促，开发人员在delay，所以我们要能够承受压力，包括外界的、工作上的压力。并且不要把因为压力而导致的不好的情绪带到工作当中。学会排遣这些压力，保持一颗轻松、平静的心，全身心投入到我们的工作。

只是想强调一点：测试在中国的发展前景是非常好的，而这点从这几年无论是测试人员和测试环境的变化还是客户对产品质量的要求越来越高都可以看出。

微软的软件测试人员分为两类 :测试工具软件开发工程师( Software Development Engineer in Test,简称 SDE/T)和软件测试工程师 (Software Test Engineer，简称 STE)。

测试工具软件开发工程师 : 负责写测试工具代码，并利用测试工具对软件进行测试;或者开发测试工具为软件测试工程师服务。产品开发后的性能测试 (Performance Test)、提交测试 (Check-in Test)等过程，都有可能要用到 SDE/T开发的测试工具。由于 SDE/T和 SDE的工作都是写代码，具有相通的地方，所以两者之间互相转换的情况比较多。但需要注意的是，两者写出来的代码用途是不一样的， SDE写的是产品的代码，而 SDE/T写的代码只用于测试产品。

软件测试工程师 : 负责理解产品的功能要求，然后对其进行测试，检查软件有没有错误 (Bug)，决定软件是否具有稳定性 (Robustness)，并写出相应的测试规范和测试案例。

除此之外，在一个软件产品的研发和销售过程中，还会需要负责给产品打补丁 (Service Pack)的快速修正工程师比( Quick Fix Engineer)，通常曲 SDE来担任，通过电话方式向用户提供售后技术支持的支持工程师 (Support Engineer)，销售和市场 (Sales and Marketing)人员，研究员和研究工程师 (Researchers & Research SDE)。

在进行产品开发的时候，主要是由前面三类人员 (项目经理、开发人员及测试人员 )组成产品开发团队来进行的。在微软内部，软件测试人员与软件开发人员的比率一般为 1.5-2.5左右，这可能远远超出了大家对测试人员的理解，但微软软件开发的实践过程已经证明了这种人员结构的合理性

测试时应考虑的几个问题