在软件测试过程中,我们定义了单元测试、集成测试、系统测试三个阶段。针对
不同的软件项目,测试的深度不同,测试停止的准则也不一样。如单元测试,有的项目我 们要求达到一定的覆盖率(语句、分支、基本路径)。有的项目没有要求,或降低覆盖率 。请教集成测试和系统测试的一个停止准则。特别是集成测试这个阶段不好把握,在单元 测试阶段中有时也作一些集成测试的工作(集成阶段不太明确)! |
个人感觉测试方法在国内很多小软件公司都不大受重视。大家都知道软件拿给用户用之前一定要测试,但是我看见过比较多的做法都是随便招几个测试人员,待遇给得很低,教教他们软件是干什么用的,然后就扔给他们测去了。白盒测试很少有人做,更不用说使用一些自动化的测试工具,写一些脚本做回归测试之类的了。测试人员普遍被认为是水平低做不了程序员才让他做测试的。我挺长时间也停留在这个认识阶段,直到后来读了一本《客户/服务器系统测试指南》才有所改善。
我以前参加的项目在需求阶段通常还是有比较严格的需求审查阶段,但是没有开发过具体的测试用例来进行需求阶段的测试工作。感觉需求阶段没有可以运行的软件,不清楚怎么样做测试,所以就把在需求阶段结合原型对需求规格进行的质量验证和审查理解成需求阶段的测试了。现在看来好像理解有问题,需求阶段也可以开发出具体的测试用例来的。希望有这方面经验的高手指点。
看过《软件测试自动化技术与实例详解》这本书吗? 里面提到了一个早期的软件测试V模型
需求-------------验收测试
功能--------系统测试
设计------集成测试
编码---单元测试
其实,在我们以前的手工测试中,也基本上是按照这个模型来设计我们的测试计划的,不过在真正的实施过程中,又完全地集中到功能测试上了。 其实在最终交到用户手中的时候,基本上功能实现,也就OK 了,至于其他的一些诸如 压力测试,容量测试,等等,根本就没有执行。不知各位在你们的工作过程当中是怎样?
我提供二个集中测试的停止准则,供大家讨论
1. 完成软件测试通常要经历三个阶段,在第一个阶段为单元测试阶段,因为存在的故障较多,可能系统的一部分模块还不能正常运行,测试中还有一部分并不需要测试用例,因此测试用例完成的很慢。第二个阶段主要是集中测试阶段,使用黑盒法测试,需要大量的测试用例,所以完成测试用例的效率很高。第三个阶段发现的错误往往是很微妙的,极难改正,因此测试用例的完成率又明显降低。
如果第一阶段占用的时间超过允许适用时间的50%,表明各单元模块存在错误和问题较多,该项工程的失败不可避免。
如果第二阶段占用的时间不在30%-60%范围内,问题可能出现在测试方法和测试用例上,也可能编码存在错误。
上诉两种情况有一条满足,就应该停止测试。
2.一般一周根据每天记录的测试用例错误比例描出一条平滑的曲线,当错误发现率开始下降后,在70%-80%完成时间的某个点上,计算这时候的错误发现的斜率,即导数。当斜率范围不在-0.3到-1内,该工程可能存在较多问题,应该停止测试。
如下几本书都是软件测试的经典,是IEEE的CSEP中关于Software Testing部分的参考书
第一本有译本.
Testing Object-Oriented Systems, Binder, Robert V. Reading, Massachusetts: Addison-Wesley, 2000.
Complete Guide to Software Testing, 2nd Ed., Hetzel, Bill, New York, New York: John Wiley & Son, 1993.
Software Testing : A Craftsman 's Approach, Jorgensen, Paul C. CRC Press, 1995.
Testing Computer Software, 2nd Ed., Kaner, Clem, Jack Falk, and Hung Quoc Nguyen, New York, New York: John Wiley and Sons, 1999.
Software Testing and Continuous Quality Improvement, Lewis, William. CRC Press 2000.
The Craft of Software Testing: Subsystems Testing Including Object-Based and Object-Oriented Testing, Marick, Brian. Prentice Hall, 1997
/
什么是白盒测试,什么是黑盒测试?(转)
答:白盒测试和黑盒测试是根据对软件代码的可见性,采用的测试方法;凡是针对代码本身的测试,都可以看做是白盒测试,凡是不考虑代码如何实现,只对代码能实现的功能进行的测试都可以看作黑盒测试。
black box testing focus on functional requirements,attempts to find following errors:
1.incorrect or missing functions;
2.interfaces errors;
3.errors in data structures or extenal database access;
4.performance errors;
5.initialisation and termination errors
white box testing test control structure of a procedural design can derive test cases to ensure:
1.all independent paths are exercised at least once;
2.all logic decisions are exercised both ture and false paths;
3.all loops are executed at their boundaries and within operational bounds;
4.all internal data structure are exercised to ensure validity;
白盒与黑盒测试什么区分?
1、黑盒测试
黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等,主要用于软件确认测试。 “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。
2、白盒测试
白盒测试也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。
“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。第二,穷举路径测试不可能查出程序中因遗漏路径而出错。第三,穷举路径测试可能发现不了一些与数据相关的错误。
软件人员使用白盒测试方法,主要想对程序模块进行如下的检查:
– 对程序模块的所有独立的执行路径至少测试一次;
– 对所有的逻辑判定,取 “ 真 ” 与取 “ 假 ” 的两种情况都至少测试一次;
– 在循环的边界和运行界限内执行循环体;
– 测试内部数据结构的有效性,等。
具体包含的逻辑覆盖有: – 语句覆盖 – 判定覆盖 – 条件覆盖 – 判定-条件覆盖 – 条件组合覆盖 – 路径覆盖。
a白盒测试技术 (White Box Testing) : 深入到代码一级的测试,使用这种技术发现问题最早,效果也是最好的。该技术主要的特征是测试对象进入了代码内部,根据开发人员对代码和对程序的熟悉程度,对有需要的部分进行在软件编码阶段,开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主,在 JAVA 平台使用 Xunit 系列工具进行测试, Xunit 测试工具是类一级的测试工具对每一个类和该类的方法进行测试。
b黑盒测试技术( Black Box Testing ):黑盒测试的内容主要有以下几个方面,但是主要还是功能部分。主要是覆盖全部的功能,可以结合兼容,性能测试等方面进行,根据软件需求,设计文档,模拟客户场景随系统进行实际的测试,这种测试技术是使用最多的测试技术涵盖了测试的方方面面,可以考虑以下方面
c正确性 (Correctness) :计算结果,命名等方面。
d可用性 (Usability) :是否可以满足软件的需求说明。
e边界条件 (Boundary Condition) :输入部分的边界值,就是使用一般书中说的等价类划分,试试最大最小和非法数据等等。
f性能 (Performance) : 正常使用的时间内系统完成一个任务需要的时间,多人同时使用的时候响应时间在可以接受范围内。 J2EE 技术实现的系统在性能方面更是需要照顾的,一般原则是 3 秒以下接受, 3-5 秒可以接受, 5 秒以上就影响易用性了。如果在测试过程中发现性能问题,修复起来是非常艰难的,因为这常常意味着程序的算法不好,结构不好,或者设计有问题。因此在产品开发的开始阶段,就要考虑到软件的性能问题
g压力测试 (Stress) : 多用户情况可以考虑使用压力测试工具,建议将压力和性能测试结合起来进行。如果有负载平衡的话还要在服务器端打开监测工具 , 查看服务器 CPU 使用率,内存占用情况,如果有必要可以模拟大量数据输入,对硬盘的影响等等信息。如果有必要的话必须进行性能优化 ( 软硬件都可以 ) 。这里的压力测试针对的是某几项功能。
h错误恢复 (Error Recovery) :错误处理,页面数据验证,包括突然间断电,输入脏数据等。
i安全性测试 (Security) :这个领域正在研究中,防火墙、补丁包、杀毒软件等的就不必说了,不过可以考虑。破坏性测试时任意看了一些资料后得知 , 这里面设计到的知识 \ 内容可以写本书了 , 不是一两句可以说清的,特别是一些商务网站,或者跟钱有关,或者和公司秘密有关的 web 更是需要这方面的测试,在外国有一种专门干这一行的人叫安全顾问,可以审核代码,提出安全建议,出现紧急事件时的处理办法等,在国内没有听说哪里有专门搞安全技术测试的内容。
j 兼容性 (Compatibility) :不同浏览器,不同应用程序版本在实现功能时的表现不同的上网方式,如果你测试的是一个公共网站的话。