هی هابر!
نام من ماکسیم پونومارنکو است و من یک توسعه دهنده در Sportmaster هستم. من 10 سال سابقه کار در زمینه IT دارم. او کار خود را در تست دستی آغاز کرد، سپس به توسعه پایگاه داده روی آورد. در 4 سال گذشته، با جمع آوری دانش به دست آمده در آزمایش و توسعه، تست را در سطح DBMS به صورت خودکار انجام داده ام.
من بیش از یک سال است که در تیم Sportmaster هستم و در حال توسعه تست خودکار در یکی از پروژه های بزرگ هستم. در ماه آوریل، من و بچه های آزمایشگاه Sportmaster در کنفرانسی در کراسنودار صحبت کردیم، گزارش من "تست های واحد در یک DBMS" نام داشت و اکنون می خواهم آن را با شما به اشتراک بگذارم. متن های زیادی وجود خواهد داشت، بنابراین تصمیم گرفتم گزارش را به دو پست تقسیم کنم. در اول، ما در مورد تست های خودکار و تست به طور کلی صحبت خواهیم کرد، و در دوم، من با جزئیات بیشتر در مورد سیستم تست واحد خود و نتایج کاربرد آن صحبت خواهم کرد.
اول، یک نظریه کمی خسته کننده. تست خودکار چیست؟ این آزمایشی است که با استفاده از نرم افزار انجام می شود و در فناوری اطلاعات مدرن به طور فزاینده ای در توسعه نرم افزار استفاده می شود. این به دلیل این واقعیت است که شرکت ها در حال رشد هستند، سیستم های اطلاعاتی آنها در حال رشد هستند و بر این اساس، میزان عملکردی که نیاز به آزمایش دارد در حال رشد است. انجام تست دستی روز به روز گرانتر می شود.
من برای یک شرکت بزرگ کار می کردم که نسخه های آن هر دو ماه یکبار منتشر می شود. در همان زمان، یک ماه تمام صرف بررسی دستی چندین آزمایشگر شد. به لطف پیاده سازی اتوماسیون توسط تیم کوچکی از توسعه دهندگان، ما توانستیم زمان تست را در یک سال و نیم به 2 هفته کاهش دهیم. ما نه تنها سرعت تست را افزایش داده ایم، بلکه کیفیت آن را نیز بهبود بخشیده ایم. تست های خودکار به طور منظم راه اندازی می شوند و آنها همیشه کل دوره بررسی های موجود در آنها را انجام می دهند، یعنی ما عامل انسانی را حذف می کنیم.
IT مدرن با این واقعیت مشخص می شود که ممکن است از یک توسعه دهنده خواسته شود نه تنها کد محصول را بنویسد، بلکه آزمایش های واحدی را نیز بنویسد که این کد را بررسی می کند.
اما اگر سیستم شما اساساً مبتنی بر منطق سرور باشد چه؟ هیچ راه حل جهانی یا بهترین شیوه در بازار وجود ندارد. به عنوان یک قاعده، شرکت ها این مشکل را با ایجاد سیستم تست خودنویس خود حل می کنند. این سیستم خودکار تست خودکار خودمان است که در پروژه ما ایجاد شده است و من در گزارش خود در مورد آن صحبت خواهم کرد.
تست وفاداری
ابتدا، اجازه دهید در مورد پروژه ای صحبت کنیم که در آن یک سیستم تست خودکار را مستقر کردیم. پروژه ما سیستم وفاداری Sportmaster است (به هر حال، قبلاً در مورد آن نوشتیم ).
اگر شرکت شما به اندازه کافی بزرگ باشد، سیستم وفاداری شما دارای سه ویژگی استاندارد خواهد بود:
- سیستم شما به شدت بارگذاری خواهد شد
- سیستم شما شامل فرآیندهای محاسباتی پیچیده خواهد بود
- سیستم شما به طور فعال بهبود خواهد یافت.
به ترتیب بریم... در مجموع اگر همه برندهای اسپورت مستر را در نظر بگیریم، در روسیه، اوکراین، چین، قزاقستان و بلاروس بیش از 1000 فروشگاه داریم. روزانه حدود 300 هزار خرید در این فروشگاه ها انجام می شود. یعنی در هر ثانیه 000-3 چک وارد سیستم ما می شود. طبیعتاً سیستم وفاداری ما بسیار پر بار است. و از آنجایی که به طور فعال از آن استفاده می شود، باید بالاترین استانداردهای کیفیت آن را ارائه دهیم، زیرا هرگونه خطا در نرم افزار به معنای زیان های مالی، اعتباری و غیره است.
در همان زمان، Sportmaster بیش از صد تبلیغات مختلف را اجرا می کند. تبلیغات متنوعی وجود دارد: تبلیغات محصول وجود دارد، مواردی وجود دارد که به روز هفته اختصاص داده شده است، مواردی وجود دارد که به یک فروشگاه خاص مرتبط هستند، تبلیغاتی برای مبلغ رسید وجود دارد، برای تعداد کالاها وجود دارد. در کل بد نیست مشتریان پاداش ها و کدهای تبلیغاتی دارند که هنگام خرید استفاده می شود. همه اینها به این واقعیت منجر می شود که محاسبه هر سفارش یک کار بسیار غیر ضروری است.
الگوریتمی که پردازش سفارش را پیاده سازی می کند واقعاً وحشتناک و پیچیده است. و هرگونه تغییر در این الگوریتم کاملاً خطرناک است. به نظر می رسید که به ظاهر ناچیزترین تغییرات می تواند منجر به اثرات کاملاً غیرقابل پیش بینی شود. اما دقیقاً چنین فرآیندهای محاسباتی پیچیده ای هستند، به ویژه آنهایی که عملکردهای حیاتی را پیاده سازی می کنند، که بهترین نامزد برای اتوماسیون هستند. بررسی ده ها مورد مشابه با دست بسیار زمان بر است. و از آنجایی که نقطه ورود به فرآیند بدون تغییر است، با یک بار توصیف آن، می توانید به سرعت تست های خودکار ایجاد کنید و مطمئن باشید که عملکرد کار می کند.
از آنجایی که سیستم ما به طور فعال مورد استفاده قرار می گیرد، کسب و کار چیز جدیدی از شما می خواهد، با زمان زندگی کنید و مشتری مدار باشد. در سیستم وفاداری ما، نسخه‌ها هر دو ماه یکبار منتشر می‌شوند. این بدان معناست که هر دو ماه یکبار باید یک رگرسیون کامل کل سیستم را انجام دهیم. در عین حال، به طور طبیعی، مانند هر IT مدرن، توسعه بلافاصله از توسعه دهنده به تولید نمی رود. در مدار توسعه‌دهنده ایجاد می‌شود، سپس به‌طور متوالی از روی میز آزمایش عبور می‌کند، آزاد می‌شود، پذیرش می‌شود و تنها پس از آن به تولید ختم می‌شود. حداقل، در مدارهای تست و آزادسازی، باید یک رگرسیون کامل کل سیستم را انجام دهیم.
ویژگی های توصیف شده تقریباً برای هر سیستم وفاداری استاندارد هستند. بیایید در مورد ویژگی های پروژه خود صحبت کنیم.
از نظر فناوری، 90 درصد منطق سیستم وفاداری ما مبتنی بر سرور است و در اوراکل پیاده‌سازی شده است. یک مشتری در دلفی وجود دارد که عملکرد یک مدیر خودکار محل کار را انجام می دهد. خدمات وب در معرض نمایش برای برنامه های کاربردی خارجی (به عنوان مثال یک وب سایت) وجود دارد. بنابراین، بسیار منطقی است که اگر یک سیستم تست خودکار را مستقر کنیم، آن را روی اوراکل انجام دهیم.
سیستم وفاداری در Sportmaster بیش از 7 سال است که وجود دارد و توسط توسعه دهندگان منفرد ایجاد شده است... میانگین تعداد توسعه دهندگان پروژه ما در این 7 سال 3-4 نفر بوده است. اما در طول یک سال گذشته، تیم ما رشد قابل توجهی داشته است و در حال حاضر 10 نفر روی پروژه کار می کنند. یعنی افرادی به پروژه می آیند که با وظایف، فرآیندها و معماری معمولی آشنا نیستند. و این خطر افزایش می یابد که اشتباهات را از دست بدهیم.
این پروژه با عدم وجود آزمایش کنندگان اختصاصی به عنوان واحدهای کارکنان مشخص می شود. البته تست وجود دارد، اما آزمایش توسط تحلیلگران، علاوه بر سایر مسئولیت های اصلی آنها انجام می شود: برقراری ارتباط با مشتریان تجاری، کاربران، توسعه سیستم مورد نیاز و غیره. و غیره... علیرغم این واقعیت که آزمایش با کیفیت بسیار بالایی انجام می شود (به ویژه ذکر این نکته مناسب است، زیرا ممکن است برخی از تحلیلگران توجه این گزارش را جلب کنند)، اثربخشی تخصص و تمرکز روی یک چیز لغو نشده است. .
با توجه به تمام موارد فوق، برای بهبود کیفیت محصول تحویل شده و کاهش زمان توسعه، ایده تست خودکار روی یک پروژه بسیار منطقی به نظر می رسد. و در مراحل مختلف وجود سیستم وفاداری، توسعه دهندگان فردی تلاش کردند تا کد خود را با تست واحد پوشش دهند. به طور کلی، این یک روند نسبتاً ناپیوسته بود و هرکسی از معماری و روش های خاص خود استفاده می کرد. نتایج نهایی برای آزمایش‌های واحد مشترک بود: آزمایش‌ها توسعه یافتند، برای مدتی مورد استفاده قرار گرفتند، در یک ذخیره‌سازی فایل نسخه‌سازی شده ذخیره شدند، اما در مقطعی اجرا نشدند و فراموش شدند. اول از همه، این به این دلیل بود که آزمایش ها بیشتر به یک مجری خاص گره خوردند و نه به پروژه.
utPLSQL به کمک می آید
آیا چیزی در مورد استفان فوئرشتاین می دانید؟
این مرد باهوشی است که بخش طولانی از حرفه خود را به کار با Oracle و PL/SQL اختصاص داده است و تعداد زیادی کار در این زمینه نوشته است. یکی از کتاب های معروف او به نام: «Oracle PL/SQL. برای حرفه ای ها." این استفان بود که راه‌حل utPLSQL یا همان طور که مخفف آن چارچوب تست واحد برای Oracle PL/SQL است را توسعه داد. راه حل utPLSQL در سال 2016 ایجاد شد، اما همچنان به طور فعال روی آن کار می شود و نسخه های جدید منتشر می شود. در زمان گزارش، آخرین نسخه به 24 مارس 2019 برمی گردد.
چیست؟ این یک پروژه منبع باز جداگانه است. وزن آن چند مگابایت، شامل مثال ها و مستندات است. از نظر فیزیکی، این یک طرح مجزا در پایگاه داده ORACLE با مجموعه ای از بسته ها و جداول برای سازماندهی تست واحد است. نصب چند ثانیه طول می کشد. یکی از ویژگی های متمایز utPLSQL سهولت استفاده از آن است.
در سطح جهانی، utPLSQL مکانیزمی برای اجرای تست های واحد است که در آن تست واحد به عنوان رویه های دسته ای معمولی Oracle درک می شود که سازماندهی آن از قوانین خاصی پیروی می کند. علاوه بر راه‌اندازی، utPLSQL گزارشی از تمام آزمایش‌های شما را ذخیره می‌کند و همچنین دارای یک سیستم گزارش داخلی است.
بیایید به مثالی نگاه کنیم که کد تست واحد چگونه است که با استفاده از این تکنیک پیاده سازی شده است.
بنابراین، صفحه کد یک مشخصات بسته معمولی را با تست های واحد نشان می دهد. الزامات اجباری چیست؟ بسته باید با پیشوند "utp_" باشد. تمام مراحل با تست ها باید دقیقاً یک پیشوند داشته باشند. بسته باید شامل دو رویه استاندارد باشد: "utp_setup" و "utp_teardown". روش اول با راه اندازی مجدد هر تست واحد، روش دوم - پس از راه اندازی فراخوانی می شود.
"utp_setup"، به عنوان یک قاعده، سیستم ما را برای اجرای یک تست واحد، به عنوان مثال، ایجاد داده های آزمایشی آماده می کند. "utp_teardown" - برعکس، همه چیز به تنظیمات اصلی باز می گردد و نتایج راه اندازی را بازنشانی می کند.
در اینجا نمونه‌ای از ساده‌ترین تست واحد است که عادی بودن شماره تلفن مشتری وارد شده را به فرم استاندارد سیستم وفاداری ما بررسی می‌کند. هیچ استاندارد اجباری در مورد نحوه نوشتن رویه ها با آزمون های واحد وجود ندارد. به عنوان یک قاعده، یک روش از سیستم تحت آزمایش فراخوانی می شود و نتیجه برگردانده شده توسط این روش با روش مرجع مقایسه می شود. مهم است که مقایسه نتیجه مرجع و نتیجه بدست آمده از طریق روشهای استاندارد utPLSQL انجام شود.
یک آزمون واحد می تواند هر تعداد بررسی داشته باشد. همانطور که از مثال مشخص است، ما چهار تماس متوالی با روش آزمایش شده برقرار می کنیم تا شماره تلفن عادی شود و بعد از هر تماس نتیجه را ارزیابی کنیم. هنگام توسعه یک تست واحد، باید در نظر داشته باشید که چک هایی وجود دارد که به هیچ وجه روی سیستم تأثیر نمی گذارد و پس از مدتی باید به حالت اولیه سیستم برگردید.
به عنوان مثال، در آزمون واحد ارائه شده، ما به سادگی شماره تلفن ورودی را فرمت می کنیم، که به هیچ وجه بر سیستم وفاداری تأثیر نمی گذارد.
و اگر تست های واحد را با استفاده از روش ایجاد مشتری جدید بنویسیم، پس از هر تست یک کلاینت جدید در سیستم ایجاد می شود که می تواند بر راه اندازی بعدی آزمایش تأثیر بگذارد.
تست های واحد اینگونه اجرا می شود. دو گزینه راه اندازی ممکن وجود دارد: اجرای تمام تست های واحد از یک بسته خاص یا اجرای یک تست واحد خاص در یک بسته خاص.
این همان چیزی است که نمونه ای از یک سیستم گزارش دهی داخلی به نظر می رسد. بر اساس نتایج آزمون واحد، utPLSQL یک گزارش کوچک می سازد. در آن ما نتیجه هر بررسی خاص و نتیجه کلی آزمون واحد را می بینیم.
6 قانون آزمون های خودکار
قبل از شروع به ایجاد یک سیستم جدید برای تست خودکار سیستم وفاداری، همراه با مدیریت، اصولی را تعیین کردیم که تست‌های خودکار آینده ما باید با آنها مطابقت داشته باشد.
- تست های خودکار باید موثر و مفید باشند. ما توسعه دهندگان فوق العاده ای داریم که حتما باید به آنها اشاره کرد، زیرا برخی از آنها احتمالاً این گزارش را خواهند دید و کدهای فوق العاده ای می نویسند. اما حتی کد فوق‌العاده آنها هم بی‌نقص نیست و خطاهایی دارد، دارد و همچنان خواهد داشت. برای یافتن این خطاها به تست خودکار نیاز است. اگر اینطور نیست، یا داریم اتوتست های بدی می نویسیم یا به منطقه مرده ای رسیده ایم که اصولاً در حال توسعه نیست. در هر دو مورد، ما کار اشتباهی انجام می دهیم و رویکرد ما به سادگی معنا ندارد.
- باید از تست های خودکار استفاده شود. بی معنی است که زمان و تلاش زیادی برای نوشتن یک محصول نرم افزاری صرف کنید، آن را در یک مخزن قرار دهید و آن را فراموش کنید. تست ها باید اجرا شوند و تا حد امکان به طور منظم اجرا شوند.
- تست های خودکار باید با ثبات کار کنند. صرف نظر از زمان روز، پایه راه اندازی و سایر تنظیمات سیستم، اجرای آزمایشی باید به همان نتیجه منجر شود. به عنوان یک قاعده، این با این واقعیت تضمین می شود که تست های خودکار با داده های آزمایشی ویژه با تنظیمات سیستم ثابت کار می کنند.
- تست های خودکار باید با سرعت قابل قبولی برای پروژه شما کار کنند. این زمان برای هر سیستم به صورت جداگانه تعیین می شود. برخی از افراد می توانند تمام روز کار کنند، در حالی که برخی دیگر انجام آن را در چند ثانیه ضروری می دانند. کمی بعد به شما خواهم گفت که ما در پروژه خود به چه استانداردهای سرعتی دست یافتیم.
- توسعه Autotest باید انعطاف پذیر باشد. توصیه نمی شود از آزمایش هر عملکردی صرفاً به این دلیل که قبلاً یا به دلایل دیگری آن را انجام نداده ایم خودداری کنید. utPLSQL هیچ محدودیتی برای توسعه اعمال نمی کند و اوراکل در اصل به شما اجازه می دهد موارد مختلفی را پیاده سازی کنید. اکثر مشکلات راه حلی دارند، فقط مسئله زمان و تلاش است.
- قابلیت استقرار ما چندین غرفه داریم که باید در آنها آزمایشات را اجرا کنیم. در هر غرفه، یک داده Dump را می توان در هر زمان به روز کرد. لازم است پروژه ای با تست های اتوماتیک به گونه ای انجام شود که بتوانید بدون دردسر نصب کامل یا جزئی آن را انجام دهید.
و در پست دوم یکی دو روز دیگر به شما خواهم گفت که چه کار کردیم و چه نتایجی گرفتیم.
منبع: www.habr.com