被“双规”的QA --- 测试计划实战

kokzhu

被“双规”的QA --- 测试计划实战    （原创）
    (kokzhu)

    我们都听说过“双规”这个具有中国特色的名词，这里借用一下，QA的测试也可以美名其曰“双规”---- 在规定的测试范围内按照规定的测试时间老老实实完成测试。当然，被双规的“同志”通常要完成若干的“书面材料”，QA也就必须要完成一堆的书面报告。
    测试计划就是这一堆书面报告中最关键的一个文件，下面就来简单列一下测试计划应该包含的主要内容，按“双规”来划分，测试计划涉及两部分：

一，测试范围相关
    测试硬件环境的界定：如果能了解用户的实际使用运行环境，那最好，计划中推荐的硬件环境和测试时使用的测试环境都可以尽量仿真，如果含糊不清，那就得尽量的从惯例，习知技术，从PM，从自己的经验去界定测试的硬件环境的状况。测试时候用双PIV跑得很爽，但用户那里还是486石器时代，那么你注定是要吐血而亡的。
    测试软件环境的界定：OS是WIndows一统天下，其他类型的软件在服务器客户端上的生存状态可就是千奇百怪，多如牛毛，其中不乏一些你的冤家对头。这个时候，用户通常站在你的对头一边，所以，惹不起，那就确认一下有没有什么特别的要求。你说我的系统和office在一起相谈甚欢哎，用户说我也有Office，怎么不行呢？其实呢，用户没有告诉你，他是支持国产软件，装的KingSoft的WPS Office而不是你默认的Microsoft Office。
    测试的一般范围的界定：测试的很重要的工作就是确认软件的功能是否全部都好了。“好了”有两层含义，第一所有功能都有了，都可以运作，没有错误；第二，所有功能都是用户规定要的，符合用户的要求。所以测试计划的很大一部分内容是在按照一定的逻辑顺序整理出来一份覆盖面所有功能的CheckList。前台的、后台的，服务器端、客户端，有UI、没UI的，看得见、看不见的，方方面面，边边角角都尽量考虑到，这里一些同志可能要开始叫了“写文件都写不完了，还测什么啊”。确实，智者千虑必有一失，100%的覆盖率是不大可能的，但这里并没有要求你一次“交待”完毕，测试计划理应在测试过程中进行持续的更新和补充。另外，测试计划是一份测试的总指导和纲领文件，如果不写出来，就没有可重复操作性，肯定会遗漏一些（当然，如果你是思维细密得滴水不漏的天才，那完全可以打腹稿就行）。

    特别范围界定：异常和猜测。很多功能按照正常的流程、操作是完美的，但一旦出现一些颠倒就开始漏洞百出，这个也是一种范围 --- 也称容错性或是健壮性。这一部分的计划往往显得比较零乱，缺乏系统性，但因为这里考虑的都是出其不意的“万一”情况，所以很多的BUG也常常出现在这部分计划的执行过程中。这里需要逆向思考，多考虑非常情况。通常如果RD的逻辑思考不够严密，这一阶段测试将爆出很多的问题。
    最后，需要说明的是，测试计划并不仅包括了上述的几个方面的范围，还可以增加或是细化，但总体有一个基本的认识，如果测试没有切合实际计划，那么从开始就注定了测试会漏洞百出；测试计划是一个测试过程的思考精华，在测试期间是动态的，并不是每个测试用例都要列举到文件里，但却要考虑到那个可能，并特别注明测试时使用“排列组合”还是什么其它方法来遍历所有的测试用例。

