测开入门（附常考面试题）

最新推荐文章于 2024-07-30 11:16:16 发布

是小鱼儿哈

最新推荐文章于 2024-07-30 11:16:16 发布

阅读量664

点赞数 3

分类专栏：测试开发文章标签：开发语言测试

本文链接：https://blog.csdn.net/weixin_61061381/article/details/127799326

版权

测试开发专栏收录该内容

8 篇文章 13 订阅

订阅专栏

一、什么是软件测试？

验证软件产品特性（功能、界面、安全性、兼容性、性能）是否符合用户需求

软件测试是贯穿于软件的整个生命周期的

软件测试不仅要测试软件系统是否做了其该做的，还要测试系统是否未做其该做的

面试题：

软件测试和软件开发的区别？

软件测试：主要是保障产品质量

软件开发：主要是编写业务代码

软件测试和软件测试开发的区别？

首先软件测试和软件测试开发的主要工作内容都是保障产品质量，不同的是软件测试开发还额外需要开发一些测试效能工具——来提升测试效率

软件测试和开发测试（软件调试）的区别？

目的不同

软件调试：开发人员验证软件是否实现了他想让软件实现的功能

软件测试：测试人员验证软件是否实现了用户的需求

角色不同

软件调试：开发人员来做

软件测试：开发人员和测试人员，一起来做这件事！（在软件测试中，开发人员主要是做白盒测试的——与代码相关的）

阶段不同

软件调试：开发阶段

软件测试：贯穿于软件的整个生命周期

你为什么要选择软件测试开发的工作？

回答自己的核心竞争力体现在哪里——自己的优势

自己有着优秀的测试人员需要具备的素质

综合能力：

1）沟通能力

2）快速学习能力

3）开发能力

4）文字能力

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

掌握自动化测试技术

探索性思维、兴趣、有责任感

我看你的简历上有较多的开发技能？你为啥要选择测试工作呢？你的优势在哪里？

有开发技能可以帮助我们更好的编写测试用例（不要抨击别人、抨击学校，这时面试的大忌）

二、软件测试的基础概念

1、需求

用户需求是五花八门的，描述是简略的。并且用户需求不一定是正确的、合理的，需要进一步的对用户需求进行提取和分析，所以用户需求不可以作为测试/开发工作的依据！！

软件需求才是进行测试/开发工作的的基本依据（产品经理写的软件需求文档）

2、测试用例

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

测试人员在执行测试之前需要编写测试用例，测试用例的好坏与产品测试质量有很大的关联关系。

我们在测试的时候，光凭头脑风暴来进行随机的测试肯定是不行的，所以我们就需要根据提前编写好的测试用例来进行更完善的测试

大家乍一看，可能就会觉得，这个测试用例很正常。
唯一缺点：就是不够详细。
是的，没有错！
测试用例，就如同上图给标题一样“正确的用户名密码可以成功登录邮箱”，它是一个非常模糊和片面的说法。
而我们通过将其划分成 4 个部分，来将这个测试用例进行初步的划分，
而且，划分出的这几个部分，其实也是可以进行细分的！
划分成一个个测试点
————————————————

3、BUG

BUG也叫做软件缺陷和软件错误

准确的说：当且仅当规格说明（软件需求文档）是存在并且是正确的时候，程序与规格说明之间的不匹配才是错误BUG。

这个BUG可以来自前端、也可以是后端，甚至是来自产品经理写的需求文档。

三、生命周期

🍑软件的生命周期

需求分析--》计划--》设计--》编码--》测试--》运营维护

需求分析：进行市场分析，这个需求量大不大？投入与盈利的占比？技术上能否实现或者说实现的难度？

计划：什么时候开始？什么时候结束？过程耗时多少？

设计：将需求细化为一个一个的任务，进行计算设计（要用到哪些接口？采用什么框架？

编码：开发人员参考需求文档和技术文档进行功能代码的编写

测试：测试人员要参考测试用例来执行测试（注意测试用例是在测试前就编好的，要明白我们的测试是贯穿软件的整个生命周期的）

