问题如下：
1.如果一款软件测试没问题，但客户使用出现问题，但测试不能复现，怎么办？
第一时间应该知道客户使用出现了什么样的问题，然后在自己模拟客户操作进行使用。若自己使用没有出现问题，就对客户的使用环境及条件进行检查。
2.面试官指着桌子上的一瓶矿泉水说，假设这是他们公司做的产品，给我测试，我要怎么测试？
水的颜色，PH值，口感，细菌量，瓶相当是UI界面，水才是你想要的
3.面试官问我点击一个按钮没有任何反应，我应该怎么办？
B/S架构的按钮很多都是要请求后台的。F12看请求调用情况，如果接口返回值正常，就是前端问题丢给前端就好。如何接口调用异常，基本就是后端的问题
4.面试官问我有没有测试过登录模块，是怎样测试的？
用户名和密码是非常重要的信息。所以说可以抓包看下是不是明文传输，如果是，就建议加密。
5.黑盒测试和白盒测试的优缺点？以及各自的测试方法有哪些？
1. 黑盒测试的优点有 ：
1) 比较简单，不需要了解程序的内部的代码及实现
2) 与软件的内部实现无关
3) 从用户的角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题
4) 基于软件开发文档，所以也能知道软件实现了文档中的哪些功能
5) 在做软件自动化测试时较为方便
缺点 ：
1) 不可能覆盖所有的代码， 覆盖率较低，大概只能达到总代码量的30%
2) 自动化测试的复用性较低。
=================
2. 白盒测试的优点有 :
1) 帮助软件测试人员增大代码的覆盖率。 提供代码的质量，发现代码中隐藏的问题
缺点 ：
1) 程序运行会有很多不同的路径，不可能测试所有的运行路径
2) 测试基于代码，只能测试开发人员做的对不对，而不能知道设计是否正确，可能会漏掉一些功能需求
3) 系统庞大时，测试开销会非常大。
6.怎么测电梯
前提条件是：这是一道软件测试工程师面试题，而非真正的电梯测试人员的面试题
第二个前提：我没有需求文档，但我了解电梯的基本业务功能
思路：把电梯当作一个我了解基本业务功能，却没有需求文档的软件来进行测试。也就是说这里考察两点:
第一，你能不能测没有需求文档，或者需求文档不完整的东西
第二，你能不能把测试用例设计方法应用到实际工作上去
还隐含第三点，你的测试思维是否完整，测试范围能想得比较全面吗。
2. 确定测试范围
以下是黑盒角度的
功能：关注电梯的基本功能是否实现
性能：关注电梯的性能指标，如负重多少kg
安全性：关注电梯的安全性，如超重报警，下坠制动
用户体验：关注电梯的舒适性
以下是白盒角度的或其他的
效率：关注电梯控制逻辑的内部算法
接口：电梯和电梯控制器，电梯和大楼，电梯和摄像头，电梯和对讲机（报警装置）的接口测试
零件：电梯的零件的单元测试
兼容性：电梯和其他东西的兼容性
3.具体测试用例的设计
3.1功能测试：
思路一：基于用户界面，如按钮，分电梯内的按钮和电梯外的按钮；电梯内分楼层键、开关门键、报警键。然后对这些键，一个一个测过来。同时关注显示屏，电梯内外的显示屏均显示电梯当前所在楼层和运行方向。
思路一就是典型的单元测试。
思路二：单个功能测好之后，再把单个的功能组合起来进行测试（集成测试），集成测试时可以根据电梯当前状态是上行、下行还是停止（状态机）来设计测试用例，以保证覆盖率。
比如上行时按XX按钮会怎么样。此时可以向面试官提出等价类划分思想，为何我要测这些按钮，如何划分等价类。
思路三：集成测试完毕后，开始测试真实用户场景（确认测试/验收测试/工作流测试），此时可以设计常见的用户场景（场景设计）并进行测试。如大量用户从1楼进入，并去不同楼层。又或者大量用户从不同楼层下到1楼。
思路四：不同品牌电梯的比较，电梯和电梯国际标准的比较，电梯和安装电梯的大楼用户需求的比较等等
思路五：特殊需求的测试，如摩天大楼可能要求高速电梯。百货大楼可能要求观光电梯。
3.2性能测试：
思路一：测试电梯负载单人时的运行情况（基准测试）、多人时的运行情况（负载测试）、一定人数下较长时间的运作（稳定性测试）、更长时间运作时的运行情况（疲劳测试）、不断增加人数导致电梯报警（拐点压力测试）
思路二：不同层次的性能，如零部件性能等
3.3安全性测试：
软件的安全性测试我也不了解。只能瞎说了。比如，暴力破坏电梯，下坠制动测试，超重警报、超时警报的测试，报警功能的测试，监控摄像头测试，火灾时应该不让用户使用，但又要让里面的人能出来等等。
3.4用户体验：
电梯是否有地毯，夏天是否有空调，通风条件，照明条件。等等
3.5效率：调度算法是否合理，是否最优，按错键是否可以取消
3.6零件: 零部件是否合格
3.7接口：电梯和其他设备的交互，如报警装置、中央空调、监控室等等如何交互，是否工作正常
3.8兼容性：电梯的整体和其他设备的兼容性
