《软件测试经验与教训》内容摘录

《软件测试经验与教训》摘抄

认知心理学

1、与测试有关的一些问题包括：

人的感觉和记忆可靠性

信念从哪里来

信念如何影响人的行为

作出决策所使用的偏见和捷径

如何了解并分享所知道的信息

如何考虑复杂事情

在压力下如何思考

如何识别模式

如何把想法和事务分类

如何注意事务之间的差别

记忆事件中的失真

如何重新构建部分记忆的事件（例如不可再现的程序错误）

认知心理学的书目：《旷野中的认知》（Cognition in the Wild）

《理论与证据：科学推理的能力的开发》

2、优秀测试员会进行技术性、创造性、批判性和实用性地思考。

技术性思考：对技术建模并理解因果关系的能力

创造性思考：产生思想并看到可能性的能力

批判性思考：评估思想并进行推断的能力

实用性思考：把想法付诸实施的能力，包括诸如运用测试工具，并使测试手段和力量与项目范围适应的技能。

当测试过程以最具破坏性的方式失败时，根本原因最有可能是视野狭窄。换句话说，这不是运行了一万个测试，而本来应该运行一万零一个的问题；问题是没有想象出测试的总体大纲，没有做即使有两倍时间和资源也不会做的测试。

后注：这说的真是太有认同感了，盲目地补洞是狭隘的，没有一个总体测试大纲，给你时间和资源，你也会遗漏。

3、黑盒测试并不是基于无知的测试。为了做好黑盒测试，就要了解用户，了解他们的期望和需要，了解技术，了解软件运行环境的配置，了解这个软件要与之交互的其他软件，了解软件必须管理的数据，了解开发的过程，等等。测试员对产品了解的越多，了解产品的方式越多，越能够更好地测试它。

后注：测试员与程序员在于思考的角度不同，而非能力的差异，测试不再是不懂编程的接口了，殊途同归。

4、测试员把精力放在评估产品上，而不只是见证产品。

后注：从这一点来看，测试决不能只验证正向的基本功能。如何对产品全面评估，不光要对产品熟悉，对用户熟悉，还涉及到认知论。

5、测试员对建模艺术越精通，越能够更好地测试。书目（《通用系统思考引论：25周年版》）

中文版名字应该是《系统思维导论》，作者温伯格，这本书值得入手

6、即使充分研究了产品，对产品有了很深的了解，仍然要探索问题。因为所有测试都是采样，而且所有样本永远也不可能完备，探索式思考要在整个测试项目过程中，在寻求最大化测试价值时起作用。

7、使用诱导推断逻辑发现推测。1）收集一些数据并要找出其中的意义；2）构造可能说明这些数据的各种解释；3）收集更多的数据，以确定或否定每种解释；4）从候选解释中，选择能够最一致地说明所有重要数据的解释，如果没有足够证据证实任何结论，则继续搜索。

后注：医生看病过程中，也是用的这种方法，做各种检查，假设，推测，再检查，直到能确定每种解释。

测试员利用诱导推断，

收集更多的数据。

收集更重要的数据。

收集更可靠的数据。

理解应用于数据的原因和效果。

找出可以说明数据的更多、更好的解释。

收集更多否定每个解释的数据。

收集更多区分解释的数据。

除非某个解释能说明所有重要数据，并且明显得到比其他解释更好的解释，否则不要确定解释。

8、猜想的置信度只能来自反驳它，但又反驳不了的努力。

给出猜想并尝试反驳，应用于测试：

测试的目的是显示产品失效，要比显示产品正常更有力。

有关软件（软件有怎样的行为、如何好等）已经牢固形成的信念应该收到质疑。这意味着应该能够想象出新的与已有信念矛盾的信息。

警惕声称以超过测试员所运行的具体测试的方式，检验或确认了产品的测试。任何量的测试都不能提供产品质量的确认性。

后注：测试是不可能完备的，通过测试不断质疑产品质量，直到达到产品质量和测试成本之间的平衡。好的测试是能暴露出产品的问题，这点要成为测试的信仰。不要坚信产品是正常的，要用挑剔的眼光来进行测试这项工作。

