软件测试-[分享]软件测试经验与教训 - TestFocus焦点测试论坛测试|软件测试技术|软件测试培训|软件测试工具|性能测试

个人空间
组别:管理员
性别:
来自:
积分:285
帖子:257
注册: 2007-04-20

2007-05-30 16:27 | 只看楼主

树型| 收藏| 小中大 1

[分享]软件测试经验与教训

转载自死傀儡论坛，特别感谢乐天，转载请注明出处

第一章　测试员的角色

测试员要在项目中起什么作用?这是本章要讨论的问题。像有关测试的很多问题一样，这个问题初看起来答案很明显、很平凡，但其实不然。

一个角色就是一种关系。这意味着人们不能控制自己的角色，但是可以协商。别人期望从测试员那里得到的可能并不合理。当测试员由于低质量的产品而受到指责时(这种事时有发生)，不管是谁指责，可能都存在分不清角色的问题。也许他们认为测试员的工作，就是在产品交付之前使用“质量魔术棒”敲打产品、他们也许认为测试员敲打得还不够狠。

当测试员清楚了自己的角色之后．在协商角色内容时，就有了在可能出现的任何情况下确立对自己预期的基础。但是，即使是清晰和恰当的测试角色也是一种苛求。

经验１　测试员是项目的前灯

一个项目就像是一次陆上旅行。有些项目很简单、很平常，就像是大白天开车去商店买东西。但是大多数值得开发的项目更像是夜间在山里开越野卡车。这些项目需要前灯，而测试员要照亮前面的道路，使程序员和经理尽管还在拿着地图争吵，但是至少可以看清他们在哪儿，要从什么样的路面上开过去，离悬崖峭壁有多远。每个公司测试团队的具体使命都不尽相同．不过在这些细节背后的要素都是一样的。测试就是要找到信息，有关项目或产品的关键决策都是根据这些信息做出的。

以今天的名义最后编辑于 2007-06-04 15:35:24

TestFocus焦点测试网

助力软件测试行业，推动软件测试发展

个人空间
组别:管理员
性别:
来自:
积分:285
帖子:257
注册: 2007-04-20

2007-05-30 16:32 | 只看楼主

树型| 收藏| 小中大 2

回复: [分享]软件测试经验与教训

经验2 测试员的使命决定要做的一切

测试员的使命，可能要取决于自己的行业、公司、项目或团队的个性．测试项目也干差万别。把测试作为一种工艺发展的挑战，一直是建立测试实践对话所面临的困难，这种测试实践要跨越我们之间的文化和技术差异。这些差异中的很多内容，决定了测试团队的不同使命。例如，在有些测试机构中，测试计划只是用来为测试员提供帮助的工具。测试计划可能写在餐巾纸上，且仍然有效。而另一些机构作为产品来编写测试计划，必须随软件一起交付。他们的测试计划必须遵循严格的格式和内容要求。

以下任何要求都可能决定测试员的使命。读者期望的是哪种要求呢？

·快速找出重要软件问题。

·对产品质量提出总体评估。

·确认产品达到某种具体标准。

·帮助客户改进产品质量和可测试性。

·保证测试过程能够达到可分清责任的标准。

·就测试和与测试员协作方式培训客户。

·采用特定的方法集或遵循特定的规则集。

·帮助预测和控制支持成本。

·帮助客户改进其过程。

·以最小化成本、时间或尽可能减少副作用的方式，完成自己的工作。

·为满足特定客户要求，完成所有必要的工作。

如果测试员将时间和精力都投入到客户并不关心的需求上，就会冒做无关工作或生产率低的风险，测试员要与自己的经理协商使命问题，并明确使命。如果不能就使命达成一致意见，就不会有做任何工作的好基础。

如果测试员不知道该做什么怎么办?一种回答是评审使命？这样做可以找出自己的核心问题。如果测试员明确自己的测试使命，就可以为自己的工作辩护，并明确地确定下一步要做什么。测试员还可以用简单的描述，向其他人解释自己的角色。如果由于某种原因不能完成自己的使命，应该立即把这个问题汇报给管理层。

