面试测试开发工程师：Java测试基础篇

目录

1. 什么是软件测试？

2. 测试与调试的区别

3. 软件测试的目的和原则

4. 什么是需求

5. 什么是bug 

5.1 如何描述一个bug

5.2 如何定义bug的级别

5.3 bug的生命周期

6. 什么是测试用例

7. 开发模型和测试模型

7.1 软件的生命周期

7.2 瀑布模型

7.3 螺旋模型

7.4 增量、迭代

7.5 敏捷

7.5.1 scrum

7.5.2 敏捷中的测试

8. 软件测试v模型

9. 软件测试W模型

10. 配置管理和软件测试

10.1 什么是配置管理

10.2 软件配置管理的应用

10.3 实施软件配置管理的好处

10.4 配置管理与软件测试

---

1. 什么是软件测试？

软件测试就是证明软件不存在错误的过程

软件测试就是为了证明程序能够正确运行

2. 测试与调试的区别

（1）目的不同：① 测试的任务是发现程序中的缺陷

                           ② 调试的任务是定位并且解决程序中的问题

（2）参与角色不同：① 测试主要是由测试人员和开发人员来执行，黑盒测试主要由测试人员完                                           成、单元/集成测试主要是由开发人员执行

                                  ② 调试由开发人员完成

（3）执行的阶段不同：① 测试贯穿整个软件开发生命周期

                                      ② 调试一般在开发阶段

3. 软件测试的目的和原则

目的：验证软件有或没有问题

原则：以客户为中心，遵循软件测试的规范、流程、标准和要求

1. 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案

2. 成功的测试是发现了至今为止尚未发现的错误的测试

3. 测试并不仅仅是为了找出错误。通过分析错误产生的原因、阶段及错误发生的趋势                          ① 帮助项目管理者了 解当前软件开发过程中的缺陷，以便及时纠错、改进                                      ② 帮助测试人员设计出有针对性的测试方法，改善 测试的效率和有效性                                          ③ 让开发人员知道错误产生的重灾区，加强自测试                                                                            ④ 让客户清楚我们专业的质 量保证团队，可以向他们提交一份满意的答卷

4. 没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法

5. 根据测试目的的不同，还有回归测试、压力测试、性能测试、安全测试等，分别为了检验修改或优化过程是 否引发新的问题、软件所能达到处理能力和是否达到预期的处理能力等

6. 软件测试为了建立软件的信心

7. 从测试的目的出发，大概可以分为两类：为了验证程序能正常工作的测试                                                                                                         为了验证程序不能正常运行的测试 

4. 什么是需求

IEEE定义：软件需求是

(1)用户解决问题或达到目标所需条件或权能(Capability)

(2)系统或系统部件要满足合同、 标准、规范或其它正式规定文档所需具有的条件或权能

(3)一种反映上面(1)或(2)所述条件或权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制

在多数软件公司，会有两部分需求，一部分是用户需求，一部分是软件需求

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

软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。 软件需求是测试人员进行测试工作的基本依据

5. 什么是bug 

准确的来说：① 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误

                      ② 当没有需求规格说明书时，判断标准以最终用户为准：当程序没有实现其最终用                             户合理预期的功能要求时，就是软件错误

5.1 如何描述一个bug

一个合格的bug描述应该包括以下几个部分：

1、发现问题的版本

开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量

2、问题出现的环境

环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位

3、错误重现的步骤

描述问题重现的最短步骤

4、预期行为的描述

要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。 要相信：测试人员是最懂需求的

5、错误行为的描述

描述错误的现象。crash等可以上传log，UI问题可以有截图

6、其他某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高

7、不要把多个bug放到一起

在无法确认是同一段代码造成的故障时，不要将bug放在一起提交

案例：

提交了如下bug：

1、在短信列表，选择一条短信，进行删除，删除失败

2、在短信列表，选择一条短信，进行查看，在查看页面，进行删除，删除失败

故障发现版本：VPS20180226_01

故障类别：兼容性

故障优先级：中

故障标题:ie下界面显示异常，界面文字有重叠

故障描述：

        测试环境：win7+IE8

        测试步骤：1、打开vps首页，点击“通知”链接，进入通知页面

        预期结果：通知页面显示正确，一页显示10条通知，按时间顺序倒序排列

        实际结果：页面显示10条通知，通知顺序正确，但是页面文字有重叠

附件：上传截图 

5.2 如何定义bug的级别

在开发和测试的争执中，一部分是究竟是不是bug？一部分是bug的级别有点高吧？那么如何定义bug的级别？

bug的定义每个公司都不一致，在定义级别之前需要查看公司规范。

