اظهارات افتتاحیه
ایوت نام (گوگل)
افتتاحیه سخنرانی
یورگن آلگایر (گوگل)
چالش Uber برای آزمایش بین برنامه‌ها/دستگاه‌های مختلف
اپل چاو (اوبر) و بیان جیانگ (اوبر)
به زودی پس از پیوستن به Uber در مارس 2015، هنگام بررسی ابزارهای تست UI برای برنامه های تلفن همراه خود، با یک چالش منحصر به فرد Uber مواجه شدیم. بسیاری از تست‌های سلامت عقل ما به برنامه سوار و برنامه راننده نیاز دارند که اقدامات خود را با یکدیگر در ارتباط/هماهنگی به منظور تکمیل سناریوی آزمایش انتها به انتها انجام دهند. در این گفتگو، ما راه حل پلتفرمی خود را به نام Octopus ارائه خواهیم داد و در مورد چگونگی هماهنگی ارتباط بین برنامه های مختلف در حال اجرا در دستگاه های مختلف بحث خواهیم کرد. این راه حل می تواند برای هر آزمایشی که نیاز به هماهنگی/ارتباط بین برنامه ها یا دستگاه های مختلف دارد (به عنوان مثال یک بازی چند کاربره، برنامه پیام رسانی/ارتباطات چند کاربره و غیره) استفاده شود.
اتوماسیون تست به کمک ربات
هانس کوسمانن (OptoFidelity) و ناتالیا لینونن (OptoFidelity)
OptoFidelity یک شرکت فنلاندی با فناوری پیشرفته با 10 سال تجربه در توسعه و ارائه راه حل های اتوماسیون تست تحقیق و توسعه است. این گفتگو شامل تجربیات و چشم انداز آینده ما از روش های تست غیر مزاحم مورد استفاده در تست عملکرد UI دستگاه تلفن همراه خواهد بود. آیا می دانستید که تیم سیستم عامل کروم از راه حل رباتی از OptoFidelity برای اندازه گیری تأخیر سرتاسر دستگاه های Android و ChromeOS استفاده می کند؟
شعبده بازی اره برقی برای سرگرمی و سود: درس های آموخته شده از تست یکپارچه سازی چند پلت فرم موبایل
دن جیووانلی (گوگل)
توسعه موبایل سخت است. ساخت زیرساخت تست سخت است. کار بر روی پلتفرم سخت است. این سه را با هم ترکیب کنید و دستور العملی برای فاجعه خواهید داشت. در این سخنرانی، Dan Giovannelli تجربیات خود را از کار بر روی یک پروژه زیرساخت تست موبایل بین پلتفرمی به اشتراک خواهد گذاشت. او درباره چیزهایی که درست پیش رفتند، چیزهایی که (خیلی) اشتباه پیش رفتند، و چیزهایی که اکنون آرزو دارد که در شروع کار بداند، بحث خواهد کرد. برای آگاهی از طراحی ابزارهای موبایل برای مهندسان غیر موبایل بیایید، بمانید تا متوجه شوید که Matrix چیست و چگونه می توان آن را در بازی خودش شکست داد.
تست اتوماسیون بازی موبایل با استفاده از دستگاه های واقعی
Jouko Kaasila (Bitbar/Testdroid)
بازی‌های موبایل بزرگترین دسته پول‌ساز در فروشگاه‌های اپلیکیشن امروزی هستند، بنابراین اطمینان حاصل می‌شود که هر نسخه از هر بازی روی دستگاه هر کاربر کار می‌کند، برای هر توسعه‌دهنده بازی اولویت بالایی دارد. علیرغم اهمیت تایید این موضوع، نمونه‌ها یا چارچوب‌های بسیار کمی برای تست خودکار بازی‌های موبایل وجود دارد، که توسعه‌دهندگان بازی را مجبور می‌کند به آزمایش دستی متوسل شوند که به اندازه‌ای نیست که شرکت‌های بازی نیاز به پوشش بازار جهانی خود داشته باشند. یکی از دلایل اصلی ماهیت منحصربه‌فرد بازی‌ها به‌عنوان برنامه‌های تلفن همراه است، زیرا آنها مستقیماً به صفحه‌نمایش دسترسی دارند و تمام سرویس‌های UI ارائه‌شده توسط سیستم‌عامل را دور می‌زنند و اکثر چارچوب‌های اتوماسیون آزمایشی را بی‌فایده می‌کنند، زیرا اشیاء سنتی در معرض دید قرار نمی‌گیرند.
خوشبختانه راه‌هایی برای استفاده از چارچوب‌های استاندارد اتوماسیون تست تلفن همراه وجود دارد تا با استفاده از برخی خلاقیت‌ها و کتابخانه‌های در دسترس عموم، اتوماسیون تست را روی دستگاه‌های موبایل واقعی برای بازی‌ها انجام دهیم. در ارائه خود، Jouko Kaasila از Testdroid سه رویکرد مختلف را با مثال های دنیای واقعی و چند نمونه کد مورد بحث قرار می دهد.
نحوه تست کامپوننت کوفته سوپ
تونی چانگ (گوگل)
افرادی که زمان زیادی را برای تثبیت تست های پوسته پوسته صرف کرده اند، موافق هستند که ما باید آزمایش ها را تجزیه کنیم. با این حال، برخی آن را دشوار می دانند و مطمئن نیستند که چگونه، برخی دیگر ممکن است توسط هم تیمی ها به چالش کشیده شوند که معتقدند برای تأیید همه سناریوها به تست E2E نیاز داریم. از آنجایی که گاهی اوقات درک این ایده در زمانی که شما عادت ندارید محصول خود را در اجزاء مشاهده کنید، دشوار است، من از یک مثال انتزاعی از کوفته سوپ استفاده خواهم کرد تا نشان دهم چگونه می توان آنچه را که به نظر می رسد یک قطعه جدا نشدنی از اجزاء است تجزیه کرد و آزمایش هایی را برای آن اعمال کرد. آنها
من شما را از طریق یک سفر سرگرم کننده برای ترجمه تست E2E به تست کامپوننت می برم که به شما در مورد محصول نهایی اطمینان می دهد. امیدواریم وقتی به محصول خود نگاه می کنید، این به شما دیدگاه تازه ای بدهد.
اتوماسیون تست Chromecast
برایان گوگان (گوگل)
اینترنت اشیا منجر به ازدیاد دستگاه های متصل شده است. اعتبارسنجی رفتار در میان دستگاه‌های مختلف در حال کار یک چالش آزمایشی مهم است. برای آزمایش Chromecast، چندین رویکرد در نظر گرفته شد. ما چارچوب‌های آزمایشی، زیرساخت‌های آزمایشگاهی و ابزارآزمایی را که برای تولید سیگنال‌های با کیفیت قابل اعتماد از محصول ایجاد کرده‌ایم، ترسیم می‌کنیم. ما چالش‌های آزمایش محصولی را که در محیط‌های شبکه‌ای پر سر و صدا عمل می‌کند، توضیح می‌دهیم. ما پیشنهاد می‌کنیم که ابزار تست برای دستگاه‌هایی مانند Chromecast در مراحل ابتدایی خود است و فرصت‌هایی را برای نوآوری در مهندسی تست نرم‌افزار ارائه می‌دهد.
استفاده از روبات برای تست برنامه اندروید
دکتر شوویک روی چوداری (گرجستان فناوری/Checkdroid)
ربات‌های نرم‌افزاری مانند Monkey را می‌توان برای آزمایش یک برنامه اندرویدی بدون تلاش دستی زیاد استفاده کرد. چندین ابزار از این دست در دانشگاه ها پیشنهاد شده است که هدف آنها تولید خودکار ورودی تست برای هدایت برنامه های اندروید است. در این گفتار، من مجموعه ای از ابزارهای تولید ورودی آزمون نماینده را معرفی می کنم و یک مطالعه تطبیقی برای برجسته کردن نقاط قوت و محدودیت های آنها ارائه می کنم. شما در مورد داخلی این ابزارها و نحوه استفاده از آنها برای آزمایش برنامه خود خواهید آموخت. جزئیات این مطالعه همراه با یک راه اندازی VM با ابزار در دسترس است: http://bear.cc.gatech.edu/~shauvik/androtest/
تست های شما پوسته پوسته نیست
آلیستر اسکات (اتوماتیک)
تست های پوسته پوسته مشکل هر مهندس تست خودکار است. همانطور که یک نفر (احتمالا آلیستر) یک بار گفت: "دیوانگی این است که آزمایش های مشابه را بارها و بارها انجام دهید و نتایج متفاوتی بگیرید". تست های پوسته پوسته هیچ پایانی برای ناامیدی ایجاد نمی کنند، اما شاید چیزی به نام تست پوسته پوسته یا بدون پوسته پوسته شدن وجود نداشته باشد، شاید لازم باشد این مشکل را از دریچه دیگری بررسی کنیم. ما باید زمان بیشتری را صرف ساختن سیستم‌های قطعی‌تر و قابل آزمایش‌تر کنیم تا زمان صرف ساختن تست‌های انعطاف‌پذیر و پایدار. Alister نمونه‌هایی از زمانی که پوسته پوسته شدن تست مشکلات واقعی را در زیر سیستم پنهان می‌کرد و اینکه چگونه می‌توان با ساختن سیستم‌های بهتر مشکل پوسته شدن تست را حل کرد، به اشتراک می‌گذارد.
تست بصری خودکار در مقیاس بزرگ
آدام کارمی (Applitools)
تست بصری خودکار یک روند اصلی در حال ظهور در جامعه توسعه دهنده / تست است. در این سخنرانی خواهید آموخت که تست بصری چیست و چرا باید خودکار باشد. ما به بررسی برخی از چالش‌های تکنولوژیکی مرتبط با اتوماسیون تست بصری خواهیم پرداخت و نشان خواهیم داد که چگونه ابزارهای مدرن به آنها رسیدگی می‌کنند. ما فناوری‌های پیشرفته‌ای را به نمایش می‌گذاریم که امکان اجرای آزمایش‌های بصری بین مرورگرها و بین دستگاه‌ها را فراهم می‌کنند و نکات کلیدی را برای موفقیت در آزمایش‌های بصری در مقیاس بزرگ ارائه می‌کنیم.
تست رگرسیون دست بردار
کارین لوندبرگ (تویتر) و پونیت خندوری (تویتر)
تیم شما به تازگی بازسازی اصلی یک سرویس را به پایان رسانده است و تمام تست های واحد و ادغام شما با موفقیت انجام می شود. کارت خوب بود! اما شما هنوز تمام نشده اید. اکنون باید بیشتر مطمئن شوید که چیزی را نشکنید و هیچ اشکالی در کمین وجود ندارد که هنوز گیر نکرده باشید. وقت آن است که دیفی را سر کار بگذاریم.
برخلاف ابزارهایی که از صحت کد شما اطمینان می‌دهند، مانند تست‌های واحد یا یکپارچه‌سازی، Diffy رفتار سرویس اصلاح‌شده شما را با ایستادن نمونه‌های سرویس جدید و سرویس قدیمی‌تان در کنار هم مقایسه می‌کند، درخواست‌های نمونه را برای هر کدام مسیریابی می‌کند، و پاسخ‌ها را با هم مقایسه می‌کند. و هرگونه رگرسیونی را که از آن مقایسه ها ظاهر شده است را ارائه می دهد.
همچنین، ما به تازگی این ابزار را منبع باز کرده ایم و به سرعت در حال تبدیل شدن به یکی از محبوب ترین ها در میان پروژه های منبع باز توییتر است.
تست دسترسی خودکار برای برنامه های اندروید
کیسی بورکهارت (گوگل)
این گفتگو مقتضیات دسترسی اصلی در پلتفرم اندروید را معرفی می کند و برخی از مشکلات رایج توسعه دهندگان مرتبط با دسترسی را نشان می دهد. در مورد چارچوب تست دسترس‌پذیری جدید اندروید و ادغام آن در چارچوب‌های تست اسپرسو و روبولکتریک خواهید آموخت. در نهایت، خواهید آموخت که چقدر آسان است که چک کردن خودکار دسترسی را به آزمایش‌های پروژه Android موجود خود اضافه کنید.
نمونه گیری داده های آماری
سلال زیفتچی (گوگل) و بن گرینبرگ (دانشجوی کارشناسی ارشد MIT)
استفاده از نمونه‌ای از داده‌های تولید در آزمایش‌ها، معمول است. مثالها عبارتند از:
- تست سلامت: نمونه ای از داده های تولید را به سیستم خود وارد کنید تا ببینید آیا چیزی شکست خورده است.
- تست A/B: یک تکه بزرگ از داده های تولید را بردارید، آن را در نسخه های فعلی و جدید سیستم خود اجرا کنید و خروجی ها را برای بازرسی متفاوت کنید.
برای به دست آوردن نمونه ای از داده های تولید، تیم ها معمولاً از راه حل های موردی استفاده می کنند، مانند:
- مشاهده دستی توزیع فیلدهای خاص (مثلاً فیلدهای عددی)،
- انتخاب یک نمونه کاملا تصادفی
با این حال، این رویکردها یک جنبه منفی جدی دارند: آنها می توانند رویدادهای نادر را از دست بدهند (به عنوان مثال موارد لبه)، که خطر ابتلا به اشکالات کشف نشده در تولید را افزایش می دهد. برای کاهش این خطر، تیم ها نمونه های بسیار بزرگی را انتخاب می کنند. با این حال، با چنین نمونه های بزرگ، معایب بیشتری نیز وجود دارد:
- رویدادهای نادر را هنوز می توان از دست داد،
- زمان اجرای تست ها به شدت افزایش می یابد،
- تفاوت ها برای انسان قابل درک نیست و تکرار زیادی وجود دارد.
در این گفتگو، ما یک تکنیک نمونه‌گیری داده‌های آماری جدید را برای انتخاب «هوشمندانه» یک نمونه «خوب» از داده‌های تولید پیشنهاد می‌کنیم که:
- تضمین می کند رویدادهای نادر را از دست ندهید،
- با حذف موارد تکراری، اندازه نمونه انتخابی را به حداقل می رساند.
تکنیک ما موارد نادر/مرز را می‌گیرد، اندازه نمونه را به حداقل می‌رساند، و به طور ضمنی بار دستی نگاه کردن به خروجی‌ها/تفاوت‌های آزمایش را بر روی توسعه‌دهندگان کاهش می‌دهد. همچنین از اجرای موازی (مثلاً MapReduce) پشتیبانی می‌کند تا بتوان مقادیر زیادی از داده‌ها را در یک بازه زمانی کوتاه برای انتخاب نمونه پردازش کرد.
Nest Automation Infrastructure
عثمان عبدالله (لانه)، جولیا گویدی (آشیانه) و سام گوردون (آشیانه)
چشم انداز Nest برای خانه متفکر شامل دستگاه های به هم پیوسته و هوشمندی است که با هم کار می کنند تا خانه شما را ایمن تر، انرژی کارآمدتر و آگاه تر کنند. این گفتگو بر روی زیرساخت های اتوماسیون و ابزارهای آزمایشی که برای کمک به تحقق این چشم انداز ساخته شده اند، تمرکز خواهد کرد. تیم‌های مختلفی در Nest روی سیستم‌های متقابل پلتفرم و دستگاه/ویژگی خاص برای آزمایش و تجزیه و تحلیل رگرسیون خودکار کار کرده‌اند. با استفاده از مثال‌های خاص از آزمایش محصول در دنیای واقعی، سخت‌افزار متقابل محصول را در زیرساخت‌های تست حلقه و ابزارهای تحلیل رگرسیون توان، همراه با مجموعه‌های ابزار خاص دوربین و تشخیص حرکت پوشش خواهیم داد.
مولدهای رویداد
روسی روسف (اسپلانک)
این گفتگو تجربیات ما در توسعه و استفاده از نرم افزارهای تولید کننده رویداد در Splunk را پوشش می دهد. با الهام از فیزیک ذرات، جایی که مولدهای رویداد در درک دنیای فیزیکی بدون اجرای ماشین‌های آزمایشی بزرگ ضروری بوده‌اند، ژنراتورهای ورود به سیستم روشی را که ما ادغام‌های متعدد خود را با نرم‌افزار شخص ثالث مدرن و قدیمی آزمایش می‌کنیم، بهبود بخشیده‌اند. بحث عملکردهای اساسی و چالش‌های ایجاد گزارش‌های واقعی را پوشش می‌دهد.
سنتز تست چند رشته ای
مورالی کریشنا راماناتان (موسسه علوم هند، بنگلور)
خطاهای همزمانی ظریف در کتابخانه های چند رشته ای که به دلیل همگام سازی نادرست یا ناکافی به وجود می آیند، اغلب با استفاده از تکنیک های ایستا به طور دقیق مشخص نمی شوند. از سوی دیگر، اثربخشی آشکارسازهای دینامیک به شدت به مجموعه‌های آزمایشی چند رشته‌ای وابسته است که اجرای آنها می‌تواند برای شناسایی و راه‌اندازی باگ‌های همزمانی از جمله مسابقه داده، بن‌بست و نقض اتمی مورد استفاده قرار گیرد. معمولاً، چنین آزمایش‌های چند رشته‌ای نیاز به فراخوانی ترکیب خاصی از روش‌ها با اشیاء درگیر در فراخوانی دارند که به طور مناسب به اشتراک گذاشته می‌شوند تا یک باگ آشکار شود. بدون دانش قبلی از اشکال، ساخت چنین تست هایی می تواند چالش برانگیز باشد.
در این گفتگو، من یک تکنیک سبک وزن و مقیاس پذیر برای سنتز آزمایشات برای تشخیص نقض ایمنی نخ ارائه خواهم کرد. با توجه به یک کتابخانه چند رشته ای و یک مجموعه تست متوالی، من یک تجزیه و تحلیل کاملاً خودکار را توصیف خواهم کرد که ردپای اجرای متوالی را بررسی می کند و به عنوان خروجی آن یک برنامه مشتری همزمان تولید می کند که اشیاء مشترک را از طریق روش کتابخانه ای به حالت هایی هدایت می کند که منجر به ایجاد یک اشکال همزمانی می شوند. . نتایج تجربی بر روی انواع کتابخانه های جاوا که به خوبی آزمایش شده اند، اثربخشی رویکرد ما را در آشکارسازی بسیاری از باگ های پیچیده نشان می دهد.
فعال کردن آزمایش‌های جریانی در نتفلیکس
مینال میشا (نتفلیکس)
تجربه پخش جریانی بیش از 69 میلیون کاربر برای نتفلیکس از اهمیت بالایی برخوردار است. به منظور بهبود سریع این، ما الگوریتم‌های جریان تطبیقی را به لایه جاوا اسکریپت منتقل کردیم. این یک چالش منحصر به فرد را برای انتشار مکرر نرم افزار جاوا اسکریپت مشتری ایجاد کرد که مستقیماً بر تجربه پخش جریانی مصرف کننده تأثیر گذاشت. با قرض گرفتن پارادایم تحویل مستمر، که به طور گسترده و با موفقیت برای برنامه‌های کاربردی سرویس پذیرفته شده است، از آن برای بازنشستگی ریسک در طول چرخه حیات ورود و ارائه به‌روزرسانی‌های مکرر استفاده کردیم. در این گفتگو ما یک جزء کلیدی از این پارادایم را برای فعال کردن به روز رسانی نرم افزار توضیح خواهیم داد. برای مقایسه دقیق وضعیت سلامت در برابر نسخه فعلی، به روند رونمایی از کلاینت جاوا اسکریپت و ابزارها می پردازیم. ما همچنین چالش های پیش روی این فرآیند را به اشتراک خواهیم گذاشت.
اینترنت را مسخره کنید
یابین کانگ (LinkedIn)
Mock the internet، صحبت در مورد یک سیستم تمسخر آمیز جدید در Linkedin که به تمسخر تمام ترافیک خروجی برای تست های یکپارچه سازی سطح سرویس کمک می کند، همچنین کمی در مورد مرور کلی استراتژی Linkedin Mocking صحبت خواهد کرد. دانش و آموخته های خود را با همه به اشتراک بگذارید.
تست موثر یک گیرنده ایستگاه مانیتورینگ GPS
اندرو نادت (لاکهید مارتین)
نگهداری ایستگاه‌های مانیتورینگ GPS موجود که توسط نیروی هوایی مورد استفاده قرار می‌گیرد دشوار شده‌اند و تلاش‌هایی برای جایگزینی آنها با رویکرد رادیویی تعریف‌شده نرم‌افزاری با شتاب GPU (SDR) در حال انجام است. مروری بر چالش های تست منحصر به فرد این گیرنده تخصصی GPS به همراه بررسی چندین رویکرد تست ارائه خواهد شد. در حالی که بر روی یک برنامه GPS متمرکز است، این رویکردهای آزمایشی می توانند به راحتی در سایر تلاش های SDR در سطح تولید اعمال شوند.
اتوماسیون در دستگاه های پوشیدنی
آنوراگ روتروی (اینتل)
از آنجایی که فناوری پوشیدنی در استفاده شخصی و تجاری در حال افزایش است، همه شرکت‌هایی که فضای مناسبی در بازار اندروید دارند، تمرکز خود را بر روی این فناوری آینده معطوف کرده‌اند. بنابراین برنامه های خود را با پشتیبانی پوشیدنی ایجاد می کنند، که تلاش برای آزمایش برنامه آنها بر روی دستگاه های پوشیدنی را نیز افزایش می دهد. از این رو اتوماسیون بر روی پوشیدنی ها برای کاهش تلاش تست و افزایش کارایی مهم می شود.
تست یکپارچه سازی Infra و CI (Docker/Vagrant)
ماکسیم گونیس (سوپرسونیک)
توسعه دهندگان هر روز برای داشتن یک محیط توسعه محلی کار آماده در هنگام توسعه، اشکال زدایی و گذراندن چرخه یکپارچه سازی مداوم تلاش می کنند. ما می توانیم آن را با ادغام docker و vagrant برای استفاده با ابزار CI حل کنیم. این ترکیب اجازه می دهد تا برنامه ها را در سطح پشته در ماشین های توسعه کنترل کنید، در حالی که می توانید از همان پشته در تست های یکپارچه سازی استفاده کنید. در این گفتگو به بحث خواهیم پرداخت:
- استفاده از داکر در تست های یکپارچه سازی CI
- کنترل پشته به جای تک داکر یا برنامه.
- کنترل نسخه محیط های توسعه و آزمایش، به راحتی با ابزار git و docker توزیع می شود.
- پشتیبانی یکپارچه برای اجرای Dockers در مک و ویندوز.
حذف بیت های تست بی فایده
پاتریک لام (دانشگاه واترلو)
تکنیک های تخصصی آنالیز استاتیک برای مجموعه های آزمایشی نتایج جالبی به همراه داشته است. قبلاً آموخته‌ایم که اکثر تست‌ها کدهای ساده و مستقیم هستند، یعنی دنباله‌ای از دستورات راه‌اندازی و به دنبال آن یک بار متشکل از ادعاها. ما نشان می‌دهیم که چگونه تجزیه و تحلیل استاتیک می‌تواند عبارات راه‌اندازی بی‌فایده را شناسایی کند، و توسعه‌دهندگان را قادر می‌سازد تا موارد آزمایشی خود را ساده و سرعت بخشند.
پوشش ارتباط قوی با اثربخشی مجموعه آزمایشی ندارد
لورا اینوزمتسوا (دانشگاه واترلو)
پوشش یک مجموعه آزمایشی اغلب به عنوان یک پروکسی برای توانایی آن در تشخیص عیوب استفاده می شود. با این حال، مطالعات قبلی که همبستگی بین پوشش کد و اثربخشی مجموعه آزمایشی را بررسی کرده‌اند، نتوانسته‌اند در مورد ماهیت و قدرت رابطه بین این ویژگی‌های مجموعه آزمایشی به توافق برسند. علاوه بر این، بسیاری از مطالعات با برنامه‌های کوچک یا مصنوعی انجام شده‌اند، که مشخص نیست آیا نتایج آنها به برنامه‌های بزرگ‌تر تعمیم می‌یابد یا خیر، و برخی از مطالعات تأثیر مخدوش‌کننده اندازه مجموعه آزمایشی را در نظر نمی‌گیرند. ما این مطالعات را با ارزیابی رابطه بین اندازه مجموعه آزمایشی، پوشش و اثربخشی برای برنامه‌های جاوا واقعی گسترش داده‌ایم. مطالعه ما بزرگترین مطالعه تا به امروز در ادبیات است. ما پوشش بیانیه، پوشش تصمیم‌گیری، و پوشش شرایط اصلاح شده این مجموعه‌ها را اندازه‌گیری کردیم و از آزمایش جهش برای ارزیابی اثربخشی تشخیص عیب آنها استفاده کردیم. ما دریافتیم که زمانی که تعداد موارد آزمایش در مجموعه کنترل می شود، بین پوشش و اثربخشی همبستگی کم تا متوسط وجود دارد. علاوه بر این، متوجه شدیم که اشکال قوی‌تر پوشش، بینش بیشتری در مورد اثربخشی مجموعه ارائه نمی‌کند.
Backend های جعلی با RpcReplay
مت گرت (گوگل)
سریع و پایدار نگه داشتن تست ها بسیار مهم است. وقتی سرورها به پشتیبان‌های زیادی وابسته هستند، این کار سخت است. توسعه‌دهندگان باید بین آزمایش‌های طولانی و شلوغ یا نوشتن و حفظ پیاده‌سازی‌های جعلی یکی را انتخاب کنند. درعوض، تست ها را می توان با استفاده از ترافیک ثبت شده از این backend ها اجرا کرد. این بهترین هر دو جهان را فراهم می کند و به توسعه دهندگان اجازه می دهد تا به سرعت در برابر باطن های واقعی آزمایش کنند.
آزمایشگاه اتوماسیون تست ChromeOS
سیمران باسی (گوگل) و کریس سوسا (گوگل)
ChromeOS در حال حاضر بیش از 60 دستگاه Chromebook/box مختلف را ارسال می‌کند که هر کدام از نرم‌افزار خود استفاده می‌کنند. در میدان، مشتریان هر 6 هفته یک بار یک سیستم جدید دریافت می کنند. این کار بدون بررسی سیستم یکپارچه سازی مستمر قوی از سوی بیش از 200 توسعه دهنده ما امکان پذیر نخواهد بود. در این گفتگو، ما معماری کلی را با تاکید خاص بر آزمایشگاه اتوماسیون تست خود توضیح می دهیم. علاوه بر این، ما در مورد Moblab (مخفف آزمایشگاه موبایل (تست)) بحث می کنیم، که کل زیرساخت اتوماسیون تست ما از یک کروم باکس اجرا می شود. این سیستم توسط بسیاری از شرکای ما استفاده می شود تا آنها نیز بتوانند آزمایشات را به روش ما اجرا کنند.
اظهارات افتتاحیه
ایوت نام (گوگل)
افتتاحیه سخنرانی
یورگن آلگایر (گوگل)
چالش Uber برای آزمایش بین برنامه‌ها/دستگاه‌های مختلف
اپل چاو (اوبر) و بیان جیانگ (اوبر)
به زودی پس از پیوستن به Uber در مارس 2015، هنگام بررسی ابزارهای تست UI برای برنامه های تلفن همراه خود، با یک چالش منحصر به فرد Uber مواجه شدیم. بسیاری از تست‌های سلامت عقل ما به برنامه سوار و برنامه راننده نیاز دارند که اقدامات خود را با یکدیگر در ارتباط/هماهنگی به منظور تکمیل سناریوی آزمایش انتها به انتها انجام دهند. در این گفتگو، ما راه حل پلتفرمی خود را به نام Octopus ارائه خواهیم داد و در مورد چگونگی هماهنگی ارتباط بین برنامه های مختلف در حال اجرا در دستگاه های مختلف بحث خواهیم کرد. این راه حل می تواند برای هر آزمایشی که نیاز به هماهنگی/ارتباط بین برنامه ها یا دستگاه های مختلف دارد (به عنوان مثال یک بازی چند کاربره، برنامه پیام رسانی/ارتباطات چند کاربره و غیره) استفاده شود.
اتوماسیون تست به کمک ربات
هانس کوسمانن (OptoFidelity) و ناتالیا لینونن (OptoFidelity)
OptoFidelity یک شرکت فنلاندی با فناوری پیشرفته با 10 سال تجربه در توسعه و ارائه راه حل های اتوماسیون تست تحقیق و توسعه است. این گفتگو شامل تجربیات و چشم انداز آینده ما از روش های تست غیر مزاحم مورد استفاده در تست عملکرد UI دستگاه تلفن همراه خواهد بود. آیا می دانستید که تیم سیستم عامل کروم از راه حل رباتی از OptoFidelity برای اندازه گیری تأخیر سرتاسر دستگاه های Android و ChromeOS استفاده می کند؟
شعبده بازی اره برقی برای سرگرمی و سود: درس های آموخته شده از تست یکپارچه سازی چند پلت فرم موبایل
دن جیووانلی (گوگل)
توسعه موبایل سخت است. ساخت زیرساخت تست سخت است. کار بر روی پلتفرم سخت است. این سه را با هم ترکیب کنید و دستور العملی برای فاجعه خواهید داشت. در این سخنرانی، Dan Giovannelli تجربیات خود را از کار بر روی یک پروژه زیرساخت تست موبایل بین پلتفرمی به اشتراک خواهد گذاشت. او درباره چیزهایی که درست پیش رفتند، چیزهایی که (خیلی) اشتباه پیش رفتند، و چیزهایی که اکنون آرزو دارد که در شروع کار بداند، بحث خواهد کرد. برای آگاهی از طراحی ابزارهای موبایل برای مهندسان غیر موبایل بیایید، بمانید تا متوجه شوید که Matrix چیست و چگونه می توان آن را در بازی خودش شکست داد.
تست اتوماسیون بازی موبایل با استفاده از دستگاه های واقعی
Jouko Kaasila (Bitbar/Testdroid)
بازی‌های موبایل بزرگترین دسته پول‌ساز در فروشگاه‌های اپلیکیشن امروزی هستند، بنابراین اطمینان حاصل می‌شود که هر نسخه از هر بازی روی دستگاه هر کاربر کار می‌کند، برای هر توسعه‌دهنده بازی اولویت بالایی دارد. علیرغم اهمیت تایید این موضوع، نمونه‌ها یا چارچوب‌های بسیار کمی برای تست خودکار بازی‌های موبایل وجود دارد، که توسعه‌دهندگان بازی را مجبور می‌کند به آزمایش دستی متوسل شوند که به اندازه‌ای نیست که شرکت‌های بازی نیاز به پوشش بازار جهانی خود داشته باشند. یکی از دلایل اصلی ماهیت منحصربه‌فرد بازی‌ها به‌عنوان برنامه‌های تلفن همراه است، زیرا آنها مستقیماً به صفحه‌نمایش دسترسی دارند و تمام سرویس‌های UI ارائه‌شده توسط سیستم‌عامل را دور می‌زنند و اکثر چارچوب‌های اتوماسیون آزمایشی را بی‌فایده می‌کنند، زیرا اشیاء سنتی در معرض دید قرار نمی‌گیرند.
خوشبختانه راه‌هایی برای استفاده از چارچوب‌های استاندارد اتوماسیون تست تلفن همراه وجود دارد تا با استفاده از برخی خلاقیت‌ها و کتابخانه‌های در دسترس عموم، اتوماسیون تست را روی دستگاه‌های موبایل واقعی برای بازی‌ها انجام دهیم. در ارائه خود، Jouko Kaasila از Testdroid سه رویکرد مختلف را با مثال های دنیای واقعی و چند نمونه کد مورد بحث قرار می دهد.
نحوه تست کامپوننت کوفته سوپ
تونی چانگ (گوگل)
افرادی که زمان زیادی را برای تثبیت تست های پوسته پوسته صرف کرده اند، موافق هستند که ما باید آزمایش ها را تجزیه کنیم. با این حال، برخی آن را دشوار می دانند و مطمئن نیستند که چگونه، برخی دیگر ممکن است توسط هم تیمی ها به چالش کشیده شوند که معتقدند برای تأیید همه سناریوها به تست E2E نیاز داریم. از آنجایی که گاهی اوقات درک این ایده در زمانی که شما عادت ندارید محصول خود را در اجزاء مشاهده کنید، دشوار است، من از یک مثال انتزاعی از کوفته سوپ استفاده خواهم کرد تا نشان دهم چگونه می توان آنچه را که به نظر می رسد یک قطعه جدا نشدنی از اجزاء است تجزیه کرد و آزمایش هایی را برای آن اعمال کرد. آنها
من شما را از طریق یک سفر سرگرم کننده برای ترجمه تست E2E به تست کامپوننت می برم که به شما در مورد محصول نهایی اطمینان می دهد. امیدواریم وقتی به محصول خود نگاه می کنید، این به شما دیدگاه تازه ای بدهد.
اتوماسیون تست Chromecast
برایان گوگان (گوگل)
اینترنت اشیا منجر به ازدیاد دستگاه های متصل شده است. اعتبارسنجی رفتار در میان دستگاه‌های مختلف در حال کار یک چالش آزمایشی مهم است. برای آزمایش Chromecast، چندین رویکرد در نظر گرفته شد. ما چارچوب‌های آزمایشی، زیرساخت‌های آزمایشگاهی و ابزارآزمایی را که برای تولید سیگنال‌های با کیفیت قابل اعتماد از محصول ایجاد کرده‌ایم، ترسیم می‌کنیم. ما چالش‌های آزمایش محصولی را که در محیط‌های شبکه‌ای پر سر و صدا عمل می‌کند، توضیح می‌دهیم. ما پیشنهاد می‌کنیم که ابزار تست برای دستگاه‌هایی مانند Chromecast در مراحل ابتدایی خود است و فرصت‌هایی را برای نوآوری در مهندسی تست نرم‌افزار ارائه می‌دهد.
استفاده از روبات برای تست برنامه اندروید
دکتر شوویک روی چوداری (گرجستان فناوری/Checkdroid)
ربات‌های نرم‌افزاری مانند Monkey را می‌توان برای آزمایش یک برنامه اندرویدی بدون تلاش دستی زیاد استفاده کرد. چندین ابزار از این دست در دانشگاه ها پیشنهاد شده است که هدف آنها تولید خودکار ورودی تست برای هدایت برنامه های اندروید است. در این گفتار، من مجموعه ای از ابزارهای تولید ورودی آزمون نماینده را معرفی می کنم و یک مطالعه تطبیقی برای برجسته کردن نقاط قوت و محدودیت های آنها ارائه می کنم. شما در مورد داخلی این ابزارها و نحوه استفاده از آنها برای آزمایش برنامه خود خواهید آموخت. جزئیات این مطالعه همراه با یک راه اندازی VM با ابزار در دسترس است: http://bear.cc.gatech.edu/~shauvik/androtest/
تست های شما پوسته پوسته نیست
آلیستر اسکات (اتوماتیک)
تست های پوسته پوسته مشکل هر مهندس تست خودکار است. همانطور که یک نفر (احتمالا آلیستر) یک بار گفت: "دیوانگی این است که آزمایش های مشابه را بارها و بارها انجام دهید و نتایج متفاوتی بگیرید". تست های پوسته پوسته هیچ پایانی برای ناامیدی ایجاد نمی کنند، اما شاید چیزی به نام تست پوسته پوسته یا بدون پوسته پوسته شدن وجود نداشته باشد، شاید لازم باشد این مشکل را از دریچه دیگری بررسی کنیم. ما باید زمان بیشتری را صرف ساختن سیستم‌های قطعی‌تر و قابل آزمایش‌تر کنیم تا زمان صرف ساختن تست‌های انعطاف‌پذیر و پایدار. Alister نمونه‌هایی از زمانی که پوسته پوسته شدن تست مشکلات واقعی را در زیر سیستم پنهان می‌کرد و اینکه چگونه می‌توان با ساختن سیستم‌های بهتر مشکل پوسته شدن تست را حل کرد، به اشتراک می‌گذارد.
تست بصری خودکار در مقیاس بزرگ
آدام کارمی (Applitools)
تست بصری خودکار یک روند اصلی در حال ظهور در جامعه توسعه دهنده / تست است. در این سخنرانی خواهید آموخت که تست بصری چیست و چرا باید خودکار باشد. ما به بررسی برخی از چالش‌های تکنولوژیکی مرتبط با اتوماسیون تست بصری خواهیم پرداخت و نشان خواهیم داد که چگونه ابزارهای مدرن به آنها رسیدگی می‌کنند. ما فناوری‌های پیشرفته‌ای را به نمایش می‌گذاریم که امکان اجرای آزمایش‌های بصری بین مرورگرها و بین دستگاه‌ها را فراهم می‌کنند و نکات کلیدی را برای موفقیت در آزمایش‌های بصری در مقیاس بزرگ ارائه می‌کنیم.
تست رگرسیون دست بردار
کارین لوندبرگ (تویتر) و پونیت خندوری (تویتر)
تیم شما به تازگی بازسازی اصلی یک سرویس را به پایان رسانده است و تمام تست های واحد و ادغام شما با موفقیت انجام می شود. کارت خوب بود! اما شما هنوز تمام نشده اید. اکنون باید بیشتر مطمئن شوید که چیزی را نشکنید و هیچ اشکالی در کمین وجود ندارد که هنوز گیر نکرده باشید. وقت آن است که دیفی را سر کار بگذاریم.
برخلاف ابزارهایی که از صحت کد شما اطمینان می‌دهند، مانند تست‌های واحد یا یکپارچه‌سازی، Diffy رفتار سرویس اصلاح‌شده شما را با ایستادن نمونه‌های سرویس جدید و سرویس قدیمی‌تان در کنار هم مقایسه می‌کند، درخواست‌های نمونه را برای هر کدام مسیریابی می‌کند، و پاسخ‌ها را با هم مقایسه می‌کند. و هرگونه رگرسیونی را که از آن مقایسه ها ظاهر شده است را ارائه می دهد.
همچنین، ما به تازگی این ابزار را منبع باز کرده ایم و به سرعت در حال تبدیل شدن به یکی از محبوب ترین ها در میان پروژه های منبع باز توییتر است.
تست دسترسی خودکار برای برنامه های اندروید
کیسی بورکهارت (گوگل)
این گفتگو مقتضیات دسترسی اصلی در پلتفرم اندروید را معرفی می کند و برخی از مشکلات رایج توسعه دهندگان مرتبط با دسترسی را نشان می دهد. در مورد چارچوب تست دسترس‌پذیری جدید اندروید و ادغام آن در چارچوب‌های تست اسپرسو و روبولکتریک خواهید آموخت. در نهایت، خواهید آموخت که چقدر آسان است که چک کردن خودکار دسترسی را به آزمایش‌های پروژه Android موجود خود اضافه کنید.
نمونه گیری داده های آماری
سلال زیفتچی (گوگل) و بن گرینبرگ (دانشجوی کارشناسی ارشد MIT)
استفاده از نمونه‌ای از داده‌های تولید در آزمایش‌ها، معمول است. مثالها عبارتند از:
- تست سلامت: نمونه ای از داده های تولید را به سیستم خود وارد کنید تا ببینید آیا چیزی شکست خورده است.
- تست A/B: یک تکه بزرگ از داده های تولید را بردارید، آن را در نسخه های فعلی و جدید سیستم خود اجرا کنید و خروجی ها را برای بازرسی متفاوت کنید.
برای به دست آوردن نمونه ای از داده های تولید، تیم ها معمولاً از راه حل های موردی استفاده می کنند، مانند:
- مشاهده دستی توزیع فیلدهای خاص (مثلاً فیلدهای عددی)،
- انتخاب یک نمونه کاملا تصادفی
با این حال، این رویکردها یک جنبه منفی جدی دارند: آنها می توانند رویدادهای نادر را از دست بدهند (به عنوان مثال موارد لبه)، که خطر ابتلا به اشکالات کشف نشده در تولید را افزایش می دهد. برای کاهش این خطر، تیم ها نمونه های بسیار بزرگی را انتخاب می کنند. با این حال، با چنین نمونه های بزرگ، معایب بیشتری نیز وجود دارد:
- رویدادهای نادر را هنوز می توان از دست داد،
- زمان اجرای تست ها به شدت افزایش می یابد،
- تفاوت ها برای انسان قابل درک نیست و تکرار زیادی وجود دارد.
در این گفتگو، ما یک تکنیک نمونه‌گیری داده‌های آماری جدید را برای انتخاب «هوشمندانه» یک نمونه «خوب» از داده‌های تولید پیشنهاد می‌کنیم که:
- تضمین می کند رویدادهای نادر را از دست ندهید،
- با حذف موارد تکراری، اندازه نمونه انتخابی را به حداقل می رساند.
تکنیک ما موارد نادر/مرز را می‌گیرد، اندازه نمونه را به حداقل می‌رساند، و به طور ضمنی بار دستی نگاه کردن به خروجی‌ها/تفاوت‌های آزمایش را بر روی توسعه‌دهندگان کاهش می‌دهد. همچنین از اجرای موازی (مثلاً MapReduce) پشتیبانی می‌کند تا بتوان مقادیر زیادی از داده‌ها را در یک بازه زمانی کوتاه برای انتخاب نمونه پردازش کرد.
Nest Automation Infrastructure
عثمان عبدالله (لانه)، جولیا گویدی (آشیانه) و سام گوردون (آشیانه)
چشم انداز Nest برای خانه متفکر شامل دستگاه های به هم پیوسته و هوشمندی است که با هم کار می کنند تا خانه شما را ایمن تر، انرژی کارآمدتر و آگاه تر کنند. این گفتگو بر روی زیرساخت های اتوماسیون و ابزارهای آزمایشی که برای کمک به تحقق این چشم انداز ساخته شده اند، تمرکز خواهد کرد. تیم‌های مختلفی در Nest روی سیستم‌های متقابل پلتفرم و دستگاه/ویژگی خاص برای آزمایش و تجزیه و تحلیل رگرسیون خودکار کار کرده‌اند. با استفاده از مثال‌های خاص از آزمایش محصول در دنیای واقعی، سخت‌افزار متقابل محصول را در زیرساخت‌های تست حلقه و ابزارهای تحلیل رگرسیون توان، همراه با مجموعه‌های ابزار خاص دوربین و تشخیص حرکت پوشش خواهیم داد.
مولدهای رویداد
روسی روسف (اسپلانک)
این گفتگو تجربیات ما در توسعه و استفاده از نرم افزارهای تولید کننده رویداد در Splunk را پوشش می دهد. با الهام از فیزیک ذرات، جایی که مولدهای رویداد در درک دنیای فیزیکی بدون اجرای ماشین‌های آزمایشی بزرگ ضروری بوده‌اند، ژنراتورهای ورود به سیستم روشی را که ما ادغام‌های متعدد خود را با نرم‌افزار شخص ثالث مدرن و قدیمی آزمایش می‌کنیم، بهبود بخشیده‌اند. بحث عملکردهای اساسی و چالش‌های ایجاد گزارش‌های واقعی را پوشش می‌دهد.
سنتز تست چند رشته ای
مورالی کریشنا راماناتان (موسسه علوم هند، بنگلور)
خطاهای همزمانی ظریف در کتابخانه های چند رشته ای که به دلیل همگام سازی نادرست یا ناکافی به وجود می آیند، اغلب با استفاده از تکنیک های ایستا به طور دقیق مشخص نمی شوند. از سوی دیگر، اثربخشی آشکارسازهای دینامیک به شدت به مجموعه‌های آزمایشی چند رشته‌ای وابسته است که اجرای آنها می‌تواند برای شناسایی و راه‌اندازی باگ‌های همزمانی از جمله مسابقه داده، بن‌بست و نقض اتمی مورد استفاده قرار گیرد. معمولاً، چنین آزمایش‌های چند رشته‌ای نیاز به فراخوانی ترکیب خاصی از روش‌ها با اشیاء درگیر در فراخوانی دارند که به طور مناسب به اشتراک گذاشته می‌شوند تا یک باگ آشکار شود. بدون دانش قبلی از اشکال، ساخت چنین تست هایی می تواند چالش برانگیز باشد.
در این گفتگو، من یک تکنیک سبک وزن و مقیاس پذیر برای سنتز آزمایشات برای تشخیص نقض ایمنی نخ ارائه خواهم کرد. با توجه به یک کتابخانه چند رشته ای و یک مجموعه تست متوالی، من یک تجزیه و تحلیل کاملاً خودکار را توصیف خواهم کرد که ردپای اجرای متوالی را بررسی می کند و به عنوان خروجی آن یک برنامه مشتری همزمان تولید می کند که اشیاء مشترک را از طریق روش کتابخانه ای به حالت هایی هدایت می کند که منجر به ایجاد یک اشکال همزمانی می شوند. . نتایج تجربی بر روی انواع کتابخانه های جاوا که به خوبی آزمایش شده اند، اثربخشی رویکرد ما را در آشکارسازی بسیاری از باگ های پیچیده نشان می دهد.
فعال کردن آزمایش‌های جریانی در نتفلیکس
مینال میشا (نتفلیکس)
69+ million user's streaming experience is of paramount importance to Netflix. In order to swiftly improve this, we moved the adaptive streaming algorithms into the Javascript layer. This posed a unique challenge of frequently releasing client javascript software which directly impacted consumer's streaming experience. Borrowing the continuous delivery paradigm, which has been widely and successfully adopted for service applications, we used it to retire risk over the lifecycle of a checkin and deliver updates frequently. In this talk we will describe a key component of this paradigm to enable software updates. We will dive into rollout procedure of the javascript client and tools to accurately compare the health against the current version. We will also share the challenges faced with this process.
Mock the Internet
Yabin Kang (LinkedIn)
Mock the internet, talking about a new mocking system in Linkedin that helps to mock all the outbound traffic for service level integration tests, will also talk a little bit about the overview of Linkedin Mocking strategy. Share the knowledge and what we learnt with everyone.
Effective Testing of a GPS Monitoring Station Receiver
Andrew Knodt (Lockheed Martin)
The existing GPS monitoring stations used by the Air Force have become difficult to maintain and an effort is underway to replace them with a GPU accelerated Software Defined Radio (SDR) approach. An overview of the unique testing challenges of this specialized GPS receiver along with an examination of several testing approaches will be presented. While focused on a GPS application, these testing approaches could easily be applied to other production level SDR efforts.
Automation on Wearable Devices
Anurag Routroy (Intel)
As wearable technology is on the rise in personal and business use, all the companies which have a solid space in the Android market have switched their focus on this upcoming technology. Thus creating their apps with wearable support, which also increases the effort to test their app on the wearable devices. Hence automation on the wearables becomes important to reduce testing effort and increase efficiency.
Unified Infra and CI Integration Testing (Docker/Vagrant)
Maxim Guenis (Supersonic)
Developers struggle every day to have a working local development environment ready when developing, debugging and going through the continues integration cycle.We can to solve that by integrating docker and vagrant to be used with CI tool. This combination allows to control applications at stack level on development machines, while able to use the same stack in integration tests. In this talk we will discuss:
- Use of Docker in CI integration tests
- Control of stack instead of single docker or app.
- Version control of development and test environments, easily ddistributed with git and docker tools.
- Seamless support for running Dockers on Mac and windows.
Eliminating Useless Test Bits
Patrick Lam (University of Waterloo)
Specializing static analysis techniques for test suites has yielded interesting results. We've previously learned that most tests are simple straight-line code, namely a sequence of setup statements followed by a payload consisting of asserts. We show how static analysis can identify useless setup statements, enabling developers to simplify and speed up their test cases.
Coverage is Not Strongly Correlated with Test Suite Effectiveness
Laura Inozemtseva (University of Waterloo)
The coverage of a test suite is often used as a proxy for its ability to detect faults. However, previous studies that investigated the correlation between code coverage and test suite effectiveness have failed to reach a consensus about the nature and strength of the relationship between these test suite characteristics. Moreover, many of the studies were done with small or synthetic programs, making it unclear whether their results generalize to larger programs, and some of the studies did not account for the confounding influence of test suite size. We have extended these studies by evaluating the relationship between test suite size, coverage, and effectiveness for realistic Java programs; our study is the largest to date in the literature. We measured the statement coverage, decision coverage, and modified condition coverage of these suites and used mutation testing to evaluate their fault detection effectiveness. We found that there is a low to moderate correlation between coverage and effectiveness when the number of test cases in the suite is controlled for. In addition, we found that stronger forms of coverage do not provide greater insight into the effectiveness the suite.
Fake Backends with RpcReplay
Matt Garrett (Google)
Keeping tests fast and stable is critically important. This is hard when servers depend on many backends. Developers must choose between long and flaky tests, or writing and maintaining fake implementations. Instead, tests can be run using recorded traffic from these backends. This provides the best of both worlds, allowing developers to test quickly against real backends.
ChromeOS Test Automation Lab
Simran Basi (Google) and Chris Sosa (Google)
ChromeOS is currently shipping 60+ different Chromebook/boxes each running their own software. On the field, customers are getting a fresh system every 6 weeks. This would not be possible without a robust Continuous Integration System vetting check-ins from our 200+ developers. In this talk, we describe the overall architecture with specific emphasis on our test automation lab. In addition, we discuss Moblab (short for mobile (test) lab), our entire test automation infrastructure running from one chromebox. This system is used by many of our partners so that they too can run tests the way we do.