测试人生

发布新日志

  • HTTP错误汇总

    2016-08-06 11:35:52

    HTTP 400 - 请求无效

    HTTP 401.1 - 未授权:登录失败

    HTTP 401.2 - 未授权:服务器配置问题导致登录失败

    HTTP 401.3 - ACL 禁止访问资源

    HTTP 401.4 - 未授权:授权被筛选器拒绝

    HTTP 401.5 - 未授权:ISAPI 或 CGI 授权失败

    HTTP 403 - 禁止访问

    HTTP 403 - 对 Internet 服务管理器 的访问仅限于 Localhost

    HTTP 403.1 禁止访问:禁止可执行访问

    HTTP 403.2 - 禁止访问:禁止读访问

    HTTP 403.3 - 禁止访问:禁止写访问

    HTTP 403.4 - 禁止访问:要求 SSL

    HTTP 403.5 - 禁止访问:要求 SSL 128

    HTTP 403.6 - 禁止访问:IP 地址被拒绝

    HTTP 403.7 - 禁止访问:要求客户证书

    HTTP 403.8 - 禁止访问:禁止站点访问

    HTTP 403.9 - 禁止访问:连接的用户过多

    HTTP 403.10 - 禁止访问:配置无效

    HTTP 403.11 - 禁止访问:密码更改

    HTTP 403.12 - 禁止访问:映射器拒绝访问

    HTTP 403.13 - 禁止访问:客户证书已被吊销

    HTTP 403.15 - 禁止访问:客户访问许可过多

    HTTP 403.16 - 禁止访问:客户证书不可信或者无效

    HTTP 403.17 - 禁止访问:客户证书已经到期或者尚未生效 HTTP 404.1 

    无法找到 Web 站点

    HTTP 404- 无法找到文件

    HTTP 405 - 资源被禁止

    HTTP 406 - 无法接受

    HTTP 407 - 要求 身 份 验 证

    HTTP 410 - 永远不可用

    HTTP 412 - 先决条件失败

    HTTP 414 - 请求 - URI 太长

    HTTP 500 - 内部服务器错误

    HTTP 500.100 - 内部服务器错误 - ASP 错误

    HTTP 500-11 服务器关闭

    HTTP 500-12 应用程序重新启动

    HTTP 500-13 - 服务器太忙

    HTTP 500-14 - 应用程序无效

    HTTP 500-15 - 不允许请求 global.asa

    Error 501 - 未实现

    HTTP 502 - 网关错误

    用户试图通过 HTTP 或文件传输协议 (FTP) 访问一台正在运行 Internet 信息服务 (IIS) 的服务器上的内容时,IIS 返回一个表示该请求的状态的数字代码。该状态代码记录在 IIS 日志中,同时也可能在 Web 浏览器或 FTP 客户端显示。状态代码可以指明具体请求是否已成功,还可以揭示请求失败的确切原因。

    日志文件的位置

    在默认状态下,IIS 把它的日志文件放在 %WINDIRSystem32Logfiles 文件夹中。每个万维网 (WWW) 站点和 FTP 站点在该目录下都有一个单独的目录。在默认状态下,每天都会在这些目录下创建日志文件,并用日期给日志文件命名(例如,exYYMMDD.log)。

    HTTP

    1xx - 信息提示

    这些状态代码表示临时的响应。客户端在收到常规响应之前,应准备接收一个或多个 1xx 响应。 

    • 100 - 继续。

    • 101 - 切换协议。

    2xx - 成功

    这类状态代码表明服务器成功地接受了客户端请求。

     • 200 - 确定。客户端请求已成功。

    • 201 - 已创建。

    • 202 - 已接受。

    • 203 - 非权威性信息。

    • 204 - 无内容。

    • 205 - 重置内容。

    • 206 - 部分内容。

    3xx - 重定向

    客户端浏览器必须采取更多操作来实现请求。

    • 302 - 对象已移动。

    • 304 - 未修改。

    • 307 - 临时重定向。


  • 转:如何寻找软件测试Bug 100%毕现的规律?

    2012-03-08 09:37:51

    引子:

      在实际工作中我们会看到这样2个现象:

      1、同样的bug,不同的测试描述出来,解决的结果不同。

      2、一些无法被解决的偶现Bug在好几个版本过后又得到了解决  

           解决后跟开发的沟通中了解到,是因为当时没有找到毕现的规律所以无法解决

      通过这两个现象告诉我一个道理,那就是:让Bug百分百毕现很有必要。

      今天我们就来讨论下如何找到能让Bug 100%毕现的规律。这种能力是我们测试所需要的。

    Bug毕现的重要性:

        Bug毕现的步骤可以提交开发效率,从而提高生产产品的效率,更好的保证质量。虽然我们不知道代码是如何设计的,但是我们可以帮助开发找到触发Bug的条件。

      我们都知道,目前在工作中,Bug是以100%毕现和非毕现(经常复现和偶尔复现)两种状态存在的。但我始终坚信:没有非毕现的Bug,只是我们没有找到能够让他100%毕现的规律

    Bug毕现的三种方法:

    一、逆向推理法

      首先要做的就是逆向推理,从时间最近的一次开始逆推,回想这段时间发生的事情(自己的操作,以及在操作期间其他程序或功能对其的影响),而不仅仅只是自己的操作。尽量在最短的时间将现场还原(这就需要在测试的过程中要“用心”,)

      可能有人问了,回想的“这段时间”是多久?

      1、容易复现的Bug,一般从本条用例开始操作到Bug出现就可以找到毕现的规律。

      2、较难复现的Bug,一般就需要追溯到上一条用例执行的操作或者结果。

      除了回想自己的操作,为什么还要留意一些别的事情?

      根据经验而言,一般不容易复现的Bug就是因为在复现Bug的同时忽略掉了其他程序对其本身操作的影响

      注:要想在最短的时间将现场还原,一定要注意细节,不要放过任何一个可能的细节。

    二、反复尝试法

      在经历了逆向推理之后,我们要做的就是“不断尝试”。

      为什么要不断的尝试呢?根据逆向推理尝试一两次不行吗?我想说的是:如果你能保证操作过程中的任何一个细节都考虑到了,并且都尝试了,那么就不用不断尝试了

      1、不断的尝试是对现场还原的一种帮助,有的时候我们记忆的时候对细节记忆的不是很清晰,只有不断的尝试,不断的找感觉,才能真正的做到现场还原。

      2、避免被表面现象所迷惑,发现一个Bug之后不要立即就提交Bug,可以反复多试几次,看看按照自己的操作是否可以100%毕现,如果可以毕现,说明我们找到了此Bug毕现的规律。(反复尝试可以帮助我们抓住Bug产生的本质性原因)

      我的原则是:提交的Bug尽量让其100%毕现

    三、判断猜测法

      判断猜测法需要建立在对产品的深度理解的基础上。我们需要根据对产品的深度理解,再结合相关测试经验进行“关联猜测”,然后根据猜测的操作进行实践。

      猜测点:模块交互部分(一级模块之间的交互、子模块与一级模块之间的交互均需考虑)、状态改变部分、用户角色转换部分等

      总之:只要是有变化的部分,就要考虑其变化对程序带来的影响

Open Toolbar