完善测试案例省心又省力

???? 软件开发是一项非常复杂的工程，每一个环节都容不得半点的马虎，否则前功尽弃，后悔莫及。需求分析如果没有做到位，很有可能导致做出来的东西不是用户想要的功能；开发如果不严谨，很有可能产生非常隐蔽的bug，测试过程也没有测试出来，导致用户在使用过程中有问题，报障平台越来越多的故障；测试如果不完整，只限于表面的测试，复杂的业务逻辑没有深入的测试，也会导致上线、升级失败。
???? 早两天的升级，由于核心的算法有问题，导致全网用户使用过程中出现问题，给顾客带来很大的损失，我们遭到顾客的投诉。今天的故障越来越多，同事分析了一个故障，根据日志分析，说明是我程序有问题。我当时也很纳闷，明明在测试环境是没有问题的，有点不大可能的感觉，但既然问题出来了，我们一定要认真的对待，去找到问题的根源，避免造成更大的损失，给团队带来负面影响。下午，我仔细的分析了日志，也仔细的把核心算法看了一下，凭直觉这个情况是会发生，然后在测试环境模拟，真的会产生这个问题。我对问题进行了修复，发出邮件提出相关建议和程序更新包。
???? 领导看到我邮件，也非常的重视此事，鉴于问题非常严重今晚务必把问题解决了，并且升级系统。其他同事也在想是否在其它的情况，还会出现问题。果然，经过大家的结合业务分析，可能还会有些情况没有考虑全面。此时，我们继续完善我们的测试案例，把相关的情况都考虑进去了。我一边修改我的代码，一边做单元测试和功能测试。我这边没有问题了，提交给测试同事测试，经过反复测试，确保没有问题。我们对一些影响非常大的点，进行了升级，目前没有什么问题了。这个时候我才真的松了一口气，当时的压力非常大，提醒自己一定要冷静，要清醒，问题一定要修复，解决。
???? 回顾整个事情，我的开发过程中存在了逻辑问题，有些情况没有考虑的周全，写代码还是要沉下心来写，不要急躁，不要浮燥。测试也出现了问题，没有一个完整的测试案例作为指导，测试人员也不知道，到底要怎样测试，才能覆盖整个代码。我们一次又一次的测试，每一次的业务需求都要准备全面的测试案例，这样我们才能确保，我们的程序是高可用的，用户满意的。

????

?

）。

无论如何，你在此次的经历，会让你受益良多。


）。

无论如何，你在此次的经历，会让你受益良多。




是的，我也觉得我的压力蛮大的。
因为我不但要负责这个系统业务需求的更新，BUG的修改工作。而且负责另外一个项目的技术工作，这个也是公司今年最大的项目，实施最困难的一个。目前，还有很多的问题待解决。

我也觉得我应该向前看，要乐观与豁达，虽然我不善于插鞋，但我依然尽最大的努力，饱满的热情投入到工作中，完成项目。在项目中获取更多的快乐，更多的经验。项目成功后，也可以感到自豪，感到欣慰，那么多网点都在用我们的系统。：）
14 楼 hiblue 2010-06-08 用机器人测试就够了,
成本很低,
自动测试机器人很多, 随便弄一个合适的, 写一些简单的脚本就可以了. 15 楼 hgq0011 2010-06-09 hiblue 写道用机器人测试就够了,
成本很低,
自动测试机器人很多, 随便弄一个合适的, 写一些简单的脚本就可以了.

