是传统瀑布（就是需求评审 - 开发（同时写用例）- 接口测试 - 测试），还是敏捷啊？

无论瀑布还是敏捷，都是这个流程，因为确实有先后顺序（难道还能不出需求就开发吗？难道还能没开发出东西就测试吗 ），个人理解核心区别在于每个阶段的时长，以及每个阶段具体包含的要素。

【以下个人理解，可能不对】
瀑布模型相对久远了，现在估计很传统的软件开发（传统 toB）或许还在用，它强调的是单产品单时间只有一个版本或很少的版本分支，后面的阶段要等前面的阶段完全结束，每个阶段要有十分完备的书面文档。在当年硬件资源匮乏，发布难度高，客户关系比较稳固，客户对交付日期要求比较松的大背景下，会有一定的科学价值。

敏捷上，网络资料更多，应该没有 toC 的公司不走敏捷模式，只是标准和不标准的区别。与瀑布最大的区别就是发布时间更短，每次发布带更少的特性，强调快速发布试错、拿到时长反馈、迅速迭代特性，这个方法论与现在公司竞争用户市场的局面下显得很适用，具体理念 11 楼 贴的链接已经说明得很清晰了。

另外，流程建设是要分阶段的，人少产品小的情况下就应该轻量高效，因为人少就不会存在严重沟通 gap，有啥事你在工位吼一声大家都知道，这个场合下强调敏捷，要不就是领导者希望团队提前建设相关氛围方便后面扩张人员，要不就是领导者单纯想实践一下这种模式。case by case，适合才是最好的。

结合自己在工作中观察 leader 对小组成员的不同评价，跟文章很多理念是切合的。

不过有些细节看得不太过瘾，比如对于技术和业务，应该如何区别评价？好业务和坏业务，应该怎么分摊收益或激励？好业务里中等水平的，跟坏业务里中等水平的，是不是本质上就有差距等等…… 这些细节如果未来有机会再开帖子阐述，我继续捧场

“背锅” 这个词其实我们内部经常调侃，但是严谨的含义其实还是责任分担。这个帖子抛的问题不严谨，从表述上看就有点测试与研发对立的意味，所以下面的探讨也不打算十分严谨。

17 楼槽神其实已经说到点了，我也罗列一些其他点来辅助一下：

公共视角

1. 有业务才有测试，业务没了测试就不用存在了，所以从饭碗角度来看，是不是要为自己的饭碗负责，质量做好一些，即使业务在走下坡路，也不至于死得更快
2. 如果这个生产事故的避免难度并不高，那我作为老板，就会考虑花同样的成本能否招来另一群能避免这种事故的测试，然后老测试就被新测试干掉了
3. 研发的真实想法：测试不为产品质量负责 -> 测试没必要参与到产品技术的重要决策 -> 测试不影响产品发展 -> 测试没有地位和话语权 -> 测试是一种随意使唤的资源；我想没有一个人愿意被人当成低级资源使用

个人视角

1. 一个具备专业素养的人一定是对自己的职业有所敬畏，会有基本要求，那么职业上的专业性必然使得自己去为问题负责，去寻找解决方案
2. 成长的机会总是潜藏在风险中，线上问题是最宝贵的实践经验，也是结合公司内部环境大家都可能会犯的毛病，应该把问题摸清楚，问题现象、成因、排查、修复、避免 等一系列要素都要整理出来，成为自己的竞争力

Get

昨天开始，通知恢复正常了，一下子一百多条历史通知，终于可以消费了！

上面已经回答得很好了，我来蹭蹭热度，我觉得的问题有几个：

1. 开发自主优化，私下找你出时间测试 —— 不正规的流程，私下对接的工作不公开，做了事情没人知道，出了锅又无法撇清关系，吃力不讨好。建议让他走正规流程提测，对清楚排期，一般分 “产品需求” 和 “技术需求”，两者可以用不同的测试方式，“技术需求” 你可以要求开发给进出改动细节，一起去评估测试范围和测试用例（产品新增功能需求可能会较少做到好的代码改动评估）
2. 找你测试，但是描述很模糊，导致你不知道要怎么测 —— 这种情况下测试同学就很被动，不去追问细节的话，最后线上出质量问题肯定第一个还是找测试盘问。建议让他澄清改动，否则不排期测试，而且设计出的用例一定要跟他一起评估（出锅一起背，很合理），直接无脑回归，一方面是浪费自己的时间，一方面对自己确实没有思考没有成长纯粹的工作量，从公从私出发都是不利的
3. 手上最近工作也很多 —— 公开你自己的人力排期甘特图，或者其他形式都行，只要是对外公布你手头的事情，这个信息让别人获取到，只要是讲道理的人都知道不会再乱给你事情，插事情进来优先级评估好各方确认就没问题。

