【测试开发】第一节.测开入门（附常考面试题）网站首页 其他

目的不同

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

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

角色不同

软件调试：开发人员来做

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

阶段不同

软件调试：开发阶段

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

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

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

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

综合能力：

1）沟通能力

2）快速学习能力

3）开发能力

4）文字能力

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

掌握自动化测试技术

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

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

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

二、软件测试的基础概念

2.1 需求

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

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

2.2 测试用例

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

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

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

举例说明：

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

3、BUG

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

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

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

三、生命周期

3.1 软件的生命周期

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

分部解析说明：

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

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

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

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

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

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

3.2 软件测试的生命周期

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

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

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

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

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

4.1 瀑布模型

执行步骤：

特点：

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

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

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

4.2 螺旋模型

螺旋模型：在瀑布模型的基础上进行风险分析

在每个阶段都有风险分析这一步——》耗时耗力（成本好，团队需要风险分析方面的人才）

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

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

使用场景：大项目

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

4.3 增量模型和迭代模型

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

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

4.4 敏捷模型

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

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

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

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

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

scrum中三个重要的角色：

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

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

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

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

5.1 V模型

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

缺点：测试后置

5.2 W模型

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

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

特点：

开发一个V，软件测试一个V【双卡双待】
换个说法：软件开发和软件测试是同步进行的。

这样做，就解决了 V 模型的缺陷：W模型能够及时发现，并处理前期出现的问题。

缺点：

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