第二天小笔记（一）

为什么要测试

1.软件的非正常运行或自身的缺陷也会引发问题
非正常运行：异常条件-逆向思维执行测试
自身的缺陷：软件在开发完成之后是没有被执行测试的所以会存在许多问题
2.软件是由代码和文档组成的，人都有可能犯错
1.需求文档--开发是一句需求文档的说明进行代码的开发
3.环境也会引发软件失效
1.每个环境的配置不一样，这些环境的配置也会导致软件无法使用
4.软件测试活动只是关键的质量保证活动之一
1.产品经理写需求文档的质量
2.开发代码的质量都是在保证软件的质量
什么是测试
1.验证软件的正确性
2.发现软件中的缺陷
3.当前软件是达到用户使用标准
测试用例
测试用例是测试人员执行测试的依据
软件的生命周期执行的阶段
1.客户的问题引入定义
客户提出需求，产品经理对接客户收集客户需求
2.可行性分析
对象：客户的需求
经济：
1.当前客户的需求实现的话，那么是否科可以带来具体的经济效益
2.当前项目组的资金是否可以支持项目运作
法律：
1.禁止黄毒毒
2.不能出现政治敏感话题
技术：当前项目技术，是否可以实现客户的需求
3.项目的招投标
1.开发公司拟建发布公告，吸引有资质的承包商来承担当前项目组的部分开发工作
4.项目立项：
1.项目组成立，招人制定工作计划，制定‘项目周期，分配工作
5.需求分析;
功能具体的需求文档/原型图分析
1.开发分析完成之后执行开发工作
2.测试分析了解需求，方便后续更加全面执行测试
6.开发阶段
1.开发设计开发逻辑，编写代码
2.测试人员执行测试，找出产品bug进行修复
维护阶段：
1.软件发送给用户使用，在用户使用过程中持续跟进用户的情况进行改进
2.准备下一阶段的开发工作
典型的软件生命周期模型
什么是软件生命周期模型？
就是当前软件开发具体实施的内容阶段
H模型，V模型，瀑布模型，增量开发模型，敏捷开发模型 w模型
瀑布模型：
1960提出的模型：
优点：
1.按阶段进行展开，每一个阶段的结束，代表下一个阶段的开展，适用于项目管理
2.清晰的表达了开发测试的阶段，是第一个重视测试的模型
缺点：
1.如果开发按照流程走一旦出现修改需求或者开发理解错误需求，就会导致项目返工的情况，增加成本开支
2.现实场景当中都是，按照用户的需求不断的完善当前的工作
3.测试人员介入的阶段台湾，对于早期的阶段的工作内容不清楚导致测试覆盖程度不够。
V模型：
用户需求：
产品经理引用客户的需求。整理输出成需求文档/原型图
需求分析：
分析当前的需求文档/原型图，分析r当前的业务逻辑以及功能实现是否正确
概要设计（HRD）：
由开发人员设计当前开发产品的开发框架，以及服务器和数据库相关配置设计，以及大致的业务逻辑设计
详细设计（LLD）：
由开发人员进行设计，参照概要设计文档，设计当前交互的接口，以及数据结构的设计，前端页面逻辑设计,UI设计等等
编码阶段：依照详细设计文档，执行编码，开发程序
单元测试（白盒测试【UT】）:
由开发人员针对自己所写的代码，进行检测，通过观察或者运行代码，检测项目是否符合标准的
集成测试（IT）
测试项目所有模块放在一起进行测试，
1.测试不用的功能是否存在兼容适配问题
2.模块与模块之间的数据传递是否正常
3.模块与模块之间的功能调用是否正常
系统测试（ST）：
集成测试通过，所有模块都兼容，没有产生问题然后执行系统测试
系统测试：又称全量测试，包含项目当中所有功能的测试，界面测试，可用性测试，可靠性测试，易用性测试，性能安全测试，都需要被执行
验收测试(UAT)：
1.由当前开发的项目组成员组织验收----->α：
都是当前项目组成员组织进行验收测试，从新测试当前的项目，看他否达到了用户使用标准，推动版本的发布，给用户使用
2.可以由客户方进行验收---->β：
客户方进行验收，我们当前项目组需要排除代表给客户讲解需求，客户组织验收，根据用户体验反馈的问题，做持续的跟进解决
V模型的输入和输出的关系
输入：用户需求                输出：需求分析
输入：需求分析                输出：概要设计
输入：概要设计                输出：详细设计
输入：详细设计                输出：编码阶段
输入：编码阶段                输出：单元测试
输入：单元测试                输出：集成测试
输入：集成测试                输出：系统测试
输入；系统测试                输出：验收测试
现阶段系统测试和集成测试已经合并（SIT）：在这个阶段所有集成测试和系统测试内容在一个阶段执行
V模型虽然概括了说所有的测试阶段的流程，但是他的测试流程阶段依旧在开发编码之后对于前面的问题在执行测试阶段才引入，导致需求理解不透彻，测试覆盖不全面，导致增加测试时常
W模型
H模型
项目和产品的q区别
先有项目再有产品，产品是当前项目输出的结果
项目和版本的区别
项目是一个工程
版本指的是实际输出产品的版本号
每个项目的的初始版本都是v1.0
项目包含版本，一个i昂木当中可以包含多个版本
冒烟测试
只有主要功能流畅，才能针对每个子节点的功能进行检测，如果中间某一功能出现问题造成阻塞，后续的功能测试人员无法进行开展
敏捷开发模型：
1990提出
1.能快速的适应市场的变化，一旦市场需求变了，我也可以更具用户情况更快的改动
交付周期短，大概1-2周左右一个版本，项目紧急就是一个礼拜一个版本，不紧急可能1-2周左右时间完成一个版本开发
缺点：
1.针对开发以及测试的能力要求比较高，敏捷开发模式一般很少会有实质性的文档产生，强调的是人与人之间的沟通
2.测试的覆盖程度不够全面，会经常产生问题
增量开发模型
1.将已知/待开发的功能进行模块化，分批次的进行开发，交付给用户使用（也是根据用户需求紧急程度来进行交付功能）
2.开发的顺序灵活，能够自由的调整开发顺序，也可以快速的适应市场
迭代开发模型
1.先做一个项目交给用户使用，在用户使用的过程当中，进行频繁的迭代，增加一些新的功能，这些功能都是未知的，根据市场需求进行功能迭代
测试的基本原则
1.测试标准是用户需求
当前测试的软件是否达到了用户标准
2.测试不单单是软件本身的测试
1.网络
2.硬件配置
3.环境
4.兼容
二八原则
模块如果出现较多的bug，那么我们更加仔细的测试这个当前的模块，因为bug可以引发更多的bug
杀虫剂效应：
测试的生命周期
测试计划（测试的准入）条件与控制：
测试的准入：
软件到达怎么的条件之后，测试人员介入测试
1.当前所有的功能已经按照需求文档实现
2.开发完成单元测试，并向测试提交测试报告申请单
3.输入的单元测试报告
测试分析与设计
分析：需求文档当中具体的需求
设计：设计执行测试的测试用例
测试的实现与执行
执行编写的测试用例，找出软件当中的问题
测试报告（测试准出）
测试过程当中的资产归档（测试总结）
产生的一些文档
测试用例，测试bug都需要进行归档留存
资产：测试机（手机）
总结：
针对此次测试工程，有哪些做出总结（具体那个环节做的不好，进行总结）