关于软件测试的问题--from seforum china

本讨论来自SE Forum China，
欢迎大家来交流

From:  BigMac (cx)
To:  "SE Forum China" <selab@egroups.com>
题目：关于软件测试的问题

单元测试：是针对开发人员而言的，它是指开发人员在完成某一相对
独立的功能的编码之后立即进行的针对此段代码的测试。它属于内部
的白盒测试，在测试时要保证代码的覆盖率，保证代码中的各个分支
均已遍历。如果达到上述要求，即可以认为已达到单元测试的要求；

集成测试：也是针对开发人员而言的，一般是指在完成了软件产品的所
有/大部分编码工作以后，将原来由不同开发人员完成的代码组合在一
起作为一个整体进行测试。进行集成测试的前提是已完成单元测试。
在集成测试时主要是测试需求规范中所规定的各项功能是否已正确实
现，是否可以结束的标准就是当前的软件产品是否已正确实现需求中
所各功能。一般而言，在集成测试中为避免开发人员自身思维的局限
性，自已所完成的部分应由其它开发人员进行测试。如果时间允许，
最好一个功能由多个不同的开发人员进行测试。集成测试如果可能的
话，尽量提前进行，随时进行。例如在实际工作中如果代码的采用版
本管理工具进行管理的话，例如MS的Source Safe，那么，每次CHECK-IN
代码进入VSS库时必须先从库中取出所有当前代码的最新版本，在自已
本机上进行单元测试和集成测试，保证正确后，再CHECK-IN。这样做
的好处是在VSS中始终中一个可能随时运行的软件版本（这也是MS在开
发中采用的方法）。当然，如果有人力物力的话，最好有一个配置管理
小组，每天负责对当前版本管理工具中的最新代码进行BUILD以及相应的测试。

系统测试：这是由专门的测试部分的同事所进行的黑盒测试。测试的标准也
是需求规范。测试人员应根据需求规范制定相应的测试计划及方案。当然
如果有可能的话，最好测试部门的高级测试人员能尽早加入开发团队，了
解需求，了解产品的内部结构，这样才能更好地更有针对性地制定方案及
计划。此外系统测试与前两种测试的不同在于，此时的测试人员是代表最

集成测试：也是针对开发人员而言的，一般是指在完成了软件产品的所
有/大部分编码工作以后，将原来由不同开发人员完成的代码组合在一
起作为一个整体进行测试。进行集成测试的前提是已完成单元测试。
在集成测试时主要是测试需求规范中所规定的各项功能是否已正确实
现，是否可以结束的标准就是当前的软件产品是否已正确实现需求中
所各功能。一般而言，在集成测试中为避免开发人员自身思维的局限
性，自已所完成的部分应由其它开发人员进行测试。如果时间允许，
最好一个功能由多个不同的开发人员进行测试。集成测试如果可能的
话，尽量提前进行，随时进行。例如在实际工作中如果代码的采用版
本管理工具进行管理的话，例如MS的Source Safe，那么，每次CHECK-IN
代码进入VSS库时必须先从库中取出所有当前代码的最新版本，在自已
本机上进行单元测试和集成测试，保证正确后，再CHECK-IN。这样做
的好处是在VSS中始终中一个可能随时运行的软件版本（这也是MS在开
发中采用的方法）。当然，如果有人力物力的话，最好有一个配置管理
小组，每天负责对当前版本管理工具中的最新代码进行BUILD以及相应的测试。

