2. Краткие сведения об истории компании

1992 г. - Основание компании на базе кафедры «Теория цепей и телекоммуникаций» Нижегородского технического университета.

1993 г. - Реализация первого крупного проекта в сфере оффшорного программирования (контракт с международной корпорацией Harris).

2000 г. - Разработка и внедрение первого собственного продукта компании (системы мониторинга линейно-кабельных сооружений и инфраструктуры сетей связи).

2005 г. - Выход на рынок системной интеграции (внедрение системы HP IUM в ОАО «Уралсвязьинформ»).

2008 г. - Начало деятельности по внедрению цифровых технологий телерадиовещания (оснащение парламентского центра в г. Екатеринбург, создание вещательного канала в г. Барнаул).

4 Тестирование

Лекция 1

Software Bug

Примеры известных ошибок (багов) в ПО:

• [Считаем одинаково!] Mars Climate Orbiter Crashes (1998)

• [Семь раз отмерь…] Therac-25 Medical Accelerator (1985)

• [Правила округления] Patriot Missile Bug (1991)

• [Ошибки тоже важны] The Ping of Death (1995)

• [Не все игры безобидны] EVE Online: Trinity (2007)

Что такое баг?

• Defect

• Fault

• Problem

• Error

• Incident

• Anomaly

• Variance

• Failure

• Inconsistency

• Feature

• Bug

Software bug: формальное определение

1. The software doesn’t do something that the product specification says it should do

2. The software does something that the product specification days it shouldn’t do

3. The software does something that the product specification doesn't mention

4. The software doesn’t do something that the product specification doesn’t mention but should

5. The software is difficult to understand, hard to use, slow, or – in the software testers eyes – will be viewed by the end user a just plain not right

Зачем нужно тестирование?

• Для улучшения качества продукта

• Поставка качественного (работоспособного, соответствующего требованиям, ожидания) ПО заказчику

• Для обеспечения соответствия продукта и его качества реальным нуждам заказчика

• Чтобы конечные пользователи могли работать с продуктом

• Чтобы понимать, насколько продукт соответствует предъявляемым к нему требованиям

• Чтобы минимизировать количество найденных дефектов заказчиком в поставленном продукте

• В узком смысле – предоставить информацию о несоответствиях программы требованиям, в широком – повысить качество продукта

• Собрать информацию о продукте (и позитивную и негативную), которая будет важна для «заказчика тестирования»

Software Testing: Термины и определения

• Verification and Validation

• Quality and Reliability

• Testing and Quality Assurance

Какие ожидания?

• Позитивные:

  • 2+2 = 4

• Негативные:

  • 10/0 = ошибка «На ноль делить нельзя»

• Исследовательские

  • Что будет, если перемножить максимально допустимые числа?

Что проверяем?

• Функционал

  • Добавленный товар попадает в корзину?

• Производительность

  • Как быстро открывается страница?

• Нагрузка

  • Могут ли 100 пользователей сделать заказ одновременно?

• Окружения

  • Работает ли всё в Opera, IE, FF?

• Совместимость

  • Работает ли магазин при

использовании различных плагинов?

• Удобство использования

  • Насколько понятно, как купить товар?

Какую часть проверяем?

Всю программу

• Мессенджер функционирует как ожидается

Модуль

• После регистрации в системе, в БД добавляется информация о пользователе (модуль регистрации)

Интеграцию модулей

• Если добавить запись в условленном

формате в БД, пользователь может

войти в систему (интеграция

регистрации и входа)

Участники программного проекта

• Project managers, program managers, or producers

• Architects or system engineers

• Programmers, developers, or coders

• Testers or QA (Quality Assurance)

• Technical writers, technical support

Что тестировщики могут сделать для успеха продукта?

• Сохранять здравый рассудок в творческой обстановке ИТ-проекта

• Хорошо знать продукт и то, как его используют клиенты

• Находить ошибки в продукте

• Помогать разработчикам исправлять ошибки

• Тестировать проектную документацию

• Предоставлять руководству всю необходимую для принятия решений информацию

• Оценивать качество продукта

• Выявлять способы улучшения продукта

• И много других не менее важных задач!

Аксиомы тестирования

• Тестирование не может показать, что программа не содержит ошибок

• The more bugs you find, the more bugs there are J

