《软件测试经验与教训》读书笔记

分享到

《软件测试经验与教训》读书笔记

发布时间:2013-3-29

测试员的角色

1）测试给项目产品做关键决策时提供信息依据。

2）测试员要明确自己的在项目中的使命，使命决定要做的一切。

3）测试员要服务于多类客户，针对不同客户，提供不同信息。（例如：技术支持、管理者、市场人员）

4）测试员需通知客户有关威胁产品价值的任何信息。

5）测试员要迅速找出重要的程序问题。（变更的、核心的、常用的、可用性、影响大的、最需要的部分）

6）为程序员提供支持。尽量建立最短、最快的反馈环路。

7）询问项目相关一切问题，最好结合其他沟通形式提问。

8）测试员关注失效，客户才能关注成功。注：确认程序正常是不可能的，除非运行所有可能的测试，所以确认成本是很高的。

9）测试员不会发现所有程序问题。所以应自知不能完成所有事，合理有效安排自己的时间。

10）测试员当心向客户传递隐藏的已“完备的”测试。应让客户详细了解测试过程，总结自己已实施和未实施测试点及如此安排的原因。

11）通过测试不能保证质量。测试员既不会提高质量，也不会降低质量，质量来源于构建产品的人。注：测试员能促进项目质量保证的信息，但质量保证是来自整个项目团队的。

12）永远别做看门人，即测试员永远不要把控产品发布的权力。因为这样团队其他成员可能会放松质量。建议：由控制项目、条件好的人承担发布产品责任或由集体决定是否发布产品。

13）当心测试中的“不关我事”理论。测试员的使命应该是尽其所能，通知团队可能会对产品的价值产生消极影响的所有问题。

--14）当心成为过程改进小组。因不管过程改进要干什么，它永远都会涉及感情。

15）别指望任何人都能理解测试，或理解测试员需要什么条件才能搞好测试。所以测试需向客户解释测试，且需一遍又遍地解释。因为疫苗的作用会逐渐衰退。

测试员的思考方式：

测试员不喜欢抱怨，他们喜欢提供证据；测试员不喜欢征服，他们喜欢打破产品没问题的幻觉；测试员不喜欢发布坏消息，他们喜欢把客户从虚假信念中解放出来。

16）测试运用的是认识论。认识论研究如何认识所了解的东西：研究证据和推理。（如：怎么知道软件足够好？如果软件不是足够好，怎么才能知道？怎么知道已完成了足够的测试？）

17）研究认识论有助于更好测试。（例如：如何收集和评估证据？如何进行有效的推论？如何使用不同逻辑形式？如何做出好的决策？）

18）认知心理学是测试的基础。如果说认识论告诉我们应该怎样思考，那么认知心理学告诉我们的是我们是怎样思考的。（例如：人的感觉和记忆可靠性。信念从哪里来。在压力下如何思考。）

19）测试能力差别在于测试员如何思考。（如：测试员的测试设计选择；解释所观察到的现象的能力；分析描述这些现象的能力。）

20）测试需要探索式推断，而不只是输出与预期结果对比。

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

技术性思考：对技术建模并理解因果关系的能力。（如：相关技术事实的知识和使用工具并预测系统行为的能力。）
创造性思考：产生思想并看到可能性的能力。（如：寻找猜想可能存在的问题。）
批判性思考：评估思想并进行推断的能力。（如：消除错误的能力并构建好的测试用例的能力。）
实用性思考：把想法付诸实施的能力。（如：运用测试工具，并使测试手段和力量与项目范围适应的技能。）

22）黑盒测试并不是基于无知的测试。因为测试员对产品及产品的方式了解得越多，越能更好地测试它。而黑盒测试的优势在于测试员可能与程序员的思考不同，因此有可能预测出程序员所遗漏的风险。

23）测试员不只是游客。两者差别：测试员把精力放在评估产品上而不只是见证产品。注意：测试员对产品做大量的非测试的事（例如：看看产品由什么组成；怎么工作的。），有助于对产品的了解，为了更好地测试。

24）所有测试都试图回答关于已BUILD产品和用户所需产品间关系的某个问题。

--25）所有测试都是基于产品模型（例如：谁是用户，用户关心什么等一些概念），而不是实际产品。

26）直觉是不错的开始，但又是糟糕的结束。建议：把直觉用作指南，但不能用作合理性证明。

27）为了测试，必须探索。所有测试都是采样，且样本永远不可能完备探索式思考要在整个测试项目过程中，在寻求最大化测试价值时起作用。这里所谓的探索，是指有目的的漫游：带着一般使命在某个空间中漫游，但没预先确定的路线。探索包括不断学习和实践。

28）探索要求大量思索。探索就是侦查，是没有边界的搜索，需要前向、后向、侧向思索。

前向思索：根据已知探索未知，从所看到的探索还没看到的。注意支流和副作用。
后向思索：从怀疑或想像的东西返回到已知，尝试证实或否定自己的推测。
侧向思索：让自己的工作由于新冒出的想法而转移，然后再探索主题返回到主线索上。

--29）使用诱导推断逻辑发现推测。诱导推断又叫做假设归纳，是一种测试员每天都要使用的关键推理形式：最佳解释的推理。主要内容是：

第1：收集一些数据并要找出其中的意义。

第2：构造可能说明这些数据的各种解释。

第3：收集更多的数据，以确定或否定每种解释。

第4：从候选解释中，选择能够最一致地说明所有重要数据的解释，如果没有足够证据证实任何结论，刚继续搜索。

30）使用猜想与反驳逻辑评估产品。

20世纪初，哲学家Karl Popper引入了猜想与反驳方法，用于如何区分宗教和科学问题。这种方法基于科学家永远也不能绝对肯定任何具体事实，或关于自然的理论这个前提。这个方法，以如下三种重要方式应用于测试：

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

第2：有关软件（软件有怎样的行为、如何好等）已经牢固形成的信念应该受到质疑。

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

31）需求是重要人物所关心的质量或条件。作为测试员，必须认识到谁的关于质量的观点最重要；不同客户通过产品要得到不同的东西，他们不一定知道要什么，而且所要的东西会随时发生变化，这使得测试员的工作更有意义。

32）通过会议、推导和参照发现需求。需求信息到达测试员主要有三种途径：

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

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

第3：既发现显式，也发现隐式规格说明，并以此作为测试的基础。

33）既要使用显示规格说明，也要使用隐式规格说明。

--显式规格说明是一个有用的需求信息源，经过客户的权威确认。（如：“是的，这就是规格说明，是产品描述。”）

--隐式规格说明是没有经过客户权威确认的一个有用的需求信息源。（如：“这不是规格说明，但是有意义。”）隐式规格说明的威信来自其内容的说服力和可信性，而不是客户的批准。在大多数情况下，只有部分隐式规格说明与当前产品有关。其存在形式：

竞争对手的产品、相关产品、同一产品的老版本、项目团队之间的电子邮件讨论、顾客意见、图形用户界面风格指南、操作系统兼容性需求、测试员自己的丰富经验等。

34）“它没有问题”真正的含义是，它看起来在一定程度上满足部分需求。注意：测试员所认为的“它没有问题”的意义，可能与别人的定义不同。

35）任何时候报告产品质量状态时，都应该用有关测试方法和测试过程等已知局限性的信息对报告限定。因为不管测试员对产品的质量有什么看法，都只是猜想。

--36）不要将试验与测试混淆。测试需包括四个活动：配置、运行、观察、评估。

37）当测试复杂产品时，使用“陷入与退出”法（plunge in and quit）。即，试着先研究复杂产品30分钟或1小时，然后停下来干点别的。这个方法的优点是，除了选择产品的一部分进行研究外，绝对不需要计划。这个几个轮次的陷入与退出后，就能开始明白产品的模式和轮廓。

38）运用试探法快速产生测试思路。（试探法测试，如：测试边界、错误消息、与程序员不同的配置环境、比较难设置的测试、避免冗余测试等）请注意：试探法中并没有智慧，智慧来自测试员，试探法所能够做的，只不过就是为测试员的思考提出建议。在收集测试方法时，要了解每个方法背后的原理，以及适用和不适用的条件。

39）测试员不能避免偏见，但可以管理偏见。多样化可抵御过强的偏向，测试员集体谈论测试问题，可将一个测试员的偏向降低到最低限度。

注意：试探法也是一种偏向，使用试探法，是因为其偏向可以以较好的方式引导测试员。

常见偏向：

同化偏向、证实偏向、可用性偏向（以头脑中已有的一种用户操作场景作为最常见的场景）、最初印象偏见、最新印象偏见、框架效应、知名偏向、表达偏向。

40）如果知道自己不聪明，就更难被愚弄。做到这一点并不难，只需仔细看看自己在测试中犯的错误，且在考虑自己的测试策略细节时就会更认真一点。任何时候都要注意其它测试员发现了本应自己也能发现但未发现的问题。

41）回溯漏测问题产生原因，是意外还是测试策略所致。

42）测试员的困惑，可能是某种重要的预示。（困惑内容，如：规格说明书不清楚；产品不清楚；用户文档不清楚？内部问题难以理解。）

43）新眼光或角度会发现失效。防止固化测试思路的三点提示：

第1：第一次接触产品或功能时，要特别注意使自己困惑和烦恼的地方，因为用户也会有类似反应。

第2：当与团队新成员一起测试时，观察他们在了解产品时的反应。

第3：警惕陷入测试惯例。在任何可能的地方引入多样性，或改由其它测试员负责。

44）测试员不能盲目遵循过程，除非过程先跟随自己。注意：其一：如果要遵循测试过程，最好采用自己设计、自己拥有或已经完全了解的过程。其二：为了得到最好结果，测试员必须掌握自己的测试，而不是自己的文档，即要使过程跟随自己。

45）在创建测试过程时，避免“1287”。即，编写测试过程时要避免与测试概念无关的细化，只需包含所有必要的信息和设计与解释测试所需的细节，但要让未来的测试有创造性和判断力地执行。

46）更好、更聪明的测试员是测试过程的一个重要成果。好的测试员永远都在学习。注意：在评估测试过程时，首先要看项目测试员的素质，要看他们怎么思考，以及这种思考怎样对其行为产生影响，只有掌握了这些信息才能评估他们的工作产品。

47）除非重新发明测试，否则不能精通测试。我们应该把东西分解，琢磨其工作原理，再以新的方式组装以适应新的条件。在学习过程初期，要重新发明不是非常好的测试、想法、手段和文档。这是正常的，要永远使头脑运转，观察其它测试员，研究和不断评估如何筛选自己的思想，要善于做到这一点，就必须实践。

测试手段：

48）关注测试员、覆盖率、潜在问题、活动、评估的组合测试手段。即“五要素测试系统”。建议：测试时要时刻想都会所有五个要素，

可能做出更好的组合选择，而不是采用只关注一种要素的手段。

测试员：进行测试的人。
覆盖率：测试了哪些内容。
潜在问题：测试的原因（要测试什么风险）。如：测试不满足这个需求的各种方式。
活动：如何测试。
评估：怎么判定测试通过还是不通过。

49）关注测试员的基于人员的测试手段。（如：强力测试、有关领域的专家测试、结对测试、自用测试）

50）关注测试内容的基于覆盖率的测试手段。（如：域测试、最佳代表测试、组合测试）

51）关注测试原因（针对风险测试）的基于问题的测试手段。（涉及约束冲突的错误例子：输入约束、输出约束、计算约束、存储（或数据）约束。）

基于风险测试设计建议：

第一：如果进行基于风险的测试，还需做相当量的非基于风险的测试，以针对了解还不够，还不能做出正确决策的风险进行测试。

第二：针对时序测试，如：竞争条件或其他事件意外发生顺序。

第三：在创建测试时，需创建测试过程，以强制程序使用测试员输入的测试数据，从而能够确定程序是否不正确地使用了这些数据。

52）关注测试方法的基于活动的测试手段。（如：冒烟测试、探索式测试、游击式测试、场景测试。）

53）关注测试是否通过的基于评估的测试手段。（如：与规格说明或其他权威文档比较、基于理念的测试）
启发式一致性。一致性是评估程序的重要评判准则。七种主要的一致性：与历史一致、与我们的想像一致、与可比较的产品一致、与所声明的内容一致、与用户的预期一致、产品内部一致、与用途一致。

54）根据自己的看法对测试手段分类。注意：进行实际测试时，仍需在五个要素方面进行决策，包括：谁来测试？要测试程序的哪些方面？要寻找什么类型的问题？具体要完成的任务？如何确定测试是否通过？
基于规格说明的测试的可跟踪性矩阵：（优点：显示永远不会测试的功能及经常测试的功能点；当某个规格说明变更后，显示对测试影响范围。）

