软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能测试，以下是查字典大学网小编整理提供的相关面试题内容，快来阅读看看吧。
软件测试面试题
问题是：怎么测电梯
前提条件是：这是一道软件测试工程师面试题，而非真正的电梯测试人员的面试题
第二个前提：我没有需求文档，但我了解电梯的基本业务功能
思路：把电梯当作一个我了解基本业务功能，却没有需求文档的软件来进行测试。也就是说这里考察两点:
第一，你能不能测没有需求文档，或者需求文档不完整的东西
第二，你能不能把测试用例设计方法应用到实际工作上去
还隐含第三点，你的测试思维是否完整，测试范围能想得比较全面吗。
2确定测试范围
以下是黑盒角度的
功能：关注电梯的基本功能是否实现
性能：关注电梯的性能指标，如负重多少kg
安全性：关注电梯的安全性，如超重报警，下坠制动
用户体验：关注电梯的舒适性
以下是白盒角度的或其他的
效率：关注电梯控制逻辑的内部算法
接口：电梯和电梯控制器，电梯和大楼，电梯和摄像头，电梯和对讲机(报警装置)的接口测试
零件：电梯的零件的单元测试
兼容性：电梯和其他东西的兼容性
3具体测试用例的设计
3.1功能测试：
思路一：基于用户界面，如按钮，分电梯内的按钮和电梯外的按钮;电梯内分楼层键、开关门键、报警键。然后对这些键，一个一个测过来。同时关注显示屏，电梯内外的显示屏均显示电梯当前所在楼层和运行方向。
思路一就是典型的单元测试。
思路二：单个功能测好之后，再把单个的功能组合起来进行测试(集成测试)，集成测试时可以根据电梯当前状态是上行、下行还是停止(状态机)来设计测试用例，以保证覆盖率。
比如上行时按XX按钮会怎么样。此时可以向面试官提出等价类划分思想，为何我要测这些按钮，如何划分等价类。
思路三：集成测试完毕后，开始测试真实用户场景(确认测试/验收测试/工作流测试)，此时可以设计常见的用户场景(场景设计)并进行测试。如大量用户从1楼进入，并去不同楼层。又或者大量用户从不同楼层下到1楼。
思路四：不同品牌电梯的比较，电梯和电梯国际标准的比较，电梯和安装电梯的大楼用户需求的比较等等
思路五：特殊需求的测试，如摩天大楼可能要求高速电梯。百货大楼可能要求观光电梯。
3.2性能测试：
思路一：测试电梯负载单人时的运行情况(基准测试)、多人时的运行情况(负载测试)、一定人数下较长时间的运作(稳定性测试)、更长时间运作时的运行情况(疲劳测试)、不断增加人数导致电梯报警(拐点压力测试)
思路二：不同层次的性能，如零部件性能等
3.3安全性测试：
软件的安全性测试我也不了解。只能瞎说了。比如，暴力破坏电梯，下坠制动测试，超重警报、超时警报的测试，报警功能的测试，监控摄像头测试，火灾时应该不让用户使用，但又要让里面的人能出来等等。
3.4用户体验：
电梯是否有地毯，夏天是否有空调，通风条件，照明条件。等等
3.5效率：调度算法是否合理，是否最优，按错键是否可以取消
3.6零件：零部件是否合格
3.7接口：电梯和其他设备的交互，如报警装置、中央空调、监控室等等如何交互，是否工作正常
3.8兼容性：电梯的整体和其他设备的兼容性
以上，是我考虑的答案。一般把整体思路说一下，再把3.1功能测试部分重点讲一讲就ok了，面试官应该会满意的。
如果把电梯换成电话，测试思路还是这个，顶多就是换一些具体用例。或者电梯换成其他任何东西都一样的，关键是，把它当作软件，展示测试思维。
常见软件测试面试题
以往是否曾经从事过性能测试工作?请尽可能的详细描述您以往的性能测试工作的完整过程。
曾经做过一套网管系统的性能测试，主要测试该软件在同时管理大量终端的情况下，在响应时间，CPU/磁盘/内存等参数是否满足要求。
也曾经做过软交换系统的呼叫性能测试，主要是测试软交换系统在有大量呼叫的情况下，响应时间，呼叫成功率，CPU/磁盘/内存等参数是否满足设计要求。
您在从事性能测试工作时，是否使用过一些测试工具?如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
测试网管系统中，使用的Mimic来模拟终端，能够大量的节省成本。
测试软交换系统的时候，使用的Prolab来模拟终端并发送呼叫软交换，他完成了同时数百人才能完成的摘机拨号工作，主要工作原理是产生一些符合要求的IP包并发送给软交换系统，同时对软交换系统的回应进行处理，决定下一步动作。
您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么?
主要是保障在大量用户的情况下，服务能正常使用。
在您以往的工作中，一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?
1.在传统的BugZilla中，BUG描述应该包括以下的信息
2.和BUG产生对应的软件版本
3.开发的接口人员
4.BUG的优先级
5.BUG的严重程度
6.BUG可能属于的模块，如果不能确认，可以用开发人员来判断
7.BUG标题，需要清晰的描述现象
8.BUG描述，需要尽量给出重新Bug的步骤
9.BUG附件中能给出相关的日志和截图。
高质量的BUG记录就是指很容易理解的BUG记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。
BUG管理工具的跟踪过程
用BugZilla为例子
测试人员发现了BUG，提交到Bugzilla中，状态为new，BUG的接受者为开发接口人员
开发接口将BUG分配给相关的模块的开发人员，状态修改为已分配
开发人员和测试确认BUG，如果是本人的BUG，则设置为接收;如果是别的开发人员的问题，则转发出去，由下一个开发人员来进行此行为;如果认为不是问题，则需要大家讨论并确认后，拒绝这个BUG，然后测试人员关闭此问题。
如果开发人员接受了BUG，并修改好以后，将BUG状态修改为已修复，并告知测试在哪个版本中可以测试。
测试人员在新版本中测试，如果发现问题依然存在，则拒绝修改;如果已经修复，则关闭BUG。
您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果?维持测试人员同开发团队中其他成员良好的人际关系的关键是什么?
尽量能有面对面的沟通，如果做不到，那么尽量能直接通过电话沟通，如果只能通过Email等非及时沟通工具的话，强调必须对特性的理解深刻以及能表达清楚。
一是真诚，二是团队精神，三是在专业上有共同语言，当然也可以通过直接指出一些小问题，而不是进入BUG Tracking System来增加对方的好感。
在您以往的测试工作中，最让您感到不满意或者不堪回首的事情是什么?您是如何来对待这些事情的?
某次性能测试覆盖不足，造成系统崩溃。
你对测试最大的兴趣在哪里?为什么?
最大的兴趣就是测试有难度，有挑战性!做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了11，12点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的1，2点我没有把握，其他点我都很有信心做好它。
刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发(学校专业课我基本上不缺席，因为我喜欢我的专业)，但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。
我觉得做测试整个过程中有2点让我觉得很有难度(对我来说，有难度的东西我就非常感兴趣)，第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写?(也就是测试计划或测试策略)，如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解(多和产品经理和开发人员沟通就能达到目的)，而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的?测试环境如何搭建?这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题?需求细节是不是没有确定好?这些问题都能在设计用例的时候发现。
第二是发现BUG的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出bug。还有如何发现bug?这就需要在测试用例有效的情况下，通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰(测试过程数据流及结果都得看仔细了，bug都在里面发现的)。如何描述bug也很有讲究，bug在什么情况下会产生，如果条件变化一点点，就不会有这个bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么?如果你够厉害的话，可以帮开发人员初步定位问题。
以上就是查字典大学网为同学们带来的“2016年软件测试面试题”内容了，希望看完能够带给大家一些力量，对同学的生活有所启示，更多内容在这里，请继续关注我们。