• Пестицидный парадокс

• Продуктовая спецификация никогда не бывает завершённой

Нефункциональное тестирование

• Performance testing (Тестирование производительности)

• Load testing (Нагрузочное тестирование)

• Reliability (Тестирование надежности)

• Volume testing (Объемы данных)

Производительность. Что измерять?

• Скорость выполнения действий и сравнение результата с требованиями

• Скорость выполнения действий c разными параметрами/ настройками в разных условиях

Производительность – загрузка ресурсов. Что измерять?

Анализируем загрузку ресурсов

• Что загружено на 100% (bottleneck)?

• Хоть что-то загружено на 100% (оптимальная загрузка ресурсов)

• Какое отличие по загрузке от других параметров?

Производительность – правила успеха

• Тщательный преданализ

  • Что измерять

  • С какими настройками

  • В каких условиях

• Точное измерение

• Тщательный постанализ

  • Причины отличий

  • Что (не)корретно?

Нагрузочное тестирование – Клиент-серверное ПО

• Работа ПО с большим количеством подключений

• С разными параметрами/ настройками

• В разных условиях

• Разные проверки

  • Функционала

  • Производительности

Нагрузочное тестирование – Интернет-магазин

• Функционал:

  • Просмотр товаров

  • Добавление в корзину

  • …

• Нефункциональные требования не зафиксированы

• Что проверять для нагрузочного тестирования?

Нагрузочное тестирование – правила успеха

• Преданализ

  • На каких действиях тестировать?

  • Сколько подключений?

  • С какими условиями?

• Автоматизированное измерение

• Постанализ

  • На каких значениях отклонения?

  • Насколько критичны отклонения?

Тестирование надежности – когда и зачем

• Серверные-приложения («Марафонцы»)

• Максимально приближенные к реальным условия

• Регулярные замеры производительности

Тестирование больших объемов – когда и зачем

• Большие объёмы данных

  • Большие файлы

  • Большие записи

  • Большие числа

  • Большие тексты

• Для проверки работы ПО в максимально страшных условиях использования

Нефункциональное тестирование – когда и зачем

• Должно проводиться как можно раньше

• Цель – не «сломать», а «изучить»

• Требует детальный анализ

  • Что можно и что нельзя?

  • Что влияет?

  • Где границы?

Compatibility testing или тестирование совместимости - метод, основной целью которого является обеспечение качественной работы конечного продукта с другим программным обеспечением, окружением.

Программное окружение может состоять из всех или нескольких перечисленных ниже элементов:

• Пропускная способность сетевого оборудования

• Совместимость перифейрийного оборудования (принтер, DVD-драйв и др.)

• Операционные системы (Windows-версии, Linus, UNIX и др.)

• Базы данных (MS SQL, MySQL, Oracle, Sybase и др.)

• Другое системное ПО (Веб-браузеры, сетевые/messagin-программы и др.)

нальное тестирование

В тестировании ПО, recovery testing или тестирование возможности к восстановлению - это активность по тестированию того, как хорошо приложение может восстанавливаться к нормальному состоянию после падений, проблем с оборудованием и других подобных проблем.

Примеры recovery testing:

• Перезагрузить компьютер, пока приложение работает, после этого проверить валидность данных с которыми приложение работает.

• Пока приложение принимает данные из сети, выдернуть сетевой кабель. После некоторого времени, вставить кабель назад и проверить, что приложение без проблем сможет восстановить соединение и продолжить прием данных с того же момента, когда соединение пропало.

Стресс-тестирование - один из видов тестирования ПО, которое оценивает надежность и устойчивость системы в условиях превышения пределов нормального функционирования. Стресс-тестирование особенно необходимо для "критически важного" ПО, однако также используется и для остального ПО. Обычно стресс-тестирование лучше обнаруживает устойчивость, доступность и обработку исключений системой под большой нагрузкой, чем то, что считается корректным поведением в нормальных условиях

Пример:

Веб-сервер можно стресс-тестировать используя скрипты, боты, либо специальное ПО для DoS для получения информации о производительности сервера в условиях пиковой нагрузки.

Тестирование окружения – тестирование оборудования на предмет устойчивости к действию агрессивной внешней среды, например:

• экстремально высокие и низкие температуры

• большое изменение температуры за короткий промежуток времени

