基本的测试方法？黑盒测试的方法有哪些?
我的回答
正确回答
- 等价类、边界值、错误推断、因果图、场景法、判定表、正交法、状态迁移法
总结
- 我竟然忘了一部分
工作中，最常用的测试方法是？
我的回答=正确回答
- 等价类、边界值、错误推断、场景法
有写测试计划吗？
我的回答
- 有写
- 我的测试计划包含了测试范围，前期需要准备什么测试数据、测试工具，测试资源如何分配，风险点，是否有送测延 期的功能
正确回答
- 有写的，我会从几个维度去写
- 前期准备：包括了分配测试资源、准备测试工具和测试数据
- 确定测试范围：被测对象，测试内容，明确测什么不测什么
- 确定测试策略：功能测试、兼容性测试、交叉测试、接口测试等等
- 送测准备：验收时间、送测时间、测试时间、发布时间
- 沟通点：这次送测的范围、改动范围、是否有延期送测的功能、是否有风险点
总结
- 回答的中规中矩，但是没有这么体系化的回答，需要优化
怎么去分配测试资源？
我的回答=正确回答
- 我们项目是2-3个人负责
- 每次送测会根据不同的功能模块分工，或者根据不同的端（移动端、web端）去分工
写测试用例会有评审吗？
我的回答=正确回答
- 按项目紧急程度决定
- 如果项目比较紧急，那可能直接写测试点、测试用例就测试了
- 如果项目不紧急，那写完会有小组内的评审
- （小声bb,其实我一次都没评审过）
不开用例评审的话，你理解的需求不会跟产品给到的需求不一样吗？
我的回答=正确回答
- 目前我们测试会参与完整的一个项目流程
- 包括前期的需求评审、交互评审、视觉评审，所以如果需求上有问题的话会及时提出和沟通解决
- 写测试点、测试用例过程中如果有问题也会及时沟通
一个功能测多少轮？
我的回答（没有标准答案）
- 我们一次送测的轮次会控制在两轮内，但不是硬性要求，这是管理层那边的决定，当然也可能会存在第三、第四轮的情况
如果测了几轮，后面才发现的问题怎么处理?
换个问题（有漏测怎么处理）
我的回答
- 先看是缺陷还是优化项，如果是优化项则留到下版本解决，如果是缺陷就进一步分析
- 首先，看严重程度，比如是否会影响主流程、主功能的使用
- 然后，看项目的紧急程度，如果并不是很紧急的话，那就直接修复bug然后上线
- 如果项目比较紧急，那就要评估这个bug的严重性，如果不是很严重，那就先上线，然后再修复bug,最后进行 hotfix
正确回答
我会从以下几个维度去评估这个问题应该怎么去处理
（ 问题的类型、缺陷出现概率、缺陷影响范围、规避措施、项目紧急重要程度）
-
问题类型
-
- 优化项
-
缺陷
-
主要功能or次要功能？
-
若是主流程，是否影响正常功能使用？
-
若是主要功能，是否影响其他功能模块的使用？
-
若是异常场景，操作步骤是否繁琐
-
该功能/场景使用频率如何？
-
规避措施
-
- 技术上有没有规避措施？
-
交互上能否提醒用户执行某些操作来规避出现缺陷?
-
出现问题后能否友好提示？
-
项目层面
-
- 发布时间是否能延期？
-
发布的版本是对内还是对外发布？
-
开发能否迅速解决问题？
-
解决问题成本如何？
-
产品团队能否接受带问题发布？
-
带问题功能能否接受暂不发布，只发布正常新功能
-
总结
-
- 如果是优化项，或者是低概率出现的缺陷，影响范围不广的缺陷可以选择下个版本解决
-
如果是必现，且又影响范围比较大如主流程、主功能的缺陷，则需要在发布前解决
-
当然实际情况还有很多种可能，比如产品团队直接做决定也不是不可能，但是作为测试一定要根据不同维度去分析这 个问题，然后给出建议
上传文件的功能，如何设计测试用例
我的回答
我会从几个维度
-
功能测试
-
- 能否正常使用上传文件功能
-
- 上传文件整个流程体验是否友好流畅
-
性能测试
-
- 持续上传大文件，查看服务器负载情况
-
并发上传文件，查看服务器负载情况
正确回答
可以回答以上五个维度，另外加一些维度
上传文件接口怎么测试？
我的回答= 正确回答：
我会从几个维度去测试
-
参数组合
-
- 全部必填参数，组合选填参数
-
响应结果的断言
- 响应信息
- 响应数据，包括数据结构和数据是否正确
很多个用户同时访问上传接口，怎么知道接口的负载能力，如何设计测试场景？
- 上传文件接口，影响比较大的是文件大小、网络带宽，所以要先确定最大可传的文件大小是多少，还要确定最大可接 受的响应时间
- 最先做一个基准测试：从一开始单线程并发，逐渐增加10、20、30、50、80、100个线程，根据最大可接受的响应 时间找到基准值，即确认并发量
- 根据确认的并发量，使用阶梯加压线程组设计一个负载场景，比如一分钟、两分钟内阶梯加压
- 负载测试过程，再同步观察系统CPU使用率、内存使用率、磁盘10读写情况，最后查看阶梯加压过程的响应时间 和TPS
除了响应时间还有什么指标可以关注
我的回答
- 响应时间外，还会关注qps、cpu使用率、内存使用率
正确答案
- 对于性能测试脚本来说，会关注响应时间、tps、qps
- 对于服务器来说，会关注cpu使用率、内存使用率、进程上下文切换次数
- 对于文件上传来说，因为是i。密集型任务，所以磁盘压力比较大，需要关注磁盘10读写的情况
接口的吞吐量到了一定值，响应时间变得很长，你会从哪些角度分析瓶颈
- 第二次问我的说法
- tps—定的饱和度，响应时间变长，什么原因导致响应时间变得这么长
我的回答
- 忽略吧，答得比较细碎
大概对的回答（仅供参考）
先写大佬们的答案，然后再总结（后面再补充吧。。。）
- 暂且理解吞吐量是tps,找到耗时多的地方，再深入分析
- 都饱和了，如果增加并发线程，有排队，时间必然变长
- 如果是小文件的话，大量的小文件上传可能会把磁盘的节点消耗完，导致文件传不上去，堵在队列里面
- 如果是大文件，可能超出链路层的mtu阈值，产生大量的切片，消耗内存和cpu
使用Jmeter有使用Beanshell写脚本？
我的回答（没有标准答案）
- 有写过，主要是接口数据如果需要加密解密的话，会添加加密解密方法
- 然后需要跨线程组传参时，也可以用BeanShell去完成
自动化测试中，你认为哪个成效最高，哪个成本最高？
我的回答
- 接口自动化测试的成效最高，UI自动化测试的成本最高
- —般开展自动化测试工作时，都会先做接口自动化
- UI自动化测试对页面稳定性要求比较高，如果版本迭代很快或者改动很大的话，其实UI自动化测试的维护成本就会 很高
正确回答（个人理解，仅做参考）
- 我认为接口自动化测试的成效最高，UI自动化测试的成本最高
- 当一个团队或者项目要开展自动化测试的时候，肯定是首选接口自动化的，接口自动化可以让测试左移，在送测前就 跑一遍自动化测试脚本
- 另一个方面，接口自动化规避了 UI自动化的缺点，不依赖界面，和端也没有关系，无论是web端还是移动端都可以 使用，所以当界面发生大幅变动的时候，接口可能还是不会变，这个时候，接口自动化维护成本低的优势就体现出来 了
- 接口自动化不仅可以通过代码去完成，也能通过工具去完成，学习成本和开发成本也会比UI自动化测试低
- UI自动化测试的成本高主要体现在它其实是一个漫长的周期，初期见效太慢，只有在随着项目的迭代以及稳定后， UI自动化测试的成效才能慢慢体现
- 而却对项目的要求也很高，如果界面或项目频繁发生变动，那UI自动化测试脚本的维护成本将会大幅提高，而且收 益成效比也很低
- UI自动化测试是分端的，如果一个项目有web端、移动端，那还得写两套自动化测试项目，而且目前大部分UI自动 化都是通过代码去完成的，学习成本和开发成本明显比接口自动化要高
