Все о тестировании по

Анонсы мероприятий:

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

Почему "Про Тестинг"?

Тестинг от английского слова Testing, что в переводе означает тестирование. То есть в русскоязычном чтении название сайта – "Про Тестирование" либо второй вариант – "Профессиональное Тестирование".

Наша миссия

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

• Мы знаем, что процесс обеспечения качества охватывает абсолютно все звенья цепи, участвующие в разработке программного обеспечения. Мы знаем, какие рекомендации по обеспечению качества дать начинающим этот тернистый путь, а так же тем, кто уже набил не одну шишку на нем. Грамотно написанные шаблоны и инструкции, использование стандартов и процессов, а также проведенный анализ выполненных проектов – это верный путь к повышению качества.
• Мы знаем немало о документации и артефактах в тестировании:

• тест план
• тест кейс
• баг репорт или дефект

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

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

Мы знаем как нужно автоматизировать процесс функционального и нагрузочного тестирования. У нас есть методики, статьи и практические советы по автоматизации тестирования, следование которым убережет Вас от многих ошибок, сократит время внедрения, увеличит надежность во время эксплуатации, а следовательно сэкономит вам деньги.

Вам нужна помощь?

Если вам нужна помощь, то вы пришли туда, где вам помогут. Наши специалисты окажут следующие услуги по тестированию и обеспечению качества:

Просто свяжитесь с нами по интересующим Вас вопросам на странице: Вопросы, пожелания и заявки

Наши планы

В ближайшем будущем вашему вниманию будут предоставлены Статьи специалистов, Тренинги, Онлайн консультации по тестированию ПО и обеспечению качества. Также Вам будут предложены готовые программные продукты, каркасы (frameworks) и java библиотеки, использование которых заметно упростит процесс тестирования и избавит вас от ряда проблем, с которыми сталкивалось большинство команд тестирования:

• запуск тестов и подготовка результатов в формате XML/HTML (пилотная версия уже доступна JTR – Java Test Runner)
• Фреймворк для автоматизации тестирования (пилотная версия уже доступна ATFwk)
• автоматическая генерация тест кейсов
• генерация данных, соответствующих вашим требованиям

Разработка программного обеспечения
Процесс разработки ПО
Ключевые процессы
Анализ • Проектирование • Программирование • Документирование • Тестирование
Модели
Итеративная • Спиральная • Каскадная • V-Model • Dual Vee Model
Методологии
Agile (XP, Lean, Scrum, FDD и др.) • Cleanroom • OpenUP • RAD • RUP • MSF • DSDM • TDD • BDD
Сопутствующие дисциплины
Конфигурационное управление • Управление проектами • Управление требованиями • Обеспечение качества

Тести́рование програ́ммного обеспе́че́ния — процесс исследования, испытания программного продукта, имеющий своей целью проверку соответствия между реальным поведением программы и её ожидаемым поведением на конечном наборе тестов, выбранных определённым образом (ISO/IEC TR 19759:2005) [1] .

Содержание

Определения тестирования [ править | править код ]

В разное время и в различных источниках тестированию давались различные определения, в том числе:

• процесс выполнения программы с целью нахождения ошибок [2] ;
• интеллектуальная дисциплина, имеющая целью получение надежного программного обеспечения без излишних усилий на его проверку [3] ;
• техническое исследование программы для получения информации о её качестве с точки зрения определённого круга заинтересованных лиц ( С. Канер[en] [уточнить] );
• проверка соответствия между реальным поведением программы и её ожидаемым поведением на конечном наборе тестов, выполненных определённым образом [1] ;
• процесс наблюдения за выполнением программы в специальных условиях и вынесения на этой основе оценки каких-либо аспектов её работы [4] ;
• процесс, имеющий целью выявление ситуаций, в которых поведение программы является неправильным, нежелательным или не соответствующим спецификации [5] ;
• процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и для определения дефектов [6] ;

История [ править | править код ]

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

