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

谢谢

我们之前也是直接 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 的 runner ，是运维管理还是测试管理？两个部门怎么分工？

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