9、需求是重要任务所关心的质量或条件

后注：这点要明确，不是每个人的观点都同等重要，不同客户通过产品要得到不同的东西，他们不一定直到要什么，而且所要的东西会随时发生变化。作为测试人员，要发现它，找到它。

10.需求信息到达测试员主要有三种途径：

会议。找出其有关质量的意见具有影响力的人，与他们交流，了解他们最关心什么。

推导。通过外推已知的项目和产品其他信息，确定什么需求最重要

参照。既发现显示，也发现隐式规格说明，并以此作为测试的基础。

一本好书：《探索需求：设计之前的质量》

11、当要测试复杂和令人畏惧的功能集合时，可间歇进行，人的头脑具有处理复杂问题的惊人能力，但是不要指望马上就能理解复杂产品。可试着先研究复杂产品30分钟或一个小时，然后停下来干点别的，这就是陷入和退出。如果觉得问题太多，则尽快退出。

经过几个轮次的陷入和退出，就会开始明白产品的模式和轮廓，很快就会在头脑中更系统、更具体地测试很研究策略。

12、运用试探法快速产生测试思路：

测试边界。边界更有可能暴露规格说明的模糊问题。

测试所有错误信息。错误代码处理与主流功能代码相比，一般比较弱。

测试与程序员的配置不同的配置。程序员已经偏信自己的配置没有问题。

运行比较难设置的测试。在其他条件相同的情况下，易于设置的测试更有可能已经被执行过。

避免冗余测试。如果某个测试实际上是重复其他测试，就不会产生新价值。

13、软件测试领域内的一些顾问和论文作者看起来相信，只要提供测试过程，测试效果差的测试员就可以变成测试效果好的测试员。在我们看来，这是一种差的实践，这反映出他们对测试和进行有效测试的人的根本误解。

在评估测试过程时，首先要看项目测试员的素质，要看他们怎么思考，以及这种思考怎样对其行为产生影响。只有掌握了这些信息才能评估他们的工作产品。

后注：人才是成功最关键的因素，牢记这一点。

14、按照指示做不会掌握任何东西，就像要沿高速路上火星一样，要像伟大的机械师和伟大的程序员那样地学习测试：把东西分解，琢磨其工作原理，再以新的方式组装到一起。不要把自己限制为指示接受智慧的服务者，而应该使自己成为智慧的创造者。

要永远使头脑运转，观察其他测试员，研究和不断评估如何筛选自己的思想。

后注：这一段是振聋发聩的呼声，要有无畏的开创精神，不要总想着有人带头，在前无古人的时候，你就是创造者，面对陌生，不要害怕，不停摸索，实践，学习，路在脚下。

15、清楚地报告问题，但不要试图解决问题

后注：做好测试员自己的事情，你的职责就是准确、清晰地表达失效本身的信息，因为没看代码，不可能知道失效的根源，你所提出的可能解决方案也许很可笑，让设计师去找到更合适的解决方案吧。切记这一点！

16、注意自己的预期，所批评的每个人都会看到报告

后注：在这一点上，自己是吃过亏的。工作的职场不是在学校，揪住同学的一个把柄，迫不及待请老师主持公道。职场上你们是平等的合作者，你们有共同的目标，不是一个此消彼长的关系，最重要的是彼此的信任和默契，也没有一个公平的裁判可以去评判。类似告状的行为，也许让你舒服一时，但得不偿失，长久以往，会失去彼此的信任。离开了人的主观性，事情是做不好的。要始终保持中立语气。不要开玩笑，别人会误解。

发现问题时，记得补充做一些后续测试，寻找该程序错误更严重的后果，或寻找比再错误报告中所描述的更广环境下出现的情况，可能会更好地推销错误修正机会。不要一发现问题，就激动地找程序员。

17、在决定要自动化的内容时，首先设计自己的测试。这样可以避免落入自动化测试的陷阱：易于自动化，但找缺陷的能力很弱。

