בדיקות יחידה ב-DBMS - איך אנחנו עושים את זה בספורטמאסטר, חלק שני

חלק ראשון - כאן.

דמיינו את המצב. אתה עומד בפני המשימה של פיתוח פונקציונליות חדשה. יש לך התפתחויות מהקודמים שלך. אם נניח שאין לך חובות מוסריות, מה היית עושה?

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

1. שחזור בדיקות יחידות ישנות. שחזור משמעותו התאמת בדיקות למצב הקיים של מערכת הנאמנות והתאמת בדיקות לתקני utPLSQL.
2. פתרון בעיה תוך הבנה של מה בדיוק, אילו שיטות ותהליכים מכוסים בבדיקות אוטומטיות. אתה חייב לשמור את המידע הזה בראש שלך, או להסיק מסקנות על סמך קוד הבדיקה האוטומטית. לכן, החלטנו ליצור קטלוג. הקצינו קוד מנמוני ייחודי לכל בדיקה אוטומטית, יצרנו תיאור והקלטנו הגדרות (לדוגמה, באילו תנאים יש להפעיל אותו, או מה צריך לקרות אם הפעלת הבדיקה נכשלת). בעיקרו של דבר, איכלנו את המטא נתונים לגבי הבדיקות האוטומטיות והצבנו את המטא נתונים האלה בטבלאות סכימת utPLSQL סטנדרטיות.
3. הגדרת אסטרטגיית ההתרחבות, כלומר. בחירת פונקציונליות הכפופה לאימות על ידי בדיקות אוטומטיות. החלטנו לשים לב לשלושה דברים: שיפורי מערכת חדשים, תקריות ייצור ותהליכים מרכזיים במערכת. לפיכך, אנו מתפתחים במקביל לשחרור, מבטיחים את איכותו הגבוהה יותר, בו זמנית מרחיבים את היקף הרגרסיה ומבטיחים אמינות מערכת במקומות קריטיים. צוואר הבקבוק הראשון שכזה היה תהליך חלוקת הנחות ובונוסים על צ'ק.
4. באופן טבעי, התחלנו לפתח בדיקות אוטומטיות חדשות. אחת ממשימות השחרור הראשונות הייתה להעריך את הביצועים של דוגמאות מוגדרות מראש של מערכת הנאמנות. לפרויקט שלנו יש בלוק של שאילתות SQL קבועות בצורה נוקשה הבוחרים לקוחות על סמך תנאים. לדוגמה, קבלו רשימה של כל הלקוחות שהרכישה האחרונה שלהם הייתה בעיר מסוימת, או רשימה של לקוחות שסכום הרכישה הממוצע שלהם הוא מעל ערך מסוים. לאחר שכתבנו בדיקות אוטומטיות, בדקנו דגימות מוגדרות מראש, הקלטנו פרמטרים של ביצועי ביצועים, ובנוסף עשינו בדיקות עומס.
5. עבודה עם בדיקות אוטומטיות צריכה להיות נוחה. שתי הפעולות הנפוצות ביותר הן הפעלת בדיקות אוטומטיות ויצירת נתוני בדיקה. כך הופיעו במערכת שלנו שני מודולי עזר: מודול השקה ומודול הפקת נתונים.

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

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

6. בדיקות אוטומטיות צריכות להתחיל ולרוץ בזמן שמקובל על המערכת שלך. לכן, אורגנה השקה לילית יומית, שעל בסיס תוצאותיה מופק דוח על התוצאות הנשלח לכל צוות הפיתוח בדואר הארגוני. לאחר שחזור בדיקות אוטומטיות ישנות ויצירת בדיקות חדשות, זמן הפעולה הכולל היה 30 דקות. ההופעה הזו התאימה לכולם, שכן ההשקה התקיימה מחוץ לשעות העבודה.

   אבל היינו צריכים לעבוד על אופטימיזציה של מהירות העבודה. מערכת הנאמנות בייצור מתעדכנת בלילה. כחלק מאחד המהדורות, נאלצנו לבצע שינויים דחופים בלילה. המתנה של חצי שעה לתוצאות הבדיקות האוטומטיות בשלוש לפנות בוקר לא שימחה את האחראי לשחרור (ברכות נלהבות לאלכסיי וסיוקוב!), ולמחרת בבוקר נאמרו מילים טובות רבות כלפי המערכת שלנו. אבל כתוצאה מכך, נקבע תקן של 5 דקות לעבודה.

   כדי להאיץ את הביצועים, השתמשנו בשתי שיטות: בדיקות אוטומטיות החלו לרוץ בשלושה שרשורים מקבילים, למרבה המזל זה מאוד נוח בגלל הארכיטקטורה של מערכת הנאמנות שלנו. וזנחנו את הגישה שבה הבדיקה האוטומטית לא יוצרת לעצמה נתוני בדיקה, אלא מנסה למצוא משהו מתאים במערכת. לאחר ביצוע השינויים, זמן הפעולה הכולל צומצם ל-3-4 דקות.

