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

首先，测试集、测试任务这块是本身 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 的 runner ，是运维管理还是测试管理？两个部门怎么分工？

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

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

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

好奇问下，你持续执行了多久？

我们刚接入云真机 ATX 的时候有测试了一下 wda 的持续运行稳定性，大概持续执行自动化 2.5 小时左右就会扛不住，提示连不上，得重启才能提供服务。配合 tidevice 的 wdaproxy（自动监听 wda 是否挂了，自动重启）可以做到自动重启。

但也见过有的手机死活重启不了 wda ，tidevice 一直报 socket 连不上，必须手动重启手机才能恢复。

看下你电脑是不是有别的程序会自动启动 adb ？可以看看进程列表里有没有。

jenkins 的 pipeline 可以控制多节点（前提是你有多节点）跑任务，但没法细到用例级别吧。

建议用 pytest ，匹配度最高，也简单（用多线程，比多节点成本低）。