采用与设计手工测试不同的方法设计自动化测试。

18、自动化工作如果要得到支持，就要把精力集中到降低开发失效的风险上。自动化测试部分目标是：

迅速检测出新版本中的不稳定的变更

尽可能迅速暴露回归程序错误

快速报告问题，因为这会使程序错误修改更容易

自动化冒烟测试；自动化单元测试

19、不要强求100%的自动化

自动化测试通常意味着更经常地运行更少的测试。很多测试只值得运行一次。如果在报告程序错误之前没有人来分析程序错误，就会浪费程序员的时间，并引起程序员的方案，会由于不得不对付大量虚警和冗余而感到不满。

20、不要通过自动化使无序情况更严重

如果测试设计得很差，则自动化会使差的测试执行得更快。如果测试组织得很差，则自动化计划会使情况更糟。如果测试员不知道或不想说自己在测试什么，则他们创建的是没有人知道如何运用的自动化测试。

后注：自动化测试不是灵丹妙药，最重要的还是测试设计，自动化测试应该是一张网，可以缩短开发周期、降低开发失效的一张网。当前项目中，一开始就做自动化测试设计，这是本末倒置，让人觉得很彷徨，在发现缺陷的能力上也很弱，长此以往，会让管理层看不到成效和产出，从而质疑自动化测试的活动。

选择自动化测试要很小心，后期失控的维护成本，可能是会经常面对的问题。

21、如果有很好的理由重用很多次相同的测试，那么测试自动化会有助于降低成本，有助于创建和运行手工运行昂贵或不可能的测试，有助于不能手工完成的程序操作（时序和内存使用）度量，有助于运行大量测试序列，查找只有经过几个月的正常使用才会表现出来的缺陷，以及手工运行太费时间的测试。通过在测试自动化上的一定投入得到这些好处中的一部分是值得的，但是如果资源和预算计划是建立在几乎不花钱就可以用部分时间完成的假设基础上，那么希望就会落空。

22、测试自动化项目需要程序设计、测试和项目管理方面的技能。同时擅长测试设计和测试自动化的人并不常见，指派不同的人完成测试设计和测试自动化是很重要的。这两种工作都是全职的。使用专家可以得到最佳结果。

23、在自动化测试设计上不要吝啬。在设计自动化测试时应该明确考虑的问题：

保证测试已经被正确地设置。

描述预期结果。

发现潜在错误和副作用。

从潜在测试失效中恢复。

防止测试相互干扰。

将测试设计形成文档，以便以后使用该测试的人能够从现在的设计思想得到一些启发。

24、避免在测试脚本中使用复杂逻辑。测试脚本中的条件逻辑会使测试更难理解，也更容易出错。可能需要逻辑控制来处理测试的设置、响应经过检查的输出，或处理定制控件。把这些逻辑放在单独的功能中。可以单独测试该功能，也使测试更容易评审。要使测试简单，使测试线性化。

后注：目前的测试框架就是这样做的，各种关键字封装，及分层的思想，目前是分4层，保持了功能点的独立和低耦合。后续可能要考虑把单独的功能点封装成类，供上层整体调用，更进一步封装功能模块。

25、为了通过相同的测试过程测试不同的输入和输入组合，可利用数据驱动的自动化测试。将测试输入和预期输出组织成表，表中的一行对应一个测试。然后创建一个从表中逐行读入的自动化测试过程，执行每个输入步骤，并检验预期结果。在有些情况下，可能很难自动化测试结果的检验。采用测试过程来收集测试结果，并在输入数据的语境中表示测试结果，这样可以简化手工结果分析。

26、关键词驱动的自动化测试，建立在数据驱动手段上，但是表中包含指令（关键词），而不只是数据。

后注：这是后面自动化测试设计的一个趋势，便于非程序员创建测试，并专注在测试设计上。缺点是关键词必须要提前存在。定义和 实现任务函数会成为主要任务。后续可以考虑将功能封装成类，由外部调用。值得注意，自动化测试也是软件开发过程，要遵循软件工程管理。

