اظهارات افتتاحیه
تونی وولم (گوگل)
لینک ها: ویدئو
افتتاحیه سخنرانی - تکامل از تضمین کیفیت تا مهندسی آزمون
آری شمش (گوگل)
شما یک برنامه ساختید. راه اندازیش کردی شما فکر کردید که آن را بیرون می آورید، مقداری حجم ایجاد می کنید، مقداری بودجه به دست می آورید، همه آن را دور می اندازید، و سپس از صفر شروع می کنید تا بتوانید "این کار را به درستی انجام دهید". اما، تقاضا برای ویژگی‌های جدید بسیار بالاست، اکنون از شما خواسته می‌شود که با سرعتی ناشناخته به سمت مقیاسی بی‌سابقه پیش بروید. بله! حالا چی؟
شما نمی توانید آن را دور بیندازید و از ابتدا شروع کنید، فقط باید آنچه را که دارید تکامل دهید، در حالی که به افزودن ویژگی های با کیفیت بالا با سرعتی خیره کننده ادامه دهید. علاوه بر این، باید اطمینان حاصل کنید که آنچه از قبل وجود دارد شکسته نشود. چگونه این کار را انجام می دهید؟ خوشبختانه، حوزه جدیدی در صنعت مهندسی نرم‌افزار در حال شکل‌گیری است که به این سناریوی رایج می‌پردازد: در گوگل، ما آن را «مهندسی آزمایش» می‌نامیم.
این گفتگو بر روی چیستی مهندسی آزمون، چگونگی تکامل آن از تضمین کیفیت، و نحوه اجرای مهندسی آزمون توسط صنعت به عنوان یک کل (با مثال‌های خاص از نحوه پیاده‌سازی آن در گوگل) تمرکز خواهد کرد.
تست سیستم‌ها در مقیاس @Twitter
جیمز والدراپ (توئیتر)
جیمز در مورد ابزارها، فرآیندها و فلسفه‌ای که به تست عملکرد در توییتر می‌پردازد، بحث خواهد کرد. تاکید ویژه‌ای بر کتابخانه آزمایش بار منبع باز Iago خواهد بود، که او نوشت تا تیم‌های مهندسی توییتر بتوانند آزمایش‌های بارگذاری را قبل از استقرار کد برای تولید انجام دهند. این گفتگو به جزئیات پیاده‌سازی برخی از این تست‌ها (از جمله کد منبع) و چگونگی مدیریت عوامل پیچیده مانند OAuth و پروتکل‌های Thrift دلخواه می‌پردازد.
چگونه یک سیستم عامل موبایل را تست می کنید؟
دیوید برنز (موزیلا) و مالینی داس (موزیلا)
این مشکلی است که وقتی تصمیم گرفتیم وارد دنیای FirefoxOS شویم، با موزیلا مواجه شد. از کجا شروع کنیم و چگونه آن را انجام دهیم، قرار بود کار جالبی را ثابت کند. بیایید گوش کنید که چگونه این مشکل را حل کردیم و چگونه یک چارچوب جدید ایجاد کردیم.
اتوماسیون سیار در خط لوله تحویل مداوم
ایگور دوروسکیخ (اکسپدیا) و کاوستوب گاوانده (اکسپدیا)
Expedia در اوایل سال 2012 سرمایه گذاری روی موبایل وب و برنامه های iOS/Android را آغاز کرد. در همان زمان، مهندسان تست شروع به توسعه راه حل های اتوماسیون آزمایشی برای ایجاد کیفیت و آزمایش پذیری در محصولات از همان ابتدا کردند. در این گفتگو، ما تجربه و یادگیری خود را در مورد استفاده از ابزارهای منبع باز برای ساخت تست خودکار در توسعه Agile و محیط تحویل مداوم Expedia به اشتراک خواهیم گذاشت. ما در مورد Test Pyramid صحبت خواهیم کرد و به جزئیات بیشتری از ابزارهای منبع باز خاصی خواهیم پرداخت که برای ما خوب کار کرده اند. برخی از ابزارهای منبع باز که ما استفاده می کنیم ابزارهای BDD مانند Cucumber، ابزار اتوماسیون وب Selenium-WebDriver، ابزار اتوماسیون iOS Frank، ابزارهای اتوماسیون اندروید Robotium و Calabash و سیستم ادغام مداوم جنکینز هستند. علاوه بر این، ما برخی از اصول تحویل چابک را که در تلاش هستیم مانند TDD، برنامه‌نویسی جفتی، ساخت و آزمایش رادیاتورها اتخاذ کنیم، به اشتراک خواهیم گذاشت. در نهایت، ما برخی از مزایایی را که از سرمایه گذاری خود در Agile و اتوماسیون آزمایشی به دست آورده ایم و اینکه چگونه ما را به اهداف تحویل مداوم خود می رساند به اشتراک می گذاریم.
تست خودکار ست تاپ باکس با GStreamer و OpenCV
دیوید روتلیسبرگر (YouView)
ما با استفاده از ابزارهای خط فرمان GStreamer و OpenCV، یک سیستم تشخیص تصویر ضبط ویدیو را در 3 دقیقه می‌سازیم. (GStreamer یک چارچوب مدیریت رسانه منبع باز است؛ OpenCV - "Open Computer Vision" - یک کتابخانه پردازش تصویر منبع باز است.)
یک نمونه برجسته از چنین سیستمی http://stb-tester.com است، یک ابزار منبع باز که در YouView برای خودکارسازی تست UI جعبه های تنظیم ما ایجاد شده است. ما stb-tester، انعطاف پذیری ارائه شده توسط زیربنای GStreamer آن، برخی از امکاناتی که باز می کند و چالش های پیش رو را شرح خواهیم داد.
لینک ها: ویدئو
Webdriver برای کروم
کن کانیا (گوگل)
کروم از زمان شروع خود به عنوان یک مرورگر فقط ویندوز، به مک، لینوکس، ChromeOS و اخیراً اندروید و iOS گسترش یافته است. تست سطح کاربر برنامه های کاربردی وب در سراسر این پلتفرم ها دشوار بوده و نیاز به رویکردهای مختلف اتوماسیون دارد. این گفتار کاری را که تیم Chrome انجام می دهد برای در دسترس قرار دادن WebDriver برای Chrome در همه پلتفرم ها شرح می دهد. این شامل نگاهی فنی به رویکرد اساسی خواهد بود، اما بر این تمرکز خواهد داشت که چگونه توسعه دهندگان می توانند از ChromeDriver جدید برای نوشتن تست برای پلتفرم های مختلف کروم استفاده کنند. همچنین وضعیت فعلی پروژه و نقشه راه آینده آن پوشش داده خواهد شد.
Karma - تست اجرا برای جاوا اسکریپت
Vojta Jina (گوگل)
مقدمه ای بر کارما - اجرای آزمایشی که آزمایش برنامه های جاوا اسکریپت را در مرورگرهای واقعی بدون اصطکاک و لذت بخش می کند.
وقتی کسی در حال ساخت یک برنامه جاوا اسکریپت است که باید در بسیاری از مرورگرها و دستگاه ها کار کند، آزمایش اختیاری نیست. با این حال اجرای آزمایش ها در همه این محیط های مختلف سخت است. کارما این کار معمولاً پر دردسر را به یک تکه کیک تبدیل می کند. این به شما امکان می دهد آزمایش های جاوا اسکریپت را در مرورگرها یا دستگاه های واقعی مانند تلفن یا رایانه لوحی خود مستقیماً از ترمینال یا IDE مورد علاقه خود انجام دهید.
لینک ها: ویدئو
اندازه گیری خودکار کیفیت ویدیو
پاتریک هوگلند (گوگل)
بله، امکان تست خودکار اندازه گیری های پیچیده و ذهنی مانند کیفیت ویدیو وجود دارد! این گفتگو نشان خواهد داد که چگونه ما یک آزمایش مداوم و خودکار از یک تماس ویدیویی WebRTC را ایجاد کردیم. ما نگاهی به زنجیره ابزار در سطح بالایی خواهیم داشت و در حین ساخت آن با چه چالش هایی مواجه شدیم. اگر می خواهید الهام بگیرید چگونه آزمایش رسانه خود را به سطح بعدی ببرید، این عالی است.
وقتی اتفاقات بد برای برنامه های خوب می افتد...
مینال میشا (نتفلیکس)
رونق محاسبات موبایل و تبلت، صنعت نرم افزار را با پلتفرم های توسعه اپلیکیشن غرق کرده است. توسعه برنامه های کاربردی مصرف کننده در پلت فرم های محاسباتی تجربه جادویی خود را برای کاربران نهایی دارد. شرکت‌های نرم‌افزاری که با مصرف‌کننده مواجه می‌شوند، همیشه سعی می‌کنند وقتی برنامه‌ای را برای این پلتفرم‌ها توسعه می‌دهند، بهترین تلاش خود را به کار گیرند. با این حال، بزرگترین چالش در توسعه برنامه تنها زمانی شروع می شود که شرکت ها اولین نسخه برنامه را عرضه کنند. مصرف‌کنندگان و شرکت‌های نرم‌افزاری می‌خواهند که جدیدترین ویژگی‌ها و قابلیت‌ها در اسرع وقت با بالاترین کیفیت توسعه پیدا نکنند. این منجر به ریزش کد ثابت در هر لایه از پشته می شود. ما، مهندسان اتوماسیون UI، انواع مختلفی از سیستم‌های تشخیص را می‌سازیم تا مشکلات برنامه را زودتر تشخیص دهیم. در این گفتگو، برخی از چالش‌ها و موفقیت‌های خود را در پشت یکی از این سیستم‌های تشخیص به اشتراک می‌گذارم، که به یافتن مشکلات در خارج از لایه برنامه کمک کرد، اما همچنان بر تجربه کاربر تأثیر منفی گذاشت.
تست بازی آموزشی و بازی آموزشی برای تست
تائو زی (دانشگاه ایالتی کارولینای شمالی)
این گفتگو Pex4Fun ( http://www.pexforfun.com/ ) را ارائه می‌کند که از تولید تست خودکار برای پایه‌گذاری درجه‌بندی خودکار در یک سیستم برنامه‌نویسی آنلاین استفاده می‌کند که می‌تواند به صدها هزار کاربر برسد. این یک تجربه بازی برنامه نویسی را در خارج از کلاس ارائه می دهد و به کاربران آموزش می دهد تا مهارت های مختلف برنامه نویسی و مهندسی نرم افزار، از جمله مهارت های آزمایشی مانند نوشتن تست های واحد پارامتری را یاد بگیرند. Pex4Fun کمک قابل توجهی به مشکل شناخته شده درجه بندی تکالیف و همچنین ارائه یک تجربه یادگیری سرگرم کننده بر اساس بازی های تعاملی می کند. Pex4Fun محبوبیت بالایی در جامعه به دست آورده است: از زمانی که در ژوئن 2010 برای عموم منتشر شد، تعداد کلیک های "Ask Pex!" دکمه (که نشان دهنده تلاش کاربران برای حل بازی در Pex4Fun است) تا اوایل سال 2013 به بیش از یک میلیون رسیده است.
پایان کلید - چگونه فیس بوک فیس بوک را در اندروید آزمایش می کند
سایمون استوارت (فیسبوک)
فیس بوک یکی از محبوب ترین اپلیکیشن های اندرویدی است. در این گفتگو، متوجه خواهید شد که فیس بوک چه کاری انجام می دهد تا اطمینان حاصل کند که هر نسخه تا آنجا که می تواند خوب باشد. ما همه چیز را از نحوه مدیریت کدمان، از طریق رویکردهایمان به آزمایش و همه راه‌ها تا آزمایش‌های آزمایشی پوشش خواهیم داد.
افتتاحیه کلیدی - جاوا اسکریپت قابل آزمایش - معماری برنامه شما برای آزمایش پذیری
مارک تراستلر (گوگل)
جاوا اسکریپت قابل آزمایش یک فرآیند است. این که آیا با یک صفحه خالی شروع کنید یا یک برنامه کاربردی از قبل پیاده سازی شده (یا جایی در میان) این که بتوانید کد جاوا اسکریپت خود را به سادگی، تمیز و موثر آزمایش کنید یک ویژگی ضروری است. کدی که قابل آزمایش نباشد بازنویسی می شود.
در حالی که جاوا اسکریپت به دلیل محیط های بی شماری که در آن اجرا می شود منحصر به فرد است، چندین روش آزمایش شده و واقعی "قابل آزمایش" از زبان های دیگر وجود دارد که برای جاوا اسکریپت نیز صادق است. و البته چالش‌های منحصربه‌فردی وجود دارد که توسعه‌دهندگان جاوا اسکریپت باید هنگام نوشتن و آزمایش کد خود با آن مواجه شوند.
چه الگوهایی کد را قابل آزمایش می کنند؟ کدام آنتی الگوها مانع از آزمایش می شوند؟ از چه معیارها و راهنمای عقل سلیم می توان برای سنجش تست پذیری کد ما استفاده کرد؟ زمانی که فرآیند ایجاد کد قابل آزمایش شروع شد، اکنون چه؟
با من همراه باشید تا روند نوشتن جاوا اسکریپت قابل آزمایش را توضیح دهیم. ما ایده‌ها، الگوها و روش‌هایی را بررسی می‌کنیم که آزمایش‌پذیری و در نتیجه قابلیت نگهداری، صحت و ماندگاری کد شما را تا حد زیادی افزایش می‌دهند. این که آیا جاوا اسکریپت سمت سرویس گیرنده یا سمت سرور را با تسلط بر این فرآیند می نویسید، کیفیت کد شما را تا حد زیادی افزایش می دهد.
شکستن ماتریس - تست اندروید در مقیاس
توماس کنیچ (گوگل)، استفان رامساور (گوگل) و والرا زاخاروف (گوگل)
آیا برای خوردن قرص قرمز آماده هستید؟
موبایل نحوه تعامل انسان با کامپیوتر را تغییر داده است. این عالی است، اما به عنوان مهندس، ما با یک ماتریس در حال رشد از محیط‌هایی مواجه هستیم که کد ما روی آنها اجرا می‌شود. روزهایی که تنها تعداد معدودی از مرورگرها و وضوح صفحه نمایش را در نظر می گیریم، باز نمی گردند. مهندسان چگونه می توانند با ماتریکس کنار بیایند؟ ما نحوه مبارزه گوگل با این مشکل تست را در ایستگاه های کاری، در فضای ابری و در ذهن شما پوشش خواهیم داد...
"من سعی می کنم ذهنت را آزاد کنم، نئو. اما فقط می توانم در را به تو نشان دهم. تو کسی هستی که باید از آن عبور کنی."
اتوماسیون رابط کاربری اندروید
گوانگ ژو (朱光) (گوگل) و آدام ممتاز (گوگل)
همانطور که اندروید در دنیای موبایل محبوبیت پیدا می کند، توسعه دهندگان برنامه ها و فروشندگان 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 فراهم می‌کند تا به تیم توسعه ما این اطمینان را بدهد که تغییرات جدید مشتریان فعلی را خراب نمی‌کند.
اسپرسو: شروع تازه برای تست رابط کاربری اندروید
والرا زاخاروف (گوگل)
به روز رسانی [اکتبر 2013]: اسپرسو اکنون منبع باز است. به https://code.google.com/p/android-test-kit/ مراجعه کنید.
ایجاد یک تست قابل اعتماد اندروید باید به همان سرعت و آسانی باشد که کشیدن یک شات اسپرسو. متأسفانه، با ابزارهای موجود، ممکن است بیشتر شبیه به ساختن سس کاراملی دوشاخه و وارونه تک شلاقی نیمه بدون کافئین لاته باشد - گیج کننده و به ندرت سازگار. اسپرسو یک چارچوب جدید تست اندروید است که به شما امکان می‌دهد تست‌های رابط کاربری مختصر، زیبا و قابل اعتماد را سریع بنویسید. API اصلی کوچک، قابل پیش‌بینی و یادگیری آسان است - اما برای سفارشی‌سازی نیز باز است. تست‌های اسپرسو انتظارات، تعاملات و اظهارات خود را به وضوح بیان می‌کنند، بدون اینکه حواس پرتی دیگ بخار، زیرساخت‌های سفارشی، یا جزئیات اجرای کثیف ایجاد شود. تست‌ها با سرعت بهینه اجرا می‌شوند - انتظارها، همگام‌سازی‌ها، خواب‌ها و نظرسنجی‌ها را پشت سر بگذارید و به چارچوب اجازه دهید وقتی در حالت استراحت است، به‌خوبی UI شما را دستکاری و تثبیت کند. از نوشتن و اجرای تست های رابط کاربری لذت ببرید - یک شات اسپرسو را امتحان کنید.
تست عملکرد وب با WebDriver
مایکل کلپیکوف (گوگل)
در تست عملکرد وب، ما به خوبی می دانیم که چگونه بارگذاری صفحه را تجزیه و تحلیل کنیم. با این حال، باید از بارگذاری صفحه فراتر برویم: برنامه های مدرن بسیار تعاملی هستند و عملیات ها تمایل دارند کل صفحه را دوباره بارگذاری نکنند، بلکه آن را به روز می کنند. افراد مختلف، از جمله من، WebDriver را در مهارهای تست عملکرد وب ادغام کرده‌اند، که کمک می‌کند، اما همچنان تست‌های عملکرد را از بقیه مجموعه تست UI جدا نگه می‌دارد. من پیشنهاد می‌کنم ویژگی‌های تست عملکرد را مستقیماً در خود WebDriver ایجاد کنیم و از Logging API اخیراً اضافه شده آن استفاده کنیم. این امکان جمع‌آوری معیارهای عملکرد را در حین اجرای آزمایش‌های عملکردی معمولی فراهم می‌کند و امکان ادغام یکپارچه‌تر تست‌های عملکرد را در توسعه کلی و جریان تست فراهم می‌کند. همچنین برای زنجیره ابزارهای ساخت/آزمایش سفارشی که تقریباً هر سازمان بزرگی ایجاد می کند، بسیار کمتر مخرب است.
من این را با ChromeDriver نسل جدید (WebDriver برای مرورگر Chromium) نشان خواهم داد.
آزمایش داده های نقشه های پیوسته
ایوت نام (گوگل) و برندان وین (گوگل)
آزمایش مداوم به طور کلی در مورد اجرای تست های واحد و تست های یکپارچه سازی است. اما وقتی داده‌هایی که سرور شما پردازش می‌کند در واقع بزرگترین دلیل تغییر است، چگونه می‌توانید اطمینان حاصل کنید که مصرف‌کنندگان داده همچنان آن را قابل استفاده می‌دانند و هیچ چیز تحت سرعت تغییر یا تغییر بد خراب نمی‌شود؟ در مورد تکنیک‌های آزمایش مداوم داده‌ها با مثال‌هایی از Google Maps صحبت خواهیم کرد.
یافتن مقصر به صورت خودکار در بیلدهای شکست خورده - یعنی چه کسی بیلد را شکست؟
Celal Ziftci (UCSD) و Vivek Ramavajjala (Google)
ساخت مداوم یکی از زیرساخت های کلیدی در گوگل است. هنگامی که یک بیلد با شکست مواجه می شود، بسیار مهم است که لیست تغییرات مجرم (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 با آن مواجه بودیم و ایده‌های پشت مدل‌های شناسایی و خزیدن در برنامه‌های کاربردی فشرده جاوا اسکریپت را تشریح می‌کنیم.