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

lsekfe

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

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

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

zhconnie

单元测试是软件测试中最小功能粒度的测试，只是保证单个功能模块的正常运作，当将这些模块集成之后就不敢保证是否能正常运作了，如接口实现方面，数据调用方面，各模块的数据类型是否一致，系统完成功能是否契合设计需求等等，以及性能方面的问题也很可能出现。

zhconnie

单元测试是软件测试中最小功能粒度的测试，只是保证单个功能模块的正常运作，当将这些模块集成之后就不敢保证是否能正常运作了，如接口实现方面，数据调用方面，各模块的数据类型是否一致，系统完成功能是否契合设计需求等等，以及性能方面的问题也很可能出现。

CoNolaen

大家说的都好全面，顶一下

huolaishao

好的代码不是100%单元测试没问题就OK了，而是在后期修改时出现问题可以用最小的力气去修复这个问题，并且不会导致其他问题，在我看来，单元测试不只是功能OK，代码的健壮性同样重要。
如果这没问题，需求没问题，业务流程没问题。我觉得大致得看三点吧：
1. 首先得看此单元是否完全符合需求的要求，
2. 然后就是看集成之后，整体数据流是否在对应的驱动或者输出接口上存在问题，
3. 其次是在极端或者意外情况下的数据进入之后，处理是否得当，是否有健全的容错机制。

ljw375

应该是流程和接口和数据的问题。

msnshow

不同类型的测试，发现不同层面的问题

乔巴

单元覆盖率达到100%，应该看相对应的功能是否对应
其次是看单元与单元之间的接口
最后再是内部的负载测试和外部的压力测试等性能测试，UI,UED等针对于客户的测试

livexmm

单元测试一般是测试代码的严谨性，并且代码是否按照详细设计来做。如果详细设计过关，单元测试一般是以详细设计为基础设计，而不是以代码为基础。
恩，就说国内，一般很多公司开发软件都不会做详细设计，或者详细设计不够严谨，这个先不说，先按照出题者的思路来回答。
一般情况下单元测试覆盖率很难达到90%以上。既然题目说是单元测试覆盖率达到100%，那基本上想表达的意思应该是程序已经完完全全按照详细设计来做，并且代码逻辑上很严谨。
会出现问题的地方以及测试范围：
先细分一下单元测试包含的内容：软件在该单元模块的功能，画面显示与画面迁移（如果单元测试覆盖率只表示代码覆盖率，那这个测试点还是得测试）。
那么从这里我们就能确定剩下还需要进行的测试：需求合理性，模块间的集成，软件性能，软件可操作性，如果有必要还需要进行安全性测试。
各个测试范围内可能出现的问题：
需求合理性：
这里会出的问题就是需求没做好，我认为这个反倒是目前国内软件开发最有可能出现问题的地方。需求出现问题随之带来的需求变更有无数的谚语与语录可以供认调侃。严格的需求审核是保证这方面质量的一个关键。并且不能把原始业务需求与需求用例混为一谈。
另外，测试团队需要在这方面发现问题必须业务熟练，并且有一定的开发经验。所以如果是完全没基础的新项目，测试团队这方面能力又不足的话，还是别考虑吃这方面的肉了。虽然确实很诱人。但是一搞不好也很丢人。
模块间的集成：
这点严格来说属于详细设计没做好。比如接口间传递的数据不对，导致画面上显示的不正确，或者干脆造成下一个业务流程无法进行下去。保证这个方面没有问题主要靠详细设计的审核与测试团队的测试。
软件性能
这里会出现的问题主要是由2部分组成。
1.代码。举个例子，一般公司都会有代码规范，并且规定数据库查询语句不允许写在循环内，但是有多少公司真正有QA，并且QA真正去追这方面的问题呢？实际上这里只需要开发人员之间的一个代码走查就能搞定了。
2.数据量过大。这个详细设计的时候就需要提一根弦，碰到查询页面不加个分页功能实在是不应该的。
还有诸如网络环境，硬件配置，业务人员操作习惯等等天灾人祸的原因太多了。不过就我实际碰到的情况，90%都是以上2点组成。另我很遗憾的是，我发现只要代码规范写得仔细，并且开发人员能够执行，很多性能问题不会出现。
当然，性能最终反馈的问题就是执行效率过慢！！想要保证性能，设计、开发、测试各个阶段都需要注意。
软件可操作性：
比如用户操作习惯的一致性，画面风格的一致性，页面简洁等等。这里主要还是一些操作习惯。如果是对用户体验比较重视的软件，那这方面到成了重点。这里会由测试团体负责，客户体验也占了很大一部分。
安全性：
安全性么，比如SQL注入，加密，文件上传与下载，网络环境的配置。涉及不多，就不多说了。