系统测试：这是由专门的测试部分的同事所进行的黑盒测试。测试的标准也
是需求规范。测试人员应根据需求规范制定相应的测试计划及方案。当然
如果有可能的话，最好测试部门的高级测试人员能尽早加入开发团队，了
解需求，了解产品的内部结构，这样才能更好地更有针对性地制定方案及
计划。此外系统测试与前两种测试的不同在于，此时的测试人员是代表最
终用户进行测试，除了按需求规范测试外，他们要从用户实际使用的角度
考虑问题：这项功能实现的过程是否流畅，人机界面是否美观等等。另外
我们应明确一点：依靠各种测度我们均无法保证100%发现软件产品中的所
有BUG！我们进行各种测试的目的在于：在有限的人力物力情况下，最终
的软件产品质量已足够好，即Good-Enough而不要奢望Zero-error。在
实际测试中常常会碰到BUG层出不穷，好象越测心里越没底，不知道何处
是尽头。其实对大多数软件来说，在测试进程中BUG的发现机率是有一定
规律性可言的，如果产品趋于稳定的话，BUG的出现率是会呈递减趋势的，
当此出现率稳定在一可接受的程序或为零时，我们就可以认为此产品已达
到GOOD-ENOUGH了，这时就可以进入稳定期测试了。在稳定期，测试人员
将会将以前测试过程中所有测试过的测试用例再过一遍。如果没有问题的
话，就可以发货了。否则将退出稳定性，开发人员修改BUG，测试方面接
着测试，最后再进稳定期直至一切OK。另外，测试过程中要注意回归测
试的问题。

最后补充一点：测试开始的越早越好！这些BUG带来的损失才能降到最小，
国外有人提出需求阶段就应进行测试，这个我没什么经验，不知有没有
了解此道的高手指点一下。

以上是个人在开发中的一些体会，欢迎指正。

-----Original Message-----
From: lujun@topgroup.com.cn <lujun@topgroup.com.cn>
To: selab@egroups.com <selab@egroups.com>
Date: 2000-06-28 15:29
Subject: [selab] 请教关于软件测试的问题

测试工作(单元测试,集成测试,系统测试)在什麽情况下可以终止.
是否有一个标准之类 的东西.

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝                                          
本讨论来自SE Forum China，
欢迎大家来交流

From:  davew
To:  "SE Forum China" <selab@egroups.com>
题目：关于软件测试的问题

说得不错，必须明确测试的基准和依据是什么。
事实上，从V模型中可以很清楚地看出各个测试的工作和停止标准。
这里停止并不意味着这一测试工作的彻底完成，迭代是很正常的。
看到陈哥的高论，我也来说说软件测试，抛砖引玉，希望大家指点
具体地讲：

单元测试对应详细设计工作（报告或文档or similar），测试时，
单元测试人员(可能就是开发人员本人，不过经常是由另外一个开发
人员来对此进行单元测试)负责学习该详细设计，根据详细设计严格
对相应模块进行测试，单元测试有好多手段，如白盒测试和黑盒测
试（黑盒测试也用），在测试时根据不同公司、不同的项目软件既
定过程、不同的客户要求、不同的质量标准可能要求不同，如不同
代码覆盖率，并可能有一些特殊测试，例如2000测试也可能就在单
元测试时展开。一般讲，当单元测试完成对应的详细设计内规定时，
就可以停止该单元的单元测试。一定一定明确的是这里的详细设计
服从于其所属的概要设计乃至相应的需求文档（产生更改时必须以
更新后的为准），因此所谓单元测试对应详细设计恐怕不能单看那
一个或几个详细设计文档，即使真正做到了需求的在详细设计的落
实和可跟踪，有些内容还是不能完全反映在单个详细设计中，如很
多性能、功能需求和其他约束。所以说，单元测试是内容是相对确
切的，而作用十分重要，其实同时也是十分灵活的，我们的软件项
目对单元测试有一定理解，应用也还是较多的，但就是理解不够，
做的就更是容易流于形式了。

