哦哦，明白。

和我这块确实不大一样。我这里的 diff 除了展示，还需要具备给用户直接复制粘贴，重新应用的能力，所以展示方式使用了脑图，而不是 json 之类的纯文本展示方式。

我的展示效果大概是这样的：

服务端相关的代码改动及配套单测，已提交 PR 给官方。地址：https://github.com/didi/AgileTC/pull/93

增量生成、应用、标记的逻辑全部在 case-server/src/main/java/com/xiaoju/framework/util/MinderJsonPatchUtil.java 这个工具类

配套单测在 case-server/src/test/java/com/xiaoju/framework/util/MinderJsonPatchUtilTest.java

哈哈，看来大家都殊途同归。

下面介绍的 start end 坐标字段，有点没太理解具体是什么的坐标。可以写个示例么？目前节点坐标信息我是通过 json-patch 里面的 jsonPointer 直接拿的。对于子节点数组型用下标会不准，我是先把 array 都转成 object ，key 是节点里 data.id 的值。

看了下官网，找到答案了：

鸿蒙的 app 不再是 apk 格式了，而是 hap 格式？

好奇问下，实际落地怎样，各个团队的测试人员愿意用单测框架写代码的形式，来记录用例信息，和登记测试结果么？

嗯嗯，我们主要用来写用例、评审用例和执行用例，作为测试平台的用例管理模块，也用于作为测试过程数据中测试进度、用例数量的量化指标来源。

不同项目组在整个测试流程上还是有一些差异的，暂时还没统一，所以暂时也不需要太复杂的，我们更崇尚 less is more ，专注做好一个功能就足够了。用户权限这个官方的最新版已经加上了，看板这个，我们内部有用另外的项目流程管理平台，看板用那里的足够了。

至于单任务关联多用例集，以前有想过，但其实维护成本和使用成本都很高（要不用例集拆得很碎方便组合，要不任务关联能力要很强能任意选择部分用例）。实际上，只要有历史用例集和复制粘贴，就可以完成类似目的了。

这是个 bug，我周末查下啥原因，修复下

好奇问下，你们现在手动测试用例是怎么编写和记录测试结果的？我们这边基本都是 xmind 为主，少数无界面可以直接 api/单测测试的，就直接写代码/上对应测试平台写用例。

哈哈，其实我 title 确实是测试开发。

非常赞同你对 “测试开发” 和 “自动化测试” 两个概念的阐述。在我们公司，自动化测试要求是社招的所有 title 带有 测试 的岗位都需要具备的。

最后这个 “而且要求具备对测试流程的理解”，也非常认同。确实这个需求其实不是一开始就按这个需求方案做的，甚至因为这个方案的复杂性，想过各种 “绕过” 的手段。但最后发现确实没有更好的手段，所以才最终选择啃下这块硬骨头。

手工的测试用例也是用单元测试框架来做吗？

谢谢

我们之前也是直接 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 文档就可以满足了，没有那么强的需要。真有强需要的，也基本有自家模板，需要适配定制，对你们来说投入产出比也不高。更关键的是，如果购买方是测试团队，相比流程，需求更大的应该还是你前面提的技术、工具。流程这块一般是公司整个研发团队甚至全部工作项的管理，才会有采购需求。