-
如何更有效使用 Rational AppScan 扫描大型网站，第 2 部分: 案例分析
2015-12-10 16:30:42
使用 AppScan 进行扫描
针对大型网站的扫描，我们按照戴明环 PDCA 的方法论来进行规划和讨论，建议 AppScan 使用步骤：计划（Plan）、执行（Do）、检查（check）、分析（Analysis and Action）。
- 在计划阶段：明确目的，进行策略性的选择和任务分解。
- 明确目的：选择合适的扫描策略
- 了解对象：首先进行探索，了解网站结构和规模
- 确定策略：进行对应的配置
- 按照目录进行扫描任务的分解
- 按照扫描策略进行扫描任务的分解
- 执行阶段：一边扫描一遍观察
- 进行扫描
- 先爬后扫（继续仅测试）
- 检查阶段（Check）
- 检查和调整配置
- 结果分析（Analysis）
- 对比结果
- 汇总结果（整合和过滤）
下面我们针对每个阶段，进行具体的阐述。
准备阶段
AppScan 安装环境要求和检查
为了保证更好的扫描效果，安装 AppScan 的硬件建议配置如下：
表 1. Rational AppScan 安装配置要求
硬件 最低需求 处理器 Pentium P4，2.4 GHz 内存 2 GB RAM 磁盘空间 30 GB 网络 1 NIC 100 Mbps（具有已配置的 TCP/IP 的网络通信） 其中，处理器和内存建议越大越好，而磁盘空间，建议系统盘（一般是 C 盘）磁盘空间至少保留 10G，如果系统盘磁盘空间比较少，可以考虑把用户文件等保存在其他盘；如默认的用户文件是：C:\Documents and Settings\Administrator\My Documents\AppScan；可以修改为其他路径。该路径可以在菜单栏中依次选择工具 - 选项 - 一般 - 文件位置部分修改。
图 1. 设置文件保存路径
磁盘要求：修改临时文件路径
有时候大家会发现，已经把上面的地址都修改到了其他盘，但是在扫描过程中，还是会发现 C 盘的空间快速被消耗，分析原因，是因为很多临时文件都保存在 C 盘，AppScan 中有一个隐藏的参数 APPSCAN_TEMP 来设置临时文件位置。在扫描过程中，如果系统盘空间比较下，可以通过修改系统变量来修改到其他硬盘空间。
临时文件位置说明：描述正常操作期间 AppScan 将其临时文件保存到的位置。缺省情况下，AppScan 将其临时文件存储在以下位置：
C:\Documents and Settings\All Users\Application Data\IBM\Rational AppScan\temp
如果需要修改此缺省位置，请按照要求编辑环境变量 APPSCAN_TEMP 的路径。（访问环境变量的方法是，右键单击我的电脑，然后依次选择属性 > 高级 > 环境变量。）
注意：在新位置的路径中绝不能有任何 Unicode 字符。
修改 AppScan 中的临时文件：
- 桌面上鼠标右键选择“我的电脑”，选择“属性”
- 选择“高级”，“环境变量”
- 增加一个新的“用户环境变量”，名字是“APPSCAN_TEMP”，设定路径，指向您希望保存临时文件的目录。
计划阶段
在计划阶段，首先明确几个问题：
- 关心哪些类型的安全问题，根据这些安全问题来设置扫描规则。
- 要扫描的网站地址，网站的业务特点。
扫描策略的选择
试想，我们现在要扫描的是某个移动公司的网站系统，该网站系统提供多个内容频道，还可以连接到多个其他移动公司网站和业务网站，我们本次安全测试重点关心的是门户网站本身和其上面的网上营业厅业务。这就是一个比较明确的测试目标对象。
然后，确定扫描策略，我们主要关心该网站是否存在跨站点脚本执行和 SQL 注入的问题，则在扫描规则中，我们就可以选择这两种类型的规则，其他规则都排除。
具体的扫描规则定制，可以在扫描配置 - 测试 - 测试策略中选择：
在测试策略中，有多种不同的分组模式，最经常使用的是“严重性”，“类型”，“侵入式”、“WASC 威胁分类”等标准，根据不同分组选择的扫描策略，最后组成一个共同的策略集合。
根据我们这次扫描的目标，关心的是跨站点脚本执行和 SQL 注入的问题，而且不考虑“基础结构”级别的安全问题。则就可以首先选择一个默认的扫描策略，然后全部置空，再选择
跨站点脚本执行和 SQL 注入，最后再去除这两种扫描策略中和基础结果相关的安全问题。
方法如下：
- 选择缺省的扫描策略，或者把当前的扫描策略，切换到按照“类型”分类，取消掉“基础结构”和“应用程序”两种类型。
说明：则把扫描策略置空，没有选择任何的扫描策略，指所有分布类型选择“类型”分类，是因为类型分类里面含有的类型，只有两种类型，可以快速全部都取消掉。
- 分组类型，切换到“WASC 威胁分类”，选择“SQL 注入”和“跨站点脚本编制”。
- 分组类型，切换到“类型”，发现这时候“基础结构”和“应用程序”两种类型的扫描策略都是选择上的模式，而且是虚线，说明这两种类型下均有部分扫描策略被选择了。
- 我们不关心“基础结构”级别的安全问题，所以在这里取消“基础结构”。
图 2. 按“类型”分类的测试策略
- 分组类型，切换到“侵入式”类型，下面有“非侵入式”和“侵入式”两种分类。取消“基础结构”级别的测试。
侵入式的测试用例，往往因为有比较强的副作用，可能对系统造成伤害，所以一般扫描生产系统的时候，很少选择。我们可以查看一个 SQL 注入类型的侵入式安全问题，在“输入以查找”输入框中输入“SQL”，然后回车查询。可以看到测试变体的描述“将参数值设置为 Declare/Case SQL 注入攻击（尝试关闭 DB 服务器）”，则扫描过程中，会使用该测试用例去执行尝试关闭数据库的命令，如果该测试用例执行通过，则就关闭了数据库，则整个系统就瘫痪！所以，要很慎重的选择“侵入式的测试用例”。
图 3. 查询测试策略
其他的在“类型”中，“应用程序”类型表示该问题的存在是因为应用程序不严谨，代码存在安全问题而造成的，修改方法就是修改原代码；而“基础结构”类型，则表示该问题是配置问题，建议修改系统配置或者安装最新的补丁（经常是中间件或数据库补丁）。
了解被测试网站
在对网站进行测试之前，我们经常需要先大概了解下这个网站，比如该网站使用了哪些技术，提供什么类型的业务（功能），网站规模等。这些都和我们的扫描设置相关。如下图，就是我们经常使用的一个调查表，了解被测试系统的基本特点。
表 2. 记录被测网站特点
应用系统名称 访问地址 应用系统架构（JEE/.Net/PHP…） URL 数量 登陆方式 备注 其中，用户经常迷惑的是 URL 数量，有些时候，用户很难评估出一个系统的大概页面数量，而按照 AppScan 的工作原理，扫描是针对页面的每个参数的，如果页面越多，参数越多，则扫描要运行的时间也就越长，扫描保存成的接过文件也是越大，更需要进行分解。如果一个扫描任务，本身的已访问 URL 数超过 5000，评估的要运行的安全测试用例数超过 50，000，则建议进行扫描配置的分析，并根据分析结果，决定是否需要进一步的任务分解和分工。
那么，如果可以了解到网站具体有哪些页面呢？这里我们就可以利用 AppScan 的探索（页面爬行）能力。
在扫描配置里面设置了主 URL 以后，工作菜单中中依次选择扫描 - 仅探索。对网站进行探索。一般会让探索工具运行 10 到 30 分钟，看该网站具体存在哪些页面，哪些参数等。这个就可以切换到“应用程序数据”视图来查看。
我们一般关心这几个视图：
- 已访问的 URL()：AppScan 已经探索到并且进行了分析的页面
- 已过滤掉的 URL()：AppScan 已经发现，同时根据扫描配置，认为不需要进行安全扫描的页面。
- 中断链接 URL()：AppScan 发现了，但是无法访问到或者访问出错的页面，如 404 页面不存在，或者 500 服务器错误等。
伪静态页面
可以选择左边“我的应用程序数据”中的 URL 树下的每一个节点，察看该节点已访问的 URL，已过滤掉的 URL 等。
如在已访问的 URL() 中，我们发现大量类似如下结构的 HTML 页面：
http://www.Test.com//focus/satisfy/file5.html http://www.Test.com//focus/satisfy/file6.html http://www.Test.com/m-zone/news/dgdd/quanbu/bylb/file5.html
其共同特征，都是以 html 为后缀名，最后的文件名格式都是 file+ 数字格式；这种类型的页面经常存在新闻，论坛等。如果访问这些页面，发现页面结构相同，差异的都是里面的文本内容，如提供不同的新闻内容等，这些页面就是所谓的“伪静态页面”，其实是网站发布系统动态产生的，由于结果相似，在安全扫描中，没有必要针对这些页面每次都进行扫描。如针对每个目录下面存在的 file+ 数字格式的页面，我们就可以设置正则表达式来过滤，比如，在扫描配置 - 排除路径和文件中
排除所有该类型的页面；.*file\d+.html
增加“例外”，对该类型的页面只扫描 file1.html 和 file20.html
经常存在的其他类似页面，还有 news1.html、content200.html 等类型，采用方法类似。
业务类型的“冗余路径”
和“伪静态页面”对应的有另外一种动态页面，这些页面按照默认的扫描规则，会被自动过滤，但是根据真实的业务场景，这些页面确实不能被过滤的，如访问 demo.testfire.net 时候在“已过滤 URL”内会显示有如下的 URL 地址，过滤原因都是“路径限制”：
http://www.Test.com/default.aspx?content=inside_community.htm http://www.Test.com/default.aspx?content=inside_press.htm http://www.Test.com/default.aspx?content=inside_executives.htm
选择 URL 地址，鼠标右键“在浏览器中显示”，会发现这里显示的页面内容完全不一样，和上面的“伪静态页面”正好相反，这些参数相同，参数值不同的动态页面，是真正的业务页面，是不能过滤掉；如果过滤，则会很多后续的业务页面无法发现。那这些页面为什么会被过滤了呢？按照什么样的规则被过滤掉的？
在 AppScan 中，默认情况下是有一个“冗余路径限制”（在“扫描配置 - 探索选型 - 冗余路径限制”），默认对于冗余的页面，最多扫描 5 次，关键的问题是，什么页面被被 Appscan 认为是冗余页面呢 ?
图 4. 冗余路径设置
简单说：
Appscan 是根据“?”号来分隔的，如果 ? 号前面的内容都相同，则就被认为是冗余页面，所以上面的页面就是冗余页面了。
遇到这样情况的页面，最多被访问 5 次。而这 5 次，具体是使用了哪些参数，是随机的，具体访问到的页面也会在“应用程序数据”视图的“已访问的 URL”中查看：
可是，在本例中 content 参数值不同的时候，其实根据业务逻辑，不应该算作“冗余页面的”，而按照配置，也会被自动过滤了，遇到这种情况，就需要考虑增加“冗余路径限制”，如设置为 20 或者 50。以可以更多次访问这些页面。
这些情况经常存在于跳转参数等情况。
顺便备注下，“冗余路径限制”，功能设置的目的是为了处理类似论坛 BBS 等页面，只有文本内容不同，页面架构完全相同的页面：如
http://www.Test.com/showthread.php?id=1 http://www.Test.com/showthread.php?id=2 http://www.Test.com/showthread.php?id=3
而我们在测试 demo.testfire.net 时候会发现每次的安全测试结果都可能有差别，一个很大的原因就是每次访问的页面是不同的，就是这个设置的影响。
分析重复的“脚本参数”
在上面的步骤中，分析了“伪静态页面”，对其应该通过“排除路径或者文件名”的方法设置排除规则；而对于“业务类型的冗余路径”，则需要通过增加“冗余路径显示”个数等的方法进行扩充，以扫描到这些 URL。我们在这个步骤来分析另外一种参数，脚本参数。
在“我的应用程序数据”树状结构下，鼠标选择目录以后，在右边视图中选择“脚本参数”，然后查看是否存在不同页面（URL) 存在相同或者类似参数的情况：如下图，在不同 URL 中，都存在 kbKey 参数，默认的参数值是“请输入您要搜索的问题”：
图 5. 脚本参数
访问这些 URL，发现每个页面内都包含了一个搜索功能，这就是为什么在不同页面都发现了该参数。而从业务角度，这些搜索页面在一个 URL 中进行测试以后，没有必要在另外一个页面也进行测试。而且该参数值的变化，可以认为是冗余页面，没有必要进行下一步的重新探索和测试。这可以通过上图中，选择该参数后，鼠标右键，选择“添加到‘参数和 Cookie’选项卡中的列表”来实现。选择后弹出下面的页面：
图表 6 添加参数定义（根据参数来设置冗余路径）
在该页面中，点击“其他选项－冗余调整”，取消选择任何一个选择框，则表示无论是否含有该参数，无论该参数值是否发生变化，都不认为是新页面，没有必要重新测试，而且不应该因为该参数的变化去影响其他参数的测试。
我们知道，AppScan 中的测试，是针对页面的每个参数进行的，而且一个参数值的变化会要求重新测试其他的参数，所以该设置，可以大大减少测试用例数。
关于更多的设置说明，可以参照下面的解释：
表 3. 设置说明
选框 选中时 ... 只要添加或除去此参数 /cookie，便再次探索 URL。 在探索阶段，如果两个 URL 的唯一区别在于一个包括此参数，而另一个不包括此参数，那么将其视为不同 URL，并且对两者都进行探索。
例如，如果是以下两个 URL，两者都将进行探索：
...page.jsp
...page.jsp?thisParam=Value
如果您取消选中此复选框，那么在此情况下，将仅发送一个请求，而其他请求将被废弃。只要此参数 /cookie 的值更改，便再次探索 URL。 在探索阶段，如果两个 URL 的唯一区别在于此参数 /cookie 的值，那么将其视为不同 URL，并且对两者都进行探索。
例如，如果是以下两个 URL，两者都将进行探索：
...page.jsp?thisParam=Value1
...page.jsp?thisParam=Value2
如果您取消选中此复选框，那么在此情况下，将仅发送一个请求，而其他请求将被废弃。只要添加或除去此参数 /cookie，便重复所有相邻参数 /cookie 测试。 在测试阶段，如果两个 URL 的唯一区别在已添加或除去了此参数，那么将其视为不同 URL，并且再次测试相邻参数。
例如，如果是以下两个 URL，将为相邻参数生成两组完整的测试，每个 URL 一组。
...page.jsp?adjacentParam=<test_this>
...page.jsp?adjacentParam=<test_this>&thisParam=Value
如果您取消选中此复选框，将为相邻参数仅生成一组测试。只要此参数 /cookie 的值更改，便重复所有相邻参数 /cookie 测试。 在测试阶段，如果两个 URL 的唯一区别在于此参数 /cookie 的值，那么将其视为不同 URL，并且再次测试相邻参数。
例如，如果是以下两个 URL，将为相邻参数生成两组完整的测试，每个 URL 一组。
...page.jsp?adjacentParam=<test_this>&thisParam=Value1
...page.jsp?adjacentParam=<test_this>&thisParam=Value2 如果您取消选中此复选框，将为相邻参数仅生成一组测试。查看每个目录页面个数
如果一个扫描任务，本身的已访问 URL 数超过 5000，评估的要运行的安全测试用例数超过 20，000，则建议进行扫描配置的分析，并根据分析结果，决定是否需要进一步的任务分解和分工。
我们在“我的应用程序数据”树状结构下，鼠标选择目录以后，在右边视图中选择“已访问的 URL()”，记录 URL 数目，如果该目录 URL 数目比较大（超过 500）则可以考虑为该目录单独建立一个扫描任务，只扫描该目录下面的链接。
执行阶段
根据在“计划阶段”确定的扫描策略，和进行的扫描设置，重新进行探索（扫描菜单依次选择：重新扫描 - 重新探索）；后继续分析页面数和测试用例数目，如果控制页面数 5000 个以内，测试用例数 20，000 个以内，则可以直接进行扫描；如果没有，建议继续分析，优化扫描配置。
分阶段测试
AppScan 的扫描过程分为“探索”和“测试”两个阶段，默认情况下，使用的是完全扫描模式，即是边探索边测试的。如果网站比较大，建议考虑先探索后测试的模式。
如当 URL 达到 5000，需要进行的测试达到 50000 的时候，可以暂停扫描，手工停止探索，选择“继续仅测试”。对已经发现和分析的页面进行测试，测试完毕，再来选择“继续仅探索”，即：
继续仅探索 --- 继续仅测试—继续仅探索 - 仅测试的一个循环过程。
在这个过程，一个阶段结束以后，建议查看下 .Scan 文件的大小，如果大小超过了 500M，则建议考虑任务分解，可以根据目录把一个扫描任务分解为多个，或者根据扫描策略来进行分解。
该方法是利用了 AppScan 扫描过程中，探索测试可以分离，而且支持扫描过程中断后继续扫描的特性。
按照业务分解扫描任务
在实际工作中，我们扫描的一个大型网站，往往包含多个频道，而每个频道可能需要的扫描配置都不同，这些配置甚至互相冲突。如一个网站的提供了 BBS 论坛功能：
http://www.Test.com/WWW.TEST.COM/showthread?channel=1&thread=1001 http://www.Test.com/WWW.TEST.COM/showthread?channel=30&thread=2001
对于这样的页面，访问后发现页面结构相同，只是文本内容不同，则应该使用“冗余路径限制”参数，控制扫描次数，没有必要多次扫描。
同时，该网站的一个服务频道存在如下的页面：
http://www.Test.com/default.aspx?content=inside_executives.htm http://www.Test.com/default.aspx?content=privacy.htm
即上面提到的业务类型的“冗余路径”，应该多次扫描，配置上要求增大“冗余路径限制”参数。
在这种情况下，就很有必要根据业务分别建立扫描任务，每个任务采用不同的扫描配置。
检查阶段
在扫描执行过程中，需要检查，看是否存在下面的情况：
- 提示网络连接不上，或者提示部分页面无法打开。则检查是否是扫描速度过快，服务器不能承受不了，根据情况修改扫描配置 - 连接 - 通信和代理，增加“超时”数，并考虑减少“并发线程数”，以允许更长时间的等待页面影响并减少对服务器的访问连接数。
- 发现扫描出的安全问题，包含我们不关心的安全隐患，则取消掉这些规则。如发现了一个安全隐患，类型是“SQL 注入文件写入（需要用户验证）”，该问题是需要用户根据提示来检查的，并且是针对 SQL 数据库的，如果我们使用的数据库不是 SQL 数据库，或用户确认后没有发现线索，则就可以在扫描配置 - 测试 - 测试策略中取消选择该策略。
- 执行“计划阶段”的检查，看是否还存在“伪静态页面”，“业务类型的冗余路径”等，如果存在，则调整扫描配置。
分析阶段
在分析阶段，结合业务特点，检查是否扫描范围，分析扫描结果，并针对扫描出来的问题，进行分析，产生多种类型的报告等。
扫描结果检查
扫描结束后，建议切换到“应用程序数据”视图中，对页面进行分析，检查是否核心页面都被测试到了。重点检查如下部分：
- 交互式 URL：一些页面，必须输入正确的信息，才可以跳转到下一个页面，比如查询手机欠费的页面，必须输入正确的 11 位手机号码；查询身份信息的页面，必须输入 18 位的身份证号才可以进入后续页面。如果没有配置，AppScan 怎么知道输入这些信息？所以如果存在“交互式”URL，可以选择该 URL 以后，鼠标右键，选择手动探索，在 AppScan 浏览器中访问这些页面，输入对应的数据，则 AppScan 会自动记录这些输入，并填充到扫描配置 - 自动表单填充中。
- 中断链接：看哪些页面在扫描过程中，访问出错或者无法访问，如针对 time out 的页面，就可能是因为网络原因，扫描过程中没有及时响应，可以选择“重试所有中断链接”重新进行访问。
报告分析
我们需要对报告进行对比分析或者报告汇总合并，方法如下：
- 增量分析：在实际工作中，经常对一个网站进行定期扫描，那么我们可以使用报告对比功能，对比两次产生的结果，检查哪些问题已经修改，哪些是新发现的安全隐患。方法是选择报告 - 增量分析。
- 报告汇总和合并：而如果我们在执行阶段，按照业务或者目录进行了分解，最后可能需要对多份扫描结果进行合并和汇总，合并过程中重复的问题只记录一次，如扫描任务 A 和任务 B 都发现了 apply.jsp 的 ID 参数存在 XSS 安全隐患，则合并后只记录一次。报告的合并需要使用到 AppScan 企业版，其具有 AppScan 标准版的扫描功能和强大的报告汇总功能，可以产生仪表盘，报告的对比分析，趋势分析等。可以把 AppScan 标准版的报告发布到 AppScan 企业版中，方法是菜单栏中依次选择文件 - 导出 - 将结果发布到 AppScan Enterprise。
图 7. AppScan 标准版的扫描结果发布到企业版
案例分析
工作中遇到一个案例，使用 AppScan 扫描扫描了 3*24 小时，扫描的 scan 文件已经达到 9G；扫描还在持续进行中，总体进度完成了 30%，可以想象扫描速度已经很缓慢，还需要多长时间才可以完成扫描？扫描完成以后如此大的结果文件是否可以成功打开和修改保存 ?
按照我的经验，如果扫描结果文件大于 1G，那就很有必要立即停止扫描，进行配置分析。我们的分析过程如下：
- 和用户讨论，确认关心的安全问题，根据这些安全问题制定测试策略；讨论后确定选择“SQL 注入”和“跨站点脚本编制”两种类型的安全隐患。
- 确定网站范围，被扫描应用是典型运营商门户网站，重点要扫描门户网站自身和其上面提供的“网上营业厅”服务。
- 分析被测网站，使用 AppScan 配置了网站主页面，然后选择“仅探索”运行 20 分钟后，发现 30，000 多个页面。停止探索，开始分析页面。
- 分析发现该网站同一个链接，存在 http、https 访问的不同情况，而且两种访问方式访问到的页面内容相同，则过滤掉 https 的请求，集中测试 http 请求。
- 分析发现存在大量的“伪静态页面”，如：
http://www.Test.com//focus/satisfy/file5.html http://www.Test.com//focus/satisfy/file6.html
在扫描配置 - 排除路径和文件中：
排除所有该类型的页面；.*file\d+.html
增加“例外”，对该类型的页面只扫描 file1.html 和 file20.html
- 同时，发现了 swf 文件，应该不准备扫描 Flash，所以在“排除文件类型”中，设置根据后缀名排除 swf 文件。
- 发现
http://www.Test.com/service
目录下存在大量如下类型的页面，都是 menu 参数值不同，访问以后发现出现的是页面中有不同的超链接：http://www.Test.com/service/Business.do?menu=Query http://www.Test.com/service/Business.do?menu=Open http://www.Test.com/service/Business.do?menu=Service
确认该页面是业务类型的“冗余路径”，应该全面扫描，则需要把“冗余路径设置”调整为比较大的参数，同时该频道是网上营业厅频道，也要求用户先登录。所以针对该目录建立一个单独的扫描任务，只扫描该目录和其下子目录。
- 分析发现 index.jsp 在多个目录下出现，而且每次出现都有两种格式，即没有参数和有固定的三个参数，每次的参数值都相同。如：
访问上面的页面，发现内容相同，则说明是否带这三个参数不会影响探索发现更多的页面，则可以设置这三个参数每次是否出现，是否有不同值都可以认为是同一个页面。
设置方法：扫描配置中依次选择“参数和 Cookie”来实现。然后增加 queryType，applyArea，kbKey 三个参数，均设置为“是否有参数”、“参数是否变化”不影响测试的模式。
- 切换到“应用程序视图”，分析“中断链接”，发现一些页面存在“范围内容超过最大容量的”的情况，在 IE 浏览器中直接访问，发现这些页面存在死循环，页面内容无限递增。则在扫描配置 - 排除路径和文件中排除这些页面。
- 根据以上设置，建立了两个扫描任务，均扫描“SQL 注入”和“跨站点脚本编制”。重新探索后，页面总数减少到 4000 多，测试用例数减少到接近 50，000，两个扫描任务均在 8 个小时内完成。
总结
AppScan 作为一种自动化的扫描设置工具，我们了解其工作原理后，需要根据被测系统的业务特点和网站结构特点，优化配置，从而可以快速的针对性扫描。
常用的设置是可以利用其“探索”功能，快速得到结构，然后分析是否存在“伪静态页面”，业务上的“冗余路径”页面，“参数重复”页面等，在扫描配置中对应设置。
同时，如果设置后网站规模还是比较大，则可以根据业务分解为多个扫描任务，从而分而攻之，快速扫描，并结合企业版等工具，综合汇总分析。
参考资料
学习
- 查看本系列的第一部分：“Rational AppScan 扫描大型网站，第 1 部分: 工作原理及技术分析”。
- “Rational AppScan: 全面检测 Web 安全漏洞的利器”（developerWorks，2007 年 11 月）：您的 Web 应用安全吗？仅仅是防火墙能够保证 Web 应用的安全吗？如何避免遭受黑客利用跨站点脚本攻击（Cross Site Scripting Flaws）等由 OWASP所公布的 Web 应用安全漏洞入侵您的网站？本讲座将为您一一介绍这些关于 Web 应用安全的常见问题。同时，还将为您介绍专门面向 Web 应用安全检测的自动化工具 IBM Rational AppScan。并介绍如何运用 Rational AppScan 来自动化检测 Web 应用的安全漏洞，从网站开发的起始阶段就扫除 Web 应用安全漏洞。
- “使用 Rational AppScan 保证 Web 应用的安全性，第 1 部分: Web 安全与 Rational AppScan 入门”（developerWorks，2007 年 12 月）：本文将从对 Web 应用现状的分析入手，通过列举常见的攻击手段，阐明 Web 应用目前面临的挑战，同时，通过对 Rational AppScan 平台的介绍，协助企业制定 Web 应用安全解决方案，为企业的 Web 应用披上盔甲。在第一部分，将介绍 Web 安全与 Rational AppScan 的入门知识。在后续的 第二部分 将介绍如何使用 Rational AppScan 应对 Web 应用攻击。
- “使用 Rational AppScan 保证 Web 应用的安全性，第 2 部分: 使用 Rational AppScan 应对 Web 应用攻击”（developerWorks，2007 年 12 月）：本文将针对 Web 安全的现状、根源、以及 Rational AppScan 产品的技术细节做全面的介绍，最后阐述IBM解决方案给企业带来的深层次价值。
- “Rational AppScan 入门简介”（developerWorks，2008 年 6 月）：本次演示将帮助您了解一个面向 Web 应用程序与 Web 服务的黑箱安全扫描工具——Rational AppScan。利用 AppScan，应用程序开发团队在项目交付前，可以对所开发的应用程序与服务进行安全缺陷的扫描。
- “IBM Rational AppScan Enterprise Edition 护驾企业 Web 应用安全，第 1 部分：企业级 Web 应用安全解决方案介绍及其特点”（developerWorks，2008 年 9 月）：本文分为两部分，第一部分将从 Web 应用安全解决方案的演进入手，探究解决方案的发展之路，并对文中称之为“战略方法”的企业级解决方案及其特点进行深入分析。
- “IBM Rational AppScan Enterprise Edition 护驾企业 Web 应用安全，第 2 部分：企业级 Web 应用安全解决方案实例”（developerWorks，2008 年 9 月）：本文分为两部分，第二部分中，将从开发人员、安全管理员、经理等角色出发，用实例的形式展示出使用统一的管理平台后，给企业安全管理带来的方便性、统一性和其它优势。
- “Web 应用安全利器：Rational AppScan”（developerWorks，2010 年 2 月）：IBM Rational AppScan 是全面的 Web 应用安全解决方案，为 Web 及 Web 2.0 应用提供了扫描、报告和修复建议等功能，可以帮助开发者在项目起始阶段就能全面准确地发现并解决安全问题。本文从新手入门的角度，为您全面介绍了 Rational AppScan 的使用方法，帮助您了解并在实际应用中运用这一功能强大的自动化 Web 应用安全检测工具。
- 查看演示：Rational AppScan 入门简介：Web 应用与 Web 服务安全扫描工具，本次演示将帮助您了解一个面向 Web 应用程序与 Web 服务的黑箱安全扫描工具——Rational AppScan。利用 AppScan，应用程序开发团队在项目交付前，可以对所开发的应用程序与服务进行安全缺陷的扫描。
- 通过多媒体课堂“Rational AppScan: 全面检测 Web 安全漏洞的利器”，深入了解 Rational AppScan。
- 访问 UML 资源中心，获得关于统一建模语言（Unified Modeling Language，UML）的入门知识、技术资源和最佳实践。
- 访问 IBM developerWorks 中国网站 Rational 专区，获得关于 IBM Rational 软件交付平台（Rational Software Delivery Platform）产品的技术资源和最佳实践。
- 订阅 IBM developerWorks 时事通讯，一份关于 developerWorks 指南、文章、下载、社区活动、网络广播和技术讲座的电子周刊。
获得产品和技术
- 下载免费的 IBM Rational AppScan Standard Edition（标准版）试用版。
- 访问 Rational AppScan 产品专题，了解最新的 IBM Rational AppScan 产品文档和产品信息，获得关于 IBM Rational AppScan 及与 Web 应用安全相关的技术文档和参考资源，还可以查阅产品概览、产品手册、产品技术支持、试用版下载，以及相关文章、教程、多媒体课堂和产品演示等信息。
- 获取免费的 Rational 软件工具包系列，了解最新的 IBM Rational 软件开发工具技术文档和资源。
- 下载更多免费的 IBM Rational 试用版软件，了解 IBM Rational 软件的最新特性。
- 获取更多 IBM 试用版软件，并熟练掌握来自 DB2®、Lotus®、Tivoli®，以及 WebSphere® 的开发工具和中间件产品，用这些试用版软件开发您的下一个项目。这些试用版软件可以免费直接从 developerWorks 下载。
讨论
- 加入 developerWorks 中文社区，developerWorks 社区是一个面向全球 IT 专业人员，可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。
- 加入 IBM 软件下载与技术交流群组，参与在线交流。
- 在计划阶段：明确目的，进行策略性的选择和任务分解。
-
关于Rational AppScan Standard扫描过程中发生的通信错误
2015-12-10 14:02:28
-
性能测试知多少---测试环境搭建
2015-12-08 14:02:00
在进行性能则试前，需要完成性能测试的搭建工作，一般包括硬件环境、软件环境及网络环境，可以要求配置和开发工程师协助完成，但是作为一个优秀性能测试工程师，这也是你的必备技能之一。性能测试环境与功能测试环境的区别
那么性能测试环境与功能测试环境有什么不同呢？性能测试对测试环境的干净、独立性要求更高，更为严格。对于一个相对较规范的公司，都会建立其独立的研发环境、测试环境、线网环境（最终运行软件的环境）。
（
这里多扯一点，系统可以分为C/S架构的系统与B/S架构的系统，C/S架构的系统又可以分为两种，第一种是基本不用与服务器连接的，比如我们用到的java虚拟机JVM，photo shop平面处理软件，我们可以开启软件更新功能，这时软件向服务器发请求，查当前版本是否是服务器端发布的最新版本，然后，提示用例是否需要更新或下载最新版本的软件。当然，我们也可以关闭更新功能或不检测更新。那么这个软件一样可以在电脑上运行。对于这类软件，我的主要测试环境就是用户的电脑。不同硬件配置、不同操作系统下对软件一系列，从安装使用到卸载。除了验证软件与硬件和系统的兼容性能，还需要验证与其它软件是否兼容。
第二种类型的C/S软件要时刻与服务器与连接，比如我的在线网游，QQ聊天工具等。从软件的启动就需要与服务器进行连接，对于此类软件，我们测试环境的重点依然是用户电脑，但服务器端必须也有一个相对应的测试环境支撑。
对于B/S的系统，我们测试环境的重点就要由用户电脑转为服务器端了，因为系统的所有功能都是由服务器端传递给用户的，所以需要验证服务器传递来的功能是否可用，以及功能的容错能力等。
）
再回到测试环境的问题上，对于一些企业为了节约资源，进行功能测试的测试环境，一台服务器可以运行多个系统，通过技术手段可以使系统之间是不会相互影响的（以前公司就是一台服务器上跑多个tomcat）。因为功能测试的重点大于系统对客户端发来的请求是否可以进行正确的处理。
那么性能测试为什么对系统的环境要求干净、独立呢？性能测试是要对整个系统运行的软件硬件环境进行测试的，如果某环境下运行多个系统，就很难判断其中的某个环境对资源的占用情况。
性能测试环境包含内容
一般web应用系统分为3层架构（在系统架构一章中有介绍）
* 表现层（web服务器）
* 业务逻辑层（应用服务器）
* 数据层（数据库服务器）
性能测试环境包含内容：
硬件：服务器、客户端、交换机等。
软件：数据库、中间件、被测系统、操作系统等。
网络：有线/无线/宽带、网络协议等。
如何保证测试环境与真实生产的一致性
保证性能测试与真实生产环境的一致性，具体从以下三个方面来看：
1、硬件环境，包括服务器环境、与网络环境
如服务器的型号以及是否和其它应用程序共享此服务器，是否在集群环境下，是否通过BIGIP进行负载均衡，客户使用的硬件配置情况，使用的交换机型号，网络传输速率。
2、软件环境
版本一致性
包括包括操作系统、数据库、中间件的版本，被测系统的版本。
配置一致性
系统（操作系统/数据库/中间件/被测试系统）参数的配置一致，这些系统参数的配置有可能对系统造成巨大的影响。所以，除了保证测试环境与真实环境所使用的软件版本一致，也要关注其参数的配置是否一致。
3、使用场景的一致性
基础数据的一致性
包括预测的业务数据量，以及数据类型的分配。很简单的一个列子，一个系统的数据库只有10条数据和一条数据库里几千万条数据，我们在对其进行性能测试时，得到的性能指标可能会有非常大的差别。
为了保证每次测试环境的更加一致性，磁盘的使用情况以及磁盘的碎片情况也会或多或少的影响的性能。
使用模式的一致性
尽量模拟真实场景下用户的使用情况，其实，我们在做性能测试前期的需求分析，其主要目的也就是为了更真实的模拟用户的使用情况。
性能测试环境的实施策略
上面讲测试环境与生产环境保持一致所需要注意的内容。其实在实际的测试中，我们很难搭建出与生产环境完全一致的一个测试环境，除非我们暂停生产环境用户于进行性能测试，这往往是不可能。一方面某些生产环境是不允许被暂停的，另一方面也为生产环境的安全性考虑。
性能测试环境并不像功能测试环境，为了节省资源可以一台服务器上运行多个系统。由于性能测试的特殊性，整个测试环境需要在严格的独立监控下管理，在很多情况下，我们很难申请到足够的且一致的资源（说白了就是老板是否愿意出钱给你买服务器搭建系统）。对于一个并未上线的项目，其生产环境的配置也属于暂定状态，性能测试的目的就是为了确定具体生产环境的硬件配置。这个时候更不可能用过高的配置来搭建性能环境（除非现成的环境放着不用）。
我们一般通过两种策略来搭建性能测试环境（预估方式均有误差）
1、通过建模的方式实现低端硬件对高端硬件的模拟
通过配置测试来计算不同配置下的硬件性能和系统处理能力的关系，从而推导出满足系统性能的真实配置情况，这种模拟需要精确的建模，模型的采样点越多，那么得到的结果越精确，从而将在低端配置下的性能指标通过该模型转化为高端配置下的最终预计性能指标。
例如：搭建一个低端环境，首先需要对这个环境的CPU和内存进行单独的性能基准测试，同过在不同的配置的性能测试，得到一个基准信息列表，当然，在进行这个性能测试的过程中，我们要确定硬件是系统的瓶颈。如果只用一个CUP，在性能测试过程中，其使用率很低，但得到的性能数据都非常底，这起码说明CUP不是系统的平静，这种情况下就无法得到想要的基准值。
如上图，在一颗CPU情况下，运行100个用户且CUP使用率接近饱和（100%）。在增加至两颗CUP的情况下，可以运行190个用户且UPU使用率接近饱和（100%），以此做记录，那么我们就可以推算出运行800个用户需要多少颗CUP。
如果你在实际应用中使用的CUP型号及其频率并非完全一样，这个时候可以使用EVEREST工具计算每种CUP的得分，对其性能进行评估。
内存也可以使用此方法进行测试推导，这里需要我们多进行试验，对硬件的性能以及对整个项目的结构都要做深入的了解，以便尽量减少误差。
2、通过集群的方式计算
对于较大的系统来说，单台服务器的处理能力是有限的，通常都会采用集群的方式来进行负载均衡，完成对海量请求的处理。虽然无法获得整体集群的测试环境，但是可以对集群上的一个节点进行性能测试，得出该节点的处理能力，再计算每增加一个节点的性能损失，同样也可以能过建模的方式得到大型负载均衡情况下的预计性能指标。
例如:首先在单台服务器上获得具体的性能指标，每台服务器能够承受500用户并发，平均TPS为60，响应时间为2秒，接着，添加负载均衡策略，再次测试负载策略下的数据损耗。得出数据后添加1台负载均衡服务器，测试在两台服务器下每台服务器的性能指标，以此类推，可以得到下表：
随着负载均衡服务器的添加，平均每台服务器的处理能力会逐渐稳定，从而了解在什么情况下需要多少台负载均衡服务器。
对于测试环境的搭建，建议生成专门的文档进行管理，并进行配置管理，确保对测试环境做到基线控制。
------------------------------------------
这个性能测试系列以理论与性能测试的整体讲解为主，市面上的大部分书籍借着性能测试的表皮在讲性能测试工具loadrunner，那我何不找份loadrunner使用手册来看更好。
-
从架构师类比测试工程师的能力特点
2014-05-08 16:42:33
-
网站性能工具Yslow的使用方法
2013-12-23 10:34:03
Yslow是雅虎开发的基于网页性能分析浏览器插件，从年初我使用了YSlow后，改变了博客模板大量冗余代码，不仅提升了网页的打开速度，这款插件还帮助我分析了不少其他网站的代码，之前我还特意写了提高网站速度的秘籍，就是通过这款插件分析得出的。网络上已经有不少Yslow使用说明了，本文我想介绍下我使用Yslow的方法和一些别人没提到的小技巧。
Yslow的安装方法
现在Yslow已经有很多版本了，本文介绍的是3.0.4最新版，打开Yslow官网就能看到有四个版本可供选择：火狐（firefox）浏览器、谷歌（chrome）浏览器、欧朋（opera）浏览器和移动版。
安装Yslow要先安装 Firebug（本地址以火狐为例），两种方法启动Yslow：1、打开Firebug窗口，选择Yslow选项。2、直接点击火狐右下角的Yslow启动按钮。
（图1：Yslow的启动界面）
点击 Run Test 运行Yslow，也可以点击 Grade, Components, 或Statistics选项开始对页面的分析，如果在 Autorun YSlow each time a web page is loaded 上打上对勾，它将自动对以后打开页面进行分。
注意图中的红框，这里是规则集，YSlow （V2）包含了所有22个测试的规则，YSlow （V1）包含原始13规则，小网站或博客-这个规则集包含14个规则，适用于小型网站或博客，建议对号入座。
雅虎评估网站性能的23条军规
雅虎曾经针对网站速度提出了非常著名34条准则：《Best Practices for Speeding Up Your Web Site》。而现在将34条精简为更加直观的23条，并针对每一条给出从F~A的评分以及最终的总分。
而现在23条网站性能优化建议在YSlow的官网首页就能看到，当然也可以不看，在使用Yslow后，在控制面板里就会给你评分提示，和改进建议。
Grade(等级视图)—Yslow的第二个选项卡
（图2：Yslow给出的网站性能评分）
Yslow给出的网站性能评分，从F~A，A是最好的，通过测试卢松松博客来看，网站有4处得分最低，例如图2中的最低分提示：我博客的HTTP请求太多。其中应用了14个外部JS、3个CSS文件（之前我已从6个合并为3个）、14个CSS背景图片。
Yslow的建议是让我合并这些，至于合并CSS引用图片我在“提高网站打开速度的7大秘籍”中介绍过。
Components（组件视图）—Yslow的第三个选项卡
（图3：通过Components考验查看网页各个元素占用的空间大小）
通过Components考验查看网页各个元素占用的空间大小，例如我博客某个页面，有236个images（图片），占用了489.2K，通过详细查看，发现来自gravatar（评论头像）的引用图片非常大，在加上我博客本省评论量就打，每个头像就占用几K，几百个就占用了整个网页50%的大小，而且图片还是引用的，加载就更慢。
所以，我得出的结论是：gravatar虽然增强了互动性和个性，但也结结实实影响了网站速度。
Statistics（统计信息视图）—Yslow的第四个选项卡
（图4：Yslow的统计信息视图）
左侧图表显示是页面元素在空缓存的加载情况，右侧为页面元素使用缓存后的页面加载情况。从图中可以直观的看出（尤其是我标的红框），这个网页263个HTTP请求，网页的大小达到773.9K，意味着打开没打开一个页面几乎需要下载1M的东西，而通过使用缓存后我们可以看到效果图片基本靠缓存，而网页的总大小压缩到43.2K。
Statistics这个统计信息视图工具和Components（第三选项卡）一样，只是效果更直观，如果要获得性能优化建议还是要看Grade（第二选项卡）的详细建议。
Tools（辅助工具）—Yslow的第五个选项卡
（图5：Yslow提供的小工具）
JSLint是一个强大的工具，它可以检验HTML代码以及内联的Javascript代码，通过JSLint发现了google analytics上的一个js错误。
ALL JS：查看你这个网页上一共引用了多少JS。
All JS Beautified：把所有JS放在打开的页面中，利用站长统一检查（我感觉作用不大）。
All JS Minified：同上，但它显示的是压缩过的js代码，如果你要JS优化，它已经给你优化好了，来过来直接用。
All CSS：显示你网页所有CSS文件。
YUI CSS Compressor：显示网页压缩后的CSS文件，也是拿过来可以直接用的。
All Smush.it™：图片在线优化网站，点击它后会自动跳到smushit网站上给你自动优化CSS图片，该网站提供了优化前与优化后的对比，点击直接下载优化后的图片，在覆盖到自己网站上就可以了，强烈推荐。
Printable View：这个是打印用的，部门开会、前端设计师讨论、向老板汇报时估计用的上。
-
Web性能优化方案
2013-12-18 15:32:48
-
http 错误代码表
2013-12-18 14:10:05
-
JMeter基础之—录制脚本
2013-12-17 14:41:37
Jmeter 是一个非常流行的性能测试工具，虽然与LoadRunner相比有很多不足，比如：它结果分析能力没有LoadRunner详细；很它的优点也有很多：
l 开源，他是一款开源的免费软件，使用它你不需要支付任何费用，
l 小巧，相比LR的庞大（最新LR11将近4GB），它非常小巧，不需要安装，但需要JDK环境，因为它是使用java开发的工具。
l 功能强大，jmeter设计之初只是一个简单的web性能测试工具，但经过不段的更新扩展，现在可以完成数据库、FTP、LDAP、WebService等方面的测试。因为它的开源性，当然你也可以根据自己的需求扩展它的功能。
我觉得它更像一个瑞士军刀，小巧，且功能齐全。初次认识Jmeter的时候，我觉得它不好，是因为相比LR来说，它没有脚本录制功能，也许不是没有，只是我不知道，因为文档上介绍的是这样，我要做一个web性能测试的话，就手动的一个个添加循环控制器、http信息管理头、http请求等等各种元件。如果测试的脚本较多时，这无疑是个体力活。
Badboy是一款不错web自动化测试工具，利用它来录制脚本，并且录制的脚本可以直接保存为JMeter文件来使用。我无疑给我们带来了很大我方便。
----------------------我的环境------------
Badboy version 2.1.1
Apache JMeter-2.3.4 (需要JDK环境来运行)
--------------------------------------------
第一种方法：通过bodboy来录制脚本。
1.打开人badboy工具，点击工栏目上的红色圆形按钮，在地址栏目中输入被测试项目的地址。
录制完成后，点击工具栏旁边黑色按钮，结束录制。
选择“文件”--àExport to Jmeter…
2.打开Jmeter工具，选择“文件”-->“打开”选择刚才保存的文件(.jmx类型)，将文件导入进来了。
第二种方法，通过JMeter自身设置来录制脚本。
这种方法是我才发现的（鄙视一下自己的无知，嘻嘻~！），觉得方法比较简单。
1. 打开JMeter工具
创建一个线程组（右键点击“测试计划”--->“添加”---->“线程组”）
创建一个http代理服务器（右键点击“工作台”--->“添加”--->“非测试元件”--->“http代理服务器”）
完整的设置参照下图：
2. 下面来设置一下IE浏览器
IE--->“internet属性”--->“连接”--->“局域网设置”
设置为本机IP就可以了，注意端口号要与Jmeter上的端口号一致。默认都是8080端口。
3. 现在点击jmeter上的“启动”按钮，打开浏览器输入需要录制web项目地址，jmeter会自动记录你IE所访问的页面。
PS:第二种方法是我刚才知道的一种，关于这两种方法哪个更好，现在还不知道，但第二方法有通过IE浏览器辅助的，我想可能只要IE能打开的，它都能记录，但它录制的脚本看上去比较乱（感觉上）
还就是http代理服务器的设置，（比如：分组：每一个组放入一个新的服务器---只有这一个选项才能正常录制），有时间再仔细比较一下两种方法的不同之处。
-
Jmeter安装
2013-12-16 15:12:05
-
利用 mount 指令解决 Read-only file system的问题
2013-12-09 09:54:14
-
WEB安全测试要考虑的10个测试点
2013-11-27 15:38:33
-
性能监控之监控SQL语句
2013-09-29 09:42:52
-
oracle-日常维护常用的55条语句
2013-09-29 09:23:51
-
JAVA中Get和Post请求的区别收集整理
2013-09-26 10:15:09
-
Oracle-常用监控SQL
2013-09-25 15:59:04
-
TD使用遇到的问题以及解决的方法
2011-04-19 13:37:22
个人总结TD使用遇到的问题以及解决的方法
问题一：
安装过程中，提示用户名密码错误，无法进行下一步的安装，原因数据执行保护DEP不允许该程序执行。解决方法：右击“我的电脑”选择“属性”高级－》性能【设置】数据执行保护，选择选项：为除下列选定程序之外的所有程序和服务启动DEP（U），点击【添加】按钮，找到TD安装程序中的bin目录下/或者是C:\Program Files\Common Files\Mercury Interactiver 的checku.exe,添加上即可。
2.Checker时,显示 SendAllQualified Service 服务失败, cannot get properties -service does not exitst到网上查看解决办法，以下解决办法是不正确的：
解决方案，在运行＼打开 框内输入：1、 直接运行C:\Program Files\Common Files\Mercury Interactive\TDAPIServer\SendAllQualifiedApp.exe
2、 运行“sc.exe create SendAllQualifiedApp binpath= "C:\Program Files\Common Files\Mercury Interactive\TDAPIServer\SendAllQualifiedApp.exe" type= own start= auto displayname= "SendAllQualifiedApp"”这个命令创建“SendAllQualifiedApp”服务，然后在控制面板-管理工具-服务里面查找到“SendAllQualifiedApp”服务启动，你会发现启动不了。（要删除此无效服务的方法是在CMD里运行“sc delete SendAllQualifiedApp”）
如下才是解决的正确方法：
1、 打开cmd命令窗口；
2、 转到C:\Program Files\Common Files\Mercury Interactive\TDAPIServer\路径，运行“SendAllQualifiedApp.exe /install” ，在到控制面板-管理工具-服务里面查找服务启动。test director checker ,重新检测，SendAllQualified 变为绿色，恢复正常。
4，TD在使用时出现The RPC server is unavailable
详细介绍如下：
1). RPC服务未启动。解决：控制面板-管理工具-服务-“Remote Procedure Call(RPC)”，启动一下（自动），服务状态“启动”；
2).服务器端IIS没装。解决：安装IIS。以2000系统为例，控制面板-添加删除程序-添加删除windows组件-“Internet 信息服务(IIS)”打一下勾，下一步……1.TD 检查，OTApool sevice 失败
可以使用sc命令修复
sc.exe create OtaPool binpath= "C:\Program Files\Common Files\Mercury Interactive\TDAPIServer\OTAPool.exe" type= own start= auto displayname= "OtaPool"
2.TD数据库的默认密码为 ：tdtdtd
C:\Program Files\Common Files\Mercury Interactive\DomsInfo下。这个目录包含了Doms.mdb文件（用户信息和工程列表）、connection strings（连接字符串）、parameters（参数）、global style. sheets（全局风格表）、the database template（Empty_DB.mdb）（一些临时数据）3.修改TD超级管理员的密码
C:\Program Files\Common Files\Mercury Interactive
打开Doms.mdb，密码为tdtdtd，进入admin表，将ADMIN_PWD的值改成空，或者改成455575（密文），明文对应为123456，重启TD服务器
打开TD登录，其管理员的密码可以是空或者1234563.修改TD每个项目管理员(admin)的密码
打开TD_DIR\项目\TestDir.mdb中的users表将admin的US_PASSWORD清空，则密码为空。
4.普通项目用户，登陆site administrator，在user tab重置该用户密码。
5.当TD登录时候出现 网络错误或磁盘错误,请检查server服务是不是异常停止了,这是犹豫系统的漏洞造成的,请用360扫描漏洞之后升级系统即可注意:
如果安装IIS时出现“将加密数据写入Web服务器配置数据库时出错” 的提示：
报错的可能是：0x8009000f=对象已经存在;0x80070006=句柄无效;IIS Admin Service 服务无法启动;World Wide Web Publishing Service 服务无法启动 ……出现这种问题，可以选“不加密写入”和“全部不加密写入”，但若在完成安装后对数据的安全有影响，并且这样的方式写入可能还是会出现一些其它的问题，如IIS的相关服务不能启动如是而已。解决这样问题的方法是:删除C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\Machine Keys 下的所有文件，然后点击“重试”，若在使用“不加密写入”或“全部不加密写入”后IIS有相关服务出现问题。那么就需要重新安装IIS，若上安装过程出现问题只需按照上边的操作，删除对应文件夹的所有文件即可。该方法确实有效 !
DEFECT
BG_ACTUAL_FIX_TIME 缺陷修复的实际时间
BG_RESPONSIBLE 被分配给
BG_CLOSING_VERSION 已关闭缺陷的版本
BG_CLOSING_DATE 关闭日期
BG_BUG_ID 缺陷ID
BG_DESCRIPTION 描述
BG_DETECTED_BY 发现者
BG_EDTECTION_VERSION 版本
BG_DETECTION_DATA 发现日期
BG_ESTIMATED_FIX_TIME 估计修复的时间
BG_VTS 修改时间
BG_PLANNED_CLOSING_VER 计划关闭的版本
BG_PRIORITY 缺陷优先级
BG_PROJECT 项目
BG_DEV_COMMENTS 研发注释
BG_REPRODUCIBLE 能否重现
BG_SEVERITY 严重级别
BG_STATUS 缺陷状态
BG_SUMMARY 概要
TEST
TS_CREATION_DATE 建立日期
TS_DESCRIPTION 描述
TS_RESPONSIBLE 设计者
TS_ESTIMATE_DEVTIME 估计设计和生成测试的时间
TS_EXEC_STATUS 执行状态
TS_VTS 修改时间
TS_PATH 路径
TS_STATUS 状态
TS_STEPS 步骤
TS_TEMPLATE 模板
TS_NAME 测试名称
TS_TYPE 类型
TEST STEP
ST_ACTUAL 实际结果
ST_DESCRIPTION 描述
ST_EXECUTION_DATE 执行日期
ST_EXECUTION_TIME 执行时间
ST_EXPECTED 预期结果
ST_TEST_ID 测试资料
ST_STATUS 状态
ST_STEP_NAME 步骤名称
RUN
RN_DURATION 持续时间
RN_EXECUTION_DATE 执行日期
RN_EXECUTION_TIME 执行时间
RN_HOST 主机名
RN_OS_NAME 操作系统
RN_os_BUTLD 操作系统生成的编号
RN_OS_SP 操作系统的服务软件包
RN_RUN_NAME 运行名称
RN_STATUS 状态
RN_TEST_VERSION 测试的版本
RN_TESTER_NAME 测试员
REQUIREMENT
RQ_REQ_AUTHOR 作者
RQ_REQ_STATUS 覆盖状态
RQ_REQ_DATE 建立日期
RQ_REQ_TIME 建立时间
RQ_REQ_COMMENT 描述
RQ_VTS 修改时间
RQ_REQ_NAME 需求名称
RQ_REQ_PRIORITY 优先级
RQ_REQ_PRODUCT 产品
RQ_REQ_ID 需求ID
RQ_REQ_REVIEWED 被检查
RQ_REQ_TYPE 类型
TEST IN TESTSET
TC_EXEC_DATE 执行日期
TC_VTS 修改时间
TC_PLAN_SCHEDULING_DATE 计划执行日期
TC_PLAN_SCHEDULING_TIME 计划执行时间
TC_HOST_NAME 计划执行主机名
TC_TESTER_NAME 测试负责人
TC_STATUS 状态
TC_TEST_VERSION 测试版本
TC_ACTUAL_TESTER 测试员
TC_EXEC_TIME 执行时间
TESTSET
CY_CLOSE_DATE 关闭日期
CY_COMMENT 描述
CY_VTS 修改时间
CY_OPEN_DATE 打开日期
CY_STATUS 状态
CY_CYCLE 测试集 -
Failed to transmit data to network:[10054]connection reset by peer
2010-01-06 10:02:13
标题搜索
我的存档
数据统计
- 访问量: 20352
- 日志数: 17
- 文件数: 4
- 建立时间: 2007-09-20
- 更新时间: 2015-12-10
