期货交易自动化论坛

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 51|回复: 0

软件测试之忧思 - 金融行业 - ITPUB论坛-专业的IT技术社区

[复制链接] |主动推送

285万

主题

285万

帖子

855万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
8553710
发表于 2022-9-11 10:19:24 | 显示全部楼层 |阅读模式
早几年,软件测试既没有受到特别重视,也没有怎么单独划分,一般都是每个开发人员编码完毕对单元进行测试,然后再找来业务人员进行集成测试。然而因为没有统一规范,开发人员单元测试则各不相同,有的人能够组织条件和数据把程序中每一分支每一行都测到,有的人干脆测都不测,直接提交业务人员来测试,其结果可想而知。
现在软件测试越来越被重视,更甚至于成了一种独立的职业划分!许多公司也都有了独立软件测试部门。现在规范到是规范了,然而实际效果则往往令人摇头,效率底下更是让人直发感慨。其主要问题我认为存在两个方面,一是对于开发人员来讲,因为有了专职软件测试工程师,于是有了更多的“依赖”心理,有了更多的“不负责任”,二是对于专职测试人员来讲,我以为软件测试工程师应该是由那些有丰富开发经验的人组成,但实际上许多公司的测试人员不是这样。为什么这么说?
对于一个大型软件来说,测试无非分单元测试和集成测试。这个集成测试可以包含不等集成度的测试,最简单“集成”是两个不同功能模块的连接测试,最复杂的“集成”则是全系统的集成。越是单元测试,越是需要丰富技术和应用开发经验,随着集成测试的“集成度”提高,测试人员的业务能力和管理能力则愈见突显。由于强调集成测试,实际工作中往往忽视了单元测试,然而这恰恰才是最致命的。实际表明,测试问题绝大部分出在单元问题上!集成测试目的不是为了找出单元的问题,而是为了测试不同功能模块之间是否存在不一致的问题。实际表明,凡是单元测试做得好的,则集成测试速度会非常快,反之,则非常慢!根本的问题就是单元测试没有做充分!
测试的目的无非是两个,一是测试功能是否实现,二是测试性能是否达标。测试手段也无非两种,一个是白盒测试,一个是黑盒测试。对于单元测试来讲,主要测试单元功能是否完整实现,测试手段则必须采用白盒测试。现在问题来了,单元测试到底由谁来测?测试工程师会说让开发工程师来测,而常常开发工程师会说那要你们测试工程师干什么用的?如何做到单元测试的规范化?单元测试要求采用DEBUG方式的白盒测试,没有开发经验的测试工程师显然根本无法胜任!
那么集成测试呢?更多地需要准备测试案例。这些案例应该是完备的,即各种极端情况案例都应该具备。其实如果单元功能测试做得好,单元BUG基本都可以被解决完毕。集成测试最后的集成应该是性能测试。过去常常是开发人员编写简单的模拟工具发起压力测试。如果没有开发经验,这也是很难完成的。当然现在测试业很发达了,有了许多测试工具,比如Rational Robot, 比如LoadRunner,在这些功能强大的测试工具面前,测试工程师越来越象是根木头。然而我对那些功能复杂的测试工具却是充满了不信任的。比如我曾经有过使用LoadRunner的经历,需要用LoadRunner模拟大批量前端同时发起交易。然而结果却是非常地令人失望,要使用LoadRunner模拟大批量前端将会空前地消耗内存资源,普通计算机根本就玩不起,更加致命的是数量稍微一上来,LoadRunner发送交易的速度慢得惊人,根本达不到并发进行压力测试的要求。也许我们没有用好LoadRunner,但从此对这些测试工具充满了不信任。而我们简单编写模拟前端程序就可以达到压力测试的要求。没有开发经验的人能做到吗?
软件测试,至少95%问题出在单元,然而单元测试至少95%地被忽视! 往往耗费巨大的集成测试最后结果是发现某一单元的某一分支功能根本就没实现,或者某一语句最低级的错误,这是非常令人遗憾的。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|小黑屋|期货交易自动化论坛

GMT+8, 2025-9-7 20:07 , Processed in 0.071707 second(s), 28 queries .

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表