如何制定成功的测试计划 o燫�
���
ixu5輈跥^
不错的文章，推荐大家看看。 w 鱘L,罇M^
-------------------------------------- �:啜稲
如何制定成功的测试计划 a寓�AUC
J媊ㄆ��k硝
“工欲善其事，必先利其器”。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是独立的，但是必定要有一个起到框架结构作用的测试计划。测试的计划应该作为测试的起始步骤和重要环节。一个测试计划应包括：产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。 禺^L寰ぱ閡
锿@@掊O芐Z
产品基本情况调研：
欘 n鞼cＪ
疺1束Z蜿拱
这部分应包括产品的一些基本情况介绍，例如：产品的运行平台和应用的领域，产品的特点和主要的功能模块，产品的特点等。对于大的测试项目，还要包括测试的目的和侧重点。 y��,盬厚
dF駥X�/�
具体的要点有： 鑏� 鎌懸A
S�灶&a痨
目的：重点描述如何使测试建立在客观的基础上，定义测试的策略，测试的配置， 粗略的估计测试大致需要的周期和最终测试报告递交的时间。 m郎Fz/絀�
蕓v遝1k鴏
变更：说明有可能会导致测试计划变更的事件。包括测试工具改进了，测试的环境改变了，或者是添加了新的功能。 勚９�*g 貍
帘縤嫩"LvD
技术结构：可以借助画图，将要测试的软件划分成几个组成部分，规划成一个适用于测试的完整的系统，包括数据是如何存储的，如何传递的（数据流图），每一个部分的测试是要达到什么样的目的。每一个部分是怎么实现数据更新的。还有就是常规性的技术要求，比如运行平台、需要什么样的数据库等等。 JSH �L�
\� +l
产品规格：就是制造商和产品版本号的说明。 獕�*�q
膙W#v�
测试范围：简单的描述如何搭建测试平台以及测试的潜在的风险。 U Ld⒍覠
驭\.G繇
项目信息：说明要测试的项目的相关资料，如：用户文档，产品描述，主要功能的举例说明。 懋xs撩jLA�
-).{咢j<
测试需求说明：
4ク{TZ
;M胤�
sˊ6
这一部分要列出所有要测试的功能项。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。万一有一天你在一个没有测试的部分里发现了一个问题，你应该很高兴你有这个记录在案的文档，可以证明你测了什么没测什么。具体要点有： �8+:T�"
� F捒g
功能的测试：理论上是测试是要覆盖所有的功能项，例如：在数据库中添加、编辑、删除记录等等，这会是一个浩大的工程，但是有利于测试的完整性。 昊*蔷�騮
|0铠谪妔撔
设计的测试：对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。 �/俦PHaH鮚
N�=笌 iP�
整体考虑：这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性。 re殯�0r+
?L7 坩綯�'
测试的策略和记录： H艢~J~y賬
製h洸m�=鲀
这是整个测试计划的重点所在，要描述如何公正客观地开展测试，要考虑：模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响。要尽可能的考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备，测试记录重要包括的部分具体说明如下： jJ舃
樊鷄d�KW
公正性声明：要对测试的公正性、遵照的标准做一个说明，证明测试是客观的，整体上，软件功能要满足需求，实现正确，和用户文档的描述保持一致。 詣-�
伦謁G
虂噒卌$jH
测试案例：描述测试案例是什么样的，采用了什么工具，工具的来源是什么，如何执行的，用了什么样的数据。测试的记录中要为将来的回归测试留有余地，当然，也要考虑同时安装的别的软件对正在测试的软件会造成的影响。 '義St*
n,嵐玅琱;�
特殊考虑：有的时候，针对一些外界环境的影响，要对软件进行一些特殊方面的测试。 ]詢o著1R碣
�1薏乑褝眗
经验判断：对以往的测试中，经常出现的问题加以考虑。 2竖﹜ [��
?悝v蛤h�
设想：采取一些发散性的思维，往往能帮助你找的测试的新途径。 \痴�
蔉J�
� ��
8
测试资源配置： �&*鰝鴎漇
��螟-�
项目资源计划：制定一个项目资源计划，包含的是每一个阶段的任务、所需要的资源，当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。 漾鵨≯薇�
�18檞u�
�
计划表： t6 廝瘉鍭
⑾ 佴B昽黅
测试的计划表可以做成一个多个项目通用的形式，根据大致的时间估计来制作，操作流程要以软件测试的常规周期作为参考，也可以是根据什么时候应该测试哪一个模块来制定。 [姎�.5s欩�
詞�0洡 <
问题跟踪报告： S魢祘�
鄫
_X{T稌�
在测试的计划阶段，我们应该明确如何准备去做一个问题报告以及如何去界定一个问题的性质，问题报告要包括问题的发现者和修改者、问题发生的频率、用了什么样的测试案例测出该问题的，以及明确问题产生时的测试环境。 病7�枏{`
鯢,H>贗�&
问题描述尽可能是定量的，分门别类的列举，问题有几种： O葉譜咙�
屔�/� D;�
1、严重问题：严重问题意味着功能不可用，或者是权限限制方面的失误等等，也可能是某个地方的改变造成了别的地方的问题。 vP⒀�/橦�
F�O族 ｖ�
2、一般问题：功能没有按设计要求实现或者是一些界面交互的实现不正确。 鲥仭按訉肕
j技h臜�
3、建议问题：功能运行得不象要求的那么快，或者不符合某些约定俗成的习惯，但不影响系统的性能，界面先是错误，格式不对，含义模糊混淆的提示信息等等。 緖"#)AD]o
.閥j'
熙\
测试计划的评审： =邀￢�Y�1
w�2鱯拧z;p
又叫测试规范的评审，在测试真正实施开展之前必须要认真负责的检查一遍，获得整个测试部门人员的认同，包括部门的负责人的同意和签字。 碎餉踗Q t�
晣募 枳玅.
结果： y蓻鋇妃�&
E躢&k杉
计划并不是到这里就结束了，在最后测试结果的评审中，必须要严格验证计划和实际的执行是不是有偏差，体现在最终报告的内容是否和测试的计划保持一致，然后，就可以开始着手制作下一个测试计划了。
