Web测试规范

Ros ·

更新时间:2024-11-14

· 567 次阅读

　　任何一个测试的开始都要制定一个完整的测试计划，现在我们从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个漏洞等等。