27、利用编程接口自动化测试。编程接口包括API、命令行接口、COM接口、HTTP等，所以测试员需要学习不同的语言和技术。

后注：尽可能绕过GUI的自动化测试，或将其放在选择表的最后，因这部分的变更更快更大，维护成本很高。相反，利用接口自动化，更加稳定和可靠，且更容易发现缺陷。

28、自动化单元测试最常见的形式，通过在语境中测试单元来避免开发桩。我们兴许可以把它叫做单元集成测试。对于自底向上构建的系统，这种形式的自动化会相当容易。测试员需要一个像Junit或unit这样的框架来管理测试包的执行。这样子既不太困难也不太昂管。代码通过该语言所支持的一般调用接口测试。程序员编写测试所使用的语言与产品软件语言一样。将单元测试用于回归测试、冒烟测试和配置测试。

后注：目前项目中采用robot framework的框架，就是这样做的，其实也就是自动化的单元测试

29、可测试性往往是比测试自动化更好的投资，可测试性是可视性和控制，潜在功能如下：

访问源代码。能够检查源代码控制系统中的变更记录特别重要

日志。记录错误信息、错误源、使用剖面、资源使用、系统消息和协议通信。

诊断。诊断可对潜在问题发出警告。断言就是一个例子

错误模拟。软件应该能够从媒体错误、内存或外村不足、网络延迟和中断连接，以及类似的问题中恢复。测试员会发现很难创造这些条件，特别时不可重现和系统问题。可以在产品软件的下层替代错误状态触发器，以便于测试错误处理情况。（也有在被测产品外部模拟这些错误的工具）

后注：这一点我们在工作中做的很不好，其实是软件可测试性的欠缺，是可以提需求要求满足的。一般是在外部模拟，如网络延迟可用网损仪。但这部分开销较大，对设备要求较高，其实可以在软件内部，通过替代的方法触发错误状态，模拟错误，以便上层协议栈处理。

测试点。能够在系统的不同点上检查或修改数据

事件触发器。当内部任务开始和结束时发出通知，有助于帮助同步测试。

读入老的数据格式。

测试接口。编程接口为可测试性带来重要好处。

定制控件支持。使GUI测试工具能够使用定制用户界面控件

允许多实例。允许在同一台计算机上允许多个客户或代理，即使在现场并不支持这样的配置。这会使测试员能够在小实验室中模拟大网络。

30、我们认为避免或对付坏关系的最好办法，就是建立相互尊重基础上的人员关系。假设要与之打交道的人是值得尊重的，并基于这种假设行动。以会赢得他们尊重的方式工作。拒绝接受误解或不尊重。作为程序员工作的正式批评者，测试员必须敏感、有鉴赏力并有外交手段。不要作为拉拉队中而置身度外，而是要让别人知道测试员理解程序员工作的价值。如果程序员的工作很差，不要为此使他们难看。

后注：理解在处事过程中人的重要作用。事情办不办得成，除了方法，很大程度上决定做事的人。不要把要和你共事的人对立起来，在对立的气氛里，是很难有共同的使命感的。切记！

31、主动直接为程序员提供帮助。这样可以建立信任。

测试第三方组件。共享测试结果，使得程序员能够决定是否可以在产品中使用第三方组件，以及怎样使用。

测试非正式个人版本和原型

为程序员建立测试环境，以便程序员自己进行测试。

评审需求文档的可测试性。程序员会由于要求很模糊而感到头疼，他们会很欢迎测试员的介入。

后注：作为测试员，所作的一切都应该是提供服务。提供服务使测试员有机会得到信任，也有机会展示自己的才能。不要觉得为程序员提供服务是不务正业，相互之间的信任是这样建立起来的。

32、测试员的正直和能力需要尊重

要干脆地报告问题

将自己的判断建立在产品行为的实际观察基础之上

如果失效是不可重现的，要展示为了重现失效所作的各种尝试。应该展现对程序员时间的尊重

直接报告坏消息。在向程序员的上司报告之前先向程序员提供使他们能够做出反应的机会