如何分析与程序的某个部分或方面关联的风险：分析可从两方面入手，其一：被测对象不能通过产品质量的某种重要度量（质量属性）；其二：考虑被测试对象可能出错的因素（问题起因）。

质量属性：例如：并发性（concurrency）、标准符合性（conformance to standards）、可伸缩性（scalability）、可维护性（maintainability）、效率（efficiency）等。

问题起因：例如：新功能、新技术、新市场、学习曲线、变更后的功能、后期变更、贸然的工作、差的设计或没有可维护性的实现、疲倦的程序员、其他的人员问题（例如：互不沟通）、意外溜入、外部组件、预算外、模糊、矛盾的需求、未知需求（开发过程中，新需求不断浮现）、需求变化、复杂性、问题过多、依赖性（失效可能触发其他失效）、不可测试性（缓慢低效的测试风险）、没经过单元测试的、未进行过系统测试、依赖狭窄的测试策略、弱的测试工具、不可修改性（不能修改错误的风险）、程序设计语言类型错误。

缺陷表的使用方法：

a在缺陷表中找到一个缺陷。

b研究被测量软件是否会有这种缺陷。

c如果在理论上有这种缺陷的可能，研究如果存在，应如何发现。

d研究在程序中出现这种错误的可能性，如果存在会产生怎样严重的失效。

e如果可以，针对这类错误设计一个或一系列测试。

程序错误分析（编写表达BUG报告）

55）错误报告，文如其人。

56）好的错误报告，能推动错误的改正。测试员的责任不是保证所有错误都得到改正，而准确报告问题，使读者能够理解问题的影响。

57）使自己的错误报告成为一种有效的“销售工具”。因为错误报告劝导人们付出宝贵资源来换取测试员所建议的好处。对于程序错误，资源就是时间和资金，好处就是通过改正这个错误而带来质量改进。销售策略一般有两个目标：其一：陈述种种好处，使得潜在客户想要它。

二：向销售人员说明预期存在的问题，并反驳他们。

58）错误报告代表的是测试员。

59）努力使错误报告有更高的价值。例如：

报告缺陷，并帮助程序员定位内部问题。
报告规格说明、测试文档、用户文档或开发工具中的问题。
为技术文档编写员提供背景信息，编写员要编写手册或公司网站中的问题定位部分。
报告提示需要通过客户培训解决的问题。
报告为客户售后支持人员提供关键信息，如他们会遇到哪些没被解决或不完全解决的问题。
报告和管理员提供正在开发的产品状态和质量信息。
报告在开始计划产品下一个版本时，提供初始改进建议。

60）任何产品/项目的相关人员都应该能够报告程序错误。

61）引用别人的错误报告时要小心。注意：一方面：如果没得到允许，可以补充评论，但不能编辑别人的材料，即使错误报告很糟糕也不要擅自修改因为很可能会遗漏重要信息的风险；另一方面，任何时候要在（特别是其他人的）错误报告做补充，都要注明自己的姓名和日期。

62）将质量作为错误报告。（质量对于个人来说就是价值。）测试员的任务就是帮助项目相关人员写出清晰的其对产品感到没价值的意见。

63）有些产品/项目相关人员不能报告程序错误，测试员就是他们的代理，所以应站在他们的立场理解要报告的内容。例如：测试员必须研究用户使用产品的方式，以及他们喜欢这种产品的什么，不喜欢什么。

64）将受到影响的项目相关人员的注意力转移到有争议的程序错误上。例如：如果测试员认为很难说服程序员改正错误，但是测试员希望改正，可以考虑公司中如果这个错误被改正能够受益的其他人。

65）决不要利用BUG管理系统监视程序员的表现。例如：使用该系统估算修改代码的时间，这样会使程序员感到为难外，其他程序员也就防备这个系统，最有可能的结果是，程序员争辩设计问题并不是程序错误，类似的错误是重复的等。

66）决不要利用BUG管理系统监视测试员的表现。例如：如果测试经理用BUG数作为考核依据，测试员也许会报告容易发现、更肤浅的BUG，也许更愿意报告同个BUG多个实例；他们会不愿意花时间指导其他测试员；程序员更有可能认为测试员是为了BUG数而不质量。

67）及时报告BUG。因为BUG报告拖延的时间越长，BUG被修复的可能性就越小；另一个风险是：项目其它相关人员就错误地以为已测功能点没BUG很稳定。

68）永远不要假设明显的BUG别人已提过。

69）测试员应报告设计错误。

70）极端的缺陷是潜在的安全漏洞。

71）使冷僻用例不冷僻。例如：极值测试思想：如果程序能够在这种条件下存活，那么在不那么极端的情况下也可以存活。因些可以通过少量极端测试了解很多东西。

72）小缺陷也值得报告和修改。Kaner和David Pels研究发现小缺陷（指修改BUG在4小时以内的BUG）修改可避免该产品一半以上的技术支持成本。

注意：任何产品都会残留一些小缺陷。但随着小缺陷数量增加，客户信心会下降，更糟糕的是容忍这些缺陷的腐蚀作用。当连报告小缺陷的行为都停止后，测试员和公司就会容忍越来越多的严重缺陷，长此以往，最终会使产品失败。

73）时刻明确严重等级和优先等级间的区别。严重等级：指BUG的影响或后果；优先等级：指什么时候要求修复。

74）失效是错误征兆，而不是错误本身。因此，任何时候看起来很小的错误，都要：执行后续测试，以发现更严重的征兆或以发现更一般的场景。当问题很难重现时，可执行后续测试，以确定使该问题重现的关键条件，然后执行后续测试，以充分暴露现在已可重现的问题。

75）针对看起来很小的代码错误执行后续测试。如果看到的是小失效，不要只是重现该失效并写入报告。程序处于脆弱状态，尝试利用这一点，继续测试，并可能发现内部缺陷的实际影响是糟糕得多的失效，例如系统崩溃或数据损坏。

对于每个认为反映了编码错误的失效至少要做几分钟的后续测试，要相信自己的判断。建议尝试如下三种后续测试：

a变化自己的行为。（通过改变操作方式改变条件）

b变化程序选项和设置。（通过改变被测试对象的条件）例如：使用不同的数据库，改变持久变量的取值等。

c变化软件和硬件环境。注意：这不是配置测试，不是要检查标准配置上的缺陷，而是要调查怎样变更配置才会使这个失效暴露充分。

76）永远都要报告不可重现的错误，这样的错误可能是时间炸弹。注意：不要报告还没尽力重现的程序错误，但如果尽力之后仍不能重现该程序错误，仍值得报告，不过要明确说明自己不能重现这个程序错误。

77）不可重现的程序错误是可重现的。如下是无法重现时需注意的关注点：

a程序错误可能有延迟效应，例如内存泄漏、指针越界。

b程序错误可能只是在安装、使用产品或使用产品的特定功能时出现一次。恢复干净系统，重新装载该程序，检查现在是否能够重现该问题。

c程序错误可能依赖于特定的数据取值或被破坏了的数据库。

d程序错误可能只在特定的时间或日期内发生。检查日末、周末、季度末、年末。

e缺陷可能依赖于以特定顺序执行一系列相关的任务。在执行这个失效任务前做了什么？

f程序错误可能是前面失效的残余。例如：上一次出现GPF后重新启动计算机了吗？

g程序错误可能是由被应用程序与后台运行的其他软件，或与被测试应用程序竞争设备访问软件的交互引起的。

78）注意缺陷报告的处理成本。

79）特别处理与工具或环境相关的程序错误。

80）在报告原型或早期个人版本的程序错误之前，要先征得同意。注意：在正式测试时，要把以前发现但仍没被修复的问题录入BUG管理系统。

81）重复错误报告是能够自我解决的问题。注意：

a不要让搜索时间失控。如果BUG数据库大，可能需花大量非生产时间搜索重复程序错误。

b编写良好的相同BUG的所有报告都包含新信息，有助于更容易修复BUG。

c两个报告是否重复还需再统一确认。两个失效可能是由同一个缺陷引起的，多个缺陷可能涉及到一个失效。要保留所收藏到的所有信息，直到确认统一并修复了该BUG。

82）每个程序错误都需要单独的报告。Pettichord另一种建议：

有时为了提高效率，可以在一份报告中包含多个相似的小BUG，假设这些BUG可以一次全解决。如果这个问题单状态标记为已修复后，仍有没修复的残余BUG，可以为这些没修复的BUG写一份新报告，并引用已修复的老问题单号。

83）BUG标题是错误报告中最重要的部分。建议包含的内容：

a简要描述，要足够具体，使读者能够想像出该失效。

b简要指出程序错误的局限性或依赖关系。例如：BUG产生的环境局限。

c简要指出程序错误的影响或后果。

84）不要夸大程序错误。记住，测试员的可信性是影响力的基础。

85）清楚地报告问题，但不要试图解决问题。

86）注意自己的语气及报告的格式。例如：全部采用大写字母，则读起来像是编写报告者在尖叫。

87）使自己的报告具有可读性，即使阅读对象是劳累和暴躁的人。要使重现步骤的描述简洁：

a一次只走查该程序错误一步。

b为每一步编号。

c不要跳过重现问题所需的任何步骤。

d尽量写出能重现的最少步骤。

e通过空行使报告更容易浏览。

f使用简短句子。

g说明实际发生了什么，自己预期会发生什么。

h如果后果很严重，可解释为什么自己认为很严重。

i便于程序员意识到问题或便于自己回归测试，可补充注释。

j对于复杂产品或问题，考虑使用描述的头三行专门小结问题，然后给出问题细节。

k要始终保持中立语气。

l不要开玩笑，别人会产生误解。

88）提高报告编写技能。研究BUG管理系统的BUG，找出提高报告编写技能的思路。例如：

a比较已修复的BUG和未修复的BUG，研究两都报告方式的差别。

b研究程序员对错误报告的反映。例如：什么使他们困惑不解、不能接受、能够接受？

89）如果合适，可使用市场开发或技术支持数据。例如：

a可与同行产品进行比较，有助于描述用户预期及有助于市场开发经理评估问题的严重等级。

b调查市场与客户接触时都遇到什么问题，他们如何说明产品，演示什么，怎么演示，在报告中使用调查结果。

c如果可能，将报告的BUG与相关的技术支持记录联系起来。可估计延迟修复BUG的技术支持成本或如果BUG留在产品中将会面临客户或技术支持人员的不满。

90）相互评审错误报告。例如：在提交给程序员前，要安排第二个测试员评审所有报告缺陷。第二个测试员要：

a检查是否清楚地提供了关键信息。

b检查是否可重现该BUG。

c研究该报告是否能够简化、概括或加强。

测试员可以评审：所有缺陷、自己发现的所有缺陷、同事发现的所有缺陷。如果发现报告有问题，可找报告提交人讨论该BUG。

注意：这是一种培训员工、提高报告质量的有用的方法，但注意不要过多地增加评审测试员的负担。评审过程需时间。

91）与将阅读错误报告的程序员见面。

92）最好的方法可能是向程序员演示所发现的BUG。

93）当程序员说问题已经解决时，要检查是否真的没问题了。

94）尽快回归已修复的BUG。

因为尽快回归已修复BUG，一方面，可表现出对程序员的尊重，也使程序员将来更有可能对测试员所报告的BUG迅速做出响应。另一方面，程序员可能仍然记得自己是怎么改的代码，并能够立即处理该问题。

95）如果回归不通过，应与程序员沟通，而不仅仅通过报告反馈信息。测试员与程序员沟通时，语气和态度应该友好、热心。测试员要帮助程序员立即得到信息，并准备随时澄清报告中的任何不清楚的地方，如果程序员想看，应准备随时演示该BUG。

96）错误报告应该由测试员关闭。一般情况下，报告该BUG的测试员应再次进行测试，但是如果程序错误是非测试员报告的，是应由最熟悉程序这部分的测试员进行评估，如果可能，该测试员也应该咨询原始报告者沟通。注意：除非经过测试员的评审和关闭，否则任何BUG都不能标识为已关闭。

97）不要坚持要求修改所有BUG，要量力而行。注意：如查不能举出某个BUG很重要，或产品/项目相关人员有充分支持测试员关于推迟特定BUG修复的请求，我们建议还是把该BUG放在一边，先考虑其它问题。

98）不要让延迟修复的BUG消失。建议：在项目一开始时评审延迟修复的BUG，因为此时进度压力最轻，而且项目经理也处于最清醒、最理智的状态。

99）测试的惰性不能成为BUG推迟修复的原因。

注意：如查测试经理要求程序员不要修复该BUG，而原因仅仅因为修复该问题会影响太多的检查单、脚本或其他测试用例，因此要占用太多的管理时间，那么说明测试过程存在致命缺陷。