运行维护：修复性的维护（对项目中未发现的问题进行修复）完善性维护（对功能进行完善）预防性维护（居安思危，为了避免产品在线上出现一些意想不到的问题，进行一些预防的手段）

🍑软件测试的生命周期

软件测试是贯穿于软件整个生命周期的。

需求分析——》测试计划——》测试设计与开发——》执行测试——》测试评估

测试计划：测试人员也需要编写测试计划文档——有多少测试人员，什么时候开始测试？

测试设计与开发：测试人员需求借助需求文档和技术文档来编写测试用例。

四、软件工程中的几种常见的开发模型

🏀瀑布模型

需求分析——》计划——》设计——》编码——》测试——》运行维护

特点：

不太重视测试，软件开发完成前不会进行测试（更看重前面的需求分析、计划、设计）
线性结构、一个阶段完成后才会进行下一步、效率不高
项目中的问题不能尽早的发现，很可能会错失解决问题的最佳时机。
需要保留足够的时间给测试、测试后置（瀑布模型的缺陷）
测试时间不够——》测试不充分——》暴露风险给用户
一个周期把所有的功能给完成——》一个可以运行的产品很晚才会给用户呈现

使用场景：因为不能够很好的迎接变化，使用与需求固定的小型项目

后面的模型都是在瀑布模型上进行了优化

🏀螺旋模型

螺旋模型：在瀑布模型的基础上进行风险分析
在每个阶段都有风险分析这一步——》耗时耗力（成本好，团队需要风险分析方面的人才）

优点：
1、强调严格的全过程风险管理。
2、强调各开发阶段的质量。
3、提供机会检讨项目是否有价值继续下去。

缺点：
1、引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高
的要求。这需要人员、资金和时间的投入。

使用场景：大项目

瀑布模型和螺旋模型对变化的项目不太友好，不容易都项目进行及时更改

🏀增量模型和迭代模型

增量模型：
将项目进行模块化，使其每个模块都能进行独立的编码测试和上线
优势：产品能够加载较短时间内尽快的交付给用户去使用

迭代模型:
一期一期的进行迭代
假如一个产品包含五个功能A、B、C、D、E
增量模型要一个一个的开发这五个不同的模块，但迭代模型会先完成这5个功能的基础版本，会再经历一期一期的迭代优化（在迭代的过程还可接收用户的使用建议）使其功能越来越优秀。

🏀敏捷模型

敏捷模型——2001年，以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人为首的“轻量”过程派聚集在犹他州的Snowbird，决定把“敏捷”(Agile)作为新的过程家族的名称。
在会议上，他们提出了《敏捷宣言》http://agilemanifesto.org/：我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工怍，我们形成了如下价值观

1、个体与交互重于过程和工具
强调团队内部人员进可能的进行高效的沟通
2、可用的软件重于完备的文档
敏捷模型最终的标准就是：可交付的软件
3、客户协作重于合同谈判
4、响应变化重于遵循计划

（在每对对比中，后者并非全无价值，但我们更看重前者）

敏捷宣言的特点：轻流程、轻文档、重目标、重产出

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

scrum中三个重要的角色

产品经理（收集用户需求，转变软件需求：开发时就是依赖软件需求来开发的，对产品负责）
项目经理（推进项目的推进，为研发团队服务）
研发团队：不同技能的成员组成

敏捷模型是一版一版进行迭代的
每个迭代模型为1---4周

每日会议结束后的产物：可交付的软件
演示会议的产物：用户新的需求——》放到需求池中，下一次产品迭代再实现。

五、软件工程中的测试模型

V模型

特点：明确了测试有不同的类型，并且每个类型和前期的开发工作之间有相对应的关系。
缺点测试后置

W模型

W 模型，也称作双V模型。

看图说话：就是两个 V 模型组成的。

特点：

开发一个V，软件测试一个V【双卡双待】
换个说法：软件开发和软件测试是同步进行的。
这样做，就解决了 V 模型的缺陷：W模型能够及时发现，并处理前期出现的问题。

缺点：

它仍然是串行执行的过程，它是不支持需求的变化。
也就是说：W模型是不支持敏捷开发的。