软件的生命周期

为什么要测试？
1、软件自身的缺陷，代码+文档
2、人都有可能犯错，代码也是人写的，也会有错误
3、环境影响
4、测试活动只是质量保证之一，不是唯一
bug起源：飞蛾事件
什么是测试？
1、验证软件的正确性
2、发现软件中的缺陷
a.测试为了证明程序有错
b.一个好的测试用例能够发现之前没有发现过的错误
c.一个成功的测试，能够发现前所未有的错误的测试
什么是测试用例？
是用于执行测试工作的一份专业文档，包含用例编号、用例标题、前置条件、操作步骤、预期结果、实际结果、优先级

软件的生命周期
1、客户问题的引入和分析（客户的要求、上线的时间、达成的目的）---产品
2、可行性分析--（产品经理、项目经理、开发经理、测试经理，架构师，技术大牛）
2.1 成本
2.2 商业/法律
2.3 政治风险
2.4 涉黄涉赌涉暴
2.5技术难关，项目组的技术水平
3、项目招投标
看哪个公司要的钱少
4、项目立项
4.1 成立项目组
4.2 人力安排
4.3 采购 服务器之类的
5、需求分析阶段--产品经理输出需求文档，进一步细化客户的需求
5.1 参与人员，项目中所有的开发、测试
5.2 需求由谁主导，一般情况下是产品经理主导的
6、开发阶段
6.1 UI设计师，输出效果图
6.2 开发工程师， 编码
6.3测试工程师，对开发输出的软件进行测试，保证产品质量
6.4交付给客户使用/验收
7.维护阶段--处理一些线上的问题

瀑布模型：
1、优点：每一个工作阶段都是比较清晰的，工作职责和先后顺序比较分明
2、缺点：工作流程比较固化，难以应对频繁变更需求的项目

V模型：
1、用户需求的引入--产品经理去对接
2、需求分析：产品经理根据用户的需求，提炼项目需求，召开需求澄清会议（需求评审）
经过多次讨论形成一个基线化的文档，叫需求文档/需求规格说明书（SRS）
基线文档：代表各方对文档已经达成一致，可以进行下一步的工作
3、概要设计，简称HLD，项目可以分为模块A、模块B等等，概要设计一般是开发人员输出
4、详细设计，简称LLD，针对每个模块中的功能点具体怎样实现，做出规定，详细设计一般也由开发输出
5、编码和实现阶段（coding阶段）：开发人员编写代码（代码打包成压缩包，war/jar）
6、单元测试阶段，简称UT，又称为白盒测试，一般是由开发人员完成，主要针对代码逻辑和代码的语法和内部数据进行测试
7、集成测试，简称IT，又称灰盒测试，接口（API）测试，主要是保证模块单独测试没有问题。
8、系统测试，简称ST，又称为黑盒测试，主要关注当前软件的功能正常使用，系统与系统之间的交互，包括第三方的系统交互
9、验收测试，简称UAT，
α测试：公司内部的人员模拟用户的操作行为，对软件进行测试，此时开发人员对发现的缺陷（bug）进行修复
β测试：产品交付到客户手中，客户参与验收，进行测试，此时发现的缺陷（bug），由客户进行搜集发送邮件到项目组
输入输出
用户需求     用户提出的需求            需求文档（初版）
需求分析     需求文档（初版）       需求规格说明书（SRS）
概要设计 需求规格说明书（SRS）                    概要设计文档（HLD）
详细设计阶段              概要设计文档（HLD）         详细设计文档（LLD）
编码和实现  详细设计文档（LLD）代码包
单元测试                    代码包                                    单元测试报告
集成测试                 单元测试报告                             集成测试报告
系统测试                 集成测试报告                             系统测试报告
验收测试                 系统测试报告                             验收测试报告

H模型：

SRS澄清：需求评审会议，得到需求规格说明书--召开人员：产品经理，参会人员：测试、开发
review：评审
TPM：测试经理编写测试计划（规定的测试范围，人力安排，时间安排，风险的评估--1.有新人参与 2.延期提测）
项目组中的评审有哪些？
1、需求评审，召开人员：产品经理，参会人员：测试、开发，产品主讲
在这个会议中，测试人员主要针对项目中的异常场景的处理与开发进行约定，并在对需求文档的理解上，跟开发和产品保持一致
2、用例评审，召开人员：测试人员，参会人员：开发、产品，测试主讲
在用例评审中，主要是看我们测试组编写的用例覆盖度、以及测试的方法和方向是否正确，主要关注预期结果，与开发沟通保持一致，避免后面因为缺陷问题产生争执
3、交叉评审：测试组内同事之间的评审，一般没有开发和产品参与
4、组内评审：项目组的开发、测试、UI设计师、产品经理一起进行评审
5、会议评审：有客户参与的评审

