-
在winsocket 协议录制的脚本里进行参数化
2007-06-27 10:12:22
操作步骤:
因为winsocket 协议录制的脚本输入的数据都被录入到data.ws里的,所以我是在data.ws里进行的参数化.右键选择要参数化的数据->选择"replace with parameter"->输入列名->在"parameter properties"进行了一些相关设置: ⑴在生成的文档里输入参数化数据 ⑵.select next row:unique ⑶.update value on:every iteration ->保存脚本. -
(转贴)性能测试的几个主要术语
2007-06-27 08:55:15
响应时间(response time)
响应时间,是指系统对用户操作的反馈时间。我们可以举一个163邮箱登录的例子:
我们如何来测试邮箱的登录响应时间呢?我们首先进入mail.163.com网页,输入合法的用户名和密码,点击“登录”,直到登录后的邮箱界面完全显示出来为止。那么响应时间从什么时候开始计算呢?是我们输入用户名的时候,还是点击“登录”的时候?
显然,我们应该从按下“登录”按钮的那一瞬间开始计时,到登录后页面完全显示出来为止,这才是真正的用户登录时间,而不包括用户输入用户名和密码的时间以及思考停顿的时间(think time)
登录响应时间其实包括3个部分:网络传输时间,服务器处理时间,浏览器显示时间
即登录响应时间=网络传输时间*2+服务器处理时间+客户端显示时间
网络传输是双向的,所以要乘以2。网络传输时间又可以包括接入网的传输时间和互联网中的传输时间,它的大小和你所使用的上网方式有关,比如光纤一般要比adsl要快。
服务器包括web服务器和数据库服务器,服务器处理时间是我们测试的重点,也是我们能够控制的部分,因为最终用户用什么机器上网,什么接入方式上网我们是控制不了的。我们要重点测试服务器的处理速度如何,以及能否承受较大的压力,我们可以用工具(比如LoadRunner)来模拟大量用户同时登录访问服务器,来查看服务器的承载能力。
客户端显示时间,如何将服务器传过来的页面尽快地显示到浏览器上,是开发人员需要考虑的问题,这里面涉及到算法优化的问题,这也是开发人员容易忽略的地方。
由此可见,响应时间是可以分解成若干个时间段的,任何一个环节出问题都会影响到最终的响应时间,这就需要我们在实际工作中结合具体情况加以分析。
最后再说明一点,响应时间的快慢是一个相对的概念,没有绝对的标准,比如对于163邮箱登录来说,用户可以接受的时间可以在10秒以内,而对于一个实时的军工软件来说,相应时间要精确到毫米级别甚至更低。
对于普通的web网站来说,一个普遍被接受的响应时间标准是2/5/10,即用户对2秒钟以内的的响应时间非常满意,对于5秒钟以内的响应时间基本满意,对于10秒钟以上的响应时间则无法接受。
吞吐量(throughput)
吞吐量,是指单位时间内流经被测系统的数据流量,一般单位为b/s,即每秒钟流经的字节数。
吞吐量是大型门户网站以及各种电子商务网站衡量自身负载能力的一个很重要的指标,一般吞吐量越大,系统单位时间内处理的数据越多,系统的负载能力也越强。
吞吐量和很多因素有关,比如服务器的硬件配置,网络的拓扑结构,软件的技术架构等。实际工作中,我们往往对升级客户的硬件配置无能为力,大多数情况下,我们还是在软件的技术架构上做文章:
比如后台数据库装oracle还是装sql server,显然前者的处理能力更强;
web服务器是用weblogic还是iis,要看服务器端的语言是jsp还是asp…
测试的时候多跟项目经理,系统架构师以及用户沟通,来获取系统架构的第一手材料。
并发(concurrency)
并发,是指多个同时发生的操作。比如有10个用户同时点击“登录”按钮(注意是同时),来登录163邮箱,我们就说此次登录163邮箱的并发数为10。
需要注意的是,并发和并行不是一个概念,并发是同时发生,并行是同步运行。10个用户并发登录163邮箱,只是在点击“登录”按钮那一瞬间是并行的,而登录后各个用户的操作则不同步。
稳定性测试(reliability testing)
稳定性测试,也叫可靠性测试(reliability testing),是指连续运行被测系统,检查系统运行时的稳定程度。
我们通常用mtbf(mean time between failure,即错误发生的平均时间间隔)来衡量系统的稳定性,mtbf越大,系统的稳定性越强
稳定性测试的方法也很简单,即采用24*7(24小时*7天)的方式让系统不间断运行,至于具体运行多少天,是一周还是一个月,视项目的实际情况而定。
负载测试(load testing)
负载测试,是性能测试的一种,通常是指让被测系统在其能忍受的压力的极限范围之内连续运行,来测试系统的稳定性。
可以看出负载测试和稳定性测试比较相似,都是让被测系统连续运行,区别就在于负载测试需要给被测系统施加其刚好能承受的压力,比如我们还是测试163邮箱系统的登录模块,我们先用1个用户登录,再用两个用户并发登录,再用5个,10个…在这个过程中,我们每次都需要观察并记录服务器的资源消耗情况(可以通过任务管理器中的性能监视器或者控制面板中的性能监视器),当发现服务器的资源消耗快要达到临界值时(比如cpu的利用率90%以上,内存的占有率达到80%以上),停止增加用户,假如现在的并发用户数为20,我们就用这20个用户同时多次重复登录,直到系统出现故障为止。
负载测试为我们测试系统在临界状态下运行是否稳定提供了一种办法。
压力测试(stress testing)
压力测试,是性能测试的一种,通常是指持续不断的给被测系统增加压力,直到将被测系统压垮为止,用来测试系统所能承受的最大压力。
比如我们不断增加并发的登录用户数,20,30,50…比如,当增加到70个用户并发登录时,系统崩溃了,我们就可以知道163邮箱所能承载的最大登录并发数为70个左右。
关于性能测试的分类,可以举一个比较通俗的例子方便大家理解:
假设一个人很轻松就能背1袋米,背2袋米很吃力,最多就能背3袋米
稳定性测试--我让他背1袋米,但是让他去操场上跑圈,看多久累倒。
负载测试--我让他背2袋米去操场上跑圈,看多久累倒。
压力测试--我让他背2袋米,3袋米,4袋米…发现他最多就能背3袋。 -
Web安全性测试
2007-06-26 21:19:18
一个完整的Web安全体系测试可以从部署与基础结构,输入验证,身份验证,授权,配置管理,敏感数据,会话管理,加密,参数操作,异常管理,审核和日志记录等几个方面入手
Web安全性测试
数据加密:某些数据需要进行信息加密和过滤后才能进行数据传输,例如用户信用卡信息、用户登陆密码信息等。此时需要进行相应的其他操作,如存储到数据库、解密发送要用户电子邮箱或者客户浏览器。目前的加密算法越来越多,越来越复杂,但一般数据加密的过程时可逆的,也就是说能进行加密,同时需要能进行解密!
登录:一般的应用站点都会使用登录或者注册后使用的方式,因此,必须对用户名和匹配的密码进行校验,以阻止非法用户登录。在进行登陆测试的时候,需要考虑输入的 密码是否对大小写敏感、是否有长度和条件限制,最多可以尝试多少次登录,哪些页面或者文件 需要登录后才能访问/下载等。
超时限制:WEB应用系统需要有是否超时的限制,当用户长时间不作任何操作的时候,需要重新登录才能使用其功能。
SSL:越来越多的站点使用SSL安全协议进行传送。SSL是Security Socket Lauer(安全套接字协议层)的缩写,是由Netscape首先发表的网络数据安全传输协议。SSL是利用公开密钥/私有密钥的加密技术。(RSA),在位于HTTP层和TCP层之间,建立用户与服务器之间的加密通信,确保所传递信息的安全性。SSL是工作在公共密钥和私人密钥基础上的,任何用户都可以获得公共密钥来加密数据,但解密数据必须要通过相应的私人密钥。进入一个SSL站点后,可以看到浏览器出现警告信息,然后地址栏的http变成https,在做SSL测试的时候,需要确认这些特点,以及是否有时间链接限制等一系列相关的安全保护。
服务器脚本语言:脚本语言是最常见的安全隐患,如有些脚本语言允许访问根目录,经验丰富的黑客可以通过这些缺陷来攻击和使用服务器系统,因此,脚本语言安全性在测试过程中也必须被考虑到。
日志文件:在服务器上,要验证服务器的日志是否正常工作,例如CPU的占用率是否很高,是否有例外的进程占用,所以的事务处理是否被记录等。
目录:WEB的目录安全是不容忽视的一个因素。如果WEB程序或WEB服务器的处理不适当,通过简单的URL替换和推测,会将整个WEB目录完全暴露给用户,这样会造成很大的风险和安全性隐患。我们可以使用一定的解决方式,如在每个目录访问时有index.htm,或者严格设定WEB服务器的目录访问权限,将这种隐患降低到最小程度。 -
用LR如何监视服务器资源
2007-06-26 13:25:00
1.点击"开始"菜单-->运行
2.输入要监控性能的机器ip,如\\10.210.3.1
3.在弹出的登陆窗口输入那台机器的管理员帐户和密码
4.运行CONTROLLER添加那台机器的性能指标后就可以监控到了 -
吞吐量
2007-06-26 13:18:17
吞吐量是Vuser从server收到的Data数量,它可以与事务响应图相对比,来看出:吞吐量是如何影响事务执行的。如果吞吐量随着Vuser数量上升而加大,说明带宽足够。如果保持平稳说明带宽限制了数据的传递。
-
在Unix系统中如何启动rstatd服务
2007-06-26 13:14:20
首先介绍一下在IBM AIX系统中如何启动rstatd服务(因为这个比较简单,顺便可以认识一下Unix系统)。使用telnet以root用户的身份登录入AIX系统,在命令行提示符下输入:
如果系统已经自己安装了,你可以这样做,如果没有,则要参照linux的方法
vi /etc/inetd.conf
在出现的界面中敲键盘:/rstatd
命令解释:在打开的文档中查找“rstatd”,接下来继续敲键盘:x
命令解释:删除当前字符,在这里为删除rstatd命令前的“#”,继续敲键盘::wq
命令解释:保存并退出,注意前面有个冒号。接着在命令提示符下输入:refresh –s inetd
命令解释:重新启动服务。这样使用loadrunner就可以监视AIX系统的性能情况了。
在RedHat Linux中要麻烦一点......需要下载一个安装包rstatd.tar.gz,并且需要安装。比较复杂,安装包中具体的说明,为了简便起见,这里直接给出配置的命令。
首先把rstatd.tar.gz文件放到用户目录下,进行解压(可以在windows下直接解压,然后把rpc.rstatd目录及其下所有文件拷贝到用户目录下)。然后进入rpc.rstatd目录,执行:
./configure
命令解释:配置,详细的就不说了,反正它自己会执行的,命令执行完毕后再敲入:make
命令解释:编译安装包,执行完毕后敲入:make install
命令解释:安装程序、数据文件和其他文档。之后敲入:rpc.rstatd
命令解释:运行rstatd服务。以上在RedhatLinux9下调试通过,RedhatLinux10下尚未通过。这时就可以使用LoadRunner监视此Linux的性能了。
有关自动启动,在SuSE Linux 7.0 (kernel 2.2.16-suse18) and 7.1 (kernel 2.4)版本需要在/etc/inetd.conf文件中增加一行:
rstatd/1-5 dgram rpc/udp wait root /usr/sbin/rpc.rstatd rpc.rstatd
-
我的测试思路
2007-06-26 08:09:24
我的测试思路
比如接到一个模块的测试任务,我首先看这个模块上有多少个功能点,统计后思考测试所要占用的时间。随机在模块上做一些功能操作,主要查看各种连接是否正确,用专业语言讲就是“冒烟测试”。然后在看界面上的布局,是否美观、是否符合公司UI设计规范的要求。
初步的测试后,就要详细对每个功能点下功夫测试。测试功能点从上到下,或者从左到右依次的进行测试。可以用个记事本把需要测试的功能点记录下来,如果测试过就在功能点后面打勾,避免遗漏。测试的前提就是要熟悉所要测试模块的需求,有的时候可能忘记了需求就要查看需求文档或者与系统需求工程师沟通确认。避免直接与开发人员沟通模块上的功能使用,开发人员的思路可能会左右你的测试思路。
首轮做的是界面测试主要查看界面的设计风格和界面中文字的测试,逐字看有无错别字;提示框信息是否有语病。接下来的测试就要查看一些易用性的操作。第二轮主要是测试功能点就是要输入一些正常值,保证功能可用。输入的值可以正常显示,功能基本满足需求等。如上述测试都满足,第三轮的测试就要一些非法值也就是健壮性的测试。在输入框或者查询框中可用输入一些特殊字符,看能否正常保存或者有无查询结果。也可以做一些超长字符和边界值的操作,此时要对比数据库设计和需求中数据字段所要求的长度。在这些测试过程中可能会出现一些非法的操作,同时要查看系统有无友好提示。比如必添项没有添写要有提示框;删除时的提示框等。
上面说的是单个模块的测试,如果模块间有接口,这个接口上的测试在集成测试阶段是必不可少的。测试方法也有几个,比如说数据流的测试,数据流能否正确的从前一个环境流转到下一个环节,如有回退情况能否正常回退。用户管理上的测试就与权限和登录关系密切。这些都属于多个模块的接口测试。如果有与硬件系统相关的接口,那么硬件方面的联动测试也是不可缺的。
测试的最后一个环节就是要执行测试用例,公司内所撰写的测试用例基本上都概括了需求,虽然用例上的case可能不满足测试的全部要求,但是满足需求的内容,走一遍测试用例就避免了需求上功能的遗漏。
以上是我个人的测试方法,大家有好的方法可以与我沟通,相互学习。
下面总结了一些测试时常用的特殊字符,给开发人员一个参考。
特殊字符
!◎#¥%……※×()——+§』『“:?』《~卍 卐
~!@#$%^&*()_+|{}:”<>?,./;’[]= - ☆☉♂△◇◆ф℅℉‰я↖∈∏∑∨∧∞√≌⊕⑦⒀∷┎┡ ╬ ╮
<td> </td> < > </>
数字
1234567890
字母
ABCDEFGHIJKLMNOPQ
Abcdefghijklmnopq
汉字
壹 贰 叁 肆 伍 陆 柒 捌 玖 拾
UNICODE编码
伂 伉 伄 佸 伨 侃 侂 佢 輲 鼲 缴 縲
-
对于软件测试计划的个人总结
2007-06-25 19:57:16
软件测试计划
软件测试计划对整个测试工作,进行规划,为整个测试过程,提供明确的方向。
软件测试测试计划主要内容
• 1) 测试目标
• 2) 测试范围
• 3) 测试工作进度
• 4) 测试工作资源
• 5) 测试阶段划分
• 6) 测试阶段总结
软件测试计划类别
• 软件测试计划,按照测试的阶段可分为多种相应的测试计划,可按照独立阶段制定测试计划,也可将所有测试计划组合成为一个综合的测试计划。划分类型可如下所示:
• 1) 综合测试计划
• 2) 单元测试计划
• 3) 系统测试计划
• 4) 性能测试计划
• 5) 安装测试计划
• 等其他类型;也可按照其他方式划分,并制定各种特定条件下的测试计划。
软件测试工作主要影响因素
• 软件测试工作,主要包括以下几个部分:
• 1) 测试工作量
• 2) 测试资源限制
• 3) 测试进度要求
• 4) 测试范围
• 5) 测试完成度/测试工作的质量
• 6) 沟通
• 以上几个因素都是相互影响;测试计划的主要任务是合理处理各个因素之间的关系。并制定特殊情况下的应急方案;使测试完成度尽可能的达到要求。
软件测试工作的开展
• 只有好的软件测试计划,并不能使测试工作完美进行;还需要相应的管理制度,使工作能够按照计划执行;当然任何工作也需要合适的测试资源;
• 合适的测试计划+合适的制度+合适的资源,才能保证测试工作的质量。
软件测试计划内容的具体要求
• 测试目的与测试目标
• 测试范围
• 测试工作量与测试资源
• 测试进度
• 测试阶段的划分
• 测试阶段总结
测试目标与测试目的
• 测试目标与测试目的必须准确,合理。描述尽可能的简要。由于测试工作的重心都将围绕测试目标与测试目的来开展,故目标与目的需要尽可能的稳定与准确。中后期变更测试目标与测试目的,都将增大后续工作的难度与工作量。
• 如:前期指定测试计划的目标为测试系统在各种平台下的兼容性;中后期变更为测试系统的可扩展性。由于测试目标的变更;导致测试工作重点的偏转;测试思路必须随之变更;同时需要变更或者新增大部分测试用例 。
解决方法
• 1) 深入理解需求,根据需求制定测试目标与测试目的;
• 2) 明确项目/产品的目的与目标;
• 3) 对于市场不成熟的项目或产品(客户的需求不成熟);深入了解客户的目的,根据客户的目的制定测试目的与目标;由于客户的目的的不明确性,故制定的目标与目的不要有太多的限制(先抽取主干,根据主干制定目标与目的)
测试范围
• 测试范围指需要测试的部分;由于软件测试工作量巨大,一般需要将不必要测试的项目;在测试范围中剔除;不重要的部分,安排优先级时必须偏底;重要的部分,安排优先级时必须比较高;对于必须测试的部分;则必须详细描述,且优先级必须最高。
解决方法
• 1) 深入了解需求,区分不必要与必要测试的部分
• 2) 整理主干业务,进行重点测试
• 3) 维护需求跟踪矩阵中有关测试的部分
• 4) 对于不同类型的测试,分类管理(单元测试,功能测试,性能测试等)
测试工作量与测试资源
• 测试工作量指测试工作所需要的所有工作量;
• 测试资源指测试时需要使用的资源,包括人力以及硬件,软件环境资源
解决方法(一)
• 1) 由于测试工作量的重心,在测试用例编写部分;而且测试用例编写的工作量相对来说是最好计算与评估的;故可按照经验计算测试的工作量;
• 2) 由于回归测试与软件的设计质量,软件的编码质量,软件的集成质量都有很大的关系,故这个部分也需要按照经验估算回归测试的工作量。
• 3) 测试资源详细描述需要使用硬件资源与软件资源,并指明各类型资源最早到位时间与最晚到位时间
• 4) 测试资源中的人力资源,由于人力资源的不可预估性,故需要罗列更详细的技能与经验要求;也需指明各岗位人员的最早到位时间与最晚到位时间。
• 5) 当测试资源不足时,建议首先对必要测试部分的工作量进行分配。并建议项目领导增加测试资源。
• 6) 由于目前软件项目进度的不可预测;故需要在一定的阶段对资源进行重新估算 。
测试进度
测试进度一般指测试工作的开展进度;一般使用甘特图表示。
解决方法
• 1) 按照功能点与测试阶段进行双重划分
• 2) 由于目前软件项目进度的不可预测;故需要在一定的阶段对进度进行重新估算
测试阶段的划分
测试阶段指,按照一定的类型如时间,测试工作类型;将整个测试周期划分为多个有意义的阶段;类似与里程碑的设立,不同于里程碑为一个点,阶段指的为一个区域。
解决方法
1) 按照时间划分,如测试工作开展时,按月的划分(独立使用的实际意义不大,但利于工作量的统计与分析)
2) 按照测试工作类型划分,如单元测试,功能测试,测试计划编写,用例编写等
3) 将时间与测试类型,以及按照里程碑来进行划分。
4) 最简单的方式为,按照里程碑划分进行划分。
5) 明确描述各阶段之间的前置条件和输出结果。
测试阶段总结
• 测试阶段总结,到达一定的阶段后,对以前的阶段工作进行总结,分析测试工作的工作过。程对资源以及进度进行重新估算,并对产生偏差的原因进行陈述。
• 备注:注意总结不属于测试计划内
其他相关
• 需求跟踪矩阵
• 测试进度变更
• 缺陷管理
• 测试风险管理
• 测试覆盖率
• 测试过程
-
系统的安全性测试
2007-06-25 19:17:17
系统的安全性测试
系统的安全测试
1. 安全测试,什么是安全测试。 安全性测试(Security test)它是指:在测试软件系统中对程序的危险防止和危险处理进行的测试,以验证其是否有效。
2. 安全性测试我们要做哪些工作呢?
a.全面检验软件在软件需求规格说明中规定的防止危险状态措施的有效性和在每一个危险状态下的处理反应情况;
b.对软件设计中用于提高安全性的逻辑结构、处理方案,进行针对性测试;
c.在异常条件下测试软件,以表明不会因可能的单个或多个输入错误而导致不安全状态
d.用错误的安全性关键操作进行测试,以验证系统对这些操作错误的反应;
e.对安全性关键的软件单元功能模块要单独进行加强的测试以确认其满足安全性需求。
3. 安全性测试方法
1. 功能验证
功能验证是采用软件测试当中的黑盒测试方法,对涉及安全的
软件功能,如:用户管理模块,权限管理,加密系统,认证系
统等进行测试,主要验证上述功能是否有效。
2. 漏洞扫描
安全漏洞扫描主要是借助于特定的漏洞扫描器完成的。通过使
用漏洞扫描器,系统管理员能够发现系统存在的安全漏洞,
从而在系统安全中及时修补漏洞的措施。一般漏洞扫描分为
两种类型:主机漏洞扫描器是指在系统本地运行检测系统漏
洞的程序。网络漏洞扫描器是指基于网络远程检测目标网络
和主机系统漏洞的程序。
3. 模拟攻击
对于安全测试来说,模拟攻击测试是一组特殊的极端的测试方
法,我们以模拟攻击来验证软件系统的安全防护能力。
刚才我们主要讲了两个内容:1. 系统安全测试要我们做的哪些工作。
2. 系统安全测试的方法。
下面我们切入主题讲系统的安全测试,都要测试哪些东西
1. 系统安全测试的内容:它主要包括
1.应用程序安全测试
2.操作系统安全测试
3.数据库安全测试
4.IIS服务器安全测试
5.网络环境安全测试
当然在这里我主要讲的是我做过的项目系统中需要测试的内容,对不同的系统安全性测试的内容也不一样,这个需要结合项目本身的情况和用户使用环境来确定测试的内容。
第一部分
应用程序的安全性:
包括对数据或业务功能的访问,在预期的安全性情况下,操作者只能访问应用程序的特定功能、有限的数据。其测试是核实操作者只能访问其所属用户类型已被授权访问的那些功能或数据。测试时,确定有不同权限的用户类型,创建各用户类型并用各用户类型所特有的事务来核实其权限,最后修改用户类型并为相同的用户重新运行测试。
应用程序的安全性问题:
我主要是结合我们刚才讲的安全性测试方法中,对于不同的安全性测试策略列举了不同的问题,当然我列的不全,在这里我主要是告诉大家一个测试的思路,因为对于不同的安全性问题大家有或许有不同的看法,所以我只列举了部分问题给大家参考。
功能验证
1.有效的密码是否接受,无效的密码是否拒绝。
2.系统对于无效用户或密码登陆是否有提示。
3.用户是否会自动超时退出,超时的时间是否合理。
4.各级用户权限划分是否合理。
漏洞扫描
无
模拟攻击
1.系统是否允许极端或不正常的登陆方式访问。(如
拷贝软件系统中的某个功能点的url地址,然后直接
通过IE访问看是否成功)
第二部分
系统安全性:
注意(这里的系统指的是操作系统也就是应用程序所运行的操作系统)
系统安全测试:
可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问,包括对系统的登录或远程访问。其测试是核实只有具备系统和应用程序访问权限的操作者才能访问系统和应用程序。
操作系统安全测试
l 帐号和口令
l 网络与服务
l 文件系统
l 日志审核
l 其它安全设置
帐号和口令
1、 对主机或域上用户强制进行口令复杂度。
2、 检查系统是否使用默认管理员帐号。
3、 检查在系统中是否存在可疑或与系统无关的帐号。
4、 检查系统用户是否有口令最短和口令长度要求。
5、 检查系统用户是否有密码过期策略。
6、
网络与服务
1、 查看主机开放的共享,关掉不必要的共享和系统默认的共享服务。
2、 查看主机进程信息。(不允许系统中安装有与应用服务无关的应用程序 )
3、 查看系统启动的服务列表。
4、 查看系统启用的端口号 。
5、 查看系统是否制定操作系统的备份恢复策略服务
文件系统
文件系统的安全主要是检查主机磁盘分区类型和某些特定目录的权限 。
注意:服务器应使用具有安全特性的NTFS格式,而不应该使用FAT或FAT32分区(上述描述的内容主要是针对windows操作系统)。
日志审核
日志的审核主要是检查主机日志的审核情况。
它主要包括:
1.应用程序日志。(运行在操作系统上的程序产生的)
2.安全日志。(用户登录系统的日志)
3.系统日志。
其它安全设置
1、 系统补丁漏洞。
2、 登陆系统操作的用户的权限。
3、 病毒防治。
4、 系统日志是否有备份功能 。
5、 数据的备份与恢复。
6、 系统上卸载与无关组件或应用程序。
第三部分
数据库安全测试
数据库安全
在管理和维护数据库的过程中为了保障数据库安全我们从以下几方面限制数据库访问安全:
1、限制能访问Oracle 数据库的客户端,指定的IP才可以访问,防止恶意的用户登陆。
2、即使有访问 Oracle 数据库的机会,帐户的密码使用强口令和其他登陆策略,恶意用户也无法轻松进入。
3、为每个登陆帐户设置了合适的权限,执行改变数据库状态的权限需要得到管理员的授权,确保了系统合法帐户对数据库的操作安全。
解决办法
1.无关IP禁止访问
方法一: 在Oracle 服务器的SQLNet.Ora 文件中设置允许访问的IP 地址,或不允许访问的 IP 地址;
方法二:在Oracle 服务器上使用NetManager 工具设置;
2.用户密码为强口令
锁定不用的默认帐户,如scott ;
更改使用的默认帐户的口令,这些帐户的密码是公开的,安装时自动建立,如帐户system 密码manager 为确保安全默认帐户必须修改密码;
密码使用强口令,即数字、特殊字符、字母组成的至少8未的密码;
设置密码失效的策略文件 profile,可在 控制台中设置。
3.用户赋予适当的权限
不要每个帐户都设置DBA权限,把系统所有操作暴露给每个用户;
每个帐户仅赋予它完成操作所需要的权限;不要轻易为帐户赋予delete 或delete any 权限,确保数据不会被误删除;
数据库安全(sql server)
1、关闭服务器端的tcp/ip协议服务。
2、数据库用户登录方式选择sql server身份认证。
3、设置用户访问指定的数据库。
4、设置用户对数据库中的对象有指定的操作权限。
5、查看数据是否有定期自动备份的操作。
第四部分
IIS服务器安全测试
1、IIS基础服务组件安装情况。(根据系统情况合理的安装,减少安装不必要的服务控件)
2、查看IIS日志是否启用,日志存储路径以及日志记录选项
3、IIS主目录路径和目录访问权限的设置。
(注意:1.目录建议不要和系统盘符设置在同一路径下,
2.目录访问权限根据所在项目系统的实际情况来设置,通常只启用”读取”权限,记录访问和索引资料权限跟系统的安全无关都默认启用,因为所用的internet用户访问的目录就是IIS设定主目录)
4、默认文档的启用。
5、访问控制的身份验证。
6、连接超时功能的设置(可以根据项目的安全要求具体的可参考系统需求规格说明书来进行合理的设置)。
7、安全补丁的更新和安装情况
第五部分
网络环境安全测试
主要检测的是系统所在局域网内的网络环境的的安全设置,根据情况可以忽略。
1.备份和升级情况
2.访问控制情况
3.网络服务情况
4.路由协议情况
标题搜索
我的存档
数据统计
- 访问量: 220176
- 日志数: 342
- 文件数: 23
- 书签数: 10
- 建立时间: 2007-06-14
- 更新时间: 2008-12-30