为什么白盒测试的代价大呢？+白盒测试的依据问题。

alps

小弟没做过白盒测试，在学习白盒测试的时候有一点困惑。都说白盒测试的代价是比较大的。
1.测试人员去做开发人员的白盒测试，代价大的原因可能是测试人员需要先去翻阅、理解代码，这是一个重复的工作，并且对能做白盒测试的人员能力要求比较高。
2.那如果是开发人员自己给自己的代码做白盒测试呢？代价大的原因是白盒要达到某种覆盖的用例数很多吗？且因为白盒是针对函数或者类的比较低层的东西，是不是因为函数多，那么为测试函数要写的桩和驱动也多导致成本高？

还有一个问题，做白盒测试的依据是程序的结构信息（流程图，控制图之类的），那么这个结构控制信息应当是在详细设计中吗？（我们的详设中没有流程图之类的东西）。如果详设中没有结构信息，那么测试人员如何产生这个结构信息呢？跟开发人员沟通去了解并产生？根据代码产生？根据代码产生的流程图并根据此图生成的用例貌似意义不大，发现死代码也许还行，发现其他问题貌似就不行了吧？

alps

看来论坛里关注单元测试的还真是不多啊，国内真的很少开展吗？我们领导的思想也挺前卫的啊。现在就让我们实践推广单元测试。
通过实践和学习自己回答一下吧：
开发人员自己去做白盒的工作量之所以大就是因为为每个函数写驱动和桩（自底向上的测试可以省去写桩的步骤），要达到函数的覆盖要写不少的用例。

依据：程序的控制信息应当是在详细设计中，但是在开发流程有问题的情况下，这些控制信息就没有了，对这样的代码做白盒测试，就需要测试员阅读程序及其注释（才、包括被测程序和与它相关的调用被调用的程序），了解程序应当的实现方式。也可以和开发人员交流去弄明白设计的流程。但是这种详细设计中没有程序控制信息的白盒测试是一件非常让人烦恼且费力不讨好的事情。

zlfoxy

楼主在帖子里同时提到了白盒测试和单元测试。我不觉得这是一个东西。
这里只讨论一下单元测试好了。
单元测试目前国内的现状是：想做单元测试的话就让开发自己去搞，如果开发不想搞就不搞。真正的让tester去搞单元测试的不多。
就像楼主所说，关注单元测试的人不多，大到国内，小到这个论坛。这也不仅仅是测试这个领域的问题了，这是整个IT大环境的现状。
有人说单元测试不重要？笑~

black_tulip

为什么说代价大，楼主说的1，能力达不到，楼主说的2，不是用例多所以代价大，而是只要去做，就有代价，这个代价微观来看是必然存在的，宏观看可能会得到的大于代价的好处，每一个个体对其关注和信任不大。

alps

呵呵，不好意思，关于单元测试和白盒测试的问题是我没写清楚~~~
我们的测试现状真的是有待提高。

[ 本帖最后由 alps 于 2009-8-24 11:56 编辑 ]

alps

恩，对，受教。
很多项目为了赶时间省掉了很多步骤，虽不能说是草草的发布，但是也是比较仓促的发布。理论、理想和实际总是有差别的~

maguschen

我做API测试，代码级别的，代价如何大，举个例子楼主看看可能会更加直观地感受
我们的开发开发一个接口，假如需要8小时（纯编码时间，不计算需求分析等……）
那么我测试这个接口大概也是需要8个小时，而且还没有达到非常好的覆盖，例如100%判定/条件覆盖。
你说代价大不大

alps

那您在这个“8小时”的测试中都做些什么呢？是不是说“8个小时“完成如下动作？
1.理解这个接口的设计或者分析详设中关于这个接口的描述
2.设计白盒测试用例
3.编写测试代码（桩和驱动）
4..执行测试

maguschen

1. 分析详设中关于这个接口的描述，理解接口部分前期已经做过了
2.设计白盒测试用例，这个也是部分已经完成了
3.编写测试代码（桩和驱动）
4..执行测试

alps

哦，那加起来时间其实是超过八个小时的啊~~~
“8小时”就是编写测试代码、执行测试和补充用例了

maguschen

原帖由 alps 于 2009-8-25 13:41 发表
哦，那加起来时间其实是超过八个小时的啊~~~
“8小时”就是编写测试代码、执行测试和补充用例了

是啊，所以有时候时间不够了，就不做那么细了，测试总是第一个想到被砍掉的部分。。。

alps

产品发布高于产品安全的发布