Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
中文简介正在准备中。当前显示原文说明。
Use when a criterion mentions speed or limits, or the change touches a list, query, endpoint or page that could get slower - timing loops, the N-vs-10N data check and Lighthouse on a production build
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
Not full load testing — a smoke check run locally, never against stage or prod.
for i in $(seq 20); do curl -s -o /dev/null -w '%{time_total}\n' "$BASE/api/tasks?limit=50"; done | sort -n | awk '{a[NR]=$1} END{print "p50="a[int(NR*.5)]" p95="a[int(NR*.95)]" max="a[NR]}'
Then run the same with 10x the seeded rows. p95 growing more than 3x for 10x the data is an N+1 suspicion — report it with the two numbers. Fail bar: p95 >1s for a simple read on localhost, or any number a criterion states explicitly. 0.5-1s is a note, not a fail.
Only when the change implies it (a shared resource, a write path under contention):
npx -y autocannon -c 10 -d 10 <url>
Errors must be 0.
Measure a production build, never a dev server — dev builds are unoptimized and that is where false fails come from:
npm run build && (nohup npx vite preview --port 4173 > "$QA/preview.log" 2>&1 &)
CHROME_PATH="$CHROME_BIN" npx -y lighthouse@13 http://localhost:4173/<page> --only-categories=performance --form-factor=mobile --screenEmulation.width=360 --chrome-flags="--headless=new" --output=json --output-path="$QA/lh-perf.json"
Report LCP/CLS/TBT against "good": LCP ≤2.5s, CLS ≤0.1, TBT ≤200ms. Fail only for a criterion's own number or a CLS shift you can see on a changed screen; other misses are notes, not fails.
Load-test stage or prod. Use k6 only when the repo already ships k6 scripts — not as the default tool.
Record cases as category: other with a title prefix perf: — the category enum has no performance value of its own.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
中文简介正在准备中。当前显示原文说明。
Use when the diff adds or changes an endpoint, resolver, RPC, job or query that takes an object id, a role check, a request binding or a tenant filter - BOLA/IDOR, function-level authorization, mass assignment and tenant scoping
中文简介正在准备中。当前显示原文说明。
Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal
中文简介正在准备中。当前显示原文说明。
Use when a task changes any screen, form, dialog, menu or control - Lighthouse/axe scan of the changed screens, a keyboard walk, and the thresholds that fail a task
中文简介正在准备中。当前显示原文说明。
How to work a task returned with review, QA or UAT findings. Use when a task is in need_revision or PR review comments are in your context.
中文简介正在准备中。当前显示原文说明。
Use when the repository keeps its alerting in code, or a person asks for alerts outside TaskTrooper - PrometheusRule YAML, a Cloud Monitoring alert policy in Terraform, a Datadog monitor, each routed to TaskTrooper's alert ingest URL so it opens an incident here
中文简介正在准备中。当前显示原文说明。