用户体验：
要素：用户的第一印象，谁是目标用户，什么样的人，使用方式，从哪里进入软件，知道是做什么的吗，用户用软件的目的，怎样使用户找到自己想要的功能以及掌握基本功能。（5W1H方法（who,when,where,what,why,how））
从用户的角度考虑问题：同理心
用户需要帮助，但是并没有那么笨
团队成员都尽可能在实际工作和生活中使用自己开发的产品（从内部测试部开始）
通过“基于场景的设计”来强化团队成员对用户体验连贯性的理解
UI设计：头一次使用产品的用户和第N次使用产品的用户
短期刺激和长期影响都需要被考虑到
高明的设计：不需要花费额外注意力，也不需要经验与专业知识即可凭直觉完成正确的操作
情感的设计:本能层次——外形；行为层次——使用的乐趣和效率；反思层次——自我形象、个人满足感、回忆。
用户体验的一个重要目的就是要降低用户的认知阻力。
软件测试：
单元测试（Unit Test）——在基本的功能/参数上验证程序的正确性
功能测试——验证模块的功能
集成测试——验证几个互相有依赖关系的模块的功能
场景测试——验证几个模块能否完成一个用户场景
系统测试——对于整个系统功能的测试
内部/外部测试 Alpha/Beta测试——测试员在实际用户环境中对软件进行全面的测试
代码覆盖率测试（Code Coverage Analysis）
构建验证测试（Build Verification Test ,BVT）
验收测试（Acceptance Test）“探索式”测试（Ad hoc Test）
回归测试（Regression Test）场景/集成/系统测试（Scenario/Integration/System Test）
伙伴测试（Buddy Test）:写好单元测试，或者运用重构技术 以保持稳定性
效能测试（Performance Test）压力测试（Stress Test）
质量保障：
实现CCMI 能力成熟度模型集成 Capacity Maturity Model Integrated
安全幻想：“人肉认证”和安全的幻想“given enough eyeballs , all bugs are shallow”
稳定和发布阶段：
ZBB（zero bug build)、RC（release candidate）、RTM（release to manufacturer）
会诊小组（Triage Team）：
修复、设计本来如此、不修复、推迟
DCR（Design Change Request ）：
问题在哪，问题的影响；如果不修改，会有什么后果；几种修改方案，各种方案的优缺点和成本
最后回归测试、砍掉功能、修复Bug 的门槛逐渐提高、逐步冻结（让当前版本和将来的版本的工作分开进行）
版本发布：不同目标人群+不同发布频率的方式
发布之后——事后诸葛亮会议：
如果重新来过，什么方面可以做的更好？
多问几次为什么，层层推进
银弹：每个角色的代表在项目过程中可以使用有限次的“停止争论，按我说的办”
问题：
1，在12章中，从用户的角度考虑问题，讲到需要有同理心，但是真的有同理心就够了吗？我是觉得在初始版本可以只是满足先满足同理心的要求，但之后我觉得应该尽量做到有预测到用户可能会出现的问题，即尽可能在用户遇到问题前就已经解决问题或者有解决问题的方案
2.在短期刺激和长期影响中，我们生活中也有很多不那么合理的设置，例如电脑太低，使用电脑会不得不弯腰驼背，那有问题了，我们应该怎么更好地去面对和解决问题？
3.在用户体验设计的步骤和目标中，假若我们不断把认知阻力降低了，会不会有这样一个问题：我们使用软件结果和使用纸和笔的结果差不多，那么用户为什么使用我们的软件而不是直接用纸和笔呢？
4.在书上12章课后练习与讨论，第4题中，我觉得直接设置静音键这就是一种没有对于用户的同理心，静音只是一种结果，为什么不设置是什么情况下的静音呢
5.之前上课，老师讲到了CMMI，我觉得这是和我们生活中很密切的事情，我们为什么不都站起来，切实用这个模型做一些事情来更好地理解和体验CMMI呢
6.在伙伴测试中， 我们除了写好单元测试和运用重构技术以外，能不能模拟使用场景来假设数据来更好地测验我们的模块和功能