如果测试员确切地知道要做什么该怎么办?经常重新考虑自己的使命，保证自己的计划不会由于过于偏重测试问题的一个方面，而忽略其他方面。

以今天的名义最后编辑于 2007-05-30 16:34:08

TestFocus焦点测试网

助力软件测试行业，推动软件测试发展

个人空间
组别:管理员
性别:
来自:
积分:285
帖子:257
注册: 2007-04-20

2007-05-30 16:35 | 只看楼主

树型| 收藏| 小中大 3

回复: [分享]软件测试经验与教训

经验３　测试员为很多客户服务

测试是一种服务角色，要乐于接受这种角色，因为测试员提供的服务是至关重要的。服务就意味着有客户，即要被服务的人。测试员是否成功，主要是看其是否很好地满足了客户的要求和最佳利益。这不会太难，不过测试会有很多客户，这些客户都有自己的需要，而且他们的各种需要不一定一致。

*项目经理。项目经理有资格了解测试员的工作进展并施加影响。测试员根据要求向其报告工作状态，迅速报告重要问题。并不要成为项目的瓶颈，从而为项目经理提供服务。指挥项目是项目经理的特权。测试员的责任就是告诉项目经理自己能做什么，不能做什么，有关项目的决策和条件会对测试产生什么影响。

*程序员。通过尽可能迅速地提供好的错误报告，使得程序员的工作更容易一些。努力提高自己的技能并了解产品，以免用错误的或用毫无意义的报告浪费程序员的时间。如果测试员可以做到这一点，就可以赢得更多的信任，而这种信任又可以转化为支持和影响。

*技术文档编写员。与测试员一样，负责编写文档和在线帮助的技术文档编写员也不能得到产品的完整信息。测试员可以帮助他们理解产品到底怎样发挥效能，并为其指出文档中的错误。技术文档编写员也会帮助测试员。当技术文档编写员研究产品，以及必须阅读文档的用户会怎样使用产品时，会了解到一些测试员不知道的信息。如果测试员与技术文档编写员有很好的关系，编写员就会告诉测试员有关产品的新特性、新用法、测试计划中的漏洞和他们所发现的软件问题。这些问题中的一部分永远也不会被报告，除非某个文档编写员知道哪个测试员关心这些程序问题。

*技术支持员。遗留在产品中的任何问题都会为技术支持员带来负担。测试员通过告诉技术支持员可能会给用户带来麻烦的产品问题，向其提供服务。如果测试员在开发期间与技术支持员一起工作，有时技术支持员会帮助测试员找出应该更正的软件问题。测试员也应该通过研究现场发现的难题，为技术支持员提供帮助。通过这种方式，能够把测试员与技术支持员拉得更近，进而与客户也更近了。

*市场开发员。市场开发员需要了解产品中任何与产品应该提供给客户的关键利益不一致的地方。对于程序员来说是很小的程序问题，对于市场开发员来说可能会是至关重要的问题。他们也许能意识到这种程序问题会使客户较难完成某种重要任务。此外，通过评审市场开发计划文档或描述，测试员可以帮助市场开发员对产品能力有更精确的认识。

*管理层和项目相关人员。测试员服务于公司业务，这也是为什么测试员必须小心，不要像个质量狂，而不是通信达理的人的原因。特别是到了项目要结束的时候，测试员要以兼顾公司短期和长期利益的方式完成自己的职责。要以明确、简洁的词汇编写测试状态报告，以便执行经理能够感到有做出决策的依据。

*用户。在测试员的心中，要想着将要使用该产品的人。当然，用户的满意是项目的最高利益。但是还要考虑满足主要用户对项目团队的特殊要求。

以上列出的各条没有什么特别顺序，不过在实际项目中可能有一定顺序，因此要认真研究，找出对项目最重要的入，找出要服务的人。这是做好测试工作的第一步。

TestFocus焦点测试网

助力软件测试行业，推动软件测试发展

个人空间
组别:管理员
性别:
来自:
积分:285
帖子:257
注册: 2007-04-20

2007-05-30 16:36 | 只看楼主

树型| 收藏| 小中大 4

回复: [分享]软件测试经验与教训

经验４　测试员发现的信息会“打扰”客户

