观后感之“无需求开发测试用例的问题讨论”

发表于:2008-9-12 15:16

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

 作者:bsbolg    来源:51Testing软件测试博客

分享:

  今天在论坛这么一个问题讨论:"没有需求文档的时候如何来设计测试用例?"

  很多测试达人发表了自己想法,并贡献出自己大量的经验,感触颇深啊。在我看来,没有需求文档就来设计测试用例,实则不得已而为之的做法,也是软件测试人员的一种无奈。

  作为测试人员都知道,测试的实际结果要与期望结果相一致。因此对期望结果的描述必须能准确的表达,这种表达要反映出产品是符合设计的。那么要如何得知产品是符合需要的呢,依靠,经验?感觉?或与一大堆人沟通后记录下来的文档?如果真是这样做的话,那么软件工程也就没什么用了。

  个人坚定的认为, 清晰的需求才是开发和测试的根本,需求文档作为需求的载体理所当然成为测试的最主要的依据。

  因为需求文档往往是多方沟通和评审后的共同想法的载体,即使需求文档可能还存在错误,但它已经是最接近于当前客户以及相关设计人员想法的文档说明,因此对于项目来说它就可以是产品的标准,它就可以是软件开发和测试的基本指导。而测试人员在做测试的时候也能有一个标准依据,知道什么是期望的结果,什么样的问题才是bug。

  看到有达人说,开发测试用例的时候,如无需求文档,可以凭经验,凭感觉,凭与开发人员交流后的得到的信息作为依据时,甚至认为这样才是真正的测试用例开发的方法。那么试问,经验,感觉以及看似可靠的信息是否真的是依据,这些信息是否通过相关人员评审过呢,你的经验,你的感觉是相关人员认同的吗,是否每次在与开发人员交流后需要他们签字来证明这是开发时的设计依据呢?的确需求文档不可能将所有的细节包含进去,但它包含了产品最核心的,最值得关注的地方,没有需求,你无法保证,依靠经验,感觉所开发的测试用例真正的覆盖到了所需要覆盖的地方,产品的质量无标准可以衡量和判定。

  盖房子要有设计草图,软件设计当然必须有需求文档,需求是软件设计和测试的根本,开发和测试过程都需要以需求文档作为指导。

  需求文档是沟通的桥梁,如果有它,测试人员就没必要花那么多的时间和精力去找开发部门,市场部门了解这个功能是否是需要的,这个模块输入的值是否应该如此,更没有必要去想方设法地去寻找可作为依据的依据了,因为得到最广泛认可的想法都写在了需求文档上了。

  其实没有需求的测试,说白了,就是项目前期,有些人该做的事情没有做,把需求像垃圾一样丢放在不同的地方,最后由测试人员充当清洁工,将垃圾回收整理起来。而测试人员还要想尽一切办法,总结出了很多经验来如何高效地收集它们。实际上测试人员做这样的事情已经本末倒置了。

  无奈的是,国内的环境就是如此,由于资金,时间等条件的制约,导致项目管理过程中的急功近利,人的惰性也被迫放大,大部分人都希望最后接手的人来收拾残局,该写需求的时候不写,想着没需求也可以开始工作,省了这一步,节约了时间,节约了资金,多省事啊。而开发的人员在没有需求的条件下想当然的开发出代码,开发完的代码自己都不想看第二遍,最后都推到了测试人员身上,怎么办,什么都没有,但工作又必须得做。幸好中国的测试达人们相应了毛主席的号召“自己动手,丰衣足食”,没有依据也要想方设法的找到依据。最后,很多大拿们通过多次的摸索总结出了大量经验,并拿出来与他人分享,真的很尊敬这样测试人员,不仅要出色的完成自己的工作,还要出色的完成别人的工作!却拿着与这份责任不符的薪水,真是太辛苦,太无奈了!

  如果开发企业在项目初期,耐心的把需求写完并评审通过,那么测试人员开发用例的时候也有了目的性,也就不会出现这些所谓的收集测试依据的高明方法,也不会有这样一个问题讨论了。

  真希望国内的开发企业能够重视需求的编写,因为写需求所节约的资源也许远远小于测试人员为了寻找需求说花费的资源,有了详细清晰的需求,测试人员可以更专注于测试本身,开发人员也能更专注于开发,这样所带来的好处和对产品质量的影响,这里就不用说了。

  有希望才能有前进的动力,相信中国的软件企业最终会走向正规,对测试的重视也会越来越高。那时测试人员就再也不用为这样的事情浪费时间和精力了。最后,希望所有正在承担这样痛苦的测试工作者们,你们要有足够的理由自信自己的能力,因为在困境中都能出色完成任务的人就是强者!


本文出自51Testing软件测试博客,转载请注明出处:

http://www.51testing.com/?79214/action_viewspace_itemid_92745.html

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

精彩评论

  • allenzgw
    2008-9-16 12:02:18

    需求文档,我觉得本身并非开发不想写详细,而且有很多原因导致他没办法写详细,第一,时间问题,第二,自己的经验,第三,本身客户也不是非常清晰,可能需要等上级批示,先让开发再说,第四,客户本身有很多变更。这些东西,比较难改变。
    但是,本身,需求文档,写好之后,需要评审,然后基线化,就是说,能固定下来的就尽量先定下来,然后,测试好写用例。这一点,没做好,才是关键。

  • 森林一木
    2008-9-15 15:23:01

    呵呵,俺也不同意,没有需求,还评审什么?需求是根本,需求都不正了,还有条条框框去约束他?没有需求最实在的就是靠测试人员、开发人员的沟通及自己的业务理解及判断力!

  • chech28
    2008-9-14 21:05:22

    不能统一楼上的说法,特别是在一个非常大,迭代周期特别长的项目的时候。
    确实开始阶段的文档是不周详的,这就是为什么需要peer review,manager review,QA review,然后汇总的意见修改文档,随着开发的每一个release之后,文档都应该再经过这样的历程。而相应的test case也是。如果一个文档很灵活很容易维护,但是关键地方不清晰,那要之何用?
    所以对于长期项目来说,追求清晰的文档也许会花费大量的时间和维护成本,但是不清晰的文档只能造成一个结果:失败。

  • Maine
    2008-9-12 16:18:26

    test case的生成确实需要参考需求文档和开发文档,而判断bug的标准也应以需求文档为标准。但是需求文档是不可能在产品开发周期的开始阶段就完全考虑周详,这并不一定节约成本所致,另一方面也为以后的开发和测试提供更灵活的依据。软件测试在产品中后期遇到的一大问题就是设计改变后需要更改大量test case,而如果需求文档过于细节化则可能需要很大成本来进行维护,如果没有及时维护就会造成文档和test case的不一致,这会迫使测试人员逐渐放弃对需求文档的参考。我认为需求文档是软件开发必备的,但是其灵活及易维护程度要比清晰详细程度更为关键。

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号