我不知道平台搭建后是否真正牛逼了，但是它的建设至少对测试团队的影响有如下几点：
　　1、增加了团队的技术含量 (至少领导不会认为我们只会点点点)；
　　2、提高了团队的作战能力；
　　3、提高了测试效率（因人而异）；
　　4、降低了成本 (待查)；
　　5、提高了产品质量 (待查)；
　　6、降低了学习自动化的难度；

从前文来看，你们的自动化测试平台只是用来方便自动化测试运行和统计用的，跟你总结的 6 点都不沾边啊。尤其是 4、5 和 6 这 3 条，这不太可能，怎么可能通过你们这样的测试平台得到这样的结果呢？

这种分散的自动化测试带来的弊端就是：1、数据无法可视化；2、脚本维护难；3、增加了学习成本；4、易用性、移植性差；5、无法统一管理；

为什么 2、3 和 4 的问题会是分散的自动化测试带来的？二者并无直接关系，可以详述吗？

等你的解决方案，希望你成功，点赞你这种发帖有始有终的精神。

有些用例就是专门测试覆盖安装后的具体行为表现的，这时候覆盖安装就是这些用例的前置条件，是必须做的了

“平时各种写脚本辅助工作。也有工具分享”，能不能举些栗子，辅助过哪些工作，分享过哪些工具？

从项目管理的角度看使用真实账号和个人账号都不是规范的做法。
使用真实账号会带来信息泄漏的问题，使用个人账号还要考虑这个人如果离开项目组的问题。

可以使用支付宝沙箱，创建一批专用测试账号来做验证。
这批专用测试账号也需要归入项目资产。

桃花过处寸草不生，金钱落地人头不保！
希望你不会成为 “受害者”。

1. 中间件是第三方产品，为什么会成为你们的 test target 呢？
2. 调度规范由中间件供应商来保证质量，为什么会进入你们的 test scope 呢？
3. 你们是怎样评审 test plan 的呢？

问题还需从根源解决吧。

为什么产品经理不在 PRD 里直接要求使用某种具体的技术？因为产品经理不懂技术也不需要很懂技术。开发团队实现了他的产品需求，他甚至不知道开发团队使用了哪种技术，他关心的是产品需求的各项指标是否得到实现和满足，包括但不限于功能、性能、易用性和兼容性。
同样的，测试团队也不需要知道开发团队使用了哪种技术，测试团队关心的也是产品需求的各项指标是否得到实现和满足。实现分布式消息系统可以有多种技术，测试团队要做的是站在产品经理和最终用户的角度，对不同条件的输入去验证系统的对应输出，是否达到了产品经理的设计。至于测试方法，万变不离其宗，等价类划分、边界值、因果图…
这解答听起来就是照搬书本，呵呵。

不同的人有不同的理解，开发和测试去理解同样的需求，有时难免产生分歧。分歧产生的时候，不要一方试图说服另一方，因为存在双方都理解有偏差或有误的可能，正确做法是要求产品经理给予澄清说明。黑盒测试不需要参考代码逻辑，理解代码对测试团队要求偏高，会造成用人（有代码能力的人）成本和时间（理解代码需要不少时间）成本上升，这种成本是没必要的，也不会带来足够的收益。
这解答听起来就是照搬书本，呵呵。

把所有脚本统一规范化,测试流程整理明白,然后大概率转正并且管理团队,高福利

机不可失，失不再来。

逃避解决不了任何问题,于是自己准备迎难而上,顺便也是对自己的一种挑战

把思路反过来，从不同的响应结果倒推需要的参数。这样做可以规避参数间的强依赖关系。
再视具体情况决定是否需要考虑所有的响应结果。
使用常见的用例设计方法去设计用例即可，比如等价类划分，边界值等。

顺便说句，N 年前《Effective C++》里就倡导参数个数不能太多，最好不超过 7 个。这个理念对别的语言也适用。
你若提出这方面的问题，开发团队的架构师或主程应该会对测试团队，嗯好吧是你，刮目相看了吧，呵呵~

开发团队能了解到，测试团队就也能了解到。与其跟进开发团队或代码，不如多跟进产品经理或 PRD。

先看下等价类划分的百度百科。
等价类划分，指的是一种典型的、重要的黑盒测试方法。其就是解决如何选择适当的数据子集来代表整个数据集的问题，通过降低测试的数目去实现 “合理的” 覆盖，以此发现更多的软件缺陷，统计好数据后由此对软件进行改进升级。价类划分法将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。

