کلیدواژگان: تست، خودکارسازی تست، تست جعبه سیاه، تست جعبه سفید، تست های تکرارپذیر، ابزارهای تست خودکار، ابزارهای تست نرم افزار.
مقدمه مهندسی نرم افزار
مقوله مهندسی در تولید نرم افزار، امری حیاتی است. در مهندسی نرم افزار، اندیشه آدمی مهم است و چون انسان ها بر اساس تجربه های گوناگون به راه حل های مختلفی می رسند، لازم است کار به صورت گروهی باشد و اینکه به طور سیستمی به راه حل برسیم. مهندسی نرم افزار، خود، یک سبک است.
اصل مهندسی نرم افزار می گوید: کار باید به طور مهندسی انجام شود و وابسته به فناوری نباشد. بنابراین، با PLC وابسته به فناوری نخواهیم بود. دو عامل مهم در مهندسی نرم افزار، هزینه و زمان می باشد. چرخه تولید محصول (PLC)، عبارت است از قالب کاری و مجموعه ای از راهکارها برای سازماندهی و پیاده سازی برنامه های توسعه محصولات. این چرخه، تمام مراحلی را که در انجام یک عمل طی می شود، به صورت استاندارد مستند می کند. همچنین، پروسه تولید محصول، شامل تعاریف قوانین سازماندهی فعالیت ها و روابط بینابینی سازمانی، در واقع، اجزای کلیدی و نقاط تحویل کار بین فازهای مختلف و تست و ارزیابی را مستند می نماید.
مفهوم تست نرم افزار
تست، مجموعه ای از فعالیت هاست که می تواند به طور پیشرفته، برنامه ریزی شده و به طور سیستمی هدایت شود. برای این منظور، باید برای فرآیند تست نرم افزار، یعنی مجموعه گام های خاص و test-caseها که بتوانیم فنون طراحی روش های تست را جایگزین کنیم، الگویی تعریف شود.
دلایل اهمیت تست نرم افزار
به طور معمول، تست، بیشترین تلاش را نسبت به دیگر فعالیت های مهندسان، نیاز دارد. اگر فرایند تست بدون دقت هدایت شود، باعث هدر رفتن زمان، تلاش غیرضروری، بدتر شدن اوضاع و عدم تشخیص خطاهای پنهان می شود. بنابراین، برپاکردن یک راهبرد سیستمی برای تست نرم افزار، معقول به نظر می رسد.
برای انجام تست مؤثر، باید مقالات فنی اثربخش را دنبال کنید. با انجام این کار، بسیاری از خطاها قبل از شروع تست، حذف خواهند شد. تست در سطح تست واحد شروع می شود و در جهت خارج، به سوی یکپارچه سازی کل سیستم مبتنی بر رایانه، کار می کند. فنون تست برای دیدگاه های متفاوت مهندسی نرم افزار و در زمان های متفاوت، می توانند مناسب باشند. فرایند تست توسط توسعه دهنده نرم افزار و برای پروژه های بزرگ، از سوی یک گروه تست مستقل هدایت می شود.
تست و اشکال زدایی، فعالیت های متفاوتی هستند؛ اما اشکال زدایی باید در هر فرایند تست جا داده شود.
چرا باید تست نوشت؟
وقتی برنامه شما یک بار درست کار می کند و بار دیگر نه، چه باید کرد؟ زمانی که برای کدی تست ننوشته ایم، به احتمال زیاد، این مشکل برایش پیش خواهد آمد؛ چرا؟ دلیلش ساده است. وقتی کدی را می نویسیم، ممکن است به همه نکات آن توجه نکنیم؛ البته این موضوع با توجه به تجربه برنامه نویس متفاوت است؛ ولی هنگامی که شما برای کدتان تست می نویسید، مجبور می شوید به خیلی از جزئیاتی که در حالت معمول به آن توجه نمی کنید، توجه داشته باشید.
تست نوشتن، باعث بهبود کیفیت کد می شود؛ زیرا برای تست نوشتن مجبوریم یکسری قواعد را رعایت کنیم. مدتی پیش، مجبور بودم متدی را تست کنم که در آن، یک دستور به سیستم استریسک (سیستم تلفنی تحت لینوکس) فرستاده می شد و من نمی توانستم به طور مستقیم آن را تست کنم؛ زیرا در محیط تست، استریسکی در کار نبود. بنابراین، تنها راهی که وجود داشت، این بود که از dependency injection استفاده کنم. یک کلاس ایجاد کردم که کار ارتباط با استریسک را در آن انجام داده بودم و آن را به کلاسی که قصد تست آن را داشتم، تزریق کردم. این موضوع، باعث شد که وابستگی کد به سیستم دیگر، مدیریت شود.
تست نوشتن، باعث مشخص شدن کدهای مرده می شود. اگر مدت هاست که به کلاسی سر نزده اید و حال قصد کار بر روی آن را دارید، با تست نوشتن می توانید کدهایی را که هرگز استفاده نشده اند، پیدا کنید. تست نوشتن، باعث آشکار شدن کدهای تکراری می شود؛ ضمن اینکه باگ های پنهان را آشکار می کند. زمانی که شما برای کدی که از قبل نوشته شده است، تست می نویسید، مجبورید دقت بیشتری به خرج دهید و در نتیجه، باگ های آن کشف خواهد شد.
نوع تست، ممکن است با توجه به فناوری تغییر کند؛ ولی چیزی که مهم است، این است که ما تست را جزئی از کد و برنامه بدانیم.
مراحل تست نرم افزار
تست اوّلیه، بر یک مؤلفه واحد یا گروه کوچکی از مؤلفه ها تمرکز دارد و تست هایی را برای آشکارکردن خطاهای داده ای و پردازش منطقی که توسط مؤلفه ها کپسوله شده، اعمال می کند. پس از اینکه مؤلفه ها تست شدند، باید یکپارچه شوند تا سیستم کامل را ایجاد کنند. در این مرحله، یکسری تست های مرتبه بالا برای آشکار کردن خطاهای مربوط به نیازمندی های کاربر انجام می شود. بعد از بروز خطاها، باید با استفاده از فرایند تشخیص داده شده و (Debugging) اشکال زدایی، تصحیح شوند.
سازماندهی تست نرم افزار
توسعه دهنده نرم افزار، موظف است که واحدهای منفرد برنامه (مؤلفه ها) را تست کند تا مطمئن شود هر یک رفتاری را بروز می دهند که برای آن طراحی شده اند. در بسیاری حالات، توسعه دهنده، تست یکپارچه سازی نیز انجام می دهد؛ یک مرحله تست که منجر به ساخت و تست معماری نرم افزار کامل می شود.
پس از تست یکپارچه سازی، یک گروه تست مستقل (ITG)(1) نیز نقش ایفا می کنند. نقش گروه تست مستقل، این است که مشکلات مربوط به تست سازنده را که به بخش هایی اجازه ساخته شدن می دهد، حذف می کند. ITG پس از همه این مراحل، گروه متعهد هستند که خطاها را پیدا کنند. ITG به طور تنگاتنگ با هم کار می کنند تا تضمین نمایند که تست های توسعه دهنده به درستی انجام شده است. هنگامی که تست انجام شد، توسعه دهنده باید حضور داشته باشد تا خطاهای آشکار شده را تصحیح نماید.
مراحل تست
- تست واحد(2): در این نوع تست، قسمت های کوچک برنامه را تست می کنیم؛ مثلاً توابع یا کلاس ها در زبان های object oriented. در این تست، با کل برنامه کاری نداریم و هدف ما، اطمینان از کارکرد قسمت های کوچک برنامه است. تست واحد، در سطح کد است و یک ابزار مناسب برای آن JUnit است. این ابزار، تست خودکار انجام می دهد که در مرکز تحقیقات کامپیوتری علوم اسلامی (نور) زبان هایی مثل: C++، C# و Java وجود دارد که برنامه نویسان تست های واحد را در برنامه های خود می نویسند و در آینده، همه کدهای موجود در مرکز تست های واحد خواهند داشت.
- تست جامعیت(3): این تست برای این است که مطمئن شویم کامپوننت های مختلف برنامه با هم درست کار می کنند. تست جامعیت نیز در معاونت فنی نور توسط برنامه نویسان، و در معاونت پژوهش نور توسط بخش های بررسی نرم افزارهای موبایل، دسکتاپ و وب در حال کنترل است.
- Functional test/ Acceptance test: برای این است که مطمئن شویم آیا نرم افزار کامل هست و به درستی کار می کند؟ این نوع تست، یک تست سطح بالا محسوب می شود و ابزار این تست، Fitnesse می باشد و روند آن توسط همکارمان در بخش بررسی نرم افزار در مرکز نور انجام می شود و قسمتی از آن نیز توسط کاربران نهایی انجام خواهد شد.
- Performance test: در این نوع تست، کارایی کامپوننت های برنامه مورد بررسی قرار می گیرد. تست کارایی در معاونت فنی نور توسط برنامه نویسان، و در معاونت پژوهش توسط قسمت بررسی نرم افزار انجام می شود.
- System test: در این نوع تست، تمام سیستم تست می شود و حتی خود نرم افزار، سخت افزار و ارتباطات بین کامپوننت ها مورد توجه قرار می گیرد. خود تست سیستم، شامل: تست گرافیک رابط کاربری(4)، Smoke test ، تست هایی از قبیل تست کارایی(5) و تست نصب(6) می باشد و همه تست های سیستمی، توسط کارشناسان نور در بخش بررسی نرم افزار مرکز انجام می شود.
انواع تست
انواع تست، عبارت اند از:
- تست نصب: این نوع تست به ما این اطمینان خاطر را می دهد که برنامه به درستی در سیستم های مشتریان درست نصب خواهد شد. در مرکز توسط بررسی نرم افزار انجام می شود.
- تست سازگاری(7): در این نوع تست، باید بررسی کنیم که برنامه با محیطی که قرار است در آن اجرا شود و همچنین برنامه های دیگری که کنار آن وجود دارند، سازگار باشد؛ مثلاً ممکن است که یک برنامه نویس برنامه اش را برای یک نسخه خاص سیستم عامل بنویسد. بنابراین، به دلیل نداشتن backward compatibility، این نرم افزار برای همه کاربران قابل استفاده نیست. به طور کلی، تست سازگاری، به همت برنامه نویسان و همکارانمان در بخش بررسی نرم افزار انجام می شود.
- تست smoke و sanity: تست sanity به ما می گوید که آیا منطقی است که به انجام تست ادامه بدهیم یا خیر؛ یعنی قبل از اینکه تستی را شروع کنیم، ممکن است با این تست بتوانیم بفهمیم که برنامه از نظر منطقی درست پیاده سازی نشده. بنابراین، آن را به توسعه دهندگان ارجاع می دهیم، به جا آنکه بیشتر بر روی تست وقت بگذاریم.
- تست smoke: در این تست، شامل حداقل تلاش برای اجرای نرم افزار است. این تست از این نظر مفید است که ما متوجه شویم که آیا هیچ مشکل حداقلی برای اجرای نرم افزار داریم یا نه؛ یعنی بعد از این تست ما می فهمیم که این نرم افزار، حداقل، کار می کند. در واقع می توان تست verification هم نام گذاری شود.
- تست رگرسیون(8): تست فوق، روی یافتن باگ بعد از یک تغییر اساسی در کد پروژه تمرکز دارد؛ به عنوان مثال، وقتی یک فیچر به پروژه اضافه می گردد، با این تست، باگ های احتمالی را مشاهده می کنیم. جایی که یک کد عمده یا یک کتابخانه به پروژه افزوده می شود، معمولاً باگ های زیادی مشاهده می شود. شاید به دلیل conflict با کد قبلی یا هر دلیل دیگری، در این قسمت باید این تست مربوطه را انجام داد. معمولاً قدم اوّل تست regression، این است که تست کیس های پیشین را دوباره تکرار کنیم و ببینیم که این تغییر کد، موجب ظهور باگ های قبلی نشده باشد. عمق تست، به ریسک فیچر اضافه شده بستگی دارد. این نوع تست، در شرکت های تجاری بیشتر مورد توجه قرار می گیرد.
- تست پذیرش(9): این نوع تست، می تواند دو مفهوم داشته باشد؛ اوّلی همان تست smoke که مطمئن می شویم اگر برنامه با حداقل منابع کار می کند. بنابراین، احتمالاً در بیشتر شرایط نیز کار می کند. دومین مفهوم، مربوط به سمت مشتری می شود که مثلاً آنها هم یک آزمایشگاه داشته باشند و روی سخت افزار خودشان برنامه را تست کنند که به این تست، user acceptance test یا UAT نیز گفته می شود. این نوع تست، می تواند در بین فازهای پروژه هم معنا پیدا کند؛ به این شکل که در صورت موفقیت در این تست، برنامه به فاز بعدی می رود.
- تست آلفا(10): تست آلفا، نوعی شبیه سازی از بازار واقعی است که مثلاً به دست یک تیم تست جداگانه سپرده شود یا به کاربران احتمالی برنامه داده شود.
- تست بتا(11): این تست، بعد از تست آلفاست که در واقع، یک تست UAT خارجی هم محسوب می شود. این نسخه از نرم افزار با نام نسخه بتا شناسایی می شود که به یک تیم تست خارج از تیم برنامه نویسی ارسال می شود که به آنها beta testers می گویند. برنامه به تعداد کمی از کاربران داده می شود؛ تا زمانی که مطمئن شوند باگ های چندانی ندارد.
- تست Functional و Non-functional: تست functional برای ما کارکرد (function) خاصی را تست می کند. در واقع، سناریوهای پیاده سازی شده را تست می نماید؛ مثلاً برنامه قرار است بتواند یک عکس را نمایش بدهد. این تست، مسئله مزبور را بررسی می کند که آیا برنامه می تواند عکس نمایش دهد یا خیر؟ در مقابل، تست Non-functional مربوط به آن قسمت برنامه است که به کاربر ارتباط مستقیم ندارد؛ مثل کارایی سیستم یا قابلیت گسترش برنامه، رفتار برنامه در یک شرایط خاص و یا امنیت برنامه. این نوع تست، نقطه شکست برنامه را می یابد. تست Non-functional در واقع، کیفیت برنامه را آزمایش می کند.
- تست مخرب(12): این نوع تست تلاش می کند که برنامه یا یک زیربرنامه موفق به عملیات نشود. این نوع تست بررسی می کند که برنامه با دادن ورودی های ناجور یا غیرقابل پیش بینی و مختلف چگونه رفتار می کند و نتیجه این تست موجب می شود که روتین هایی برای مدیریت error و اعتبارسنجی ورودی نوشته شود که در نتیجه، موجب قدرتمند شدن برنامه می شود.
- تست کاربری(13): این تست، بررسی می کند که آیا کارکردن با رابط کاربری برنامه راحت است، یا نه.
- تست امنیت(14): در واقع، تست متدهای مختلف امنیت در برنامه است و تستی مهم به شمار می رود؛ به خصوص در برنامه هایی که حریم خصوصی افراد در آن تعریف می شود و باید با نفوذ هکرها مقابله کرد.
- تست توسعه(15): این نوع تست، راهبردهای های مقابله با باگ را مطرح می کند که با پیروی از آنها، آسیب های توسعه برنامه، هزینه و زمان آن به حداقل می رسد.
- تست A/B: در واقع، مقایسه دو خروجی است. پروسه تست، این گونه است که وقتی یک متغیر تغییر می کند، تست را اجرا می کنیم و با دوباره تغییر دادن آن، تست را تکرار نموده، با مقایسه خروجی ها، متوجه درستی عملکرد برنامه می شویم.
- تست Concurrent: بر کارایی برنامه در شرایطی که ما تست را به صورت مداوم انجام می دهیم، تمرکز دارد. این نوع تست، در مقابل تست فشار یا استرس است که در مدت زمان کوتاه فشار بسیاری به برنامه می آوریم.
- تست conformance یا typing: این نوع تست، بررسی می کند که برنامه بر اساس استانداردهای تعریف شده کار می کند یا نه؛ مثلاً در تست کامپایلرها، این تست بدین هدف انجام می شود که بدانیم آیا کامپایلر مورد نظر بر اساس استانداردهای لازم آن زبان خاص، درست کار می کند؟
- تست ad-hoc testing: به تست های فی البداهه ای گفته می شود که بدون هیچ برنامه یا مستنداتی اجرا می شوند و تنها یک بار صورت می گیرد؛ مگر اینکه یک خطا و یا به اصطلاح تست نرم افزاری، یک defect وجود داشته باشد که برطرف نشده باشد. در این نوع تست، test case تولید نمی شود و تنها نکته قدرت آن، در سرعت پیدا کردن defectها می باشد و بنا به ابتکار عمل و تشخیص tester، مورد تست صورت می گیرد. این فرایند، در مرکز توسط بخش بررسی نرم افزار انجام می شود.
رویکردهای تست
رویکردهای مربوط به تست عبارت اند از:
1. تست ایستا(16): نوعی تست است که در آن، از نرم افزار استفاده نمی شود. در این تست، وارد جزییات نمی شویم و مثلاً در آن منطق برنامه، الگوریتم و داکیومنت های آن بررسی می شوند؛ در این نوع تست، کد را می خوانیم و به دنبال اشکال ها می گردیم که معمولاً خود توسعه دهنده برنامه، این کارها را انجام می دهد.
2. تست پویا(17): رفتار نرم افزار را به ورودی هایی که به مرور زمان تغییر می کنند، نشان می دهد؛ یعنی تستی که در آن برنامه اجرا می شود و با ابزاری دیگر به آن ورودی های مختلف داده می شود و رفتار یا خروجی آن را می بیند و تحلیل می کند.
3. تست جعبه سفید(18): در این تست، کارکرد ساختارهای داخلی برنامه بررسی می شود و اینکه منطقاً به کد احتیاج هست تا مثلاً متدهای مختلف بررسی شوند. فنونی که در این نوع تست استفاده می شود، به این شرح است:
- - تست API: در تست جعبه سفید، هر API را به صورت جدا گانه تست می کنیم.
- - بررسی سطر به سطر کد(19): یعنی بررسی خطوط کد، به صورت خط به خط و جزءبه جزء؛ به صورتی که خطوط کد و مسیرهای مستقل داخل یک پیمانه حداقل یک بار اجرا و تست شوند.
- - متدهای Fault injection: طی این متد، یک کد خطا در کد تزریق می کنیم تا خطایی رخ دهد و بتوانیم موردی را تست کنیم.
- - متدهای mutaion test: برای تست نرم افزار، خودمان یک خطا را در کد ایجاد می نماییم.
4. تست جعبه سیاه(20): در این نوع تست، به اجزای داخلی نرم افزار کاری نداریم و به آن به عنوان یک جعبه سیاه نگریسته، رفتار برنامه را با دادن ورودی بررسی می کنیم.
5. تست جعبه خاکستری(21): در این نوع تست، در مورد ساختار داخلی نرم افزار و الگوریتم آن اطلاعاتی داریم و از آن برای طراحی تست استفاده می کنیم؛ درحالی که در تست هایی که طراحی می کنیم، هیچ دسترسی به ساختار داخلی نرم افزار نداریم و مانند یک جعبه سیاه به آن می نگریم.
چه کسانی تست نرم افزار را انجام می دهند؟
متخصصان و یا ابزارهایی که روند تست نرم افزار را انجام می دهند، عبارت اند از:
- مدیر پروژه: شاید بیشتر مدیر پروژه تست هایی را برای تأیید یک فاز پروژه و رفتن به فازهای بعدی، انجام می دهد. تست مدیر پروژه، بعد از بررسی های دقیق کارشناسان تست و تست برنامه نویسان است.
- مهندسان نرم افزار: مهندسان تست، برای هر قسمت از برنامه، کد تست می نویسند که از این نوع تست ها، به عنوان تست های واحد تعبیر می شود. یا هنگامی که چند واحد برنامه را کنار هم قرار می دهند، برای تست اینکه متوجه بشوند چند واحدِ یکپارچه شده در کنار همدیگر درست کار می کنند یا نه، بررسی هایی انجام می دهند و تست هایی تعریف می نمایند که به این نوع تست، تست یکپارچگی گفته می شود.
- متخصصان تست: افرادی هستند که در تمام مراحل تولید برنامه، روش هایی برای تست تعریف می کنند و سعی دارند این تست ها را انجام دهند؛ مثلاً در قسمت کد، از برنامه نویس می خواهند که تست های واحد را انجام دهند و اینکه چه جاهایی را بیشتر تست نمایند. بعد از ورژنیگ، تست رگرسیون را انجام می دهند؛ یعنی اینکه چه جاهایی از سیستم تغییر کرده است. برای این منظور، تست های پیشین را یک بار دیگر انجام می دهند. وقتی رابط کاربری آماده شد، برای کاربردپذیری و اینکه اجزای واسط کاربری درست کار کنند، اقدام به انجام تست های دستی می نمایند.
در رابط کاربری، برخی تست ها را به صورت ماشینی انجام می دهند؛ همان طورکه در کد برنامه، برخی تست ها را به صورت ماشینی انجام دادند. برای انجام تست و آلفا و بتا، روش هایی را اتخاذ می کنند که کمترین هزینه را داشته باشد و در کمترین زمان ممکن سامان یابد.
انواع برنامه های تست نرم افزار
برخی شرکت ها برای تست نرم افزار برنامه هایی را ارائه داده اند که می توان از جمله به: رونرکس، تست کامپلیت و تستینگ انی ور اشاره کرد. این سه نرم افزار، روی محصولات وب، موبایل و دسکتاپ قابل استفاده هستند. در این نرم افزارها، انجام تست خودکار و دستی امکان پذیر است. همچنین، این نرم افزارها قابل زمان بندی و برنامه نویسی هستند؛ مثلاً می توان یک تست، مانند ورود به یک وب گاه را انجام داد. همچنین، این تست را می توان به این صورت نوشت که هر هفته یک بار این تست انجام شود و اگر تست موفقیت آمیز باشد، یک ایمیل با این عبارت به فرد مورد نظر بزند: «تست مورد نظر درست انجام شد.» اما اگر فیلد شد، یعنی نتوانست وارد وب گاه شود، به کارشناس تست ایمیل بزند: «تست مورد نظر درست انجام نشد.» و همچنین، دلایلی را که نتوانسته وارد وب گاه مربوطه شود، به کارشناس تست گزارش دهد.
گفتنی است، این سه نرم افزار یک نسخه آزمایشی یک ماهه دارند که پس از پایان یک ماه، باید نسخه تجاری آن را تهیه کرد؛ ولی یک راهکار برای استفاده از این نرم افزارها بدون خرید آنها وجود دارد و آن این است که روی یک رایانه مجازی این نرم افزار را نصب کنیم و حالت اوّلیه آن را ذخیره کنیم و هر ماه به حالت اوّلیه برگردیم.
افزون بر سه نرم افزار یادشده، نرم افزارها و وب گاه های بسیاری در انجام تست نرم افزار در سه نوع موبایل، وب و دسکتاپ وجود دارد؛ مثل نرم افزار مانکی که مخصوص تست نرم افزارهای موبایلی است.
برخی ابزارهای تست
- Appium: نرم افزار تست خودکار.
- Calabash: نرم افزار تست خودکار.
- xamarin test cloud: با این شرکت، می توان یک تست خودکار روی تعداد بسیاری گوشی به طور هم زمان انجام داد.
- Testdriod: تست خودکار نرم افزار موبایل روی گوشی های واقعی اندروید و iOS.
- prefecto mobile: تست خودکار و functional برنامه. استفاده از مدل continuous quality این نرم افزار، commercial است.
- SOASTA touch test: تست خودکار نرم افزار موبایل، به صورت functional.
- Testin: این نرم افزار، این قابلیت را فراهم می سازد که نرم افزارهای خود را روی بیشتر از 300 گوشی تست کنیم. حالت cload آن، امکانات بیشتری مانند automated compatibility و performance testing دارد.
- Ubertesters: این برنامه کمک می کند که روند توسعه نرم افزار بر اساس پروسه QA، سازمان یافته تر باشد.
- crashlytics: این برنامه، یک نرم افزار آزاد برای iOS و اندروید است.
- Ranorex: این برنامه، یک نرم افزار تست موبایل است که به وسیله آن یک تست را رکورد می کنیم و می توانیم آن را روی deviceهای بسیاری اجرا نماییم.
- Experitest: نرم افزار تست خودکار و تست functional. با این نرم افزار می توان یک تست رکورد کرد و آن را به دفعات زیاد روی یک دیوایس اجرا نمود. می توان با زبان های python و C# یک تست را نوشت و روی گوشی های مختلف اجرا کرد.
- Android Lint: یک ابزار است که به eclipse اضافه می شود و کدهای پروژه را به منظور یافتن اِشکال چک می کند و همچنین، از نظر امنتتی و کارایی، عملکرد نرم افزار را بهبود می بخشد.
- FindBugs: یک نرم افزار تست کد استاتیک است که می توان از آن برای اصلاح برنامه های جاوا استفاده کرد.
- Maveryx: یک نرم افزار تست برای تست functional، تست خودکار و تست GUI در نرم افزارهای اندروید است.
- clang static analyzer: یک ابزار اپن سورس برای iPhone است که تست static انجام می دهد و نرم افزار را آنالیز می نماید.
- Analyze code for Xcode: یک افزونه برای Xcode است که در زمان compile، کد را آنالیز کرده، اِشکال ها و باگ ها را گزارش می دهد.
- Monkeytalk: یک نرم افزار آزاد است که تست خودکار و functional را با روش های بسیاری مثل smoke test انجام می دهد.
- Caliper: یک نرم افزار اپن سورسِ ساخته شده توسط گوگل است که نتایج javamicrobenchmarks را روی اپلیکیشن ما نشان می دهد. این روش، در واقع، یک تست کارایی با benchmarkهای موجود است.
- EMMA: این برنامه، یک ابزار مناسب برای اندازه گیری code coverage مربوط به یک برنامه جاواست.
- Robotium: یک فریم ورک تست خودکار است که بدون نیاز به دانش زیاد در مورد اپلیکیشنِ مورد تست، می توان آن را آزمایش کرد. نوع تست آن، balck-box است؛ یعنی نیازی به این نیست که کد برنامه را در اختیار داشته باشیم.
- Robolectric: یک فریم ورک unit test است که کلاس ها را دنبال می کند و قابلیت این را دارد که بدنه متدها را دوباره بنویسد؛ به گونه ای که به صورت default مقادیر را به Null یا 0 برگرداند.
- Monkeyrunner: به IDE اضافه می شود و به ما اجازه می دهد که تست functional بگیریم. این نوع تست، به سورس کد برنامه احتیاجی ندارد و بر روی دیوایس و emulator اجرا می شود و در نتیجه، می توان با python برنامه نوشت.
- Apthwack: یک API آزاد برای تست نرم افزار است که به کمک آن، برنامه را آپلود کرده، تست می کنیم که اشکال ها را به ما می گوید. این متد، روی تعداد بسیاری دیوایس فرایند تست را انجام می دهد و مصرف منابع را به ما گزارش می دهد.
- HP: یک راه حل تست شرکت hp با قابلیت های تست موبایل، مانیتورینگ نرم افزار موبایل، امنیت نرم افزار موبایل و شبیه سازی شبکه با کارایی بالاست.
- mobilelabs: یک راه حل جامع برای تست نرم افزار موبایل در کلود (فضای ابری) است.
ابزارهای تست (22)GUI ابزارهای محبوب خودکارسازی تست وب ابزارهای تست واحد(23)
ابزارهای تست نرم افزار موبایل
ابزارهای تست موبایل، ممکن است به کد برنامه احتیاج داشته باشند یا تنها لازم باشد که فایل محصول را به آن داد تا آزمایش مورد نظر را انجام دهد.
ابزارهای تست کد
در این قسمت، برنامه هایی را معرفی می کنیم که برای استفاده از آنها احتیاج به کد است و گاهی نیز حین توسعه نرم افزار کارایی دارند. در این نوع، ابزارهای جداگانه ای برای مشاهده وجود ندارد و عموماً با نصب SDK می توان از این ابزارها استفاده کرد.
- Monkey: این ابزار به صورت اتفاقی دکمه های مختلف را تست می نماید؛ یعنی eventهای مختلف را call می کند تا برنامه در صورت وجود مشکل، کرش کند. ابزار فوق، برای stress test، برنامه مناسبی است.
- Fitnesse: این یک فریم ورک است که به افراد پروژه امکان ارتباط بیشتر را با کسانی که در یک پروژه در حال همکاری هستند، می دهد؛ ولی در عین حال، ابزارهای تست هم دارد. این ابزار، برای مدل تست acceptance test و Integrated test استفاده می شود.
- Hamcrest: یک لایبراری تست است که به کد هم احتیاج دارد. با استفاده از متدهایی که دارد، می تواند Unit تست انجام دهد. در صورتی که احتیاج باشد برنامه را به صورت ایزوله تست کند، می تواند با امکانی به اسم parser test کامپوننت های برنامه را به صورت ایزوله تست نماید؛ حتی اگر آنها به یک API ، JSON یا XMLهایی خارج از برنامه احتیاج داشته باشند. همچنین، می توان با آن Memory leak برنامه را تشخیص داد.
لزوم تست نرم افزار توسط تیم جدا
آیا بخش تست شما جداست؟ این، یعنی همان دهمین آیتم از تست جوئل. اگر در تیم شما افرادی که وقتشان اختصاصاً برای تست کردن باشد ـ حداقل یک نفر برای هر دو یا سه برنامه نویس ـ وجود نداشته باشد، شما محصولات خود را باگ دار تحویل خواهید داد.
اینکه برنامه نویس یک سیستم، نرم افزار را تست کند، لازم و ضروری است؛ ولی به هیچ عنوان کافی نیست. این تصمیم که محصول تولیدی، توسط تیم جداگانه ای تست شود، شاید در مرحله اوّل خوب به نظر نیاید، ولی در واقع، بسیار مفید است. دلایل اشتباهی که ممکن است فکر کنیم به شخص یا ابزار تست کننده نیاز نداشته باشیم، عبارت اند از:
- - باگ ها توسط برنامه نویسان ضعیف تولید می شوند؛
- - برنامه من، یک برنامه وب است و سریع می توانم مشکل آن را برطرف کنم؛
- - مشتری من، سیستم را برای من تست می کند؛
- - من از عهده هزینه تستر برنمی آیم.
به نظر می رسد، مشتری انتظار دیدن باگ در سیستم را ندارد و با دیدن هر باگ، از سیستم ناامید و ناامیدتر می شود. باگ را در هر کدی می توان یافت و فقط به برنامه نویسان ضعیف اختصاص ندارد. تست توسط تیم جدا می تواند به راحتی از هزینه های اضافی و نارضایتی مشتری جلوگیری نماید.
چشم انداز
حجم برنامه های کاربردی، روز به روز در حال افزایش است. از نظر مهندسان نرم افزار، نوشتن کدهای تست، به خودی خود، مثل توسعه خود محصول، وقت گیر و گران است. خودکارسازی تست، زمانی مؤثر است که شرایط نرم افزار تحت تست مناسب باشد. باید توجه داشت که تست خودکار، به این معنا نیست که کل فرآیند تست نرم افزار به صورت خودکار انجام می شود؛ بلکه به معنای تست نرم افزار با کمک رایانه است. استفاده از تست خودکار، پُرهزینه است و در واقع، تست خودکار، مکملی برای فرآیند تست دستی می باشد.
نتیجه گیری
در این بین، جای یک چارچوب تست خودکار جامع که در آن مجموعه ای از ابزارهای خوب و کارآمد موجود باشد، خالی است و نیاز به چنین چارچوبی به وضوح قابل درک است. در مجموع، می توان گفت روش آزمون در این چارچوب، روش جعبه خاکستری است؛ زیرا گرچه نیازی به داشتن اطلاعات دقیق از کد منبع نرم افزار و ارتباطات داخلی آن برای انجام آزمون نداریم، اما دسترسی به یک مدل کلی از نرم افزار و یا دسترسی به خود کد منبع برای به دست آوردن یک مدل، به ما در تهیه موارد تست جامع تر کمک می نماید.
شایان توجه است که در قسمت ابزار تست، با توجه به آزمون های تست که از طریق ابزارهایی مانند: تست کامپلیت، رونرکس و تستینگ انی ور داشته ایم، به این نتیجه رسیدیم که این ابزارها تا حدودی می توانند نیازهای شرکت های تولید نرم افزار را پوشش بدهند؛ اما با توجه به اینکه این نرم افزارها کامرشیال است، مقرون به صرفه نیست که شرکت های تولید نرم افزار به سوی این نرم افزارها بروند و از آنها استفاده کنند. این نرم افزارها، ایده های خوبی برای خودکارسازی تست می دهند و می توان از این محصولات جهت تولید ابزار تست به صورت مهندسی معکوس عمل کرد.
به علاوه، شرکت های تولید محصولات نرم افزاری، اگر بیشتر روی یونیت تست ها سرمایه گذاری کنند و تمامی کدهای تست خود را بنویسند، ضمن اینکه بخشی از کد خود را می توانند به صورت ماشینی خودکار نمایند، در قسمت رابط کاربری هم می توانند با توجه به کدهای تست در لایه کد، برخی از تست های رابط کاربری را به صورت ماشینی انجام دهند.
پی نوشت ها:
منابع: