灰盒测试与团队协作

发表于:2011-7-26 11:51

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

 作者:未知    来源:51Testing软件测试网采编

分享:

  引言:互联网公司几乎所有的部门都跟测试部门打过交道,大家对测试都或多或少有所了解,角度不同,理解不同,我们的工作可不仅仅是找BUG,发布产品这么简单噢,背后有很多内容与故事,以后可以慢慢道来,实际上,我们的核心理念就是与各开发或项目部门协作,确保并提高软件的质量,这其中,我们进行了一些尝试与探索。

  需求:在测试部所有的工作中,包含了两个大块的内容,功能测试性能测试,大家可以回忆一下,产品完成了,项目上线了,是不是经常会找测试部来检查质量?我们也有机会接触公司各种新产品,甚至奔赴全国各地(也许空闲时间可以逛逛大好好河山),但是,大家注意没有,我们介入的时间都是什么时候?末期。嗯,大多都是这种时候,一般来说,末期这个词意味着效率要高,也意味着风险也高,在长期的合作过程中,我们发现,也许,更早的协作、更早的介入可能更好,正如一个楼盘的建设,打地基时就让质监部门检查是很重要的,房子盖完了,查出有问题,损失可就大了。

  图1著名的“楼歪歪”,要知道,比萨斜塔是不可复制的


  有意思的是,在学校的时候,软件工程中,也是这么说的。

  切入:提起协作,总需要一个名头,一个方向,甚至还需要理论支撑,因为这个工作还需要传承下去。为此我们在循序的工作中,总结出一套具有“地方”特色的协作方法,切入点正是一种新的测试理念:灰盒测试

  提起测试,稍有了解的朋友都会说,了解,不久黑盒测试白盒测试吗。没错,按照测试无数分类标准中的一种,这么分没错的,前者正如其名,不关心测试代码,从功能上(其实更多的时候就是从界面开始)来进行测试,一个常见的场景是这样的,“姚工,刚才在注册用户提交时,弹出一个JS错误框啊,咋整的啊?”,这个时候,姚工可能要自己用一下,查一下,改一下,然后测试者过一下,就这样,这种测试直观、快捷,缺点是太直观以至于看不到暗处,太快捷以至于只能后期介入,界面变了,时间晚了,都会对整个过程造成影响。

  白盒测试,那就简单了,能看见盒子里面的代码嘛,实际上我们很多部门已经在开展的单元测试就是白盒测试的一种,这个过程质保当然也是可以做的,一种常见的场景是这样的,“王总,Portal的注册方法有问题啊,空名提交没有返回错误!”。白盒测试的好处是定位准确,坏处是成本高难度大,实际上,在软件测试的课程中,大家最觉得最难的就是白盒测试的方法,左路径右覆盖,非一日之功所能拈来。另一个问题就是,开发与测试的任务协调问题,这种模式要求测试承担一部分开发的工作,就目前我们的资源来说,还达不到这种条件。实际上,单元测试我认为还是应该由开发来进行,当然,如果以后质保资源更加充分,可以调整,你知道,质保的工作还是很饱和的。

  罗嗦半天,黑盒、白盒都有了,都有问题,我们要说的就是,我们整了个灰盒测试,部门解决了以上问题,更重要的,是为了改进过程。

  方法:其实灰盒测试不是我们发明的,1999年洛克希德-马丁公司(大名鼎鼎大名鼎鼎啊)就提出了灰盒测试的方法,揉合了黑盒、白盒与变异测试等方法,其关注点就是从需求入手,获取用例并运用与校验中。目前,灰盒测试这种方法在国外运用尤其多,国内的话,淘宝公司也有一定的积累。由于目前公开信息还是有限,因此我们摸索着也开始提出一些具有我们自己特色的方法与理论:基于业务逻辑的灰盒测试方法。


 图2灰盒子好不好暂且说,重要的是它提供了一种新的选择


  我们想要什么呢?

  补充(注意不是替代)当前的测试、更早的介入测试、更好的协作、自动化(该偷懒时就要偷懒)。

  为了达到这个目的,我们首先改进了开发流程,常见的软件开发流程是这样的:

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

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号