既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
需求调查：全面了解系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等。根据系统概况进行项目所需的人员、时间和工作量估计以及项目报价。
制定初步的项目计划。
测试准备：组织测试团队、培训、建立测试和管理环境等。
测试设计：按照测试要求进行每个测试项的测试设计，包括测试用例的设计和测试脚本的开发等。
测试实施：按照测试计划实施测试。
测试评估：根据测试的结果，出具测试评估报告。
13、你对SQA的职责和工作活动(如软件度量)的理解?
SQA就是独立于软件开发的项目组，通过对软件开发过程的监控，来保证软件的开发流程按照指定的CMM规程(如果有相应的CMM规程),对于不符合项及时提出建议和改进方案，必要时可以向高层经理汇报以求问题的解决。通过这样的途径来预防缺陷的引入，从而减少后期软件的维护成本。SQA主要的工作活动包括制定SQA工作计划，参与阶段产物的评审，进行过程质量、功能配置及物理配置的审计等；对项目开发过程中产生的数据进行度量等等。
14、说说你对软件配置管理的理解
项目在开发过程中要用相应的配置管理工具对配置项(包括各个阶段的产物)进行变更控制，配置管理的使用取决于项目规模和复杂性及风险的水平。软件的规模越大，配置管理就越显得重要。还有在配置管理中，有一个很重要的概念，那就是基线，是在一定阶段各个配置项的组合，一个基线就提供了一个正式的标准，随后的工作便基于此标准，并只有经过授权后才能变更这个标准。配置管理工具主要有CC，VSS,CVS,SVN等。
15、怎样写测试计划和测试用例
简单点，测试计划里应有详细的测试策略和测试方法，合理详尽的资源安排等，至于测试用例，那是依赖于需求(包括功能与非功能需求)是否细化到功能点，是否可测试等。
16、什么是兼容性测试？兼容性测试侧重哪些方面？
兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。
兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。
兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。
兼容和配置测试的区别在于，做配置测试通常不是Clean OS下做测试，而兼容测试多是在Clean OS的环境下做的。
17、我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题？
–1、检查系统是否有中毒的特征；
–2、检查软件/硬件的配置是否符合软件的推荐标准；
–3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务；
–4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的；
–5、在系统没有任何负载的情况下，查看性能监视器，确认应用程序对CPU/内存的访问情况。
18、测试的策略有哪些？
黑盒/白盒，静态/动态## 标题，手工/自动，冒烟测试，回归测试，公测（Beta测试的策略）
19、你觉得bugzilla在使用的过程中，有什么问题？
–界面不稳定；
–根据需要配置它的不同的部分，过程很烦琐。
–流程控制上，安全性不好界定，很容易对他人的Bug进行误操作；
–没有综合的评分指标，不好确认修复的优先级别。
20、描述测试用例设计的完整过程？
–1、需求分析 + 需求变更的维护工作；
–2、根据需求得出测试需求；
–3、设计测试方案，评审测试方案；
–4、方案评审通过后，设计测试用例，再对测试用例进行评审；
21、单元测试的策略有哪些？
逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析
22、LoadRunner分哪三部分？
用户动作设计；场景设计； 测试数据分析；
23、LoadRunner进行测试的流程?
–1、 熟悉业务流程，测试规划
–2、 创建虚拟用户脚本
–3、 创建运行场景
–4、 运行测试脚本
–5、 监视场景
–6、 分析测试的结果
以上，最好是结合一个案例，根据以上流程来介绍。
24、软件的评审一般由哪些人参加？其目的是什么？
在正式的会议上将软件项目的成果（包括各阶段的文档、产生的代码等）提交给用户、客户或有关部门人员对软件产品进行评审和批准。其目的是找出可能影响软件产品质量、开发过程、维护工作的适用性和环境方面的设计缺陷，并采取补救措施，以及找出在性能、安全性和经济方面的可能的改进。
人员：用户、客户或有关部门开发人员，测试人员，需求分析师都可以，就看处于评审那个阶段
25、Beta测试与Alpha测试有什么区别？
–Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场
–Alpha testing (α测试),是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试
26、你认为做好测试计划工作的关键是什么？
软件测试计划就是在软件测试工作正式实施之前明确测试的对象，并且通过对资源、时间、风险、测试范围和预算等方面的综合分析和规划，保证有效的实施软件测试；
做好测试计划工作的关键 ：目的，管理，规范
（1）、明确测试的目标，增强测试计划的实用性编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
（2）、坚持“5W”规则，明确内容与过程“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
（3）、采用评审和更新机制，保证测试计划满足实际需求测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
（4）、分别创建测试计划与测试详细规格、测试用例应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。
27、你认为做好测试用例工作的关键是什么？
需求和设计文档的理解程度，对系统的熟悉程度
28、简述一下缺陷的生命周期？
提交->确认->分配->修复->验证->关闭
29、软件的安全性应从哪几个方面去测试？
(1) 用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议
(2) 加密机制
(3) 安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描
(4) 数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理
(5) 防病毒系统
30、你觉得软件测试通过的标准应该是什么样的？
缺陷密度值达到客户的要求
31、一套完整的测试应该由哪些阶段组成？
需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进TD）－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）
32、如何理解压力、负载、性能测试测试？
性能测试是一个较大的范围，实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。
压力测试是对服务器的稳定性以及负载能力等方面的测试，是一种很平常的测试。增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。而负载测试是压力相对较大的测试，主要是测试系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。
100个用户对系统进行连续半个小时的访问可以看作压力测试，那么连续访问8个小时就可以认为负载测试，1000个用户连续访问系统1个小时也可以看作是负载测试。
实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行测试。
33、如何编写提交给用户的测试报告？
----根据内部测试报告进行编写，一般可以摘录；
----不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道；
----报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的；-报告上面的内容尽量要真实可靠；
----整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告。
34、您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
1 ．等价类划分
划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
2．边界值分析法
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
3．错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
4．因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
35、你对测试最大的兴趣在哪里？为什么？
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
.(img-wIWmAk8w-1715493861812)]
[外链图片转存中…(img-CXf1m3ME-1715493861813)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
571
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
