测试的工作计划

测试的工作计划（精选8篇）

测试的工作计划 第1篇

做好测试计划和测试用例的工作的关键

做好测试计划和测试用例的工作的关键（转）

对于目前大部分公司存在的状况，很多测试计划文档只是一种形式而已

所以我的理解是：怎样让测试计划对整个测试工作真正具有指导作用

这里把测试计划和测试方案分开来讲（计划对应于管理层面的问题，方案对应于技术方面的问题）

测试计划中最重要的内容包括： 进度安排；人力、物力资源分配（包括组织结构等）、风险假设和规避措施。（其他像软件版本号之类的，只要是个人都会写，这里不列了）写好测试计划的关键在于：充分了解你的团队的整体实力和团队中每个成员的特点充分理解为当前软件制订的整个研发活动过程

带过项目的人都知道：在实际项目中，往往进度才是第一位的，但是对进度的把握和估算却是极其困难的。只有做到这两点才有可能对进度有比较准确的把握，对人员有一个合理的分配。否则所谓的进度，所谓的资源分配，都是拍脑袋得出的结果，风险假设更是无从谈起，这样的测试计划文档只能流于形式也就不足为奇了。

写好测试方案的关键在于：有一个合理的测试计划熟悉相关业务深入体会用户的实际需求

这个不想多解释了，不难理解。

至于测试用例，看到上面不少朋友认为关键在于理解用户需求。

其实理解用户实际需求是一切的根本，并且对于有些测试（比如像单元测试）对应的测试用例通常和用户需求之间的关系可能并不直接或是十分密切。

当然，如果有一份好的需求和设计文档的话，什么事情都解决了。可是现实往往是不存在这样的文档的。

所以我的看法是：对业务理解的深入程度经验有自己的文档

前两条不解释了。自己的文档包括两方面：一个是常用的特殊测试数据，比如一些特殊字符，极限长度的输入等等。这个在项目时间紧迫的时候是非常有帮助的（有的时候甚至可以当成check list）。另一个就是自己测试模块对应的相关需求和设计文档。服务器上的标准文档拖到本地来并且记得及时更新。然后在测试过程中，需要什么内容文档上没有，最直接的方法是和开发人员沟通。（其实我很反对这么做。你想，按开发人员自己说的标准

去测他们自己开发的模块能测出因为需求或者设计错误导致的问题么„„应该是和客户和designer去沟通，可惜一般没有这条件-_-）任何标准文档上缺少的内容，只要是和你有关的，一定要记得做记录。当然你有时间有精力把整个系统的需求和设计文档都捣鼓出来最好，不过通常是没这可能性的。

补充说明：lz最后提到的“完全凭借自己的经验在执行测试活动”不如说是完全凭借自己的感觉在执行测试活动。

项目需要的用例详尽程度可以商量，但是必须要有。如果进度很紧，可以用一部分用例加上check list进行测试活动（比如很多日本外包项目的UI测试，相当一部分可以用check list来代替具体的用例，效果并不差)

完整的大纲应该是：

目录

测试计划标识符

目录表

参考文献

词汇表

介绍

测试项

软件风险问题

待测特征

不予测试的特征

方法

测试项通过/失败准则

挂起准则和恢复需求

测试交付物

测试任务

环境需求

职责

人员安排与培训需求

进度表

计划风险与应急措施

审批

测试的工作计划 第2篇

无论做什么工作，都是计划先行，然后按照所制定的计划去执行、跟踪和控制。软件测试也一样，先要制定测试计划，是做好整个测试工作的前提。所以在进行实际测试之前，应制定良好的、切实可行的、有效的测试计划。软件测试计划的目标是提供一个测试框架，不断收集产品特性信息，对测试的不确定性（测试范围、测试风险等）进行分析，将不确定性的内容慢慢转化为确定性的内容，该过程最终使得我们对测试的范围、用例数量、工作量、资源和时间等进行合理的估算，从而对测试策略、方法、人力、日程等做出决定或安排。

1．测试计划的要点

测试规划与软件开发活动同步进行，在需求分析时，就开始测试策划，确定测试需求、目标、资源等。测试计划可以按不同的测试阶段（集成测试、系统测试等）来组织，也可以为每个测试任务或目标(安全性、性能、可靠性等测试)进行考虑。

测试计划主要集中在测试目标、质量标准、测试策略、测试范围、测试用例设计方法、所需资源和日程安排等，其关键是制定有效的测试策略，界定清楚地测试范围，识别出测试中所存在的各种风险并找出风险回避、监控和管理的方法，针对不同的测试目标或阶段确定测试方法，对测试工作量及所需的资源、时间进行合理的估算。所有这些，都是为了两个根本目的：测试的质量和效率。

2．制定测试策略

制定测试策略主要分析测试的目标和质量指标、确定测试的对象和依据，测试的重点和所采用的方法，包括在规定的时间内哪些测试内容要完成，软件产品的特性或质量在哪些方面得到确认。测试策略可以分为：

基于测试技术的测试策略，根据软件系统的技术构成和层次结构，着重考虑如何分层测试、选择哪些测试工具、如何将白盒测试和黑盒测试有机地结合起来等。

基于测试方案的综合测试策略，根据测试的目标和范围，着重考虑如何更好地满足测试需求、如何让功能测试、适用性测试和兼容性测试等进行有机结合、如何充分利用测试资源、如何更有效地完成回归测试等。

为了更好地制定好测试策略，要做到：

全面细致地了解产品的项目信息：应用领域、测试范围、市场需求、产品特点、主要功能和技术架构；

基于模块、功能、系统、版本、性能、配置和安装等各个因素对产品质量的影响，客观地、全面地展开测试计划；

根据软件单元在系统结构的重要性差异和一旦发生故障将给客户造成的损失大小，来确定软件测试的等级、重点和先后次序；

需要在测试用例数和测试覆盖率上进行权衡而获得一个平衡点，以便能使用尽可能少的有效测试用例去发现尽可能多的程序错误。测试不足意味着让用户承担隐藏错误带来的危险；同时反过来看，过度测试则又会浪费许多宝贵的资源或耽误软件产品的发布时间。

3．确定测试范围

