התחברות או הרשמה
להמשך הרשמה ידנית – לחץ על כפתור ההרשמה, להרשמה/כניסה מהירה בעזרת חשבון רשת חברתית – לחץ על הלוגו בכותרת

אפס סיסמה - שכחתי את שם המשתמש

שם משתמש
זכור אותי

he icon   en icon

בכדי לכתוב בפורום יש להרשם או להתחבר - ההרשמה/כניסה מתבצעת מכותרת האתר.  

ברוך הבא, אורח
שם משתמש: סיסמה: זכור אותי
פורום זה נועד לפיתוח שאלות לדוגמה בשיתוף עם הקהילה
הנכם מוזמנים לחוות דעתכם לגבי השאלות שמוצגות בפורום
ולהציע שאלות דוגמה נוספות

נושא תנאי בדיקה (test condition) הוא:

תנאי בדיקה (test condition) הוא: 25 דצמ 2015 14:58 #3432

  • halperinko
  • halperinko's Avatar
  • מנותקים
  • Administrator
  • פוסטים: 836
  • תודות שהתקבלו 35
  • קארמה: 3
פרק 1.4, רמה 1K

תנאי בדיקה (test condition) הוא:
א. תנאי חוזי או רגולטורי לביצוע הבדיקה או חלק ממנה
ב. אמת מידה ליציאה המהווה תנאי לביצוע הבדיקה או חלק ממנה
ג. תוצאה של מקרה בדיקה או חלק ממנו המהווה תנאי לביצוע הבדיקה
ד. פריט או אירוע שעשוי להיות מאומת על ידי מקרה בדיקה

יעד לימוד: מושגים, סעיף 1.4 (הלומדים נדרשים לזכור (1K) את כל המושגים המופיעים תחת הכותרת "מושגים" בכל פרק )

הסבר: תשובה ד הינה התשובה הנכונה ותואמת להגדרת המושג במילון המונחים (glossary):
"פריט או אירוע של רכיב או מערכת שעשוי להיות מאומת על ידי מקרה בדיקה אחד או יותר, למשל פונקציה, תנועה (transaction), תכונה (feature), מאפיין איכות, או אלמנט

תשובה א אינה נכונה כי מתייחסת לבדיקות תאימות (compliance testing) של המוצר לתקנים או התחייבויות חוזיות.
תשובה ב מתייחסת לתנאי יציאה (exit condition) מפרויקט
תשובה ג היא סתם ערבוב לא הגיוני (אם כבר יש תוצאה לבדיקה, אז מסתבר שהרצנו אותה כבר). מעבר לעניין הפשוט ש"תנאי בדיקה" אינו תוצאה של בדיקה.
יש להרשם בכדי לכתוב בפורום.

חדשות מעולם הבדיקות

  • X Things I’ve Learned about Contract Testing with Pact

    A couple of weeks ago, while at TestBash Manchester, I attended the “Contract Testing in Practice with Pact” workshop led by Pierre Vincent. I had some knowledge of the topic but the workshop helped me get some concepts straight, that either I was not familiar with or I had all wrong. Here are some of the things I’ve learned. Hopefully I got them right. Purpose The aim of contract tests should be to check if there are any changes in the structure of an API (renamed fields, change of type of data, etc.) and not its business logic. As an API consumer You provide the contract, stating your expectations of what a call to an API should return. Contract tests serve as unit tests of the structure of your request. Contract tests should respect the tolerant reader pattern. As the post says, you should “only take the elements you need, ignore anything you don’t.” Running the contract tests you created doesn’t inform you of any changes from the provider’s side. If you are consuming external APIs contract testing won’t really work for you. Unless you have a way of ensuring that the external providers will execute the contracts you supply them with. As an API provider Running contract tests lets you know if you still respect the way your consumers use your API. In case a contract test fails, you should either fix it or start discussions with the consumers about mutually changing the contract. As a provider of an external service[…]

    15.10.2019 | 7:37 קרא עוד...
  • Meme of the Day: Bug Reports

    The post Meme of the Day: Bug Reports appeared first on The Life Of One Man.

    15.10.2019 | 4:32 קרא עוד...
  • Five Blogs – 15 October 2019

    The (best) five blogs I read today. Check them out. How to Apply Shift-Left Testing in Continuous Testing? Written by: Katalon Studio Team Lessons Learned about Cloud Written by: Srinivas Kadiyala Working with People Who Aren’t Self-Aware Written by: Tasha Eurich Things You Should Know About IoT Testing Written by: TestingWhiz How to Move from Stupid to Smart when You’re Stressed Written by: Dan Rockwell Quote of the day: “There are certain things, no matter what, you have to keep inside.” -Haruki Murakami You can follow this page on Twitter

    15.10.2019 | 12:33 קרא עוד...


לרשימה המלאה >>