缺陷等级

缺陷 1. 软件缺陷的概述 1.1 软件缺陷定义 软件缺陷, 通常又被叫做bug或者defect, 即为软件或程序中存在的某种破坏正常运行能力的问题、错误,其存在会导致软件产品在某种程度上不能满足用户的需求. 软件缺陷是指存在于软件(程序、数据、文档中的)那些不符合用户需求的问题. 1.2 软件缺陷的表现形式 主要表现为三种形式:“缺陷”、“故障”、 “失效” 缺陷: 存在于软件中的偏差,可被激活，以静态的形式存在于软件内部，相当于bug; 故障: 软件运行中出现的状态，可引起意外情况，若不加处理，可产生失效，是一个动态行为； 失效: 软件运行时产生的外部异常行为结果，表现与用户需求不一致，功能能力终止，用户无法完成所需要的应用。 缺陷不一定就会导致故障,只要缺陷没被触发; 同样,故障不一定就会导致失效,只要故障处理的得当. 2. 产生软件缺陷的原因 产生软件缺陷的原因很复杂,原因各种各样,: 需求有缺陷 系统架构设计阶段有缺陷 程序设计阶段有缺陷 程序研发阶段有缺陷 测试阶段有缺陷 硬件有缺陷 3.缺陷的信息 为了便于缺陷的定位、跟踪和修改,要对说发现的缺陷,按照缺陷的严重程度、优先级、发现阶段、修复阶段、缺陷的性质、所属功能模块、西庸环境等方面进行分类和统计, 3.1 状态 New:缺陷的初始状态； Open：开发人员开始修改缺陷； Fixed：开发人员修改缺陷完毕；

1，B/S和C/S架构的区别？ 从测试的角度来讲。B/S架构需要重点考虑系统在不同的浏览器中的兼容性问题；C/S 架构需要考虑系统在不同平台的安装、卸载、升级 B/S 即Browser/Server(浏览器/服务器)结构,指浏览器和服务端，在客户机端不用装专门的软件，只要一个浏览器即可。 C/S 即Client/Server(客户机/服务器)结构,指客户机和服务端，在客户机端必须装客户端软件后才能访问服务器。 2，对HTTP协议怎么理解的？ http协议是应用层的一个数据传输协议，由请求和响应构成， 主要的请求方式有get和post两种，get请求的请求数据在请求头，post请求的请求数据在请求体 响应的数据也包含响应头和响应体。 3，常见的http状态码？ 200 请求成功 用于get/post请求 301 永久移动 302 临时移动 404 服务器无法找到资源，网页丢失 500 服务器内部错误 4，http请求头包含哪些信息？ content-type （作用：定义网络文件的类型和网页的编码 ） accept （作用：发送端（客户端）希望接受的数据类型） 5，get和post的区别？ get 请求数据参数放在请求头传送，请求地址长度有限制，一般用在获取数据。 post请求数据参数放在请求体传送，请求地址没有长度限制，一般用在提交数据。 6，什么是软件测试？ 软件测试就是使用软件

1 、问：你在测试中发现了一个bug ，但是开发经理认为这不是一个bug ，你应该怎样解决？ 首先，将问题提交到缺陷管理库里面进行备案。 然后，要获取判断的依据和标准： 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 根据用户的一般使用习惯，来确认是否是缺陷； 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 2 、问：给你一个网站，你如何测试？ 首先，查找需求说明、网站设计等相关文档，分析测试需求。 制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试 设计测试用例： 功能性测试 可以包括，但不限于以下几个方面： 链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。 提交功能的测试。 多媒体元素是否可以正确加载和显示。 多语言支持是否能够正确显示选择的语言等。 界面测试 可以包括但不限于一下几个方面： 页面是否风格统一，美观

一 Bug重现环境 这个应该是我们重现bug的一个前提，没有这个前提，可能会无法重现问题，或根本无从下手。 操作系统 这个是一般软件运行的一大前提，基本上所有的软件都依赖于操作系统之上的，对于一个软件来说，要想在某个操作系统上运行，必须要对这个操作系统支持，这就需要有真对性的设计与开发。对于不同的操作系统，其可能存在差异（如：win xp 与 win 7与win10）或本质的区别（如 win 7 与 CentOS linux ），所以，操作系统环境是重现问题的一个重要前提。 浏览器 对于B/S系统，或面向大众的互联网产品（网站，邮箱等），浏览器的兼容性也是必须测试的一个重点，对于现在的浏览器市场，各式的浏览器都有其用户群，要想使产品大众化，必须考虑这些产品的兼容性问题。 不同的浏览器之间（IE、 firefox、chrome、opera 等），甚至同一系列不同版本（ie6/ie7/ie8/ie9等）都可能存在兼容性问题，所以，对于这类应用，浏览器环境重现bug前提条件之一。 其它（重要） 对于不同的系统发现重现问题，都会有其特定的前提，拿我测试的邮箱来说，必须要描述其是在测试线还是现网环境，而且还要附带一重现问题的帐号等。 对于c/s软件，可能还要考虑与其它常用软的兼容等，例如，是在安装的某款软件后，对本软件的安装和使用造成影响。这些都是重现问题的必须描述的环境。 二 问题类型

对BUG的分析与理解 bug的分类 bug，其实就是软件期望的行为与实际行为的差异。从程序的角度来看，在软件整个生命周期中都会有bug的出现。需求分析过程中，需求理解的不足，导致的理解错位 ，遗漏甚至变化都可能导致bug；设计本身有好坏之分，但是bug本身还是比较隐晦，不是那么明显。 编码阶段，也会有理解错误，语言特性，第三方库框架，等等导致的bug. 后期打包，部署，运维也会产生 bug，打包的错误，配置错误，以及环境的错位。 自己主要谈谈编码引入的和环境的导致bug。这是最最经常碰到的bug。 　　另外也可以从其他方面开分类，比如稳定可重现的bug与不可稳定重现的bug。 比如多线程导致的竞争。数据敏感的导致的不能稳定重现的bug。 从是否与环境关联，业务逻辑的bug，环境相关的的bug等。 一个BUG的生命周期 缺陷状态 对于一个问题，其处理过程是一个周期，周期的不同阶段，其所处的状态也是不一样的。不同状态所对应的处理人也是不一样的。 打开 ： 表示问题被提交等待有人处理。 重新指派 ： 问题被重新指派给某人处理。 处理 ： 问题在处理中，尚未完成。 固定 ： 确认此问题存在，但暂时不进行处理。 回归 ： 对已经修复的问题进行回归确认。Reopened 关闭 ： 问题的最后一个状态。 提交（打开）缺陷 在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属性。Bug重现环境

1.软件的生命周期（prdctrm） 计划阶段（planning）-〉需求分析（requirement）-〉设计阶段（design）-〉编码 （coding）->测试（testing）->运行与维护（running maintrnacne） 2、问：你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决？ 首先，将问题提交到缺陷管理库里面进行备案。 然后，要获取判断的依据和标准：根据需求说明书、产品说明、原型图、设计文档等，确认实际结果 是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据， 1）可以根据同行或类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 2）根据用户的一般使用习惯，来确认是否是缺陷； 3）与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 合理的论述，向测试经理说明自己的判断的理由，等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 3、给你一个网站，你如何测试？ 首先，查找需求说明、网站设计等相关文档，分析测试需求。 制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性 能测试；数据库测试；安全性测试；兼容性测试 设计测试用例： 功能性测试可以包括，但不限于以下几个方面： 链接测试。链接是否正确跳转