编写规范的技计划书

1、a 1 刖旨本文档主要描写对该计划的前期阐述，说明其重要性与操作过程的前期计划。 着重点描述未来本公司软件测试规范操作手册的深度与可操作性等问题。2为什么要编写此规范手册首先从公司的现状來看，我们公司是刚刚起步的新软件开发公司，口前的开发 主项目xxxxx管系统己经接近尾声。虽然属于延迟完成项目，但是却给我们 带来很多可以总结的经验和教训。比如开发流程，开发文档的编写。并在此方面做了很多积极的探索。2.1分析我们公司目前软件项目在开发管理过程中 的现状：存在问题-、日前的xxx管系统项日仍然过分分依赖少数个人的作用,没有建立起协 同作战的氛围，没有科学的软件开发管理流程；技术上只垂视系统和数据

2、库.开发工具的选 择，而忽视开发规范化过程，需求变更频繁，导致即使使川同类规程，也l+lt-nj操作性差而搁 浅。存在问题二、开发管理没有适吋跟进。我们是一家新的软件公司，领导和项目负责人对具 体的开发过程理解有限。对每一个开发过程中需要把握的结果尺度不够。片血的讲究时间效 应。导致项ri开发没竹必要的前期可以参考的完成标准就肓ri对项ri进行赶进度。虽然人多 按吋完成任务，但不久乂发现问题出现。比如：报警系统，前期客八就明确提出要求有这个 功能，我们没冇对该功能进行必要的分析和设计，只是在项n代码开发进行到最厉阶段，才 想起來后补加该功能。补加的报警功能没有明确的需要实现目的，只是根据客户的

3、口头描述来开发，没有在前期 设计时进行必耍的功能流程与设计界而可操作性。幸运的是，负责该功能开发的员工处理能 力比较好，很快开发出该功能的基本流程功能（如设置，修改，显示，反查等功能）。但是 后来暴露的问题确实让我们应该总结的，比如等待吋间，界而和整体软件的协调性，很多用 户不愿意使用，以及没有上下级利用该功能进行沟通的能力等。虽然这些属于软件开发的规 范流程问题，但是开发过程中对测试的忽略是很多功能没有延时和失败的根本原因。存在问题三、项间沟通规范性差。各个开发人员各自开发,编写的代码不仅风格各异, 而且编码和设计脱节（实际上没有对以参考的相关的设计文档）。本来开发中错误在所难免, 进展早一

4、点完成功能和晩一点的完成功能，但是因为代码开发的不规范性，别人很难对其他 员工开发的代码进行快速的理解与修改。系统升级，需要修改程序，没人能看到及吋更新的文档，尽管有一堆代码库，但是后来的 程序员都没办法分析明白程序结构。存在问题四、接上，文档与程序严重脱节。软件产品是公司的宝贵财富，代码的重用率是 相当高的，如何建好知识库，用好知识库对公司优质高效开发产品，具有亜大的影响。前人留 卜的程序既无像样的文档（即使留卜了文档，其与源程序也严重脱节），开发风格乂不统一，就 像一堆垃圾，要开发人员到垃圾中去捡破烂，从这个角度上看,开发人员的要求是合理的。存在问题五、测试工作不规范。仍然停留在”业务与技

5、术人员做测试”的底水平上，传统的 开发方式中。测试工作只是在我们们的一种主观愿望测试中，根木无法提出具体的测试耍求, 加z开发人员的遮11,测试工作往往是只看功能点的结果，不看全局。测试结果既无法考核 乂无法量化，当然更无法对以后的开发工作起指导作川。存在问题六、没有成功进行项目开发的版木控制，不同的开发吋间有不同的版木，但是可 能就会冇不同的开发人员就有不同的版木，最后由项ri负责人合并的时候，变成另一个新版 木。不同时期的更改都在记录在儿个骨干人物的脑袋甲。开发人员要手工地保持多份不同的 拷贝，即使是相同的问题，但由于在不同吋期提叽由不同人解决，其做法也不同，程序的可维 护性越來越差。久而

6、久之，最后连自己都分不清楚了，代码的相互覆盖现象时冇发生，冃这苦 水还无法倾诉，因为可能怕别人笑话，其至别人问起,还得想法搪塞，可谓费尽苦心。存在问题七、没有规范的测试说明文档，更没有规范的测试用例（其实跟本就没有）。测 试人员没有具体的可以依赖的测试用例和操作步骤，无从做起。项廿负责人没有提供必耍的 可指导的实施工作经验，没有前期的技术设计文档。所有的测试工作只能按照后期的操作说 明书进行。只能进行测试工作小最简单的功能测试。对潜在的bug跟本无法预见，更不能 对程序的性能捉出测试结果。2.2寻求解决之道首先要说明的是，我的这个文档授终的完成后，也无法完全解决以上和以及没有列上的问题, 我们

