1、为什么需要测试？
1、软件的缺陷和非正常运行会引发很多问题
2、人都是有可能犯错的，代码也是人写的，也有可能出现错误
3、环境影响
4、测试活动只是软件质量把控的重要活动之一，但不是唯一把控质量标准的手段
2、什么是测试？
软件：
1、验证软件的正确性
2、尽早的发现软件中的缺陷，是公司的成本尽可能降到最低
3、 测试是为了证明程序有错
4、一个好的测试用例，能发现之前没有发现过的bug
5、一个好的测试人员，具备发现之前没有发现过的bug的能力
3、飞蛾事件
4、软件的生命周期
1、客户问题的引入和定义--》客户要求的功能点，上线的时间，达成的目的
2、可行性分析
2.1成本和盈利
2.2政治风险
2.3法律因素（涉及到黄赌毒）
2.4技术问题，主要是看当前项目组的技术水平，是否能实现客户要求
3、项目招投标--》主要是哪个公司要的钱少
4、项目立项
4.1成立项目组
4.2人力的安排
4.3采购服务器，办公用品之类的设施
5、需求分析--》产品经理输出需求文档，进一步细化客户的需求，比如采用什么
样的形式实现客户的需求
6、开发阶段
6.1项目经理
6.2产品经理
6.3开发经理
开发人员--》写代码
前端开发
后端开发
UI设计师--》输出效果图
6.4测试经理
测试人员--》对开发出来的软件进行测试，保证交付的产品质量
7、维护阶段
运维人员--》处理客户的问题，或者线上的问题
8、停服--》下架了，不再提供相关的服务
5、瀑布模型
优点：每一个工作节点都比较清晰，工作的先后顺序比较分明
缺点：工作流程比较固化，比较难以应对频繁变更需求的项目，
在每个阶段的工作，标准不明确
6、V模型
1、用户需求阶段：产品经理对接客户
2、需求分析阶段：产品经理去引入客户的需求，将客户的需求进行提炼，召开需求澄清会议，
又叫需求评审：经过多次的讨论输出一个基线化的文档，叫需求文档，也叫需求规格说明书
需求澄清会议是产品经理召开，开发和测试
基线文档：一般拥有固定的格式，代表双发达成了一致，一般不会修改
3、概要设计，又叫HLD，就是把项目中需要实现的功能区域，划分为A模块、B模块，概要设计一般
是开发做，输出概要设计文档
4、详细设计：又叫LLD，把概要设计中区分好的模块，针对每个模块的功能点怎样实现，做出详细的规定
输出详细设计文档
5、编码和实现，又叫coding阶段，开发人员编写代码，然后将编写好的代码进行打包（rar，war，jar）
6、单元测试，简称UT，又叫白盒测试，主要是开发对于代码的语法和逻辑进行的测试，代码走查
7、集成测试，简称IT，又叫灰盒测试，又叫API接口测试，主要是保证模块单独的测试没有问题，和模块
的交互功能正常
8、系统测试，简称ST，又叫黑盒测试，也称为功能测试，主要是关注软件的功能是否正常，系统与系统
之间的交互是否正常，包括第三方系统的交互
9、验收测试，简称UAT测试
α测试：公司内部的人员进行模拟用户的操作进行验收测试，发现缺陷的话，此时开发人员对
缺陷进行修改
β测试：产品交付到客户的手中，客户参与验收进行测试，由客户进行问题收集，以邮件的形式
统一提交给项目组，由项目组来修改
输入 输出
用户需求 用户提出的需求 需求文档（初版）
需求分析 需求文档（初版） 需求规格说明书（SRS）
概要设计 需求规格说明书（SRS） 概要设计文档（HLD）
详细设计 概要设计文档（HLD） 详细设计文档（LLD）
编码实现 详细设计文档（LLD） 代码包
单元测试 代码包 单元测试报告
集成测试 单元测试报告 集成测试报告
系统测试 集成测试报告 系统测试报告
验收测试 系统测试报告 验收测试报告
7、H模型
SRS澄清会议：需求评审会议，产品经理召开，参会人员：开发、测试、产品
review ：审阅、评审
TPM:测试经理--》负责输出测试计划和测试方案（规定的测试范围，人力的安排，时间节点的安排，风险
分析--》时间上的风险，组内有新人加入要重点关注一下新人负责的模块，可能会有漏测或者效率不高的情况）
项目组中有哪些评审会议？
1、需求评审，产品召开，参会人员：开发、测试、产品，在需求评审中，一般测试人员主要项目中的异常
场景的处理和开发进行确认和约定，并保持对需求文档的理解跟开发和产品是一致的
2、用例评审，测试人员召开，参会人员：开发、测试、产品，在用例评审中，测试人员主讲，主要是看我
们测试组编写的测试用例的覆盖度和测试方法以及测试策略是否正确，还要对测试用例的预期结果跟开发
保持一致，避免后续返工以及因为缺陷的问题与开发有争执
3、交叉评审：测试组内同事之间进行评审，一般没有产品参与
4、组内评审：项目组的开发、测试、UI设计师、产品一起评审
5、会议评审：有客户参与的评审会议
testlink：是一款用例管理工具，相似的平台：禅道
TPM搭建测试环境，项目组中有哪些环境？
1、开发环境：开发人员进行编码和代码调试的环境--》dev环境
2、测试环境：测试人员进行测试活动的环境--》sit环境
3、准生产环境/预发布环境：模拟用户的场景，产品经理进行验收的环境，这里的代码跟将要上线的代码
是一样的--》uat环境
4、生产环境/线上环境/正式环境，真实的客户使用的环境
环境搭建好以后，开发人员进行代码打包，由TPM或者测试骨干或者运维部署项目包，项目包一般部署在linux系统上
冒烟测试：在集成测试和系统测试之前进行，一般选择一些主线的流程/主体功能进行测试，主要是看主体功能是否
能够跑的通，冒烟测试不通过，直接打回给开发人员进行修复，修改完成以后继续冒烟，知道冒烟通过才可以进行
接下来的测试
sit1：称为全量测试，就是把所有的案例全部都执行一遍，有bug的话要协助定位bug
sit2：又称为回归测试，主要是针对第一轮出现bug的案例和有可能会影响到的案例进行重复执行，重点复测，防止
开发在修复bug的时候引发新的bug
回归测试的内容：
1、第一轮出现缺陷的案例
2、可能会影响到的模块
3、增量案例：在测试过程中增加的案例
4、冒烟测试
测试准出的标准：
1、需求中规定的功能，全部得以实现
2、所有的案例全部都执行通过
3、发现的缺陷，要全部修复，或者可以遗留1-2个建议性的缺陷，不影响功能的使用和客户体验
项目、产品、版本之间有什么关系？
先有项目，后有产品，一个产品可以有多个不同的版本
项目上线：
上线前：测试人员进行交叉测试或者随机测试
上线中：整理当前版本输出的文档，进行归档--》需求文档、测试计划、测试大纲、测试用例
上线后：在正式环境环境中进行线上验证（所有的测试活动都要按照用户的操作来进行，测试环境中
出现过bug的模块进行验证）
测试报告：
1、测试范围
2、不测试范围
3、bug-list：bug列表，主要是每一轮测试测出来有哪些bug，bug的修复情况，产生的原因分析
4、风险分析
a：遗留缺陷的影响
b：新人负责的模块，有可能漏测
5、本次迭代业务总结
a：业务上的总结，比如加入了优惠券的功能
b：工作方法的总结，比如工作中遇到了哪些阻塞性的问题，占用太长时间，以后怎么规避
如果发版以后出现了很严重的bug，导致项目崩溃，一时间难以修复，怎么办？
回滚，也叫版本回退
8、敏捷迭代
1、周期短，1-2周就一个版本
2、轻量级，每个版本的任务量不大
3、晨会，15-20分钟
昨天预计做什么，实际做了什么，有哪些差异，产生差异的原因
今天预计做什么，做多少，预计进度如何，有没有发现风险
9、增量开发
1、比较适合复杂且周期比较长的项目，可以将项目进行独立的功能划分，分多个版本上线
2、可以避免前期公司投入太多的人力物力，降低风险
10、测试的基本准则
1、测试不仅仅是软件本身的测试
1.1了解项目的背景和目的
1.2考虑外在的环境因素对项目的影响--》弱网
2、测试应该尽在介入
2.1需求评审的时候介入，对需求更为透彻的理解，为后面的编写测试用例打下基础
2.2降低项目延期的风险
2.3测试介入的越早，问题修复的成本就越低
3、二八原则
80%的缺陷会集中在20%的区域内--》开发修复缺陷的过程中很有可能引发新的bug
4、杀虫剂效应
在测试过程中，发现案例存在遗漏，或者案例的回归已经发现不了新的bug了
解决方法：做案例增量
11、测试活动的生命周期
1、测试计划
2、测试分析与设计，主要做一些测试大纲类和测试用例的文件
3、测试的执行，根据测试案例进行测试活动
4、测试报告的输出
5、测试资产--》需求文档、测试计划、测试大纲、测试用例、测试报告，业务上的知识沉淀文档
|
|
135
0
多测师社区 
