《构建之法》阅读笔记5

由于很长时间没有写阅读笔记了，之前看的一些内容没来得及做记录，所以就从现在看的这些写起吧。

 用户体验（12）

用户体验的要素：

用户的第一印象，用户安装软件之后，软件第一次启动，软件设计者要给用户什么样的第一印象？用户头一回来访问你的网站，你要给他们什么样的第一印象？

很多软件设计者把用户界面等同于给领导汇报的工作成绩单，所有的功能都争先恐后地出现在用户面前，唯恐用户没有注意到。但是用户往往会被繁乱的界面弄得晕了头，无所适从，诸如电视遥控器。

还有的软件把自己当成一个毫无感情的工具，早期的一些字处理软件就是这样。用户启动软件后，看到屏幕上部出现了一行菜单，紧接着好几行小按钮，下面就是全白的屏幕。有更好的设计么？

我们至少可以考虑以下两点。

谁会是我们的目标用户？他们是什么样的人？他们的使用方式是什么样的？用户是从哪里进入到这个软件或网站？他们知道这个产品是做什么的吗？用户想达到什么目的？怎样让他们尽快找到相应的功能入口，完成任务？我们的软件可能比难用（学习曲线较陡），怎样才能让用户尽快掌握基本功能？

用户和软件的第一次使用，很大程度上决定了用户对软件的评价。怎样让用户在第一次使用的时候，少花时间（或者不花时间）在对用户没有价值的部分（如配置软件的基本设置、登录、填写用户的各种属性等），而把大部分时间花在有实际价值的功能（如完成任务、消费内容、创建内容）上？

从用户的角度考虑 曾有网友爆料，福建某银行公布的反假币电子邮箱地址长度超过70个字符（字母和数字组成）。该银行工作人员解释称，该地址在内部使用时是中文，和外网衔接时会变成一长串代码。有网友根据GBK编码翻译出部分代码对应的汉字为“出纳与现金管理”。 我们试着想一下事情的经过： 领导/项目经理：要公布一个电子邮箱地址，让人民群众能发邮件投诉假币和其他事情！

技术人员：好，内网地址搞好了，工具自动转成外网的地址。搞定！

测试人员：把邮件地址复制/粘贴到电子邮件的地址栏，发送一个邮件试试看，收到了么？收到了。好，通过！

项目经理：好，把邮件地址印成提示牌，搬到各地的营业处去！

软件服务始终都要记住用户的选择

用户使用任何软件来解决问题，软件从头到尾的各个部件要结合起来把用户的问题给解决了。这样的问题，可以通过“基于场景的设计”来强化团队成员对用户体验连贯性的理解。

短期刺激和长期影响

很久以前，百事可乐和可口可乐在市场上竞争很激烈，有一次，百事宣布其新型饮料在用户试验中大获好评，测试用户“尝了都说好”，可口可乐公司立马买了对方的饮料，在自己的实验室也做用户实验。不料结果真的像竞争对手说的那样，大部分用户都很喜欢百事公司的新饮料。这下可口可乐公司里的一些人士开始着急了，纷纷寻找对策。但是过了几个月，市场数据显示这个在实验室里很受欢迎的饮料并没有产生巨大的销量，这是怎么回事？是投放市场不对，还是供货跟不上，又或者是实验室里的用户撒谎？后来大家才知道在实验室里喝几口饮料和在消费者家里喝是很不一样的。在实验室里：大家心里想着，我要品尝饮料啦！漱口之后，品尝几口或一听饮料。反馈是：新产品甜味较大，口感很好，我喜欢！在家里：美国消费者一次买一箱（24听），随意坐在沙发里，一边看电视一边喝。反馈是：新产品甜味较大，喝多了太腻味，喝不下去了。再也不买了！

不让用户犯简单的错误

大家知道，战斗机有[紧急弹射座椅]这一功能，在紧急情况时，它能帮助飞行员逃生。这个按钮不应该藏得很隐蔽，不然飞行员在碰到紧急情况时半天找不到这个按钮。如果我们把[紧急弹射座椅]这一按钮放在战斗机控制面板上的这些常用按钮之中：[喷水刷窗] [FM电台] [弹射座椅] [机舱灯]可以想象有不少悲剧会发生，飞行员想打开调频电台，啊……这一设计也可以称为——“脑残设计中的战斗机”。 “不让用户犯简单的错误”（Fool Proof）的原则当然是大多数人都同意的，高明的设计能让操作者不需要花费额外注意力，也不需要经验与专业知识即可凭直觉完成正确的操作。

软件测试（13）

各种测试方法

单元测试

代码覆盖率测试（Code Coverage Analysis）

代码覆盖率，简单来说就是代码被执行过，就是被“覆盖过”。如果一段程序运行一组测试用例之后，100%的代码被执行了，是不是意味着再也不用写新的测试用例了呢？答案是否定的。这是因为不同的代码是否执行，有很多种组合。一行代码被执行过，没有出现问题，并不表明这一行代码在所有可能条件的组合下都能正确无误地运行。

代码覆盖不能测出未完成的代码（所缺少的逻辑）导致的错误。比如：

没有检查过程调用的返回值；

没有释放资源。

代码覆盖不能测出效能问题。

代码覆盖不能测出时序问题，即由时序导致的程序错误（例如：线程之间的同步）。

所以，不能简单地以代码覆盖率来衡量代码中与用户界面相关的功能的优劣。

构建验证测试（Build Verification Test，BVT）

顾名思义，构建验证测试是指在一个构建完成之后，构建系统会自动运行一套测试，验证系统的基本功能。在大多数情况下，这些验证的步骤都是在自动构建成功后自动运行的，有些情况下也会手工运行，但是由于构建是自动生成的，我们也要努力让BVT自动运行。

通过BVT的构建可以称为可测（Testable），意思是说团队可以用这一版本进行各种测试，因为它的基本功能都是可用的。反之，通不过BVT的构建称为“失败的构建”（Failed，Rejected）。如果构建验证测试不能通过，那么自动测试框架会针对每一个失败的测试自动生成一个Bug（小强）。一般来说，这些Bug都有最高优先级，开发人员要首先处理。大家知道，维持每日构建，并产生一个可测的版本是软件开发过程中质量控制的基础。对于导致问题的小强，我们有以下几种应对：

找到导致失败的原因，如果原因很简单，程序员可以立即修改并直接提交。

找到导致失败的修改集，把此修改集剔出此版本（程序员必须修正Bug后再重新把代码提交到源代码库中）。

程序员必须在下一个构建开始前修正该Bug。

效能测试 效能测试要验证的问题是：软件在设计负载内能否提供令用户满意的服务质量。这里涉及如下两个概念。

1. 设计负载 首先要定义什么是正常的设计负载。从需求说明出发，可得出系统正常的设计负载。例如，一个购物网站，客户认为正常的设计负载是每分钟承受20次客户请求。

2. 令用户满意的服务质量 其次要定义什么样的质量是令用户满意的。比如，同一个购物网站，用户满意的服务质量可以定义为：每个用户的请求都能在2秒钟内返回结果。