7、是一个新软件公司，很多方曲都在探索z中，我最大的愿望是越做越好。而不是越來越 差，我想这也是全体员工与领导的愿望。2.2.1人员安排：我们公司的人力有限，不考虑未来数刀要离开公司的人员情况。以廿前的 员工规模为19人，我们只算一个小型的软件开发公司。分为行政二人（经理和助理），研 发组10人（如果说算部门的话也可以，只能是自我安慰一下算了。其屮包括软件测试人员）。 其他就是技术支持与美工组。未來的测试人员必须要独立出來，i大i为如果测试人员属于开发组负责人管辖的话，怎么能保 证其结果的真实性呢！就彖市法院与检查院被市长管的话，他们怎么敢去查处市政府的问题 呢！当然这只算个比方，我们系统有bug

8、并不代表我们的工作没有认真负责。2.2.2对测试规划的整体布局：测试与开发计划步骤应该协调一致。我们应该找到一个可 以让我们的开发计划与实际的开发过程有一个很好的同步处理机制。2.2.3在软件的开发过程屮，功能的完成不应该仅仅是时间和表面的结果。应该对项n 的全局考虑，这样就要并入整体测试，对代码和规范性进行测试。对相关的文档要并入资料 库。方便将來其他员工对代码的修改。2.2.4为什么我们没有前期开发设计呢？好象都有，实际又都没有。我们都知道软件开 发的结果是给用户来使用。那么前期的需求就是客八提出，我们的软件设计人员来总结处理, 然后在和客八沟通我们可以实现的结果式样，模拟给用户看,然后在

9、让用八提出在修改意见。 这样不断的迭代，最终设计出我们和客户都认可的软件详细设计书。也许我这甲描述的很简 单，实际操作就非常复杂。比如，我们给客户看的是什么样子，客户没有什么必要的电脑知 识，他们不理解我们的设汁思路怎么办。他们的想法千人千意怎么办。这就要看我们的前期 设计人员的处理能力了。否则为什么要软件系统分析师呢。上面的内容有点离题了，但是日前我们每天都在做着这些跑题的事情。下血是我们开发过程 中每天都可能做的真实的案例：我们开发的每一个功能模块没有一个完善的前期设计文档, 这样就没有可以处理测试依据。这样根本就无从谈起我们如何设计测试用例。我们分配工作 或分配开发模块的描述基本和客户的

10、说法一样的。比如人事调动，出现迁移的事情。我们的 系统就要实现这样的功能，我们分配模块开发时也许把客户说的原话拿过來，然后附带一下 相关表格。最多在告诉你这些数据应该保存到哪些数据库的表里。然后就是应该多少时间内 完成这样的功能。这就算完了。当然还可以在所谓的开发过程记录表格里记上你的开发功能 和安排的完成预期时间。可以看到，这个过程没有任何的的测试计划，其唯一的可以了解的测试入口就是和客八提供 样的描述语句，在加上你要完成的时间。在软件工程的规范化管理中，这样做毫无意义。我们要的是可以预见的，可以测试的开发设计书。每一个功能开发任务的下发都要有对应的 测试用例。2.2.5我们的开发软件，是以

11、工程项h为主的。这个项忖必须保持版本的一致性。记得原 来我们也用过版本控制软件vss (microsoft visual sourcesafe),但是不知道什么原 因中途就停止了。我们应该很好地掌握一个性能稳定，适合我们开发工具的版本控制工具。 这个就要让独立的测试人员來单独控制。这样也方便他们的测试工作开展。对该技术的熟悉 程度也是该版本控制系统实施成功的关键，我们应该让熟悉的人员进行深入研究，然后对测 试人员进行必要的培训。如果时间允许也可以让测试管理人员对该工具进行深入学习。2.2.6测试工作不仅仅是让单独的测试人员來做，应该分布在整个软件开发过程。我记得 ibm的软件开发就讲究软件开发