В 1960-х много внимания уделялось «исчерпывающему» тестированию, которое должно проводиться с использованием всех путей в коде или всех возможных входных данных. Было отмечено, что в этих условиях полное тестирование программного обеспечения невозможно, потому что, во-первых, количество возможных входных данных очень велико, во-вторых, существует множество путей, в-третьих, сложно найти проблемы в архитектуре и спецификациях. По этим причинам «исчерпывающее» тестирование было отклонено и признано теоретически невозможным.

В начале 1970-х годов тестирование программного обеспечения обозначалось как «процесс, направленный на демонстрацию корректности продукта» или как «деятельность по подтверждению правильности работы программного обеспечения». В зарождавшейся программной инженерии верификация ПО значилась как «доказательство правильности». Хотя концепция была теоретически перспективной, на практике она требовала много времени и была недостаточно всеобъемлющей. Было решено, что доказательство правильности — неэффективный метод тестирования программного обеспечения. Однако, в некоторых случаях демонстрация правильной работы используется и в наши дни, например, приёмо-сдаточные испытания. Во второй половине 1970-х тестирование представлялось как выполнение программы с намерением найти ошибки, а не доказать, что она работает. Успешный тест — это тест, который обнаруживает ранее неизвестные проблемы. Данный подход прямо противоположен предыдущему. Указанные два определения представляют собой «парадокс тестирования», в основе которого лежат два противоположных утверждения: с одной стороны, тестирование позволяет убедиться, что продукт работает хорошо, а с другой — выявляет ошибки в программах, показывая, что продукт не работает. Вторая цель тестирования является более продуктивной с точки зрения улучшения качества, так как не позволяет игнорировать недостатки программного обеспечения.

В 1980-е годы тестирование расширилось таким понятием, как предупреждение дефектов. Проектирование тестов — наиболее эффективный из известных методов предупреждения ошибок. В это же время стали высказываться мысли, что необходима методология тестирования, в частности, что тестирование должно включать проверки на всем протяжении цикла разработки, и это должен быть управляемый процесс. В ходе тестирования надо проверить не только собранную программу, но и требования, код, архитектуру, сами тесты. «Традиционное» тестирование, существовавшее до начала 1980-х, относилось только к скомпилированной, готовой системе (сейчас это обычно называется системное тестирование), но в дальнейшем тестировщики стали вовлекаться во все аспекты жизненного цикла разработки. Это позволяло раньше находить проблемы в требованиях и архитектуре и тем самым сокращать сроки и бюджет разработки. В середине 1980-х появились первые инструменты для автоматизированного тестирования. Предполагалось, что компьютер сможет выполнить больше тестов, чем человек, и сделает это более надёжно. Поначалу эти инструменты были крайне простыми и не имели возможности написания сценариев на скриптовых языках.

В начале 1990-х годов в понятие «тестирование» стали включать планирование, проектирование, создание, поддержку и выполнение тестов и тестовых окружений, и это означало переход от тестирования к обеспечению качества, охватывающего весь цикл разработки программного обеспечения. В это время начинают появляться различные программные инструменты для поддержки процесса тестирования: более продвинутые среды для автоматизации с возможностью создания скриптов и генерации отчетов, системы управления тестами, ПО для проведения нагрузочного тестирования. В середине 1990-х годов с развитием Интернета и разработкой большого количества веб-приложений особую популярность стало получать «гибкое тестирование» (по аналогии с гибкими методологиями программирования).

В 2000-х появилось ещё более широкое определение тестирования, когда в него было добавлено понятие «оптимизация бизнес-технологий» [ источник не указан 1810 дней ] . Основной подход заключается в оценке и максимизации значимости всех этапов жизненного цикла разработки программного обеспечения для достижения необходимого уровня качества, производительности, доступности.

Стандарты, относящиеся к тестированию [ править | править код ]