二，测试时间相关
    是计划就一定要和时间相关，标准的工程方法或CMM方式是对工作量进行估算，然后得出具体的估算值。但是这种方法过于复杂，这里不讨论。（下述方法是转载自一个叫 钟华 的牛人）
    一个可操作的简单方法是：根据测试执行上一阶段的活动时间进行换算，换算方法是与上一阶段活动时间1：1.1~1.5左右。举个例子，对测试经理来说，因为开发计划可能包含了单元测试和集成测试，系统测试的时间大概是编码阶段（包含单元测试和集成测试）1到1.5倍。这种方法的优点是简单，依赖于项目计划的日程安排，缺点是水分太多，难于量化。
    那么，可以采用的另一个简单方法是经验评估。评估方法如下：
        1． 计算需求文档的页数，得出系统测试用例的页数
                需求页数：系统测试用例页数 ≈ 1：1

        2． 由系统测试用例页数计算编写系统测试用例时间
                编写系统测试用例时间 ≈ 系统测试用例页数×1小时

        3． 计算执行系统测试用例时间
                编写系统用例用时：执行系统测试用时 ≈ 1：2

        4． 计算回归测试包含的时间
            系统测试用时：回归测试用时≈ 2：1
    注：以上比值是个人工程经验值，需要更正比值的测试经理可以在具体实践中收集数据。
    基于以上方法优点是需求为已知的，可以利用已知来推算未知，适用于需求是已知且相对稳定的情况下；缺点是处于研发状态的项目，需求不清晰的时候比较难计算。现套用一个例子加于说明：需求文档页数为500，系统测试用例页数推算为500，则编写系统测试用例时间为500小时，执行系统测试用例时间为1000小时，回归测试需要500小时，加起来总共为2000小时，按一天8小时计算，共计250个工作日/人；假如一个月为22个工作日，则共计约11人/月，即投入4个人需要3个月左右时间工作量完成。当然，这是系统测试需要的全部时间。根据测试阶段划分原则，设计用例时间可以和开发同步进行，只需在测试阶段中安排的时间为1500小时即4人2个月工作量。
    （测试经理在编写测试计划时候，测试进度中的计划开始/结束时间往往用如20050101-20051201的具体时间划分方式，这样引起的问题是当项目计划进行变更的时候，测试计划时间不得不随时调整，这种变更可能是频繁而琐碎的，可以替代的办法是取消这种方式，采用30工作日/2人或者2人月这种工作量记录方式，这样一来，只需在项目计划中跟踪阶段的具体开始时间即可，不必反复修改测试计划。）
    值得注意的是：国内大多数公司的测试时间都是不足的，不可能按照这样的理想比例进行运作，因为测试执行的时间实际上不可能占据整个项目周期的1/2，甚至要短于其中任何一个项目阶段时间。即使是微软的测试结束原则也并不是完成所有必需的测试，而是测试在按计划结束的那一天结束！
   
    上述N人所述的方式可能会有点理想化，但关于测试时间的部分确实是现实，在测试时间不足的情况下，首先是分清楚轻重缓急，重要的优先，按80/20原则分配测试时间，并且在适当的时机（讨论Release时间）说明将如何测试，测试需要多少时间，如果一些测试没有做，可能的风险是什么，是否有严重的后果？如果PM认可则按计划执行，如果不认可则应获取明确的反馈并进行改进，直到得到认可，必要时还需要PM签字画押，丑话说在前的方式虽然不那么的和谐，但却可以避免项目后期扯皮和互相指责推诿。
   
    回到起点，测试是在规定的测试范围内按照规定的测试时间老老实实完成测试，测试计划则是这个测试范围和测试时间的载体。毫无疑问，严密的计划有助于最终的成功，但计划的关键还是执行。在很多的情况下测试都是单人单项目，但或许还有其他的选择，比如多人测试一个项目，利用人的思维差异来扩大测试的覆盖面，这或许又可以另题讨论了 .(kokzhu)
（原创，如需引用，请注明作者！）

[ 本帖最后由 kokzhu 于 2006-1-18 16:06 编辑 ]

ilovejolly

-_-!!

archonwang

此文推荐一读，在推进测试行为标准化的进程中，双规既是对测试人员的要求，也是对推行测试合理性的思考。