bug与测试公司环境

缺陷BUG：软件运行过程出现问题的简称。分为四级；

一级---致命--L1--A

二级---严重--L2--B

三级---一般--L3--C

四级---建议--L4--D

1级bug，必须优先要改

致命错误：

1、常规操作引起的系统崩溃、死机、死循环

2、造成数据泄漏的安全性问题，比如恶意攻击造成的账户私密信息泄露

3、涉及金钱，如支付类软件，金钱计算错误

2级bug

严重错误：

1、重要功能不能实现（例如：微信没有实现语音聊天、朋友圈，等）

2、错误的波及面广，影响到其他重要功能正常实现

3、非常规操作导致的程序崩溃、死机、死循环 (非常规操作：用户使用软件时不会进行的操作）

4、外观难以接受的缺陷（例如：直播平台的封面图片的失真、压缩，完全变形）

5、密码明文显示

3级bug

一般错误：

不影响产品的运行、不会成为故障的起因、但对产品外观和下道工序影响较大的缺陷

1、次要功能不能正常实现

2、操作界面错误（包括数据窗口内列名的定义，含义不一致）

例如：列名与列名下的内容不一致

3、查询错误、数据错误显示

4、简单的输入限制未放在前端进行控制；（格式显示，如登录和注册中的格式判断可由前端判断）

5、删除操作未给出提示

4级bug

程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误

1、界面不规范

2、辅助说明描述不清楚

3、提示窗口文字未采用行业术语

4、界面存在文字错误

5、改进意见：可以提高产品质量的建议，包括新需求和对需求的改进

（重点软件测试工程师不是把问题全部找出，是尽量减少问题的发生）

file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml8328\wps3.jpg

发现软件中的缺陷：

file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml8328\wps4.jpg

测试是为了证明程序中的错误：

file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml8328\wps5.jpg

TC：测试用例：描述测试的步骤，预期的结果

file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml8328\wps6.jpg

file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml8328\wps7.jpg

file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml8328\wps8.jpg

file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml8328\wps9.jpg

瀑布模型：

1.测试是在最后介入的，软件的问题只能在最后发现

2.合适需求稳定的项目，不能变动

3.整个阶段的前一个阶段和后一个阶段需要互相关注，但是不能跨阶段关注

4.每个阶段都会生产对应的文档，表示可以进入下一个阶段

V模型：

例1：

file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml8328\wps10.jpg

例2：

file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml8328\wps11.jpg

file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml8328\wps12.png

1.用户需求，需求分析：分析用户的需求，得出需求规格说明书（SRS），在公司通过会议进行需求的澄清，需求问题的说明，这个会议称为需求澄清会议。

2.概要设计（概设，HLD）：主要是考虑整个系统要实现的功能，把当前这个系统进行划分，划分模块，模块与模块之间的接口接口设计。

3.详细设计(详设，LLD）：面向具体的模块进行设计内部实现的过程。

4.编码阶段：开发写代码。

5.单元测试（UT）：主要测试具体模块的代码，检查代码逻辑，一般是由开发人员执行测试。

6.集成测试（IT）：面向模块进行测试，将系统的模块进行拼接测试，看看各自模块能不能正常运行。

7.系统测试（ST）：不单单要保证当前模块能不能正常运行，而且要保证和其他外部模块或者系统的业务能不能正常运行。

*sit系统集成测试：就是把集成测试和系统测试一起进行，主要面向的是概要设计说明那些功能。

8.验收测试（UAT）：面向着整一份需求进行测试。

*UAT分为正式验收和非正式验收：非正式验收又分为两种：

α（阿尔法）验收测试：在公司内部做的一场非正式验收，开发和测试都在场，发现问题马上进行修改。

β（贝塔）验收测试：由特定用户进行验收，开发和测试都不在场，有问题就集中收集，统一反馈。（内测）

正式验收：正式版本，交由广大的用户使用。

9.一般在公司里的环境：

（1）开发环境（dev）：开发写代码进行调试的环境。

（2）测试环境（sit）：测试人员进行测试的环境。

（3）验收环境，预发布环境（uat）：进行验收。

（4）真实环境、生产环境、线上环境（prod）：广大用户使用的环境。

10.V模型的优缺点；

优点：1.改进了瀑布模型

2.反映的测试阶段与开发阶段是有对应的关系

3.添加了测试策略，对底层的代码进行测试，对系统需求进行测试，对用户的需求进行了测试。

缺点：1.还是一个串行的模型，前期阶段的问题只能在后期发现。

2.测试介入的时间晚，在软件开发生命周期的编码阶段之后才开始介入。

W模型：

例：

file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml8328\wps13.jpg

file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml8328\wps14.jpg

H模型

例：

file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml8328\wps15.jpg

H模型（重中之重）

主要分为两个阶段：前期准备阶段、后期执行阶段。

准备阶段：

1.进行需求澄清会议，由产品经理进行召开，一般的参加人员有，整个项目的所有人(项目经理、开发经理，开发人员、测试经理、测试人员，（运维人员可来可不来）），需求澄清会议之后，各方都觉得没什么大问题就可以输出基线化需求文档*基线化：不会再有大的改动。

2.分析开发所输出的概设和详设文档。

3.测试经理会输出测试方案或者测试计划。

4.测试人员编写测试用例，进行用例评审。

用例评审会议（一般由测试经理召开）；

组内评审（交叉评审）：测试组内的组员进行互相的评审。

组外评审：邀请对应项目组成员进行评审，一般参与人员有跟当前项目相关的测试人员和开发人员，产品经理。

5.评审通过之后形成基线化的用例文档，测试经理会把文档提交到用例管理工具（textlink、禅道），分配给对应的测试人员。

6.搭建测试环境

执行阶段（开发进行转测，提测，也叫转测试，开发人员写好代码并打包，通过自测之后提交给测试人员进行测试）

7.项目包部署：一般由测试经理测试骨干进行（小公司），由测试运维执行（大公司）。

8.冒烟测试：

（1）测试当前版本的主体功能和重要的分支功能

（2）一般不会超过半天，两个小时左右就可以完成

（3）冒烟测试如果不通过就进行版本打回

冒烟测试用例怎么去挑选？

选择和主体功能相关的测试用例和用例级别比较高的测试用例

9.冒烟测试通过就进入sit1测试（第一轮系统集成测试，一般分三轮）

sit测试选择全量的测试用例（和当前版本相关的所有测试用例）

sit2/sit3测试（也叫回归测试，指的是相对于第一轮SIT的回归），选择的是：

（1）上一轮出现bug的用例需要重新验证。

（2）bug相关模块的测试用例。

（3）每一轮都要进行主体流程的测试，都要挑选主体功能的测试用例（每一轮开发都会构建代码包给测试）。

（4）可以选择你觉得可疑的测试用例和测试场景。

（5）测试人员补充的测试用例。

*为什么要补充测试用例？

因为开发过程，我测试人员并不知道最终开发出来的产品是不是我们预期的，在所有开发完成之后才能看到相关一些页面，这些问题可能我们测试人员出现漏测，为了避免漏测的情况，需要及时的补充测试用例。

10.整一个测试周期，bug的数量是呈现收敛的状态。

11.输出测试报告，需达到测试准出（0bug上线），当然也可以遗留1-2个的建议性bug，遗留bug必须明确在后续的版本进行修改。

12.回归测试分为两种情况。

（1）SIT过程的回归测试，除了SIT1以外的测试都叫回归测试。

（2）SIT过程以外的回归测试，主要做系统回归。

面试题：你了解冒烟测试和回归测试的区别吗？

冒烟测试：有称为版本构建测试，提交测试，每次版本构建时都要进行的测试，对版本的基础功能和主体功能进行测试，一般两个小时左右，不会超过半天，不通过直接进行打回。

回归测试：系统维护阶段进行，对原有的功能、缺陷进行验证测试。

区别：两者区别在于测试的阶段不一样，冒烟测试是在版本构建提交时进行测试，而回归测试则是在系统维护阶段进行。

在测试过程，执行测试用例时，发现一个bug就及时的进行提交bug的操作，叫做提单。

file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml8328\wps16.jpg

测试流程总结：产品经理召开需求澄清会议，输出基线化需求文档——测试了解需求规格说明——测试经理编写测试计划，下发测试任务——测试人员编写测试用例，进行用例评审——测试经理召开测试用例评审会议，进行组内组外评审，评审通过形成基线化用例文档——开发组提交项目包测试经理部署测试环境——测试人员使用通过的测试用例对开发组提交的项目包进行冒烟测试——测出bug提单给开发——开发修改代码——测试经理收到修改代码，重新验证bug模块测试用例进行回归测试——冒烟测试测出0bug成功达到测试准出——编写测试报告/小结——产品上线