12、人员与测试人员测试互补进行。当然测试人员必须独立与 开发组管辖。2.2.7我们应该规范我们的测试文档，大家都知道，没有完全通用的规范。针对不同的开 发项目，可能我们设计出來的测试计划和测试用例是不同的。但是做为软件开发公司，又是 一个不足30人的。目前仅仅只开发一套软件的小软件公司，我们更应该及早对测试这一块 工作出台一套可以指导性的手册。2.3长远想法与计划我们对测试规范的手册的编写的根本h的是规范开发流程。减少不必耍的资源浪费。不 是要对我们员工工作进行更严格的倚制，更不是要他们每做一件事情都要进行时间的川报与 限制。我们到口前为止，已经进行了 n次的工作实践表明，这样的工作方法是失败的。

13、任 何非人性化的管理方法都应该抛弃。我们要在一定的时间内开发出客户认为可以验收的项忖，其因素很多。对软件构架师來 说，软件的最终川户的使川，是他们的关注重点。对软件公司的老板或经理来说，成木与积 累经验更車耍。客八的想法在此不必提出。而要达到合理的双嬴，测试的规范性是比不可少 的。没有可以预见的功能，任何客户都不会购买，任何老板都没有办法确定员工工作的好坏。 可以积存的开发经验，没有可以测试的文档就不完整，或毫无意义。开发人员最人的好处是 可以让他们有一个完全可以知道口己的开发流程，与完成结果的测试依据。在也不是依据某 个人的主观能力來判断其是否完成的工作安排。为什么不先对软件项目的整个开发流

14、程进行规范呢？这主要是我们的人力有限，其能力 更有限。要对整个项日进行规范化管理，就要对整个公司进行改造，这儿乎是不可能的事情。 但是我们的事业乂要发展，我们始终希望我们的公司能蒸蒸h上。这样就要找到一个合理的 切入点，让人家各个方面都可以接受的切入点。针对我们口前的工作缺点进行a理的改进, 提高我们的工作效率，提升员工的士气，这个很重要。当然这些现象不会在我这个测试规范 操作于册发布后就能体现岀來。这需要一个过程，也许将來老板会认为我的这个测试规范手 册实施的非常有效果，然后在让我写整个项目的开发规范手册。也许这个手册刚一出來就被 扔进垃圾筒里。我想那肯定就是我的切入点寻找的失败。3大致的时

15、间安排与对应的内容我原先就与xxx谈起，这个时间不可能完全准确。因为需要做的丄作很多，因为这些 内容完全是依靠实际的工作经验來写。个人能力有限吧，在处理具体各个模块的测试方法与案例设计的时候会有不同。我也会尽力寻找相关资料和同行朋友进行必要的交流。使其更加 完善。我们的操作手册是计划有以卜儿大部分:相关内容耐is说明测试的人事安排计划。1测试人员的工作职责。1整个项目开发流程与测试计划的对应 关系。1测试人员与开发人员（项日负责人） 的沟通方式与流程3设计测试计划的方法与实际测试用 例。如下说明功能测试2确保应用程序符合指定的要求白盒测试，2测试小范围特定区域的代码安全性测试2测试应用程序及其

16、数据是否受 到保护、隐私是否受到保护，以 及数据是否正确加密性能测试2测试应用程序在齐种情况下的 处理和响应时间集成测试2确保应用程序与其他系统和组 件配合工作内容测试2验证文档的正确性安装测试2验证应用程序已正确安装在客 户端计算机上对bug系统的合理跟踪与处理5这个是测试中最关键的部分。版本控制系统的选用3软件的配置是测试软件的前提。测试文档的规范范例5对各个阶段的测试报告与表格 进行说明对软件详细设计说明书的测试1启动测试流程的前期工作设计软件测试计划书3对需要这个计划书的内涵规范 进行解释，包含了以上的部分内 容。其他问题处理2做些零碎的问题说明。当然这也不是最后的手册冃录，我会根据实

17、际的情况做些修改。时间安排上也 不是非常死板。根据从前的公司给我的时间安排情况，我想又会出现压缩工作时间的事情，虽 然我很讨厌这样的作法，但是我也没有办法改变这样的现状。只好适应了。如果压缩时间的话，我想我前期会根据具体的时间，首先完成几个关键的部分, 比如功能测试部分，因为现在我们公司只停留在这个水平。我也会对bug跟踪系统的规范做一些研究，比如问题的规范性描述，提交的方 式与流程。接受方需要处理的过程。这个问题最终到什么情况下才可以结束。如 何避免同类的问题还在我们接续的项fl中出现等。我和具他同事探讨规范性的时候，往往更多的是关注文档的如何书写，表格如 何画法。其中应该有哪些该添的元索。我们的操作手册中对此也要做全面详细的 论述。但是这不是我们编写该手册的重点。我个人感觉如果太强调这些的话，我 们的测试就本末倒置了。4、面临的挑战