100）对BUG延迟修复应立即上诉。

101）如果决定要上诉，就一定要赢。

注意：如果测试员确实要上诉，不要依赖自己最初错误报告中的语言和信息。如果测试员不列举出更有效的例子，则不仅是浪费自己的时间也损害自己的信誉。为了准备自己的上诉，测试员需提前做到如下几点：

a与其它产品项目相关人员沟通。找出如果BUG留在产品对其影响最大的人，确定该BUG会增加他们多少成本或给他们带来多大麻烦。

b补充做一些后续测试，寻找更严重的后果或寻找更广的环境下产生。

c创建一些场景，说明合理的用户在合理地使用该产品时也会遇到该问题。

d寻找一些讨论与所报告错误类似问题的报刊文章。如：同行交付类似问题的产品后带来的后果。

测试自动化：

如果自动化能促进测试使命的完成，就利用自动化。评估利用自动化是否成功的标准，是看它在多大程度上帮助测试员完成自己的使命。
测试自动化注意点：

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

b采用与设计手工测试不同的方法设计自动化测试。例如：自动化时需考虑考虑人所不能做的事。因为在设计手工测试时，测试员不太可能考虑如数千文件重复进行的测试，只因工作量太大。

总结为两点：

a没有好的测试设计的自动化可能会产生大量活动，但没什么价值。

b没很好理解自动化可能性的测试设计，可能会低估一些最有价值的自动化机会。

102）加快开发过程，而不是试图在测试上省钱。

即如果要得到支持，就要把精力集中到降低开发失效的风险上。例如：迅速找出新版本中不稳定的变更；尽快暴露回归结果；快速报告问题。

其中，支持加快开发节奏的手段有：自动化冒烟测试、自动化单元测试。

冒烟测试：这个词来自硬件测试。测试员插入一块新板子并接通电源。如果看到板子冒烟，立即切断电源。不必再做进一步的测试。冒烟测试又叫“版本确认测试”在有限的时间内，快速测试产品的功能。如果关键的功能不能正常运行或重要的BUG回归不通过，测试员就不再浪费时间安装或测试该版本。

103）拓展测试领域，不要不断重复相同的测试。注意：利用自动化拓展测试领域，使测试员能够看到更多、做到更多。
自动化测试可拓展如下的测试范围：负载测试、性能基准测试、配置测试、耐力测试、竞争条件、组合错误。

104）根据自己的背景选择自动化测试策略。自动化测试策略受测试需求、软件产品体系结构、测试人员技能。
测试需求：系统中往往只有少量的功能是关键的，且会被要求将其自动化；另一方面关注自动化能如何帮助控制产品的主要风险。
软件产品体系结构：分析产品体系结构以确定测试自动化的可能性。例如：主要软件组件是什么？这些组件如何通信？使用了什么技术？有哪些可用接触点？组件间的关系。即，语言、环境和组件都会影响测试工具的适用性。
测试人员技能：因为有些自动化测试方法适合没编写程序能力的测试员，有些则对编写程序能力要求较高。

105）不要强求100%自动化。

106）测试工具并不是策略。注意：工具不能教测试员如何测试，如果测试出问题，则测试工具会加重问题。在实现测试过程自动化前，应首先解决测试过程中的问题。

107）不要通过自动化测试使无序情况更严重。如果测试设计得很差，则自动化会使差的测试执行得更快；如果测试组织得很差，计算机并不会替人组织，且自动化测试会把人的注意力从真正需要做的工作移开。

108）不要把手工测试与自动化测试等同起来。
因为自动化测试只能执行测试员明确描述的测试，而不能利用测试员隐含的知识和认识。经过专业培训的人大脑是最好的测试工具，要超过何可能的自动化测试工具。

109）不要根据测试运行的频率来估计测试的价值。因为测试价值在于它所提供的信息，自动化测试的价值是成本和效益综合分析。注意：测试本身是不可比较的，因手工测试和自动测试不能提供相同类型的信息。

110）自动化的回归测试发现少部分程序错误。非正式调查显示，回归测试发现BUG数占总数的15%，而老功能的新测试一般能发现接近30%～80%的程序错误。

111）在自动化测试时考虑什么样的程序错误没有发现。在计算测试自动化的成本时，建议关注机会成本。考虑花在自动化的时间可用来做什么呢？现在没运行什么测试？没发现什么BUG？

112）差的自动化测试问题是没有人注意。例如：自动化测试包是以前创建的，现在仍用来测试该产品。此时需注意：该包可能并不能完成所想像的工作；测试可能已不再重要；覆盖率可能很差；虚警可能很常见；测试结果可能有错。

好的测试包是活的。要补充新测试，要修复或删除老测试。如果没出现这种情况，测试包就会开始僵化。不久开发人员就会转到其它工作上，测试包就会开始进入神话般的老橡树状态，即动画片中的那种给出建议的角色。慢慢地，因为它已存在很长时间，我们盲目相信创建了出色测试包的老测试员的智慧和编码的现象叫做老橡树综合症。

113）捕获回放失败。关键问题是，这种录制回放工具的脚本与用户界面和系统配置的微小细节捆绑得太紧，只要程序或设计一改，这些测试就不能再用了。所以我们建议：要在构建能够持久或与手工测试结合的自动化测试的技能和规划上投入，与录制回放相比，这两种测试更高效。但录制回放工具对学习工具很有用，并有助于手工编辑测试脚本，我们反对将录制回放单独做为解决方案。

114）测试工具也有程序错误。

115）用户界面变更。保持与用户界面设计变更同步，是GUI自动化测试的一个主要困难，如果要自动化GUI测试，需把这点考虑在内。另，我们要抽象测试自动化设计的界面。即当用户界面变更时，只需升级抽象层，而不是升级访问修改后界面的所有测试。以下是提供产品GUI抽象的一些手段：

a窗口映射：GUI测试工具支持各种手段来标识窗口控件。例如内容名称、各种属性、邻近标签和顺序位置。注意：不是将标识手段嵌入到对控件的所有引用中，而是使用窗口映射名称与该控件的标识手段关联。如果用户界面变更迫使变更具体手段，则只需更新窗口映射。

b数据驱动的自动化测试：使测试员变更测试过程后仍能使用之前所创建的测试数据。

c任务库：将测试用例分解为要素任务。每个任务在概念上都应该是不同的。要特别注意任务的起始和结束状态。为这些任务创建可以在测试脚本中使用的函数。如果任务的用户界面出现变化，只需更新任务而不用更新任务的测试。

d关键词驱动的自动化测试。

e基于API的自动化测试：完成避免GUI。

116）根据兼容性、熟悉程度和服务选择GUI测试工具。需考虑的因素，例如：确定团队已知的工具或已知的工具所使用的语言（因为工具使用培训和学习费用相当高）；提供商支持工具的能力；需花一段时间测试工具与产品的兼容性，并检查提供商的服务记录，要有一个试用期（30～90天），或至少30天的订金返还保证。

117）自动回归测试消亡。自动化回归测试不能使用的时间比期望的要早得多。很多自动化测试开发人员都发现，在诊断测试失效和修复退化测试方面所花的时间太多。所以失控的维护成本也许是自动回归测试要解决的最常见问题。

118）测试自动化是一种软件开发过程。测试自动化项目常由于缺乏约束和项目管理而失败。具体建议做到：规划项目，并建立里程碑和可音乐会制品，定义需求，对工具、自动化代码和测试进行源代码控制；在编写代码前先设计并对代码进行评审和测试；跟踪自动化程序的BUG；将自动化测试的使用写成文档并提供给非自动化开发人员使用。

119）测试自动化是一种重要投资。注意：不要把测试自动化的所有预算都投到测试工具上，那只是冰山一角。

120）测试自动化项目需要程序设计、测试和项目管理的技能。

121）通过试点验证可行性。例如：计划用一个月左右的时间显示结果，然后全面推广。

122）请测试员和程序员参与测试自动化项目。考虑关键域，确立清晰的目标并定义需求：

a可评审性：谁评审测试？做到这一点难度有多大？

b可维护性：谁将维护测试？他们必须了解什么？

c完整性：怎么知道测试被别人信任？

123）设计自动化测试以推动评审。

--124）在自动化测试设计上不要吝啬。

自动化测试设计需明确考虑的问题：

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

b描述预期结果。

c发现潜在的错误和副作用。

d从潜在测试失效中恢复。

e防止测试相互干扰。

125）避免在测试脚本中使用复杂逻辑。当需要复杂的逻辑控制时，可把逻辑放在单独的功能中，这样也可以单独测试该功能，也使测试更容易评审。注意：要使测试简单，使测试线性化。

126）不要只是为了避免重复编码而构建代码库。因为使用这种库的测试很难评审、调试、修改。有用的库应该遵循更强的设计原则，应关注封装用户可感知到的任务，特别注意函数的起始和结束状态。这种工作并不总能达到目的，如果出现这种情况，可采用“开放编码”方法。（即，保留重复代码不动）。

127）数据驱动的自动化测试更便于运行大量测试变种。这种方法对于有很多不同数据选项的产品工作流来说最有效。

--128）关键词驱动的自动化测试便于非程序员创建测试。

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

关键词驱动的自动化测试实行步骤：

a这种方法既要求支持运行测试，又支持设置库、结果分析和报告的一般框架。

b必须创建一个任务库，封装被测产品支持的用户任务。标识可在测试中使用的所有任务函数，对每个任务函数在任务库中都有一个记录与之对应。声明任务函数有效的起始状态，以及所产生的结束状态。这样可以分辨出哪个任务函数序列有效，以便捕获有问题的测试。

c增加对读取电子表格数据的支持，每次读入一行。通过声明把第一列解释为任务函数的名称，后续列是函数的参数。使用函数的参数执行该函数。然后指向下一行。

129）利用自动化手段生成测试输入。在以下情况有帮助，例如：

a创建大文件。

b创建大量测试输入。

c设置测试床。

d创建随机数据。

e覆盖所有输入组合。

f覆盖等价类的所有代表对偶。

g覆盖逻辑条件的交互。

h通过状态模型创建测试场景。

130）将测试生成与测试执行分开。例如：数据驱动的自动化测试。这种分离的优点：测试易于理解和评审；可使用不同的测试工具或程序设计环境生成和执行测试；如果预先生成数据，则更容易重复测试；不同的测试专业人员会各自关注自动化测试的不同方面。

131）使用标准脚本语言。例如：Perl、JavaScript、Python。测试员可使用它生成测试用例、访问编程接口、检验结果。注意：脚本语言是便于使用而不是用于提高执行性能的高级语言。建议避免使用提供商自己专用的脚本语言。

--132）利用编程接口自动化测试。公共API（指可用来实现测试的编程接口）和私用API（指没提供编程接口软件可能有不公开的接口）因更可能提供稳定性和利于检测和隔离，所以想要搞好测试自动化，就须学习或找了解这些编程接口的人帮忙。

133）鼓励开发单元测试包。测试员需一个像Junit这样的框架来管理测试包的执行，代码通过该语言所支持的一般调用接口测试。将单元测试用于回归测试、冒烟测试和配置测试。

134）小心使用不理解测试的自动化测试设计人员。注意：我们应该运用评审、设计策略和测试来防止开发设计的自动化程序错误。

135）避免使用不尊重测试的自动化测试设计人员。

136）可测试性往往是比自动化测试更好的投资。例如：安装软件后，用户需检查记录文件以查看是否安装有误。如何自动化这种测试？更好的思路是把这些作为软件的一个功能在产品内部实现。这样也许更可靠，实际上可直接使用户受益。还有一个例子：断言是代码中语句，如果结果为假则指示出现错误。断言放入被测软件，以检查结果是否合理，与编写外部代码检验结果相比，这种方法往往更容易、更高效。

137）可测试性是可视性和控制。可测试性如：访问源代码、日志、诊断、错误模拟、测试点、事件触发器、读入老的数据格式、测试接口、定制控件支持、允许多实例（即允许同一台计算机上运行多个客户端或代理）。

138）尽早启动测试自动化。原因：

a当测试已成型后，很难把资源转向自动化。

b当测试员和过程都集中于手工测试后，他们会抵触变更。

c设计完成后，程序员在可测试性要求方面会变得不那么合作。

注意：不要一开始就尝试自动化所有东西，迟早建立基础设施，但在选择要自动化哪些测试时要慎重。

139）为集中式测试自动化小组明确章程。注意：如果有这样的小组，要确保有明确的章程描述要提供的测试辅助类别；应如何提出请求；以及如何平衡相互矛盾的要求。建议要求接受帮助的测试小组指定专人参加测试自动化项目，优点：

a可以评估他们做出的承诺或所面临的实际问题。

