К основному контенту

Хочешь хороший продукт? Знай азы качественной проверки :)

В наши дни информационные технологии развиваются стремительно. Но мало кто задумывается, что, прежде чем новому ИТ продукту выйти в свет, необходимо пройти жизненный цикл его разработки. Одним из важных этапов которого является тестирование.
Что такое тестирование? Из чего оно состоит? На сколько необходимо? Мало тех, кто действительно хорошо знаком с тестированием, и знает всю сложность этого процесса.
                                            
         Что же понимается под словом тестирование? Тестирование программного обеспечения — процесс анализа программного средства и сопутствующей документации с целью выявления дефектов и повышения качества продукта. 
Процесс тестирования состоит из:
- планирование и управление;        
- анализ и проектирование;
- внедрение и реализация;
- оценка критериев выхода и создание отчетов;
- действия по завершению тестов.
В процесс тестирования также входит рецензирование документации (включая исходный код) и проведение статического анализа.
Планирование тестирования включает в себя определение целей тестирования и описание задач тестирования для достижения этих целей. А управление тестированием представляет собой постоянный контроль текущего положения дел и соответствие их с планом, и отчетность о состоянии дел, включая отклонения от плана.
Анализ и проектирование тестов состоит из воплощения общих целей тестирования в тестовые условия и тестовые сценарии.
Хорошим считается тест, который имеет высокую вероятность обнаружения еще не выявленной ошибки. Удачным – обнаруживает еще не выявленную ошибку. 
Реализация и выполнение тестов – это деятельность, где процедуры тестирования или автоматизированные сценарии задаются последовательностью тестовых сценариев, а также собирается любая информация, необходимая для выполнения тестов, разворачивается окружающая среда, и запускаются тесты. 
Оценка критериев выхода состоит из оценивания выполнения тестов согласно определенным целям и выполняется для каждого уровня тестирования.
Действия по завершению тестирования осуществляются для сбора данные  о завершенных испытаниях для  объединения опыта, тестового обеспечения, фактов и цифр.        
Само по себе тестирование – это не отдельный процесс. Он связан с другими работами по разработке ПО. Из этого следует, что различным моделям разработки ПО необходимы также различные подходы к тестированию.
Исходя из выше сказанного понятно, что тестирование состоит из нескольких уровней:
- Компонентное (модульное).  Основывается на поиске дефектов и подтверждении функционирования программных модулей, программ, объектов, классов и т.п., которые можно протестировать отдельно.
- Интеграционное тестирование. Осуществляется проверка интерфейсов между компонентами, взаимодействий различных частей системы (операционная системы, файловая система, аппаратное обеспечение, и интерфейсы между системами.)
- Системное тестирование. Сконцентрировано на поведении тестового объекта как целостной системы или продукта.
- Приёмочное тестирование. Основная цель -  проверка работоспособности системы, частей системы или отдельных нефункциональных характеристик системы.
Прочитав маленький кусочек теории тестирования, можно уже сделать вывод, что данный процесс не так прост, как казалось. Тестируя продукт, необходимо понимать всю важность процесса, и осознавать какую ответственность тестировщик берет на себя.
Существует ошибочное мнение, что программу можно полностью протестировать. Ниже приведены 3 причины, по которым полное тестирование невозможно:
- Количество всех возможных комбинаций входных данных слишком велико, чтобы его можно было проверить полностью.
- Количество всех возможных последовательностей выполнения кода
программы также слишком велико, чтобы его можно было проверить полностью.
- Пользовательский интерфейс программы (включающий все возможные комбинации действий пользователя и его перемещений по программе) обычно слишком сложен для полного тестирования.
Тестирование имеет достаточно большое количество видов, каждый из которых выбирается в зависимости от преследуемой цели:
· Функциональные виды тестирования (ФТ). ФТ базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования. Функциональные виды тестирования рассматривают внешнее поведение системы. Одни из самых распространенных видов функциональных тестов:
- Функциональное тестирование;
- Тестирование безопасности;
- Тестирование взаимодействия.
· Нефункциональные виды тестирования (НФТ). НФТ описывает тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, "Как" система работает. Основные виды нефункциональных тестов:
- Все виды тестирования производительности (нагрузочное тестирование, стрессовое тестирование, тестирование стабильности или надежности, объемное тестирование);
- Тестирование установки;
- Тестирование удобства пользования;
- Тестирование на отказ и восстановление;
- Конфигурационное тестирование.
· Связанные с изменениями виды тестирования. После проведения необходимых изменений, таких как исправление бага/дефекта, программное обеспечение должно быть пере тестировано для подтверждения того факта, что проблема была действительно решена.
· Тестирование после установки программ (Дымовое, Регрессионное, Тестирование сборки, Санитарное тестирование или проверка согласованности/ исправности.
·  Модульное тестирование – тестирование программы на уровне отдельно взятых модулей, функций или классов. 
·   Интеграционное тестирование – тестирование части системы, состоящей из двух и более модулей. (интерфейсное взаимодействие между модулями) 
·   Системное тестирование - тестируется интегрированная система на ее соответствие требованиям. (Альфа – тестирование, Бета-тестирование)
·  Тестирование производительности - тестирование, которое производится с целью определения, как быстро работает вычислительная система или ее часть под определенной нагрузкой.
Также тестирование делят на методы: при тестировании "белого ящика" разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО; при тестировании "черного ящика" тестировщик имеет доступ к программе только через интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования; при тестировании "серого ящика" разработчик теста имеет доступ к исходному коду, но при непосредственном выполнении тестов доступ к коду, как правило, не требуется.
Для подробно изучения и погружения в тестирование следует прочитать массу книг на эту тему, но руководствуясь тем, что изложено в данной статье, можно дать ответ на последний вопрос, что был задан в самом начале: На сколько необходимо тестирование? 
Ответ таков: без тестирования все разрабатываемые продукты потерпели бы крах, так как любой пользователь заинтересован в качестве и стабильности продукта, а без тестирования этого не добиться.

Комментарии

  1. Этот комментарий был удален автором.

    ОтветитьУдалить
  2. Зачем 2 раза писать про модульное, интеграционное и системное тестирование?
    Форматирование текста так себе (об этом стоить задуматься, при чтении раздражает не много)
    И где ссылки на источники интересные, ведь в статье черным по белому написано "Для подробно изучения и погружения в тестирование следует прочитать массу книг на эту тему", вам, как разбирающемуся человеку в теме, следовало бы порекомендовать что-нибудь.

    ОтветитьУдалить
    Ответы
    1. Уважаемый читатель. Если вы обратили внимание, то первый раз про модульное, интеграционное и системное тестирование говорится в рамках уровней тестирования. Второй раз в рамках ВИДОВ тестирования.
      Если вам необходима литература, то я могу вам посоветовать Канер, Фолк -
      тестирование ПО, Савин - Тест dot com, Куликов - тестирование ПО. ISTQB и protesting из электронного.
      Спасибо за ваше мнение.

      Удалить

Отправить комментарий

Популярные сообщения из этого блога

Дымовое, критического пути и расширенное тестирование

Из приведенной ранее классификации тестирования (в статье " С чего начинать изучение тестирования? Конечно же с методов! ") нам осталось рассмотреть «по степени важности тестируемых функций». Но, на этом теория еще не заканчивается) Итак, по степени важности тестируемых функций разделяют следующие виды: - «Дымовое» (smoke) - тестирование, которое состоит из минимального набора тестов на явные ошибки. Дымовое тестирование на начальном этапе выявляет основные критические дефекты. Исходя из того, что данные проверки практически всегда одинаковы и редко претерпевают изменениям, целесообразно будет их автоматизировать. Ежедневная сборка продукта и smoke тестирование являются передовыми практическими методами. Программу, не проходящую "дымовой тест", не имеет смысла отдавать для более глубокого тестирования. - Критического пути ( critical path test ) — основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются н

