Тест-план и исследовательское тестированиеVasiliy Burov
В своем докладе я расскажу как мы в своей работе совмещаем тест-план и исследовательское тестирование. С первого взгляда, может показаться что это не совсем совместимые вещи. Исследовательское тестирование ассоциируется с методом свободного поиска, а тест-план наоборот – следование заданному порядку. Как совместить эти сущности и ничего не потерять – я попытаюсь рассказать.
Sharing the slides pack on Accessibility testing talk at Agile India. This pack has some good tips around how to get started with a11y on various SDLC stages and some new methodologies
Как провести юзабилити-тестирование самостоятельноНетология
Видеозапись открытого занятия «Оценка эффективности SMM-кампании: как достичь цели?» можно посмотреть здесь - http://bit.ly/1swilQC
Юзабилити-тестирование позволяет узнать, насколько хорошо интерфейс вашего сайта позволяет решать задачи пользователей. Узнайте, как организовать аудит сайта самостоятельно, и что для этого потребуется.
— Что такое юзабилити-текстирование?
— Что такое юзабилити-экспертиза?
— Когда и как проводить тестирование?
— Когде не надо проводить юзабилити-тестирование?
— Этапы ю-тестирования
— Различные варианты ю-тестирования
In this session we'll review the checks you must go through before deciding whether to use an ARIA role or attribute, reveal our favorites, discuss the ones that need more user agent support, and show you how you can help us make it happen.
비행기 설계를 왜 통일 해야 할까?
디자인 시스템을 하는 이유
비행기들이 다 용도가 다르다...어떻게 설계하지?
맥락이 다른 페이지와 패턴
경유지까지 아직 멀었다... 언제 수리하지?
디자인 시스템을 적용하는 시점
엔지니어랑 얘기해서 정비해야하는데...어떻게 수리하지?
디자인 시스템을 적용하는 프로세스
비행기 설계가 바뀐걸 어떻게 알리지?
디자인 시스템의 전파
Тест-план и исследовательское тестированиеVasiliy Burov
В своем докладе я расскажу как мы в своей работе совмещаем тест-план и исследовательское тестирование. С первого взгляда, может показаться что это не совсем совместимые вещи. Исследовательское тестирование ассоциируется с методом свободного поиска, а тест-план наоборот – следование заданному порядку. Как совместить эти сущности и ничего не потерять – я попытаюсь рассказать.
Sharing the slides pack on Accessibility testing talk at Agile India. This pack has some good tips around how to get started with a11y on various SDLC stages and some new methodologies
Как провести юзабилити-тестирование самостоятельноНетология
Видеозапись открытого занятия «Оценка эффективности SMM-кампании: как достичь цели?» можно посмотреть здесь - http://bit.ly/1swilQC
Юзабилити-тестирование позволяет узнать, насколько хорошо интерфейс вашего сайта позволяет решать задачи пользователей. Узнайте, как организовать аудит сайта самостоятельно, и что для этого потребуется.
— Что такое юзабилити-текстирование?
— Что такое юзабилити-экспертиза?
— Когда и как проводить тестирование?
— Когде не надо проводить юзабилити-тестирование?
— Этапы ю-тестирования
— Различные варианты ю-тестирования
In this session we'll review the checks you must go through before deciding whether to use an ARIA role or attribute, reveal our favorites, discuss the ones that need more user agent support, and show you how you can help us make it happen.
비행기 설계를 왜 통일 해야 할까?
디자인 시스템을 하는 이유
비행기들이 다 용도가 다르다...어떻게 설계하지?
맥락이 다른 페이지와 패턴
경유지까지 아직 멀었다... 언제 수리하지?
디자인 시스템을 적용하는 시점
엔지니어랑 얘기해서 정비해야하는데...어떻게 수리하지?
디자인 시스템을 적용하는 프로세스
비행기 설계가 바뀐걸 어떻게 알리지?
디자인 시스템의 전파
Description- SOAtest is a testing and analysis tool suite for testing and validating APIs and API-driven applications (e.g., cloud, mobile apps, SOA).[1] Basic testing functionality include functional security testing, simulation and mocking, runtime error detection, web services testing, interoperability testing, WS-* compliance testing, and load testing
Headless CMS – the foundation of modern SEOCory Schmidt
In this talk, Cory Schmidt explains the SEO implications of migrating to a headless CMS. He will use the story of his company's recent migration and its challenges, and the huge impact on organic search...
Free and Open Source web service testing application.
Released in Sept. 2005, Developed by eviware software.
Built entirely on java platform & uses swing for UI.
Soap UI Pro is the commercial enterprise version.
Latest version 4.5.1
Including Everyone: Web Accessibility 101Helena Zubkow
Shouldn’t the web be awesome for everyone? That's not always the case, but it could be.
Designed for developers, project managers, and directors alike, the goal of this session is to introduce everyone to the wonderful world of web accessibility. We'll cover the basic standards and regional expectations for accessibility, as well as the principles and concepts that make up the accessibility field. This session will touch on Section 508, WCAG 2.0 standards, and the financial viability of a web accessibility initiative in an industry where time is money.
This session is proposed as a conceptual prelude to our more developer-oriented accessibility session that is taking place at the Higher Ed Summit. Based on my experience as a web accessibility specialist from both the perspective of a project manager and a front-end developer, I'll share the knowledge I've gained with you to address the following important questions:
- What is web accessibility?
- Why does web accessibility matter to my users?
- Why does web accessibility matter for my company and clients?
- How will a web accessibility initiative affect my bottom line?
- How can I include web accessibility in my company's culture and work plans?
- What tools can I use to assess and improve accessibility in my projects?
- How can I help the web accessibility community?
What are web services?
Component of web services
Architecture
Operations in web service architecture
Diagram of web service architecture
Types of web services
What is SoapUI
SoapUI test structure
It's just as important that you follow the right approach to integration, as well as using the right technology. We'll start this session by exploring MuleSoft's API-led approach to connectivity, and then use demos to bring to life the tooling in the Anypoint Platform that allows you to design and build your integration applications quickly and easily.
Join us for an overview of behavior-driven development and test automation, which aided in the production of a Visualforce/JavaScript application for an enterprise client. Using Cucumber JVM, Selenium, Jenkins, and Git - the team was able to catch regression errors during development. We'll provide an overview of the solution used and how it worked in a real-world environment.
Introduction to Selenium | Selenium Tutorial for Beginners | Selenium Trainin...Edureka!
( Selenium Training: https://www.edureka.co/testing-with-selenium-webdriver )
This Edureka tutorial on "Introduction to Selenium" will tell you how testing with Selenium WebDriver works. The following topics have been covered in this tutorial:
1. Pain points of Manual Testing
2. Advantages of Automation Testing
3. Introduction to Selenium
4. Selenium vs other tools
5. Demo: Selenium WebDriver in action
Introduction to Selenium blog: https://goo.gl/b523IO
Incorporating accessibility into your software.
What does accessibility mean?
Why should we do this?
How we should do this?
What impacts does this have?
Description- SOAtest is a testing and analysis tool suite for testing and validating APIs and API-driven applications (e.g., cloud, mobile apps, SOA).[1] Basic testing functionality include functional security testing, simulation and mocking, runtime error detection, web services testing, interoperability testing, WS-* compliance testing, and load testing
Headless CMS – the foundation of modern SEOCory Schmidt
In this talk, Cory Schmidt explains the SEO implications of migrating to a headless CMS. He will use the story of his company's recent migration and its challenges, and the huge impact on organic search...
Free and Open Source web service testing application.
Released in Sept. 2005, Developed by eviware software.
Built entirely on java platform & uses swing for UI.
Soap UI Pro is the commercial enterprise version.
Latest version 4.5.1
Including Everyone: Web Accessibility 101Helena Zubkow
Shouldn’t the web be awesome for everyone? That's not always the case, but it could be.
Designed for developers, project managers, and directors alike, the goal of this session is to introduce everyone to the wonderful world of web accessibility. We'll cover the basic standards and regional expectations for accessibility, as well as the principles and concepts that make up the accessibility field. This session will touch on Section 508, WCAG 2.0 standards, and the financial viability of a web accessibility initiative in an industry where time is money.
This session is proposed as a conceptual prelude to our more developer-oriented accessibility session that is taking place at the Higher Ed Summit. Based on my experience as a web accessibility specialist from both the perspective of a project manager and a front-end developer, I'll share the knowledge I've gained with you to address the following important questions:
- What is web accessibility?
- Why does web accessibility matter to my users?
- Why does web accessibility matter for my company and clients?
- How will a web accessibility initiative affect my bottom line?
- How can I include web accessibility in my company's culture and work plans?
- What tools can I use to assess and improve accessibility in my projects?
- How can I help the web accessibility community?
What are web services?
Component of web services
Architecture
Operations in web service architecture
Diagram of web service architecture
Types of web services
What is SoapUI
SoapUI test structure
It's just as important that you follow the right approach to integration, as well as using the right technology. We'll start this session by exploring MuleSoft's API-led approach to connectivity, and then use demos to bring to life the tooling in the Anypoint Platform that allows you to design and build your integration applications quickly and easily.
Join us for an overview of behavior-driven development and test automation, which aided in the production of a Visualforce/JavaScript application for an enterprise client. Using Cucumber JVM, Selenium, Jenkins, and Git - the team was able to catch regression errors during development. We'll provide an overview of the solution used and how it worked in a real-world environment.
Introduction to Selenium | Selenium Tutorial for Beginners | Selenium Trainin...Edureka!
( Selenium Training: https://www.edureka.co/testing-with-selenium-webdriver )
This Edureka tutorial on "Introduction to Selenium" will tell you how testing with Selenium WebDriver works. The following topics have been covered in this tutorial:
1. Pain points of Manual Testing
2. Advantages of Automation Testing
3. Introduction to Selenium
4. Selenium vs other tools
5. Demo: Selenium WebDriver in action
Introduction to Selenium blog: https://goo.gl/b523IO
Incorporating accessibility into your software.
What does accessibility mean?
Why should we do this?
How we should do this?
What impacts does this have?
Tech Talks @NSU: Организация тестирования в IT-компаниях Академгородка. Карье...Tech Talks @NSU
http://techtalks.nsu.ru
5 апреля 2012. Организация тестирования в IT-компаниях Академгородка. Карьерный путь тестировщика (Мария Колчинская, AcademSoft)
«Мария Колчинская (AcademSoft) рассказывает о процессах тестирования и карьере тестировщика»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Solit 2013, Эволюция тестирования на Selenium, Мычко Алексейsolit
Алексей Мычко, Минск, компания JazzTeam, Software Engineer (test automation)
«Эволюция тестирования на Selenium». Лекция и мастер-класс. Development секция. Для заинтересованных.
Для автоматизации web-приложений самым популярным средством является Selenium. Этот продукт дает возможность создавать как очень простые тесты, так и сложные тестовые фреймворки, позволяющие тестировать системы любой сложности.
В мастер-классе будет наглядно показано создание следующих видов тестов:
- с использование программ, генерирующих тесты по манипуляциям с браузером
- тесты в стиле процедурного программирования
- тесты в стиле объектно-ориентированного программирования
- тесты на DSL (Domain Specific Language) языке
Презентация на комплексную тему Continious integration-Automated Testing-Agile, показывается связи между этими темам, обоснование автоматического тестирования , и вложения ресурсов для развертывания автоматического тестирования и непрерываной интеграциия. Все темы тесно связаны между собой , хотя бы появились независимос друг от друга.
Презентация, раскрывающая принципы функционирования сети электронных библиотек (ЭБС)Вивальди. Документ описывает как создать электронную библиотеки с помощью Vivaldi. Гибкость подключения, надежность хранения данных в собственном data-центре. С помощью применения интересной идеи организовано подключение каталогов пользователей.
Настоящий документ включает в себя технические требования на создание и внедрение веб-портала (далее — Портал) автоматизированной системы экологического мониторинга (АСЭМ). Портал предназначен для автоматизации процесса сбора, хранения, обработки и предоставления экологической информации, в том числе обобщенной оценки экологической ситуации, в свете решения приоритетных для Краснодарского края экологических проблем. Портал предназначен для Краевого информационно-аналитического центра экологического мониторинга Краснодарского края (КИАЦЭМ), являющегося единым информационным центром системы государственного экологического мониторинга на территории Краснодарского края.
Настоящий документ включает в себя технические требования на создание и внедрение модульной системы контроля, диспетчеризации и управления удаленными объектами Protector.
Цели работы:
• Разработка ПО серверной части ММ.
• Разработка ПО оконечного устройства на основе ARM-микрокомпьютера.
• Разработка ПО микроконтроллера для ППК — функционального аналога «Сигнал 10».
• Разработка защищенного протокола передачи данных по шине RS-485.
• Разработка протоколов передачи данных между компонентами системы в локальной сети и сети Интернет.
• Разработка драйверов для USB-устройств в случае необходимости.
• Разработка структуры хранения данных.
• Разработка ПО АРМ диспетчера.
• Разработка ПО администратора.
• Разработка ПО для управления RS-устройствами (кроссплатформенное).
• Внедрение ПО для просмотра видео с сервера видеонаблюдения (кроссплатформенное).
• Разработка Мессенджера (кроссплатформенный).
• Разработка ПО для модуля оповещения.
• Разработка ПО для модуля геопозиции.
• Разработка ПО для модуля связи.
• Разработка проектной документации и инструкции пользователей.
• Опытная эксплуатация и внедрение в коммерческую эксплуатацию.
Модуль базы данных работает с выбранной информационной базой. Протестированы и поддерживаются форматы и протоколы Access, SQL Server 2005 в редакциях Express и Enterprise, Oracle Database Server. Совместимость достигается через документальные требования по осуществлению взаимодействия с БД . Доступ реализуется по принципу «один код — три базы». Подключаемый модуль содержит XML-описание собственных таблиц, корректируемых при отклонениях в соответствии с манифестом. Администратор или наладчик получает преимущества подключения дополнительных таблиц и полей. Создать манифест можно вручную или при помощи специальной утилиты. Есть идеи разработки редактора данных, позволяющие настраиваться на предоставленную структуру.
Для программного обеспечения становится безразличен выбор базы в качестве хранилища. Клиент решает в соответствии с конкретными стандартами.
Модуль конфигурации позволяет провести импорт и экспорт данных в XML. Посмотрим на систему глазами заказчика. Клиент хочет получить данные в читаемом и понятном виде. Для измерительной системы предлагается использовать по умолчанию eXtensible Markup Language — расширяемый язык разметки.
На практике XML является общепринятым стандартом передачи информации в коммерческих продуктах. Использование формата открывает широкие горизонты для осуществления импорта и экспорта данных.
XML не зависит от платформ и позволяет обмен данными системам, базирующимся на принципиально разных платформах.
XML поддерживается всеми компиляторами.
XML самодокументирован и понятен для программиста, который открыл наши данные впервые.
XML иерархичен и позволяет описывать сложные структуры с неограниченной вложенностью.
XML расширяем. В процессе эксплуатации формата можно добавлять новые элементы. Исключается фатальная несовместимость структуры.
Клиент всегда прав. Если заказчика не устроит XML, можно разработать уникальное хранилище. Благо модульность это позволяет.
Преимущества нового окна.
Дизайн разработан специально для измерительной системы.
Поддержка представлений позволяет программисту корректировать содержимое окна, меняя интерфейс пользователя.
Модули работают в отдельных потоках исполнения команд, что существенно увеличивает производительность. Окно выглядит монолитно, не подвисает при длительных операциях.
Пользователи проходят весь механизм подтверждения прав на ресурсы.
Приложение поддерживает замену Проводника. Никаких лишних файлов. Компьютер используется исключительно как часть аппаратно-программного комплекса.
Целью настоящего проекта является разработка многопользовательского онлайн1 3D-шутера2 от 1-го (3-го) лица с элементами RPG3, ориентированного на аудиторию лиц в возрасте от 7-ми до 40-ка лет и старше, заинтересованных в истории развития современного вооружения и военной техники стран мира. Следует отметить, что термин шутер лишь частично подходит для описания данного проекта, в виду того, что вооружение, экипировка, техника и прочие элементы игры подбираются и моделируются максимально приближёнными к реальности, что позволяет в какой-то степени отнести проект к термину симулятор4.
Термин «онлайн» – означает, что игра будет доступна только при активном подключении к сети интернет. Игроки будут подключаться к игре посредством специального приложения-клиента и сражаться друг с другом. В игре будут только реальные противники, без искусственного интеллекта.
3D-шутер (англ. shooter — стрелялка) — жанр компьютерных игр. Название произошло совмещением понятий «3D» (три измерения) и shooter (англ. стрелок). На момент зарождения жанра укрепилось слово «шутер», как вариант описания игрового процесса и перевод для слова shooter.
Симулятор - имитатор, механический или компьютерный, имитирующий управление каким-либо процессом, аппаратом или транспортным средством. Чаще всего сейчас слово «симулятор» используется применительно к компьютерным программам (обычно играм). Симуляторы — программные и аппаратные средства, создающие впечатление действительности, отображая часть реальных явлений и свойств в виртуальной среде.
Слайд № 8. Перспективные разработки
Следующие этапы помогут усовершенствовать системы.
1. Устройство «Умная машина», устанавливаемое в автомобиль. Автоматически делает транспортное средство частью социальной сети. Автомобиль регистрируется, отражается на карте. Мобильное приложение выводится на консоль. Социальная сеть становится противоугонной системой, средством удаленной диагностики и коммуникации.
2. Возможность удаленной оценки стоимости ремонта или консультации. Данный сервис даст возможность ремонтным мастерским получать дополнительных клиентов.
3. Построение народных карт и геоинформационных систем.
4. Инвентаризация пропускной способности, качества дорог и дорожного покрытия.
5. Прокладка маршрута и навигация, аналогичная Google Navigation.
Цель использования указанного программного продукта: информирование и оповещение населения о риске чрезвычайных ситуаций.
Вестник МЧС полезен в случаях, когда пользователь изолирован от средств централизованного оповещения (радио, телевидение). Например, находится в своей квартире с выключенными радио и телевизором.
Ввиду широкого распространения интеллектуальных мобильных устройств и мобильного Интернета информация может легко транслироваться на телефоны заинтересованных пользователей, причем с учетом их географического положения или интересующего региона.
Автоматические оповещения позволят информировать пользователей о пожарах, террористических актах, наводнениях, ураганах, цунами, лавинах, блокировании дорог, техногенных катастрофах и других неприятностях жизни, подстерегающих нас на каждом шагу. Вестник даст возможность населению планировать жизнь с учетом непредвиденных ситуаций. Мы будем счастливы, если программный продукт спасет хотя бы одну жизнь.
Система будет работать в трех режимах.
1) Информирование населения.
2) Оповещение населения.
3) Экстренные оповещения.
3. ПРОЦЕСС ЛИЦЕНЗИРОВАНИЯ
3.1. В центр лицензирования предоставляется информация о списке модулей с контрольными суммами файлов и идентификатором компьютера. В ответ на файл, сгенерированный на весах, посылается лицензионный файл, который привязывает текущую конфигурацию ПО к весам.
1. EDISON. Центр разработки программного обеспечения
+7 (499) 500-14-94
http://www.edsd.ru
site@edsd.ru
1
ПЛАН ТЕСТИРОВАНИЯ
КЛИЕНТ-СЕРВЕРНОЙ СИСТЕМЫ
2. EDISON. Центр разработки программного обеспечения
+7 (499) 500-14-94
http://www.edsd.ru
site@edsd.ru
2
ОГЛАВЛЕНИЕ
1. ВВЕДЕНИЕ.................................................................................................................................................................................... 3
1.1. Цели тестирования........................................................................................................................................................... 3
1.2. Стратегии тестирования.................................................................................................................................................. 3
1.3. Виды тестирования.......................................................................................................................................................... 3
1.4. Документирование........................................................................................................................................................... 5
2. ЦИКЛ ТЕСТИРОВАНИЯ............................................................................................................................................................. 6
2.1. Срочная активность......................................................................................................................................................... 6
2.2. Тестирование релиза........................................................................................................................................................ 6
2.3. Ежедневная активность................................................................................................................................................... 6
2.4. Разработка новых тестов................................................................................................................................................. 7
2.5. Полугодичная активность............................................................................................................................................... 7
3. ТЕСТОВЫЙ СТЕНД..................................................................................................................................................................... 7
3.1. Планировщик задач автоматизированного тестирования............................................................................................ 7
3.2. Конфигурации оборудования ......................................................................................................................................... 8
3.3. Конфигурации и расположение данных ........................................................................................................................ 8
3.4. Тестируемые компоненты............................................................................................................................................... 8
3. EDISON. Центр разработки программного обеспечения
+7 (499) 500-14-94
http://www.edsd.ru
site@edsd.ru
3
1. ВВЕДЕНИЕ
В настоящем плане тестирования описаны и определены стратегия и принципы тестирования, применяемые при
тестировании системы удаленного доступа. План будут использовать исполнители работ для получения представления о
тестировании на проекте. Документ определяет распределение обязанностей при тестировании и описывает тесты,
намеченные к выполнению.
План тестирования разработан для решения следующих задач.
• Спланировать управление тестированием и техническую поддержку тестирования в ходе всего
жизненного цикла разработки системы.
• Определить исчерпывающий план тестирования, который описывает природу и рамки тестирования,
достаточные для достижения целей и решения задач тестирования в проекте.
1.1. Цели тестирования
Основными целями тестирования являются:
• обеспечение выполнения всех системных требований и критериев, установленных к программному
продукту;
• повышение вероятности того, что приложение при любых обстоятельствах будет функционировать
надлежащим образом и соответствовать установленным требованиям за счет обнаружения максимально
возможного числа дефектов;
• обеспечение работоспособности каждого разрабатываемого модуля согласно спецификации требований к
данному модулю;
• обеспечение работоспособности всей системы в целом согласно спецификации требований к системе;
• обеспечение отказоустойчивости системы и каждого отдельного модуля;
• обеспечение установленных параметров производительности;
• обеспечение нормального качества исходных материалов и исходных кодов;
• оперативное информирование заинтересованных лиц об уровне качества регулярных сборок;
• обеспечение пользователя наиболее удобным графическим интерфейсом.
1.2. Стратегии тестирования
Основными задачами тестирования являются:
• проведение функционального тестирования каждого модуля и компонента системы для обеспечения его
соответствия функциональным требованиям;
• проведение комплексного тестирования для обеспечения взаимодействия модулей и компонентов друг с
другом согласно требованиям к системе;
• определение и максимальное увеличение производительности системы и каждого отдельного модуля;
• проведение нагрузочного тестирования для обеспечения отказоустойчивости системы и каждого
отдельного модуля;
• максимальная автоматизация процесса тестирования;
• разработка достаточного набора контрольных примеров для тестирования новых модулей и компонентов;
• своевременная разработка контрольных примеров для покрытия устраняемых ошибок;
• увеличение покрытия кода тестовыми примерами;
• тестирование удобства применения модулей, имеющих графический интерфейс.
1.3. Виды тестирования
Для решения указанных выше задач тестирования будут использоваться следующие виды тестирования.
Тестирование — процесс многогранный, и указанные ниже виды могут пересекаться. Конкретный список видов
тестирования для каждого модуля приводится в задании на тестирование.
• Анализ спецификаций требований к каждому модулю и компоненту — подготовка и определение
параметров тестирования каждого отдельного компонента системы.
• Анализ спецификаций требований к системе — подготовка и определение параметров тестирования всей
системы в целом.
• Ручное тестирование — выполнение тестировщиком прохода тестового цикла вручную, с последующей
4. EDISON. Центр разработки программного обеспечения
+7 (499) 500-14-94
http://www.edsd.ru
site@edsd.ru
4
ручной фиксацией результатов по каждому тесту в отчете.
• Автоматизированное тестирование — автоматический проход тестового цикла, с последующим
автоматическим уведомлением заинтересованных лиц о результатах.
• Смешанное тестирование — вариант объединения ручного и автоматизированного тестирования.
Наиболее часто используется в практике.
• Дымовое тестирование — простейший вид тестирования, основанный на определении успешности сборки
системы из ветви исходного кода, находящейся в разработке. Обычно проводится один раз в день.
• Ежедневное тестирование — часть тестового цикла, обязательная к проходу каждый день.
• Модульное тестирование — самый важный вид тестирования, основанный на проверке
работоспособности функций, методов и свойств в условиях их нормального и ошибочного исполнения. Это
тестирование проводится на уровне исходного кода каждого существующего класса. Что нужно тестировать
на данном этапе:
- класс правильно объявлен;
- структура класса соответствует спецификации требований;
- класс имеет достаточную функциональность;
- класс совместим со средствами автоматической обработки кода (построение автодокументации, анализ
покрытия, качества кода и т.п.);
- некорректное функционирование и ошибочные ситуации корректно обрабатываются;
- класс совместим со связанными классами в рамках используемого наследования, полиморфизма,
процедур вызова и т.п.;
- время выполнения, частота выполнения, нагрузка на ресурсы соответствуют требованиям;
- класс не содержит утечек памяти и других ресурсов.
В идеале необходимо покрыть тестами каждую строку исходного кода. Когда продукт находится на ранней стадии
разработки — исправление ошибок обходится гораздо дешевле. По мере продвижения разработки выявление и
исправление ошибок становится все более и более затратным. В большинстве случаев предоставление модульных
тестов является ответственностью разработчика, их создание производится в момент разработки класса.
• Интеграционное тестирование — после разработки тестов на отдельные классы необходимо проверить,
как они будут работать вместе в рамках одного исполняемого процесса. Необходимо проверить, как
соотносятся классы, разработанные по-разному разными разработчиками. Данный вид тестирования
базируется на предыдущем и также производится на уровне исходного кода. Обычно тестовые примеры
строятся на основе вызова одного компонента из другого.
• Сквозное тестирование — проверяет работоспособность компонентов системы на уровне взаимодействия
нескольких отдельных исполняемых процессов. На данном этапе тестируется функционирование клиент-
серверных систем, их взаимодействие внутри и с внешними компонентами. Обычно сквозные тесты
содержатся во внешнем по отношению к системе процессе, который делает тестирующие запросы. Так
проверяются функции макроуровня, надежность, производительность, координация.
• Функциональное тестирование — рассматривает продукт, состоящий из множества классов, процессов,
компонентов, данных как единое целое. На этом этапе проверяется в целом его работоспособность,
функциональные и технические характеристики, а также бизнес-логика. Такая проверка может
осуществляться в нескольких конфигурациях окружения оборудования и наборов данных.
• Тестирование интерфейса — проверка клиентских и административных интерфейсов пользователя на
возможность выполнения с их помощью сценариев использования. Сценарий использования представляет
собой последовательность действий пользователя, которые имитируют его активность при работе с
интерфейсами системы. Сценарий использования должен покрывать спецификацию требований к
пользовательскому интерфейсу. Такое тестирование производится в автоматическом режиме с помощью
специализированных утилит. Тестирование должно проверять корректность работы интерфейсной части
приложения при любых возможных настройках экрана (различное разрешение, масштаб, шрифт), при
изменениях фокуса, при работе с мышью и клавиатурой.
• Нагрузочное тестирование — определение и проверка характеристик производительности системы в
заданной конфигурации оборудования и набора данных.
5. EDISON. Центр разработки программного обеспечения
+7 (499) 500-14-94
http://www.edsd.ru
site@edsd.ru
5
• Тестирование базы данных — проверка функционирования внешней базы данных и хранимых процедур в
соответствии со спецификацией требований. Проверка политики безопасности доступа к базе в
соответствии с ролями системы. Определение и проверка характеристик базы данных, таких как
производительность, среднее время доступа, максимальное количество обслуживаемых клиентов,
минимальная и максимальная длительность обработки запроса и т.п.
• Тестирование безопасности — определение ролей и проверка списка функций системы, доступных для
каждой роли. Может осуществляться на уровне интерфейса, на уровне компонента, на уровне базы данных,
на уровне модуля и на сетевом уровне. Проводится в соответствии с принятым документом «Политика
безопасности». Включает проверку методов шифрования данных при хранении и передаче, отказа доступа к
запрещенным функциям, перехвата данных, подделки удостоверения личности, отказа в обслуживании и
других атак.
• Тестирование удобства использования интерфейса — разработка отчета об удобстве использования,
быстроте освоения, наглядности пользовательских интерфейсов системы. Данный отчет может содержать
предложения по улучшению этих характеристик.
• Тестирование конфигурации — проверка работоспособности системы в заданном окружении
конфигурации оборудования и набора данных.
• Верификация — проверка успешности исправления разработчиком ошибки, проведенная тестировщиком в
тестовом окружении.
• Регрессивное тестирование — повторное выборочное тестирование продукта с модифицированными
частями после исправления ошибки или добавления новой функции. Внесение изменений в исходный код
может повлечь цепочку зависимостей и получение новых ошибок во взаимозависимых функциях. Данный
вид тестирования минимизирует риск подобного события.
• Инспекции и критические просмотры — регулярное или по требованию исследование системы и
отдельных ее компонентов с целью:
- выявления слабых мест;
- определения степени соответствия стандартам и требованиям;
- определения тенденций развития;
- разработки новых архитектурных решений;
- выработки предложений по рефакторингу кода;
- улучшения качественных и функциональных характеристик.
• Анализ исходного кода — регулярное исследование исходного кода с целью определения степени его
соответствия документу «Требования к оформлению исходного кода». Разработка предложений по
рефакторингу.
• Анализ покрытия тестами кода — автоматическое определение областей кода, не затронутых
контрольными тестами, с целью разработки новых тестов для максимизации покрытия.
• Тестирование инсталляции — проверка корректной работы инсталляционного пакета, инсталляционных
сценариев для копирования, обновления и последующей автоматической настройки работоспособности
системы.
• Тестирование документации — проверка документации на полноту описания инструкций пользования в
соответствии с «Требованиями по разработке пакета рабочей документации пользователя и администратора
системы».
• Финальное тестирование релиза — тестирование, проводимое как последняя стадия разработки релиза,
которое обычно состоит из двух частей:
- alpha-тестирование, проводимое в соответствии с формальными требованиями на тестовой площадке
компании разработчика;
- beta-тестирование, завершающая стадия тестирования, возникающая при использовании релиза в
«реальном мире» на площадке компании заказчика.
1.4. Документирование
В процессе разработки и проведения тестовых примеров обязательным является их документирование.
Документация должна в любой момент времени давать следующую информацию:
6. EDISON. Центр разработки программного обеспечения
+7 (499) 500-14-94
http://www.edsd.ru
site@edsd.ru
6
• полный список тестов;
• задание на тестирование каждого компонента;
• список тестов по каждому компоненту;
• каждый пример должен быть хорошо комментирован;
• хронологический архив результатов тестирования.
2. ЦИКЛ ТЕСТИРОВАНИЯ
В данной главе описан процесс тестирования, который состоит из следующих видов активности в порядке
приоритета: срочная внеплановая активность, тестирование релиза, ежедневная плановая активность, разработка
новых тестов, полугодичная активность.
2.1. Срочная активность
Заключается в выполнении тестировщиком срочных поручений менеджера проекта, большая часть из которых
является критическими и блокирует ход разработки.
В данный вид активности также включается проведение верификации критических ошибок и доработок.
Тестировщику следует внимательно подходить к верификации, внесение изменений оказывает влияние на другие
участки кода и может вносить дополнительные ошибки. Необходимо тщательно проверять предполагаемые
зависимые участки кода таким образом, чтобы верификация приближалась к регрессивному тестированию по
каждому инциденту.
Менеджерам следует понимать, что большое количество срочности срывает выполнение плановых работ и ведет к
уменьшению тестирования. Для этого необходимо планировать загрузку и увеличивать ритмичность работы
тестирования.
2.2. Тестирование релиза
Данная процедура носит временный характер, стартуя в момент начала финального тестирования и заканчиваясь
после принятия релиза. Обычно целью тестирования релиза является сдача продукта с определенными
характеристиками к определенному сроку.
Обязательным атрибутом данного вида тестирования является проверка обеспечения функциональных
характеристик продукта в соответствии со спецификацией требований. Для этого проводится тщательный анализ
спецификаций требований к системе в целом и к каждому компоненту.
Важным является определение отличий текущего релиза от предыдущего и проведение по этим отличиям
регрессивного тестирования.
Тестировщик разрабатывает инсталляционный пакет.
В процессе тестирования релиза удостоверяется успешное прохождение предыдущего ежедневного
автоматического теста, выполняется функциональное alpha- и beta-тестирование, производится тестирование
инсталляции и документации, проводятся дополнительные ручные тесты. Также осуществляется консультирование
заказчика по вопросам переноса и внедрения системы.
В процессе тестирования релиза тестировщик открывает новые срочные инциденты.
2.3. Ежедневная активность
Ежедневная активность тестирования заключается в проведении запланированных автоматических тестов на
тестовом стенде.
Каждую ночь производится попытка осуществить сборку системы из исходного кода. Таким образом выполняется
операция «дымового» тестирования. В случае успеха осуществляется автоматический проход запланированных
тестов во всех запланированных конфигурациях. В результате формируется отчет, который рассылается всех
заинтересованным лицам. Сбой дымового тестирования является критической ошибкой и подлежит немедленному
анализу.
В данный вид активности также включается проведение верификации некритичных ошибок и доработок в
соответствии. На каждый открытый инцидент желательно написать тесты, проверяющие его. Повторно
возникающие инциденты должны повлечь за собой разработку дополнительных тестов.
Тестировщик контролирует ход тестирования и получает ежедневный отчет о ходе тестирования. Он управляет
включением тестов, настраивает тестовый стенд, конфигурирует необходимые окружения для проведения тестов.
Тестировщик постоянно анализирует спецификацию требований к системе, технические задания и регулярно
7. EDISON. Центр разработки программного обеспечения
+7 (499) 500-14-94
http://www.edsd.ru
site@edsd.ru
7
выдает рекомендации по улучшению тестирования, а также сообщает разработчикам о расхождениях
функциональности описанной в задании и реальных характеристик системы, если таковые появляются.
Тестировщик осуществляет также дополнительные ручные тесты, которые необходимы. Действия, повторенные
более чем три раза, нуждаются в последующей автоматизации.
Задачей ежедневной активности тестирования является также постоянная автоматизация тестирования.
В процессе усовершенствования системы некоторые контрольные примеры могут перестать выполняться успешно,
например, при изменении пользовательского интерфейса. Поэтому ежедневной задачей тестирования является
анализ причин неудач, обновление и исправление контрольных примеров.
В процессе тестирования тестировщик открывает новые инциденты по результатам тестирования, назначая их
разработчикам.
2.4. Разработка новых тестов
Разработку новых тестовых блоков выполняет разработчик в процессе создания и доработки системы. По
завершении разработки блока тестировщик включает его проход в планировщик задач автоматического
тестирования.
Тестировщик, при наличии времени, также может принимать участие в разработке тестов как разработчик.
Тестировщик может принимать участие в первоначальной разработке базового набора модульных тестов, а также
дополнять список тестов в процессе анализа и улучшения тестирования.
Обычно ответственность за разработку автоматических тестов распределяется следующим образом:
Планировщик автоматического тестирования Тестировщик, разработчик
Дымовое тестирование Тестировщик
Модульное тестирование Разработчик
Интеграционное тестирование Разработчик
Сквозное тестирование Разработчик
Нагрузочное тестирование Разработчик, тестировщик
Тестирование конфигурации Тестировщик
Тестирование базы данных Разработчик, тестировщик
Тестирование безопасности Разработчик, тестировщик
Тестирование интерфейса Тестировщик, разработчик
2.5. Полугодичная активность
Производится один раз в полгода по запросу менеджера или после сдачи очередного релиза. В результате
формируется отчет о текущем положении дел с предложениями по улучшению. Данная активность включает в
себя проведение:
Инспекция и критический просмотр кода Руководитель, проектировщик, главный программист
Тестирование удобства использования интерфейса Тестировщик
Анализ качества исходного кода Тестировщик
Анализ покрытия тестами кода Тестировщик
3. ТЕСТОВЫЙ СТЕНД
3.1. Планировщик задач автоматизированного тестирования
Необходимо разработать программное обеспечение на любом из скриптовых языков, которое позволит
тестировщику конструировать и проигрывать необходимые тестовые последовательности в заданное время.
Данное программное обеспечение осуществляет ежедневную сборку, дымовое тестирование и автоматически
запускает установленные блоки тестирования. Необходимо обеспечить поддержку управления несколькими
компьютерами и различными виртуальными машинами из данного планировщика.
Планировщик обеспечивает интерфейс для формирования отчетов по результатам тестирования. Данные отчета
представляют собой пронумерованный и разделенный список результатов пройденных контрольных примеров. В
8. EDISON. Центр разработки программного обеспечения
+7 (499) 500-14-94
http://www.edsd.ru
site@edsd.ru
8
случае ошибки теста ее текст также сохраняется в отчет. Результатом является успех или код ошибки.
Минимальным заданием является блок тестов. Блок тестов реализуется как отдельный исполняемый файл,
который может содержать модульные, интеграционные, нагрузочные и т.п. тесты.
Необходимо разработать шаблон такого файла. Данный шаблон должен предоставлять функции записи
результатов тестирования для планировщика. Необходимо разработать механизм интеграции средства
автоматизированного тестирования GUI для проведения тестирования интерфейса пользовательских приложений.
После завершения всего тестирования производится автоматическая экспертная оценка по проведенному
тестированию. Отчет анализируется, и формулируется общее заключение. Помимо этого планировщик
предоставляет возможность проведения экспертного анализа. Производится расчет общего процента успехов при
выполнении тестов.
Планировщик осуществляет слежение за запусками, формирует лог запусков и сохраняет результаты каждого
прохода в отдельной папке.
Обработанный отчет высылается по электронной почте списку заинтересованных лиц. Этот список можно
конфигурировать.
3.2. Конфигурации оборудования
Для работы системы требуется следующие тестовые конфигурации серверов и клиентских ПК. Для исполнения
тестовых процедур необходим тестовый стенд, состоящий из двух серверов конфигурации №1, одного сервера
конфигурации №2, по одному ПК конфигураций №2 и №3.
Конфигурация №1 (Сервер):
Конфигурация №2 (Клиент):
Конфигурация №3 (Удаленный клиент — минимальная):
3.3. Конфигурации и расположение данных
Система тестируется в единственном окружении, которое используется у заказчика:
• Сервер SRV1 с установленным массивом данных. IP = x. В тестовом массиве документов 30 шт.
Конфигурация сервера следующая: x.
• Сервер SRV2 с установленным сервером приложений. IP = x. PDFServer установлен в папку x.
Конфигурация следующая: х.
• Клиентский ПК CLI3 с установленными клиентским и административным интерфейсами в папках х.
• Сервер SRV1 подключен к серверу SRV2 напрямую через сетевой интерфейс 1 Gbps.
• ПК CLI3 подключен к SRV2 через свитч 100 Mbps и другой сетевой интерфейс 100 Mbps.
• На сервере SRV2 и клиентском ПК CLI3 запускаются клиентские и административные интерфейсы.
• На сервере SRV2 установлена база данных SQL Server в папке х, имя instance х. Настройки ODBC: х.
• Встроенные брандмауэры отключены.
3.4. Тестируемые компоненты
На основе данного плана формулируются задания на тестирование конкретных модулей в качестве Приложений к
Плану тестирования. Далее идет общий список компонентов:
9. EDISON. Центр разработки программного обеспечения
+7 (499) 500-14-94
http://www.edsd.ru
site@edsd.ru
9
Все тестовые процедуры проводятся на тестовом стенде, компоненты системы тестируются на следующих
конфигурациях:
1 №1, №2
2 №1, №2
3 №1, №2
4 №1, №2
5 №1, №2, №3
6 №1, №2, №3
7 №1, №2
8 №1, №2
9 №1, №2
10 №1
11 №1, №2, №3
12 №1, №2, №3
13 №1, №2, №3
15 №1, №2, №3