סקיל webapp-testing: בדיקות אוטומטיות לאתרים בקלוד קוד
webapp-testing הוא הסקיל הרשמי של Anthropic לבדיקות אוטומטיות של אפליקציות ווב מקומיות באמצעות Playwright. הסקיל מאפשר לקלוד קוד לפתוח דפדפן, להריץ אינטראקציות אמיתיות, לצלם מסך ולקרוא לוגים, כדי לאתר באגים בממשק לפני שהם מגיעים לייצור. עם כ-52 אלף התקנות שבועיות זה כלי חובה לכל מפתח שעובד על אפליקציה אינטרקטיבית. בסקירה זו אבחן את היכולות, את דפוסי העבודה הנכונים, ומקרי שימוש אמיתיים מעבודה על מערכות לקוחות.
פקודת התקנה
npx skills add https://github.com/anthropics/skills --skill webapp-testing
קובץ הסקיל הוא Markdown פתוח. אפשר להוריד אותו ולהריץ בדיקת קוד לפני התקנה דרך הכפתורים שבראש העמוד.
מה הסקיל כולל?
הסקיל מטעין לקלוד קוד את הידע איך להפעיל Playwright בצורה נכונה על אפליקציה מקומית, יחד עם דפוסי הבדיקה שמונעים שגיאות נפוצות של דפים שלא נטענו עד הסוף.
קוד הסקיל המלא
---
name: webapp-testing
description: Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
license: Complete terms in LICENSE.txt
---
# Web Application Testing
To test local web applications, write native Python Playwright scripts.
**Helper Scripts Available**:
- `scripts/with_server.py` - Manages server lifecycle (supports multiple servers)
**Always run scripts with `--help` first** to see usage. DO NOT read the source until you try running the script first and find that a customized solution is abslutely necessary. These scripts can be very large and thus pollute your context window. They exist to be called directly as black-box scripts rather than ingested into your context window.
## Decision Tree: Choosing Your Approach
```
User task → Is it static HTML?
├─ Yes → Read HTML file directly to identify selectors
│ ├─ Success → Write Playwright script using selectors
│ └─ Fails/Incomplete → Treat as dynamic (below)
│
└─ No (dynamic webapp) → Is the server already running?
├─ No → Run: python scripts/with_server.py --help
│ Then use the helper + write simplified Playwright script
│
└─ Yes → Reconnaissance-then-action:
1. Navigate and wait for networkidle
2. Take screenshot or inspect DOM
3. Identify selectors from rendered state
4. Execute actions with discovered selectors
```
## Example: Using with_server.py
To start a server, run `--help` first, then use the helper:
**Single server:**
```bash
python scripts/with_server.py --server "npm run dev" --port 5173 -- python your_automation.py
```
**Multiple servers (e.g., backend + frontend):**
```bash
python scripts/with_server.py
--server "cd backend && python server.py" --port 3000
--server "cd frontend && npm run dev" --port 5173
-- python your_automation.py
```
To create an automation script, include only Playwright logic (servers are managed automatically):
```python
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
browser = p.chromium.launch(headless=True) # Always launch chromium in headless mode
page = browser.new_page()
page.goto('http://localhost:5173') # Server already running and ready
page.wait_for_load_state('networkidle') # CRITICAL: Wait for JS to execute
# ... your automation logic
browser.close()
```
## Reconnaissance-Then-Action Pattern
1. **Inspect rendered DOM**:
```python
page.screenshot(path='/tmp/inspect.png', full_page=True)
content = page.content()
page.locator('button').all()
```
2. **Identify selectors** from inspection results
3. **Execute actions** using discovered selectors
## Common Pitfall
❌ **Don't** inspect the DOM before waiting for `networkidle` on dynamic apps
✅ **Do** wait for `page.wait_for_load_state('networkidle')` before inspection
## Best Practices
- **Use bundled scripts as black boxes** - To accomplish a task, consider whether one of the scripts available in `scripts/` can help. These scripts handle common, complex workflows reliably without cluttering the context window. Use `--help` to see usage, then invoke directly.
- Use `sync_playwright()` for synchronous scripts
- Always close the browser when done
- Use descriptive selectors: `text=`, `role=`, CSS selectors, or IDs
- Add appropriate waits: `page.wait_for_selector()` or `page.wait_for_timeout()`
## Reference Files
- **examples/** - Examples showing common patterns:
- `element_discovery.py` - Discovering buttons, links, and inputs on a page
- `static_html_automation.py` - Using file:// URLs for local HTML
- `console_logging.py` - Capturing console logs during automation
מה זה סקיל webapp-testing ולמה הוא חשוב?
webapp-testing הוא הסקיל הרשמי של Anthropic לבדיקות אוטומטיות של אפליקציות ווב בקלוד קוד. הוא לא מחליף QA ידני, אבל הוא הופך אותו ליעיל פי כמה: במקום לבדוק כל פיצ'ר ידנית בכל deploy, אפשר לבקש מקלוד להריץ סקריפט בדיקה שמחקה משתמש אמיתי.
הבעיה שהסקיל פותר ידועה לכל מפתח: כל שינוי קטן בקוד עלול לשבור משהו במקום אחר. בדיקות ידניות מפספסות חלק גדול, ובדיקות אוטומטיות בקוד שאין מי שיכתוב אותן הן רק תיאוריה. webapp-testing מאפשר לקלוד קוד לכתוב את הסקריפטים האלה בעצמו, על סמך תיאור בעברית של מה שצריך לבדוק.
הבסיס הוא Playwright, ספריית בדיקה מודרנית של Microsoft שיציבה יותר מ-Selenium ומהירה יותר מ-Cypress. הסקיל מתעד את הדפוסים שעובדים בפועל ואת המלכודות הנפוצות, כמו שכחה לחכות ל-networkidle או שימוש בסלקטורים שמשתנים בכל refresh.
הסקיל הזה משתלב מעולה עם פיתוח אפליקציות שדורש בדיקות איכות מתמשכות, ועם אוטומציות עסקיות שכוללות תהליך אישור משתמש. במקום לסמוך על כך שהכל עובד, יש סקריפט שמוודא את זה בכל הזדמנות.
מה סקיל webapp-testing נותן לקלוד קוד?
הסקיל מוסיף לקלוד קוד יכולת של תפעול דפדפן אמיתי, חיבור לשרת מקומי, וקריאה של מצב הדף בזמן אמת. כל אחת מהיכולות הבאות זמינה אוטומטית עם התקנת הסקיל.
ניהול שרת אוטומטי
הסקיל כולל סקריפט with_server.py שמטפל בהפעלה ובסגירה של השרת המקומי לפני ואחרי הבדיקה. אין יותר שרתים תלויים שצורכים פורטים ומפריעים לפעם הבאה. תמיכה גם בשרת אחד וגם בכמה שרתים במקביל.
צילומי מסך מלאים של דפים
הסקיל יודע לקחת צילום מסך full-page של דף אחרי שהוא נטען לגמרי. שימושי לבדיקות חזותיות של רגרסיה ולתיעוד באגים שדורשים הקשר ויזואלי. הצילום נשמר אוטומטית ל-tmp לשליפה מהירה.
קריאת לוגים מהדפדפן
הסקיל יודע לקרוא console.log, console.error והבקשות הרשתיות שהדפדפן שלח. שימושי במיוחד לאיתור באגים ב-JavaScript שלא מתגלים בעין, או לזיהוי קריאות API שנכשלות בשקט מאחורי הקלעים.
Reconnaissance-then-action
במקום לכתוב סקריפט בדיקה עיוור, הסקיל מנחה לקרוא את ה-DOM, לזהות את הסלקטורים האמיתיים, ורק אז להפעיל את הפעולות. הסקריפטים שיוצאים יציבים יותר ולא נשברים בכל שינוי קוסמטי במבנה.
בלי הסקיל, כתיבת בדיקות אוטומטיות דורשת מומחיות ב-Playwright וזמן ניסויים. עם הסקיל, כל מפתח יכול לבקש מקלוד לכתוב סקריפט בדיקה לתרחיש בשפה טבעית.
למי הסקיל הזה מתאים?
מפתחי Frontend וצוותי FullStack: מי שעובד על אפליקציה אינטראקטיבית וצריך להבטיח שכל deploy לא ישבור פיצ'רים קיימים. הסקיל מאפשר לבנות חבילת בדיקות בסיסית תוך שעות במקום שבועות.
צוותי QA שעוברים מבדיקה ידנית לאוטומציה: ל-QA יש לרוב הבנה מצוינת בתרחישי השימוש אבל לא תמיד מיומנות בקוד. הסקיל מאפשר להם לתאר את התרחיש בעברית, ולקבל סקריפט עובד תוך דקות. בשילוב עם סקיל skill-creator אפשר לבנות סקילי בדיקה מותאמים לתחום עבודה ספציפי.
סטארטאפים בשלב מוקדם: כשהמשאבים מצומצמים אין לרוב QA מסור, ולכן בדיקות אוטומטיות קריטיות. הסקיל מאפשר ליזם או למפתח יחיד להגן על האפליקציה מרגרסיה. הוא משתלב היטב עם קלוד קוד שמנהל את כל זרימת הפיתוח.
סוכנויות פיתוח שמספקות אפליקציות ללקוחות: לפני מסירה ללקוח אפשר להריץ חבילת בדיקה אוטומטית שמוודאת שהמערכת עומדת בכל דרישות התרחיש. זה מבדל את הסוכנות ומספק רמת אמון גבוהה ללקוח. פלאגין Superpowers שבחנתי בעבר מאפשר לטעון את הסקיל כחלק מסביבת עבודה מלאה.
מי שלא מתאים: בדיקות performance עם עומס של אלפי משתמשים. עבור הסקיל הזה לא נועד לשם, ועדיף לפנות לכלים יעודיים כמו k6 או JMeter. הסקיל הזה מצוין לבדיקת תפעול בודד, אבל לא לעומסי קצה.
איך סקיל webapp-testing עזר לי בפרויקטים אמיתיים
בדיקת רגרסיה אוטומטית לפני כל deploy
אפליקציה של לקוח קיבלה pipeline שמריץ את הסקיל לפני כל deploy לייצור. הסקיפט בודק 12 מסלולי משתמש קריטיים, צובע צילום מסך לכל אחד, ועוצר את ה-deploy אם משהו נופל. תוך חודש זוהו 5 רגרסיות שלא היו מתגלות אחרת.
איתור באג של מסך לבן בטעינה ראשונה
משתמש דיווח שהאפליקציה מציגה מסך לבן בטעינה ראשונה. הסקיל הריץ את הדף, חיכה ל-networkidle, וזיהה ב-console שגיאת JavaScript של רכיב חסר. הבאג נמצא תוך 3 דקות במקום שעות של דיבוג ידני.
בדיקת תהליך תשלום קצה לקצה
חנות מקוונת רצתה ודאות שתהליך התשלום מסתיים תקין. הסקיל בנה סקריפט שמוסיף מוצר לעגלה, ממלא טופס משתמש, מבחר באמצעי תשלום, ומאשר. ההרצה רצה כל שעה ושלחת התראה אם משהו נשבר. זיהינו תקלה בשער תשלום שהיינו מפסידים עליה.
בדיקה אוטומטית של RTL וטקסט עברי
אפליקציה של לקוח שעברה עיברות, נדרשה לבדיקת RTL מקיפה. הסקיל ניווט בכל הדפים, צילם אותם, ובדק שהטקסט והכפתורים לא חורגים. נמצאו 14 אזורים בהם העיצוב נשבר בעברית, וכולם תוקנו לפני העלייה לאוויר.
ארבעת המקרים האלה מדגימים שהסקיל מתאים לבדיקות רגרסיה תקופתיות, לאיתור באגים נקודתיים, לבדיקת מסלולי תשלום קריטיים, וגם לאימות עברית ו-RTL. הזמן הנחסך בכל פרויקט הצדיק את שעות ההטמעה של הסקיל.
סיכום
webapp-testing הוא סקיל חובה לכל מי שמפתח אפליקציות ווב באופן רציני. הוא הופך את ההבדל בין QA ידני יקר ל-QA אוטומטי שלא דורש מומחיות, ופותח את הדלת לבדיקות מקיפות שכל מפתח יכול לכתוב.
אם אתם מתחילים, הריצו את פקודת ההתקנה, בקשו מקלוד לבדוק תרחיש פשוט באתר שאתם מפתחים, וצפו בסקריפט שהוא כותב. תראו שהקוד יציב, ברור, וקל להרחבה. אפשר גם להוריד את קובץ הסקיל המלא ולקרוא אותו לפני התקנה.
בסקירות הבאות אבחן גם את סקיל canvas-design ליצירת גרפיקה ואת סקיל mcp-builder לבניית שרתי MCP. לעסקים שמפתחים אפליקציות ווב באופן קבוע, זו הזדמנות חיסכון משמעותית של זמן וכסף בבדיקות.
שיתוף הסקיל
שאלות ותשובות
האם צריך לדעת Python כדי להשתמש בסקיל?
לא חובה. קלוד קוד יכתוב את כל סקריפט ה-Playwright במקומכם על סמך תיאור התרחיש בשפה טבעית. ההמלצה היא להבין את המושגים הבסיסיים של Playwright (selector, action, wait) כדי לאמת שהקוד עושה מה שביקשתם, אבל לא חובה לכתוב אותו בעצמכם.
האם הסקיל עובד גם על אתרים בייצור?
הסקיל מתועד לעבודה על אפליקציות מקומיות, אבל הוא יעבוד טכנית גם על אתרים בייצור. ההמלצה היא לא להשתמש בו ככה בלי אישור מפורש מבעל האתר, כדי לא להיכנס לבעיות של תנאי שימוש. לאתרי לקוח שלכם, אפשר להשתמש חופשי.
איך הסקיל מטפל בהמתנה לטעינה דינמית?
הדפוס המומלץ של הסקיל הוא wait_for_load_state('networkidle'), שמחכה עד שאין יותר בקשות רשת ל-500 ms. למצבים מורכבים יותר אפשר להשתמש ב-wait_for_selector שמחכה לרכיב ספציפי. הסקיל מסביר מתי כל אחת מהשיטות מתאימה.
מה ההבדל בין הסקיל הזה ל-Cypress או Selenium?
Playwright הוא מודרני יותר מ-Selenium ויציב יותר על אפליקציות SPA. ההבדל מ-Cypress הוא ש-Playwright מריץ במהירות גבוהה יותר ותומך באופן טבעי ב-headless. הסקיל בנוי במיוחד לזרימת עבודה של קלוד קוד שכותב סקריפטים על פי בקשה, ולא לעבודה של QA ידני.
איך משתלבים עם CI/CD pipeline?
הסקיל מתאים מצוין ל-pipeline של GitHub Actions, GitLab CI, או כל מערכת אחרת. הסקריפטים רצים בדפדפן headless, לוקחים פחות מדקה לתרחיש סטנדרטי, ומחזירים exit code לפי הצלחה או כישלון. מתועד מצוין במסמכי Playwright הרשמיים.
מה התמיכה בבדיקות מובייל?
Playwright יודע לחקות גודל מסך של מכשירים שונים, סוכן משתמש, וכיוון מסך. הסקיל יכול לבקש ממנו לבדוק תרחיש כפי שהוא נראה ב-iPhone או באנדרואיד מסוים. למצבי מובייל אמיתיים יש כלים יעודיים יותר, אבל לבדיקות בסיסיות זה מספיק.
האם הסקיל מטפל גם ב-authentication ובכניסה למערכת?
כן. הסקיל יודע למלא טפסי כניסה, לשמור cookies, ולשחזר אותם בין ריצות. למצבי OAuth ו-2FA אפשר לשמור את המצב המאומת ולהשתמש בו לכל הבדיקות. שימושי מאוד לבדיקות אזורים מוגנים שדורשים משתמש מחובר.
מה עושים כשהסקריפט נתקע ולא מסיים?
הסקיל מנחה להוסיף timeout מפורש לכל פעולה, ולוודא שהדפדפן נסגר ב-finally. אם בכל זאת נתקע, אפשר להוריד timeout כללי ב-Playwright לסגירה אוטומטית אחרי דקה. השימוש ב-with_server.py מבטיח שגם השרת ייסגר נקי.