Test Your Soft - QA сервис. Тестирование ПО и web приложений.

Скорее всего, раньше вам не приходилось сталкиваться с процессом тестирования. А теперь, когда вы хотите заказать тестирование программы, вам интересно, за что же вы платите деньги? Какие виды тестирования существуют и чем они отличаются? Читаем 

Тест кейсы (Test Cases). Что такое Test Case? На этот вопрос вряд ли можно ответить в двух словах. Тем не менее мы попробуем дать краткую характеристику этому понятию. Итак, для того чтобы выявить тот или иной баг необходимо произвести определенные действия, сравнить полученные результаты с ожидаемыми и сделать вывод о том, имеется баг или нет. Все это и есть Test Case. Тест кейс - это минимальный элемент тестирования. Хороший тест кейс состоит из трех частей: 
  * Привести тестируемый продукт в нужное состояние 
  * Верифицировать то, что подлежит проверке 
  * Привести продукт в исходное состояние 
Существенно то, что акт верификации только один. Именно поэтому тест кейс нельзя измельчить, разбить на несколько тест кейсов. Именно поэтому он является минимальным элементом проверки. Если верификаций больше, чем одна, то это не тест кейс, а его фальсификация. Первый и третий компоненты тест кейса тоже очень важны. Они делают разные тест кейсы независимыми друг от друга. Их можно выполнять в любой последовательности. Это исключительно важно при автоматизации тестирования. Но и для ручного тестирования это тоже важно. Потому что из тест кейсов составляют тест свит (test suite) - группу связанных тест кейсов. Объединение в группу тест свитов приводит к созданию нового тест свита. То есть, тест свит состоит либо из тест кейсов, либо из тест свитов.

Виды тестирования по степени владения знаниями о системе

Собственно, существуют два способа тестирования системы. Самый естественный - тестирование со стороны (black box testing), так, как будто вы ничего не знаете о том, как система устроена. Другой способ тестирование – тестирование т.н. стеклянного ящика (white box testing). Прежде всего это, конечно задача программиста:

Тестирование "черного ящика" (black box testing)  – тестирование на соответствие программного продукта его функциональным спецификациям без знания о внутренней структуре реализации системы;

Тестирование "белого ящика" (white box testing)  – тестирование, проводящееся при наличии исходного кода и технических спецификаций, существенно повышающее качество и достоверность результатов тестирования, и улучшающее качество системы. Этот вид тестирования позволяет провести локализацию ошибок и дефектов, компонентное и корреляционное тестирование, детальный анализ надежности и устойчивости и т.п. Кроме того, возможно построение временных профилей, отражающих точное время, затрачиваемое различными компонентами системы на выполнение различных операций. Тесты строят, стараясь задействовать все ветви в коде.

Тесты можно классифицировать следующим образом:

GUI-тесты  (тестирование графического интерфейса пользователя). Т.е. тестирование интерфейса - экранов, кнопок и т.д. Большая часть функциональности ПО реализуется, как правило, через пользовательский интерфейс.

Функциональное тестирование.  Подразумевает воспроизведение действий пользователя для решения поставленной задачи с проверкой реакции ПО на эти действия. Функциональное тестирование – это проверка правильности функционирования системы. Обычно проверяется выполнение test cases. Правильное получение, обработка и выдача данных, функционирование бизнес правил. Использует black box testing . Работа ведется посредством взаимодействия с GUI.
Цель: проверить правильность работы системы, включаю навигацию, ввод, обработку и вывод данных.
Метод: выполнение тестов с использованием валидных и невалидных данных чтобы проверить:
  * Правильную работу, когда вводятся правильные данные 
  * Корректную обработку ошибок (предупреждение или error) если введены неправильные данные 
  * Корректную отработку бизнес правил.

Unit–тестирование  – тестирование отдельных компонентов, изолируя модули от их реального окружения. Эти тесты служат для проверки правильности работы отдельных модулей системы, как правило - классов. Использует white box testing.

Тестирование производительности  – тестируются характеристики, связанные со скоростью обработки данных, пропускной способностью, количеством одновременно обслуживаемых запросов.

Нагрузочное тестирование (стресс-тесты). Т.е. тестирование в экстремальных условиях (нехватка памяти, дискового пространства, одновременное использование большим числом пользователей, функционирование в непрерывном режиме и т.д.). В эту группу относят тесты на заведомо дефектном ("условно рабочем") оборудовании.

Конфигурационное тестирование (Configuration Testing) - работа при различных конфигурациях системы – заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.

Инсталляционное тестирование (installation testing). Проверить корректную установку системы при различных условиях с софтом и хардом: недостаток места на диске, недостаточные системные требования, отсутствие привилегий создания директорий и т.д. Проверка работы системы при апргрейде со старой версии на новую, так же как и установки с нуля. Установка в различных локализациях.

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

Тесты Регрессии (или Regression Test Pass).  Под этим понятием объединяют те тесты, которые уже проводились с предыдущими версиями программы, притом успешно, т.е. не выявили багов и были отмечены как pass (passed). Необходимость проведения таких тестов очевидна. Приведем пример. Допустим, что ранее проведенный тест № 2, который обеспечивал проверку в программе участка кода (назовем его условно кодом-А) не выявил ошибок в программе, и был отмечен как pass. В ходе разработки возникла необходимость изменить участок кода-А (например, при исправлении какого либо иного бага или же придания программе новой функциональности). В результате этот участок кода требует дополнительной проверки, что и будет сделано при повторном проведении теста № 2. Среди Собственно Тестов Регрессии можно выделить две группы. Первая - тесты, входящие в набор (т.н. Regression Test Pass with Regression Test Suit), другие - тесты не входящие в набор (т.н. Regression Test Pass without Regression Test Suit). Существенные отличия между ними в следующем: первые - вносятся в базу и описываются, для них могут и должны быть созданы скрипты, которые позволяют автоматизировать процесс тестирования; вторые - существуют только "в голове" тестировщика и проводятся вручную, причин этого может быть много - от малых сроков тестирования, до отсутствия необходимого ПО, для автоматизации процесса.

Тесты регрессии на "закрытых" багах.  Рассмотрим пример. Допустим, что тест № 3, выявивший баг, после исправления этого бага разработчиком был проведен повторно, при том успешно. Тест был отмечен как pass, а баг - как Verified. Такой баг откладывается "на полку", "дело" закрыто. Такой баг и будет "закрытым". Допустим теперь, что в ходе разработки, участок кода, где был исправлен этот баг был изменен, или сменился разработчик, который случайно удалил "нашлепку" в коде исправлявшую этот глюк и показавшуюся ему лишней и т.п. В этом случае баг проявится снова. Что бы не допустить подобного, тестеру время от времени необходимо проводить тесты, выявлявшие ранее баги в измененном участке кода, исправление которых уже было проверено ранее и зафиксировано в базе. Это и есть Тесты регрессии на "закрытых" багах.

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

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

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