不要假装了解自己并不了解的东西

不要夸张错误报告

如果测试员是正直的，就可以展示自己的能力。如果测试员丧失正直性，其能力就会变得毫无意义。

33、测试员的角色是服务，而不是控制：

服务提供者控制他尽最大努力所提供服务的质量和相关性，以取得最终结果。我们向需要服务的人们提供优质服务。

服务提供者不控制最终产品的质量，不控制其他服务提供者所使用的过程，不批准或拒绝产品的发布。服务提供者不是项目经理，而是要向项目经理提供服务

后注：认识到这一点很重要，质量不是由测试来保证的，换句话说，质量不是测出来的，没有好的过程，没有其他服务提供者的共同努力，质量是测不出来的。测试员要认准自己的定位，不要做质量警察，经常发布一些准则或限制他人的过程文件，这没有意义。

34、不要尝试建立一种控制文化。测试小组没有资源、经验或行政力量来改正更广的开发过程，也不能管理被改正的过程。胜任的测试小组可以向各种项目经理提供一致的服务，要在非常不同的项目管理风格下工作，包括不方便的风格，以及使测试成为低效项目开发一部分的风格。

后注：这里很有意思，人不能超越自己的地位和职责，要管理或诟病整个团队，等你成为团队的领头再说。批判总是很容易的，难的是真正实施。在没到达那个位置前，你是没有机会去实施的。

35、测试员在公司中的权利建立在自己的调查技能和自如沟通的基础上，而不是建立在命令链上，因为测试员在项目团队的命令链中的位置并不很高。我们建议测试员要成为能够为别人带来价值的守信用、高度正直的信息提供者，因此来施展和扩大自己的影响力。

36、需求是在我们想要和我们能够得到的功能之间进行不断斗争的结果。随着项目的展开，需求会变化。

后注：需求的变更是永恒的，要积极拥抱变更，不断调整计划

37、项目涉及功能、可靠性、时间和资金之间的折衷

项目经理的任务就是按时并在预算限度内交付一组合适的功能，达到合适水平的可靠性。这是一种具有挑战性的折衷。

功能。选择合适的功能集，交付所有项目相关人员所要求的一切功能太昂贵。

可靠性。使产品能够正常运转，但不能花费无限时间和资金保证在所有能够想象出的环境下都能完美地运行。

时间。尽可能迅速地将产品投入正式使用和销售。

成本。以最低的合理成本构建产品。成本包括资金和机会成本。当把关键资源（特别是技术熟练人员或独特设备）用于项目团队时，其他项目团队就不能使用该资源。

后注：任何事都是有代价的。不能陷入对技术的狂热，不能完美主义，这是一个复杂的世界，要学会平衡和妥协。

38、测试员参加早期开发可以是很有价值的活动，如：

他们可以评审需求文档的可理解性、可测试性和模糊性。

随着其他项目工作制品的开发，再对它们进行测试。不要等整个产品完成才测试。

推动代码评审

拟定硬件配置和准备购置或借用设备的初步清单。

要求提供可测试性功能。

讨论代码覆盖率度量和使用其他开发支持工具的可能性。

准备测试自动化。

研究测试工具。

如果可能，订购可用于被测软件的外部开发的测试包。

了解产品的市场和竞争情况。

39、当被测版本就绪时测试环境也应该就绪，这一点很重要。在快节奏的项目团队中，没有管理良好的测试环境的测试小组是没有价值的。

后注：管理良好的测试环境，是很值得投入的一项工作。目前的工作中，这一项做的很不好，搭建环境的时间占了测试的大部分，这是低效的。

40、程序员就像龙卷风。把测试方法建立在公司内部编程小组不会实施的实践基础上，是没有意义的。把他们看做是一种自然力量。程序员会按照自己的方式做，而且在不同的公司中程序员的工作方式也有很大不同，测试经理应该相应地设计自己的实践。

后注：不要假设事情会以你设想的方式发展，然后去设计臆想中的方案，这不切实际，也不会有什么用。人最大的特点是能及时适应环境，穷则思变，变则通。不要死板，不要教条主义，要具体问题具体分析。