测试主要依据 “产品设计规格说明书”、代码所发生的变化及其影响的区域，来确定哪些功能和特性要测试，哪些功能和特性不需要测试。在确定测试范围时，主要考虑的因素有：

优先级最高的需求功能

新增加的功能和编码改动较大的已有功能

容易出现问题的部分功能

过去测试不够充分的地方

经常被用户使用的功能和配置（占20%）

4．所需资源和日程安排

为了合理、准确地安排日程，对测试工作量要进行正确的估计。除了对工作量的估计之外，还要正确评估参与该项目人员的培训时间、适应过程和工作能力等。由于涉及到不同的项目、不同的测试人员、不同的前期介入方式，要对每人每天能够完成的平均测试用例数目做出一个准确的估计确实很困难，但是可以根据以前一些项目测试的经验或历史积累下来的数据进行判断推理，并适当增加10%-20%的余量，估算结果就比较准确了。

在估算的基础上，进行有效的、合理的资源安排。在不同的测试阶段人力资源的需求是不一样的，所以人力资源的计划要有一定的灵活性和动态性，形成有机的动态平衡，保证测试的进度和资源的使用的效率。

5．编制测试计划的技巧

要做好测试计划，测试设计人员要仔细阅读有关资料，包括用户需求规格说明书、设计文档等，全面熟悉系统，并建议注意以下方面：

让所有合适的相关人员参与测试项目的计划制定，特别是在测试计划早期；

测试所需的时间、人力及其它资源的预估，尽量做到客观、准确、留有余地；

测试项目的输入、输出和质量标准，应与各方达成一致；

建立变化处理的流程规则，识别出在整个测试阶段中哪些是内在的、不可避免的变化因素，加以控制。

6．测试项目计划的评审

测试项目的计划不可能一气呵成，而是要经过计划初期、起草、讨论、审查等不同阶段，才能将测试计划制定好。测试计划的评审是完成测试计划关键的一个环节，包括测试组织内部的自我评审、讨论和修改，然后交到评审会进行正式的评审，直至测试计划得到审批。

测试计划的正式评审，项目中的每个人（产品经理、项目经理、开发工程师等）都应当参与。计划的审查是必不可少的，每一个参与者都可能根据其经验及专长提出问题或建议，弥补在测试范围、工作量、风险等各方面的不足，进一步完善测试计划。

二、测试用例在测试活动中的作用：

1.强化测试用例在测试活动中的作用

测试用例在实际中没有起多大作用 , 在实际测试时根本没有按测试用例执行，测试执行后没有把新的测试用例补充到用例库中等等。

为何如此？ 根本原因是对测试用例重要性的认识不够，测试流程不完善，针对测试用例的管理流程更不完善，其实，从三个方面具体来说：

1）测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据，如果这个依据不能足够发挥它应起的作用，那是不是说这个依据不明确、依据设计的不合理呢？答案是肯定的！

2）制定了完备有效的测试用例，为什么不按测试用例执行测试呢？首先是因为企业没有严格和良好的机制促使和保证测试执行者这样做；其次是个别测试人员投机取巧心理作祟的表现。

3）测试用例设计得不可能天衣无缝，不可能完全满足软件需求的覆盖要求，测试执行过程里肯定会发现有些 测试路径或数据在用例里没有体现，那么事后该将其补充到用例库里，以方便他人和后续版本的测试；如果没有这样做，那么测试部门负责人和每个测试员都难辞其疚，是该重新坐下来思考一下公司的测试用例管理规范和测试流程了。

2.改进测试用例执行过程

那么究竟如何做，才能尽量避免上述问题呢？

我们不妨从软件开发周期的每个阶段就把这些问题考虑进去，以便从初始就力争将问题缩到最小，将问题扼杀在萌芽阶段。

1）软件需求分析阶段，测试人员从软件生命周期的需求阶段就开始介入。通常测试人员的测试工作开展在开发周期的末尾，如果前期不涉入，如何通晓整个系统的需求和架构而对其充分测试呢？

项目的测试负责人和测试工程师在 需求阶段 的任务有：

a.参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；更重要的是，对不可测或难以测试性问题要及时与客户或项目经理协调解决。

b.全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。

2）软件分析设计阶段：

l 测试人员除制定测试计划书等基本工作外，还有一个相当必要的任务，那就是将系统的可测性落实到书面文档，以备将来编写测试用例。（之所以要这么做，是因为考虑到很多企业编写测试用例直接参考需求规格说明书或者分析流程图，这样跨度大，难度也大，是造成测试用例不完备、覆盖范围小的重要原因）。

l 测试人员更要编写一份《软件功能点测试描述书》，它是软件的详细测试分析文档，其主旨是将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等，这些信息都是描述性的，无须具体数据；它的作用是据此编写测试用例，以及测试执行时的参考依据，基于它直接来源于需求，覆盖当然最全，也最能贴近客户要求。

l 当然该文档不是非要不可，如果有类似的替代文档或有工具可自动实现此功能，则会倍加受推崇！

3）软件开发阶段： 编写测试用例。应该遵守的原则是：

n 首先，从覆盖率来说，测试用例库的用例要达到最大覆盖软件系统的功能点。编写测试用例时，基本上就是将《软件功能点测试描述书》中的每个功能点进行操作上的细化：一是从步骤上描述到达校验点的方式，二是从内容上描述以何种数据校验功能点；如此可实现趋向最大需求覆盖率。

n 其次，从数量来讲，一个多于半年开发周期（指从编码开始直到提交客户的时间段）的软件系统，它的用例数量不要低于 4000 个，甚至更多！（IBM 等大公司测试过程的人士会认为 4000 还是很少的数目。我们试想，对于一个中小型软件系统，如果设计出 5000 个用例，那它的测试覆盖率还怕不高么）！

n 再次，如此众多测试用例的管理问题。是的，最好是需要测试用例管理工具软件。以 word 或 excel 来编写测试用例也可以。）测试用例 格式上一般内容以外的几个要点：

l 制定适合本公司的测试用例模版；

l 是用例模版里要有关键字索引，以方便按关键字分类查找，如测试方法（分手工 / 自动两种）；

