• MTSC 2023 深圳站议题征集 at 2023年08月25日

    会有的,近期会放出参会报名入口并社区置顶。

  • when installing package: npm command 'install --save-dev --omit=peer --save-exact --global-style --no-package-lock appium-uiautomator2-driver --json' failed with code 1.

    这个是最表面的问题,只要程序运行不正常,都会 with code 1 。但要知道具体什么原因引起,得看下面详细日志。从你给的日志看,根本问题是底下的 Error installing Chromedriver: read ECONNRESET

  • 有点没太明白楼主具体要做啥

    为了提高网站性能,开发对页面请求做了优化

    具体是做了啥优化?请求串行变并行、请求聚合(多个接口请求合并为单个)、请求数量缩减,还是?

    有时候同样的请求会请求多次,领导让把所有页面的所有请求抓出来,做个对比。

    要对比的是啥?同个页面优化前后的性能情况,还是不同页面之间请求数量的对比(后者个人觉得意义不大)?
    对比的最终目的是啥?简单验证本次开发优化后效果是否有提升、提升多少?还是要建立长期监控机制,持续监控观测各个页面的请求速度,找出请求最慢或者页面 tti(可交互时间,详细可看 https://web.dev/i18n/zh/tti/ )最慢的 top10,进行治理?

    然后针对楼主每个问题,也说下个人的一些想法:

    1、怎么确定一个网站有多少页面

    能看到源码的话就直接看源码里 route 路径数量,多少个 route 就多少个页面

    2.用什么法子抓取每个页面下的请求,包括地址、请求头、请求体、大小、时间等要素

    这里要区分下你这个抓取要求是抓你本地看实验室数据,还是要抓线上用户看大盘数据的。
    如果是本地的,方法很多,前面提到的配置代理、直接 f12 等都可以。
    如果是线上用户的,可以接入一些前端线上监控的 sdk 来直接实现。比如阿里云的 arms。

    3、网页较多,自动化实现

    如果是线下测试用,不上监控,可以通过 UI 自动化 +proxy 来做。UI 自动化逐个打开每个网页的 url,然后 proxy 捕获涉及的所有网络请求情况并保存本地。
    如果是上监控,接入后直接看监控就行了。

  • Error installing Chromedriver: read ECONNRESET

    看报错,原因是下载 chromedriver 时网络请求失败了。检查下你的网络是否可以正常下载 chromedriver?

    如果不行,可以通过设置 APPIUM_SKIP_CHROMEDRIVER_INSTALL 这个环境变量,让程序自动判定为跳过下载 chromedriver 步骤。

  • 这个问题有点太伸手了吧。你列的这些要求并不高,大部分 UI 自动化平台应该都具备。然后这些 UI 自动化平台,通过社区的开源项目板块,或者直接搜索引擎搜索应该都能找到不少答案。找到后你再根据自己的情况去进一步筛选整理,选出最合适自己的就好。

    建议你问 chatgpt 或者搜索引擎,这样效率更高。如果真的想问大家的意见的话,可以先列一下你找过了那些平台,这些平台在你看来什么原因无法满足,然后再问大家有没有能满足你这些要求的平台。

  • 城市首选一线城市

    然后建议楼主可以投简历去面试一下,体验一下面试会问什么问题,再针对性去准备。

    按我的经验,如果没有实际项目或者实习经验,实习或者校招一般不大会问很偏测试的内容,更多问的是比较通用的内容,考察下在学校学习的基础掌握情况。基础好的,测试工具的应用以及测试脚本的编写可以很快就上手。

  • 关于 IOS 的 monkey 测试 at 2023年08月04日

    可以用 fastbot android 的白名单机制来做。

    详细直接看官方文档吧:https://github.com/bytedance/Fastbot_Android/blob/main/handbook-cn.md

  • 看场景。

    如果是单接口测试,那前置条件越简单稳定越好。这种场景推荐方法 1

    如果是场景测试,比如要完整走一遍 创建 - 获取库存 - 购买 - 减库存 ,那需要用方法 3

    方法 2 个人不是很推荐,因为测试环境数据比较多样,且有可能存在脏数据。直接获取已有商品有可能获取到脏数据,导致不稳定。

  • 点赞!学习了

  • 关于 IOS 的 monkey 测试 at 2023年08月02日

    那就不清楚了,我这没有 xcode 14 + ios 13 这个组合。

  • 不是很确定,你可以试试?

    没有维护不代表不能用,我当时找 istanbul-middleware ,就已经有一段时间没维护了。

  • 因为实际落地没有提效,所以还需要加班。

    从你描述上看,就没太感觉到这些工具平台在你们团队的落地,有起到提效作用。可能你们耗时最长的部分,就不在你们现在花精力提效的部分。

    我目前接触到能起到提效效果的,基本都是先手工测试并且明显感受到有些地方比较重复繁琐,评估提效方案和预期能起到的提效效果,然后再落实提效的。没有前面的评估分析,只是单纯别人有我们也需要有,很可能最后起不到想要的效果。

  • Monkey 的操作间隔,以及执行量一般是个什么策略呢?

    操作间隔我们没有特别设定,反正上一个事件跑完下一个立马接上。至于执行量,这个由业务根据情况设定,一般至少跑 2 个小时。

    还有这两个,自动遍历型、随机时间型,大致是个什么意思呢?

    自动遍历型,指的是这个程序会识别界面内容,把可以打开的界面、可以点击的按钮全部点击一遍,把程序整体进行遍历。最典型是字节开源的 fastbot 。

    随机事件型,指的是不会理会当前程序界面情况,只是无脑把一些事先设定好的随机事件(如点击、长按、滑动等),按一定的比重直接应用到 app 中。最典型的是 android 自带的 monkey 工具。

    从时间线以及技术难度上说,最先出现的是随机事件型,然后实际使用会发现对于比较复杂、界面比较多的应用,一些操作路径比较多才能进入的界面经常进不去,而且很容易一直停在某个页面出不去,所以才会诞生自动遍历型,解决覆盖度低的问题。在很多云测平台上,也会把它叫做智能 monkey。

  • 基于人工智能的测试流程 at 2023年07月28日

    分享一些个人对于人工智能以及如何将其转换为实际落地的一些思考。本身这方面不算专业,仅供参考。大家有其他意见也欢迎交流分享。

    个人觉得目前接触到的人工智能从大类上,大致分为两类。一类是机器学习,另一类是今年开始火的大模型。

    • 机器学习

    基本上今年之前提到的智能化测试,都属于这类。核心逻辑是把问题转换为模型,然后用机器学习,让模型输出更准确。大致步骤:

    1、把输入转变为数据(或者叫提取特征),然后对数据进行清洗、打标,产生训练集和测试集。
    2、基于场景需要,寻找合适的机器学习模型,然后用训练集进行训练,用测试集检验效果
    3、最后放到实际业务里面使用,过程进一步循环 1、2,使模型输出更精准。

    详细步骤可参考:https://www.51cto.com/article/661538.html

    目前看到过的应用场景:精准用例推荐降噪、流量回放降噪、图像元素识别等。可以看看 MTSC 大会历年和 AI 或者智能化相关的议题看看。

    优势:已经发展很多年,比较成熟
    不足:对数据比较依赖,且基本只能用于特定场景,换个场景复用度比较低。所以中小厂一般很少做,只有大厂有足够的资源进行相关基础设施建设,以及有足够大的数据规模,才比较能做起来。

    • 大模型

    这个最典型的就是今年开始火热的 chatgpt ,或者也叫 AIGC 或者 LLM(Large Language Model)。相比机器学习类,因为 openai 直接提供了很方便的 api 调用接口,所以也相对来说比较容易落地。

    目前了解到或者接触到的应用场景:业务测试用例生成、自动化测试脚本生成、代码 review 意见生成进而辅助人工 review 等。建议可以看看这个文章,里面有其他人对于大模型赋能质量保障的一些想法和探索,讲得会比较全:https://testerhome.com/topics/37001

    由于通用模型的返回太通用,很多时候不一定可以准确匹配需要,据了解各个大厂都有在基于开源的大模型,结合自己的业务场景数据,训练适合自己的大模型,提高准确度。

    优势:模型强大,且外部有第三方直接调用 api 使用的模型,接入成本很低,可以快速尝试
    不足:使用通用模型的话,返回结果还不是特别靠谱,需要多次交互才能得到一个比较不错的回答。更适合作为参谋,辅助工作。

  • 把 yaml 这个依赖库重装试试?

  • 没看明白你的问题。。。

    另外,这类问题应该搜索引擎或者 chatgpt 可以找到一些相关答案吧,可以说说这些答案是哪些部分觉得不满足,希望有其他人给你更好的意见?

  • 建议不要只看未来,也看看自己的过去,从过去中分析自己,再做选择。

    工作了 3 年,可能对自己长期想做什么还没想清楚,但对于自己不想做什么、擅长做什么应该是有比较明显的感知了。可以总结下自己擅长什么,然后从擅长点出发去寻找合适的方向。比如擅长业务逻辑的梳理设计的话,可能相比测试,产品会更适合你。

  • "增删改查的用例" 这个信息有点模糊,不知道你具体指的是纯接口,还是包含前端界面?

    另外,不是很建议你一上来就做用例自动生成。一般需要先明确用例的模板以及变化点,才好做自动生成。而你现在自动化用例还没做起来的情况下,直接做用例自动生成,难度比你直接做自动化高不少。

    PS:你确认真的纯粹是数据库的增删改查,没有额外计算逻辑么?如果是,那这些功能前端以及后端都有自动代码生成工具或框架的,只要用这些工具生成。且测试确认过生成的代码靠谱,这些简单功能甚至可以直接免测。

  • 目前使用 monkey 在工作中发现的问题较少,大家是怎么使用的呢?

    我们发版流程会固定跑 monkey,而且是好几种类型的 Monkey(自动遍历型、随机时间型都会跑)。

    上线后出现的崩溃闪退问题,Monkey 也并未出现,但是查明原因后,特定场景可以通过手工方式触发,有什么办法能让 monkey 跑出类似异常呢

    这个没办法。monkey 本身主打的就是随机型动作,特定场景特定操作步骤的事情,不是 monkey 测试范畴要做的。通过跑 monkey,可以快速发现应用是否存在高崩溃率问题,但没法保障所有崩溃或者异常都能跑出来。

    要有效控制实际用户手上使用的崩溃率,一般需要通过崩溃监控平台 + 合适的灰度策略,逐步放量并通过监控平台查看整体崩溃率,如果过高就从 top 1 崩溃开始修复,直到崩溃率达到公司或行业标准。

  • 不想一直做重复没有意义的工作

    可以把自己目前最重复的工作,变成由机器自动完成,节省自己投入开始。自己的事情自己掌控度是最高的,而且做出来确实给自己省力,成就感也强。

  • 使用 mock ,和单接口、接口场景是相互独立的关系。单接口或者接口场景都可以使用/不使用 mock,取决于你的需要。

    单接口、接口场景主要是指用例测试内容。单接口是只关注一个接口,接口场景一般是关注多个接口。

    而 mock 则是通过直接固定外部系统的返回内容,解决涉及多系统交互时,外部系统难以控制,影响稳定性和场景丰富度问题。

  • MTSC 2023 深圳站议题征集 at 2023年07月25日

    都欢迎参加~

  • 信息有点少,而且也不清楚你现在个人能力情况和你自己的目标期望,很难说建议你选哪个。我按自己理解分别对两个做一些简要分析,你看看哪个适合你自己吧。

    创业公司 001 QA:高风险高收益,容易变成多面手和随着业务增长自己获得上升。比较适合你已经有很不错的技能和体系,想挑战一下从零到一。不过前期杂活估计会比较多,如果股权不多,没有太强的和公司同进退的想法的话,慎重选择。

    热门爆款项目专项大头兵:比较适合专注深入技术,可以获得一项比别人有优势的技能,不过上升机会可能相对少一些,要耐住性子出成绩。

  • 学习了,怪不得我的搜狗输入法是不是会抽疯。。。

  • Hmm,就一个 001 号 QA 的信息,不知道可以给啥建议😂