Юлия Ковалёва. Fscheck — альтернативный путь для unit тестовMskDotNet Community
Как помочь тестам находить баги? Что лучше: каждый новый запуск на новом наборе данных или же стабильность? Как сделать тестовые данные эффективными?
В докладе рассматривается Property based подход для написания unit-тестов.
На реальных примерах будет показано то, какими возможностями обладает FsCheck в связке с C#, какие есть плюсы и минусы у данного инструмента и стоит ли тратить время на его изучение.
Улучшение качества открытого программного обеспечения с помощью инструментов ...Andrey Karpov
Одним из способов внести свой вклад в развитие открытого программного обеспечения, является поиск и исправление
различных программных ошибок и потенциальных уязвимостей. Достаточно просто, это можно осуществить, используя статические анализаторы кода. Это можно делать даже в том случае, если вы ещё мало знакомы с устройством работы проекта, но хотите внести вклад в его улучшение. Поговорим о методологии анализа исходного кода, бесплатных инструментах и автоматизации процессов проверки.
Запись доклада: https://youtu.be/-eUxbZ6W5Ig
Ангелы и демоны многопоточного программирования / Алексей Федоров (Одноклассн...Ontico
Современные процессоры имеют на борту по нескольку вычислительных ядер, позволяющих запускать задачи на них параллельно. И, казалось бы, вот оно — счастье: бей большие задачи на куски, запускай эти куски параллельно на разных ядрах и радуйся.
Но не все так просто. Для того чтобы одновременный доступ к общим данным выполнялся корректно, современные системы используют разные примитивы синхронизации. В основе одних лежат блокировки (locks), в основе других — операции типа сравнение-с-обменом (compare-and-swap). Однако и у тех и у других есть свои слабые места. О них мы и поговорим.
Из доклада вы узнаете, чем блокирующие алгоритмы отличаются от неблокирующих, и какими достоинствами и недостатками обладает каждый из этих классов. Кроме того, будут показаны различные подводные камни тех и других решений: Deadlock, Livelock, Starvation, Mutable vs Immutable hype.
Юлия Ковалёва. Fscheck — альтернативный путь для unit тестовMskDotNet Community
Как помочь тестам находить баги? Что лучше: каждый новый запуск на новом наборе данных или же стабильность? Как сделать тестовые данные эффективными?
В докладе рассматривается Property based подход для написания unit-тестов.
На реальных примерах будет показано то, какими возможностями обладает FsCheck в связке с C#, какие есть плюсы и минусы у данного инструмента и стоит ли тратить время на его изучение.
Улучшение качества открытого программного обеспечения с помощью инструментов ...Andrey Karpov
Одним из способов внести свой вклад в развитие открытого программного обеспечения, является поиск и исправление
различных программных ошибок и потенциальных уязвимостей. Достаточно просто, это можно осуществить, используя статические анализаторы кода. Это можно делать даже в том случае, если вы ещё мало знакомы с устройством работы проекта, но хотите внести вклад в его улучшение. Поговорим о методологии анализа исходного кода, бесплатных инструментах и автоматизации процессов проверки.
Запись доклада: https://youtu.be/-eUxbZ6W5Ig
Ангелы и демоны многопоточного программирования / Алексей Федоров (Одноклассн...Ontico
Современные процессоры имеют на борту по нескольку вычислительных ядер, позволяющих запускать задачи на них параллельно. И, казалось бы, вот оно — счастье: бей большие задачи на куски, запускай эти куски параллельно на разных ядрах и радуйся.
Но не все так просто. Для того чтобы одновременный доступ к общим данным выполнялся корректно, современные системы используют разные примитивы синхронизации. В основе одних лежат блокировки (locks), в основе других — операции типа сравнение-с-обменом (compare-and-swap). Однако и у тех и у других есть свои слабые места. О них мы и поговорим.
Из доклада вы узнаете, чем блокирующие алгоритмы отличаются от неблокирующих, и какими достоинствами и недостатками обладает каждый из этих классов. Кроме того, будут показаны различные подводные камни тех и других решений: Deadlock, Livelock, Starvation, Mutable vs Immutable hype.
Контроль качества высоконагруженных систем / Андрей Дроздов (Avito)Ontico
HighLoad++ 2017
Зал «Конгресс-Холл», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/2972.html
Разработка любого высоконагруженного сервиса не обходится без нагрузочных тестов. Во многих проектах процесс анализа работы системы под большой нагрузкой слабо структурирован или выполняется непосредственно в бою. Есть масса статьей и рецептов использования тех или иных инструментов, но самые важные вопросы не раскрыты до конца: что именно мы должны измерять, правильно ли мы интерпретируем результаты и как ловить баги, которые проявляются только под высокой нагрузкой.
...
Евгений Сафронов "Тестирование. точка зрения разработчика"DataArt
Что прежде всего объединяет тестировщика и разработчика? Работа в одной команде и общая цель — качественный и завершенный программный продукт.
Мы рассмотрим различные мнения и подходы к тестированию.
Познакомимся с различными видами тестирования, которые может выполнять программист, работая над продуктом. Разберем несколько интересных примеров Unit-тестирования, поговорим о востребованных и эффективных на сегодняшний день практиках.
Модели в профессиональной инженерии и тестировании программ. Александр Петрен...yaevents
Александр Петренко, ИСП РАН
Профессор, доктор физико-математических наук, заведующий отделом технологий программирования Института системного программирования (ИСП РАН), профессор ВМК МГУ. Основные работы в областях: формализация требований, генерация тестов на основе формализованных требований и формальных моделей (model based testing – MBT). Приложения: тестирование операционных систем и распределенных систем, тестирование компиляторов, верификация дизайна микропроцессоров, формализация стандартов на API операционных систем и телекоммуникационных протоколов. Сопредседатель оргкомитетов International MBT workshop (http://www.mbrworkshop.org/), Spring Young Researcher Colloquium on Software Engineering – SYRCoSE (http://syrocose.ispras.ru), городского семинара по технологиям разработки и анализа программ ТРАП/SDAT (http://sdat.ispras.ru/).
Тема доклада
Модели в профессиональной инженерии и тестировании программ.
Тезисы
Model Based Software Engineering (MBSE) является расширением подхода к разработке программ на основе моделей. В MBSE в отличие, например, от MDA (Model Driver Architecture) существенное внимание уделяется не только задачам собственно проектирования и разработки кода, но и задачам других фаз жизненного цикла – анализу требований, верификации и валидации, управлению требованиями на всех фазах жизненного цикла. Model Based Testing (MBT) хронологически возник гораздо раньше, чем MBSE и MDA, однако его место в разработке программ в полной мере раскрылось вместе с развитием MBSE. По этой причине MBT и MBSE следует рассматривать в тесной связке. В докладе будут рассмотрены концепции MBSE-MDA-MBT, основные источники и виды моделей, которые используются в этих подходах, методы генерации тестов на основе моделей, известные инструменты для
"Опыт создания системы управления сборкой и тестированием" (слайдкаст)SPB SQA Group
Доклад посвящен вопросам создания и использования собственной системы управления процессами сборки и тестирования ПО. Описываются ключевые моменты построения таких систем, в частности: вопросы интерфейсов, быстродействия, качества и интеграции в общую инфраструктуру. Затрагиваются концепции встраивания качества в код, сбора и использования метрик ПО, неотделимости сборки от тестирования, автоматизированного ведения базы знаний об ошибках и другие.
Практические основы тестирования на php Unit-test: понятия, тонкости, пути решения, вопросы для проработки.
PHPUnittest fast start
Разработано http://webgloss.ru
"Опыт создания системы управления сборкой и тестированием" (полная)SPB SQA Group
Доклад посвящен вопросам создания и использования собственной системы управления процессами сборки и тестирования ПО. Описываются ключевые моменты построения таких систем, в частности: вопросы интерфейсов, быстродействия, качества и интеграции в общую инфраструктуру. Затрагиваются концепции встраивания качества в код, сбора и использования метрик ПО, неотделимости сборки от тестирования, автоматизированного ведения базы знаний об ошибках и другие.
ГЕНЕРАЦИЯ ТЕСТОВ ДЛЯ ОЛИМПИАДНЫХ ЗАДАЧ ПО ПРОГРАММИРОВАНИЮ С ИСПОЛЬЗОВАНИЕМ Г...ITMO University
Предлагается метод автоматизированной генерации тестов для олимпиадных задач по программированию, предназначенный для выявления неэффективных решений. Этот метод основан на использовании генетических алгоритмов. Описывается использование предлагаемого метода для генерации новых тестов к олимпиадной задаче из Интернет-архива acm.timus.ru, при этом ни одно из имевшихся решений не прошло построенный набор тестов.
Поплоухина Елена, Руководитель отдела тестирования в Usetech
https://vk.com/lena_flower
Расскажу об опыте организации процесса внутреннего тестирования проекта со строго формализованным техническим заданием от момента получения технического задания для тестирования требований до момента передачи релиза на приемочное тестирование.
Контроль качества высоконагруженных систем / Андрей Дроздов (Avito)Ontico
HighLoad++ 2017
Зал «Конгресс-Холл», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/2972.html
Разработка любого высоконагруженного сервиса не обходится без нагрузочных тестов. Во многих проектах процесс анализа работы системы под большой нагрузкой слабо структурирован или выполняется непосредственно в бою. Есть масса статьей и рецептов использования тех или иных инструментов, но самые важные вопросы не раскрыты до конца: что именно мы должны измерять, правильно ли мы интерпретируем результаты и как ловить баги, которые проявляются только под высокой нагрузкой.
...
Евгений Сафронов "Тестирование. точка зрения разработчика"DataArt
Что прежде всего объединяет тестировщика и разработчика? Работа в одной команде и общая цель — качественный и завершенный программный продукт.
Мы рассмотрим различные мнения и подходы к тестированию.
Познакомимся с различными видами тестирования, которые может выполнять программист, работая над продуктом. Разберем несколько интересных примеров Unit-тестирования, поговорим о востребованных и эффективных на сегодняшний день практиках.
Модели в профессиональной инженерии и тестировании программ. Александр Петрен...yaevents
Александр Петренко, ИСП РАН
Профессор, доктор физико-математических наук, заведующий отделом технологий программирования Института системного программирования (ИСП РАН), профессор ВМК МГУ. Основные работы в областях: формализация требований, генерация тестов на основе формализованных требований и формальных моделей (model based testing – MBT). Приложения: тестирование операционных систем и распределенных систем, тестирование компиляторов, верификация дизайна микропроцессоров, формализация стандартов на API операционных систем и телекоммуникационных протоколов. Сопредседатель оргкомитетов International MBT workshop (http://www.mbrworkshop.org/), Spring Young Researcher Colloquium on Software Engineering – SYRCoSE (http://syrocose.ispras.ru), городского семинара по технологиям разработки и анализа программ ТРАП/SDAT (http://sdat.ispras.ru/).
Тема доклада
Модели в профессиональной инженерии и тестировании программ.
Тезисы
Model Based Software Engineering (MBSE) является расширением подхода к разработке программ на основе моделей. В MBSE в отличие, например, от MDA (Model Driver Architecture) существенное внимание уделяется не только задачам собственно проектирования и разработки кода, но и задачам других фаз жизненного цикла – анализу требований, верификации и валидации, управлению требованиями на всех фазах жизненного цикла. Model Based Testing (MBT) хронологически возник гораздо раньше, чем MBSE и MDA, однако его место в разработке программ в полной мере раскрылось вместе с развитием MBSE. По этой причине MBT и MBSE следует рассматривать в тесной связке. В докладе будут рассмотрены концепции MBSE-MDA-MBT, основные источники и виды моделей, которые используются в этих подходах, методы генерации тестов на основе моделей, известные инструменты для
"Опыт создания системы управления сборкой и тестированием" (слайдкаст)SPB SQA Group
Доклад посвящен вопросам создания и использования собственной системы управления процессами сборки и тестирования ПО. Описываются ключевые моменты построения таких систем, в частности: вопросы интерфейсов, быстродействия, качества и интеграции в общую инфраструктуру. Затрагиваются концепции встраивания качества в код, сбора и использования метрик ПО, неотделимости сборки от тестирования, автоматизированного ведения базы знаний об ошибках и другие.
Практические основы тестирования на php Unit-test: понятия, тонкости, пути решения, вопросы для проработки.
PHPUnittest fast start
Разработано http://webgloss.ru
"Опыт создания системы управления сборкой и тестированием" (полная)SPB SQA Group
Доклад посвящен вопросам создания и использования собственной системы управления процессами сборки и тестирования ПО. Описываются ключевые моменты построения таких систем, в частности: вопросы интерфейсов, быстродействия, качества и интеграции в общую инфраструктуру. Затрагиваются концепции встраивания качества в код, сбора и использования метрик ПО, неотделимости сборки от тестирования, автоматизированного ведения базы знаний об ошибках и другие.
ГЕНЕРАЦИЯ ТЕСТОВ ДЛЯ ОЛИМПИАДНЫХ ЗАДАЧ ПО ПРОГРАММИРОВАНИЮ С ИСПОЛЬЗОВАНИЕМ Г...ITMO University
Предлагается метод автоматизированной генерации тестов для олимпиадных задач по программированию, предназначенный для выявления неэффективных решений. Этот метод основан на использовании генетических алгоритмов. Описывается использование предлагаемого метода для генерации новых тестов к олимпиадной задаче из Интернет-архива acm.timus.ru, при этом ни одно из имевшихся решений не прошло построенный набор тестов.
Поплоухина Елена, Руководитель отдела тестирования в Usetech
https://vk.com/lena_flower
Расскажу об опыте организации процесса внутреннего тестирования проекта со строго формализованным техническим заданием от момента получения технического задания для тестирования требований до момента передачи релиза на приемочное тестирование.
Зачем тестировать? Тестирование в интерпретаторе и доктесты. Модуль unittest. Пакет py.test - на порядок лучше. Тестирование свойств и пакет hypothesis.
Presentation from https://heisenbug-piter.ru/en/talks/2018/spb/kkw6oivsoywayacggksmk/
Once upon a time, we got a requirement to finish all testing in 2 days despite the number of tests to run. That number grew, and grew, and grew, and now there are tens of millions of them. So this is a story about building a dam against the never-ending flood which turned out to be not that scary. You are very welcome to join and see it for yourself.
Промышленный подход к автоматизации тестирования или Keyword-driven testing в...Maksim Grinevich
Доклад описывает промышленный подход к организации процесса автоматизации тестирования. Если у вас серьезный проект ни на один человекогод и необходимо внедрять автоматизацию, либо сделать так, чтобы она, наконец, заработала – предлагаю рассмотреть нашу реализацию как один из возможных выходов из ситуации.
Автотесты генерируют специалисты в предметной области, а не тестировщики-программисты. Сценарии тестирования пишутся в формате xml с использованием "стандартных операций". Эти операции поддерживаются генератором автотестов и автоматизированы на VBScript (QuickTestPro).
Доклад может быть интересен тем, кто вплотную занимается автоматизацией либо пытается разобраться в этом вопросе.
Как оценивать состояние проекта по разработке с помощью формальных метрик и о...Dmitry Andreev
Можете ли вы завтра утром в 8:05 положить на стол руководства детальный отчет по прогрессу разрабатываемой системы, количестве ошибок в разрезе подсистем и требований, качестве юнит-тестов, скорости внесения изменений в код и возникновения ошибок? Можете ли вы с помощью средств аналитики оценить узкие места проекта, например, ответив на вопрос «какая подсистема имеет самое большое количество вновь возникающих ошибок»? Если вы хотите узнать, как это сделать то приходите на доклад о возможностях подсистем отчетности Visual Studio Team System 2010. В докладе будут рассмотрены подходы по созданию формальной системы метрик, индикаторов, отчетов для оценки прогресса и состояния проекта по разработке программного обеспечения.
This document discusses continuous performance testing (CPT) and introduces the Jagger CPT solution. It provides an overview of why performance testing is important, outlines the principles and goals of CPT, and describes the key parts of the Jagger CPT platform including load generation, metrics collection, test data management, and environment management. It also provides an example customer success story where Jagger was used for continuous performance testing of a large ecommerce site.
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииSQALab
This document provides an overview of the JDI (Java UI test automation framework). It discusses features of JDI including being UI element oriented, providing common UI elements and solutions to common problems. It provides examples of how to write tests using JDI annotations and page object pattern. The document also summarizes benefits of JDI such as reducing test code, improving test clarity, reuse across projects. Finally it outlines new features planned for JDI 2.0 including layout verification, page object generator, integration with Selenium and expanding JDI to other languages like Python.
The document discusses testing of geolocation systems. It provides an overview of geolocation, including definitions and importance. It then outlines the speaker's experience and work testing GIS systems. The rest of the document details approaches to testing geolocation, including simulating calls, checking responses and databases, and verifying accuracy. It also discusses common data formats, projections, tools like PostGIS and QGIS, and potential bugs to watch for like coordinate jumbling. The conclusion emphasizes starting simple, practicing to improve, and for tests to grow with knowledge as geolocation is important for future IT.
2. АБС. Тесты - Особенности
• Один документ/операция – тест-кейс длиной 10..15 шагов
• Цепочка тест-кейсов – 10..15 тест-кейсов на бизнес-процесс
• Тест-кейсы сильно связаны по данным:
данные, создаваемые одним тест-кейсом, используются последующими
Пример бизнес-процесса:
1. тест-кейс № j создает документ
2. АБС присваивает документу уникальный номер
3. Над документом выполняется операция (зарегистрировать, оплатить , …)
4. Операция порождает
1. Записи в журнале операций (нужно проверять)
2. Записи в журнале проводок (нужно проверять)
3. Новые документы (нужно проверять)
5. тест-кейсы №№ j+k, j+l используют созданный документ
3. АБС. Тестовые данные -
особенности
• 50..100 - констант и переменных в цепочке
• длиной 10..15 тестов, каждый из которых состоит из 10..15
шагов
• 3…5 наборов констант и переменных
• используются с одной цепочкой. Отличие между наборами –
10..20% значений
• 2..4 час
• Занимает у тест-аналитика подготовка набора начальных
значений для цепочки.
5. 20 век - конвейер
аналитик тестировщик программист Тест-инженер Тест-менеджер
Разработка Разработка Разработка Прогон Анализ
требований тест-кейсов автотестов автотестов результатов
Требования Тест-кейсы Автотесты Логи Выводы
Основное
КБ склад
производство
6. 21 век - ГАП
аналитик тестировщик Тест-менеджер
Разработка Разработка Прогон Анализ
требований тест-кейсов тест-кейсов результатов
Требования Тест-кейсы Выводы
Основное
КБ склад
производство
Разработка Инструменты
Инстру- инструментов
ментальный цех
программист
7. Инструментальное
производство - цифры
• в себестоимости машиностроительной продукции затраты на
технологическую оснастку достигают 15%.
• В общих затратах на технологическую подготовку производства затраты на
оснастку доходят до 60%.
• Проектирование и изготовление технологической оснастки имеет
значительную трудоемкость.
• Источник - http://www.kazedu.kz/referat/176709
• Затраты на технологическую оснастку в массовом производстве достигают
25-30% стоимости оборудования, в крупносерийном – 10-15%, в
мелкосерийном и единичном – около 5%. Доля затрат на оснастку (в %): 1,5-
4, 4-6, 6-8 и 8-15 и выше.
• В инструментальных цехах сосредоточено 10—20% станочного парка и
занято до 10% работающих.
• Источник - http://www.buhucheta.net/referatpage-854-1.html
• на долю проектирования и изготовления технологической оснастки при
освоении новых изделий приходится более 80% трудоемкости всех работ по
подготовке производства.
• Источник - http://www.grandars.ru/college/biznes/instrumentalnoe-hozyaystvo.html
8. Как сделать
• Технология
• keyword-driven подход
• Предметно-ориентированные Keywords = Bankwords
• Специализация сотрудников
• Bankwords разрабатываются
• «инструментальщиками» = программистами автотестов
по заказу
• «производственников» - тестировщиков
• Перераспределение функций и смена ролей
• роль «тест-инженер» выполняет тест-менеджер
• Тест-кейс запускает на выполнение тест-менеджер
• Результат прогона , отображаемый в теле тест-кейса,
анализируется тест-менеджером
12. Результат
• Итог:
• Трудоемкость оформления тесткейса увеличивается на 10..20%,
• Трудоемкость разработки атотеста уменьшается на 80-90%
• Типовой автотест готов за 4..8 2..4 часа
• Тест-кейсы легким движением при помощи xslt превращаются в
точную техдокументацию по системе
• Источники выгоды:
• Программистам автотестов не нужно изучать приложение
• Тест-менеджер эффективнее работает с привычной формой тест-
кейса
• В 80-90% случаев нет этапа разработки автотеста
• Издержки (как же без них)
• Повышаются требования программистам – нужно писать универсальные механизмы
• Строже требования к ручным тестерам – нужно писать детальные и
формализованные тест-кейсы
14. Схема обмена данными
Данные, созданные автотестом i, используются автотестами j,k
Диаграмма – строится динамически, используется Graphviz
Диаграмма строится до и после прогона.
Значения переменных прогона видны по линкам на диаграмме просто анализировать обмен данными между
отдельными тестами цепочки
15. Организация конвейера
данных
• Кто проектирует: Тест-аналитик
• Кто реализует: программист автор тест-кейса
• Как реализует:
• 1. Формулирует правила обмена данными между тестами
цепочки
• 2. Задает начальные значения переменных цепочки
16. Правила обмена
Значение с атрибутом
«импорт» - извлекается из набора переменных цепочки
«экспорт» - помещается в набор переменных цепочки
Первый тест цепочки как правило задает основные параметры,
последующие их используют.
Параметр идентифицируется именем, например «ДатаОперДня»
32. Не хватает данных – что
делать
• Тестовый комплект генерации данных разных типов
• Данные для блока АБС «Расчетно-кассовое обслуживание»
• Типов данных -20..30
(клиенты, кассиры, кассы, клиенты, счета, тарифы, ….)
• Данных каждого типа 1..100
(счет Петрова, Иванова, …; касса 1,2,…; …)
• Время генерации 2..5 час
• Комплект может запустить ручной тестировщик
33. Ручные тестировщики
мешают друг другу – что
делать
• Если бы для каждого тестировщика был свой банк – он и
бы не мешали друг другу
• Создать (настроить ) банк ручной тестировщик может за
40..80 час. Вообще, говоря, этим занимаются внедренцы за
существенные деньги.
• Теоретически можно было бы иметь свою копию БД для
каждого ручного тестировщика. На практике
• 1 . не хватает железа
• 2. не хватает админов
• 3. нет скриптов клонирования БД
• 4. расходы на сопровождение N копий БД неприемлемы
34. Ручные тестировщики не
мешают друг другу – как
• Делаем тестовый комплект для замены
• Тестовый комплект способен создать обособленное отделение банка.
Отделение банка = функциональный аналог банка.
• Тестовый комплект способен создать платежную систему – компонент АБС,
обеспечивающий платежи между отделениями
• Ручной тестировщик может создать для себя отделение банка (читай
обособленный банк)
• Комплект использует данные для блока АБС «Расчетно-кассовое
обслуживание»
• Типов данных -20..30
(клиенты, кассиры, кассы, клиенты, счета, тарифы, ….)
• Данных каждого типа 1..100
(счет Петрова, Иванова, …; касса 1,2,…; …)
• Время генерации 2..5 час
• Комплект может запустить ручной тестировщик
• Время создания банка - 12..14 часов (в 4..5 потоков)