从微软的转型看软件测试的发展 (2)

发布:

在实际工作中,大部分公司使用敏捷开发(agile development), 软件项目的构建被切分成多个子项目,各个子项目的成果都可以测试, 且可以集成和统一运行。它是一种以人为核心,人们可以先做想要做的的模块,可以修改流程,可以变更和修改当前的功能; 同时又是一种迭代,循序渐进的开发方法。即使有多年的敏捷开发应用经验的团队,测试都是一种挑战,人们很容易的说, 我们自始至终都做测试, 但是很难把它做好。有时测试影响了这个项目的时间进度,质量得不到保证。

经常听到团队的人说:“为了实现新的功能, 代码到最后一刻才做好,怎么能完成测试呢?”

“我们试图用自动测试代码来完成验收这个新的编译,可是十有八九要失败,因为程序代码改变了,而自动测试没有及时更新那些调用。”

“我想许多缺陷没有发现, 因为我们重点测试已有的功能,新的功能,对软件系统没有仔细的测试。”

现在人们普遍认为,测试人员测试,程序员写编码,把二者分开是很重要的。独立的测试队伍才能保证软件的质量。现在我们来分析一下为什么程序员不能测试。

也许你会说,”当然, 程序员可以测试”, 但是, “他们不会找出他们自己的编码错误,也许他们可以测试其他人的代码, 但不是他们自己的。”

但是,同时作为程序员和测试员, 时间不够是比上述问题更重要的问题,至少我个人认为是这样。当我的时间不够时, 我匆匆忙忙完成任务,因此就容易忘记或漏掉去测试一些功能。后来, 当缺陷从最终用户哪里反馈来了, 这个缺陷就发生在我忽略的那一部分,或者我忘记的那部分。测试其他人的编码不能发现由于时间的压力,忽略的那些功能而导致的缺陷。

推荐阅读

科技产能开发中的风险阻拦问题

开发AlphaGo人工智能软件的人原来就是他

开发中国市场, 我于小扎同行

从微软的转型看软件测试的发展 (2)

从微软的转型看软件测试的发展 (1)

多哥杂谈 :软件开发的途径

系统语言与思考的有效探讨

在ubuntu系统安装java详细教程