其实作者此处只是表述不当，其本意是等价类划分就是解决如何选择适当的数据子集来代表整个数据集的问题，通过降低测试的数目去实现 “合理的” 覆盖。
一组测试数据是否足够？这就牵涉到 “可信度”（不太记得这个专业词汇了，加个引号）问题。仅使用一组测试数据验证某个功能点且验证通过，我们是否可以 100% 相信这个功能点就是正确的呢？不是的。有多大可信度呢？统计表明这个数字是 86%--87%（小数点后不太记得），这是个很不错的可信度，但同时离完全可信又有差距。增加为两组测试数据，注意这里并不增加测试用例，可信度上升至 92%--93%；接着增加为三组测试数据，可信度还不超过 93%；继续增加，四五六组数据都能通过，则可信度上升非常缓慢，近似平直。结论就是：验证一组测试数据通过已有较高的可信度，多设计几组测试数据可以得到更好的保证，一般五六组即可，视项目 workload 而定，再多则投入产出比急剧下降。
对于你担心的冗余问题，其实等价类划分法目的之一就是为了避免冗余（降低测试的数目）。

真正掌握黑盒测试方法后，是不需要参考代码逻辑的。

谢邀，虽然我现在还不是最大的大佬。
这个世界唯一不变的就是改变！唯一能做的就是改变自己，适应环境！
自己不思进取，我们提高行业准入标准，带领整个测试行业往前走关你们什么事，你们愿意在大清朝待着你就待着，你就是想混日子，我们 K8S 玩的可香了呢，在我们带领行业前进，探索测试边界的道路上，希望你们这群不思进取的同志主动去别的行业混饭吃，或者回家种地卖红薯吧。关年龄什么事啊，还是你不够努力，还是你不够鸡血，还是你加班不能 007，还是你不够主动赋能，还是你不够左移右移，还是你不够三高，还是你不够增加自己能力的护城河，时代抛弃你都不会和你打招呼的呢！

计算都在前端，前端也有接口的吧？后端只操作数据库和少量的计算。是接口就可能出问题，就需要测试，怎么会没意义呢？
建议在技术、时间和支持都具备的情况下，同时从 GUI 层面也开展自动化测试。开发技术用的 MS 的.net winform，测试工具建议选择 MS 的 CodedUI。

目前已经写出了第一版，但是开发没有准备 api 文档，参数也是随便传。没什么标准，啥都是用 json 传的，返回值倒是规定了。

你的意思是开发频繁修改 api 的定义及实现吗？

楼主总结的极为到位，抛出了有关测试团队效率的 4 个思考。

紧接着继续思考，就有了下面 4 个问题：

1. 测试环境问题该怎么解决，由谁解决？
2. 开发数据构造平台应由谁负责？对该平台的要求是怎样的？目前有没有开源或商业工具/平台？
3. 开发版本发布平台应由谁负责？对该平台的要求是怎样的？目前有没有开源或商业工具/平台？
4. 测试开发通过技术手段提高了测试效率，反而没有业务测试繁琐低效加班受重视，这种情况现实中会发生吗？

UI 自动化的工作量和维护成本你们做过评估了吗？评估后或许你们会觉得可以接受呢！
可使用场景有多少你们做估算或统计了吗？如果真的不太多，那确实光点点点就可以了。

1. 这各版本没有这个公式改动，所以只跑了主流程
   回归测试不能只跑主流程，要全量跑所有的回归用例。但可以根据项目情况，对小版本只跑主流程，对主要版本进行全量回归。换句话，几个版本跑完主流程后，就必须跑一次全量，如此循环。

2. 这个 avbl 场景和前端切换币对没有一毛钱关系，他是依赖于后端的
   接口测试可以验证后端，但要保证前端也是正确的，就需要把前后端或说是整个产品看做个黑盒，从 GUI 的角度，从真实用户的角度，去使用和验证产品。

3. 回归测试切换币对时，一般来说，就切换那 2，3 个币对，测试切换功能是否正常，这个时候，如果这 2 个币对杠杆倍数一致，avbl 也是对的。
   这是用例设计的问题，只设计两三组测试数据是不够的，多设计几组测试数据（不需要多设计测试用例）就能避免这种 “巧合漏网” 的现象。

4. 求助大家，像这种 bug，后续怎么测试才能保证测试到，业务上没有关联的 2 个点，因为开发原因影响到了，该怎么办
   这个案例很好地说明了基于 UI 的功能测试的重要性和必要性。测试用例设计要全面，保证覆盖度，相比接口测试，UI 测试应适当加大比重。每个版本都必须或尽可能全量执行回归。考虑自动化测试。

被业务测试同学远离 (因掌握了技术被孤立)，确定是这个原因？会不会是前面一条呢？
不要过于追求开发技术, 会跑偏 (我很认真, 并且可以接受讨论)。非常同意这条。

从产品设计角度来看，删除自己的评论的功能不应提供吧？若提供，评论区信息的完整性和一致性如何保证呢？

既然有代码重构，加入了新功能，产品质量是怎么保证的呢？是个测试团队还是？要进行回归测试吗？