先分析,如果一点头绪都没,就堆量呗。
那你就要去维护前端扫描脚本了。
安全啊 ,学好终生不愁,还会被国家收编。
多几个角度,随便能说一大堆
把影响质量稳定的因素挨个说一遍。
什么过程质量、结果质量、提测质量、需求质量、文档质量、技术支撑等等
影响质量的一些条件也可以说说啊,比如人员、环境、竞品等等
1.如何做一位合格优秀的业务测试?
熟悉业务,根据自身业务知识能快速准确分解需求,找到需求问题,并辅助技术做业务的设计。可取带性和合格优秀是两个维度的概念。
2.业务测试在一线城市有封顶薪资吗?
看平台和赛道。门槛高、壁垒强的行业更具竞争力。有些公司某些技术就是他们的业务。
3.业务测试如何去发展自身的特长,也就是职业发展?
多元化角色,多维度技能,或者某方面专家。
4.如何让技术循循渐进的进步?
选择目标->学习 + 实践->总结 + 分享。
说的是线上缺陷吧。你统计数据这个没啥意义。
大家的规避措施倒是可以参考下。
学习了
没怎么接触过,以下是我想到的:
先招招人的人,再招人 哈哈
好文!不过向上管理挺难的。特别是整个研发中心都是成本中心的情况下。
一般这种情况有以下几个原因:
测试的价值一直都在,测试人员的价值就得靠自己挖掘了,每个团队测试人员表现出来的价值是不同的。
只是数值上的对比的话想办法获取就行。不过一些前端渲染啊样式这些,还是得靠看。
另外如果重构方案你参与过评审的话,测起来可能更有头绪一点。
如果后端没变,仅仅是前端展示有变化,做个前端 diff 测试就行了吧。
本来该长一样的数据,结果变了,一下子就出来了。
可以问问自己以下两个问题:
有 SQL 注入风险,可以用 SQLMAP 扫一遍,用安全缺陷说话。
有功能上的缺陷,可以用功能缺陷来说话。
设计上的问题,我们可以给建议,但是建议最好有事实的依据,毕竟你不是产品,也不是设计者。
没测试过,不过如果我遇到,我应该把一些差不多大小的文件改成测试的图片音频格式直接上传来验证边界。
至于是否会产生文件损坏以及其他啥的,那是另外的测试了。
可以分类
还有些比如线上测试规范、测试数据管理、环境管理规范等等
本来就不是一个东西。
不过实际工作中,有些可能是描述上的问题,我们产品爱用并发用户数来描述性能,因为他们关心的是客户端用户情况,他们对服务器处理能力说实话有些没有太大的概念,在他们看来是一回事儿。。。所以提的性能指标需求翻译过来可能就是线程数。
但是做性能测试和分析的人得知道差别。
可以从短期和长期结合来考虑:
两个都不搭边,就是来白嫖的。
你们这种情况做做接口自动化回归就行,变来变去成本太大。
这么霉。。。另外都要解散了还招人的公司也无语的
如果被裁了,裁员是被淘汰还是被动涨工资,取决于你的实力~
如果不想被裁,取决于运气加实力。运气不好整个业务都砍,那真没辙。
语言用的溜,常见算法 OK,实习期熟悉下研发流程的各个环节,各种规范,用到的工具和技术就行,这些才是你实习期该积累的经验,其他的学习都是长期的过程。
积分来了,不整个头衔 + 成就?
一个 iframe 直接定位即可。