b通过培训其员工，可减少后续维护和失效分析要求。c通过与该测试小组合作，可以从头至尾在项目中把他们的测试需求结合到工作中。

140）测试自动化要立即见效。应把关注点放在影响大、成本小的自动化任务。如下是可供参考的自动化切入点：

a系统设置与准备。

b辅助诊断：数据破坏和内存泄漏缺陷一般到该数据被访问或内存耗尽才会被检测出来，而构建这种检查内存工具也不困难。

c会话记录：严谨的错误报告要示提供完整的配置信息，程序可自动收集和报告必要的信息。

d测试生成：利用自动化手段生成测试输入。

141）测试员拥有的测试工具会比所意识到的多。因为有些测试工具并没贴上“测试工具”的标签。例如：内存监视器、宏工具等。

测试文档：

我们在使用IEEE标准829的结果并不乐观，问题在于标准829并不是满足公司需求的合适方法。

142）为了有效地应用解决方案，需要清楚地理解问题。

143）不要使用测试文档模板：除非可以脱离模板，否则模板就没有用。注意：测试文档模板不能替代技能。

为了使用模板编写好的测试文档，必须理解模板每一部分的含义，理解为什么要有这一部分，什么时候可删除。如果测试员对这些都能够理解，就不再需要模板了。如果不理解这些，就不要受模板的影响。由于测试员不理解模板作者对需求和权衡所做的全面考虑，模板就会使测试员生产率降低。使用模板的人必须能够根据自己当前具体需求剪裁模板。

144）使用测试文档模板：模板能够促进一致的沟通。

145）使用IEEE标准829作为测试文档。

146）不使用IEEE标准829。实践遇到使用该标准的问题如下：

a标准的前提假设看起来是瀑布方法，要在早期开发测试，仔细编写测试，以后就不再更改。

b大量的测试文档产生一种盲从心理。

该标准没提供测试文档的需求分析，即没有提供什么时候提供什么类型信息的建议或指南。

d没明显提到/讨论到提供所有这些信息的成本。

e强调文档的广度，好像越多越好。

f没提出判断测试文档特定实例好坏的准则。

g这样大量的文档维护成本是很高的。
h将每个测试都写入文档会严重影响自动化的测试等。

147）在决定要构建的产品前先分析需求，这一点既适用于软件也同样适用于文档。

148）为了分析测试文档需求，可采用类似以下给出的问题清单进行调查。

a测试小组的使命是什么，测试这个产品的目标是什么？

b自己的测试文档是产品还是工具？如果是产品，测试员可能要按照客户的要求遵循任何标准，反之则能在最低限度上有助于达到目标即可。

c软件质量是受法律问题驱动还是受市场驱动？

d设计变更有多频繁？如果变更频繁，则不要编写大量测试文档，可能不值得。

e反映设计变更的规格说明变更有多频繁？如果规格说明不完整或过时，则不能采用规格说明驱动的测试。如果不能得到好的规格说明，应计划修改测试策略，而不是修改项目团队政策。如果测试员要力争更好的规格说明，则应该以其它项目相关人员编写规格说明的成本和风险为基础。

f在测试时，是希望证明与规格说明一致，还是希望证明与客户预期不一致？

g要采用的测试风格更依赖于预先定义的测试，还是探索式测试？如果是前者，主要重用测试用例；如果是后者，则更需要战略和策略文档

h测试文档应该关注要测试什么（目标），还是应该关注怎么测试（过程）？

j文档应该控制测试项目吗？

k如果文档控制部分测试项目，那么是在项目的初期还是后期进行控制？

l测试文档要在多大程度上支持项目状态与测试进展的跟踪和报告。

m文档要在多大程序上支持向新测试员工指派工作。

n对新测试员的技能和知识做哪些假设？

o测试包应该提供预防、检测和预测收益。对于本项目来说，哪一种收益最重要?

p文档的可维护性有多高？多大程度上能够保证测试变更能够跟上代码变更？

q测试文档有助于标识程序风险模式的永久转移吗？

149）用简短的语句归纳出核心文档需求。如：

a测试文档集主要支持我们自己找出这个产品版本中的程序错误、指派工作和跟踪工作状态。

b测试文档集将支持当前产品开发和至少10年的测试维护，为新测试小组成员提供培训材料，并创建适合管理者或法庭检查使用的档案。

程序员交互

150）理解程序员怎样思考。例如：

a大多数程序员都很专一。形成对比，测试员常常是多面手。为了更好地测试，测试员必须理解程序的各个部分如何组合在一起，并必须能向程序员提供完整的系统信息。

b程序员关注自己的系统理论。程序员拥有系统组件如何关联，哪个组件是可靠的，以及错误如何传播的模型。他们说没问题时，是指这种错误与他们的模型不匹配，他们相信模型是没问题的。所以测试员要仔细记录，应明确说明实际看到了什么并让程序员根据他们自己的推断找出缺陷。

c程序设计是一种复杂活动。这耗费程序员很大精力，导致他们只想思想集中地关注他们认为最重要的东西，而对别人打扰感到不耐烦。

d程序员常常要与各种困难做斗争。

e很多程序员不喜欢例行工作，常常构建工具和脚本来自动化自己所面临的重复性工作。测试员不要把自动化测试当作赢得程序员尊重的一种方法。

151）获得程序员的信任。如果要与程序员打交道，应与其共享信息，这样测试工作会更有效。且能找出程序员需要什么样的反馈信息并为其提供。测试员如果与程序员有不同观点，可陈述自己的观点，但不要反复唠叨。

152）提供服务。主动直接为程序提供帮助。这样可以建立信任，并证明测试员是程序员应该与之合作的人。测试员能为之提供的服务：

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

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

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

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

153）测试员的正直和能力能被尊重。

报告问题时需注意：

a要干脆地报告问题。即，一步一步地将问题显现出来，没有多余的步骤。这样的工作会得到别人的尊重，因为测试员这样的表现出的是对程序员时间的尊重。

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

c如果失效是不可重现的，要展示为了重现失效所做的各种尝试。即展现对程序员时间的尊重，而不是一遇到困难就推给程序员。

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

e不要假装了解自己并不了解的东西。要么继续收集证据；要么不发表意见；要么明确表明自己是在猜测的。

f不要夸大错误报告。

g如果测试员是正直的，就可以展示自己的能力。

154）将关注点放在产品上，而不是人上。

155）程序员喜欢谈论自己的工作，应该问他们问题。一个很好的切入点是讨论程序员所使用的设计文档。先做点准备工作，浏览能够得到的所有文档。如果可能，还可以看看代码。如果没文档，可以向他们索要系统框图。

例如：当程序员在白板上画出系统框图时，测试员指着任意一个箭头或方框问：“如果不这样会发生什么？”这样会发现遗漏错误处理或无异议的假设。对两个或以上的程序员问这样的问题，会暴露出程序员间很有意思的观点差别。此时测试员应做好笔记，并与程序员、其它测试员共享信息，因为程序员不喜欢一遍又一遍地对不同测试员回答同样的问题。当测试员在积极地聆听时，应注意尝试帮助其他人说出必须说出的内容，询问能够启发补充信息或条件的问题，做出推论等。作为测试员，其工作就是考虑产品怎样才会失效。需要理解产品的价值所在，要让程序员知道自己理解他们的工作价值。

注意：在向程序员索取文档等信息时，要向程序员解释为什么需要这些信息，及这些信息对自己工作能带来怎样的帮助。因为程序员不知道测试员在想什么的。

156）程序员乐于通过可测试性提供帮助。测试员通过程序员得到可测试性功能时，需注意：

a用程序员的语言谈话。测试员必须以程序员能够理解的方式提出请求。例如：确切地描述自己想要在哪部分代码中提供什么样的接口，程序员会相当公正地听取这类意见。

b尽早提出要求。

c要现实。因为有些可测试性要求很小，可以与其他实现任务一起完成。有些可测试性要求需要新的功能，像其它所有功能一样，也有预算和进度计划问题。测试员还必须向管理层说明这些问题。
注意：提出可测试性要求很难，但是很值得。我们建议读者要有不屈不挠的精神。

管理测试项目：

管理测试项目与管理其它类型的项目基本一样，不过至少有一个特点：测试项目是受编程项目驱动的。测试员的工作是对程序员工作的反映。

157）建议一种服务文化。测试员的角色：
a向需要服务的人提供优质服务。即，服务提供者尽更大努力控制他所提供质量和相关性，以取得最终结果。
b服务提供都不控制最终产品的质量，不控制其它服务提供者（程序员、市场开发人员）所使用的过程，不批准或拒绝产品的发布。注：服务提供者不是项目经理，而是要向项目经理提供服务。

158）不要尝试建立一种控制文化。测试小组没资源、经验或行政力量来改正更广的开发过程，也不能管理被改正的过程。
注意：我们鼓励测试员扩展自己在公司中的作用和影响，但是要以合适的角色管理项目，即先当上项目经理的经理，因为测试经理并不是管理项目经理的角色。

159）要发挥耳目作用。测试员在公司中的权力建立在自己的调查技能和自如沟通的基础上，而不是建立在命令链上，因为测试员在项目团队的命令链中的位置并不很高。

建议：测试员要成为能够为项目其它人有价值的、守信用的、高度正直的信息提供者。以此来施展和扩大自己的影响力。

160）测试经理管理的是提供测试服务的子项目，而不是开发项目。项目经理在如何动作测试项目上有很大控制权，便测试经理要通过各种方式提出建议，要把自己的想法说出来。如果项目经理没采纳您的建议，那么接受现实。但如果项目经理做对测试员不恰当的批评或连续加班等超出项目经理合理的职权范围时，作为测试经理，自己工作的一个很重要部分就是要保护下属人员不被滥用。

161）所有项目都会演变。管理良好的项目能够很好地演变。在每个项目的整个过程中，测试经理一样准备（正常情况下）对整个计划的大小细化或更新。项目就是一组任务。项目团队要为集成新信息、确定下一步（可能）做什么、项目完成前的迭代工作提供某种框架。要把项目看作是有关下一步应该做什么的，及正在进行着的结构化对话。

162）总会有很晚的需求变更。用户不能确切描述自己需求的原因是：

a他们不知道自己的所有需求。

b当他们试用软件的早期版本或竞争对手产品后，其需求会发生变化。

c不同项目相关人员具有不同的需求，而这些需求常常是矛盾的。

Bach说过：需求是我们想要的和我们能够得到的功能间进行不断斗争的结果。
163）项目涉及功能、可靠性、时间和资金间的折衷。项目经理的任务就是：按时并在预算限度内交付一组合适的功能，达到合适水平的可靠性。

164）让项目经理选择项目生命周期。明智的项目经理会挑选能够流畅地控制自认为很难管理的方法，而预留出自己特别有能力解决的方面。

注意：生命周期选择相互间有很大不同，做出选择并不容易。

165）瀑布生命周期把可靠性与时间对立起来。瀑布模型下，要么修改错误而推迟交付时间；要么按时交付产品，但产品有较多错误。这也是项目经理和测试员间经典的争执。

注意：在瀑布模型中，总不可避免地会存在可靠性和时间之间的折衷考虑，所以使用该模型时需小心。

166）迭代生命周期把功能与时间对立起来。团队要在任何时候发布该产品（即发布通过测试的最新版本），所以新版本与旧版本的区别只是功能数量上的不同。

167）愿意在开发初期将资源分配给项目团队。测试员参加早期开发可以是有价值的活动。例如：

a评审需求文档的可理解性、可测试性、模糊性。

b可尽早分段对产品进行测试。不要等整个产品完成后才测。

c推动代码评审。

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

e要求提供可测试性功能。

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

g准备测试自动化。

h研究测试工具。

--i订购可用于被测软件的外部开的发测试包。更一般地，寻找可用于预测的软件，以便于进行大量测试。

j了解产品的市场和竞争情况。要成为该产品行家，至少要能熟悉使用两个同行产品。

168）合同驱动的开发不同于寻求市场的开发。

合同驱动的开发：开发公司的主要责任是根据合同完成自己的义务。随着产品的开发，客户可能会改变有关产品某些功能的想法。
寻求市场的开发：客户只在开发公司已经开发出产品后才会购买。所以在整个开发过程中，项目团队的主要考虑是所发布的产品是否能销售
目标市场。市场人员在整个开发过种中，都会根据所搜集到的客户、竞争对手和媒体期望的最新信息，而要求修改设计。
在合同驱动的项目中，测试员的主要活动是对照一组规格说明测试软件；在寻求市场的项目中，测试员更可能根据不同客户的预期，来研究和测试产品。

169）要求可测试性功能。