• IEEE 829—2008 IEEE Standard for Software and System Test Documentation
• ANSI/IEEE Std 1008—1987 — IEEE Standard for Software Unit Testing
• ISO/IEC/IEEE 29119-1:2013 Software and systems engineering — Software testing — Part 1: Concepts and definitions
• ISO/IEC/IEEE 29119-2:2013 Software and systems engineering — Software testing — Part 2: Test processes
• ISO/IEC/IEEE 29119-3:2013 Software and systems engineering — Software testing — Part 3: Test documentation

Классификации видов и методов тестирования [ править | править код ]

Существует несколько признаков, по которым принято производить классификацию видов тестирования. Обычно выделяют следующие:

Уровни тестирования [ править | править код ]

• Тестирование компонентов — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто тестирование компонентов осуществляется разработчиками программного обеспечения.
• Интеграционное тестирование — тестируются интерфейсы между компонентами, подсистемами или системами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.
• Системное тестирование — тестируется интегрированная система на её соответствие требованиям.

• Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться программа.
• Бета-тестирование — в некоторых случаях выполняется распространение предварительной версии (в случае проприетарного программного обеспечения иногда с ограничениями по функциональности или времени работы) для некоторой большей группы лиц с тем, чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей.

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

Статическое и динамическое тестирование [ править | править код ]

Описанные ниже техники — тестирование белого ящика и тестирование чёрного ящика — предполагают, что код исполняется, и разница состоит лишь в той информации, которой владеет тестировщик. В обоих случаях это динамическое тестирование.

При статическом тестировании программный код не выполняется — анализ программы происходит на основе исходного кода, который вычитывается вручную, либо анализируется специальными инструментами. В некоторых случаях анализируется не исходный, а промежуточный код (такой как байт-код или код на MSIL).

Также к статическому тестированию относят тестирование требований, спецификаций, документации.

Регрессионное тестирование [ править | править код ]

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

Тестовые сценарии [ править | править код ]

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

Тестирование «белого ящика», «чёрного ящика» и «серого ящика» [ править | править код ]

В зависимости от доступа разработчика тестов к исходному коду тестируемой программы различают «тестирование (по стратегии) белого ящика» и «тестирование (по стратегии) чёрного ящика».

