BUG报告

一、接口测试问题：

自己的问题：请求地址错误，方法错误，数据格式错误，头信息content-type,token,request/session()能够保存状态,写的提取代码的问题。程序的问题：有数量限制，添加只能一次。

工具的问题：单独执行与集合整体执行。环境变量的问题。

二、测试流程

需求-计划-设计用例（-实现脚本工具），执行测试（提交缺陷小流程）-报告。

1.如何提交bug

使用软件：jira和禅道

2.bug等级：

**A 类：**严重，崩溃

致命错误。不能完全满足系统要求，基本业务功能未实现，系统崩溃、不稳定或挂 起等导致系统不能继续运行、导致系统出现不可预料的严重错误的问题。
系统崩溃，死机，非法退出，无法继续操作，或引起其他软件系统出错。 (如：操作系统崩溃，其他软件崩溃，执行主流程时，数据库发生死锁)
业务流程或重要功能错误(如：主要流程某对象状态发生错误，严重的数值计算错误等)。
数据通讯完全错误； 与数据库连接错误。

B 类： 功能没实现

严重错误。严重地影响系统要求或基本功能的实现，且没有办法更正（重新安装或 重新启动不属于更正办法）。使系统不稳定、破坏数据、产生错误结果，部分功能无法执行。
一般性功能不符，业务流程不正确，需求没有实现。
重要流程和场景下，导致数据错误，操作无效，操作结果错误。
程序接口错误。 造成数据库不稳定的错误。

C 类：部分没实现

一般性错误。 界面错误(严重的界面提示错误或不友好表现)。
非重要功能无法正确执行， 实现不正确， 实现不完整，但不影响一起功能(如删除时没有考虑数据关联，对其它模块造成影响； 系统界面上，一些可接受输入的控件点击后无作用；对数据库的操作不能正确实现)。
非严重性产生错误结果，但不影响一起功能。正确性不受影响，但系统性能和响应时间受到影响。

D 类： 一般小问题

轻微错误。使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能，或对最终结果影响有限的问题。
系统处理需要优化。 输入限制未放在前台进行控制，或控制错误。增删改等功能，在次要界面不能实现，但在主要界面可以实现。 界面定义不一致，界面定义不规范， 显示格式不规范。
提示文字，没有，不明确，不简明， 不清楚，不正确，未采用标准术语。
(如： 重要删除操作未给出提示。 可编辑区和不可编辑区不明显； 必填项与非必填项应加以区别。键盘支持不好。(如在可输入多行的字段中，不支持回车换行)。
界面不能及时刷新，影响视觉效果。 滚动条无效。光标跳转设置不好，鼠标（光标）定位错误。

E 类： 小bug

测试建议。不影响系统运行，对系统的可用性等提示的建议性的问题。
系统各个位置初始值的建议。 流程优化建议等等。

3. bug的优先级：

3.1

领导，开发，测试，用户，客户：每个人针对bug可能都有自己的想法，自己修改bug顺序

要从其他角度思考问题，最后意见是测试优先级，上线的软件，用户优先级能高一 些，不严重bug领导优先级不高，开发难改，不需要要管。

4. bug报告怎么写才能算清楚

1. 和BUG对应的软件版本
2. 开发人员，测试人员
3. BUG的优先级
4. BUG的严重程度
5. BUG可能属于的模块
6. BUG的标题
7. BUG的描述（步骤，实际结果，预期结果）
8. BUG的截图
9. BUG的状态
10. BUG的错误类型（数据，界面。。。。）

5.基于需求的测试覆盖：

要在测试生命周期中评估多次，来确定测试生命周期中里程碑上的测试覆盖，例如计划的、实施的、执行的和成功的测试覆盖。 测试数量和需求量的比

6.基于代码的测试覆盖：

对照评估测试中有多少代码已经执行和有多少代码有待执行。代码覆盖可以基于控制流（语句、分支或路径）或者数据流。 测试运行的代码行数和总代码行数的比，可提供作为预测还剩多少测试工作的基础。