测试经验

不管你是一个测试新手还是一个经验丰富的测试专家，都有不少有益的东西需要牢记在心。
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  测试员的使命决定要做的一切
   测试员的使命，可能要取决于自己的行业、公司、项目或团队的个性．测试项目也干差万别。把测试作为一种工艺发展的挑战，一直是建立测试实践对话所面临的困难，这种测试实践要跨越我们之间的文化和技术差异。这些差异中的很多内容，决定了测试团队的不同使命。例如，在有些测试机构中，测试计划只是用来为测试员提供帮助的工具。测试计划可能写在餐巾纸上，且仍然有效。而另一些机构作为产品来编写测试计划，必须随软件一起交付。他们的测试计划必须遵循严格的格式和内容要求。
   以下任何要求都可能决定测试员的使命。读者期望的是哪种要求呢？
•快速找出重要软件问题。
•对产品质量提出总体评估。
•确认产品达到某种具体标准。
•帮助客户改进产品质量和可测试性。
•保证测试过程能够达到可分清责任的标准。
•就测试和与测试员协作方式培训客户。
•采用特定的方法集或遵循特定的规则集。
帮助预测和控制支持成本。
•帮助客户改进其过程。
•以最小化成本、时间或尽可能减少副作用的方式，完成自己的工作。
•为满足特定客户要求，完成所有必要的工作。
如果测试员将时间和精力都投入到客户并不关心的需求上，就会冒做无关工作或生产率低的风险，测试员要与自己的经理协商使命问题，并明确使命。如果不能就使命达成一致意见，就不会有做任何工作的好基础。
    如果测试员不知道该做什么怎么办?一种回答是评审使命？这样做可以找出自己的核心问题。如果测试员明确自己的测试使命，就可以为自己的工作辩护，并明确地确定下一步要做什么。测试员还可以用简单的描述，向其他人解释自己的角色。如果由于某种原因不能完成自己的使命，应该立即把这个问题汇报给管理层。
    如果测试员确切地知道要做什么该怎么办?经常重新考虑自己的使命，保证自己的计划不会由于过于偏重测试问题的一个方面，而忽略其他方面。
经验３　测试员为很多客户服务
    测试是一种服务角色，要乐于接受这种角色，因为测试员提供的服务是至关重要的。服务就意味着有客户，即要被服务的人。测试员是否成功，主要是看其是否很好地满足了客户的要求和最佳利益。这不会太难，不过测试会有很多客户，这些客户都有自己的需要，而且他们的各种需要不一定一致。
*项目经理。项目经理有资格了解测试员的工作进展并施加影响。测试员根据要求向其报告工作状态，迅速报告重要问题。并不要成为项目的瓶颈，从而为项目经理提供服务。指挥项目是项目经理的特权。测试员的责任就是告诉项目经理自己能做什么，不能做什么，有关项目的决策和条件会对测试产生什么影响。
*程序员。通过尽可能迅速地提供好的错误报告，使得程序员的工作更容易一些。努力提高自己的技能并了解产品，以免用错误的或用毫无意义的报告浪费程序员的时间。如果测试员可以做到这一点，就可以赢得更多的信任，而这种信任又可以转化为支持和影响。
*技术文档编写员。与测试员一样，负责编写文档和在线帮助的技术文档编写员也不能得到产品的完整信息。测试员可以帮助他们理解产品到底怎样发挥效能，并为其指出文档中的错误。技术文档编写员也会帮助测试员。当技术文档编写员研究产品，以及必须阅读文档的用户会怎样使用产品时，会了解到一些测试员不知道的信息。如果测试员与技术文档编写员有很好的关系，编写员就会告诉测试员有关产品的新特性、新用法、测试计划中的漏洞和他们所发现的软件问题。这些问题中的一部分永远也不会被报告，除非某个文档编写员知道哪个测试员关心这些程序问题。
*技术支持员。遗留在产品中的任何问题都会为技术支持员带来负担。测试员通过告诉技术支持员可能会给用户带来麻烦的产品问题，向其提供服务。如果测试员在开发期间与技术支持员一起工作，有时技术支持员会帮助测试员找出应该更正的软件问题。测试员也应该通过研究现场发现的难题，为技术支持员提供帮助。通过这种方式，能够把测试员与技术支持员拉得更近，进而与客户也更近了。
*市场开发员。市场开发员需要了解产品中任何与产品应该提供给客户的关键利益不一致的地方。对于程序员来说是很小的程序问题，对于市场开发员来说可能会是至关重要的问题。他们也许能意识到这种程序问题会使客户较难完成某种重要任务。此外，通过评审市场开发计划文档或描述，测试员可以帮助市场开发员对产品能力有更精确的认识。
*管理层和项目相关人员。测试员服务于公司业务，这也是为什么测试员必须小心，不要像个质量狂，而不是通信达理的人的原因。特别是到了项目要结束的时候，测试员要以兼顾公司短期和长期利益的方式完成自己的职责。要以明确、简洁的词汇编写测试状态报告，以便执行经理能够感到有做出决策的依据。
*用户。在测试员的心中，要想着将要使用该产品的人。当然，用户的满意是项目的最高利益。但是还要考虑满足主要用户对项目团队的特殊要求。
    以上列出的各条没有什么特别顺序，不过在实际项目中可能有一定顺序，因此要认真研究，找出对项目最重要的入，找出要服务的人。这是做好测试工作的第一步。
