测试计划评估+详细说明.doc

Satisfice, Inc. James Bach, Principal Version 1.12 9/25/99测试计划评估模型这个测试计划有多好?，问题的答案只能用参考测试计划应该是什么样的思想来回答。尽管有大量说明测试计划文档格式的公共标准，但是这些标准基本上没有提供区别测试计划好坏的依据。此文档的模型说明了最基本的概念，测试计划的作用，测试计划应该符合的标准，以及一些对确定标准是否符合特定功能有所帮助的启发：术语和概念测试计划. 测试计划是一系列指导或者描述预期测试过程的思想。这些思想常常只有部分文被文档化，跨越了多个文档，也经常随着项目的进展而被改变。测试计划文档.测试计划文档就是那些任何可以传达测试计划信息的文档。然而，测试计划文档不是测试计划的唯一信息来源资源。测试计划信息还包括项目的口头传授传统和公司的文化。测试策略 测试策略是设计和执行测试的方法，并且还可以被有效优质的评估用以它可以支持有效的质量评估，此处如果用“用以”，就显的策略的功能太狭隘了支持有效的质量评估。测试策略是测试可以覆盖产品的那一部分以及使用哪种测试技术的计划。测试策略与执行策略的细节部署逻辑不同。测试策略是整个测试过程的灵魂。“头脑”部分。测试方案 测试方案是执行测试策略所使用的方法、要提交的结果。测试方案是测试过程的主干。测试计划的作用测试计划的作用就是测试计划预期要完成的事，下面就是一个理想的测试计划功能列表。然而，测试计划文档仅可以仅仅表述仅可以比较符合汉语表达习惯，同时也与前面的“然而”转折词相对应；测试计划文档并不单单是表述功能，虽然处理不能确且的表达，但是表述与原意义差别有点大处理预期功能中的一部分；其余部分功能或是在其它文档中表述处理，或是由测试管理者和测试人员个人直接管理，并且这些功能没有任何文档支持。这样，测试计划的好坏只能用测试计划要具有的功能来判断，或者是用其他方法无法完成而策划计划可以完成的功能来判断。有利于品质评估的发展质量评估，以便给出关于产品的明智而及时的决定在这里，是说质量评估的发展，因为后面有说的产品的变更；英明与太及时是并列的，不是转折的关系，所以用“而”不合适而这些品质评估能够使人可以根据产品作出英明及时的决定。描述并证明汉语的证明如果后面说结果，就是半句话，所以此处适合将“证明”部分提出来，后面加上证明什么是正确的。涉及技术需求要求和技术风险的测试策略（包括所提到的测试覆盖）。，并证明这样的测试策略是正确的。促进促进。认识不通顺提高对测试策略优点和局限性的认识意识。为了保证测试项目的进展是要求和准则的定语，不是描述与证明的目的状语，最初翻译与原文比较一致。，描述并证明所有必须符合这样的特殊特别要求或标准入口准则，为了测试方案可以进展，同样，需要测试要符合的特别要求或标准，描述所有确定何时停止测试的出口或步骤； 并且要证明这些特别要求或标准以及出口或步骤是正确的。_支持测试方案方案的启动和组织工作：包括事先准备，工作人员的配畚，责任的分工，设备需求，任务计划和计划日程安排。支持测试方案方案和测试策略的每日管理和每日评估。支持测试团队的有效协调、合作，以及其它关系，还有测试团队与项目其他人员的有效协调、合作。_确定和管理那些会冲击项目的风险或问题提案。说明测试方案方案的交付交接和交付过程过程交接。记录历史信息，对过程审核审查、过程改进改善以及以后的测试项目方案都有所帮助。测试计划质量标准这些标准与测试计划如何更好的执行其功能有关。在某种程度上，测试计划符合这些标准，那么这个测试计划就是好的测试计划。准确的讲，测试计划如何好到“足够好”，有赖于测试环境状况因素和判断。有效性有用性：。测试计划是否有效的执行了预期的功能？准确性：。对相对应的事实描述比较起来是否准确？效率有效性。：是否有效的利用了可用资源？适应性：。是否可以容许测试项目方案合理的变化和发生的不可预期事情的发生？清晰性：明了。 测试计划z自身描述的内容是否一致，是否足够明确？可用性：。测试计划文档是否简明、是否可维护、并且很好的组织起来了。持的以及有益组织的？兼容性：。测试计划是否可以接受外部强加的要求？基础性：创立。 测试计划是否是有效测试计划过程的产物？可行性。是否在执行测试计划组织的能力范围内？ 测试计划的启发为了确定测试计划多大程度上好的符合以上测试标准，我们利用了启发的方法。也就是说，测试计划评估一般是建立在被广泛接受公认拇指规则的经验法则基础上，而这些公认拇指规则经验法则是我们通过实践和学习获得的。下表中的每一个启发都涉及到上面说明的一个或多个的标准和功能。唯一没有相应启发的是兼容性。这是因为兼容外部强加的需求，要求需要那些需求相关要求的专业特殊知识。我们是用通用一般的规则和规则的简要基本原则部分来描述每一个启发。这些基本原则的初衷是帮助我们确定何时何处来应用启发。启 发启 发 根 据 的 基 本 原 则1. 测试应该优先快速发现重要问题，而不是相同的紧急程度下，企图一下找出的最掉的所有问题。在项目方案中越晚发现的问题，不能及时安全解决的风险就越大。问题存在以后，越早发现问题，无法这里是说解决的不好，不是无法解决，糟糕解决问题的风险就越小。2. 测试策略应该将大部分注意力集中在有潜在技术风险的部分，然而给小风险部分一些注意力仅仅是怕万一风险分析错误。完全意义上的完成测试是有不可能的，但是我们永远不可能知道我们对技术风险的理解是否完全准确。3. 测试策略应该说明测试平台配置、产品如何操作、如何观测产品以及如何利用这些观测评估产品。草率对待或忽略这四个基本测试活动会增加检测不到重要问题的可能性。 4.测试策略应该使用多种测试技术和观点。评估测试覆盖的方法应该考虑多维覆盖，包括结构、功能、数据、平台、操作和需求。使用线性方式的单一测试技术不可能暴露所有重要问题。我们永远不可能确保我们发现了所有问题。多样化可以减小测试策略只考虑了某一种问题的风险。5. 测试策略应该说明如何设计及如何得出测试数据。通常测试策略是围绕功能和编码而制定的，从而将测试数据留给测试人员自由的编制。这样常常就意味着测试策略太着重于确认功能，而没有充分的考虑可靠性。6. 不是所有的测试都应该详细的预先说明。测试策略应该包含合理的变化，用测试员根据测试状况推理的能力，将测试员注意力集中在重要的，但不可预期的问题上。严格的测试策略很可能会使问题的特别子问题没有被覆盖，但是，在一个复杂的系统中，严格的测试策略会减少重要问题没有被覆盖的可能性。测试中合理的变化,如交互式、探测性测试的结果可扩大偶然测试覆盖面，但没有足够扩大基本的测试覆盖面。7. 根据隐含含蓄的需求（需求的充分扩展，不仅仅是需求描述的那样）测试是很重要的。由于需求一般都定义的不完全，以及描述需求的自然语言固有的不明确性，所以仅根据清晰描述的清晰与隐含不是一对相对的词，所以用在这不大合适需求描述的那样测试来测试，是不会暴露所有重要问题的。8.测试方案应该促进推动与方案的其它职责协作方案中描述的所有的功能的协同工作这里的功能与后面的“人员”“文档”不一致，特别是开发人员者、技术支持和技术文档。为了更好的了解客户和用户需求，测试人员也要尽可能的与实际的客户和用户沟通协作 。其他团队和1常常掌握与产品问题或潜在问题有关的信息，而这些信息对测试团队是有用的。他们的观点有助测试人员对风险更好的分析。测试员也掌握了对自己有用的信息。9. 测试方案应该与开发者协商，有助于开发者构建编译一个更可测的产品。测试策略能否达到它的目的在很大程度上受产品的可测性影响。10.测试计划应该着重测试策略和测试方案中的那些非常规、方案说明方面。事实上，任何值得做的软件项目都涉及到特别的技术挑战优秀测试必须要考虑的技术挑战。一个十分普通的测试计划通常意味着需要一个星期来完成计划一个差劲的测试计划过程。同样，十分普通的测试计划也只是意味着是一个不变的样本。11.测试方案应该用人工实施人工做的好的部分，用自动化实施自动化做的好的部分。根据需要，合适的采用手工测试方法或者自动化测试方法。人手工测试应该允许即席创作以及当场鉴定思想测试过程中对测试的改进和对关键问题的思考，而自动化测试应该被用于那些要求高重复次数多，高速度以及不用判断的测试。许多测试方案受到可信度问题错误认识的困扰，例如，人工测试使用特定详细说明的测试脚本测试是非常有效的，或者是在测试执行期间，自动化测试复制录用了人工认识值测试过程中人的思维方式，这对于测试是很有效的。人工和自动化测试不是同一事物的两种形式。它们是完全不同的两类测试技术。12.应该给出测试日程安排应该描述，并且证明测试日程安排的合理性。证明的过程中，需要考虑测试日程安排对软件开发过程的依赖、产品的可测试性、上报问题的时间、项目团队的风险评估等问题。和证明产品的易测性、报告问题的时间以及项目团队的风险估价，用这样的方法描述和证明是为了突出测试安排依赖开发过程。测试计划中独立的的模块测试日程安排常常意味着测试是一独立行为的信任度问题的活动，这种看法是错误的。测试日程安排可以是完全独立的，不过前提条件只是就好的产品具有很好的、软件开发可以及时完成，可测性、开发是完全的以及测试过程不会被频繁的报告问题打断方面来说的。13.测试过程应该尽可能不受关键路途径影响。 测试与开发并行进行，发现值得解决的问题比开发者解决这些问题快，可以做到不受影响。为了转移压力，剪短裁减测试过程是重要的。14. 测试员和开发者之间的反馈循环要尽可能通畅的紧密。在定义测试周期的时候，应该考虑在回归测试之前，能够对开发人员产品的增加的功能和功能修改作出迅速的反馈。设计的测试循环在开始一个完全衰退测试之前，应该给开发者提供快速的反馈，这些反馈是有关开发者最近的增加部分和改变。测试人员和开发者任何时候都应该尽可能互相靠近工作。为了最大程度的提高质量改善的有效性和速度，互相靠近工作是非常重要的。也有助于测试不受关键途径的影响。15.为了有助于测试方案的评估和调整，测试方案应该使用有关质量的信息渠道，而不是形式上正式这里强调的是要根据地信息调整，所以翻译成形式测试比较合适的测试。 这些渠道包括有视察检视、实地域范围这部分主要是说非正式测试，所以说域范围不合适，应该是实地测试。测试，或者是测试团队以外的人员非正式的测试。检查产品的质量信息，这些信息是用不同的测试团队之外的不同的方法收集的，这样可以暴露正式测试策略的盲点。16. 所有与测试策略有关的文件，包括测试用例和过程从后面的表述“应该由一些没有写文档的人员评审”可以看到，此处应该说的是“程序”，而不是过程，因为人是不可以写过程的程序，应该由一些没有写文档的人员评审。根据文档的重要程度，采用与之匹