软件测试工程师从入门到进阶一（概念篇）

软件测试岗位中的相关概念

软件测试就是为了验证产品特性是否满足用户的需求，特点：只是一个样本试验，具有不可穷尽性。与开发相比较，开发广度小，专业度高。测试广度大，专业度低。软件测试岗位又分为软件测试工程师，测试开发工程师，性能测试工程师，安全测试工程师和其他（系统测试工程师，嵌入式测试工程师，硬件测试工程师等）。在开发岗位如此卷的今天，大家可以学一下测试多一条出路多一分机会呀😁😁👍。

1. 一个优秀的测试人员应该具备的素质。

软件测试人员需要具备哪些能力呢？

1.综合能力

• 沟通能力：测试工程师的沟通能力会直接影响事务开展的效率。良好清晰的沟通能力，是一个技术优秀的测是工程师是否可以获得更好发展的“敲门砖”。
• 快速学习的能力：对不同业务需求和功能的快速学习与理解能力。 对于测试新技术和新方法的学习能力。
• 开发能力
• 文字能力

2.掌握自动化测试技术

掌握自动化测试技术，可以把你从大量重复性的手工劳动中解放出来，这样可以把更多的精力花在更多类型的测试上。

3.优秀的测试用例设计能力

测试用例设计能力是指，无论对于什么类型的测试，都能够设计出高效地发现缺陷，保证产品质量的优秀测试用例。

如何提高测试用例设计的能力？ 1 ，掌握设计测试用例的方法 2 ，积累，总结 3 ，阅读好的测试用例设计案例

4.具备探索性思维

测试工程师在执行测试的过程中不断学习被测系统，结合自己的经验，知识，直觉，进行系统的错误猜测和逻辑推理，整理和分析出更多有针对性的的测试关注点。

2. 什么是需求？

需求即满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。

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

软件需求： 或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。

大多数公司在进行软件开发的时候会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据就是软件需求。

需求是测试人员开展软件测试工作的依据。

过程如下，业务需求 —> 软件功能需求点 —> 测试需求点 —> 测试用例

• 从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率
• 对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计

3. 什么是bug（软件错误）？

当程序没有实现其最终用户合理预期的 功能要求时，就是软件错误。

4. 什么是测试用例？

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

测试用例解决了两大问题：测什么，怎么测。

实例如下：

5. 开发模型和测试模型

软件的生命周期可以分成6个阶段，即需求分析、计划、、设计、编码、测试、运行维护。

开发和测试模型当我们进入工作时便可以感受到他们的存在。

其中开发模型有瀑布模型，螺旋模型，增量模型，迭代模型，敏捷模型scrum等

测试模型有V模型和W模型等

下面我们来分别对每个模型的概念和优缺点进行重点介绍：

瀑布模型

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

优点： – 强调开发的阶段性； – 强调早期计划及需求调查； – 强调产品测试。 缺点： – 依赖于早期进行的唯一一次需求调查，不能适应需求的变化； – 由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程； – 风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。

适用场景：需求固定，规模小的项目

螺旋模型

这种模型对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。

优点： – 强调严格的全过程风险管理。 – 强调各开发阶段的质量。 – 提供机会检讨项目是否有价值继续下去。 缺点： – 引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投

适用场景：需求复杂，规模大，风险大的项目

增量模型

迭代模型

增量模型将一个大的需求修改成多个小功能，每个功能独立开发上线 迭代模型会上线一个基础版本，但基础版本所有的功能都有只不过功能比较简陋，后期再继续迭代优化上线

适用场景：大型项目，需求不明确

敏捷模型

敏捷模型是当今最主流的一种开发模型，旨在为了解决项目开发期间处理来自客户的变更请求以及合并这些变更所需的高成本和时间。

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

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

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

三个角色：

scrum 由 product owner( 产品经理 ) 、 scrum master( 项目经理 ) 和 team( 研发团队 ) 组成。

• 其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。
• scrum master 负责召开各种会议，协调项目，为研发团队服务。
• 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

迭代开发：

与瀑布不同， scrum 将产品的开发分解为若干个小 sprint( 迭代 ) ，其周期从 1 周到 4 周不等，但不会超过 4周。参与的团队成员一般是5 到 9 人。每期迭代要完成的 user story 是固定的。每次迭代会产生一定的交付。

五个重要会议：

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

V模型

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

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

W模型

特点：测试的对象不仅是程序，需求，设计等同样要测试，测试和开发是同步进行的。

缺点：

• 需求，设计，编码等活动被视为串行的。
• 测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一阶段工作。
• 重流程，无法支持敏捷开发模式（轻文档轻流程）。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