概念+bug

模型

迭代模型和增量模型

增量模型是将一个大的需求变成小的功能，然后将每个功能逐个开发几乎完整再上线。

迭代模型会上线一个基础版本，但是基础版本所有的功能都有但是非常简陋，之后再迭代优化上线。

一般都是两个一起用，不具体区分迭代模型和增量模型。

敏捷模型

就是在工作中的时候，产品功能根据产品经理的改变而随时改变。

                                        《敏捷宣言》

个体与交互重于过程和工具            强调高效的沟通

可用的软件重于完备的文档             强调轻文档，文档不应该作为工作验收的标准

客户协作重于合同谈判                    主动及时了解当下的需求

响应变化重于遵循计划                     能够主动迎接变化

总结敏捷模型的特点：轻文档，轻流程，重目标，重产出。

Scrum是敏捷模型重点的一种，又称为迭代式增量软件开发模型。

在scrum模型中，主要是三个角色和五个重要会议

三个角色：

scrum由productowner（产品经理）、scrummaster(项目经理)和team(研发团队)组成。
产品经理：负责收集需求，产出软件需求文档。

项目经理：协调项目，为研发团队服务。

研发团队：很多角色组成：开发人员（前端、后端）、测试、交互、设计。
五大重要会议:

scrum的基本流程：

1. 产品负责人负责整理user story，形成左侧的product   backlog。
2. 发布计划会议    product    owner负责讲解user   story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。
3. 迭代计划会议：项目团队对每一个story进行任务分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计
4. 每日例会：每天scrummaster召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
5. 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
6. 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，以达到持续改进的效果。

 测试模型

优点：明确的标注了测试过程中存在的不同类型的测试

缺点：仅仅把测试作为在编码之后的一个阶段，未在需求阶段就介入测试。缺点同瀑布模型。
 

W模型（双V模型）

缺点：需求、设计、编码等活动被视为串行的；

测试和开发活动也保持着一种线性的前后关系上一阶段完全结束，才可正式开始下一个阶段工作。

重流程，无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。轻文档轻流程

开发V模型并不是单单指编码阶段，而是为产品开发流程而实施的各个阶段
特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的

BUG

软件测试贯穿于人软件的整个生命周期

测试人员不仅要具备开发能力、测试能力，最好具备一定的产品分析能力

测试执行结束后，不能认为项目100%的问题都被发现了。问题是不可能被完全发现

实际在工作中，上线要分成多个步骤：沙盒、小流量、全流量、全线上

沙盒：企业内部的线上环境可以供内部人员进行测试

小流量：部分线上真实的用户可以使用到测试人员要在线上手动测试，还要观察有没有错误日志

全流量：所有的真实用户都可以使用到。

全线上：

bug的概念：

准确的来说：

1.当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误

。2.当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。
描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果。

bug的级别意义在哪里？

评估程序猿的开发能力2)年终奖10w，2w3）乡给bug修复顺序排序

1）评估程序猿的开发能力

2)年终奖10w，2w

3）给bug修复顺序排序

 

2.5！与开发产生争执怎么办（高频考题）

2.5.1先检查自身，是否bug描述不清楚

反省自己：是不是在测试的时候出现了误操作、bug描述是不是没有写清楚

2.5.2站在用户角度考虑并抛出问题

功能正常只是测试的一部分，还需要考虑用户的使用感受如果你是用户，你能接受这样的界面/功能/使用吗？

2.5.3BUG定级要有理有据

bug定级描述文档拿出来，然后将bug的表现和bug定级描述文档进行匹配，说服程序猿

2.5.4提高自身技术和业务水平，做到不仅能提出问题，最好也能给出解决方案

测试小白：更多的是提出问题(bug)

测试大牛：除了提出问题也能够定位到问题，给出解决方案

测试用例

什么是测试用例？

测试用例（TestCase）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

笔试的时候编写测试用例题，需要按照excel表格的方式来答题(会涉及到测试用例的要素）

而面试的时候回答测试用例题，按照思维导图的方式一一道来即可(不会涉及到测试用例的要素)

2.1常规思考+逆向思维+发散性思维 

设计测试用例的万能公式：功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全测试。

功能测试：从产品功能角度出发，验证功能是否是正确的

界面测试：肉眼可以看到的部分都称为界面，界面所有的元素都需要测试

性能测试：通常为一些极端的情况

兼容性测试：不同版本（软件、系统)浏览器的兼容性不同的浏览器

易用性测试：具备简单易上手的属性（引导教程）

安全测试：是否具备危险材质气味接口响应数据也要考虑到用户数据的安全性登录场景也需要将秘密进行加密展示数据存储用户隐私数据是否加密。