查看完整版本: 测试代码的测试

测试代码的测试

单元测试或者其他类型的测试，如果开发代码来进行测试，针对这部分代码肯定也需要测试，这是否也是一个不小的工作量，并且测试代码中还是有可能存在错误。

大家有什么看法？

大家好像对这个问题没什么兴趣阿，或者是因为我的描述不够清晰？版主能否发表一点看法？

你的意思是,单元测试的时候,需要写代码,也就是写一些小工具来测试代码...
那么,还需要花时间去测试这些小工具,是这个意思吗?

对，就是你说的这个意思。
但不仅仅是单元测试，还包括其他类型的测试也可能需要写一些来减轻测试工作量，或者实现一些手工测试不容易实现的功能测试。

code review最能帮忙！

再补充点儿：写automated test cases前你会有test requirement，最好和开发人员沟通好，然后自己写test specification，和开发人员一起坐下来讨论，正式一点的话来个specification review，然后做design，同样，design做完后可以和有经验的automation tester交流，正式的话也可以是design review。最后Automated test cases写好后，和有经验的automation tester坐下来做code review。这是我们这里的日常工作模式，看似时间花得长，但真正有效、实用，对于test case代码的维护effort也会降低。

记住一句话，如果写automated test cases，就要把它当成一个小的deveolpment project对待。Development project里有的东西，你都可以借过来为你所用，通过这样的流程写出来的代码可重用性高，也更稳定。

兄弟，死锁了！·

这样整不完的！

就是,死循环了!

肯定是必需的

这个方法看上去很美，但是个人感觉不必要，而且实际操作起来很困难：
1. 测试代码是内部使用，不是给用户用的 (作为工具交付的另当别论，那已经不完全是测试代码了，是产品一部分)
2. 测试的目的是测试产品，因此要尽量轻快，敏捷。可以有很大量的代码，很大量的数据，但是结构上不要搞的太繁琐，不要把自己过于复杂化。
3. 测试时间往往不宽裕，写自动测试已经很耗费时间了，长周期项目才能现出优点，再来针对测试做测试，有点得不偿失。

个人认为可能的解决方法：
1. 建立良好的框架，尽可能实现复用，结构要清晰，要预留可能的接口或者扩展，不一立即定要实现。
2. 每一个功能块（可以是一个脚本，也可以是一个函数）尽量精简，尽量缩小其覆盖，便于发现错误。
3. 良好的log，不仅要考虑到记录测试的pass或fail,也要考虑记录测试代码本身的一些行为，比如可以用异常处理，或者system error level。
4. incremental 方式；有时间的话，每次与其对测试做测试，不如强化重要的功能测试，增大覆盖。毕竟，测试是为了测试产品的，不是为了自动化而自动化。来不及的部分不如先手工，等下个周期再实现。而且这个过程本身就包含了一定意义上对测试代码的测试。
5. 做好做细自动化之前的手工测试。

以上主要是针对 regression testing,我觉得这也是自动化测试最有价值的地方之一。有统计显示，大部分的bug其实是在“做自动化代码的过程中的手工测试中发现的”。仔细想像这其实很正常，并不能因此说明自动化的无用，而恰恰是自动化是一种方法过程。自动化回归测试本身的意义只应该在验证正确，而不是发现错误。要是反过来，那这个测试问题大了。至于unit testing,大多有现成框架，代码量也不大，应该可以控制bug的，不过这方面偶没怎么做过，欢迎指教。
本人测试经历不长，随便说说欢迎拍砖交流。

我觉得单元测试有用

我觉得这就是测试中的测试，其实可以借助外来工具进行测试覆盖率的测试。

回复 10# 的帖子

很久很久没来了，来了看到回帖，觉得大家讨论得很有意思。
我前面已经说过，这就是我们的工作模式，在实际工作中被证明是十分有效的。
如果要是写出稳定、有效、可靠、可重用性高的测试代码，就是这样的，没什么不可以，这样反倒降低了维护的effort。确实是实践证明了的。所以，我们这里对于做自动测试的人的要求，起码他会写代码，最好是搞计算机出身的，一般没有编程经验的还不要呢。我上面和这里说的测试脚本主要是用于回归测试。对于新的功能，还是手工测试比较好。而且，由于新的功能还不是很稳定，马上就写测试脚本，通常的情况下会是脚本也不稳定，且维护的effort较大，得不偿失。
10楼人说，测试脚本是给内部用的，这话不错。不过，请不要忘了，自己写的东西，自己也许可以做维护。但是如果文档不全，在过了一段时间之后，即便是同一个人也不会记得自己所有的代码，更何况，很多情况下，也许其他人也会重用你的代码，或者由于功能的更新，你也会回到原先的代码里面进行修改、维护。如果脚本开发初始阶段做足准备工作，以后就会省时、省力。

在好的基线框架上开发测试代码与同行评审可以保证