• wifi 连接稳定性如何?

  • 问题梳理得非常详细,点个赞。

    楼上对于这种情况已经有很多建议了,我就不再重复了。楼主这种情况我理解其实并不算迷茫期,更多是工作内容和自己预期差异太大,做起来既辛苦又没有成就感,所以对是否要继续下去产生很大的动摇。

    以前也曾经有过一段时间是处于这个状态,在团队里是唯一的测试,给测试提要求的是开发,而且有些要求相对来说会比较笼统(比如通过前置接口自动化测试,保障客户端和服务端联调时不出现问题),每天花比较长时间去测试,但还是无法保障到位。最后是因为团队工作内容调整,换到了另一个项目的测试团队里,才跳出这个困境的。

    所以,建议楼主可以先针对上面的问题逐条想一下,自己是否想要去逐个突破,逐步建立流程和解决你提到的这些问题。如果觉得已经身心俱疲不想突破,那就出来投递一下简历,看能不能找到更适合自己的吧。

  • 嗯嗯,这个确实是社区组织的。

    @kasi 卡斯看看?

  • 你具体说的是哪个微信群,群名字发一下,我们先确认下是不是社区组织的群?

  • 关于工时评估的疑问 at July 18, 2022

    项目负责人在做排期时压缩测试时间,该怎么说服 ta 给到足够的测试时间

    这里没有怎么压缩的细节(比如是测试给出的排期计划有些模块测试时间他认为过久所以压,还是啥细节都不看无脑压),不好说怎么说服。

    结合你提到的这个测试跟着项目走的背景,以及项目负责人认为效率优先牺牲质量,那大致能理解项目负责人压缩的出发点。建议是和项目负责人沟通清楚,如果按这个时间,测试只能保障到哪些核心内容,哪些部分无法安排测试会有风险,如果项目负责人接受,那就按这个来走,出问题就拿这个东西来说明这是项目组决定的,有锅一起背。如果项目负责人觉得风险太高,但时间不能延长,那就从别的地方抽调资源来支援(比如这 8 个开发找一些来执行一下测试)。

    这和自己想要保证质量是相悖的,但想要快速上线也只能牺牲质量在后续迭代再来弥补,说到底可能还是对质量不够重视

    这么说吧,新产品还在求生存的时候,质量只需要保障够用就好,速度高于一切。重视质量细节只会出现在业务已经相对稳定,需要进行用户体验等细节打磨的时候。甚至有的产品其实还在小规模内测/公测阶段,质量要求可以低到只要冒烟测试能通过,就可以上线。公司生存靠的是业务,所以有些时候还是要结合业务来决定质量要求。

  • 自动化测试 at July 15, 2022

    rest-assured 挺好用的。

  • 哈哈,这个前几天我们公司内部技术群也有在传。整个过程和原因复盘都非常详细,很值得学习。

  • 先说下简历:

    整体看完后感觉:应届生常见的 学生干部经历、获奖经历、内部学校项目经历 基本没有,大篇幅的项目经历也没有一个能打的(项目经历不是越多越好,1-2 个但能体现你能力最强的一面就足够了)。

    1、项目经历看似很多,但都比较简单,多而不精。而且你这里附上了代码仓库,大概率面试官会去看具体代码情况,如果写得不咋地或者用例数量很少,可能反而是扣分项。不知道是否方便公开下代码仓库?

    2、简历上看,感觉像是面向自动化测试岗的,而非业务测试岗。而且你的项目经验看起来并非是公司工作经验,而只是自学经验。大部分情况下,自学经验是经不起推敲的,只能作为加分项,不适合作为基本盘,因为自学项目相比实际工作项目,复杂度低太多了,只能用于辅助了解技能学习程度,无法认为有工作经验。所以如果有工作经验,尽量突出工作经验,而不是自学经验。然后学下 STAR 法则,用符合这个法则的方式去写工作经验,不要单纯只是说做了啥。

    3、专业技能里,“了解掌握” 到底是了解还是掌握?两个要分开,不要合在一起。“Redis 数据库” 这个,redis 不是数据库呀。

    然后简历之外,有几个建议:

    1、你目前是已毕业还是明年毕业?现在行情,从学校里招人,测试岗实习比直接招应届性价比更高,所以大多是直接实习转正。直接招应届生的,你这里面没有相应实习经验也会比较吃亏。

    2、你是下定决心做测试吗,还是只是权宜之计?如果并不是下定决心做测试,更建议你去针对面试中自己答得不好的地方,去进行针对性学习,深化自己的开发能力,走开发路线。

  • 比如你在测试注册接口的时候,会由后端发一个手机验证码,这个验证码你很有可能会通过查数据库的方式去获取,否则你就很难进行下一步操作。

    挑个小毛病,这个验证码只是临时数据,基本不会是存数据库吧。

    另外,标题里 “应不应该用数据库” ,这里的 用 字很奇怪,很难理解。从文中的内容看,应该主要是说应不应该涉及数据库吧。

  • 把使用中的问题记录下来,并表述清楚这些问题严重影响效率,然后反馈得领导,借助领导的力量去推动平台维护方解决。当然就算解决确实不及时,也先用一段时间吧。

    其实你第一句已经说的很清楚了,领导要强推这个测试平台(都和绩效绑定了,足够明显了吧),不管好用不好用都得用。那你的沟通就应该要先遵循这个大方向,然后在大方向下提问题和寻求解决方案。你提出用开源框架,和团队的大目标不一致,当然会被否决。

  • 这是个开放性问题,更多看的是你的思考高度和对自己任务的理解。不知道楼主面得是什么岗位,如果是中级或以下,我觉得这个回答还算可以,不至于会直接否决。

    如果楼主想复盘为啥面试没通过的话,建议还是综合评估,不要只是看这一个问题。对于这个问题,不同级别、不同业务领域、乃至于不同公司文化下,都会有不同的答案,没有标准答案的。就算有,那也不一定适合每个人,这里问的是个人的理解,而不是教科书标准答案。

  • 实在改变不了环境,那就换环境吧。

  • 你单独建个帖子,把你的详细操作步骤也补充贴上来吧。

    光这样一个截图和错误日志,不好定位问题。我现在已经很少用 repeater 了,也没熟练到直接看日志就看得出问题的程度。

  • @A.D console 启动了么?文章顶部 console 相关的配置都配好了吗?

    PS:请使用 markdown 排版

  • 入网验收,入的是啥网?可以提供除了这 4 个字之外,更详细的描述么?

    我能想到的就只有工信部对手机的入网验收,但不知道你说的是不是这个。

  • 那就把冒烟测试调整一下,改为开发演示。验证的内容还是一样的(测试要提前提供这些场景对应的用例给开发),只是改为由开发操作,产品 + 测试在旁边看,确认流程可以通。

    可以辅以允许开发排期里加入自测时间这样的手段进行推进。

  • 自家 app,总归可以找开发弄一个单独的设置语言的菜单吧。

  • 现在比较新的是结合 AI 进行智能化测试。大会上也有相关的分享,甚至有一些游戏的测试已经做到可以自动确认一些任务的主流程是否有问题了。但不知道楼主对 “令人激动的新技术” 的定义是什么?

    1.手工点点点
    2.写脚本代替手工点点点

    你这里只包含执行测试相关的东西,质量保障可不只包含执行测试。

  • 点赞,英文文章或者官方文档都是很好的教材,而且不得不承认,国外大部分的文章写起来条理性很足,前因后果都会交代地很清楚,相对来说国内大部分都是类似随笔那样,只记录个结论,但是为啥会这样,不一定会说。

  • cookies 一般 web 系统用比较多,自带超时时间等鉴权常用的配置,实现比较简单。
    token 一般客户端除了 web 还包含 app 的用得比较多,因为 app 没有内置 cookies 机制,所以用 token 更方便。

    大部分情况下,二选一就可以满足了。至于你的系统两个都用了,估计是历史原因吧,比如中途切换后为了保障兼容性之类的所以保留了老的方式。然后没有人继续跟踪把老方式完整下掉,所以老的方式就继续延续了。

  • 额,这个可以变通一下,往多语言文案配置里弄 2 门特殊语言,一门长度和最短的一致,一门和最长的一致,就好了。

    这样测试的时候,排版方面的通过这两门语言就可以完成。

    这也不是我想出来的,以前 MTSC 看到有个分享多语言测试的议题里提到的。

  • 楼上这个建议很好,保持耐心是第一位的。能力不足的情况下做一些挑战性事情,效率低甚至磕磕碰碰基本是必然的。保持耐心,坚持学习和总结记录,随着你解决的问题越多,你的经验就积累起来了。

    我在楼上的基础上,补充一个点:要选择性解决问题,不要选择解决所有问题。

    比如正文里提到的 pycharm 里两种执行界面的差异,这个有阻碍你什么吗?如果没有,可以记着,但不要花太大精力去弄懂它。这属于次要问题,不重要也不紧急,记录下来,等你操作多了,pycharm 用得熟练了,你自然就找到答案了。

    新人学习,会对一切东西都很好奇,喜欢问十万个为什么。这本身不是坏事。但在没有导师或者资深专家随时解答的情况下,很多好奇心引起的、不阻碍自己学习的问题,解决效率其实并不高(因为不重要,所以大部分人并不会特意去研究,相关资料也少),反而容易舍本逐末,影响学习热情。这个工作中也是一样的,不是所有问题都需要解决的,解决核心问题,能办成事,这个才是最重要的。 Done is better than perfect

    最后,针对你提出的两个问题,解答一下第一个问题:为什么表现形式不同
    答:选择的运行配置不同,所以不一样。在 pycharm 的 run configuraion 里,有多种运行配置可选:

    选择 python ,是通用性最强的,所以界面也是最简单的,直接展示 console 输出内容。
    选择 pytest ,是定制型最强的,所以界面针对测试这个场景有更适合的展示方式(如分别展示每个用例的运行结果)

    你点击 if __name__ == "__main__" 前面的运行按钮,pycharm 自动会当做通用的 python 脚本去运行(印象中是),因为他没法判定 main 里面跑的是啥。
    你点击用例方法前面的运行按钮,pycharm 会自动用 pytest 去运行,因为它已经识别出这是个 pytest 用例了,所以才给你便捷的一键执行按钮。

  • 排版问题,核心主要和文本长度有关吧?

    从多语言里选最短文本、最长文本,两个都能 hold 住,应该就不会有太大问题。

  • 求一个 qq_openid at July 07, 2022

    额,为啥会这么问呢?先不说这涉及到私人账号信息不方便给,就算给了你也用不了,因为不是同一个应用,不通用。

    OpenID 是此网站上或应用中唯一对应用户身份的标识,网站或应用可将此 ID 进行存储,便于用户下次登录时辨识其身份,或将其与用户在网站上或应用中的原有账号进行绑定。

    https://wiki.connect.qq.com/%E8%8E%B7%E5%8F%96%E7%94%A8%E6%88%B7openid_oauth2-0

  • 从正文看,楼主其实已经选择了写真的了。剩下的只是怎么写的问题。

    建议:
    1、项目经历里,重点写你在 IT 行业期间的经历,其他行业的放在末尾略写,让看简历的人专注看 IT 的经历。工作经验也如实写你在 IT 行业的年限。
    2、如果担心别人会因为你中途转行淘汰简历,可以加一段文字专门说明下。

    基本上招聘的目标是找到能力匹配、薪资匹配的人。至于是不是中途转行,不纠结的自然不纠结,纠结的你也改变不了什么。