bug与测试公司环境
缺陷BUG：软件运行过程出现问题的简称。分为四级；一级---致命--L1--A二级---严重--L2--B三级---一般--L3--C四级---建议--L4--D1级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成功达到测试准出——编写测试报告/小结——产品上线敏捷开发模型：1.重点明确，及时调整。（往一个明确的目标进行开发，出现偏差及时进行调整）2.倾听用户声音，相信用户直觉。（面向市场用户的需求进行开发）3.勇于创新，小步快跑。（头脑风暴，什么相关的想法都可以提出来，有问题或者不适合就不要，适合用户的就继续改进）4.持续不断发现问题，解决问题。（频繁迭代更新，保证主体功能无误，允许小问题，但是需要及时进行修改）5.持续提升整个团队的能力。 file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml8328\wps17.jpg 其他模型： file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml8328\wps18.jpg file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml8328\wps19.jpg 测试不仅仅是单纯的软件本身的测试。要考虑软件的背景和目的，还需要考虑软件是否会受到其他的环境因素影响。测试应该尽早介入（需求文档出现时就可以介入测试了，越早阅读需求文档，可以让测试人员更加熟悉需求内容，确保产品，开发，测试多方对需求理解是一致的，可以避免后期功能开发的错误风险，可以尽可能的降低项目延期的风险）杀虫剂效应：重复执行相同的测试用例会导致这类测试用例发现bug的能力几乎为0，可以通过更新测试用例，交叉测试，随机测试降低杀虫剂效应。
页:
[1]