测试文档：
我们在使用IEEE标准829的结果并不乐观，问题在于标准829并不是满足公司需求的合适方法。
142）为了有效地应用解决方案，需要清楚地理解问题。
143）不要使用测试文档模板：除非可以脱离模板，否则模板就没有用。注意：测试文档模板不能替代技能。
为了使用模板编写好的测试文档，必须理解模板每一部分的含义，理解为什么要有这一部分，什么时候可删除。如果测试员对这些都能够理解，就不再需要模板了。如果不理解这些，就不要受模板的影响。由于测试员不理解模板作者对需求和权衡所做的全面考虑，模板就会使测试员生产率降低。使用模板的人必须能够根据自己当前具体需求剪裁模板。
144）使用测试文档模板：模板能够促进一致的沟通。
145）使用IEEE标准829作为测试文档。
146）不使用IEEE标准829。实践遇到使用该标准的问题如下：
a标准的前提假设看起来是瀑布方法，要在早期开发测试，仔细编写测试，以后就不再更改。
b大量的测试文档产生一种盲从心理。
C该标准没提供测试文档的需求分析，即没有提供什么时候提供什么类型信息的建议或指南。
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个最糟糕的问题。