安全测试计划.doc

安全测试计划 篇一：Web安全测试测试计划编写 Web 安全测试 任何一个测试的开始都要制定一个完整的测试计划，现在我们就从 web 安全测试的测试计划开 始 要做一个测试计划首先要明确测试需求。在写测试计划之前必须要明确测试需求， 暗含的要求：例如很少看到这样明确话的文档要求： “入侵这相应手册中不许友拼写错误”但同 时有些组织是允许拼写错误存在的。 这样暗含的要求我们就要明确， 可以通过和主管部门或是用 户沟通来明确这样的要求。 不完全的或模糊的要求 比如：“所有的网站都应该安装 SP3 补丁”这样的要求就是模糊不清的，因为没有指明是操作 系统还是网站服务软件，或是某些具体的系统软件。这样的需求就应该有需求提出的人来明确， 确定在什么系统上安装 sp3 补丁。 未指明的要求 如：“必须使用强密码”看起来还向没什么问题，但从测试观点看，设么是强密码呢？是常超过 7 个字符的，还是应该有大小写的。这样的要求我们就应该根据密码要求标准具体化，比如：要 求密码加强必须大于 7 个字符。 笼统的要求 比如 “站点必须是安全的” 尽管每个人都会同意这个要求， 但展点能够彻底安全的唯一方法就是， 断开展点的所有连接，内网的外网的，然后锁在一个加了封条的屋子里。但是这并不是要求的本 意。这样的要求应该具体化，制定要求达到的安全程度。 好了要求明确了，下面就说一下就话的结构。呵呵我也是学来的，照别人的说吧，也有我的体会 测试计划的结构 测试计划可以依照工业标准（例如软件文档标准——Std.829）组织，也可以基于内部摸版，甚 至可以用创献礼的全新个是编排。 但大家一定要注意一点， 测试计划重要的不是个是而是创建测 试计划的过程一定要获得测试组的认可。 但有的测试必须用规格的测试计划格式， 行业内部摸版 或行业标准，这样的测试如：政府机构、保险承销商等。 测试计划可以长达几百页，也可以简单的只有一张纸，关键测试计划必须实用，也不必要把大量 的人力和物理花费在测试计划上，要根据具体情况来确定。 根据 IEEE Std.829-1998(软件测试文档标准 1998 年修订版)来介绍测试计划的内容 1.测试计划标题 就是说没个测试计划和每个测试计划的版本都应该有一个公司内部的独一无二标示， 这也是文档 控制和版本控制的基本要求，我觉得在正规公司的同仁们都应该明白。 2.介绍 这一部分适度测试的一个总的概括， 通过这一部分一该让读者明白此项目的准确目标和测试组如 何达到这些目标。根据情况也可以做一些基本概念的解释，比如为什么要做安全测试等等。 3 项目范围 在这一部分中明确项目的测试目标， 如果在介绍中已经描述的测试目标的话在这一部分应该详尽 的介绍测试目标。同时在这一部分可以列出在测试中不设计的测试项。 4 变动控制过程 这一部分主要是解决再测试中如果有需要变动的测试项应做如何处理， 可参考 CCB(变动控制委 员会)的意见进行适当的变动。 5 待测的特性（还没吃饭呢，同志们现在不写了好吗，等明天在写吧，好了写玩这一部分！坚持） 这一部分应该是对测试对象的描述， 测试组应该对则是对象进行研究， 对测试对象进行可行性检 查。因该根据具体情况对测试项进行删改，比如：应该确定是否有足够的时间和资金来测试每一样特性。测试组极有可能没有得到想要的足够资源，在这种情况下，必须做出决定应重点测试哪 些方面，而那些方面可以相对简单。达成这一点的方式是使用风险分析。 （好了不行了，饿晕了， 等有时间在写吧）未完待续 6 不测的特性这一部分主要说明因为测试项目多，可能测试的过程中有的重要的测是项目可能会被忽略。“因为在测试 计划的各自测试范围拼合的不是很紧密，可能出现系统的某个特性就完全没有测试，因为企业里的每个人 都以为其他人会测试系统的这个方面。”解决的办法就是：不仅在某个测试计划中记录下什么项将被测试， 也纪录下这些项的哪些方面将会测试而那些将是在测试计划范围之外的。从而明确澄清各个测试计划的范 围会涉及到什么和不涉及什么。一句话就是在测试计划重要把这些都确定下来，不能含糊不清。 7 方法 测试计划的这部分一般用来阐明测试组达成选前确定的测试目标所用的策略。无需深入到每个测试策略决 定的详尽细节。但是应该明确主要的决定。例如：将执行什么层级的测试和在系统生命周期内何时执行测 试。下面对一些概念进行介绍： 1） 测试的层级 测试分为多测试阶段（或测试层）的一个策略是按照某个测试可运行前系统必须完成的测试程度 来划分测试。比如一个测试可以分为单元测试（在系统一个组件上单独进行的测试也可称为模块 测试。 ） 、 整合级、 串级或连级测试 （设计用来测试系统的两个或个多组件见的通信的测试。 ） 、 系统测试等。 根据测试的具体情况将一个或几个层写到一个