• условия высокой и низкой влажности

• устойчивость к вибрации

• солнечная радиация

• высокое и низкое давление

• работа под различными углами

• ускорение

• песок, пыль, соль… плесень.

Тестирование безопасности - оценка уязвимости программного обеспечения к различным атакам.

Тестирование безопасности проверяет фактическую реакцию защитных механизмов, встроенных в систему, на проникновение. В ходе тестирования безопасности испытатель играет роль взломщика. Ему разрешено все:

• попытки узнать пароль с помощью внешних средств;

• атака системы с помощью специальных утилит, анализирующих защиты;

• подавление, ошеломление системы (в надежде, что она откажется обслуживать других клиентов);

• целенаправленное введение ошибок в надежде проникнуть в систему в ходе восстановления;

• просмотр несекретных данных в надежде найти ключ для входа в систему.

Тестирование масштабируемости – тестирование возможности ПО на предмет возможности увеличения или уменьшения каких-либо его показателей. Примером подобных показателей может быть увеличение поддерживаемой нагрузки, увеличение поддерживаемых транзакций, либо изменение объема поддерживаемых данных

Юзабилити-тестирование - эксперимент, выполняемый с целью определения, насколько хорошо люди могут использовать некоторый искусственный объект (такой как веб-страница, пользовательский интерфейс или устройство) для его предполагаемого применения, то есть юзабилити-тестирование измеряет юзабилити объекта. Юзабилити-тестирование сосредоточено на определённом объекте или небольшом наборе объектов, в то время как исследования взаимодействия человек-компьютер в целом - формулируют универсальные принципы.

Installation testing – вид тестирования, сконцентрированный на проверке процесса, необходимого совершить пользователю для того, чтобы установить новое ПО на оборудование. Данный вид тестирование также может включать в себя полное, либо частичное тестирование установки, а также обновление ПО.

• Встроенный текст и графика

• Маркетинговые материалы, реклама и другое

• Гарантии/регистрационные материалы

• Лицензионное соглашение (EULA)

• Инструкции по установке

• Руководство пользователя

• Online-помощь

• Примеры, шаблоны

• Сообщения об ошибках

Локализационное тестирование – часть процесса тестирования, сконцентрированная на проверке аспектов локализации. Локализация – это процесс адаптирования приложения к конкретному региону. Локализация включает в себя перевод пользовательского интерфейса на определенный язык, а также адаптирование изображений и графики к специфике определенной культуры. Локализация также может включать в себя перевод материалов документации.

Тестирование интероперабельности (англ. interoperability — способность к взаимодействию) - тестирование способности программного продукта выполнять набор функций, определённых в его внешнем описании и удовлетворяющих заданным или подразумеваемым потребностям пользователей.

Цели функционального тестирования ПО:

Цель №1 (техническая)‏

• Определить соответствие ТЗ с полученным продуктом

• Исследовать соответствие ТЗ с реальными требованиями заказчика

Цель №2 (финансовая)‏

• Минимизировать финансовые затраты на разработку продукта

• Максимально содействовать выходу качественного продукта

Источник знаний для функционального тестирования

Источник №1 (документация)‏

• Техническая документация на ПО

• Спецификация/требования/ТЗ на ПО

• Руководство пользователя

Источник №2 (люди)‏

• Поддержка пользователей

• Архитекторы

• Разработчики ПО

Когда начинаем тестировать, что тестируем?

Начинаем тестировать

• Зависит от стандартов организации конкретной компании

• Может начинаться с момента напсиания ТЗ

Что тестируем

• Тестируем ПО

• Тестируем документацию

Масштаб функционального тестирования

Модульное (элементарное) тестирование:

• Проверка граничных вх./вых. параметров

• Позитивные/негативные проверки

• Проверка классов эквивалентности

• Исследовательская проверка

Интегральное (integration) тестирование:

• Проверка комбинацийй граничных вх./вых. параметров

• Позитивные/негативные проверки

• Проверка классов эквивалентности

• Исследовательская проверка

Системное (system) тестирование:

• Проверка граничных вх./вых. параметров

• Позитивные/негативные проверки

• Проверка классов эквивалентности

• Исследовательская проверка

Этапы функционального тестирования