7. פרויקט עם בדיקות אוטומטיות אמור להיות מסוגל להיפרס בעמדות שונות. בתחילת דרכנו היו ניסיונות לכתוב קבצי אצווה משלנו, אבל התברר שהתקנה אוטומטית שנכתבה בעצמה היא זוועה מוחלטת, ופנינו לפתרונות תעשייתיים. בשל העובדה שהפרויקט מכיל הרבה קוד ישיר (קודם כל, אנחנו מאחסנים את קוד הבדיקה האוטומטית) ומעט מאוד נתונים (הנתונים העיקריים הם מטא נתונים על בדיקות אוטומטיות), היישום בפרויקט Liquibase התברר כפשוט מאוד.

   זוהי ספרייה בקוד פתוח, בלתי תלויה במסד נתונים למעקב, ניהול ואכיפת שינויים בסכימת מסד נתונים. מנוהל באמצעות שורת הפקודה או מסגרות כגון Apache Maven. עקרון הפעולה של Liquibase הוא די פשוט. יש לנו פרויקט מאורגן בצורה מסוימת, המורכב משינויים או סקריפטים שצריך לגלגל לשרת היעד, וקבצי בקרה שקובעים באיזה רצף ועם אילו פרמטרים יש להתקין את השינויים הללו.

   ברמת DBMS נוצרת טבלה מיוחדת בה Liquibase מאחסנת את יומן הגלגול. לכל שינוי יש גיבוב מחושב, אשר מושווה בכל פעם בין הפרויקט לבין המצב במסד הנתונים. הודות ל-Liquibase, אנו יכולים להפעיל בקלות שינויים במערכת שלנו לכל מעגל. בדיקות אוטומטיות מושקות כעת על מעגלי בדיקה ושחרור, כמו גם על קונטיינרים (מעגלים אישיים של המפתחים).

אז בואו נדבר על תוצאות השימוש במערכת בדיקת היחידה שלנו.

1. כמובן, קודם כל, אנחנו משוכנעים שהתחלנו לפתח תוכנה טובה יותר. בדיקות אוטומטיות מופעלות מדי יום ועשרות שגיאות נמצאות בכל מהדורה. יתרה מכך, חלק מהשגיאות הללו קשורות רק בעקיפין לפונקציונליות שבאמת רצינו לשנות. יש ספקות רציניים שהטעויות הללו נמצאו בבדיקה ידנית.
2. כעת יש לצוות ביטחון שהפונקציונליות הספציפית פועלת כהלכה... קודם כל, זה נוגע לתהליכים הקריטיים שלנו. לדוגמה, במהלך ששת החודשים האחרונים לא נתקלנו בבעיות בחלוקת הנחות ובונוסים על קבלות, למרות שינויי השחרור, אם כי בתקופות קודמות אירעו טעויות בתדירות מסוימת
3. הצלחנו לצמצם את מספר איטרציות הבדיקות. בשל העובדה שהבדיקות האוטומטיות נכתבות עבור פונקציונליות חדשה, אנליסטים ובודקים במשרה חלקית מקבלים קוד באיכות גבוהה יותר, מכיוון זה כבר נבדק.
4. חלק מהפיתוחים בבדיקות אוטומטיות משמשים מפתחים. לדוגמה, נתוני בדיקה על קונטיינרים נוצרים באמצעות מודול יצירת האובייקטים.
5. חשוב שפיתחנו "קבלה" של מערכת הבדיקות האוטומטיות מצד המפתחים. יש הבנה שזה חשוב ושימושי. אבל מניסיוני אני יכול לומר שזה רחוק מלהיות המצב. צריך לכתוב בדיקות אוטומטיות, לתמוך ולפתח אותן, לנתח את התוצאות, ולעתים קרובות עלויות הזמן האלה פשוט לא משתלמות. הרבה יותר קל ללכת להפקה ולטפל שם בבעיות. כאן, מפתחים עומדים בתור ומבקשים מאיתנו לכסות את הפונקציונליות שלהם עם בדיקות אוטומטיות.

