我把软件测试面试的整个题库都搬来啦，面试能拿下80%，剩下就看你满不满意公司的开价咯。以下答案都是我自己写的，大家根据自己的经历稍作改动，答案仅供参考哦！题库持续更新，需要PDF版可以点击文末小卡片领取~~
灵活问题
-
自我介绍
-
自己的优点和缺点是什么？性格特点是怎么样的？
-
项目一般多长时间？一个项目有多少个接口？
-
公司有几个测试，工作如何分配？
-
有关注过错误率吗？在百分之多少里面是合适的范围？
-
工作过程中你有哪个印象深刻的bug吗？
-
未来的职业规划
Q1
大概说说之前公司的测试流程
A
（1）在产品人员组织需求评审后，进行测试用例编写、组织用例评审会，用例评审通过后等待开发自测P0用例后提测到测试环境，用例评审不通过则根据评审结论修改测试用例再重新评审
（2）开发提测后，在测试环境测试P0用例，P0用例通过后执行测试，P0用例不通过则打回重新开发
（3）测试过程发现bug提交给开发修复，最后回归验证缺陷和重点测试用例，测试通过后发送测试报告，进入发布流程
（4）发布后，在预发布环境和线上环境进行测试验证
Q2
测试报告有哪些内容？
A
（1）项目需求：需求链接、需求提测时间、是否准时交付、是否变更、上线风险评估
（2）人员：项目组成员包括产品人员、测试人员、开发人员、业务人员、项目经理
（3）测试用例：P0用例是否通过、用例是否评审、用例集呈现
（4）缺陷：缺陷数量、缺陷等级、遗留缺陷
（5）接口信息：接口URL、路径
（6）测试结果：明确测试是否通过
（7）风险评估：评估测试完上线后可能会出现的风险
Q3
如何保证用例的覆盖度？
A
（1）首先设计用例先覆盖显性需求，需求文档中提到的内容全部覆盖
（2）思考隐含的需求，如需求未提及的页面交互细节，需和项目组同事确认后补充用例
（3）利用等价类、边界值、错误推测等方法提高覆盖度
（4）项目的典型问题、出现频率较高的缺陷、线上遗留问题作为用例参考
（5）用例评审，从产品、开发、业务人员多角度提高用例覆盖度
Q4
什么是测试用例，什么是测试脚本？两者的关系是什么？
A
测试用例是为测试执行编写的操作步骤、预期结果等的集合，测试脚本是为自动化测试而编写的脚本，测试脚本是根据测试用例来编写的
Q5
bug的级别，是按照什么划分的？
A
按照对系统的影响程度和处理的优先级来划分
一级bug（致命性缺陷）：常规操作导致系统崩溃死机、无法正常使用，或者涉及金钱损失，还有令测试工作无法继续进行，也就是执行不通过的冒烟用例
二级bug（严重缺陷）：重要的功能不能实现，影响其他功能使用
三级bug（一般缺陷）：次要功能不能实现，外观与原型设计不符，查询数据错误
四级bug（细微错误）：程序不美观，不符合用户使用习惯，错别字
Q6
你认为是bug，开发认为不是bug，你会如何解决？
A
首先要本着解决问题的目的，不应该过分追究是否为bug，而是讨论这个问题是否需要解决
在发现与用例预期结果不符的问题，我会将问题提交到缺陷库，然后和开发当面沟通，说明理由和复现bug产生的过程，如果是由于需求不明确，会和产品一起讨论问题是否应该解决。
Q7
给你一个网站，你怎么进行测试？
A
（1）仔细研读需求文档，对需求不明确的点进行记录，和产品开发确认好需求的细节
（2）编写测试用例应包含功能测试、界面测试、性能测试、安全性测试、兼容性测试。
功能测试需覆盖每个链接是否正常跳转以及需求内要求的功能是否正常实现
界面测试需要验证网站的界面是否与原型设计一致
性能测试根据要求的性能指标设计测试用例
安全性测试需验证接口提交非法参数是否会注入脏数据影响网站的使用
兼容性测试需验证网站在各浏览器中是否兼容
Q8
如果没有需求文档怎么办？
A
没有需求文档我认为测试不应该介入到项目中，没有需求文档会增加团队沟通的成本，任务进度安排和分配也不合理，如果需求变更会陷入恶性循环
Q9
编写用例用什么工具写，包含什么内容？
A
我习惯用xmind编写，包含用例编号、标题、优先级、输入的数据和步骤、预期结果、实际结果
Q10
需求文档不详细，怎么设计测试用例？
A
（1）分析需求文档原型图，思考需求目的和最终实现的结果
（2）有问题记录下来，整理成问题清单，与项目组产品开发沟通确认
（3）编写测试用例后，进行测试用例评审，再对测试用例进行补充
Q11
web测试bug如何定位，有哪些手段方法？如何定位前后端bug？
A
（1）首先排除这个问题不是由于操作失误和网络原因引起的
（2）抓包查看接口，定位是前端问题还是后端服务问题，检查前端发送的参数是否正确，后端响应信息是否返回正确，前端是否把后端响应正确展示到界面
Q12
app测试和web测试有什么区别？
A
（1）app测试是基于客户端的，web测试是基于浏览器的
（2）web性能测试需要关注响应时间、CPU、系统负载能力，app性能测试还需要关注流量和手机电量、运行内存
（3）web兼容性测试考虑操作系统和浏览器类型和版本的兼容，app兼容性测试则需要考虑手机型号、设备系统、手机分辨率、手机大小以及手机浏览器的兼容
Q13
bug管理工具包含哪些内容？
A
包含整个缺陷生命周期的流程，由测试提起bug，开发接受bug，bug已解决，bug重新打开，bug关闭，bug拒绝，bug延期处理
Q14
简述bug的生命周期
A
新建、已拒绝、关闭
新建、接受、已解决、(重新打开、已解决）、已关闭
Q15
项目是如何发布的？（项目流程）
A
（1）测试完成后发送测试报告，通知项目组人员，达到上线标准后进入发布流程
（2）前后端开发打包代码到Jenkins
（3）测试统一部署到生产环境
（4）生产环境进行重要功能的验证，验证通过后通知产品验收
Q16
项目上线有bug，如何处理？
A
（1）判断bug等级以及影响的范围
（2）致命性缺陷和严重性缺陷考虑版本回退再修复，一般缺陷不影响重要功能使用的和产品开发讨论修复bug的时间以及优先级
Q17
站在测试角度，怎么保证软件产品的质量？
A
（1）需求评审阶段对需求有充分的理解，尽可能与产品开发理解达成一致
（2）用例设计阶段尽可能提高用例覆盖率
（3）发现问题及时沟通处理，对于不能复现的问题也要做好记录
（4）进行回归测试，引入自动化测试提高回归测试的工作效率
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。