以下为样例：

1、Blocker（崩溃）：

阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能 丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等（该问题 在测试中较少出现，一旦出现应立即中止当前版本测试）

2、Critical（严重）：

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测 试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳 定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等 （该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）

3、Major（一般）：

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格 式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多）

4、Minor（次要）：

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范， 页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受 不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

5.3 bug的生命周期

每个公司、每一个工具对bug生命周期的定义都是不一致的，下面仅是一个常见的例子

测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态

● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改

● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员

● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证

● Rejected：如果认为不是Bug，则拒绝修改

● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改

● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug

● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改

无效的bug：open->closed open-rejected-closed

缺陷状态变更流程每个项目团队的实际做法可能不大一样。并且需要结合实际的开发流程和协作流程来使用

例如，测试人员新发现的Bug，必须由测试组长评审后才决定是否Open并分派给开发人员。测试人员Open的Bug 可以直接分派给Bug对应的程序模块的负责人，也可以要求都先统一提交给开发主管，由开发主管审核后再决定是否分派给开发人员进行修改。 Bug的跟踪以及状态变更应该遵循一些基本原则：

测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试，确保相同的问题不 再出现，才能关闭缺陷

对于拒绝修改和延迟修改的Bug，需要经过包含测试人员代表和开发人员代表、用户方面的代表（或代表用户角度的人）的评审

6. 什么是测试用例

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

测试过程中可能会遇到以下问题：

① 不知道是否较全面的测试了所有功能

② 测试的覆盖率无法衡量

③ 对新版本的重复测试很难实施

④ 存在大量冗余测试影响测试效率

测试用例的产生就是为了解决上述的问题

7. 开发模型和测试模型

随着软件工程学科的发展，人们对计算机软件的认识逐渐深入。软件工作的范围不仅仅局限在程序编写，而是扩展到了整个软件生命周期，如软件基本概念的形成、需求分析、设计、实现、测试、安装部署、运行维护，直到软件被更新和替换新的版本。软件工程还包括很多技术性的管理工作，例如过程管理、产品管理、资源管理和质量管理，在这些方面也逐步地建立起了标准或规范。

7.1 软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间

如果把软件看成是有生命的事物，那么软件的生命周期可以分成6个阶段，即需求分析、计划、设计、编码、测试、运行维护

​​​​​​​

a) 需求阶段

测试人员了解需求、对需求进行分解，得出测试需求

b) 计划阶段

根据需求编写测试计划/测试方案

c) 设计阶段

测试人员适当的了解设计，对于设计测试用例是很有帮助的，测试人员搭建测试用例框架，根据需求和设计编写一部分测试用例

d) 编码阶段

测试人员一般是不需要编码的，但已经编码的模块，专业的白盒测试人员可以计划执行单元测试，完善、细化测试用例以及调整测试计划和方案

e) 测试阶段

测试阶段是软件测试人员最为重要的工作阶段，根据测试用例和计划执行测试，在执行的过程中记录、管理 缺陷，测试完成后编写测试报告

f) 运行维护

测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达 能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人

7.2 瀑布模型

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

优点：

①强调开发的阶段性；

②强调早期计划及需求调查；

③强调产品测试。

缺点：

①依赖于早期进行的唯一一次 需求调查，不能适应需求的变化；

②由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；

③风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。

瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。这会给项目带来很大的风险，尤其是集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶段的工作大面积返 工，业界流行的说法是：“集成之日就是爆炸之日”。尽管瀑布模型存在很大的缺陷，例如，在前期阶段未发现的错 误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。 但是目前很多软件企业还是沿用了瀑布模型的线性思想，在这个基础上做出自己的修改。例如细化了各个阶段，在 某些重点关注的阶段之间掺入迭代的思想。

在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致 测试不充分，从而把缺陷直接遗留给用户

7.3 螺旋模型

螺旋模型（Spiral Model）

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。 这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重要性就不言而喻了

优点：

① 强调严格的全过程风险管理。

② 强调各开发阶段的质量。

③ 提供机会检讨项目是否有价值继续下去。

缺点：

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

7.4 增量、迭代

增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。增量开发模型，鼓励用户反馈，在每个达代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。

增量通常和迭代混为一谈，但是其实两者是有区别的。

增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……

而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色

7.5 敏捷

《敏捷宣言》： 我们通过身体力行和帮助他人来揭示更好的 软件开发方式。经由这项工怍，我们形成了如下价值观。

个体与交互重于过程和工具

可用的软件重于完备的文档

客户协作重于合同谈判

响应变化重于遵循计划

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

