软件测试定义
- 软件测试就是验证软件产品特性是否满⾜用户的需求。
软件测试开发⼯程师和测试⼯程师的区别
- 相同点：
- 都统称为测试⼈员
- 对产品质量负责，保障产品的质量
- 不同点：测试开发⽐测试多开发⼆字，⽽这个开发并不是指业务开发，因为业务开发是开发⼈员的主要职责，这⾥的开发指的是需要开发测试效率⼯具，通过效率⼯具来提升测试效率和测试质量，⽐如我们的⾃动化、性能测试等就属于效率⼯具。
软件的⽣命周期
- 软件生命周期包括：需求分析、计划、设计、编码、测试、运行维护。
| 阶段 | 具体内容 | 产出 |
|---|---|---|
| 需求分析 | 分析用户需求是否合理，分别从市场需求、技术等⽅⾯进⾏分析。 | 该阶段会输出需求等⽂档。 |
| 计划 | 对成⽴的需求执⾏需求执⾏计划，多⻓时间内完成该需求，每段时间具体完成哪些功能。 | 该阶段会输出计划等⽂档。 |
| 设计 | 将需求细化成⼀个个任务，团队成员各司其职领取任务并进⾏技术设计（如何进⾏架构设计，设计哪些接⼝、采⽤什么技术） | 该阶段会输出技术等⽂档。 |
| 编码 | 开发⼈员参考需求⽂档、设计⽂档、交互图等等⽂件进⾏代码的编写。 | 代码⽂件等⽂档。 |
| 测试 | 测试⼈员需要介⼊到软件的测试中来，参考测试⽤例对软件进⾏测试。 | 测试⽤例、测试设计与计划、测试报告等⽂档 |
| 运⾏维护 | 项⽬测试结束之后，项⽬需要进⾏上线，并对产品进⾏线上的维护。线上的维护主要分为三个⽅⾯。分别为修复性维护、完善性维护和预防性维护。修复性维护：对项⽬中未发现的问题进⾏修复。完善性维护：对功能进⾏完善。预防性维护：居安思危，为了避免产品在线上出现⼀些其他不可预料的问题，进⾏⼀些防护的⼿段。 | 无 |
常见的开发模型
- 瀑布模型:
- start-->需求分析-->计划-->设计-->编码-->测试-->end
- 瀑布模型在软件⼯程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每⼀个阶段都只执行⼀次，因此是线性顺序进⾏的软件开发模式。
- 瀑布模型优缺点总结：
| 优点 | 缺点 |
|---|---|
| 强调开发的阶段性；线性结构，每个阶段只执⾏⼀次;是其他模型的基础框架 | 1.测试后置:前⾯各阶段遗留的⻛险推迟到测试阶段才被发现，导致项⽬⼤⾯积返⼯，失去了及早修复的机会；必须留有⾜够的时间给测试活动，否则导致测试不充分，将缺陷直接暴露给用户（产品质量差）2. 周期太⻓，产品很迟才能被看到和使⽤，可能会导致需求/功能过时 |
- 瀑布模型的适⽤场景：需求固定的⼩项⽬
- 螺旋模型
- ⼀般在软件开发初期阶段需求不是很明确时，采⽤渐进式的开发模式。螺旋模型是渐进式开发模型的代表之⼀。
- 这对于那些规模庞⼤、复杂度⾼、⻛险⼤的项⽬尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有⼀段独⽴的测试时间和阶段，测试必须跟随开发的迭代⽽迭代。因此，回归测试的重要性就不⾔⽽喻了。
| 优点 | 缺点 |
|---|---|
| 强调严格的全过程⻛险管理。 强调各开发阶段的质量。增加⻛险分析和原型 | 项⽬中可能存在的⻛险性与⻛险管理⼈员的技能⽔平有直接关系；需求⼈员、资⾦、时间的增加和投⼊，可能会导致项⽬的成本太⾼ |
- 适⽤场景：规模庞⼤、复杂度⾼、⻛险⼤的项⽬。
- 增量模型、迭代模型
- 增量开发能显著降低项⽬⻛险，结合软件持续构建机制，构成了当今流⾏的软件⼯程最佳实践之⼀。增量开发模型，⿎励⽤⼾反馈，在每个迭代过程中，促使开发⼩组以⼀种循环的、可预测的⽅式驱动产品的开发。因此，在这种开发模式下，每⼀次的迭代都意味着可能有需求的更改、构建出新的可执⾏软件版本，意味着测试需要频繁进⾏，测试⼈员需要与开发⼈员更加紧密地协作。
- 与此类似的有⼀个迭代开发，增量开发和迭代开发往往容易被⼈，但是其实两者是有区别的。增量是逐块建造的概念，迭代是反复求精的概念。
- 适⽤场景：⼤型项⽬，需求不明确
- 敏捷模型
- 敏捷模型主要旨在帮助项⽬快速适应变更请求。因此，敏捷模型的主要⽬的是促进项⽬的快速完成。要完成这项任务，需要敏捷。敏捷性是通过使过程适应项⽬，删除对特定项⽬可能不是必需的活动来实现的。此外，避免任何浪费时间和精⼒的事情。
- 在敏捷模型中，需求被分解成许多可以增量开发的⼩部分。敏捷模型采⽤迭代开发。每个增量部分都是在迭代中开发的。每次迭代都旨在⼩⽽易于管理，并且只能在⼏周内完成。⼀次为客户计划、开发和部署⼀个迭代。没有制定⻓期计划。
- 敏捷开发有很多种⽅式，其中scrum是⽐较流⾏的⼀种。在scrum模型中，主要有三个⻆⾊和五个重要会议。
- 三个⻆⾊：scrum由product owner(产品经理)、scrum master(项⽬经理)和team(研发团队)组成。
- 其中product owner负责整理user story(⽤⼾故事)，定义其商业价值，对其进⾏排序，制定发布计划，对产品负责。
- scrum master负责召开各种会议，协调项⽬，为研发团队服务。
- 研发团队则由不同技能的成员组成，通过紧密协同，完成每⼀次迭代的⽬标，交付产品。
- 五个会议：
- 迭代计划会议
- 每日站会
- 迭代评审会议
- 迭代回顾会议
- 需求细化会议
测试模型
- 测试模型中有两个⾮常重要且具有标志性的测试模型：V模型和W模型
- 优点：
- 明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系，有效提升测试的质量和效率。
- V模型指出：
-
单元和集成测试应检测程序的执⾏是否满⾜软件设计的要求；
-
系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；
-
验收测试确定软件的实现是否满⾜⽤⼾需要或合同的要求
缺点：仅仅把测试作为在编码之后的⼀个阶段，未在需求阶段就介⼊测试。缺点同瀑布模型。 -
W模型增加了软件各开发阶段中应同步进⾏的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表⽰出了测试与开发的并⾏关系。
-
特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进⾏的
-
优点：
- 有利于尽早地全⾯的发现问题。例如，需求分析完成后，测试⼈员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项⽬难度和测试⻛险，及早制定应对措施，显著减少总体测试时间，加快项⽬进度。
-
缺点：
- 需求、设计、编码等活动被视为串⾏的；
- 测试和开发活动也保持着⼀种线性的前后关系，上⼀阶段完全结束，才可正式开始下⼀个阶段⼯作。
- 重流程，⽆法⽀持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理⾯临着困惑。
软件测试的⽣命周期
- 软件测试的⽣命周期是指测试流程，这个流程是按照⼀定顺序执⾏的⼀系列特定的步骤，去保证产品质量符合需求。在软件测试⽣命周期流程中，每个活动都按照计划的系统的执⾏。每个阶段有不同的⽬标和交付产物
- 具体包括：需求分析、测试计划、测试设计以及测试开发、测试执行、测试评估、上线、运行维护。
- 总之软件测试贯穿于软件的整个生命周期。
BUG
- bug的定义：⼀个计算机bug指在计算机程序中存在的⼀个错误(error)、缺陷(flaw)、疏忽(mistake)或者故障(fault)，这些bug使程序⽆法正确的运⾏。Bug产⽣于程序的源代码或者程序设计阶段的疏忽或者错误。
- 描述bug的要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果。
- bug级别：⼀般分为崩溃、严重、⼀般、次要。
- bug的⽣命周期：
- 测试⼈员在执⾏测试的过程中如有发现bug，需要在对应的bug管理平台来创建bug（bug⽣命起源），创建好的bug需要被开发⼈员修复，以及测试⼈员的持续跟踪和测试。
- New:新发现的bug,未经评审决定是否指派给开发人员进行修改
- Open:确认是bug,并且认为需要修改，指派给相应的开发人员
- Fixed:开发人员进行修改后标识为修改状态，待测试人员进行验证
- Rejected:如果认为不是bug,则拒绝修改
- Delay:如果认为暂时不需要修改或者暂时不能修改，则延后修改
- Closed:修改状态的bug经过测试人员的回归测试验证并通过，则关闭bug
- Reopen:如果经过验证bug依然存在，则需要重新打开bug,开发人员重新修改
- ⽆效的bug：open->closed open-rejected-closed