41、好的测试计划便于后期变更。以下是一些建议：

不要在测试之前开发大的测试包，而是在需要测试包时再开发。

不要编写维护成本很高的大量测试文档，例如详细手工测试脚本。

不要把手工或自动化测试捆绑到特定的用户界面，除非想要专门测试该用户界面。

通过最大化可维护性和跨平台可移植性来设计自动化测试。

构建一组能够在不同程序中重复使用的通用测试

构建一组很强的冒烟测试，以快速检测被测软件中的基本失效。

慎重考虑使用极限编程法开发自动化的测试。

开发一种产品用户和用户要通过产品获得效益的模型。通过这种模型导出复杂测试。这些测试中的大多数都不会随项目的推进而快速变化，因为这些测试关注的是收益，而不是实现细节。

帮助程序员开发大的单元测试包，以及相对简单功能的其他测试。

42、足够测试意味着有足够的信息可供客户做出好决策。

由于测试是一种信息收集过程，当收集了足够的信息时就可以停下来。当有理由相信产品仍然有重要的未发现问题的可能性很低，就可以停止测试。

判定测试是否足够好有多种因素：

测试员知道要发现的重要问题的种类，如果存在这种问题的话。

测试员知道产品的不同部件如何表现出严重问题。

测试员对产品做了与这些风险相应的检查。

测试策略具有合理的多样化，以避免视野太窄。

测试员使用了所有可用的资源进行测试。

测试员满足客户期望满足的所有测试过程标准。

测试员尽自己的可能，清晰地表示测试策略、测试结果和质量评估。

43.我们可以把进展报告看做涉及不同的因素，如：

产品已经完成了多少测试？

计划进行的测试已经完成了多少？

发现了多少问题？其中有多少问题还没有解决？

我们对测试质量有多大把握（如，如果尽测试员发现以前的测试员遗漏的很明显的错误，那么对质量的把握就比较低）？

出于未解决缺陷，或缺乏设备，或没有做出决策，有多少测试工作受到阻碍？

44、周状态报告的推荐结构

后注：这部分非常重要！！！有借鉴意义

可以把状态报告看做四页长的文档。第一页列出关键问题，如：

所需的决策。（例如，应该如何确定这些功能的优先级？测试什么设备？是否吸收新测试小组成员？）

所需的程序错误修改。（对测试工作产生影响的所有程序错误，都应该优先解决。）

预期的交付的工作制品（例如承诺交付的文档、设备、功能和工具）以及承诺的交付日期。在截止日期之前一点就要把这些工作制品列在清单上，过期没有交付的工作制品要留在清单上，删除以及提交的工作制品。这种清单表示遗漏的东西，而不是累积工作表。突出显示阻碍工作进展的因素，例如无法访问承诺提供的计算机或没有完成和交付功能清单。

意外问题。（例如，报告由于员工跳槽引起的某部分测试效率降低，某种关键工具不像预想的那样好用，员工需要培训等）。

第二页描述测试小组完成计划任务进展的情况。例如，可以列出不同测试工作进度计划，每项测试工作的预算（例如两周），每项测试任务的完成情况（例如完成了10%），每项测试工作使用的时间。在这个例子中，如果所使用的时间超过了计划两周的10%以上，那么这部分工作的进展就会落后进度计划。通过浏览这个清单，就可以得到进展（或停滞）对比计划和进度的总体印象。

第三页提供错误报告统计数字。我们把程序错误数放在报告的中间页，把自己认为很重要的新闻放在第一页，并在其他页塞入要通报的其他内容。

最后一页列出本周被推延的程序错误。清单可以只包括程序错误数、总计行，以及测试员为该程序错误划定的严重程度。需要更多信息的读者可以进一步查找。

45、所设计的测试计划要符合自己的具体情况。给定5种资源和约束：

开发。产生将要测试的产品的系统。如何接收该产品？该产品的可测试性如何？

