اظهارات افتتاحیه
مت لوری (گوگل)
سیر تکاملی بهره وری تجاری و مهندسی
ماناسی جوشی (گوگل)
در این سخنرانی اصلی، ما سعی می‌کنیم همه را به سفری ببریم که چگونه نظم و انضباط بهره‌وری مهندسی در Google تکامل یافته است و چگونه برای رشد کسب‌وکار Google برای حرکت سریع، پایدار ماندن و ایجاد اعتماد به نفس زیادی از طریق فرآیندهای توسعه/انتشار/نظارت مؤثر بوده و هست. ما همچنین به برخی از چالش‌های امروزی و افق‌های جدید برای آزمایش پلتفرم متقابل در یک تجربه محصول بسیار متصل/عمودی که Google در حال گذراندن آن هستیم اشاره می‌کنیم.
خودکار کردن رانندگی با ربات از راه دور
تانیا جنکینز (کنتیلور مشاور)
آزمایش رابط رانندگی یک دستگاه حضور از راه دور چالش برانگیز است. در دنیای واقعی عمل می کند، با افراد و اشیاء تعامل دارد، اما باید در یک محیط کنترل شده آزمایش شود. چگونه با ایجاد یک محیط رانندگی از راه دور واقع گرایانه مقابله می کنید در حالی که به طور همزمان مکان و موقعیت دستگاه را تأیید می کنید در حالی که نمی توانید آن را ببینید؟ من یک راه حل نوآورانه ارائه خواهم کرد.
در کیف پول شما چیست؟
هیما ماندلی (پایتخت یک)
Capital One یکی از بزرگترین شرکت های کارت اعتباری در ایالات متحده با بیش از 70 میلیون حساب است. در Capital one، ما در حال ساخت بسیاری از محصولات جالب هستیم که تجربیات دیجیتالی شگفت انگیزی را برای مشتریان خود فراهم می کند. با تبدیل شدن دستگاه های تلفن همراه به کانال ترجیحی برای مشتریان ما، این گفتگو بر روی چگونگی حل مشکل اتوماسیون آزمایشی برای برنامه های وب تلفن همراه متمرکز خواهد شد و برای رسیدن به خط لوله تحویل نرم افزار سریعتر چه کردیم. ما همچنین ابزارهای منبع باز که استفاده کردیم و داشبورد منبع باز که برای حل مشکلات خود ساخته ایم را به اشتراک خواهیم گذاشت.
استفاده از آمار اتوماسیون آزمایشی برای پیش‌بینی اینکه کدام آزمایش باید اجرا شود
بوریس پریخودکی (تکنولوژی های یونیتی)
تست‌ها به بخشی حیاتی از فرآیندهای توسعه اپلیکیشن تبدیل شده‌اند، اما وقتی یک ناجی به یک گلوگاه در زندگی روزمره تبدیل می‌شود، چه باید کرد. در اینجا ما تجربه خود را در مورد کاری که انجام دادیم در زمانی که 3 تا 6 ساعت زمان انتظار برای اجرای یک پیکربندی آزمایشی داشتیم به اشتراک می‌گذاریم. رویکرد ساده اما در عین حال قدرتمند در این سخنرانی ارائه شده است که باعث صرفه جویی در زمان گرانبها در اجرای آزمایش های همیشه سبز در مزرعه ساخت و آزمایش می شود. راه های احتمالی برای بهبود فرآیند نیز پوشش داده شده است.
اتوماسیون تست مبتنی بر سلنیوم برای ویندوز و ویندوزفون
نیکولای آبالوف (2gis)
سلنیوم برای تست اتوماسیون برنامه های کاربردی وب وجود دارد. Appium برای برنامه های موبایل در iOS و Android وجود دارد. اما برای Windows Desktop و Windows Phone/Mobile باید راه حل مبتنی بر سلنیوم خودمان را ارائه می کردیم. بنابراین Winium ایجاد شد. Winium یک راه حل منبع باز برای تست اتوماسیون ویندوز دسکتاپ و برنامه های Windows Phone/Mobile است. Winium مبتنی بر سلنیوم است، بنابراین اگر قبلاً سلنیوم یا اپیوم را می شناسید، شروع استفاده از آن برای نیازهای اتوماسیون شما نسبتاً آسان است، می توان آن را در زیرساخت سلنیوم موجود خود ادغام کرد. در بحث من پروژه هایی را ارائه خواهم کرد که Winium را می سازند و Winium.Desktop و Winium.Mobile را در عمل نشان می دهند.
سمت عجیب‌تر تست‌ها
برایان ونپی (گوگل)
همه اشکالات یکسان ایجاد نمی شوند. گاهی اوقات ابهامات در زبان های برنامه نویسی که ما استفاده می کنیم مقصر هستند، و یافتن آنها اغلب حتی بهترین برنامه نویسان و آزمایش کنندگان را نیز دچار مشکل کرده است. به ما بپیوندید تا با نشان دادن نمونه‌های دست‌چین شده از بسیاری از زبان‌هایی که روزمره استفاده می‌کنیم، نگاهی سرگرم‌کننده به جنبه‌های عجیب‌تر آزمایش بیاندازیم. در نهایت، ما شما را به چالش می‌کشیم که سعی کنید و حدس بزنید، زیرا یک سری مثال‌های عجیب و غریب را که در زبان‌هایی مانند C، Java، Objective-C، PHP، و مورد علاقه همه - جاوا اسکریپت - یافت می‌شوند، ارائه می‌کنیم.
الگوریتم ML برای تنظیم محیط تست موبایل
Rajkumar Bhojan (فناوری های Wipro)
با پیشرفت سریع فناوری محاسبات تلفن همراه، تقاضای قابل توجهی برای آزمایش برنامه های تلفن همراه در دستگاه های تلفن همراه وجود دارد. مدیریت دستگاه تلفن همراه نقشی حیاتی در تست اپلیکیشن موبایل ایفا می‌کند و درک چالش‌های موجود در مدیریت دستگاه تلفن همراه به اندازه حل آنها مهم است. برای جلوگیری از مشکلات خاص دستگاه، توسعه دهندگان اتوماسیون آزمایشی باید برنامه های خود را بر روی تعداد زیادی دستگاه آزمایش کنند، که پرهزینه و ناکارآمد است. در این گفتگو، ما نشان می‌دهیم که چگونه الگوریتم یادگیری ماشینی می‌تواند مجموعه درستی از دستگاه‌ها را برای راه‌اندازی محیط تست موبایل شناسایی کند.
"آیا صدای من را می شنوی؟" - تست کیفیت صوتی زنده
الکساندر براکمن و دن هیسلوپ (سیتریکس)
IATF: یک چارچوب آزمایشی خودکار بین پلتفرمی و چند دستگاهی API
یانبین ژانگ (اینتل)
برای سهولت پذیرش فناوری WebRTC و در دسترس قرار دادن آن به طور گسترده برای گسترش یا ایجاد برنامه های کاربردی جدید، اینتل راه حل پایان به انتها WebRTC، Intel® Collaboration Suite برای WebRTC را توسعه داده است. در حال حاضر، اینتل در حال حاضر یک اکوسیستم رو به رشد Intel® Collaboration Suite برای WebRTC در سراسر جهان ایجاد کرده است. همکاری حوزه‌های مختلفی را پوشش می‌دهد، از جمله آموزش، پزشکی، ابر صنعت، پخش آنلاین رسانه‌های اجتماعی، کنفرانس ویدیویی و ابزارهای پوشیدنی و غیره. رشد سریع تعداد پلتفرمهای پشتیبانی‌شده برای APIهای SDK باعث می‌شود سازگاری پلتفرمهای متقابل و تلاش‌های آزمایش یکپارچه‌سازی به طور انفجاری افزایش یابد. نحوه آزمایش خودکار قابلیت همکاری بین آن SDK های مختلف در پلتفرم های مختلف به یک مشکل بزرگ تبدیل می شود. در این گفتار، چارچوب تست بین پلتفرمی و چند دستگاهی API تست Framework-IATF خود را ارائه خواهیم داد. می‌توان آن را برای هر آزمایش SDK بین پلتفرمی و چند دستگاهی که نیاز به ارتباط بین پلتفرمهای مختلف دارد، استفاده کرد.
استفاده از تحلیل مفهومی رسمی در تست نرم افزار
فدور استروک (Yandex/NRU HSE)
تجزیه و تحلیل مفهوم رسمی جعبه ابزاری را برای ساختن هستی شناسی رسمی بر روی مجموعه ای از اشیاء با توضیحات (که به صورت مجموعه ای از ویژگی ها بیان می شود) در اختیار ما قرار می دهد. این شاخه از تئوری جبری در سال 1984 معرفی شد و اکنون برای طیف گسترده ای از وظایف داده کاوی استفاده می شود. این گفتگو بر روی تکنیک‌هایی متمرکز است که می‌تواند به‌ویژه برای تست نرم‌افزار ارزشمند باشد: استفاده از هستی‌شناسی رسمی برای گزارش‌های تست راحت و برای استخراج موارد آزمایشی نیمه خودکار.
چگونه تست های پوسته پوسته در یکپارچگی مداوم: تمرین فعلی در گوگل و مسیرهای آینده
جان میکو (گوگل)
وعاطف ممون (دانشگاه مریلند، کالج پارک)
Google مجموعه عظیمی از آزمایش‌ها را دارد که ما به طور مداوم در سیستم یکپارچه‌سازی پیوسته عظیم خود اجرا می‌کنیم. با نگاهی به این داده ها، متوجه می شویم که آزمایش های پوسته پوسته باعث ایجاد زباله های زیادی در چندین بعد مختلف می شوند. ما برای بهبود توانایی خود در درک تأثیر، شناسایی و کاهش سطح ذاتی پوسته پوسته شدن که در سیستم خود می بینیم، کار می کنیم.
تجربه توسعه دهنده، FTW!
نیرانجان تولپول (گوگل)
Docker Based Geo Dispersed Test Farm - تمرین زیرساخت آزمایشی در برنامه اندروید اینتل
جری یو (اینتل) و گوبینگ چن (اینتل)
OpenHTF - چارچوب تست سخت افزار منبع باز
جو اتیر (گوگل) و جان هاولی (گوگل)
نسل آزمایش هدایت شده برای تشخیص ناکارآمدی حلقه
مونیکا دوک (موسسه علوم هند)
پیمایش اضافی از حلقه ها به عنوان منبع اشکالات عملکرد در بسیاری از کتابخانه های جاوا شناسایی شده است. این منجر به طراحی تکنیک های تحلیل استاتیک و پویا برای شناسایی خودکار این اشکالات عملکرد شده است. با این حال، در حالی که اثربخشی تحلیل‌های دینامیکی به تست‌های ورودی تحلیل‌شده وابسته است، تحلیل‌های ایستا در تأیید خودکار وجود این مشکلات، اعتبارسنجی اصلاح‌ها و اجتناب از رگرسیون در نسخه‌های آینده کمتر مؤثر هستند. ما یک رویکرد جدید برای تولید تست‌ها به صورت خودکار برای تشخیص ناکارآمدی حلقه در کتابخانه‌های جاوا پیشنهاد می‌کنیم. این گفتار مروری کوتاه بر این اثر دارد.
Need for Speed - تسریع تست های اتوماسیون از 3 ساعت تا 3 دقیقه
امانویل اسلاوف (Comfo Inc)
همه تست‌های خودکار سطح بالا برای محیط‌های سریع و سریع امروزی کند هستند. این همان فیل در اتاق است که همه نادیده می گیرند. و برای یک دلیل خوب. دستیابی به تست های خودکار سریع، قابل اعتماد و مفید کار سختی است. با این حال، شما چاره‌ای ندارید – با تست‌های خودکار آهسته، فقط سریعتر موارد مزخرف را به مشتریان خود ارسال می‌کنید. در کامفو، هر شب بیش از 3 ساعت تست داشتیم. زمان اعدام بدون محدودیت در حال افزایش بود. تست ها به عنوان یک حلقه بازخورد ناپایدار و غیرقابل استفاده می شدند. در یک نقطه آزمایش ها بیش از 20 روز متوالی با شکست مواجه شدند. اشکالات رگرسیون در تولید ظاهر شدند. تصمیم گرفتیم جلوی این جنون را بگیریم و بعد از تلاش و فداکاری قابل توجه، فعلا همین تست ها کمتر از 3 دقیقه اجرا می شود. این داستان بهبود مستمر از چگونگی دستیابی ما به آزمایشات 60 برابر سریعتر است.
پوشش کد یک پیش بینی کننده قوی برای اثربخشی مجموعه آزمایشی در دنیای واقعی است
راهول گوپینات (دانشگاه ایالتی اورگان)
ClusterRunner: تست بازخورد سریع را از طریق مقیاس بندی افقی آسان می کند
Taejun Lee (Box Inc) و Joseph Harrington (Box Inc)
Box حدود سی ساعت تست واحد و یکپارچه سازی در هر commit اجرا می شود. ما آنها را موازی می کنیم تا در کمتر از 17 دقیقه با استفاده از پلت فرم توزیع آزمایشی منبع باز خود، ClusterRunner اجرا شوند. چرا باکس این همه تست دارد؟ ClusterRunner چگونه کار می کند؟ آیا تنظیم ClusterRunner برای تست های خود آسان است؟ (Spoiler: بله.) ClusterRunner با موازی کردن تست ها روی یک میزبان و توزیع در بسیاری از هاست ها، بازخورد آزمایشی بسیار سریع و دیوانه کننده ای را به شما می دهد. که توسط تیم مهندسی بهره‌وری Box توسعه داده شده است، ما از ClusterRunner به صورت داخلی برای اجرای مجموعه‌ای از بیش از 30 ساعت خطی آزمایش در 17 دقیقه استفاده می‌کنیم و این کار را هر روز صدها بار انجام می‌دهیم. ClusterRunner منبع باز و زبان شناس است، بنابراین می توانید به راحتی از آن برای پروژه خود استفاده کنید. ما ClusterRunner را برای تیم‌های مهندسی ایجاد کردیم که با تأخیرهای طولانی بازخورد آزمایشی یا کدهای تست نشده مشکل دارند. ما آن را از پایین به بالا طراحی کردیم تا استفاده آسانی داشته باشد و بتواند با سیستم CI موجود شما یکپارچه شود. می آموزد که تست های شما چقدر طول می کشد تا اجرا شوند، و اجرای آتی را بر این اساس برنامه ریزی می کند تا بازخورد را در سریع ترین زمان ممکن ارائه دهد. اجزای آن از طریق یک REST API دوستانه ارتباط برقرار می کنند که آن را هم در دسترس و هم قابل توسعه می کند.
تست یکپارچه سازی با چندین دستگاه تلفن همراه و خدمات
الکساندر دورخین (گوگل) و آنگ لی (گوگل)
Mobly یک چارچوب متن باز و توسعه یافته توسط Google برای آزمایش محصولاتی است که نیاز به تعامل بین چندین دستگاه مانند برنامه های اجتماعی دارد. یا تست هایی که نیاز به کنترل محیط تست دارند، مانند اتصال Wi-Fi. در مورد تفاوت تست چند دستگاهی با آزمایش تک دستگاهی و مشکلات منحصر به فرد آن، مانند همگام سازی و جریان کد بین چندین دستگاه، و نحوه حل آنها توسط Mobly بحث خواهیم کرد.
مقیاس در مقابل ارزش: تست اتوماسیون در بی بی سی
جیتش گوسای (بی بی سی) و دیوید باکهورست (بی بی سی)
ما یک ابر دستگاه منبع باز داخلی برای آزمایش مقیاس برنامه های تلفن همراه و تلویزیون خود ساختیم، اما خیلی سریع به هیولایی تبدیل شد که ما را مجبور کرد در رویکرد خود به اتوماسیون تجدید نظر کنیم و تعادل صحیح بین مقیاس و ارزش را پیدا کنیم. بیاموزید که چگونه چالش‌های آزمایش روی دستگاه را با اتوماسیون متمرکز و مالکیت مشترک حل کردیم. همچنین بیاموزید که چگونه ابر دستگاه داخلی خود را بسازید و از ابزارهای منبع باز ما استفاده کنید.
یافتن اشکالات در کتابخانه های ++C با استفاده از LibFuzzer
Kostya Serebryany (گوگل)
چگونه آزمایش خرابی سرور را یاد گرفتم
جاناتان آبراهامز (MongoDB)
بیایید یاد بگیرید که چگونه استحکام سرور MongoDB را برای زنده ماندن در سناریوهای مختلف خرابی سیستم آزمایش کردیم. بیاموزید که چگونه توانستیم یک سرور با هر نوع سیستم عامل و پیکربندی میزبان (فیزیکی یا مجازی) را خودکار کنیم.