《构建之法》读书笔记——第13章 软件测试

第13章 软件测试

13.1 基本名词解释及分类

团队统一思想要从基本名词解释开始。

         Bug：软件的缺陷

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

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

 

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

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

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

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

13.1.1 按测试设计的方法分类

测试设计有两类方法：黑箱（Black Box）和白箱（White Box）。

13.1.2 按测试的目的分类

1. 功能测试

测试名称	测试内容
Unit Test	单元测试——在最基本的功能/参数上验证程序的正确性
Functional Test	功能测试——验证功能模块的功能
Integration Test	集成测试——验证几个互相有依赖关系的模块的功能
Scenario Test	场景测试——验证几个模块能否完成一个用户场景
System Test	系统测试——对于整个系统功能的测试。
Alpha/Beta Test	外部软件测试人员（Alpha/Beta测试员）在实际用户环境中对软件进行全面的测试

 

2. 非功能测试

测试名称	测试内容
Stress/Load Test	压力测试——测试软件在负载情况下能否正常工作
Performance Test	效能测试——测试软件的效能
Accessibility Test	可访问性测试——测试软件是否向残疾用户提供了足够的辅助功能
Localization/ Globalization Test	本地化/全球化测试
Compatibility Test	兼容性测试
Configuration Test	配置测试——测试软件在各种配置下能否正常工作
Usability Test	易用性测试——测试软件是否好用
Security Test	软件安全性测试

 

13.1.3 按测试的时机和作用分类

测试“烽火台”

测试名称	测试内容
Smoke Test	冒烟测试——测试不通过，则不能进行下一步工作。
Build Verification Test	验证构建是否通过基本测试
Acceptance Test	验收测试——全面考核某方面的功能/特性

 

不同的测试方法

测试名称	测试内容
Regression Test	“回归”测试——对一个新的版本，重新运用以往的测试用例，确认新版本相比已知版本有无“退化”（Regression）
Ad hoc（Exploratory）Test	随机进行的、探索性的测试
Bug Bash	Bug大扫荡——全体成员参加的找“小强”活动
Buddy Test	伙伴测试——开发人员（伙伴）作为测试人员测试特定模块

 

13.2 各种测试方法

13.2.1 单元测试（Unit Test）

13.2.2 代码覆盖率测试（Code Coverage Analysis）

13.2.3 构建验证测试（Build Verification Test，BVT）

顾名思义，构建验证测试是指在一个构建完成之后，构建系统会自动运行一套测试，验证系统的基本功能。在大多数情况下，这些验证的步骤都是在自动构建成功后自动运行的，有些情况下也会手工运行，但是由于构建是自动生成的，我们也要努力让BVT自动运行。

13.2.4 验收测试（Acceptance Test）

在MSF敏捷建模中，我们建议还是采用场景来规划测试工作。

13.2.5 “探索式”的测试（Ad hoc Test）

就是指为了某一个特定目的而进行的测试，且就这一次，以后一般也不会重复测试。在软件工程的实践中，“Ad hoc”大多是指随机进行的、探索性的测试。

13.2.6 回归测试（Regression Test）

回归测试不仅仅包括单元测试，也包括其他类型的测试。

13.2.7 场景/集成/系统测试（Scenario/Integration/System Test）

在软件开发的一定阶段，我们要对一个软件进行全面和系统的测试，以保证软件的各个模块都能共同工作，各方面均能满足用户的要求。这类测试叫系统/集成测试。

13.2.8 伙伴测试（Buddy Test）

伙伴测试是指开发人员可以找一个测试人员作为伙伴（Buddy），在签入新代码之前，开发人员做一个包含新模块的私人构建（Private Build），测试人员在本地做必要的回归/功能/集成/探索测试，发现问题直接与开发人员沟通。通过伙伴测试把重大问题都解决了之后，开发人员再正式签入代码。

13.2.9 效能测试（Performance Test）

1. 设计负载

2. 令用户满意的服务质量

13.2.10 压力测试（Stress Test）

压力测试要验证的问题是：软件在超过设计负载的情况下是否仍能返回正常结果，没有产生严重的副作用或崩溃。

13.2.11 内部/外部公开测试（Alpha/Beta Test）

13.2.12 易用性测试（Usability Test）

13.2.13 “小强”大扫荡（Bug Bash）

13.3 实战中的测试

实战中的测试是在项目的稳定阶段执行的。团队在这一阶段的核心任务是：在满足最低接受条件的前提下，提高各个部分的质量。

13.3.1 似是而非的测试观念

13.3.2 测试工作中的文档

13.4 运用测试工具

下面的均略。

13.4.1 运用工具记录手工测试

13.4.2 运用工具记录自动测试

13.4.3 如何测试效能

13.5 练习与讨论