170）协商版本开发进度计划。内容包括测试小组接受软件的频度，对提交的被测试软件的要求，以及在旧版本中发现的程序错误如何在新版本中重现。

171）了解程序员在交付版本之前会做什么及不会做什么。要了解他们的开发过程（例如：是否有做单元测试）并根据自己对他们的了解来确定他们所做的事。

172）为被测试版本做好准备。当被测试版本就绪时测试环境也应该就绪，这一点很重要。所以管理良好的测试环境是很有价值的，特别是在快节奏的项目团队中。

173）有时测试员应该拒绝测试某个版本。拒绝理由如下：

a由于这个版本应加入某个关键功能，测试员发现没加或马上失效。

b以前正常关键功能现在不能正常使用。测试小组的冒烟测试应发现这种失效。

c如果收到一个版本，并已知另一个版本在几个小时后将完成，并且不会以任何方式受这个版本发现的问题产生影响时，取决于检验和安装一个版本的成本，可能需要忽略该版本，直接等待下个版本同时继续测试老版本。

174）使用冒烟测试检验版本。

一般，在冒烟测试中包含一系列标准的核心测试，以有少量对这个版本特别重要的BUG回归测试或特别功能的功能测试。注意冒烟测试过程是公开的。

175）有时正确的决策是停止测试，暂停改错，并重新设计软件。例如：如果不管进行了多少次程序错误的修复，在同一位置总发现问题，或不管对用户界面做了多少小修改，仍存在使用户困惑的问题，也许应该停止测试并对有关代码进行调试，这部分内容也可能需要重新设计或重写。

测试要向项目经理提供服务，包括好的建议。测试经理可私下单独向项目经理进行这种说明或建议，并且要认识到有可能不能说服项目经理采取自己所推荐的行动。

176）根据实际使用的开发实践调整自己的测试过程。

177）项目文档是一种有趣的幻想：有用，但永远不足。有人估计，在现代软件项目中，超过80%的代码用于实现错误处理，实现主要控制流的代码不足20%，但即使完整的规格说明也只会用20%的篇幅描述错误处理。这意味着805的代码是程序员边编码边设计的。

注意：在使用规格说明时应要求提供特定补充信息以弥补这种差距。不要根据文档完备、一致或准确的假设设计测试或规划项目。

178）测试员除非要用规格说明书，否则不要索要。要保证项目经理和编写该文档的人员知道测试员要使用，并知道将如何使用，否则以后他们不会向测试员提供会给他们带来不便的任何材料。

179）充分利用其他信息源。例如：

用户手册草稿、产品市场开发文献、市场人员向管理层做的推销产品概念的演讲、程序每个新的内部版本附带的软件变更备忘录、内部备忘录、已出版的风格指南和用户界面标准、第三方产品兼容性测试包、已出版的规定、错误报告、程序逆向工程的结果、与项目相关人员（如：客服、项目经理、开发小组、领域专家等）面谈、所使用的所有第三方工具的规格说明和问题清单、原型以及针对原型的所有实验室记录、前一个版本的客户电话记录（在用户现场发现了什么问题）、针对本公司产品的问题及所使用环境或平台上的常见问题、与同行产品进行确切比较、参考描述常见错误的BUGnet和其它类似网站。

180）向项目经理指出配置管理问题。如果项目在修复问题时引入新问题或使用已修复的问题又reopen的机率很大时，需向项目经理讨论这个问题，并要求提出解决意见，不管原因是配置管理的问题还是不切实际的进度计划导致错误修复草率。如果问题还得不到解决，在状态报告中要说明需要高级别的回归测试。在一定程序上，这像是公司的一个递归问题，需要增加未来项目的预算，以便实现大量自动回归测试。

181）程序员就像龙卷风。把他们看作是一种自然力量。程序员会按照自己的方式做，而不同公司中程序员的工作方式也有很大不同，测试经理应该相应地设计自己的实践。

注意：把测试方法建立在公司内部编程小组不会实施的实践基础上，是没有意义的。

182）好的测试计划便于后期变更。建议如下：

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

b不要编写维护成本很高的大量测试文档，例如：详细手工测试脚本。应使自己的文档尽可能简洁。

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

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

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

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

g慎重使用极限编程法开发自动化的测试。我们建议构建一种整体体系结构并设计一系列自动化测试，然后反复设计和交付代码。所采用方法的优先顺序是：最小化测试项目风险、结对编程、与项目相关人员密切合作以确定下一步应该做什么。

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

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

注意：当软件出现后期变更时，测试经理要分析自己的测试实践和环境条件，以确定会有哪些成本支出和效率降低，然后寻找变更自己测试过程的途径，以降低成本或把成本分摊到整个开发周期中，而不是集中到项目后期。

183）只要交付工作产品，就会出现测试机会。只要工作产品已能够测试，都要尽快测试。

184）做多少测试才算够？这方面还没有通用的计算公式。对的测试不确定性比错的测试确定性要好，关于多少测试算够的好的决策，必须依靠自己的技能和判断，不要费心寻找计算公式，还是多开动脑筋。

185）“足够测试”意味着“有足够的信息可供客户做好决策”。

判断测试是否足够好（即，存在未发现重要问题的机会足够少），有多种因素：

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

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

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

e测试策略具有合理的多样化。

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

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

h测试员能清晰地描述测试策略、测试结果、质量评估。

如果已做到以上几点仍在交付时存在大问题，可能原因如下：

a测试员不想按照自己想像的那样子了解风险的动态。现在知道得深入一些。

b测试员在测试中出现错误。下一次会做得好一些。

c测试员的风险评估是正确的。但管理层决定冒风险，并造成损失。

186）不要只为两轮测试做出预算。因为往往产品测试不得不进行的次数比两次要多得多。

187）为一组任务确定进度计划，估计每个任务所需的时间。测试员的工作由大量任务构成，列出的任务清单中，有些只能进行一般描述，有些任务可分解得相当细。例如：对需要一天以上时间完成的任务单独列出一项。估计每个任务会占用的时间，然后累加起来，再加上25%的会议、培训和其他非项目工作，并以此估计所需的总时间。

其它估算方法如下：

a用以前类似项目所需时间估算这次所需时间。

b使用当前公司将程序长度和复杂度与测试时间关联起来的数据为基础的模型，则使用这种模型导出估计值。

c如果了解与这个项目有关的风险，则估计针对这种风险测试需要什么，最终估计出整个产品的测试任务。

d其他因素也会影响测试员的估算。例如：程序员擅长这种应用程序开发，则他们的代码可能需要较少的测试。

188）承担工作的人应该告诉测试经理完成该任务需要多长时间。如果测试员的估算比测试经理的估算长得多，先不要试图让测试员改变估算，而是尽力理解测试员对任务范围的看法，测试员还做了什么，以及还有什么因素使测试员得到看起来很高的估算。

建议：由在估算有误时要承担责任的人进行估算（因此有得到最好估算的动力）。

189）在测试员与开发人员间没正确的比例。原因：

a统计谁、什么时候开始统计、在将测试与其他工作比较时统计什么任务这些问题上，各个公司之间是有差别的。这使得不能在公司之间做这种比例的假设。

b这种比例关注的是自身，而不是所完成的工作。例如：假设在项目中，程序员花了16个人月，测试员花24个人月，即比例24：16是精确的，但没意义。改变新代码与第三方代码的代码比例，改变重用以前项目的代码量，改变对错误报告中错误定位的要求等其它很多可变的因素，都会使上一个项目的比例不适合当前项目。

注意：并不是不能讨论比例问题，而是要讨论必须做什么工作，以及每项工作需多少人完成。

190）调整任务、不能胜任的人员。不同的测试员都有不同的强项，要鼓励测试员承担风险并扩展自己的能力，测试经理要尽可能提供指导，但是要关注测试员的进步。不要让测试员承担不适合的工作。

191）轮换测试员的测试对象。当一个测试员开始对被测试对象的质量有信心时，可把他调离当前项目，所指派新测试员很有可能会发现前一个测试员没想过的缺陷。

192）尽量结对测试。优点：

a当一个测试员必须向另一个测试员说明自己的思想时，简单的说明过程看起来能够把思想更好地集中，并很自然地启发更多的思想。

b有助于两个测试员始终关注任务，更容易重现和分析程序错误，并使一个测试员进行工作，而另一个测试员应付中间插入的情况，或离开主任务以抓住所需的东西。即其它人用小问题打扰他们的可能性更小。

c结对测试与单独测试的效率至少一样。结对测试可以在更短的时间内完成更多的工作。

建议：在开始测试前，每组结对测试的成员要先有个约定，大概花5～10分钟时间考虑接下来的一两个小时的工作方向。例如：可以关注要调查的风险、要测试的功能、或使用的工具。这只是一个总体指南。在进行一段时间后，应检查一下约定，以确定下一步该做什么。

193）为项目指派一位问题查找高手。问题查找高手是经验丰富、热心探索的测试员。使用“问题查找高手”的方式如下：

a对有怀疑的部分进行初步探索式测试，形成更细致的想法，接着让经验不足的测试员执行。

b探索被认为是风险很低的部分，--问题查找高手能够快速找到导致重新评估风险的程序错误吗？

c定位看起来很容易引起不可重现问题的关键部分。

d找出关键程序错误，以说服项目经理推迟（不成熟的）发布日期。

194）确定测试的阶段计划，特别是探索式测试的阶段计划。

阶段计划：测试员清楚地知道自己在接下来的60～90分钟内要做什么。这种方法有助于测试员集中注意力，但并不锁定在这种计划上，如果发现值得怀疑的现象或有了很好的想法，测试员可随时按新思路进行；如果没明显更有吸引力或更大压力的事情，则应该回到原定的计划上来。

195）分阶段测试。一个阶段是一个不受干扰的时间块，长度为60～90分钟。在一个阶段中，测试员要进行专题测试，测试经理应保护这个阶段的完整性——可在测试员的隔板外挂上所有人（包括测试经理本人），都应该尊重的“请勿打扰”牌子，除非有严重问题需要紧急解决。

196）通过活动日志来反映对测试员工作的干扰。

197）定期的状态报告，是一个强有力的工具。测试小组的真正力量来自沟通，不是监管。状态报告是传递自己信息的很有用的工具，编写状态报告时需注意：

a永远使用中性、客观的语气，不要使用感叹号、全大写词汇或幽默。

b不要针对具体的某人。注意：对事不对人。

c采用所有项目都一致的格式。

d按照标准进度计划提交报告。对所有项目都要采用一样的报告频率。例如：项目早期，状态报告的频度可以是每两周一次，以后后是每周一次，项目接近结束时是每天一次。

e仔细地选定状态报告的内容。状态报告要简练，要在几页纸中包含大量信息。

f要把状态报告提交给项目相关人员及项目团队之外的人。---这一点要慎重考虑，要视公司文化氛围及责任而定。

198）再也没有比副总裁掌握统计数据更危险的了。在报告状态（度量）时，应知道自己在统计什么数据及这些数据给谁看。测试经理应清楚度量的条件背景，有效地利用它。谨慎地给不知道条件背景的高层经理提供数据，可预测会带来的误解并直接提出问题，并拒绝提供某些数据。例如：

a不要跑到高层经理的办公室，抱怨某个程序员修复BUG的时间远远大于平均水平。如果测试经理主动提供了根据BUG管理系统得出的个人表现数据，以后会被要求大量提供这种信息。

b如果提供的信息中提到“到交付至少需要5周”，因为还有200个BUG未修复，而开发修复BUG的速度是40个/周。此时应在数学旁加上注释。因为其它项目因素比BUG数量对确定交付时间的影响更大。

c当被要求提供个人统计数据（例如：每个测试员发现的BUG数）时，可拒绝并向其解释，这种做法带的反效应。

199）要小心通过程序错误数度量项目进展。BUG数是一种试题项目进展的不错参数，但BUG数是不充分的，并常常产生误导。
BUG数可以用来说明项目离发布时期还很远；但BUG数不能用来说明产品已经接近发布时所要求的质量。因为如果到了项目的最后阶段，未解决的BUG数已经降低到接近要求的水平，这意味着产品更稳定，还是测试小组花了太多时间编写错误报告、运行回归测试（导致很少发现新的BUG），以及不直接导致发现新BUG的其它活动等。这些仅从BUG数中不能得到这些问题的答案。

--200）使用的覆盖率度量越独立，了解的信息越多。

覆盖率试题涉及给定类型可能的测试总集合、计划运行的测试集合、实际运行的测试集体。可以把已执行的测试数与计划执行的测试数的比值作为覆盖率度量，也可以把已经执行的测试数与有意义的测试总数的比值做为覆盖率试题。两种比值都很有用。覆盖率度量都只限于一类因素，不管是所执行的代码行、配置、经典风险等。所以每类可能的失效都会对应一种因素。

