随着疫情的逐渐好转，各用人单位也开始复工复产，再加上现在是招聘旺季，面试是少不了的。为了回馈粉丝，织雀教育特将目前为止已经毕业并顺利通过各大公司面试的学员遇到的问题做了整理，相信会给大家带来一定的帮助！
01测试延期怎么办？
首先，我们要分析出测试延期的原因，是研发没有按时提交被测试代码；还是由于测试任务比较重，导致没有在规定的时间内完成。然后针对具体的情况实行相应的策略。
1.如果是研发没按时间提交被测试代码，为了保证测试质量，我们还是按照里程碑里规定的测试周期进行测试，整个项目周期需要顺延。（因为是研发周期变长，没有理由缩短测试周期，我们只能保证测试周期不变，项目的整体时间顺延）
2.如果是因为测试任务比较重，导致测试延期，这种情况下我们需要从所有的任务中进行优先级别的划分，针对优先级别较高的任务优先去进行测试。（这种情况下，需要整个项目组成员开会去讨论优先级别）
3.从其他项目组协调相关的测试人员，争取在规定的时间内完成测试。
02软件测试在整个项目中的重要性
我认为测试在整个项目中担任很重要的角色。因为，测试是保证软件质量的最后一关。如果公司研发的软件没有经过测试，用户在使用的过程中，可能会有很多问题暴露在用户现场。这种情况下，给用户带来的不仅仅是软件不可用的问题，而是用户对公司的认可问题，甚至严重的情况下会带来更严重的问题，比如财产、人身安全等问题。
03Bug的管理工具，用什么软件管理bug？
我上家公司，用的是QC，我也用过禅道，目前禅道在国内有好多单位都在用。其他的缺陷管理工具Bugzilla、BugFree我也了解过。
04能够独自编写测试用例吗，用例的要素？
我自己可以独立完成测试用例设计，我在做XXX项目时，整个项目是我自己独立负责的，测试用例的编写以及组织用例评审、测试的执行、问题的提交和跟踪、最终测试报告的提交，整个项目是我自己负责的。
我在做XXX项目时，我们公司用的测试用例模板大概包括则几个方面：测试的目的、测试的环境、测试步骤、预期结果、实际结果、测试的优先级别、执行人和测试时间。
05登录界面的测试用例
我在做XXX项目的是，我设计用的思路是这样的。
首先，要分析登录界面包括的元素有哪些，我们登录时会输入用户名、密码、验证码等条件选项。
然后，判断登录后，有两种结果，一个是成功，另一个是失败。输入的内容是条件，得出的是结果。所以在设计用例时可能考虑到因果关系，要用到因果图去设计测试用例。
所有的条件都输入正确的情况，登录时成功的。其中一个条件或多有条件输入错误的情况，登录是失败的。
最后，我们还要考虑，登录失败次数达到上限，会不会锁定登录；还要考虑到在锁定时间内，重新登录的情况；还要考虑到超过锁定时间，重新登录的情况。
06怎么编写的测试用例（针对输入框）
针对输入框，是有长度和输入类型的限制。在设计测试用例时要使用等价类和边界值结合一起进行设计测试用例，针对长度测试要考虑到边界的左右两组数据。针对类型的话要考虑到有效的类型和无效的类型。
07负责的项目明天上线却发现了一个重要bug，你该怎么办？
1.把问题及时汇报给自己的领导，同时，把这个问题告知项目组所有参与项目的同事。
2.然后组织整个项目组的同事，讨论这个问题对上线的影响。
3.最终确定如何去解决这个bug，因为出现的是严重的bug而不是紧急的bug，不一定影响产品上线，我们可以在发现问题后及时去解决。如果情况很紧急，则要尽快解决这个问题，不影响正常上线。
08研发如果给了未开发完成一部分的产品要怎么测试
首先，要把完成的和未完成的功能点梳理出来。然后，针对完成的功能点进行测试。
1. 数据库会什么命令
我在做项目的时候，用到过，创建用户的命令：create user 用户名@% identified by ‘密码’；删除用户的命令：drop user 用户名@% ；创建数据库的命令：create database 数据库名字；
创建表的命令：create table 表名（列名1 类型1，列名2类型2）；等等
09SQL修改数据、查询命令
修改数据的命令：update user set 列名 =‘ 修改后的内容 ’ where 列名=‘ 列名所修改行数’；
常用查询表的命令：select * from 表名where列名=‘ 需要查找的内容‘；
010删除数据命令
删除数据的命令：delete from 表名where 列名=‘ 需要删除的内容‘；
011你发现了BUG，开发认为不是怎么办
首先，我要确定这是一个可以复现的真实bug。在bug管理工具中提交这个bug。在提交的过程中，我要保存每一步的截图，作为证据。
然后，根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；也可以根据根据用户的一般使用习惯，来确认是否是缺陷；
最后，组织设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；（在探讨的过程中，合理的论述，说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。）
閱讀更多 說說軟件測試那些事兒 的文章
