1、前言本文档主要描写对该计划的前期阐述，说明其重要性与操作过程的前期计划。着重点描述未来 《本公司软件测试规范操作手册》的深度与可操作性等问题。
2、为什么要编写此规范手册首先从公司的现状来看，我们公司是刚刚起步的新软件开发公司，目前的开发主项目《xxxxx管系统》已经接近尾声。虽然属于延迟完成项目，但是却给我们带来很多可以总结的经验和教训。
比如开发流程，开发文档的编写。并在此方面做了很多积极的探索。
2.1分析我们公司目前软件项目在开发管理过程中的现状：存在问题一、目前的《XXX管系统》项目仍然过分分依赖少数个人的作用,没有建立起协同作战的氛围,没有科学的软件开发管理流程; 技术上只重视系统和数据库、开发工具的选择,而忽视开发规范化过程,需求变更频繁，导致即使使用同类规程,也由于可操作性差而搁浅。
存在问题二、开发管理没有适时跟进。我们是一家新的软件公司，领导和项目负责人对具体的开发过程理解有限。对每一个开发过程中需要把握的结果尺度不够。片面的讲究时间效应。导致项目开发没有必要的前期可以参考的完成标准就盲目对项目进行赶进度。虽然大多按时完成任务，但不久又发现问题出现。比如：报警系统，前期客户就明确提出要求有这个功能，我们没有对该功能进行必要的分析和设计，只是在项目代码开发进行到最后阶段，才想起来后补加该功能。
补加的报警功能没有明确的需要实现目的，只是根据客户的口头描述来开发，没有在前期设计时进行必要的功能流程与设计界面可操作性。幸运的是，负责该功能开发的员工处理能力比较好，很快开发出该功能的基本流程功能（如设置，修改，显示，反查等功能）。但是后来暴露的问题确实让我们应该总结的，比如等待时间，界面和整体软件的协调性，很多用户不愿意使用，以及没有上下级利用该功能进行沟通的能力等。虽然这些属于软件开发的规范流程问题，但是开发过程中对测试的忽略是很多功能没有延时和失败的根本原因。
存在问题三、项目之间沟通规范性差。各个开发人员各自开发,编写的代码不仅风格各异,而且编码和设计脱节（实际上没有可以参考的相关的设计文档）。本来开发中错误在所难免, 进展早一点完成功能和晚一点的完成功能，但是因为代码开发的不规范性，别人很难对其他员工开发的代码进行快速的理解与修改。
系统升级，需要修改程序，没人能看到及时更新的文档，尽管有一堆代码库，但是后来的程序员都没办法分析明白程序结构。
存在问题四、接上，文档与程序严重脱节。软件产品是公司的宝贵财富,代码的重用率是相当高的,如何建好知识库,用好知识库对公司优质高效开发产品,具有重大的影响。前人留下的程序既无像样的文档(即使留下了文档 ,其与源程序也严重脱节),开发风格又不统一,就像一堆垃圾,要开发人员到垃圾中去捡破烂,从这个角度上看,开发人员的要求是合理的。
存在问题五、测试工作不规范。仍然停留在"业务与技术人员做测试"的底水平上，传统的开发方式中。测试工作只是在我们们的一种主观愿望测试中,根本无法提出具体的测试要求,加之开发人员的遮丑,测试工作往往是只看功能点的结果，不看全局。测试结果既无法考核又无法量化,当然更无法对以后的开发工作起指导作用。
存在问题六、没有成功进行项目开发的版本控制，不同的开发时间有不同的版本，但是可能就会有不同的开发人员就有不同的版本，最后由项目负责人合并的时候，变成另一个新版本。不同时期的更改都在记录在几个骨干人物的脑袋里。开发人员要手工地保持多份不同的拷贝,即使是相同的问题,但由于在不同时期提出,由不同人解决,其做法也不同,程序的可维护性越来越差。久而久之,最后连自已都分不清楚了,代码的相互覆盖现象时有发生,且这苦水还无法倾诉,因为可能怕别人笑话,甚至别人问起,还得想法搪塞,可谓费尽苦心。
存在问题七、没有规范的测试说明文档，更没有规范的测试用例（其实跟本就没有）。测试人员没有具体的可以依赖的测试用例和操作步骤，无从做起。项目负责人没有提供必要的可指导的实施工作经验，没有前期的技术设计文档。所有的测试工作只能按照后期的操作说明书进行。只能进行测试工作中最简单的功能测试。对潜在的bug跟本无法预见，更不能对程序的性能提出测试结果。
2.2寻求解决之道
首先要说明的是，我的这个文档最终的完成后，也无法完全解决以上和以及没有列上的问题，我们是一个新软件公司，很多方面都在探索之中，我最大的愿望是越做越好。而不是越来越差，我想这也是全体员工与领导的愿望。
2.2.1人员安排：我们公司的人力有限，不考虑未来数月要离开公司的人员情况。以目前的员工规模为19人，我们只算一个小型的软件开发公司。分为行政二人（经理和助理），研发组10人（如果说算部门的话也可以，只能是自我安慰一下算了。其中包括软件测试人员）。其他就是技术支持与美工组。
未来的测试人员必须要独立出来，因为如果测试人员属于开发组负责人管辖的话，怎么能保证其结果的真实性呢！就象市法院与检查院被市长管的话，他们怎么敢去查处市政府的问题呢！当然这只算个比方，我们系统有bug并不代表我们的工作没有认真负责。
2.2.2 对测试规划的整体布局：测试与开发计划步骤应该协调一致。我们应该找到一个可以让我们的开发计划与实际的开发过程有一个很好的同步处理机制。
2.2.3 在软件的开发过程中，功能的完成不应该仅仅是时间和表面的结果。应该对项目的全局考虑，这样就要并入整体测试，对代码和规范性进行测试。对相关的文档要并入资料库。方便将来其他员工对代码的修改。
2.2.4 为什么我们没有前期开发设计呢？好象都有，实际又都没有。我们都知道软件开发的结果是给用户来使用。那么前期的需求就是客户提出，我们的软件设计人员来总结处理，然后在和客户沟通我们可以实现的结果式样，模拟给用户看，然后在让用户提出在修改意见。这样不断的迭代，最终设计出我们和客户都认可的软件详细设计书。也许我这里描述的很简单，实际操作就非常复杂。比如，我们给客户看的是什么样子，客户没有什么必要的电脑知识，他们不理解我们的设计思路怎么办。他们的想法千人千意怎么办。这就要看我们的前期设计人员的处理能力了。否则为什么要软件系统分析师呢。
上面的内容有点离题了，但是目前我们每天都在做着这些跑题的事情。下面是我们开发过程中每天都可能做的真实的案例：我们开发的每一个功能模块没有一个完善的前期设计文档，这样就没有可以处理测试依据。这样根本就无从谈起我们如何设计测试用例。我们分配工作或分配开发模块的描述基本和客户的说法一样的。比如人事调动，出现迁移的事情。我们的系统就要实现这样的功能，我们分配模块开发时也许把客户说的原话拿过来，然后附带一下相关表格。最多在告诉你这些数据应该保存到哪些数据库的表里。然后就是应该多少时间内完成这样的功能。这就算完了。当然还可以在所谓的开发过程记录表格里记上你的开发功能和安排的完成预期时间。
可以看到，这个过程没有任何的的测试计划，其唯一的可以了解的测试入口就是和客户提供一样的描述语句，在加上你要完成的时间。在软件工程的规范化管理中，这样做毫无意义。
我们要的是可以预见的，可以测试的开发设计书。每一个功能开发任务的下发都要有对应的测试用例。
2.2.5 我们的开发软件，是以工程项目为主的。这个项目必须保持版本的一致性。记得原来我们也用过版本控制软件VSS（Microsoft Visual SourceSafe），但是不知道什么原因中途就停止了。我们应该很好地掌握一个性能稳定，适合我们开发工具的版本控制工具。这个就要让独立的测试人员来单独控制。这样也方便他们的测试工作开展。对该技术的熟悉程度也是该版本控制系统实施成功的关键，我们应该让熟悉的人员进行深入研究，然后对测试人员进行必要的培训。如果时间允许也可以让测试管理人员对该工具进行深入学习。
2.2.6 测试工作不仅仅是让单独的测试人员来做，应该分布在整个软件开发过程。我记得IBM的软件开发就讲究软件开发人员与测试人员测试互补进行。当然测试人员必须独立与开发组管辖。
2.2.7 我们应该规范我们的测试文档，大家都知道，没有完全通用的规范。针对不同的开发项目，可能我们设计出来的测试计划和测试用例是不同的。但是做为软件开发公司，又是一个不足30人的。目前仅仅只开发一套软件的小软件公司，我们更应该及早对测试这一块工作出台一套可以指导性的手册。
2.3 长远想法与计划
我们对测试规范的手册的编写的根本目的是规范开发流程。减少不必要的资源浪费。不是要对我们员工工作进行更严格的管制，更不是要他们每做一件事情都要进行时间的申报与限制。我们到目前为止，已经进行了N次的工作实践表明，这样的工作方法是失败的。任何非人性化的管理方法都应该抛弃。
我们要在一定的时间内开发出客户认为可以验收的项目，其因素很多。对软件构架师来说，软件的最终用户的使用，是他们的关注重点。对软件公司的老板或经理来说，成本与积累经验更重要。客户的想法在此不必提出。而要达到合理的双嬴，测试的规范性是比不可少的。没有可以预见的功能，任何客户都不会购买，任何老板都没有办法确定员工工作的好坏。可以积存的开发经验，没有可以测试的文档就不完整，或毫无意义。开发人员最大的好处是可以让他们有一个完全可以知道自己的开发流程，与完成结果的测试依据。在也不是依据某个人的主观能力来判断其是否完成的工作安排。
为什么不先对软件项目的整个开发流程进行规范呢？这主要是我们的人力有限，其能力更有限。要对整个项目进行规范化管理，就要对整个公司进行改造，这几乎是不可能的事情。但是我们的事业又要发展，我们始终希望我们的公司能蒸蒸日上。这样就要找到一个合理的切入点，让大家各个方面都可以接受的切入点。针对我们目前的工作缺点进行合理的改进，提高我们的工作效率，提升员工的士气，这个很重要。当然这些现象不会在我这个测试规范操作手册发布后就能体现出来。这需要一个过程，也许将来老板会认为我的这个测试规范手册实施的非常有效果，然后在让我写整个项目的开发规范手册。也许这个手册刚一出来就被扔进垃圾筒里。我想那肯定就是我的切入点寻找的失败。
3、大致的时间安排与对应的内容
我原先就与xxx谈起，这个时间不可能完全准确。因为需要做的工作很多，因为这些内容完全是依靠实际的工作经验来写。个人能力有限吧，在处理具体各个模块的测试方法与案例设计的时候会有不同。我也会尽力寻找相关资料和同行朋友进行必要的交流。使其更加完善。
我们的操作手册是计划有以下几大部分：
相关内容
预计完成天数
说明
测试的人事安排计划。
1
测试人员的工作职责。
1
整个项目开发流程与测试计划的对应关系。
1
测试人员与开发人员（项目负责人）的沟通方式与流程
3
设计测试计划的方法与实际测试用例。
如下说明
功能测试
2
确保应用程序符合指定的要求
白盒测试，
2
测试小范围特定区域的代码
安全性测试
2
测试应用程序及其数据是否受到保护、隐私是否受到保护，以及数据是否正确加密
性能测试
2
测试应用程序在各种情况下的处理和响应时间
集成测试
2
确保应用程序与其他系统和组件配合工作
内容测试
2
验证文档的正确性
安装测试
2
验证应用程序已正确安装在客户端计算机上
对Bug系统的合理跟踪与处理
5
这个是测试中最关键的部分。
版本控制系统的选用
3
软件的配置是测试软件的前提。
测试文档的规范范例
5
对各个阶段的测试报告与表格进行说明
对软件详细设计说明书的测试
1
启动测试流程的前期工作
设计软件测试计划书
3
对需要这个计划书的内涵规范进行解释，包含了以上的部分内容。
其他问题处理
2
做些零碎的问题说明。
当然这也不是最后的手册目录，我会根据实际的情况做些修改。时间安排上也不是非常死板。
根据从前的公司给我的时间安排情况，我想又会出现压缩工作时间的事情，虽然我很讨厌这样的作法，但是我也没有办法改变这样的现状。只好适应了。
如果压缩时间的话，我想我前期会根据具体的时间，首先完成几个关键的部分，比如功能测试部分，因为现在我们公司只停留在这个水平。
我也会对bug跟踪系统的规范做一些研究，比如问题的规范性描述，提交的方式与流程。接受方需要处理的过程。这个问题最终到什么情况下才可以结束。如何避免同类的问题还在我们接续的项目中出现等。
我和其他同事探讨规范性的时候，往往更多的是关注文档的如何书写，表格如何画法。其中应该有哪些该添的元素。我们的操作手册中对此也要做全面详细的论述。但是这不是我们编写该手册的重点。我个人感觉如果太强调这些的话，我们的测试就本末倒置了。
4、面临的挑战为什么说是挑战呢，有很多方面的原因。首先这个规范的编写就有可能立即结束。那就是本计划书没有写好。
还有测试手册的编写首先就是可操作性，这个不比我们随便从网络上下载的国标软件开发文档中描述的内容（实际上任何正规软件开发公司都不会套用那个老掉牙的模板，原因非常简单，不实用）。
也许这个操作手册是对我们公司量身订做的，这就要根据我们公司的实际状况来规划这个实际规范操作说明书。没有实际的运转能力的规范就像我们开发的软件，没有实际的用户去操作是毫无意义的事情。要让大家都能很快掌握，喜欢按照这个流程与规范来做，是对这个操作手册处理的关键所在。