由敏捷宣言可以看出，敏捷其实是有关软件开发的社会工程(Social Engineering)的。敏捷的主要贡献在于他更多地 思考了如何去激发开发人员的工作热情，这是在软件工程几十年的发展过程中相对被忽略的领域。

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

7.5.1 scrum

scrum里面的角色

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

① 其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产 品负责

② scrum master 负责召开各种会议，协调项目，为研发团队服务

③ 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品

迭代开发

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

scrum的基本流程

a) 产品负责人负责整理user story，形成左侧的product backlog

b) 发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出 这一期迭代要完成的story列表，sprint backlog

c) 迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计

d) 每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题

e) 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story

f) 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果

7.5.2 敏捷中的测试

挑战1：轻文档

挑战2：快速迭代

1、测试工作的核心内客是没有变的，就是不断地找Bug，只是要调整好自己的心态，一切以敏捷的原则为主

2、测试人员不能依赖文档，测试用例作用减弱，更多的采用思维导图、探索性测试（强调自由度，设计和执行同 时执行，根据测试结果不断调整测试计划）、自动化测试

3、敏捷讲求合作，在敏捷项目组中，测试人员应该更主动点，多向开发人员了解需求、讨论设计、一起研究Bug 出现的原因

8. 软件测试v模型

V模型最早是由Paul Rook在２０世纪８０年代后期提出的，目的是改进软件开发的效率和效果。是瀑布模型的变种

① 明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的 对应关系

② V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的 质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求

③ 局限性:仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试

9. 软件测试W模型

a) W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试 与开发过程，图中明确表示出了测试与开发的并行关系。

b) W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的

c) W模型优点：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。

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

10. 配置管理和软件测试

是否真正做过项目从对配置管理的熟悉程度来看，是最容易辨别的

SVN &GIT

很多人其实对配置管理并不熟悉，对配置管理的作用也很模糊，存在很多的误解，认为配置管理是可有可无的东 西。甚至很多测试人员也对此知之甚少，认为软件测试与配置管理的关系不大。实际上，一个配置管理做得好的公 司，它的测试活动也会开展得比较顺利，测试人员在这种环境下工作也会碰到更少的阻碍和困难

在参与当代软件开发时，必须具备软件配置管理方面的基本素养。不懂软件项目的配置管理，就不懂软件开发管 理。没有对软件项目进行配置管理，其实就没有进行软件项目开发管理

10.1 什么是配置管理

配置管理( Configuration Management)是通过对在软件生命周期不同的时间点上的软件配置进行标识，并对这些被标识的软件配置项的更改进行系统控制，从而达到保证软件产品的完整性和可溯性的过程

10.2 软件配置管理的应用

软件开发过程中会产生大量软件产品（包括文档、源代码和数据等），且这些产品之间存在关联关系。同一软件产品也会发生变更，从而产生许多版本。软件开发小组必须清晰地知道会有哪些产品、这些产品会有哪些不同的形式 和版本。开发小组必须清晰地知道如何将产品的变更通知给受影响的小组。如果不能有效地了解软件产品及其变 更，开发小组将很难组装这些软件产品，很难得到所需的软件产品

10.3 实施软件配置管理的好处

实施软件配置管理(SCM)，至少能给项目团队带来如下好处

(1)能够对项目中的文档、代码等的变化进行有效管理

(2)能够方便地重现某个文件的历史版本

(3)能够重新编译某个历史版本，使维护工作变得容易

(4)能够使 异地多团队开发、并行开发成为现实

(5)从公司级看，实行统一的配置管理流程可提高项目组间人员流动时的工作效率

10.4 配置管理与软件测试

测试人员是SCM中的参与者，有些公司也会把测试人员和配置管理员合二为一。如果配置管理流程不规范，或者没有遵循一定的配置管理流程进行软件测试活动，也可能导致很严重的后果

假设开发人员修正了一个Bug，然后找测试人员过去讨论，测试人员在开发人员的机器上重新测试了一下，发现 Bug没再出现了，修复了，这时候，如果测试人员把缺陷关闭了，则可能导致缺陷莫名其妙地在用户那边又出现了

其实，原因可能仅仅是开发人员把这个Bug修改的代码没有提交的到配置管理数据库中。但是作为测试人员有没有责任呢？

当然有，因为测试人员也没有按照规范的配置管理流程执行测试，测试人员应该从配置库取源代码编译后再测试，只有看到新的构建版本不再出现那个Bug，才能把缺陷库中的Bug关闭

如有错误还请各位小伙伴批评指正

最后美图收尾嘻嘻~~（星之守护者 迦娜）