是不是有些软件测试就没有办法写出测试计划。。

fly-bird

做测试一年了，却停留在简单的功能测试层面上，对测试的理论了解不少，但是我们自己测试时却没有什么流程之类的，简单到程序员提交模块就进行测试，发送bug报告修改，继续测试，我现在想，到底是我们的测试不规范呢还是我们软件的测试就根本无法进行测试计划、测试用例等的编写呢，因为程序员提交都是按模块提交的，顶多的时候是由模块组成的一个小的子系统流程，而如果单个模块则一天或两天就可以测试通过了，这样怎么写什么测试计划什么的？越来越糊涂了。。。

skinapi

1、不要把测试计划、测试用例和测试计划文档、测试用例文档混在一起，你有可能没有用文字写任何测试计划和测试用例，但只要你在做测试就不可避免的会存在测试计划和测试用例，只不过这两者只是存在你的大脑里，而且可能不系统、不完整，但肯定是存在的。将计划和用例通过文档的形式表达出来一方面是帮助测试人员思考的更系统、完整，另一方面是方便进行测试管理。
2、再小的模块、再少的代码也需要有测试计划和测试用例，不管是在大脑里还是以文档形式出现。

fly-bird

那这么说来，是我的计划和用例在脑中形成了嘛？
我确实也有自己的一个常见的bug清单，计划就没有了，只是按照任务测试完就交差了，顶多是经理说比较紧张就测的快点，说不紧张的时候可能就测的慢点
没有文档的形式。。。

skinapi

计划肯定也是有的，最简单你测试时肯定是先选择某一个用例进行测试然后再选择另一个，这就是计划的内容，只不过你没有意识到这是在计划罢了。^_^

fly-bird

可是我还是想能让测试标准化，曾经我也问过站长该如何让一个不标准得测试过程标准化，站长的回答是只是从测试开始走这些流程是没有用的，要从整个软件开发过程进行改进，无奈我觉得如果这样的话似乎单凭我一个人的力量就无法实现了，不过最近公司在上CMMI，我希望通过这个CMMI的实施能让我们一切都量化起来，测试也标准起来。。。

rien2128

同感，同感。

sho166

我也有个问题：决定了测试阶段的时间段(比如2005-8-20-2005-10-20)后，怎样准确的计划系统的回归测试批次呢？当系统在维护期，用户又提出了一个比较大的需求变更，怎么维护该系统测试计划“文档”及测试报告“文档”？

billrub

依据项目单元开发里程得知阿尔法版本的Release时间，再从本阶段测试用例出发，预估工作量（人*小时），计划回归周期和批次；过程中有3个资源可调节：人、时间、测试需求；呵呵，如果时间不可调则只有调人和需求，总之至少要有一项资源可调；

糊里糊涂

针对于搂主的情况，在制定软件计划时间时不应过于详细，对于一个项目可以整体大概的计划时间段，然后在每周末去确定下一周的测试计划。
对于测试用例的编写可以不用非常详细，只需将你平常测试时的测试思想写出来就可以了

sunkitty

谢谢分享

xiongxing

好像只感觉到需要写这些东西，而不知道具体该怎么去写．

wudamyw

书面的计划存在，并且能最大程度的执行是需要有一定的规范流程基础上的。 如果流程一团糟，那即使能写出计划也是空谈，计划是为了更好的工作，如果总是根据工作改计划，那就。。。。。还是现规范流程吧。