编写背景：
       今天上我那块测试论坛的菜地看看去了，想把一些东西给规整规整，对其中的一个帖子发表了好长的感慨，大家有空可看看。^_^。

                                      开发阶段遇到需求变更，测试用例如何控制！！！

案例描述：
 开发阶段的测试用例如何设计

常遇到这类问题,开发阶段的策划案经常修改,程序也经常调整,而一份详细的测试用例要花费几倍的测试时间,好不容易完成了,只要策划案子一修改,以前做的就白费了,部门很多人也不赞成写测试用例,认为对于一个老测试员来说,这根本是不必要的,是只工作时间的浪费,而且以目前的工作量来说,根本没有时间写,对于不稳定的异变的程序来说,意义也不大,在这种环境中,如何推广测试用例呢?测试用例的存在有何意义?sdlkfj8

我的回复：
今天回头看了一下这个帖子，发现有这么几点问题：

1、首先帖子的标题是：开发阶段的测试用例如何设计

   没看帖子内容，一看这个题目就觉得很奇怪，测试用例的设计和开发阶段有什么关系。具体看了帖子内容后才明白，原来是，测试用例设计好后，在开发阶段时出现需求变更，导致测试用例要进行变化的现象。

   建议楼主把帖子标题改成：开发阶段遇到需求变更，测试用例如何控制。这样帖子标题和内容更一一对应上。

2、在帖子的内容中，描述了如下的几个观点和现象：

   1）开发阶段的策划案经常修改,程序也经常调整,而一份详细的测试用例要花费几倍的测试时间,好不容易完成了,只要策划案子一修改,以前做的就白费了。

   2）部门很多人也不赞成写测试用例,认为对于一个老测试员来说,这根本是不必要的,是只工作时间的浪费，而且以目前的工作量来说,根本没有时间写,对于不稳定的异变的程序来说,意义也不大

   3）在这种环境中,如何推广测试用例呢?测试用例的存在有何意义?

   我的观点如下：

   对于第1个，开发阶段需求会有变化；我在猜想，如果你的测试用例是关于黑盒/灰盒的测试用于系统测试阶段的话，在开发阶段需求发生变更，从结果上就可以知道，这个需求前期做的有问题，要么是用户不明白自己要做什么，不然就是需求人员没有搞懂用户到底要做什么；之所以让用例修改，祸根就是需求的变化不是人家开发惹得祸；要弄清楚病根到底在哪里，才好下药。应对办法，测试前期参与需求理解、从测试的角度去把需求中不明确的地方弄清楚；在写测试用例的时候、尽量简洁明了可以节省时间，这就是写作技巧的能力了。

   如果你的测试用例是关于白盒的测试用于单元测试阶段的话，这真的很惨，有一种花费了很高成本做好的东西拿出去卖，没人买，被耍的感觉。我没遇到这样的现象，目前不知道是怎么应对的。

   对于第2个，部门很多人不赞成写测试用例，原因是：浪费时间没有必要，其次是没有时间写，最后就成了意义不大。我在想，做测试的如果没有时间写测试用例、来一个产品就随便点点、想怎么用就怎么用，这叫测试吗？这不叫测试，这叫试用。我看不想写用例的根本原因一个是：懒，说白了就是对这个工作忽悠过就得了；在就是自己感觉对这个东西挺熟悉的，有经验，不写用例也可以点出问题来，这说明程序写的很烂、试用都能用出一堆问题。有责任心的人，当测试过的产品在用户那边出现一堆问题的时候，就会自我反省那个地方漏测了，没有写用例的人往往会漏的很多。把测试用例看的那么没有意义、那么不重要，我在想你们部门应该是个产品试用部门吧，还算不上真正的测试。

   对于第3个，我觉的很好玩也很奇怪，基于上面的1和2点，把测试用例看得那么不重要、那么没有意义，为什么还要推广呢，你自己都不认为很重要的东西想让旁边的人认为重要，很难、非常的困难。想要把一个好的东西介绍给人使用，首先自己要觉得它很有价值，然后要让大家看到实实在在的价值和帮助、还有好处，这样才会得到认同。不过我觉得你那的环境比较困难，从你上面的描述得出，非常的困难、不是一般的困难、是相当的困难。

   嘿嘿，写了那么多，不知道能否对你有启发，祝你好运了。^_^。

  最后回到正题，开发阶段遇到需求变更，测试用例如何控制? 问题已经出现了，需求已经变了，该怎么办？那只能修改测试用例咯，然后告诉具体负责人，需求变更已经影响到了测试的进度和工作，做好这方面的时间工期应对风险。

帖子地址：

http://bbs.testage.net/viewthread.php?tid=37275&pid=172303&page=1&extra=page%3D1