快剑砍断

小小支持一下

土土的豆豆

单元测试，又可以称为模块测试或组件测试，是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。
总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。通常，单元测试主要由开发人员自己完成。通过编码验证和检查，属于白盒测试范围。无论是代码覆盖还是路径、条件、组合等交错匹配，还是最初的一个检验阶段。
我认为，LZ这里给出的QA其实应该称之为：Tester。
在单元测试阶段后，测试人员可以做的工作实在太多了。整个测试才刚刚开始。按测试目的来说，包含传统测试过程中的静态测试、集成测试、系统测试、验收测试，做得好些的项目/程序/产品，也可以进行非功能性测试、维护测试等。
这里简单说明一下：
1. 最基本的静态测试，可以分析程序/网站/项目上一些静态链接，检查页面图片、文本、超链接等资源的有效性。
2. 集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求组装成为系统。这时可以发现的问题是：

——在把各个模块连接起来的时侯，穿越模块接口的数据是否会丢失；

——一个模块的功能是否会对另一个模块的功能产生不利的影响；

——各个子功能组合起来，能否达到预期要求的父功能；

——全局数据结构是否有问题；

——单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。

当然，在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。子系统的集成测试特别称为部件测试，它所做的工作是要找出集成后的子系统与系统需求规格说明之间的不一致。
3.系统测试，是将通过确认的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。系统测试的目的在于通过与系统的需求定义作比较,发现软件与系统的定义不符合或与之矛盾的地方。这主要就是黑盒测试了。参考文档即软件需求规格说明书。任何与需求不一致的地方，就是问题。
4.验收测试，也可以称为确认测试。主要是看系统是否满足了用户的需求，而不仅仅是满足软件需求规格说明书。毕竟，我们的系统/项目/产品，最终用户满意才是王道。那对于任何用户提出的意见、需求变更、模块改进等，都属于这个阶段产生的问题。
5.非功能性测试，除去功能测试外，在GB/T 16260标准质量特性中的其他几大特性，可靠性，易用性，效率，可维护性，可移植性等，有条件的当然都需要测试。对于系统/项目/产品的质量好坏，功能方面只是个基本，高效、稳定、安全的系统才是用户喜欢的。这里不多说了。
6.维护性测试，这里的维护性测试特指用户验收通过后，给予的技术支持和保障，任何后续需要帮助、解释、说明的部分，都属于测试范围。
综上，在开发人员完成单元测试后，其实测试才刚开始。所以，绝大部分缺陷问题理所当然会在软件测试生命周期各个阶段暴露出来。这才是测试工作的本质和重点。
以上纯属个人愚见，不足之处，望大家指正。

monica417

单元测试实际上是为了检测代码模块内部逻辑是否正确，一验证开发人员是否按照详细设计说明中设计的进行编写，另外由于设计书的同行评审不可能100%找出缺陷，单元测试也可以检测详细说明书中本身设计是否有缺陷从而完善；

同理，集成测试验证的是代码集成后功能模块之间的集成问题，如：接口、数据等，一验证集成代码与概要设计的一致性，二验证概要设计本身的正确性；

系统测试验证的是代码产品集成后与产品的功能需求的一致性，如：主要工作流、性能等，二验证功能需求本身的正确性；

需求和设计文档的评审不可能把缺陷都暴露出来，只有编写代码后通过单元测试、集成测试、系统测试才能真正一步一步检验到该工作产品是否符合客户真正需求。

所以即便单元测试覆盖率达到了理想的100%覆盖，测试人员还是可以测试出很多问题的；不过实际项目中公司会综合考虑项目成本，一般单元测试的100%覆盖是很难达到的，一般只会对重要的或者代码复用率较高的模块进行单元测试用例的编写！

lvchongen

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

TesterChen

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

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

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

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

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

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

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

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

san

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

lsekfe

回复 16# Fox_琦琦


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

Fox_琦琦

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

missoflong

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

missoflong

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

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

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

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

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

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

missoflong

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