l 是测试用例要有 状态跟踪，可根据用例执行状态索引用例（测试通过、测试失败、测试中断等）；

l 是执行失败的用例要 链接到相应的缺陷报告，如有根据缺陷报告检索测试用例的试图更妙，可评估该缺陷影响范围的大小；

l [FS:PAGE] 是测试用例的修改，以及每个测试周期的运行都有 日志记录，以便后期追踪

和新员工参考；）软件测试阶段，测试负责人划分不同的测试阶段（如集成测试、系统测试、回归测试、性能测试等），再划分不同的子测试周期（如前两个星期做 冒烟测试，测试方式是手工 / 自动，测试版本是 **，测试环境是 **，包括服务器端与客户端等；接着做第一模块功能测试；如此顺次。），再为项目组测试人员分配测试用例（通常原则是每个人负责几块区域的测试任务），测试人员则按照详细的用例文档去执行测试，测试失败则提交软件缺陷报告。这里要遵循的几个原则是：

A）有健全且严格的体制保证测试执行者严格按照测试用例执行测试。这并不妨碍测试者创造力的发挥，因为前期用例的设计和编写就是项目全体测试人员智慧的结晶！我们一直苦苦追寻众多测试工程师加班加点辛苦工作的原因，其实大都发生这一阶段；如此实施，即便没有解决根本问题，也会大大提高测试执行效率。

B）如有对测试用例认识模糊或内容遗漏的地方，可暂做记录待后期解决，或经测试负责人与项目其他管理人员同意方可更新用例库。

C）测试负责人每日负责跟踪本测试子周期或阶段的测试用例执行情况，以及每日提交的缺陷报告，根据执行进展状态以及缺陷数量或严重等级与项目高层或其他人员展开交流，商议解决途径，并确定或调整未来时间的测试任务。

D）测试执行者负责执行自己区域的测试用例，还要负责跟踪该区域软件缺陷的修改进展，根据其状态 不断验证软件功 能点。

E）通过缺陷管理工具来 管理软件缺陷 ；这样的集成工具都提供了清晰的报告模版及强大的追踪功能，测试团队的每一成员按照自己的角色和权限访问缺陷管理工具，并不断跟踪软件缺陷的状态。

F）对于自动测试（包括自动化功能测试和性能、压力测试），有一些特殊要点。是自动化测试无须编写测试用例，只要在编写时将用例库里适合或需要自动测试的用例的测试方法（不同工具可能名称不同）设为自动即可，故而到此阶段才提及自动化测试。自动化测试的实施方案有所不同，每款测试工具的使用和测试流程也不同，但都可以从在这一阶段编写测试脚本，并运行自动测试。这里要提的其他几个基本原则是：

l 是选择恰当的测试工具品牌，并要求提供培训；

l 是项目的自动化测试工作有专人负责跟踪，以保证工作质量，他们可不参与日常测试；l 是确定自动化测试成员在项目中的角色，一般自动化测试成员隶属于项目测试负责人，负责人同样跟踪其工作状态；

l 是选择最简单、最重用的测试用例使用自动测试方法；

l 是使用工具厂商提供的测试框架编写脚本，千万别采用单纯录制回放的方式，要开发出健壮且重用性强的测试脚本 ；

l 是有专人更新脚本，也有专人跟踪自动测试结果；

l 一般选择的测试工具品牌和缺陷管理工具品牌是同一厂商，以方便不同类型缺陷的集中管理；

l 是在多人协作开发测试脚本、代码量相对较大情况下，应考虑使用配置管理工具来管理测试脚本。）由于不同公司开发产品的特殊性，也许需要特殊类型的测试，如安全测试、甚至代码级单元测试等，这些内容需要酌情考虑测试用例的编写，以及测试的执行。）软件验收阶段 ：除了提交软件测试评估报告（各种类型测试结果的评估都应有报告）这些基本工作外，对于测试用例，此时要集中时间更新，更新整个测试周期中一切需要更新的内容，以方便未来新版本的测试。即便您开发的是项目软件--提交客户后没有新版本--那也需要后期维护，维护阶段需要重新测试某功能点，然而用例如果不准确，碰巧又是一个

新员工来做，那就死翘翘了！）其他说明：加强测试部门内部人员的培训教育很重要，包括工作技能与个人素质两方面，可通过国内主要的培训机构，也可是购买工具厂商的直接培训。应该说，很多测试新人对于测试用例的书写还存在问题，更别提及测试用例的管理或执行；以此可见，我们的测试工程师需要培训的空间还很大。

3.总结

浅谈软件测试计划的制定 第3篇

在国内,很多中小型软件公司,软件测试过程不规范,很多软件测试人员没意识到测试计划的重要性,对软件测试工作缺乏整体的规划安排,有很多软件测试项目在没有制定充分的测试计划或者没有制定测试计划情况下,就匆忙展开测试工作,这样导致了测试工作大打折扣,甚至使测试计划成为一纸空文,不能指导测试过程。几乎可以肯定的是,没有计划地消耗测试所需的资源,必然会导致资源的浪费,并且无法对安装前进行的修正状态进行评估,甚至造成很多软件不能投入使用。

2 测试计划的任务和作用

2.1 测试计划的任务

软件测试是有计划、有组织和有系统的软件质量保证活动,而不是随意地、松散地、杂乱地实施过程。测试计划是软件测试中最重要的步骤之一,测试计划的任务是为了尽早明确测试工作的内容范围、测试工作的方法以及测试工作所需要的各种资源,并把这些信息发布给所有涉及到测试工作的测试人员,尽快将下一步测试工作需要考虑的问题和准备的条件落实下来。也就是说测试计划工作的重点在于对测试工作任务的准备和规划以及信息的交流。在对软件进行测试之前,必须认真制定测试计划。

2.2 测试计划的作用

测试计划的作用主要体现在下面三个方面:

1)领导能够根据测试计划做宏观调控,进行相应资源配置等。

2)测试人员能够了解整个项目测试情况以及项目测试不同阶段所要进行的工作等。

3)便于其他人员了解测试人员的工作内容,进行有关配合工作。

4)对开发人员的开发工作,整个项目的规划,项目经理的审查都有辅助性作用。

3 测试计划的定义和内容