מה הלאה

בואו נדבר על תוכניות הפיתוח של פרויקט הבדיקות האוטומטיות.

כמובן שכל עוד מערכת הנאמנות של ספורטמאסטר קיימת וממשיכה להתפתח, אפשר גם לפתח בדיקות אוטומטיות כמעט בלי סוף. לכן, כיוון הפיתוח העיקרי הוא הרחבת שטח הכיסוי.

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

אבל אלו דרכים ברורות להתפתחות. אם אנחנו מדברים על משהו יותר לא טריוויאלי, נדגיש את הדברים הבאים:

1. נכון להיום, ניהול בדיקות אוטומטיות מתבצע ברמת DBMS, כלומר. ידע ב-PL/SQL נדרש לעבודה מוצלחת. במידת הצורך, ניהול מערכת (לדוגמה, הפעלה או יצירת מטא נתונים), אתה יכול ליצור איזשהו פאנל ניהול באמצעות Jenkins או משהו דומה.
2. כולם אוהבים מדדים כמותיים ואיכותיים. עבור בדיקות אוטומטיות, מחוון אוניברסלי כזה הוא כיסוי קוד או מדד כיסוי קוד. באמצעות מחוון זה, אנו יכולים לקבוע איזה אחוז מהקוד של המערכת שלנו הנבדקת מכוסה על ידי בדיקות אוטומטיות. החל מגרסה 12.2, אורקל מספקת את היכולת לחשב את המדד הזה ומציעה שימוש בחבילת DBMS_PLSQL_CODE_COVERAGE הסטנדרטית.

   מערכת הבדיקה האוטומטית שלנו היא בת קצת יותר משנה ואולי זה הזמן להעריך את הכיסוי שלנו. בפרויקט האחרון שלי (לא פרויקט ספורטמאסטר) זה מה שקרה. שנה לאחר העבודה על בדיקות אוטומטיות, ההנהלה קבעה את המשימה להעריך איזה אחוז מהקוד אנחנו מכסים. עם כיסוי של יותר מ-1%, ההנהלה תשמח. אנו, היזמים, ציפינו לתוצאה של כ-10%. התקנו כיסוי קוד, מדדנו אותו וקיבלנו 20%. כדי לחגוג, הלכנו לקבל את הפרס, אבל איך הלכנו להשיג אותו ולאן הלכנו אחר כך זה סיפור אחר לגמרי.

3. בדיקות אוטומטיות יכולות לבדוק שירותי אינטרנט חשופים. אורקל מאפשרת לנו לעשות זאת די טוב, ולא ניתקל עוד במספר בעיות.
4. וכמובן, ניתן ליישם את מערכת הבדיקה האוטומטית שלנו בפרויקט אחר. הפתרון שקיבלנו הוא אוניברסלי ומצריך רק שימוש באורקל. שמעתי שפרויקטים אחרים של ספורטמאסטר מתעניינים בבדיקות אוטומטיות ואולי נלך אליהם.

ממצאים

בואו נסכם. בפרויקט מערכת הנאמנות בספורטמאסטר, הצלחנו ליישם מערכת בדיקות אוטומטית. הוא מבוסס על פתרון utPLSQL של ​​סטיבן פוירשטיין. סביב utPLSQL יש קוד בדיקה אוטומטית ומודולים נלווים שנכתבו בעצמם: מודול השקה, מודול יצירת נתונים ואחרים. בדיקות אוטומטיות מושקות מדי יום, והכי חשוב, הן עובדות ושימושיות. אנו בטוחים שהתחלנו לשחרר תוכנה באיכות גבוהה יותר. יחד עם זאת, הפתרון המתקבל הוא אוניברסלי וניתן ליישם אותו באופן חופשי על כל פרויקט שבו יש צורך לארגן בדיקות אוטומטיות ב-Oracle DBMS.

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

כתבו הערות אם ישנן נקודות שכדאי לשים עליהן דגש בעתיד, או שאלות הדורשות חשיפה.

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

נכתוב על זה עוד?

• כן, כמובן

• לא תודה

12 משתמשים הצביעו. 4 משתמשים נמנעו.

מקור: www.habr.com