تیستن جامعه مهندسین تست نرم‌افزار ایران
نوشته های مرتبط
خلاصه: شیوه های دقیق تقویت Performance به انضمام انعطاف‌پذیری(Resilience) و تست به صورت مداوم برای این جوانب، راه‌هایی عالی برای در اختیار گرفتن یک مشکل قبل از شروع آن هستند. در اینجا نیز مانند بسیاری از جوانب تست، کیفیت Performance بسیار مهمتر از تعداد تست‌هاییست که انجام شده است. در اینجا هفت نکته ساده برای ایجاد یک Performance مناسب و شیوه مهندسی انعطاف‌پذیری ارائه شده است.
انعطاف‌پذیری و Performance نرم‌افزار، مولفه‌های کلیدی تجربه کاربری(User Experience-UX) هستند، اما از آنجایی که صنعت نرم افزار DevOps را در آغوش گرفته است، جنبه‌های Performance و انعطاف پذیری روند کاهشی را آغاز کرده‌اند. مسائل مربوط به Performance اغلب تا زمانی که نرم‌افزار به طور کامل با شکست مواجه نشود، نادیده گرفته می‌شوند.
با این حال، همه ما می‌دانیم Performance به طور ناگهانی افول نمی‌کند. همانطور که نرم‌افزار در هر Itteration منتشر می‌شود و پیرو آن به حجم کد اضافه می‌شود، باعث بروز هزینه‌های Performance به همراه با حلقه‌های منطقی اضافی می‌شود. این موارد قادر هستند همه چیز را خراب کرده و همچنین ثبات(Stability)را هست که در آن همه چیز می تواند خراب شود و ثبات کلی را تحت تأثیر سیستم را تحت الشعاع قرار دهند.
مشکلاتی از قبیل Performance معیوب یا Availability در نرم‌افزار تقریبا همیشه به دلیل تغییر کد حادث می‌شوند. برخورداری از شیوه های دقیق تقویت Performance به انضمام انعطاف پذیری و تست به صورت مداوم برای این جوانب، راه‌هایی عالی برای در اختیار گرفتن یک مشکل قبل از شروع آن هستند. در اینجا نیز مانند بسیاری از جوانب تست، کیفیت Performance بسیار مهمتر از تعداد تست‌هاییست که انجام شده است. در اینجا هفت نکته ساده برای ایجاد یک Performance مناسب و شیوه مهندسی انعطاف‌پذیری ارائه شده است.
۱- استفاده از Benchmarkها(محک) و تغییر فقط یک متغیر در زمان
در مهندسی انعطاف‌پذیری و Performance، یک Benchmark عبارتس از یک مشکل یا تست استاندارد که به عنوان مبنایی برای ارزیابی یا مقایسه استفاده می‌شود. ما چنین تست‌هایی را تعریف می‌کنیم تا بتوانیم آنها را با یکدیگر مقایسه کنیم. برای مقایسه، یک عنصر را تغییر داده و تاثیر آن تغییر را در برابر تست دیگری اندازه‌گیری می‌کنیم.
در طی فرآیند Continuous Integration(یکپارچه‌سازی مداوم)، ما نسخه‌های جدیدی از نرم‌افزار را برای ارزیابی این موضوع که تغییرات کد چه تأثیری بر Performance و انعطاف‌پذیری نرم‌افزارمان دارند، Benchmark می‌کنیم. در بعضی Benchmarkهای دیگر می‌خواهیم بسنجیم که چگونه نرم‌افزار ما بر روی سخت‌افزار‌های با اندازه‌های مختلف اجرا می‌شود. از آنجایی که ما از File Systemها، دیتابیس‌ها، سیستم‌عامل‌ها، پلتفرم‌ها و معماری‌های چندگانه پشتیبانی می‌کنیم، می‌خواهیم نه تنها قادر به تعریفِ چگونگی حصول بهترین Performance و انعطاف‌پذیری باشیم، بلکه بتوانیم آنها را با یکدیگر مقایسه نیز بکنیم.
اینها همگی شیوه‌های Benchmark معتبر است زیرا ما یک عنصر را تغییر می‌دهیم و تاثیر آن تغییر را اندازه‌گیری می‌کنیم. با این حال، اگر ما بایستی نسخه نرم‌افزار تحت تست و سخت‌افزاری که به صورت همزمان در حال تست آن هستیم را تغییر دهیم و سپس سعی کنیم نتایج را مقایسه کنیم، نمی‌توانیم بفهمیم که آیا تغییرات مشاهده شده به دلیل یک Change خاص است، یا به دلیل Change دیگریست، و یا ترکیبی از هر دو باعث چنین تغییراتی شده است(اغلب اوقات، ترکیب تغییرات نسبت به زمانیکه به صورت جداگانه رخ می‌دهند، آثار متفاوتی دارند.)
در مهندسی Performance سعی کنید سیب‌ها را با سیب‌ها مقایسه کنید(کنایه‌ای بر مقایسه موارد مشاله با هم). علاوه بر این از Benchmarkها استفاده کنید و فقط یک متغیر را در نسخه‌های مختلفِ تستی که می‌خواهید انجام دهید، تغییر دهید.
۲- حافظه، پردازنده، دیسک و استفاده از شبکه(Network Usage) را مانیتور کنید
ازآنجایی که مهندسی Performance و انعطاف‌پذیری تلاشی علمی است، می‌توان می‌توان آنرا صرفا با گشتن به دنبال توضیح عینیِ رویدادهایی که می‌بینیم(البته در یک روش تجدیدپذیر) بدست آورد. این یعنی ما به اندازه‌گیری نیاز داریم.
برای مهندسی Performance، نه تنها ما باید نرم‌افزارهایی را که تست می‌کنیم اندازه‌گیری کنیم، بلکه سخت افزار را هم باید تحت تست قرا گیرد. نظارت بر حافظه، پردازشگر، دیسک و استفاده از شبکه برای تجزیه و تحلیل ما کلیدیست. ما همچنین باید بدانیم که چگونه این منابع تخصیص یافته، چرا که این موضوع به نیازهای پردازشی ما مربوط می‌شود.
در فناوری اطلاعات همیشه اطلاعات را از یک نقطه به دیگری انتقال می‌دهیم و آن را تبدیل می‌کنیم. در طول این راه، ما با افزونگی(Redundancy) مواجه می‌شویم. بعضی از این افزونگی‌ها یک زباله(Waste) یا سربار(Overhead) است و بعضی دیگر از آنها ضروری هستند، زیرا که به ما اجازه می‌دهد تا از یکپارچگی داده(Data Integrity) و امنیت اطلاعات(Security) اطمینان حاصل کنیم. مهندسی Performance تماما در مورد حذف سربار و افزودن یکپارچگی داده است.
۳- هر تست را حداقل سه بار اجرا کنید
قبل از اینکه بتوانیم نتایج تست را مقایسه کنیم، باید اطمینان حاصل کنیم که اعداد مورد نظر ما قابل اعتماد هستند. هربار که یک تست را اجرا می‌کنیم، انتظار داریم که اگر همان تست را تحت شرایط مشابه در زمان متفاوتی اجرا کنیم، نتایج و معیارهای مشابهی بدست آوریم.
اما هنگامی که برای اولین بار یک تست را اجرا می‌کنیم، هیچ سابقه‌ای از این تست در شرایط جدید نداریم تا تصمیم بگیریم که آیا نتایج ما قابل تکرار هستند یا خیر. در نظر داشته باشید که تست‌های قبلی که در آنها یکی از مولفه ها با سایر مولفه ها فرق دارد نمی تواند برای تکرار نتایج به حساب آورده شود. تنها همان تست مشابه که چند بار اجرا شده می تواند به ما اجازه دهد تا به نتایج‌مان اعتماد کنیم.
نتایجی که بتوانیم به آن اعتماد کنیم یک عنصر کلیدیست، بنابراین توصیه می‌کنم که نتایج تست را برای مقایسه Performance را در نظر نگیرید مگر اینکه حداقل سه بار آن را امتحان کرده باشید. حتی پنج بار برای اطمینان از صحت تست بهتر هم هست. برای انتشار ویژه مشتری و یا انتشار عمومی Test Execution بیشتری لازم است.
۴- به واریانس زیر ۳ درصد برسید
با این همه هنوز در مورد نتایج، باید ثابت کنیم که همان تست در زمان‌های مختلف، نتیجه قبلی را تولید می‌کند. یک شاخص کلیدی، واریانسِ متریکِ اولیه( به آن تغییرپذیری یا Variability نیز می‌گویند) است. واریانس یک متریک است که بیانگر اختلاف درصد بهترین و بدترین اجرای یک تست است.
بگذارید یک تست Performance را در نظر بگیریم که در آن متریک اولیه عبارتست از اندازه‌گیری بازده(Throughput) در تراکنش‌های(Transaction) یک ثانیه‌ای. اگر ما یک تست داشته باشیم که بدترین بازده اجرایی آن ۱۰۰ تراکنش در ثانیه باشد و بهترین اجرا را با ۱۱۰ تراکنش در ثانیه داشته باشیم ، واریانس ما ۱۰ درصد خواهد بود:
- مقدار کمتر: LowV
- مقدار بزرگتر: LrgV
- واریانس: Var
( LrgV- LowV)/LowV = Var
(۱۱۰ – ۱۰۰)/۱۰۰ = ۰٫۱
به همین ترتیب، برای تست انعطاف‌پذیری(Resilience Test) که در آن متریک اولیه زمان بازیابی یا Recovery Time(بر مبنای ثانیه) است، اگر ما یک تست با بدترین زمان بازیابی پنج دقیقه‌ای داشته باشیم و در نقطه مقابل بهترین زمان بازیابی ما چهار دقیقه باشد، واریانس ما ۲۵ درصد است.
واریانس شاخصی کلیدیست که به ما می‌گوید نتایج ما قابل اعتماد است یا نه. بازه واریانس‌ها معانی مختلفی دارند که در زیر به آنها اشاره می‌کنیم:
- واریانس کمتر از ۳ درصد به این معنی است که نتایج ما قابل اعتماد هستند.
- واریانس بین ۳ تا ۵ درصد به این معنیست که نتایج قابل قبول و قابل تکرار هستند، اما با امکان پیشرفت برای بهبود ثبات تست، محیط یا نرم افزار تحت تست.
- واریانس بین ۶ تا ۱۰ درصد بدین معنست که نمی‌توانیم نتایج خود را تکرار کنیم و باید به طور جدی بررسی کنیم که چرا چنین واریانس بالایی داریم.
- هر تست با واریانس بیش از ۱۰ درصد نمی‌تواند برای بررسی Performance مورد استفاده قرار گیرد.
۵- تست‌های بار(Load Test) خود را حداقل نیم ساعت اجرا کنید
تست بار اغلب با هدف اندازه‌گیری ظرفیت یک سیستم برای استفاده‌های خاص انجام می شود. هدف این است که سیستم را برای پردازش بیشترین حجم کار در کوتاه ترین مدت (البته بدون شکست) به کار ببندیم. تجربه می‌گوید برای اندازه‌گیری چنین تست‌هایی، باید Performance اندازه گرفته شده حداقل برای سی دقیقه پایدار باشد.
هنگامی که شما روی آن فکر می‌کنید، تنها چیزی که با تست بارگیری ۱۵ دقیقه‌ای اثبات کرده‌اید این است که سیستم می‌تواند بار را برای ۱۵ دقیقه اداره کند. علاوه بر این، اجرای کوتاهتر، بیشتر درگیر واریانس مصنوعی خواهد شد.
علاوه بر تمام این موارد در مهندسی Performance، به زمان برای آماده شدن نیاز داریم؛ چرا که اولین اجراها همیشه در اولین فراخوانی ها کندتر هستند. حتی در یک سیستم آماده شده، اولین تراکنش‌های یک تست احتمالا کندتر خواهند بود و لزوما در بین چندین اجرا مشابه نخواهند بود. به همین دلیل واریانس مصنوعی خواهد بود. دریک تست سی دقیقه‌ای یا بیشتر، این تست‌ها بروز نخواهند کرد نمایش داده نخواهند شد و احتمال کمی دارد که واریانس ایجاد نمایند.
اگر مدت تست بار کمتر از سی دقیقه باشد، نتایج آن از نقطه نظر مهندسی Performance اهمیت کمتری خواهند داشت. تستی که حداقل نیم ساعته باشد، دوره‌های دست گرمی و بی‌ارزش را حذف می‌کند.
۶- ثابت کنید که نتایج Load شما می‌تواند حداقل برای ۲ ساعت ادامه بیابد
باز هم حداقل نیم ساعت را توصیه می‌کنیم. همانطور که در بند قبلی توضیح داده شد، تنها چیزی که با تست بار سی دقیقه‌ای ثابت کرده‌اید این است که سیستم می‌تواند بار را به مدت سی دقیقه اداره کند. در حالی که سی دقیقه برای تشخیص تغییرات Performance جدید آنچنان که معرفی شده‌اند کافی خواهد بود. اما به منظور قانونی کردن تست‌ها را در وضعیت “کاملا قابل اطمینان قرار دهیم” لازم است بتوانیم ثابت کنیم که آنها می‌توانند برای حداقل دو ساعت زیر همان بار اجرا شوند.
یک Peak Load باید بی نهایت پایدار باشد. اثبات اینکه بار می‌تواند برای دو ساعت اجرا شود، اولین گام خوب در این کار است. توصیه می‌کنیم برای شش، دوازده و بیست و چهار ساعت به صورت Milestone هدف‌گذاری کنید و در صورت امکان ثابت کنید که می‌توانید این تست بار را برای پنج روز متوالی اجرا کنید.
توجه داشته باشید که این تست‌های “استقامت زیر بار” برای اثبات پایداری در مورد نتایج بار است. لازم نیست آنها با هر تغییر کد اجرا شوند، بلکه فقط برای اثبات پایداری تعداد بار هستند.
با اثبات دو ساعت پایداری شروع کنید.
۷- اطمینان حاصل کنید که اتوماسیون خوبی دارید
نمی‌توانید بدون اتوماسیون خوب، مهندسی Performance موفقی داشته باشید. آیا زمان بیشتری را صرف تجزیه و تحلیل نتایج تست خود(که در خودکارسازی خوب اتفاق می‌افتد) می‌کنید، زمان بیشتر را برای اجرای تست‌ها و ایجاد تغییرات در اتوماسیون موجود (که در خودکارسازی بد اتفاق می‌افتد) صرف می‌کنید؟
اگر فکر می‌کنید می‌توانید اقدامات اتوماسیون خود را بهبود بخشید، با این ۷ اصل شروع کنید:
- متوجه شوید که چرا از اتوماسیون استفاده کرده‌اید
- مراحل اتوماسیون خود را درک کنید
- فقط Happy Path و یا Unhappy Path را در نظر نگیرید
- بلاک‌هایی(Block) را بسازید که بتوانید آنها را روی یکدگر بچینید
- اتوماسیون را خیلی زود Plan کنید
- سناریوی اتوماسیون خود را بچینید
- معیارهای مربوط به اتوماسیون‌تان را جمع‌آوری کنید
تست های خود را برای رسیدن به نتایج معنادار مهندسی کنید
مؤثرترین راه برای رسیدن به Performance و قابلیت انعطاف نرم افزار با تست‌های مفید و مؤثر امکان پذیر است. اما بازبینی و بازسازی تست‌ها نباید بیش از حد پیچیده باشد. پیروی از این هفت نکته ساده، بسیاری از مسائل مربوط به Performance را قبل از آنکه تبدیل به مشکلات واقعی شوند، حل می‌کند