3.1 测试计划的定义

《IEEE软件测试文档标准829-1998》将测试计划定义为:“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员时间安排以及与计划相关的风险。”[1]。

软件测试计划是指导测试过程的纲领性文件,其中必不可少的三个要素是时间、资源、范围。时间就是什么时候做以及要花多久做;资源就是你要调用的人力、机器等资源;范围是你要测试的东西以及测试重点。除以上提到的3项外,还有比较重要的部分有策略(具体就是怎么测)、风险控制(一旦有问题采取什么应急措施)等部分。

3.2 测试计划的内容

下面结合图书管理系统的测试计划的制定,来讨论测试计划一般应该包括的内容:

1)测试概要:摘要说明所需测试的软件(系统基本功能和特征等)、测试背景、名词解释、以及列出所参考的相关文档。如图书管理系统的功能简介,特征是基于B/S的Web软件等;相关的参考文档有:图书管理系统的需求说明书、总体设计说明书、数据库设计说明书、详细设计说明书等。

2)测试目标:对测试目标进行简要的描述。制定被测软件的产品质量目标和软件测试目标。如图书馆管理系统测试目标是各项功能可靠实现,在系统的安全性方面和性能方面满足用户需求等。

3)测试范围和优先级:指出需要测试的范围,哪些需要重点测试、哪些无需测试、无法测试或推迟测试。测试的范围包括文档和软件系统,如文档有图书管理系统需求说明书、总体设计说明书、数据库设计说明书、详细设计说明书;软件各功能模块,重点需要测试的是系统需求说明书、图书管理模块、读者管理模块、借还书模块。

4)重点事项:列出需要被测软件的所有主要功能和测试重点。如图书管理系统的主要功能是:管理员能够对图书信息、读者信息进行添加(单项数据和批量数据进行添加)、删除、修改,可以实现借还书的操作,添加管理员和设置管理员权限、密码等;对于读者来说可以通过校园网内任意一台客户机查询图书信息和个人借书情况。对图书信息、读者信息进行添加(单项数据和批量数据添加)、删除、修改,可以实现借还书的操作是测试的重点。

5)资源需求:指测试所需要的软硬件、测试工具、必要的技术资源、培训和文档等。

6)人员组织:需要多少人进行测试,各自的角色和责任,他们是否需要进行相关的学习和培训,什么时候他们需要开始,并将持续多长时间。

7)测试策略:制定测试整体策略、所使用的测试技术和方法。本系统采用的策略是:黑盒法--白盒法--黑盒法的循环过程。对逻辑结构复杂的模块采用白盒法;对于以输入、输出为主的模块,采用黑盒法测试以提高测试效率。鉴于本系统测试为基于web的系统测试,所以需额外测试系统在不同Windows操作系统下的浏览器端的显示是否正常以及进行安全性和可用性测试。因此在功能测试中需添加Cookies测试;性能测试中添加浏览速度测试以及安全性测试。

8)测试开始/完成/延迟/继续的标准:测试计划中每个阶段要明确表明测试开始、完成的标准,并且测试的输入、输出条件要清楚;某些时候,测试计划会因某种原因(如过多阻塞性的Bug)而导致延迟,需指出问题解决后测试继续测试的标准。

9)测试进度、任务和人员安排:制定详细的测试进度,并将测试工作合理分配给不同的测试人员,并注意先后顺序。对于长期大型的测试计划,可以使用里程碑表示进度的变化。

10)风险分析:需要考虑测试计划中可能的风险和解决方法。如由于系统压力测试和性能测试中只能模拟几百台计算机访问系统,对于上千人同时访问系统的情况不可知,只能在系统投入使用后,发现问题时进行完善。

11)发布提交:在按照测试计划进行测试后,提交需要交付的软件产品、测试案例、测试数据及相关文档等。图书管理系统测试完成后,需要提交软件测试报告、软件测试计划、测试案例、测试数据等相关文档和相应的图书馆管理系统软件。

测试计划的内容会因不同的项目以及项目的大小而有所不同,可以在上面的内容中进行相应的取舍。

4 测试计划制定的关注点

制定一份切实可行的软件测试计划,需要关注以下几个方面:

4.1 计划尽早开始和测试阶段划分

就通常软件项目而言,基本上采用“瀑布型”开发方式,这种开发方式下,各个项目主要活动比较清晰,易于操作。整个软件生命周期为“需求-设计-编码-测试-发布-实施-维护”。然而,将制定测试计划和测试工作全部放入生命周期的“测试阶段”,这样造成的问题是浪费了开发阶段可以并行的项目日程。合理的测试阶段应遵循下面划分方法:在项目的需求分析阶段就开始制定测试计划,并在设计和编码阶段不断完善测试计划,而测试设计也可以结合在开发过程中实现并行,执行测试的活动贯穿整个开发过程中。

4.2 坚持“5W+H”规则[6],明确内容与过程

“5W”规则指的是“What(测试哪些方面,不同阶段的工作内容)”、“Why(为什么要进行这些测试)”、“When(测试不同阶段的起止时间)”、“Where(相应文档,缺陷的存放位置,测试环境等)”、“who(项目有关人员组成,安排哪些测试人员进行哪些测试)”、“How(如何去做,使用哪些测试工具以及测试方法进行测试)”。利用“5W+H”规则创建软件测试计划,明确测试的目标,在需要测试的内容里并突出关键部分,可以列出关键及风险内容、属性、场景或者测试技术。对测试过程的阶段划分、文档管理、缺陷管理、进度管理给出切实可行的方法。

4.3 明确标准

测试计划是指导测试人员进行测试的,而且测试工作往往是多人参与,因此必须指明各种标准,这些标准主要包括:

1)接受测试标准:指开发组完成相应的文档和程序后,送测试组测试时,测试组接受的标准,如果不满足此标准则拒绝测试。

2)测试开始/停止的标准:在制定测试策略时,对每一个测试项目要明确指出该项测试的开始和停止标准。

3)命名标准:测试文档的命名标准,如测试用例文件名命名标准,测试用例编码标准等,如测试用例中的编号规则可以使用:功能名_界面名(每个字第一个汉语拼音大写)_编号。例如:借还书信息第一个用例,JH_TS_0001。

