利用 SharePoint Service 来实现软件测试管理

去年在参加 Microsoft Architect 2000 培训的时候，看到讲师在介绍 Microsoft 内部的开发管理工具 RAID 的时候，感觉它确实是一个经过实践检验的好东西，但它没有产品化，后来 Microsoft 和上海合资成立的微创公司参照 RAID 做出一个产品 —- BMS，本来以为这个东西会很好，后来碰巧别人送我一个试用版，结果一安装，让我大失所望，拙劣的界面、复杂的安装说明、速度慢，安装完用了一下就马上删除了，我在想，微创的高层管理人员也应该是 MS 的人呀，怎么做出这样一个四不象的产品，难道 MS 的这么多经验与技术到了中国的公司就马上失去了作用？不过这是当时的想法，据说现在微创 BMS 系统经过进一步的开发，已经十分稳定和有效了，但没有实证过。 

我主要是 Share 一下我的测试管理（主要是 Bug 管理）工具的实现方法，就是使用常见的 Windows SharePoint Services（或者早期的 SharePoint Team Services） ，以下是大概步骤：

1. 自定义一个列表（List），命名为“XXX项目测试管理”，并加到快速启动链接（Quick Launch）中
2. 在列表中然后自定义 Bug 的常用信息字段，如主题、级别、复现方法、测试数据、Bug 状态（BugStatus）等，Bug 的状态是“列表”类型数据，值的列表有：激活、关闭、重新激活等，也可以根据实际的测试流程增加其它中间状态，如“已解决，待复测”等
3. 根据 User Role 的不同，自定义不同的视图，如开发人员只看到处于“激活”状态的 Bug ( BugStatus=’激活’），测试人员可以增加新的 Bug，同时可以看到已回复的 Bug 的列表，非常方便
4. STS 的列表是可以订阅（Subscribe）的，所以当有新的 Bug 登记时，系统会自动发邮件通知相关的开发人员，当某一 Bug 被关闭时，也可通知测试人员进行回归测试
5. 可以做 Bug 的统计，分类
6. 对于早期的 SharePoint Team Services（STS） 来说，除文档库外，自定义列表中不能增加附件，而测试中经常可能会将出错屏幕抓下来，供开发人员参考，但对于新版本的 Windows SharePint Services（WSS）来说，列表中的每个条目都可以增加任意数目的附件，可以完全将 Bug 的附加信息、相关文件附在一起提交。

比较遗憾的是，WSS（STS）的列表统计中没有各种图表，不能进行以图形化的方式展示测试进展情况，如总 Bug 数、已解决 Bug 数及其比重，但对于一般的中小软件的测试来说， WSS（STS） 提供的自定义列表功能就可以完全满足要求，而且实现起来相当简单、方便。 

我曾经在一家大银行的某分行做整个核心系统的升级，利用这个测试管理站点（Bug管理工具），将有关的三四家软件开发商、分行、总行的软件开发项目组的 Bug 完全集中化管理，简单而有效，深受各方欢迎。

当然，也有更专业的 Bug 管理工具，如 Numega DevPartner、Rational TestManager、TestTrack、Bugzilla等，但我感觉使用 WSS（STS） 实现起来最方便，而且是 Web Based ，不用安装客户端，用起来也最简便，这也算是我的一个比较好的、具有实践价值的 Best Practise 吧 。