第二天笔记

1.软件的非正.常运行或自身的缺陷也会引发问题
   非正常运行：异常条件-逆向思维执行测试的所有会存在许多问题。
2.软件是由代码和文档组成的，人都有可能犯错
   需求文档--开发是依据需求文档的说明执行代码的开发。
3.环境也会引发软件失效
软件生命周期执行的阶段：
1.客户的问题引入定义：
客户提出需求，产品经理对客户收集客户需求。
2.可行性分析：
对象：客户的需求。
经济：1.当前客户的需求实行的话，那么是否可以带来具体的经济效益
2.当前项目的资金是否可以支持项目运作。
法律：1.禁止黄赌毒。
政治：1.不能出现政治敏感话题。
技术：1.当前项目的技术，是否可以实现客户的需求？
项目的招投标：
1.开发公司拟建发布公告，吸引有资质的承包商来承担当前项目组的部分开发工作。
项目立项：
1.项目组成立，招人，执行工作计划，执行项目周期，分配工作。
需求分析：
当前功能具体的需求文档、原型图进行分析。
1.开发分析完成之后执行开发工作
2.测试分析了解需求，发布后续更加全面执行测试
开发阶段：
1.开发设计开发逻辑，编写代码
2.测试人员执行测试，找出产品bug进行修复。
维护阶段;
1.软件发送给用户使用，在用户使用的过程当前持续的跟进用户的情况，进行改进。
2.准备下一阶段的开发工作
典型的软件生命周期模型有哪些？
什么是软件生命周期模型？
就是当前软件开发具体实施的内容阶段。
h模型，v模型，w模型，瀑布模型，增量开发模型，迭代开发模型，敏捷开发模型
瀑布模型：

1970年提出的开发模型。
优点：按阶段进行展开，每一个阶段的结束，代表下一个阶段的开展，适用于项目管理。
2.瀑布模型，清晰的表达了开发测试的阶段，是第一个重视测试的模型。
缺点：
1.如果开发按照流程走下去，一旦出现修改需求，或者开发理解错误需求，就会导致项目反工的情况，增加成本的开支
2.显示场景当中都是，按照用户的需求不断的完善当前的工作
3.测试人员介入的阶段太晚，对于早期的阶段工作内容不清楚导致测试覆盖程度不够。
v模型阶段：

用户需求：
产品经理引用客户的需求，整理输出需求文档、原型图
需求分析：分析当前的需求文档、原型图，分析当前的业务逻辑以及功能实现是否正确，以及当前的技术是否可以支持对于的开发工作
概要设计：简称hld（由开发人员设计，设计当前的开发产品的开发框架，以及服务器和数据库相关配置的设计，以及大致的业务逻辑设计）
详细设计：简称（lld 由开发人员进行设计，参照概要设计文档，设计当前交互的接口，以及数据结构设计，前端页面逻辑设计，ui设计等等）
编码阶段：依照详细设计文档，执行编码。开发程序。
单元测试：白盒测试，由开发人员针对自己所写代码进行检测，通过观察或者运行代码，检测项目是否符合标准的。
集成测试：简称it
集成测试的内容：
1.模块与模块合并集成，是否会产生影响，出现适配的问题
2.模块与模块之间数据传递是否正常
3.模块与模块之间功能调用是否正常
系统测试：简称st
集成测试通过，所有的模块都兼容，没有产生问题·，然后执行系统测试。
系统测试：又称全量测试，包含项目当中所有功能的测试，界面测试，可用性测试，易用性测试，界面测试，性能安全测试，都需要被执行。
验收测试：又称uat：
由谁进行验收？
可以由当前开发的项目组成员组织验收
可以由客户方进行验收
α：都是当前项目组成员组织进行验收测试，重新测试当前项目，看他是否达到了用户使用标准，推动版本的发布，给用户使用。
β：beta：客户方验收，我们当前项目组需要派出代表给客户讲解需求，客户组织验收，根据用户具体反馈问题，做持续的更近解决。
v模型的输入和输出的关系：
输入：用户需求   输出：需求分析
输入：需求分析   输出：概要设计
输入：概要设计   输出：详细设计
输入：详细设计   输出：编码阶段
输入：编码阶段   输出：单元测试
输入：单元测试   输出：集成测试
输入：集成测试   输出：系统测试
输入：系统测试   输出：验收测试
先阶段系统测试以及集成测试以及合并：
简称 stt 系统集成测试，在这个阶段所有集成测试的内容，系统测试的内容在同一个阶段进行执行
v模型虽然他概括了所有的测试阶段的流程，但是他的测试流程阶段依旧在开发编码之后，对于前面的问题在我执行测试的阶段才引入，导致我需求理解不透彻，测试覆盖不全面，导致增加测试市场。
w模型：

项目和产品的区别？
现有项目再有产品，产品是当前项目输出的结果。
项目和版本的区别?
项目是一个工程，版本指的是实际输出的版本号。
每个项目的初始都是v1.0，
项目都是包含版本的，一个项目当中可以包含多个版本
srs（需求规格说明书，
电商的主体业务流程
商品添加，进行支付，下单成功，待发货
如果支付
敏捷开发模型：
1990年提出。
能够快速的适应市场的变化，一旦市场需求变了，我也可以根据用户情况更快的改动。
2.交付周期，大概1-2左右一个版本，项目紧急就是1个星期一个版本，不紧急可能1-2左右时间完成一个版本的开发。
缺点：针对开发以及测试的能力要求比较高，敏捷开发模式一般很少会有实质性的文档产生，强调是人与人之间的沟通。
2.测试的覆盖程度不够全面，会经常产生问题。
增量开发模式：
1.将已知，待开发的功能进行模块化，分批次的进行开发交付给用户进行使用。（也是根据用户需求紧急程度来进行交付功能）
2.开发的顺序灵活，能够自由的调整开发顺序，也可以快速的适应市场
迭代开发模型：
1.先做成一给项目交给用户使用，在用户使用的过程当中，我在进行频繁的迭代，增加一些新的功能，这些功能都是未知的，根据市场的需求进行迭代功能
测试的基本原则：
1.测试标准是用户的需求;
测试的软件是否达到了用户标准
2.测试不单单是软件本身的测试
1.网络2.硬件配置3.环境4.兼容

二八原则：
模块如果出现比较多的bug，那么我们更加仔细的测试这个当前模块，因为bug可以引发更多的bug的产生
测试计划的(测试的准入）条件与控制：
测试的准入：
软件到达怎样的条件之后，测试人员介入测试
1.当前所有开发的功能已经按照需求文档实现
2.开发完成单元测试，并向测试提交测试报告申请单
3.输入的单元测试报告
测试分析与设计：
分析：需求文档当中具体需求
设计：设计执行测试的测试用例
测试的实现与执行：
执行编写的测试用例，找出软件当中的问题
测试报告（测试的准出):
测试过程当中资产归档（测试的总结）
产生一些文档
测试用例测试bug都需要进行归档留存.
资产:测试机(收集)
针对此次测试工程,有哪些做出总结.
(具体那个环节做的不好.进行总结)