4.4 分别创建测试计划与测试详细规格、测试用例

编写软件测试计划要避免一种不良倾向是测试计划的“大而全”,无所不包,篇幅冗长,长篇大论,重点不突出,既浪费写作时间,也浪费测试人员的阅读时间。“大而全”的一个常见表现就是测试计划文档包含详细的测试技术指标、测试步骤和测试用例。最好的方法是把详细的测试技术指标包含到独立创建的测试详细规格文档中,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。

4.5 采用评审和更新机制,保证测试计划满足实际需求

测试计划包含多方面的内容,编写人员可能受自身测试经验和对软件需求的理解所限,而且软件开发是一个渐进的过程,所以最初创建的测试计划可能是不完善的、需要更新的。需要采取相应的评审机制对测试计划的完整性、正确性、可行性进行评估。例如,在创建完测试计划后,提交到由项目经理、开发经理、测试经理、市场经理等组成的评审委员会审阅,根据审阅意见和建议进行修正和更新。

5 结束语

好的测试计划是成功的一半,另一半是对测试计划的执行。对小项目而言,一份更易于操作的测试计划更为实用,对中型乃至大型项目来看,测试经理的测试管理能力就显得格外重要,要确保计划不折不扣的执行下去,测试经理的人际谐调能力,项目测试的操作经验、公司的质量现状都能够对项目测试产生影响。另外,计划也是“动态的”,是紧追项目的变化,实时进行思考和贯彻,根据现实修改,一份切实可行的测试计划再加上成功实施,才能实现测试计划的最终目标--保证软件项目最终产品的质量。

摘要：讨论了软件测试过程中编写测试计划这一环节,指出了测试计划的任务和作用,并通过图书管理系统这一项目,说明了测试计划包含的内容,并总结出测试计划制定时的关注点。

关键词：测试计划,软件测试,计划制定

参考文献

[1]Patton R.软件测试[M].张小松,译.北京:机械工业出版社,2007:177-186.

[2]软件测试网.做好测试计划和测试用例的工作的关键是什么-[EB/OL].http://www.51testing.com/-action-viewnews-itemid-84567.html.

[3]夏雪刚,卢顺利,支高英.图书管理系统相关文档[D].陕西:宝鸡文理学院,2003.

[4]张靖,贲可荣,罗云锋.软件测试研究综述[J].武汉:计算机与数字工程,2008(10).

[5]Perry W E.软件测试的有效方法[M].高猛,译.北京:清华大学出版社,2008:151-207.

[6]测试时代网.如何编写软件测试计划[EB/OL].http://www.testage.net/html/71/n-156071-2.html.

[7]陈霖,张瑞.软件测试的风险管理[J].湖北武汉:计算机与数字工程,2008(6).

测试的工作计划 第4篇

关键字：工作过程 软件测试 课程开发

【中图分类号】TP311.53-4

一、工作过程导向的课程开发方法

工作过程是在企业中为完成特定的工作任务并获得工作成果而实施的完整的工作程序。基于工作过程的课程，应以企业的实际工作内容作为课程内容的组织范围、以工作过程为课程内容的组织逻辑、以完成工作任务为课程目标、以工作过程的行动导向为课程的实施原则。确保教学领域与实际应用领域吻合；教学过程与实际工作过程吻合；教学任务与实际工作任务吻合。基于工作过程的课程内容以受众对象为中心，注重通过直接经验的形成来掌握蕴含于工作过程中的知识、技能和技巧。

基于工作过程的课程的设计，是以工作过程为主线，提炼出由实践情景构成的过程逻辑，让教学课程的过程成为基本符合企业的实际工作过程的过程。课程设计时，要遵循由浅到深，由易到难，由单一技能到综合技能的认知规律。由生疏到熟练，由新手到专家的职业成长规律。图1是我国学者在研究国内外职业教育的工作过程导向的实践与理论成果的基础上提出的课程模式，我们在此模式的基础上探讨工作过程导向的具体开发方法。

工作过程系统化课程模式，是一个二维矩阵，纵向是学习领域，每一个领域都是一个完整的工作过程，学习领域是理论和实践的有机结合、遵循认知学习规律和成长规律的课程单元，一个学习领域对应一门课程，一个专业由若干学习领域组成，一个学习领域由一个或若干个学习情境组成。

横向是学习领域的学习情境，学习领域课程的教学内容，即案例化的主题学习单元。它把理论知识、实践技能与实际应用环境结合在一起，是学习领域这一宏观计划的具体化。它将学习领域中的目标表述和学习内容进行教学论和方法论的转换，构成在学习领域框架内的“小型”主题学习单元。学习情境可以表现为具体教学项目，在软件测试技术专业，教学项目多为测试一个应用软件，一个WEB系统等。

基于工作过程课程的开发可分解为如下几个流程；

工作任务分析：根据本专业对应的工作岗位及岗位群实施典型工作任务分析。

行动领域归纳：根据能力复杂程度整合典型工作任务形成综合能力领域

学习领域转换：根据认知及职业成长规律递进重构行动领域转换为课程

学习情境设计：根据完整思维及职业特征分解学习领域为主题学习单元

以上是基于工作过程导向的课程设计方法，接下来我们来针对高职院校软件专业的重要课程《软件测试》进行工作导向的设计。

二、软件测试的工作过程分解

1.获取，归纳，整合实际软件测试工作中的典型工作任务

通常在企业中，普通测试人员的主要工作任务是依据测试用例，设计测试数据，实施测试，取得测试结果，进行测试结果的检证，进行缺陷报告，回归测试等；高级测试人员的主要工作是，依据测试计划，方针，设计测试用例，指导普通测试人员进行测试，进行缺陷跟踪，进行测试的评审等；测试管理人员（如：测试经理）的主要工作是，依据项目整体计划，特别是质量计划，制定测试计划，测试方针，进行测试管理，分析测试结果，质量评估等。

另外，某些情况下还要进行测试开发，如：用JUNIT对JAVA类进行测试时，要进行JUNIT测试代码的开发；测试环境的搭建；自动化测试设计、实施等。

