第六章Web测试V1.1.pptVIP

安全性用例设计：登录 用例设计思想 正常和异常的用户名密码登录 SQL注入式攻击（如：mm‘ or ’2‘’1 ） 猜解密码的测试 不同权限用户登录 小贴士：安全性测试并不能最终证明应用程序是安全的。 /coderzh/category/151315.html 强口令规则 Web应用安全开发规范中的强口令策略： 规则.1：口令长度的取值范围为：0-32 个字符；口令的最短长度和最长长度可配置；口令的最短长度建议默认为6个字符。 规则.2：口令中至少需要包括一个大写字母（A-Z）、一个小写字母（a-z）、一个数字字符（0-9）；口令是否包含特殊字符要求可以配置。 规则.3：口令中允许同一字符连续出现的最大次数可配置，取值范围：0-9，当取值为 0 时，表示无限制，建议默认为 3。 规则.4：口令须设置有效期，最短有效期的取值范围：0-9999 分钟，当取值为0时，表示不做限制，建议默认：5 分钟；最长有效期的取值范围：0-999 天，当取值为 0 时，表示口令永久有效，建议默认：90 天。 规则.5：在口令到期前，当用户登录时系统须进行提示，提前提示的天数可配置，取值范围：1-99 天，建议默认：7 天。 强口令规则 规则.6：口令到达最长有效期后，用户再次登录成功但在进入系统前，系统强制更改口令，直至更改成功。 规则.7：口令历史记录数可配置，取值范围为：0-30；建议默认：3个。 规则.8：管理员/操作员/最终用户修改自己的口令时，必须提供旧口令。 规则.9：初始口令为系统提供的默认口令、或者是由管理员设定时，则在用户/操作员使用初始口令成功登录后，要强制用户/操作员更改初始口令，直至更改成功。 规则.10：口令不能以明文的形式在界面上显示。 规则.11：口令不能以明文的形式保存，须加密保存；口令与用户名关联加密，即加密前的数据不仅包括口令，还包括用户名。 规则.12：只有当用户通过认证之后才可以修改口令。 规则.13：修改口令的帐号只能从服务器端的会话信息中获取，而不能由客户端指定。 强口令测试 编号 SEC_Web_ AUTHEN_08 用例名称 强口令策略测试 测试目的 本测试为检查目标系统是否存在强口令策略。 用例级别 2 测试条件 已知Web网站地址 Web业务运行正常 Web业务存在帐号管理 已知正常用户的用户、口令 存在口令修改页面 执行步骤 使用正确的用户、口令登陆Web业务系统 打开口令修改页面 在新口令输入框中输入字母加数字的5位字符（如ab123）作为密码并提交，如果未提示“口令长度过短”等诸如此类的信息，说明存在弱点，完成测试。 在新口令输入框中输入6位数字（如123456）作为密码并提交，如果未提示 “口令字符需要大小写” 等诸如此类的信息，说明存在弱点，完成测试。 观察结果 预期结果 目标系统存在满足上述步骤的较严格的口令复杂度策略。 备注 上面只是举例说明口令复杂度的测试，实际上强口令策略还包括口令有效期、历史口令等，这些都要测试。对于一些Web应用（如移动网上客服系统）密码只能是数字组成，则不强制要求强口令。 测试结果 课程回顾 * 从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。 基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。 基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。 重要的是，还要从最终用户的角度进行安全性和可用性测试 Q A 这种最常见的模型中，客户端是第一层； 使用动态 Web 内容技术的部分属于中间层； 数据库是第三层。用户通过 Web 浏览器发送请求（request）给中间层，由中间层将用户的请求转换为对后台数据的查询或是更新，并将最终的结果在浏览器上展示给用户 * * * * 1、? ? ? ? 功能测试：检验系统是否满足功能需求说明中的功能需求；（1）? ? ? ? 连接：连接是否存在,是否正确;（2）? ? ? ? 表单：提交是否正确，是否返回必须的信息，服务器能否正确保留这些数据，后台运行的程序能否正确解释和使用这些信息；（3）? ? ? ? 数据检验：检验功能是否正常工作；（如省份的字段可能用一个有效列表进行校验；（4）? ? ? ? Cookies：如在COOKIES中保存注册信息，则确认该COOKIES能否正常工作且对这些信息加密；（5）? ? ? ? 应用程序特定的功能需求；2、? ? ? ? 负载/压力、流量测试、性能测试： 通过模拟大量用户的并发请求，给系统较大的负载，检测整个系统处理交易的能力；在反常数量或资源的情况下检测中间件系统在长时间、高负载下的运行处理能力，从而检验系统的稳