我看“阿里巴巴测试难题”——2

吃完午饭，没有象往常那样在楼下遛弯，直接上来，不为别的，只是为了梁兄那篇《阿里巴巴测试难题》，呵呵。

天啊，地啊，上帝呀菩萨呀，洋洋洒洒写了40分钟的一篇文章怎么能就这么没了呢？中间只是不小心碰了一下BackSpace回退键呀！163的blog还有记忆功能，怎么这个blog怎么就没有呢？

没办法，从头开始写吧。不过不是现在，等下班后或者明天再说吧。55555 55555 55555

（三) 测试标准

5 如何在没有单元测试代码情况下，度量代码测试覆盖率

没有代码还要度量测试覆盖率？我猜想这个测试覆盖率应该指的是代码的结构覆盖率吧。在几个月之前，我肯定会回答“这是不可能的”。但现在，倒是可以讨论一下，因为在此期间我了解到有一个工具可以对目标码做覆盖率测试，它就是VerOCode，简单介绍如下

VEROCODE is a verification tool to support structural coverage analysis of safety critical applications.  Analysis is performed at the executable code level and satisfies the coverage analysis objectives of DO-178B for Level A applications.

虽说看起来它可以针对执行码（目标码）做覆盖率分析，但我认为它满足不了梁兄的要求，两点：

X 它针对的是safety critical applications，面向的是以DO-178B for Level A为目标的应用，即高可靠的安全系统，通常是嵌入式的应用，它的客户都是boeing、airbus之类的民航制造公司，因为只有他们最关心DO-178B标准。普通的互联网公司不适合使用，也不是目标客户；

× 上面的说明决定了它不会是一个通用的测试软件，所以它价格非常昂贵（从国外BBS里了解到的）。

总之，根据我的了解，在没有代码情况下想要度量覆盖率，目前还做不到。如果谁知道有这样的方法，请及时告诉我。先谢了。

相反我倒觉得(五) 测试新技术的应用与推广  

2 白盒测试工具引入及白盒技术等
如：单元测试工具Junit, parasoft的白盒测试工具使用与引入等。

这个对互联网公司很适合，无论是开源的Junit还是商业的parasoft的Jtest，但这些工具引入后实施对象不应该是测试组，我觉得开发组在编码过程中使用、测试组适当监督会更合适。Parasoft的单元测试工具真的不错，无论是针对C/C++的c++test，还是针对JAVA的Jtest，或者针对.NET的.TEST，毕竟parasoft已经有整整20年的技术积累了。2008年是Parasoft成立20周年。

至于(四) 测试管理

2 如何有效度量测试工程师的绩效？

的确是一个很麻烦的问题，它也困扰我很久。51testing的“每周一问”4月份第2周的题目就是我提出的类似的问题，请看http://bbs.51testing.com/thread-111440-1-1.html

虽说我对当时的“最佳答案”并不太满意，但说老实话，暂时的确也想不出更好的办法。参考一下吧。

(三) 质量管理平台

2 项目管理、需求管理、缺陷管理多个系统入口， 并没有统一关联。另外代码与需求之间映射关系随着业务变更也难以一一映射

这是一个处在快速发展的团队常常面临的问题。就好比我们的国防，当然美国的国防也这样，只是比我们先行一步。

我们的解放军海陆空，包括二炮，随着军队信息化的推进，每个军种都有了自己的指控系统，在过去的很多年里，大家都相安无事。但随着现代战争的发展，时代要求所有军种协同作战，不同军种之间信息也要完全畅通，原来的指控系统已经不能满足现代的需求。

人非圣贤，代表着国家最高水平的军队都这样，何况是偶们普通的开发团队呢。

团队开始运作一段时间，意识到了测试的重要，于是有了专门的测试组，经历了一段“用word记录bug”的时期，逐渐认识到了bug也需要管理，于是有了缺陷管理系统；

随着团队认识的不断加深，我们明白了“光靠测试发现bug是远远不够的”，混乱的需求还会导致测试难度的加大，于是我们有了需求管理系统，从项目开始就要把需求变更管好；

慢慢的，我们还有了配置管理系统、项目管理系统等等。

按理说该有的我们都有了，应该一切ok了？不，我们遇到了难度更大的问题，甚至它可能让我们原来的工作前功尽弃。这个问题就是各个管理系统之间如何协作。我们需要在“需求—设计—测试—BUG，以及配置管理项”之间建立映射关系，但在以前做那些管理系统的时候，我们没有想到今天将会面临这样的难题。

在软件管理领域，国外的发达国家比我们真的要先进。我们今天遇到的问题，他们昨天已经遇到了，这一点从国外那些主流的商业软件上就能看出，如下面一些主流软件的桥接图

不同的工具都提供了接口，使得从需求到bug到配置管理都提供了双向的接口，这样我们就可以很容易

×从bug追溯到测试用例—代码设计—需求

×一旦某个需求变更，很容易做影响分析，很快就明确受到影响的代码设计，需要重新执行的测试用例等

说了这么多，我想说的是如果你现在要上管理系统，我个人觉得最好不再闷头自己研发了，有钱的采用上面提到的主流商业软件，手头紧的用一些主流的开源软件，这样也会为以后的扩展留下充分的空间。

但如果原来那么多自研的管理系统要实现无缝协作，可能就要对原来的产品设计做比较大的修改，各自互相开放通信接口，估计会比较麻烦。

好像有点文不对题了，呵呵，随便看看吧，一家之言。