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

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

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

he icon   en icon

שילוב Continuous Integration) CI) בבדיקות אוטומטיות (חלק #3) - דייב הפנר (עולם הבדיקות גיליון #8)

נכתב על ידי 
שני, 17 אפריל 2017 19:45
דרגו כתבה זו
(1 הצבעה)

שילוב Continuous Integration) CI) בבדיקות אוטומטיות (חלק #3) - דייב הפנר (עולם הבדיקות גיליון #8)

זוהי הכתבה האחרונה בסידרה של שלוש כתבות העוסקות באיך להתחיל לעבוד עם בדיקות רשת אוטומטיות באופן הנכון.
ככל הנראה תצליחו להתקדם באופן משמעותי כשתריצו את הבדיקות האוטומטיות מהמחשב שלכם, תבחנו את התוצאות ותספרו לחברי הצוות שלכם כאשר אתם נתקלים בבעיה באפליקציה. עם זאת, צורת העבודה הזו תפתור רק חלק מהבעיה שלכם.
המטרה האמיתית בבדיקות אוטומטיות היא למצוא את הבעיות באופן מהיר, אמין ואוטומטי - ורצוי שזה יקרה בסנכרון עם תהליך הפיתוח של המוצר, שאתם כמובן חלק ממנו.
על מנת לגרום לזה לקרות, עלינו להשתמש בשרתי אינטגרציה מתמשכת.
הבסיס של שרתי CI
תפקידם של שרתי אינטגרציה מתמשכת (CI) הוא למזג את הקוד הנמצא בשלבי הפיתוח אל תוך הפרויקט המרכזי באופן תדיר (מספר פעמים ביום או לאחר שנוסף קוד חדש) על מנת לאתר ולפתור בעיות במועד מוקדם ככל הניתן - כל זה על מנת לדאוג לשחרור גרסה תקינה של המוצר במועד הצפוי.
בעזרת אינטגרציה מתמשכת, תוכלו להריץ את הבדיקות שלכם בצורה אוטומטית כך שהם יצאו לפועל כחלק מתהליך הפיתוח. חלק הארי של בדיקות שרצות על שרתי CI הוא לרוב בדיקות יחידה אך עם זאת, נוכל בקלות להוסיף את מבדקי ה- Selenium שכתבנו לאחרונה...

מאמר זה הופיע בגיליון #8 של מגזין עולם הבדיקות - לצפייה בפורמט המלא כולל קישורים וכד' ובשאר מאמרי גיליון זה:
bit.ly/TW-8view

 

TW8 HowToStartWebAutoCI P3 DaveH 01

TW8 HowToStartWebAutoCI P3 DaveH 02

TW8 HowToStartWebAutoCI P3 DaveH 03

TW8 HowToStartWebAutoCI P3 DaveH 04

 

שונה לאחרונה ב שני, 17 אפריל 2017 19:57

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

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

  • Influences on me as a programmer

    Influences on me as a programmer In this article I will talk about two things that have influenced how I approach my craft, which is programming.  They appear to be contradictory, but I think I can live with both at once.  This is an area where everyone has to work things out for themselves.  I’m not trying to preach; just talk about things I’ve found helpful in case you find them helpful too. A ship-building grandfather My grandfather was a shipbuilder on Merseyside.  Because Merseyside had a port as well as shipyard, you might see a ship you’d worked on come back later to the port.  Any of the tens or even hundreds of people who had worked on a ship would point to it and say, “That’s my ship.” They were proud of what they had made. I like to take pride in my work.  There’s already enough bad and annoying code in the world – I don’t want to add to it.  I try to approach people with dignity, which means they have innate value.  That in turn means the users of my software deserve a reasonably good user experience, just because they’re humans with value. I want to be able to look myself in the mirror and think I did an OK job.  Or, on the other side of this, what I want to avoid is looking at some code and then thinking: What idiot wrote this?Oh, me. I’m exaggerating for effect here – I try to not be too hard on other[…]

    17.04.2021 | 3:13 קרא עוד...
  • Is talking about “scaling” human testing missing the point?

    Is talking about “scaling” human testing missing the point? I recently came across an article from Adam Piskorek about the way Google tests its software. While I was already familiar with the book How Google Tests Software (by James Whittaker, Jason Arbon et al, 2012), Adam’s article introduced another newer book about how Google approaches software engineering more generally, Software Engineering at Google: Lessons Learned from Programming Over Time (by Titus Winters, Tom Manshreck & Hyrum Wright, 2020). The following quote in Adam’s article is lifted from this newer book and made me want to dive deeper into the book’s broader content around testing*: Attempting to assess product quality by asking humans to manually interact with every feature just doesn’t scale. When it comes to testing, there is one clean answer: automation.Chapter 11 (Testing Overview), p210 (Adam Bender) I was stunned by this quote from the book. It felt like they were saying that development simply goes too quickly for adequate testing to be performed and also that automation is seen as the silver bullet to moving as fast as they desire while maintaining quality, without those pesky slow humans interacting with the software they’re pushing out. But, in the interests of fairness, I decided to study the four main chapters of the book devoted to testing to more fully understand how they arrived at the conclusion in this quote – Chapter 11 which offers an overview of the testing approach at Google, chapter 12 devoted to unit testing, chapter 13 on test doubles and chapter 14 on “Larger[…]

    17.04.2021 | 6:22 קרא עוד...
  • In defence of lobbying

    Lobbying of politicians has acquired a dirty name, and that’s a pity. In fact, I find it rather irritating. Lobbying means campaigning, providing expert analysis and briefing to politicians, who are usually generalists and need that guidance from experts. Good politicians even come looking for it, to gain a better understanding of complex problems. That’s when lobbying is being done well and responsibly. Some of my recent work counts as lobbying, related to the law of evidence in England and the Post Office Horizon scandal. I’m proud of that. It is a worthwhile activity and can help the political process work better. Lobbying is quite different from schmoozing old pals to give other chums contracts without the tedious bureaucracy of open tenders. It’s different from offering politicians highly paid sinecures in the hope they’ll work on behalf of you rather than their constituents. It is certainly different from handing out bribes. Lobbying is not the same as corruption, and that is what we’ve been seeing lately in the UK.

    17.04.2021 | 6:17 קרא עוד...

טיפים

  • מבט מערכתי לבודקים – Systems Thinking
    מבט מערכתי לבודקים – Systems Thinking מבט מערכתי לבודקים – Systems Thinking התכונה או מערכת אותה אנו בודקים - אינה מנותקת משאר העולם, תיקון בנקודה אחת – עשוי להשפיע ולפגוע בנקודות אחרות, ולכן על הבודק להכיר את המערכת והקשרים בין חלקיה. כמו…
    קרא עוד...
  • בדוק מוקדם ככול הניתן
    בדוק מוקדם ככול הניתן "בדוק מוקדם ככול הניתן" – אחת המטרות של הבדיקות הינה לספק כמה שיותר משוב ומידע לגבי איכות המערכת מנקודות מבט שונות (פונקציונליות ולא פונקציונליות כמו עמידה בעומסים ושאר יכולות). לעיתים בודקים נוטים בטעות לחשוב כי הדרך…
    קרא עוד...
לרשימה המלאה >>