本周51testing每周一问的这个问题很精彩，于是我做了如下回答。

问题如下：

测试的流程中，测试计划是对整个测试活动的安排，而测试用例则是测试执行的指导，但是，现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性，在项目时间比较紧张的情况下，计划和用例往往成了形式上的东西，甚至有些测试人员脱离用例，完全凭借自己的经验在执行测试活动，对此，你有什么样的看法？

   这个问题问的非常好，也确实是很多人有过切肤之痛的问题，对我来说，我也一直在苦苦追寻这个问题的答案，现在我不能说完全找到了，只能说把自己的心得分享一下，希望大家的测试计划和测试用例不再是一个摆设。

（一） 先说测试计划吧

诚如magic_zhu所言，现在很多测试人员没意识到测试计划的重要性，很多时候测试计划成为一纸空文，其根本原因在于测试计划缺乏可执行性，也正是因为测试计划缺乏可执行性，导致下一次写计划的时候非常草率，甚至不写，就算写了也是一个花架子应付领导，这样形成了一个恶性循环，久而久之，测试计划纯属一个摆设，我们很多从业者不写测试计划，其理由是反正写了也不能按照计划执行，这种理由真的很荒唐可笑，这是典型的因噎废食，因为你的计划执行性差就不写？这样只能使测试更加失去控制，使你的测试过程彻底无计划，无目标，变成一个放任主流的状态，完全没有受控性。这样的产品质量保证显然是空谈。

我觉得这个问题的解决方案不是不写，而是想办法写得更好，更有实效性，执行性。这个是问题的关键。

一个好的测试计划是用来计划测试的，指导整个测试过程。所以一个好的测试计划一定是可以指导测试的，就是对整个测试过程中的人力，时间，资源，策略，范围的一个说明。

作为一个测试计划来讲，核心的三个要素是时间，资源，范围。（这句话摘自微软的软件测试培训材料），时间就是什么时候做以及要花多久做，资源就是你要调用的人力、机器等资源，范围是你要测试的东西以及测试重点。除以上提到的3项之外，还有比较重要的项目有策略（具体就是怎么测）、风险控制（一旦有问题采取什么应急措施）等项目。

要把一个计划做得很有实用性，按照笔者的经验，要注意以下几个方面：

a.   上面提到的三要素不能少

b.   测试策略一定要交待清楚，就是大概怎么测试

c.   需要其他人员（部门）协调的，要交待清楚

d.   在估计测试所需的时间、人力及其它资源时，尽量做到客观、准确、留有余地，特别是估计开发时间和debug时间，以及要对自己的执行用例速度，回归速度心里有数

e.   测试计划中每个阶段要明确表明，并且测试阶段的输入、输出文档要清楚

f.   测试计划中的时间段不宜太长（最好以day为单位），太长就比较模糊，不好度量，不好check

g.   一定要有风险控制，要不然计划缺乏可执行性

h.   计划写完之后不是装在兜里，要组织PM和Dev进行评审

i.   要不断更新计划，记住：每个计划都是动态的，不是一成不变的

（二） 再说测试用例

和测试计划一样，测试用例很多时候也沦为形式，这是软件测试的可悲之处，软件测试的依据就是测试用例，如果用例弃之不用，你凭什么做好测试？这个很可笑。但是实际测试过程中很多时候测试用例并没用到实处，笔者认为还是用例实用性问题，有的时候用例洋洋洒洒数万字，到回归测试的时候根本用不上，至于如何选择回归测试用例，我曾经写过另一篇文章，欢迎查阅。

下面我就个人体会谈谈做好测试用例的关键。

首先，在做用例之前，要做两件事情。

第一，透彻了解程序（需求和架构）。

第二，做一个正式的测试设计（最好文档化）。然后再开始写用例。一般写用例的步骤和建房子一样，先搭框架，然后填材料，填材料的时候，主要根据需求做相关的设计，具体的设计方法就是那几种（郑老的书上写的很清楚）