测试团队的使命包括(或应该包括)根据客户对价值的定义，通知客户有关威胁产品价值的任何信息。如果发现即使产品能够按意图运行，但是仍然达不到所要求的价值，则测试员有责任报告。如果客户忽视报告，那是他们的权力。

TestFocus焦点测试网

助力软件测试行业，推动软件测试发展

个人空间
组别:管理员
性别:
来自:
积分:285
帖子:257
注册: 2007-04-20

2007-05-30 16:36 | 只看楼主

树型| 收藏| 小中大 5

回复: [分享]软件测试经验与教训

经验５　迅速找出重要程序问题

测试员的使命很可能包括找出重要的(与无意义相反)程序问题，而且要迅速找出。如果是这样，那么这对测试员所执行的测试意味着什么呢?

·首先测试经过变更的部分，然后测试没有变化的部分。修改和更新都意味着新的风险。

·首先测试核心功能，然后测试辅助功能、测试产品所完成的关键和常用功能，测试完成产品基本任务的功能。

·首先测试能力，然后测试可靠性。先测试每个功能是否完全能用、然后再深入检查任何一个功能在很多不同条件下表现如何。

·首先测试常见情况，然后测试少见情况。使用常用的数据和使用场景。

·首先测试常见威胁，然后测试罕见威胁。用最有可能出现的压力和错误情况进行测试。

·首先测试影响大的问题，然后测试影响小的问题。测试在出现失效的情况下会产生大量破坏的产品部件。

·首先测试最需要的部分，然后测试没有要求的部分。测试对团队其他人有重要意义的任何部分的任何问题。

测试员如果对产品、产品必须与之交互的软件和硬件以及将使用软件的人越了解，越有可能更快地找出重要问题。应好好研究这些方面的内容。

TestFocus焦点测试网

助力软件测试行业，推动软件测试发展

个人空间
组别:管理员
性别:
来自:
积分:285
帖子:257
注册: 2007-04-20

2007-05-31 11:41 | 只看楼主

树型| 收藏| 小中大 6

回复: [分享]软件测试经验与教训

经验６，跟着程序员走

为程序员提供支持，很可能是测试员使命的关键部分。在测试员测试程序员正在编写或刚刚完成的程序时，测试员的反馈有助于提高程序员的工作效率。程序员交付软件后，应该马上测试；程序员修改代码后，应该马上测试所做的变更。尽可能建立最短、最快的反馈环路。当程序虽正在苦苦地思索测试员刚刚发现的程序问题时，测试员又开始寻找更多的程序问题。对于测试员来说，理想情况是，程序员为了修改测试员找出的程序问题忙得团闭转，使程序员（而不是测试员）成为项目的瓶颈。

经验７，询问一切，但不一定外露

不问问题当然可以测试，但是不可能测试得好。问问题是测试员对项目发挥作用的基础。不问问题．测试就没有目标，就是呆板、机械的。不过很直白的问题会刺激别人，常常使人产生顾虑。

问题就像是一剂猛药，最好采用低剂量，或与饭一起吃(即结合其他沟通形式)。幸运的是，这样问问题的价值并不低于直白地发问。测试员所想到的任何问题都会有助于启发自己的思想，最终产生对问题的至关重要的认识。

如果测试员在测试时发现对产品提不出问题，那么还是先停下来。

TestFocus焦点测试网

助力软件测试行业，推动软件测试发展

个人空间
组别:管理员
性别:
来自:
积分:285
帖子:257
注册: 2007-04-20

2007-05-31 11:41 | 只看楼主

树型| 收藏| 小中大 7

回复: [分享]软件测试经验与教训

经验８，测试员关注失效，客户才能关注成功

测试是项目团队中唯一不直接关注成功的角色。其他所有人都在创造什么，或创造性地指导创造。但测试员却是消极的。测试会是一种沉闷的工作，几乎像希腊神话所说：“测试者在孤岛上，注定要不停地寻找不会存在、也不应该存在的东西，深信成功会为神带来不幸。”

