Softwaring

Separation of Concerns به طور خلاصه به معنی فرآیند جداسازی وجوه و موضوعات مختلف یک سیستم از یکدیگر است. به عبارت ساده تر، تمرکز بر روی فرآیند یا عملکردی از یک سیستم و عدم توجه به کارکرد و جزییات دیگر آن.

به عنوان مثال، شما و همسرتان در خیابان قدم می زنید که یک اتومبیل (برای جذابیت بیشتر موضوع تصور کنید یک BMW آخرین مدل!) از کنار شما به سرعت رد می شود. ممکن است شما به خلاقیت سازندگان در طراحی بدنه اتومبیل مزبور توجه کرده باشید در صورتی که در همان زمان همسر شما در مورد اینکه قیمت چنین اتومبیلی چند می تواند باشد می اندیشد. در واقع شما دو نفر یک اتومبیل را از دو منظر متفاوت نگاه کرده اید (Separation of Concerns).

نمونه ای نرم افزاری از این مفهوم، الگوی طراحی MVC است.

 Separation of Concerns  - به نظر من - یکی از مفاهیم زیر بنایی برای انجام موفق تست های مختلف نرم افزار است. معمولا یک سیستم نرم افزاری در حین تولید و پس از آن تحت تست های مختلفی قرار می گیرد که از آن جمله می توان به تست ماژول های برنامه (Unit Test)، تست فشار (Stress Test) و تست پذیرش (Acceptance Test) و بسیاری دیگر اشاره کرد.

در واقع انواع مختلف تستهای یک سیستم، خود گویای مفهوم (Separation of Concerns) است. اما هدف من از نگارش این مطلب طرفداری از ایده انجام تستهای مختلف به صورت مجزاست. هر چند با توجه به ماهیت برخی از گونه های تست اصولا نمی توان آنها را با هم اجرا کرد (مثل Unit Test و User Acceptance Test) اما برخی دیگر را می توان به صورت همزمان انجام داد (مثل تست عملکرد برنامه و واسط کاربری).

ایده اصلی این است:

تا حد امکان از انجام تست های مختلف یک برنامه به صورت همزمان پرهیز کنید.

هر چند که گاهی انجام همزمان تست ها در کاهش زمان تست یک سیستم تاثیر دارد اما تاثیر منفی آن در کیفیت تست های انجام شده قابل چشم پوشی نیست.

در وبلاگ آقای مهندس مهرداد مطلب جالبی درج شده بود در مورد تحقیقی صورت گرفته در رابطه با ۲۵ خطای خطرناک و شایع در نرم افزارها که بسیاری از تیم های برنامه سازی مرتکب آن می شوند. خواندن آنرا به همه دوستان نرم افزارچی(!) توصیه می کنم:

The Top 25 Errors are listed below in three categories:
Category: Insecure Interaction Between Components (9 errors)
Category: Risky Resource Management (9 errors)
Category: Porous Defenses (7 errors)

CATEGORY: Insecure Interaction Between Components
CWE-20: Improper Input Validation
CWE-116: Improper Encoding or Escaping of Output
CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection')
CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection')
CWE-319: Cleartext Transmission of Sensitive Information
CWE-352: Cross-Site Request Forgery (CSRF)
CWE-362: Race Condition
CWE-209: Error Message Information Leak
CATEGORY: Risky Resource Management
CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer
CWE-642: External Control of Critical State Data
CWE-73: External Control of File Name or Path
CWE-426: Untrusted Search Path
CWE-94: Failure to Control Generation of Code (aka 'Code Injection')
CWE-494: Download of Code Without Integrity Check
CWE-404: Improper Resource Shutdown or Release
CWE-665: Improper Initialization
CWE-682: Incorrect Calculation
CATEGORY: Porous Defenses
CWE-285: Improper Access Control (Authorization)
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
CWE-259: Hard-Coded Password
CWE-732: Insecure Permission Assignment for Critical Resource
CWE-330: Use of Insufficiently Random Values
CWE-250: Execution with Unnecessary Privileges
CWE-602: Client-Side Enforcement of Server-Side Security

برای مشاهده اصل گزارش اینجا را کلیک کنید.

در آوریل 1990، تلسکوپ فضایی هابل به مدار زمین فرستاده شد. هدف اصلی این تلسکوپ فضایی، بزرگنمایی اهداف مورد مشاهده با استفاده از یک آینه بزرگ بود. تولید آینه مزبور امری دشوار و نیازمند صحت و دقت بسیار بالایی بود (رجوع کنید به تفاوت صحت و دقت در مطالب گذشته وبلاگ). آزمایش این آینه از این جهت که قرار بود محیط واقعی آن در فضا باشد، در محل ساخت آن در زمین بسیار مشکل می نمود. در نتیجه تنها راه تست، اندازه گیری دقیق مشخصات محصول ساخته شده و مقایسه آن با مشخصات تعیین شده برای محصول مورد نظر بود. این آزمایشات با موفقیت صورت گرفته و هابل آماده پرتاب اعلام شد.