一般来说，设计一个比较实用的测试用例，注意如下几个方面：

a.   选用好的用例管理工具（这个很重要，千万不要用word，excel）

b.   用例一定要及时更新（补充新的想法，删除过时的需求）

c.   做好用例分级

d.   做好用例评审，写用例之前可以征询相关人员的意见

e.   可以考虑结对编写，这个是不错的主意

f.   要全面，包括功能、性能、兼容性、安全性、易用性、容错性等等

g.   注意把握适当的颗粒度

    OK，以上是我个人总结的一些心得，希望对您有些帮助，谢谢magic_zhu提这个问题，如果对读者您有些帮助，也不浪费我写到凌晨0点的心血，呵呵~~~~~~~~关于这两个话题太大了，欢迎大家展开讨论！！

前几天都在忙着上驾校，测试时代论坛升级好几天都没法进去看资料，今天运气不错，论坛可以进去了，可以翻翻老贴，把一些自己认为比较有价值的整理整理然后收藏；看完测试时代的接着就要翻一翻51testing的了。

今天收录的关于历史数据迁移的测试，通常很少碰到；在我过去工作的5年多里，运气还不错，做过一次这方面的测试任务，在此记录记录。

历史数据迁移的测试

历史数据迁移，说白了就是数据库数据迁移，比如：把一个ACCESS数据迁移到ORACLE数据库，或者是其它数据库之间的数据迁移。

有的人可能会想，既然是数据库数据迁移，不需要做测试需求的确认了，检查一下数据就可以了；有的人由于没有做过这类测试、第一次碰到，傻眼了这可怎么测试啊，书籍上说的黑盒测试技巧里并没有历史数据迁移的测试方法，该怎么办。

我第一次接到这个测试任务时，感觉很特殊，因为实在少见，怎么做呢？

首先，在做历史数据迁移测试之前，也需要做测试需求的确认，主要是弄清楚用户为什么要做这个历史数据的迁移。

我记得，当时这个案例的用户是因为它的一个系统，之前的老系统是在ACCESS数据库中存储的，后来有了新系统、新系统的数据是在ORACLE里，为了把数据统一，就需要把老数据导入到新系统的数据库ORACLE里，便于新系统能查看到即可。

从这个需求，得出如下测试需求点：

1、 ACCESS数据库里有很多张表，要和用户确认要迁移的是那几张表？弄清楚老库中的老表对应要迁移到新库中的那几张新表？

2、 迁移的表中，那些数据字段需要迁移，那些数据字段不需要迁移？

3、 老表迁移到新表中，新表中有些必填字段在老表中没有的，用什么数据填写？

4、 老表迁移到新表中，老表数据在新表中没有对应字段存储，怎么处理？

5、 老库老表数据与新库新表重复，数据怎么处理？

6、 老表要迁移的数据记录条数是多少？

和用户弄清楚这些疑问点后，还需要和开发确认疑问点：

1、 老库中老表的表关系迁移到新系统新表中的表关系是怎样的？

2、 确认用开发编写的数据迁移程序迁移完后的数据检查方法？

确认上面的疑问点后就开始做工期时间计划安排、编写测试计划和测试用例。

    其次，要注意数据迁移后，新系统对老数据功能的使用。

记得当时在确定了测试需求点后，在编写测试用例时，我重点使用了一下新系统、确认新系统会用到老表数据的业务都有哪些？把这部分业务也作为测试用例点进行测试。也许有的人会想，只要后台把数据库表正确迁移完毕，前台应用程序应该是没有问题的，不需要检查的。这是一种偷懒怀着侥幸心理的想法。回到之前的用户需求，用户为什么要数据迁移，目的就是为了能在新系统使用这些数据，因此在数据迁移完毕后，还要重点的检查老数据在新系统中的使用。

