قسمت اول - .
یک موقعیت را تصور کنید. شما با وظیفه توسعه عملکرد جدید روبرو هستید. شما تجربه ای از پیشینیان خود دارید. با فرض اینکه هیچ تعهد اخلاقی ندارید، چه کار می کنید؟
اغلب، همه تحولات قدیمی فراموش می شوند و همه چیز از نو شروع می شود. هیچ کس دوست ندارد کد شخص دیگری را بررسی کند، و اگر وقت دارید، چرا شروع به ایجاد سیستم خود نکنید؟ این یک رویکرد معمولی است و از بسیاری جهات صحیح است. اما در پروژه مان طور دیگری عمل کردیم. ما سیستم آزمایش خودکار آینده را بر اساس پیشرفت‌های آزمایش‌های واحد بر روی utPLSQL از پیشینیان خود قرار دادیم و سپس در چندین جهت موازی به کار پرداختیم.
- بازیابی تست های واحد قدیمی بازیابی به معنای تطبیق تست ها با وضعیت موجود سیستم وفاداری و تطبیق تست ها با استانداردهای utPLSQL است.
- حل مشکل با درک و اینکه دقیقاً چه روش ها و فرآیندهایی را با تست های خودکار پوشش داده ایم. یا باید این اطلاعات را در ذهن خود نگه دارید یا مستقیماً بر اساس کد تست های خودکار نتیجه گیری کنید. بنابراین تصمیم گرفتیم یک کاتالوگ ایجاد کنیم. ما یک کد یادگاری منحصر به فرد را به هر تست خودکار اختصاص دادیم، یک توضیحات ایجاد کردیم و تنظیمات را اصلاح کردیم (مثلاً در چه شرایطی باید اجرا شود، یا اگر اجرای آزمایشی با شکست مواجه شود چه اتفاقی باید بیفتد). در اصل، ما ابرداده‌های مربوط به تست‌های خودکار را پر کردیم و این ابرداده را در جداول استاندارد طرحواره utPLSQL قرار دادیم.
- تعریف استراتژی توسعه، به عنوان مثال. انتخاب عملکردی که توسط تست‌های خودکار تأیید می‌شود. ما تصمیم گرفتیم به سه چیز توجه کنیم: بهبودهای جدید در سیستم، حوادث ناشی از تولید، و فرآیندهای کلیدی سیستم. بنابراین، ما به موازات انتشار، از کیفیت بالاتر آن اطمینان می‌دهیم، همزمان دامنه رگرسیون را گسترش می‌دهیم و قابلیت اطمینان سیستم را در مکان‌های بحرانی تضمین می‌کنیم. اولین چنین گلوگاهی، فرآیند توزیع تخفیف و پاداش با چک بود.
- به طور طبیعی، ما شروع به توسعه خودکار تست های جدید کردیم. یکی از اولین وظایف انتشار، ارزیابی عملکرد نمونه های از پیش تعریف شده سیستم وفاداری بود. پروژه ما دارای بلوکی از پرس و جوهای sql ثابت است که مشتریان را با توجه به شرایط انتخاب می کند. برای مثال، فهرستی از تمام مشتریانی که آخرین خریدشان در یک شهر خاص بوده است، یا فهرستی از مشتریانی که میانگین مبلغ خریدشان بالاتر از مقدار مشخصی است، دریافت کنید. با داشتن تست‌های خودکار، نمونه‌های از پیش تعریف‌شده، پارامترهای عملکرد معیار ثابت را بررسی کردیم و به‌علاوه آزمایش بار را دریافت کردیم.
- کار با تست های خودکار باید راحت باشد. دو اقدام متداول عبارتند از اجرای تست‌های خودکار و تولید داده‌های تست. به این ترتیب دو ماژول کمکی در سیستم ما ظاهر شد: ماژول راه اندازی و ماژول تولید داده.
راه‌انداز به عنوان یک رویه عمومی با یک پارامتر متن ورودی نشان داده می‌شود. به عنوان یک پارامتر، می توانید یک کد یادداشت خودکار، نام بسته، نام آزمایش، تنظیمات تست خودکار یا یک کلمه کلیدی رزرو شده را ارسال کنید. این رویه تمام تست‌های خودکار را که شرایط را برآورده می‌کنند، انتخاب و اجرا می‌کند.
ماژول تولید داده به صورت بسته ای ارائه می شود که در آن برای هر شی از سیستم تحت آزمایش (جدولی در پایگاه داده)، رویه خاصی ایجاد شده است که داده ها را در آنجا درج می کند. در این روش، مقادیر پیش‌فرض حداکثر پر می‌شوند، که ایجاد اشیا را به معنای واقعی کلمه با کلیک یک انگشت تضمین می‌کند. و برای سهولت استفاده، الگوهایی برای داده های تولید شده ایجاد شد. به عنوان مثال، با یک تلفن آزمایشی و یک خرید تکمیل شده، یک مشتری با سن خاصی ایجاد کنید.
- تست های خودکار باید در یک زمان معقول برای سیستم شما اجرا و اجرا شوند. بنابراین، یک راه اندازی شبانه روزانه سازماندهی شد که بر اساس نتایج آن گزارشی از نتایج تولید شده و از طریق پست شرکتی برای کل تیم توسعه ارسال می شود. پس از بازیابی خودکار تست های قدیمی و ایجاد تست های جدید، کل زمان اجرا 30 دقیقه بود. چنین عملکردی برای همه مناسب بود، زیرا پرتاب در ساعات غیرفعال انجام شد.
اما باید روی بهینه سازی سرعت کار کار می کردیم. سیستم وفاداری تولید در شب به روز می شود. به عنوان بخشی از یکی از نسخه ها، مجبور شدیم فوراً تغییراتی را در شب ایجاد کنیم. نیم ساعت انتظار برای نتایج تست های خودکار در ساعت سه بامداد باعث خوشحالی مسئول انتشار نشد (درودهای پرشور به الکسی واسیوکوف!) و صبح روز بعد سخنان گرم زیادی به سیستم ما گفته شد. اما در نتیجه یک استاندارد 5 دقیقه ای برای کار تعیین شد.
برای سرعت بخشیدن به عملکرد، ما از دو روش استفاده کردیم: ما شروع به اجرای خودکار تست ها در سه رشته موازی کردیم، زیرا این به دلیل معماری سیستم وفاداری ما بسیار راحت است. و زمانی که تست خودکار داده های تست را برای خود ایجاد نمی کند، اما سعی می کند چیزی مناسب در سیستم پیدا کند، رویکرد را رها کردیم. پس از ایجاد تغییرات، زمان کل عملیات به 3-4 دقیقه کاهش یافت.
- یک پروژه با تست های خودکار باید بتواند در غرفه های مختلف مستقر شود. در ابتدای سفر، تلاش هایی برای نوشتن فایل های دسته ای خودمان انجام شد، اما مشخص شد که نصب خودکار خودنویس یک وحشت کامل است و ما به سمت راه حل های صنعتی روی آوردیم. با توجه به اینکه پروژه مستقیماً کدهای زیادی دارد (اول از همه، ما کد تست‌های خودکار را ذخیره می‌کنیم) و داده‌های بسیار کمی (داده‌های اصلی فراداده‌های مربوط به تست‌های خودکار است)، ادغام آن در تست‌های خودکار بسیار آسان است. پروژه Liquibase
این یک کتابخانه مستقل از پایگاه داده منبع باز برای ردیابی، مدیریت و اعمال تغییرات طرحواره پایگاه داده است. از طریق خط فرمان یا چارچوب هایی مانند Apache Maven مدیریت می شود. اصل عملکرد Liquibase بسیار ساده است. ما پروژه ای داریم که به روش خاصی سازماندهی شده است، که شامل تغییرات یا اسکریپت هایی است که باید روی سرور هدف قرار گیرند و فایل های کنترلی که تعیین می کند این تغییرات به چه ترتیب و با چه پارامترهایی باید نصب شوند.
در سطح DBMS، یک جدول ویژه ایجاد می شود که در آن Liquibase گزارش بازگشتی را ذخیره می کند. هر تغییر دارای یک هش محاسبه شده است که هر بار بین پروژه و وضعیت موجود در پایگاه داده مقایسه می شود. به لطف Liquibase، ما به راحتی می توانیم تغییرات سیستم خود را در هر مداری اعمال کنیم. اکنون تست‌های خودکار روی حلقه‌های آزمایش و انتشار و همچنین روی کانتینرها (حلقه‌های شخصی توسعه‌دهندگان) اجرا می‌شوند.
بنابراین، بیایید در مورد نتایج اعمال سیستم تست واحد خود صحبت کنیم.
- البته، اول از همه، ما متقاعد شده ایم که شروع به توسعه نرم افزارهای بهتر کرده ایم. تست‌های خودکار روزانه اجرا می‌شوند و در هر نسخه ده‌ها اشکال پیدا می‌کنند. علاوه بر این، برخی از این خطاها فقط به طور غیرمستقیم با عملکردی مرتبط هستند که ما واقعاً می خواستیم آن را تغییر دهیم. تردیدهای قوی وجود دارد که این خطاها با آزمایش دستی پیدا شده اند.
- تیم اطمینان حاصل کرد که عملکرد خاصی به درستی کار می کند... اول از همه، این به فرآیندهای حیاتی ما مربوط می شود. به عنوان مثال، در طول شش ماه گذشته، علیرغم تغییراتی که در هر نسخه انجام شده، در توزیع تخفیف ها و پاداش ها با چک مشکلی نداشته ایم، اگرچه در دوره های قبل خطاها با مقداری تکرار رخ می دهد.
- ما موفق شدیم تعداد تکرارهای آزمایشی را کاهش دهیم. با توجه به اینکه تست‌های خودکار برای عملکردهای جدید نوشته شده‌اند، تحلیلگران و آزمایش‌کنندگان پاره وقت کدی با کیفیت بالاتر دریافت می‌کنند، زیرا قبلا تایید شده است
- بخشی از پیشرفت های تست خودکار توسط توسعه دهندگان استفاده می شود. به عنوان مثال، داده های آزمایشی روی کانتینرها با استفاده از ماژول تولید شی ایجاد می شوند.
- مهم است که ما یک "پذیرش" سیستم تست خودکار توسط توسعه دهندگان را ایجاد کرده ایم. این درک وجود دارد که این مهم و مفید است. و با توجه به تجربه خودم می توانم بگویم که این موضوع بسیار دور از واقعیت است. تست‌های خودکار باید نوشته شوند، باید نگهداری و توسعه داده شوند، نتایج تجزیه و تحلیل شوند، و اغلب این هزینه‌های زمانی ارزشش را ندارند. رفتن به سمت تولید و مقابله با مشکلات در آنجا بسیار آسان تر است. در کشور ما، توسعه دهندگان صف می کشند و می خواهند عملکرد خود را با تست های خودکار پوشش دهند.
بعدی چیست؟
بیایید در مورد برنامه های توسعه پروژه تست خودکار صحبت کنیم.
البته، تا زمانی که سیستم وفاداری Sportmaster زنده است و به پیشرفت خود ادامه می‌دهد، تست‌های خودکار نیز تقریباً بی‌پایان قابل توسعه هستند. بنابراین، جهت اصلی توسعه، گسترش منطقه تحت پوشش است.
با افزایش تعداد تست های خودکار، کل زمان کار آنها به طور پیوسته افزایش می یابد و ما دوباره باید به موضوع عملکرد برگردیم. به احتمال زیاد راه حل افزایش تعداد نخ های موازی خواهد بود.
اما اینها راههای آشکار توسعه هستند. اگر در مورد چیزی غیر پیش پا افتاده صحبت کنیم، موارد زیر را برجسته می کنیم:
- اکنون تست‌های خودکار در سطح DBMS مدیریت می‌شوند، یعنی. دانش PL/SQL برای کار موفق لازم است. در صورت لزوم، مدیریت سیستم (به عنوان مثال، راه اندازی یا ایجاد ابرداده) می تواند توسط نوعی پنل مدیریت با استفاده از Jenkins یا چیزی مشابه حذف شود.
- همه شاخص های کمی و کیفی را دوست دارند. برای آزمایش خودکار، چنین شاخص جهانی پوشش کد یا متریک پوشش کد است. با استفاده از این اندیکاتور می توانیم تعیین کنیم که چند درصد از کد سیستم مورد آزمایش ما تحت پوشش تست های خودکار قرار دارد. با شروع از نسخه 12.2، Oracle توانایی محاسبه این معیار را فراهم می کند و استفاده از بسته استاندارد DBMS_PLSQL_CODE_COVERAGE را پیشنهاد می کند.
سیستم تست خودکار ما بیش از یک سال قدمت دارد و ممکن است زمان ارزیابی پوشش فرا رسیده باشد. در آخرین پروژه من (پروژه ای که توسط Sportmaster نیست) این اتفاق افتاد. یک سال پس از کار بر روی تست‌های خودکار، مدیریت این وظیفه را تعیین کرد که چند درصد از کد را تحت پوشش قرار دهیم. با بیش از 1٪ پوشش، مدیریت خوشحال خواهد شد. ما، توسعه دهندگان، انتظار نتیجه حدود 10٪ را داشتیم. پوشش کد را خراب کردیم، آن را اندازه گرفتیم، 20٪ گرفتیم. برای جشن گرفتن، ما برای جایزه رفتیم، اما اینکه چگونه به دنبال آن رفتیم و بعد به کجا رفتیم، داستان کاملاً متفاوتی است.
- تست‌های خودکار می‌توانند خدمات وب در معرض نمایش را آزمایش کنند. اوراکل این امکان را به شما می دهد و دیگر با تعدادی مشکل مواجه نخواهیم شد.
- و البته، سیستم تست خودکار ما را می توان در پروژه دیگری اعمال کرد. راه حلی که ما دریافت کردیم جهانی است و فقط به استفاده از Oracle نیاز دارد. شنیده ام که علاقه ای به تست خودکار روی پروژه های دیگر Sportmaster وجود دارد و شاید به سراغ آنها برویم.
یافته ها
بیایید خلاصه کنیم. در پروژه سیستم وفاداری در Sportmaster، ما موفق شدیم یک سیستم تست خودکار را پیاده سازی کنیم. اساس آن راه حل utPLSQL از Stephen Feuerstein است. در اطراف utPLSQL کدی برای تست‌های خودکار و ماژول‌های خودنویس کمکی وجود دارد: یک راه‌انداز، یک ماژول تولید داده و موارد دیگر. تست‌های خودکار روزانه اجرا می‌شوند و مهم‌تر از همه، کار و فایده دارند. ما متقاعد شده ایم که شروع به انتشار نرم افزار با کیفیت بالاتر کرده ایم. در عین حال، راه حل به دست آمده جهانی است و می تواند آزادانه برای هر پروژه ای که در آن نیاز به سازماندهی آزمایش خودکار در DBMS Oracle باشد، اعمال شود.
PS معلوم شد که این مقاله خیلی خاص نیست: متن زیادی وجود دارد و عملاً هیچ نمونه فنی وجود ندارد. اگر موضوع در سطح جهانی جالب است، پس ما آماده ایم آن را ادامه دهیم و با ادامه بازگردیم، جایی که به شما خواهیم گفت که در طول شش ماه گذشته چه تغییراتی کرده است و نمونه هایی از کد ارائه می دهیم.
اگر نکاتی وجود دارد که باید در آینده بر آنها تأکید شود یا سؤالاتی که نیاز به افشا دارند، نظرات خود را بنویسید.
فقط کاربران ثبت نام شده می توانند در نظرسنجی شرکت کنند. ، لطفا.
در این مورد بیشتر بنویسیم؟
-
بله حتما
-
نه ممنون
12 کاربر رای دادند. 4 کاربر رای ممتنع دادند.
منبع: www.habr.com