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

היי הבר!

שמי מקסים פונומרנקו ואני מפתח בספורטמאסטר. יש לי ניסיון של 10 שנים בתחום ה-IT. הוא התחיל את הקריירה שלו בבדיקות ידניות, ואז עבר לפיתוח מסדי נתונים. ב-4 השנים האחרונות, בצבירת הידע שנצבר בבדיקות ופיתוח, אני עושה אוטומציה של בדיקות ברמת DBMS.

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

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

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

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

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

בודקים נאמנות

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

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

• המערכת שלך תהיה עמוסה מאוד
• המערכת שלך תכיל תהליכי מחשוב מורכבים
• המערכת שלך תשתפר באופן פעיל.

בואו נלך לפי הסדר... בסך הכל, אם ניקח בחשבון את כל מותגי Sportmaster, אז יש לנו יותר מ-1000 חנויות ברוסיה, אוקראינה, סין, קזחסטן ובלארוס. כ-300 רכישות מתבצעות בחנויות אלו מדי יום. כלומר, כל שנייה 000-3 צ'קים נכנסים למערכת שלנו. באופן טבעי, מערכת הנאמנות שלנו עמוסה מאוד. ומכיוון שהוא נמצא בשימוש פעיל, עלינו לספק את הסטנדרטים הגבוהים ביותר של איכותו, מכיוון שכל טעות בתוכנה פירושה הפסדים כספיים, מוניטין ואחרים גדולים.

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

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

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

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

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

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

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

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

utPLSQL בא להציל

האם אתה יודע משהו על סטיבן פוירשטיין?

מדובר בבחור חכם שהקדיש חלק ארוך מהקריירה שלו לעבודה עם אורקל ו-PL/SQL, וכתב מספר די גדול של עבודות בנושא זה. אחד מספריו המפורסמים נקרא: "Oracle PL/SQL. למקצוענים". זה היה סטיבן שפיתח את פתרון utPLSQL, או כפי שהוא מייצג, Unit Testing framework עבור Oracle PL/SQL. פתרון utPLSQL נוצר בשנת 2016, אך ממשיכים לעבוד עליו באופן פעיל ומשוחררות גרסאות חדשות. במועד הדיווח, הגרסה האחרונה מתוארכת ל-24 במרץ 2019.
מה זה. זהו פרויקט קוד פתוח נפרד. הוא שוקל כמה מגה בייט, כולל דוגמאות ותיעוד. מבחינה פיזית, זוהי סכמה נפרדת במסד הנתונים של ORACLE עם קבוצה של חבילות וטבלאות לארגון בדיקות יחידות. ההתקנה אורכת מספר שניות. מאפיין ייחודי של utPLSQL הוא קלות השימוש שלו.
באופן גלובלי, utPLSQL הוא מנגנון להפעלת בדיקות יחידה, כאשר בדיקת יחידה מובנת כהליכי אצווה רגילים של Oracle, אשר ארגונם פועל לפי כללים מסוימים. בנוסף להפעלה, utPLSQL מאחסן יומן של כל ריצות הבדיקה שלך, ויש לו גם מערכת דיווח פנימית.

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

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

"utp_setup", ככלל, מכין את המערכת שלנו להריץ בדיקת יחידה, למשל, יצירת נתוני בדיקה. "utp_teardown" - להיפך, הכל חוזר להגדרות המקוריות ומאפס את תוצאות ההשקה.

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

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

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

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

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

6 כללים של בדיקות אוטומטיות

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

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

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

מקור: www.habr.com