《构建之法》（六）

本周主要看了第13章，第14章的前一部分。主要开始讲设计开发完成后的进一步优化完善。比如做软件测试，软件质量保障等

第十三章 软件测试

一、基本名词解释及分类
bug：软件缺陷
Test Case：测试用例，描述一个完整的测试过程。
test suite：测试用例集，就是一组相关的测试用例

bug可分解为：
症状（symptom）：从用户角度看，程序出现了什么问题
程序错误（fault）：从代码角度看，设么错误导致的上述问题
根本原因（root cause）

a. 按测试方法分类
黑箱：也就是注重软件的行为而不是内部结构
白箱：根据内部结构和知识来选择测试数据及具体的测试方法

b. 按测试目的分类：
功能测试：测试范围由小到大，测试者由内到外
非功能测试：除了基本功能外的特性，也叫服务质量需求。

c. 按测试的时机和作用分类：


二、各种测试方法

1. 单元测试(详见第二章第一节)

2. 代码覆盖率测试（单元测试一般在项目开发阶段）
不同的代码是否执行，有很多种组合。一行代码被执行过，不代表没有出现问题 代码覆盖并不能测出未完成的代码导致的错误

3. 构建验证测试（开发阶段）
指在一个构建完成后，构建系统自动运行一套测试，验证系统的基本功能。(构建系统(build system)：用来从源代码生成用户可以使用的目标(targets)的自动化工具。目标可以包括库、可执行文件、或者生成的脚本等等。)通过BVT的构建可以成为可测，即团队可以用这一版本进行各种测试，因为它的各种功能都是可用的。

4. 验收测试
按照测试计划，测试各各自负责的模块和功能，并验证测试结果的成功与失败。

5. 探索式测试
往往不进行重复测试
一些风险很大的领域（一旦出了安全问题就会有很大威胁），就要多鼓励一些探索式测试

6. 回归测试(详见第二章)
7. 场景/集成/系统测试
对软件进行全面和系统的测试，以保证软件各个模块都能共同工作，各方面均能满足用户要求。
8. 伙伴测试
9. 效能测试
验证的问题是：软件在设计负载内能否提供令用户满意的服务质量
10. 压力测试
11. 内部/外部公开测试
12. 易用性测试

三、实战中的测试
是在项目稳定阶段执行的。团队在这一阶段的核心任务是：在满足最低接受条件的前提下，提高各个部分的质量。
测试工作中的文档：
测试设计说明书(TDS)
测试用例(Test Case)
错误报告(Bug Report)
测试修复，关闭缺陷报告(Resolve)
测试报告(Test Report)

如何测试效能
除了功能方面的测试外，我们还要测试那些“服务质量”。如效能测试、负载测试、压力测试。我们在第7章中讲到了这三种测试的区别。在Stone 项目中，以产品搜索为例，这三种测试的区别如下：
效能测试：在100个用户的情况下，产品搜索必须在3秒钟内返回结果。 
负载测试：在2 000个用户的情况下，产品搜索必须在5秒钟内返回结果。
压力测试：在高峰压力（4 000个用户）持续48小时的情况下，产品搜索的返回时间必须保持稳定。系统不至于崩溃。

第十四章 质量保障

1.软件=程序质量+软件工程质量
  软件质量=程序+软件工程

程序质量：体现在软件外在功能的质量
软件工程的质量：
软件开发过程的可见性（visibility）
软件开发过程的风险控制（risk management）
软件开发成本的控制（cost control）
内部自量指标的完成情况(Internal Benchmarks)

2.CMMI（capacity maturity model integrated）能力成熟度模型

衡量和管理项目。降低成本的同时提高了项目质量和完成率
两种实施方法
连续式：衡量企业在某一个项目中的管理能力
阶段式：衡量一个企业的成熟度