武汉3班第2天笔记

测试分类的方法：
黑盒测试：对程序的外壳进行测试，
       优点：容易实施，更贴合用户的使用场景，
       缺点：测试的时候没有关注到底层的代码结构，覆盖代码量比较低，一般在45-50％
灰盒测试：postman jmeret  灰盒测试都是借助工具辅助测试。
          通过接口可以定位这个bug到底是属于前段还是后端
           1.这个接口的请求报文有问题，那就是前端问题。
           2.这个接口的返回报文有问题，那就是后端问题。
D:\Youdaodict\qqBEB585DCC0154741470A5D740C8AFDAD\b4faad67d2844937925770acb4151d80\image1.jpeg
白盒测试：
    1.语句覆盖：每一个语句都至少运行一次
    2.判定覆盖：判定取值的分支要运行一次
    3.条件覆盖：所有可能的结果都至少运行一次
    4.判定条件覆盖：判定过程中所有可以取值的都要运行一遍，及各个判断所有可能的条件都要运行一次
    5.条件组合覆盖：判定过程中，所有组合条件，都要运行一次
    6.路径覆盖：每条可能执行到的路径都要运行一次
白盒测试方法有哪些优点：对代码的测试比较彻底
                  缺点：代价比较昂贵
静态测试：是指这个程序没有被运行时，进行的测试。
动态测试：运行这个程序执行测试
自动化测试：UI   APP api
      UI自动化：你是通过什么转换UI脚本测试用例？
                 通过功能测试用例进行转换脚本
      你的UI自动化项目覆盖率（功能测试用例转换率是多少）
                 30%左右，基本覆盖项目的主体流程
                  Python+se   
      api：接口其实就是一条URL地址，通过这个地址去获取相应的资源
           接口自动化：做接口自动化是根据开发提供的接口文档，编写测试用例脚本，
        验证接口的请求以及返回信息
          postman   jmeret   Python+request
      APP：是手机版本
UI测试：是根据UI设计师提供的高保真图，进行页面的测试，界面的风格、文字、背景、排版，把对应的问题反馈给UI设计师

冒烟测试：是开发单元测试完成之后，测试人员的第一轮测试，针对   的对象是产品大致的主体功能是否畅通，是否阻碍下一阶段的测试行为（有没有阻断性的bug）
冒烟测试主题功能阻塞怎么办？
        直接打回给开发进行修复，直到开发修复完成之后再一轮的冒烟测试通过才进行下一阶段的测试工作
总结：冒烟测试就是对产品大致的主题功能进行测试

随机测试：随机测试没有书面的测试用例，主要根据测试人员以往的经验来进行

安装测试： 安装：
           升级：
           卸载：




典型的软件生命周期模型有哪些？这些生命周期模型是用来干什么的？
      这些软件的生命周期模型其实就是一个项目开发流程。
常见的软件生命周期模型有几种？
瀑布模型，v模型，w模型，H模型，敏捷开发模型
迭代开发模型，增量开发模型

（一）瀑布模型：最早的开发模型，1970年被提出来
    优点：1.层级分明，阶段性展开，一个阶段结束才开始下一   个阶段
          2.能够清晰地表达开发周期地全过程，明确了有哪些阶段
          3.更够更贴合项目的管理
    缺点：1.很难按照模型走下去，因为对人员的要求很高，
          2.测试介入阶段在开发编码后，测试对需求不清晰
          3.在开发过程中需求其实是根据客户的变化而修改需求，那么瀑布模型的话，如果客户修改需求，就会导致这个项目烂尾，等于重新做一遍
          4.在项目初期很难看到结果，只有在项目尾期才能看到结果

D:\Youdaodict\qqBEB585DCC0154741470A5D740C8AFDAD\7ac543854646414f8d96893d4f48a736\image2.png

（二）V模型
      特点：是一个串行结构的模型，从左到右描述了开发测试的全过程。

D:\Youdaodict\qqBEB585DCC0154741470A5D740C8AFDAD\11941c2020bc4d9b929528e41ae8738e\image3.png
优点：1.描述每一个阶段，便于控制开发的每一个过程
      2.包含了单元测试，系统/集成/验收测试
缺点：1.虽然有参照的依据，但是测试的行为还是在开发系统之后
      2.对于前期发现的问题，我们测试人员不是很清楚
项目的输入与输出：
输入：用户需求       输出：需求分析
输入：需求分析       输出：概要设计
输入：概要设计       输出：详细设计
输入：详细设计       输出：编码阶段
输入：编码阶段       输出：单元测试
输入：单元测试       输出：系统集成测试
输入：系统集成测试   输出：验收测试

（三）W模型
W模型是V模型的延伸，测试活动提早到需求分析的阶段，能够更好的了解需求
W模型的理念强调测试伴随着整个开发的周期
  测试左移：提早测试介入项目测试时间
  测试右移：推迟测试介入项目测试时间
