《Don’t Make Me Think》读书摘要，实践到新路由 WebUI 开发中。[ 2013 Q4 ]
一、可用性测试 (Web Usibility)
一次向一个用户展示一些内容（网站原型/页面草图），并且要求用户说出：
- 这是什么
- 试着用它完成一项典型的任务
测试的关键不是要证明什么或者反驳什么，而是了解你的判断力。例如，人们通常会认为，他们可以用测试来证明导航系统A比B更好，但这做不到，没有人有这样的资源来设置你所需要的受控试验。
测试能做的就是给你提供有价值的参考，加上你的经验、专业判断和常识能够让你更容易地在A和B之间作出更明智、也更自信的选择。
1.1 应该测试多少用户
很多情况下，每轮测试理想的用户数量是三个，最多是四个。
前三个用户很可能会遇到几乎所有最明显的问题，而且更重要的是多做几轮测试、而不是写下每轮测试里面发现的所有问题。
另外，由于你会修正在第一轮测试里发现的问题，因此在第二轮测试里，另外三名用户很可能发现一些新的问题，但他们不会再遇到第一轮中的那些问题了。
1.2 测试什么
- 理解测试：让测试用户看到网站，然后看他们能否理解这个网站，理解网站的目标、价值主张、组织方法、运行方式等
- 关键任务测试：让用户完成一些任务，然后观察他们是怎么做的。
1.3 测试过程示例
嗨，Janice... 我们在测试这个网站，不是你本人，在这里你完全没必要担心自己会出错；我们想要改进网站，因此我们需要知道你的真实想法，请别担心会伤害到我们的感情。
...如果你有问题，就尽管问。我也许不能马上回答这些问题，因为我们想知道如果没有别人在旁边的时候，人们会怎么做。
请看这个页面，然后告诉我你认为它是什么，还有，你觉得你可以先点击哪里
...
1.4 常见问题
每轮测试后，开发团队要尽快回顾每个人的观察。你从可用性测试中了解到的东西总会是很有意义，而且每个观察了这个过程的人都能看出这些过程。
记住，这是一个循环的过程，因此团队不必对完美的解决方案达成一致，你只要确定下一步做什么就可以了。
1.4.1 用户不清楚概念
他们就是不理解，他们看着网站或者页面，要么不知道它们说的是什么，要么他们自以为自己知道，但是理解有误。
1.4.2 他们找不到自己要的字眼
通常意味着：
- 你用来组织内容的分类不符合用户习惯
- 分类符合他们的习惯，但没有使用他们期望的名字
1.4.3 内容太多了
有时候，他们要找的内容就在页面上，但他们就是看不到，在这种情况下，你需要：
- 减少页面上的整体干扰
- 把他们需要看到的内容设置得更醒目，让它们从可视层次结构中更突出
1.5 问题分类指南（决定修正哪些问题）
- 忽略 Kayak（皮划艇问题）：用户暂时出现错误，然后又在不需要任何帮助的情况下回到原来轨道
- 抵制添加的冲动：当在测试时清楚地看到人们没有理解某些内容时，大部分人第一反应是添加一些内容（例如一些注释或一些指导说明）。然而正确的解决方案往往是去除某些让人混淆的内容，而不是增加另一些干扰
二、Use Case
2.1 什么是 Use Case
Use Case 描述了用户如何使用系统以实现某一特定目标。注意用例不是站在开发者的角度、而是在用户的角度来分解系统（用户并不想了解系统的内部结构和设计）。Use Case 考虑更多的是用户行为及交互情形，即定义系统对于用户的外部行为。
A USE CASE is a software and system engineering term that describes how a user uses a system to accomplish a particular goal. A use case acts as a software modeling techique that defines the features to be implemented and the resolution of any errors that may be encountered.
Use Case 可以通过自然语言、或活动图、状态机等表达。关于用例文档，参考以下模板 (RUP)：
- 简要说明 (Brief Description)： 介绍用例作用及目的；
- 事件流程 (Flow of Event)：事件流表现出所有的场景；
- 用例场景 (Use-Case Scenario)：包括成功场景和失败场景，场景主要是由基本流和备选流组合；
- 特殊需求 (Special Requirement)：描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）；
- 前置条件 (Pre-Condition)：执行用例前系统状态；
- 后置条件 (Post-Condition)：用例执行完毕系统可能的状态；
2.2 Use Case 不做的事情
- Implementation details: 不要描述实施细节，例如不要说明资料被存到 Oracle 数据库，而说资料将被存储就好
- GUI Information: 不要讲UI的内容
- Internal processing unrelated to a stakeholder request: 不要将与使用者无关的系统内部作业，这一点和第一项很像，就是不用讲过多的逻辑内容在里头
- Non-functional requirements: 要将非功能性需求，例如系统每秒操作要在2s内回应，同时上线人数要达3000人等