需求。成功产品的评判准则。该产品的风险是什么？有关质量谁的意见最重要？

测试团队。能够投入该产品测试的人员。有合适的人选嘛？能够及时完成任务吗？

测试实验室。使测试团队能够完成测试任务的系统、工具和材料。有合适的设备吗？程序错误跟踪系统的状态是否良好？

任务。测试团队必须要按照客户认可的成功标准解决的问题。快速找出重要问题？对质量做出准确评估？

测试小组的控制能力在于如何应对这些资源和约束：自己要有什么样的测试策略、保障条目和工作产品？

46、利用测试计划描述在测试策略、保障条件和工作产品上所做的选择

测试计划必须描述三类选择：

策略。如何测试产品以快速找出重要问题？需要对哪些部分进行特殊测试？要运用什么手段创建测试？当程序错误出现时怎样识别？测试策略要规定测试项目与测试任务之间的关系。

保障条件。如何利用资源实现测试策略？谁来测试？什么时候测试？要想成功需要什么条件？

工作产品。怎样向客户提供工作产品？如何跟踪程序错误？需要编写什么测试文档？需要编写什么报告？

47、好的测试策略是：与具体产品有关；关注风险；多样化；实用

48、指定好的测试计划要考虑的几个问题：

1）监视影响测试计划的主要问题：

状态检查：

¨  是否有要满足的特别关键或很难度量的产品质量标准？

¨  产品是否复杂或很难学会？

¨  测试员是否需要特殊培训或工具？

¨  是否有很难得到或配置的部分测试平台？

¨  是否将测试未集成或不可操作的产品组件？

¨  是否存在具体的可测试性问题？

¨  项目团队是否缺乏产品设计、技术或用户群的经验？

¨  测试是否必须很快开始?

¨  是否有制定测试计划所需的信息还没有收集到？

¨  是否能够评审被测产品的某个版本（甚至是演示版、原型版或老版本）？

¨  是否有足够的难以录用或组织的测试人员？

¨  是否必须遵循自己所不熟悉的测试理论？

¨  项目计划的制定是否没有考虑测试需要？

¨  计划是否要经过漫长的协商或批准？

¨  测试员是否远离客户？

¨  项目计划是否经常变动？

¨  计划是审计的一个内容吗？

¨  客户是否说不出测试员能够为他们做什么？

2）.明确任务：

需要考虑的任务要素

¨  快速找出重要问题

¨  进行综合质量评估

¨  确认产品质量是否达到具体标准

¨  尽可能缩短测试时间或降低测试成本

¨  尽可能提高测试效率

¨  就提高质量或可测试性问题，向客户提出建议

¨  就如何测试向客户提出建议

¨  保证测试过程是可以充分说明的

¨  严格遵循特定的方法或指示

¨  使特定的项目相关人员感到满意

可能的工作产品：

¨  说明测试任务的简短电子邮件

¨  一页纸篇幅的测试要求

状态检查：

¨  是否知道谁是自己的客户？

¨  关键人物是否赞同测试任务？

¨  测试任务是否足够清晰，以作为制定计划的基础？

3）分析产品

了解被测产品及其内部技术。了解如何使用被测产品。需要深入下去。随着对产品了解的深入，测试会变得越来越好，因为自己越来越接近成为产品专家。

分析什么：

¨  用户（用户是谁，他们的职业是什么）

¨  结构（代码、文件等）

¨  功能（产品做什么）

¨  数据（输入、输出、状态等）

¨  平台（外部硬件和软件）

¨  运营（产品是用来完成什么任务的）

分析方式：

¨  执行探索式测试。

¨  评审产品和项目文档

¨  与设计人员和用户面谈。

¨  与类似产品比较

可能的工作产品：

¨  测试覆盖大纲

¨  带注释的规格说明

¨  产品问题清单

状态检查：

¨  设计人员赞同产品覆盖大纲吗？

¨  设计人员认为测试员理解了产品吗？

¨  测试员能够可视化产品并预测产品行为吗？

¨  测试员能够产生测试数据（输入和结果）吗？

