第十一章 软件设计与实现
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测试方法
①黑箱：指的是设计测试的过程中，把软件系统当做一个“黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是行为测试设计，即从软件的行为，而不是从内部结构出发来设计测试
②白箱子：指的是在设计测试的过程中，设计者可以“看到”软件系统的内部结构，并使用软件的内部结构及知识来选择测试数据及具体的测试方法。