软件测试的基本概念
1.什么是软件测试？ 这样做的目的是什么？ 您对软件测试有何看法？
2.什么是软件测试的生命周期？ 每个阶段对应的任务是什么？
3、测试计划和测试计划的内容和区别是什么？
4、需求评审的内容是什么？ 参与者？ 为什么测试人员应该参与需求评审？
5. 测试用例的设计方法有哪些，对应哪些典型业务功能？
6. 缺陷级别和管理流程是什么？
7. 考试录取和通过的标准是什么？
8. 测试机型有哪些？
9. 如何保证测试覆盖率？ 测试用例评审方法、如何组织、为什么需要评审、评审内容？
10.敏捷模型？ 瀑布模型？
11、检测报告的内容是什么？
12、测试中发现不可重现的缺陷怎么办？
13. 测试流程是怎样的？
14、检测方法有哪些？
15. 测试有哪些类型？
16. alpha测试和beta测试有什么区别？
17.什么是敏捷测试？ 什么是探索性测试？
18、V型和W型有什么区别？
19. 什么是在线？ 你以前上班是怎么上网的？
20. 测试用例的内容是什么音效，优先级定义，如何编写？
21.如何测试水杯？
22、需求拆分时需要注意什么？
26. scrum 模型中有哪些特殊术语？
27. 如何对自己熟悉的游戏进行简单的分析和测试？
28.如何搭建测试环境？
29、app和web的测试环境有什么区别？
30. 系统工程的组成是什么？
31.如何构建测试数据？ 测试数据（接口测试内容）的构造方式有哪些？
32、如何确认测试数据的正确性？
33. 你们的测试和开发环境是否相同？ 如果是这样，如何保证测试结果不受影响？
40.如何提交高质量的缺陷记录？ （缺陷报告包含哪些内容？）
软件测试的基本概念 1.什么是软件测试？ 这样做的目的是什么？ 您对软件测试有何看法？
它是执行程序以检测错误的过程。 软件投入运行前对软件需求分析、设计规范和编码的最终审查是软件质量保证的关键步骤。
目的是暴露程序中的错误。 发现测试对象与期望之间的差异。 具体来说，不同的测试阶段对应不同的测试目的。
软件测试工作者应该站在用户的角度思考问题，根据用户的实际使用环境和习惯来验证被测对象的应用性能。 与软件开发的创造性思维不同，软测试活动的思维方式是破坏性的，通过构造正常和异常输入来测试被测对象的鲁棒性。 测试是一项极其重要的质量保证活动。 因为测试部门是软件发布质量控制的出口，也可能是用户反馈的入口。
2.什么是软件测试的生命周期？ 每个阶段对应的任务是什么？
测试周期是指从测试项目计划建立到提交BUG的整个测试过程，包括软件项目测试计划、测试需求分析、测试用例设计、测试用例执行、BUG提交五个阶段。 软件测试周期与软件生命周期并行，存在于软件生命周期的各个阶段。
需求分析阶段：测试人员了解需求，分解分析需求，导出测试需求。
测试计划阶段：根据需求编写测试计划/测试方案。 确定测试范围、测试通过标准、测试时间、人力、物力、资源、风险等，输出测试计划文件
测试设计和测试开发阶段：测试人员根据需求和设计构建测试用例框架并编写一些测试用例。 输出测试计划文档。
测试执行阶段：测试执行阶段是软件测试人员最重要的工作阶段。 测试是根据测试用例和计划执行的。
测试评估阶段（BUG提交）：记录并管理执行过程中的缺陷。 测试完成后，撰写测试报告并进行测试评估。
3、测试计划和测试计划的内容和区别是什么？
测试计划确定测试范围、测试通过标准、测试时间、人力、物力、资源、风险等；
测试计划确定测试方法和类型； 确定用例设计方法、缺陷管理流程； 缺陷严重程度划分、用例格式等
测试计划一般由测试经理、测试主管或项目测试负责人制定。 它们是管理文档，解决要做什么的问题。 测试计划是由测试工程师设计的，是解决如何做问题的技术文档。
4、需求评审的内容是什么？ 参与者？ 为什么测试人员应该参与需求评审？
内容：同步产品需求的详细设计，收集大家对需求的各种反馈。
参与人员：产品、设计、研发、运营、测试等岗位人员
亲自同步需求，反馈需求的合理性、全面性。
5. 测试用例的设计方法有哪些，对应哪些典型业务功能？
等价类划分
边值分析
决策表驱动分析
因果图
场景设计
错误猜测
6. 缺陷级别和管理流程是什么？
致命（Uregent）：主进程无法运行，系统无法运行、崩溃或业务中断，应用模块无法启动或异常退出，主要功能模块无法使用。 例如：1.内存泄漏； 2、数值计算错误严重； 3、系统容易死机； 4、功能设计严重不符合要求； 5、系统无法登录； 6、循环报错，无法正常退出。
严重（非常高）：影响系统功能或操作。 主要功能存在严重缺陷，但不影响系统稳定性。例如： 1、功能未实现； 2、功能有错误； 3.数值存在轻微计算误差
中：接口和性能缺陷。例如：1、边界条件下的错误； 2、容错能力差； 3、大数据下容易反应迟钝； 4、大数据操作时不提供进度条
提示（低）：易于使用和咨询问题。 例如： 1、界面配色不好； 2、文字排列不整齐； 3、出现错别字，但不影响功能； 4、接口格式不规范。
1、测试人员填写Bug并（分配）给测试负责人，状态为New；
2、测试负责人的缺陷（回顾）。 主要检查报告规范并确认错误。 如果是有效的 bug，则状态更改为打开并分配给开发人员； 如果 bug 无效，则将其分配（Assign）回测试人员，并且 bug 状态保持新状态。
3、开发者根据缺陷描述确认是否为缺陷，如果是则进行修复。 修改完成并进行单元测试后，将bug状态更改为已修复，并在注释中说明修改方法，并分配给缺陷发现者。 如果不是缺陷或延迟修改，请将错误状态更改为“已拒绝”并在注释中注明原因。
4、每天检查自己提交的Bug的状态变化应该成为每个测试人员的常规行为；
5、当bug的状态变为fixed时，测试人员打开bug，开始对该bug进行回归测试； 如果错误回归测试通过，状态将更改为已关闭。 否则，该bug的状态变为重新打开（必须说明重新打开和关闭状态更改的原因或操作流程）；
6. 如果测试人员重新确认（Reject）后认为该缺陷为缺陷，则需要将该缺陷（Reopened）给开发人员并注释原因。
7. 如果回归测试通过，但修改过程中引入了新的Bug，则重新提交Bug，状态为新。 如有必要，请注明相关的错误编号；
8、只有所有Bug状态关闭后才能发布版本。
注意：每当bug状态发生变化时，必须给出相应的注释和说明，以便查看bug生命周期的变化。
7. 考试录取和通过的标准是什么？ 开发人员已完成编码并完成单元测试。 需求说明书中规定的功能或开发者提交的功能说明书中的功能已通过冒烟测试，接口上的功能已实现并符合设计文件中规定的功能。 开发人员向测试部门提交“测试应用程序”，以实现所有正在执行的 1 级和 2 级用例的 100% 覆盖。 3级用例执行率达到95%，4级用例执行率达到80%。 1级和2级缺陷100%修复。 ，3级修复95%游戏设计报告初稿，4级修复60-80%。具体缺陷问题需要与用户沟通确认。 8. 测试机型有哪些？
缺点包括：测试介入较晚，滞后于研发。 如果早期发现问题，维修成本非常高； 不利于需求变化； 用户只有在项目交付时才能看到成品。
缺点：需求、设计和编码等活动被认为是串行的。 同时游戏设计报告初稿，测试和开发活动也保持着线性关系。 只有前一阶段彻底完成后，才能正式开始下一阶段的工作。 这无法支持迭代开发模型。 对于当前软件开发复杂多变的形势，W模型并不能缓解测试管理面临的困惑。
解决发展滞后问题
缺点：管理要求高，需要明确每次迭代的规模，测试准备点分析困难
9. 如何保证测试覆盖率？ 测试用例评审方法、如何组织、为什么需要评审、评审内容？
测试覆盖范围：
测试需求分析必须全面2d素材，并且必须进行测试需求评审以确保其准确性和完整性。 在设计测试需求的用例时，采用测试用例设计方法：首先划分等价类，必须结合边界值分析方法。 你可以使用 error 推测的方法来添加一些测试用例。 应根据具体情况选择其他设计方法。 用例设计完成后，必须召开用例评审会议。 在用例执行过程中，必须保证用例100%的覆盖率。 测试用例必须不断补充和完善，以确保测试覆盖率的提高。 测试过程中，应及时更新测试需求和测试用例。 测试需求、测试用例和发现的bug应该关联起来，以便于管理和跟踪，建立需求跟踪矩阵，并方便查看覆盖范围。
10.敏捷模型？ 瀑布模型？
详情见问题8
11、检测报告的内容是什么？
检测报告的内容可概括为以下几类：
· 首页：标题（报告名称+测试范围）、日期、版本变更历史等。
· 引言：目的、背景、缩写、参考文献
· 测试总结：测试方法（黑盒、白盒）、范围（测试用例设计）、测试环境、工具
· 测试结果及缺陷分析：功能、性能（覆盖率分析、缺陷曲线图等）
· 测试结论和建议：项目概述、测试时间和测试情况、结论和性能总结
· 附录：缺陷统计
12、测试过程中发现不可重现的缺陷怎么办？
不可重现性的主要原因包括：测试环境不一致、测试配置不一致、内存泄漏、数据接口不一致等。
解决方案： 1、测试环境配置充分详细：严格检查需求，充分考虑环境变化。 另外，您还可以使用Ghost对硬件或某个分区进行镜像备份。
2、捕获系统日志并分析异常信息：测试人员应该养成记录系统错误日志的习惯，以便在发生错误时保留系统的真实状态。 例如，将 IE 浏览器高级选项设置为“显示每个脚本错误的通知”。
3、监控系统状态并及时报警异常：系统运行监控的一个重要内容是需要及时反馈系统运行异常情况并提供异常报告。
4、测试数据详细、易于追溯：在开始软件测试之前，必须开发完整的测试用例，辅以详细的测试数据，并且必须明确定义测试数据的操作步骤以及每个步骤的预期结果。 这样，当软件出现问题时，方便复现和定位。
13. 测试流程是怎样的？
即是测试周期，详细见问题2
14、检测方法有哪些？
黑盒测试：只关注输入和输出，不关注内部逻辑。 它是基于需求规范的功能测试。 主要验证被测物的质量和外部特性（功能、性能、接口）。
白盒测试：只关注代码的内部逻辑结构。 它是结构测试和逻辑驱动的测试，是基于程序代码内部结构的测试。 白盒测试常用于单元测试。
灰盒测试：重点关注模块之间、白盒与黑盒之间的数据交互。 同时考虑被测对象的外部特征和内部结构。例如关注日志的集成测试、性能测试和自动化测试
基于风险的测试：指评估测试的优先级。 在测试时，应首先进行高优先级的测试。 如果时间和精力不足，可以暂时跳过低优先级的测试。 对于用户很少使用的功能，出现问题的概率很小。 即使出现问题，影响也不会很大，可以考虑不测试。
基于模型的测试：是指用语言来描述系统的行为，从而定义其可能的形式以及形式之间的转换关系，即状态转移图。
15. 测试有哪些类型？
功能测试：也称为黑盒测试，是主要验证软件业务需求是否实现的测试活动。 意思是为了让用户更容易理解。
主要检查被测对象是否存在以下三类错误： 1、是否存在功能错误、缺失或冗余。 2、是否满足用户需求以及系统设计的隐藏需求。 3、能否正确响应输入，能否正确显示输出结构。
性能测试：利用自动化测试工具模拟各种正常、峰值和异常负载情况，测试系统的各项性能指标。
负载测试和压力测试都是性能测试，两者可以结合起来。
意义在于，现实情况下资源总是有限的。目的是验证系统是否具有声称的能力
通过负载测试，确定系统在各种负载下的性能。 目的是测试负载逐渐增加时系统各项性能指标的变化。 压力测试是确定系统的瓶颈或不可接受的性能点以获得系统可以提供的最大服务水平的测试。
主要关注CPU、内存、读写（响应速度、并发数、业务成功率、资源占用率）
接口测试：接口是软件和用户之间最直接的一层。 界面的好坏决定了用户对软件的第一印象。
此外，还有兼容性测试、安全测试、可靠性测试、可用性测试、移植测试、维护测试、确认测试、回归测试等。
16. alpha测试和beta测试有什么区别？
两者都是验收测试，都是以用户为中心、让用户参与的。
Alpha测试：在开发环境中进行，测试环境受控，开发现场
Beta测试：在实际使用环境（生产环境）进行，测试环境不受控，开发也不存在
17.什么是敏捷测试？ 什么是探索性测试？
敏捷测试：是适应敏捷方法而采用的新的测试流程、方法和实践。 它对传统的测试流程进行了剪裁，侧重点有所不同，比如减少了测试规划、测试用例设计等工作的比重，增加了与产品的联系。 设计师和开发人员之间的沟通与协作。 在敏捷测试过程中，参与单元测试，关注不断迭代的新功能，并对这些新功能进行充分的验收测试，而原有功能的回归测试则依赖于自动化测试。 由于敏捷方法迭代周期短，测试人员尽早开始测试，包括及时评审需求和开发设计，更重要的是，可以对软件产品的质量提供及时、持续的反馈。简单来说，敏捷测试就是对软件质量问题持续及时的反馈。
探索性测试：强调测试过程中更加发散的思维，放弃复杂的测试计划和测试用例设计流程，强调遇到问题时及时改变测试策略。 对用户故事测试和自动回归集的一个很好的补充。 由于没有测试脚本，因此您可以将测试扩展到显然已经测试过的各种场景之外。 发现测试将学习、测试设计和测试执行集成到一种测试方法中。 探索性测试的最大特点是在测试测试对象的同时学习测试对象并设计测试，并利用测试过程中获得的有关测试对象的信息来设计新的、更好的测试。 基本流程如下（链接之间没有绝对的顺序）：
确定软件系统的用途；
识别软件系统提供的功能；
识别软件系统中潜在不稳定的区域；
在探索软件系统时记录有关软件的消息和问题；
创建测试模式并使用它来执行测试。
18、V型和W型有什么区别？
v模型：测试通常在开发过程的后半段添加。 测试对象只是程序本身。 前期面向方案，后期面向用户。适合工程量较小、人力投入较低的情况
w模型：测试和开发同时进行。 测试对象除了程序之外，还包括需求、设计等。
19. 什么是在线？ 你以前上班是怎么上网的？
上线：软件已具备正式制作的全部条件，已完成发布工作
流程：上线前准备： 1.确定上线策略（上线顺序、修复数据策略、旧数据分析）
2.撰写在线申请邮件（数据配置、在线注意点）
3、配置线上环境数据
在线：一般只有少数人有权限上网，所以在线人数是固定的。 上传代码时，需要先停止线上环境下的作业。 我们也使用Jenkins进行自动化部署，但是需要手动版本号和标签。 、部署版本、停止Djob任务、完全上线后启动Djob任务等。
上线后：1.灰度测试
2.监控在线数据
全文链接：测试软件之前和之后需要做什么？ - 知道得差不多了
示例：项目启动流程-知乎
20. 测试用例的内容是什么，优先级定义，如何编写？
内容：
+ 用例编号（用例 ID）
+ 通用系统-测试级别-模块-001 --- 示例：CRM-ST-客户管理-新客户-001
+ 测试标题（用例标题）----验证XXXX通过/失败---肯定语气
+ 测试项目（属于哪个模块）
+ 用例属性（测试类型）——通常是功能测试
+ 重要性级别（优先级）---- 1-4 或非常高-高-中-低
优先级定义：
+ 极高----烟雾（主要业务流程）
+ 高 ---- 流程类型，稍微重要的流程
+ Medium ---- 通用流程，可能在界面中比较常用
+ 低 ---- 界面异常情况，或者很少出现的情况
怎么写：
1、功能模块划分
2、转发功能验证：是否实现正常操作功能
3、单功能项验证：转发+异常
4、功能之间的交互验证：模块之间的数据传输
5、隐性需求：熟悉业务
+ 只要涉及到输入框，都是先输入空。
+ 一个用例仅测试一个功能点
+ 测试正常和异常情况时遵循28点原则
+ 操作步骤与预期结果一一对应
+ 如果有多个条件，实际测试时，默认满足其他条件。
+ 在为模块编写用例时，首先浏览一下该模块的整体业务。
+ 在编写接口的用例时，可以先给页面一个接口的用例----对于有接口原型的人
+ 优先级高的一般只占该模块的5%左右。
21.如何测试水杯？
查看水杯上的说明。 如有必要，请充分阅读并理解水杯上的说明。 按照说明进行操作并测试所有要求。
根据测试重点，主要分为以下几个方面：
功能测试：
