浅谈测试与开发并行

发表于:2010-4-02 14:39

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

 作者:yuanhua    来源:Taobao QA Team

  参加了两次测试相关的培训,有些感想,结合工作的情况,像谈谈我对于这个问题的看法。

  第二次培训的是前微软的测试经理,他提到了一个课题“测试与开发并行”,他提到的很多观点与做法是值得我们思考的。他的核心思想是想让测试不再成为整个项目周期中单独的阶段,而是与开发并行的阶段。相信很多人都会对此提出质疑,软件还没有做出来,我们测试怎么可以开始测试了呢?他觉得要做到这样:

  1、对测试人员的要求是很高,最低是不低于开发人员,他说了一句比较白的话“开发与测试做同一个系统,做出来后进行比较”。

  2、自动化的测试技术。只有让测试更多的自动化,才能使测试更有效率,不在测试执行上花费大多的时间,只有这样才可以测试在前期做更多的工作,而留给开发充分的时间进行开发。自动化不仅在执行测试上,还有一部分是测试过程中的自动化,从准备环境到测试报告。

  3、文档的重要性。需求文档需要多方评审签字确认,各个方面都必须都对需求做充分的了解,因为你一旦签了字,就意味着你没有什么任何问题了。开发与测试之后会根据需求文档编写开发与测试文档,同样需要各方签字确认。这样在一定程度中上保证了需求与设计确定,测试有了确定的依据后,自动化程序就可以与开发同时编写了。

  再说一下第一次培训的老师,他好像是外包公司测试经理,因为做过不少培训,他对各个大公司的测试都比较,他说目前自动化测试很多公司主要用来“测旧”,也就是用来回归,一般新项目都是先手工测试的。

  比较起来可能是微软的测试是领先了一步,打破了常规的模式。我对这个概念是比较感兴趣的,在实际工作尝试把这个想法付诸于实践(不只我一个人在这样做),我实践的效果并不如人意。我们的测试方式是通过代码进行测试,可以自动化执行,一定程度上我解决了三个要素中的第二个,但是因为需求的不确定性,我们经常性的遇到需求变更,导致我们的工作重来,用例重新设计,代码重新编写,使工作量成倍的增加。总结起原因,一个在需求很不明确的情况下,就开始设计与编码,而设计的文档通常很简单与随意,通过文档你并不能了解内部的业务逻辑与设计思路,在实际编码的时候,一边写,一边改,只有全部代码写完了,才能知道整个系统是个什么样子。测试在依赖一个模糊而又飘渺基础上的东西,不仅过程中要进行很多的沟通,产出的结果也存在很多的风险。

  另外普遍存在一个情况是开发的技能水平要高于测试,测试对需求的了解要找到开发。还有测试技术的水平的提升,如何减少因需求变更带来的代码的重写的工作量,如何更快的完成测试的代码的编写,如何提升整个过程中的效率等等。

  说到这里我又想到测试驱动开发,这个被热炒的概念,我想这可能是测试与开发并行之后的事情了吧。(以上言论仅代表作者的个人观点,不代表51Testing观点)

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

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号