文章目录
[+]
我的回答
先看是缺陷还是优化项，如果是优化项则留到下版本解决，如果是缺陷就进一步分析首先，看严重程度，比如是否会影响主流程、主功能的使用然后，看项目的紧急程度，如果并不是很紧急的话，那就直接修复bug然后上线如果项目比较紧急，那就要评估这个bug的严重性，如果不是很严重，那就先上线，然后再修复bug,最后进行 hotfix正确回答
我会从以下几个维度去评估这个问题应该怎么去处理
（图片来自网络侵删）
（ 问题的类型、缺陷出现概率、缺陷影响范围、规避措施、项目紧急重要程度）
问题类型优化项缺陷出现概率是否必现？偶现概率？偶现概率偏低是否可以考虑延期修复影响范围主流程or异常场景？主要功能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自动 化都是通过代码去完成的，学习成本和开发成本明显比接口自动化要高
