多测师第二课

为什么要测试？
1软件自身的缺陷，代码+文档
2代码是人写的，人都有可能犯错
3环境也会影响软件，以致出现软件“失效”现象
4软件测试活动只是关键的质量保证之一，不是唯一
bug起源：飞蛾事件

什么是测试？
1验证软件的正确性
2发现软件中的缺陷
a:测试为了证明程序有错  
b:一个好的测试用例能够发现之前没有发现过的错误

什么是测试用例？
是用于执行测试的一份专业文档包含:用例编号，用例标题，前置条件，操作步骤，预期结果，实际结果，优先级

测试软件生命周期
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.1UI设计师，输出效果图
6.2开发工程师编码
6.3测试工程师，对开发输出的软件进行测试，保证产品质量
6.4交付给客户使用/验收
7维护阶段---处理一些线上问题
瀑布开发模型：系统需求--软件需求--分析--程序设计--编码--测试--运行（完成上一阶段才会开始下一阶段）
优点：每个工作阶段比较清晰，工作职责先后顺序分明
缺点：工作流程固化，难以应对频繁变更需求的项目
V模型：


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

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发现的缺陷全部被修复（0BUG），也允许有一个易用性的缺陷遗留，前提是这个bug 不能影响功能的使用
项目与产品：现有项目后又产品
项目与版本：一个项目可以包含多个版本
项目上线：产品经理会提前告知相关人员具体的上线时间，测试人员需要配合上线前，上线中和上线后的工作
1上线前：测试人员做随机测试或者交叉测试
2上线中：整理当前版本的相关文件记录并归档---需求文档最终版，测试案例，测试计划
3上线后：要在正式环境中进行测试（所有的测试都按照用户的操作进行验证）
测试报告主要包含哪些内容？
1测试范围
2不测试范围
3bug列表，包括每一轮出现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基线文档完备（概要设计等等一些）