构建之法读书笔记七

第十一章 软件设计与实现

11.2 图形建模和分析方法

思维导图、实体关系图、Use Case Diagram

11.3 其他设计方法

形式化的方法、文学化编程

11.5 开发阶段的日常管理

第十二章 用户体验

12.1 用户体验的要素

用户的第一印象

从用户的角度考虑问题

软件服务始终都要记住用户的选择（长期的使用只会使软件更好用）

短期刺激 长期影响

不让用户犯简单的错误

注重用户体验和质量

情感设计

12.3 评价标准

对于一个软件的用户界面，我们有没有什么评价标准呢？可以参考费茨法则（Fitts law）、Nielsen启发式评估十条原则以及其他经验。下面是邹欣老师在自身实践的基础上总结的一些原则：

1. 尽快提供可感触的反馈系统状态

2. 系统界面符合用户的现实惯例（Familiarity，Avoid Surprise）

与用户沟通，软件系统要使用用户语言而不是开发者语言，所用的概念要贴近生活实际，而不是用学术概念或开发者的概念。我们说的生活实际，最好是目标用户的实际生活体验。

3. 用户有控制权

操作失误可回退，要让用户可以退出软件（很多软件都没有退出菜单，这是导致用户反感的一大原因）。用户可以定制显示信息的多少，还可以定制常用的设置。

4. 一致性和标准化

在软件中，对同一事物和同类操作的表示用语，各处要保持一致。例如，某词典软件有“帮助用户收集生词并且背诵生词”的功能。这个功能要有明确一致的称呼，不能混杂着叫“单词本”、“生词本”、“Word List”、“Word Book”、“单词文件”……等等。

5. 适合各种类型的用户

6. 帮助用户识别、诊断并修复错误

7. 有必要的提示和帮助文档

不需要文档，用户就能使用自如，当然更好，必要时还可以提供在线帮助。如果软件和用户的工作相关（而不是简单的游戏），那么基本的提示和帮助文档还是很有必要的，而且也要提供便利的检索功能。文档要从用户的角度出发描述具体步骤，并且不要太冗长。

第十三章 软件测试

13.1 名词解释

Bug ：软件的缺陷

Test Case ：测试用例。测试用例描述了一个完整的测试过程，包括测试环境、输入、期望的结果等

Test Suite ：测试用例集。即一组相关的测试用例

13.2 Bug解释与实例

①Bug可以分解为：症状（Symptom）、程序错误（Fault）、根本原因（Root Cause）

症状：即从用户的角度看，软件出了什么问题

程序错误：即从代码的角度看，代码的什么错误导致了软件的问题

根本原因：错误根源，即导致代码错误的根本原因

②Bug例子

症状：用户报告，一个windows应用程序有时会有在启动时报错，继而不能运行

程序错误：有时候一个子窗口的handle有空，导致程序访问了非法内存地址，此为代码错误

根本原因：代码并没有确保创建子窗口，因此子窗口的handle变量有时会在访问时处于未赋值状态（为空），导致出现代码错误

13.3测试方法

①黑箱：指的是设计测试的过程中，把软件系统当做一个“黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是行为测试设计，即从软件的行为，而不是从内部结构出发来设计测试

②白箱子：指的是在设计测试的过程中，设计者可以“看到”软件系统的内部结构，并使用软件的内部结构及知识来选择测试数据及具体的测试方法。