Рейтинг
0.00

Тестирование ПО

5 читателей, 37 топиков

Основные техники тест дизайна (Software Test Design Techniques)

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

Техники тест дизайна

Разделение по классам еквивалентности
Для примера, имеется определенный диапазон предполагаемых значений от 1 до 10 ваша задача выбрать 1 без погрешности значение внутри этого интервала, допустим 3 и одно с погрешностью то есть не верное вне промежутка -0.

Анализ граничных Значений
В этом случае для положительного тестирования нужно выбрать, наименьшую и наибольшую границу: допустим от 2 и до 9 и значения больше и меньше границ допустим 1 и 10. Анализ имеет применение к любым сущностям с ограничениями в данной области.

Причина/ Следствие
В этом случае ввод определенных комбинаций будет представлен причиной. Когда ответ самой системы это будет следствие. Допустим, вы собираетесь узнать о возможности добавить пользуясь одной из мониторных форм. Для определения нужно разметить на несколько полей «Фамилия», «Год», «номер страховки» и и как только вы нажмете иконку «Добавить» — вы получаете причину. А следствие будет то когда система, добавит и выдаст его номер в базе.

Читать дальше →

Тестовое Покрытие (Test Coverage). Критерии тестового покрытия в Тестировании ПО

Тестовое покрытие
– критерий, отображающий добротность тестирования. Характеризует полноту охвата тестами программного кода либо требований к нему.
Основной подход к оцениванию – формирование тестового пула. Значение тестового покрытия кода находится в прямой зависимости от количества отобранных вариантов проверки к нему.
Многозадачность и универсальность современного софта обусловливает невозможность организации тестового покрытия с показателем в 100%. Так что для максимального охвата тестируемого кода, разработаны особые приёмы и инструменты.
Существуют три подхода для оценки качества и выражения тестового покрытия в численном представлении в зависимости от области проверки: покрытие требований, покрытие кода и покрытие на базе анализа потока управления. Подробнее о каждом.
Покрытие требований (Requirements Coverage)
. Применяя матрицу трассировки, рассматривается охват тестами требований, выдвигаемых к программе.
Формула для оценки выглядит следующим образом:

Tcov= (Lcov/Ltotal)*100.

Результат выражается в процентах.

Расшифровка переменных:
Tcov — тестовое покрытие;
Lcov – число отобранных для тестирования требований;
Ltotal – полное число заявленных требований.

Тестовое покрытие

Один из путей упрощения задачи – разделение требований к коду на подразделы. Для этого важно провести их тщательный анализ. В последующем, подраздел привязывается к проверяющим тестам. Сумма этих связей называется «матрица трассировки». Она позволяет отследить проверяемые требования для конкретного тестового случая.
Бессмысленным является применение тестов без связи с требованиями. В то же время, если не привязать к проверке требование, его проверка проведена не будет. Вследствие этого, об уровне реализации требования в программном коде судить не представится возможным. Поскольку многозадачность современного софта влечёт за собой некоторую стандартизацию, выражающуюся в общих, для стандартных условий, решениях, есть смысл применять стандартные техники тест дизайна.
Покрытие кода (Code Coverage)
В этом случае отслеживаются области программного кода, которые не были охвачены процессом собственно поверки.
Формула для оценки выглядит так:

Tcov = (Ltc/Lcode) * 100%
Результат выражается в процентах.

Переменные:
Tcov – тестовое покрытие;
Ltc – число охваченных проверкой строк кода;
Lcode – суммарное количество строк кода.

Для рутинной работы разработаны стандартные инструменты. Например – Clover. Этот продукт отслеживает и предоставляет информацию о сроках вхождений при тестировании. Анализ данных позволяет существенно расширить область покрытия, поскольку выявляются дублирующие проверки и случаи выпадения из тестирования участков кода. Такая методика оптимизации покрытия находит применение при анализе по принципу «белого ящика» и в стратегиях модульного, интеграционного, системного тестирования. Не зная внутренней структуры кода, как можно предположить из формулы, это не самый лучший выбор для реализации тестирования по принципу «чёрного ящика». Будут трудности при конфигурировании, установке. Придётся привлекать и авторов продукта.

Читать дальше →

