https://virgool.io/feed/@info.qualatech شرکت کوالاتک متخصص تست اتوماتیک نرم افزار و اپلیکیشن و تضمین کیفیت می‌باشد • اجرای تست عملکردی و غیر عملکردی • آزمایشگاه تست بار و کارایی • راه اندازی تیم تست • آموزش • منتورینگ و مشاوره 02140662678 fa 2026-07-06 13:18:11 https://files.virgool.io/upload/users/1172770/avatar/fpqDba.png?height=120&width=120 https://virgool.io/@info.qualatech https://virgool.io/@info.qualatech/smoke-test-%D9%88-sanity-test-%DA%86%DB%8C%D8%B3%D8%AA-mbu4h942pwqw بررسی تست Smoke و تست Sanityدر این مقاله، در مورد مفاهیم و تفاوت های  smoke test و sanity test در فرآیند تست نرم‌افزار، توضیح داده می‌شود.تست smoke چیست ؟زمانی‌ که نرم افزار از لحاظ کارکرد در وضعیت پایدار و مطلوبی نیست و وظایف اصلی و حیاتی خود را طبق انتظار انجام نمی‌دهد، اجرا کردن تست هایی که بصورت جامع، عملکرد و همه‌ی ویژگی های آن را پوشش می‌دهد، کاری بیهوده است. به کمک تست اسموک (smoke test) ، وضعیت کلی و استاندارهای اصلی ابتدا بررسی می‌شوند و بر اساس گزارش های آن، گام بعدی تست نرم افزار برداشته می شود..به این تست همچنین  “Build Verification Testing“ یا “Confidence Testing” هم می‌گویند.  این تست به عنوان مقدمه‌ی تست های Functional  و یا Regression  شناخته شده و بررسی می‌کند که آیا برنامه آمادگی لازم جهت تست جامع و کامل را دارد یا خیر.تست اسموکتست smoke بصورت اتوماتیک پیاده سازی می‌شود زیرا معمولا روندی مشخص و ثابت را طی می‌کند. ( تست کیس های اصلی برنامه که شامل فیچرهای مهم سیستم هستند، از قبل مشخص شده اند و کمتر دچار تغییرات می‌شوند)هدف تست smoke، مشخص کردن مشکلات اولیه و اصلی برنامه است، بنابراین فیچر ها و قابلیت های جدید نرم‌افزار را بررسی نمی‌کند بلکه تمرکزش بر روی مشخصات و قابلیت های حیاتی و مهم سیستم است!چهت آشنایی با چالش ها و خدمات تست smoke، صفحه ی مربوطه را مطالعه کنید.مثال :برای نمونه، یک سوپرمارکت اینترنتی را درنظر بگیرید که هر کاربری می‌تواند محصول مورد نیازش را سفارش دهد.این سامانه در کنار خرید محصول، خدمات دیگری هم به کاربران خود ارائه می‌دهد و فیچر و ویژگی های زیادی به مرور به آن اضافه شده است. اما مهم ترین ویژگی آن، قابلیت سفارش و خرید محصول است. برای تست smoke، یک سناریو خرید محصول طراحی می‌کنیم و این تست را بعد از هر build که در اختیار تیم QA قرار می‌گیرد، اجرا می‌کنیم تا مطمئن شویم مهم ترین قابلیت سامانه، دچار مشکل نشده است. اگر این مرحله با موفقیت سپری شد، نرم افزار آماده اجرای تست کیس های بیشتر در آزمایش های دیگر می‌شود.تست سناریو در این مثال به شکل زیر است:لاگین توسط کاربرانتخاب یک محصول و اضافه کردن به سبد خریدسفارش و پرداختتست sanity چیست ؟از طرفی زمانی که تغییراتی در یک نرم افزار صورت می‌گیرد، ابتدا باید تضمین شود که تغییرات صورت گرفته مطابق با انتظار عمل می‌کنند یا خیر. سپس بعد از این مرحله نرم افزار آماده‌ی آزمایش بصورت عمیق تر و جامع تر می‌شود.پیشن نیاز این امر، پایدار بودن نرم افزار (Stable) است، به عبارتی قبل از اجرای تست سلامت (sanity test)، نرم افزار باید تست smoke را با موفقیت طی کرده باشد. در غیر این صورت، تست sanity کاری بیهوده خواهد بود.منظور از stable builds این است که تست های Smoke و دیگر تست ها مانند Regression  را پشت سر گذاشته است.تست sanittyنکات :این تست معمولا بصورت دستی (manual) صورت می‌گیرد زیرا روند تکراری و از قبل مشخص شده ای ندارد. در غیراین صورت، می‌توان با درنظرگرفتن شرایطی خاص و یا ادغام با تست regression، بصورت اتوماتیک هم پیاده‌سازی کرد.همچنین از تست sanity در مواقعی که نیاز است نرم‌افزار بعد از اعمال تغییرات، سریع عرضه شود، می‌توان استفاده کرد. این تست کمک می‌‌کند که در کوتاه ترین زمان، عملکرد نرم افزار و نواحی تحت تاثیر آن، آزمایش شود .تست sanity، را می‌توان بخشی از تست regression درنظر گرفت که بصورت سطحی تر، عملکرد نرم افزار را در شرایطی که فرصت کمی برای آزمودن جامع وجود دارد، بررسی می‌کند.هدف از sanity test این است که عملکرد کلی تغییرات جدید نرم افزار را بررسی کند تا مشخص شود که توسعه دهندگان در حین تولید نرم افزار،استانداردهای اصلی را رعایت کرده اند.چهت آشنایی با چالش ها و خدمات تست sanity، صفحه ی مربوطه را مطالعه کنید.تفاوت های تست Smoke و Sanity شرکت کوالاتک | تست اتوماتیک نرم افزار و اپلیکیشن شرکت کوالاتک | تست اتوماتیک نرم افزار و اپلیکیشن Sun, 23 Jan 2022 13:39:56 +0330 https://virgool.io/@info.qualatech/%D8%AA%D8%B3%D8%AA-%D8%B1%DA%AF%D8%B1%D8%B3%DB%8C%D9%88%D9%86-regression-%DA%86%DB%8C%D8%B3%D8%AA-ixjicstpbgap تست رگرسیون - کوالاتکدر این مقاله با مفهوم و concept تست رگرسیون regression آشنا می‌شوید. ما سعی کردیم بصورت تجربی و با نگاهی ساده، تست رگرسیون را شرح دهیم. تعاریف و دسته بندی های مختلفی از انواع تست وجود دارد که این امر می‌تواند موجب سردرگمی خصوصا برای افراد تازه وارد شود. قبل از ورود به این مطلب، شما باید در نظر بگیرید که  این تعاریف و دسته بندی ها ، بسته به نوع نگاه و scope ، اولویت یا priority در سازمان ، نوع محصول و در کل هدف ما بستگی دارد. در مقاله ای دیگر به طور دقیق تری به این موضوع پرداخته خواهد شد.تست رگرسیون چیست؟تست Regression برای اطمینان از اینکه هر تغییری در سورس کد مانند اصلاح خطا، اضافه کردن فیچر و… تاثیری مخربی بر روی عملکرد سیستم نگذاشته باشد، اجرا می‌شود. این تست معمولا بصورت جعبه سیاه – black box انجام می‌شود.یک محصول نرم افزاری در حال توسعه را درنظر بگیرید. تیم توسعه‌ی نرم‌افزار، با توجه به نیازمندی‌ها، شروع به پیاده‌سازی ماژول ها و فیچرها می‌کند. درکنارش، تیم تست باتوجه به این نیازمندی‌ها، برای مثال  ۲۰۰ تست کیس برای تست functional طراحی می‌کند. در مزحله ی بعد، یک نسخه از نرم افزار در اختیار تیم تست قرار گرفته، و تست اجرا می‌شود. بعد از این فرایند، احتمالا نرم افزار آماده‌ی اجرای تست پذیرش و سپس تحویل به کارفرما می‌شود .بعد از مدتی کارفرما، یک نیازمندی جدید تعریف کرده و تیم توسعه فرایند کد زنی را شروع کرده و بعد از اتمام، یک نسخه در اختیار تیم تست قرار می‌دهند.تیم تست هم با توجه به فیچر جدید، ۵۰ تست کیس طراحی می‌کند. و برای اطمینان از اینکه تغییرات جدید، تاثیری مخربی بر عملکرد قبلی سیستم ( ۲۰۰ تست کیس قبلی که اجرا شدند) نداشته باشد، علاوه بر اجرای ۵۰ تست جدید، تست کیس قبلی را هم اضافه می‌کنند (با اینکه ممکن است هیچ تغییری در کامپوننت ها و ماژول های نسخه ی قبلی صورت نگرفته باشد). این فرایند به همین شکل ادامه پیدا می‌کند، و هربار تست های قبلی هم مجددا اجرا می‌شوند. این مثال به طور کامل تعریف تست رگرسیون را نشان می‌دهد.همونطور که گفته شد در حالت کلی این تست زمانی اجرا می‌شود که یک تغییر در نرم افزار شکل بگیرد. این تست تضمین میکند که با تغییرات صورت گرفته در کد، برنامه همچنان به درستی کار می‌کند.نکات:این تست قبل از نسخه دهی نهایی در طول فرایند توسعه، اجرا می‌شود.بسته به نوع و رویکرد توسعه ی پروژه، میتواند روزانه و یا هفتگی اجرا شود.این تست بهتر است که بعد از تست های sanity و smoke پیاده سازی شود.معمولا بصورت e2e انجام میشود.دارای مجموعه‌ی وسیعی از تست کیس است که این تست کیس ها با تکنیک های مختلفی اجرا می‌شوند ( که در ادامه بررسی می‌شود.)انواع تست رگرسیونما اینجا به دو مورد از approach یا رویکرد های مطرح تست regression اشاره می‌کنیمPartial/Regional Regressionدر این رویکرد قسمتی که دچار تغییر شده و قسمت هایی که ممکن است تحت تاثیر این تغییر باشند، بررسی می‌شود . از این متود معمولا در متودولوژی های agile بهره گرفته می‌شود، جایی که زمان و بهینه بودن اهمیت فراوانی پیدا می‌کند. به این صورت که تیم QA ، با توجه به تغییرات، تست کیس های منتخب و مربوطه را انتخاب و اجرا می‌کنند.Full Regressionاین رویکرد علاوه بر بررسی نواحی مورد تغییر و مناطق تحت تاثیر (impact areas) ، ماژول ها و فیچر های قدیمی را هم بررسی می‌کند. به عبارتی کل محصول را پوشش داده می‌شود. از این روش معمولا در مراحل پایانی و همچین بعد از تعییرات وسیع که ممکن است حوزه های functional و non-functional را تحت تاثیر قرار دهد استفاده می‌شود.انتخاب هر کدام از این رویکرد ها به scale پروژه و همچنین رویکرد توسعه‌ی نرم افزار ( اجایل یا واترفال ) ، نوع زمان بندی و … بستگی دارد.تست Regression چه زمانی مورد نیاز است ؟اصطلاح خطا و باگاضافه شدن ویژگی جدید به نرم افزاراصلاح یا Refactor کدحتی زمانی که تغییراتی در قسمت performance نرم افزار شکل بگیردتکنیک های تست رگرسیونانواع تکنیک های تست regressionRetest All :در این تکنیک، همه‌‌ي تست کیس ها اجرا می‌شوند. تا تضمین دهد هیج تاثیر مخربی روی عملکرد قبلی نرم افزار ایجاد نشده است.این تکنیک در مقایسه با موارد دیگر به زمان و منابع بیشتری نیاز دارد.توحه: دو تکنیک زیر، گاهی به عنوان تکنیک تست کیس نویسی برای تست رگرسیون هم درنظر گرفته می‌شود.Regression test selection :در این تکنیک به جای اجرای مجدد همه ی تست کیس ها، بخشی از آن را انتخاب و اجرا میکنیم. تست کیس ها به دو دسته یReusable یا تست مجددObsolete  یا منسوخ شدهتقسیم میشوند.Reusable ها دوباره در چرخه رگریشتن بعدی استفاده می‌شوند، منسوخ شده ها هم کنار گذاشته می‌شوند. به این ترتیب در زمان و هزینه صرفه جویی می‌شود.Prioritization of test cases :در این تکنیک، test case ها اولویت بندی می‌شوند. به بیان ساده، تست کیس های مهم و حیاتی که فیچرها و functionality های اصلی نرم افزار را در برمی‌گیرند، انتخاب می‌شوند.این کار به میزان قابل توجهی تعداد تست کیس ها را کاهش داده و به صرفه جویی در زمان کمک می‌کند.نکته: تفاوت تکنیک و رویکرد در این است که رویکرد، scope و ناحیه ی ما را مشخص می‌کند، که ما در این scope می‌توانیم از بعضی تکنیک ها استفاده کنیم.انتخاب Test Case ها برای تست رگرسیونبهتر است در انتخاب تست کیس ها به موارد زیر توجه کنیم:بیشترین تعداد خطا را داشته باشندفیچرها و فانکشنالیتی هایی که بیشترین استفاده توسط کاربران را دارندحیاتی ترین فیچر اصلی محصول را پوشش دهدماژول هایی که بیشترین تغییرات در آن ها رخ می‌دهندتست کیس هایی که پیچیدگی خاصی دارند.ابزار تست رگرسیونسوالی که مطرح می‌شود این است که این تست را اتوماتیک اجرا کنیم یا بصورت دستی؟اگر در مراحل ابتدایی پروژه هستید و نرم افزار هنوز به پایداری نرسیده است ( یعنی ممکن است تغییرات وسیعی صورت بگیرد و یا اینکه هنوز بصورت کامل فیچرهای اصلی اون پیاده سازی نشدند) و یا ابعاد و مقیاس پروژه کوچک می‌باشد، بهتر است بصورت دستی انجام شود. همچنین ممکن است در برخی مواقع نوشتن اسکریپت برای اجرای یک action، پیجیده و یا نشدنی باشد که در این صورت باید بصورت manual تست شود.تست اتوماتیک هم بیشتر برای پروژه ها بزرگ تر و یا معمولی درنظر گرفته می‌شود. این کار بشدت در زمان صرفه جویی می‌کند، در agile development هم ممکن است بهره ی زیادی از آن گرفته شود. جایی که تیم ها باید در بازه های مشخص release داشته باشند که اجرای اتوماتیک باعث می‌شود زمانشان را روی انواع تست دیگر بگذارند. تست اتوماتیک رگرسیون، گاهی برخی از خطا ها و باگ هایی را که در تست دستی امکان شناسایی آن نیست، کشف می‌کنند. خصوصا خطاهایی که ممکن است بصورت تصادفی ایجاد شوند که این امر با تکرار پیاپی تست ها، قابل شناسایی ست.انتخاب ابزار هم وابسته به نوع تست ماست، برای مثال اگر رگرسیون فقط بصورت فانکشنال و در لایه ی ui است، ابزار هایی مانند selenium و cypress کمک بسیاری برای اجرای تست های end to end می‌کنند.چالش‌های تست رگرسیوناز مشکلات تست رگرسیون می‌توان به موارد زیر اشاره کرد:یکی از مشکلاتش کمیت تست کیس ها است که به مرور افزایش پیدا می‌کنند و درنتیجه هزینه و زمان زیادی باید صرف شود.با کوچیک ترین تغییر در کد، بایست تست regression انجام شودپیاده سازی محیط تست و نگهداری و استفاده ی مجدد از آن نیازمند دانش و تجربه و بررسی دقیق است.تفاوت Confirmation testing یا Retest با تست رگرسیون چیست؟در بعضی از رفرنس ها و منابع تست، یک type از تست در کنار functional و non-functional، به نام change-related test در نظر گرفته شده است. این دسته از تست زمانی که هر تغییری در سیستم مانند اصلاح خطا یا اضافه کردن امکانات جدید و… صورت می‌گیرد، بررسی می‌کند که تغییرات انجام شده مطابق انتظار عمل می‌کنند و مشکلی وجود ندارد. change-related همانطور که از نامش مشخص است، وابسته به تغییر است.این تست، دو عضو دارد:RegressionConfirmation testing/Re-testتست رگرسیون را قبلا بررسی کردیم. Confirmation testing یا Re-testing و یا تست مجدد، تستی است که بعد از fix شدن یک باگ انجام می‌شود. زمانی که یک تست خطا می‌خورد، گزارش این باگ در اختیار تیم توسعه قرار گرفته می‌شود و آنها بعد از بررسی، این مشکل را در نسخه ی جدید رفع می کنند. حال برای اینکه مطمین شوند که این خطا رفع شده، مجدد تستی را که مربوط به همین خطا است احرا می‌کنند تا مطمئن شوند خطا اصلاح شده است. این تست ترمرکزش بر روی فیکس شدن باگ است، که تفاوتش با regression هم در این نکته است! ابتدا Retest انجام می‌شود، سپس تست رگرسیون.برای آشنایی با خدمات تست رگرسیون کوالاتک کلیک کنید شرکت کوالاتک | تست اتوماتیک نرم افزار و اپلیکیشن شرکت کوالاتک | تست اتوماتیک نرم افزار و اپلیکیشن Sat, 15 Jan 2022 13:43:56 +0330 https://virgool.io/@info.qualatech/%D8%AA%DA%A9%D9%86%DB%8C%DA%A9-%D9%87%D8%A7%DB%8C-%D9%86%D9%88%D8%B4%D8%AA%D9%86-%D8%AA%D8%B3%D8%AA-%DA%A9%DB%8C%D8%B3-lgvzhcwdtox3 در این مطلب شما با تکنیک های طراحی و نوشتن تست کیس (test case design techniques) با رویکرد جعبه سیاه (Black-Box)  و همچنین علت استفاده از آن‌ها آشنا می‌شوید. در مقاله ی تست کیس و تست سناریو به مفاهیم کلی برای نوشتن تست کیس اشاره شده است. دستیابی به آزمایش و تست با کیفیت،نیازمند استفاده از تست کیس مناسب است که با بهره‌بردن از تکنیک های طراحی، این امر دست یافتنی است. انواع متنوعی از تکنیک ها وجود دارد که هر کدام برای شناسایی انواع خطاها و error ها ایجاد شده اند. در نتیجه ما برای هر برنامه و اپلیکیشن باید تست کیس مناسب با هدف آن نرم‌افزار را طراحی کنیم. با این‌کار بصورت عمیق تری نرم افزار بررسی شده و همچنین به پوشش تست (test coverage) مناسب تری دست پیدا می‌کنیم. در ادامه می‌بینیم که روش‌های طراحی تست کیس چیست و یاد می‌گیریم چگونه تست کیس بنویسیم.تکنیک های نوشتن تست کیستکنیک های طراحی تست کیستکنیک‌های طراحی تست کیس به دو قسمت White-Box و Black-Box تقسیم می‌شوند. در این قسمت به برخی از تکنیک‌های رایج در روش Black-Box اشاره می‌کنیم. این تکنیک‌ها عبارتند از:Equivalence Partitioning یا پارتیشن بندی هم ارزیBoundary Value Analysis یا تحلیل مقدار مرزیDecision Table Testing یا جدول تصمیم گیریState Transition Testing یا انتقال وضعیتError Guessingتکنیک Equivalence Partitioning یا پارتیشن بندی هم ارزیپارتیشن بندی هم ارزی یکی از تکنیک‌های رایج طراحی Test Case است.در این تکنیک دامنه‌های ورودی را به چند قسمت و ناحیه تقسیم می‌کنیم و برای هر ناحیه یک تست درنظر می‌گیریم. با این کار، تعداد Test Case‌ها کاهش پیدا می‌کند.برای مثال یک input، فقط برای ورودی از جنس عدد دربازه‌ی ۱ – ۱۵ طراحی شده است. هر عددی غیر از این بازه، نامعتبر شناخته می‌شود. یک عدد به دلخواه از این بازه مانند ۵ انتخاب می‌کنیم و خروجی را با این ورودی بررسی می‌کنیم. همچنین انتظار داریم اعداد دیگر هم در این بازه، رفتار مشابهی مانند عدد ۵، از خود نشان دهند. در واقع عدد ۵ یک نماینده برای این بازه درنظرگرفته می‌شود. به هر یک از این نواحی یک کلاس یا پارتیشن گفته می‌شود.برای پیاده سازی این تکنیک نیاز هست شرایط ورودی‌ها به دقت بررسی شوند و مطابق با سند نیازمندی باشند. بعد از بررسی، ورودی‌ها را به دو دسته‌ی valid و invalid تقسیم می‌کنیم. در مثال قبلی دسته بندی بدین صورت است:تکنیک Equivalence Partitioning یا پارتیشن بندی هم ارزیvalid : از ۱ تا ۱۵invalid : بزرگتر از ۱۵ و کوچکتر از ۱سپس کلاس بندی یا پارتیشن‌ها را ایجاد می‌کنیم. یک کلاس برای بازه‌ی valid و دو کلاس هم برای بازه‌ی invalid. خروجی مانند تصویر زیر می‌شود.Equivalence Partitioningبرای هر کلاس یک تست کیس انتخاب می‌کنیم. با این کار، به پوشش تست ۱۰۰٪ با استفاده از این تکنیک، دست پیدا خواهیم کرد. یعنی تمامی سناریو‌های ممکن را (مثبت و منفی) درنظر گرفته‌ایم. معمولا در این روش، یک Test Case، برای تمامی حالات ورودی‌های معتبر کافی است. در حالی که برای ورودی‌های غیر معتبر، باید برای هر حالت یک Test Case درنظرگرفته شود.برای مثال فرض کنید در سامانه‌ی ورود با ‌ایمیل، ورودی معتبر را میتوان ترکیبی از عدد و حروف وارد کرد که هر دو حالت را پوشش دهد. در حالی که برای مقادیر نامعتبر مثل برخی کاراکتر‌های زبان‌های مختلف و نماد‌هایی مانند * و #، نمی‌توان با یک تست همه آن‌ها را بررسی کرد. بلکه باید در دو حالت (یکبار با کارکتر و یک بار با نماد‌) جداگانه آزمایش شودتکنیک Boundary Value Analysis یا تحلیل مقدار مرزیاین تکنیک از روش Equivalence Partitioning هم استفاده می‌کند و تمرکز اصلی اش بر روی مقادیر مرزی است.چرا که ممکن است بسیاری از خطا‌ها در شرایط مرزی ایجاد شوند. در نتیجه دانستن دقیق دامنه‌ی داده‌ی نیازمندی(Input Domain)، از اهمیت ویژه ای برخوردار است. این تکنیک، مقادیر(Values) را به چند دسته‌ی min, min+, Max -, Max تقسیم می‌کند. در این روش شرایط ورودی و گاهی رابطه ی آن با خروجی را نیز می‌توان بررسی کرد.مثال ۱)فرض کنید شرایط ورودی مانند مثال قبل، ۱-۱۵ است. مانند جدول، مقادیر حداکثری و حداقلی را درنظر می‌گیریم و برای هر کدام یک Test Case درنظر می‌گیریم.در این تکنیک حداقل به ۴ تست کیس نیاز داریم تا به پوشش ۱۰۰ درصدی از تست دست پیدا کنیم.تکنیک تحلیل مقدار مرزی، نسبت به تکنیک پارتیشن بندی، دقیق تر و جامع تر است. در واقع ریزدانگی و عمق تست کیس ها بیشتر می‌شود. این امر سبب می‌شود تعداد موارد آزمون کمی بیشتر شود، درنتیجه اجرای تست‌ها زمان بیشتری می‌برد.تکنیک Decision Table Testing یا جدول تصمیم گیریدر این تکنیک ترکیب شرایط ورودی‌ها و حالت‌های مختلف آن بررسی می‌شود. در دو تکنیک قبل فقط شرایط ورودی‌ها در نظر گرفته می‌شد اما در این تکنیک ترکیب‌های مختلف شرایط ورودی نیز در نظر گرفته می‌شود.در این متد ترکیب انواع ورودی‌ها با خروجی مورد انتظار در یک جدول نمایش داده می‌شوند و مطابق با آن تعداد Test Case‌های مورد نیاز بدست می‌آید.ممکن از برخی از تست کیس های بدست آمده قابل اجرا نباشند که در این صورت آن‌ها را درنظر نمی‌گیریم.مثال ۱) به جدول زیر توجه کنید. فرض کنید برای ورود در یک سامانه، باید‌ ایمیل و پسورد معتبر وارد کنید.تکنیک Decision Table Testing یا جدول تصمیم گیریاین جدول از سه قسمت Rules، Conditions و Actions تشکیل شده است. شرایط برای ورود به سامانه، پر کردن فیلد‌های‌ ایمیل و پسورد است. پس۲ شرط (Condition) داریم. Action هم به شرایط خروجی اشاره می‌کند. اگر ورودی‌ها معتبر باشند(true)، وارد می‌شود، اگر نباشد(false)، با خطا مواجه می‌شود. پس خروجی هم ۲ حالت دارد. Rules هم به ترکیب‌های مختلف شرط‌ها (Conditions) اشاره می‌کند. برای بدست آوردن تعداد Test Case‌ها در این روش از فرمولNo of TC = No of Rules = 2^(number of condition)استفاده می‌کنند.در این مثال تعداد Test Case‌ ها طبق فرمول برابر با ۴ است (۲ به توان تعداد شروط). پس در نتیجه ۴ Rule باید درنظر بگیریم. این Rules‌ ها بصورت ترکیبی از حالت‌های True و False ایجاد می‌شوند. در این مثال کاربر باید دو فیلد ‌ایمیل و پسورد را وارد کند. اگر هر دو معتبر و صحیح بود، وارد صفحه‌ی اصلی می‌شود، در غیر این صورت با خطا مواجه می‌شود. همانطور که مشاهده می‌کنید برای بررسی این المنت به ۴ Test Case نیاز داریم تا به پوشش کامل از تست برسیم.مثال ۲)یک سرویس خرید اینترنتی را در نظر بگیرید. اگر کاربر جدید باشید و اولین بار در اپ ثبت نام کردید ۵۰ درصد تخفیف می‌گیرید، اگر یک کاربر قدیمی و معمولی باشید ۱۰ درصد تخفیف می‌گیرید. همچنین می‌توانید از کد‌های تخفیف ۳۰ درصدی نیز استفاده کنید.پس سه شرط داریم:New user 50%Old user  10%Discount code 30%تعداد Test Case‌ها و قوانین طبق فرمول، ۸ عدد می‌شود. (2^Cond). به جدول زیر توجه کنید. در قانون ۳، امکان ندارد که هم کاربر جدید باشید و هم قدیمی، پس این تست رد می‌شود. این شرایط برای قانون‌ها ۳و ۵ و۷ و ۴ هم برقرار است. پس تعداد Test Case‌ها در این مثال به ۴ می‌رسد.تکنیک Decision Table Testing یا جدول تصمیم گیرینکته: در دو مثال قبل، حالت های ورودی ها بصورت true و false در نظرگرفته شده است (با توجه به شرایط مسئله). ممکن است این شرایط بصورت مقادیر دیگری هم باشند.تکنیک State Transition Testing یا انتقال وضعیتاز این تکنیک زمانی که تغییر در شرایط ورودی‌ها باعث تغییر در حالت خروجی شود، استفاده می‌شود. برای درک بهتر فرض کنید اگردر پنل ورود بیش از ۳ بار تلاش ناموفق برای ورود اتفاق بیفتد، خروجی برنامه وارد یک حالت از پیش تعیین شده می‌شود. (ممکن است پاپ آپ اخطار ظاهر شده و دسترسی شما را برای مدتی محدود کند). در واقع سیستم برای شرایطی که در گذشته اتفاق افتاده، برای ورودی‌های مشابه، این بار خروجی متفاوتی از خود نشان می‌دهد.برای نمایش این تکنیک از دو روشDiagram و Table استفاده می‌شود.به مثال ورود در یک سامانه برمی‌گردیم.ما در این مثال پنج state یا حالت داریمتکنیک State Transition Testing یا انتقال وضعیتبه دیاگرام رسم شده توجه کنید. همونطور که مشاهده می‌گنید اگر کاربر در تلاش اولش (State 1) پسورد معتبر وارد کند وارد صفحه‌ی اصلی سامانه می‌شود(State 4). اگر نامعتبر و invalid باشد، فرصتی دیگری برای ورود داده می‌شود (State 2) و برای بار دوم پسورد را وارد می‌کند، اگر معتبر باشد، به صفحه اصلی ریدایرکت شده در غیر این صورت به حالت سوم می‌رسد (یعنی دوباره می‌تواند شانسش را برای ورود امتحان کند.) منتهی اگر در سومین تلاشش ورودی نامعتبر وارد کند، در این صورت اکانتش از دسترس خارج می‌شود (State 5)حال به کمک دیاگرام میتوانیم شرایط را تحلیل و بررسی کنیم و برای همه‌ی حالات Test Case طراحی کنیم.برای مثال میتوانیم این تست کیس ها را بررسی کنیم:وارد کردن پسورد معتبر در اولین گاموارد کردن پسورد نامعنبر در اولین گام، سپس وارد کردن پسورد معتبروارد کردن پسورد نامعتبر در اولین و دومین گام، سپس وارد کردن پسورد معتبروارد کردن پسورد نامعتبر در اولین و دومین و سومین گام، سپس وارد کردن پسورد نامعتبربرای درک حالات مختلف، از جدول هم می‌توان استفاده کردتکنیک Error Guessingاین روش همانطور که از نامش مشخص است، بر اساس حدس و تجربه و مشاهده است. برای یافتن خطا، تمامی احتمالات و سناریو‌هایی که ممکن است مستعد خطا باشند را مهندس تست در نظر می‌گیرد. سپس Test Case‌ ها را بر اساس آ‌‌ن‌ها انتخاب می‌کند. این روش در مقاسیه با دیگر تکنیک‌ها ساده و سریع است و براساس تجربه و مشاهده‌ی افراد، بصورت بارش فکری شکل می‌گیرد.برای مثال از یک input انتظار می‌رود که فقط عدد طبیعی مثبت، به عنوان ورودی دریافت کند. مهندس تست سناریو‌های منفی که منجر به خطا می‌شود را بررسی می‌کند. مثلا اعداد منفی، حروف، کاراکتر، ترکیب عدد با حروف و… را به عنوان ورودی درنظر می‌گیرد و تست کیس را بر اساس حدسش طراحی می‌کند.در این روش طبیعتا پوشش تست درنظر گرفته نمی‌شود و همچنین ممکن است بسیاری از نواحی پوشش داده نشوند. معمولا بعد از تست‌هایی که با متد‌های دیگر اجرا شده‌اند، از این متد استفاده می‌شود زیرا ممکن است برخی از سناریو‌ها با تکنیک‌های دیگر قابل اجرا نباشند.نتیجه گیریتکنیک های بسیاری برای نوشتن تست کیس وجود دارد و ما سعی کردیم شما را با رایج ترین تکنیک ها آشنا کنیم. بعد از خواندن این نوشته باید بدانید چگونه تست کیس بنویسید. همچنین این نکته را در نظر بگبرید که لزوما نیاید فقط از این روش ها استفاده شود، گاهی ممکن است تستر با شرایطی مواجه شود که هیج کدام از این موارد نتواند کمک کننده باشد ( مانند برخی از سناریو تست ها که بحث پوشش تست معمولا در آن‌ها مطرح نمی‌شود.). آشنا شدن با این متد ها دید بهتری نسبت به طراحی و نوشتن تست کیس می‌دهد، خصوصا در مواردی که بحث پوشش تست باید جدی بررسی شود. گاهی ممکن است تستر چند روش را باهم ترکیب کند و با تجربه ی و دانش خود، روش ابداعی و اصولی خود را پیش ببرد. شرکت کوالاتک | تست اتوماتیک نرم افزار و اپلیکیشن شرکت کوالاتک | تست اتوماتیک نرم افزار و اپلیکیشن Mon, 10 Jan 2022 18:35:43 +0330 https://virgool.io/@info.qualatech/%D8%AA%D8%B3%D8%AA-%DA%A9%DB%8C%D8%B3-%D9%88-%D8%AA%D8%B3%D8%AA-%D8%B3%D9%86%D8%A7%D8%B1%DB%8C%D9%88-%DA%86%DB%8C%D8%B3%D8%AA-sdlwvgfuxt0b در این مقاله سعی شده درباره ی مفاهیم و نوشتن تست کیس (test case) و تست سناریو (test scenario) ، ویژگی ها و چالش های آن به زبان ساده بحث شود.تست سناریو چیست؟قبل از تعریف تست کیس ، نیاز هست با مفهوم تست سناریو و تفاوتش با تست کیس آشنا شویم. تست سناریو یک توضیح کوتاه و کلی در مورد این است که چه کاری باید انجام بگیرید و تمرکزش بر روی فانکشنالیتی یک اپلیکشن است.برای مثال، یک سامانه را که از قسمت های مختلف مانند صفحه ی لاگین، صفحه ی HomePage، نوار جستجو و.... تشکیل شده است را درنظر بگیرید. تستر باید طبق نیازمندی های نرم افزار فرایند لاگین کردن را تست کند. برای اینکار باید یک سناریو طراحی کند. مانند:بررسی فرآیند لاگین با ورودی های معتبراین توضیح مختصر و کوتاه یک سناریو نامیده می‌شود. درواقع تستر با یک نگاه به این متن، متوجه میشود که چکاری باید انجام دهد و کدام فانکشنالیتی را باید بررسی کند. اما چگونه؟! برای جواب دادن به این سوال باید به تست کیس مراجعه کند.تست سناریو در اصطلاح یک High-Level-Documentation است و در آن صحبتی از جزییات کار، صورت نمی‌گیرد. این جزییات بصورت step by step در تست کیس پیاده می‌شودبرای مثال قبل Test Case به این صورت نوشته می‌شود:وارد وبسایت شوید.ایمیل و پسورد معتبر را در فیلد‌های مشخص شده وارد کنید.روی دکمه‌ی ورود کلیک کنید ..در Test Case چگونگی انجام کار و همچنین جزییات بصورت دقیق مشخص می‌شود.ممکن است برای یک سناریو، چندین Test Case در نظر گرفته شود.برای مثال:سناریو: بررسی فرایند پرداخت یک محصولtestCase - پرداخت با کارت بانکیtestCase- پرداخت با اعتباربرای مشخص شدن تفاوت های test case و test scenario به جدول زیر توجه کنید.مقایسه تست کیس و تست سناریوتست کیس چیست؟با درنظر گرفتن تعاریف گفته شده در قسمت قبل، در مهندسی نرم افزار، تست کیس مشخصات ورودی‌ها، شرایط اجرا، روش آزمایش و نتایج مورد انتظاری است که برای دستیابی به یک هدف، مانند انجام یک مسیر برنامه خاص یا تأیید منطبق بودن با یک نیاز خاص، یک آزمون واحد را اجرا می‌کند. در واقع اگر قرار باشد یک قسمت از یک اپلیکیشن را تست کنید نیاز است که یک تست کیس برای آن قسمت طراحی کنید. این طراحی می‌تواند بصورت مستند و با جزییات در قالب یک سند ثبت شود.نوشتن تست کیس چه کمکی می‌کند؟فرض می‌کنیم تست کیس مستند شده نداریم، در این صورت چه اتفاقی می‌افتد؟اگر در طول توسعه ی نرم فزار، تست کیس document شده نداشته باشیم. در این صورت اجرای مورد تست ها، وابسته به افرادی می‌شود که آن ها را اجرا می‌کنند.فرض کنید در تست رگریشن (regression) قبل از release، مهندس تست شما، ۲۰۰ test case را اجرا می‌کند. برای نسخه ی بعدی نرم افزار، که همراه با تغییرات ( مانند اضافه کردن فیچر جدید، اصلاح کد و یا ....) است، تستر ممکن است ۱۵۰ test case را قبل از نسخه دهی اجرا کند. مهندس تست باید این را در نظر داشته باشد که تست های قبلی در نسخه ی قبلی را هم اجرا کند.( فرض می‌کنیم فیچر های نسخه ی قبلی حذف نشده اند). با عدم وجود تست کیس مستند، تستر طبقه بندی درستی نسبت به اجرای تست‌کیس ها ندارد.در واقع همه ی این سناریو ها وابسته به حافظه و ذهن تستر دارد و اگر این تستر از شرکت خارج شود و مهندس جدیدی جایگزین شود، شرکت با مشکل جدی در اجرای تست‌کیس ها مواجه می‌شود. چراکه تستر جدید هیج دانشی نسبت به تست‌کیس های اجرا شده ندارد.مشکل بعدی در زمینه ی کیفیت کد بروز می‌کند. عدم وجود تست کیس ، کیفیت تست ها را تحت تاثیر قرار می‌دهد. منظور از کیفیت ، پوشش تست (Test Coverage) است. بدون وجود تست‌کیس، قطعا پوشش تست خوب هم درکار نخواهد بود. چرا که مشخص نیست کدام نواحی و فانکشنالیتی های اپلیکیشن و همچنین تمامی سناریوهای رایج برای یک فیچر، در تست ها پوشش داده شده است یا خیر.ممکن است تستر برخی از فیچر ها و فانکشنالیتی ها را فراموش کند، و از یاد ببرد.اجرای تست های تکراریعدم وجود تست کیس استاندارد، منجر به عدم اعتماد به تستر می‌شود. برای مثال فرض کنید شما قبل از نسخه دهی،تمامی فیچر ها و فانکشنالیتی ها را تست و بررسی می‌کنید. بعد از pass شدن همه ی تست ها و حل کردن مشکلات، نسخه را تحویل کارفرما می‌دهید. بعد از مدتی یک باگ یا نقص در قسمتی از اپلیکیشن مشاهده می‌شود. اگر شما تست‌کیس استاندارد نداشته باشید، نمی‌توانید به کارفرما یا ذینفعان پروژه ثابت کنید که فیچر مورد بحث، در مراحل تست، با سناریوهای مشخص،مورد تایید و بررسی قرار گرفته است.بطور خلاصه میتوان گفت عدم مستند کردن test case ها منجر به عدم ثبات در اجرای آن‌ها، عدم Test Coverage مناسب و همچنین وابستگی به فرد یا افراد مشخص، می‌شود. درنتیجه نوشتن تست کیس از اهمیت ویژه ای برخوردار است.ویژگی های Test caseاین ویژگی ها عبارتند از:اولین و مهم ترین ویژگی تست کیس خوب، داشتن Test Coverage خوب است. زمانی که Test Coverage مناسب باشد، کیفیت تست هم افزایش میابد. منظور از پوشش تست، پوشش تمامی سناریو های مثبت و منفی ممکن، در قسمت های مختلف اپلیکیشن( شامل ماژول ها، فیچرها و فانکشنالیتی ها) است. با این کار احتمال یافتن باگ افزایش پیدا می‌کند. هدف مهندسین تست یافتن باگ است، بنابراین اگر پوشش تست، مناسب نباشد، از این هدف دور می‌شوند.برای مثال فرض کنید شما برای اپلیکیشن خود 200 تست‌کیس طراحی کردید، اما پوشش تست شما 50% است. اگر test case شما به درستی طراحی شده باشد، ممکن است با اضافه کردن یک test case، پوشش تست شما افزایش پیدا کند و برای مثال به ۸۰٪ برسید. در نتیجه در این قسمت طراحی test case از اهمیت ویژه ای برخوردار است.اگر تست کیس به درستی مستند شده باشد، هنگامی که یک نیروی جدید تست وارد شرکت می‌شود، با مطالعه ی Test Case Document متوجه عملکرد سامانه و همچنین به درک مناسبی از آن دست پیدا خواهد کردتست کیس باید جوری طراحی شده باشد که قابلیت کشف خطا را داشته باشددر ابتدا سناریو های مثبت و سپس سناریو های منفی طراحی شوند (Negative)تکراری(Duplicate) نباشدتست کیس باید جوری باشد که بتوان هم بصورت دستی و اتوماتیک پیاده کرد. در واقع اگر تست‌کیس ها برای تست دستی (manual) طراحی شده است، تبدیل آن به تست اتوماتیک ساده باشد.از تکنیک های Test Case Design استفاده شده باشد. شرکت کوالاتک | تست اتوماتیک نرم افزار و اپلیکیشن شرکت کوالاتک | تست اتوماتیک نرم افزار و اپلیکیشن Sun, 02 Jan 2022 15:56:09 +0330 https://virgool.io/@info.qualatech/%D8%AA%D8%B3%D8%AA-%D9%88%D8%A7%D8%AD%D8%AF-unit-testing-cy6a8uvhlxis تست واحد، جزء اولین تست هایی است که باید از آن بهره برد.قبل از بزرگ شدن حجم کد های نرم افزار یا اپلیکیشن خود به فکر چاره باشیدتست واحد – Unit Testing تست واحد یا Unit Test چیست ؟ تست واحد یا Unit Test نوعی آزمون نرم افزاری است که در آن واحدها یا اجزای نرم افزار -کوچکترین قطعه کد- مورد آزمایش قرار می گیرند. هدف تست واحد این است که تأیید شود که هر واحد کد نرم افزار مطابق انتظار عمل می کند یا خیر. تست واحد در طول توسعه نرم افزار توسط توسعه دهندگان انجام می شود ، البته در دنیای عملی به دلیل محدودیت زمان یا عدم تمایل توسعه دهندگان به آزمایش ، مهندسان QA نیز Unit Test را انجام می دهند.تست واحد در SDLC ، STLC ، V Model ، Testing Unit اولین سطح آزمایش می باشد و قبل از  integration test انجام می شود. Unit Test یک تکنیک آزمایش White Box است. در اجرای تست واحد بخشی از کد جدا می گردد و صحت آن مورد بررسی قرار می گیرد. یک واحد ممکن است یک تابع ، روش ، رویه ، ماژول یا شیء باشد.دلایل انجام Unit Test در مهندسی نرم افزار :رفع اشکالات فنی در مراحل اولیه چرخه توسعهارائه درک درست ساختار کد به توسعه دهندگانصرفه جویی در هزینه هاتسریع در رفع مشکلات فنیداشتن یک سند پروژه مطلوبکمک به استفاده مجدد از کدیکپارچه سازی بی نقص نرم افزارچالش های تست واحدتوسعه دهندگان نرم افزار اغلب سعی می کنند در حین انجام کار در زمان صرفه جویی کنند یا همه استانداردهای ساختار نرم افزار را رعایت نمی کنند. این کار در ابتدای شروع پروژه مشکلی بوجود نمی آورد ولی هر چقدر پروژه توسعه می یابد باعث بروز مشکلات جدی تری می شود که شناخت و اصلاح آن کار سخت تری می شود.همچنین پیاده‌سازی تست unit ، گاهی اوقات بیشتر از توسعه ی کد برنامه، زمان می‌برد درنتیجه فرآیند توسعه با تاخیر بسیاری روبرو می‌شود.از طرفی آزمایش نامناسب واحد منجر به هزینه های زیادی می شود زیرا رفع نقص در هنگام تست سیستم ، آزمایش یکپارچه سازی و حتی آزمایش بتا پس از ایجاد برنامه،  بسیار طاقت فرسا و مشکل خواهد بود.راهکارهای تست واحداگر آزمایش واحد مناسب در مراحل اولیه انجام شود ، در نهایت در وقت و هزینه شما صرفه جویی می شود.انجام Unit Test در مراحل اولیه سبب می شود تا  در وقت و هزینه شما صرفه جویی می شود و از بروز مشکلات غیر قابل پیش بینی در حین استفاده توسط مشتریان جلوگیری شود.تیم کوالاتک با ارايه راهکارها و رویکردها، منجر به سریع تر و آسان تر شدن و همچنین پیاده‌سازی صحیح و افزایش بهره وریی از تست واحد می‌شود شرکت کوالاتک | تست اتوماتیک نرم افزار و اپلیکیشن شرکت کوالاتک | تست اتوماتیک نرم افزار و اپلیکیشن Wed, 29 Dec 2021 16:49:23 +0330 https://virgool.io/@info.qualatech/%DA%86%DA%AF%D9%88%D9%86%D9%87-%D8%A8%D9%87%D8%B1%D9%87-%D9%88%D8%B1%DB%8C-%D8%A8%DB%8C%D8%B4%D8%AA%D8%B1%DB%8C-%D8%A7%D8%B2-%D8%AA%D8%B3%D8%AA-%D8%AF%D8%A7%D8%B4%D8%AA%D9%87-%D8%A8%D8%A7%D8%B4%DB%8C%D9%85-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-tdpbvcijcdvc بهره‌وری تست نرم افزار و اپلیکیشندر بخش قبل، از بهره‌وری تست نرم افزار و اپلیکیشن صحبت کردیم. در ادامه مقاله قبلی میخواهیم نحوه انتخاب بین دو راهی تست اتوماتیک و تست دستی را مطرح کنیم.از پارامترهای مهم برای افزایش بهره‌وری تست نرم افزار و اپلیکیشن ،‌استفاده از تکنولوژی‌های مناسب برای محصول تحت تست می باشد. در همین راستا، پیش از هر چیز باید نیازمندی خود را شناسایی کنیم. برای تشخیص این نیازمندی‌ها باید ابتدا با سوالات اساسی زیر پاسخ دهیم:آیا بازخورد سریع از اجرای تست‌ها مهم است؟چه تست‌هایی برای اجرا داریم؟بازخورد تست‌ها برای چه کسانی مهم‌تر است؟ ‌مدیران، مهندسین تست‌ یا توسعه دهنده‌ها؟تسلط تیم تست بر روی چه ابزارهایی است؟تعداد تست‌های لازم برای پوشش مطلوب فیچر‌ها چندتاست؟مدت زمان اجرای تست‌های اتوماتیک چقدر است؟آیا محصول زیرساخت لازم برای mocking یا stub را دارد؟در طراحی محصول،‌ کامپوننت‌ها با چه کیفیتی طراحی شده یا پیاده‌ شده‌اند؟بعد از پاسخ به این سوالات می توانیم ابزارهای مناسب را انتخاب کنیم. برای نمونه نحوه انتخاب چند تا از ابزارها به عنوان بررسی می‌شود:نحوه انتخاب ابزار CI:یکی از دسته ابزارهایی که می‌تواند تاثیر زیادی در بهره‌وری آزمون نرم افزار داشته باشد ابزارهای CI (Continuous Integration یا همان یکپارچه‌سازی مداوم) است. در مورد تاثیرCI در چرخه تست بعدا شرح داده خواهد شد. این ابزارها به تستر‌ها کمک می‌کنند که بازخورد سریع‌تری از تست‌های خود داشته باشند. همچنین بسیاری از فرآیند‌های دستی و روتین خود را به یک فرایند اتوماتیک تبدلی کنند. در انتخاب این ابزار باید دقت کرد که استفاده کننده نهایی از این ابزار چه کسانی هستند. برای مثال در صورتی که استفاده کننده‌های نهایی، توسعه دهنده‌ها باشند و همچنین ابزار VCS در حال استفاده توسط تیم توسعه gitlab باشد بهتر است فرآیند Continuous Integration با استفاده از Gitlab-CI پیاده‌سازی شود. اما اگر بازخورد بیشتر برای تسترها یا مدیران مهم باشد می‌توان از ابزارهای open source ای مانند Jenkins استفاده کرد که امکانات قدرتمندی را در اختیار آزمونگر ها یا مدیران قرار می‌دهد و با پشتیبانی از plugin انعطاف بالایی در استفاده از آن می‌توان داشت.ابزار تست E2E :برای تست e2e ابزارهای مختلفی می توان استفاده کرد. برای مثال، فرض کنید می‌خواهیم برای محصول وب خود تست اتوماتیک e2e پیاده کنیم.اگر مهندسان تست زبان جاوا اسکریپت بدانند از طرفی محصول وبی که تحت آزمایش است به زبان انگولار پیاده شده باشد استفاده از protractor می تواند گزینه مناسبی باشد اما اگر تسترها به زبان پایتون آشنایی داشته باشند می توان از فریموورک سلنیوم (selenium) و با استفاده از پایتون تست های end-to-end خود را پیاده کند.از طرف دیگر اگر محصول، یک محصول Enterprise باشد که با رعایت تمام اصول حرفه‌ای طراحی، پیاده‌سازی و توسعه پیاده شده باشد استفاده از سایپرس (cypress) می‌تواند گزینه مناسبی باشد. با استفاده از سایپرس می‌توان علاوه بر پیاده‌سازی تست‌های e2e، تست‌هایی اتوماتیک UI نیز پیاده کرد. از طرفی در سایپرس امکان جداسازی کامپوننت‌ها در تست‌ها به صورت آسان‌تری فراهم هست اما همین فرآیند در ابزارهای selenium-base دشوار است. همچنین باید در نظر داشت که استفاده از سایپرس به فرد حرفه‌ای تری نیاز دارد که بتواند از امتیاز آن به نسبت سلنیوم استفاده کند.با این حال باید توجه داشت که سلنیوم امتیازهایی  community قوی تری دارد و قابلیت‌هایی مانند multi-tab یا cross-platform،‌ پشتیبانی بهتری از مرورگرها را به نسبت سایپرس دارد.ابزار مدیریت تست و مدیریت باگ:ابزارهای دیگری که می‌توانند ما را در بهره‌وری بسته کمک کنند ابزارهای مدیریت تست‌ها یا باگ‌ها هستند. از فواید مدیریت تست کیس و مدیریت باگ در نوشته‌های آتی بیشتر گفته می‌شود.در بسیاری موارد، با استفاده از  google-sheet یا یک فایل اکسل به اشتراک گذاشته شده می‌توان نیازمندی خود را برای مدیریت تست کیس‌ها پاسخگو بود اما اگر بخواهیم در یک تیم چند نفره، مدیریت دقیق‌تری از تست‌ها یا باگ‌ها داشته باشیم و یا بخواهیم از ارتباط بین تست‌ها و باگ‌ها استفاده کنیم می‌توان از ابزارهایی که برای Test Management طراحی شده‌اند استفاده کنیم. در این ابزارها می‌توانیم تاریخچه اجراهای تست دستی یا اتوماتیک را داشته باشیم. گزارش‌های مربوط به آن‌ها را ببینیم یا آنالیز کنیم. از طرفی امکان integrate شدن به ابزارهای مدیریت پروژه مانند Jira یا پیام‌رسان‌هایی مانند slack در این ابزارها فراهم است.برای مثال می‌توان از پلاگین‌ TestFlo برای مدیریت تست‌ها و باگ‌ها در جیرا استفاده نمود (این پلاگین رایگان نیست و استفاده از این پلاگین در ایران دشوار است).یا با استفاده از ابزار قدیمی و رایگان TestLink می‌توان کمی مدیریت تست‌ها را بهبود داد اما امکانات این ابزار به نسبت ابزارهای دیگر محدود و کم است.برای کسانی که از ابزارهای open source استقبال می‌کنند kiwiTCMS پیشنهاد می‌شود. این ابزار را می‌توان به صورت on premise برای محصول راه‌اندازی نمود و استفاده کرد. امکانات این ابزار رایگان نیز قابل توجه است. برای مثال می‌توان به موارد زیر اشاره کرد:مدیریت برنامه تست (test plan)مدیریت تست کیس (test case)مدیریت اجرای تست (test run و test execution)ردیابی خطاها یا باگ‌ها (Bug tracker)یکپارچه شدن یا Integerate شدن با ابزارهایی مانند jira، GitHub، GitLabنتیجه گیری:تا به اینجا دیدیم ابزارها می‌توانند استفاده از تست‌ها را آسان‌تر کنند و به عنوان نمونه نحوه انتخاب بعضی از این ابزارها را دیدیم. نکته مهم این است که برای هر بخش بهترین ابزار می‌تواند وابسته به نیازمندی یا شرایط ما متفاوت باشد.در نوشته‌های بعدی همراه ما باشیدhttps://qualatech.ir/ شرکت کوالاتک | تست اتوماتیک نرم افزار و اپلیکیشن شرکت کوالاتک | تست اتوماتیک نرم افزار و اپلیکیشن Wed, 22 Dec 2021 14:55:19 +0330 https://virgool.io/@info.qualatech/%DA%86%DA%AF%D9%88%D9%86%D9%87-%D8%A8%D9%87%D8%B1%D9%87-%D9%88%D8%B1%DB%8C-%D8%A8%DB%8C%D8%B4%D8%AA%D8%B1%DB%8C-%D8%A7%D8%B2-%D8%AA%D8%B3%D8%AA-%D8%AF%D8%A7%D8%B4%D8%AA%D9%87-%D8%A8%D8%A7%D8%B4%DB%8C%D9%85-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-rq1biw8pe8ex فرض بر این است که خواننده، اهمیت تست و تضمین کیفیت را در حیات یک کسب و کار نرم‌افزاری بداند. در اینجا به این موضوع پرداخته نمی‌شود. اما کافی است بدانید که بخش بزرگی از عامل موفقیت شرکت‌های بزرگ نرم‌افزاری فرآیند تضمین کیفیت و تست است. برای مثال علت اصلی شکست Flud به عنوان یک بیزینس بزرگ را نبود فرآیند موثر QA می‌دانند.در فرآیند تست، مهندسین تست همیشه با چالش‌هایی روبه‌رو هستند که اگر اصول‌ پیاده‌سازی و اجرای تست را به درستی درک نکنند در این چالش‌ها موفق نیستند. به عنوان مثال از مهندسین تست یا مدیران تست می‌شنویم:فرآیند تست طولانی و وقت گیر استمدیر نمی‌خواهد بیشتر از این برای تست هزینه کندتست‌ها خطا دارند و یک نفر باید مسئول تست کردن تست‌ها باشد.در واقع چالش اصلی را می‌توان در این نکته خلاصه کرد که کسی که دانش تست دارد لزوما مهندس تست نیست! در تعریف مهندس آمده است که « یک مهندس می‌بایست ضمن شناخت مسئله یا موضوع کاری، علوم و فنون لازم، محدودیت‌های مربوطه را تشخیص دهد تا بتواند به دستاوردهای لازم برسد.»همین امر در حرفه‌های مرتبط با نرم‌افزار هم دیده می‌شود که توسعه‌دهنده‌ها با مطالعه syntax های یک زبان برنامه نویسی مهارت خود را برای توسعه یک نرم‌افزار کافی می‌بینند.یکی از مهار‌ت‌هایی که هر مهندس باید داشته باشد این است که بتواند با بودجه محدود بهترین فرآیند تست را برای تست محصول تشخیص و راه‌اندازی نماید در غیر این صورت بهره‌وری پایین تست سبب می‌شود که مدیران و ذی نفعان پروژه تست را کم اهمیت تشخیص دهند و بودجه آن را کمتر کنند (اگر بودجه‌ای در نظر گرفته باشند!).مهندس تست باید همیشه از خود بپرسد آیا تست‌های پیاده شده ارزشی دارد؟ آیا فرآیند تست از این بهتر نمی‌شود؟ چه قدمی برای کاهش هماهنگی بین تسترها و تیم توسعه می‌تواند بردارد؟هر چه نرم‌افزار بزرگتر می‌شود این چالش‌ها مشکل تر و پیچیده تر است و صرفا با به خدمت گرفتن ریسورس بیشتر حل نمی‌شود. در این حالت، به جای استفاده بیشتر و بیشتر از ریسورس‌ها یا افزایش نیرو‌های تست، باید استراتژی‌های تست را تغییرداد. چرا که در دنیای واقعی، هر پروژه به یک رویکرد و استراتژی منحصر به فرد نیاز دارد.تجربه شخصی نویسنده این است که در بیشتر موارد،‌ نبود استراتژی درست علت اصلی موثر نبودن تست است و در خیلی از موارد دیده شده که بدون هزینه اضافی و صرفا با تغییر رویکرد و استراتژی تیم تست، فرآیند تست کارا تر بوده است.اما پاسخ دادن به این سوالات ساده نیست و نیاز به تجربه و دانش کافی دارد. زیرا استراتژی مشخص و ثابتی برای تست همه نرم‌افزارها وجود ندارد. ممکن است نرم‌افزار تحت تست، نرم‌افزاری کوچک باشد و صرفا با تست‌های دستی ساده بتوان نیازمندی آن را برطرف نمود از طرفی ممکن است به حدی پیچیده و یا بزرگ باشد که صرفا با یک فرآیند تست اتوماتیک ساده نتوان پاسخگوی نیاز آن باشیم.در همین راستا،‌ مواردی را ذکر می‌کنیم که مهندسین تست بتوانند با آن ارزش تست‌ها را بالا ببرند یا بر اساس بودجه تعیین شده برای تست بهترین بهره‌وری از آن را داشته باشند.کدام بخش از تست‌‌ها باید به صورت دستی و کدام بخش‌ها باید اتوماتیک باشند؟برای افزایش بهره‌وری تست لزومی ندارد همه تست‌ها اتوماتیک شوند. تست‌هایی باید اتوماتیک شوند که:تعداد دفعات اجرای تست بالا باشدنیاز به بازبینی و تغییر فرایند تست بصورت مداوم توسط تستر نباشدنرخ maintanance تست‌ها نسبت به نرخ توسعه پایین باشداتوماتیک کردن فرآیند تست پیچیده نباشدشاید بپرسید که از موارد بالا چگونه می‌توان به این نتیجه رسید که کدام تست‌ها باید اتوماتیک شوند؟ در صورتی که معیار کاهش هزینه‌ها باشد، یک راهکار ساده برای بررسی این موضوع، می‌تواند بررسی هزینه میان مدت‌ در دو حالت تست دستی و اتوماتیک باشد.برای مثال برای یک پروژه با اندازه متوسط می‌توان هزینه‌های پیاده‌سازی، نگهداری و اجرای تست‌های اتوماتیک را با تست‌های دستی در یک بازه زمانی ۶ ماهه مقایسه کرد تا بتوان میزان به صرفه بودن تست‌های اتوماتیک را بررسی کرد.از طرفی باید توجه داشت که اتوماتیک کردن برخی از روش‌های تست ممکن است چالش‌های زیادی را داشته باشد. برای توضیح بیشتر مطلب مزیت-تست-اتوماتیک-نرم-افزار-و-اپلیکیشن را مطالعه کنید.برای مثال تست اکتشافی (exploratory testing) باید به صورت دستی پیاده شود. زیرا در این حالت تست‌ کیس نوشته نمی‌شود و تستر‌ها با نگاه موشکافانه در جهت کشف خطا‌ها اقدام می‌کنند.بهره گرفتن از یک مهندس QA امری ضروری در این راستا می‌تواند باشد شرکت کوالاتک | تست اتوماتیک نرم افزار و اپلیکیشن شرکت کوالاتک | تست اتوماتیک نرم افزار و اپلیکیشن Mon, 13 Dec 2021 09:01:59 +0330