重新定义比较积极的测试员使命是错误的，例如确认程序正常。即使“确认程序正常”作为使命交给测试员，测试员也要忠告客户，这样的确认是不可能的。这种确认成本极高。除非运行所有可能的测试，否则就不能证明程序正常。测试员只能够说：“就我所执行的测试来说，没有发现产品不正常。”但是反过来的确认就非常经济了：只需一个测试，就可以说明产品不正常。

测试员关注失效，是因为这可以增加发现失效的机会。用自己全部的创造力和技能，寻找产品中的关键问题。如果测试员没有找到关键问题，程序员就不能改正，以后用户可能会替测试员找到。通过发现程序中客现存在的问题，测试员能够帮助项目团队更加了解自己的技能和产品风险，帮助他们将产品做得更好，更具可支持性，在市场中有可能更成功。

TestFocus焦点测试网

助力软件测试行业，推动软件测试发展

个人空间
组别:管理员
性别:
来自:
积分:285
帖子:257
注册: 2007-04-20

2007-05-31 11:42 | 只看楼主

树型| 收藏| 小中大 8

回复: [分享]软件测试经验与教训

经验９，不会发现所有程序问题

测试员的任务就是找出并报告重要的程序问题，但是不会发现所有的程序问题。为了发现全部程序错误，测试员必须检查所有可能有问题的地方，要在所有可能发生的不同条件下观察这些地方，还需要一种十分可靠的方法，当所有类型的程序错误发生时，都能够识别出来。如果测试员认为自己能够做到这些，那么要么产品非常简单，要么测试员的想像力太差。

知道并承认自己不能做所有的事之后，测试员必须选择如何使用自己的时间。

经验１０，当心“完备的”测试

有一些测试员承认自己不知道是否发现了产品中的全部问题，但仍然不准确地讨论结束测试的含义。“对这个产品我需要测试5天”可以解释为，他可以在5天之内对产品进行完备的测试，也可能意味着他会在5天之内发现所有问题。完备性常常是隐含地表示出来的，而不是明说出来的。不管是哪种情况，这都是必须小心对待的概念。请考虑完备测试可能的含义：

·完全发现了产品中每个问题。

·完全检查了产品的每个部分。

·完成了自认为是有用和经济的测试。

·尽自己所能，完全达到了项目团队制定的目标。

·完成了约定的测试。

·完成了在一定条件下人所能够测试的所有内容。

·完成了自己知道如何测试的所有内容。

·完成了自己所承担的测试部分，不考虑其他人的工作。

·完成了对产品很广、但是不深的测试。

·完成了对产品的一种测试。

·用完了分配给测试的时间。

如果测试员小心地澄清自己的意思，不要有“完备”、“完成”、“结束”等含义，则可能会很安全，由于有些工作没有做而受到的责备可能更少，在受到责备时可以更好地为自己辩护。请注意，“完备”的定义并不是在项目一开始就

能够最终确定的，随着测试项目的进展，随着新测试任务的突然出现，需要重新考虑。

为了解决在完备性上的普遍沟通问题，可让客户详细了解测试过程。总结自己实施的测试，以及为什么值得实施这些测试，并告诉客户自己没有做的其他值得做的测试，以及为什么没有做这些测试。

TestFocus焦点测试网

助力软件测试行业，推动软件测试发展

个人空间
组别:管理员
性别:
来自:
积分:285
帖子:257
注册: 2007-04-20

2007-06-01 11:40 | 只看楼主

树型| 收藏| 小中大 9

回复: [分享]软件测试经验与教训

经验１１，通过测试不能保证质量

测试员太容易把自己看作是质量卫士了。但是测试员既不会提高质量，也不能降低质量。测试员表现出好像是自己“制服”了产品，但实际上产品到测试员手中时已经被制服。质量来源于构建产品的人，有时这对他们来说是要背负的沉重负担。测试员使命中的很大一部分，就是帮助他们更有效地对付真正的负担。如果测试员自认为是项目团队中惟一关心交付好产品的人，就不能很好地完成这部分使命。

测试小组的任务可能叫做“质量保证”，但是测试经理可别真的也这样认为。测试员的测试和错误报告提供促进项目质量保证的信息，但是这种保证要来自整个项目团队。

经验１２，永远别做看门人

