اظهارات افتتاحیه
سونال شاه (گوگل)
افتتاحیه سخنرانی - سریع حرکت کنید و چیزها را خراب نکنید
آنکیت مهتا (گوگل)
اتوماسیون برای یک وب بهتر
جیمز گراهام (موزیلا)
وب محبوب‌ترین پلتفرم برنامه‌های کاربردی در جهان است، با این حال، عملکرد ضعیف مرورگر عاملی است که باعث ناراحتی و ناامیدی توسعه‌دهندگان وب می‌شود. به منظور تلاش برای بهبود این وضعیت، W3C تلاش های جامعه را برای تولید یک مجموعه آزمایشی به طور مداوم به روز شده، متقابل مرورگر، برای وب باز تسهیل کرده است. تست های پلت فرم وب در این گفتگو، جیمز تست‌های پلتفرم وب را معرفی می‌کند و ابزارهایی را که برای خودکارسازی تست‌ها در طیف وسیعی از مرورگرهای دسکتاپ و در دستگاه‌های تلفن همراهی که سیستم عامل فایرفاکس دارند، ایجاد کرده‌ایم، توضیح می‌دهد. او نشان خواهد داد که چگونه این نرم‌افزار برای مقابله با چالش‌های اجرای یک مجموعه آزمایشی با منبع خارجی، که اغلب به‌روزرسانی می‌شود، روی صدها تعهد در روز در سیستم یکپارچه‌سازی مداوم موزیلا طراحی شده است.
کروم را به بهترین مرورگر موبایل تبدیل کنید
کارین لوندبرگ (گوگل)
یکی از دلایل موفقیت کروم، اصول اصلی سرعت، پایداری، سادگی و امنیت (4 S) بوده است. وقتی کروم را برای اندروید و iOS منتشر کردیم، نه تنها 4 S را روی خود مرورگر اعمال کردیم، بلکه در مورد نحوه انجام تست خودکار و نوع آزمایش‌هایی که اجرا می‌کنیم نیز استفاده کردیم:
- سرعت برای تست عملکرد و تست های سریع است.
- پایداری برای تست پایداری و تست های پایدار است.
- Simplicity برای آزمایش اینکه Chrome تجربه کاربری ساده ای دارد و برای ساده کردن آن برای افزودن و اجرای آزمایشات است.
- امنیت برای تست امنیتی است.
زبان اتوماسیون تست برای مدل های رفتاری
نان لی (راه حل های مدیتا)
آزمایشگران مبتنی بر مدل، تست های انتزاعی را بر حسب مدل هایی مانند مسیرها در نمودارها طراحی می کنند. سپس تست های انتزاعی باید به تست های انضمامی تبدیل شوند که از نظر اجرا تعریف می شوند. تبدیل از آزمون های انتزاعی به آزمایش های عینی باید خودکار باشد. تکنیک‌های آزمایش مبتنی بر مدل موجود برای مدل‌های رفتاری از نمودارهای اضافی زیادی مانند نمودارهای کلاس و از نمودارهای موردی برای تبدیل و تولید آزمایش استفاده می‌کنند. استفاده از آنها در عمل بسیار پیچیده است زیرا آزمایش کنندگان باید تمام نمودارهای مرتبط را همیشه ثابت کنند، حتی زمانی که الزامات اغلب تغییر می کنند.
این سخنرانی یک زبان اتوماسیون تست را معرفی می‌کند تا به آزمایش‌کنندگان اجازه می‌دهد تنها با استفاده از یک مدل رفتاری مانند نمودار ماشین حالت، آزمایش‌هایی تولید کنند. سه موضوع مورد بررسی قرار خواهد گرفت: (1) ایجاد نقشه‌برداری از مدل‌ها به کد آزمایشی اجرایی و تولید مقادیر آزمایش، (2) تبدیل نمودارها و استفاده از معیارهای پوشش برای تولید مسیرهای آزمایش، و (3) حل محدودیت‌ها و تولید آزمایش‌های بتن.
پوشش تست در گوگل
آندری چیریلا (گوگل)
آیا تا به حال فکر کرده اید که آزمایش در گوگل چگونه به نظر می رسد؟ از چه ابزارهایی برای کمک به ما استفاده می کنیم و چگونه پوشش آزمون را اندازه گیری و عمل می کنیم؟ ما به طور خلاصه روند توسعه را در Google شرح می دهیم، سپس بر استفاده از اندازه گیری پوشش کد و نحوه استفاده از پوشش کد برای بهبود کیفیت کد و بهره وری مهندسی تمرکز می کنیم. در پایان، ما حجم وسیعی از داده‌های پوشش را ارائه می‌کنیم که بیش از 100000 تعهد را در بر می‌گیرد، که جمع‌آوری کرده‌ایم و به برخی از نتایج کاربردی‌تر که به آن رسیده‌ایم.
CATJS: برنامه هایی که خود را آزمایش می کنند
ران اسنیر (HP) و لیور روون (HP)
در سال‌های گذشته ما شاهد ناهنجاری‌های بسیاری بوده‌ایم که طرز تفکر ما را در مورد دنیای محاسبات تغییر داده است. چاپگرهای سه بعدی هستند که چاپگرهای سه بعدی را چاپ می کنند، روبات هایی که خودشان فکر می کنند و سپس ما catj داریم.
catjs یک چارچوب متن باز است که این قابلیت را برای اپلیکیشن‌های وب موبایل برای آزمایش خود اضافه می‌کند. حاشیه نویسی های ساده در کد HTML5 شما به اسکریپت های آزمایشی تعبیه شده در چرخه عمر برنامه ترجمه می شود. این تست های وب موبایلی می توانند بر روی هر دستگاه، سیستم عامل و مرورگری اجرا شوند. catjs یک راه سریع و آسان برای مراقبت از جریان تست برنامه شما است.
یکپارچه سازی پیوسته مقیاس پذیر - با استفاده از منبع باز
Vishal Arora (Dropbox)
بسیاری از ابزارهای منبع باز برای یکپارچه سازی مداوم (CI) در دسترس هستند. فقط تعداد کمی در مقیاس بزرگ به خوبی عمل می کنند. و تقریباً هیچ کدام برای مقیاس در یک محیط توزیع ساخته نشده اند. بیایید چالش‌های پیاده‌سازی CI در مقیاس را بیابید و یکی از راه‌های کنار هم قرار دادن قطعات منبع باز برای ایجاد سریع سیستم CI توزیع‌شده و مقیاس‌پذیر خود را بیابید.
من اغلب تست نمی‌کنم... اما وقتی انجام می‌دهم، در تولید تست می‌کنم
گرت بولز (نتفلیکس)
هر روز، نتفلیکس مشتریان بیشتری دارد که محتوای بیشتری را در تعداد فزاینده ای از دستگاه های مشتری مصرف می کنند. ما همچنین به طور مداوم در حال نوآوری برای بهبود تجربه مشتریان خود هستیم. آزمایش در چنین محیطی که به سرعت در حال تغییر است یک چالش بزرگ است و ما به این نتیجه رسیده ایم که اجرای آزمایش ها در محیط تولید ما اغلب می تواند کارآمدترین راه برای تأیید این تغییرات باشد. این گفتگو سه روش آزمایشی را که در تولید استفاده می‌کنیم شامل می‌شود: شبیه‌سازی انواع خاموشی‌ها با ارتش سیمیان، جستجوی رگرسیون با استفاده از قناری‌ها، و اندازه‌گیری اثربخشی آزمون با تحلیل پوشش کد از تولید.
اهمیت تست خودکار روی دستگاه های موبایل واقعی و مجازی
جی سرینیواسان (گوگل) و مانیش لاچوانی (گوگل)
در مقایسه با دنیای وب، تست موبایل یک میدان مین است. از دستگاه‌ها، سیستم‌عامل‌ها، شبکه‌ها و مکان‌های مختلف، به نظر می‌رسد تعداد نامتناهی متغیری وجود دارد که توسعه‌دهندگان باید در نظر بگیرند. در این جلسه آموزشی به برخی از چالش های منحصر به فرد ناشی از بهینه سازی عملکرد و کیفیت اپلیکیشن های موبایل و راهکارهایی برای رفع آن ها از جمله نیاز به اتوماسیون، دستگاه های واقعی و شرایط واقعی کاربر می پردازیم.
تست های رایگان بهتر از موز رایگان هستند: استفاده از داده کاوی و یادگیری ماشینی برای خودکارسازی نظارت بر تولید در زمان واقعی
Celal Ziftci (Google)
علاقه فزاینده ای به استفاده از تکنیک های داده کاوی و یادگیری ماشین در تحلیل، نگهداری و آزمایش سیستم های نرم افزاری وجود دارد. در این گفتگو، Celal در مورد چگونگی استفاده از چنین تکنیک‌هایی برای استخراج خودکار متغیرهای سیستم، استفاده از آنها در نظارت بر سیستم‌های خود در زمان واقعی و هشدار مهندسان از هرگونه مشکل احتمالی تولید در عرض چند دقیقه بحث خواهد کرد.
این گفتگو شامل دو ابزار است که ما در داخل از آنها استفاده می کنیم، و اینکه چگونه آنها را ترکیب می کنیم تا نظارت بر تولید در زمان واقعی را تقریباً به صورت رایگان برای مهندسان ارائه دهیم:
- ابزاری که می تواند متغیرهای سیستم را استخراج کند.
- ابزاری که سیستم های تولید را نظارت می کند و از اولین ابزار برای تولید خودکار بخشی از منطقی که برای شناسایی مشکلات احتمالی در زمان واقعی استفاده می کند استفاده می کند.
تست اتوماسیون روی ست تاپ باکس مادون قرمز
اولیویه اتین (نارنجی)
این سخنرانی توضیح می‌دهد که زمینه برنامه تلویزیون چیست و با چه مشکلاتی می‌توانیم هنگام تلاش برای خودکارسازی چیزها با آن مواجه شویم. اولیویه شکست های قبلی، رویکرد آنها و نکات کلیدی برای ساخت یک ابزار تست خودکار را پشت سر خواهد گذاشت. اگر زمان اجازه دهد، او در جزئیات اجرا عمیق تر خواهد شد.
بیایید گوش کنید که چگونه چند لحیم کاری و چند خط کد دنیای غنی آزمایش وب را به یک جعبه تنظیم باز کرده است.
چالش مقایسه عادلانه ارائه دهندگان ابر و آنچه ما در مورد آن انجام می دهیم
آنتونی وولم (گوگل)
این گفتگو به تاریخچه بنچمارک از مین فریم تا ابر خواهد پرداخت. هدف این است که پایه ای در مورد جایی که معیارها شروع شده اند و چگونه به جایی که هستند، گذاشته اند. ایده هایی برای آینده محک زدن Cloud و نحوه انجام عملی آن ارائه خواهد شد.
هرگز انسانی را برای انجام کار ماشینی نفرستید: چگونه فیس بوک از ربات ها برای مدیریت تست ها استفاده می کند
روی ویلیامز (فیسبوک)
فیس بوک یک سازمان آزمایشی ندارد، توسعه دهندگان همه چیز را از نوشتن کدشان گرفته تا تست کردن آن تا تولید آن را در اختیار دارند. این به این معنی نیست که ما تست نمی کنیم! روشی که ما این مقیاس را ساخته‌ایم از طریق خودکار کردن چرخه عمر آزمایش‌ها برای بالا نگه داشتن سیگنال و پایین نگه داشتن نویز بوده است. آزمایش های جدید غیرقابل اعتماد تلقی می شوند و پوسته پوسته شدن به سرعت از درخت خارج می شود. ما در مورد اینکه چه چیزی برای ایجاد اعتماد در تست‌ها موثر بوده و چه چیزی جواب نداده است صحبت خواهیم کرد.
اسپرسو، قاشق، وایرماک، اوه من! (یا چگونه یاد گرفتم که نگران نباشم و عاشق تست اندروید باشم)
مایکل بیلی (امریکن اکسپرس)
درباره ایجاد و اجرای تست‌های سریع و قابل اعتماد خودکار رابط کاربری Android بیاموزید. ابزارها شامل اسپرسو، قاشق، وایرموک و جنکینز خواهند بود. دانش پایه توسعه اندروید و جاوا فرض شده است.
Google BigQuery Analytics
برایان ونس (گوگل)
BigQuery سرویس کلان داده تعاملی Google Cloud است. کاربران می توانند ترابایت داده را در چند ثانیه از طریق پرس و جوهای SQL مانند تجزیه و تحلیل کنند. این بر روی Dremel ساخته شده است، که آزمایش کنندگان Google سال ها از آن به صورت داخلی استفاده می کردند. ما چند نمونه را مرور خواهیم کرد و به شما نشان خواهیم داد که چگونه می توانید با BigQuery شروع به کار کنید.
سلندروید - سلنیوم برای اندروید
دومینیک دری (ادوبی)
Selendroid یک چارچوب اتوماسیون تست منبع باز است که رابط کاربری برنامه های بومی و ترکیبی اندروید و وب تلفن همراه را حذف می کند. تست ها با استفاده از API مشتری سلنیوم 2 نوشته می شوند. برای آزمایش، هیچ تغییری در برنامه تحت آزمایش به منظور خودکارسازی آن لازم نیست.
این ارائه به مخاطب نشان می دهد که چقدر آسان است که اتوماسیون تست موبایل انجام شود. این نشان می دهد که چگونه می توان از Selendroid برای آزمایش برنامه های اندرویدی بومی و ترکیبی استفاده کرد و چگونه می توان از Selenium Grid برای آزمایش موازی در چندین دستگاه استفاده کرد. موضوعات پیشرفته مانند گسترش خود Selendroid در زمان اجرا و انجام تست های متقابل پلت فرم نیز پوشش داده خواهد شد.
حفظ سلامت در دنیای ابررسانه ای
آمیت ایسو (Comcast)
همانطور که Comcast از یک شرکت کابلی به یک رهبر رسانه و فناوری تبدیل شده است، تیم های مهندسی نیز هوشمندتر شده اند. هنگامی که Amit در سال 2006 به Comcast Interactive Media (CIM) پیوست، آنها یک فروشگاه تست دستی بودند. پس از اینکه آنها اولین وب سایت خود را در سال 2007 ارسال کردند، او شروع به ایجاد نمونه های اولیه برای یک زیرساخت خودکار تست UI کرد. او در GTAC 2008 با سلنیوم معرفی شد و سپس به Comcast بازگشت تا یک زیرساخت تست خودکار با Selenium Grid، Hudson و Subversion بسازد. امروز، او هر روز هفته روی تست API با استقرار در Production کار می کند. این کار با Python، Git، Gerrit و Anthill امکان پذیر شده است.
با MSL زودتر و سریعتر از بین برید!
برایان رابینز (FINRA) و دانیل کو (FINRA)
ارائه سریعتر نرم افزار بدون به خطر انداختن کیفیت کار بی اهمیتی نیست. همه ما می خواهیم با توسعه آزمایشات زودهنگام و اجرای سریعتر تست ها، با حداقل ردپای تعمیر و نگهداری، با سرعت حرکت کنیم. در FINRA، ما MSL (تلفظ «موشک») را توسعه دادیم تا تیم‌های Agile را با بهره‌گیری از معماری‌های لایه‌ای مانند MVC قادر می‌سازیم تا کد UI خود را زودتر و سریعتر در انزوا آزمایش کنند.
MSL از تست یکپارچه سازی کدهای UI (مانند جاوا اسکریپت، HTML، CSS) با استقرار محلی روی سرور Node.js و پیکربندی پاسخ های HTTP ساختگی از کد آزمایشی با استفاده از یکی از مشتریان ما (جاوا، جاوا اسکریپت یا Node.js) پشتیبانی می کند. این گفتگو با چند مثال ویژگی های کلیدی MSL را معرفی می کند.
آزمایش تجربه کاربر
الکس ایگل (گوگل)
محصولات گوگل به طور مکرر منتشر می شوند، و این نیاز به آزمایش خودکار و «سازگاری» دارد. ما اکنون در تلاش هستیم تا زیرساخت آزمایشی خود را به عنوان بخشی از Google Cloud Platform ارائه دهیم. این سخنرانی برخی از روش‌هایی را که برای سبز نگه‌داشتن ساختمان‌هایمان و محصولاتمان بدون نقص استفاده می‌کنیم، مورد بحث قرار می‌دهد و پیش‌نمایشی از نحوه نمایش این موضوع در جهان ارائه می‌دهد.
گفتگوی میز گرد 1 - تست کراس پلتفرم موبایل
بحث میز گرد 2 - پوشش اتوماسیون اسناد
تاثیر ساختار جامعه بر عملکرد حل کننده SAT
زک نیوشام (دانشگاه واترلو)
حل کننده های مدرن CDCL SAT به طور معمول نمونه های صنعتی بسیار بزرگ SAT را در دوره های زمانی نسبتاً کوتاه حل می کنند. واضح است که این حل کننده ها به نوعی از ساختار نمونه های دنیای واقعی سوء استفاده می کنند. با این حال، تا به امروز نتایج کمی وجود داشته است که دقیقاً این ساختار را مشخص کند. در این مقاله، ما شواهدی ارائه می‌دهیم که ساختار جامعه نمونه‌های SAT دنیای واقعی با زمان اجرای حل‌کننده‌های CDCL SAT مرتبط است. مدتی است که مشخص شده است که نمونه های SAT در دنیای واقعی که به عنوان نمودار در نظر گرفته می شوند، دارای جوامع طبیعی هستند. یک جامعه یک زیرگراف از نمودار یک نمونه SAT است، به طوری که این نمودار فرعی دارای لبه های داخلی بیشتری نسبت به خروجی به بقیه نمودار است. ساختار جامعه یک نمودار اغلب با یک معیار کیفیت به نام Q مشخص می شود. به طور شهودی، یک نمودار با ساختار جامعه با کیفیت بالا (Q بالا) به راحتی در جوامع کوچکتر قابل تفکیک است، در حالی که گراف با Q پایین اینطور نیست. ما سه نتیجه بر اساس داده‌های تجربی ارائه می‌کنیم که نشان می‌دهد ساختار جامعه نمونه‌های صنعتی دنیای واقعی، پیش‌بینی‌کننده بهتری برای زمان اجرای حل‌کننده‌های CDCL نسبت به سایر عوامل معمول در نظر گرفته شده مانند متغیرها و بندها است. اول، نشان می‌دهیم که یک همبستگی قوی بین مقدار Q و معیار فاصله بلوک لغوی کیفیت عبارات تضاد مورد استفاده در سیاست‌های حذف بند در حل‌کننده‌های گلوکز مانند وجود دارد. دوم، با استفاده از تحلیل رگرسیون، نشان می‌دهیم که تعداد جوامع و مقدار Q نمودار نمونه‌های SAT در دنیای واقعی بیشتر از معیارهای سنتی مانند تعداد متغیرها یا بندها، زمان اجرای حل‌کننده‌های CDCL را پیش‌بینی می‌کنند. در نهایت، نشان می‌دهیم که نمونه‌های SAT تولید شده به‌طور تصادفی با 0.05 ≤ Q ≤ 0.13 به طور چشمگیری برای حل‌کننده‌های CDCL دشوارتر از موارد دیگر هستند.
فراتر از پوشش: چه چیزی در مجموعه های آزمایشی در کمین است؟
پاتریک لام (دانشگاه واترلو)
همه ما مجموعه های تست "بهتر" را می خواهیم. اما چه چیزی یک مجموعه تست خوب را ایجاد می کند؟ مطمئناً، مجموعه‌های آزمایشی باید پوشش خوبی داشته باشند، حداقل در سطح پوشش بیانیه. برای مفید بودن، مجموعه های آزمایشی باید به اندازه کافی سریع اجرا شوند تا بازخورد به موقع ارائه کنند.
این گفتار تعدادی از ابعاد دیگر را بررسی خواهد کرد که بر اساس آنها می توان مجموعه های آزمایشی را ارزیابی کرد. این بحث ادعا می‌کند که مجموعه‌های تست بهتر قابل نگهداری‌تر، قابل استفاده‌تر هستند (مثلاً به این دلیل که سریعتر کار می‌کنند یا از منابع کمتری استفاده می‌کنند)، و خرابی‌های غیرقابل توجیه کمتری دارند. در این گفتگو، من حقایقی را در مورد 10 مجموعه تست منبع باز (از 8000 تا 246000 خط کد) ارائه و ترکیب خواهم کرد و نحوه عملکرد آنها را ارزیابی می کنم.
سبز شدن: پاکسازی محیط سمی موبایل
توماس کنیچ (گوگل)، استفان رامساور (گوگل)، والرا زاخاروف (گوگل) و ویشال ستیا (گوگل)
ما ابزارها و تکنیک هایی را برای ایجاد محیط های تست سریع، پایدار و هرمتیک برای اجرای تست های اندروید در هر دو حالت توسعه تعاملی و یکپارچه سازی مداوم ارائه خواهیم داد. این مبتنی بر بحث سطح بالاتری است که در آخرین GTAC ارائه کردیم.