是的，目前兼容 apk，以后就说不准了

我们部门之前就有这个倾向，按了一年，因为组织架构调整，死灰复燃了。

学习下~
之前我也准备转到 agileTC，不过由于离职的太多，搁浅了。
另外由于项目要求必须向下兼容，所以目前 git 管理用例还行。

这里应该 H-G 吧。
另外整个流程不就是递归的吗？

加个约定俗成的缺陷类别就行了

路径去掉空格换行什么的试试

跑一下把请求返回以及对应的第三方请求返回录下来

1. 哪个顺手用哪个，我的经验是开发用啥我用啥，资源不够的时候好抓壮丁
2. 根据需要自己组合就行，哪儿有什么好不好的。。。你这和 java 好还是 python 好这个问题差不多
3. 涉及到第三方多的，一定要便于录制，比如自动录制 mock 数据什么的

我在 LeetCode 刷到过，原题及题解帮你找到了。
https://leetcode-cn.com/problems/department-highest-salary/solution/bu-men-gong-zi-zui-gao-de-yuan-gong-by-leetcode/

毕竟人都是活在预期中的。超出预期一次，就是压榨的开始~

流程跟不上研发节奏，标准化不接团队地气，没有形成团队共识。

这是流程化、标准化的工具的通病，很多流程化、标准化的工具，慢慢的被变化的团队结构和研发流程所遗弃或者选择性使用了。

根据实际情况来吧，有些公司或者个别领导，就要那些用不上自己也不看的玩意儿，或者蹭点数据去做汇报。
美其名曰：数据支撑。实际毛用没有。

发个风险邮件完事儿。测试报告不用自己写的，也没人看，自动生成了。

用的最多的是流水线和 xmind，其他都和代码一起管理了。

ok 了 3Q

我那个可以改下用户名吗，自己改不了。

就是在改邮箱的时候提示的。。。

这个咋整，github 登录的，改不了邮箱

mark 下

看这个错 金额计算用了 double 么

伸手党来了，java 有类似的包吗~

把他们习惯的操作封装成更简单的操作，以及做下易用性兼容

只说我自己的做法哈，可能有一定项目特殊性。

由于我们接口（http 协议基于 XML 交互的接口）请求参数非常多，而且对所有空字符、null 等都很敏感，对所有参数要求和文档定义一致，但是产品给字段定义比较痛快，所以我会在接口还没开发但是给了定义文档的时候，根据这个接口最全的字段做一个请求模板，根据这个模板，程序会按规则依次按照每个 XML 结点空、null、字段范围定义等规则，去跑一些 定义之外 的测试（单因素法）。一般会和开发约定此类报错给一个或者一组错误码，用来验证结果，拼接测试报告。

由于基础规则几乎所有接口都差不太多，所以只需要预设一个请求模板就行。用例设计更多关注业务的参数组合。