测试计划
测试计划是整个可用性测试的基石。计划应当阐明如何测试，何时、何地，由谁来推动测试，为何测试以及测试内容。不过，有时在项目期限临近的巨大压力 下，你可能不打算写一份详尽的测试计划。毕竟，你认为自己对即将进行的测试已了然于心，不必再花时间把它写下来。但是，这样不规范的做法显然是错的，最终 不可避免地将带来麻烦。
为什么要制定测试计划?
合理的做法是：当你知道将要进行测试的那一刻起，就该着手准备测试计划了。之后随着项目推进，不断完善计划，收集反馈，如此往复。当然，灵活也是有限 度的，你在测试前必须设定某个时间节点，确保在此之后，计划不会变动。同时，测试的产品在这个时间节点后，也不允许再有任何改动，直到测试结束。你可能已 经发现测试计划是产品开发周期中唯一具有明确时间点的文档，因此格外重要。
当期限临近时，你要竭尽所能不要去变动将要进行测试的设计产品。额外改动会令之前制定的测试方案变得不再可靠，譬如需要研究的问题甚至是数据收集方法 的信度都会受到影响。如果在计划的时间点之后被迫更改测试，那要确保每个人都了解此举带来的风险：测试可能是无效的，并且临近测试前改动的产品有可能无法 正常使用。
下文列出了为何需要制定详实计划的原因，以及在开发团队中测试计划作为沟通工具的使用方法。
作为测试的计划准则
正如图纸精确画出了所要建造的房子一样，测试计划也精确描述了将如何去测试你的产品。你肯定不愿意建筑承包商在建造房屋时不按计划地即兴发挥，可用性测试同样遵循这一逻辑。测试计划确保一切有据可循。在测试第一位被试时，你肯定不希望测试中仍存在尚不清楚的事项。
作为主要沟通工具
测试计划是设计师、开发者、测试主持人以及团队其他成员的主要沟通工具。开发团队和管理团队(如果他们感兴趣且在团队中)的相关人员应该仔细阅读测试 计划的文档报告：了解测试是如何进行的，并确认是否已满足他们的具体需求。你可以利用计划从其他成员那儿获得建议和反馈，以保证每个人都同意将要进行的实 战测试。进行的项目每天每周都会有变化，你也不想在测试结束后某人质疑他或她的某些需求没在测试里出现。另外，如果这是你组织的第一次测试，更要让测试结 果的相关负责人员审查测试计划。这也保证了计划的商业性和政治性。
计划写明或暗含所需资源
测试计划描述或暗示了测试所需要的内部和外部资源。一旦你准确列出了何时将进行何事，那预估测试所需的资源这一任务就变得清晰容易了。无论是直接写明亦或是间接暗示，测试计划包含了成功测试所必需的资源。
计划是测试和实际阶段的连接点
没有测试计划，细节就会变得模糊不清，尤其是在截止时间的压力下。测试计划迫使你的测试方法具有系统性，提醒开发团队即将到来的截止日期。说了这么 多，这是完全可以接受的，并且是极有可能发生的。当你逐渐了解更多的测试目标，与参与测试的被试沟通更多时，测试计划在这个阶段中也会逐渐优化。项目是动 态的，当测试真正开始时，即便是看起来最完美的计划也不得不变更。通过优化测试计划，你可以适应过程中遇到的变数。例如，当你的时间和资源的限制越来越清 晰的时候，你可能变得不那么雄心勃勃了，而是想敷衍了事。或者，也许你没有按照自己的设想找到足够多合格的参与者。也许不是文档中所有模块或章节的需求都 将按时准备好。也许你的测试目标太不精确，需要简化和集中。这些都是来自真实世界的例子，他们迫使你修改测试过程和测试计划。
注意：当你制定计划时要始终将最终用户牢记心中。随着项目进行，你很有可能忘记你要测试的内容：具有某些特点的用户与产品的关系，而不是测试产品本身。
测试计划的组成部分
测试类型不同，或是你所在的组织对测试规范度的要求不同，测试计划的格式也是不同的。不过，通常会包含以下9部分，下文将对它们具体地描述。
■ 测试目的、目标和对象
■ 研究问题
■ 被试特征
■ 方法(测试设计)
■ 任务清单
■ 测试环境、仪器和后勤准备
■ 测试中主持人的作用
■ 收集的数据和评估方法
■ 报告内容和呈现
其中，由于测试中主持人的作用巨大，在第4章将作为独立章节详加讨论。其余部分则在本章阐述。
回顾测试目的和目标
文档的这部分描述了进行该项测试的原因。这里不是要你说出测试考察的具体目标或问题;相反，你的焦点或出发点应该是站在组织的角度，关注重点的问题。例如：
■ 测试旨在解决的问题是：公司的呼叫中心或技术支持先前上报过的问题吗?
■ 服务器日志或网站使用数据是否已表明公司网站的访客在某个流程中的某一节点离开，使得业务无法完成?
■ 公司是否最近公布了新规范要求所有产品在发布前进行测试?
■ 管理者是否意识到开发团队在此时了解真实用户是非常重要的?
测试目的拔高到较高的高度是合适的：因为后续的研究问题及描述部分可以将大目标具体到可测量水平。测试与组织的商业目标紧密相关这点非常重要，这样测试才会成为解决问题和探寻机会的最佳工具。
什么时候不进行测试
下面几条是产品应该进行可用性测试的非常模糊和不恰当的理由。这些理由可能很少会被书面化，通常是口头交流。但是，下列的测试理由并不合理，反而最终会影响整个项目。
■你可以提升用户体验(你只能测试产品部分的用户体验，而不是产品与用户的所有接触点)。
■其他人都在做可用性测试项目(其他人还有很多别的事儿呢)。
■ 用作可用性测试的会议室本月的第三周都是空闲的(会议室每天晚上也空着)。
■ Lou先生刚参加了新一届计算机协会人机交互特别兴趣组ACM SIGCHI的会议，并且学会了这种有用的测试技术(那先让Lou先生向公司高层推荐这一有用的技术)。
■ 你想要确认是否该类型的产品有市场需求的(这个逻辑显然反了，焦点小组和问卷才是更为恰当的在产品早期阶段使用的方法)。
你可能会说服自己，尤其是当你非常迫切开展可用性测试时，“我只是想做测试，我并不关心原因，我们可以后续再考虑测试结果。”短期来看，前面的任何理 由都可以开始测试。但从长远角度看，如果你希望测试是开发产品中不可或缺的部分，你必须将测试与产品需求和组织的整体商业需求结合起来。否则，你会面临测 试被当成短期流行的新技术的困境。
进行测试的最佳理由
以下清单列出了进行测试的合理原因，它们帮助得出有效的结果，并为未来测试奠定基础。
■ 你想确定是否你的两类主要用户都能很好地使用产品。
■ 你想了解提供文档是否可以解决界面中的某些普遍问题。
■ 你收到了大量使用产品中的投诉。你想确定这些投诉的本质，以及在今年开发预算下如何修复这些问题。
图5-1给出了一个示例：在线酒店预订网站的可用性测试目标。
图5-1 可用性测试的目的和目标示例
沟通研究问题
这一章节是测试计划中最重要的部分，它描述了需要解决的问题和研究焦点，以及与测试计划、设计和操作相关的部分。研究问题必须尽可能地准确、精确、清 晰并且可测量的(或是可观察的)。就算是产品开发早期进行的探索性测试——非结构化的测试，仍需要精确地阐述你希望从中得到什么。
如果没有清晰简洁的研究目标，你会发现自己陷入了不利境地，执行的测试无法解答项目团队成员所关心的核心问题。或者，你会发现测试总是处于无休止的争 论中，因为根本问题“测试的是什么”还未达成一致。从我自身的经历来说，我们遇到过准备工作推进着，但测试本身争议不断的情况，这其实还是测试目的没有落 实成书面报告的缘故。
以下两个例子的研究问题就太模糊，太不明确了。
■ 例子1：当前的产品是有用的吗?
■ 例子2：该产品是否可以发布还是需要更多工作要做?
研究的困难之处并非是说这些问题毫无意义。而是说这些问题是不完整、含糊不清的，没有说明或暗含该如何测量或量化结果。依据此类描述来进行的测试最终 会引起结果偏差。为什么?如果相关人员就需要解决的问题都无法达成一致，那你又如何确认已经找到问题的解决之道了呢?当然，在这样的情况下，通常是连研究 问题都找不到。
下表列出了几类不同产品的研究问题，这些案例的研究问题恰当，重点明确。研究问题是在和开发团队或开发人员、技术人员、市场人员的讨论中形成的。如果他们很难归纳出测试目标或者仅仅提出了大概的问题或目标，也无需沮丧，这可能正说明：
■ 他们还没有做好测试的准备。
■ 他们需要更充分地了解测试目标、目的和过程。
■ 他们在将目标转化为具体的可测量和可观察的研究问题上需要帮助。你不要犹豫，是时候介入其中或提供帮助。
如果你发现自己很难设计测试方案和(或)合适的量表，又或是确定不了合适的终端用户，甚至是无法确定数据收集的形式，你不妨再回到研究问题本身，确认它们是否是清晰、需要进一步细化的。
下图5-2 给出了某个在线酒店预订网站的可用性测试的研究问题。
图5-2 研究问题示例
描述被试特征
测试计划的这个部分是描述测试产品的终端用户特征。与组织内的其他成员通力合作，从而确定目标用户的特点是非常重要的。有关如何建立用户档案和招募被试的具体过程可参见第7章。图5-3举例某在线酒店预订网站可用性测试中的被试特征。
当描述被试特征时，首先要牢记招募合适数量的被试。当说到参与测试的被试数量时，最重要的原则是“你不可能有太多被试”。从结果在统计学上的有效性考 虑，小样本量缺乏统计效力，无法检验组间的差异显著性。真实的实验设计中，你必须确保每个条件下至少有10-12名被试。但是，对于非正式的可用性测试来 说，研究证明，有4-5名具有代表性的用户就够了。这群代表目标群体的被试将会发现产品80%的可用性问题，而这80%正是产品的主要问题。当然，如果你 有时间或资源去测试超过4-5名的被试，你有可能会发现另外20%产品的重要问题。
我们参与的很多测试同样印证了上述原则。在某个测试中，Jeff测试了8名被试，其中80%的问题在对前4名被试的测试中就已经发现了。但是，第8名 被试，也是最后1名被试，在某个任务中出现了严重错误，不得不寻求产品的呼叫帮助。如果只测试4名被试，我们将永远无法发现这个严重问题。如果你的测试经 验还不丰富，那招募尽可能多的被试无疑会降低漏掉重要问题的可能性，同时也提供了额外机会锻炼你的测试技能。
如果你没有时间和大笔预算，你可能会想要试下“打折”的可用性测试：在开发周期内进行几次小型的，迭代的可用性测试。一场测试招募4-5名目标用户， 进行1-2组任务条件，将结果应用到界面设计中。随后，进行另一场规模和任务类似的测试。3-4次测试后，你已经有了相对较大的样本量，并且开发团队也能 发现不同测试间的变化。
图5-3 被试特征及合理人数示例
描述测试方法
测试计划的这部分将会详细叙述如何对被试进行研究，以及如何展开测试。实质上，测试方法就是你测试设计的大纲：被试到达至被试离开的整个测试过程中的 每一节点的细致阐述，以便测试观察者可以大概了解内容。为何测试计划中需要包含如此多的细节内容?下面列出的理由可以解开你的疑惑。
■它帮助其他人员理解测试的过程并使之可视化呈现，以便他人可以提出意见或建议。
■ 它有助于你从测试执行者的角度关注被试到达前需要准备的材料和事项。
■它提醒你需要将测试计划与其他资源方沟通协调。譬如前台，当被试到来时不至于忘记问候。
■它使多个测试主持人(如果测试计划需要如此的话)可以遵照相似的流程和规范执行测试。
设计测试是可用性专家必备的且具有高度专业性的技能，通常涉及实验设计和方法，以及基础的统计分析知识。设计可用性测试，首先需要明确和理解测试目 标，然后根据提出的测试问题设计出解决问题的最有效的测试计划。如果测试设计是有缺陷的，或者执行测试时没有严格的实验控制，那结果会是不可信的。这不仅 会导致错误的建议，更糟糕的是会直接损害组织中可用性工程的建设。因此，在进行可用性测试前，请富有经验的同事审阅你的测试计划，听取他们的建议和反馈是 非常重要的。
测试设计主要以两类测试目标——产品本身和产品的使用者为基础。现有的资源、阻碍甚至是你的创造力，都会极大地影响设计成果。时间、金钱、管理层和开 发团队的支持、被试招募的能力，以及其他现实生活中的问题都会成为限制因素。下文将列出几个你可能会遇到的，常见情形中的测试设计案例。另外，我们给出了 一些确保实验严格性的指导原则。
最简单的测试设计：测试几名不同用户，用户均属于同一类型(如老年人)，要求他们完成网站不同部分的某些有代表性的任务。
独立组间设计或被试间设计
顾名思义，独立组间设计是指网站的每一部分都是由不同的用户测试的。如下表所示，组间设计要求15名被试，每名被试仅完成一个任务。这样会消除任务的 先后顺序造成的潜在的学习迁移效应。用户完成任务A可能会帮助他们顺利完成任务B，因此与任务B有关的可用性问题很难被发现。另外，如果每个任务都非常 长，被试有可能疲惫，你也应该使用这种设计。
被试内设计
测试15名被试有可能是难以实现的。现实是，你只有5名被试，不得不让他们每人都完成全部的3个模块。这就是被试内设计。但是，你需要考虑学习的迁移效应。你可以使用平衡抵消的技术来消除学习效应。
为了平衡抵消，如下图所示，你需要改变任务的顺序，每名被试完成任务的顺序是不同的。任务顺序随机化减弱了迁移效应，在上述例子中你最少只要4名被试 就够了。但是，随机化顺序会引起其他问题。在日常生活中很多流程本身就是有顺序的(譬如注册后才能进行付款)，如此一来你就不得不做出权衡：到底是让用户 按照正常顺序完成任务，但有可能掩盖后续任务的可用性问题(可以测量被试在任务过程中是否有学习效应)呢?还是提供随机顺序的任务(一般是在实验室中)， 但被试有可能迷惑和陌生?大多数人同意你应该保持合理的任务顺序。如果你决定这样做的话，你需要注意可能的迁移效应。你可以在正式任务前，让被试预先进行 训练，使被试间的使用经验达到相同水平。另外，在进行完每个部分后被试要有间隔时间休息。
测量多个产品版本
现在让我们来看另外一种常规情况。譬如你想要比较某个产品的2个不同版本，版本A和版本B，以便确定最终设计采用哪个版本更好。同时，你想要比较两类用户组，主管和技术人员，使用产品的差别。这就相当于2×2的矩阵设计。
如果你采用独立组间设计，你的测试计划是表中的数量单元格指不同的被试。该设计需要16名被试，分配到4个不同的条件：4名主管使用版本A，4名技术 人员使用版本A，以此类推。如果你只有8名被试，那每个条件的单元格只有2名被试，这样每个类别的数据过少，测试结果可能是无意义的。但是，如果你让两组 的每名被试，主管和技术人员，都操作两个版本，使用一个版本后再使用另一版本。和前述例子一样，后测试的版本可能会有优势，被试在第一个版本的测试中可能 学会了某些任务。但是，另一方面，这种效应可能会反过来：被试在第一个版本中形成了某些习惯，而无法适应第二个版本，尤其是当两个版本差异非常大的话。不 管哪种情况，你的结果都会有偏差。
考虑到这种潜在的问题，你需要平衡两个版本的顺序。如上表所示，8名被试中，一半被试先测试版本A，另一本被试先测试版本B。注意，每个版本被第一次测试的次数和最后一次测试的次数是一样的，这样可以消除潜在的顺序偏差效应。
测试多个用户组别
现在让我们进入略微复杂的实际场景。假设你的用户档案包括两类不同的用户组：经理和柜员。你的测试目标之一，是了解两组或多组用户(经理和柜员)在使 用产品时是否存在差异;另一目标是每个用户组内的新手和专家用户的使用差异。因此在使用经验和工作类型这两个因素上，分别有两个水平。你的矩阵设计如下：
4类条件的被试都是不同集合的。也就是说，如果你想每类条件(也就是上图单元格)有4名被试，那总共需要16名被试。即使出于预算或时间的考虑，16 名被试太多(每个条件至少要有4名被试才能测量组间差异)，你也不能简单地就采用组间设计。你只能减少每个单元格中的被试数量或者是简化你的研究。要注意 的是，每个单元格的被试数量少于4时将会严重影响结论的推广。你可能需要简化研究，不再探索组间差异(图5.4)。
图5-4 测试方法举例
注意：如果你是可用性测试的新手，还不能信心十足地保证测试中的实验严格性，请务必使你的测试简单。测试越简洁明了，执行时更容易保证流程顺利和一 致。从简单精悍的研究中获得了有意义的结果，远比进行大型研究得到一堆无意义的数据要好得多。你最好尽早并尽可能多地开展可用性测试，它可是极为有用和划 算的。
相关阅读
问题描述：使用postman工具，用post请求向后台传送json数据，后台返回的是字符串的一个地址链接。但是postman的结果显示Unexpected 'h'
超实用压力测试工具-ab工具在学习AB工具之前，我们需了解几个关于压力测试的概念吞吐率（Requests per second）概念：服务器并发处理能力
希望通过我们的几篇文章，能够帮助你更好的了解A/B测试和置信区间，一起实现用A/B测试驱动产品优化。A/B测试的实质是对照试验，即通过
所谓脚本计划其实做淘宝直播前的一种规范，制定的目的就是为了让此次的直播更加的圆满，那么淘宝直播秒杀脚本如何去写呢?下面就这个
设计冲刺（Sprint）是一套用于解决棘手难题的五天式流程，是战略、创新、消费行为学、产品设计等领域的“超级精选专辑”，可以理解为设计