不过这些东西真的能帮助我们重用测试用例么？我想未必。测试用例的重用，应该是测试用例里面的设计思想的重用，而不是具体某个测试用例的，因为对于功能测试的测试用例来说，大多数的测试用例都跟某个具体的被测应用有想到大的关联性，例如要测试一个博客编辑器，对于MySpace的博客编辑器和facebook的博客编辑器来说，它们的主要功能是相似的，都有发表博客，编辑博客，修改博客等……但是由于这是两个不同公司的产品，他们的具体功能或者UI是完全不一样的，所以拿到的两套测试用例，也应该是不一样的。如果分别提取出测试用例的核心思想（就是那些可以重用的部分），应该能看到很多的共同点，或许会有这么一条共同的用例思想。

1. 打开博客编辑器
2. 点击插入视频的按钮
3. 粘贴视频代码
4. 点击保存，发布

期望结果是该视频能正确显示在博客上。

这条用例可以提取为“验证博客编辑器能够插入视频”，至于实现的细节，可能两家的处理不一样，可能前者用<object>标签，后者用<embed>标签。回到实际的测试用例，前者可能要求将博客编辑器切换到HTML编辑模式下，要看到<object>….</object>的代码，另外一个就是要检查有<embed>….</embed>的代码。其实测试用例是测试工程师之间的很好的沟通交流工具。通常在一些研讨会上，有人抛出一个问题“对于日期输入框大家会怎么进行测试”，大家接着七嘴八舌地进行讨论，这样的讨论结果就是大家都知道了一些，又好像不知道一些。如果这时候有人拿出自己的测试用例，那么会不会更加一目了然，更加有系统性？

在看完http://msdn.microsoft.com/en-us/testing/cc514239.aspx这篇文章以后，里面有一些测试的模式，这些也就是可重用的测试用例的一个例子，看完这些例子以后就会觉得这个测试用例的重用其实并不是那么抽象

CRUD模式（创建，获取，更新，删除）

1. 选择并确定出一条记录或者一个字段
2. 产生一个随机的等价类item
3. 检查这个新产生的item是没有存在的
4. 添加一个新的item
5. 读取并且验证这个item的正确性
6. 修改该item并且验证item确是已经被修改
7. 删除该item并且验证item缺少已经删除

以上测试用例可以应用于不同的场景，例如MySpace中的一个帐号，也可以是一条歌单，还可以是一篇博客。这种类型的用例才是可重用的，而不是发布一篇博客，修改博客，删除博客……测试用例的重用，也就是测试用例的精华部分，其设计思想，而不是一些存在QC,TD中的01010100101001。

Related posts:

1. VSTS 2010 Test Edition文章收集
2. software testing buzzword
3. 分享两个PPT，关于gcov和lcov，还有代码覆盖

Customer Requirements（客户需求）

Specifications（说明书），说明书是从需求转化而来，定义了产品是怎么样的，能干什么等等

Schedules（进度表）

Software Design Documents（设计文档）书上说的5种，有些也可能只是某文档的一部份而已。我自己见过比较常见的High-Level Design（概要设计）, Low-Level(Detail) Design（详细设计）。书上说的数据流图，状态转换图等等，有时候就出现在HLD里面了

Test Documents（测试文档）包括了测试计划，测试用例，问题报告，统计报告等……这里我自己讲讲体会，刚到SPSS实习的时候看文档的时候我看到了Test scrīpt这个名词，一开始我以为是自动化脚本，后发现其实就是Test Case，所以说这些所有名词都可以有其他叫法。

以上就是作为一个测试工程师会经常遇到的文档。

软件开发生命周期模型(Software Development Lifecycle Model)

最常见的就是瀑布模型，迭代模型。

这里讲一下我的体会，其实软件开发发展到现在，基本上已经没有纯瀑布模型，也没有纯迭代模型，他们之间都是在互相渗透着，所以只需要弄清楚一个总体个概念就行了，这就是：

分析-需求-设计-编码-测试-维护

Related posts:

1. 《Software Testing》第十八章 – 编写和跟踪测试用例
2. 《Software Testing》第二十一章 – 软件质量保证
3. 《Software Testing》第三章 – 软件测试