• Инсталляционное (installation) тестирование

  • Выполняется при завершении разработчиками работы над очередной версией программы

  • Длительность не превышает одного дня

  • Предназначено для выявления ошибок на этапе инсталляции и проверяет наличие установленных файлов и их версии

• Приёмочное (smoke/sanity/acceptance) тестирование

  • Выполняется после инсталляционного тестирования

  • Длительность не превышает одного дня

  • Предназначено для выявления наиболее принципиальных ошибок

• Тестирование свежих починенных дефектов/улучшений (bugfix)‏

  • Выполняется после приёмочного тестирования

  • Длительность не превышает одного дня

  • Предназначено для проверки починенных ошибок и выявление новых дефектов, связанных с починкой

• Регресионное (regression) тестирование

  • Выполняется после проверки починенных дефектов

  • Длительность зависит от сложности проекта

  • Предназначено для проверки наиболее «тонких» мест в ПО, проверки давно починенных дефектов

• Функциональное (functional) тестирование

  • Выполняется после проверки починенных дефектов

  • Длительность зависит от сложности проекта

  • Предназначено для наиболее полного тестирования продукта

Функциональное тестирование

Метод прозрачной коробки (white/glass box)‏

• меняется разработчиками для тестирования модулей и их взаимодействия (автоматическое тестирование)‏

• Применяется тестовыми инженерами для тестирования продукта без графического интерфейса (GUI)‏

Достоинства метода

• Детальное тестирование модулей

• Хорошее тестирование взаимодействия модулей

Недостатки метода

• Плохое тестирование системы в целом

• Взаимодействие процессов во времени

• Взаимодействие ПО с разной конфигурацией РС

Метод чёрного ящика (black box)‏

Применяется тестовыми инженерами для тестирования продукта

Достоинства метода

• Хорошее тестирование системы в целом

• Хорошее тестирование взаимодействия модулей

Недостатки метода

• Модульное тестирование системы укрупнено

  • За модуль принимается некоторая базовая функция, которая в коде может состоять из многих программных модулей

  • Состав программных модулей неизвестен

Метод серого ящика (grey box)‏

Применяется тестовыми инженерами для тестирования продукта

Достоинства метода

• Хорошее тестирование системы в целом

• Хорошее тестирование взаимодействия модулей

• Хорошее модульное тестирование системы укрупнено

  • За модуль принимается некоторая базовая функция, которая в коде может состоять из многих программных модулей

  • Состав программных модулей известен

Типовые проверки функциональног тестирования

Графический интерфейс (GUI)‏

• Что проверять

  • Граничные условия

  • Неверный тип входных данных (строка/число, язык)‏

  • Данные за границей допустимого или неправильные

  • Неверный формат данных (дата, целое/дробное и т.п.)‏

  • Недопустимые символы (в имени пути на диске)‏

  • Работа с разными региональными настройками

  • +Соответствие ТЗ

• Что знать

  • ТЗ как работает часть программы в штатном режиме

  • Как программа должна реагировать на нештатные ситуации

Типовые проверки функциональног тестирования

База данных (DB)‏

• Что проверять

  • То же что и в тестировании GUI

  • Соответствие вводимых данных и данных в БД при настройке разных региональных настроек форматов данных

  • Выявить наличие/отсутствие “мусорных” записей которые могут появиться в результате выполнения ПО

• Что знать

  • ТЗ как работает часть программы в штатном режиме

  • Как программа должна реагировать на нештатные ситуации

  • Язык запросов SQL

Запись/чтение файлов (cifs/ftp)‏

• Что проверять

  • Корректность записи/чтения в штатной ситуации

  • Корректное поведение при указании неверных параметров для записи/чтения

  • Корректность данных записываемых/считываемых в файл

  • +Соответствие ТЗ

• Что знать

  • ТЗ как работает часть программы в штатном режиме

  • Как программа должна реагировать на нештатные ситуации

Утилита способная проверить метаданные, состав файлов

Работа с оборудованием

• Что проверять

  • Корректность выполняемой операции оборудования и корректность отклика в штатной ситуации

  • Отсутствие реакции или корректная реакция оборудования в нештатной ситуации со стороны ПО

  • +Соответствие ТЗ

• Что знать

  • ТЗ как работает часть программы в штатном режиме

  • Как программа должна реагировать на нештатные ситуации

  • Протокол работы оборудования/логику работы оборудования