有效软件测试50条建议.pptVIP

有效软件测试50条建议 王伟 2009－02－18 前言 本书提供了一些实践经验和关键理念,组织可以利用这些实践和理念成功地实现有效的测试工作.本书的目的是为读者提供各种经过精心挑选的技术和建议,软件从业人员能够直接用它们来改进产品,同时也能避免损失惨重的过失和疏忽.本书详述了50条最好的软件测试实践,分为10部分进行讲述,这10部分大致和软件生命周期的各个阶段相对应. 第一条 软件人员及早介入 测试人员需要彻底地了解产品,只有这样他们才能设计出更出色和更全面的测试计划.测试设计,测试过程和测试用例.测试组及早介入,就可以避免在项目生命周期中的后续阶段对产品的功能行为不理解. 测试组及早介入,还可以了解到应用程序的哪些方面对最终用户来说最关键以及哪些元素的风险最大,这样测试组就可以首先把精力集中在应用程序中最重要的部分,避免对不经常使用的部分过度测试对重要部分又测试不充分 测试人员所要掌握的不仅仅只是软件的”输入和输出”,他们还需要掌握更深入的知识,而这种知识只有了解撰写产品功能说明书的思考过程才能获得,这种理解不仅能够提高测试人员开发的测试过程的质量和深度,而且测试人员也可以针对需求提出反馈意见 在生命周期中发现缺陷越早,那么修正缺陷的 代价就越小 第二条：验证需求 下面是软件测试人员在需求阶段用来验证需求质量的检查列表，运用这一检查列表是及早发现需求中的缺陷的第一步： 正确性：根据用户的需要进行检查，例如：标准和规则描述得是否正确？需求是否准确地反映了用户的需要？在需求阶段，最终用户或者恰当的用户代表的介入是非常必要的，正确性也可以给予标准进行检查，需求是否遵从某个标准？ 完整性：用于保证需求中没有遗漏任何必须的元素，其目的是为了避免只是由于没有人提出恰当的问题或者没有人检查所有相关的原始文档而引起的需求遗漏。 一致性：验证的是工作产品的内部元素之间或者工作产品之间没有内部或者外部的矛盾，通过提出问题，规格说明书中是否清晰和准确，例如：需求规格说明书中的许多地方都使用了术语“观察者”，而这一术语在不同位置根据上下文有着不同的含义，那么这样给后面的设计和实现阶段带来的问题，没有清晰一致的需求定义，就无法确定需求的正确性。 可测试性或可验证性： 保证了测试一条需求的可能性，同时测试的结果是预先知道的并且能够通过编程或者人工来加以验证。如果一条需求不能被测试，或者不能通过其他方法来验证，那么我们就必须注明这个事实以及相关的风险，我们应该尽可能调整需求以使它可以测试。 可行性：保证了需求可以在给定的预算，进度表，技术和其他可用资源的情况下实现。 必要性：验证规格说明书中的每条需求是否都与系统有关，为了检查相关性或者必要性，测试人员需要对照系统的既定目标来检查需求，这条需求对实现系统目标有价值吗？去掉这条需求会影响系统实现它的目标吗？其他需求依赖这条需求吗?有些与系统无关的需求并不是真正的需求，只是建议的解决方案。 明确性: 保证了需求的陈述使用了精确的和可测量的方法，下面的例子就是一个不明确的需求：“系统快速地响应用户的查询请求”。“快速”是模糊的和主观的，因此这条需求是不可测试的。 可追溯性: 保证了每条需求可以通过下面的方法来确定，那就是能够找到所有引用它的系统部分，对于需求的任何变化，我们能确定系统中受这种变化影响的所有部份。 第十二条：估计测试准备和执行所需的时间 为了获得做好的效果，这里列出的方法必须根据组织的要求和规程进行调整。 1.开发比例法：由于软件工业关注的焦点是估计软件开发的工作量，所以测试工作量的估计一般基于开发比例方法得到。 2.项目人员比例法 利用整个项目计划投入的人数（包括需求、配置、 过程、 开发和QA等各类人员）来计算测试组的规模。当实施开发 工作的人数频繁变化或者难于确定数量时，这种方法特别有 价值。 3.测试过程法 计算方式：采用已经完成的各种开发项目的历史记录，这些记录中需要包含有关开发规模的度量值，即功能点，使用的测试过程数量、“人/小时”为单位的测试工作量的测量结果。 局限性：由于这种方法只考虑需要设计和执行的测试过程的数量，而忽视了对测量测试工作量有影响的其他重要因素，所以这种方法在某种程度上是有局限性的，为了使估计更加全面准确，这种方法只能和此处列出的其他方法配合使用。 4.任务规划法 这种估计测试工作所需工作量的方法需要回顾相似类型的测试工作在人/小时数方面的历史数据，这种方法和“测试过程法”的不同之处在于它关注的焦点是测试任务。 第十六条 了解系统架构和基本组件 全面了解系统架构对测试工程师的帮助: ·提高缺陷报告的质量。 测试过程一般依赖于需求，因此它 会沿着一条相对固定的路径经