所以说，正规的流程，对大家都好，不用再顾虑太多人情世故，大家都遵守规则就好。

首先，测试我理解是一个动作，质量保障是一个体系，不要把自己设限在测试这个动作执行者上。
然后，认可业务价值，理解业务发展，有业务合作落地经验，能度量数据，能改进过程，能发现痛点定义问题找人解决，事情去到你手上能成功落地（但是别人就做不到你的效果），这是业务能力，也是质量保障中的业务方向。
再来，也是大家一直说的技术，其实我觉得如果单纯谈 UI 自动化、接口自动化等事物，已经被玩坏了，业界现成开源能用的方案比比皆是，如果钻研技术不是个人爱好，完全可以就着业界现有成果拿来主义解决问题，不能把 “技术” 定义得太死板。

还是要多从质量保障的初衷目标去看，从上下游质量痛点去看，这个时候质量保障 sense 更重要，举个简单例子，比如发现研发排查问题需要在几个平台上反复横跳效率低下工作困难，我们能否做链路跟踪日志管理平台等。

当跳脱出常规的需求测试之后，其实质量保障的空间还是很广阔的，甚至可以把开发的领域建设都卷过来做。能力衡量上，就是前面说到的几个点：

1. 最重要的是质量保障的 sense，这个决定了你能否主动出击识别问题
2. 其次是逻辑目标规划等能力，一方面是你的视野（关注别人和业界，消化技术信息），一方面是你的经验（实践与思考），这个是往上爬的必备要素，面试过不少十多年经验的同学，技术开发经验很丰富，但是带人能力差，欠缺规划和思考，所以只能局限在【个人共享者】的角色
3. 基础技术能力，之所以放在第三，是因为我觉只要技术能支撑 idea 实现就好，结果导向业务导向，最终可以去到学习能力和技术理解力

5 年也太短了，一眨眼我自己都毕业多年了，刚实习那会自己尝试维护内部的测试平台，结果搞出了糗事的，都还历历在目。个人觉得 5 年还很明显是一个上升期而不是瓶颈期，如果真的 5 年就到了瓶颈，要不就是能力太强学东西太快接触事物很多，要不就是自己设限画地为牢限制了自己成长。

这个后续会有同学排查问题么？ 继续收不到关注人的动态通知，只能收到回复的信息通知

借老哥宝地，发一下字节 移动端端专项测试 的招聘帖：https://testerhome.com/topics/31151

已经几周都收不到我关注的人发的帖子了，关注通知功能已经挂了一段时间。

（我瞎回答的）看一看 atx-server 有没有默认做了 CORS 配置，将其设置为不生效试试（牺牲了安全性，但如果是内部系统，风险相对低一些）

20 楼正解。

楼主这个写法就是不正确的，url 它如果是全局变量就应该在 setUp 里面完成初始化，你这样的实现，每个测试用例之间就不再是独立的，其他用例都要耦合 test1_login 中对 url 变量的赋值，受到它的影响。

另外，你原本报错的那个 TestCase，留意到函数名写成了test_10_getonemain，test 后面带了个下划线，命名规范跟之前的所有测试用例不一致。网上搜索说 python unittest 是按照 TestCaseName 的命名 ASCII 来排序的，所以这一点也会影响实际的运行顺序。最好的规范就是，所以需要统一命名格式，不要人为设定 TestCase 的运行先后顺序，它们之间应该是独立的，如果耦合，那就应该拆分成多个 TestCase ，或者在单个 TestCase 内重新写一遍

self.url 是个 None，path 是个 str，那自然无法用 + 操作符链接。

问题原因：self.url 为空，根本就没有初始化，代码 bug

该走就走，消耗自己的时间就是对自己不负责，考虑一下我们团队呗：https://testerhome.com/topics/31151

先回答楼主原先的疑问：

Python 不足以支持问题排查时，Java 要学习到什么程度，才能进行接口调式和问题排查，能够看的懂代码

如果只是常规的 web 前后端代码，如果要读懂并且能调试（先不说要自己实现编码吧），其实难度一般，Java 基本语法熟悉了，业务使用的框架（一般也就是 spring 全家桶吧）的一些基本用法，或者业务实现中你看到的用法都了解了，这个程度就够了。

其实不需要你对框架、对 Java 底层有多少了解，那些都是唬人的，就好比你要玩游戏玩得很厉害并不需要你去自己开发游戏一个道理。编程语言、框架都是工具，用法知道了，如果只是实现常规需求，其实大多数是熟练度的问题，深入编程语言虚拟机、框架原理什么的，只是追求更极致更优雅的编码实现。所以不要给自己设限，把它假想得很可怕。

来自一个 Java 大佬的嘲讽：我们之前有个测试，是会调式前后端代码的，直接告诉我们哪里写错了，这样就能很快解决问题

