افتتاحیه کلیدی - جاوا اسکریپت قابل آزمایش - معماری برنامه شما برای آزمایش پذیری
مارک تراستلر (گوگل)
جاوا اسکریپت قابل آزمایش یک فرآیند است. این که آیا با یک صفحه خالی شروع کنید یا یک برنامه کاربردی از قبل پیاده سازی شده (یا جایی در میان) این که بتوانید کد جاوا اسکریپت خود را به سادگی، تمیز و موثر آزمایش کنید یک ویژگی ضروری است. کدی که قابل آزمایش نباشد بازنویسی می شود.
در حالی که جاوا اسکریپت به دلیل محیط های بی شماری که در آن اجرا می شود منحصر به فرد است، چندین روش آزمایش شده و واقعی "قابل آزمایش" از زبان های دیگر وجود دارد که برای جاوا اسکریپت نیز صادق است. و البته چالش‌های منحصربه‌فردی وجود دارد که توسعه‌دهندگان جاوا اسکریپت باید هنگام نوشتن و آزمایش کد خود با آن مواجه شوند.
چه الگوهایی کد را قابل آزمایش می کنند؟ کدام آنتی الگوها مانع از آزمایش می شوند؟ از چه معیارها و راهنمای عقل سلیم می توان برای سنجش تست پذیری کد ما استفاده کرد؟ زمانی که فرآیند ایجاد کد قابل آزمایش شروع شد، اکنون چه؟
با من همراه باشید تا روند نوشتن جاوا اسکریپت قابل آزمایش را توضیح دهیم. ما ایده‌ها، الگوها و روش‌هایی را بررسی می‌کنیم که آزمایش‌پذیری و در نتیجه قابلیت نگهداری، صحت و ماندگاری کد شما را تا حد زیادی افزایش می‌دهند. این که آیا جاوا اسکریپت سمت سرویس گیرنده یا سمت سرور را با تسلط بر این فرآیند می نویسید، کیفیت کد شما را تا حد زیادی افزایش می دهد.
شکستن ماتریس - تست اندروید در مقیاس
توماس کنیچ (گوگل)، استفان رامساور (گوگل) و والرا زاخاروف (گوگل)
آیا برای خوردن قرص قرمز آماده هستید؟
موبایل نحوه تعامل انسان با کامپیوتر را تغییر داده است. این عالی است، اما به عنوان مهندس، ما با یک ماتریس در حال رشد از محیط‌هایی مواجه هستیم که کد ما روی آنها اجرا می‌شود. روزهایی که تنها تعداد معدودی از مرورگرها و وضوح صفحه نمایش را در نظر می گیریم، باز نمی گردند. مهندسان چگونه می توانند با ماتریکس کنار بیایند؟ ما نحوه مبارزه گوگل با این مشکل تست را در ایستگاه های کاری، در فضای ابری و در ذهن شما پوشش خواهیم داد...
"من سعی می کنم ذهنت را آزاد کنم، نئو. اما فقط می توانم در را به تو نشان دهم. تو کسی هستی که باید از آن عبور کنی."
اتوماسیون رابط کاربری اندروید
گوانگ ژو (朱光) (گوگل) و آدام ممتاز (گوگل)
همانطور که اندروید در دنیای موبایل محبوبیت پیدا می کند، توسعه دهندگان برنامه ها و فروشندگان OEM در حال بررسی راه هایی برای انجام آزمایش UI مبتنی بر انتها برای برنامه ها یا کل پلت فرم هستند. با مروری کوتاه بر راه‌حل‌های موجود اتوماسیون UI در اندروید، این گفتار چارچوب Android UI Automator را که اخیراً منتشر شده است، معرفی می‌کند و همچنان نگاهی درونی به چارچوب، موارد استفاده معمولی و گردش کار ارائه می‌دهد.
Appium: اتوماسیون برای برنامه های موبایل
جاناتان لیپس (آزمایشگاه سس)
Appium یک سرور Node.js است که برنامه های موبایل بومی و ترکیبی (هم iOS و هم اندروید) را خودکار می کند. فلسفه Appium حکم می‌کند که برنامه‌ها نباید برای خودکار شدن اصلاح شوند و شما باید بتوانید کد آزمون خود را به هر زبان یا فریم ورکی بنویسید. نتیجه یک سرور Selenium WebDriver است که مانند یک بومی با تلفن همراه صحبت می کند. Appium بر روی دستگاه‌ها و شبیه‌سازهای واقعی اجرا می‌شود و کاملاً منبع باز است، و آن را به روشی فوق‌العاده دوستانه برای شروع اتوماسیون تست تلفن همراه تبدیل می‌کند. در این گفتگو من اصولی را بیان می کنم که طراحی Appium را مشخص می کند، در مورد Appium در فضای سایر چارچوب های اتوماسیون موبایل صحبت می کنم و معماری را معرفی می کنم که باعث می شود جادو اتفاق بیفتد. در نهایت، کد یک تست ساده از یک برنامه موبایل کاملاً جدید را بررسی می‌کنم و نشان می‌دهم که Appium این آزمایش را روی iPhone و Android اجرا می‌کند.
ساخت زیرساخت تست موبایل مقیاس پذیر برای Google+ Mobile
ادواردو براوو (گوگل)
آزمایش برنامه های بومی به روشی معنادار، پایدار و مقیاس پذیر یک چالش است. G+ با ارائه زیرساخت مناسب برای هر یک از سناریوهای آزمایش پیچیده ای که موبایل ارائه می دهد، راه حل های کارآمدی برای مقابله با این مشکلات ایجاد کرده است. زیرساخت آزمایش فعلی ما ابزارهای مناسبی را برای برنامه‌های iOS و Android فراهم می‌کند تا به تیم توسعه ما این اطمینان را بدهد که تغییرات جدید مشتریان فعلی را خراب نمی‌کند.
اسپرسو: شروع تازه برای تست رابط کاربری اندروید
والرا زاخاروف (گوگل)
ایجاد یک تست قابل اعتماد اندروید باید به همان سرعت و آسانی باشد که کشیدن یک شات اسپرسو. متأسفانه، با ابزارهای موجود، ممکن است بیشتر شبیه به ساختن سس کاراملی دوشاخه و وارونه تک شلاقی نیمه بدون کافئین لاته باشد - گیج کننده و به ندرت سازگار. اسپرسو یک چارچوب جدید تست اندروید است که به شما امکان می‌دهد تست‌های رابط کاربری مختصر، زیبا و قابل اعتماد را سریع بنویسید. API اصلی کوچک، قابل پیش‌بینی و یادگیری آسان است - اما برای سفارشی‌سازی نیز باز است. تست‌های اسپرسو انتظارات، تعاملات و اظهارات خود را به وضوح بیان می‌کنند، بدون اینکه حواس پرتی دیگ بخار، زیرساخت‌های سفارشی، یا جزئیات اجرای کثیف ایجاد شود. تست‌ها با سرعت بهینه اجرا می‌شوند - انتظارها، همگام‌سازی‌ها، خواب‌ها و نظرسنجی‌ها را پشت سر بگذارید و به چارچوب اجازه دهید وقتی در حالت استراحت است، به‌خوبی UI شما را دستکاری و تثبیت کند. از نوشتن و اجرای تست های رابط کاربری لذت ببرید - یک شات اسپرسو را امتحان کنید.
تست عملکرد وب با WebDriver
مایکل کلپیکوف (گوگل)
در تست عملکرد وب، ما به خوبی می دانیم که چگونه بارگذاری صفحه را تجزیه و تحلیل کنیم. با این حال، باید از بارگذاری صفحه فراتر برویم: برنامه های مدرن بسیار تعاملی هستند و عملیات ها تمایل دارند کل صفحه را دوباره بارگذاری نکنند، بلکه آن را به روز می کنند. افراد مختلف، از جمله من، WebDriver را در مهارهای تست عملکرد وب ادغام کرده‌اند، که کمک می‌کند، اما همچنان تست‌های عملکرد را از بقیه مجموعه تست UI جدا نگه می‌دارد. من پیشنهاد می‌کنم ویژگی‌های تست عملکرد را مستقیماً در خود WebDriver ایجاد کنیم و از Logging API اخیراً اضافه شده آن استفاده کنیم. این امکان جمع‌آوری معیارهای عملکرد را در حین اجرای آزمایش‌های عملکردی معمولی فراهم می‌کند و امکان ادغام یکپارچه‌تر تست‌های عملکرد را در توسعه کلی و جریان تست فراهم می‌کند. همچنین برای زنجیره ابزارهای ساخت/آزمایش سفارشی که تقریباً هر سازمان بزرگی ایجاد می کند، بسیار کمتر مخرب است.
من این را با ChromeDriver نسل جدید (WebDriver برای مرورگر Chromium) نشان خواهم داد.
آزمایش داده های نقشه های پیوسته
ایوت نام (گوگل) و برندان وین (گوگل)
آزمایش مداوم به طور کلی در مورد اجرای تست های واحد و تست های یکپارچه سازی است. اما وقتی داده‌هایی که سرور شما پردازش می‌کند در واقع بزرگترین دلیل تغییر است، چگونه می‌توانید اطمینان حاصل کنید که مصرف‌کنندگان داده همچنان آن را قابل استفاده می‌دانند و هیچ چیز تحت سرعت تغییر یا تغییر بد خراب نمی‌شود؟ در مورد تکنیک‌های آزمایش مداوم داده‌ها با مثال‌هایی از Google Maps صحبت خواهیم کرد.
یافتن مقصر به صورت خودکار در بیلدهای شکست خورده - یعنی چه کسی بیلد را شکست؟
Celal Ziftci (UCSD) و Vivek Ramavajjala (UCSD)
ساخت مداوم یکی از زیرساخت های کلیدی در گوگل است. هنگامی که یک بیلد با شکست مواجه می شود، بسیار مهم است که لیست تغییرات مجرم (CL)/تغییرکنندگان را به سرعت مشخص کنید تا بتوان آن را اصلاح کرد تا بیلد به رنگ سبز بازگردد.
راه‌حل‌های تشخیص مقصر برای ساخت‌های کوچک و متوسط وجود دارد، اما برای ساخت‌های ادغام‌شده بزرگ وجود ندارد.
هدف یاب مقصر ما یافتن CL مقصر برای ساخت‌های بزرگ به صورت خودکار، در بازه زمانی بسیار کوتاه با موفقیت بالا است. بر اساس استفاده از تولید در پروژه های متعدد در 9 ماه گذشته، یاب مقصر نتایج بسیار امیدوار کننده ای را ارائه می دهد. بیایید گفتگوی ما را ببینید تا ببینید چگونه مقصر یاب را پیاده سازی کردیم، چقدر در تولید موفق است و چه احساسی دارد و چه ظاهری دارد.
بررسی تجربی کیفیت خط تولید نرم افزار
Katerina Goseva-Popstojanova (دانشگاه ویرجینیای غربی)
خطوط تولید نرم افزار دارای میزان اشتراک بالایی در بین سیستم های موجود در خط تولید و تعداد مشخصی از تغییرات احتمالی است. بر اساس داده‌های استخراج‌شده از دو مطالعه موردی - یک خط تولید صنعتی با اندازه متوسط و یک خط تولید منبع باز بزرگ و در حال تحول - به طور تجربی بررسی کردیم که آیا استفاده مجدد سیستماتیک کیفیت را بهبود می‌بخشد و از پیش‌بینی موفقیت‌آمیز خطاهای احتمالی آینده از خطاهای تجربه شده قبلی، کد منبع پشتیبانی می‌کند. معیارها و معیارهای تغییر. نتایج تحقیقات ما، در یک تنظیم خط محصول نرم‌افزار، یافته‌های دیگران را تأیید کرد که خطاها بیشتر با معیارهای تغییر مرتبط هستند تا معیارهای کد استاتیک. نتایج ارزیابی کیفیت نشان داد که اگرچه بسته‌های قدیمی‌تر (از جمله موارد مشترک) به طور مداوم تغییر می‌کردند، اما تراکم خطای پایینی را حفظ کردند. علاوه بر این، خط تولید منبع باز از نظر کیفیت با تکامل آن از طریق انتشار بهبود یافت. پیش‌بینی مبتنی بر مدل‌های رگرسیون خطی تعمیم‌یافته، بسته‌ها را با توجه به خطاهای پس از انتشار با استفاده از مدل‌های ساخته‌شده در نسخه قبلی، به دقت رتبه‌بندی کرد. نتایج همچنین نشان داد که پیش‌بینی‌های خطای پس از انتشار از اطلاعات اضافی خط محصول سود می‌برند.
AddressSanitizer، ThreadSanitizer و MemorySanitizer -- ابزارهای تست پویا برای C++
Kostya Serebryany (گوگل)
AddressSanitizer (ASan) ابزاری است که سرریزهای بافر (در stack، heap و globals) و باگ‌های بدون استفاده در برنامه‌های C/C++ را پیدا می‌کند. ThreadSanitizer (TSan) نژادهای داده را در برنامه های C/C++ و Go پیدا می کند. MemorySanitizer (MSan) یک ابزار در حال پیشرفت است که کاربردهای حافظه اولیه (C++) را پیدا می کند. این ابزارها بر اساس ابزار دقیق کامپایلر (LLVM و GCC) هستند که آنها را بسیار سریع می کند (به عنوان مثال ASan فقط 2 برابر کاهش سرعت را متحمل می شود). ما تجربه خود را در آزمایش در مقیاس بزرگ با استفاده از این ابزارها به اشتراک خواهیم گذاشت.
پایان سخنرانی - نوشیدن اقیانوس - یافتن XSS در مقیاس Google
کلودیو کریسیونه (گوگل)
اسکریپت نویسی متقابل سایت یا XSS معادل امروزی طاعون سیاه میانسالی در دنیای برنامه های وب است: گسترده است، بد است و راه های فنی کمی برای تشخیص آن تا زمانی که خیلی دیر شده است وجود ندارد. DOM XSS یک نوع بسیار بد از آن ها است، زیرا برای شناسایی نیاز به یک مرورگر واقعی یا معادل آن دارد: یک مشکل دشوار با راه حل های خودکار کمی در دسترس.
ما به ابزارهای قدرتمند و خودران برای شناسایی DOM XSS در اوایل چرخه عمر توسعه نیاز داشتیم که توسط مهندسان خارج از تیم امنیتی قابل استفاده باشد: تنها چیزی که می‌خواستیم محصولی بود که بتواند مجموعه برنامه‌های عظیم، سریع، بسیار پیچیده و محرمانه ما را اسکن کند. .. و البته هیچ کدام را پیدا نکردیم. بنابراین ما خودمان را ساختیم: یک اسکنر برنامه وب با هدف قرار دادن DOM XSS که بر پایه فناوری‌های استاندارد Google طراحی شده است. این برنامه در App Engine اجرا می شود و از مرورگر قدرتمند کروم و صدها CPU به عنوان یک پلت فرم اسکن امنیتی استفاده می کند.
همچنین یک شهروند خوب از زرادخانه آزمایش در Google است: به جای اینکه ابزار تیم امنیتی باشد، در زیرساخت آزمایش ما زندگی می کند.
در این گفتگو، رویکرد جدید خود، چالش‌هایی که در مقیاس‌سازی سیستم خود به اندازه Google با آن مواجه بودیم و ایده‌های پشت مدل‌های شناسایی و خزیدن در برنامه‌های کاربردی فشرده جاوا اسکریپت را تشریح می‌کنیم.