一、测试理论
3.1 你们原来项目的测试流程是怎么样的?
我们的测试流程主要有三个阶段：需求了解分析、测试准备、测试执行。
1、需求了解分析阶段 我们的 SE 会把需求文档给我们自己先去了解一到两天这样，之后我们会有一个需求澄清会议， 我们会把不明白不理解的需求在会议上说出来，包含需求的合理性还有需求的可测性等， 产品这边解答，目的是让我们测试这边和开发对需求的理解达到一致。
2、测试准备阶段 会议结束之后我们开始准备测试工作，我们测试这边会写一个测试计划，分配每个人负责的模块， 然后我们就根据自己负责的模块用 xmind(思维导图)进行测试需求分析，分析测试点， 以及编写测试用例，之后我们会在自己的组内先进行评审，评审修改之后还会在我们的项目组评审， 评审完后进行修改测试用例。
3、测试执行阶段 开发人员编写好代码之后，我们会把代码包通过 Jelkins 部署到测试环境提测，进行 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)交付件 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 华测教育专属 15 参考答案 2 我们公司之前按照考核要求写过测试计划，不过后面老大觉得太耽误工作进度， 后面一般都不再写测试计划，而是写版本计划，这个在版本计划，每个人的任务列出来， 负责人列出来，自己根据自己的情况分配时间，然后汇总，大家一起开个小会评审就可以了。
3.5 用例包含哪些部分，哪些用例设计方法，你一般常用哪些方法?
原来我们用例包含 测试项目，用例编号、测试标题、优先级、预置条件、操作步骤、测试数据、预期结果 黑盒测试用例设计方法：主要是等价类、边界值、错误推测法、判定表、因果图、正交表、 流程分析法、状态迁移法、异常分析法。 常用的：等价类、边界值、判定表、流程分析法、错误推测法。 等价类是指某个输入域的子集合，在该子集合中， 各个输入数据对于揭露程序中的错误都是等效的， 并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此，可以把全部 输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件， 就可以用少量代表性的测试数据取得较好的测试结果， 等价类划分可有两种不同的情况有效等价类和无效等价类。 边界值的话就是对等价类划分方法的补充。测试工作经验告诉我，大量的错误往往是发生在输入或输 出范围的边界上而不是发生在输入输出范围的内部，因此的话针对各种边界情况来设计测试用例，可 以查出更多的错误，使用边界值分析方法设计测试用例的话，首先应该确定边界情况，通常输入和输 出等价类的边界，就是应着重测试的边界情况应当选取正好等于，刚刚大于或刚刚小于边界的值作为 测试数据，而不是选取等价类中的典型值或任意值作为测试数据。 对于错误推断法，这个是基于经验和直觉推测程序中所有可能存在的各种错误， 从而有针对性的去设计测试用例的方法的，主要就是列举出程序中所有可能有的错误和容易发生错误 的特殊情况去根据这些情况来选择测试用例，例如，在单元测试时曾列出的许多在模块中常见的错误 以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为 0 的情况。 输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况，可选择这些情况下的例子作为 测试用例。 前面介绍的等价类划分方法和边界值分析方法都是着重考虑输入条件但都没有考虑输入条件之间的 联系，相互组合等等的情况。考虑输入条件之间的相互组合，可能会产生一些新的情况， 但是要检查输入条件的组合并不是一件容易的事情，即使把所有输入条件划分成等价类， 他们之间的组合情况也相当多，因此的话可以考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例，这就需要用到因果图(逻辑模型)。 因果图方法最终生成的就是判定表它适合检查程序输入条件的各种组合情况。
3.6 TestLink 工具使用?
(1)创建用户，并给新创建的用户指定权限。 (2)创建测试用例，对测试用例进行增、删、改、查 (3)把测试用例关联到对应的测试计划中。 (4)把测试用例指派给对应的测试人员。 (5)对应的测试人员，查看被指派的测试用例，并执行测试用例。
3.7 如何提交一个好的 BUG
对 BUG 有一个清晰明了的描述； 详细描述 BUG 重现的步骤 对于产生 BUG 的环境进行描述； 提交 BUG 相关的图片和日志; 定位好 BUG 的等级； 将预期结果与实际结果进行对比。
3.8 提 bug 需要注意哪些问题?
1) 不要急着提交，先跟开发说明 bug 的情况，定位分析下 bug。 是前端问题还是后端问题再去提交 bug。 2) 简单明了的概括 bug 标题，清晰的描述 bug 重现步骤，分析 bug 和预期正确结果，附加 bug 的截 图或者日志。描述 bug 的时候。 3) 在不能确认该情况是否为 bug 的时候，可以请教其他人。 4) 提交完 bug 以后，后面还要跟踪 bug 修复情况。
3.9 bug 怎么管理的，bug 的生命周期或者是 bug 的状态
原来 bug 是用禅道来管理的 原来我们公司 bug，提交 bug 直接给对应的开发人员，对应开发人员修复完成，交给测试复测， 复测通过关闭 bug，不通过打回给对应开发。 提交-开发人员(已激活未确认)-开发进行确认，状态变成已激活，已确认，开发修复完成， 标注状态是已修复，测试人员复测通过，已关闭，打回给对应开发，已经激活。
3.10 提交 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 测试中，如何判断是前端的 bug 还是后端的 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 开发人员在上线规定时间之前都还没有修复好的话，就看问题的严重性， 如果严重就延期上线，如果我们是迭代版本的话我们还需要版本回滚。 如果不严重，产品跟客户觉得可以上线，就正常上线。
二、接口测试
9.1 接口测试怎么测
（jmeter 版本） 首先开发会给我们一个接口文档，我们根据开发给的接口文档，进行测试点的分析，主要是考虑正常 场景与异常场景，正常场景，条件的组合，参数的格式校验等价边界值;异常场景，多一个参数，少 个必填参数，参数为空;接着编写测试用例，用的 Jmeter 工具去运行，创建线程组，建立 http 请求， 输入测试用例，请求参数，建立察看结果树，运行，看返回的结果，是否跟接口文档里面要求的返回 结果一致，其他用例，值需要修改里面的参数，请求地址这些信息。 举例说明：(不要登录跟注册) 比如说原来我们做一个申请借款的接口，对接口进行测试分析，考虑正常场景与异常场景，正常场景， 考虑不同参数组合，比如说，不同借款方式，还款期限，还款曰期，借款的利率等参数组合;也要测 试每个参数格式校验，异常场景，：多一个参数，少一个必填参数，比如没有借款的利率，参数为空 的，比如借款标题为空，编写测试用例 在 jmeter 中执行，填写参数，更地址就 ok，发送请求 （python + request） 原来我们接口主要是用的 python + requests 去运行的 首先，开发会给我们一个接口文档，拿到接口文档后，我们就进行测试点的分析， 考虑正确场景，条件的组合， 异常场景，多一个参数，少一个参数，参数为空的情况 比如原来我们做一个生成订单的接口，考虑正常场景，异常场景 正常场景就是不同的订单类型，订单金额，能不能申请订单，每个参数的格式类型的校验， 异常场景，多一个参数，少一个必填参数的时候，还有参数为空的情况 原来我们是用 python + request 去做的接口 首先，导入 request 包 建立一个 headers，保存请求头的信息，因为订单请求方式是 post 类型，数据格式是 form 表单格式， 我们把数据保存到 data 的字典里面 这个时候我们还需求登录的 cookie 值跟登录后产生的 token 值 我们会去通过动态关联去获取登录的 token 跟 cookies， cookies 值的话，我们是直接调用登录返回的 cookies、token 值的时候，我能是通过导入 re 模块， 通过正则表达式去提取 当参数， headers、cookies 输入完成以后，我们就发送请求，打印返回结果，检返回结果是否跟我 们测试用例一致 当运行其他测试用例时，我们去修改 data 里面的参数就行，在发送请求 有的请求时 htps 协议的时候，我们发送请求的时候还会 very= false 去忽略掉证书验 证对应多个接口调用 cookies 我们会用到 session 去保存接口发现比较多的问题，就是格式校验这 块 比如说我们提交订单，订单数据没有显示，订单格式也没有显示，输入字母，汉字都可以 订单类型为空，也会生成订单成功 我觉得接口可以发现接口更多的 bug，还可以提早进行测试，提高测试的质量
9.2 两个接口有关联， jmeter 具体怎么做
另外两种问法：上个接口的返回值是下个接口的请求参数，这种如何处理?动态关联有没有了解过? 这个涉及到动态关联，首先要搞清楚后一个接口需要用到上一个接口的什么数据，例外要看数据是在 哪里取的，是在 head 还是在 body 里，然后如果要取的数据是 json 格式我会在发请求用 json 提取器 去取这个数据，如果是其他格式的就用边界提取器或正则表达式去取数据 就拿我当时做的那个下单接口来说吧，因为下单接口需要先登录，需要用到登录接口的 cookies 来做鉴权，首先就是把登录接口调试通过，然后在登录接口的 http 请求中添加一 个边界值提取器或者也可以用正则表示式提取器去提取登录接口的响应头中的 cookies 值 然后在下单接口中需要添加一个 http cookies 管理器，在 http cookies 管理器中引用登录 接口提取出来的 cookies，这样就可以了 如果是不同的线程组的话，那在登录接口中还得添加一个 Beanshell 取样器，在 Beanshell 取样器中，利用函数助手中的 SetProperty()函数把提取出来的 cookies 设置为全局变量， 然后在下单接口的 http cookies 管理器中利用函数助手中的 Property()函数引用登录接口中设置的 全局变量，这样就可以了。
9.3 接口测试主要目的是什么?
例外两种问法：接口测试的价值，意义?为什么要做接口测试? 主要就是验证后台服务端的业务逻有没有问题，提高测试的效率 ①越底层发现 bug，它的修复成本是越低的 ②前端页面修改频繁情况下，接口测试不受页面元素改变而影响 ③检查系统的安全性，前端传参不可信，比如京东购物，前端价格不可能传入-1 元，但是 通过接口可以传入-1 元 ④如今的系统复杂度不断上升，传统的测试方法成本急剧增加且测试效率大幅下降，接口自动化测试 可以提高测试效率 ⑤接口测试相对容易实现自动化持续集成，且相对 U 自动化也比较稳定，可以减少人工，回归测试人 力成本与时间，缩短测试周期
9.4 接口测试的流程
1，首先分析开发给到的接口文档 2，接口文档分析完成，编写测试用例 3，然后借助接口测试工具去测试执行测试用例 4，发现 bug 提交 bug，并跟进 bug 修复
9.5 接口测试和平常的 Ul 测试有什么区别?
其实这两者测试的侧重点是不同的，接口因为没有界面，更多考虑后台服务器对请求的，处理逻辑问 题，业务交互，检测的是后台“容错机制”是否完整； 而 ui 更多会去关注页面展示，数据转换，界面排序这些功能，当然也会后台数据处理的问题，ui 测 试其实已经包含了接口测试。系统功能的用例更全面，不仅有界面的，也有业务功能用例，还有其他 用户场景的用例功能入口用例，流程用例，而接口测试主要根据各种入参场景来设置用例。
9.6 给你一个新的接口，你怎么去设计用例?
首先要对于每个要测的接口都要先搞清楚这个接口的功能，它的作用是什么，熟悉这个业务功能需要 用到什么协议，请求方式是什么，接口有哪些参数。对于每个参数的作用都要搞清楚，像数的类型， 是否有约束限制，是否为必填的，长度，其他的限制等等，如果两个参数之间有关联我们还要考虑参 数的组合场景，对于参数不理解的，一般都会跟开发沟通下，然后考虑返回数据的类型，返回数据中 的返回码和返回信息是什么，通过以上几个点去提炼测试点，设计用例。 参数约束——长度、必选项、格式、数据类型 业务场最——正确的业务场景;错误的业务场景；异常场景：服务器空间不足 组合场景——相互依赖：手机和验证码、用户名和验证码； 相互排斥：二选一当然还有边界值等价类等等 Jmeter 测试流程，步骤如下： 创建 jmeter 线程组一添加 HPPT 请求-输入协议-域-端口-路径-编码-请求方式-请求参数-启动 Jmeter 测试流程： 先需求，再根据需求写测试点转换成测试用例，根据测试用例编写测试脚本；执行测试脚本； 提交 BUG，跟踪 BUG
9.7 接口文档主要包含哪些内容?
接口文档一般两种形式的，要不就是 word 版本的要不就是 htm 的形式，具体内容 1．URL(接口地址) 2．接口功能 3．请求方式：post 4．请求参数，以及接口中每个参数的详细说明，类型，是否为必填，约束条件等等 5．响应数据及格式，返回码，返回码解释等等
9.8 你们什么时候测试接口
一般有需求就会做，后台的接口开发好，就可以开始测。例外，如果增加了新需求，也要做接口测试， 还有就是开发对后台的接口做了修改，交互逻辑发生变化，我们也要重新对接口进行测试。
9.9 你怎么去检查，分析
我们主要是根据入参情况，去看接口的返回值，对于返回值，我主要关注的几个点：1.状态码 2.提示信息 3.返回数据的具体内容。根据接口文档的说明去检查这个 3 个点是否满足接口需求文档， 4.有些如果要检查数据库的，就连接数据库获取数据与返回的数据做对比。 如果不满足就是有问题，如果满足则通过，如果有 Bug 我们会先大概分析下，是什么原因， 并进行复测，如果还是有问题，提交 Bug 给开发，让开发修复，之后再回归测试
9.10 什么是 api 接口测试
接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点测试的重点， 是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等
9.11 什么情况下开展接口测试?
1、项目处于开发阶段 2、有接口需求文档，开发已完成联调，功能测试展开之前 3、专项测试：参数约束测试，业务场景测试，测试接口请求响应时间（性能） 4、版本上线前，进行整体回归测试，查看接口是否有异常(如 404 等)
9.12 依赖于第三方的接口如何测试
1，需要第三方接口的，接口文档 2，发送请求到第三方接口，检查第三方接口返回的数据是否正确 3，不正确的时候，要跟第三方接口联调，看是请求问题，还是第三方接口返回数据有误， 这个我们公司的第三方接口，我们都是打通的，比如电商，我们通过调用微信接口等等，都是打通的， 比如要测试下单第三支付，我们自己开店，收款设置我们自己的账号，然后通过商品设计 1 分钱，去 测试的。 如果不打通的话，基本也只能抓包，主要保证我们发送出去的数据符合需求文档就行，然后真正的上 线之前，我们会在预生产环境做一个联调测试，把各自系统连在一起，做一个联调测试没有问题了 我们就可以上线，基本就这么做的 联调测试怎么做的： 其实联调测试就是数据拉通测试，两个子系统，连在一起，形成一个完整的系统，然后从上游下数据，下游接到数据看传过来的数据是否符合下游的系统要求然后下游做了操作，把数据返回给上游，通知 上游说数据返回了，上游看返回的数据是否符合要求，如果没有问题，就这个数据就拉通成功这个都 是按照用例来执行，上游和下游一起出一份用例，两边都评审通过，然后按照测试用例执行，每条用 例测试通过那么联调测就完成了。
9.13 你们接口怎么鉴权的?
(1)通过用户和密码，auth 鉴权 (2)通过 cookie 和 session (3)通过 token (4)通过 sign 签名 现在 app 一般是通过 token 鉴权，有些是通过把 token 放在请求头里面，有些是通过 singn 签名这 个字段放在 body 里面去鉴权的，一般的 web 是通过 session 去鉴权的
9.14 接口传输格式有哪些
常见的媒体格式类型如下： text/html：HTML 格式 text/plain：纯文本格式 text/xm：XML 格式 Image/gif：gif 图片格式 mage/jpeg：jpg 图片格式 Image/ng：png 图片格式 以 application 开头的媒体格式类型 application/xhtm + xml： XHTML 格式 application/ml：XML 数据格式 application/atom + xml： Atom XML 聚合格式 application/json：JsoN 数据格式 application/pdf：pdf 格式 application/msword：Word 文档格式 application/octet-stream：二进制流数据(如常见的文件下载) application/x-www-form-urlencoded：encoded：
中默认的 encType,form 表单数据被编码为 key/value 格式发送到服务器(表单默认的提交数据的格式) 另外一种常见的媒体格式是上传文件之时使用的： multipart/form-data：需要在表单中进行文件上传时，就需要使用该格式
9.15 cookie、session、token 的区别
它们都是用来做鉴权的，区别的话，大概是这样的 1、现在 cookie、session 一般是配合使用的用户第一次登陆时，服务器会创建一个 session 生成一个 sessionID，sessionID 保存在 cookie 中，然后返回到客户端，保存在浏览器中。 客户端每次发请求都会把这个值带到服务器，做一个鉴权和会话的跟踪，或者时效的验证 2、token 和 cookie、session 差不多，通过算法，每次验陆，会产生一串很长的随机字符串，一般 是在放在返回的 body 里面，或者返回的头里面，他们都是服务器产生，带过来是要做验证和时效的 验证的。一般在 app 中使用 token 比较多一点，Web 端使用 cookie、session 的鉴权方式会多一点。
9.16 接口测试的工具有哪些?
Fiddler 抓包工具，也可以做接口测试 Postman 接口测试工具，支持接口自动化测试 wireshark 支持电脑上各种协议的抓包工具，主要常见有 http 和 tcp 抓包 Soapui 功能强大的接口测试工具，性能测试，接口自动化测试 java+httpclient.jar java 代码实现接口自动化测试，一般需要借助单元测试框架 junit 和 TestNG 接口自动化测试框架设计：java+httpclient+TestNG Python + requests python 代码实现接口与接口自动化测试，测试框架： unittest，pytest， 接口测试框架设计： python+ requests+ unittest+ htmlTestRunner 或者 python +requests+ pytest Loadrunner 接口自动化测试，接口性能测试(主要) jmeter 接口测试，接口自动化测试，接口性能测试(主要) Swagger 编写在线接口文档，在线接口测试
行动吧，在路上总比一直观望的要好，未来的你肯定会感 谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入扣群：731789136，里面有各种软件测试+开发资料和技术可以一起交流学习哦。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
