关于测试的概念
什么是需求？
需求分为用户需求和软件需求。
软件需求可以作为开发和测试工作的依据，而用户需求不一定是合理的，这里的不合理有很多的角度：技术角度上，市场需求上，投入成本和收益比噔噔。
关于开发模型
首先软件开发生命周期大致分为以下：
需求分析-计划-设计-编码-测试-运行维护
常见开发模型
瀑布模型：
如上图可以看到，整个开发流程都是串行化的，也就是线性的开发流程。
优缺点：
优点：
1.强调开发的周期性
2.因为是线性结构，所以每个阶段只执行一次。
3.是其它模型的基础框架。
缺点：
1.测试后置：
a.
前⾯各阶段遗留的⻛险推迟到测试阶段才被发现，导致项⽬⼤⾯积
返⼯，失去了及早修复的机会
b.
必须留有⾜够的时间给测试活动，否则导致测试不充分，将缺陷直
接暴露给⽤⼾（产品质量差）
2.周期太⻓，产品很迟才能被看到和使⽤，可能会导致需求/功能过时。
瀑布模型的适用场景：需求固定，规模小的项目。
螺旋模型
⼀般在软件开发初期阶段需求不是很明确时，采⽤渐进式的开发模式。螺旋模型是渐进式开发模型的代表之⼀。
优缺点：
优点/特点：
强调各开发阶段的质量。
引入了原型和风险分析。
缺点：
需要耗费额外的时间和人力成本。
并且是否遗留风险跟风险分析人才的技能水平直接挂钩。
适用场景：需求复杂，规模大，风险高 的项目
增量模型
其实就是将一个大的需求分割成多个小的需求，每个功能独立开发上线。
迭代模型
迭代模型会先上线一个基础版本，但是基础版本的所有功能会比较简陋，后期再迭代优化上线。
关于增量模型和迭代模型，一般的企业很少会独立使用某一个模型，而是两个模型一起使用。
一起使用这两个模型的场景：大型，需求不明确的项目。
敏捷模型（重要）
在早期，迭代瀑布模型⾮常流⾏来完成⼀个项⽬。但是现在开发⼈员在使⽤它开发软件时⾯临着各种各样的问题。主要困难包括在项⽬开发期间处理来⾃客⼾的变更请求以及合并这些变更所需的⾼成本和时间。为了克服瀑布模型的这些缺点，在1990年代中期提出了敏捷软件开发模型。
在敏捷模型中有一个重要的宣言， 《敏捷宣言》：
个体与交互重于过程和⼯具 （强调高效的沟通）
可⽤的软件重于完备的⽂档 （强调轻文档，文档不应该作为工作验收的标准）
客⼾协作重于合同谈判 （及时了解当下需求的变化）
响应变化重于遵循计划 （能够主动迎接变化）
通过敏捷宣⾔可以总结出敏捷模型的四个特点：轻⽂档，轻流程，重⽬标，重产出。敏捷开发有很多种⽅式，其中scrum是⽐较流⾏的⼀种。
Scrum是敏捷模型中的⼀种，⼜称为迭代式增量软件开发模型。
在scrum模型中，主要有三个⻆⾊和五个重要会议。
三个⻆⾊：
scrum由product owner(产品经理)、scrum master(项⽬经理)和team(研发团队)组成。
•
其中product owner负责整理user story(⽤⼾故事)，定义其商业价值，对其进⾏排序，制定发布
计划，对产品负责。
•
scrum master负责召开各种会议，协调项⽬，为研发团队服务。
•
研发团队则由不同技能的成员组成，通过紧密协同，完成每⼀次迭代的⽬标，交付产品。
迭代开发
与瀑布不同，scrum将产品的开发分解为若⼲个⼩sprint(迭代)，其周期从1周到4周不等，但不会超过4周。参与的团队成员⼀般是5到9⼈。每期迭代要完成的user story是固定的。每次迭代会产⽣⼀定的交付。
scrum的基本流程如上图所⽰：
•
产品负责⼈负责整理user story，形成左侧的product backlog。
•
发布计划会议：product owner负责讲解user story，对其进⾏估算和排序，发布计划会议的产出
就是制定出这⼀期迭代要完成的story列表，sprint backlog。
•
迭代计划会议：项⽬团队对每⼀个story进⾏任务分解，分解的标准是完成该story的所有任务，每
个任务都有明确的负责⼈，并完成⼯时的初估计。
•
每⽇例会：每天scrum master召集站⽴会议，团队成员回答昨天做了什么今天计划做什么，有什么
问题。
•
演⽰会议：迭代结束之后，召开演⽰会议，相关⼈员都受邀参加，团队负责向⼤家展⽰本次迭代取
得的成果。期间⼤家的反馈记录下来，由po整理，形成新的story。
•
回顾会议：项⽬团队对本期迭代进⾏总结，发现不⾜，制定改进计划，下⼀次迭代继续改进，以达
到持续改进的效果。
在这个基本流程中就包含了五个会议。
测试模型
V模型：
V模型是瀑布模型的变种。
优点：
明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间
各阶段的对应关系，有效提升测试的质量和效率。
缺点：
仅仅把测试作为在编码之后的⼀个阶段，未在需求阶段就介⼊测试。缺点同瀑布模型。
W模型：
W模型由两个V字型模型组成，分别代
表测试与开发过程，图中明确表⽰出了测试与开发的并⾏关系。
特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进⾏的
优点：有利于尽早地全⾯的发现问题。
缺点：
需求、设计、编码等活动被视为串⾏的；
•
测试和开发活动也保持着⼀种线性的前后关系，上⼀阶段完全结束，才可正式开始下⼀个阶段⼯
作。
•
重流程，⽆法⽀持敏捷开发模式（敏捷模型要轻文档轻流程）。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理⾯临着困惑
Bug的概念
软件测试的生命周期
之前也说过，软件测试是贯穿整个软件的整个生命周期的。
软件测试的⽣命周期是指测试流程，这个流程是按照⼀定顺序执⾏的⼀系列特定的步骤，去保证产品质量符合需求。在软件测试⽣命周期流程中，每个活动都按照计划的系统的执⾏。每个阶段有不同的⽬标和交付产物
实际工作中，上线要分为多个步骤：沙盒，小流量，全流量，全线上。
比如沙盒就是指：企业内部的线上环境。
小流量就是指：先让线上部分真实的用户可以使用到。
Bug
Bug 的概念
定义： ⼀个计算机bug指在计算机程序中存在的⼀个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障 (fault)，这些bug使程序⽆法正确的运⾏。Bug产⽣于程序的源代码或者程序设计阶段的疏忽或者错误。
准确来说：
1. 当且仅当规格说明（需求文档）是存在的并且正确，程序与规格说明之间的不匹配才是错误。
2. 当需求规格说明书没有提到的功能，判断标准以最终⽤⼾为准：当程序没有实现其最终⽤⼾合理
预期的功能要求时，就是软件错误。
描述bug的要素
描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果
比如问题出现的版本
还有问题出现的环境：Windows / Linux等。
问题出现的步骤可以让开发人员较好的去复现这个bug。
bug级别
给bug定级别的意义是什么？
通过定义bug的级别，能够明确看出问题的严重程度。⼯作中开发⼈员通常需要按照bug的级别来分配优先级来处理bug，除此之外，通过bug级别也能够体现出开发⼈员的开发质量。
bug级别⼀般分为：崩溃、严重、⼀般、次要。
bug的生命周期
测试⼈员在执⾏测试的过程中如有发现bug，需要在对应的bug管理平台来创建bug（bug⽣命起
源），创建好的bug需要被开发⼈员修复，以及测试⼈员的持续跟踪和测试。
与开发产生争论怎么办？（*）
1.先检查自身 ，看bug是否描述不清楚。
2.站在用户的角度抛出问题。
3.BUG的定级要有理有据。
4.提升自身技术和业务水平，做到不仅能提出问题，还能给出解决方案。
5.bug评审：
bug评审主要解决两个问题：
1）决定如何处理bug
2）分析缺陷产⽣的原因，找出预防的对策
bug评审⾄少需要项⽬组各个⽅⾯的代表参加：
1）测试代表
测试代表主要从Bug的具体表现、严重程度等⽅⾯提供信息，并提出⾃⼰对Bug的处理意⻅。需要
注意的是，测试⼈员不应该⼀味地要求对Bug进⾏修改，因为修改可能带来回归的⻛险，同时带来
的是回归测试的⼯作量，如果时间⽐较紧迫，修改后剩余的时间若不⾜以做⼀次有效的回归测试，
可能不修改是个明智的选择。
2）开发代表
开发代表主要从修改缺陷的难度和⻛险出发，考虑缺陷修改需要付出的代价，以及可能影响的范
围、可能引发的⻛险等，如果决定要修改，还要讨论出修改的初步⽅案。
3）产品代表
产品代表主要从产品的整体计划、⽤⼾的要求等⽅⾯对缺陷的修改必要性、缺陷修改的时间和版本提出⾃⼰的意⻅
