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



Слабым местом стандартизации результатов тестирования является невозможность учета ошибок, обусловленных воздействием человеческого фактора, который в свою очередь проявляет себя на всех этапах процедуры. Главный стандарт в данной области – ISO 9126 («Стандарт для оценки качества ПО») Международной организации по стандартизации указывает, что тестирование должно осуществляться путем соблюдения следующим критериям: Functionality, Reliability, Usability, Efficiency, Maintainability, Portability

Также, действует стандарт IEEE 829-1998 («Стандарт для тестовой документации тестирования программного обеспечения»), который определяет перечень необходимых документов для проведения тестирования, а именно: план и журнал его проведения, отчеты об общих и промежуточных результатах тестирования.

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

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



Существует два главных уровня конфигурационного тестирования: серверный и клиентский.

Серверный уровень тестирования конфигурации

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

Клиентский уровень тестирования конфигурации

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

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

Автоматизация тестирования

Тестирование программного продукта, в процессе которого главные этапы проверки осуществляются при помощи автоматических инструментов (запуск, инициация, проведение, обработка результатов и оформление выводов) в английском варианте выглядит как “functional automation testing”. По-русски – автоматизированное тестирование программного обеспечения.

Предпосылки для автоматизации

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

К неоспоримым достоинствам автоматического тестирования относятся:

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

Минусы автоматического тестирования ПО

• Цикличность (да-да) – однообразные тесты не могут зацепить другие элементы, чем те, для которых они написаны. Человек же способен заметить мелкие нестыковки и на уровне тестирования сделать выводы о природе ошибки или внести исправления.
• Поддержка – хоть и затраты на ручное тестирование больше, автоматические тесты также нужно обновлять и доводить, чтоб функциональность проверок соответствовала уровню тестируемого приложения (с повышением сложности проверяемого ПО, возникает потребность в обновлении кода автотестов).
• Разработка – написание, а главное – отладка и тестирование автотестов требует много времени. Ведь, по сути, софт для тестирования программного обеспечения – не что иное, как то же самое программное обеспечение. Только функционал очень узкий.
• Стоимость – лицензионный экземпляр фрейворка для автоматизации может обойтись в приличную сумму. И хоть бесплатные варианты тоже, как правило широко используются, их функциональность часто оставляет желать много лучшего, а лицензия должна помочь при возникновении проблемы, описанной в п.2 данного списка.
• Мелкие ошибки – автотесты могут не замечать мелких дефектов, не наносящих вреда функциональности кода, но портящих визуальный интерфейс и затрудняющих работу конечного пользователя (сдвиг окон, грамматические ошибки…).

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

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



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

Написание тест кейсов на основе спецификации требований

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

Написание тест кейсов на основе функциональности программы

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

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

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

Юзабилити тестирование

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

Результат тестирования позволяет оценить степень комфортности приложения по нескольким критериям:

1. Продуктивность и результативность (efficiency) – характеризует время и количество последовательных действий, предпринимаемых пользователем для получения конечного результата.
2. Точность (accuracy) – обозначает количество ошибочных действий пользователя при использовании приложения.
3. Закрепление в памяти (recall) – показывает объём информации о работе с приложением, сохранившийся у пользователя в памяти, спустя много времени после последней работы с продуктом.
4. Эмоциональный отклик (emotional response) – даст оценку ощущениям пользователя, оставшимся после работы с софтом; вероятность рекомендации другим людям.

Usability Testing на разных уровнях тестирования

Тестирование удобства пользования подразумевает проверку приложения по типу «чёрного ящика» и «белого ящика». Тестер становится на место конечного потребителя и даёт оценку продукту. Проверке подвергается уровень комфорта в использовании объектов, классов, методов, переменных.

Изучается уровень довольства при необходимости в изменении и расширении, обеспечения взаимодействия с дополнительными модулями, системами. Выбор правильного интерфейса (API) положительно отразится на добротности, позволит возрасти скорости написания и обслуживания создаваемого кода, повлечёт за собой повышения уровня качества приложения в итоге.

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

Как улучшить Юзабилити тестирование сайта?

Перво-наперво следует предусмотреть безупречно себя зарекомендовавшую систему защиты «от дурака». Англоязычные ресурсы называют её fail-safe или японским термином Poka-yoke. Общий принцип прост: предотвратить получение ложных вводных вследствие невнимательности либо безграмотности конечного пользователя. Подходом в этом случае может стать схема контроля над вводимыми данными (для примера – не допускать числовых значений в текстовом поле).

Учёт мнений пользователей готового продукта должен стать основой в совершенствовании приложения. Правильно интерпретируя отзывы, можно вывести комфорт пользования на несколько порядков выше первоначальных. Цепочка Plan-Do-Check-Act – планирование-действие-проверка-коррекция. Это так называемый цикл Деминга-Шухарта – алгоритм менеджмента по управлению процессом и решению поставленных задач.

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

Тестирование любого программного продукта не может быть внезапным и самопроизвольным, тестинг нужно планировать.
Test Plan (Тест план) — это документ, подробно определяющий, и описывающий что и как теcтировать.

Из чего состоит Тест План

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

Компоненты, которые должны тестироваться

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

Раздел «Характеристики и свойства, которые не должны тестироваться»

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

В раздел «План проведения испытаний»

вы можете включить такие темы:

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

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

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

Одним из наиболее важных, но довольно часто оставляемых без должного внимания видов тестирования программного обеспечения, является инсталляционное тестирование (Installation Testing).

Под ним подразумевают уровень корректности установки некоего программного продукта в искусственно созданной среде с целью выявления степени ее готовности к эксплуатации.

Причины проведения Установочного Тестирования

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

Важно ли проводить Инсталляционное Тестирование

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

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

Разделение по классам еквивалентности

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

Анализ граничных Значений

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

Причина/ Следствие

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

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

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

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

Покрытие требований (Requirements Coverage)

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

Tcov= (Lcov/Ltotal)*100.

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

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



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

Покрытие кода (Code Coverage)

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

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

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

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

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

Санитарное или Санити тестирование (Sanity Testing)

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

Дымовое или Смоук тестирование (Smoke Testing)

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



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