仅楼主可见
如果产品还在,等到只剩你自己的时候去提要求,加薪升职,不然就撤
是啊,一切没有实际产出的事务都是扯淡,需求带动增长才是最有效的方式
当你提交辞职信的时候,你们就不在是伙伴了,甚至不如陌生人,所以不要想着最后再奉献些什么
你应该反问他:开发人员还能写出来高级 Bug 吗???
当出现大量低级或阻塞性问题时,也侧面反映了所在项目中转测入口的管控力度小或者根本没有,另一方面就是开发人员的自测没啥效果或者根本没有。你能做的就两方面:
1.如果有强有力的推动,你可以选择加强并制定转测规则,反向推动开发自测工作的进行和保证。
2.如果没有推动力而且还是孤军奋战,那你可以通过提交问题单,以问题单来逼近来督促来获取管理人员的推动
其中你现在面临的主要问题是岗位与期望不符,理想的发展路线是 测开->测开 但是现岗位确实业务->测开,这种差异也导致你对现环境有些不满,可是你也没办法,除了跳槽!
专职测开是要注意公司规模及产品情况的,参与到业务测试组内基本就是你现在的这种情况,如果不想跳槽抛弃掉应届生的身份,就坚持下去,熟悉业务流程,自我巩固技术层,期望与某一天公司立志与创建自己的测试服务小组,开发自己的测试工具或平台。
空有屠龙术,却卖屠户家,确实是不甘的
多谢各位大佬的回复,不胜感激
无论是留下还是跳槽,现在都是一个考验你计划制定和时间分配的好时机;
跳槽的话就要找出自己的闪光点和能力范围
自顶!!!
请教各位大佬 TPS/响应时间在设计用例时的相互关系
英雄所见略同啊,质量的控制与提高是测试永远离不开的中心点,但是除此之外我还有一些想法,亮有一言,请诸位静听。测试岗位的引入首先带来的除了硬性的产品质量提高,还有一种思想上矛盾面的出现,即使是一个应届生测试人也会给项目内其他人员带来一种警戒与自我怀疑,这也在另一方面提高了产品质量。
如何问一个问题呢:1.说清楚自己观察到的现象,无论是直接还是间接的 2.说清楚问题出现前的操作,给出自己认为的可能性关联点 3.如有相关日志或其他相关信息,一同给出完整题 4.如有初步的定位结果或定位进度一并给出 5.说清楚自己的问题中心点,无论是否与实际问题中心一致 6.保证回答者的权威,如果你很确定自己的正确性,求同存异给与其应有的尊重
总结下就是持续集成这事只能在公司流程完善,产品成熟,计划安排合理的情况下去做
input
你的意思是同一串信息,不同的来源(解密/抓包),然后抓包的就可以直接使用登录吗?
一个关注的是接口本身,一个关注的是接口间的流转情况,可以在保证接口无问题的情况下进行完整流程的接口间调用测试。其实这个就和单元测试后集群测试的性质差不多,个体与集体的关系
测试 - 技能图谱!干饭人!
不明觉厉,时代的洪流滚滚而过,不进取的结果只有被取代!
对流计算的具体流程有了概念,但是具体测试手段还是有些不清晰,主要疑问点是 checkPoint 的间隔时间点内去多次注入故障,以求出现数据重复类的问题,可是大数据量的情况下,怎么去验证数据重复的问题出现呢?现在项目也在用
sql-》kafka-》flink》sql 的流程,是不是可以直接通过两端此时间段内的数据量差别来进行确定呢?
简单来说,左移:把自己当成产品人员来对待需求,提高需求质量,优化需求方案;右移:把自己当成现场/实施人员来看待产品,发现可能在实验室中无法发现的线上环境导致的问题
测试负责的情况其实就一种:从测试手上出去的产品出的问题。
当然有几个前提:1.代码在测试结束后未变 2.出现的问题已在测试阶段提出 3.测试结果为质量较差,不建议上线,然后强行带风险发版 4.出现的问题与需求不符
base
一台电脑都有哪些组件,怎样的电脑算好电脑,怎么组装一台不黑屏且可以热菜的电脑
真香啊,我要去上海!!!
嗯,我只是给个建议