单元测试覆盖率达到100%时，QA可以发现什么样的缺陷？(7.17）（获奖名单已公布）

missoflong

看了前面不少人的回复，暴露一个问题：命题中的单元测试的范围是模糊不清的。在各家公司，所谓的单元测试范围也各不相同。

先谈一个命题理想状态的情况下，测试能发现的缺陷吧。理想状态即开发的各个单元环节都按照开发设计文档完美的实现了，而设计文档完全符合需求文档，需求文档完美。
在此时，测试几乎无法发现任何bug。前面说的集成时的缺陷也不会存在，因为代码开发都不是上来就写，需要开发框架文档，做概要设计文档，最后做单元设计文档，在大公司，往往发现分工很细，往往发现刚入职的程序员都是coding，如同机器人。
至于性能，体验，业务的缺陷也不会有，完美的需求，都会考虑到。此时估计很多人忘了一点：测试的目的是为了什么。个人的理解，测试就是为了检查程序是否符合需求。所以，若需求完美，也发现不了问题。打个比方，我现在在用new户ipad，发现51test发现51有很大不兼容的地方，51招聘那块检索。但是51当初的需求就没考虑过此问题，就算在我看是bug，但是对当初这个项目来说不能算。51也许以后会考虑。

顺便说句，完美状态是不存在的。

missoflong

看了前面不少人的回复，暴露一个问题：命题中的单元测试的范围是模糊不清的。在各家公司，所谓的单元测试范围也各不相同。

先谈一个命题理想状态的情况下，测试能发现的缺陷吧。理想状态即开发的各个单元环节都按照开发设计文档完美的实现了，而设计文档完全符合需求文档，需求文档完美。
在此时，测试几乎无法发现任何bug。前面说的集成时的缺陷也不会存在，因为代码开发都不是上来就写，需要开发框架文档，做概要设计文档，最后做单元设计文档，在大公司，往往发现分工很细，往往发现刚入职的程序员都是coding，如同机器人。
至于性能，体验，业务的缺陷也不会有，完美的需求，都会考虑到。此时估计很多人忘了一点：测试的目的是为了什么。个人的理解，测试就是为了检查程序是否符合需求。所以，若需求完美，也发现不了问题。打个比方，我现在在用new户ipad，发现51test发现51有很大不兼容的地方，51招聘那块检索。但是51当初的需求就没考虑过此问题，就算在我看是bug，但是对当初这个项目来说不能算。51也许以后会考虑。

顺便说句，完美状态是不存在的。

missoflong

既然提到51的ipad缺陷，那就再说一个bug吧。ipad上面点击＂发表回复＂，响应状态没有，也没有临时禁掉此按钮，会导致勿回复多个

missoflong

既然前面提的完美状态不存在。那就谈谈普通状态。所谓的普通状态，即剔除测试，其他一切都普通，测试是一流的。

结果：尽管单元100通过。可以发现的bug有很多。先从黑盒说，主要有需求的bug，不知道有人遇到过没，需求提供者提供的需求有时候前后矛盾，或者是一个不符合常规业务的一个设计。比如a股，成交都按手为单位，你偏偏在交易里用股做基础单位，输入交易额时，又乘100，1手等于100股。

其次，异常值处理bug，你会发现如果需求没有提，很多文本框没有长度限制，没有异常值输入控制，什么都能输入。
再其次，业务逻辑的bug，如前面说的，开发各顾各的，当他们互相调用接口的时候，连参数都传错。比如，我现在回复的内容可能跑到其他帖子里。
最后，最容易忽略的，界面，易用性，性能等问题，当然还有更多，就不细说。

从白盒来看，如果所谓百分之百单元测试通过，仅仅只测试了条件分支覆盖，那么条件组合？循环语句覆盖？代码规范是否符合？等等。高级一点，可以直接提出框架的设计就有问题，优化框架。

灰盒，我个人的感觉是通过前台黑盒功能表现，推测后台逻辑问题。当然，专业点就是黑白通吃，结合测试。往往很多公司根本不提供代码，却又要我们测试出所有问题。比如算法 从来a表提取b字段和c表提取d字段求和显示在程序前端。我们都是从数据库拿数据根据需求算法计算前端显示的值是否正确。变相证明后台从数据库提取数据算好，再通过接口让前台调用显示，这一段流程的正确性。当然这个测试的流程也是没办法的办法。公司为保密，不让接触代码。

唉，太多了，真要问能测试出什么，可以什么都测试出来，也可以什么都测试不出来

missoflong

其实，测试只象一个医生，可以帮助公司检查程序是否有问题，无法保证程序不出问题^_^。人也一样，乱吃东西，医生也保不了你。