如何做好测试计划

slm601

一直觉得测试计划好像没什么用，每次都是拿到一个测试任务都是写写测试用例，然后直接执行测试。前段时间，项目组要求让谢测试计划了，看了很多资料，也不知道怎么去做好测试计划。关于测试计划的制定，我目前有以下问题：
（1）首先是测试的范围和内容：是包含从项目立项到软件release之间所有要测的东西吗？我觉得一般软件需求规范就可以很清楚的描述这一方面，那测试计划里又该做些什么呢？
（2）其次是测试的目的：我觉得所有的测试，好像测试目的都是一样的，都是为了找出隐藏在软件中的bug，保证软件的质量。如果这样写在测试计划里，就感觉完全像是一个模板了，而且每次的测试计划都可以套用？？？？
（3）关于测试的开始与结束时间： 这个是指软件最初立项的时间到软件release的时间吗？感觉这段时间也太长了吧！我觉得每个模块的测试时间计划好像更有意义吧？但这个时间好像变动又很大，不知道怎么写。
（4）关于测试环境：这个应该在软件需求规范里有指定的，是不是把里面相应的部分挪到这里就好了。
（5）关于测试方法：是不是把设计测试用例的方法列出来就可以了？如果是这样的话，每次测试好像方法也都是一样的了。
另外测试计划还要写些什么啊？在后期执行中是不是都需要按计划进行啊？
真诚的希望有经验的前辈给予指导！谢谢！

heavy200t

我说说自己的理解吧，大家交流：

>>（1）首先是测试的范围和内容：是包含从项目立项到软件release之间所有要测的东西吗？我觉得一般软件需求规范就可以很清楚的描述这一方面，那测试计划里又该做些什么呢？
测试的范围和内容不是指要测试哪些功能。
测试范围包括进行哪些测试？功能测试、性能测试......这个确定了要做哪些事？
是否要测试用户体验，业务逻辑......这些除了确定要做哪些测试，也确定了哪些Bug应该提，哪些不必提。

>>（2）其次是测试的目的：我觉得所有的测试，好像测试目的都是一样的，都是为了找出隐藏在软件中的bug，保证软件的质量。如果这样写在测试计划里，就感觉完全像是一个模板了，而且每次的测试计划都可以套用？？？？
测试目的可以是进行多少轮测试，测试密度达到多少，缺陷密度达到多少.......

>>（4）关于测试环境：这个应该在软件需求规范里有指定的，是不是把里面相应的部分挪到这里就好了。
照实写，进行测试用的配置是什么就写什么。

slm601

回复 2# heavy200t


   （1） 那测试范围那一块，需不需要指明对哪些功能做功能测试，哪些做性能测试？
“用户体验”“业务逻辑” 这个好像也是属于功能测试中的一部分吧？
“哪些bug应该提，哪些不该不必提” 这个好像也可以根据软件需求规范确定吧！只要不满足需求规范的都可以认为是bug
（2）缺陷密度  是指出整个测试过程的缺陷密度呢  还是单个测试任务的？
还有我上面提到的测试方法的问题，期待新的见解？

PrefTest

计划赶不上变化，但是没有一场仗是在毫无计划的情况下打赢的

http://blog.csdn.net/testing_is_ ... /09/24/1798733.aspx

heavy200t

回复 3# slm601


>>    “用户体验”“业务逻辑” 这个好像也是属于功能测试中的一部分吧？
是的。范围定义就是要确定哪些要做，哪些不要做。说白了，其实是要确定哪些不要做。
比如说在有些阶段的测试，你可以不用关注用户体验。这一点就可以在测试范围中说明，让项目的关系人知道。业务逻辑也是一样的.有的时候，我们只要测试系统算法是否和设计一致。至于在业务层面，库存加减、税率计算，这些算法到底合不合理。这不是测试范围内的，也可以在范围定义内排除。

>>“哪些bug应该提，哪些不该不必提” 这个好像也可以根据软件需求规范确定吧！只要不满足需求规范的都可以认为是bug
没错。那么我要问一下，字体大小不一，界面不美观，算不算Bug，要不要提？
在有些阶段，不是迫切要关心的。那么那时候提太多这类的Bug显然没有意义。
如果没有明确说明这一点，有时候就会在提还是不提上出现争论或是困惑。

>>（2）缺陷密度  是指出整个测试过程的缺陷密度呢  还是单个测试任务的？
这个有多个标准，看实际情况。有按功能点来算的，defects/features。 也有按照千行代码数来算的，defects/KLOC。


当然上面的这些都是建议，可以写可以不写。计划这类的文档还是要根据实际情况灵活处理的。
计划这类文档，其实也是中沟通的方式。写什么，怎么写，就看你要跟人说什么，怎么说了。
我的意见就是，某些形式固然必不可少。就看怎么来理解这些形式化的东西，将其落到实处了。

关于测试方法，你得告诉人家，你怎么进行测试的。拿功能测试来说，流程是怎么样的。测试用例如何写的，如何管理的？缺陷是如何管理的。设计用例的思路是什么，分析业务流程，边界值、等价类......
每个项目可能有其特点，重点可以突出这些不同之处。

还是要看沟通对象是谁。如果对方（比如客户或领导）对测试不了解。你可以介绍一些测试的理论和方法，体现专业性。如果对方很熟悉这块，那么可以针对性地写一些这个项目测试方法上的特点。

msnshow

测试的目标比目的更适用一点

slm601

回复 5# heavy200t


  谢谢，说的很详细！
但是如果按照你这样说的，从测试流程方面来讲，测试方案就已经包含在测试计划中了，对不？如果按照你这样说，测试流程应该是怎样的呢？谢谢。

heavy200t

回复 7# slm601

>>从测试流程方面来讲，测试方案就已经包含在测试计划中了，对不？
不太明白这句话的意思。
在我理解：
测试计划是测试全过程各个阶段的任务以及时间进度安排，包括风险控制。更偏重于项目管理。
测试方案描述需要测试的特性、测试的方法、测试环境的规划.....，更偏重于实施。
可以说测试方案比测试计划更具体些，也可以说两者就是一回事儿，都是Plan嘛。

>>如果按照你这样说，测试流程应该是怎样的呢？
还是按我的理解说：
测试流程有很多了
从大的来说 分析->计划->设计->实施->分析->总结->报告。这就是一个流程。
当然，测试人员发现Bug以后如何填写，指派给谁，然后再由谁处理.....这是比较细节的流程。

楠族开心果

自己安排自己测试，没写过测试计划……哈哈
不过网上找了下，你可以看下这个文档http://www.cnblogs.com/mikeyond/archive/2008/09/10/1288041.html

愚人

拜读了……

slm601

回复 9# 楠族开心果


    唉！我也是自己安排自己测试来着。不过发现我给自己安排的也挺乱。

楠族开心果

回复 11# slm601


    我也是自己安排自己，所以我基本不安排~~~

slm601

回复 12# 楠族开心果


    哈哈。。。 就是因为我测试的很乱  所有想好好安排来着

楠族开心果

回复 13# slm601


    嗯，我也是，是该好好计划下了~话说我也带了3个学生了~哎~~。
一起加油

slm601

回复 8# heavy200t


    谢谢，-+根据你现在的说法，我的理解是：
测试计划一般是对现有测试资源的配置，不用很详细，只简单交代下（困惑的地方是：但这样好像又太简单了，写详细一点呢又成测试方案了）；
测试方案呢就是如何利用现有的资源进行实施。
我这样说，对不？