متاسفانه به محض عملیاتی شدن این تلسکوپ مشخص شد که تصاویر ارسال شده توسط آن به هیچ وجه فوکوس نیست. در تحقیقات صورت گرفته مشخص شد که ساخت آینه به درستی صورت نگرفته است. آینه مزبور بر اساس مشخصات تعیین شده (Specifications) تولید شده بود اما این مشخصات نادرست بوده است. این آینه به طور کامل دقیق (Precise) ساخته شده بود اما از صحت لازم (Accuracy) برخوردار نبود.

آزمایشات تایید کرده بود که آینه مزبور مشخصات لازم را تامین کرده است (Verification) اما درستی خود مشخصات اولیه را مورد بررسی قرار نداده بود (Validation).

به عبارت دیگر Verification به فرآیند مطابقت محصول با مشخصات آن گفته می شود اما Validation فرآیند مقایسه مشخصات محصول با نیازمندی های واقعی کاربر است.

هر چند مثال بالا مثالی خارج از حوزه نرم افزار است اما به طور دقیق قابل نگاشت به محصولات نرم افزاری می باشد. در نتیجه هرگز تصور نکنید که در صورت مطابقت نرم افزار تولید شده با مشخصات آن، محصول مزبور بدون عیب است. بلکه بخش مهم دیگر در آزمایش نرم افزار، مطابقت مشخصات محصول با خواسته واقعی کاربر آن است.

اصل 1: هدف از تست نرم افزار یافتن خطا است، نه اطمینان از درستی کارکرد نرم افزار.

اصل 2: برنامه نویس باید از تست برنامه خود اجتناب کند.

اصل 3: آزمایش موارد قابل انتظار در برنامه نیمی از ماجراست. نیم دیگر آزمایش مواردی است که انتظار میرود برنامه آن را انجام ندهد.

اصل 4: با فرض اینکه هیچ نقصی در برنامه نخواهید یافت تست را آغاز نکنید.

اصل 5: احتمال اینکه اشکالات بیشتری در قسمتی از برنامه کشف شود متناسب با تعداد اشکالات کشف شده  قبلی در آن بخش از برنامه است (به عبارت دیگر هرچه در ماژولی از برنامه خطاهای بیشتری پیدا کنید، احتمال وجود خطاهای دیگر در آن ماژول بیشتر است).

اصل 6: غیر ممکن است که بتوان یک برنامه را به طور کامل تست کرد.

اصل 7: تست نمیتواند نشان دهد که اشکالی وجود ندارد، بلکه تنها قادر است نشان دهد که اشکال وجود دارد!

اصل 8: برنامه پس از مدتی در برابر تستهای تکراری مقاوم خواهد شد (همانگونه که آفت ها پس از مدتی در مقابل یک آفت کش ثابت مصون میگردند).

References:

1.      The Art of Software Testing, Second Edition, Glenford J. Myers, Wiley Pub.

2.      Software Testing, Ron Patton, Sams Pub.

دو مفهوم صحت و دقت در شکل زیر به خوبی به تصویر کشیده شده اند:

·         شکل پایین – چپ: شلیک ها نه صحیح و نه دقیق است. تیرها به شکل غیر مجتمع بوده و به مرکز هدف نیز نزدیک نیست.

·         شکل پایین – راست: شلیک ها صحیح است اما از دقت کافی برخوردار نیست.

·         شکل بالا – چپ: شلیک ها به شکل مجتمع و دقیق انجام شده اما با هدف فاصله دارد. لذا دارای دقت و فاقد صحت است.

·         شکل بالا – راست: شلیک ها هم از ویژگی دقت و هم صحت برخوردار است.

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

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

هر چند ماهیت نرم افزار با دیگر انواع محصولات تاحدی متفاوت است (در جایی خواندم که اجرای ساختمان را به ساخت لگو و تولید نرم افزار را به درست کردن شکلی با خمیر بازی کودکان تعبیر کرده بود)، اما آیا می توان طراحی نرم افزار را طوری انجام داد که احتمال خطای کاربر به صفر برسد؟ آیا در سطح تولید نرم افزار می توان خط تولید را طوری طراحی کرد که احتمال خطای تیم توسعه منتفی گردد؟

اشکال تقسیم با ممیز شناور Intel Pentium (1994)

معادله زیر را در ماشین حساب PC خود وارد کنید:

(4195835 / 3145727) * 3145727 - 4195835

در صورتی که پاسخ صفر است پردازنده شما بدون عیب است. در صورتی که هر پاسخ دیگری مشاهده کردید، پردازنده دستگاه شما یک Intel Pentium  قدیمی است که در کلیه پردازنده های سری ساخت پردازنده شما تکرار شده است.

در 30 اکتبر 1994، دکتر Thomas R. Nicely  از کالج Lynchburg (ویرجینیا) در یکی از آزمایشات خود پاسخ غیر منتظره ای در تقسیم معادله مورد آزمایش بر روی Pentium PC خود مشاهده کرد. وی این کشف را بر روی اینترنت قرار داد و پی از آن خیل عظیمی از دیگر افرادی که در محاسبات خود به مشکل مشابه برخورد کرده بودند این مشکل را گزارش کردند. خوشبختانه این مشکل تنها در محاسبات پیچیده­ نمود پیدا می­کرد و بیشتر برنامه های محاسبه ای تجاری نظیر محاسبه مالیات و سود و زیان به چنین مشکلی برخورد نکرده بودند.