经验４　测试员发现的信息会“打扰”客户
    测试团队的使命包括(或应该包括)根据客户对价值的定义，通知客户有关威胁产品价值的任何信息。如果发现即使产品能够按意图运行，但是仍然达不到所要求的价值，则测试员有责任报告。如果客户忽视报告，那是他们的权力
经验５　迅速找出重要程序问题
    测试员的使命很可能包括找出重要的(与无意义相反)程序问题，而且要迅速找出。如果是这样，那么这对测试员所执行的测试意味着什么呢?
•首先测试经过变更的部分，然后测试没有变化的部分。修改和更新都意味着新的风险。
•首先测试核心功能，然后测试辅助功能、测试产品所完成的关键和常用功能，测试完成产品基本任务的功能。
•首先测试能力，然后测试可靠性。先测试每个功能是否完全能用、然后再深入检查任何一个功能在很多不同条件下表现如何。
•首先测试常见情况，然后测试少见情况。使用常用的数据和使用场景。
首先测试常见威胁，然后测试罕见威胁。用最有可能出现的压力和错误情况进行测试。
•首先测试影响大的问题，然后测试影响小的问题。测试在出现失效的情况下会产生大量破坏的产品部件。
•首先测试最需要的部分，然后测试没有要求的部分。测试对团队其他人有重要意义的任何部分的任何问题。
  测试员如果对产品、产品必须与之交互的软件和硬件以及将使用软件的人越了解，越有可能更快地找出重要问题。应好好研究这些方面的内容。
经验６，跟着程序员走
   为程序员提供支持，很可能是测试员使命的关键部分。在测试员测试程序员正在编写或刚刚完成的程序时，测试员的反馈有助于提高程序员的工作效率。程序员交付软件后，应该马上测试；程序员修改代码后，应该马上测试所做的变更。尽可能建立最短、最快的反馈环路。当程序虽正在苦苦地思索测试员刚刚发现的程序问题时，测试员又开始寻找更多的程序问题。对于测试员来说，理想情况是，程序员为了修改测试员找出的程序问题忙得团闭转，使程序员（而不是测试员）成为项目的瓶颈。
经验７，询问一切，但不一定外露
    不问问题当然可以测试，但是不可能测试得好。问问题是测试员对项目发挥作用的基础。不问问题．测试就没有目标，就是呆板、机械的。不过很直白的问题会刺激别人，常常使人产生顾虑。
    问题就像是一剂猛药，最好采用低剂量，或与饭一起吃(即结合其他沟通形式)。幸运的是，这样问问题的价值并不低于直白地发问。测试员所想到的任何问题都会有助于启发自己的思想，最终产生对问题的至关重要的认识。
    如果测试员在测试时发现对产品提不出问题，那么还是先停下来。
经验８，测试员关注失效，客户才能关注成功
    测试是项目团队中唯一不直接关注成功的角色。其他所有人都在创造什么，或创造性地指导创造。但测试员却是消极的。测试会是一种沉闷的工作，几乎像希腊神话所说：“测试者在孤岛上，注定要不停地寻找不会存在、也不应该存在的东西，深信成功会为神带来不幸。”
    重新定义比较积极的测试员使命是错误的，例如确认程序正常。即使“确认程序正常”作为使命交给测试员，测试员也要忠告客户，这样的确认是不可能的。这种确认成本极高。除非运行所有可能的测试，否则就不能证明程序正常。测试员只能够说：“就我所执行的测试来说，没有发现产品不正常。”但是反过来的确认就非常经济了：只需一个测试，就可以说明产品不正常。
    测试员关注失效，是因为这可以增加发现失效的机会。用自己全部的创造力和技能，寻找产品中的关键问题。如果测试员没有找到关键问题，程序员就不能改正，以后用户可能会替测试员找到。通过发现程序中客现存在的问题，测试员能够帮助项目团队更加了解自己的技能和产品风险，帮助他们将产品做得更好，更具可支持性，在市场中有可能更成功。
经验９，不会发现所有程序问题
    测试员的任务就是找出并报告重要的程序问题，但是不会发现所有的程序问题。为了发现全部程序错误，测试员必须检查所有可能有问题的地方，要在所有可能发生的不同条件下观察这些地方，还需要一种十分可靠的方法，当所有类型的程序错误发生时，都能够识别出来。如果测试员认为自己能够做到这些，那么要么产品非常简单，要么测试员的想像力太差。
    知道并承认自己不能做所有的事之后，测试员必须选择如何使用自己的时间。
经验１０，当心“完备的”测试
    有一些测试员承认自己不知道是否发现了产品中的全部问题，但仍然不准确地讨论结束测试的含义。“对这个产品我需要测试