不少同学对这个开发都是负面态度，不评价这个开发的观点。既然开发不排斥你去调试他们的代码，那你就上呗（以前我对接的业务是公司的安全业务，很多代码权限都不给测试开的，我想看都没得看）。

web 后端代码本身阅读理解难度就低，逻辑清晰，多数就跟你在 web 前端操作获得的直接反馈很接近，调试也方便。这是一个学习机会，也是一个增加个人影响力的机会，可遇不可求。如果不是常规 web 后端，而是一些服务后端，也是一样，就自己多花些心思啃一啃就好了。

3 楼恒捷的观点表示认可，首先需要明确到底是什么原因导致 元素动态的变化，写出来的测试脚本不稳定 ，如果这个点没调研清楚，那上面的想法不能否认没有价值，只能说有点自嗨。

另外，NLP 将人工用例转化为代码用例这一 part 是最不靠谱的，要实现这一点的前提是用例格式是统一规范的（要推动全部人遵循规范，这个成本已经劝退了），否则我觉得 NLP 再牛逼都实现不了。

所以很多时候，大家的思路更多是从降低 编写 o 或维护用例的成本 出发来做这个事，比如做一个用例编写的 ide，支持通过 UI 点击拖拽的方式快速编写用例、或者有更好的用例工程代码封装来达到最大复用等

学习学习~

本帖持续有效嗷！！！

是的是的，这个业务讲解，一般我会讲这么些内容：

1. 团队定位，本团队负责范围，合作团队工作，双方的工作边界 —— 让新人明白为什么要做这些工作
2. 团队所有的方向，新人会接触的到子方向工作总览，以及直接接触的子工作 —— 让新人明白做的是什么工作

以上时间大概 55 开，都很重要，但是不要陷入太多细节，要把主链路呈现清楚，不分散新人的注意力

目前待过 4 名新人（社招校招均有），简单分享我的经验。

• 入职第一天的业务讲解：这个是最重要的手段，重点是如何在一个新人面前将整体业务的逻辑讲清楚，需要考量新人的背景知识是否适合，讲解粒度是否要调整，很考验导师的水平（如果讲完新人不懂，我觉得是讲解人的表达总结水平问题）
• 文档：文档以简明有重点为主，细节充足是好事，但是要能保证维护更新
• 定期 1v1：前两个月每周或者每双周要 1v1 一次，这个 1v1 学问非常大，并不是找个时间让你去给新人洗脑，而是要真实关心新人的状态。1v1 要让新人来主导，让 ta 提问题你来回答或者解决。可以从【工作遇到的挑战、工作的成就来源、团队沟通合作、工作内容感受】等不同维度引导。里面有非常多的技巧性，个人水平有限也在持续摸索
• 培训：大厂一般会有强制观看内部录制课程的机制，如果公司没有这样的机制那就只能看个人了，导师可以自行收集一些外网视频或分享会等资料，打包提供给新人，并建立简单的学习复核考察机制

上面这些点，作用最大的是首日业务讲解，细水长流靠的是定期 1v1 和适当的文档。

我接触的 UI 自动化还停留在传统的 PO 封装上，看完此文后不知道我下面的表述是否正确：

1. 组件层：这层基本上都是控件定位的封装，简单来说可能是各种 find、locate elements 等控件定位获取的操作？
2. 页面层：基于组件层对所有控件定位的封装，在这一层就是把相同页面的控件整合在一起呈现一个页面的类，看起来似乎很薄？
3. 业务逻辑层：这一层比较好理解，一个或多个页面上有业务一样的操作，比如账号登录是一个业务逻辑（当然也能说是一个用例，这里举例可能不够合适），在这一层给封装起来
4. 用例层：很好理解，如果按照这样的模式，写用例基本就是调函数了

同样没了解过，尝试猜测一下。
首先大型游戏肯定都是模块化开发的，各个组件（物理、光照、）最开始肯定都是单独的测试，可能是单测、接口测试、宿主 demo 测试，个人感觉跟 sdk 的测试方法可能比较接近。
当模块化的组件确保没有问题，开始组合成场景（不同的场景由同样的组件集合来组装，就是等价类的概念），场景中插入一些任务，这里的 “任务” 概念我理解就是业务逻辑，这个时候相当于是集成测试环节。一个 3A 游戏虽然复杂（剧情、玩法、各种要素、各种场景等），但从游戏迭代的角度来说还是应该高度自动化的（游戏 bugfix 补丁也可以去跑）。而集成测试，可能会有部分专业的人做探索测试，更多工作可能是给到外包团队低成本铺人去点点点。

如楼上所说方案，我们目前也是用方案三，自己买主机挂载手机，同时连在办公网（wifi）下，而不是放在 idc 机房。
idc 机房可能会跟办公网隔离，不同公司规章制度不一样。

长见识了…… 真不知道还会有这种坑