首页:软件测试网 >> 软件测试技术 >> 软件测试专家堂 >> 软件测试专家文章 >> 查看资讯

项目案例分析第五期

发布: 2007-4-22 20:30 | 作者: admin | 来源: | 查看: 252次 | 进入软件测试论坛讨论

案例分析第五期（2005-07）

你在日常的工作中没有遇到问题吗？如果有，你也可以提交案例。【我要提交案例】
案例分析
		本期案例
题目：白盒测试的困惑：究竟多少人在做？适用范围？所属主题：测试技术作者：Alan
案例内容：　　一般软件工程书籍在介绍白盒测试时，通常包括了“流图符号”、“环形复杂性估算”、“图矩阵”、“条件测试”、“数据流测试”、“循环测试”等方法。这些方法比较复杂，对于非关键性应用（即除了航空航天，原子能反应堆控制等领域），从经济角度来看进行白盒测试似乎不大合理。　　XP的测试驱动开发中强调的单元测试，从网络上现有的介绍资料（主要是JUnit和NUnit的有关文档）来看，似乎仅限于程序特性的验证而已，和测试理论书籍中的白盒测试、黑盒测试还是有很大不同。　　像Parasoft公司的JTest、C++Test等工具，其中的文档好像说要进行一般测试理论意义上的那种单元测试，就必须采用Design by Contract的方法。也就是说，必须提供严格的程序规格说明。　　那么，一般的应用开发，特别是企业应用开发，考虑到经济合理的目标，应该如何进行测试呢？　　诚心请教各位，你们真正做过那种测试理论书上的白盒测试吗？这种白盒测试适用范围何在？特别希望在航空航天、国防军工领域，或者嵌入式开发、电信开发领域有测试经验的网友给予指点！不胜感激！　　而且，另外一个感觉是所有的书都在互相抄袭，不知道谁是原创。关于白盒测试，几乎所有书的案例都是同一个！哪位有经验的网友能够给出一个不同于测试理论书中的实际案例？谢谢！　　另外，那本《Software Testing - A Craftsman Approach》（网上有英文电子版，中文版由机械工业出版），作者的开发领域是电话交换系统。那么，除了这种领域的开发，比如ERP开发，就不需要这种严格的形式化的以数学理论为基础的测试吗？ERP测试有什么方法呢？哪位网友能谈谈呢？
相关分析
分析一：　　分析内容：　　白盒测试实际上是一种测试方法，测试的一种思维方式.按照解释来看，就是基于被测对象的结构来设计测试套件。有些人习惯的将白盒测试和单元测试混淆在一起。实际上集成,系统测试都可以使用白盒测试的方法。　　即使在ERP类型的软件测试中，也是有需要单元测试的地方。系统中关键的组件、类、服务端组件都是需要经过严格的各个级别的测试。　　有的公司可能会有详细的函数规格说明书，在这样的情况下，采用白盒测试技术的单元测试是必须要做的。
分析二：　　作者：newbie 　　分析内容：　　基于功能规格说明书的测试，应该是黑盒测试吧？　　我理解白盒测试应该是基于程序源代码或者控制流程图之类能够揭示程序内部结构的制品（artifact）的测试。　　我希望了解的是，如何采用白盒测试技术进行单元测试？特别是ERP领域。希望能够提供实例。先谢谢了！　　白盒测试，就是在已经了解软件的内部结构的基础上，有针对性地设计更有可能暴露和揭示程序错误和缺陷的测试用例的测试方法。　　在单元测试阶段，白盒测试需要程序源代码或控制流程图；而黑盒测试需要程序功能规格说明书。　　在集成测试阶段，白盒测试需要交互图（序列图和协作图）；而黑盒测试需要集成模块的规格说明书。　　依次类推。
分析三：　　作者：cocoying 　　分析内容：　　个人认为黑盒测试、白盒测试都是相对的！　　对于一个模块进行黑盒测试，他对于整个系统就是白盒测试！　　而对于一个类进行黑盒测试，他对于所属模块就是白盒测试！　　对于一个方法乃至算法进行黑盒测试，他对于所属类就是白盒测试！
分析四：　　作者：hunle 　　分析内容：　　赞同cocoying 　　个人认为：最好不要用黑盒、白盒来区分测试（尤其是对于测试工作人员）。应该针对不同的测试对象选用不同的测试方法，以期达到不同的测试标准。
分析五：　　作者：Alan 　　分析内容：　　white box ，black box 测试只是一种测试方法。和测试的类型没有必然的联系。即使是系统级别的测试，也可以使用white box 。同样你对一个单元测试的时候，比方一个函数，也是可以采用black box 来测试函数的外部特性。
分析六：　　作者：取自深圳测试论坛深圳测试论坛流程版　　分析内容：　　第四环节单元测试　　这一个环节是单元测试。在测试过程中，这一块是比较神秘的地方。因为国内的测试人员，有很多人都是看过理论知道而没有真实的去做过。单元测试对测试人员设计能力要求比较高。　　单元测试也要有测试计划、测试用例等相关文档。当然，如果不做单元测试的话也就不会有这些文档了。单元测试的技术　　从整体上可分为白盒测试和黑盒测试其实就是对程序的逻辑结构和数据流的检查。　　白盒测试也就是我们通常是的程序员代码互查。通常使用的技术是独立路径测试。主要是要检查独立的执行路径，程序是否有逻辑错误，对循环的检查，还有内部数据的有效性检查等等。　　黑盒测试注重于测试软件的功能性需求，通常黑盒测试试图发现以下类型的错误：功能不正确或遗漏，接口错误，性能错误等等。黑盒测试技术通常分为等价划分、边界值分析、因果图等。做黑盒测试要设计驱动模块和桩模块，也就是要测试人员写代码了。　　单元测试更多的也还是借助于测试工具，但是有相当一部分的单元测试工具是要和源代码结合起来的。所以要做好单元测试就要有比较好的编码功底了。　　由于开发方式的不同，单元的划分存在一些差异，一般的单元划分方法如下：　　面向对象的软件开发：以Class(类)作为测试的最小单元。以方法的内部结构作为测试的重点。　　结构化的软件开发：以模块（函数、过程）作为测试的最小单元。　　在这里我不试图对单元测试做更多的讲解，所以这一环节的内容很少。
分析七：　　作者：ahhuang 　　分析内容：　　测试的类型分单元、集成、系统、接受性测试。测试的技术则有白、灰、黑盒。　　呵呵，不想在浪费时间纸上谈兵。但清晰的概念有利于讨论。　　将单元测试类型同白盒测试技术混淆是非常正常的，但也没什么大不了的（毕竟我们不是理论家，而是实干者）。　　关键是如果你为每个“单元”都编写驱动和桩模块，来跑遍所有测试路径，那你就达到了两者的和谐统一。但这通常是不可能的（sorry，是对于我们开发非高危性系统来说），除非你时间盒资源大大的多。　　实际上更可行的做法是单元集测试（编写少量的驱动和桩模块，对几个有调用关系的单元联测）运用上灰盒测试（接口级别的测试），以期望少投入，快产出，当然，这是以质量为代价的（进度要求同质量总是成反比的）
分析八：　　作者：yanyubaobao 　　分析内容：　　之前一直做功能性验证测试，熟悉了自动测试软件，最近看到一份程序员提供的部分软件函数说明，在分析这些函数功能和参数以及各自关系的过程中发现很多在集成测试中不好发现的问题在这里可以找到很好的依据，在某种程度上可以加强测试的深度　　不过我们在用户方面使用深度的探索上有待提高，什么是用户常用的，我们需要寻找。
分析九：　　作者：关河　　分析内容：　　首先，白盒测试不等于单元测试　　白盒测试是一种测试方法，而单元测试是测试过程。　　在单元测试过程中，一般采用白盒测试的方法，但由于要实现完整意义上的路径覆盖测试开销实在太大，一般的公司很少会把路径覆盖作为单元测试的退出准则，我所见到的一般要求语句覆盖不小于90％（甚至更高）。　　除单元测试意外的测试阶段（集成测试、系统测试）也可以采用白盒测试方法，此时的白盒测试方法体现在利用对代码的认识设计相应的测试用例，这部分就是非常依赖经验和开发基础的了，如yanyubaobao所说：“在分析这些函数功能和参数以及各自关系的过程中发现很多在集成测试中不好发现的问题在这里可以找到很好的依据”，通过这种方式可以将测试进行到更深入的程度。
分析十：　　作者：戴金龙　　分析内容：　　白盒和黑盒是针对同一事物采用不同的观察角度而产生出的方法差异。白盒注重事物内部的组织、结构与逻辑；黑盒注重事物整体的一致、协作与效用。二者是相辅相成的，统一于高品质的软件测试过程之中。　　有时候，事物本身是如此复杂，以致单使用白盒和黑盒方法还不足以描述清楚其局部与整体、内部与外部之间错综复杂的关系，于是，人们又提出灰盒的概念，灰盒是联系白盒方法与黑盒方法的一个中间地带。视所分析的对象本质及环境不同，灰盒的“宽度”有所差异。　　打个比方，研究一棵树木，如果去一一察看它的叶子、树冠、树干和根系，这时使用的就是白盒方法；如果要综合起来判断树木的种属、生长状态及使用价值，这时使用的就是黑盒测试的方法；而如何从叶子、树冠、树干及根系推断出种属、生长状态及使用价值，就得灰盒测试的方法。　　白盒与黑盒是相对的。例如，研究一棵树木的种属、生长状态及使用价值在上面的例子中属于黑盒部分，但如果研究对象是整片的树林，自然，上述部分又成了白盒方法应该关心的内容了。　　白盒与黑盒乃至灰盒在测试流程中具体如何使用，使用到什么程度，部分是工程问题，部分是艺术问题。工程问题，可以借鉴以往的技术文档照猫画虎，艺术问题则要靠管理者个人的技能、对团队成员的领悟以及对工程环境的把握来统筹完成。
测试时代工作室分析
从产品来讲：商业级应用软件中要求最高的就是金融类了，这就决定了软件的侧重点－即数据安全及正确。其次才是流程的正确和软件的易用。　　从软件内部实现来看：80%以上的代码是用来实现框架、应用及流程的，只有不到20%的代码用于完成数据校验和计算。　　由此可见，商业软件的测试中，关键的测试所占比例不高。　　从测试技术上讲：商业软件所使用到的技术主要是黑盒测试技术，这是其特点所决定的。还有少量的白盒技术，但在实际中很少有公司愿意投入人力来作。白盒测试做法　　第一步：确定软件中的数据计算及校验模块　　第二步：使用基本路径法计算模块中所有可能的路径　　第三步：设计用例，覆盖所有路径　　商业应用级软件的白盒测试只需使用基本路径法遍历路径即可。基本路径法可在任意一本介绍测试技术的书籍中找到。　　目的：验证设计实现即可。（无需做到军用或航天产品的质量级）　　好处：降低测试的难度以压缩测试周期和投入。　　使用范围：测试的各阶段均可进行白盒测试。　　使用对象：数据安全和数据计算。（如利息或税费计算）　　说明：　　1.基本路径法比较严谨，符合使用对象对测试的要求。　　2.由于使用方法单一，从而在不降低测试效果的前提下降低的技术复杂性和实现难度。　　3.由于只针对不到20%的代码进行白盒测试，所以比较经济。
关注案例
焦点5：在软件项目规划和开发阶段，如何考虑与测试配合？焦点6：覆盖率如何计算？焦点7：如何进行滚动测试？焦点8：嵌入式软件的测试设计应该如何做？焦点9：怎么搭建测试环境。
案例分析
你在日常的工作中没有遇到问题吗？如果有，你也可以提交案例。【我要提交案例】
－>本期案例点评