就在这个数据迁移测试的过程中，我跟我们的部门经理说，用户肯定会有其它的需求、迁移这些数据肯定要做一些业务处理、新系统程序可能会有改动。结果在迁移数据做完后，用户真的提出了新的需求，被我说中了。^_^。为了让这些老数据在新系统能很好的完成新业务处理，要对老数据进行特殊标识后才进入新系统、同时新系统针对这部分数据相应要增加功能。这就是用户需求没有摸透、没有看清楚需求背后的真正需求，导致迁移程序需要再次进行修改。

有些人，在测试数据库迁移时，一开始想到的理论知识就是：测试数据的完整性、可靠性、有效性；有的人就会问，数据的完整性、可靠性、有效性的测试用例怎么写啊？说实话，我也没有写过数据的完整性、可靠性、有效性的测试用例，我只会根据用户给的需求、整理并发掘测试需求，根据需求形成测试用例。也许数据的完整迁移测试点就属于数据完整性测试用例吧；数据迁移完后新系统对迁移数据可正常使用并处理业务，就属于数据的可靠性、有效性测试用例吧。

不管怎样，在测试的过程中，一定要弄明白用户的真正需求，才不会走弯路，虽然只是个数据迁移，但不只是简单的数据迁移，背后有着很多不为人知的故事！！！！！^_^

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

      这一周都在忙着面试，总算告一段落；今天回了我在测试时代的那块菜地看了看帖子，突然心血来潮，给如何做项目的测试经理这个问题简单的回复，希望能对大家有所帮助，有更多的点子，想看看我都回了啥，大家要耐心看咯。^_^。

                                [讨论]测试过程管理案例6---如何做项目的测试经理？

帖子地址：

http://bbs.testage.net/viewthread.php?tid=4588&pid=184557&page=1&extra=page%3D1#pid184557

案例描述：

简单叙述一下我遇到的问题吧：

公司其它部门有个项目，需要做很严格的测试，请求我们部门支持，部门就指派我负责。因为项目刚开始不久，项目经理说测试的人员目前还未定，暂时只有我一个人，所以我过来了之后就一直在埋头编写测试计划和测试用例，就像以前做过的那样。但今天早上我的主管把我叫去了，跟我说了一番话，对我触动很大。他说其它部门请我们去支持测试，是希望我们给他们带去一些更专业的测试思想和方法，而不仅仅是叫我们去给程序找BUG。我应该更多的考虑如何去做好测试，把整个过程想清楚，需要什么资源，如何安排，要大胆地向项目经理提出，而不是跟着项目的进度走，那样就根本体现不出我们部门的价值。我觉得他说得很有道理，但是说实话，我对一个项目的测试经理究竟需要考虑些什么，注意些什么，该做些什么，并不是十分清楚。所以在此提出来讨论，希望大家给我些建议，谢谢！

我的回复：

这是3年前的帖子了，今天回来在看这个帖子，这么久都没有人给个好的思路讲一讲这个关于如何做项目的测试经理，也许这个问题问的太大了吧，今天有感而发，说说我的观点吧。

对于项目的测试经理，每个公司组织结构、项目管理模式不一样，想做好项目的测试经理，首先是要和开发负责人、项目负责人达成共识，是对于项目的软件质量理解的共识，对于速度、成本、质量这三个方面，更偏向于那一面、还是都持平。

当然，站在测试的角度，希望软件质量是很高的，那么站在项目的测试，做为测试，要明白能做什么？起到的作用是什么？

程序一旦提交到测试，进度完全是可以在测试这一方来主控了。

本帖的案例，我看了一下描述，目前苦恼的问题是：

1、领导说其它部门请我们去支持测试，是希望我们给他们带去一些更专业的测试思想和方法，而不仅仅是叫我们去给程序找BUG。

2、我应该更多的考虑如何去做好测试，把整个过程想清楚，需要什么资源，如何安排，要大胆地向项目经理提出，而不是跟着项目的进度走，那样就根本体现不出我们部门的价值。

