构建之法阅读笔记05

第11章　软件设计与实现

图形建模和分析方法:我们要给事物建造出一个“模型”，描述事物、事物的属性、事物之间的关系（静态的）以及各个事物之间的信息传递。现在流行的UML就是用图来表示软件的事物，人，用例之间的关系。但是代码的关键依然是用智慧解决计算机问题。

代码完成就是指工程师认为所有应该写的代码都写了，所有应该实现的功能都实现了（但未必没有问题）。但是这样的软件仍然不能发布，因为还有各种各样的bug，经过测试后将关键的bug解决后才可以发布bate版。

每日构建，是软件的必备，不构建就不能调试软件的，不能找出错误。这样会大大增加后期的问题。所有熟练度技术都是在实际操作中获得的。测试出来 的bug必须要 定时修复，不然可能会导致大的错误。小强地狱——让Bug多的队员专心修复Bug，不要开发新功能

第12章　用户体验

用户体验的要素：用户的第一印象：用户和软件的第一次使用，很大程度上决定了用户对软件的评价。怎样让用户在第一次使用的时候，少花时间（或者不花时间）在对用户没有价值的部分（如配置软件的基本设置、登录、填写用户的各种属性等），而把大部分时间花在有实际价值的功能。大胆的“减法”：从用户的角度考虑问题，这需要有“同理心”。软件团队的设计师和软件工程师有“同理心，什么是同理心？就是理解别人的处境、心理、动机的能力　。用户没有那么笨。

软件用得越多，越来越好用：软件要能记住用户的选择，习惯等等，让用户不再多次选择同样的东西。

不让用户犯简单的错误：软件要有对用户可能范的错误，进行预防。

评价标准：1. 尽快提供可感触的反馈系统状态2. 系统界面符合用户的现实惯例3. 用户有控制权4. 一致性和标准化5. 适合各种类型的用户6. 帮助用户识别、诊断并修复错误7. 有必要的提示和帮助文档

第13章　软件测试

    基本名词解释及分类：Bug：软件的缺陷2.Test Case：测试用例，测试用例描述了一个完整的测试过程，包括测试环境、输入、期望的结果等。3.Test Suite：测试用例集,即一组相关的测试用例。

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

1）症状：即从用户的角度看，软件出了什么问题。例如，输入（3211）时，程序出错退出。

2）程序错误：即从代码的角度看，代码的什么错误导致了软件的问题。例如，代码在输入为某种情况下访问了非法的内存地址——0X0000000C。

测试设计有两类方法：黑箱（Black Box）和白箱（White Box）。所谓黑箱/白箱，是指软件测试设计的方法，不是软件测试的方法。测试的范围由小到大，测试者也由内到外——从程序开发人员（单元测试）到测试人员，到一般用户（Alpha/Beta测试）。构建验证测试是指在一个构建完成之后，构建系统会自动运行一套测试，验证系统的基本功能。在大多数情况下，这些验证的步骤都是在自动构建成功后自动运行的，有些情况下也会手工运行。伙伴测试（Buddy Test）：开发人员可以找一个测试人员作为伙伴（Buddy），在签入新代码之前，开发人员做一个包含新模块的私人构建（Private Build），测试人员在本地做必要的回归/功能/集成/探索测试，发现问题直接与开发人员沟通。通过伙伴测试把重大问题都解决了之后，开发人员再正式签入代码。效能测试（Performance Test）用户使用软件，不光是希望软件能够提供一定的服务，而且还要求服务的质量要达到一定的水平。软件的效能是这些“非功能需求”或者“服务质量需求”的一部分。压力测试（Stress Test）压力测试严格地说不属于效能测试。压力测试要验证的问题是：软件在超过设计负载的情况下是否仍能返回正常结果，没有产生严重的副作用或崩溃