既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
2.9 怎么转行的，毕业之后一直从事软件测试吗
非专业
1、培训，不要说刚培训出来 2019 年底开始
2、自学，不断一直学习
3、家里有关系，带你入行，后面学习过程很勤奋
计算机相关专业
1，实习开始，公司分配到做测试，做测试过程，比较喜欢测试，一直做下来
2.10 以前在哪里上班，公司地址，测试多少人，开发多少人
根据你简历上面写的，公司详细地址
产品 1、项目 1 个、架构师 1 个、前端 3 个、后端 5 个、0os 1 个、Android 1 个，
测试 3 个(测试主管，核心测试人员)、运维 1 个、ui 1 个
2.11 你的期望薪 资是多少? ?
1，期望薪资不要说区间比如说：6-8，那肯定是 6
2，如果原来公司在二线城市原有薪资不要说太高，
3，深圳那边薪资，比广州高 10% - 15%
2.12 多久能入职? ?
1，公司比较满意，直接随时过去。
2，不是很满意，下周一，个人有点事情，比如说回家一趟等等。
2.13 是怎么考虑做软件测试呢? ?
1、个人性格合适 2、前景还可以 3、个人技能也匹配
2.14 是否有考虑往开发方面测试? ?
我觉得，IT 行业，没有具体的界限，后期，开发也要懂测试，测试也要懂开发，
如果公司有机会，愿意去尝试
2.15 计算机专业课程有哪些? ?
公共课程：数学(高等数学、线性代数、概率论与数理统计、离散数学、数值分析)，
政治(马克思主义思想概论、毛泽东思想概论与中国特色社会主义思想、
思想道德修养与法律基础、中国近现代史纲要)、大学英语、体育。
专业基础课程：电路原理、模拟电子技术、数字逻辑、微机原理、汇编语言、操作系统原理、
编译原理、算法与数据结构、面向对象方法、C 语言/C++语言等。
专业方向课程：计算机数据库原理、python 语言、图形学、人工智能，多媒体技术、
网络安全、人机交互、无线互联网技术、软件开发方法、高性能技术系统仿真和虚拟现实等。
大专 3 年、本科 4 年，
本科四级、大学英语四级及格 425 分、总分 710
2.16 说一下上一个公司背景? ?
了解公司主要是什么项目，百度查下，
如果公司主营产品跟你项目不匹配
比如：原来公司做医疗设备，那就说：我们是项目外包的部门，专门接项目
2.17 超过 6 26 岁女孩子，目前有没有打算结婚
暂时没有结婚的计划与打算，如果已经有小孩，说暂时不考虑二胎，
有小孩，可以说小孩在老家(原来有学员因为这个问题，被公司 pas 过)
三、测试理论 论
3.1 你们原来项目的测试流程是怎么样的? ?
我们的测试流程主要有三个阶段：需求了解分析、测试准备、测试执行。
1、需求了解分析阶段
我们的 SE 会把需求文档给我们自己先去了解一到两天这样，之后我们会有一个需求澄清会议，
我们会把不明白不理解的需求在会议上说出来，包含需求的合理性还有需求的可测性等，
产品这边解答，目的是让我们测试这边和开发对需求的理解达到一致。
2、测试准备阶段
会议结束之后我们开始准备测试工作，我们测试这边会写一个测试计划，分配每个人负责的模块，
然后我们就根据自己负责的模块用 xmind(思维导图)进行测试需求分析，分析测试点，
以及编写测试用例，之后我们会在自己的组内先进行评审，评审修改之后还会在我们的项目组评审，
评审完后进行修改测试用例。
3、测试执行阶段
开发人员编写好代码之后，我们会把代码包通过 Jenkins 部署到测试环境提测，进行 SIT 测试，
在正式测试之前我们会先做一个冒烟测试，冒烟测试通过之后我们才转测，在执行测试的过程中，
我们如果发现 bug 就会用 tapd(或者禅道)记录并且提交 bug，也会进行 bug 复测，以及回归测试，
每一轮测试结束之后我们都会写一个测试报告，一般情况下，测试 4-5 轮之后会达到上线要求，
当达到上线的标准后，测试报告会认为测试通过，上线前我们会做预发布测试，预发布通过后，
由项目组与产品决定时间上线，上线完成，一周左右我们会写一个项目总结测试报告，
总结我们在上一个版本中遇到的问题以及今后有哪些地方需要改进，在产品选代过程中，
我们会跑自动化用例来进行回归测试。
3.2 如果需求不明确的话你怎么办? ?
需求不明确的话我会在需求澄清会议上面提出来，问清楚这个需求只有明确需求，
才能更好的完成工作，后续工作中还是不清楚，可以找产品再去确认这个需求。
3.3 有哪些需要评审，哪些人在
1、 xmind 思维导图评审，主要是测试人员
2、测试用例需要评审，测试人员，开发人员，产品人员
3、需求文档，项目组所有的人员，都会到场
3.4 有没有写过测试计划，具体包括哪些内容? ?
参考答案 1：
测试计划内容：
(1)目的和范围 (2)规程 (3)测试方案和方法 (4)测试的准入和准出
(5)测试计划(流程、时间安排、对应人员) (6)测试的环境配置和人员安排 (7)交付件
参考答案 2
我们公司之前按照考核要求写过测试计划，不过后面老大觉得太耽误工作进度，
后面一般都不再写测试计划，而是写版本计划，这个在版本计划，每个人的任务列出来，
负责人列出来，自己根据自己的情况分配时间，然后汇总，大家一起开个小会评审就可以了。
3.5 用例包含哪些部分，哪些用例设计方法，你一般常用哪些方法? ?
原来我们用例包含
测试项目，用例编号、测试标题、优先级、预置条件、操作步骤、测试数据、预期结果
黑盒测试用例设计方法：主要是等价类、边界值、错误推测法、判定表、因果图、正交表、
流程分析法、状态迁移法、异常分析法。
常用的：等价类、边界值、判定表、流程分析法、错误推测法。
等价类是指某个输入域的子集合，在该子集合中，
各个输入数据对于揭露程序中的错误都是等效的，
并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此，可以把全部
输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，
就可以用少量代表性的测试数据取得较好的测试结果，
等价类划分可有两种不同的情况有效等价类和无效等价类。
边界值的话就是对等价类划分方法的补充。测试工作经验告诉我，大量的错误往往是发生在输入或输
出范围的边界上而不是发生在输入输出范围的内部，因此的话针对各种边界情况来设计测试用例，可
以查出更多的错误，使用边界值分析方法设计测试用例的话，首先应该确定边界情况，通常输入和输
出等价类的边界，就是应着重测试的边界情况应当选取正好等于，刚刚大于或刚刚小于边界的值作为
测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
对于错误推断法，这个是基于经验和直觉推测程序中所有可能存在的各种错误，
从而有针对性的去设计测试用例的方法的，主要就是列举出程序中所有可能有的错误和容易发生错误
的特殊情况去根据这些情况来选择测试用例，例如，在单元测试时曾列出的许多在模块中常见的错误
以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为 0 的情况。
输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况，可选择这些情况下的例子作为
测试用例。
前面介绍的等价类划分方法和边界值分析方法都是着重考虑输入条件但都没有考虑输入条件之间的
联系，相互组合等等的情况。考虑输入条件之间的相互组合，可能会产生一些新的情况，
但是要检查输入条件的组合并不是一件容易的事情，即使把所有输入条件划分成等价类，
他们之间的组合情况也相当多，因此的话可以考虑采用一种适合于描述对于多种条件的组合，
相应产生多个动作的形式来考虑设计测试用例，这就需要用到因果图(逻辑模型)。
因果图方法最终生成的就是判定表它适合检查程序输入条件的各种组合情况。
3.6 TestLink 工具使用? ?
(1)创建用户，并给新创建的用户指定权限。
(2)创建测试用例，对测试用例进行增、删、改、查
(3)把测试用例关联到对应的测试计划中。
(4)把测试用例指派给对应的测试人员。
(5)对应的测试人员，查看被指派的测试用例，并执行测试用例。
3.7 如何提交一个好的 BUG
对 BUG 有一个清晰明了的描述； 详细描述 BUG 重现的步骤
对于产生 BUG 的环境进行描述； 提交 BUG 相关的图片和日志;
定位好 BUG 的等级； 将预期结果与实际结果进行对比。
3.8 提 提 g bug 需要注意哪些问题? ?
- 不要急着提交，先跟开发说明 bug 的情况，定位分析下 bug。
是前端问题还是后端问题再去提交 bug。
- 简单明了的概括 bug 标题，清晰的描述 bug 重现步骤，分析 bug 和预期正确结果，附加 bug 的截
图或者日志。描述 bug 的时候。
-
在不能确认该情况是否为 bug 的时候，可以请教其他人。
-
提交完 bug 以后，后面还要跟踪 bug 修复情况。
g 3.9 bug 怎么管理的，g bug 的生命周期或者是 g bug 的状态
原来 bug 是用禅道来管理的
原来我们公司 bug，提交 bug 直接给对应的开发人员，对应开发人员修复完成，交给测试复测，
复测通过关闭 bug，不通过打回给对应开发。
提交-开发人员(已激活未确认)-开发进行确认，状态变成已激活，已确认，开发修复完成，
标注状态是已修复，测试人员复测通过，已关闭，打回给对应开发，已经激活。
3.10 提交 g bug 包含 哪些内容
所属产品、所属模块、所属项目、影响版本、指派人员
截止日期、严重程度、优先级、bug 类型、bug 环境
Bug 标题、重现步骤、附件
3.11 你提交的 bug ，开发不认可怎么办? ?
首先我会再看需求文档，是不是我的理解有误，如果是我对需求理解错的话我就去关闭 bug。
如果是 bug 再去让其他测试人员看看听下他们的意见，然后自己先再三去复测，并目保存好截图和日
志，确定这是一个 bug 之后我就去跟开发说明白，并且给他看 bug 重现的截图以及日志，如果开发还
是不认可的话我就跟产品或项目经理说明白情况。
3.12 对 应无法重现 bug ，应该怎么处理? ?
首先，我会多测几次，测了好多次都无法重现的话我就先把 bug 挂起，并且留意一下，看看往后的测
试中，如果在后面的测试中重现 bug 就激活，如果经过几个版本都还没发现的话就关闭 bug。
3.13 界面中的乱码可以是哪里导致的? ?
(1)数据库中的编码设置 (2)前端页面编码 (3)后台代码也会编码
3.14 bug 的级别有哪些，级别如何判断
1、致命：对业务有至关重要的影响，业务系统完全丧失业务功能，无法再继续进行，
或业务系统丢失了业务数据且无法恢复，影响公司运营的重要业务数据出错。
2、严重：对业务有严重的影响，业务系统已经丧失可部分的重要的业务功能，或业务系统
丢失了业务数据且可以恢复，一般业务数据出错。
3、一般：对业务有较小的影响，业务系统丧失了较少的业务功能，
例如：界面错误，打印或显示格式错误。
4、提示：对业务没有影响，不影响业务过程正常进行，
例如：辅助说明描述不清楚，提示不明确的错误提示。
3.15 测试中，如何判断是前端的 g bug 还是后端的 g bug 呢? ?
通常可以利用抓包工具来进行分析。可以从三个方面进行分析：请求接口、传参数、响应。
1）请求接口 un 是否正确如果请求的接口 ur 错误，为前端的 bug
2）传参是否正确如果传参不正确，为前端的 bug
3）请求接口 u 和传参都正确，查看响应是否正确如果响应内容不正确，为后端 bug
4）也可以在浏览器控制台输入 js 代码调试进行分析
3.16 项目上线后发现 bug ，测试人员应该怎么办
看严重级别：严重还是不严重
严重的：紧急变更上线
不严重：修复好后跟下个版本一起上线
用户会通过运维反馈到项目组这边，项目经理会根据功能模块的负责人，分给对应的开发与测试。
测试人员：编写对应的测试用例、测试环境中重现 bug、提交 bug、
交给开发进行修复、修复完成 bug、进行 bug 的复测。
如果测试环境无法重现，可以导入生产环境的包到测试环境中测试，
还是不能复现，查看生产环境的日志去定位问题。
3.17 如何保证质量
(1)需求要吃透，多问，多去了解。
(2)严格按照测试流程去执行：多考虑用户测试场景，使用测试用例设计方法，多评审。
(3)要有良好的测试执行：要求用例执行率达到 100%，多轮测试，进行探索性测试，
需要测试之间交叉测试，用工具来管理我们的测试工作(禅道， testlink， excel，tapd)
(4)不断的反思与提升。
3.18 产品是怎么上线的? ?
一般我们会选择晚上上线，开发测试还有产品全部到场，进行上线测试。
首先，开发将代码打包到生产环境的服务器中，如果数据表有变化，就会运行 sql 文件，
对表的一些操作，接着，我们测试就开始先测试主体业务功能以及新增的功能模块;
测试通过之后，我们会在界面上把上线测试的数据删除，正常上线。
如果发现 bug，开发人员当场修复 bug，修复成功之后我们测试再复测，通过就可以正常上线
如果发现了 bug 开发人员在上线规定时间之前都还没有修复好的话，就看问题的严重性，
如果严重就延期上线，如果我们是迭代版本的话我们还需要版本回滚。
如果不严重，产品跟客户觉得可以上线，就正常上线。
3.19 你测试数据是从哪里获得? ? 怎么获得的，假如不告诉你，你怎么处理? ?
(1) 一般都是我们测试人员在测试过程自己造的测试数据，如果大量数据，我们可以用到存储过程。
(2) 也可以让运维人员帮忙从生产环境导出相关的测试数据，如果测试数据中涉及安全性的数据，
直接是不能导出。
3.20 如何测试万分之一概率问题
-
用 Jmeter 或者其他自动化测试工具造大量数据
-
让开发修改概率的比例
3.21 为什么要写测试用例? ?
1)提高测试效率 2)提高测试覆盖率 3)监控测试进度情况 4)也是质量的标准指标
CMM 质量体系(用例数也是一个度量标准 QA 岗位)
3.22 那你们测试用例是怎么编写的
原来我们主要是用 exce 编写的，当然也用过用禅道， testlink 去编写，禅道都是 excel 表格编写
完成，导入禅道系统， testlink 也可以 Exce 表格，编写，编写测试，导入 testlink
3.23 有没有写过测试报告，具体包括哪些内容? ?
参考答案 1：
1)项目背景和目的 2)测试用例设计 3)测试环境 4)测试过程用到的工具
5)测试范围 6)测试用例执行情况 7)测试缺陷分析和总结 8)测试结果
参考答案 2：
这个是写过的，测试报告，其实就是把我们测试的整个过程情况，数据统计，做成报告，包括用例执
行情况，测试了哪些模块，多少用例，会哪里模块，自动化通过率，自动化跑了多少，是否全部通过，
发现了多少 bug，bug 的情况，是否遗漏 bug，测试结论等等这些，基本就这些。
3.24 测试报告中测试的结论是什么? ?
测试报告里面有个测试结论：
1）bug 的情况、bug 级别、bug 分布情况(分布哪些模块)、
bug 产生原因(设计问题，需求问题，代码问题)
2）测试是否通过
3.25 如何写好一个测试用例
能够发现 bug 的用例就是一个好的测试用例
当然我们在编写测试用例的时候，一定要步骤、场景清晰、尽量去覆盖所有的测试场景
3.26 什么是冒烟测试 ? 在什么时候进行冒烟测试? ?
冒烟测试一般我们是在系统测试之前，对所有主体的业务功能，测试看是否存在严重 bug，
如果存在严重 bug，表示，冒烟测试不通过
3.27 回归测试策略
1）功能的回归
优先测试用例级别比较高的功能模块，可以进行自动化测试
如果时间够，进行全量测试
2）bug 回归
复测这个 bug，并且相关联的模块与功能也会测试一遍，以免由于修改 bug 导致其他问题产生
3.28 和开发沟通。是怎么沟通的
一般我在提 bug 的时候跟开发沟通最多，比如有一些不清晰的内容会去问开发，还有提完 bug 后会跟
踪 bug 的进度，提醒开发尽快修复 bug，还有测接口的时候去找开发拿接口文档，其实我们的工作跟
开发都是息息相关的所以都经常都会有沟通的。
3.29 测试中有哪些风险
1）测试，需求理解上面有偏差
2）测试人员水平不够，测试人员覆盖点不全
3）测试人员时间不够，导致测试不完全
4)测试环境上面不足，导致测试点不能完全测试完成
3.30 怎么保证测试质量或者你怎么保证你 100% 覆盖了需求
把需求了解通透，引用用例评审机制，然后编写测试用例的时候用边界值，用等价类补充一些用例，
根据过往经验用错误推断法来追加一些用例，如果存在组合情况的话我会用因果图或者判断表来编写，
如果业务场景清晰的情况下我会用流程分析法，如果状态有发生改变的话我就会用状态迁移法。编写
用例一个极其考验耐心的事情，要考虑到各种场景，全面覆盖到会出现的场景。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
有沟通的。
3.29 测试中有哪些风险
1）测试，需求理解上面有偏差
2）测试人员水平不够，测试人员覆盖点不全
3）测试人员时间不够，导致测试不完全
4)测试环境上面不足，导致测试点不能完全测试完成
3.30 怎么保证测试质量或者你怎么保证你 100% 覆盖了需求
把需求了解通透，引用用例评审机制，然后编写测试用例的时候用边界值，用等价类补充一些用例，
根据过往经验用错误推断法来追加一些用例，如果存在组合情况的话我会用因果图或者判断表来编写，
如果业务场景清晰的情况下我会用流程分析法，如果状态有发生改变的话我就会用状态迁移法。编写
用例一个极其考验耐心的事情，要考虑到各种场景，全面覆盖到会出现的场景。
[外链图片转存中…(img-F4wjoGLt-1715286836343)]
[外链图片转存中…(img-n2vIlevh-1715286836343)]
[外链图片转存中…(img-fMPisoiE-1715286836344)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
扫一扫
8万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
