同理，集成测试验证的是代码集成后功能模块之间的集成问题，如：接口、数据等，一验证集成代码与概要设计的一致性，二验证概要设计本身的正确性；
系统测试验证的是代码产品集成后与产品的功能需求的一致性，如：主要工作流、性能等，二验证功能需求本身的正确性；
需求和设计文档的评审不可能把缺陷都暴露出来，只有编写代码后通过单元测试、集成测试、系统测试才能真正一步一步检验到该工作产品是否符合客户真正需求。
所以即便单元测试覆盖率达到了理想的100%覆盖，测试人员还是可以测试出很多问题的；不过实际项目中公司会综合考虑项目成本，一般单元测试的100%覆盖是很难达到的，一般只会对重要的或者代码复用率较高的模块进行单元测试用例的编写！ 单元测试，又可以称为模块测试或组件测试，是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。
总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。通常，单元测试主要由开发人员自己完成。通过编码验证和检查，属于白盒测试范围。无论是代码覆盖还是路径、条件、组合等交错匹配，还是最初的一个检验阶段。
我认为，LZ这里给出的QA其实应该称之为：Tester。
在单元测试阶段后，测试人员可以做的工作实在太多了。整个测试才刚刚开始。按测试目的来说，包含传统测试过程中的静态测试、集成测试、系统测试、验收测试，做得好些的项目/程序/产品，也可以进行非功能性测试、维护测试等。
这里简单说明一下：
1. 最基本的静态测试，可以分析程序/网站/项目上一些静态链接，检查页面图片、文本、超链接等资源的有效性。
2. 集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求组装成为系统。这时可以发现的问题是：
——在把各个模块连接起来的时侯，穿越模块接口的数据是否会丢失；
——一个模块的功能是否会对另一个模块的功能产生不利的影响；
——各个子功能组合起来，能否达到预期要求的父功能；
——全局数据结构是否有问题；
——单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
当然，在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。子系统的集成测试特别称为部件测试，它所做的工作是要找出集成后的子系统与系统需求规格说明之间的不一致。
3.系统测试，是将通过确认的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。系统测试的目的在于通过与系统的需求定义作比较,发现软件与系统的定义不符合或与之矛盾的地方。这主要就是黑盒测试了。参考文档即软件需求规格说明书。任何与需求不一致的地方，就是问题。
4.验收测试，也可以称为确认测试。主要是看系统是否满足了用户的需求，而不仅仅是满足软件需求规格说明书。毕竟，我们的系统/项目/产品，最终用户满意才是王道。那对于任何用户提出的意见、需求变更、模块改进等，都属于这个阶段产生的问题。
5.非功能性测试，除去功能测试外，在GB/T 16260标准质量特性中的其他几大特性，可靠性，易用性，效率，可维护性，可移植性等，有条件的当然都需要测试。对于系统/项目/产品的质量好坏，功能方面只是个基本，高效、稳定、安全的系统才是用户喜欢的。这里不多说了。
6.维护性测试，这里的维护性测试特指用户验收通过后，给予的技术支持和保障，任何后续需要帮助、解释、说明的部分，都属于测试范围。
综上，在开发人员完成单元测试后，其实测试才刚开始。所以，绝大部分缺陷问题理所当然会在软件测试生命周期各个阶段暴露出来。这才是测试工作的本质和重点。
以上纯属个人愚见，不足之处，望大家指正。
小小支持一下
小小支持一下 本帖最后由 livexmm 于 2012-7-11 17:33 编辑单元测试一般是测试代码的严谨性，并且代码是否按照详细设计来做。如果详细设计过关，单元测试一般是以详细设计为基础设计，而不是以代码为基础。
恩，就说国内，一般很多公司开发软件都不会做详细设计，或者详细设计不够严谨，这个先不说，先按照出题者的思路来回答。
一般情况下单元测试覆盖率很难达到90%以上。既然题目说是单元测试覆盖率达到100%，那基本上想表达的意思应该是程序已经完完全全按照详细设计来做，并且代码逻辑上很严谨。
会出现问题的地方以及测试范围：
先细分一下单元测试包含的内容：软件在该单元模块的功能，画面显示与画面迁移（如果单元测试覆盖率只表示代码覆盖率，那这个测试点还是得测试）。
那么从这里我们就能确定剩下还需要进行的测试：需求合理性，模块间的集成，软件性能，软件可操作性，如果有必要还需要进行安全性测试。
各个测试范围内可能出现的问题：
需求合理性：
这里会出的问题就是需求没做好，我认为这个反倒是目前国内软件开发最有可能出现问题的地方。需求出现问题随之带来的需求变更有无数的谚语与语录可以供认调侃。严格的需求审核是保证这方面质量的一个关键。并且不能把原始业务需求与需求用例混为一谈。
另外，测试团队需要在这方面发现问题必须业务熟练，并且有一定的开发经验。所以如果是完全没基础的新项目，测试团队这方面能力又不足的话，还是别考虑吃这方面的肉了。虽然确实很诱人。但是一搞不好也很丢人。
模块间的集成：
这点严格来说属于详细设计没做好。比如接口间传递的数据不对，导致画面上显示的不正确，或者干脆造成下一个业务流程无法进行下去。保证这个方面没有问题主要靠详细设计的审核与测试团队的测试。
软件性能
这里会出现的问题主要是由2部分组成。
1.代码。举个例子，一般公司都会有代码规范，并且规定数据库查询语句不允许写在循环内，但是有多少公司真正有QA，并且QA真正去追这方面的问题呢？实际上这里只需要开发人员之间的一个代码走查就能搞定了。
2.数据量过大。这个详细设计的时候就需要提一根弦，碰到查询页面不加个分页功能实在是不应该的。
还有诸如网络环境，硬件配置，业务人员操作习惯等等天灾人祸的原因太多了。不过就我实际碰到的情况，90%都是以上2点组成。另我很遗憾的是，我发现只要代码规范写得仔细，并且开发人员能够执行，很多性能问题不会出现。
当然，性能最终反馈的问题就是执行效率过慢！！想要保证性能，设计、开发、测试各个阶段都需要注意。
软件可操作性：
比如用户操作习惯的一致性，画面风格的一致性，页面简洁等等。这里主要还是一些操作习惯。如果是对用户体验比较重视的软件，那这方面到成了重点。这里会由测试团体负责，客户体验也占了很大一部分。
安全性：
安全性么，比如SQL注入，加密，文件上传与下载，网络环境的配置。涉及不多，就不多说了。 单元覆盖率达到100%，应该看相对应的功能是否对应
其次是看单元与单元之间的接口
最后再是内部的负载测试和外部的压力测试等性能测试，UI,UED等针对于客户的测试 不同类型的测试，发现不同层面的问题 应该是流程和接口和数据的问题。 好的代码不是100%单元测试没问题就OK了，而是在后期修改时出现问题可以用最小的力气去修复这个问题，并且不会导致其他问题，在我看来，单元测试不只是功能OK，代码的健壮性同样重要。
如果这没问题，需求没问题，业务流程没问题。我觉得大致得看三点吧：
1. 首先得看此单元是否完全符合需求的要求，
2. 然后就是看集成之后，整体数据流是否在对应的驱动或者输出接口上存在问题，
3. 其次是在极端或者意外情况下的数据进入之后，处理是否得当，是否有健全的容错机制。 大家说的都好全面，顶一下 单元测试是软件测试中最小功能粒度的测试，只是保证单个功能模块的正常运作，当将这些模块集成之后就不敢保证是否能正常运作了，如接口实现方面，数据调用方面，各模块的数据类型是否一致，系统完成功能是否契合设计需求等等，以及性能方面的问题也很可能出现。 单元测试是软件测试中最小功能粒度的测试，只是保证单个功能模块的正常运作，当将这些模块集成之后就不敢保证是否能正常运作了，如接口实现方面，数据调用方面，各模块的数据类型是否一致，系统完成功能是否契合设计需求等等，以及性能方面的问题也很可能出现。
页:
1
[2]