有些测试员梦想对产品的发布具有否决权。不妨给他们点教训，让他们梦想成真。问题是当测试员获得控制产品发布的权力之后，同时也承担了产品质量的全部责任，团队其他成员可以为此放松一点，也许还会大大地放松。如果问题逃过测试，走出项目团队大门，团队其他人员会(并且也将)耸耸肩膀，并责备测试员。谁让测试员交付有问题的产品来着。另一方面，如果测试员延误发布，作为这种质量狂，会被严厉追究并承担很大压力。

最终，要由控制项目、条件最好的人承担发布产品的责任。但是我们所看到的大多数非常有效的项目团队，都采用某种方式的集体决定是否发布产品．如果读者被授权决定产品的发布，我们建议毫不犹豫地立即坚持与项目团队的其他角色一起分担这种权力。

TestFocus焦点测试网

助力软件测试行业，推动软件测试发展

个人空间
组别:管理员
性别:
来自:
积分:285
帖子:257
注册: 2007-04-20

2007-06-01 11:45 | 只看楼主

树型| 收藏| 小中大 10

回复: [分享]软件测试经验与教训

经验１３，当心测试中的不关我事理论

测试是如此复杂．与其他项目活动如此密切关联，以至于测试员总想通过采用狭隘的测试使命观进行更好的控制。有些测试员认为．自己的使命就是找出产品和规格说明之间的差别。任何超出这个范围的问题，例如可使用性问题、需求问题、数据质量和可支持性问题，都“不关我的事”。我们强烈要求这样的人把眼光放宽一些。所有其他事情都一样，测试员的使命应该是尽其所能，通知团队可能会对产品的价值产生消极影响的所有问题。因此，优秀的测试团队应由理解项目总体问题的不同类型的人员组成：产品将怎样设计、制造、市场开发、销售、使用、服务和升级。

说“不关我的事”的另一个原因是测试员处于困难的测试环境。负责程序设计的同事编写的规格说明可能很差，可能交付代码太迟，以至于没有时间执行合理的测试过程。他们可能声称测试员发现的重要问题实际上是测试员自己的主观臆想。在这种环境下，很想拒绝测试。测试员可以说，解释模糊的规格说明或在这样短的时间内进行某种测试不是自己的事。如果情况很严重，这样做也许不错，但是首先应该考虑一下自己的期望是否实际，考虑一下是否有其他方式能够得到自己所需要的条件。如果测试员接受这样的哲学．认为自己的工作就是付出合理的努力去适应和灵活应对各种情况，则程序员更有可能把测试员当作恩赐，而不是负担。而这反过来又会促使他们把帮助测试员看作是自己的事。

经验１４，当心成为过程改进小组

有时测试员会对查找问题感到厌烦，并考虑是否最好能够防止问题的发生。也许程序员更仔细一些，问题就会更少一些。就问题而言，这确实很有意义。但是同样有意义的是，满怀好意地告诉自己所爱的人怎样生活得更好。如果尝试一下就会知道，好的忠告并不总能被真正接受。问题不在于是否能够认识到，而在于感情。不管过程改进要干什么，它永远都会涉及感情。

即使测试员通过测试着手推进质量改进有管理层强有力的支持。但是团队其他成员同时会有很多方法避开测试员的努力，并使测试员看起来无能。是的，如果过程改进是整个团队的工作，则测试员可以成功地参与工作，并获得成功，但是我们强烈要求测试员不要试图把测试小组“提升”到扮演过程批评角色。这样做是愚蠢的。

TestFocus焦点测试网

助力软件测试行业，推动软件测试发展

TestFocus焦点测试论坛测试人生 职业发展[分享]软件测试经验与教训

标题: [分享]软件测试经验与教训

[分享]软件测试经验与教训

回复: [分享]软件测试经验与教训

回复: [分享]软件测试经验与教训

回复: [分享]软件测试经验与教训

回复: [分享]软件测试经验与教训

回复: [分享]软件测试经验与教训

回复: [分享]软件测试经验与教训

回复: [分享]软件测试经验与教训

回复: [分享]软件测试经验与教训

回复: [分享]软件测试经验与教训