由此，我们可以将实际企业中的软件测试工作，归納，整合为如下几个工作任务：测试项目管理、测试计划、测试设计、测试准备，测试实施、测试报告、缺陷跟踪、测试评审、测试评估。

2.分类，排序典型工作任务

按照上面阐述的认知规律和职业成长规律，按照由简单到复杂，由单一技能到综合技能；由新手到专家的规律，把通过软件测试人员职业分析得到的典型工作任务分类，筛选，排序将客观的工作任务，同时也是学习任务按照一定的主观标准进行了系统化的处理。上面的典型工作任务中，我们将测试准备、测试实施、测试报告划分到基础级别的软件测试工作任务；将测试设计、测试跟踪、测试评审划分到高级级别的软件测试工作任务；将测试项目管理、测试计划、测试评价划分到管理级别的软件测试工作任务。

3.确定学习领域

依据上面典型工作任务的分析结果，我们为软件测试课程设计三个学习领域，即：基础软件测试、高级软件测试、软件测试管理。培养符合企业需求的软件测试实施人员是本课程的主要课程目标。所以，将基础软件测试和高级软件测试作为本课程的重点。其中，不同的企业、不同的项目对测试准备和测试评审的要求和作业内容也不尽相同，行业也没有统一的标准，所以我们介绍较为常见的作业内容，学生也只需了解该部分内容即可。这样可以得出各学习领域的内容和要求，如表1所示：

三、《软件测试》课程教学实践

《软件测试》本身是理论与实践紧密结合的一门技术性课程，笔者所在院系的此课程共128课时，共计8学分。根据工作工程导向的设计结果，结合实际教学实践，为每个学习情境分配具体课时，如表4所示。

测试员的工作计划 第5篇

1、协调好软件测试工程师与测试员之间的工作关系

2、对不同的项目进行优先评级，合理分配人力资源。

二、目的：

更好的协助软件测试工程师，按时甚至时提前完成测试项目。

三、工作计划

一、协助测试员的导师，帮助刚入职的测试员进行工作环境和工作内容，工作规范，规章制度的熟悉。

二、帮助刚入职的测试员把测试时必须用的耳机， USB线，下载线，T卡，充电器，SIM卡，备齐。

三、分配测试项目

1、测试员分配测试项目的原则

(1)按照项目的优先等级进行分配

(2)按照测试能力进行分配

(3)按照对不同平台的熟悉程度进行分配

2、测试工程师提交协助测试项目的原则

(1)以书面形式，提前一天，特殊情况可提前半天，提交协助测试申请。内容包括：现在正在负责测试项目的个数，协助测试项目的进度安排，预计占用测试员的天数。

(2)以口头或者是书面的形式，告知测试项目的修改内容和测试重点。

(3)原则上测试员手上都有项目的话，将不在接手新项目，重点紧急项目可例外。

四、测试员的日常管理

1、与测试员进行交流与沟通，对工作中遇到的问题与困难能帮助解决的尽量帮助解决，自己不能解决的请教他人与于帮助解决。

2、监督测试员的日常工作，对工作中的错误与于指正。

3、每周提交周工作总结表(见附件)，每月提交月工作总结表

原则上：周工作总结表，每周五五点半开始填写，六点之前上交

测试的工作计划 第6篇

窗口与窗口之间的调用情况；

窗口尺寸变化时窗口中控件能否自适应；

多个窗口同时打开和调用的情况；

窗口拖动是否正常；

主窗口和子窗口调用能否正常处理；

窗口能否根据浏览器大小进行缩放【双击浏览器、浏览器最大化、最小化和还原查看窗口的变化情况】；

窗口显示标题是否正确。

2.工具条测试主要测试内容如下：

工具条能否正常显示；

工具条能否隐藏；

可移动工具条在窗口中间位置其形状是否正确；

工具栏上工具按钮功能是否能正常实现；

工具按钮显示是否正确、友好、醒目易懂；

工具栏上的工具按钮是否有鼠标悬停提示；

工具栏上的工具按钮是否可以任意定制；

是否有输入框；

是否有个人用工具条；

是否有网站型工具条；

是否有专项型工具条；

是否有企业型工具条。

3.工具条测试主要测试内容如下：

输入正常的字母或数字；

输入已存在的文件的名称；

输入超长字符，例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入 256个字符，检查程序能否正确处理；

输入默认值，空白，空格；

若只允许输入字母，尝试输入数字；反之；尝试输入字母；

利用复制，粘贴等操作强制输入程序不允许的输入数据；

输入特殊字符集，例如，NUL及n等；

输入特殊字符集，例如，NUL及n等；

输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示；

输入非法数据；

输入默认值；

输入特殊字符集；

输入使缓冲区溢出的数据；

输入相同的文件名；

输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示。4.菜单测试主要测试内容如下：

菜单项是否符合需求，能否正常工作，是否与实际执行的内容一致；

菜单措辞是否准确；

菜单位置及顺序是否合理；

菜单图形布局是否一致；

下拉菜单是否根据选项含义进行分组；

菜单的热键、快捷键能否有效使用和重复；

帮助菜单的“关于”中应有版权和产品信息；

界面菜单公司信息和产品信息显示是否正确。5.页面布局测试主要测试内容如下：

页面布局是否根据分辨率大小自动调整；

页面长宽比例合理是否合适；

界面风格要一致；

背景色彩搭配要协调。6.图标测试主要测试内容如下：

是否符合表达习惯；

不同目标是否采用不同图标；

图标尺寸是否合适；

图标是否有标注，包括公司图标和产品图标。7.界面按钮测试主要测试内容如下：

按钮位置是否合适，是否有正常响应，是否有相应的匹配按钮如：按钮；

单选框和复选框按钮的测试；

功能按钮图标上或在鼠标经过时是否给予正确提示信息。8.时间控件测试主要测试内容如下：

时间年月日选择（开始时间不可大于结束时间）；

时间有效期；

时间年月日显示是否正确；

时间查询。

9.界面文字测试主要测试内容如下：

界面文字描述是否准确，无异议；

文字大小是否合适（一般9-12号）；

是否出现中英文混合；

界面文字是否可根据浏览器的编码方式自适应。10.界面信息提示测试主要测试内容如下：

提示信息是否具有可理解性的语言描述；

