完善测试案例省心又省力

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

    

 

所有的测试如果都这样写，那成本太高了

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

首先，非常感谢mock1234的回复

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


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


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

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

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

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

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

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

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

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

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

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

自己权衡吧。

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