别的业务线都有自己的造数工具，为什么要投入精力研发这样一个统一平台呢，背后有没有上级主管的支持？
如果有的话，可以尝试做个优势分析，可以稍微吹一点，拿着数据再让高层帮忙推动；如果没有，一般来说是没戏了。
做工具跟做产品的思路一样，前面几楼也说得很清楚了。

创业不易，我也无意泼冷水。
至于拒绝缺陷，tapd 的处理方式是这样：

支持根据解决方法检索或统计缺陷。
中间还有哪些想抽取出来拆成不同的状态呢？
新改的那张图上还是有很明显的 bug，为了产品形象建议再看看。
最后的建议是想清楚到底是管理敏捷开发过程还是只管测试，目标用户是哪一类，他们的痛点在哪，现在定义的流程适合他们吗。

感觉你的回复暴露了更多的测试管理方面的问题，缺陷常见状态就下面这些，目前看足够覆盖所有的业务场景。

已改未确认跟已修复或者已解决有什么区别？非错未确认跟已拒绝又有什么区别？
换个表述意味着客户得重新接受一次概念，这里的风险产品经理要不要考虑？
已改/同步到测试环境这状态是想解决什么问题，测试工作产出不是针对指定版本、指定环境吗，这样是不是带来测试管理的混乱。
最后说下那张图的毛病，
1、测试任务与项目测试是通过什么维度并列展示在一起的
2、项目研发下面为什么放的是测试任务
3、如果说每一栏最上面一行想表示项目生命周期的各个阶段，缺陷跟踪怎么又和测试执行并列了
4、需求部分为什么不在敏捷测试的测试迭代里
5、需求管理下面怎么列的是维护测试模块？

1、作为产品不在细分市场寻求突破，追求全面，就有可能因为某一项赶不上别家而被全盘放弃。
2、太多的度量指标，给人的感觉是产品方自己在测试领域没有沉淀，所以就把能透出的指标都透出来，让用户自己进行选择。
3、某些概念没有采用通用标准来描述，比如缺陷状态的已改未确认，非错未确认，不太明白开发者是不知道怎么描述还是刻意寻求差异化。
4、敏捷测试管理那张图逻辑性也有待商榷，参考https://www.cnblogs.com/linkxu1989/p/6673087.html，不是说老外总结得就一定好，但现有的这张图说服不了我个人。

看看是不是请求头的设置导致返回内容不一致了

只要业务还在，你留下就是老大

吾之美食,汝之鸩毒

挺有意思，先试用下

如果研发团队已经很牛逼了，就根据团队安排的来做
如果研发团队不行，你很牛逼就搭框架，定流程，定标准，卡准入准出
如果研发团队不行，你也不太会就忘了这事

感谢分享，顺便挑个刺，

8 小时了没人回，非特殊性的问题百度，google 一下不是快得多么

[W3C] Encountered internal error running command: Error: Neither ANDROID_HOME nor ANDROID_SDK_ROOT environment variable was exported.
顺着这里往下查吧

有工具能录出类似下面的代码，Airtest 不考虑借鉴下吗？

describe('Test 1', () => {
    let browser, page;
    beforeAll(async () => {
        browser = await puppeteer.launch({ headless: false, defaultViewport: null, args: ['--start-maximized'] ,ignoreDefaultArgs: ['--enable-automation']});
        page = await browser.newPage();
        await page.goto('https://kaifa.baidu.com/home');
    });
    it('Test 1 - 1', async () => {
        await page.click('.ant-input');
        await page.type('.ant-input', 'py');
        await page.keyboard.press('Backspace');
        await page.type('.ant-input', 'uppeteer');
    }, 60000);
});

设计就有问题，都是相对路径，你通过域名判断怎么搞

国内很多地方测开=自动化测试，所以面的时候问清楚，可能老板自己都不知道自己该招个什么样的。
总感觉测开这个角色不太适合国情。
开发只要写代码就行了，测开要完全读懂代码甚至自己写代码，并且得有测试的方法论，比如边界值，再通过 TDD 或者 BDD 的方式保证代码的质量。

反手就是一个赞。
关键是做对的事情，工作给自己什么回报，给团队什么回报，盲目追求技术最后往往会很失落。

测试团队、或者质量团队定位是业务支撑部门，国内应该没几家公司老板愿意去投入搞测试前沿技术研究。
比如说我们希望降低 bug 逃逸率，提升回归测试效率，愿意学习先进的测试思想和方法，但肯定不愿意投入过多的研发成本做工具来实现。
关于精准测试，国内宣传厉害的有家叫星云测试，如果真的好用，买一套不比自己研发来得优惠么。

小公司玩不起，写请求的处理始终是个难点。
读请求也要考虑数据一致性的问题，搭建一比一的测试环境成本太高。
我想把流量录制用于线上问题跟踪，现在的日志系统采集率不足，全链路也没做起来，作为临时替代方案感觉还行。

先考虑下测试分层解耦吧，为什么 B 用例要用到 A 用例的返回数据，用例不是只要知道通过还是失败就行了吗。
如果测业务流程有数据依赖，把涉及到的方法组织在一起做一条完整的流程用例，而流程中的各个步骤使用各自独立的数据单独测试会不会好点。
非要这么干的话，用 redis 也是个选择。

当 TPS 不能随着并发用户数的上升而增长时，那首先达到最高 TPS 的并发数就是最优的
最大并发数一般要结合性能需求来，比如超过多少用户后，TPS 下降，响应时间增长，服务器负载过高到某个阈值等等。
最好是通过手动加压来测，因为在测试之前，这些值都是未知，预先制定的加压策略可能说明不了问题
另外做性能首先得根据测试目标定好策略，对曲线的每一个走势都能拿出合理解释。

用 jenkins 试试

测试平台也要一年一换了吗？

如果是面试，我会问
推广使用的效果怎么样
如何说服测试同学放弃 postman,jmeter 这些工具
平台上有多少用例在跑，在 CICD 中发挥了什么作用

用例数，执行效率，稳定性，可维护性，啥都没有，也不知道膨胀个啥

jsonschema,指定 required