一个bug由测试人员发现并提交，我们将状态注为新建，开发人员接受了该bug，将bug的状态 修改为已分配（Assigned）,表示已经认可，开发人员解决了该bug后，就将bug的状态修改为解决，并发给了测试人员回归测试，测试人员解决了该进行回归测试，如果确认已经解决，就将bug的状态修改为关闭，否则的话则发给开发重新修改，还要说明的是，bug是可以“死而复生”的，以前版本已经官兵的bug，如果新版本中重新出现，我们就需要将其状态修改为重新打开。
bug定级示列
1级，系统崩溃
定义：严重阻碍测试和开发工作
对应优先级：最高
具体可分为：
1.功能完全没有实现
2.应用闪退/崩溃无法运行
3.应用必须完全模式，无法运行
4.其他导致功能无法测试的问题
2级。至关重要
定义：非阻碍用例执行的严重问题
对应优先级：高
具体可分为：
1.简单操作应用闪退/崩溃，卡死
2.数据丢失
3.严重影响系统，自身功能无法运行
4.严重数值计算错误
5.数据库损坏或无法保存配置
6.安全性问题（包括数据加密等）
3级，主要
定义：功能存在缺陷，但不影响应用和系统的稳定性
对应优先级：中
具体可分为：
1.内存泄漏（长时间不用的对象需要被回收，不可回收占内存）
2.功能实现逻辑覆盖不全面
3.非必现，但复现概率超过50%的先退/崩溃和安全模式
5.28的总结
测试总结
问题：
软件开发的生命周期
客户提出需求
根据客户的需求写出相对的《需求文档》 说明书
同时进行
前端同时设计效果图（原型图）
后台开发人员设计与编写代码实现功能
测试人员也会根据需求文档编写测试计划 和测试用意
d.在后台开发实现功能后根据测试用例测试人员进行测试
e. 开发完全结束后测试人员进行整体测试，全面测试。测试成功之后进入上线
f.软件上线后根据用户体验和实际效果进行小版本的迭代
对于软件缺陷的定义
软件未达到产品说明书的功能
软件出现了产品说明书指明不会出现的错误
软件功能超出产品说明书指明范围
软件未达到产品说明书虽未指出但应达到的目标
软件测试员认为难以理解、不易使用、运行速度缓慢、或者最终用户认为不好
软件缺陷产生的原因种类
需求变更次数频繁 理解误差 产品或者是用户
开发和设计 代码问题 开发人员
运维 资源使用率产生 公司问题
测试流程：
在立项会上根据客户需求编写需求文档/规格说明书，UI设计原型后台编码，测试人员编写测试计划和测试用例
随着开发的代码实现测试进行测试评审
主要代码实现后测试人员进行冒烟测试
代码实现后测试执行测试用例
根据执行的结果进行对应bug提交给对应的开发人员让其修改代码
开发修改后测试人员进行回归测试
直至项目上线后 测试人员编写测试总结用于下一个版本的迭代
冒烟测试 在这个软件中主要的功能实现后进行测试
回归测试 在开发人员修改后进行的同一个问题的测试
随机测试
软件测试分类：
按阶段划分：
单元测试 对一个模块测试
集成测试 对多个模块测试（有一定的关联）
系统测试 在软件编译后执行的整体测试
验收测试 对软件执行后的用户体验的测试
α 阿尔法测试 有一定的开发测试的测试 内测
β 贝塔测试 只有用户参与的测试 公测
按是否运行程序划分
静态测试 UI设计图
动态测试 有执行代码过程中产生的问题
按是否查看源代码方式划分
黑盒 只看外观 就把它当做一个盒子 不看里面的结构 只关心能否输入输出以及响应时间
功能测试 界面 安装 兼容 易用
性能测试 压力测试 负载测试 一般性能 稳定性测试
压力测试 在同一时间进行多个用户的访问 8:00
负载测试 在多个用户在一段时间内的持续访问 8：00 ~ 11:00
白盒测试 只看代码结构以及代码实现方式
灰盒测试 介于白盒和黑盒之间一种
面试题： 对于任意物品的测试
回答思路：
功能上 体积 形状 用途 材质
界面上 颜色 图案
性能上
易用性
安全性
软件测试的原则
尽早原则
考虑意外情况和极端情况发生
群集现象
测出问题能复现问题
不要在短期进行高效测试
回归测试的关联性
善于总结相关文档
面试题
如果在测试过程中出现的bug 而开发人员不认为bug的时候你怎么办？
自我原因
首先我会从自身查看ug的出现次数和频率，记录复现bug的方式，然后发送给开发人员
在根据需求文档确认是否为bug
别人原因
找领导
如果开发不认为是bug 将复现bug的记录和需求文档找产品经理进行商议由产品经理和项目经理来确认是否bug
如果项目经理和产品经理都不认为是bug，我会将bug记录到测试文档中，方便在下次评审会上将问题再次抛出
软件测试开发模式常见的为
V型
WW型
H型
螺旋形
day2 测试计划和测试用例以及测试方法
测试用例定义 作用 格式 设计原则
测试用例设计方法
测试计划内容 模块分析 测试报告内容 分析
测试用例的定义
执行测试的一句 将测试的操作步骤进行以文档的方式记录下来
测试用例的格式
测试用例的模块 测试用例的编号 测试输入 执行条件 预期结果 实际结果
测试用例的模块 操作软件的一个大的菜单 命名以模块名称为主
测试用例的编号 命名为菜单下具体功能–数字
测试输入 对具体功能的操作步骤
执行条件 操作的先决条件
预期结果 是以需求文档
测试用例的文档方式2种 exl 表格的方式 word文档方式
测试用例的特征
代表性：能够代表并覆盖各种合理和不合理、合法和不合法、边界
针对性：对程序中的可能存在的错误有针对地测试
可判定性：测试执行结果的正确性可判定的，每个测试用了你都应有的期望结果
可重现性：对同样的测试用例，系统的执行结果应当格式相同
软件分类
3. OA 办公自动化
crm 客户管理系统 电商项目
ERP 进销存系统