1、客户问题的引入与分析---从而产生开发产品的想法
---产品经理/客户
2、可行性分析（技术方法能否实现；做这个项目能不能挣钱；有没有涉及侵权、涉及政治，以及是否违法）
---产品经理/需求人员
3、项目招投标：指确定项目的交付周期
---项目经理
----项目经理
5、需求分析：由产品经理召开一个需求澄清会议，然后由产品经理主讲---产品经理
6、开发测试阶段：开发编写代码、测试设计测试用例并且执行测试用例
7、部署维护
部署：指软件进行上线或者给客户进行安装部署
维护：软件开发完成后投入使用，由于各方面的原因，软件不能适应客户的需求，需要延续软件的使用寿命，就必须对软件进行维护。
8、升级淘汰阶段：
升级阶段：修复错误（bug）、添加需求等等，编码后测试通过，进行推送升级
淘汰阶段：客户不用了：他又去找开发做了一款满足他需求的软件，意味着一款新的软件诞生，软件的生命周期又开始轮回起来了
2.3软件生命周期模型：（测试流程）
开发模型：瀑布模型(waterfall)、V模型（重点讲解）、W模型、H模型（重点讲解）、敏捷开发模型（重点讲解）、迭代开发模型、增量开发模型（了解）
---瀑布模型（waterfall）
明确了每一步需要完成的工作内容，但同时也导致每步工作之间关联性很强，上一步没有完成就无法开展下一步工作。
测试模型：V模型、W模型、H模型（重点，要求掌握）
---V模型
V模型是瀑布模型的变种，把瀑布模型中的测试阶段与之前的分析设计阶段对应起来，得到V模型
需求（简称：srs）全称：软件需求规格说明书
1、用户需求：一个文档，对整个项目的设计、框架、功能、模块的描述
2、概要设计：简称HLD，一个文档，架构的初步设计文档，使用说明什么类型数据库，架构的描述，设计，模块的名称（可理解为：盖房子的大概设计，基本框架结构）
3、详细设计：简称（LLD），一个文档，针对功能具体的实现，模块的具体实现，具体设计，架构的具体描述，（可理解为：房子的具体的装饰设计）
（1）单元测试
单元测试：指验证软件单元是否满足详细设计文档的规格，能正确的执行，主要是对代码的测试。单元测试也是最小的测试单位。在工作中单元测试一般情况是开发自测，如果需要测试进行单元测试，对测试的技术要求非常高，必须要懂开发语言；
（2）集成测试
集成测试是指多个单元组合验证软件是否满足概要设计文档的规格，能正常执行，主要是模块与模块之间的数据交互。
（3）系统测试
系统测试是指把软件进行正常运行，对整个软件系统进行测试，验证这个系统能正常的运行，主要是测试一个整体业务的流程。
（4）验收测试
验收测试是指：站在用户角度去对软件进行测试，验证系统满足用户需求；
验收测试测试分为两种：alpha测试（α）和bete测试（β）
α测试是内部测试β测试是客户方测试
α测试和β测试区别：
1、α测试测试地点：是在自己公司；β测试一般在客户方
2、α测试都是内部人员进行测试，开发在现场及时发现问题，及时解决；β测试是在客户方的员工测试，发现问题同意反馈非开发在解决
备注：
（1）集成测试（it）和系统测试（st）合并成（sit测试）
（2）sit测试（系统集成测试），技术测试；uat测试（验收测试）
（3）sit环境（sit1环境，sit2环境，sit3环境）；uat环境（专门用来验收环境）
（4）环境：
a.线上环境（也叫生成环境）：客户在实现
b.测试环境：测试人员使用
c、开发环境：开发人员使用
V模型优点：
1、非常明确的标明了测试过程中存在的不同级别，并且每个级别与分析设计阶段对应，这个测试他不是用同一种方法进行测试，他是每个不同阶段都有一个不同的方法
2、每个测试阶段有明确的交付物
V模型局限性：不够灵活，测试阶段介入晚
如果用户的需求在提出时就有问题，或者是在设计阶段就有，是发现不了，直到开发编码完成把这个东西做出来后开始单元测试，才能发现，甚至更后面才能发现问题，越往后发现我们需要返工的东西就会越多，从而成本也会越大。问题发现的晚，修复的质量产品的质量也会降低.
---W模型
---敏捷开发模型（重点）
敏捷开发模型是一个新型模型适应快速需求变化，交付周期比较短，轻量级的开发模式。
产品拿到一个需求，开发一周，测试编写用例，第二周测试区测试，开发修改，修改好就上线
---迭代开发模型
项目被分为一系列的增量，每一个增量都交付整个项目需求中的一部分功能，需求按优先级进行划分增量的交付。
如：买家版，卖家版，商家版，，先左买家版，
---增量开发模型
如：买家版，卖家版，商家版，先左买家版，
---H模型
（1）需求澄清会议（产品经理会组织需求会议）
（2）拿到需求，深入分析和了解需求文档
（3）测试经理编写测试计划（重点)
测试计划：（内容：测试目的，背景，范围，测试准入，测试准出，环境和资源，测试任务和测试进度，风险及风险管理，测试交付文档）
准入：
开发：需求分析报告，需求规格说明书，概要设计说明书，详细设计说明书，版本说明书及开发自测报告；
测试：测试计划，测试用例通过，测试环境搭建好
准出:
a.用例100%执行
b.0bug
c.输出测试报告
（4）编写用例
（5）评审用例（测试人员：组内评审（开发，测试，产品都参加），交叉评审（测试人员之间评审））
（6）用例评审通过以后导入到用例管理工具中禅道.
（7）搭建测试环境（运维搭建，自己搭建）
（8）开发提交代码包，提测（也叫转测）
（9）测试将代码包部署到环境，
（10）进行冒烟测试，冒烟测试通过，进入sit测试，如果，冒烟测试不通过，就把版本打回非开发，开发修改，在提测。
冒烟测试（也叫版本验证测试）定义：指对新本本的主要功能，基本功能进行测试。
如果通过，那么冒烟测试通过，如果冒烟测试失败，那么就把版本打回给开发进行修改，直到冒烟测试通过
（11）sit系统集成测试（一般一个项目有3次系统集成测试，有些项目周期长也有4次，5次）
（12）第一次sit测试也叫全量测试（把前面写的所有用例都要进行测试），测试出来的bug，指派给开发（通过禅道），测试小结
（13）开发修改bug，在提交
（14）第二次sit测试，第二sit测试测试前要冒烟测试，冒烟测试通过以后才能进行第二次sit测试；
第二sit测试和第三sit测试都叫做回归测试
回归测试：是系统维护阶段进行的验证测试
区别：测试阶段不同
冒烟测试是版本提交时第一个测试，回归测试是在维护阶段测试
（14）第二次sit测试，在将bug提交给开发，开发修改，
（15）第三sit测试，先冒烟测试，在去测试，验证。。。。。。以此类推
a、冒烟测试用例
b、验证上一个版本提交bug的用例
c、测试和bug有关联的模块用来
d、你认为可疑的测试场景和测试用例
e、测试补充的测试用例和测试场景
（16）直到用例100%执行，0bug，
（17）输出测试报告=========================说明sit测试测完
测试报告：
内容：测试目的，测试范围，测试背景，测试实施日期，测试人员，bug清单，用例清单，测试结果，
（18）sit测完通知uat测试，uat验收通过，
（19）封板（封装版本）
（20）等待上线
（21）上线前准备线上数据
（22）上线后在线上测试，
（23）测试没有bug，如有bug就要分析bug，bug影响程度，影响大，就回退版本，如果影响小就备注下次版本修改
（24）上线成功
—————————————————————————————
H模型（重点，要求掌握）
目前软件行业市场，主要都是以H模型的流程，进行软件开发工作
H模型我们可以理解为项目流程
什么项目？什么是产品？什么是版本？什么是迭代？
项目和产品的区别？先有项目再有产品
项目和版本的区别？一个项目中项目只有一个，版本可以有多个
H模型特点：
1、H模型开发、测试活完全独立，各自形成一个独立的流程，并且与其它流程并发进行
2、H模型贯穿与产品的周期
3、软件测试可以尽早的进行，也可以根据被测物的不同而分层次进行
测试准备阶段
需求下来了后，项目经理就会把需求文档分给开发经理、测试经理，然后把需求文档分给对应的开发、测试，分下来干嘛？分下来去看在看的过程我们每个人的理解想法意见不一样，所以要开一个需求澄清会议（产品经理召开，产品经理主讲），大家把各自的意见、想法、建议都抛出来进行讨论，经过多次讨论后，大家都认可了，想法也一致了，然后最终就会输入一个基线化文档：
SRS：需求规格说明书
基线化文档：表示这个文档已经确认了，稳定了，没有特殊情况不会进行修改了，同时它也是进入下一个环节的基础
SRS澄清后
开发这边：
1、编写概要设计说明书（HLD）：就是这个需求需要哪些功能或者是需求分为哪些模块列出一个大纲
2、编写详细设计说明书（LLD）：就是对概要设计说明书列出的功能或模块进行详细设计
3、coding（编码实现）
测试这边
1、评审概要设计说明书（reviewHLD）
2、继续了解SRS
1、评审详细设计说明书（reviewLLD）
2、深入了解SRS
为什么测试人员可以评审开发人员编写的HLD和LLD？
因为开发和测试看的是同一份需求文档，开发要实现的功能，测试人员也是清楚的，所以测试人员也可以评审（但是实际工作中一般没有这个步骤）
如果我们对需求不够了解，在设计测试用例的时候可能就会出现覆盖不全，可能导致漏测，漏测在测试工作中属于比较严重的问题，所以得特别注意
3、TPM（测试经理）
输出一个测试计划/测试方案（一般由测试经理编写）
1、TE输出TC初稿，并进行多次用例评审，最终形成用例基线文档
TE（软件测试工程师）
TC（测试用例）
多次用例评审，有哪几种用例评审方式？
1.交叉评审：测试团体成员之间进行评审
2、团队评审：产品经理、开发、测试、运维一起评审
3、会议评审：有客户参加
2、TPM（测试经理）将基线用例输入到testlink（用例管理工具）并将TC（测试用例）分配给TE（测试）谁写的谁测
3、TPM或测试骨干或者是环境运维人员搭建测试环境
公司里的环境有哪几种？
3.1开发环境：开发人员使用的一个环境
3.2测试环境：测试人员使用的一个环境
3.3正式环境/生产环境：正式对外提供服务，客户正式使用的环境
测试就绪点
测试环境搭建好了，开发编码也完成了，开发负责人会讲开发的代码打成一个war包，交由测试经理或者是运维人员去部署到测试环境的linux服务器上，部署完成后启动服务器，就可以通过浏览器访问网页，测试工作就可以开始了
测试执行阶段
什么是冒烟测试？
确认软件的基本功能是否正常，需求的主流程是否正常，是否可以进行后续的测试工作，如果冒烟测试不通过，就暂时先不进行正式的测试工作，把这个冒烟不通过的这个需求打回给开发，让他去修复，什么时候冒烟能通过，什么时候进行正式测试工作（只针对当前需求）
确认基本功能是否正常，基本功能是什么？
比如支付宝基本功能-支付
淘宝基本功能-购物
开发完成需求后需要进行自测（冒烟测试），自测通过提测
冒烟测试通过后正式执行SIT
SIT（系统集成测试/全量测试）全量测试什么意思？
就是把所有的用例都进行执行一遍，比如我们写了1000用例，就要把这1000条用例全部执行完
第一轮SIT1，全量测试，执行所有用例
第二轮SIT2，我们称之为增量测试/回归测试
增量测试：我们在测试过程中，测试某个功能点，就发现按照原理的用例来测试覆盖的不是很全，所以要在原先的用例上再加上几条用例，把这个需求测试点给覆盖完全
回归测试：开发在修复bug可能会对其它代码造成影响，然而出现新的问题，如果不去进行回归测试，这些问题就发现不了
回归测试要测什么？
一般情况下测试这些内容就可以了
1、新增这些用例
2、执行上一轮发现bug的这些用例
3、执行与上一轮bug所属模块的用例以及有关联的模块的用例
4、再进行一轮冒烟测试
第三轮SIT3，回归测试
。。。。。。
SIT40/1：上线的硬性要求
用例执行100%，软件需求分析均已实现
测试准出报告
2.4测试流程
1、首先是用户需求
2、用户提出需求后，接下来会对需求进行一个分析，这时产品经理会召开一个需求澄清会议，把需求人员（产品经理、开发、测试、运维）拉过来，由产品经理主讲，一起把需求讲清楚，经过多次的分析，多次的讨论，最终会输入一个基线化文档——需求规格说明书文档，英文简称：SRS（这个文档是确定了，稳定了，一般没有特殊情况不会再进行修改了）
3、概要设计
4、详细设计
5、编码实现：开发编写代码实现需求
测试的基本原则：
1、测试是从用户的角度去测试；（用户故事测试）
2、测试不仅测试是软件本身，测试环境，配置，网络等
3、软件外在可用，不代表软件没有问题
4、软件测试是没有完成正确，只有更加完美
5、测试是永远测不远
6、测试应尽早介入，
7、2/8原则，（80%的错误集中在20%的区域）
8、杀虫剂效应
9、测试尽量选择第三方测试
10、测试活动的依赖对象（功能测试，性能测试，安全测试等）
测试活动的周期
测试计划（安排任务）-------测试分析和设计（编写用例）-----测试实现执行（测试阶段）---输出测试报告----资产归档（测试文档）
准入（也叫转测，也叫提测）：
开发：详细设计，概要设计，开发自测报告，
测试：测试计划，测试用例，测试用例审核通过，搭建好环境