软件测试 —— A / 入门
🌈个人主页：慢了半拍
🔥 创作专栏：《算法分析》 | 《无味生》 |《C语言》 | 《C练习解析》|《C++讲解》|《软件测试》|《Linux》|《数据结构》|《计组》
🏆我的格言：一切只是时间问题。
目录
一、测试认知
二、需求概念
三、开发模型
1、引例
2、常见开发模型
3.2.1 瀑布模型
3.2.2 螺旋模型
3.2.3 增量模型、迭代模型
3.2.4 敏捷模型
四、测试模型
1、V模型编辑
2、W型
五、BUG
1、软件测试的生命周期
2、bug
5.2.1 定义：
5.2.2 描述：
5.2.3 级别：
5.2.4 争吵：
一、测试认知
书籍推荐：《软件测试的艺术》
1、软件测试开发工程师和测试工程师的区别
相同点：
1.都统称为测试人员
2.对产品质量负责，保障产品的质量
不同点：
测试开发比测试多“开发”二字，而这个开发并不是指业务开发，因为业务开发是开发人员的主要职责，这里的开发指的是需要开发测试效率工具，通过效率工具来提升测试效率和测试质量，比如我们的自动化、性能测试等就属于效率工具，并且测试得贯穿于软件的整个生命周期 。
2、工作流程：
1.熟悉工作和测试流程
2.通过业务测试熟练个人的测试能力
3.掌握各种各样的工具提高测试质量和效率
4.开始逐步学习开发各种效率工具
3、走测试岗位为什么还要学习开发知识?
1)测试人员也需要编写代码，如自动化测试、性能测试、开发测试效率工具等。测试人员需要能够看懂代码、了解开发框架。
2)学好开发知识能够提高软件测试质量。通过查看代码中数据的走向能够更好的从代码层面去发现问题。
4.优秀的软件测试人员具备的素质
沟通能力、快速学习的能力、开发能力、文字能力、结合自己的经验，知识，直觉，进行系统的错误猜测和逻辑推理，整理和分析出更多有针对性的的测试关注点。探索性思维的质量取决于测试人员的经验。
5.为什么走测试岗位而不走开发岗位？
回答思路：从岗位工作性质分析+个人性格/爱好+个人职业规划三个方面阐述。
1）个人兴趣爱好：从性格和兴趣出发，测试工作需要测试人员具备良好的耐心、细心，接
触了测试内容后对测试工作产生浓厚兴趣
2）岗位性质：不管是测试还是测试开发都统称为测试人员，测试⼈员主要以保障项目测试质量为主，通过开发⼀些测试效率工具（比如我们学的自动化就是效能⼯具，除此之外还有我们课件上写的内存泄漏工具等等）来提高测试效率。而软件开发主要以业务编码为主。
3）个人职业规划：大学期间就树立了走测试方向的目标，今后将继续提高测试和开发能
力，争取在测试领域做出⼀番有影响力的事务
6.开发和测试出现冲突怎么办？
(1)反思自己是否是bug描述的不清楚，或者是否由于自己的疏忽导致误判？
(2)站在用户的角度反问开发人员 : 如果你是用户你能接受这样的情况吗?
(3)不仅能提出问题，最好也能给出解决方案。
切记：不要以命令式的语气要求开发人员完全按照自己的思路来解决问题。
二、需求概念
1、用户需求：需经过合理的评估；
2、软件需求
用户的需求不能直接作为开发和测试的依据。针对用户的需求，产品经理需要进行需求分析
（技术可行性、市场可行性、成本投入和收益占比等）后才可转变为软件需求。
三、开发模型
1、引例
软件生命周期实际就是软件的开发模型。
案例：
假如我想要建造⼀套房，房的生命周期（流程）是什么样的？
生命周期：需求分析⸺计划⸺设计⸺编码⸺测试⸺运行维护
产品经理：定需求，明确需求是否正常执行中
项目经理：为整个项目负责，人员调配等工作
交互：设计交互图
前端：设计前端内容(框架、技术、工具)
后端：设计后端内容(框架、技术、工具)
测试：测试用例、测试计划(测试类型、工具等)
2、常见开发模型
3.2.1 瀑布模型
瀑布模型的适用场景：需求固定的小项目
3.2.2 螺旋模型
适用场景：规模庞大、复杂度高、封风险大的项目
在螺旋模型中需要额外招聘专业的风险分析人才，各阶段是否遗留问题完全取决于风险分析人员，这跟风险分析人员的技术能力直接挂钩。
3.2.3 增量模型、迭代模型
增量是逐块建造的概念：一点一点盖房子；
迭代是反复求精的概念：活动板房拼接房子。
适用场景：大型项目，需求不明确迭代模型和增量模型在现在已经不会单独去使用，而是配合着去使用
3.2.4 敏捷模型
四个特点：轻文档，轻流程，重目标，重产出。
Scrum是敏捷模型中的一种，又称为迭代式增量软件开发模型，其中主要有三个角色和五个重要会议。
三角色：
由 product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。
• 其中product owner 负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。
• scrum master 负责召开各种会议，协调项目，为研发团队服务。
• 研发团队则由不同技能的成员组成，通过紧密协同，完成每⼀次迭代的目标，交付产品。
五会议：
•发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出
就是制定出这一期迭代要完成的story列表，sprint backlog。
• 迭代计划会议：项目团队对每⼀个story进行任务分解，分解的标准是完成该story的所有任务，每
个任务都有明确的负责人，并完成工时的初估计。
• 每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么?今天计划做什么?有什么问题。
• 演示会议：迭代结束之后，召开演示会议，相关⼈员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由 po 整理，形成新的 story。
• 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下⼀次迭代继续改进，以达到持续改进的效果。
四、测试模型
测试模型中有两个非常重要且具有标志性的测试模型：V模型 和 W模型
1、V模型
优点：明确的标注了测试过程中存在的不同类型的测试，有效提升测试的质量和效率；
缺点：仅仅把测试作为在编码之后的一个阶段，未在需求阶段就介入测试。缺点同瀑布型。
2、W型
优点：有利于尽早地全面的发现问题；
缺点：
• 需求、设计、编码等活动被视为串行的；
• 测试和开发活动也保持着⼀种线性的前后关系，上⼀阶段完全结束，才可正式开始下⼀个阶段工作。
• 重流程，无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。
五、BUG
1、软件测试的生命周期
实际在工作中，上线要分成多个步骤：沙盒（内部）、小流量（部分用户）、全流量（所有用户）、全线上，测试执行结束后，不能认为项目100%的问题都被发现了，某些问题是不可能被完全发现的。
2、bug
5.2.1 定义：
1. 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
2. 当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。
5.2.2 描述：
描述bug的必要要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果
5.2.3 级别：
通过定义bug的级别，能够明确看出问题的严重程度。⼯作中开发⼈员通常需要按照bug的级别来分配优先级来处理bug，除此之外，通过bug级别也能够体现出开发⼈员的开发质量。
bug级别⼀般分为：崩溃、严重、一般、次要
5.2.4 争吵：
把握：要理性的分析和反馈问题
步骤：
A / 先检查自身，是否bug描述不清楚，反省自己:是不是在测试的时候出现了误操作、bug描述是不是没有写清楚；
B / 站在用户角度考虑并抛出问题，功能正常只是测试的一部分，还需要考虑用户的使用感受
“如果你是用户，你能接受这样的界面/功能/使用吗?
C / BUG定级要有理有据，bug定级描述文档拿出来，然后将bug的表现和bug定级描述文档进行匹配，说服程序猿；
D / 提高自身技术和业务水平，做到不仅能提出问题，最好也能给出解决方案
E / 实在不行：bug评审 （测试代表、开发代表、产品代表）
bug评审主要解决两个问题:
1)决定如何处理bug
2)分析缺陷产生的原因，找出预防的对策
面经：Docs
补充：Docs