你能得到什么
- 真实浏览器中的 UI 测试
- REST 和 GraphQL 契约检查
- 根据失败的运行生成的缺陷报告：复现步骤、截图、严重程度。已做重复检查，经你批准后才会提交。
- 缺陷提交到 Jira, ClickUp, GitHub Issues, Linear, Azure DevOps
- 提醒发送到 Slack, Discord, Telegram
- AI 分诊：是不稳定的测试还是真实缺陷
- 根据你的代码仓库分析根因，只读
- 严重程度
- P1
- 复现步骤
- 添加一件商品，打开 /checkout，使用过期的优惠码，用测试卡付款。
- 预期结果
- 优惠码被拒绝并给出提示信息。
- 实际结果
- 显示“优惠码已应用”，并按全额扣款。
- 提交到
- Jira，经批准后提交。已发送 Slack 提醒。
缺陷是如何流转的
每次部署都会运行测试套件。失败的测试会变成缺陷报告；经你批准后，它会进入你的缺陷跟踪工具，并通知你团队的聊天群。
部署后测试运行，其中一个失败，它的 Bug 报告被移到团队的跟踪工具中，同时一条 Slack 消息发出通知。
一次运行失败
每次部署都在真实浏览器中运行，并针对你的 API 测试。
分诊判定
是不稳定的测试、基础设施的偶发抖动，还是真实的产品缺陷。
报告自动生成
复现步骤来自实际运行的过程，附上截图和严重程度。
由你批准
批准之后，它才会进入你的缺陷跟踪工具和聊天群，之前不会。
默认安全
只读检查可在生产环境运行。任何会创建或修改数据的操作，只在开发或预发布环境运行。提交工单或发送聊天消息需等待你的批准。我们绝不会为了让运行变绿而隐瞒真实缺陷。
Pro 还包含
Pro ($29/mo) 每月包含 1,000 次测试额度：按需运行生成的测试、挑选测试、保存测试套件、根据描述生成测试并以可视化方式编辑。定时运行、提交到缺陷跟踪工具、聊天提醒和 AI 分诊属于 Enterprise。
也支持 Web3。dApp 同样适用：蜘蛛使用模拟钱包驱动钱包流程（连接、切换网络、签名、拒绝），针对测试网执行合约调用，并检查你的界面显示的内容是否与链上一致。
团队常问的问题
这与我们自己编写测试有什么不同？
没有什么能阻止你自己写。QA Spider 编写的是你的团队也能写出的标准测试代码。区别在于由谁来做这些工作：它起草测试、在每次部署时运行、在界面变化时修复定位器并提交缺陷。你的工程师只需审阅结果。
它会让我们的缺陷跟踪工具被刷屏吗？
不会。每个失败都会先经过分诊：不稳定的测试会被修复，基础设施的偶发问题会被重试，只有确认的产品缺陷才会变成工单。提交需要你批准，每个工单还会检查是否重复。
我们的界面变化时会怎样？
如果因为你改版导致定位器失效，Spider 会修复测试并做好记录。如果行为出现了回归，它会提交缺陷，而不是悄悄修改测试让结果保持通过。
你们如何处理登录、支付和测试数据？
你为 Spider 提供预发布环境的测试账号。它会在那里登录、用测试卡结账并提交表单。会修改数据的流程只在开发和预发布环境运行；生产环境只做只读检查。
你们需要我们的源代码吗？
测试不需要：Spider 以用户接触应用的方式来测试它。你也可以选择以只读方式连接代码仓库，这样失败时就能指出背后的文件和提交。
在生产环境运行安全吗？
生产环境的运行仅限于只读的冒烟检查。任何会创建、编辑或删除数据的操作都会被标记为修改型，只在开发或预发布环境运行。