201）利用综合计分牌需考虑多个因素的状态报告。综合计分牌常常用于度量企业是否健康发展。多个不同的数字看起来可以比较好地说明企业的状态，但任何一个数字孤立地看都很容易产生严重的副作用。项目进展度量也应涉及多个不同的因素。例如：

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

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

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

d我对测试质量有多大把握。（例如：如果beta测试员发现很明显的问题，那么对质量的把握就比较低。）

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

202）以下是周状态报告的推荐结构。

可以把状态报告看作四页长的文档。

第一页列出关键问题，例如：所需的决策（例如：应该如何确定这些功能的优先级？测试什么设备？是否吸收新测试小组成员？）；所需的程序错误修改（对测试工作产生影响的所有程序错误，都应该优先解决。）；预期的交付件以及承诺的交付日期（在截止日期之前一点就要把这些交付件列在清单上，过期没交付的交付件要留在清单上，删除已提交的交付件，这种清单是表示遗漏的东西而不是累积工作表，应突出阻碍工作进展的因素）；意外问题（例如：某种关键工具没预想那么好用，员工跳槽等）。

第二页描述测试小组完成计划任务进展的情况。例如：不同测试工作进度计划，每项测试工作的预算，每项测试任务的完成情况，每项测试工作使用的时间。

第三页提供错误报告统计数字。

第四页列出本周推迟修复的BUG。清单可以只包括BUG数、总计（或标题）行，及测试员为该BUG划定的严重程度。需要更多的信息，读者可进一步查找。

203）项目进展表是另一种展示状态的有用方法。进展表是一种图表，画在会议室的白板上，向项目团队所有成员和与该项目有关的任何人公开。典型的进展表会列出多个工作区，每个工作区对应一行。对于每个工作区，白板显示当前工作量水平、计划覆盖率、已达到的覆盖率、测试员对质量评估（分为高、中、低）、测试员能够补充一些关键注释，以便进行评估。
典型的进展表每周更新一次（在项目初期），当项目接近尾声时，可增至每天1～2次。进展表提供的信息要足够新，使经过的经理也希望看一看。

204）如果里程碑定义得很好，里程碑报告很有用。如果公司要在每个里程碑处评估产品，那么测试经理需要知道应对照什么进行评估。公司怎样定义里程碑？产品需要与里程碑定义中的哪些方面进行比较？如果没有可用的里程碑，建议把里程碑看作是一个项目迭代的完成，需明确这个迭代退出的准则是什么？可下一个迭代进入的准则是什么？

205）不要签署批准产品的发布。要让项目经理或项目团队确定什么时候发布产品。测试经理的工作是使项目经理能够得到可以做出这种决策的最好的数据。

206）不要签字承认产品经过测试达到测试经理的满意程度。如果有人坚持要测试经理签署产品发布表，需声明自己的签字只说明产品已经过充分测试，已完成了约定程度的测试，或测试小组在可用的时间内尽力做了最好的测试。

207）如果测试经理要编写产品发布报告，应描述测试工作和结果，而不是自己对产品的看法。测试小组对产品的整体质量或产品对目标市场的适合性做出评估是非常困难的。因为测试经理并没有相关的数据，他只掌握错误报告和测试覆盖点。

注意：测试经理应只描述自己所知道的东西。

208）在产品最终发布报告中列出没有修复的程序错误。如果测试经理准备（或帮助准备）产品最终发布报告，应该附上没修复的BUG清单。还应在清单中列出认为重要而被拒绝的设计问题。这份清单应事先传阅，以免大家在最终报告才看到这份清单而感到意外。

209）有用的发布报告应列出批评都可能指出的10个最糟糕的问题。

测试小组的管理：

210）平庸是一种保守期望。如果认为在自己的公司内不会出现英雄，就不会得到英雄。

211）要把自己的员工当作执行经理。执行经理就是管理自己的时间以及影响机构发挥作用的人。

其实大多数脑力劳动者（例如测试员）都是执行经理，人们交给执行经理的工作量，总是比其所能够完成的要多。有效的执行经理会挑出自己能够完成好的那一部分任务子集，并完全不考虑其他任务；低效的执行经理总是试图做所有的事，总是不成功，特别是不能取得自己所努力争取的结果。

我们对待测试员不要像对工厂工人那样发号施令，管理测试小组时要录用具有不同经历和背景的员工，且要更多关注新测试员。我们的目标是产生执行经理，并从一开始就要表现出对其学习、思考的尊重；我们期望他们能够迅速担起责任，表现出工作热情，建立自己的信誉，发展自己的技能。

212）阅读自己员工完成的错误报告。这样有助于测试经理了解产品情况、自己员工的强项和品德及影响自己员工的沟通和人际问题。针对员工的错误报告，可以用如下提问来评估员工的工作质量：

a这些报告写得好吗？

b报告直率地提出了问题吗？

--c报告留下迫切要求后续测试的漏洞了吗？

d发现程序错误的测试看起来是例行公事还是很有见地？

e程序错误很难发现吗？程序错误出现在应用程序一般比稳定的部分吗？如果是，这反映出测试员的坚韧性还是好运气？

f报告的语气怎么样？

g程序员能理解报告吗？程序员对报告有什么反馈意见？这反映出程序员和测试良好的协作？还是相互指责？

213）像评估执行经理那样评估测试员。

注意：BUG数顶多就是测试员工作有效性的没价值的度量，它会使测试经理产生误导。我们建议评价员工工作时可以通过：阅读错误报告；阅读其编写的代码；阅读其编写的测试文档；收集与其一起工作的程序员及其它相关人员的意见。需考虑如下因素：

a他卷入了什么争端，为什么？

b在按期完成任务方面做得怎么样？

c在信守自己的诺言方面做得怎么样？

d他遗漏了什么类型的问题？

e他对其他测试员或程序员提供了什么类型的帮助，以提高他们的工作效率？

f他在学习新技能吗？他在把自己的技能传授给其他测试员方面做得怎么样？

g他站在公司的立场上处理过什么问题？这些在其对公司业务的判断和个人道德上是如何体现的？

另，测试经理可把员工的自我评估当作正式评估的一部分参考依据，但不能太过依赖自我评估。且正式评估的频度不能太低：每半年或一年进行一次。

214）如果测试经理确实想知道实际情况，可与员工一起测试。

测试经理参加项目团队可能并不实际，但可对自己的时间划分优先级，可仔细考虑至少积极地参加一个项目团队的可能性，这项工作很重要，值得给出较高优先级。

因为如果测试经理不参加项目团队的测试工作，一段时间后可能就会丧失自己的很多技术能力，就不能看到测试员正在处理的真正问题，且很难评估测试员工作的质量。

215）不要指望别人能够高效处理多个项目。注意：

a有些人会接受多项任务，但在特定的一周（一个月）内，他们只能承担其中一项，而其它任务会被抛在一边。

b积极地承担所有任务的测试员会把时间分得太碎，要在管理方面花很多时间。最终测试经理使某个测试员参与多个项目，参加很多会议，花大量时间了解各个项目，而对任何一个项目所做的实际测试都很少。

216）积累自己员工的专业领域知识。领域知识包括：用户如何使用类似的产品、什么俗人问题对他们很重要、同行如何解决这些问题等

通过如下途径可积累真正的专业领域知识：

a阅读面向类似产品客户的杂志和书籍。

b参加客户如何使用类似产品的培训。

c参加与产品的下层主题有关的培训。

d在客户现场工作。

e推销自己公司的产品或同行的产品。利用周六日到零售商推销软件，掌握了产品市场的很多信息。

f每周利用几个小时解答公司技术支持需处理的热线电话。

217）积累自己员工相关技术方面的专门知识。

218）积极提高技能。对于强化测试小组在公司中的价值极有帮助。

219）浏览技术支持日志。为了理解软件安装后正常运行时出现的问题，应阅读公司的客户投诉记录，思考为了使某类投诉减少自己可以做些什么；如果有这样的问题，思考什么类型的测试会有助于发现被测软件中类似的一般问题。

220）帮助新测试员获得成功。实施步骤如下：

a为新测试员找好地方，并在他上班前安排好（例如：提供计算机等硬件软件及必要的公司项目文档）。

b至少要安排一天的时间让新测试员与有关人员见面，带他参观公司部门，向他介绍将在一起工作的每一个同事，通过面谈了解他的希望和预期。

c为新测试员指派一位指导者。指导者要带新测试员各处参观，并回答各种问题，检查新测试员所完成的工作并提出建议，午餐请几次客，这些都很有帮助。注意：指导者并不是新测试员的上级，并不向测试经理报告有关新测试员的任何事，除非是很重要的问题。

221）让新测试员对照软件核对文档。即，新测试员运行软件核对用户手册或在线帮助，这样能让他了解程序的所有部分。

222）通过正面测试使新测试员熟悉产品。当新测试员核对完用户文档，已理解产品应该提供什么功能后，应尝试以简单且实际的方式使用该产品，并列出使用类似的产品有可能做的事然后使用被测试产品，尝试简单地照样做。

223）让初次接触测试的员工在编写新错误报告前，先改写老的错误报告。

224）让新测试员在测试新程序前，先重新测试老的程序错误。例如：重现仍未关闭的BUG；重新测试已解决的BUG；重新测试已解决但还没关闭的程序错误。

225）不要派测试新手参加几乎完成的项目。因为要花费大量时间编写详细的测试步骤等文档供测试新手使用，且测试新手使用这些文档会遗漏大量程序错误。

226）员工的士气是一种重要资产。Napoleon指出“三分士气一分体力”。如何营造提升员工士气的氛围，具体如下：

a礼貌地对待员工，尊重员工。

b关注他们的工作。

c称赞好的工作、热心和诚实努力。

d如果员工加班，测试经理也要加班。不一定要每晚，不一定每个周末，但要足够经常，使得员工可以感到测试经理在观察他们加班的情况。

e如果可能，为员工指派他们感兴趣的任务和项目。鼓励他们说出自己的兴趣，并给予考虑。

f如果测试员任务完成得不顺利，可指派别人给予帮助、指导，如果有必要还可以考虑替换。

g提供培训机会。表现出测试经理很看重技能和专业背景。

h测试经理要公平对待员工，并要求别人也公平对待他们。

j不要对任何一位员工产生误导。如果测试经理不知道问题答案，就实话实说。

k不要对员工叫喊，不要利用自己的权力强制要别人接受自己的观点。

l避免公开批评员工，但必须在私下指出其错误和问题。

m不要与员工私下议论其他小组内的员工。

n测试经理不要与员工约会。并在接受员工个人提供的方便或礼物时应特别小心，即使是小礼物。给的东西往往要多于接受的东西。

227）测试经理不要让自己被滥用。注意：

a不要做自己做不了的事。很多经理不管员工已多努力工作，都按惯例试图为每位员工再增加10%～20%的工作。测试经理对于自己做不到的，不要陷入责任圈套，不要为了过度工作而搞垮自己和整个团队。

b软件开发并不总是朝九晚五的工作。有时项目经理需要测试经理帮助时，如果测试经理能提供帮助，一定要想方设法尽量提供。但测试经理应该支持自己的小组，要选择自己的节奏，并做出自己的承诺。记住此时测试经理是志愿者，而不是牺牲者。

c测试经理不要承诺不可能做到的事，在这样的事上不必说谎，更不必掩盖问题。事实上，测试员工作的本质就是暴露问题，而不是将其掩盖起来。不必，也永远不应该在诚实上让步。测试经理的力量来自于向需要了解真相的人说明真相，如果在诚实上让步，就会使自己力量的一个核心支柱弱化。

228）不要随意让员工加班。长期加班会使员工体力透支、跳槽率升高、不信任别人、关系复杂、低效、工作草率，所以强烈建议测试经理要避免让测试员长期加班。

如下措施，可避免让测试员长期加班：

a在制定项目进度计划时，不要指望员工能够每天都8个小时集中在工作上。如果幸运的话，测试员可每天有6个小时专心办公室工作，其余时间用于完成其他必须做的工作（例如：参加会议、培训、填写人力资源要求的表格等）。

b不要同意自己知道的不现实的进度计划，要尽可能准确估算完成不同任务需要多少时间。面对比自己估算时间短的进度计划时，应该问清楚首先要完成哪些任务，哪些任务在时间有剩余时才完成。如果项目经理坚持要求完成所有工作，则要问题清楚哪些任务可以完成得不那么全面，并要求提供更多人手。面对不听别人说明理由的项目经理，测试经理要明智地管理好自己的员工，否则会失去他们。

项目经理奖励加班的人，认为加班得多的人完成的工作更多、更好。测试经理的挑战是找出一种方法，使更有效率的员工的工作效果能够展现出来。

