• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

项目开发中软件测试类型的分类

发布: 2009-4-29 11:28 | 作者: 不详 | 来源: 测试时代采编 | 查看: 30次 | 进入软件测试论坛讨论

领测软件测试网   测试一般是放在系统完成后进行测试,但今天,却常常听到资深开发人员劝导新人们:“测试是开发的第一步”。这句话如何理解呢?如果从日本人发明的巴克质量管理的方式去理解,大概是指每一个环节交给下一级时都应该进行测试。有些测试对后面的操作没有太大的影响,如图片不漂亮、菜单不合理、布局很难看之类;而另一些,却直接让下一级无法开始工作,象用例不清晰、用例自相矛盾、组件内部错误、框架不合理等等。
  固然,一级级把关,可以把质量提高到至少一个档次以上;但就每一个环节而言,仍然是在开发的最后阶段。所以,看来本人的水平还是不到家,“测试是开发的第一步”难以理解,惟一可理解的就是规范先行、文档先行、文档规范化总应该是在编码以前,这也是QA的主要内容;大概这还多少算解释得通。这样,测试和规范两样东西就重合起来了,从严格角度看,测试就是测试,规范归入规范,还是从模块(项目)后的测试开始理解吧;所以所有关于编程和文档、设计规范的内容本人全部不纳入测试讨论范围。或者说,我们重点放在QC上,而不是着眼于规范的QA,尽管那也非常重要。
  单元测试(Unit test):是针对模块组件或方法的测试。在本人的操作中,一般是开发员工作范围内的测试;在具备组件接口规范的情况下,一般需要做一个测试工具模拟调用环境,编写测试实例,通过断点情况监视模块实际工作是否正常。一股采用这种方式开发的单一功能模块质量都是非常高的。但是如果没有统一的模块规范,那么开发与测试的工作量接近一比一;但如果模块是按统一的标准开发的,那么同一套测试套件就可以用到各个模件上,从而节省了测试时间。本人认为这属于开发部门工作范围内的测试,与QA/QC部门没有什么大的关系,事实上,在这一层次的用例也不是QC可以做到和理解的。
  白箱测试:在理解内部流程的情况下针对逻辑流程设计测试实例,目的是找出极限边缘以及内在的逻辑错误。单元测试中白箱测试的比例很高,(原因不难理解,还有谁比作者自已更理解模块的构造流程的?)。
  黑箱测试:这是QC部门的主要工作。黑箱测试主要在于编写测试实例。不过在实际操作中,都是把最不懂技术的成员分配做测试,最高技术水平就是会用VSS,所以也就别指望编什么测试实例。所谓的黑箱测试,常常是对着菜单按钮,这个按下去,噢,有东西出来了,对的,打个勾——其实,这时侯的实例就是一个个按下去然后看看有没有输出,而且只限于界面方面,内在的部分和边缘情况大概是不用指望的。但据作者所知,在CMM达到四以上的国外软件公司中,黑箱测试是对软件评价的最主要方式,通过合适的测试实例,除了最常见的可用性测试外,还包括压力测试,和怪用测试(Monkey test)。
  压力测试:评价一个系统极限可以承受的压力是多少,同时在超负荷后的的响应情况;同时,在极限状况下,一些平时不太出现的bug也会浮现出来。所以,这个测试作者认为不应该单独由QC部门进行,而应该由开发部门与QC部门联合进行。理想的系统在极限测试状况下就算响应不及,也不至于当机,并在负荷恢复正常后一段时间内可以恢复正常运转。这时当初对Windows恶评的原因之一:像网站一旦超出100-200个concurrent,Windows不但罢工还死掉了;不得不重启系统(当然,Windows任意硬重启都能死鱼翻生,大多数情况下吧,也属一种难能可贵的优点);而linux在超出负荷后一般情况下下降曲线不至于太明显——不过这也不是绝对的,作者就发现一旦Linux在极限状态下进入内存抖动时,死相和Windows差不了多少;所以内存不至于耗干是Linux可靠性能超过Windows的重要因素。
  回归测试;在修改其中一个模块后看其他模块有什么问题。作者认为这个测试是过程化程序的观念产物,在模块化软件中相互耦合程度低,而且服从统一的调动协议,是不是修改真是自家里的事情,和他人(模块)没有半点相干。
  整体测试:把不同的模块连结后,看看联合工作情况如何。这实际上是对接口协议的测试。作者认为是可以作为接口互动部分的设计一部分工作,没有必要摆出来作为流程之一。同理还有系统测试,反正最后整个系统运行起来是什么情况。看似大,但如果前面已经做到好好的,这里如果出问题那才叫怪呢!
Alpha测试:放任内部成员胡作非为的测试;
  Beta测试:让全世界的坏人都胡作非为的测试。
  过了这一关后,大概应该可以了吧??在欧洲美国日本的规范的软件公司大概是可以了。但在中国可不见得,许多时侯业务需求人员会蹦出来说:“不是这个样子的!”早的时侯他不知上那里去了!或者“加上另一个什么功能吧?”,早的时侯他大概是睡觉了。大家伙儿前面做的事情,就冲这两句话就全废了,全部事情得从中间某个环节重来,这才叫恶梦。这时,与其顺着他们老哥胡说八道跑,不如找出合同来一条条地仔细颁下去。

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: 分类 开发 类型 软件测试 项目


关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备2023014753号-2
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网