1.非正常的运行
2.自身的缺陷：代码+文档
制造业的定义：以检验产品是否满足需求为目标
软件行业的定义，有多种说法：
a：验证软件的正确性
b：发现软件中的缺陷
发现软件中的缺陷的3种观点：
1.测试是为了证明程序有错
2.一个好的测试用例：在于它能发现以前未发现的错误
3.一个成功的测试：能发现前所未有的错误的测试
测试用例：是用于测试工作的一份专业文档
包含要素（用例序号、用例标题、前置条件、操作步骤、预期结果、实际结果）
软件生命周期别称：软件生存周期或软件开发生命周期
1.指的是软件从生产到报废的整个过程，是一种时间概念
生命周期的阶段：
1.客户问题引入或定义
2.可行性分析（产品经理、项目经理、开发经理、测试、架构师、技术大佬）
2-1.项目成本（人力、天数）
2-2.商业/法律
2-3.政治风险：诋毁国家
2-4.技术难关：根据公司现有的技术能力是否能解决实现 项目功能
3.项目招投标（对比双方的时间、预算、资质等各方面的优势）
4.项目立项
4-1.成立项目组
4-2.人力安排、时间安排
4-3.采购服务器
5.需求分析---产品经理收集客户需求，输出需求文档：进行需 求分析
5-1.参与人员：所有参与项目研发的人员
5-2.需求分析由产品经理主导
6.开发阶段（设计、编码、测试）
6-1.UI设计师：输出效果图
6-2.开发工程师：进行编写代码
6-3.测试：对项目软件测试验证
6-4.交付给客户进行验收
7.维护
生命周期模型有哪些？
瀑布模型
V模型
W模型
H模型
敏捷开发模型
迭代开发模型
增量开发模型
V模型
1.需求分析--产品经理根据用户需求提炼为项目需求，召开需求澄清会议（需求评审）：
经过对轮讨论分析最终形成一个基线化文档，叫需求规格说明书，简称SRS
基线文档：代表各方对该文档达成一致，可以进入下一阶段
2.概要设计：简称HLD，项目分为模块A、模块B、模块C--开发输出概要设计文档
3.详细设计：简称LLD，针对每个模块中具体的功能怎么实现---开发输出详细文档
4.编码和实现：开发人员编写代码（代码打成压缩包文件、.war/.jar）
5.单元测试：简称UT，又称白盒测试---对代码进行测试，由开发人员完成
6.集成测试：简称IT，模块A/模块B/模块C单独测试没问题，放在一起进行测试，又称灰盒测试，接口（api）测试
7.系统测试：简称ST，又称黑盒测试，也就是功能测试，除了保证当前软件的功能正常使用，还需要保证与第三方系统对接不会出现问题
8.验收测试：简称UAT
α（阿尔法测试）：公司内部的开发和测试人员模拟用户行为操作软件，对此时发现的bug进行修复
β（贝塔测试）：产品已经交付到客户手中，此时出现bug，客户进行收集发送邮件抄送给项目组
9.上线
项目经历了哪些阶段？每个阶段的输入与输出是什么？
输入 输出
需求分析 用户需求 需求规格说明书（SRS）
概要设计 需求规格说明书 概要设计文档
详细设计 概要设计文档 详细设计文档
编码阶段 详细设计文档 代码包（.war/.jar）
单元测试 开发部署环境 单元测试报告
系统集成测试 单元测试报告 系统集成测试报告
验收测试 系统集成测试报告 验收测试报告
H模型：
SRS澄清：需求评审，得到需求规格说明书
TPM：测试经理编写测试计划（规定的测试范围，人力的安排，软件与硬件的资源、测试进度、风险评估）
风险评估：1.新人参与测试 2.项目需求延期提测
项目组常用的评审：（用例评审，谁写的谁讲）
交叉评审：测试组内同事之间进行评审；
组内评审：项目组开发、产品、UI设计、测试进行评审；
会议评审：有客户参与；
testlink：是一款用例管理工具
TPM或测试骨干或运维人员搭建测试环境
公司有哪些环境？
开发环境：开发人员编码使用的环境
测试环境：测试人员测试当前项目软件的环境
预发布环境：模拟用户使用场景，产品经理验收使用
生产环境：线上环境、真实环境
环境搭建好了之后，开发人员将开发的功能代码打包，交由TPM或运维人员进行部署测试环境，部署完成之后重启服务器，就可以通过浏览器访问；项目部署一般都是在Linux服务器上
冒烟测试：在sit1系统集成测试之前执行，在测试用例中选取部分用例进行测试；
定义：对主体功能进行测试
QQ登录功能主体功能是什么？---QQ登录成功
QQ注册功能主体功能是什么？---成功注册新的QQ帐号
冒烟测试不通过：版本打回，开发人员重新编码修复，修改完成之后再次进行打包部署，再次进行冒烟测试，直到能通过冒烟测试
系统集成测试
SIT1：又称全量测试，需要测试所有编写的测试用例：假如编写了1千条测试用例，需要全部执行测试完成：
SIT2：称为回归测试----450条（逐渐变少）
回归测试要测试哪些内容？
1.测上一轮发现bug的用例；
2.测试与上一轮发现bug相关模块的用例；
3.每一轮都执行冒烟用例
4.测试新增加的用例
SIT3：回归测试----120条
SIT4：回归测试----50条
上线硬性标准
《0》bug
允许带易用性bug上线（易用性bug不会影响功能使用）
当前版本发现的易用性bug如果要留到下个版本中解决，必须要做好记录并邮件告知项目相关成员
项目与产品：先有项目然后才有产品
项目与版本：一个项目会有多个版本
灰度发布：小范围发布、降低风险
敏捷开发模型：
周期短：1-2周一个版本
轻量级：每个版本的任务量不会太多
晨会：15分钟左右
1.对前一天的工作进行总结
2.对当天开发工作的进度安排
3.是否存在延期风险
增量开发模型
迭代开发模型：将复杂且周期长的项目，划分为多个独立的功能模块划分为多个版本开发上线
微信：聊天列表、通讯录、零钱、扫码支付
第一个版本：聊天列表、通讯录
第二个版本：零钱、扫码支付
1.测试不仅仅是单纯的软件本身的测试
1-1.了解功能背景的目的
1-2.软件是否受到外界因素的影响（弱网/断网）
2.测试应尽早介入
2-1.需求分析评审，对需求理解更加透彻，为后面输出测试用例和测试工作打下基础
2-2.确保开发、测试和产品经理对需求理解是一致的，规避后面功能开发出现错误
2-3.尽最大可能降低项目延期的风险
3.二八原则：80%的错误会出现在20%的区域
4.杀虫剂效应
测试准入：
基线需求文档（SRS）
概要设计文档（HLD）
详细设计文档（LLD）
通过冒烟测试
控制：时间周期、风险控制
准出标准：
《0》bug
输出测试报告
1.测试计划
2.测试用例的编写，输出测试用例
3.测试实现与执行（冒烟测试、SIT）
4.输出测试报告，达到准出标准
5.版本文档归档
|
|
194
0
多测师社区 