چیزی که این داستان را برجسته می سازد نه اشکال یاد شده، بلکه نحوه برخورد Intel با این مشکل بود:

·         مهندسین تست نرم افزار این مشکل را در حین آزمونهای خود و پیش از ارایه این سری پردازنده به بازار کشف کرده بودند. اما مدیریت Intel به اندیشه اینکه این مشکل جدی نبوده و احتمال وقوع آن بسیار پایین است تصمیم به انتشار این پردازنده بدون اطلاع رسانی عمومی گرفت.

·         هنگامی که این مشکل فاش گردید، Intel از طریق رسانه های جمعی سعی در کم اهمیت نشان دادن مشکل مزبور کرد.

·         شرکت Intel تحت فشار رسانه ها و افکار عمومی اعلام کرد که پردازنده های دارای مشکل را تعویض می کند اما به شرطی که دارنده آن بتواند ثابت کند که از این اشکال متاثر شده است.

پس از آن، موج اعتراض مشتریان خشمگین روانه این شرکت شد. گروه های خبری در اینترنت مملو از نوشته های  اعتراض آمیز شد که خواستار رفع این مشکل از طرف Intel شده بودند و اخبار و نشریات، شرکت Intel را متهم به بی توجهی و بی تفاوتی به خواست مشتریان نمودند.

در نهایت Intel از نحوه برخورد خود با این مشکل عذرخواهی کرده و متحمل هزینه ای بالغ بر 400 میلیون دلار برای تعویض پردازنده های معیوب خود گردید. در حال حاضر Intel کلیه مشکلات شناخته شده را بر روی وب سایت خود قرار می دهد و به دقت بازخورد مشتریان خود را در گروههای خبری اینترنتی دنبال می کند.

کاوشگر مریخ ناسا 1999 (NASA Mars Polar Lander - 1999)

در 3 دسامبر سال 1999 کاوشگر مریخ که قرار بود روی سطح کره مریخ فرود بیاید ناپدید شد. هیئت بررسی شروع به تحقیق در مورد علت این امر نمود و مشخص شد که علت، ست شدن نادرست یک بیت (!) بوده است. همه اتهامات متوجه تیم تست نرم افزار این کاشف شد.

برنامه فرود به این شکل تعیین شده بود: در زمانی که کاوشگر باید فرود می آمد، یک پاراشوت (چتر) می بایست باز میشد تا سقوط کاوشگر را کند نماید. چند ثانیه بعد باید سه پایه از زیر کاوشگر خارج می شد و در جهت فرود قرار می گرفت. هنگامی که کاوشگر در ارتفاع 1800 متری مریخ قرار می گرفت، باید پاراشوت رها می شد و موتور فرود وسیله در جهت عکس سقوط روشن می شد تا کاوشگر به آرامی در روی سطح مریخ فرود آید.

یکی از مهترین مسائل در این فرآیند این است که کاوشگر تشخیص دهد که چه زمانی بر روی سطح مورد نظر فرود آمده تا به موقع موتور فرود خود را خاموش کند. برای این منظور ناسا که در دیگر سفینه های خود از رادارهای گرانقیمتی بهره برده بود تصمیم گرفت که برای کاهش هزینه ها، از مکانیزم ساده تری استفاده کند. به این شکل که در زیر سه پایه فرود کاوشگر سوییچ های تماسی (Contact Switch) تعبیه کردند تا به محض برخورد این سوییچ ها با سطح مریخ، یک بیت ست شده و در اثر قطع شدن سوخت، موتور فرود خاموش شود.

هیئت بررسی پس از تحقیق متوجه شد که هنگام باز شدن سه پایه فرود کاوشگر، در اثر لرزش حاصله از این عمل، بیتی که باید پس از تماس با سطح ست می شد به اشتباه ست شده و کاوشگر که تصور کرده به سطح رسیده است موتور خود را خاموش کرده و از ارتفاع 1800 متری سقوط کرده است. به همین سادگی (!)

نتیجه فاجعه بار بود اما علت ساده. کاوشگر توسط تیم های مختلفی مورد آزمایش قرار گرفته بود که هر تیم مسئول تست بخشی از عملکرد کاوشگر بودند. یک تیم فرآیند باز شدن پایه ها را مورد آزمایش قرار داده بود و تیم دیگر فرآیند فرود را از زمان باز شدن پایه ها. تیم اول آزمایش نکرده بود که آیا بیت مورد نظر ست شده است یا خیر. تیم دوم نیز همواره کامپیوتر را Reset می کرده و بیت مورد نظر را به مقدار اولیه برمی گردانده و سپس آزمایش خود را به انجام می رسانده است.

هر دو تیم به طور مجزا کار خود را بدون نقص انجام داده بود اما اشکال مزبور تنها هنگامی بروز میکرد که دو تیم باهم ترکیب شوند  (Integration Test).

(منبع: Software Testing,Ron Patton, Sams Publishing, 2005)