从上面的描述可以了解到，部门领导会这么说可能是因为：

1、在项目测试的过程中进度没有过程控制点，具体一点就是没有具体的工作计划（什么时间，用多少人力做什么样的测试？）

2、程序提交测试后，什么时候能发布、可不可以发布没有个确定点；测试没有自己的主见，项目经理说测试进度怎么做就怎么走

要想做好项目的测试，我想需要具备下面的一些素质吧，仅供参考：

1、深刻了解测试的整个工作流程、也就是在项目的测试工作中需要做的测试需求、测试计划、测试用例、测试报告、bug分析

2、及时的收集测试过程中的问题、了解测试进度，把问题和进度反馈给项目的各方负责人

3、很好的沟通、协调能力，应变测试过程中发生的需求变更、bug修改进度缓慢、开发延期提交等等一系列问题

4、很好的承受工作压力和适应能力，做为一个测试负责人，如果不能抗得住、下面的测试执行者就会慌乱

5、具有发现问题寻求好的解决问题的途径

6、关心组员的工作表现、会换位思考等等

暂时想到这些，希望会对楼上的楼主有帮助！！！祝好运！

         测试计划的制定，要考虑的因素确实很多，但要抓住最主要的就可以避免大的测试执行风险。
         为了有效的制定测试计划，首先要清楚，制定这个测试计划的目的是什么，作用是什么。

         我认为测试计划的主要作用是：明确工作内容、工作完成时间、工作资源、工作风险等、最终目的是提高测试的工作效率，作为保障测试工作顺利、保质保量完成。

          那么，如何有效制定测试计划？
第一：根据自身实际情况的项目、团队管理情况，要有个合适的测试计划文档模块用于编写测试工作的测试计划、便于向项目中的其它成员告知测试工作是如何安排和进行的。

         测试计划文档现在在网上有一堆，看了好几个，自己综合后整理了一个，最终认为测试计划文档大纲要包含如下内容：
------目录
------1. 简介
----------1.1 编写目的
----------1.2 编写背景
----------1.3 使用范围
----------1.4 参考资料
------2. 测试说明
----------2.1 测试项说明
--------------2.1.1 系统名称
--------------2.1.2 应测试项
--------------2.1.3 非测试项
----------2.2 测试资源
--------------2.2.1 硬件设备
--------------2.2.2 软件设备
--------------2.2.3 人员安排
--------------2.2.4 测试工具
----------2.3 测试安排
--------------2.3.1 测试培训
--------------2.3.2 测试进度
----------2.4 测试文档
------3. 系统风险
------4. 测试优先级
------5. 测试策略
----------5.1 接口测试
----------5.2 集成测试
----------5.3 数据和数据库完整性测试
----------5.4 功能测试
----------5.5 用户界面测试
----------5.6 性能测试
----------5.7 负载测试
----------5.8 强度测试
----------5.9 容量测试
----------5.10 安全性和访问控制测试
----------5.11 故障转移和恢复测试
----------5.12 配置测试
----------5.13 安装和反安装测试
------6. 评价准则
----------6.1 范围
----------6.2 尺度
--------------6.2.1 测试覆盖率
--------------6.2.2 质量评测
--------------6.2.3 缺陷报告
--------------6.2.4 性能评测

     上面这些内容大家看起来会觉的很多很全，这个模板适合大的测试项目，个人用着感觉不错；可能，有的人会问，我可能只是做功能的测试，我只是做一个数据迁移的测试，可能涉及的测试项根本没有那么多，那么我该怎么写我的测试计划呢？