Отличие Санитарного (Sanity Testing) от Дымового (Smoke Testing) видов тестирования

Санитарное или Санити тестирование (Sanity Testing)
относится к виду тестирования, которое используется с целью доказательства работоспособности конкретной функции или модуля согласно заявленным техническим требованиям. Зачастую санитарное тестирование используют для проверки какой либо части программы или приложения в результате внесенных изменений на нее со стороны факторов окружающей среды. Выполнение его обычно происходит в ручном режиме.

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

Дымовое и Санитарное тестирование

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

Нагрузочное тестирование (Load Testing) в Тестировании ПО

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

«Нагрузочное тестирование». Два слова, которые мы сейчас попытаемся объяснить для более полного понимания процесса.



«Load Testing» — нагрузочное тестирование в переводе на английский. Синоним – тестирование производительности. Программно проводится имитация деятельности нескольких, определённого количества пользователей представляемого программного продукта (Performance Testing).

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

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

Нагрузочное тестирование — (load testing) в профессиональной среде тестирования ПО используется с целью принятия решения о возможности его окончательного запуска в эксплуатацию. Суть Лоад тестирования состоит в оценке производительности и быстродействия веб-ресурса (или его приложения) в условиях исскуственно созданной определенной нагрузки на систему. Главными индикаторами нагрузки для тестируемых интернет-ресурсов могут выступать ожидаемое количество его посетителей за конкретный интервал времени, заданное число операций, одновременно выполняемой на платформе веб-сайта.
Наиболее ожидаемым результатом нагрузочного тестирования является факт соответствия полученных результатов тем системным требованиями к работе веб-ресурса, которые разрабатывались на этапе формирования функционала веб-ресурса до начала разработки архитектуры программного обеспечения. Но учитывая тот факт, что заданные требования довольно часто могут быть не определены или недостаточно конкретизированы, используется вариант пробного нагрузочного тестирования (англ. exploratory load testing), которое предусматривает использование вероятностных вариантов ожидаемой нагрузки на систему.
Применение нагрузочного тестирования является оптимальным для определения производительности программного обеспечения веб-ресурса на этапе его ранней разработки, так как способствует выявлению состоятельности системы в целом.

Профессия QA Engineer. Кто такой Тестировщик?

QA Engineer что это — это такая же профессия, работа по найму в IT как и многие другие о которых вы скорее всего слышали и знаете, к примеру, такие как программист или аналитик. QA Engineer выполняет весь обьем работ связанный с тестированием ПО на проекте.

Чем же занимается QA Engineer?
Его обязаности очень обширны начиная от анализа технической документации (требований, спецификаций) до написания тестовой документации и собственно тестирования и написания автоматических тестов. Но не все тестировщики (так их называют в народе) занимаются все этим на своей работе. Все зависит от компании в которой они работают и какой уровень квалификации имеют.

QA Engineer, Тестировщик

Уровни квалификации и опыта у Тестировщика (QA Engineer)

Обычно Тестировщиков делят на 4 основные категории:

Trainee QA Engineer
— это обычно человек, который не имеет опыта работы в этой профессии и только начинает свой путь в тестировании ПО
Junior QA Engineer
— человек, который уже имеет какие-то навыки и опыт в тестировании возможно комерческий или фриланс, часто таким знанием и квалификацией награждают после прохождения испытательного срока, который может длиться от 1 до 6 месяцев в зависимости от компании.
Middle QA Engineer
— это специалист среднего уровня знаний, умений и ответственности на проекте, может выполнять задачи самостоятельно и подсказывать по проекту и профессии младшим сотрудникам Trainee и Junior тестировщикам. Обычно имеет опыт от 1 до 3х лет в профессии.
Senior QA Engineer
— опытный сотрудник высокого уровня квалификации. Кроме самостоятельного выполнения задач, может легко обучать других сотрудников, брать на себя тестирование более сложных технических задач, выполняет наиболее широкий спектр задач используя различные виды тестирования как правило уже практикующий автоматизацию, но это не всегда, так как есть и такие инженеры, которые специализируются только лишь на ручном тестировании.

Читать дальше →

Баг репорт (Bug Report) или заведение бага в тестировании ПО?

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