优点：1.伴随着整个开发的周期，可以更早的进行需求分析阶段
      2.测试和开发独立运行的
缺点：1.对于有些项目组，他根本不会产生文档，所以我们测试就少了参照的对象，那么就会导致下一阶段工作无法开展
      2.对于开发技术的要求比较高
使用的场景：必须要产生文档，且开发的技术达到一定的要求

（四）H模型（☆）
D:\Youdaodict\qqBEB585DCC0154741470A5D740C8AFDAD\265bdcff92c941d0914460835c14ad69\image4.png
SRS（需求规格说明书）
测试人员注重点：
   1.这个需求规格说明书是否存在疑问的地方
   2.这个需求规格说明书是否有矛盾的地方
   3.这个需求我该执行哪些测试方法
   4.这个需求交付的测试结果日期
   5.交付的标准

了解需求规格说明书：
XMdin：思维导图
1.将这个需求，一个功能以及一些需求要求罗列出来
2.根据思维导图，提取测试用例
TPM（测试经理）输出测试计划
TE（测试人员） TC（测试用例）
TE输出测试用例的时候，是根据测试用例方法进行输出测试用例：判定表，因果图，等价类，边界值，场景法，正交表，
用例评审：
        评审的对象-测试用例
        评审这个测试用例对软件的覆盖率，是否存在遗漏的地方，需要补充
如果测试用例评审不通过，那么测试人员继续进行补充。
如果补充完成之后，再次进行评审，直到评审通过。
   用例评审方式：
  1.会议评审
项目组所有的人员，包括项目经理，开发人员以及所有的测试人员进行评审
  2.组内评审
测试组所有组成员进行评审
  3.交叉评审
  参与这个项目的测试人员进行相互评审
  testlink：是一款用例/bug/项目管理工具，他可以记录bug，提交bug指派给开发进行修复，还有管理用例、管理项目、报表统计功能

你用过哪几种用例bug管理工具？
禅道，qc，tapd
禅道：优点开源免费

tpm进行分配测试用例：
   谁写的测试用例就由谁来进行测试
TPM/测试骨干/运维人员搭建测试环境

需求了解之后的开发活动
概要设计的内容：系统结构，系统的数据设计，以及大致的主体模块

详细设计的内容：一些接口编写，和子模块的设计；接口文档

编码coding；去实现开发这个项目
单元测试（只有开发单元测试通过，评审通过之后才会将代码包进行打包）

编码完成之后，开发将代码包进行打包，一般的包格式jar，war
开发人员/运维人员/测试人员进行提交部署到测试环境
代码包部署环境（Linux Windows）
代码包部署完成之后：
测试人员进行冒烟测试：
        冒烟测试的内容：对产品的大致主体功能进行测试，是为了防止有阻断性bug阻碍我们下个阶段的测试。
       冒烟测试通过→开展下一阶段的测试
       冒烟测试不通过→直接打回给开发进行修复，修复完成之后再冒烟，直到通过
sit①（系统集成测试）：全量测试（批量注入测试用例）
   测试人员：在进行测试的同时，记录发现bug提交到禅道或者其他的bug管理用例管理工具，指派给相应的开发人员进行修复
sit②...又称回归测试，回归上一轮出现bug的问题，再次进行验证，如果说这个bug扔存在，那么就继续提交给开发进行修复，然后再下一轮的回归测试中进行验证
sit③...
随着回归测试的深入，那么bug也在相应的减少，如果说由于项目的时间紧迫，可以遗留1-2个bug，移交到下个版本再进行修复


测试的准出：
1.开发完成编码，且通过了单元测试
2.需求文档的内容均已实现
3.基本主体功能流程可以走通
4.开发人员向测试人员提供测试申请单和配置文件

软件测试暂停的标准：
1.程序出现重大bug，影响基本功能的使用，或过多bug导致功能无法走通，我们可以向领导申请暂停测试，打回给开发
2.在工作当中任务等级会划分优先级，当出现更高级别的任务，测试人员可以提出暂停测试，进入优先级别高的任务
3.项目开发周期因为进度偏差，可以申请暂停测试

软件测试恢复测试的标准：
1.重大bug已经被修复，主体流程可以走通
2.优先级别较高的任务已经完场，恢复当前测试
3.软件项目暂停之后重新启动，测试可以恢复

单元测试结束的标准：
1.单元测试用例已经通过评审
2.按照单元测试的规范，已经完成所有单元测试的活动
3.单元测试覆盖率，达到了项目要求

集成测试（模块与模块之间的组装测试）停止的标准：
1.集成测试用例设计，已经通过评审
2.已经完成了整个系统的集成测试
3.集成测试已经完成项目中功能以及性能要求
4.在集成测试当中，我们发现的bug均已被修复

系统测试停止的标准：
1.所有的系统测试用例，已经通过用例评审
2.已经完成系统测试的所有要求