Тест план и тестовая модель - что это?

Test Plan (тест план)  — это документ или совокупность документов, расписывающих всю тестовую активность (цели, подходы, ресурсы и график запланированных тестовых активностей)  в пределах одного проекта, все работы проводимые командой тестирования или одним тестировщиком. В стандарте IEEE 829 перечислены пункты, из которых должен состоять тест-план:   1) Test plan identifier (идентификатор);   2) Introduction (описание/цель) - Предельно краткое описание цели разработки приложения (частично это напоминает бизнес-требования);   3) Features to be tested (Области, подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые будут подвергнуты тестированию. В некоторых случаях здесь также приводится приоритет соответствующей области. 4) Features not to be tested (Области, не подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые не будут подвергнуты тестированию. Причины исключе

Советы для молодых тестировщиков или как составлять тест - кейс =)

Тест (test) представляет собой набор операций, предназначенных для получения одного или большего числа ожидаемых результатов в некоторой программной системе. Тест-кейсы должен помочь тестировщику (даже начинающему) провести проверку продукта без ознакомления со всей документацией. В тест – кейсе желательно избегать зависимостей от других тест – кейсов. Тест кейс в основном состоит из * Основных параметров - id (номер) - уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге). - Автор – имя и фамилия тестировщика, который написал тест – кей. - Название — краткое описание сути проверки. - Предусловие – предварительные шаги. - Шаги – что нужно сделать, чтобы что-то получить. - Ожидаемый результат – тот результат, который соответствует документации или здравому смыслу =). - Фактический результат – то, что получилось в итоге действия в шаге. - Постусловия – заключительные ша