229）不要让员工被滥用。

一方面，如果别人不善待测试员，也许测试经理该给员工做一些规定，为员工提供精神支持，并解决各种不公正待遇。另一方面，如果测试员说出不恰当的话或做出不恰当的事时，管理上应礼貌地处理表现不当的测试员，私下向测试员明确说明这样的表现是不能接受的。

230）创造培训机会。例如：

a成立阅读小组。每周一次或每月两次。目标是阅读一篇论文或专著中的章节并进行讨论（测试员讨论，测试经理参加但不要说很多话），这样的活动要体现自愿原则，所有人都不是被迫参加的。但要寻找某种方法奖励经常参加活动并积极发言的人。

b召开午餐培训会议。每周一次或每月两次。有时测试经理要讲话；有时邀请其它公司的测试经理或领域专家演讲；有时某位员工可以介绍一种技术可测试某个功能时所遇到的挑战。

c如果公司统一安排培训，可搞清楚当地大学提供什么相关课程，有什么更好的与软件有关的在线课程。测试经理不要告诉别人该选什么课，但要指出自己认为教得较好并与公司当前项目相关的，或对员工职业发展有益的课程。一般派出两人或三人参加课程和会议，以便能讨论所学到的内容，回来后，要向测试小组报告所学的内容。

231）录用决策是最重要的决策。

--232）在招募期间利用承包人争取回旋余地。

233）谨慎把其他小组拒绝的人吸收到测试小组中。因为更多的人头数会影响下一次请求批准新员工的录用，周围的人也会认为测试小组的能力应与员工人数成比例增加，测试员增加会招来新工作，如果有了新工作，而新的测试员又不能承担，只会增加小组其他人的工作负担。

234）对测试小组需要承担的任务，以及完成这些任务所需的技能做出规划。

235）测试团队成员要有不同背景。

236）录用其他渠道的应聘者。在非传统场合寻找测试员，尤其是在人力市场很紧张的时期。例如：律师和会计他们有很强的分析技能；刚当上母亲的高级程序员或项目经理需要放慢其工作节奏等。

237）根据大家意见决定录用。让测试小组中的任何全职员工及与测试小组工作关系密切的任何人测试候选人面谈。所有参加面谈的人都可以否决候选人，测试经理应细心、投入地倾听员工所描述的观点，并尊重员工的否决决定，除非员工的否决有歧视问题。

238）录用热爱自己工作的人。谨慎录用对其过去的工作不满的人。

239）录用正直的人。测试人员的价格会影响客户的信任程度。

240）在面试时，让应聘者展示雇佣者所期望有的技能。通过应聘者询问的问题、所进行的查询以及把各部分信息综合为整体方法的方式，对其做出判断。

241）在面谈时，请应聘通过非正式能力测验展示其在工作中能够运用的技能。有些测试小组确实通过逻辑或数字脑筋急转弯迷题，来实行某种非正式的能力测验。我们并不反对这样做，不过我们认为这样做并不像有些人想像的那样能够说明问题，因为对于逻辑和数字脑筋急转弯迷题，通过做大量实际练习会提高其更好地解答脑筋急转弯迷题。

242）在录用时，要求应聘者提供工作样本。例如：自己编写的代码样本、起草的错误报告、论文或报告。永远不要要求提供机密材料，并保证应聘者提供的材料是非保密。

243）一旦拿定主意就迅速录用。

244）要将录用承诺形成文字，并遵守诺言。永远不要承诺超出自己职权的事，例如：职业发展或提升等。

软件测试职业发展

245）确定职业发展方向并不懈努力。测试方面职业发展的两个一般方向是：技术和管理。

技术方向的测试包括：自动化测试结构分析员、自动化测试程序员、性能和可伸缩测试员、系统分析员、用户界面和人员因素分析员和鉴定员、测试计划设计员、专题测试专家、黑盒测试员。

测试员通过学习范围相当宽的测试技术，并用领域知识加以补充，会使自己对当前雇主的价值得到提高，这样的测试员可以要求明显更高的工资。一条很实用的指导原则是，确定雇主（或行业）最需要的技能，并努力掌握这种技能。

管理方向的测试包括：测试小组组长、测试经理、测试主任或质量主任、内部顾问、外部顾问。

与程序员相比，测试员对产品有更广、一般来说更浅的认识，并往往对整个产品有兴趣、有影响力。结果很多熟练的测试负责人得到培训并调到其他管理岗位机会：程序设计经理或项目经理、技术支持经理、产品经理、文档编写小组经理、销售支持经理。

测试员的另一个发展方向是过程管理人员，包括：软件指标专门人员、软件过程改进专门人员。建议在向过程管理方向发展时应该小心，因为这些岗位没直接捆绑到任何产品的开发和收益上，可能更容易受到裁员的影响。

246）测试员的收入可以超过程序员的收入。具有专门技术特长的测试员比具有管理技能的测试员更受重视，而管理技能的测试员比黑盒测试员更受重视。

247）可大胆改变职业发展方向并追求其他目标。例如：如果想转型为程序设计员，在逐渐掌握了有关程序设计语言的基本技能之后，可向程序设计小组提出用自己业余时间承担一部分工作。

248）不管选择走哪条路、都要积极追求。
职业发展方向是自己的事。应认真考虑自己的职业发展方向问题，搞清楚自己需要什么，自己对什么感兴趣，这会使自己更有价值。

249）超出软件测试拓展自己的职业发展方向。

花大量时间寻找并批评其他人的错误会变得俗套，尝试做一些其他工作，掌握一些软件开发的其他技能，这会使自己见识更广、更灵活、更适合就业市场的需要、对项目团队所面临的挑战和约束会更有见地。与只承担过一项任务的经理相比，能够发挥多种作用的经理常常难获得更高报酬。

250）跨越公司拓展自己的职业发展方向。职业发展方向是自己的事，即使公司明天出现问题，自己的职业发展方向仍然还是原来的方向。软件测试员群体很大，我们可以通过不同的方式参加这个群体。例如：出席软件测试或软件开发会议、参加当地的计算机学会、美国质量学会等。

251）参加会议是为了讨论。

a参加有关软件测试或软件开发的会议时，不要只是坐在分组讨论会场中听别人发言，应该参加很多分组讨论，但还要花很多时间与参加会议的其他人见面，讨论所做的发言或本领域中的一些问题。

b如果不认识很多与会人员，午餐时，与不认识的人坐在一起，听其谈话，寻找有兴趣且有见地的人。

c在与这些人见面时，询问他们的工作内容，了解他们在会上所讨论的内容。他们发现了什么重要的东西？

d经过一段时间后，就会结交一些在会议上见面的朋友，通过网络与他们交流最新信息。

252）很多公司的问题并不比本公司的问题少。与其他公司的测试员建立联系，有助于自己的未来发展。

253）如果不喜欢自己的公司，就再找一份不同的工作。当前有工作几乎总比当前没工作更容易找到好工作。但如果现在的工作环境如此恶劣以至于影响自己对自己的看法，以及面谈时对自己的描述那么最好还是离职，休息一段时间，如果可能，可参加夜校给自己充电，使自己处于很好的精神状态，以便更有效的为下一个潜在雇主工作。

254）为寻找新工作做好准备。例如：准备最新的简历、与一些很好的招募人员有不错的关系、知道有哪些类型的招聘岗位、有哪些公司要招聘及其待遇等。

255）积累并维护希望加入的公司的名单。收集自己希望加入的公司信息，特别是通过网络、会议和关系，与在那些公司中工作的人见面、交谈

256）积累材料。积累能够证明自己能力的一些代码、文档或其他的工作样本，可利用这些材料显示出其他应聘者不具备的能力。获取这些资料的最好时机是：

a在裁员涉及到自己时，经理或人力资源的代表会解释裁员条件。如果自己手中有特定的工作样品，他们会乐意签署文件，允许员工向可能的雇主或客户出示这些样本，以便获得工作。

b离开公司半年到一年后，如果自己的前老板还在原公司，则这个问题比较好处理。

c在会议上用作例子。

257）把简历当作推销工具。目标是写出针对恰当市场的简历。

a如果对有显者不同的工作岗位感兴趣，则写出不同的简历。要突出最能够说明自己的技能、兴趣和背景。注意：要保证自己不同简历的有关背景和成就的描述是一致的。

b准备一份历史简历。历史简历要以时间顺序描述自己的工作经历，突出介绍在每个工作中取得的成就。

c准备一份功能性或关键词简历。

d决不要夸大自己的背景、技能或经验。诚信是自己的主要资产。

258）找一位内部推荐人。

259）搜集薪金数据。通过www.salary.com这样的网站，可查询到现实的薪金预期值，了解这些信息，更好地准备面谈。

260）如果是根据招聘广告应聘，应根据广告要求调整自己的申请。明确指出招聘广告多项要求中自己已满足的条目及还不满足但很希望学习的条目。

261）充分利用面谈机会。当应聘者接到不太感兴趣的工作面谈机会，应考虑接受这种面谈，并以确实想要应聘工作的同样热情准备面谈。因为这种面谈也是一个实践自己面谈技能的机会。

262）了解准备应聘的招聘公司。如果招聘公司为电，要求进行电话交谈，可向其索取以下信息：

a索取产品材料或公司介绍材料。

b索取他们发行的软件演示版，或询问公司所使用的开发和软件测试工具。询问公司所开发的应用程序类型。

c询问从哪里可以找到有关该公司的其他信息。

注意：如果公司寄来一些材料，一定要在面谈前看完。

263）在应聘时询问问题。应针对不同类型的人挑选不同的问题，如下是沉淀产生有意义回答的问题，例如：

贵公司提供什么产品和服务？

我可以看一下关键产品的演示吗？

贵公司提供的产品和服务有什么特别之处？有哪些主要优点和弱点。

贵公司如何开发主要产品？有些什么关键的开发综合考虑？

贵公司的客户、竞争对手有哪些？

贵公司如何了解自己的客户或如何了解自己的客户对整个产品、设计和缺陷的满意程度？

请描述贵公司的组织图（你们在什么位置、我将在什么位置）。

贵公司的工作情况怎样？

你的工作是什么？你提供什么产品和服务？

你在产品开发过程处于什么位置？

你对你的工作有什么看法？

你想做一些改变吗？

你怎样安排时间与家人待在一起？

你对自己的工作有多大的控制力度？

谁来设计你所运行的测试？谁来运行你所设计的测试？

请谈谈你们的测试设计过程。

我可以看看一些测试计划和测试用例吗？

你对自己的待遇、老板、同事有什么看法？

去年你听过哪些课，出席过哪些会议？

你还接受过什么其他培训？

你怎样学习新技术？

请描述去年你所学到的三种关键技术。

在面谈时，要集中注意力看着对方，认真地听。从而获取如下信息：

a面谈者累了吗？

b面谈者和其他人对他们自己工作的看法是肯定的吗？

c他们是否有很好的士气和团队精神？

e他们的办公设备如何？他们在提高工程技术人员的环境舒适度和生产率方面的投资有多大？员工的办公设备与经理的办公设备有多大不同？

e测试员占用多大的工作面积，设备和照明，更高层人员占有多少?

f寻找所声称的工作条件和实际工作条件的差别。例如：工作时间。

264）就自己的工作岗位进行谈判。谈判是一种技能，必须实践。在谈判期间得到的信息越多，谈判就越有效。关键的信息例如：知道自己想要什么；知道他们想要什么；知道他们的想法；知道他们作为潜在雇主怎样谈判；知道自己的其他选择。

以下是谈判期间会出现并应该考虑的问题：

a在会谈初期，要讲清楚自己想要什么（非报酬方面）以及自己对什么感兴趣。

b应聘者应拒绝提供以前的报酬信息，在雇主对自己感兴趣前，婉转地拒绝回答有关报酬期望方面的询问。

c应热心，但不要过于迫切。

d应使用他们的词汇讨论他们的产品。

e应聘者应该发现并指出自己能够为招聘公司提供帮助的方面，提出建议，给出自己想法的例子。

f应聘者要让招聘公司知道自己想要哪份工作。

g如果应聘者没完全达到该工作岗位的要求，但是又想得到这份工作，可作为一种拓展机会坦率提出来，让招聘公司知道自己多么想得到这份工作，这份工作多么适合自己的兴趣和发展目标，及自己在该岗位上施展才华。

h当心潜在雇主员工带有威胁味道的谈判风格。

请注意：在谈话和谈判时，公司经理都会极为检点。一旦录用后，他们不会更友善，不会减缓威胁口吻，不会更诚实，也不会更为员工着想了。

--265）留意人力资源部。要与决策者谈话，而不是与人力资源部谈话。