你这种只适合节约劳动力的那种。如果有非常复杂的业务逻辑的，要经过人工干预的，那就不适合了。
16 楼 t42dw 2010-06-10 看了这么多有关测试的东东小弟十在郁闷，做了2年开发了从没像各位说的那样测试过，之前做华为外包开发时间很紧且需求变动很大，如果想测试做充分的话怕是项目不能按期交付。
17 楼 tuti 2010-06-10 mock1234 写道[要想进行测试驱动开发，首先要抛开传统的单元测试观念。

mock1234 常年在 javaeye上宣传TDD，是个好同志啊 18 楼 fucktianya 2010-06-18 我还以为是给碧生源做广告呢，呵呵

省力更省心。哈哈。还能通一通多年的老便（pian）秘 19 楼 mercyblitz 2010-06-26 hgq0011 写道那有什么好的办法，确保软件是万无一失呢?
其实，也存在性价比的权衡？
没有完美的办法，事实上，单元测试有时候没有一点用。但是不能没有，没有的话，心里没有底。

主要我觉得还是集成测试用例的覆盖度，可是不可能完全OK，在开发代码的同时，需要开发人员自信测试，比如不同的操作系统，浏览器（如果是Web程序的话）。最后是，知识库的归档，包括Troubleshooting，开发技巧等等。 20 楼 mercyblitz 2010-06-26 hgq0011 写道首先，非常感谢mock1234的回复
mock1234 写道
编程人员基于传统的单元测试的书本知识来写测试是作用很有限的。当你花很长时间（比如2天）写下功能代码，然后再考虑写单元测试，这时候写出的所谓单元测试往往是限于你的编程思路中，其实是重复无用的东西。传统的测试只好纠缠于所谓覆盖率问题，让人难以自拔。

这是因为传统的单元测试思路的所谓“单元”，纠缠于个别功能代码，而不是反映需求。

我觉得我们的项目不是简单的单元测试。应该也包括功能测试，集成测试，回归测试。
由于当前只是满足业务部门，对功能进行调整，也就是修改原有代码。单元的测试时间不会间隔那么长时间的，每前进一点就会测试的。我想请问的是关于用例覆盖率，怎样才能够做好测试，做好案例覆盖，您有什么好的见解呢？我个人觉得回归测试就是要每一个每一功能都要测试，每一个案例都要覆盖到，才能够保障软件的可用。

mock1234 写道
敏捷开发强调是先写测试，用测试来驱动出设计思路，测试代码是针对设计而不是针对你的实现代码！这是非常关键的。由于是比较高层次的测试思路（即根本不考虑你的实现代码），当你写30个纯粹为了驱动出设计才写的测试，并且每10分钟之内就回归一次（每一次自动随机产生测试数据），那么这些测试之间相互牵制就会发现大量深层次bug。特别是，要打乱测试顺序、并且可能的话开100个线程并发测试，可以发现大量深层次bug。

您说的测试驱动设计，来指导开发。当然非常好。但是，我们的系统不是简单的可以模拟随机数，就可以测试的。系统要和第三方的设备通讯，所以测试比较复杂。我觉得您说的“当你写30个纯粹为了驱动出设计才写的测试”也是测试案例的一种体现。如果你所说的30个为测试驱动设计的测试，能够把所有的情况考虑到，那么把它转换成测试人员的测试案例，那么也能够保障软件是可用的。

mock1234 写道
核心的观念是：1.测试不是用来证明你的实现代码的，测试应该驱动设计的。2. 测试应该每1~10分钟进行一次（你可以选择大部分时间仅执行最近7天的测试，但是每天也要至少进行5次全面回归测试）。3. 在有任何编程想法前都坚持先写测试然后才实现，而不是相反。4. 你编程每一个1个小时都应该写下一个测试，而不是2、3天才写一个测试。5.一个项目的测试驱动必须达到一定强度，也许100也许3000，总之不会很少。

真正的测试驱动开发，轻松、自然、有趣，你会有勇气去修改自己的代码，有勇气让别人随时修改你自己的代码，有勇气随时（闲时）重构系统结构。看似摸着石头过河，实则永远追求统一。你不再盲目纠缠于理论，不再简单地靠过分纠缠理论的是是非非来“保证”你的代码的正确性。

不但对于功能代码，对于GUI也要自动化测试。一个基本的原则是：如果你的代码注释掉了之后仍然可以让自动测试程序通过，那么就说明这些未经测试驱动的代码就是有毒的代码早就应该删掉。

要想进行测试驱动开发，首先要抛开传统的单元测试观念。
您所在的公司都是这样开发的？那真的很羡慕，很幸福。
能请教你们怎样实现自动化测试？我觉得非常的有难度。



其实很难，特别是实施起来。TDD太消耗时间咯 21 楼 mercyblitz 2010-06-26 t42dw 写道看了这么多有关测试的东东小弟十在郁闷，做了2年开发了从没像各位说的那样测试过，之前做华为外包开发时间很紧且需求变动很大，如果想测试做充分的话怕是项目不能按期交付。



时间相对宽松才行，关键是看上级的素质，有些根本就不懂，认为开发+测试=开发。