При тестировании белого ящика (также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого программного обеспечения. Это типично для компонентного тестирования, при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрики покрытия кода или мутационное тестирование.

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

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

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «чёрного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

Бета-тестирование в целом ограничено техникой чёрного ящика (хотя постоянная часть тестировщиков обычно продолжает тестирование белого ящика параллельно бета-тестированию). Таким образом, термин «бета-тестирование» может указывать на состояние программы (ближе к выпуску, чем «альфа»), или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой. То есть, тестировщик может продолжать работу по тестированию белого ящика, хотя программа уже «бета-стадии», но в этом случае он не является частью «бета-тестирования».

Покрытие кода [ править | править код ]

Покрытие кода показывает процент исходного кода программы, который был выполнен («покрыт») в процессе тестирования. По способам измерения выделяют покрытие операторов, покрытие условий, покрытие путей, покрытие функций и др.

Много слышали о тестировании и примеряете на себя возможность работы в этой области? Но пока не совсем понимаете, с чем придется работать?

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

Чем занимается специалист по тестированию?

На рынке ИТ постоянно появляются новые программы, призванные упростить и улучшить жизнь людей.

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

Именно от тестировщика зависит качество продукта и, как результат, успех проекта на рынке. Кто станет пользоваться приложением, если оно не в состоянии выполнить даже базовые функции?

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

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

К основным обязанностям тестировщика ПО относятся:

• Написание тест-кейсов и чек-листов.

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

• Выполнение нужного набора тестов.

В зависимости от поставленных задач специалист по тестированию решает, какие виды тестов применить.

• Документирование и анализ найденных дефектов.

Когда найдена ошибка, ее нужно описать. Делается это для того, чтобы разработчик ПО смог быстро понять, в какой части кода программы кроется ошибка. Сейчас тестировщики вносят все ошибки в баг-трекинговые системы, например, JIRA или TestRail. Для более подробного описания ошибок можно приложить скриншоты экранов или видео.

• Контроль за устранением ошибок разработчиками.

Еще один шаг – контроль за устранением всех найденных ошибок. В баг-трекинговой системе каждой ошибке присваивается градация серьезности (от тривиальной до блокирующей) и статус в соответствии с этапом жизненного цикла бага (от нового до закрытого).

В процессе контроля за устранением дефектов тестировщик следит за тем, чтобы разработчик ПО своевременно устранял все ошибки и делал соответствующие отметки в системе.

• Разработка автоматических тестов.

Для ускорения тестирования могут применяться не ручные, а автоматизированные тесты. В таких случаях тестировщик пишет код проверки и запускает его. А программа автоматически выполняет тысячи нужных проверок, при этом сохраняя время тестировщику.

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

Что нужно, чтобы стать тестировщиком?

Несмотря на относительную молодость профессии тестировщика (не более 20 лет), сегодня сформирован набор требований, которые нужны для старта.

Во-первых, чтобы успешно справляться с рабочими задачами, тестировщик должен иметь прочные теоретические и практические навыки.

К тому же, необходимо обладать рядом специфических качеств. Например, природная любознательность, внимание к деталям, усидчивость, недоверчивость и желание постоянно перепроверять себя.

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

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

Какие виды тестирования ПО выделяют?

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

Все виды тестирования разделяют на две группы:

• Функциональные (осуществляется проверка того, насколько хорошо система выполняет свои функции, если вообще выполняет).
• Нефункциональные (тестируется в целом готовность системы к работе, осуществляется проверка всего, что может касаться пользовательского опыта, например, нагрузочное тестирование, тестирование безопасности).

Помимо видов, в тестировании выделяют еще и уровни, которые показывают над чем ведется работа: над системой в целом или только над одним определенным компонентом.

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

Пример кейса по тестированию для новичков

Чтобы на деле увидеть, что делает тестировщик, давайте рассмотрим небольшую практическую задачу.

Необходимо протестировать форму регистрации в социальной сети LinkedIn.

Первое, что нужно сделать, – открыть сайт. Форма для регистрации выглядит следующим образом:

Далее необходимо провести набор тестов для того, чтобы понять, работает ли форма корректно.

Во-первых, нужно проверить обязательность заполнения всех полей. Для этого нужно, ничего не заполняя, нажать кнопку «Присоединиться». Форма сразу выдает ошибку и выделяет красным те поля, которые необходимо заполнить. В нашем случае – все:

Далее мы проверим, среагирует ли форма на небезопасный пароль. Для этого, заполнив наши данные во всех полях, вводим пароль до 6 символов.

Сразу появилось предупреждение о том, что пароль слишком короткий.

Далее посмотрим, как приложение поведет себя, если мы будем вводить в поля нехарактерные символы. Например, введем в поля «Имя» и «Фамилия» символы, отличные от букв.

Форма требует указать настоящие данные. Однако это условие относится лишь к имени, о фамилии в тексте формы нет ни слова.

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

Почему так происходит? Возможно, проблема кроется в том, что форма проверяет лишь первое поле в коде. Или же можно говорить о не совсем верной локализации. Ведь приложение изначально написано для англоязычных пользователей. На английском языке имя и фамилию можно передать как name и last name. А на русском языке могли оставить лишь перевод имени.

Такой дефект можно охарактеризовать как малозначимый (minor), и относится он к пользовательскому интерфейсу.

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

Далее посмотрим, как поведет себя форма при вводе корректного электронного адреса. Например:

Форма приняла этот адрес и инициировала проверку безопасности. Адрес был введен корректно, структура соблюдена, присутствует символ «@».

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

Итог

Хотите научиться безошибочно распознавать дефекты, правильно их документировать и научиться выполнять основные задачи тестировщика? Курс « Основы тестирования ПО » от QA Academy поможет вам погрузиться в профессию, попробовать свои силы на практике, а главное – сделать первый шаг по карьерной лестнице.

Ведь хороший специалист по тестированию ПО всегда будет востребован как дома, так и за границей. Дерзайте!