解决软件测试的近忧和远虑

发表于:2007-9-06 15:42

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:谢敏 沈雪芳 戴金龙    来源:网络转载

分享:

  软件测试设计属于“近忧”;软件测试件管理属于“远虑”。测试团队应同时做好这两方面工作,以使测试工作更加高效。

  针对某个特定的软件项目而言,测试团队应该如何合理地统筹安排软件测试工作?测试团队在完成一定数量的软件项目测试工作后又该如何快速提升下一软件项目测试工作的水平?这两个问题对于成立不久的软件测试团队而言是很棘手也是很现实的。

  做好软件测试设计,排除“近忧”

  过度测试会造成测试成本上升,而测试不够又会造成项目中遗留某些重要缺陷。但针对于某个特定的软件项目量身定做相应的软件测试方案是需要足够的技术能力和实战经验的。在软件测试活动的生命周期中,测试设计实际上是对前面所做测试计划进行进一步细化、具体化从而形成针对特定项目的测试策略、测试方案及测试用例的过程。

测试策略设计

  测试策略要解决的问题是根据测试需求、资源配备及工程环境,因地制宜剪裁测试技术,形成测试工作的技术路线。对于一个小项目做大测试是得不偿失的,同样,对一个大项目做小测试也是不负责任的。通常,对于工作量小于5个人月的普通商用软件,重点应该抓系统测试(包括功能测试性能测试及GUI测试等)及验收测试,而不宜铺排开来,面面俱到。而对于一个工作量接近30个人月的中型商用软件而言,一般应该认真完成需求验证、设计验证、单元测试、集成测试、系统测试及验收测试,而不宜只关注系统测试。但这并不绝对,譬如,用户希望软件有好的人机交互界面,这时,就应该考虑采用快速原型生成工具来进行用户界面设计的确认测试;又如用户希望软件有较好的健壮性,这时,就应该考虑进行相应的负载测试和可恢复性测试。

  一个好的测试策略设计应能清楚地回答下列问题:是否在测试成本与测试预期效果之间达到了最佳平衡?是否在测试需求与测试活动安排之间达到了最佳平衡?策略设计形成的技术路线是否在工程实际与企业质量承诺之间达到了最佳平衡?策略设计形成的技术路线是否具有可行性?有无设计依据?

测试方案设计

  测试方案是对测试策略设计形成的技术路线的进一步细化。如某一技术路线规定了某小型软件项目测试工作要重点围绕“功能测试与验收测试”展开。那么测试方案设计阶段就必须具体定义哪些功能需要被测试到,以及如何去测试,哪些部分需要做验收,以及采用什么形式做。

  测试方案的设计除了要明确定义各个测试活动的对象、执行人员、测试进度、放行标准等一系列属性外,还要充分考虑到成本与技术可行性。一个好的测试方案总是遵循以下设计原则:测试成本与测试工作产生的效益处于最佳比值; 各具体测试活动描述清晰,目标明确,内容完备; 测试手段是可行的; 测试产生的结果是可以用于指导产品质量改进的。

  在进行测试方案的具体设计时,常常也暴露出来一些难题和障碍。最常见的就是角色安排多,测试人员少。解决这一问题的根本途径是招募测试人才,建设高效测试团队。然而,远水解不了近渴。那么,就需要考虑一下变通之策:外包和外协都是不错的处理办法。另外,建议适当考虑自动测试工具,某些工具的确能减少工作压力。除了人手的问题,了解测试团队各成员的专业技能也是很重要的,避免无人担当相应角色。除此之外,设计人员还应多多参考软件开发管理类文档,在测试的时间进度安排上与开发保持同步,如果开发进度有变动,应及时调整相应的测试进度安排。

测试用例设计

  测试用例设计是对测试方案实现技术部分更为细致描述,相关设计技术已经相对成熟(见表1)。本文选取了几个有代表性的方法进行介绍。

             

  其中,黑盒测试中常用的等价类划分方法是先把程序的输入域划分成若干区间,然后从每个区间中选取少数代表性数据当作测试用例(由于数量太大,穷举测试一般情况下不可能实现)。在使用等价类划分方法时,通常会涉及到两种等价类:有效等价类和无效等价类。顾名思义,有效等价类就是对程序的规格说明是有意义的合理的输入数据集; 无效等价类就是对程序规格说明书不合理或无效的输入数据集。我们在设计测试用例时,要兼顾这两种情况。同时要注意一个测试用例只能覆盖一个无效等价类。这样便于错误定位,防止一个错误表征掩盖了另一个错误。例如,程序的规格说明中规定了“……每类科技图书10至50册,……”,若一个测试用例为“小说5册”,在测试中很可能只检测出书的类型错误(小说不是科技类图书),而忽略了书的册数错误(5不在10至50之间)。

  黑盒测试中另一个常用的测试用例设计方法是边界值分析,它是一种补充等价类划分的测试用例设计技术,它选择一组测试用例检查边界值是否符合相应规格说明。因为输入域的边界比中间更加容易发生错误,所以引进了边界值分析方法往往能发现更多的软件缺陷和错误。

  而不管黑盒测试多么全面,它都可能忽略类似于逻辑性错误、潜在破坏性执行流程、冗余程序代码乃至于简单打字错误等,而白盒测试则可以进一步发现它们,查找出代码层次的错误和缺陷。白盒测试用例设计包括的门类也相当繁多,这里限于篇幅不再赘述。

做好软件测试件管理,消除“远虑”

  测试件泛指一切手工测试和自动测试活动中必须受控或值得纳入测试团队知识库的所有输入和输出数据,包含团队自主开发的测试自动化工具。如何有效地管理好测试件,是影响测试团队效率与整体水平的重要因素之一。在待测项目规模小、功能点少的情况下,测试工作或许能正常进行。但如果测试团队要同时测试多个项目,各项目规模都相对较大,涉及的测试人员较多时,测试工作的效率可能会大为降低。除此之外,测试件管理对于团队的整体水平提高亦具有不可估量的长远意义,将有代表的测试用例、测试方案等积累起来,可避免团队长时间在一个较低水平上徘徊。

  在表2所示测试件中,除了测试用例自动化管理、测试缺陷(报告)跟踪管理已经有较好的自动化管理工具外,其他测试件目前尚未发现有对应的专用管理工具,笔者建议采用配置管理工具(如CVS)。(由于测试缺陷跟踪管理在上期已有详细的论述,这部分内容本文从略)

           

 

21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号