یک روش بهتر برای گزارش نتایج تست Performance

نوشته های مرتبط

اتوماسیون تست بیش از حد

آبان ۲۴, ۱۴۰۰

نحوه بهینه سازی تجربه مشتری با استفاده از تست

آبان ۱۲, ۱۴۰۰

چگونه تعامل صحیح کسب و کاری می تواند به تحول “همیشه شاد” یا Happy Ever After منجر شود؟

آبان ۱۰, ۱۴۰۰

گزارش‌دهی موثر از نتایج تست یکی از فوت‌های کوزه‌گری حرفه ماست. اگر به درستی انجام شود، کیفیت پروژه را بهبود می‌بخشد و ما را برای تمرکز روی مسائل واقعی کمک می‌کند. اما اگر بدرستی انجام نشود، باعث سردرگمی شده و ارزش کار تسترها را کاهش می‌دهد.

گزارش نتایج تست‌های Functional نسبتا ساده است، زیرا این تست‌ها دارای نتایج واضح Pass یا Fail هستند، اما گزارش نتایج حاصل از Performance Testing بسیار متنوع‌تر است.

بیایید با یک تعریف شروع کنیم: برای هدف این مقاله، از واژه Performance Test استفاده می‌کنیم که به معنی هر تستی است که سنجشی را انجام می‌دهد، و خروجی آن محدوده وسیعی از مقادیر عددیست که همه آنها به عنوان یک نتیجه قابل قبول در نظر گرفته می‌شوند. این خروجی‌ها ممکن است اندازه‌گیری مصرف انرژی، تعداد کاربران یک وب سایت که به طور موازی کار می‌کنند، سرعت داده‌هایی که می‌تواند از یک دیسک خوانده شود، و یا هر چیز دیگری باشد. هر اندازه‌گیری هم که انجام شده است برای یک نیازمندی Non-Functional بوده است.

اولین چالش در تست Performance تصمیم‌گیری در مورد چیزیست که “Pass” در نظر گرفته می‌شود. اغلب اوقات این موضوعیست که در فاز تعریف نیازمندی‌ها(Requirements) مورد غفلت واقع می‌شود. شخصا نیازمندی‌های زیادی را دیده‌ام که چیزی شبیه به این است: “زمان استخراج داده‌ها از پایگاه داده باید کمتر از ۱۰ میلی ثانیه باشد” یا “نرخ پردازش یک فایل ویدئویی حداقل باید ۱۰۰ فریم بر ثانیه (fps) باشد.” چنین نیازمندی‌هایی کامل نیستند، چرا که آنها هدف واقعی که ما می‌خواهیم به آن برسیم را شامل نمی‌شوند. ما تنها بدترین نتیجه را می‌دانیم و موافقت می‌کنیم که مدارا نموده و محصول را تائید نماییم. در اینجا دو مشکل وجود دارد:

• ابتدا فرض می‌کنیم که یک تست انجام دادیم و متوجه می‌شویم که پردازش فایل ویدیویی با نرخ ۱۰۱ فریم بر ثانیه انجام می‌شود (به یاد بیاورید که حداقل ۱۰۰ فریم در ثانیه مد نظر ما بود). به نظر خوب است! درست است؟ اما آیا این بدان معنی است که ما نزدیک به لبه‌(یعنی محصول به سختی نیازمندی را پوشش داده است) هستیم یا اینکه نه؛ همه چیز خوب است؟ اگر نیازمندی‌ها به خوبی تعریف شده باشند، می‌تواند هم هدف و هم حداقل مد نظر را شامل شود، برای مثال، هدف: ۱۲۰ فریم در ثانیه؛ حداقل: ۱۰۰ فریم در ثانیه. با چنین نیازمندی، نتیجه fps 101 به وضوح نشان می‌دهد که محصول به سختی نیازمندی را پوشش داده است.
• دوم، هنگامیکه تست به صورت مویی و لب مرز Fail می‌شود(به عنوان مثال، ۹۹ فریم در ثانیه)، مدیریت محصول تحت فشار قرار می‌گیرد تا “انعطاف پذیر” بوده و محصول را با همین وضع بپذیرد. تاکنون چقدر مانند این نقل قول: “در واقع، ما پایین‌تر از Minimum هستیم، اما تقریبا کار را Pass کردیم، بنابراین می‌توانیم تصمیم بگیریم که در وضع خوبی هستیم” را شنیده‌ایم؟ اگر نیازمندی‌ها به صورت کامل در دسترس بود(اهداف: ۱۲۰ فریم در ثانیه)، مشخص می‌شد که نتایج از هدف چقدر فاصله دارند و محصول با چنین وضعی دارای یک مشکل واقعیست.

