制定可用性测试计划(一).pdfVIP

制定可用性测试计划 （一 ） 测试计划是整个可用性测试的基石。计划应当阐明如何测试 ，何时、何地 ，由谁 推动测试 ，为何 测试以及测试内容。不过 ，有时在项目期限临近的巨大压力 下 ，你可能不打算写一份详尽的测试 计划。毕竟 ，你认为自己对即将进行的测试已了然于心 ，不必再花时间把它写下 。但是 ，这样不 规范的做法显然是错的 ，最终 不可避免地将带 麻烦。 为什么要制定测试计划? 合理的做法是 ：当你知道将要进行测试的那一刻起 ，就该着手准备测试计划了。之后随着项目推进 ，不断完善计划 ，收集反馈 ，如此往复。当然 ，灵活也是有限 度的 ，你在测试前必须设定某个时间 节点 ，确保在此之后 ，计划不会变动。同时 ，测试的产品在这个时间节点后 ，也不允许再有任何 改动 ，直到测试结束。你可能已 经发现测试计划是产品开发周期中唯一具有明确时间点的文档 ，因 此格外重要。 当期限临近时 ，你要竭尽所能不要去变动将要进行测试的设计产品。额外改动会令之前制定的测试 方案变得不再可靠 ，譬如需要研究的问题甚至是数据收集方法 的信度都会受到影响。如果在计划的 时间点之后被迫更改测试 ，那要确保每个人都了解此举带 的风险 ：测试可能是无效的 ，并且临近 测试前改动的产品有可能无法 正常使用。 下文列出了为何需要制定详实计划的原因 ，以及在开发团队中测试计划作为沟通工具的使用方法。 作为测试的计划准则 正如图纸精确画出了所要建造的房子一样 ，测试计划也精确描述了将如何去测试你的产品。你肯定 不愿意建筑承包商在建造房屋时不按计划地即兴发挥 ，可用性测试同样遵循这一逻辑。测试计划确 保一切有据可循。在测试第一位被试时 ，你肯定不希望测试中仍存在尚不清楚的事项。 作为主要沟通工具 测试计划是设计师、开发者、测试主持人以及团队其他成员的主要沟通工具。开发团队和管理团队( 如果他们感兴趣且在团队中)的相关人员应该仔细阅读测试 计划的文档报告 ：了解测试是如何进 行的 ，并确认是否已满足他们的具体需求。你可以利用计划从其他成员那儿获得建议和反馈 ，以保 证每个人都同意将要进行的实 战测试。进行的项目每天每周都会有变化 ，你也不想在测试结束后某 人质疑他或她的某些需求没在测试里出现。另外 ，如果这是你组织的第一次测试 ，更要让测试结 果的相关负责人员审查测试计划。这也保证了计划的商业性和政治性。 计划写明或暗含所需资源 测试计划描述或暗示了测试所需要的内部和外部资源。一旦你准确列出了何时将进行何事 ，那预估 测试所需的资源这一任务就变得清晰容易了。无论是直接写明亦或是间接暗示 ，测试计划包含了 成功测试所必需的资源。 计划是测试和实 阶段的连接点 没有测试计划 ，细节就会变得模糊不清 ，尤其是在截止时间的压力下。测试计划迫使你的测试方法 具有系统性 ，提醒开发团队即将到 的截止日期。说了这么 多 ，这是完全可以接受的 ，并且是极有 可能发生的。当你逐渐了解更多的测试目标 ，与参与测试的被试沟通更多时 ，测试计划在这个阶段 中也会逐渐优化。项目是动 态的 ，当测试真正开始时 ，即便是看起 最完美的计划也不得不变更。 通过优化测试计划 ，你可以适应过程中遇到的变数。例如 ，当你的时间和资源的限制越 越清 晰的 时候 ，你可能变得不那么雄心勃勃了 ，而是想敷衍了事。或者 ，也许你没有按照自己的设想找到足 够多合格的参与者。也许不是文档中所有模块或章节的需求都 将按时准备好。也许你的测试目标太 不精确 ，需要简化和集中。这些都是 自真实世界的例子 ，他们迫使你修改测试过程和测试计划。 注意 ：当你制定计划时要始终将最终用户牢记心中。随着项目进行 ，你很有可能忘记你要测试的 内容 ：具有某些特点的用户与产品的关系 ，而不是测试产品本身。 测试计划的组成部分 测试类型不同 ，或是你所在的组织对测试规范度的要求不同 ，测试计划的格式也是不同的。不过 ， 通常会包含以下9部分 ，下文将对它们具体地描述。 ■ 测试目的、目标和对象 ■ 研究问题 ■ 被试特征 ■ 方法(测试设计) ■ 任务清单 ■ 测试环境、仪器和后勤准备 ■ 测试中主持人的作用 ■ 收集的数据和评估方法 ■ 报告内容和呈现 其中 ，由于测试中主持人的作用巨大 ，在第4章将作为独立章节详加讨论。其余部分则在本章阐述 。 回顾测试目的和目标 文档的这部分描述了进行该项测试的原因。这里不是要你说出测试考察的具体目标或问题;相反 ，你 的焦点或出发点应该是站在组织的角度 ，关注重点的问题。例如 ： ■ 测试旨在解决的问题是 ：公司的呼叫中心或技术支持先前上报过的问题吗? ■ 服务器