Рейтинг
0.00

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

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

Юзабилити тестирование или Usability Testing в Тестировании ПО

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

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

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

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

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

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

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

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

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

Что такое Тест План (Test Plan) ?

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

Тест План

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

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

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

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

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

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

Инсталляционное Тестирование (Installation Testing) или Установочное Тестирование

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

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

Инсталяционное тестирование

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

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

Тестовое Покрытие (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), которое предусматривает использование вероятностных вариантов ожидаемой нагрузки на систему.
Применение нагрузочного тестирования является оптимальным для определения производительности программного обеспечения веб-ресурса на этапе его ранней разработки, так как способствует выявлению состоятельности системы в целом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

black box testing

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

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

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