浦发银行软件测试面试真题（小编面试亲测）

对于想要面试去银行面试的小伙伴们看过来，今天为大家总结了浦发银行的面试题，其实很多面试题很多公司都差不多。主要看自己如何灵活回答。以下的问题小编盆友之前面试非浦发银行的银行项目也有被问到过，是在一面的时候被问到的。答案仅作为参考，大家可以灵活回应。希望对大家有所帮助！

说说你们公司测试的一个基本测试流程是什么？

首先会召开需求分析会议，参加人员有产品、开发和测试，主要是探讨需求主要的一些功能点，完了之后，开发就排期进行开发，我们就根据主管写出来的计划、分配到的任务编写测试用例，写完之后会进行用例评审，有评审修改的就修改整理形成最终的用例版本，之后开发人员版本编译完成后，我们会依据测试用例来执行测试，测试过程中，提交bug，跟踪bug，直至关闭，测试完后编写测试报告。

你对上一家公司如何评价

我的上家公司环境蛮不错的，整个项目组的成员都很团结，氛围很浓郁，遇到不懂的问题我能够和同事们进行沟通，但是考虑到我自身发展的因素，我还是被迫辞职了

你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决。

首先，将问题提交到缺陷管理库里面进行备案。

然后，要获取判断的依据和标准：根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；

如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；

根据用户的一般使用习惯，来确认是否是缺陷；与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。

等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并由上级做出决定。

软件生存周期及其模型是什么？

软件生存周期是软件开发全部过程、活动和任务的结构框架，是从可行性研究到需求分析、软件设计、编码、测试、软件发布维护的过程。

在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为"生命周期模型"（Life Cycle Model）。

什么是系统测试？

系统测试是指针对软件产品系统进行的测试，是做完单元测试和集成测试后进行的测试，总体包含功能测试与非功能测试。

功能测试是验证软件系统功能是否实现系统需求规格的测试过程，而非功能测试是验证系统是否在实现功能测试的基础上，测试系统的容错性、稳定性、异常处理能力，以及高强度输入的处理能力、可用性、性能等是否符合用户要求的测试过程。

Web测试包括哪几类测试？

●界面测试

●功能测试

●可用性测试

●客户端兼容性测试

●安全性测试

黑盒测试与白盒测试的区别？

（1）黑盒测试也称功能测试，通过测试来检测每个功能是否都正常使用，测试中把程序看成一个黑盒子，在完全不考虑内部程序结构和特性的情况下，执行测试。黑盒测试是以用户角度，从输入数据与输出数据的对应关系出发进行的测试。缺点是：发现不了本身设计或规格说明的问题。黑盒测试设计测试用例的方法包括：等价类划分法、边界值分析法、判定表法、因果图法、正交法、错误猜测法等；

（2）白盒测试是基于代码测试，白盒是指盒子是可视的，清楚内部是如何运作的，白盒测试人员要全面了解程序内部逻辑结构、对所有的逻辑路径进行测试。常用的白盒测试用例设计方法有：语句覆盖法、判定覆盖法、条件覆盖法、判定条件覆盖法、路径覆盖法；

什么是冒烟测试？

冒烟测试是对应用程序的重点功能进行测试，主要是看测试的软件主要功能能否实现，环境通不通

测试计划包含哪些内容5个W一个H

Why:为什么要进行测试，测试的目的是什么

What:测试哪些方面，不同阶段的工作内容

When:测试不同阶段的起止时间

Where:相应的文档、缺陷存放位置，测试环境等

Who:测试的人员安排

How:测试的策略方法以及测试工具

Bug的生命周期

录入缺陷后，测试人员应该跟踪一个缺陷的整个生命周期，从new到closed的所有状态包括new、open、fixed、rejected、delay、closed和reopen这些状态。

提交缺陷到缺陷管理工具，这时缺陷的状态是new。当确认是bug后，打开缺陷，此时缺陷状态为open，并且指派给相应的开发人员。开发人员进行修改把缺陷状态置为fixed修改状态，修改好后等待测试人员回归测试。如果开发人员认为不是bug有权拒绝修改把缺陷状态改为rejected。如果开发人员认为暂时不需要修改或暂时不能修改，则延后修改，缺陷状态为delay。修改状态的bug经过测试人员复测通过后，则关闭bug，状态为closed。如果复测不通过，则重新打开bug这时的缺陷状态是reopen，等待开发人员重新修改。

QA和QC他们的共同点和区别？

QA是质量保证人员 QC是质量控制人员

他们都是对质量进行管理，都是在查找错误，但是QC查找的是产品错误，而QA查找的是过程错误

如何测试一部电梯？

功能性方面：首先看看这部电梯是否能够使用，能不能承载重物，看看使用说明；

安全性方面：看这部电梯有没有产品安全标识，验证在使用过程中是否能够保证安全使用；

易用性方面：看看这部电梯操作是否都能正常，按键能不能操作，门能否能打开；

界面方面 ：先看看电梯外观是否完好无损，有没有破坏的地方，或者设计不合理的地方；

兼容性方面 ：看看这样的电梯安装在不同地区的楼层是都都能正常使用，在不同的温度，人员重量下是否正常使用；

性能测试方面：看看电梯的控制主板是否正常，是否需要等很长时间；

压力测试方面 ：实验用此电梯的极限重量的物品放在电梯里面，看电梯是否会报警；

可靠性方面：长时间使用这部电梯看看电梯正常工作的最长时间是多少。

测试人员在软件开发过程中的任务是什么？

1、寻找Bug；

2、避免软件开发过程中的缺陷；
3、衡量软件的品质；
4、关注用户的需求。
总的目标是：确保软件的质量。

黑盒测试和白盒测试是软件测试的两种基本方法，请分别说明各自的优点和缺点！

黑盒测试的优点有：

●比较简单，不需要了解程序内部的代码及实现；

●与软件的内部实现无关；

●从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；

●基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；

●在做软件自动化测试时较为方便。

黑盒测试的缺点有：

●不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%；

●自动化测试的复用性较低。

白盒测试的优点有：

●帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。

白盒测试的缺点有：

●程序运行会有很多不同的路径，不可能测试所有的运行路径；

●测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；

系统庞大时，测试开销会非常大。

测试计划工作的目的是什么？测试计划文档的内容应该包括什么？其中哪些是最重要的？

软件测试计划是指导测试过程的纲领性文件。

包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）。

黑盒测试的测试用例常见设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

划分等价类:

等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

边界值分析法

边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

错误猜测法

基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

因果图方法

前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

正交表分析法

有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。

场景分析方法

指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。

状态图法

通过输入条件和系统需求说明得到被测系统的所有状态，通过输入条件和状态得出输出条件；通过输入条件、输出条件和状态得出被测系统的测试用例。

大纲法

大纲法是一种着眼于需求的方法，为了列出各种测试条件，就将需求转换为大纲的形式。大纲表示为树状结构，在根和每个叶子结点之间存在唯一的路径。大纲中的每条路径定义了一个特定的输入条件集合，用于定义测试用例。树中叶子的数目或大纲中的路径给出了测试所有功能所需测试用例的大致数量。