笔记2-软件的生命周期

为什么要测试？
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）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.1 将问题前置话，规避后面开发可能会犯的错误、保证开发，测试、产品的理解是一致的。
2.3 降低延期的风险。
3、二八原则
80%的错误都会集中在20%的区域中
4、杀虫剂效应
在测试过程中，发现用例存在遗漏，或者实际的开发迭代中，用例的回归，发现不了新的bug就要考虑更新补充一下测试用例，达到测试效果。

测试的准入标准
1、冒烟测试通过
2、基线文档完备