رفتن به محتوا

۹ دقیقه مطالعه

بهترین ابزارهای آزمایش اسکنر بارکد برای توسعه‌دهندگان

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

چه چیزی ابزار آزمایش را واقعاً مفید می‌کند

ابزار خوب فقط ثابت نمی‌کند مسیر خوشحال یک بار کار می‌کند. کمک می‌کند وقتی چیزی شکست می‌خورد سریع پیش بروید. در آزمایش اسکنر بارکد این معمولاً چهار چیز است:

  • راه‌اندازی سریع
  • ورودی تکرارپذیر
  • دید به آنچه برنامه واقعاً دریافت کرده
  • کنترل کافی برای بازتولید حالت‌های مرزی زمان‌بندی و پسوند

معمولاً ابزارها را با یک پرسش می‌سنجم: آیا زمان بین «این غلط به نظر می‌رسید» و «می‌فهمم چرا خراب شد» را کوتاه می‌کند؟ اگر پاسخ نه باشد، ابزار احتمالاً به‌جای ارزش، تشریفات اضافه می‌کند.

۱. شبیه‌ساز اسکنر بارکد به جعبهٔ ابزار پیش‌فرض تعلق دارد

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

به همین دلیل ابزاری مثل Barcode Scanner Emulator مفید است: حلقهٔ بازخورد را کوتاه می‌کند. می‌توانید مقدار بارکد را عوض کنید، اسکن را دوباره اجرا کنید، پسوند دیگری را بیازمایید و نتیجه را فوراً مقایسه کنید. برای بیشتر اشکال‌زدایی رابط و گردش، این ارزشمندتر از انتظار برای دسترسی به اسکنر فیزیکی است.

آزمایش اسکنر بارکد آسان‌تر است وقتی ابزارهای اصلی سریع، تکرارپذیر و برای اشکال‌زدایی عملی گردش ساخته شده باشند.
آزمایش اسکنر بارکد آسان‌تر است وقتی ابزارهای اصلی سریع، تکرارپذیر و برای اشکال‌زدایی عملی گردش ساخته شده باشند.

۲. اسکنرهای سخت‌افزاری واقعی هنوز مهم‌اند

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

سخت‌افزار واقعی برای اعتبارسنجی این‌ها مهم است:

  • رفتار ماشهٔ اسکنر
  • اتصال USB و ویژگی‌های عجیب درایور
  • محدودیت‌های پایانه
  • تفاوت پیکربندی سخت‌افزار
  • حس واقعی اپراتور

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

۳. فیکسچرهای پایدار دادهٔ آزمایش دست‌کم گرفته می‌شوند

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

مجموعهٔ مستندی از بارکدهای آزمایش نگه دارید برای:

  • یک محصول معتبر
  • یک بارکد ناشناس
  • بارکدی با صفرهای آغازین
  • کالای محدود یا دارای محدودیت سنی
  • محصولی با تخفیف یا تبلیغ

این به‌ویژه برای آزمایش POS مهم است. اگر دادهٔ آزمایش هر روز عوض شود، در نهایت محیط را اشکال‌زدایی می‌کنید نه نرم‌افزار را.

۴. ابزارهای بازرسی شبکه و API هم بخشی از آزمایش بارکدند

شمار غافلگیرکننده‌ای از شکست‌های مربوط به اسکن بعد از ورود مقدار به فیلد رخ می‌دهد. بارکد درست فرود می‌آید، اما درخواست جست‌وجو بدشکل است، نادرست بریده شده، بد در حافظهٔ نهان مانده، یا بک‌اند آن را رد کرده است.

به همین دلیل لاگ‌ها، بازرس‌های شبکه و ابزارهای API هنوز بخشی از بهترین پشتهٔ آزمایش اسکنر بارکد هستند. اگر اسکن در فیلد جست‌وجوی POS هیچ کاری نکند، می‌خواهم بدانم بارکد درست نرمال شده یا نه، Enter دو بار زده شده یا نه، و سرور نتیجهٔ مورد انتظار را برگردانده یا نه. ابزار اسکنر به‌تنهایی به این پرسش‌ها جواب نمی‌دهد.

۵. جعبه‌های شنی POS و محیط‌های staging شکاف گردش را می‌بندند

در آزمایش POS و گردش صندوق، staging مهم است چون اسکن هرگز فقط ورود متن نیست. قیمت، مالیات، مجوز، موجودی، انتساب مشتری و منطق رسید را لمس می‌کند.

اینجاست که محیط staging یا جعبهٔ شنی ضروری می‌شود. اسکن شبیه‌سازی‌شده ممکن است در صفحهٔ نمایش یک جزء کامل کار کند و باز هم شکست بخورد وقتی تبلیغ، قاعدهٔ موجودی و مجوز صندوق‌دار وارد می‌شوند. این دلیل کنار گذاشتن شبیه‌ساز نیست. دلیل جفت کردن آن با اعتبارسنجی بهتر گردش است.

پشتهٔ ابزاری عملی که برای بیشتر تیم‌ها کار می‌کند

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

  1. شبیه‌ساز بارکد برای توسعهٔ روزانه و تکرارهای QA
  2. یک اسکنر واقعی برای اعتبارسنجی انتشار
  3. فیکسچرهای پایدار بارکد، بسته به محصول یا موجودیت شناخته‌شده
  4. لاگ درخواست و برنامه برای اشکال‌زدایی
  5. محیط staging یا جعبهٔ شنی POS برای بررسی کامل گردش

سریع‌ترین تیم‌ها لزوماً بیشترین ابزار را به کار نمی‌برند. مجموعهٔ کوچک درست را به کار می‌برند و مطمئن می‌شوند هر کدام نوع متفاوتی از شکست را بپوشاند.

قاعدهٔ کوچک و قاطعی که وقت ذخیره می‌کند

اگر قرار باشد یک اشتباه را از بیشتر تیم‌ها حذف کنم، این است: برای پرسش‌هایی که آشکارا دربارهٔ رفتار گردش نرم‌افزارند از سخت‌افزار واقعی استفاده نکنید. اگر مسئله فوکوس، رسیدگی به Enter، زمان‌بندی جست‌وجو یا ترتیب اعتبارسنجی است، با شبیه‌سازی و لاگ شروع کنید. سخت‌افزار را وقتی برگردانید که مسئله را تنگ کرده باشید.

این ترتیب حلقهٔ اشکال‌زدایی را سالم نگه می‌دارد. همچنین مانع می‌شود خود اسکنر بهانه شود که چرا اشکال پس از نیم‌روز بررسی هنوز مبهم است.

جایی که این واقعاً فرق ایجاد می‌کند

سریع‌ترین تیم‌ها به یک ابزار تکیه نمی‌کنند.

چند ابزار ساده را با هم ترکیب می‌کنند که بگذارند وقتی چیزی می‌شکند سریع حرکت کنند.

اگر چیدمان شما کمک کند همان اسکن را دوباره اجرا کنید، ببینید چه شده، و سریع تنظیم کنید، از پیش جلو هستید.

گام مفید بعدی

اگر می‌خواهید این گردش‌ها را در عمل امتحان کنید، از ابزار Barcode Scanner Emulator شروع کنید و سپس برای الگوهای آزمایشی بیشتر به بقیهٔ وبلاگ برگردید.

مقاله‌های مرتبط