به منظور تکمیل صحبت‌هایم، ذکر خواهم کرد که یک نیازمندی Non-Functional نه تنها باید هدف و حداقل را شامل شود، بلکه باید Test Method را نیز مشخص کند، چرا که روش تست بر نتایج تاثیر می‌گذارد. به عنوان مثال، هنگام اندازه‌گیری مصرف CPU، نتایج به طور قابل توجهی بسته به نحوه اندازه‌گیری ما متفاوت خواهند بود. ما حداکثر مقدار ثبت شده را اندازه گیری می‌کنیم؟ طی چه مدت زمانی؟ آیا ما از اندازه‌گیری‌های خود معدل‌گیری(به دست آوردن میانگین اندازه‌ها) می‌گیریم؟ چه تعداد اندازه‌گیری در یک ثانیه انجام می‌شود؟ چه چیز دیگری به موازات تست ما روی پردازنده اجرا می‌شود؟

در تئوری، به طور کلی گزارشگیری نتایج تست Performance نباید مشکل باشد. چرا که فقط نتایج را نشان می‌دهد و یک Pass یا Fail ارائه می‌شود. اما مجددا می‌گویم ما نه تنها می‌خواهیم نتیجه را بدانیم؛ بلکه می‌خواهیم بدانیم که چگونه نتیجه به هدف مربوط می‌شود. تهیه گزارشی که بیش از حد پیچیده نیست اما هنوز هم تصویری کامل از وضعیت ارائه می‌دهد، یک عمل متعادل است.

ما می‌توانیم از یک جدول استفاده کنیم:

با این حال، به دلیل اینکه اکثر محصولات دارای نیازمندی‌های Performance زیادی هستند، ما با یک جدول بزرگ پر از اعداد، کار را به پایان خواهیم برد. دشوار است که به سرعت متوجه شوید که آیا مشکلی وجود دارد یا خیر. ما می‌توانیم از رنگ برای بهبود خوانایی استفاده کنیم:

اما این کار سوالات بیشتری را به ارمغان می‌آورد. آیا این منطقیست که سرعت پردازش فریم و مصرف CPU یک کد رنگ مشابه را دریافت می‌کنند؟ یکی تقریبا Fail شده است، در حالی که دیگری در محدوده قابل قبول است. شاید بد نباشد پردازش Frame به رنگ قرمز نمایش داده شود؟ با این اوصاف از چه رنگی برای Failure استفاده می‌کنیم؟ و تا چه مدت می‌توان نتیجه سبز را قبل از اینکه زرد شود مشاهده نمود؟

یک بار برای آزمایش خون به یک آزمایشگاه رفتم، هر چند من متخصص آزمایشگاه نبودم، اما با یک نگاه کلی به مجموع رکوردهای آزمایش که بیش از ۲۰ رکورد بود، فورا وضعیت حدودی خود را متوجه شدم، تصویر چیزی شبیه به عکس زیر بود:

این موضوع مرا به فکر انداخت که چرا ما از این همین روش در گزارشات Performance Testing که می‌تواند مجموعه زیادی از اعداد و ارقام را داشته باشد، استفاده نکنیم، به همین دلیل با پاورپوینت چیزی شبیه تصویر پایین درست کردم:

توجه داشته باشید که من هنوز از رنگ استفاده می‌کنم، اما در اینجا میله یا مسیر که مربع روی آن قرار گرفته است انتخاب رنگ را توضیح می‌دهد و علاوه بر این تعیین می‌کند مستقل از رنگ، بالا بودن یا پایین بودن کدام ویژگی بهتر است. خواننده گزارش به وضوح می‌تواند موقعیت هر اندازه‌گیری را در محدوده مجاز ببینید؛ رنگ‌ها عمدتا برای متمرکز شدن توجه در جایی که مشکل وجود دارد، به کار گرفته می‌شوند. ایجاد چنین گزارشی طول می‌کشد، اما می‌توان آن را خودکار کرد.