编写背景：

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

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

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

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

　　我的回复：

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

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

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

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

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

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

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

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

　　我的观点如下：

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

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

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

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

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

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