1、软件测试的理解、软件测试的重要性、软件测试在软件生命的地位、软件测试的意义、为什么选择软件测试这个行业
软件测试主要是为了保障软件的质量，质量保证在生活中是随处可见的。有了软件测试这一阶段，可以验证软件是否符合需求说明书、设计文档，可以为软件的质量提供评估依据，同时也能找出软件的缺陷，改进开发流程，降低软件缺陷风险
所以我认为软件测试是软件生命周期不可或缺的一环
2、软件测试流程
需求分析、评审--负责人编写测试计划--测试员编写测试用例--评审测试计划--评审测试用例
--搭建测试环境--执行测试--发现bug就提交bug，bug完成闭环--回归测试--完成测试，统计测试用例执行的结果，编写测试报告--bug汇总分析，各个等级的bug如果都关闭--测试负责人评估是否可以发布版本
3、 常见测试工具
postman：接口调试，一般用于初级人员接口测试
jmeter：接口和性能测试
软件缺陷管理平台：JIRA、禅道
fiddler：抓包工具
4、设计功能测试用例的方法、黑盒测试方法
等价类：有效等价和无效等价类
边界值：假设输入框规定1-10位数一下，边界值为0、1、5、10、11
因果图：程序输入为因，程序输出为果，不同条件不同结果
判定表：条件组合多，输出结果也多时使用。确认所有条件以及对应结果，列出所有条件以及结果，填入输入输出，合并规则减少冗余
场景法：根据事务的正确流程得到正确结果称为基本流，其他阻塞或故障情况称为备选流
正交排列：用于情况特别多的情况，选出一部分情况来代表统一水平
可使用正交设计助手，https://www.jb51.net/softjc/628400.html
错误推测：凭借以往的测试经验、对业务的理解来推测可能出现bug的地方
5、如何进行需求分析、怎么快速理解需求、你对需求有疑问时如何处理
根据产品经理下发的需求说明书文档，熟悉并通读一遍，根据自己的理解编写XMind，如果条件允许可以借开发人员的开发环境进行适当的操作，对需求不清楚、有疑问、有歧义、感觉不符合用户操作、有遗漏、不完整的先记录，在需求评审会议上提出，根据产品经理的答复，达成需求理解一致
需求评审的的目的：为了检查是否有需求遗漏、需求错误、需求冗余，最后产品、研发、测试三方需求理解一致
6、测试计划的内容
概述：此次测试的目的及相关项目文档
测试范围或对象：测试项目的版本模块，系统架构、组网图
测试资源需求：人力、软硬件资源
测试排期：每个测试活动的时间安排
测试准入准出条件：测试项目的启动、暂时挂起、停止的准则
测试用例执行规则：测试用例失败、成功、阻塞blocked、WIP的规则，回归测试的规则
测试策略：设计测试用例使用的测试方法、规定测试优先级
测试风险分析：预判测试可能出现的风险以及如何解决风险
测试交付：什么时候提交测试计划
7、测试用例的内容
编号、标题、版本、模块、前置条件、测试数据、测试步骤、预期结果、优先级、测试人员
8、bug的内容
编号、标题、模块、测试步骤、预期结果、实际结果、测试环境、影响版本、处理优先级、严重等级、测试执行人、经办人、时间
9、是否搭建过测试环境
会，之前工作时使用过devops20.8.1，搭建环境，使用的系统是centos7.5
根据部署文档部署：
安装devops
集群配置
加密狗配置
镜像导入
安装服务、导入、部署
到处devops集群信息
10、执行过多少测试用例、测试用例执行怎么提高效率
至少执行了2000条
收到测试用例执行的任务，先规划每日、每周需要执行多少条，提前规避时间风险
根据需求业务理解，分不同模块执行，对有相同功能或类似的测用例一起执行
对有阻塞较多的模块，提前告知测试负责人，每日汇报测试执行进度
11、bug的生命周期、bug有哪些阶段、你发现了bug会怎么做
提交bug给开发负责人，然后分配给指定的开发人员? ?new--open
开发人员收到bug，处理bug后为已解决? ? ? open--fixed
bug流转到测试人员，测试人员验证bug是否修复
? ? ? ? 修复bug成功，关闭bug? ? ? fixed--closed
? ? ? ? 修复bug失败，重新打开bug? fixed--reopene
开发人员继续修复bug? ?reopen--fixed
测试人员再次严重bug是否修复成功 ，直到bug修复成功后关闭
开发人员收到bug，认定为不是bug的情况，bug状态为rejected
开发人员收到bug，觉得可以暂时不修复或下个版本修复，delay
12、作为测试人员如何定义一个bug
主要依据为需求说明书、个人对业务理解、测试经验
需求实现错误
需求实现遗漏
需求实现的方式不符合说明书
实现了冗余功能
未到达需求定义的指标
不符合用户操作习惯
用户觉得难操作
13、以你的经历 ，阐述一下产生bug的主要原因
我认为主要是需求方面的原因，需求变更频繁容易导致bug
沟通不良，导致需求理解不一致
其他：时间紧任务重，前后端联调未完全，开发自测程度低，开发人员人力缺失、产品人员缺失、开发人员技术能力或经验不足
14、回归测试的概念、回归测试的作用和目的、如何做回归测试
回归测试：当bug修复好，目的1要验证bug，还要验证之前好的功能是否还是好的，目的2是bug修复导致原先好的功能出现新bug
15、各个测试阶段概念及描述
单元测试：属于开发人员测试，对各个独立代码单元模块的正确性进行测试
集成测试：将各个单元模块组装，形成子系统，对子系统进行测试，主要是为了测试程序模块之间的调用的正确性
系统测试：将人员、软件、硬件、操作平台、数据等结合在一起，形成一个系统，在实际允许环境下，对整个系统进行全面的测试
验收测试：模拟实际用户环境（试运行环境），测试人员或者和实际用户一起进行全面测试
16、tcp? udp
tcp：面向连接的传输服务、可靠数据传输（无差错、无失序、无丢失、无重复）
可靠性保证，通信钱建立连接，应答机制，通信结束正常连接断开
udp：无连接的传输服务，数据传输可能会丢失，但是传输过程简单，实现容易，以数据包形式传输，传输效率高
都属于OSI七层模型的传输层协议
区别：
1、需要建立连接? ? 无连接
2、数据传输可靠? ? 数据传输不可靠
3、字节流? ? ? 数据表
4、数据量大且可靠的场景? ? 数据量小可靠性要求低的场景
文件传输、邮件收发、点对点传输? ? ? ? 视频流（直播、视频聊天）、广播、游戏画面
17、tcp三次握手
1、客户端向服务端发送 建立连接请求
2、服务端收到请求后响应，可以连接
3、客户端收到回复后，发送最终报文建立连接
18、tcp四次挥手
客户端和服务端都可以是主动方，另一方就是被动方
1、主动方发起断开连接的请求
2、被动方收到请求后，立即回复，准备断开连接
3、被动方准备好了后，再次发送报文，表示可以断开连接
4、主动方收到消息后，发送最终报文，完成断开
19、tcp沾包、原因、解决
tcp协议的传输方式是 字节流，没有消息边界
数据传输的过程中，收发数据的速度不一致
解决：人为控制，添加消息边界，分割消息，控制收发数据的速度
20、测试报告的内容
xxx公司
xxx产品测试报告
1、概述
? ? ? ? 测试目的、项目背景
2、测试环境
? ? ? ? 硬件环境、软件环境
3、测试人员
? ? ? ? 参与此次测试的人员
4、实际进度
? ? ? ? 排期表、实际到哪一个测试阶段，是否有时间风险
5、测试参考文档
? ? ? ? 测试计划书、测试用例
6、测试结果的各种数据
? ? ? ? 测试用例执行情况
? ? ? ? bug统计情况
? ? ? ? 是否存在p1、p0级问题
? ? ? ? 列出比较重要的或者严重等级高的未解决bug，@相关人员，跟进bug解决进度
7、项目总结
? ? ? ? 测试是否通过，通过或者失败的依据
8、意见和建议
? ? ? ? 对本次测试工作提出自己的意见或者建议
