اگر سی شارپ زبان مورد استفاده شما نیست، نگران نباشید. فقط به اصول اولیه این تکنیک تست نیاز دارید. اگر می خواهید اصول اولیه تکنیک تست بار را یاد بگیرید، می توانم خواندن این مطلب را به شما توصیه کنم.
جهت جلوگیری از خستگی خواننده کل مطلب را در دو بخش تقسیم میکنم:
1- بخش اول شامل توضیح اصول تست و مشاهده یک نمونه
2- بخش دوم شامل آموزش تست نویسی واقعی و بررسی عمیق تر نتایج تست بار(شما در حال خواندن این بخش هستید)
هر تست NBomber از سه بخش اصلی تشکیل شده است:
علاوه بر سه قسمت اصلی ذکر شده سه بخش اختیاری هم وجود دارند:
ما قصد داریم که یک سناریو، شامل سه مرحله را تست کنیم. کاربر باید وارد شود و بتواند داشبورد خود را ببیند. بنابر این عملکرد این سناریو بسیار مهم می باشد.
این APIها داده ها را فقط به کاربران احراز هویت شده برمیگرداند.
ابتدا فرایند احراز هویت را توسط NBomber انجام میدهیم:
public static void Run() { var httpFactory = ClientFactory.Create( name: "http_factory", clientCount: 5, // we need to init our client with our API token initClient: (number, context) => { var client = new HttpClient(); client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue( "Bearer", "<your access token>"); return Task.FromResult(client); });
در کد فوق ما 5 کلاینت ایجاد کردیم.برای احراز هویت درخواست ها در NBomber باید هدر Authorization را بر اساس نیاز های سرویس خود تنظیم کنیم.
در مرحله بعد ما گام های تست را ایجاد میکنیم:
var load_user_by_email = Step.Create("load_user_by_email", clientFactory: httpFactory, execute: async context => { var response = await context.Client.GetAsync( baseUrl + "users/bySignedInUser"); return response.IsSuccessStatusCode ? Response.Ok() : Response.Fail(); }); var loadUserCompanies = Step.Create("load_User_companies", clientFactory: httpFactory, execute: async context => { var response = await context.Client.GetAsync( baseUrl + "companies/bySignedInUser"); return response.IsSuccessStatusCode ? Response.Ok() : Response.Fail(); }); var loadCpmpanyProjects = Step.Create("load_company_projects", clientFactory: httpFactory, execute: async context => { var response = await context.Client.GetAsync( baseUrl + "projects/company"); return response.IsSuccessStatusCode ? Response.Ok() : Response.Fail(); });
مرحله بعد باید سناریو های خود را مشخص کنیم:
var scenario = ScenarioBuilder.CreateScenario("index_requests",
load_user_by_email, loadUserCompanies, loadCpmpanyProjects)
.WithLoadSimulations(new[]
{
// from the nBomber docs:
// It's to model an open system.
// Injects a random number of scenario copies (threads) per 1 sec
// defined in scenarios per second during a given duration.
// Every single scenario copy will run only once.
// Use it when you want to maintain a random rate of requests
// without being affected by the performance of the system under test.
Simulation.InjectPerSecRandom(minRate: 5, maxRate: 10, during: TimeSpan.FromMinutes(1))
});
در آخر تست را رجیستر کرده و جهت اجرا Program.cs را تنظیم خواهیم کرد.
NBomberRunner .RegisterScenarios(scenario) .Run();
class Program { static void Main(string[] args) { indexLoadTests.Run(); } }
پس از اجرای تست، بلافاصله نتایج تست را در داخل خط فرمان همانطور که در قسمت اول توضیح داده شد مشاهده خواهید کرد. اما این تنها خروجی تست نیست. علاوه بر خروجی خط فرمان یک فایل HTML و md زیبا برای اشتراک نتیجه تست یا ذخیره آن تولید خواهد شد که در مسیر زیر ذخیره می شود:
\bin\Release\net6.0\reports
می توانید نتایج ارزیابی را در فایل HTML مشاهده کنید.نمونه در زیر قابل مشاهده است.
میتوانید آمار درخواست های موفق و ناموفق را مشاهده کنید.
بعد از اجرا دوباره تست نتایج ارزیابی به شکل زیر تغییر خواهد کرد:
نمودار های زیر تصویر آمار تاخیر را از جدول خروجی که در خط فرمان تولید شد به شکل زیبا تر نشان می دهد. همچنین می توانیم نمودار تست های موفق و ناموفق را ببینیم. اما هنوز تمام نشده است!
سمت چپ منو، می توانید سناریو های اجرا شده را نیز مرور کنید و هر سناریو را با جزئیات بیشتری ببینید.
در حال حاضر ما فقط یک سناریو ایجاد کرده ایم. در این صفحه، می توانید دوباره جدولی را با اطلاعات هر گام از این سناریو مشاهده کنید. اما جالب تر نموداری است که در زیر مشاهده میکنید.
برای هر سناریو، NBomber نتیجه شبیه سازی تست بار، تعداد درخواست های ارسال شده در ثانیه(RPS) و زمان آزمون را با یکدیگر ادغام کرده و نمایش می دهد.
همچنین نمودار مشابهی وجود دارد که رفتار تاخیرو انتقال داده را نشان می دهد.
هماهنطور که در نتایج تست ما مشاهده می کنید، تاخیر فقط کمی افزایش می یابد. این موضوع با تعداد کلاینت های بیشتر جالب خواهد بود.که در آن شما می توانید تاخیر را برای تعداد بالای درخواست ها مشاهده کنید.
در بخش نکات می توانید نکات مفیدی را برای تست بار خود مشاهده کنید. مثلا ما باید کد وضعیت پاسخ API را بررسی کنیم تا مشخص شود که آیا فقط مشکل تایید اعتبار وجود دارد یا خطای 500 و ...
نتیجه گیری نهایی:
میدانیم که مشاهده این نمودار ها خوب است، اما چه چیز دیگری می توانیم از آزمایش های تست بار نتیجه بگیریم؟
می توانیم مشخص کنیم که در کجای سیستم درخواست ها به کندی اجرا می شوند و در کدام API ها مشکلات جدی باعث از کار افتادن سیستم می شود.
گام های بعدی پس از اجرای تست بار، بازدید از گزارشات آماری توسط ابزارهایی شبیه به Jaeger جهت پیدا کردن نقاط تنگنا و اقدام برای رفع آنها در سرویس شما می باشد.
توضیح و آموزش نحوه یافتن و رفع این مشکلات قطعا این مقاله را بمباران می کند، اما بزودی مقالاتی در مورد تجزیه و تحلیل درخواست ها ارائه خواهم کرد که می توانید از طریق صفحه فهرست من در ویرگول به آنها دسترسی داشته باشید.پس با من همراه باشید!
امیدوارم که دانش جدیدی از این مقاله کسب کرده باشید. اگر می خواهید از من و زمانی که برای نوشتن این مقالات صرف می شود حمایت کنید، می توانید برای من قهوه بخرید.
موفق و پیروز باشید.