- 软件的生命周期？
根据市场需求—制定项目计划—进行需求分析—设计阶段— 程序编码—软件测试—运行维护
根据线上运行情况以及市场需求制定下一个 项目计划。
软件测试基础理论
- 为什么要进行需求评审？
消除歧义，完善细节，达成共识， 最终形成一个完整的，统一的标准的需求文档。
项目成员，项目需求评审
- 需求评审的原则
明确性，正确性，完整性，优先级，限制性，一致性。具体可以参考
项目成员，项目需求评审
- 需求评审的流程
产品人员制定需求文档—给到开发，测试人员
开发，测试，产品 进行三方评审 （小的需求30分钟以内，大的视情况而定）
生成统一的标准的需求文档
开发根据需求文档进行编码，测试人员根据需求 制定测试计划，编写测试点，测试用例。
项目成员，项目需求评审
- 软件测试计划中有哪些内容？
测试对象，测试目标，测试准则（通过/失败/挂起/恢复），项目风险，防范机制，项目周期，交付标准。
一般由测试经理，测试组长编写。
软件测试的流程
- 你们公司软件测试的流程（比较重要）
我们从拿到需求文档就是开始介入测试的
根据需求文档进行测试计划编写，测试点整理，测试用例编写 （Excel，Xmind，禅道平台）
对测试点，测试用例进行评审
等开发提测，开始正式进入测试阶段
先进行简单的冒烟测试 （标准是主流程能够跑通）
对本次开发更新的功能进行全量测试
全量测试通过之后进行1-3轮回归测试，最后进行一次验收测试（产品经理，用户）
达到上线标准之后进行上线，上线之后在线上进行简单的冒烟测试。
编写测试报告与总结。
- 编写整理需求点（整理测试点，整理测试用例）的方法有哪些？
常用的黑盒测试方法：
- 等价类划分法
- 边界值分析法
- 判定表法
- 场景法
- 因果分析法
- 状态迁移法
- 正交实验法
- 异常分析法
- 错误推测法
整理到xmind中，或者Excel文件中。
- 编写测试用例的步骤
我一般使用Xmind（Excel，禅道）工具来编写用例。
根据需求文档，整理测试点，
根据整理的测试点编写测试用例，
测试用例包含：
- 序号
- 模块
- 标题
- 前提条件
- 测试环境
- 操作步骤以及数据
- 预期结果
- 实际结果
- 优先级
- 是否通过
- 备注
如何评审测试用例?
- 根据需求文档，是否100% 覆盖所有的需求。
- 检查是否详细的操作步骤以及明确的预期结果。
- 可操作性要强。
- 测试用例是否清晰，简洁，明了。
- 测试用例是否有冗余。
你认为什么样的用例是好的用例?
参考回答
- 确保测试用例跟需求文档上面的需求点保持一致；
- 确保用例有足够多的异常场景（无效等价类的测试点），同时确保用例没有冗余；
- 用例要保证操作步骤，预期结果的准确性，简洁清晰，确保用例可操作性，可复用性(举例： 测试新系统的时候可以复用旧版本的用例)
- 测试用例的评审优化用例
- 用例要根据需求的变更及时更新
- 测试用例你们公司是怎么评审的？谁来评审？
我们公司内部先测试人员进行交叉评审。
评审完成之后，给开发，产品进行评审。
我们评审的时候一般遵循如下原则：
- 根据需求文档，是否100% 覆盖所有的需求。
- 检查是否详细的操作步骤以及明确的预期结果。
- 可操作性要强。
- 测试用例是否清晰，简洁，明了。
- 测试用例是否有冗余。
- 给你一个已经上线的应用，之前没有测试人员，现在由你进行测试工作，你会从哪些方面开始进行测试工作？
首先根据自己的以往经验，先做一次主要流程的冒烟测试。
测试过程中记录下自己对这些功能的理解，形成对应的文档，与产品人员约定一个合适的时间进行一次文档评审。
也可以根据市场竞争对手的产品进行对比，从用户的需求出发来对我们公司的产品进行对比，遇到一些有出入的功能及时与产品人员讨论。
参考产品的使用手册整理测试点，编写测试用例，约时间与开发，产品人员进行评审。
- 如何提交一个高质量的bug？
bug标题要简洁，清晰明了，能够清楚的描述出缺陷。
复现步骤要具体并且有具体的数据。
提供必要截图或者日志信息。
所测软件的版本号以及测试环境。
bug 的严重程度有哪些？
- 致命问题
- 严重问题
- 一般性问题
- 建议性问题
bug 的优先级有哪些？
- 立即处理
- 紧急处理
- 正常处理
- 延后处理
一条bug中包含哪些内容？
- bug摘要/标题
- 具体的操作步骤和数据
- 预期结果与实际结果
- 严重程度
- 优先级
- 指派给
- 状态
- 必要的附件和截图，日志
- 备注
用户通过什么渠道进行bug提交？
我们的软件中有用户反馈功能，用户可以直接通过邮件的方式与我们进行反馈。
- 你提交了一个bug，开发不认为这是一个bug，你会怎么办？
首先检查提交的bug是否清晰，明了。描述是否完整无误。
其次检查对应的需求文档。
“对事不对人”与开发一起根据需求进行讨论。
如果以上没有结果，将这个bug提交上级领导，让上级领导来定夺。
- 给你一个**功能，让你来测试，你大概需要多久？
（这类问题不要直接说多久）
要根据需求来推测。
首先 确定这个功能对应的需求点有哪些
整理需求点的时候 分为 有效，无效，边界值这些测试点，
根据整理的测试点编写测试用例，推测 有多少测试用例。
除了功能测试之外，还要考虑性能测试，兼容测试，界面测试，安全测试，易用性测试等。
总之 回答这类问题的时候，要把你分析问题的步骤说出来。也就是从需求分析，整理测试点，测试方法，测试用例这些讲一下。
- 每次回归测试的时候你们是怎么测试的？（几轮回归，每轮回归是怎么做的）
我们每周迭代一次，每次3轮回归
- 将本次迭代版本的所有测试用例以及跟本次迭代相关功能的用例进行一次全量测试。
- 第一次回归发现的bug以及跟bug相关的功能重点回归。
- 只对发现的缺陷进行回归。
我们回归测试需要1天左右时间。
- 第二轮回归发现的bug 比第一轮回归的bug 还多，你会怎么办？
要分析bug产生的原因，正常来讲，第二轮回归已经修复了一部分的bug。
如果还多，根据以往的经验，还没有被发现的bug 更多，所以后面回归要更全面的执行用例。
根据二八定律，要重点测试发现的这些bug 以及相关的模块。
- 你觉得怎么样才能提高测试的效率,，保证测试的质量（开发留给测试的时间特别短，怎么办？）
优化测试用例：
使用比较少的用例覆盖更多测试场景，使用有针对性测试用例。
优化测试流程：
加入测试左移, 提高测试组成员专业技能，掌握代码技术，编写自动化测试代码，在开发进行编码阶段介入测试，使用自动化代码每次代码提交之后进行自动化测试，将测试尽早介入。
测试右移：产品上线之后也要进行线上监控，比如添加线上埋点，监控用户的行为数据，根据用户的数据可以更好设计测试用例，从用户的需求出发。
- 你的未来职业规划。
要看公司的发展，根据公司的需要。如果公司定位我作为一个功能测试人员，那平时我也比较关注一些测试方法，以及测试理论。多注重测试基础，测试思想这块，保证整个软件的质量。
如果公司后期需要功能测试有代码能力，转自动化或者测试开发要求，我平时也有代码基础，我可以后期去更加系统的学习代码编程，将一些公司内部比较稳定的功能测试先转换为自动化测试，方便测试左移。
总之，还是看公司需要。
- 每天可以写多少条测试用例？
具体多少用例还是跟需求相关，需求越多，用例也越多。
我们一般编写用例是从需求评审开始的，
- 根据需求点整理测试点
- 使用等价类，边界值，场景法等编写测试点，以及整理测试用例
- 编写测试用例的时候一般使用Excel工具编写
- 内容主要有 标题，模块，测试环境，前置条件，操作步骤数据，预期结果，是否通过，优先级，备注这些。
一般我就是根据这些来做测试用例的，现在您问我一天能写多少条用例，我也不好说，还是根据需求量来确定。
- 每天可以执行多少条测试用例？
具体执行多少用例，还是要看用例的复杂程度。
我们在写测试用例的时候一般分为 单元测试用例以及系统测试用例。
单元测试用例 一般都是针对单个功能进行正向和反向的测试。相对来说执行起来也很快，比如像登录，我只需关注用户输入信息，比如用户名和密码不同的组合即可。这些用例我可以一天执行很多。
系统测试用例一般更多关注整个流程类的测试，比如像外卖类的应用，测试一个订单的流程用例就需要至少三个账号，在不同客户端平台进行操作，还需要关注每个流程中的每个点，这些用例执行起来比较麻烦，比较复杂。相对这类应用就会少些。
所以，您问我一天执行多少用例，我也不好说具体的数据，只能看是什么类型的用例了。
- 每天可以提交多少条bug？
这个跟开发人员，以及产品的阶段有关。
一般情况下，在项目前期，因为系统没有经过专门的测试，相对bug会比较多。
中期一般系统趋于稳定，一些经常变动的模块bug相对来说比较多。
后期系统整体功能比较完善稳定，一般也就是一些建议性的bug，一些小的功能需要优化的bug。
有些时候，测试很多也没有发现bug，但是这些测试也是必要的。没有发现bug的测试是保证产品质量的重要环节。
- 测试总结中有哪些内容？
本次测试bug的数量，修复的数量，遗留的bug数量。
bug产生的原因。
下次测试活动需要注意的模块（根据二八定律）
也可以是一些用例需要优化的地方，测试流程需要优化（测试左移，测试右移）。
- 上线了，发现bug怎么处理？
严重的bug肯定会影响用户的使用，也有可能会造成公司的财产损失。
根据严重的程度
- 如果影响整个系统运行，可以立即停止系统运行，可以回退到上一个版本，进行紧急修复。
- 如果只是影响到个别模块。针对这个模块可以做服务暂时关闭，进行紧急修复后再上线。
- 如果只是一些小的问题，不影响用户的正常使用，可以留到下个版本修复。
- 热更新和冷更新的区别？
热更新不更新客户端本身，只是根据服务器端的资源进行更新。王者荣耀更新资源包。
冷更新主要更新客户端本身，会替换原来的客户端。
- 埋点测试怎么测试？
大数据测试 中一个比较重要的测试就是 埋点测试。
有效等价类：
功能测试，app在什么地方加的有埋点，测试的时候就做对应的操作，然后去服务器上看有没有对应的记录。
无效等价类：
- 在刷短视频的时候有来电，接打电话的时候 app 不应该算作存留时间 （中断测试）。
- 刷短视频的时候，将手机退回到Home,让app后台运行
- 将手机一直打开 呈现播放状态。
- 手机断电，断网。
- 使用手机管家 进行数据拦截。
通过设计一些不同测试场景查看服务器端有没有收到这些上报事件。
- 谈谈你对软件测试的理解。
可以从软件测试的目的来谈：
测试不仅仅是为了发现bug。通过发现bug 产生的原因和发展趋势，帮助项目管理者更好的优化产品质量。
没有发现bug的测试也是必要的。是保证产品质量的必要环节。
测试人员也应该不断学习，更新测试用例，测试方法，提高软件的质量。
也可以从测试左移，右移来说：
测试人员不应该仅仅局限在开发提测之后才被动的进行测试，要主动与开发沟通，将测试尽早介入，在开发阶段，编写自动化测试代码，开发提交代码进行自动测试，实现测试左移。
上线之后，在线上进行监控，监控用户的操作方式，为后面设计更好的整理测试用例。做到测试右移。
推荐一下 学习代码的网站：
https://space.bilibili.com/306107070
B站/抖音 搜索 用户 ABTester
若有收获，就点个赞吧
0 人点赞