集成测试在V模型中对应的是概要设计，什么时候可以停止集成测
试呢，那就需要看概要设计的内容了。事实证明，很多问题都是
在集成测试才发现的，关注我们概要设计的模块间的接口吧！集成测
试的一项重要任务就是对不同模块间的接口设计进行检验，即使设计
的结构很细致，由于需求的变更，这文档or similar），测试时，
单元测试人员(可能就是开发人员本人，不过经常是由另外一个开发
人员来对此进行单元测试)负责学习该详细设计，根据详细设计严格
对相应模块进行测试，单元测试有好多手段，如白盒测试和黑盒测
试（黑盒测试也用），在测试时根据不同公司、不同的项目软件既
定过程、不同的客户要求、不同的质量标准可能要求不同，如不同
代码覆盖率，并可能有一些特殊测试，例如2000测试也可能就在单
元测试时展开。一般讲，当单元测试完成对应的详细设计内规定时，
就可以停止该单元的单元测试。一定一定明确的是这里的详细设计
服从于其所属的概要设计乃至相应的需求文档（产生更改时必须以
更新后的为准），因此所谓单元测试对应详细设计恐怕不能单看那
一个或几个详细设计文档，即使真正做到了需求的在详细设计的落
实和可跟踪，有些内容还是不能完全反映在单个详细设计中，如很
多性能、功能需求和其他约束。所以说，单元测试是内容是相对确
切的，而作用十分重要，其实同时也是十分灵活的，我们的软件项
目对单元测试有一定理解，应用也还是较多的，但就是理解不够，
做的就更是容易流于形式了。

集成测试在V模型中对应的是概要设计，什么时候可以停止集成测
试呢，那就需要看概要设计的内容了。事实证明，很多问题都是
在集成测试才发现的，关注我们概要设计的模块间的接口吧！集成测
试的一项重要任务就是对不同模块间的接口设计进行检验，即使设计
的结构很细致，由于需求的变更，这个接口可能会发生直接或间接的变化，
很多项目的一大部分时间都花在了集成测试上，一方面可能是单元测
试质量不高，另一方面也可能是概要设计存在问题，但概要设计出现
问题时，就需要重新进行结构的设计，这个重新的程度就看问题有多
大了，有时需要重新对整个方案进行考虑。

系统测试在V模型中对应的是需求，对应的是功能规格说明FS，理论
上讲，仅当FS中的每一个需求都得到确认和验证时，系统测试才能宣
告ok. 在项目功能分配上，不同组织系统测试安排可能不一样，有的
系统测试是由专门的部门来进行，有的则是项目组内部现招或调，无
论那种形式，都必须由项目组来统一组织和管理。根据系统测试的目标，
可以推出测试人员在FS形成阶段就应当开始工作了，深度理解FS，把握
需求分配，到集成设计完毕时，他们应当已经准备好了test case，
test script等等的设计。从我的体会来讲，用户手册的编写和维护
应当由测试人员来负责，他们最理解FS，最理解用户的每一项需求，
了解每一次需求变动，而且会对每一个需求进行确认和验证，用户手册的
工作可能就在很早就可以开始了（FS形成之后），大家以为如何呢？

时间所限，就谈这些。

davew
6/29

*********** REPLY SEPARATOR ***********
On 00-6-28 at 16:02 Gao,Smith wrote:
我个人的经验是：
测试工作是以系统的设计、需求为依据的，正常情况下，只要系统达到
设计要求和需求，并且没有运行错误，就可以OK。 测试具有一定的重复性，
集成测试阶段发现系统单元的新问题时，既要进行单元测试，又要进行集成
测试；测试的终止只 具有阶段性，比如，在系统发布前如果发现不了问题，
测试就可以告一段落，但用户使用过程中有可能发现新的问题，修
改问题时，又要进行新一轮的单元测试，集成测试，系统测试了
以上只是我的一些经验，不知会答的对否！

-----原始邮件-----
发件人: lujun@topgroup.com.cn [mailto:lujun@topgroup.com.cn]
发送时间: 2000年6月28日 15:29
收件人: selab@egroups.com
主题: [selab]请教关于软件测试的问题
测试工作(单元测试,集成测试,系统测试)在什麽情况下可以终止.是否有一个标准之类 的东
西.