| 1 |
Тестирование программного обеспечения — проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. |
| 2 |
В более широком смысле, тестирование — это одна из техник контроля качества, включающая в себя активности по планированию работ, проектированию тестов, выполнению тестирования и анализу полученных результатов. Качество программного обеспечения — это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. |
| 3 |
Верификация— это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы. |
| 4 |
Валидация — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе. Также можно встретить иную интерпритацию: |
| 5 |
Процесс оценки соответствия продукта явным требованиям (спецификациям) и есть верификация, в то же время оценка соответствия продукта ожиданиям и требованиям пользователей — есть валидация. Также часто можно встретить следующее определение этих понятий: Цели тестирования Повысить вероятность того, что приложение, предназначенное для тестирования, будет работать правильно при любых обстоятельствах. Повысить вероятность того, что приложение, предназначенное для тестирования, будет соответствовать всем описанным требованиям. |
| 6 |
Предоставление актуальной информации о состоянии продукта на данный момент. Этапы тестирования: 1. Анализ 2. Разработка стратегии тестирования и планирование процедур контроля качества 3. Работа с требованиями 4. Создание тестовой документации 5. Тестирование прототипа 6. Основное тестирование 7. Стабилизация 8. Эксплуатация Тест план— это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения. Отвечает на вопросы: Что надо тестировать? Что будете тестировать? Как будете тестировать? Когда будете тестировать? Критерии начала тестирования. |
| 7 |
Критерии окончания тестирования. Основные пункты тест плана В стандарте перечислены пункты, из которых должен (пусть — может) состоять тест-план: |
| 8 |
1) тест план айдентифайер; 2) интродакшн; 3) тест айтемс; 4) фичерс то би тестед; 5) фичерс нот ту би тестед; 6) эпроач; 7) айтем пэс феил крайтириа; 8) саспеншн крайтириа энд рэсамшн реквайрементс; 9) тест деливеребелс; 10) тестинг таскс;11) энварименталс нидз; 12) респонсибилитис; 13) стаф энд трейнинг нидз;14) скедул; 15) рискс; 16) эпрувелс. Тест дизайн — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования. Роли, ответственные за тест дизайн: Тест аналитик — определяет ЧТО тестировать? Тест дизайнер — определяет КАК тестировать? |
| 9 |
Техники тест дизайна Эквивалентное Разделение. Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала — 0. Анализ Граничных Значений. Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения. Матрица соответствия требований — это двумерная таблица, содержащая соответсвие функциональных требований продукта и подготовленных тестовых сценариев. В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. Матрица соответсвия требований используется для валидации покрытия продукта тестами. |
| 10 |
МСТ является неотъемлемой частью тест-плана. Тестовый случай— это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части. Каждый тест кейс должен иметь 3 части: Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. |
| 11 |
Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния. Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям Список действий, переводящих систему в первоначальное состояние Виды Тестовых Случаев: Тест кейсы разделяются по ожидаемому результату на позитивные и негативные: Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию. |
| 12 |
Негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора. Чек-лист — это документ, описывающий что должно быть протестировано. |
| 13 |
При этом чек-лист может быть абсолютно разного уровня детализации. На сколько детальным будет чек-лист зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта. Как правило, чек-лист содержит только действия (шаги), без ожидаемого результата. |
| 14 |
Чек-лист менее формализован чем тестовый сценарий. Его уместно использовать тогда, когда тестовые сценарии будут избыточны. Также чек-лист ассоциируются с гибкими подходами в тестировании. Дефект (он же баг) — это несоответствие фактического результата выполнения программы ожидаемому результату. |
| 15 |
Дефекты обнаруживаются на этапе тестирования программного обеспечения (ПО), когда тестировщик проводит сравнение полученных результатов работы программы (компонента или дизайна) с ожидаемым результатом, описанным в спецификации требований. |
| 16 |
Баг — ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так как планировалось и программа выходит из-под контроля. Например, когда никак не контроллируется ввод пользователя, в результате неверные данные вызывают краши или иные радости» в работе программы. Либо внутри программа построена так, что изначально не соответствует тому, что от неё ожидается. |
| 17 |
Баг Репорт — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата. |
| 18 |
Шапка Короткое описание Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации. Компонент приложения Название части или функции тестируемого продукта Номер версии Версия на которой была найдена ошибка Серьезность Наиболее распространена пятиуровневая система градации серьезности дефекта: Блокирующий Критический Значительный Незначительный |
| 19 |
Тривиальный Приоритет Приоритет дефекта: Высокий Средний Низкий Статус бага. Зависит от используемой процедуры и жизненного цикла бага Автор Создатель баг репорта Назначен наИмя сотрудника, назначенного на решение проблемы Окружение Описание Шаги воспроизведения Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке. Фактический Результат |
| 20 |
Результат, полученный после прохождения шагов к воспроизведению Ожидаемый результат Ожидаемый правильный результат Дополнения Прикрепленный файл Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы. |
| 21 |
Серьезность — это атрибут, характеризующий влияние дефекта на работоспособность приложения. Приоритет — это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект. |
| 22 |
Уровни Тестирования 1. Модульное тестирование Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.). |
| 23 |
2. Интеграционное тестирование Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования. |
| 24 |
3. Системное тестирование Основной задачей системного тестирования является проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования, отсутствующая или неверная функциональность, неудобство использования и т.д. 4. Операционное тестирование. |
| 25 |
Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации, как это было определено в бизнес моделе системы. |
| 26 |
Следует учесть, что и бизнес модель может содержать ошибки. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях; недостаточная производительность системы в среде эксплуатации и др. |
| 27 |
Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема. Поэтому так важно проведение не только верификации, но и валидации, с самых ранних этапов разработки ПО. 5. Приемочное тестирование Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью: определения удовлетворяет ли система приемочным критериям; вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет. |
| 28 |
Функциональные виды тестирования Функциональное тестирование Тестирование безопасности Тестирование взаимодействия Нефункциональные виды тестирования |
| 29 |
Все виды тестирования производительности: нагрузочное тестирование стрессовое тестирование тестирование стабильности или надежности объемное тестирование Тестирование установки Тестирование удобства пользования Тестирование на отказ и восстановление Конфигурационное тестирование Связанные с изменениями виды тестирования Дымовое тестирование Регрессионное тестирование Повторное тестирование Тестирование сборки Санитарное тестирование или проверка согласованности/исправности |
| 30 |
Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификаций функциональности компонента или системы в целом. |
| 31 |
Тестирование безопасности — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным. |
| 32 |
Тестирование взаимодействия — это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости и интеграционное тестирование Нагрузочное тестирование — это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе. |
| 33 |
Стрессовое тестирование позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса. Стрессом в данном контексте может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. |
| 34 |
Также одной из задач при стрессовом тестировании может быть оценка деградации производительности, таким образом цели стрессового тестирования могут пересекаться с целями тестирования производительности. Объемное тестирование. Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения |
| 35 |
Тестирование стабильности или надежности. Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Тестирование установки направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения. Тестирование удобства пользования — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. |
| 36 |
Сюда также входит: Тестирование пользовательского интерфейса — это вид тестирования исследования, выполняемого с целью определения, удобен ли некоторый искусственный объект (такой как веб-страница, пользовательский интерфейс или устройство) для его предполагаемого применения. Юзер экспириенс — ощущение, испытываемое пользователем во время использования цифрового продукта. |
| 37 |
Тестирование на отказ и восстановление проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). |
| 38 |
Целью данного вида тестирования является проверка систем восстановления (или дублирующих основной функционал систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта. |
| 39 |
Конфигурационное тестирование — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.) Дымовое тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции. |
| 40 |
Регрессионное тестирование — это вид тестирования направленный на проверку изменений, сделанных в приложении или окружающей среде (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что существующая ранее функциональность работает как и прежде. |
| 41 |
Регрессионными могут быть как функциональные, так и нефункциональные тесты. Повторное тестирование — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок. В чем разница между Регрешн тестинг и Ри-тестинг? Ри-тестинг — проверяется исправление багов Регрешн тестинг — проверяется то, что исправление багов не повлияло на другие модули ПО и не вызвало новых багов. |
| 42 |
Тестирование сборки или — тестирование направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования. По своим целям является аналогом Дымового Тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию. |
| 43 |
Вглубь оно может проникать дальше, в зависимости от требований к качеству выпущенной версии. Санитарное тестирование — это узконаправленное тестирование достаточное для доказательства того, что конкретная функция работает согласно заявленным в спецификации требованиям. Является подмножеством регрессионного тестирования. |
| 44 |
Используется для определения работоспособности определенной части приложения после изменений произведенных в ней или окружающей среде. Обычно выполняется вручную. |
| 45 |
Подходы к интеграционному тестированию: Снизу вверх Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения. |
| 46 |
Сверху вниз Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами. Таким образом мы проводим тестирование сверху вниз. Большой взрыв Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. |
| 47 |
Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования. Принципы тестирования Принцип 1 — Тестирование демонстрирует наличие дефектов Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но, даже если дефекты не были обнаружены, это не доказывает его корректности. |
| 48 |
Принцип 2 — Исчерпывающее тестирование недостижимо Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо исчерпывающего тестирования должны использоваться анализ рисков и расстановка приоритетов, чтобы более точно сфокусировать усилия по тестированию. |
| 49 |
Принцип 3 — Раннее тестирование Чтобы найти дефекты как можно раньше, активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки программного обеспечения или системы, и должны быть сфокусированы на определенных целях. Принцип 4 — Скопление дефектов Усилия тестирования должны быть сосредоточены пропорционально ожидаемой, а позже реальной плотности дефектов по модулям. |
| 50 |
Как правило, большая часть дефектов, обнаруженных при тестировании или повлекших за собой основное количество сбоев системы, содержится в небольшом количестве модулей. Принцип 5 — Парадокс пестицида Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот парадокс пестицида», тестовые сценарии должны регулярно рецензироваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения, или системы, и найти как можно больше дефектов. Принцип 6 — Тестирование зависит от контекста Тестирование выполняется по-разному в зависимости от контекста. |
| 51 |
Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем сайт электронной коммерции. Принцип 7 — Заблуждение об отсутствии ошибок Обнаружение и исправление дефектов не помогут, если созданная система не подходит пользователю и не удовлетворяет его ожиданиям и потребностям. |
| 52 |
Cтатическое и динамическое тестирование Статическое тестирование отличается от динамического тем, что производится без запуска программного кода продукта. Тестирование осуществляется путем анализа программного кода или скомпилированного кода. Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. |
| 53 |
Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к статическому тестирвоанию относится тестирования спецификации и прочей документации. Исследовательское / эд-хок тестирование Простейшее определение исследовательского тестирования — это разработка и выполнения тестов в одно и то же время. |
| 54 |
Что является противоположностью сценарного подхода (с его предопределенными процедурами тестирования, неважно ручными или автоматизированными). Исследовательские тесты, в отличие от сценарных тестов, не определены заранее и не выполняются в точном соответствии с планом. Разница между эд хок и экспоратори в том, что теоретически, эд хок может провести кто угодно, а для проведения экспоратори необходимо мастерство и владение определенными техниками. Обратите внимание, что определенные техники это не только техники тестирования. |
| 55 |
Требования — это спецификация (описание) того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения. Что, а не как. |
| 56 |
Требования к требованиям: Корректность Недвусмысленность Полнота набора требований Непротиворечивость набора требований Проверяемость (тестопригодность) Трассируемость Понимаемость Жизненный цикл бага Стадии разработки ПО — это этапы, которые проходят команды разработчиков ПО, прежде чем программа станет доступной для широко круга пользователей. |
| 57 |
Разработка ПО начинается с первоначального этапа разработки (стадия пре-альфа») и продолжается стадиями, на которых продукт дорабатывается и модернизируется. Финальным этапом этого процесса становится выпуск на рынок окончательной версии программного обеспечения (общедоступного релиза). |
| 58 |
Программный продукт проходит следующие стадии: анализ требований к проекту; проектирование; реализация; тестирование продукта; внедрение и поддержка. Каждой стадии разработки ПО присваивается определенный порядковый номер. Также каждый этап имеет свое собственное название, которое характеризует готовность продукта на этой стадии. |
| 59 |
Жизненный цикл разработки ПО: Пре-альфа Альфа Бета Релиз-кандидат Релиз Пост-релиз Таблица принятия решений — великолепный инструмент для упорядочения сложных бизнес требований, которые должны быть реализованы в продукте. В таблицах решений представлен набор условий, одновременное выполнение которых должно привести к определенному действию. |
Комментарии