¨  测试员能够配置并操作被测产品吗？

¨  测试员理解产品将被怎样使用吗？

¨  测试员是否发现设计中的不一致问题？

¨  测试员是否找出显示和隐式规格说明？

4）分析产品风险

被测产品可能怎样以一种重要方式失效？开始测试员最多也只会有一个一般想法。随着测试员对产品了解的深入，测试策略和测试会变得越来越好，因为对被测产品的失效机理了解得越来越多。

分析对象：

¨  威胁（具有挑战性的条件和数据）

¨  脆弱性（在什么地方可能失效）

¨  失效模式（可能的问题种类）

¨  失效影响（问题的严重程度）

分析方式：

¨  评审需求和规格说明

¨  评审实际失效

¨  与设计人员和用户面谈

¨  对照风险启发和质量评判大纲评审产品

¨  找出一般问题和失效模式

可能的工作产品：

¨  组件/风险矩阵

¨  风险清单

状态检查：

¨  设计人员和用户对风险分析认可吗？

¨  测试员能够找出所有重要的问题种类吗？这些问题都应该在测试期间出现吗？

¨  为了尽可能提高测试效果，测试员知道该把测试工作集中到哪些对象上吗？

¨  设计人员是否采取措施使重要问题更容易被检测，或降低发生的可能性？

¨  测试员如何发现自己的风险分析是否准确？

5）设计测试策略

为了根据已有的产品最佳信息快速、有效地测试，测试员可以做什么了首先尽可能做出最好的决策，同时又要让测试策略能够在项目整个开发过程中改进。

考虑五方面的手段：

¨  以测试员为核心的手段

¨  以覆盖率为核心的手段（结构覆盖率和功能覆盖率）

¨  以问题为核心的手段。

¨  以活动为核心的手段。

¨  以评估为核心的手段。

计划方式

¨  针对风险和产品域确定手段

¨  可视化具体和实用手段

¨  使测试策略多样化，尽可能减少遗漏重要问题的机会

¨  寻找通过自动化测试扩展测试策略的途径。

¨  不要计划得过死，使测试员能够发挥自己的才智。

可能的工作产品：

¨  逐项列出的每条所选测试策略以及如何运用的说明

¨  风险/任务矩阵

¨  所选测试策略固有的问题或挑战清单。

¨  针对没有充分覆盖的产品部分提出的建议。

¨  测试用例（仅当需要时）。

状态检查：

¨  客户认同测试员制定的测试策略吗？

¨  测试策略给出的所有内容都是必要的吗？

¨  测试策略是否能够实际贯彻？

¨  测试策略是否过于通用？可以容易地用于任何产品吗？

¨  是否还有不准备测试的任何重要问题？

¨  测试策略利用了可用的资源和帮助者吗？

条件计划

测试经理将如何实现测试策略？测试策略会收到条件约束或指示的很大影响，努力争取所需的资源，并尽量利用可用的所有资源。

保证条件方面的问题：

¨  测试工作量估计和进度安排

¨  可测试性宣传

¨  测试团队力量（合适技能）

¨  测试员培训与管理

¨  测试员任务分配。

¨  产品信息、收集与管理

¨  项目团队会议、沟通和协同

¨  与项目团队所有其他小组，包括开发小组的关系。

¨  测试平台的获得和配置。

¨  约定和协议

¨  测试工具和自动化测试

¨  插桩和模拟需要

¨  测试包的管理和维护

¨  构建和传送协议

¨  测试周期管理。

¨  错误报告系统和协议

¨  测试状态报告协议

¨  代码冻结与增量测试

¨  项目最后的压力管理。

¨  测试停止协议

¨  测试效果的评估

可能的工作产品

¨  问题清单

¨  产品风险分析

¨  责任矩阵

¨  测试进度计划

状态检查

¨  项目团队的保障条件是否支持已制定的测试策略？

¨  是否存在阻碍测试的问题？

¨  测试条件和策略是否能够修改，以适应可以预见的问题？

¨  现在是否可以开始测试，以后再解决其余问题？