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

lsekfe

本周的问题为“当开发人员的单元测试覆盖率达到100%时，QA可以发现什么样的缺陷？”
此话题由会员zdlzx提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	livexmm	50移动充值卡	24#

yaojinyf

单元测试覆盖率100%
测试人员可以发现集成后软件的功能问题，接口问题，流程问题， 不同流程组合后出现的功能问题，逻辑问题，不同压力下的性能问题...等等，本人只是根据经验总结以上，不足之处请指教！！！

Hedis

单元测试神马的覆盖率？语句覆盖？条件覆盖？循环覆盖？

mandy.wang

看了半天没明白问题！
思索了半天，在想标题中的“QA”并不是指质量保证人员，而是测试人员？

下面通过一些理论基础来说明我个人的看法：
理论基础：
单元测试是对最小的可测试软件元素（单元）实施的测试，它所测试的内容包括单元的内部结构（如逻辑和数据流）以及单元的功能和可观测的行为。使用白盒测试方法测试单元的内部结构，使用黑盒测试方法测试单元的功能和可观测的行为。
个人理解：
白盒测试由开发人员执行，黑盒测试由测试人员执行。
故存在上面的质疑：标题中的“QA”并不是指质量保证人员，而是测试人员？

再回答问题：
如果开发人员的单元测试覆盖率达到100%（实际单元测试覆盖率达到100%几乎没有可能吧？），即说明单元的内部结构（如逻辑和数据流）均通过测试，但单元的功能和可观测的行为需要通过黑盒测试方法去测试，所以推测出问题的答案如下：

当开发人员的单元测试覆盖率达到100%时，QA（PS：此处我理解的是测试人员）可以发现单元的功能和可观测的行为方面的问题。

qvbfnsc

这要从各种的测试的作用来看：
1、单元测试负责的只是代码内部逻辑处理的验证，单元测试达到100%覆盖，至多也只能说明程序代码的内部实现是没有问题而已；
2、集成测试负责的是各模块的集成之间的功能验证，只进行了单元测试未进行集成测试，还会存在各模块集成方面的问题，如程序接口、系统接口、数据一致性、数据同步等方面的问题
3、系统测试负责是产品程序与需求的符合度验证，只进行了单元测试未进行系统测试，还会存在与需求不符的问题，如安全方面、性能方面及UI方面等的问题

AwL_1124

单元100%，集成又会出各种问题
每个模块的动作不是依据单个Func或者CPP就可以完成的。

shiruili215

个人见解：
1. 单元测试覆盖率100%，保证了程序代码内部实现的问题；但是不能保证程序代码所实现的功能就是客户的需求，究竟开发做的功能是不是客户想要的，能不能按照客户所预期的方式运行，还需要测试人员进行验证确认，实际上测试人员会发现很多实现和需求相悖、需求实现遗漏之类的重大问题；

2. 单元测试重在代码内部实现，语句，条件，循环，分支等等，都是针对内部分离的小模块，而相关模块间的接口并不能覆盖到，这样程序的接口问题、数据一致性等问题需要通过集成测试进行挖掘，这的确是考验测试人员技术的一项测试工作，但是一旦集成测试做到位，对于软件整体质量的提高有很大帮助，也会有利于后续系统测试的开展；

3. 系统测试更是不可缺少，概括起来包括了系统功能和需求的验证，性能测试，兼容性测试，易用性测试等等，这些测试活动中发现的缺陷比重分量不轻呢；

4. 文档测试更可以让测试人员的价值完美体现；

jy01226343

逻辑覆盖？语句覆盖？

jy01226343

逻辑覆盖？语句覆盖？

ivanland

有几个问题：
1、单元测试的测试对象是函数级别的，覆盖率达到100%最多只能体现是函数代码不存在逻辑上的错误；而如果真要趋向于测试的完备性，函数的黑盒功能也可以有缺陷让我们去发现，另外向上的集成测试和系统测试以及验收测试，肯定还是能发现不少问题;
2、QA是对于测试流程规范的管理角色，理论上是不会从事实际的测试工作的，不过国内的普遍现象是很多公司的QA所从事的工作内容和测试人员没有什么区别，所以让一些人误以为QA就是Tester;

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

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

Fox_琦琦

这些问题的最后答案在哪里啊？？？

lsekfe

回复 16# Fox_琦琦


    这个活动是每期结束后，我们会评选出最好的答案来。并且还能获得50元的手机充值卡奖励哦！

san

先试下ipad能不能回复...

TesterChen

首先，同样提出来的是，标题中的“QA”并不应该是指质量保证人员，而是测试人员，所以最好以“Tester”替代比较合适

然后，回复本周的问题：当开发人员的单元测试覆盖率达到100%时，Tester可以发现什么样的缺陷？

单元测试通过只能表明，单元内的功能实现是正确的，而把这一小部分放在整个环境中能否保证整个环境及他本身的正常运转，是有待进一步验证的！
如：一个零件本身是正常运转的，但把这个零件放到整个机器中，能否保证整个机器和零件本身正常运转，是同一个道理

1.单元之间数据交互异常
在集成测试和系统测试过程中，我们可能发现某个单元与某个单元之间的数据交互存在异常
如：单元A输入的数据格式是abc，而单元B需要单元A输入的格式应该是ABC，这样两个单元本身测试是正常的，但集成时就会出现问题

2.功能或系统设计问题
我们可能发现某个单元本身的功能是正确的，但放在整个系统中进行测试时，发现当时的设计是有问题的，无法契合整个系统的设计
如：设计时考虑不周，导致在后期系统测试时才发现设计上的缺陷

3.现兼容性、及用户的使用体验等问题
单元测试往往是白盒测试的方式，白盒测试往往很少依赖用户界面，当把对应的单元功能移植到用户界面上时，出现浏览器的兼容性问题

4.系统性能问题
对于Web系统，如某一个单元或模块中传输的数据流量过大，导致整个系统的传输及响应速度慢

5.业务逻辑及需求上的问题
在进行详细的系统测试时，会发现许多的系统业务逻辑及需求上的缺陷。

lvchongen

我对题目的理解是，问题中的QA主要职责是白盒或者灰盒测试。
      首先，我们需要明确一个问题，什么是代码覆盖率？基本上可以理解为测试过程中运行代码的行数与总行数的比率。代码覆盖程度的度量方式有很多种，比如语句覆盖，判定覆盖，条件覆盖，路经覆盖，这四种基本的覆盖方式测试能力从弱到强，那么问题是题目中的覆盖率100%是采用了哪种覆盖方式，即使采用了最强的  覆盖方式，测试人员就不能再发现缺陷了么？
      软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。所以我们测试代码的时候需要从很多角度出发，功能,性能,安全等。
      (1)性能方面，常见的错误就是内存泄露，算法有待优化等，而这些往往是开发人员的思维死角。
      (2)安全方面，一般是隐藏的漏洞，加密算法，容错能力等，有兴趣的朋友可以百度以下WebShell提权，典型的针对代码漏洞取得管理员权限。
      (3)功能方面，比如集成测试，虽然模块功能正确，但集成后失效，其实就是接口存在缺陷。
      随着测试人员对代码的理解，对系统的认识，知识的累积，会找到更多的角度测试，所以即使开发人员的代码覆盖率100%，我们要做的还有很多。