目录
前言：
在上一节博客中小编主要和大家一起探讨了什么是测试，软件测试以及开发的区别和软件测试和调试的区别，最后给大家讲解了一下一个测试人员应该具备的素质有哦哪些，这节中小编将带着大家一起深入了解一下测试中的一些基础知识，重点需要大家掌握什么是需求，什么是bug、什么是测试用例、开发模型和测试模型的了解。
1.什么是需求
1.1需求的定义
需求是衡量软件测试结果的依据。
- 用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务，该需求一般比较简略。
- 软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。
大多数公司在进行软件开发的时候会把用户需求转换为软件需求，开发人员和测试人员工作的直接依据就是软件需求。软件需求就是测试工作人员进行测试的基本依据。
那么软件需求是谁来写的呢？
在我们开发一个产品或者是测试一个产品的时候需要拿着软件需求进行测试/开发呢？还是拿着用户需求进行测试/开发呢？其实答案显而易见当然是要拿着软件需求来进行测试/开发了，用户需求就是一句话，二软件需求是一个文档，里面详细的描述了用户需求要如何实现，在日常工作中我们通常是使用软件需求来进行开发测试的。
1.2为什么有软件需求
- 从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。
- 对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计。
1.3测试人眼里的需求
在具体设计测试用例的时候，首先需要搞清楚每个业务需求对应的多个软件功能需求点，然后分析出每个软件功能需求对应的多个测试需求点，然后针对每个测试需求点设计测试用例。
过程如下所示：
业务需求-->软件功能需求点-->测试需求点-->测试用例
举例如下所示：
1.4如何深入了解需求
测试工程师是在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。只有真正了解到原始业务需求之后，才有可能从业务需求的角度去设计，针对性更加明确，从终端用户 的使用场景到端到端的覆盖率较高的测试用例集。
测试人员为了深入了解需求就需要测试人员参加需求评审会议，然后再进行查阅文档，再与其他人员进行反复沟通。
2测试用例
2.1什么是测试用例
测试用例（Test Case）就是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
测试用例主要解决了两大问题：测什么和怎么测。
举例：
例如现在我要测试163邮箱的登录界面。
那么现在我们的测试用例的设计就有如下所示：
- 测试环境：Windows系统+QQ浏览器+本地
- 测试数据：账号和密码
- 操作步骤：输入账号、输入密码、点击同意协议、点击登录。
- 预期结果：登录成功
2.2为什么要有测试用例
测试的过程中可能会遇到一下问题：
- 不知道是否较全面的测试了多有的功能
- 测试的覆盖率无法衡量
- 对新版本的重复测试很难实施
- 存在大量冗余测试影响测试效率
存在测试用例的原因：
- 测试用例提高了工作人员的工作效率/降低了测试人员的工作重复性。
- 测试用例是建立自动化的基础。
- 为了解决上述所描述的问题
3.软件错误（BUG）
3.1什么是bug
当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。当规格说明书没有提到功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。
简单来说就是 预期结果!=实际结果 就是一个BUG。
4.软件的生命周期
软件的生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。如果把软件看成是有生命的事物，那么软件的生命周期可以分成6个阶段，即需求分析、计划、设计、编码、测试、运行维护。
- 需求分析：分析需求是否合理。
- 计划：谁开发、谁测试、开发多久、测试多久....
- 设计：UI方面的设计...
- 编码：写代码。
- 测试：测试人员测试产生测试报告。
- 运行维护：如果上线有问题，此时测试人员需要协助开发定位问题+解决问题。
5.开发模型
5.1瀑布模型
瀑布模型在软件工程中国占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模型。
特点：线性的
优点：每个阶段做什么，产出什么都非常的清晰。
缺点：风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。
适用的项目：小型的项目适用于这种模型。
5.2螺旋模型
一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模型，螺旋模型是渐进式开发模型的代表之一。
如下图所示：
优点：每个阶段都会进行风险分析，避免一些线上问题发生。
缺点：风险分析可能分析错，需要人力财力的投入。
适用项目：适用于比较大的项目。
5.3增量迭代
增量是逐块建造的概念，例如画一幅人物画，我们可以先画人物的头部，再画人的身体，在画手和脚...
迭代是一个反复求精的概念，以上述的画人物来举例，同样是画人但是我们可以先画出这个人的大体轮廓，再勾勒出基本雏形，在细化、着色。
增量开发可以显著的降低项目的风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。增量开发模型，鼓励用户反馈，在每个迭代的过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。
5.4敏捷
对于敏捷开发模型来说他是有一个《敏捷宣言》的，这里我们是通过身体力行和帮助他人来揭示更好的软件开发方式，经由这项工作我们形成了如下价值观：
- 个体与交互重于过程和工具。（讲究个体之间的面对面沟通）
- 可用的软件重于完备的文档。（这里的文档指的是开发文档、需求文档...）
- 客户协作重于合同谈判。
- 响应变换重于遵循计划。
- 在没对比对中，后者并非全无价值，但我们更加看重前者。
由敏捷宣言可以看出敏捷其实是有关软件开发的社会工程，敏捷的优点在于他更多的考虑了如何去激发开发人员的工作热情，敏捷开发有很多种方式，其中scrum是比较流行的一种，下面我们就来具体看一下scrum。
5.4.1scrum
scrum里面的角色有product owner（产品经理）、scrum master（项目经理）和 team（研发团队）组成。
- 其中product owner负责整理user story（用户故事），定义其商业价值，对其进行排序，制定发布计划，对产品负责。
- scrum master负责召开各种会议，协调项目，为研发团队服务。
- 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。
scrum的基本流程如下所示：
- 产品负责人负责整理user story，形成product backlog。
- 发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这期迭代要万成的story列表，Spring backlog。
- 迭代计划会议：项目团队对每个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工作的初估计。
- 每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
- 演示会议：迭代结束之后，召开演示会议，相关人员都首受邀参加，团队负责向大家展示本次迭代取得的成果，期间大家的反馈记录下来，有PO整理，形成新的story。
- 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。
5.5软件测试模型
5.5.1V模型
V模型最早是由Paul Rook提出的，目的是改进软件开发的效率和效果，是瀑布模型的变种。他指出单元和集成测试应检测程序的执行是否满足软件设计的要求，系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标，验收测试确定软件的实现是否满足用户需求或者合同的要求。
具体的解析如下所示：
- 用户需求：PM将用户需求收集形成软件需求。
- 需求分析与系统设计：验证需求是否正确确定编程语言，确定框架。
- 概要设计：解决项目结构如何设计。
- 详细设计：每个接口，设计哪些库表，设计哪些任务。
- 编码：写代码。
- 单元测试：Java中测试每一个方法，类。C语言中就是测试函数。
- 集成测试：将许多方法集成一起测试。
- 系统测试：模块和模块之间没有影响。
- 验收测试：验收的人，产品，运营。
特点：左边是开发，右边是测试，类似于瀑布模型。
优点：测试被划分成许多类型。
缺点：测试人员介入的太晚，发现问题时机太晚。
5.5.2W模型
W模型增加了软件各种开发阶段中应同步进行的验证和确认活动，W模型是由两个V模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行的关系。
特点：开发一个V测试一个V。
优点：测试人员尽早介入了需求。
缺点：测试人员和开发人员一定程度上还是串行的，不能拥抱变化，不能适应与敏捷开发模型。
结束语：
好了这节小编与给大家分享到这里啦，这节中小编主要给大家分享了什么是需求，什么是测试用例，BUG的简述，软件的生命周期的阐述以及五大开发模型的简单讲解。后期中小编还会继续细细给大家讲解的，大家记得点赞+收藏哦！大家继续跟紧小编的步伐，一起往前冲！！！希望这节对大家认识测试有一定的帮助，想要学习的同学记得关注小编和小编一起学习吧！如果文章中有任何错误也欢迎各位大佬及时为小编指点迷津（在此小编先谢过各位大佬啦！）
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
