完善测试案例省心又省力

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

    

 

评论

21 楼 mercyblitz 2010-06-26  

t42dw 写道

看了这么多有关测试的东东小弟十在郁闷，做了2年开发了从没像各位说的那样测试过，之前做华为外包开发时间很紧且需求变动很大，如果想测试做充分的话怕是项目不能按期交付。

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

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太消耗时间咯

19 楼 mercyblitz 2010-06-26  

hgq0011 写道

那有什么好的办法，确保软件是万无一失呢?
其实，也存在性价比的权衡？

没有完美的办法，事实上，单元测试有时候没有一点用。但是不能没有，没有的话，心里没有底。

主要我觉得还是集成测试用例的覆盖度，可是不可能完全OK，在开发代码的同时，需要开发人员自信测试，比如不同的操作系统，浏览器（如果是Web程序的话）。最后是，知识库的归档，包括Troubleshooting，开发技巧等等。

18 楼 fucktianya 2010-06-18  

我还以为是给碧生源做广告呢，呵呵

省力更省心。哈哈。还能通一通多年的老便（pian）秘

17 楼 tuti 2010-06-10  

mock1234 写道

[要想进行测试驱动开发，首先要抛开传统的单元测试观念。

mock1234 常年在 javaeye上宣传TDD，是个好同志啊

16 楼 t42dw 2010-06-10  

看了这么多有关测试的东东小弟十在郁闷，做了2年开发了从没像各位说的那样测试过，之前做华为外包开发时间很紧且需求变动很大，如果想测试做充分的话怕是项目不能按期交付。

15 楼 hgq0011 2010-06-09  

hiblue 写道

用机器人测试就够了,
成本很低,
自动测试机器人很多, 随便弄一个合适的, 写一些简单的脚本就可以了.

你这种只适合节约劳动力的那种。如果有非常复杂的业务逻辑的，要经过人工干预的，那就不适合了。

14 楼 hiblue 2010-06-08  

用机器人测试就够了,
成本很低,
自动测试机器人很多, 随便弄一个合适的, 写一些简单的脚本就可以了.

13 楼 hgq0011 2010-06-07  

stoneskin 写道

兄弟，你是一个有很强责任感的程序员，感觉你的压力有点大。
没关系，向前看。

在这bug的解决上，你做了很多的工作，并解决了问题。
如果你能在这件事上让你的领导看到你分析解决问题的能力，而不是一个处处要人替你擦屁股的人。那么你就是得大与失的。谁没犯过错啊（但也不能老犯）。

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

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

我也觉得我应该向前看，要乐观与豁达，虽然我不善于插鞋，但我依然尽最大的努力，饱满的热情投入到工作中，完成项目。在项目中获取更多的快乐，更多的经验。项目成功后，也可以感到自豪，感到欣慰，那么多网点都在用我们的系统。：）

12 楼 stoneskin 2010-06-07  

兄弟，你是一个有很强责任感的程序员，感觉你的压力有点大。
没关系，向前看。

在这bug的解决上，你做了很多的工作，并解决了问题。
如果你能在这件事上让你的领导看到你分析解决问题的能力，而不是一个处处要人替你擦屁股的人。那么你就是得大与失的。谁没犯过错啊（但也不能老犯）。

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

11 楼 hgq0011 2010-06-06  

stoneskin 写道

如果需求里写清楚了而你没实现，当然得承担一定的责任。
但几乎所有程序员都会以工作量大，deadline紧等客观存在理由来规避责任。
其实如老板懂行的话就明白有bug是正常的，产品有缺陷主要是QA的责任，不全是程序员的责任。

大家都知道自己查自己的代码是不可能找到全部bug的。

如果老板不懂这些或对你有了成见。 两条路：咬牙忍了，与老板沟通；或跳槽，让他另请高明。
（另加据题外话，与老板搞好关系在任何时间地点都是非常重要的，有时比技术还重要）

需求是大方向的描叙，整体的功能当然没有问题。因为系统比较复杂，有一种情况我没有考虑周全，导致系统有BUG。
经过观察，我觉得领导的意思是把责任定位在我身上。
第一：第二天我的大领导发邮件关于昨天故障的问题。中午时候碰到他，他说邮件不是针对我的，是针对整个团队的。
第二：我的直接领导对我说－－你看领导发话了，你看我多被动了。
第三：在聚餐上，我平时不喝酒。但那天领导那桌，同事叫我过去喝。我也有意想借此机会，向协助完成工作的同事表示谢意。我和大领导和了小半杯红酒，领导说：做事要注意方式方法。我点头应允。然后又和其他同事每人干了一小杯。我有点醉意了。

我应该汲取教训，尽量的规避这些事情。

10 楼 stoneskin 2010-06-06  

如果需求里写清楚了而你没实现，当然得承担一定的责任。
但几乎所有程序员都会以工作量大，deadline紧等客观存在理由来规避责任。
其实如老板懂行的话就明白有bug是正常的，产品有缺陷主要是QA的责任，不全是程序员的责任。

大家都知道自己查自己的代码是不可能找到全部bug的。

如果老板不懂这些或对你有了成见。 两条路：咬牙忍了，与老板沟通；或跳槽，让他另请高明。
（另加据题外话，与老板搞好关系在任何时间地点都是非常重要的，有时比技术还重要）

9 楼 hgq0011 2010-06-05  

但领导会认为是我的代码没有写好或设计有问题，也就是做事的方法有问题。怎样改变这样的局面？

8 楼 stoneskin 2010-06-05  

一切按合同。
第三方QA可以是客户雇来验收你们的产品，也可以是你们自己雇来保证代码质量。

做产品的追求质量是对的，但也得有个成本限度。
（其实那是老板考虑到问题，
程序员嘛，保证自己的饭碗，
从工作中学到东西这两点才是要关心的）

自己权衡吧。

7 楼 hgq0011 2010-06-04  

stoneskin 写道

那是没错，所以QA也很重要。
很多公司用第三方QA的。

第三方？那出了问题谁负责呢？

6 楼 stoneskin 2010-06-04  

那是没错，所以QA也很重要。
很多公司用第三方QA的。

hgq0011 写道

stoneskin 写道

放轻松，，bug是生活的一部分。
bugfree只有天堂里才有。

Agile的特性之一是迅速反应，fix the bug, 而不是bug free.
楼主不要过分追求完美了。

时间长了你就会发现，很多时候你很紧张的bug，你老板却不当回事。

小bug当然没有问题，但是bug造成公司损失，顾客利益受到伤害，那就非常的严重和危险了。所以我们要有策略性的应对，去解决我们开发，部署过程中的问题，规避风险。

5 楼 hgq0011 2010-06-04  

stoneskin 写道

放轻松，，bug是生活的一部分。
bugfree只有天堂里才有。

Agile的特性之一是迅速反应，fix the bug, 而不是bug free.
楼主不要过分追求完美了。

时间长了你就会发现，很多时候你很紧张的bug，你老板却不当回事。

小bug当然没有问题，但是bug造成公司损失，顾客利益受到伤害，那就非常的严重和危险了。所以我们要有策略性的应对，去解决我们开发，部署过程中的问题，规避风险。

4 楼 stoneskin 2010-06-04  

放轻松，，bug是生活的一部分。
bugfree只有天堂里才有。

Agile的特性之一是迅速反应，fix the bug, 而不是bug free.
楼主不要过分追求完美了。

还有，做测试的与写代码的不应该都是你吧。

各个公司情况不同，很多时候你很紧张的bug，你老板却不当回事。

3 楼 hgq0011 2010-06-04  

首先，非常感谢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也要自动化测试。一个基本的原则是：如果你的代码注释掉了之后仍然可以让自动测试程序通过，那么就说明这些未经测试驱动的代码就是有毒的代码早就应该删掉。

要想进行测试驱动开发，首先要抛开传统的单元测试观念。

您所在的公司都是这样开发的？那真的很羡慕，很幸福。
能请教你们怎样实现自动化测试？我觉得非常的有难度。

2 楼 hgq0011 2010-06-04  

那有什么好的办法，确保软件是万无一失呢?
其实，也存在性价比的权衡？