对重要、具有破坏性的操作命令是否有确认信息；

提示信息是否具有统一的标记和标准；

提示信息不易过长。

11.鼠标和快捷键测试主要测试内容如下：

是否支持滑轮；

鼠标点击右键是否显示菜单，取消右键是否隐藏；

无规则点动鼠标，查看界面的响应；

经过键盘或鼠标复制粘贴；

支持快捷键使用；

支持键盘自动浏览按钮（Tab键、Enter键）。

测试：你适合的工作型态 第7篇

你适合当老板。领导力极佳的你天生最适合担任主管、总经理甚至是老板的工作。只是除非你是含着金汤匙出身，否则这类的机会对你是可遇而不可求。你也很容易在还没爬到这个位置之前就放弃了。成功绝非偶然，脚踏实地才是致富之道。

选择D的人

你适合从事创意类的工作，也习惯以一技之长来闯天下。只是你虽身怀绝技，却总是无法营销自己，为自己找到出路而使生活产生困难。戴晨志说：困难就是困在家里万事难、出路就是出去走走就有路。广结善缘，累积人脉，借力使力你才能成功。

选择E的人

你希望生活平静，能够有个稳定的工作环境，除了上班之外，剩下的就是你的时间;所以，一般朝九晚五类的工作也最适合你。这样的工作也是最多，你可以依照兴趣去选择你想要的。只是，也要让自己能时时学习，才不会因为突发状况而面临失业。

论软件测试计划的成功制定 第8篇

关键词：测试计划,变更,测试资源配置,问题跟踪报告

0 引言

软件测试是一个极为复杂的过程。一个规范化的软件测试过程通常须包括以下基本的测试活动：拟定软件测试计划、编制软件测试大纲、设计和生成测试用例、实施测试、生成软件问题报告。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是独立的，但是必定要有一个起到框架结构作用的测试计划。测试计划应该作为测试的起始步骤和重要环节。在越来越多公司的软件开发中，软件质量日益受到重视，测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中。这样，如何规划整个项目周期的测试工作；如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。测试计划因此成为测试工作展开的基础。

一个好的测试计划可以起到如下作用：首先避免测试的“事件驱动”，其次使测试工作和整个开发工作融合起来，最后资源和变更事先作为一个可控制的风险。

测试计划的模板在各个公司中都大同小异，在个人的实践中发现，测试计划制定中存在的问题具有相似性，下面就这些相似的问题谈谈如何制定软件项目测试计划。

1 测试阶段划分

就通常软件项目而言，基本上采用“瀑布模型”开发方式，这种开发方式下，各个项目主要活动比较清晰，易于操作。整个项目生命周期为“需求-设计-编码-测试-发布-实施-维护”。然而，在制定测试计划时候，有些测试经理对测试的阶段划分还不是十分明晰，经常性遇到的问题是把测试单纯理解成系统测试，或者把各类型测试设计（测试用例的编写和测试数据准备）全部放入生命周期的“测试阶段”，这样造成的问题是浪费了开发阶段可以并行的项目日程，另一方面造成测试不足。

合理的测试阶段应遵循下面划分方法：

照上图所述，相应阶段可以同步进行相应的测试计划编制，而测试设计也可以结合在开发过程中实现并行，测试的实施即执行测试的活动即可连贯在开发之后。值得注意的是：单元测试和集成测试往往由开发人员承担，因此这部分的阶段划分可能会安排在开发计划而不是测试计划中。

2 系统测试阶段日程安排

划分阶段清楚了，随之而来的问题是测试执行需要多长的时间？标准的工程方法或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个月工作量。值得注意的是：国内大多数公司的测试时间都是不足的，不可能按照这样的理想比例进行运作，因为测试执行的时间实际上不可能占据整个项目周期的1/2，甚至要短于其中任何一个项目阶段时间。在测试时间不足的情况下，可参考下面项目计划变更时的做法，因为计划变更也涉及到测试时间不足的情况。

3 变更的控制

测试计划改变了已往根据任务进行测试的方式，因此，为使测试计划得到贯彻和落实，测试组人员必须及时跟踪软件开发的过程，对产品提交测试做准备，测试计划的目的，本身就是强调按规划的测试战略进行测试，淘汰以任务为主的临时性。在这种情况下，测试计划中强调对变更的控制显得尤为重要。

变更来源于以下几个方面：(1)项目计划的变更；(2)需求的变更；(3)测试产品版本的变更；(4)测试资源的变更。

测试阶段的风险主要是对上述变更所造成的不确定性，有效地应对这些变更就能降低风险发生的几率。要想计划本身不成为空谈和空白无用的纸质文档，对不确定因素的预见和事先防范必须做到心中有数。

对于项目计划的变更，除了测试人员及时跟进项目以外，项目经理必须认识到测试组也是项目成员，因此必须把这些变更信息及时通知到项目组，使得整个项目得到顺延。项目计划变更一般涉及都是日程变更，令人遗憾的是，往往为了进度的原因，交付期限是既定的，项目经理不得不减少测试的时间，这样，执行测试的时间就被压缩了。由于时间不足，不能“完美”的执行所有测试，为了保证质量，第一种办法是调整测试计划中的测试策略和测试范围。调整的目的是重新检查不重要的测试部分，调换测试的次序和减少测试规模，对测试类型重新组合择优，力求在限定时间内做最重要部分的测试，可以把忽略部分留给确认测试或现场测试。其他应对办法包括减少进入测试的阻力，例如降低测试计划中系统测试准入准则；分步提交测试，例如改成迭代方式增量测试；减少回归测试的要求，例如开发人员实时修改，在测试计划中对缺陷修复响应时间和过程进行约定；简化配置管理，跳过正式发布环节；缺陷进行局部回归而不是重新全部测试等等。

