软件测试文档标准1998：测试计划

根据IEEE Std.829-1998(软件测试文档标准1998年修订版)来介绍测试计划的内容 
1.测试计划标题 
就是说没个测试计划和每个测试计划的版本都应该有一个公司内部的独一无二标示，这也是文档控制和版本控制的基本要求，我觉得在正规公司的同仁们都应该明白。 
2.介绍 
这一部分适度测试的一个总的概括，通过这一部分一该让读者明白此项目的准确目标和测试组如何达到这些目标。根据情况也可以做一些基本概念的解释，比如为什么要做安全测试等等。 
3项目范围 
在这一部分中明确项目的测试目标，如果在介绍中已经描述的测试目标的话在这一部分应该详尽的介绍测试目标。同时在这一部分可以列出在测试中不设计的测试项。 
4变动控制过程 
这一部分主要是解决再测试中如果有需要变动的测试项应做如何处理，可参考CCB(变动控制委员会)的意见进行适当的变动。 
5待测的特性（还没吃饭呢，同志们现在不写了好吗，等明天在写吧，好了写玩这一部分！坚持） 
这一部分应该是对测试对象的描述，测试组应该对则是对象进行研究，对测试对象进行可行性检查。因该根据具体情况对测试项进行删改，比如：应该确定是否有足够的时间和资金来测试每一样特性。测试组极有可能没有得到想要的足够资源，在这种情况下，必须做出决定应重点测试哪些方面，而那些方面可以相对简单。达成这一点的方式是使用风险分析。（好了不行了，饿晕了，等有时间在写吧）未完待续 
6不测的特性 
这一部分主要说明因为测试项目多，可能测试的过程中有的重要的测是项目可能会被忽略。“因为在测试计划的各自测试范围拼合的不是很紧密，可能出现系统的某个特性就完全没有测试，因为企业里的每个人都以为其他人会测试系统的这个方面。”解决的办法就是：不仅在某个测试计划中记录下什么项将被测试，也纪录下这些项的哪些方面将会测试而那些将是在测试计划范围之外的。从而明确澄清各个测试计划的范围会涉及到什么和不涉及什么。一句话就是在测试计划重要把这些都确定下来，不能含糊不清。 
7方法 
测试计划的这部分一般用来阐明测试组达成选前确定的测试目标所用的策略。无需深入到每个测试策略决定的详尽细节。但是应该明确主要的决定。例如：将执行什么层级的测试和在系统生命周期内何时执行测试。下面对一些概念进行介绍： 
1） 测试的层级 
测试分为多测试阶段（或测试层）的一个策略是按照某个测试可运行前系统必须完成的测试程度来划分测试。比如一个测试可以分为单元测试（在系统一个组件上单独进行的测试也可称为模块测试。  ）、整合级、串级或连级测试（设计用来测试系统的两个或个多组件见的通信的测试。）、系统测试等。 根据测试的具体情况将一个或几个层写到一个测试计划中。 
2） 何时测试 
这一部分解决测试应该在何时进行，反对以前的那种当软件设计完成后才进行的安全测试，软件测试应该贯穿整个软件开发周期。 
3） 何时再测试 
这个概念是说只要系统在运行安全测试就应该不断地进行测试，测试的频率由执行这些测试的资源的可用性及系统随时间变动的程度来决定。因为系统完成开发运行后可能出现新的安全隐患如：以前所用的操作系统的一个未知的漏洞现在被黑客团体知道了；系统增加了一些复述设备（防火墙，服务器，路由器）以使之符合更高的使用要求等等。 
4） 再测试什么 
这里的再测试就是软件测试中的回归测试，测试在前期测试过程中出现的bug是否已经修复。测试是否出现新的安全风险等等。 
 8通过/未通过的标准 
 在安全测试中通过/未同过的结果比较难下，建议在测试之前先对测试的预期结果过进行文档化操作。最好这个结果应该由负责做出决策的人来定，而不是测试组，测试组需要做的应该是如何把测试成果提交给负责做出决策的人。（建议测试组提交一份通过测试结果评估出来的系统运行后可能出现的安全风险的报告，而不是自动化检测工具检测出来的安全漏洞的列表）。如果必须有测试组指明通过不同过的标准最好用这样的标示方法：“有信息安全经理决定网站中全部探测到的/或严重部分是否需要返工或再测试”而不应该用“通过95%的测试用例系统可视为系统通过” 
9暂停标准或重测 
测试计划这一部分可用来标明在何种情况下可以谨慎的暂停整个（或部分）测试工作及因此要达到什么样要求才能恢复暂停测试。例如：建议在主要网站服务器上的操作系统计划要安装最新的补丁包之前，不要运行渗透性测试。相反如果暂停等到服务器上的操作系统安装了最新的补丁，并重新进行了配置，就可以重新进行测试了。 
10测试交付物 
在这一部分应该记录在安全测试工作中应该交付的测试结果文 件。在安全测试结果中应该交付如下这些文件 
1） 测试日志 
以时间顺序记录测试执行中发生的事件。 
2） 测试事件报告  
测试事件报告是在测试过程中出现的一些问题的报告，比如测试过中重出现的一些系统的错误信息等等，在测试过程中可以由测试成员以观察报告的形式记录下来，由最终出报告的人来进行分析。 
3） 漏洞追查报告  
就是用自动化工具检查出来的漏洞结果。 
4） 度量 
就是衡量一个事物的单位，比如每天出现15个漏洞等等。 
5） 测试总结报告 
就是总结在测试工作中所找到的一切东西。 
11环境需求 
在测试计划的这一部分主要描述测试所需要的环境。和在环境中需要一些什么设施。 
12配置管理 
配置管理是及时的以离散点标识（什么）、控制（库管理）、追查（谁和何时）和报告（谁需要知道）系统组件的过程，其主要目的是为了维护系统的完整性。 
13责任 
在测试计划中这一部分主要是确定，某些事情应该由谁来负责协调，或某些人应该负责什么等。就是说在这一部分应该确定部门责任。如公司层 负责镜网站的物理安全评估；部门层：负责安装配置测试环境等等。 
14提供人员和培训需要 
测试计划在这一部分要求计划制定者考虑自己测试组的能力，如果需要可以进行人员培训计划。 
15测试进度 
在测试计划的这一部分主要是制定测试每一个阶段需要花费的时间，进度控制等。对于打得测试项目可以考虑单独的作为一个文档来做这个测试进度可以应用一种进度控制工具（Easy Schedule Maker等）进行管理，进度的细节可以在其他的计划文档中详细描述。 
16预计风险和应急措施 
在测试计划的这一部分应该有计划的制定者考虑到在测试中可能遇到的风险，以及遇到这种风险的解决办法，以条款的形式列出。做一个风险百分比图，通过这个图可以知道在测试中什么风险占的比例最大，再测试中应该进行避免这种风险的出现。 
17审批 
在测试计划这一部分就是确定评审组的成员，既由那些人来评审你的测试计划，有哪些人来评审你的测文档等。可能不同的公司需要的评审程度不一样，根据自己公司的具体需要来定。但前面提到的粮店是必不可上的。