讨论会后的思考

最近在忙活着建立一个更好（即更方便，更通用，设计更良好等等）的测试工具框架。于是请来了开发的L大人，一起进行了第一次正式的讨论。

2个小时下来，发现了我们没有经验，能力还有很大的不足，忽略了几个重要的问题。

1。设计前的需求分析。

一直觉得我们有在做啊，我们每个工具写之前不是都分析了好一阵子，还有文档呢。可是说到搭框架就傻眼了。想这里，想那里，结果都没有想到点子上。

我们想这么多小工具，每个小工具还有自己的一些配置文件，输入文件。我怎么把它们组织到框架里来呢。我是用一个exe呢，还是用多个呢。等等诸于此类的问题。

L老大一上来就问，你们现在有些什么，答曰很多小东西，很多不同格式的配置文件。很多不同格式的输出报告。

L老大说，那我们就分析他们，把他们归类，框架写各个类型配置文件的解释器。（有了点豁然开朗的感觉）

那我们是不是要保留一个自定义可扩展的类型呢？L老大答，尽量不要，增加案例实现者的难度而已。（感悟：自由度高的东西不见得很好，反而会引进一些麻烦）。

2。引入了测试覆盖率分析的概念。

这个概念是知道的，但似乎从来没有体会过其真正的内涵。

我们在讨论前一直有这样的一个观点，我们把工具写出来了。并没有办法代替手工的测试，手工测试还是继续干一样的活，还因为工具的引入而多了很多确认工具结果的工作。看起来工具的引入并没有给测试组带来效率的提高，反而是降低了效率。

那我能说工具引入会大幅提高软件质量吗？似乎也不行，因为工具能发现的问题实在太少太少。

于是我们在苦恼，工具怎样去代替一些可以代替的手工（其实这是一个误区）。

引入测试覆盖分析就可以解决上面的问题了（至少目前我知道的就只有这个最好了）。怎么说呢？L老大打了个比方，我们要测试的程序是一个桌子的平面，我们的工具是盖在桌子上的书，测试覆盖分析可以告诉我们书盖住了桌子哪些地方。这些地方就可以告诉我们被覆盖得较多的地方，代码相对是稳定的（对发布产品的风险预估也是有用的）；可以指导我们的手工测试去测哪些工具覆盖较薄弱，或根本没有覆盖的地方。wow，问题解决了！

可是通过写这个blog时，我又想到，那手工测试怎么知道测什么地方就是在测工具覆盖薄弱或没有覆盖的地方呢？看来这个问题还是需要再探讨一下，改天再仔细想想。呵呵

今天就写到这里先了。To be continued...