testlink：是一款用例管理工具
TPM或者测试骨干搭建测试环境，环境有哪些环境？
1、开发环境：开发的人员编码使用的环境---dev环境
2、测试环境：测试人员进行测试活动的环境---sit环境
3、预发布环境：模拟用户的使用场景，产品经理进行验收的环境---uat环境
4、生产环境：又叫线上环境，真实的客户使用的环境

环境搭建好以后，开发人员将代码包打包提到电子流平台，由TPM和运维部署到测试环境，部署完之后重启服务器，然后通过浏览器访问，项目一般都部署在Linux系统中

冒烟测试：要在集成测试、系统测试之前进行，一般选择主线流程的20-30条用例进行执行，主要是看项目的主体流程是否能够跑的通（对主体功能的测试）
qq登陆的主体功能是什么？qq登陆成功
qq注册的主体功能是什么？qq注册成功

冒烟测试不通过：版本打回，开发人员进行重新修改，修改完成以后再进行打包部署，再执行冒烟，直到冒烟通过，才可以进行接下来的测试
sit1：称为全量测试，需要把所有的案例进行执行，编写了1000条案例，就执行1000条，要全部执行完成
sit2：又称为回归测试，主要是针对第一轮出现过缺陷的案例，以及可能会影响到的案例，包括冒烟的案例，进行重复执行--》400条

回归测试主要测试那些内容？
1、测上一轮发现bug的案例
2、发现bug的相关模块的案例
3、增量案例：指在测试过程之中新增的案例
4、冒烟的案例
测试准出的标准：
1、需求中规定的功能模块得以全部实现
2、编写的测试案例被全部执行
3、发现的缺陷，全部被修复（0 bug），也允许有1个易用性的缺陷遗留，前提是这个bug不能影响功能的使用
项目与产品：先有项目，后有产品
项目与版本：一个项目可以包含多个版本
项目上线：产品经理会提前告知相关人员具体的上线时间，测试人员需要配合上线前、上线中、上线后的工作
上线前：测试人员做随机测试或者交叉测试
上线中：整理当前版本的相关文件记录并归档--需求文档最终版，测试案例，测试计划
上线后：要在正式环境中进行测试（所有的测试都按照用户的操作进行验证）
测试报告主要包含哪些内容呢？
1、测试范围
2、不测试范围
3、bug列表，包括每一轮出现bug的列表，bug产生的原因分析，bug的修复情况
4、风险分析
a.遗留缺陷的风险分析，主要分析该缺陷会对什么模块或者什么功能产生影响
b.组内有新人加入，对业务不是很熟练，新人负责的模块可能会有漏测，需要重点关注
5、本次迭代的内容总结
a.业务上的内容总结，本次新增了什么功能，修改了哪些功能
b.工作方法上的总结，本次迭代，遇到了哪些阻塞性的问题，怎样解决的，以后的工作怎么避免类似的问题


敏捷开发
1、周期短，一般1-2周一个版本
2、轻量级，每个版本的任务量不会太多
3、晨会：15分钟左右
前一天工作的总结
当天工作的安排
是否发现风险（延期风险）

增量开发
1、将复杂且周期长的项目，划分为独立的功能模块，分多个版本进行开发上线
2、可以有效的避免公司前期投入巨大的财力和人力，可以降低公司承担的风险
微信：聊天、通讯录、发红包、收藏、小程序、公众号
第一个版本：聊天列表和通讯录
第二个版本：发红包、收藏
第三个版本：小程序、公众号

测试的基本原则：
1、测试不仅仅是软件本身的测试
1.1 了解功能的一些背景目的
1.2 考虑软件在受到其他的外界因素的影响：弱网/断网
2、测试应该尽早介入
2.1 需求评审，对需求的理解更为透彻，为后面的输出的测试用例打好基础
2.2 将问题前置化，规避后面开发可能会犯的错误，保证开发、测试、产品的理解是一致的
2.3 降低延期的风险
3、二八原则
80%的错误都会集中在20%的区域中
4、杀虫剂效应
在测试过程中，发现用例存在遗漏，或者实际的开发迭代中，用例的回归，发现不了新的bug，
就要考虑更新补充一下测试用例，达到测试的效果

测试的准入标准
1、冒烟测试通过
2、基线文档完备
测试计划（测试准入）与控制——测试分析与设计——测试实现与执行——测试报告（测试准出）——测试过程资产归档（测试总结）