基于参数的导航站点的提问

扫描包含基于参数的导航的站点所需配置更改的说明。

缺省情况下，AppScan 的冗余路径限制为 5（可将某一请求发送到相同 URL 的最大次数，请参阅“探索选项”视图）。在一般站点中，这可避免不必要地重复测试。但是，当站点导航基于参数时，此低限制实际上会妨碍 AppScan® 彻底扫描站点，并且使用“常规扫描”模板的扫描运行几乎不会发现和测试站点的任何部分。

放宽冗余路径限制，或者将其完全禁用，都不能独立解决该问题。实际上，这可能会使 AppScan 进入无限循环，或者至少创建具有许多测试（以致 AppScan 耗尽内存）的扫描。这由两个原因引起：
  1. 在探索阶段中，将请求散列化时，AppScan 将包含其在请求中找到的所有参数和 cookie。在没有冗余路径限制的情况下，这些值的所有组合都将被考虑在内。

    例如，我们假定站点中某一部分中的每个页面均包含数百个指向某一脚本的链接，而该脚本从数据库中检索有关可供销售的商品的信息。这些链接包含一个名为 item_id 的参数，该参数在生成新页面时无足轻重，仅用于检索有关商品的信息。除非可从散列中排除 item_id，否则 AppScan 最终将请求此商品信息页面的数千个实例。

  2. 在测试阶段中，问题变得更加严重。假设请求中包含两个参数 par1 和 par2，并且 AppScan 遇到四个包含这两个参数的链接：
    http: // site.com/content.aspx?par1=a&par2=c
http: // site.com/content.aspx?par1=a&par2=d
http: // site.com/content.aspx?par1=b&par2=c
http: // site.com/content.aspx?par1=b&par2=d

    如果有 400 个测试适用于各参数，那么 AppScan 总共将发送 1600 个测试（当 par2=c 且 par2=d 时，对 par1 执行 800 个测试；当 par1=a 且 par1=b 时，对 par2 执行 800 个测试）！因此，除了从探索散列中排除这些参数外，还必须指示 AppScan 对各参数仅测试一次：对 par1 执行 400 个测试，对 par2 执行 400 个测试。

对于扫描带有基于参数的导航的站点，从上述内容中获得的原则便是：
  1. 探索阶段：忽略所有参数（导航参数除外）的值。
  2. 测试阶段：参数（导航参数除外）的值更改时，不创建新测试。

另请参阅：

使用基于参数的导航的站点

基于参数的导航模板