• 谢谢

  • 我们之前也是直接 git 管理 xmind,但发现很容易后面改动后的用例就没再同步了,而且也不好直接统计通过率、用例数什么的,所以用了 agileTC

  • 大概看了下这篇文章,好像没提及 xmind 这种格式?

    非常认同你的观点,能用已有成熟方案的话,尽量用,避免自己造轮子。但 git 可能在这个领域,经过我的思考,不一定适用。git 适用的领域主要是纯文本,对二进制文件相对比较弱,基本就是全量更新。

    xmind 文件本质上比较接近于 xml ,但实际存储格式是非纯文本,在 git 里面基本都是全量更新。而在线脑图 kityminder 可以将其以纯文本 json 格式存储,理论上具备可行性。但实际上,这个 json 和脑图看到的内容,直觉上还不大能直接关联起来。

    举个例子,脑图 json 如下:

    {
        "root": {
            "data": {
                "text": "百度产品"
            },
            "children": [{
                "data": {
                    "text": "1",
                    "resource": ["自定义标签"],
                    "priority": 1
                },
                "children": [{
                    "data": {
                        "id": "cc3eeotpqsg0",
                        "created": 1623679673934,
                        "text": "1.1"
                    },
                    "children": []
                }, {
                    "data": {
                        "id": "cc3eepzptug0",
                        "created": 1623679676474,
                        "text": "1.2"
                    },
                    "children": []
                }]
            }, {
                "data": {
                    "id": "cc3eerciow00",
                    "created": 1623679679425,
                    "text": "2",
                    "layout_mind_offset": {
                        "x": 405,
                        "y": 80
                    }
                },
                "children": []
            }]
        },
        "template": "default",
        "theme": "fresh-blue",
        "version": "1.4.43"
    }
    

    对应实际脑图是这样的:

    这还只是一个很简单只有 3 层、5 节点的脑图。如果是日常过千个用例,数千个节点的脑图,出现冲突看着 git 里面的 diff ,真的会一脸懵逼呀。

    同时还有一个问题,就是测试任务场景里,很可能用户看到的只是子集而非全集,这个时候可以理解为看到的版本和实际用例版本不一样。git diff 是基于行号 + 改动内容前后数行内容来定位的,如果是测试任务的场景,很容易因为改动内容前后数行和全集不一致,直接理解为冲突。

  • 好问题,我这里补充说明下吧。

    首先,测试集、测试任务这块是本身 agileTC 的已有设计,测试集用于存储测试用例,测试任务用于执行用例。测试任务可以在用例集中筛选/全选用例,进行每个用例的测试结果登记。但测试用例不能修改用例,要修改用例必须到用例集编辑界面(此界面无筛选功能)

    在我司的实际项目使用中,常见用法是:

    1、项目前期主要是少数 1-2 人参与,他们根据需求及技术方案,完成初版的完整用例,并在里面标记开发自测用例。用例评审用的也是这一版。
    2、提测前开发自测时,测试会创建对应的开发自测用例并给开发参照执行、登记结果。
    3、提测后,用例会分给多人执行(人数可能不止前期的 1-2 人),会通过自定义标签形式记录这批用例是谁负责。此时会通过测试任务的筛选条件来筛选到只剩下此人负责的用例,单独进行执行和登记。

    实际执行中,可能会由于需求变更、部分需求细节需要补充等原因,在 2、3 步经常需要更新用例集。虽然也可以到测试集进行更新,但测试集合计会有过千个用例,而测试任务则只有数百个,因此在测试任务中就进行更新,相对而言会更为方便。

    由于总用例集需要用于进行一些数据统计和二轮测试用,所以此时也需要更新。基于此,所以做这个增量保存的功能。

  • 我加到问答区顶部说明提醒了:

  • 我分享下我当时的学习路线,你可以参考下:

    1、看苹果开发者网站的 object-c 教程,理解 oc 的基本套路(比如 .h/.m 的区别,函数及类的定义,内置数据类型等)
    2、看苹果开发者网站一些指引教程,比如经典的 todo list app,会从 mvc 分层设计开始,先定义每一层的 .h ,然后再实现各层的功能,手把手级别的教程实现人生中第一个 ios app 。(刚找了下,苹果官网已经没有这个例子了,新的例子是 https://developer.apple.com/tutorials/swiftui
    3、看一下网易公开课里 ios 开发课程,我当时看得斯坦福的课,不过讲得比较深,所以是当时春节前相对事情没那么多的时候集中学习的,没全部看完,大概看了前 5 节左右。现在慕课什么的课程应该也挺多的,可以找个合适自己的看,边看边自己按照里面写得去实现代码。一般这种教程没有第二步那么手把手,刚好锻炼下自己怎么通过思路描述去完成代码编写。
    4、完成第二步后,其实也可以开始在项目中看开发代码了,主要看本地迭代开发修改的内容,因为自己知道实现的功能有哪些,感受会更明显。开发代码建议越早看越好,因为很多入门课程都在教你怎么用 storyboard ,但实际项目为了方便复用,很多都是直接用代码手撸界面的,会有种教程都在 level 1 ,实际项目直接跳到 level 5 这种感觉,所以早点看代码可以避免自己陷入自己已经完全懂开发这种错觉。

    基本上每天抽 30 分钟-1 小时做这些,第一步大概花了 1 周,第二步 2 个周末(需要完整时间,避免思路被打断),第三步春节前大概 3-4 天(也是比较完整的时间)。

  • 这经历好励志,继续加油!

    你的所思/问别人的问题决定别人对你的看法。

    这句话最近也深有感触,共勉。

  • 刚爬完楼。分享下我的观点:

    问题一:试下点击应用内其他非输入框的空白处,是否可以隐藏?
    问题二:不确定你们开发有没有用自己额外自定义的 UI 组件(这个从 pagesource 看不出的,因为控件树拿到的类名,都是 iOS 系统提供的少数几个基础类,有可能和开发写代码时看到的组件封装好的名字完全不一样。属性名同理)。

    XCUITest 获取到的元素属性,应该只有基类固定的几个,如果用了其他的属性来存,有可能 XCUITest 获取不到。建议你问下你们开发,或者直接找开发拿项目源码来看看吧,看下怎么存的,放到了啥属性值里。 xcode 本身也有自带查看整个界面层次结构的工具(可以看看 https://blog.csdn.net/PZ0605/article/details/50670285 ),这个工具相对会更可靠。

    PS: @ 醋精测试媛 看到你做 UI 自动化已经有一段时间了,也发过不少求助帖,确实也是一些网上不容易直接搜到的疑难杂症。个人经验,这类问题之所以不常见,和你测试的应用具体怎么实现是强相关的。所以网上其他同学能给到的大多只能是参照思路,真正去探究到核心原因以及怎么解决最合适,还是需要你去熟悉被测应用的源代码,辅以熟悉 OC/Swift、XCUITest 框架以及 iOS SDK 提供的各个基本的 UI 控件,能搞清楚每个基本控件的属性和 XCUITest 乃至 appium 拿到的属性的对应关系。

    提个小建议,可以到网上找门 iOS 开发入门课学一下(我当时看得是网易公开课里斯坦福的 iOS 开发课,但估计有点老了,你可以找下新的)。不要求学到能自己独立写 app,但仿照课程内容写一遍后,能让你对 iOS 开发的套路有大概的了解,也便于你后面看源码、和开发准确交流。

  • 这个提醒我了,还有开发版操作系统强开 debug 这招。话说以前一般真机上用小米的开发版系统做,现在这方法还能走得通不?

  • 感谢支持。客户端性能方面我也只是入门,分析调优这块大头目前接触还比较少,算不上大佬哈,只是分享点个人经验。

  • 简单版这样足够了。

    第一点重复性工作太大,可以考虑用 airtest 之类的可以低成本做自动化脚本的工具,把你的自动化脚本弄出来。

    第二点报告怎么分析,这个你得先确定通过指标(怎么算通过,怎么算不通过),然后看报告里面有没有不符合指标要求的,不符合的再进行具体分析。

    一般最关注的是
    CPU 占用高不高(影响耗电量以及发热,一般应用最高应该在 15% 以内)
    内存是否有泄露或接近系统内存的上限(重复操作这个场景 5 分钟以上,内存会持续上涨且不会回落。内存占用达到系统上限后,会被系统强制杀掉,给用户感受是偶发性闪退、应用不稳定)
    是否卡顿(看 Jank 以及主观感受,给用户感受是不流畅)。

    另外,机型选择,建议也结合线上用户使用占比来决定,优先选择整体占比高的或者高价值用户(如大额消费的用户)用得多的,不要拍脑袋。

  • 不过我也只是互联网公司的经验,可能有的传统企业有这方面需求。这块还是要以你们受众的需求为准。

  • 哦哦,明白了。那你们场景和我以前的不一样。

    从我的经历看,每个公司这方面的流程都不大一样,用的系统也都不大一样。经历了 4 家公司,除了 jira ,没见到两家公司用同一个流程工具的。而且虽然用 jira ,但自定义的工作流也是有不少差别的,基本都不会用自带的默认流程。

    如果你们是在初创期,建议先专注做自己特色吧。测试计划、测试报告在不少互联网企业,可能一个 wiki 文档就可以满足了,没有那么强的需要。真有强需要的,也基本有自家模板,需要适配定制,对你们来说投入产出比也不高。更关键的是,如果购买方是测试团队,相比流程,需求更大的应该还是你前面提的技术、工具。流程这块一般是公司整个研发团队甚至全部工作项的管理,才会有采购需求。

  • 这么说吧,原理上,不提供 debug 包,或者更明确说,应用包里面 webview 没有打开 debug 开关的话,那就没法从 webview 内核拿到元素树等信息,也没法操作里面的元素。

    这种情况下,图像识别是目前认知里面唯一能用的招了。

    如果你的 h5 功能和 app 没有耦合或者调用,那还有一种方法,你另外用浏览器单独测试这个 h5 。

  • 用 airtest 之类的,通过图像识别来做?

  • 好奇想了解下,一线团队忽略流程,忽略的是什么流程,他们反馈的是什么原因?

    我们以前推一些流程,比较有效的做法是问题驱动。比如多次开发不经过测试评估直接上线出问题,就上线流程上改为只有测试才有权限;开发自测经常没做好冒烟不通过,就直接改为开发演示,在测试和产品面前演示核心流程可以跑通,然后直接提测,测试也省掉冒烟(开发演示的和冒烟的内容差不多)。至于没怎么出过问题的地方,也说明团队已经磨合好没太大问题,所以推流程急迫度也不高。

    我们流程推动,一般都是先有流程并开始小范围试点,这个阶段主要靠领导强推和持续反馈。跑通了且有效果,再工具提效和巩固。

    流程最终落地靠的是一线的同学,自顶而下可以破局,但如果下面持续不认可,最后这个流程其实也落不下去。这个时候领导也容易觉得这个流程其实推不推关系不大(本来就没做到位,自然出不了效果),继续强推反而容易反弹,也不会再继续强推了。

  • 嗯嗯,明白

    我们之前用 dubbo ,本身底层选择的就是 http 协议,所以做接口测试和普通的接口差异不大,http 的工具可以复用。不过你们开发如果不允许换的话,那就只能从外部绕了。

  • 对,具体不是我装的,是同组的其它同学弄得。我周一问下他。

  • 我们用官方的 docker-compose 安装,好像没啥问题。

    倒是后面改为实体机安装,费了不少劲。

  • 好奇问下,dubbo 的传输协议,本身就支持 http 的吧?而且这个内部配置对 rpc 调用来说是无感知的,是否有和开发沟通过,测试环境切换为 http 协议,方便测试?

    https://dubbo.apache.org/zh/docs/v2.7/user/references/protocol/http/

  • 这个真的没能想到什么通用的标杆,只能说句正确的废话:能提高测试效率的就是标杆。

    建议可以先去业务团队做几个迭代测试,自己记录下自己觉得低效的地方,也和团队聊聊看大家是否也是相同的观点。如果有共同点,把它工具化、平台化就对了。举个我司的例子:
    1、每个迭代的用例,用 git 仓库管理,容易更新不及时和遗漏——搞用例管理平台,统一管理,在线更新
    2、每次发版都要跑 monkey ,但 monkey 对环境要求比较高,很多时候跑起来还得一个人调半天环境——搞个内部云测平台,一键选设备跑 monkey

    有没有搞到 100 分不重要,只要这个功能是大家需要的,大家也喜欢用,那就没问题了。

  • 我的理解:

    1、流程化和标准化其实都很重要,也有不少 devops 的文章有提及先标准化,后工具化这样的顺序。但实际做起来,成本高、见效慢、不可控因素太多,要真的做好需要天时地利人和,特别是上级领导的协助。而且很多时候测试团队在研发团队地位并不算高,自己的活都没能做的非常出彩,这时候去推动外面改变基本是不大可能的。所以做得好的相对少,做得好且大家看得到的更少而已。

    2、流程化,标准化的工具却渐渐式微,我觉得只是这方面工具不再是由测试来做而已吧?tapd、jira、云效、teambition、乃至禅道,都挺多团队用的呀。只是这方面的理念这几年好像也没什么大变化,所以这些工具不管新老,用起来觉得合适就继续用下去了。

    3、不用标准化的流程,不用测试计划、测试报告 这个,我待过的一些互联网公司,测试计划和测试报告确实有时候会省略,但只是不记录为正式文档或邮件,过程中还是要有计划(或者叫测试排期,确定测试内容,根据资源给出预计测试时间)和报告(或者叫测试结论,先说是否通过,然后说风险)的。至于标准化的流程,不知道楼主所说的标准化流程是怎样的?

  • 测试平台 - 集成 Gitlab-CI at 2021年05月28日

    想了解下,你们 gitlab ci 的 runner ,是运维管理还是测试管理?两个部门怎么分工?

    我们之前用 gitlab ci 的时候,因为 gitlab 是运维管理的,所以 runner 也是运维管理。有些时候要装别的插件什么的或者出现本地无法重现的错误,都需要找运维协助,比较麻烦。后面 runner 迁到我们主机后,会好一些。而 jenkins 就是我们自己完全管理,相对方便一些。

  • 测试平台 - 集成 Gitlab-CI at 2021年05月28日

    这个是用 gitlab ci 取代 jenkins 完成部署和测试任务的触发?

    只用过 gitlab ci 做一些组件库的自动测试和发布,没试过做镜像构建和部署之类的。用起来方便么,有没有什么坑?