项目进行过程中最不可避免的就是需求的变更。因此，制定计划时，如果项目需求处于动态变化时，在测试用例章节就要进行说明。许多测试经理在编制测试用例时往往没有把测试用例和测试数据进行区分，因而造成的问题是当需求变化时辛苦设计的数据就作废了。在这时，假使面临一个需求动态的项目，必须在计划中对需求变更造成的测试（设计）方式变化进行说明，例如采用用例和数据分离、流程和界面分离、字典项和数据元素分离的设计方式，然后等到最终需求确定后细化测试设计；另一个方面是最好制定一个变更周期的约定，尤其在执行测试阶段发现需求的变更，定义变更的最大频度和重新测试的界限，计划从一定程度上能够降低不可预期需求变化造成的投入损失。值得注意的是：需求发生变更时测试经理额外的工作是记住要在需求跟踪矩阵上做记录。

对于测试产品版本的变更，除了部分是由于需求变更造成之外，很有可能是由于修改缺陷引发的问题或配置管理不严格造成。众所周知，测试必须是基于一个稳定的“基线”进行，否则，因反复修改造成测试资源和开发资源的浪费是可观的。合理的测试计划在章节中应增加一个测试更新管理的章节，在此章节明确更新周期和暂停测试的原则。例如，小版本的产品更新不能大于每天三次，一个相对大的版本不能每周大于1次，规定紧急发布产品仅限于何种类型的修改或变更，由谁负责统一维护和同步更新测试环境。测试计划通常制定了准入和准出准则，这是不够的，要考虑测试暂停的时候，产品错误发布或者服务器数据更新就是一个例子，暂停的时候如果测试经理不进行跟踪，可能发生测试组等待测试而没人通知继续测试的情况，所以，增加更新周期和暂停测试原则是很有必要的。

最后，测试资源的变更是源自测试组内部的风险而非开发组风险，当测试资源不足或者冲突，测试部门不可能安排如此多的人手和足够时间参与测试时，在测试计划中的控制方法与测试时间不足相类似。没有测试经理愿意承担资源不足的测试工作，只能说公司本身是否具备以质量为主的体系或者项目经理对产品质量的重视程度如何决定了对测试资源投入的大小，最终产品质量取决因素不仅仅在于测试经理。为了排除这种风险，除了象时间不足、测试计划变更时那样缩减测试规模等等方法以外，测试经理必须在人力资源和测试环境一栏标出明确需要保证的资源，否则，必须将这个问题作为风险记录。

当然，要制定一个成功的软件项目测试计划除了做到上述之外，在实际中还应做好以下几方面：产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、问题跟踪报告、测试计划的评审、结果等等。

产品基本情况调研。这部分应包括产品的一些基本情况介绍，例如：产品的运行平台和应用的领域，产品的特点和主要的功能模块，产品的特点等。对于大的测试项目，还要包括测试的目的和侧重点。目的重点描述如何使测试建立在客观的基础上，定义测试的策略，测试的配置，粗略的估计测试大致需要的周期和最终测试报告递交的时间。技术结构可以借助画图，将要测试的软件划分成几个组成部分，规划成一个适用于测试的完整的系统，包括数据是如何存储的，如何传递的（数据流图），每一个部分的测试是要达到什么样的目的。每一个部分是怎么实现数据更新的。还有就是常规性的技术要求，比如运行平台、需要什么样的数据库等等。产品规格就是制造商和产品版本号的说明。测试范围能简单的描述如何搭建测试平台以及测试潜在的风险。项目信息说明要测试项目的相关资料，如：用户文档，产品描述，主要功能的举例说明。

测试需求说明。这一部分要列出所有要测试的功能项，凡是没有出现在这个清单里的功能项都排除在测试的范围之外。功能的测试理论上是测试是要覆盖所有的功能项，例如：在数据库中添加、编辑、删除记录等等，这会是一个浩大的工程，但是有利于测试的完整性。设计的测试即对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。整体考虑这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性。

测试的策略和记录。这是整个测试计划的重点所在，要描述如何公正客观地开展测试。公正性声明要对测试的公正性、遵照的标准做一个说明，证明测试是客观的，整体上，软件功能要满足需求，实现正确，和用户文档的描述保持一致。测试案例描述测试案例是什么样的，采用了什么工具，工具的来源是什么，如何执行的，用了什么样的数据。测试的记录中要为将来的回归测试留有余地，当然，也要考虑同时安装的别的软件对正在测试的软件会造成的影响。需特殊考虑有的时候，针对一些外界环境的影响，要对软件进行一些特殊方面的测试。经验判断即对以往的测试中，经常出现的问题加以考虑。设想即采取一些发散性的思维，往往能帮助你找的测试的新途径。

测试资源配置。主要指项目资源计划，制定一个项目资源计划，包含的是每一个阶段的任务、所需要的资源，当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。

问题跟踪报告。在测试的计划阶段，我们应该明确如何准备去做一个问题报告以及如何去界定一个问题的性质，问题报告要包括问题的发现者和修改者、问题发生的频率、用了什么样的测试案例测出该问题的，以及明确问题产生时的测试环境。问题描述尽可能是定量的，分门别类的列举。

测试计划的评审。又叫测试规范的评审，在测试真正实施开展之前必须要认真负责的检查一遍，获得整个测试部门人员的认同，包括部门的负责人的同意和签字。

4 结论

尽管上面尽可能的描述了测试计划如何制定才能“完美”，但是还存在的问题是对测试计划的管理和监控。一份计划投入再多的时间去做也不能保证按照这份计划进行实施。好的测试计划是成功的一半，另一半是对测试计划的执行。对小项目而言，一份更易于操作的测试计划更为实用，对中型乃至大型项目来看，测试经理的测试管理能力就显得格外重要，要确保计划不折不扣的执行下去，测试经理的人际谐调能力，项目测试的操作经验、公司的质量现状都能够对项目测试产生足够的影响。另外，计划也是“动态的”，不必要把所有的因素都可能囊括进去，也不必要针对这种变化额外制定“计划的计划”，测试计划制定不能在项目开始后束之高阁，而是紧追项目的变化，实时进行思考和贯彻，根据现实修改，然后成功实施，这才能实现测试计划的最终目标，即保证项目最终产品的质量。

参考文献

[1]倪子伟.软件开发过程[M].北京:高等教育出版社,2004.

[2]刘怀亮,相洪贵.软件质量保证与测试[M].北京:冶金工业出版社,2007.

[3]论软件测试计划的制定[EB/OL].http://www.javaeye.com/topic/356143,2009年3月.