• 本人是从游戏测试转过来的,只能说关键要看你自己原来的功能测试怎么做的了

    游戏测试相比Web和APP,人机交互上不可预测的变量更多,因此掌握了单变量控制、逆向思维的人转其他测试反而觉得游刃有余,如果之前做过偏数学类的测试比如刚体碰撞、地图检查、追踪轨迹测试、lod减面等等,再加上能会一个语言,转其他的测试问题不大

  • 为什么想从测试转开发 at 2018年05月31日

    现在从填报专业到选择就业完全处于没有任何情报支撑的情况,出来以后找不准自己的定位很正常,换个角色换个视角是一个方法,建议可以先维护一个github投石问路,看看自己是否真的适应开发的工种再去针对性的学习课程,能找到一份好一点的工作

  • 仅楼主可见
  • 😢 人在杭州,超想去,请问会后可以索要相关资料吗

    1. 测试从按次测试改成按轮测试,整轮开始之前记录版本号,整轮结束之前不接受提交代码修改
    2. sonar规则扫描,每次出问题花时间跟到代码层追溯,整理成sonar的规则;建议初期用findbugs排除低级错误
    3. 测试过程数据分析:建议全部测试开始前清理掉数据库和日志,测试过程中全部保留,最后测完之后分析,比如测试环境限制了邮件发送,那么发送记录表里面就不能有成功的记录;再比如主数据与关联数据关系应该是1:3,做个联表group找找有没有关系不对的;日志里面所有的异常必须全部过一遍、另外,对各个流程节点关键日志进行统计,在某一个节点数量大幅增加的可能就是有bug的
    4. 推动jenkins和docker,部署脚本建议测试维护,确保上线环境与测试环境一致
    5. 埋点提前预测线上bug,这个一两句很难说完,建议自己查资料
  • 怎样算一个好的测试主管 at 2018年05月15日

    我有过这种经历,但是试着反过来考虑一下,如果你的上司什么都答应了,那你推动任何事情都会被开发各种甩回来还甩你一句你老大答应了啊或者你要不好说话我就找你老大了,你更郁闷,这个世界上当好人永远比坏人容易了

    当然了,不是说完全顺着自己的脾气来了,我觉得你的主管既然还在这个位置,那就是说至少他的做法在这个环境是适用的吧大概,人家也是被逼的

  • Postman,Charles都有mock功能能做到这点

  • 因为之前有人问过我相同的问题但是当时我没答上来,这里放一下我自己总结的请大家也帮忙看一下:

    1.测试平台的出发点:经验分享、标准统一、便于量化执行
    2.好的测试平台需要关注的点:
    针对主营业务近几年的发展已经和将要遇到的问题,能不能起到正确的引导方向;
    如何去考核平台对执行效果的影响(问的人看来有相当的眼界和水平了,第三个问题实际上是第二个问题的答案);
    平台推广的方案
    3.平台对效率的提升,实际上这个问题完全取决第一个问题有没有答到点上,如何量化看第二个问题的回答

  • 大家平时的工作量饱和吗 at 2018年05月15日

    需求问题,明确本期的建设目标,别什么都压在这一期,要划出基线;

    过程中有共性的问题,举一反三,别一个地方数值不对相关的部分就放过了

    另外,本期风险较高的,比如框架改造、对外接口、不合规的调用、自定义的控件交互等等可能要反复回归的,优先自动化,别一直功能测试

    还有,每天八小时,最少留一小时总结一下,别死干

  • “你用自动化解决过什么问题”,我面过多数做过自动化的测试,都答不上来;

    关于这一点,我觉得作为QA,让公司认识到自动化的价值本身也是我们的工作之一。认为自动化达到天花板的,请问你有认真的评估过目前的行业都会遇到哪些问题吗?

    首先,测试开发比的下降,自动化是一个方向,但是只靠web、APP、UI等他能带来的下降是有极限的,随着系统的扩张,还是需要进行进一步抽象和框架性的优化的,当然,这需要了解这些技术的同时也要熟谙业务

    再一个就是解决的问题深度;接口Web和APP测试,我认为只是前人把自己遇到的问题抽出公共的部分,不同行业还会有多得多的问题,比如游戏中难度设置的测试,又比如法务领域的合同文本关键点标亮,还有金融领域的高频交易问题等等,不通过建模和算法辅助去预测和实践,根本无从入手

    自动化的价值核心,并不在技术和工具本身,而在于方案