是先写测试用例，还是先测试？
我目前所在的公司，若有新的需求，等程序员把东西做出来了以后，我们就开始测，只能根据需求文档进行测试，等测完了后，才开始写测试用例。我们也想先写测试用例，后开始测，但程序员东西没做出来，没看见东西，也不知从何写。不知大家的工作流程是怎么样，如何做到先写测试用例，后测试的。 不是有需求文档吗？有了需求文档还写不出测试用例？ 对亚！测试用例就是要根据需求文档来写啊，而不是说编码人员作出什么样的东西，你们呢就写什么样的用例，按需求来的！ 我们所谓的需求文档，是用户提出来的功能要求，上面只写明他们需要实现什么功能，如此而已，没有其它的东西了 有了需要实现的功能，就会有如何实现的具体业务规则和要求，根据这些内容就可以完成一部分测试用例设计工作了。
如果需求文档不明确，就去问问开发人员或者需求人员，把这些最基本的细节明确一下。
如果开发人员或者需求人员不愿意讨论，你就只能自己想办法了。 按照你的实际情况，你可以先根据用户提出来的功能要求写出一部分用例，然后等到编码人员具体实施完以后再完成另一部份的测试用例！
服了。。。。。
用例驱动呀按eatmouse说的办
同意eatmouse说的“按照你的实际情况，你可以先根据用户提出来的功能要求写出一部分用例，然后等到编码人员具体实施完以后再完成另一部份的测试用例！” 。就这么干！ 同意eatmouse的说法
通常来讲,拿到需求文档的时间要比得到开发人员代码的时间要早很多,这时候我们就可以根据需求文档上客户所列出的功能来编写测试用例.一个好的测试用例不仅能正确的测出某个功能点是否能正常的工作,还能测出此功能点所引发出来的其他功能点是否能正常的工作.举个updata的例子来说,我们要测的是updata是否能正常的更新软件,这时除了看软件是否正确更新,还要看更新后的软件是否能正常的运行,是否与以前的版本相兼容,新加的功能点是否可用,是否正确……这样的话就可以写很多的用例，相对的覆盖面积也会比较的广了。
当然，仅仅这些还是不够的。当编程人员写好代码后，很可能客户会加进新的要求和新的功能点，这时仅凭需求文档的用例已不能满足要求了。所以你要重新设计新的用例来满足软件的要求。
总之，我觉得写用例不仅仅是对需求文档的一种覆盖，更多的是从某一功能点出发，来尽量的覆盖所有有关的功能。个人认为，只有这样的case才是真正的好case.
你们都没遇到这种情况吗，我们公司是只做一个产品，不断增加产品的功能，当用户在使用的过程经常提出新需求，且都要求在两三天之内完成的，需求一到公司就转到研发部门，而我们也只有等研发开发完后，才知道有这个需求，而且只给我们半天或几个小时之内就得测试完，发布面对都是这样的需求测试，此时我该如何做测试用例。
[ Last edited by huishelml on 2005-5-20 at 08:41 ] 那可否和相关人员沟通一下，让需求到达开发部门的同时也可以转给测试人员 这种问题都问的出来？呵呵……
页:
[1]