266）学习Perl语言。或使用公司指定的脚本语言如：Python、Ruby。

267）学习Java或C++。积极运用所学到的知识，例如编写自己的测试工具，来学习本公司使用主要开发语言，并在实践中运用。

268）下载测试工具的演示版并试行运行。建议：熟悉本公司没有使用的工具。

269）提高自己的写作技巧。可通辑有关技术和劝导写作方面的课程，并寻找其他途径实践来提高自己的写作技巧。

270）提高自己的公众讲话技巧。

271）考虑通过认证。认证或许可以在应聘简历中很有用，但不要通过认证就以为自己是专家。

272）不要幻想只需两个星期就能够得到黑带柔道段位。很多人对认证很感兴趣，但这与要成为成功的工程师没多大关系。

--273）有关软件工程师认可制度的警告。

计划测试策略：

--274）有关测试策略要问的三个基本问题是“为什么担心”、“谁关心”、“测试多少？”。

275）有很多种可能的测试策略。以下是三种不同的测试策略：

a我们经过简单内部评审，找出所有特别明显的问题后，将产品发给友好的用户。让这部分用户实际使用产品并告知我们需做哪些方面的修改。

b我们定义以用户与产品交互动作序列表示的测试用例，这些测试用例合在一起，代表预期一般用户使用产品的各种方法。还在此基础上补充压力测试和异常使用测试。首先要做的，是发现对比特定行为的基本偏差，并关注该程序与用户期望冲突的方式。还要考虑可靠性，但我们还没确定如何最有效地评估可靠性。

c我们执行并行探索式测试，开发和执行自动化回归测试。探索式测试是基于风险的，并根据需要按覆盖区域分配，我们每周都要重新检查分配情况。自动化回归测试关注基本功能的检验，以提供涉及主要功能失效的早期报警系统。我们还注意利用大量随机测试的机会。
请注意，每种策略都有不同的重点，都说明将如何进行测试。好的测试策略会给出要完成测试的令人信服的描述和论证。

276）实际测试计划是指导测试过程的一套想法。这种想法很重要。是否记录及怎样记录这些想法则完全是另一个问题。请不要把测试计划与沟通管理该计划的方式混淆起来。

277）所设计的测试计划要符合自己的具体情况。Satisfice语境模型，五角形各个角上的圆圈表示测试小组的具体条件：资源与约束，这五个圆圈分别代表：开发、任务、需求、测试实验室、测试团队。五角形的中央表示测试小组的选择。测试计划的目标是所选的测试过程能够使测试控制在项目环境中，同时又能充分利用资源，完成自己的任务。

给定五种资源和约束具体是：

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

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

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

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

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

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

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

好的测试计划，不管是不是书面的，都要描述有关测试过程的一套选择。测试计划必须描述三类选择：

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

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

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

279）不要让保障条件和工作产品影响实现测试策略。即，测试策略常常被测试计划其他部分掩盖。例如：有些测试计划文档详细给出进度计划、团队及交付件等信息，但几乎没谈如何测试该产品。

280）如何利用测试用例。讨论测试用例的内容，即讨论风险和覆盖率，否则不要利用测试用例统计信息，因为知道得很少但是正视现实比知道得很少假装知道得很多要好得多。

注意：测试用例就像箱子，只统计箱子个数而不管其中的内容是没意义的。仅统计测试用例的通过与未通过比例说明不了任何问题，仅统计已实现/计划实现的测试用例比例也说明不了问题，因为也许最困难的测试用例被推到最后，最后10%的测试用例需要50%的时间完成，也许所计划的测试用例数还根本不足以覆盖重要的风险。

281）测试策略要比测试用例重要。因为测试策略包含测试用例执行背后的理由，即它时总结产生测试用例的手段和目标概述。

282）测试策略要解释测试。好的测试策略是：

a与具体产品有关。

b关注风险。显示测试过程可以怎样描述重要问题。将测试过程与这个项目的任务关联起来。

c多样化。多样化测试策略要包含各种不同的测试手段或方法，逃脱一种测试方法的问题还可能被另一种方法捕获。

d实用。测试策略必须能被执行。不要提出远超出项目团队能力的测试策略。

283）运用多样化的折衷手段。执行达到相当水平的多种不同测试，要优于完美地执行一两种测试，我们把这种原则叫做“多样化折衷手段”。这个原则来源于软件产品的结构复杂性。

284）充分利用强有力测试策略的原始材料。测试策略可利用的资源，例如：

a测试员运用各种测试手段的技能。

b测试员有关产品内部技术的知识。

c具有特殊测试或工艺技能的朋友。

d原始测试数据库。

e各种测试平台，包括多种操作系统和硬件配置。

f各种测试工具。

g实际用户数据。

h植入产品中的可测试性功能（例如：日志记录文件、判断和测试菜单。）

285）项目的初始测试策略总是错的。

随着对被测试产品及其失效模式认识的不断深入，测试策略也应更新，应避免过早固定一种且只有一种测试策略，建议要根据风险确定测试策略。

286）在项目的每个阶段，可自问“我现在可以测试什么，怎样才能测试好？”。

测试策略要考虑进行测试的项目开发阶段以及测试结构层次（单元、子系统或系统），但并不是决定性的考虑因素。不要认为特定手段只是在一定的开发阶段才是有用的。要使自己的测试策略能够抓住更多的机会。在任何时候，测试任何值得测试的东西，使用任何能够最好地满足客户要求的手段。

287）根据产品的成熟度确定测试策略。总体目标是随着产品开发的进展，不断调整测试策略，使得在产品开发整个过程中，重要错误的发现率都保持比较高的水平。

测试策略分四4个阶段：

a项目初期，同情地测试。在这个阶段不必进行深入的测试，因为简单的测试也会发现问题，程序员想知道的是刚刚实现的功能是否基本上能够运行。

b项目中期，积极地测试。在这个阶段需更严格、更复杂的测试，层层深入测试产品的各个部分，尽可能多地发现并报告错误。因为此时产品逐渐成型，主要功能已实现，简单测试已没什么作用。

c项目末期，多样地测试。在这个阶段可充分发挥自己的想像力和管理层所提供的支持，推行多样化测试，因为找出成熟产品的错误更困难些。例如：自动测试工具、查错奖励措施、启发式测试等，持续测试多样化可使曲线保持较高水平，直到想不出新的、更好的测试。

d项目最后，谨慎地测试。在这个阶段测试的重点应该更具防御性。要仔细测试每个变更，检查这个版本要交付的所有文件。利用结对测试为每个测试再增加一层保障。

288）利用测试分级简化测试复杂性的讨论。为了在测试策略中简化测试复杂性的描述，很多测试项目团队都发现区争测试级别会有帮助。例如：

0级，冒烟测试。显示产品已经可进行独立测试的简单测试，如果0级测试失败，可把产品直接打回给程序员。

1级，能力测试。检验产品每个函数能力的测试。1级测试的目标是保证每个函数都能够执行其任务。1级测试应该避免采用曲折的场景、富有挑战性的数据和功能交互。

2级，函数测试。检查产品各个个体函数和子函数的能力和基本可靠性。使用边界、压力和错误处理测试，避免采用曲折的场景和功能交互。

3级，复合测试。包含多组函数间交互和控制流，以构成复杂场景的测试。评估的重点已扩展，可能要包括性能评估、兼容性、资源紧张程度、内存泄漏、长时间可靠性或其它类型的质量评估。

注意：这四级测试中的每一级，可能对应一些不同的测试技术或技术组合。总体思路是首先宽泛地、同情地测试，随着测试不断成熟，逐步进行深度和边缘测试。对产品的早期版本执行第3级测试，而不首先执行第1、2级测试，可能会使程序员感到反感，更有可能的是，根本不能执行这些测试。

289）测试灰盒。灰盒测试的概念很简单：如果了解一些产品内部工作情况，就能够从外部进行更好的测试。与白盒测试不同的是，白盒测试需了解产品内部细节。在灰盒模型中，要从产品的外部测试，就像黑盒测试一样，但所选择的测试反映出测试员对内部组件操作和交互的了解。

290）在重新利用测试材料时，不要迷信以前的东西。即，在重用测试用例等任何测试材料时，不要将其当作黑盒使用。要先做一些了解，思考测试材料为什么采用这种方式设计。另一方面，如果对编写将被重用的测试用例想法感兴趣，可自问别人怎么会知道该测试用例的含义，编写这个测试用例的理由，以及这个测试用例该在什么时候过时或更新。

291）两个测试员测试同样的内容，也许并不是重复劳动。重复测试工作几乎都不会是浪费，因为两个测试员可能会注意到不同的问题。其实重点不是重复测试工作是否浪费，而是产品的某一部分是否值得进行重复测试。

292）设计策略时既要考虑产品风险，也要考虑产品要素。基于项目的测试策略所制定的原则如下：

a不要在测试员间的缝隙中遗漏错误。因为这些遗漏会出现在两个测试员（小组）任务间的边界处，除非采用多样化折衷测试手段。

b经常测试客户要求测试的内容。测试员弄清他们的要求并至少完成一部分所要求的测试。

c偶尔测试客户要求不要测试的内容。有时客户要求不要测试产品的特定部分。这是个微妙的问题，有时被要求不要测试的正是最需要测试的。

d测试不够清晰和矛盾的内容。任何有模糊和矛盾的地方，就会有很多错误。例如：程序员不太确定某个功能应该完成什么任务；程序员是第一次使用这种技术；两个程序员编写相互间接口的单元。

e不要痛打落水狗。如果已清楚某个功能看起来有很多错误，就不要继续测试了，除非要和程序员一起检查。因为程序的组件可能直接被替代而不是修改，所以发现的所有错误都会被一起归档，不必再费劲测试。

f更多变更意味着更多测试。理论上，产品中微小的变更也会产生大的全局效果。这意味着任何变更都可能潜在地使已经完成的该产品测试无效，所以测试员必须测试所做的变更。到项目快结束时，这部分的测试工作量很大。

293）把测试周期看作是测试过程的韵律。真正的测试计划是实际指导自己实施测试的一套想法。计划共包括7个任务主题。

a监视影响测试计划的主要问题。确定影响制定实用、有效的测试策略中时间、工作量或可行性要素的风险、障碍或其它挑战。要把握计划的整体作用。在整个项目开发过程中，全程监视这些问题。

b明确任务。根据对具体项目的了解，为测试任务目标排队。对于所有适用的目标，找出可以用来评判的具体的成功指标。

c分析产品。了解被测产品及其内部技术。了解如何使用被产品。需要深入下去。分析什么（用户、结构、功能、数据、平台、运营）；分析方式（执行探索式测试、评审产品和项目文档、与设计人员和用户面谈、与类似产品进行比较）；可能的工作产品（测试覆盖大纲、带注释的规格说明、产品问题清单）。

d分析产品风险。被测试产品怎样以一种重要方式失效？分析对象（威胁、脆弱性、失效模式、失效影响）；分析方式（评审需求和规格说明、评审实际失效、与设计人员和用户面谈、对照风险启发和质量评判大纲评审产品、找出一般问题和失效模式）；可能产品（组件/风险矩阵、风险清单）。

e设计测试策略。测试员可以做什么？首先做出最好的策略，同时又要让测试策略能够在项目整个开发过程中改进。考虑五方面的手段（以测试员为核心、以覆盖率为核心、以问题为核心、以活动为核心、以评估为核心）；计划方式（针对风险和产品域确定手段、可视化具体和实用手段、使测试策略多样化，尽可能减少遗漏重要问题的机会、寻找通过自动化测试扩展测试策略的途径、不要计划得过死，使测试员能够发挥自己的才智。）；可能的工作产品（逐项列出的每条所选测试策略及如何运用的说明、风险/任务矩阵、所选测试策略固有问题清单、针对没有充分覆盖的产品部分提出的建议、测试用例（仅当需要时））。

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

g共享测试计划。测试员并不孤独，至少要让项目关键成员参加测试计划讨论制定，从而得到他们的理解和隐含支持，以争取实现测试计划。目标：对测试过程有一致理解、对测试过程有一致承诺、测试过程合理参与、管理层对测试过程的合理预期。

测试计划的质量准则：

a有用性。测试计划会有效地支持其所提供的功能？

b准确性。测试计划文档是否准确地与事实描述保持一致？

c高效性。测试计划是否能够高效地利用已有资源？

d可适配性。测试计划是否能适应项目中合理的变更和不可预测性？

e清晰性。测试计划是否自我一致并足够明确？

f可使用性。测试计划文档是否简练、可维护并有很好的结构？

g兼容性。测试计划是否满足外部提出的需求？

h依据。测试计划是否是有效测试计划过程的产品？

i可行性。测试计划是否没超出必须使用该计划的机构能力？