构建之法-13-软件测试

软件测试

本章介绍了一些主流的测试方法。

---

13.1 基本名词解释及分类

1. 介绍几个名词

Bug：软件的缺陷
Test Case：测试用例，测试用例描述了一个完整的测试过程，包括测试环境、输入、期望的结果等。
Test Suite：测试用例集,即一组相关的测试用例。

2. Bug的组成部分：

1. 症状（Symptom）：即从用户的角度看，软件出了什么问题。例如，输入（3211）时，程序出错退出。
2. 程序错误（Fault）：即从代码的角度看，代码的什么错误导致了软件的问题。例如，代码在输入为某种情况下访问了非法的内存地址——0X0000000C。
3. 根本原因（Root Cause）：错误根源，即导致代码错误的根本原因。例如，代码对于id1==id2的情况没有做正确的判断，从而引用了未赋值的变量，出现了以上情况。

3. 按测试设计的方法分类

黑箱：指的是在设计测试的过程中，把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是行为测试设计（Be-havioral Test Design），即从软件的行为，而不是从内部结构出发来设计测试。

白箱：指的是在设计测试的过程中，设计者可以“看到”软件系统的内部结构，并使用软件的内部结构和知识来选择测试数据及具体的测试方法。

4. 按测试的目的分类

   
   
   功能测试分类
   
   
   非功能测试

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

   
   
   测试“烽火台”

不同的测试方法

---

13.2　各种测试方法

1. 单元测试（Unit Test）

参看本书第2章“单元测试”一节

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

是指在一个构建完成之后，构建系统会自动运行一套测试，验证系统的基本功能。

3. 验收测试（Acceptance Test）

在“基本场景”的基础上，把系统在理论上目前支持的所有场景都列出来，然后按功能分类测试，如果测试成功，就在此场景中标明“成功”，否则，就标明“失败”，并且用一个或几个“小强”/Bug来表示失败的情况。

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

“Ad hoc”也意味着测试是尝试性的，“我来试试，在这个对话框中一通乱按，然后随意改变窗口大小，看看会出什么问题……”，如果没问题，那么以后也不会再这么做了。

5. 回归测试（Regression Test）

请看本书第2章“回归测试”一节的介绍

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

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

7. 伙伴测试（Buddy Test）

是指开发人员可以找一个测试人员作为伙伴（Buddy），在签入新代码之前，开发人员做一个包含新模块的私人构建（Private Build），测试人员在本地做必要的回归/功能/集成/探索测试，发现问题直接与开发人员沟通。通过伙伴测试把重大问题都解决了之后，开发人员再正式签入代码。在项目后期，签入代码的门槛会变得越来越高，大部分团队都要求缺陷修正（Bug Fix）必须经伙伴测试的验证才能签入代码库。

8. 效能测试（Performance Test）

1. 设计负载
   例如，一个购物网站，客户认为正常的设计负载是每分钟承受20次客户请求。
2. 令用户满意的服务质量
   例如，每个用户的请求都能在2秒钟内返回结果。
3. 设计负载的细化

• 设计负载的细化上面我们只提到“承受20次客户请求”，那么这些客户的请求到底是什么，可以按请求发生的频率来分类。
• 有些请求，是要对数据进行“写”操作，可以要求慢一些，比如“用户下订单，购买商品”，对这一服务质量，请求可以放宽为5秒钟，甚至更长。

9. 压力测试（Stress Test）

软件在超过设计负载的情况下是否仍能返回正常结果，没有产生严重的副作用或崩溃。

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

开发团队希望让用户直接接触到最新版本的软件，以便从用户那里收集反馈，这时开发团队会让特定的用户（Alpha/Beta用户）使用正处于开发过程中的版本，用户会通过特定的反馈渠道（E-mail、BBS、微博等）与开发者讨论使用中发现的问题，等等。这种做法成功地让部分用户心甘情愿地替开发团队测试产品并提出反馈。

11. 易用性测试（Usability Test）

“易用性测试”似乎更多地用来描述一套测试软件可用性的过程，这个过程一般不是由测试人员来主导的，而是由对软件设计和软件可用性有大量研究的“可用性设计师”来实行

12. “小强”大扫荡（Bug Bash）

一般是安排出一段时间（如一天），这段时间里所有测试人员（有时也加入其他角色）都放下手里的事情，专心找某种类型的小强

---

13.3 实战中的测试

1. 一些不正确的观念

测试在项目的最后进行就可以了。

测试就得根据规格说明书（Spec）来测，所以是很机械的。

测试人员当然也写代码，但是质量不一定要很高。

测试的时候尽量用Debug版本，便于发现Bug。

2. 测试工作中的文档

   
   
   测试工作中的文档

---

The End