چطور اپ‌تان را قبل از راه‌اندازی آزمون کنیم: برنامه عملی پیش از انتشار
برای آزمون اپ قبل از راه‌اندازی، چند مسیری را که کاربر باید بتواند کامل کند فهرست کنید، هر کدام را به‌عنوان کاربری کاملاً تازه روی لپ‌تاپ و گوشی اجرا کنید، سپس راه‌های اشتباه رفتن را امتحان کنید: داده خالی، ورودی بد، حساب دوم، اتصال کند. هر چیزی را که به پول یا داده خصوصی مربوط است با دقت بیشتری آزمون کنید و بعد از انتشار جریان‌های اصلی را روی نشانی زنده تکرار کنید. در پایان، کسی را که اپ را هرگز ندیده تماشا کنید که سعی می‌کند از آن استفاده کند.
برای این کار به تیم کیفیت یا چارچوب آزمون نیاز ندارید. به یک فهرست، یکی دو ساعت و انضباط برای واقعاً کلیک کردن در آن نیاز دارید.
گام ۱: مسیرهایی را که مهم‌اند بنویسید
مسیر یعنی یک کار از ابتدا تا انتها که کاربر برای انجامش می‌آید. بیشتر اپ‌ها سه تا شش مسیر دارند که واقعاً مهم‌اند. برای یک اپ رزرو:
- ثبت‌نام و تأیید حساب
- پیدا کردن یک کلاس و رزرو آن
- لغو یک رزرو
- پرداخت برای یک پاس کلاس
- کارکنان: دیدن رزروهای امروز
اگر داستان‌های کاربر را نوشته‌اید، معیارهای پذیرش آنها همان موارد آزمون شما هستند. اگر نه، برای هر مسیر یک خط بنویسید که «موفقیت» یعنی چه.
آنها را رتبه‌بندی کنید. مسیرهایی که پول می‌سازند یا همه کاربران به آنها می‌رسند (ثبت‌نام، ورود، عمل اصلی) اول و بیشتر آزمون می‌شوند.
گام ۲: مسیر خوشبختانه را به‌عنوان کاربر تازه آزمون کنید
«مسیر خوشبختانه» یعنی مسیری که دقیقاً همان‌طور که در نظر بوده پیش می‌رود. آن را همان‌طور آزمون کنید که یک غریبه تجربه می‌کند:
- از یک پنجره مرورگر خصوصی استفاده کنید، تا وارد نشده باشید و داده ذخیره‌شده‌ای نداشته باشید.
- از یک حساب تازه با ایمیل واقعی که بتوانید بررسی‌اش کنید استفاده کنید.
- از صفحه اصلی یا یک لینک شروع کنید، نه صفحه‌ای که هنگام ساخت نشانک زده‌اید.
کاربران جدید داده ندارند. بسیاری از باگ‌ها فقط وقتی دیده می‌شوند که فهرست خالی است، پروفایل عکس ندارد، یا هنوز چیزی خریده نشده. حساب خودتان، پر از داده آزمایشی، آنها را پنهان می‌کند.
گام ۳: سعی کنید آن را خراب کنید
حالا هر مسیر را تکرار کنید و عمداً کار اشتباه انجام دهید.
| این را امتحان کنید | چه چیزی را بررسی می‌کنید |
|---|---|
| فرم‌ها را خالی یا فقط با فاصله ارسال کنید | فیلدهای اجباری با پیام روشن اعمال می‌شوند |
| متن بسیار بلند، ایموجی، نام‌های با حروف تأکیددار | چیدمان پایدار می‌ماند، داده درست ذخیره می‌شود |
| فرمت‌های اشتباه: حروف در فیلد شماره تلفن، تاریخ گذشته | اعتبارسنجی هم در صفحه و هم در سرور |
| دکمه ارسال را دوبار کلیک کنید | هیچ سفارش یا رزرو تکراری ایجاد نمی‌شود |
| دکمه بازگشت مرورگر وسط یک جریان | هیچ وضعیت خراب یا داده گم‌شده‌ای نیست |
| هر صفحه را رفرش کنید | داده پایدار می‌ماند؛ صفحه خالی یا ۴۰۴ نمی‌بینید |
| خروج کنید، سپس دکمه بازگشت را بزنید | صفحه‌های خصوصی نمایش داده نمی‌شوند |
| دو تب که یک چیز را ویرایش می‌کنند | آخرین ذخیره، اولی را بی‌صدا پاک نمی‌کند |
رفرش ارزش اشاره دارد: اگر وقتی کلیک می‌کنید اپ کار می‌کند اما رفرش روی یک صفحه عمیق‌تر خطای ۴۰۴ نشان می‌دهد، چطور خطاهای ۴۰۴ بعد از انتشار را برطرف کنیم را ببینید.
گام ۴: دسترسی‌ها را با دو حساب آزمون کنید
این مهم‌ترین آزمون برای هر اپی با حساب کاربری است و اغلب جا می‌ماند.
دو کاربر عادی، A و B، و (اگر اپ شما دارد) یک مدیر بسازید.
- با A یک رکورد بسازید. با B وارد شوید. آیا B می‌تواند آن را ببیند، ویرایش یا حذف کند؟ نباید بتواند، مگر اینکه طراحی‌اش این باشد.
- با A نشانی یکی از رکوردهایتان را کپی کنید. با B وارد شوید و آن نشانی را مستقیم باز کنید.
- با یک کاربر عادی، صفحه‌های مدیریت را با تایپ کردن نشانی‌شان باز کنید.
- کاملاً خارج شوید و همان نشانی‌ها را امتحان کنید.
اگر اینجا مشکلی پیدا کردید، قبل از اینکه رفع نشود راه‌اندازی نکنید. بررسی باید در سرور انجام شود، نه فقط با پنهان کردن یک دکمه. فهرست امنیت برای اپ‌های ساخته‌شده با هوش مصنوعی عمیق‌تر به این موضوع می‌پردازد.
گام ۵: روی دستگاه واقعی آزمون کنید
اپ را روی یک گوشی واقعی باز کنید، نه فقط در یک پنجره باریک مرورگر.
- آیا می‌توانید بدون زوم هر دکمه را لمس کنید؟
- آیا صفحه‌کلید فیلدی را که تایپ می‌کنید می‌پوشاند؟
- آیا جدول‌ها و محتوای پهن اسکرول می‌شوند یا شکسته می‌شوند، به‌جای اینکه صفحه را به کنار هل دهند؟
- آیا متن بدون بزرگ‌نمایی خوانا است؟
اگر بتوانید، حداقل یک آیفون (Safari) و یک گوشی اندروید (Chrome) را امتحان کنید. به‌خصوص Safari رفتارهای خاص خودش را با تاریخ، ویدیو و عناصر با موقعیت ثابت دارد.
گام ۶: پول و ایمیل را از اول تا آخر آزمون کنید
هر چیزی که کارت را شارژ می‌کند یا ایمیل می‌فرستد به اجرای کامل نیاز دارد.
پرداخت‌ها. از حالت آزمایشی ارائه‌دهنده پرداخت و شماره کارت‌های آزمایشی آن استفاده کنید. یک پرداخت موفق، یک کارت ردشده و یک تسویه لغوشده را بررسی کنید. تأیید کنید سفارش یا اشتراک بعد از پرداخت در اپ شما نمایش داده می‌شود، نه فقط در داشبورد ارائه‌دهنده. اگر اپ شما به وب‌هوک‌ها (پیام‌هایی که ارائه‌دهنده پرداخت به سرور شما می‌فرستد) وابسته است، بررسی کنید روی اپ منتشرشده برسند، نه فقط در توسعه. سپس قبل از راه‌اندازی به کلیدهای زنده بروید و یک خرید واقعی کوچک انجام دهید و آن را بازپرداخت کنید.
ایمیل‌ها. با نشانی‌های واقعی نزد دو یا سه ارائه‌دهنده مختلف ثبت‌نام کنید. بررسی کنید ایمیل‌ها می‌رسند، در هرزنامه نیستند، و هر لینک داخل آنها به دامنه زنده اشاره می‌کند، نه نشانی پیش‌نمایش.
گام ۷: سرعت و خطاها را بررسی کنید
- ابزارهای توسعه‌دهنده مرورگر را باز کنید (راست‌کلیک ← Inspect) و تب Console را روی هر صفحه اصلی ببینید. خطاهای قرمز ارزش رفع دارند، حتی اگر چیزی خراب به نظر نرسد.
- سایت را روی گوشی با اینترنت موبایل بارگذاری کنید، نه Wi-Fi. اگر صفحه اول چند ثانیه طول می‌کشد، ابتدا اندازه تصاویر را بررسی کنید.
- یک ممیزی رایگان مثل Lighthouse را در ابزارهای توسعه‌دهنده کروم اجرا کنید تا یک نگاه سریع به عملکرد و دسترس‌پذیری داشته باشید.
گام ۸: اپ منتشرشده را آزمون کنید، نه فقط پیش‌نمایش را
پیش‌نمایش و اپ منتشرشده یک محیط نیستند. قبل از اینکه به کسی درباره راه‌اندازی بگویید، جریان‌های اصلی را روی نشانی زنده تکرار کنید:
- آیا همه متغیرهای محیطی و رازها برای اپ منتشرشده تنظیم شده‌اند؟
- آیا از پایگاه داده درست استفاده می‌کند، با داده‌ای که انتظارش را دارید؟
- آیا هدایت ورود و لینک‌های ایمیل از دامنه زنده استفاده می‌کنند؟
- آیا رفرش روی یک صفحه عمیق درست بارگذاری می‌شود؟
گام ۹: تماشا کنید کس دیگری آن را استفاده می‌کند
یک یا دو نفر را با یک هدف مواجه کنید («برای شنبه یک کلاس یوگا رزرو کن»)، نه دستورالعمل. تماشا کنید، کمک نکنید، و بنویسید کجا مکث می‌کنند. این سریع‌ترین راه برای پیدا کردن متن گیج‌کننده و دکمه‌های پنهان است. برای نسخه بزرگ‌تر این کار، چطور آزمون بتا اجرا کنیم را ببینید.
وقتی به باگی برخوردند، آن را درست یادداشت کنید: مراحل، نتیجه مورد انتظار و نتیجه واقعی. راهنمای ما درباره نوشتن گزارش باگ خوب قالب آن را نشان می‌دهد.
استفاده از هوش مصنوعی برای کمک به آزمون
اگر با هوش مصنوعی می‌سازید، می‌توانید از آن بخواهید در برنامه‌ریزی و اجرای آزمون کمک کند:
مسیرهای اصلی کاربر را در این اپ فهرست کن و برای هر کدام، حالت‌های مرزی که بیشترین احتمال خرابی دارند را بنویس: حالت‌های خالی، ورودی نامعتبر، دسترسی‌ها و رفرش. آن را در یک چک‌لیست بگذار که بتوانم یکی‌یکی انجامش دهم.
با دو کاربر آزمایشی مختلف وارد شو و بررسی کن آیا کاربر B می‌تواند چیزی را که کاربر A ساخته ببیند یا تغییر دهد، از جمله با باز کردن مستقیم نشانی رکوردهای A. قبل از رفع هر چیزی، آنچه پیدا کردی را گزارش کن.
گزارش آزمون خود هوش مصنوعی را به‌عنوان مرحله اول در نظر بگیرید. مسیرهای پول و دسترسی را همچنان خودتان کلیک کنید.
آزمون در Mythex
در Mythex، دستور /test آزمون اپ را اجرا می‌کند: عامل یک مرورگر را روی پیش‌نمایش زنده شما هدایت می‌کند، صفحه‌ها را کلیک می‌کند، تصویر می‌گیرد و جریان‌های خراب را در گفت‌وگو گزارش می‌دهد. بهترین نتیجه را وقتی دارد که یک مسیر مشخص را به آن بدهید، مثل «ثبت‌نام و رزرو یک کلاس را آزمون کن». آنچه پیدا می‌کند را با /fix یا یک پیام عادی رفع کنید، سپس /test را دوباره اجرا کنید. آزمون اپ از پیش‌نمایش استفاده می‌کند، پس بعد از انتشار خودتان مسیرهای اصلی را روی نشانی منتشرشده بررسی کنید. آزمون اپ را در مستندات ببینید، و راهنمای ما درباره اشکال‌زدایی اپ ساخته‌شده با هوش مصنوعی را برای زمانی که چیزی خراب می‌شود.
اشتباهات رایج
- فقط با خودتان آزمون کردن. حساب مدیر شما با داده زیاد، باگ‌های حالت خالی و دسترسی را پنهان می‌کند.
- فقط روی لپ‌تاپ آزمون کردن. بیشتر بازدیدکنندگان بسیاری از سایت‌ها با گوشی می‌آیند.
- رد شدن از حساب دوم. نشت داده بین کاربران جدی‌ترین باگی است که یک اپ می‌تواند با آن راه‌اندازی شود.
- اعتماد به پیش‌نمایش. اپ زنده تنظیمات متفاوتی دارد؛ آن را هم آزمون کنید.
- رفع باگ بدون آزمون دوباره بخش‌های نزدیک. اصلاح یک فرم می‌تواند فرم دیگری را که کد مشترک دارد خراب کند.
چک‌لیست قبل از راه‌اندازی
- مسیرهای اصلی فهرست و رتبه‌بندی شده‌اند
- هر مسیر به‌عنوان کاربر کاملاً تازه در پنجره خصوصی موفق است
- ورودی خالی، نامعتبر، بلند و تکراری مدیریت شده است
- رفرش روی هر صفحه کار می‌کند
- کاربران نمی‌توانند داده یکدیگر را ببینند یا تغییر دهند، حتی با نشانی
- صفحه‌های مدیریت برای کاربران عادی و بازدیدکنندگان خارج‌شده بسته است
- روی یک آیفون واقعی و یک گوشی اندروید کار می‌کند
- پرداخت‌ها آزمون شده‌اند: موفق، ردشده، لغوشده، و اپ بعد از آن به‌روز می‌شود
- ایمیل‌ها می‌رسند، به هرزنامه نمی‌روند، و به دامنه زنده وصل‌اند
- هیچ خطای قرمز در کنسول صفحه‌های اصلی نیست
- مسیرهای اصلی روی نشانی منتشرشده تکرار شده‌اند
- حداقل یک فرد بیرونی آن را امتحان کرده در حالی که شما تماشا می‌کردید
پرسش‌ها
یک اپ کوچک قبل از راه‌اندازی چقدر آزمون لازم دارد؟
به اندازه‌ای که مطمئن شوید مسیرهای اصلی برای یک کاربر کاملاً تازه، روی گوشی و لپ‌تاپ کار می‌کنند، کاربران نمی‌توانند داده یکدیگر را ببینند، و هر چیزی که به پول مربوط است از اول تا آخر کار می‌کند. برای بیشتر اپ‌های کوچک این چند ساعت تمرکز است، نه هفته‌ها.
برای یک MVP به آزمون خودکار نیاز دارم؟
لزوماً نه. آزمون دستی جریان‌های اصلی بیشتر باگ‌هایی را که مانع راه‌اندازی می‌شوند می‌گیرد. آزمون‌های خودکار وقتی ارزش پیدا می‌کنند که اپ را زیاد تغییر دهید و بخواهید سریع بدانید چیزی را که قبلاً کار می‌کرد خراب نکرده‌اید.
آزمون را روی پیش‌نمایش انجام دهم یا روی اپ زنده؟
هر دو. در پیش‌نمایش دقیق آزمون کنید، سپس بعد از انتشار جریان‌های اصلی را روی اپ منتشرشده تکرار کنید، چون متغیرهای محیطی جاافتاده، یک پایگاه داده متفاوت یا تنظیمات مسیریابی می‌توانند رفتار نسخه زنده را تغییر دهند.
غیر از خودم چه کسی باید اپم را آزمون کند؟
حداقل یک نفر که هرگز آن را ندیده باشد. به او هدف بدهید، نه دستورالعمل، و بدون کمک کردن تماشا کنید. سازنده‌ها ناخودآگاه از مسیرهایی که خراب می‌شوند دوری می‌کنند.