第二：根据具体测试工作任务情况编写测试计划，剪裁适合自己的测试计划模板

    上面给的都是在写测试计划中要考虑的点，就像在执行测试时都要执行的测试用例点有哪些。具体在写测试计划中，那些信息是需要考虑的，那些东西是不需要考虑的，可以根据自己项目的具体情况进行裁剪和设计即可。

    模板只是起到提醒作用，提醒在测试前需要注意考虑的信息都有哪些？在具体编写中，如果没有经验，要适当请教公司内部有经验人士给予评价和指导，便于制定出来的计划是可行的并没有遗漏重要点。

    下面是通常非常小的测试任务中，我用过的感觉非常好的测试计划模板表格，供大家参考：

第三：测试计划不是一层不变的，随着项目的进行，会由于各方面的因素（如：提交测试的程序版本质量低、bug量大修改慢、需求变更等等）导致测试计划无法按原计划执行，这时要适当的调整测试计划。

    关于如何有效制定测试计划，我只是范范的写这么几点，不知道是否会给大家一些启发；最后还想补充点：在制定测试计划时，关于人员分工这部分，要根据每个人对系统的熟悉程度以及能力情况进行分配，让大家的能量都能得到最大化的发挥。

    最后祝大家好运，希望能有所收获。^_^。

最近在测试时代翻看一些老帖子，发现一些很有意思的东西，收集整理后，把它放到了这里，那天回头看会有另一翻感受。^_^

Ayi 问： 请问怎么写 bug 才能不被开发人员讨厌？

davy_chen 答：

1、   描述精确，完整；

2、   简洁，无歧义；

3、   可稳定复现；

4、   利用截图，调试信息等辅助说明；

5、   反馈验证结果及时，变化内容描述详尽。不被开发人员讨厌最主要的是建立威信，也就是你说出的都是真实的，你说有 bug 就确实存在。

6、   若对于很难重现的 Bug 还需要注明该 Bug 在测试过程中出现的几率。

sww1980 答：

1 、不被讨厌不一定用写 bug 的方式，跟开发人员搞好关系也很重要。
2 、只要有 bug, 开发人员肯定会烦，这时候你的亲和力就尤为重要，让开发人员觉得你不是在挑他的毛病，  

而是想一起开心的把软件做好。

小颖 答：

1、   如果能够指出 bug 的原因或出处一方面可以让开发人员感觉你的水平比较高，另一方面减少了开发人员找错的时间，他会心服口服。

2、   在有不要抓住一些规范性的错误不放，应该发现一些有深度的错误，功能实现是重要的

celine 答：

我觉得沟通很重要，尝试站在开发人员的角度上描述问题，而且要对事不对人。

gigobin 答：

1、   开发人员喜欢的 bug ，是能够一幕了然知道出现了什么样的问题，然后是一个简洁的复显问题的步骤。 一般我都习惯于先写一个简单的问题的 brief ，一句话，比如：在 xxx 输入某字符后，点击 save 报 500 错误。 然后下面是你的测试端的配置。然后是你的测试平台的情况。这些都是参考。 然后就是第一步怎么做，第二步怎么做，。。。，然后出现了什么错误。 最好是一个 bug 里面只有一个问题。这样便于大家跟踪状态。

2、   对于交流问题，我觉得如果有一个好的 bug 平台，在一个清楚的 bug 时，很少需要开发人员和测试人员交流。尤其是什么是不是一个问题时，如果开发人员认定不是，不需要太多的纠缠。除非你认为这个将非常有损客户的利益。而且这个时候应该报知测试 leader 去和开发 leader 进行协调。 而且尽量不要去写我认为这个问题是什么引起的，应该怎么改。你只需要保证开发人员能够复显就可以了。过多的涉及这个问题，会牵扯双方的精力。你的任务是发现问题，报告问题，追踪问题而不是解决问题。

3、   测试人员不是在找开发人员的错，也不是开发人员的矛盾体。测试人员是帮助开发人员节省精力去找出错误，修改错误的。一个好的开发人员是不会因为测试人员找出他很多错误而烦恼的，因为不断改进错误的同时，是对他的一个提高。 一个好的产品团队是协作良好的开发团队，测试团队以及管理组和设计核心组组成的。