谢谢建议
跳槽后 没用这个工具了，就没有持续投入开发维护了
官方版本应该有 docker 部署方式，可以参考构建

我现在也在质检团队 多交流哈

我的神 多年没有上论坛了 发现 n 年前的思考 以及大家的评论，内心居然有点小感动；

关于敏捷：这么多年过去了，我跳了好几个团队，大多数都是伪敏捷，或者说大敏捷，小瀑布，或者说需求敏捷，研发瀑布；这方面我还需要成长，多涨见识，属实没有见到敏捷玩儿的很好的团队；也许是能力有限，不能加入到更优秀的团队涨姿势。

关于 QA：我回顾了下上文，确实时间久远，也记不清当时的思路了；确实我想表达的不是 tester 要做什么，而是偏向于 质检、SQA、质量运营，这类岗位；不同公司叫法不同；不过大题上，就是做质量文化建设、搞流程规范建设、做过程质量管理、撸质量结果评价、推质量改进方案这类事；

关于质量和效率：这 tm 是个操蛋的话题，真的得分行业、分业务阶段、分阶段目标，当然这个明面上都会说：我都要，但是实际呢，用户增量都没有，产品都不知道会不会被认可，玩命的搞质量？不快速迭代？相反的，一个相对稳定的产品，要寻求突破寻求增量，一堆产品在哪搞需求，但是都没有明显的商业收益，技术团队如果不拿 ROI 去挑战下，也是等被 diss 的节奏；

当然会有人讲，快速迭代和高质量不冲突，我也认可，但这中间有很多变量：比如怎么个快速，比如团队技术能力，团队人员稳定性、需求密度、团队业务熟悉程度；我觉得任何时候不考虑这些点，就说我都要的负责人，绝对是流氓！遇到这种要耍流氓的人，搞质量的就一定要前置，左移动，是那种极度前，极度左的；而且得充分拿过程和商业收益对比说事，倒逼流氓做选择，而不是他想用什么姿势就用什么姿势；否则，就等着背锅，你想说不反抗躺着享受都不可能；

还是回到主题：QA/SQA 随便怎么说吧，搞质量一定是要和团队目标契合的，充分沟通，充分暴露风险，让产研测运一起决策当前的质量目标和投入，才是最优解，自己在那意淫肯定会被人说你务虚；

采集数据 -- 说明现象 -- 分析根因 -- 摆问题 -- 出多套方案 -- 共同决策 这是正确的思路

实际落地的时候，有部门墙、有不同团队的利益冲突、有优先级冲突；怎么把质量团队的活动和项目/产品/公司大目标绑定，是个技术活儿！

再说点不成体系的杂言：
很多时候，希望能有短平快的动作，既能快速拿结果，又能支撑绩效，又能吹牛晋升，脏乱杂的活儿没人干，或者不愿意干，抓大放小；但实际上，支撑系统稳定不出乱子的 80% 工作，就是这些细节，每天改进一点点，谁说站在光里的才算英雄；
希望所有质量工作者能坚持初心，干到 70 岁！你的初心是什么！
欢迎加微交流： xiancrazy

嗯 后续会考虑优化开发这几个能力

体验站点停服了，暂时没有部署体验站点

谢谢大家反馈，回逐步优化改进

确实如此，不过去掉插件使用更方便，也只需要维护一套请求逻辑， 至于本地回环的问题 确实应该支持，我考虑下怎么既能解决跨域又不用插件

谢谢大家的回复

不过我想再说明的一点是，我本身也是非常讨厌理论派，任何理论的东东我都努力给出具体怎么做的步骤，具体的交付物,具体的标准。

我写这段东东的初衷给我们的团队，也是想传递一个想法，我们可以不用纠结要不要 QA 这个职位，也不用去想哪些是 QA 做的，哪些是项目经理做的，哪些是测试或者开发做的，共同的目的是改变现状，提高在快速迭代过程中产品的交付质量。

一开始准备招聘一个经验丰富的 QA 从业人员，我直接否定了这种做法，一上来就是一套完整的体系制度文档，就是硬着陆，我更加喜欢根据自己团队目前的结症，每个月改进一点点。

不知为何本文会和敏捷扯上关系？我反复看了我的行文，似乎是我写的 QA 活动几个点在几个月内实现之类的话将大家的思路引导到敏捷上去了，我本意并非如此

我所指的活动改进，是项目进行过程中的不好的习惯，而并非 story。本意旨在形成了良好的习惯了，产品质量自然会一定程度提升