测试（一）

1.用户需求

可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。

2.软件需求

或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能(所谓的测试文档)。
大多数公司在进行软件开发的时候会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据就是软件需求。

3.测试用例

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
测试用例解决了两大问题：测什么，怎么测。

4.软件错误(BUG)

当且仅当规格说明(软件需求、规格说明书)是存在的并且正确，程序与规格说明之间的不匹配才是错误。
当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

5.软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。 如果把软件看成是有生命的事物，那么软件的生命周期可以分成6个阶段，即需求分析、计划、、设计、编码、测试、运行维护。
需求分析：分析需求是否合理、需求是否完整

6.开发模型

6.1瀑布模型（Waterfall Model）

特点：线性的
优点：每个阶段做什么、产出什么非常清晰
缺点：风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。
适用的项目：小型的项目适用于这种模型

6.2螺旋模型（Spiral Model）

优点：每个阶段都会进行风险分析，避免一些线上问题发生
缺点：风险分析可能分析错误，需要人力财力的投入
适用项目：适用于项目比较大、风险比较多的项目

6.3增量、迭代

只需要会区分哪些是增量哪些是迭代就可，例如：
增量是逐块建造的概念，例如画一幅人物画，我
们可以先画人的头部，再画身体，再画手脚……
而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。

6.4敏捷

敏捷思想：

敏捷开发有很多种方式，其中scrum是比较流行的一种。

6.4.1scrum

迭代开发：
与瀑布不同，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。
• 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

6.5测试模型

6.5.1软件测试v模型

特点：左半边是开发，右边是测试；类似于瀑布模型
优点：测试被划分为许多类型
缺点：测试人员介入太晚，问题发现太晚

6.5.1软件测试w模型(双v模型)

特点：开发一个v，测试一个v
优点：测试人员能够尽早的介入需求
缺点：测试人员和开发人员一定程度上还是串行的 ，不能拥抱变化、不适用于敏捷