-
Notifications
You must be signed in to change notification settings - Fork 18
Home
Человек может сделать ошибку, которая приведёт к дефекту (ошибке, сбою) в коде в программного обеспечения, системе или в документе. Если дефект выполнился в коде, система не сделает того, что она должна сделать (или сделает что-то, чего она не должна делать), что в свою очередь приведет к отказу. Дефекты в программном обеспечении, системах или документах могут быть причиной отказа системы, но не всегда. Дефекты происходят, потому что людям свойственно ошибаться, есть ограничения во времени, код может быть сложным, инфраструктура комплексной, технологии могут меняться, а взаимодействие систем нетривиальным. Отказы могут быть вызваны условиями окружающей среды: радиация, магнетизм, электрические поля и загрязнение может привести к перебоям в программно-аппаратных средствах или повлиять на выполнение и работу программного обеспечения в следствии изменения условий работы аппаратного обеспечения. Тщательное тестирование систем и документов может помочь уменьшить риски связанные с возникновением проблем в эксплуатации и внести лепту в качество программного обеспечения, если найденные дефекты исправлены до того, как система начнет эксплуатироваться. Тестирование программного обеспечения может быть необходимо для выполнения условий контракта, юридических требований или некоторых промышленных стандартов. Тестирование может дать уверенность в качестве программного обеспечения, если найдено мало дефектов или не найдено совсем. Правильно спроектированный тест, который выполняется успешно уменьшает общий уровень риска в системе. Когда же во время тестирования найдены дефекты, качество системы возрастает, после того как эти дефекты исправлены. Однажды сделанные ошибки не должны повторяться. Посредством понимания главных причин дефектов найденных в предыдущих проектах, процесс может быть улучшен, что в свою очередь должно предотвратить появление этих дефектов вновь, как следствие, улучшить качество будущей системы.
Согласно расхожему представлению тестирование - это только выполнение тестов, т.е. выполнение программы. В действительности понятие тестирование намного шире. Можно выделить несколько целей тестирования: • найти дефекты; • убедиться в надлежащем уровне качества и получение необходимой информации; • предотвратить ошибки. Процесс проектирования тестов на ранних стадиях жизненного цикла (проверка тестового базиса через проектирование теста) может помочь предотвратить появление дефектов в коде. Анализ документов (например, требований) также помогает предотвратить появление дефектов в коде. Различные точки зрения в тестировании принимают во внимание различные цели. Например, в тестировании в процессе разработки (например, компонентное, интеграционное и системное тестирование), главной целью может быть поиск наибольшего количества отказов для того, чтобы дефекты в программном обеспечении были идентифицированы и исправлены. В приемочном тестировании главной целью является подтверждение того, что система работает как ожидалось, и соответствует требованиям. В некоторых случаях главной целью тестирования является оценка качества программного обеспечения (без намерения исправления ошибок), предоставление информации о рисках в данное время заинтересованным сторонам. Тестирование поддержки часто включает проверку на отсутствие новых ошибок, внесенных во время изменений. Во время функционального тестирования главной целью является определение характеристик системы, таких как надежность и работоспособность. Отладка не является тестированием. Тестирование может показывать неисправности, причинами которых являются дефекты. Отладка это часть процесса разработки, которая включает обнаружение происхождения дефекта, испарвление кода и проверка того, что дефект был исправлен правильно. Последующее подтверждающее тестирование гарантирует, что исправление на самом деле избавило нас от сбоя. Разработчик несет ответственность за отладку, а тестировщик за тестирование. Психология тестирования Способ мышления, необходимый в процессе тестирования или рассмотрения, отличается от способа мышления, необходимого для программирования и анализа. С правильным мышлением разработчик может тестировать собственный код, но разделение этой ответственности обычно делается для того, чтобы помочь сфокусировать усилия и обеспечить дополнительные преимущества, такие как независимый взгляд тренированного профессионала в тестировании. Независимое тестирование может иметь место на любом из уровне тестирования. Определенный уровень независимости (избегающий предвзятости автора) часто более эффективен в поиске дефектов и сбоев. Независимость, тем не менее, не является заменой знания системы, поэтому разработчики тоже могут эффективно находить дефекты в собственном коде. Можно определить несколько уровней независимости: • Проектирование тестов человеком, который написал программу (низкий уровень независимости). • Проектирование тестов другим человеком (например, из команды разработчиков). • Проектирование тестов человеком из другой организационной группы (например, независимая команда тестировщиков). • Проектирование тестов человеком из другой организации или компании (например, аутсорсинг или сертификация другой компанией). Люди как и проекты управляются целями. Люди склонны подстраивать свои планы согласно целям установленным руководством или заказчиками, например, поиск дефектов или подтверждение, того что программное обеспечение работает. Поэтому четкая установка целей очень важна для тестирования. Нахождение сбоев программы во время тестирования может быть воспринята как критика продукта или автора. Поиск неисправностей в системе требует любопытства, профессионального пессимизма, критического взгляда, внимания к деталям, коммуникационных навыков общения с разработчиками, и опыта на котором базируется интуитивный поиск ошибок. Проблемы могут возникать, если тестировщики рассматриваются как люди, приносящие плохие новости. Тем не менее, существует несколько способов улучшить взаимоотношения между тестировщиками и разработчиками: • Плохой мир лучше хорошей войны - напомнить каждому об общих целях улучшения качества системы; • Общаться нейтральным способом, сфокусироваться на фактах, не критиковать, например, описать цели, факты и анализ того, что вы нашли; • Попытаться понять, что чувствуют другие люди и почему они так реагируют; • Убедиться, что другие люди поняли что вы сказали и наоборот.
Говоря о принципах тестирования, принято называть следующие:
- Тестирование выявляет наличие дефектов (а не их отсутствие). Т.е. тестирование уменьшает шансы наличия в ПО неизвестных ошибок, но даже если не найдено ни одного дефекта, это не является доказательством безупречности приложения.
- Избыточное тестирование невозможно. Протестировать каждый возможный вариант поведения при всех комбинациях входных данных возможно лишь в самых тривиальных случаях. Вместо этого мы анализируем риски и приоритеты, чтобы потратить усилия и время наиболее эффективно.
- Раннее тестирование. Тестовые активности следует начинать как можно раньше и они должны быть направлены на заранее определенные цели.
- Кластеризация дефектов. Как правило большую часть ошибок содержит небольшая группа модулей приложения.
- Парадокс пестицида. Тесты следует поддерживать в актуальном состоянии, постоянно отслеживая изменения в тестируемой системе и анализируя найденные ошибки. Статический набор кейсов, даже если он и написан изначально хорошо, со временем будет терять свою эффективноть. (как это происходит с пестицидами -оттуда и название)
- Тестирование контекстуально обусловлено. Тестирование производится по-разному в зависимости от контекста. Так, тестируя ПО для медицинского оборудования или магазин по продаже тапочек, мы будем отталкиваться от разных приоритетов.
- Отсутствие багов - не главная цель. Казалось бы, любой тестер сочтет эту фразу кощунственной. Но если вдуматься глубже, то даже найдя и пофиксив все дефекты, мы можем получить приложение, которое не удовлетворит нужд юзеров. Поэтому для тестеров отсутствие багов - не первоцель, как и для программистов - красивый и оригинальный код. В этом и состоит седьмой принцип.
Самое очевидное в тестировании это выполнение тестов. Но для того, чтобы быть эффективным, планы тестирования должны включать время на планирование, разработку, подготовку для выполнения тестов, а также оценку результатов. Базовый процесс тестирования состоит из следующих главных активностей: • планирование и контроль В процесс планирования включаются определение целей и заданий тестирования, а также методов их достижения и выполнения Контроль тестирования включает деятельность по сравнению действительного состояния с планом, сообщение о статусе, включая отклонение от плана. А также включает корректирующие действия для достижения целей и выполнения заданий. Для контроля процесса тестирования мониторинг деятельности должен проходить в течении всего проекта. При планировании принимается во внимание информация полученная в процессе мониторинга и контроля. • анализ и проектирование Анализ и проектирование это действия, в процессе которых общие цели тестирования трансформируются в явные условия тестирования и модели. • внедрение и выполнение Разработка и выполнение тестов это процесс, в котором тестовые условия трансформируются в тестовые сценарии, наборы тестов и сред выполнения. • оценивание критериев выхода и отчетность Оценка критериев выхода это процесс сопоставления результатов тестов и поставленных целей тестирования. Рекомендуется делать для каждого уровня тестирования • завершение тестирования В финальной фазе процесса тестирования происходит сбор данных о проведенных тестах, фактах и цифрах. Например, когда программная система выпущена в работу', проект тестирования выполнен (или отменён), контрольные точки проекта были достигнуты, или поддержка выпущенной версии закончена.
Хотя существует несколько видов У-модели, самый распростаненный из них включает 4 уровня тестирования, которые соответствуют 4 уровням разработки. (Оттуда и название V модель: 4 уровня разработки можно представить в виде ниспадающей линии, каждому отрезку которой соответствует отрезок восходящей линии с 4 уровнями тестирования - см. иллюстрацию в самом низу статьи) Эти 4 уровня включают: • компонентное (модульное) тестирование; Тестирование отдельных модулей программы. • интеграционное тестирование; Тестирование взаимодействия между модулями. • системное тестирование; Тестирование системы в целом. • приёмочное тестирование. Тестирование клиентом на предмет удовлетворения требований. На практике У-модель может содержать больше, меньше или созсем другие уровни разработки и тестирования, в зависимости от проекта и программного продукта. Например, может быть интеграционное компонентное тестирование после компонентного тестирования и системное интеграционное тестирование после системного. Продукты разработки (такие как бизнес-сценарии, спецификации, проектная документация и код) создающиеся во время разработки, являются базисом для тестов для одного или нескольких уровней. Ссылки на основные продукты работы включают в себя «Усовершенствованную модель зрелости процессов производства ПО» (СММ1) и «Жизненный цикл программного обеспечения» (1ЕЕЕ/1ЕС 12207) Верификация и валидация (а также ранняя разработка тестоз) могут проводиться во время разработки ПО.
Итерационная разработка - это процесс при котором создание требований, разработка, конструирование и тестирование являются серией небольших разработок. Например: прототипирование, быстрая разработка приложения (РАО), Ка(юпа111тйес] Ргосезз (РУР) и модели гибкой разработки. Прирост, созданный на каждой итерации, может быть протестирован на различных уровнях в процессе разработки. Значимость регрессионного тестирования возрастает начиная со второй итерации. Верификация и валидация осуществляется на каждой итерации.
Гибкая методология разработки (англ. АдИе зоймаге г1еуе1ортеп1), адНе-методы -собирательный термин для ряда подходов и практик, основанных на 12 принципах:
- Наивысшим приоритетом является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
- Изменение требований приветствуется, даже на поздних стадиях разработки.
- Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
- На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
- Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
- Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
- Работающий продукт - основной показатель прогресса.
- Инвесторы, разработчики и пользователи должны иметь возможность поддержизать постоянный ритм бесконечно.
- Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
- Простота - искусство минимизации лишней работы - крайне необходима.
- Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
- Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. Основной метрикой адНе-методов является рабочий продукт Отдавая предпочтение непосредственному общению, ад|1е-методы уменьшают объем письменной документации по сравнению с другими методами. Это привело к критике этих методов как плохо организованных. Основные идеи: люди и взаимодействие важнее процессов и инструментов, работающий продукт важнее исчерпывающей документации-сотрудничество с заказчиком важнее согласования условий контракта; готовность к изменениям важнее следования первоначальному плану.
### Компонентное тестирование Целью компонентного тестирования является поиск дефектов и проверка функциональности компонентов (модулей, программ, объектов, классов и т.д.), которые можно протестировать отдельно. Это можно сделать отдельно от системы, в зависимости от контекста жизненного цикла программного обеспечения и системы. Для этого могут быть использованы заглушки, драйвера, симуляторы. Компонентное тестирование может включать функциональные и нефункциональные характеристики, такие как поведение ресурсов (например, утечки памяти) или тестирование надежности, а также структурное тестирование (например, покрытие ветвей). Тестовые сценарии можно получить из спецификации компонента, архитектуры или модели данных. При компонентном тестировании обычно имеется доступ к коду, а также среде разработки, такой как, например, набор структур для компонентного тестирования или средства отладки, также на практике часто привлекают разработчика кода. Дефекты как правило исправляются сразу после нахождения без составления отчета об ошибке. Один из подходов к компонентному тестированию это подготовка и автоматизация тестовых сценариев перед кодированием. Этот подход называется процессом разработки управляемым тестированием. Этот подход итеративный и основан на циклах разработки тестовых сценариез, потом сборки и интеграции небольших частей кода и выполнении компонентных тестов до достижения правильного результата.
В процессе интеграционного тестирования проверяются интерфейсы между компонентами, взаимодействие различные частей системы, таких как операционная система, файловая система, аппаратное обеспечение и взаимодействие между ними. Чем больше степень интеграции, тем сложнее определить принадлежность дефекта к тому или иному компоненту, что может привести к повышению степени риска. Стратегии систематического интеграционного тестирования могут основываться на архитектуре системы, функциональных задачах, последовательностях обработки транзакций или каких либо других особенностях системы или компонента. Для того, чтобы свести к минимуму риск позднего нахождения дефектов, интеграция, как правило, должна быть итеративной и системной, а не случайной. В интеграционное тестирование может быть включено нефункциональное тестирование (например, тестирование производительности). На каждой стадии интеграции, тестировщики концентрируются исключительно на интеграции как таковой. Например, если интегрируется модуль А в модуль В - наиболее интересным с точки зрения тестирования язляется взаимодействие между модулями, а не функциональность каждого из модулей. Для тестирования могут быть использованы как функциональный, так и структурный методы. В идеале, тестировщики должны понимать архитектуру и ее влияние на интеграционное планирование. Если интеграционные тесты запланированы до того, как компоненты или система разработаны, то они (компоненты или система) могут разрабатываться з порядке, который необходим для наиболее эффективного тестирования.
Системное тестирование делает упор на поведении программы в целом. В системном тестировании тестовая среда должна максимально соответствовать рабочей или производственной среде выполнения, для того чтобы минимизировать риски нахождения дефектов, которые были пропущены во время тестирования. Системное тестирование может включать тесты, основанные на рисках иили спецификациях требований, бизнес-процессах, вариантах использования или других высокоуровневых описаниях поведения системы, взаимодействия с операционной системой или ее ресурсами. В процессе системного тестирования должны исследоваться функциональные и нефункциональные требования к системе. Требования могут быть предстазлены как текст или модель. Тестировщикам необходимо иметь дело с неполными или недокументированными требованиями. Системное тестирование различных аспектов системы начинается с использования подходящих методик черного ящика. Например, на основе комбинаций бизнес-правил можно построить таблицу решений. Структурные подходы (методика белого яшика) можно использовать для оценки покрытия тестами всех структурных элементов, например, таких как структура меню или навигация на веб-странице. Часто системное тестирование выполнят независимая команда тестирования.
Приемочное тестирование часто ложится на плечи заказчиков или пользователей системы; другие субъекты тоже могут принимать участие. Целью приемочного тестирования является проверка работоспособности системы, части системы или специфичных нефункциональных характеристик системы. Поиск дефектов не является главной целью приемочного тестирования. Приемочное тестирование может оценивать готовность системны для промышленной эксплуатации и использования, хотя необязательно является последним и окончательным уровнем тестирования. Например, интеграционные тесты большой системы могут проходить после приемочных. Приемочное тестирование может выполняться не только как один из уровней тестирования, но и как подуровень на нескольких других уровнях тестирования, например: • Коммерческое готовое Г10 может быть подвергнуто приемочному тестированию, когда ПО установлено или интегрировано. • Приемочное тестирование удобства использования может происходить во время компонентного тестирования. • Приемочное тестирование новой функциональности может происходить после системного тестирования. Виды приемочного тестирования включают: • Пользовательское приемочное тестирование Обычно проверяет то, насколько система подходит пользователям. • Альфа- и бета-тестирование Разработчики рыночного или готового программного обеспечения часто хотят услышать мнение существующих или потенциальных пользователей системы перед тем, как продукт начнет продаваться. Альфа-тестирование выполняется в организации разработчика. Бета-тестирование выполняется заказчиком на собственных мощностях. Оба вида тестирования выполняются потенциальными пользователями, а не разработчиками. Могут также использоваться и другие термины, такие как производственное приемочное тестирование, приемочное тестирование на площадке заказчика для систем, которые тестируют до или после установки у заказчика.
Целью компонентного тестирования является поиск дефектов и проверка функциональности компонентов (модулей, программ, объектов, классов и т.д.), которые можно протестировать отдельно. Это можно сделать отдельно от системы, в зависимости от контекста жизненного цикла программного обеспечения и системы. Для этого могут быть использованы заглушки, драйвера, симуляторы. Компонентное тестирование может включать функциональные и нефункциональные характеристики, такие как поведение ресурсов (например, утечки памяти) или тестирование надежности, а также структурное тестирование (например, покрытие ветвей). Тестовые сценарии можно получить из спецификации компонента, архитектуры или модели данных. При компонентном тестировании обычно имеется доступ к коду, а также среде разработки, такой как, например, набор структур для компонентного тестирования или средства отладки, также на практике часто привлекают разработчика кода. Дефекты как правило исправляются сразу после нахождения без составления отчета об ошибке. Один из подходов к компонентному тестированию это подготовка и автоматизация тестовых сценариев перед кодированием. Этот подход называется процессом разработки управляемым тестированием. Этот подход итеративный и основан на циклах разработки тестовых сценариез, потом сборки и интеграции небольших частей кода и выполнении компонентных тестов до достижения правильного результата.
Функции, которые должны выполняться системой, подсистемой или компонентом, могут быть описаны как спецификация требований, варианты использования, или функциональные спецификации, или же быть недокументированы. Функцией является то, что система делает. Функциональные тесты основываются на функциях и характеристиках (которые могут быть описаны в документации или поняты тестировщикам), могут быть выполнены на всех уровнях тестирования (тесты компонентов могут основываться на спецификации компонентов).Методика, основанная на использовании спецификаций, может быть использована для извлечения тестовых условий и тестовых сценариев из функциональности ПО или системы. Функциональное тестирование рассматривает внешнее поведение системы (тестирование методом черного ящика). Один из вариантов функционального тестирования - тестирования безопасности, исследует функции (например, брандмауэра) в контексте угроз, таких как вирусы и другие вредоносные программы.
Нефункциональное тестирование включает в себя, но не ограничивается следующими видами тестирования: тестирование производительности, нагрузочное тестирование, стрессовое тестирование, тестирование удобства использования, тестирование возможности взаимодействия, эксплуатационное тестирование, тестирование надежности и тестирование переносимости. Это тестирование того, как система работает. Нефункциональное тестирование может выполняться на всех уровнях тестирования. Термин «нефункциональное тестирование* описывает, какие тесты необходимы для измерения характеристик системы и ПО в соответствии с различными шкалами, такими как например время ответа ПО. Эти тесты могут ссылаться на модели качества, например определенные в 'Разработка программного обеспечения - Качество программного продукта1 (180 9126).
Структурное тестирование (методом белого ящика) может выполняться на всех уровнях тестирования. Структурную методику лучше всего применять после методики основанной на использовании спецификаций, для измерения охвата, посредством измерения покрытия структуры. Покрытие - это часть структуры, которая была выполнена в процессе тестирования, выраженная в процентах покрытых элементов. Если покрытие не равняется 100%, тогда нужно разработать дополнительные тесты для пропущенных элементов, и как следствие увеличить покрытие. Методики покрытия описаны в главе 4. На всех уровнях тестирования, а в особенности в компонентном и интеграционном компонентном тестировании, можно пользоваться специальным инструментарием для измерения покрытия элементов кода, таких как команды и решения. Структурное тестирование может основываться на архитектуре системы, например иерархии вызовов. Методы структурного тестирования могут быть использованы на системном, системном интеграционном и приемочном уровнях (например, бизнес-модели и структуры меню).
Когда дефект обнаружен и исправлен, тогда ПО должно быть протестировано вновь для того, чтобы подтвердить, что основной дефект был успешно удален. Это называется подтверждающим тестированием. Отладка (исправление дефектов) это процесс разработки, а не процесс тестирования. Регрессионное тестирование - повторяющееся тестирование уже протестированных программ после изменений, для обнаружения любых дефектов, внесенных или не обнаруженных в результате изменений. Эти дефекты могут быть или в ПО, которое тестируется, или в других, связанных или не связанных компонентах ПО. Выполняется после изменений ПО или среды. Глубина регрессионного тестирования основывается на риске пропуска дефектов в ПО, которое уже работало. Регрессионное тестирование может иметь место на всех уровнях тестирования и применяться к функциональному, нефункциональному и структурному тестированию. Наборы регрессионных тестов могут выполняться много раз и, как правило, развиваются медленно, таким образом, регрессионное тестирование является твердым кандидатом на автоматизацию.
Классическим разделением методик тестирования является разделение на «Метод черного ящика» и «Метод белого ящика». Метод «черного ящика* (его также называют метод тестирования по спецификации) это способ получить и выбрать тестовые условия или тестовые сценарии, основываясь на анализе документации, неважно функциональной или не функциональной, для компонента или системы безотносительно к внутренней структуре. К методикам черного ящика относят: • Эквивалентное разбиение Входные данные программы или системы разбиваются на группы, от которых ожидается одинаковое позедение, т.е. их можно обрабатывать по единому сценарию. Эквивалентные сегменты (классы) могут быть найдены как для верных, так и для незерных данных, то есть значений, которые могут быть отброшены. • Анализ граничных значений Поведение на границах каждого эквивалентного сегмента зачастую некорректно, границы это места, в которых тестирование с большей вероятностью соберет урожай ошибок. Максимальное и минимальное значение сегмента это граничные значения. Граничные значения для правильного сегмента - это зерные граничные значения; граничные значения для неправильного сегмента - неверные граничные значения Эта методика часто рассматривается, как расширение метода эквивалентного разбиения и также может быть использована для значений, вводимых человеком, например для временных или табличных граничных значений. Граничные значения также можно использовать для выбора тестовых данных. • Тестирование с использованием таблиц решений Таблицы решений это правильный путь для сбора требований к системе, которая содержит логические условия, и для документирования внутренней структуры системы. Они могут быть использованы для записи сложных бизнес правил, которые должна реализовывать система. Спецификация анализируется и определяются условия и действия системы. Входные условия и действия, как правило устанавливаются как верные или ложные (Булево выражение). Таблицы решений содержат инициирующее условие, часто как комбинацию верности или ложности для всех входных условий, и результирующие действия для каждой комбинации условий. Каждая колонка таблицы соответствую бизнес-правилу и определяет уникальную комбинацию условий, которая приводит к действию, связанному с этим правилом. Стандарт покрытия часто используется с таблицами решений для того, чтобы иметь как минимум один тест для колонки, который, как правило, приводит к покрытию всех комбинаций инициирующих условий. Преимущество тестирования с использованием таблиц решений в том, что оно создает комбинации условий, которые не могут быть проверены тестированием иным способом. Оно может применяться во зсех случаях, когда позедение системы зависит от нескольких логических решений. • Тестирование переходов состояний Система может по-разному реагировать на действия в зависимости от текущего состояния и истории (истории состояний). В этом случае этот аспект системы может быть показан как диаграмма перехода состояний. Это позволяет тестировщику посмотреть на систему с точки зрения состояний, перехода между состояниями, входных данных или событий, которые влекут за собой переход из одного состояний в другое, и действий, которые могут происходить в этих состояниях. Состояния системы или объекта, которые тестируются, различны, идентифицируемы и конечны. Таблица состояний показывает связь между состояниями и входными данными, а также возможные переходы, которые неверны. Тесты могут быть разработаны так, чтобы покрыть типичные переходы состояний, каждое состояние, выполнение каждого перехода, особой последовательности переходов состояний или недействительных переходов. Тестирование переходов состояний широко используется в индустрии встраиваемого программного обеспечения и технической автоматизации вообще. Однако, этот подход можно использовать и для моделирования бизнес-объектов которые имеют особые состояния, или тестирования переходов экранных диалогов (например, интернет-приложения или бизнес-сценарии). • Тестирование сценариев использования Тесты могут создаваться на основе сценариев использования или бизнес-сценариев. Сценарий использования показывают взаимодействие между действующими лицами, включая пользователей и систему, которая (система) создает выходные данные для пользователя. Каждый сценарий использования имеет предварительные условия, которые должны соблюдаться для того он работал правильно. Каждый сценарий использования заканчивается выходными условиями, которые являются видимыми результатами и конечным состоянием системы, после того как сценарий использования завершен. Как правило, сценарий использования имеет главный сценарий (наиболее вероятный) и иногда альтернативные ветки. Сценарий использования описывает «течение процесса» в системе, основываясь на ее типичном использовании, таким образом, тестовые сценарии, полученные из сценариев использования, полезны для нахождения дефектов в последовательности операций процесса при реальном использовании системы. Сценарии использования очень полезны для разработки приемочных тестов при участии заказчика или пользователей. Они также могут быть полезны при нахождении интеграционных дефектов вызванных взаимодействием интерфейсов различных систем, которые не могут быть выявлены при раздельном тестировании этих систем.
Метол «белого ящика» (его также называют структурным или основанным на структуре) основывается на анализе внутренней структуры компонента или системы. Некоторые методики можно сразу отнести к одной категории; другие имеют признаки нескольких категорий. Характерные особенности методики основанной на структуре: • Информация о том, как сконструировано программное обеспечение, используется для получения тестовых сценариев, например, код или модель. • Степень покрытия может быть измерена для существующих тестовых сценариев, в дальнейшем тестовые сценарии можно получать систематично, увеличивая покрытие. В этом параграфе обсуждаются два относящиеся к покрытию кода метода -основанный на командах и оснований на решениях. Для тестирования решений может быть использована диаграмма потоков управления для визуализации альтернатив для каждого решения. • Тестирование и покрытие команд В компонентном тестировании покрытие команд оценивается 8 процентах выполняемых команд, которые используются набором тестовых сценариев. Тестирование команд использует тестозые сценарии для выполнения отдельных команд, таким образом увеличивая степень покрытия. • Тестирование решений и покрытие Покрытие решений, относится к тестированию ветвлений, и оценивается как процент результатов решений (например Истина или Ложь для условий Если), которые были обработаны в процессе выполнения теста. Тестирование решений использует тестовые сценарии для обработки отдельных результатов решений, таким образом увеличивая степень покрытия. Тестирование решений это метод тестирования управляющей логики, так как он обеспечивает прохождение процесса управления через точки решения. Подход покрытия решений более мощный, чем подход покрытия команд: 100% покрытие решений гарантирует 100% покрытие команд, но не наоборот. • Другие структурные подходы Существуют более мощные методы структурного покрытия, чем покрытие решений, например, покрытие условий или многократное покрытие условий. Концепция покрытия также может быть использована и на других уровнях тестирования (например, интеграционный уровень), где процент модулей, компонентов или классов которые обрабатываются набором тестовых сценариев, может быть выражен в покрытии модулей, компонентов или классов. При структурном тестировании кода полезно пользоваться соответствующим инструментарием.
Возможно, наиболее широко распространенной методикой является предположение о наличии ошибки. Тесты создаются на основе интуиции и опыта работы тестировщика с похожими приложениями и системами. При использовании для усиления систематического тестирования, интуитивное тестирование может быть использовано для нахождения особых тестов, которые невозможно получить с помощью формальных методов, в особенности, когда это применяется после использования формальных методов. Однако, эффективность метода очень сильно зависит от опыта тестировщиков. Структурный подход при методики предположения об ошибке это составление списка возможных ошибок и создание тестов, которые нацелены на их воспроизведение. Эти списки дефектов или сбоев могут быть построены на опыте, доступных данных о дефектах или сбоях, а также из общих знаний о том, почему программа дает сбой. Исследовательское тестирование - это параллельное проектирование тестов, выполнение тестов, изучение и регистрация тестов, основанное на испытательной таблице, содержащей цели тестирования и выполняемое в заданные временные рамки. Этот подход наиболее эффективен, когда спецификаций мало, либо они неполные и наблюдается нехватка времени, или для того, чтобы усилить или дополнить другие, более формальные методики. Этот тип тестирования может служить для проверки тестового процесса, чтобы удостовериться, что наиболее важные дефекты найдены.
Выбор методики для тестирования зависит от множества факторов, включая тип системы, правовые стандарты, требования клиентов или контракта, степень риска, тип риска, цель тестирования, доступная документация, уровень знаний тестировщиков, время и бюджет, жизненный цикл разработки, модели сценариев использования и предыдущий опыт по типам найденных дефектов. Некоторые методики более всего подходят для определенных ситуаций и уровней тестирования; другие подходят для всех уровней тестирования.
Есть множество средств тестирования, которые поддерживают различные аспекты тестирования. Средства тестирования классифицированы в этом курсе в соответствии с функциями тестирования, которые они поддерживают. Некоторые средства поддерживают только одну функцию; другие могут поддерживать больше, чем одну функцию, но классифицируются по той функции, с которой они наиболее тесно связаны. Некоторые коммерческие средства тестирования предлагают поддержку только одного типа функционала; другие коммерческие средства тестирования предлагают комплекты или линейки средств, которые обеспечивают поддержку для многих или всех функций. Средства тестирования могут улучшить эффективность тестирования путем автоматизации повторяющихся заданий. Средства тестирования также могут улучшить надежность тестирования путем, например, автоматизации сравнения больших объемов данных или эмуляции поведения. Некоторые типы средств тестирования могут быть «агрессивными» в том смысле, что сам инструментарий влияет на результаты тестирования. Например, измерение времени может быть различным в зависимости от того, как Вы измеряете его, используя различные средства тестирования производительности, или Вы можете получить различную степень покрытия кода в зависимости от средства, которое Вы используете. Различают следующие типы инструментальных средств тестирования: • Средства управления тестированием • Средства статического тестирования • Средства проектирования тестов • Средства поддержки контроля и протоколирования тестов • Средства тестирования производительности и мониторинга • Средства поддержки тестирования приложений специфических областей
Просто покупка или аренда средства не гарантирует успех. Каждый тип средств может потребовать дополнительные затраты для достижения реальных и устойчивых выгод. Существуют потенциальные возможные преимущества использования средств, но также существуют и риски. Потенциальные выгоды от использования инструментальных средств: • Уменьшается повторяющаяся работа (например, запуск регрессионных тестов, ввод одинаковых тестовых данных, проверка на соответствие стандартам программирования). • Большая целостность и повторяемость (например, тесты запускаются средством и получаются из требований). • Объективная оценка (например, статических измерений, покрытия и поведения системы). • Простота доступа к информации о тестах и тестировании (например, статистика и графики о прогрессе тестирования, уровне ошибок и производительности). Риски использования средств тестирования включают: • Нереалистичные ожидания от средства (включая функциональность и простоту использования). • Недооценка времени, стоимости и объемов работ на начальное внедрение средства (включая обучение и внешние экспертизы). • Недооценка времени и объемов работ, необходимых для получения значимого и устойчивого результата от использования средства (включая необходимость изменений в процессе тестирования и постоянного улучшения способа использования средства). • Недооценка затрат на поддержку тестовых артефактов, генерируемых средством. • Слишком большая надежда на средство (замена проектирования тестов или использование там, где ручное тестирование уместней).
Основные принципы внедрения средств в организации включают: • Оценку зрелости, сильных и слабых сторон организации и поиск возможностей улучшенного процесса тестирования, поддерживаемого средствами. • Оценку на основании доступных средств и объективных критериях. • Опытную эксплуатацию для проверки требуемой функциональности и определения того, отвечает ли продукт целям. • Оценка поставщика (включая обучение, поддержку и коммерческий фактор). • Определение внутренних требований к руководству использования средств. Опытная эксплуатация может быть проведена на малом пилотном проекте, позволяющем снизить влияние при обнаружении серьезных препятствий и неудачном пилотном проекте. Пилотный проект имеет следующие цели: • Узнать больше деталей о средстве. • Посмотреть, как средство сочетается с существующими процессами и инструкциями, и как они должны будут измениться. • Принять решение по стандартному использованию, хранению и поддержке средства и преимуществам тестирования (например, соглашения по именованию файлов и тестов, созданию библиотек и определнию модульности тестовых пакетов). • Оценка, будут ли преимущества достигнуты приемлемыми затратами. Факторы успеха развертывания средства в организации включают: • Распространение средства на всю организацию постепенно. • Адаптация и улучшение процессов для совместимости с использованием средства. • Обеспечение обучения и руководства новых пользователей. • Определение норм использования. • Реализация способов получения опыта из использования средства. • Мониторинг использования средства и преимуществ.
Статическое тестирование производится без запуска программного кода продукта. Тестирование осуществляется путем анализа программного кода (соде гемеш) или скомпилированного кода. Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. В отличие от статического, динамическое тестирование производится путем запуска продукта и проверки его функционала. Проверка осуществляется с помощью ручного или автоматического выполнения заранее подготовленного набора тестов.
Цель тестирования - предоставление актуальной информации о соответствии производимого продукта требованиям.
Программным дефектом называется ошибка в программном продукте, вследствие которой продукт ведет себя непредвиденно (неверно). Большинство дефектов возникают из-за допущенной ошибки в программном коде или логической ошибки, допущенной во время проектирования. Гораздо меньшее количество - вследствие ошибок работы инструментальных средств (компилятора, генератора кода).
Граничное тестирование применяется для проверки поведения продукта на крайних значениях входных данных, таких как, например максимумы и минимумы значений. Набор тестов для стресс-тестирования может включать граничные тесты. Граничное тестирование может также включать тесты, проверяющие поведение системы на входных данных, выходящих за допустимый диапазон значений. При этом система должна определенным (заранее оговоренным) способом обрабатывать такие ситуации. Например, с помощью исключительной ситуации или сообщения об ошибке.
Capability Maturity Model Integration (Модель зрелости процессов разработки).
Требования бывают: • Прямыми(Формализованными в технической документации, спецификациях, User Story) • Косвенными (Проистекающими из прямых, либо являющиеся негласным стандартом для данной продукции или основывающиеся на опыте и здравом смысле использования продукта или продуктов подобных ему)
Это решение тест-менеджера, которое чаще всего будет принято на основе: тестового покрытия: анализа рисков; граничных сроков, установленных заранее; выполнения всех предусмотренных тест-кейсов; когда после определенного момента, мы практически не находим новых багов или критических дефектов
Чем раньше, тем лучше. Более детально: когда тестирование ПО проводится на ранней стадии, можно с легкостью повлиять на дизайн, так как его изменение на этой стадии гораздо дешевле, чем на более поздних стадиях; в общем случае, чем раньше обнаруживается ошибка, тем дешевле она стоит компании; также тестирование может начинаться до фактического получения ПО (статическое тестирование), что действительно немаловажно, так как снижает сложность провождения динамической стадии тестирования.
1 Description (Описание) 2 Severity (Серьезность) 3 Steps to reproduce (шаги к воспроизведению) 4 Ехрected result (Ожидаемый результат) 5 Actual result (Фактический результат)
- Принятие решения о создании ПО;
- Сбор и анализ требований;
- Дизайн (Системы и ПО) на основе требований, прототипирование;
- Кодирование на основе дизайна системы;
- Тестирование;
- Внедрение в пользовательскую среду;
- Сопровождение (в том числе фиксация найденных в пользовательской среде ошибок);
- Изъятие из эксплуатации (не всегда);
Контроль качества (QC) - это совокупность действий, проводимых над ПО в процессе разработки, для получения информации о его актуальном состоянии в аспектах готовности к выпуску, соответствия зафиксированным требованиям и соответствия заявленному уровню качества этого ПО.
Верификация(verification) - это процесс оценки системы или ее компонентов с целью определить удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого эта па (выполняются ли цели, сроки, задачи, поставленные в начале текущей фазы). Валидация(validation) - определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе. Расскажите про позитивное и негативное тестирование. Позитивное тестирование проводится в приложении с целью определить, насколько система функциональна. Такой подход больше известен как «тест на прохождение». Тестирование негативных сценариев в ПО: высвечивает ли система ошибку, когда она должна это делать, или не должна. Иными словами проверка таких сценариев, которые не должны иметь место при нормальном использовании программы
Тестирование общей функциональности системы, включая интеграцию данных в модулях. В Е2Е-тестах мы проверяем работоспособность не отдельных юнитов, а всей системы сразу.
Agile - гибкий подход к разработке, включающий разные методологии (Scrum, Канбан, Lean и другие).Это обобщающий термин для целого ряда подходов и практик, основанных на ценностях Манифеста гибкой разработки программного обеспечения и 12 принципах, лежащих в его основе. Вот эти принципы:
- Наивысшим приоритетом является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
- Изменение требований приветствуется, даже на поздних стадиях разработки.
- Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
- На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
- Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
- Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
- Работающий продукт - основной показатель прогресса.
- Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.
- Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
- Простота - искусство минимизации лишней работы - крайне необходима.
- Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
- Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Проверка интерфейса программного обеспечения на предмет соответствия требованиям.
Явление, когда набор проверок, долгое время не подвергающийся изменениям, теряет свою эффективность с течением времени
Дефект, который вынуждает остановить ход тестирования.
Отладка (debugging) - это процесс поиска, анализа, и устранения причин отказов и ошибок в ПО. Чтобы понять, где возникла ошибка, приходится: узнавать текущие значения переменных; выяснять, по какому пути выполнялась программа. Существуют две взаимодополняющие технологии отладки. Использование отладчиков - программ, которые включают в себя пользовательский интерфейс для пошагового выполнения программы: оператор за оператором, функция за функцией, с остановками на некоторых строках исходного кода или при достижении определённого условия. Вывод текущего состояния программы с помощью расположенных в критических точках программы операторов вывода - на экран, принтер, громкоговоритель или в файл. Вывод отладочных сведений в файл называется журналированием.
Сборка (build) - подготовленный для использования информационный продукт. Чаще всего это исполняемый файл (двоичный файл, содержащий исполняемый код программы). Предположим, что номер версии сборки выглядит так: 2.53.1.1 Первый идентификатор - основной номер версии. Второй идентификатор - дополнительный номер версии. Третий идентификатор - номер сборки. Четвёртый идентификатор - номер редакции.
Задачей тестирования стабильности (stability) / надежности (reliability) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Время выполнения операций может играть в данном виде тестирования второстепенную роль. При этом на первое место выходит отсутствие утечек памяти, перезапусков серверов под нагрузкой и другие аспекты, влияющие на стабильность работы.