按测试的时机和作用分类

　　在开发软件的过程中，不少测试起着“烽火台”的作用，它们告诉我们软件开发的流程是否顺畅，这些测试如表7-3所示：

表7-3  烽火台

 

 

测试名称

测试内容

Smoke Test

“冒烟”——如果测试不通过，则不能进行下一步工作

Build Verification Test

验证构建是否通过基本测试

Acceptance Test

验收测试，为了全面考核某方面功能/特性而做的测试

　　另一些测试名称，则是说明不同的测试方法，如表7-4所示：

表7-4  不同测试方法

 

 

测试名称

测试内容

Regression Test

“回归”测试——对一个新的版本，重新运行以往的测试用例，看看新版本和已知的版本相比是否有“退化”（Regression）

Ad hoc (Exploratory) Test

随机进行的、探索性的测试

Bug Bash

Bug大扫荡——全体成员参加的找“小强”活动

Buddy Test

伙伴测试——测试人员为开发人员（伙伴）的特定模块作的测试

 

　　单元测试（Unit Test）

　　二柱：我们也试过用单元测试来保证质量，要求每人都要写，在签入代码前必须通过单元测试。但是搞了几个星期不了了之。

　　大家七嘴八舌地列举了单元测试的问题：

　　◆  有时单元测试报了错，再运行一次好了，后来大家不想花时间改错，多运行几次，有一次通过行了；

　　◆  单元测试中好多错都和环境有关，在别人的机器都运行不成功；

　　◆  花在单元测试上的时间要比写代码的时间还多，提高代码覆盖率到90%以上太难了；

　　◆  单元测试中我们还要测试效能和压力，花了很多时间；

　　◆  我们都这么费劲地测了，那还要测试人员干什么？

　　阿超：看来问题还不少，我们留到后面再谈（见后面“单元测试”的具体描述）。