测试的准出：
1.需求文档的功能均已实现
2.测试中出现的bug修复率达到了98%以上才可以上线给客户使用
3.输出相应测试用例执行情况
4.输出测试过程中的测试报告
5.输出测试过程中的测试计划

H模型相比其他模型，具体给了一个阶段工作的时间
一个版本就是一个迭代，迭代的是增加以前没有上线的功能

一个项目代表产品
一个项目可以划分多个版本

面试问题：
冒烟测试是什么意思？
是开发单元测试完成之后，测试人员的第一轮测试，针对的对象是产品大致的主体功能是否畅通，是否阻碍下一阶段的测试行为（有没有阻断性的bug）
没通过的话直接打回给开发进行修复，直到开发修复完成之后再一轮的冒烟测试通过才进行下一阶段的测试工作
总结：冒烟测试就是对产品大致的主题功能进行测试

你的项目流程是什么？

你提的bug，开发说不是bug怎么办？
我们是专业的，丰富的测试经验，第一，给开发重现这个bug，如果不改，直接交给开发或者测试经理进行定义。

如果发版之后，线上出现重大问题，你觉得是谁的责任？
首先不是推卸责任的时候，第一时间去确认这个bug，协助开发进行修复，等到修复完成之后会有复盘会来探讨，当然出现bug不是测试一个人的责任，当然我们也不会去推卸责任。


（五）敏捷开发模式：
1990年提出，现在很火的一种模式
特点：1.能够快速适应需求的变化
      2.交付的周期短（基本上以周为单位）
它的开发过程当中很少产生实质性的文档，对技术人员的沟通能力要求比较高，很多时候面对面进行沟通。
敏捷开发模式更贴合用户，根据用户的需求进行迭代，能快速适应需求的变化。
优势：1.强调的是人与人之间的沟通，面对面交流是最好的沟通方式。
      2.业务人员开发人员测试人员之间的合作关系会加强。
      3.可以关注更好的技术与设计进行变更
      4.适应市场带来的变化。
缺点：1.交付周期短会导致产品质量的下降
      2.交付周期短会导致测试覆盖不够全面，从而会导致很多bug
      3.缺乏对文件的重视程度
      4.对开发的要求会相对较高
敏捷开发模式的周期：一般2个周一个版本


增量开发模式：
  部分公司可能一个项目包含很多功能，那么他会先发一部分留住客户，在后续过程当中，按照任务的优先级别，或者用户使用情况来定，下一个增加给客户使用内容

怎么去定义一个缺陷（bug）？
  1.按照需求文档，与需求文档不符的
  2.软件没有达到需求文档要求的
  3.软件当中出现了需求文档指明不应该出现的错误
如何去描述一个bug？
   1.bug出现的版本
   2.bug出现的环境（测试环境、预发布环境、生产环境）
   3.bug的重现步骤
   4.预期结果
   5.实际结果
   6.bug级别：1级 崩溃（服务器崩溃）  
              2级 严重（主体流程出现了阻断性的问题）
              3级 一般（不影响进行测试的bug）
              4级 建议性/优化性bug（这个bug影响不是很高，一般是指UI界面的问题）
   7.bug截屏
   8.bug录屏
   9.bug标题
   10.bug发起人
bug的状态分为哪几种？
  1.新的，指这个bug才刚刚被发现
  2.已存在 表示我这个建的bug已存在bug/用例管理工具
  3.已指派 表示已经指派给对应的开发进行修复
  4.解决中 表示开发正在解决这个bug
  5.已修复 开发修复完成之后会把bug改为已修复/测试人员进行验证
  6.已关闭 开发修复好之后，测试通过
  7.仍存在 开发修复bug之后，测试没有通过
  8.重新打开：已经关闭的bug，关闭之后又重新出现了这个问题

测试的基本原则：
1：测试的标准就是用户的需求，所有的需求建立在用户需求之上，那么我们测试的标准其实是系统是否满足了客户的需求
2.测试不单单是软件本身的测试
环境配置，硬件的配置，是否贴合用户的使用习惯
3.软件外在没有失效，不代表这个系统是可用的。
4.尽早的测试和不断测试，可以尽早的发现问题，那么对应的修复成本会相对低
5.穷尽的测试是不可能的
6.测试应该尽早的介入（早期引入的问题占比整个项目50%）
7.二八原则：80%的错误会集中在20%的区域中
8.杀虫剂效应，只有不断地去更新测试用例才能发现新的bug
9.测试关注点不一样，发现的问题也不一样
10.尽量选择第三方测试（避免自己开发的测试自己测试）
11.提前定义好产品的质量标准，只有提前定义好了产品的质量，我们后续才可以更好的对产品进行分析和评估
12.测试用例是设计出来的，不是写出来的，我们要采取相对应的方法去设计测试用例，而不是盲目的去写测试用例
13.对发现错误较多的程序，应该更深层次的进行测试