خلاصه: در فیلم پلیس آهنی یک مامور سایبورگِ اجرای قانون، به مردم توصیه میکرد “از درد سر دوری کنند”. این مقاله تمرکز خود را روی اجتناب از دردسر در زمان تولید یک محصول نرمافزاری معطوف کرده است و این کار را با طی کردن مراحل تست نرمافزار انجام میدهد. در همین راستا از فیلم پلیس آهنی که در سال ۱۹۸۷ ساخته شده است به عنوان مثال استفاده شده است. بنابراین به ما اجازه بدهید مراحل مختلف تست را بررسی کنیم تا ببینیم آیا میتوانیم یک پلیس آهنی بهتر بسازیم.
در فیلم پلیس آهنی یک مامور سایبورگِ اجرای قانون، به مردم توصیه میکرد “از درد سر دوری کنند”. این مقاله تمرکز خود را روی اجتناب از دردسر در زمان تولید یک محصول نرمافزاری معطوف کرده است و این کار را با طی کردن مراحل تست نرمافزار انجام میدهد. در همین راستا از فیلم پلیس آهنی که در سال ۱۹۸۷ ساخته شده است به عنوان مثال استفاده شده است. بنابراین به ما اجازه بدهید مراحل مختلف تست را بررسی کنیم تا ببینیم آیا میتوانیم یک پلیس آهنی بهتر بسازیم.
تست یونیت یا Unit Testing
یک یونیت در حقیقت کوچکترین قسمت عملیاتی از یک کد در اپلیکیشن نرمافزاریست. در برنامهنویسی Object Oriented، کوچکترین یونیت معمولا یک متد است. متد میتواند به سادگی یک دستورالعمل تک خطی باشد، مانند حاصلضرب a در b، که Function مرتبط با ضرب دو عدد در یکدیگر را انجام میدهد. یک Unit Test، برای حصول اطمینان از اینکه Functionها همانطور که انتظار میرفته طراحی شدهاند، کوچکترین قطعه از کد عملیاتی را اجرا میکند. در این مورد Unit Test ضرب دو عدد را که یک مقدار درست تولید میکند را ممیزی مینماید.
در مثال پلیس آهنی، یک یونیت میتواند انگشت کوچک پلیس آهنی باشد. Unit Testهای ما ممیزی میکند که انگشت کوچک باید قادر به خم و راست شدن باشد. در زمان خمیدگی یا خم شدن در مسیری که مفاصل برای حرکت در آن راستا طراحی نشدهاند(البته خمیدگی در حد معقول)، انگشت کوچک نباید دچار شکستگی شود. یک تمایز مهم این است که یک بند انگشت، یعنی یک سوم انگشت، یک یونیت به حساب نمیآید، چرا که این یک سوم هیچ کار معنی داری انجام نمیدهد. به همین دلیل اولین قطعهای که یک فعالیت معنیدار که همان خم شدن باشد، انجام میدهد یک یونیت محسوب میشود، که در این مثال همان انگشت کوچک است.
تست یکپارچهسازی یا Integration Test
این مرحلهای از تست نرمافزار است که در آن دو یا چند یونیت با هم ترکیب شده و به عنوان یک گروه تست میشوند. هدف از تست Integration افشای مشکلات ناشی از تعاملات صورت گرفته میان یونیتهای ترکیب شده است.
بیایید تست کردن دو روش برنامهنویسی را که باید خروجیهایی تولید کنند که با هم کار میکنند را تصور کنید. به صورت جداگانه، هر متدی تمام Unit Testها را پاس میکند، اما باز هم خروجیهای هر متد با هم کار نمیکنند. یک متد یک رشته(String) را به عنوان خروجی ارائه میدهد، و متد دیگر یک خروجی Integer ارائه میدهد، به شکلی که عدم تطابق نوع(Type Mismatch) وجود دارد.
میتوان فرض کرد که Integration Testing برای پلیس آهنی مانند تست کردن دست(از مچ تا سر انگشتان) این ربات است، که از ۵ انگشت جداگانه به صورت یونیت و البته یک یونیت دیگر به نام کف دست(که انگشتان را با هم مجتمع کرده و به هم متصل میکند) تشکیل شده است. یک Integration Test خوب الزاما باید “چنگ کونگ فوییِ” پلیس آهنی را به عنوان یک پیش نیاز برای قهرمانان هالیوودی تحت آزمون قرار دهد. یک چنگ، بدون قابلیت پیادهسازی ضربات کونگ فو استاندارد نبوده و فورا رد خواهد شد.
نمونهای از شکست در تست Integration این است که دست پلیس آهنی نتواند دو یا بیشتر انگشتانش را در یک لحظه حرک دهد. آنچه در فیلم به بدان اشاره میشود این است که پلیس آهنی نیازمند چنگی هم برای دست دادن و هم شکستن دست است.
تست سیستم یا System Test
این مرحلهای از Software Testing است که در آن تمام گروههای Integrate شده برای شکلدهی به سیستم کامل با هم ترکیب میشوند. هدف System Testing افشای هر نوع Defect ناشی از تعامل میان گروههای Integrate شدهایست که روی هم سوار شدهاند. دراین مرحله شما دیگر کامپوننتها را تست نمیکنید، بلکه نتایجِ بازگشتیِ واقعیِ استفاده از محصول را مورد آزموایش قرار میدهید. اگر محصول شما یک برنامه پردازندۀ کلمات(Word Processor) است، شما باید این موضوع را تست کنید که تمام Menu Optionها نتایجی که از آنها انتظار میرود را تولید کنند، و اینکه برنامه مربوطه قادر به تولید یک سند متنی(که ظاهر آن بر حسب دلخواه شماست) باشد و بتواند آنرا برای پرینت ارسال کند.
اکنون پلیس آهنی به طور کامل روی هم سوار شده، و تمام مفاصل باید قابلیت خم شدن داشته باشند. پلیس آهنی باید قادر به حرکت مانند یک افسر پلیس سایبورگ بر مبنای نیازمندیهای طراحی شده خود باشد که عبارتند از: راه رفتن، دست دادن، و نوشتن برگ جریمه.
تست پذیرش یا Acceptance Testing
مرحله نهاییِ تست، ارزیابیِ سیستم است که تعیین میکند آیا محصول آماده شده، برای تحویل به مشتری، قابل پذیرش است یا خیر. سیستم ترکیب شده پلیس آهنی اکنون تحت آزمایش قرار میگیرد تا تعیین کند که آیا پلیس آهنی قادر به انجام تمام وظایف محوله(مانند افسر پلیس انسانی) در راستای اجرای قانون میباشد یا خیر. این کار باید به گونهای انجام شود که برای مشتریان قابل درک بوده و نیازمندیهای Usability مشتریان را برآورده نماید.
تست Acceptance این سوال را میپرسد که: “آیا مشتریان میتوانند به صورت موثر از سیستم پلیس آهنی استفاده نمایند؟”.
این مساله صرفا به معنیِ انجام دستورالعملهای تعریف شده بوسیله برنامهنویسی Logical کامپیوتری نیست، بلکه موضوع Context-Driven نیز مد نظر است. به عنوان نمونه، سیستم پلیس آهنی نباید برگه جریمه برای سگها و برای آشغال ریختن در پیادهرو صادر نماید. هر چند ممکن است بعضی از کارهای صورت گرفته خلاف قانون باشد، اما پلیس آهنی باید توان استدلال انسانی داشته باشد، و به این نتیجه برسد که این یک کار بی فایده است که مثلا برای سگها برگ جریمه صادر شود. البته همانطور که در فیلم بود، پلیس آهنی در تست پذیرش قبول میشود.
اگر بخواهیم مثالی از Fail شدن تست Acceptance در مورد پلیس آهنی ذکر کنیم، میتوانیم به اجرای قانون توسط ربات دیگری در این فیلم اشاره کنیم، که ED-209 نام داشت. ED-209 به نوعی رقیب رباتیکِ پلیس آهنی(شخصیت اول فیلم) محسوب میشد. این ربات به نوعی یک کرگدنِ چرخدندهای و دست و پا چلفتی بود که فقط به پردازش کد کامپیوتری برای رفتارهایش میپرداخت، و نمیتوانست مانند یک انسان تصمیمگیری کند. در طول تست Acceptance این ربات نه تنها برای یک سگ برگ جریمه صادر کرد، بلکه سگها را برای فعل خلاف در پیادهرو دستگیر کرد. اگر ما مسئول تست ED-209 بودیم، قطعا میگفتیم که تست پذیرش این ربات شکست خورده و نباید آنرا به مشتری تحویل داد.
دفعه بعد که خواستید تست یک محصول را به پیش ببرید، به پلیس آهنی و تست آن فکر کنید و مطمئن شوید که تمام مراحل بررسی کیفیت با موفقیت طی شده است.