Существует различное множество баг-трекинговых систем, которые позволяют нам не только создавать задачи, менять их статусы но и создавать баг репорты. Самые распространенные на сегодняшний день это Redmine, Bugzilla, Mantis, JIRA

Пример того как выглядит список баг репортов в JIRA:
Список Баг репортов в JIRA

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

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

Читать дальше →

Основные Виды тестирования Програмного Обеспечения

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

Приемочное тестирование (Acceptance testing)
Это тестирование, направленное на то чтобы сделать вывод пригодно ли наше приложение к использованию или стоит что-то доработать или исправить. Такое тестирование проводится обычно на стороне заказчика после окончания разработки и тестирования функционала. Тесты пишутся или придумываются и выполняются обычно самим заказчиком.

Функциональное тестирование (Functional testing)
Функциональное тестирование — это тестирование функциональности и поведения нашей программы, для того чтобы убедится что поведение программы и ее функционал соответствуем требованиям функциональной спецификации. Обычно выполняется как тестирование черного ящика, подавая на вход какой-то набор данных и ожидая чего-то на выходе

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

Тестирование Безопасности (Security testing)
Проверка прав доступа, невозможность захода в программу посторонним лицам, SQL инъекции, XSS атаки. Проверяем что приложение соответствует необходимым требованиям к безопасности

Читать дальше →

Что такое Тест Сьют или Тестовый Набор (Test Suite) ?

Что такое Тест Сьют и для чего он нужен?
Тест Сьют это набор тест кейсов, которые объединены тем что относятся к одному тестируемому модулю, функциональности, приоритету или одному типу тестирования. Каждый тест сьют состоит из более чем одного тест кейса и зачастую выполняется всей «пачкой» в процессе тестирования.
тест сьют, test suite
Тест кейсы объединяют в тест сьюты для большего удобства при проходжении тест кейсов, проходя их последовательно от модуля к модулю, от одного типа тестирования к другому а не сумбурно, бросаясь из одного угла в угол, оставив не проверенным большую часть модуля или общей функциональности.

Основные принципы в тестировании ПО

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

Принципы в тестировании ПО

Основные принципы в тестировании ПО

Из множества принципов, которые наверно для себя выделил каждый тестировщик занимающийся тестированием ПО есть основные по мнению сообщества тестировщиков, которые и хотелось бы выделить:

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

2) Скопление багов. Если брать продукт и разбить его по модулям, то в процессе тестирования можно заметить что основная часть багов лежит в одном или нескольких модулях продукта, следовательно можно отметить эффект скопления багов. Как правило такое можно наблюдать в совершенно разных продуктах. Для того чтобы эффективно протестировать наш продукт, следует распределить свои усилия в тестировании по реальной плотности багов в модулях продукта, если же тестируем впервые, то пропорционально ожидаемой плотности. Со временем тенденция с накоплением багов может изменятся от модуля к модулю. Это следует отслеживать и перераспределять усилия в дальнейшем тестировании.

Читать дальше →

Что такое Тестирование Черного Ящика (Black box testing) ?

Черный ящик (Black box testing)
Что такое тестирование Черного Ящика — это стратегия или метод тестирования, базируется только лишь на тестировании по функциональной спецификации и требованиям, при этом не смотря во внутреннюю структуру кода и без доступа к базе данных. Фактически мы знаем какой должен быть результат при определенном наборе данных, которые подаються на вход. Результат проверяем с юзер интерфейса на уровне простого пользователя. На данный момент такая стратегия является наиболее часто применима в IT компаниях.

black box testing

Серый ящик (Grey box testing)
Чуть меньшее количество тестировщиков тестируют стратегией серого ящика, который подразумевает частичный доступ, например к структуре баз данных или наборов параметров, которые принимают сервисы.

Белый ящик (White box testing)
Наименьшая часть тестировщиков, способны анализироваь чужой код и заниматься написанием тестов даже не запуская программу или приложение а только базируясь на коде, эта стратегия называеться белым ящиком. Может использоваться в дополнение к черному и серому ящикам. Таких специалистов на рынке очень мало, и они скорее всего бывшие разработчики ушедшие в тестирование или увлекающиеся программированием.

Читать дальше →