任何一个测试的开始都要制定一个完整的测试计划，现在我们就从web安全测试的测试计划开始
要做一个测试计划首先要明确测试需求。在写测试计划之前必须要明确测试需求，
暗含的要求：例如很少看到这样明确话的文档要求：“入侵这相应手册中不许友拼写错误”但同时有些组织是允许拼写错误存在的。这样暗含的要求我们就要明确，可以通过和主管部门或是用户沟通来明确这样的要求。
不完全的或模糊的要求
比如：“所有的网站都应该安装SP3补丁”这样的要求就是模糊不清的，因为没有指明是操作系统还是网站服务软件，或是某些具体的系统软件。这样的需求就应该有需求提出的人来明确，确定在什么系统上安装sp3补丁。
未指明的要求
如：“必须使用强密码”看起来还向没什么问题，但从测试观点看，设么是强密码呢？是常超过7个字符的，还是应该有大小写的。这样的要求我们就应该根据密码要求标准具体化，比如：要求密码加强必须大于7个字符。
笼统的要求
比如“站点必须是安全的”尽管每个人都会同意这个要求，但展点能够彻底安全的唯一方法就是，断开展点的所有连接，内网的外网的，然后锁在一个加了封条的屋子里。但是这并不是要求的本意。这样的要求应该具体化，制定要求达到的安全程度。
好了要求明确了，下面就说一下就话的结构。呵呵我也是学来的，照别人的说吧，也有我的体会
测试计划的结构
测试计划可以依照工业标准（例如软件文档标准——Std.829）组织，也可以基于内部摸版，甚至可以用创献礼的全新个是编排。但大家一定要注意一点，测试计划重要的不是个是而是创建测试计划的过程一定要获得测试组的认可。但有的测试必须用规格的测试计划格式，行业内部摸版或行业标准，这样的测试如：政府机构、保险承销商等。
测试计划可以长达几百页，也可以简单的只有一张纸，关键测试计划必须实用，也不必要把大量的人力和物理花费在测试计划上，要根据具体情况来确定。
根据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审批
在测试计划这一部分就是确定评审组的成员，既由那些人来评审你的测试计划，有哪些人来评审你的测文档等。可能不同的公司需要的评审程度不一样，根据自己公司的具体需要来定。但前面提到的粮店是必不可上的。
要做一个测试计划首先要明确测试需求。在写测试计划之前必须要明确测试需求，
暗含的要求：例如很少看到这样明确话的文档要求：“入侵这相应手册中不许友拼写错误”但同时有些组织是允许拼写错误存在的。这样暗含的要求我们就要明确，可以通过和主管部门或是用户沟通来明确这样的要求。
不完全的或模糊的要求
比如：“所有的网站都应该安装SP3补丁”这样的要求就是模糊不清的，因为没有指明是操作系统还是网站服务软件，或是某些具体的系统软件。这样的需求就应该有需求提出的人来明确，确定在什么系统上安装sp3补丁。
未指明的要求
如：“必须使用强密码”看起来还向没什么问题，但从测试观点看，设么是强密码呢？是常超过7个字符的，还是应该有大小写的。这样的要求我们就应该根据密码要求标准具体化，比如：要求密码加强必须大于7个字符。
笼统的要求
比如“站点必须是安全的”尽管每个人都会同意这个要求，但展点能够彻底安全的唯一方法就是，断开展点的所有连接，内网的外网的，然后锁在一个加了封条的屋子里。但是这并不是要求的本意。这样的要求应该具体化，制定要求达到的安全程度。
好了要求明确了，下面就说一下就话的结构。呵呵我也是学来的，照别人的说吧，也有我的体会
测试计划的结构
测试计划可以依照工业标准（例如软件文档标准——Std.829）组织，也可以基于内部摸版，甚至可以用创献礼的全新个是编排。但大家一定要注意一点，测试计划重要的不是个是而是创建测试计划的过程一定要获得测试组的认可。但有的测试必须用规格的测试计划格式，行业内部摸版或行业标准，这样的测试如：政府机构、保险承销商等。
测试计划可以长达几百页，也可以简单的只有一张纸，关键测试计划必须实用，也不必要把大量的人力和物理花费在测试计划上，要根据具体情况来确定。
根据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审批
在测试计划这一部分就是确定评审组的成员，既由那些人来评审你的测试计划，有哪些人来评审你的测文档等。可能不同的公司需要的评审程度不一样，根据自己公司的具体需要来定。但前面提到的粮店是必不可上的。
小结：
无论选择测试计划的格式是基于工业标准， 还是内部模版，或是为具体项目配置的独特摸版，其测试计划和相关文档一定要经过修订以确保其充分说明了下表测试计划要考虑的因素：
测试计划考虑因素列表
是 否 描述
是否系统的安全要求以被澄清并做了文档化操作
是否已经明确定以了测试工作的目标（及其范围）
是否标明了所有待测项（及其版本）
是否未列出重要的不测项
是否定以了变动控制过程并标明了那些有权限批准测试范围变动的人
是否标明了所有待册特性
是否未列出重要的不测特性
是否以对测试方法（策略）进行文档化操作
是否以将把系统视为通过的标准（如果有）进行文档化操作
是否以将测试终止（和恢复）的标准（如果有）进行文档化操作
是否以将测试工作要产生的文档进行文档化操作
是否研究过将测试工作所有的环境需要进行文档化操作
是否将待测项的配置管理策略进行文档化操作
是否以将测试脚本和测试数据（测试套件）的配置管理策略进行文档化操作
是否以指派了所有测试工作的责任
是否以指派了所有测试工作所依赖的责任
是否标明了人事需要的来源
是否标明了培训需要的来源
是否创建了测试进度
是否以考虑了项目圆满结束的必须步骤
是否以标明了预计的最严重的风险
是否以设计并通过了预计的最严重的风险的规避风险措施
是否以将所有的问题、假设、约束和依赖进行文档化操作
是否以定义了所有的不常见的简写和术语
是否以标明并互相引用了支持文档
是否以标明了负责批准计划的人
是否以标明了负责接收测试结果的人
是否以标明了需要通报测试工作进展的人
