第二天笔记

1.软件的非正常运行或者自身的缺陷会引发问题
  非正常运行：异常条件-逆向思维执行测试
  自身的缺陷：软件在开发完成之后是没有被执行测试的会存在许多问题
2.软件是由代码和文档组成，人都有可能犯错
  需求文档--开发是依据需求文档的说明执行
3.环境也会引发软件失效
  每个环境配置不一样，也会导致软件无法正常使用
4.软件测试活动只是关键的质量保证活动之一
  产品经理编写需求文档的质量
  开发代码的质量都是在保证软件的质量
测试用例：
  测试用例是测试人员执行测试的依据
软件生命周期执行的阶段：
1.客户的问题引入定义：
客户提出需求，产品经理对接客户收集需求
2.可行性分析;
对象;客户的需求
经济：当前客户需求执行的话，是否带来经济效益
      当前项目组资金是否支持运作
法律：禁止黄赌毒
政治：不能出现政治敏感话题
技术：当前项目技术是否可以实现的客户需求
项目的招投标：
  1.开发公司拟建发布公告，吸引有资质的承包商来承担当前项目的部分开发
项目立项：
  1.项目组成立,招人，制定工作计划，制定项目周期，分配工作
需求分析：
  当前功能具体的需求文档/原型图进行分析
  1.开发分析完成之后执行开发工作
  2.测试分析了解需求，方便后续更加全面测试
开发阶段;
  1.开发设计开发逻辑，编写代码
  2.测试人员执行测试，找出产品bug进行修复
维护阶段：
  1.软件发送给用户使用，在用户使用的过程中当前持续的跟进用户的阶段，进行改进
  2.准备下一阶段的开发工作
典型的软件生命周期模型有哪些
  什么是软件生命周期模型
就是当前软件开发具体实施的内容阶段
  H模型,V模型，W模型，瀑布模型，增量开发模型，迭代开发模型，敏捷开发模型
瀑布模型;
1970年提出的开发模型
优点;
1.按阶段进行展开，适用于项目管理
2.清晰的表达了开发测试的阶段，是第一个重视测试的模型
缺点：
1.出现修改需求或者开发错误，就会导致项目反工，增加成本开支
2.显示场景中都是，按照用户的需求不断的完善当前的工作
3.测试人员接入太晚，对于前期不清楚，导致测试覆盖程度不够
V模型：
V模型阶段：
用户需求：
   产品经理引用客户需求，整理输出成需求文档/原型图
需求分析;
   分析当前的需求文档/原型图，分析当前的业务逻辑以及功能实现是否正确，以及当前技术是否可以支持对应的开发工作
概要设计：简称HLD(由开发人员设计，设计当前的开发产品的开发框架，以及服务器和数据库相关配置的设计，以及大致的业务逻辑设计）
详细设计：简称LLD（由开发人员进行设计，参照概要设计文档，设计当前交互的接口，以及数据结构的设计，前端页面逻辑的设计，ui设计等等）
编码阶段;依照详细文档编码，执行编码，开发程序
单元测试：简称UT,又称白盒测试，有开发人员针对自己所写的代码进行检测，通过观察或者运行代码，检测项目是否符合标准的
集成测试：简称IT
   集成测试内容;
   1.模块与模块合并集成，是否会产生影响，出现适配的问题
   2.模块与模块之间的数据传递是否正常
   3.模块与模块之间的功能调用是否正常
   系统测试：简称ST
   集成测试通过，所有的模块都兼容，没有产生问题，然后执行系统测试
   系统测试：又称全量测试，包含项目中所以功能的测试，界面测试，可用性测试，可靠性测试，易用性测试，性能安全测试，都需要被执行
   验收测试：又称UAT
   1.由当前开发的项目组成员组织验收
   2.可以由客户方进行验收
α:阿尔法: 都是当前项目组成员组织进行验收测试,从新测试
当前的项目,看他是否达到了用户使用标准.推动版本的发布,
给用户使用.
β:beta:客户方进行验收,我们当前项目组需要派出代表给
客户讲解需求,客户组织验收,根据用户具体反馈的问题,做
持续的更近解决.
V模型的输入与输出关系：
   输入：用户需求  输出：需求分析
   输入：需求分析  输出：概要设计
   输入：概要设计  输出：详细设计
   输入：详细设计  输出：编码阶段
   输入：编码阶段  输出：单元测试
   输入：单元测试  输出：集成测试
   输入：集成测试  输出：系统测试
   输入：系统测试  输出：验收测试
现阶段：系统测试和集成测试已经合并
简称SIT 系统集成测试，在这个阶段所有集成测试的内容，系统测试的内容在同一阶段进行执行
V模型;虽然概况了所有的测试阶段的流程，但是他的测试流程阶段依旧在开发编程以后对于前面的问题，需求理解不透彻测试覆盖不全面，导致增加测试成本
W 模型:

项目和产品的区别?
            现有项目再有产品.产品是当前项目输出的结果.

      项目和版本的区别?
            项目是一个工程.

            版本指的是实际输出产品的版本号.
            每个项目的初始版本都是v1.0,
            项目是包含版本的,一个项目当中可以包含多个
            版本.


      SRS(需求规格说明书,需求文档/原型图)
      test case TC(测试用例)
      testlink(bug用例管理工具)


      电商的主体业务流程
      -->商品添加-->进行支付--->下单成功-->待发货

      如果支付功能出现问题,就造成了阻塞.后续的功能
      测试人员无法进行开展.
      只有主体的流程畅通,才能针对每个节点的子功能
      进行检测.
H模型:
.png

敏捷开发模型：
   1990年提出的一种新型的模型，
优点：
   1.能快速适应市场的变化，一但市场的需求变了，我也可以根据用户情况更快的改动
   2.交付周期短，大概一到两周一个版本，紧急下一周一个版本
缺点：
   1.针对开发和测试能力要求高，敏捷开发模式一般很少会有实质性的文档产生，强调人与人之间的沟通
   2.测试覆盖程度不够全面，会经常产生问题
增量开发模型;
   1.将以知/待开发的功能进行模块化，分批次的进行开发，交付给用户使用（也是根据用户需求紧急程度来进行交付功能）
   2.开发的顺序灵活，能够自由的调整，快速适应市场
迭代开发模型：
   1.先做出一个项目给用户使用，在用户使用的过程中，在进行频繁的迭代，增加新功能，这些功能都是未知的根据市场需求进行迭代功能
测试的基本原则：

测试的基本原则:
      1.测试标准是用户需求:
            但前测试的软件是否达到了用户使用标准.

      2.测试不单单是软件本身的测试:
            1.网络
            2.硬件配置
            3.环境
            4.兼容
      二八原则：
            模块如果出现比较多的bug,那么我们更加仔细的测试
            这个当前模块,因为bug可以引发更多bug的产生.
杀虫剂效应：

测试计划的准入条件与控制：

测试的准入：
软件达到怎样的条件以后，测试人员介入测试：
   1.当前所有开发的功能已经按照需求文档实现
   2.开发完成单元测试，并向测试提交测试报告申请单
   3.输入的单元测试报告
测试分析与设计：
   分析：需求文档当中具体的需求
   设计:设计执行测试的测试用例
测试的实现与执行：
   执行编写的测试用例，找出软件当中的问题
测试报告（测试的准出）：