| 1 |
Приемочное тестирование Проверяет, выполнены ли все бизнес-требования перед выпуском приложения на рынок. На текущем уровне тестирования обязательно должны применяться реальные данные и реальное использование приложения. Такой подход делает приемочное тестирование очень важным этапом цикла выпуска приложения. Это окончательное тестирование, выполняемое после завершения модульного, интеграционного и системного тестирования |
| 2 |
Приемочное тестирование включает следующие формы: Пользовательское приемочное тестирование — производится пользователями конечного продукта; Операционные приемочные испытания - как правило, проводят системные администраторы. Проверяются функции резервного копирования, установка/ удаление/ обновление системы, проверка безопасности и производительности приложения. Необходимо удостовериться, что приложение возможно обслуживать и сопровождать на требуемом уровне даже в экстремальных условиях; Контрактные и нормативные приемочные испытания — проверка, что приложение соблюдает все нормативные требования, продукт не нарушает чью-то интеллектуальную собственность или не использует нелицензионный софт; Альфа и бета-тестирование. |
| 3 |
Тестирование черного ящика (отсутствие доступа к коду) — также известное как тестирование, основанное на спецификации или тестирование поведения — техника, основанная на работе исключительно с внешними интерфейсами системы. |
| 4 |
Согласно ISTQB, тестирование черного ящика — это: тестирование, как функциональное, так и нефункциональное, не предполагающее знания внутреннего устройства компонента или системы; тест-дизайн, основанный на технике черного ящика — процедура написания или выбора тест-кейсов на основе анализа функциональной или нефункциональной спецификации компонента, или системы без знания ее внутреннего устройства. |
| 5 |
Тестирование белого ящика (полный доступ к коду / сам писал код) — вид тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику. Мы выбираем входные значения, основываясь на знании кода, который будет их обрабатывать. Так же мы знаем, каким должен быть результат этой обработки. В данном случае тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит. Как правило, таким видом тестирования на проектах занимаются сами программисты, ведь для использования этого вида тестировщик должен обладать достаточно высокой квалификацией. |
| 6 |
Согласно ISTQB, тестирование белого ящика — это: тестирование, основанное на анализе внутренней структуры компонента или системы; тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента. |
| 7 |
Тестирование серого ящика (частичный доступ к коду) — вид тестирования ПО, который предполагает комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично. |
| 8 |
Статическое тестирование — тип тестирования, при котором код программы не исполняется во время проведения тестов. |
| 9 |
Статическое тестирование включает тестирование спецификации и прочей документации, файлов, либо тестирование и анализ программного кода или скомпилированного кода без его запуска. Может производиться как вручную, так и с помощью специальных инструментальных средств, т.е .автоматизировано. Код-ревью может выполняться одним из участников команды разработчиков или тестировщиком. Как правило, на код-ревью проверяются качество кода, стандарты использования, решения реализации, оставляются комментарии. Это помогает предотвратить дефект на начальном этапе. |
| 10 |
Динамическое тестирование — тестирование, при котором выполняется код программы и проверяется поведение приложения во время работы. Тут происходит взаимодействие с интерфейсом запущенной программы, ее формами, сервером, базой данных и т.д. Если проводятся тесты на работающем приложении — значит, это динамические тесты. |
| 11 |
Тестирование не может доказать отсутствие багов(только их наличие); Исчерпывающее тестирование невозможно по определению; Раннее тестирование позволяет сэкономить ресурсы; Парадокс пестицидов; Кластеризация багов; Тестирование зависит от контекста; Заблуждение об отсутствии багов; |
| 12 |
подходы к тестированию по степени формализации: 1. Тестирование на основе тест-кейсов (виды тестовой документации будут рассмотрены в 3 разделе курса) — формализованный подход, в котором тестирование производится на основе заранее подготовленных тест- кейсов и иной документации. Тест-кейс — это совокупность входных данных, условий выполнения и ожидаемого результата, необходимых для проверки реализации функционала тестируемого программного обеспечения (ПО) или какого-то его свойства. 2. Исследовательское тестирование — это частично формализованный подход тестирования ПО, при котором тестовые наборы не создаются заранее, а тестировщик проверяет приложение «на лету». Тестировщик выполняет работу с продуктом по выбранному сценарию, который, в свою очередь, дорабатывается в процессе выполнения с целью более полного исследования приложения. В качестве альтернативы сценариям при выборе действий с приложением иногда могут использоваться чек-листы. Также в результате исследовательского тестирования могут появиться новые тест- кейсы. То есть мы можем выполнять исследовательское тестирование и с целью написания новых тест-кейсов. 3. Свободное (интуитивное) тестирование полностью неформализованный подход, в котором не предполагается использования ни тест-кейсов, ни чек-листов, ни сценариев. Тестировщик полностью опирается на свою интуицию для спонтанного выполнения с продуктом действий, которые, как он считает, могут обнаружить ошибку. |
| 13 |
Интуитивное тестирование подразделяется на 2 вида: buddy testing (совместное тестирование) — когда 2 человека, как правило разработчик + тестировщик, работают параллельно и находят дефекты в одном и том же модуле. Такой вид тестирования помогает тестировщику выполнять необходимые проверки, а программисту фиксить баги на ранних этапах. pair testing (парное тестирование) — когда 2 тестировщика проверяют один модуль и помогают друг другу. К примеру, один может искать дефекты, а второй — их документировать. Какой именно подход выбирать — зависит от конкретного проекта и целей поставленных перед тестировщиком. |
| 14 |
Ручное тестирование - это вид тестирования, при котором тестировщики вручную выполняют тесты без использования инструментов автоматизации. |
| 15 |
Каждое приложение должно быть протестировано вручную, прежде чем тесты можно будет автоматизировать. Это делается для того, чтобы определить, нужно ли вообще внедрять автоматизацию. Для проведения ручного тестирования необязательно владеть навыками использования какого-либо инструмента. Один из основных принципов тестирования заключается в том, что 100% автоматизация невозможна. Поэтому ручное тестирование неизбежно во всех проектах. |
| 16 |
Автоматизированное тестирование - это вид тестирования, при котором тесты проверяются автоматически с помощью специальных инструментов. Например, Selenium или Appium. Как только тесты автоматизированы, человек практически не принимает участие в выполнении тестов. Поэтому автоматизированное тестирование является эффективным видом тестирования. Цель автоматизации - сократить количество тестов, которые необходимо выполнять вручную, чтобы сократить время на тестирование. |
| 17 |
Позитивное тестирование — тестирование с применением сценариев, которые соответствуют ожидаемому поведению приложения. Пример позитивного сценария: для Авторизации в системе уже зарегистрированного пользователя необходимо ввести существующий логин, правильный пароль, нажать кнопку «Войти». Ожидаемый результат — произошел вход в систему. |
| 18 |
Негативное тестирование — тестирование с применением сценариев, которые соответствуют внештатному поведению приложения. Негативные тестовые сценарии проверяют, как приложение справляется с данными, которые выходят за границы, предусмотренные требованиями, или неожиданными действиями пользователя. Пример негативного сценария: для Авторизации в системе уже зарегистрированного пользователя ввести несуществующий логин, или неправильный пароль, нажать кнопку «Войти». Ожидаемый результат – появляется сообщение о неправильности введенных данных. |
| 19 |
Негативное тестирование - это тестирование того, как ведет себя приложение, получая на вход «неправильные» данные. Это делается для того, чтоб определить, как ведет себя приложение в таком случае. Если такой вариант описан в спецификации, а он должен быть описан, то сравнить ожидаемый результат с полученным результатом. Обработка невалидных данных всегда описываются в качественных требованиях. |
| 20 |
Дымовое тестирование - включает в себя минимальный набор тестов на самые очевидные ошибки. Дымовое тестирование проверяет работоспособность критически важных функциональных частей приложения. Например, регистрация нового пользователя, создание нового заказа, выставление счета клиенту, получение оплаты. Это базовый функционал, который регулярно контролируется Smoke-тестами. |
| 21 |
Санитарное тестирование — проводится после незначительных изменений в функционале, коде или починке багов. Проверяет, что исправленный код или новый функционал работает, как и ожидалось. Как пример, программисты устранили дефект на странице создания нового заказа. В этом случае санитарные тесты должны проверить общее состояние приложения и нацелены на то, чтобы избежать потерь времени и усилий, чтобы быстрее определить возможные недостатки ПО и их критичность, а также стоит ли переходить в фазу более тщательного тестирования. Обычно выполняется вручную. |
| 22 |
Регрессионное тестирование — тестирование приложения, направленное на обнаружение ошибок в ранее проверенных участках программ (или исходных кодах). Помогает убедиться, что недавние изменения не сломали работающую функциональность приложения. Регрессионные тесты должны проводиться при любых изменениях кода, потому полная автоматизация — лучшая практика в этом типе тестирования. В регрессию включаются тесты, которые покрывают тестирование безопасности, критических и важных функций. Включаются те области, которые часто меняются в ходе разработки, где высока вероятность ошибки. |
| 23 |
Функциональное тестирование включает в себя тесты, оценивающие функции приложения. Функции системы — это то, «что» должна делать система. С помощью этого вида приложение проверяется на способность выполнять свои функции. Сюда входят: модульное, интеграционное, системное и приемочное тестирование. Кроме того, регрессионное и дымовое тестирования тоже являются подвидами функционального. Исполняется функциональное тестирование на основании требований в виде спецификаций или пользовательских историй. |
| 24 |
Нефункциональное тестирование оценивает характеристики систем и программного обеспечения, такие как надежность, производительность, удобство использования, эффективность работы или его безопасность. Нефункциональное тестирование — это проверка того, «насколько хорошо» ведет себя система. |
| 25 |
санитарное тестирование проводится после изменения в программном коде или функционале, чтобы проверить, что все работает так, как и должно быть после этого изменения. повторное тестирование проводят после исправления дефекта в части функционала или программы, чтобы подтвердить, что он действительно был исправлен. |
| 26 |
Тестирование пользовательского интерфейса — проверка соответствия интерфейса ПО требованиям дизайна. Например, проверка наличия всех требуемых элементов на странице, их размеров и расположения, тестирование шрифтов, цветов, изображений. |
| 27 |
Тестирование удобства пользования — определение удобства использования приложения. Проверяется эргономичность интерфейсов. Например, оформление и графические элементы с точки зрения удобства восприятия, удобство навигации. В этот вид входит Тестирование доступности. Тестирование Доступности — проверка доступности приложения для пользователей с нарушением слуха, зрения и цветовосприятия, а также людей, у которых нет возможности использовать клавиатуру. Например, использование определенной цветовой гаммы, добавление субтитров на видео или озвучивание всей страницы. |
| 28 |
Тестирование производительности — тестирование скорости работы приложения под определённой нагрузкой. |
| 29 |
Нагрузочное тестирование — данный тип тестирования позволяет оценить поведение системы при нормальных условиях и возрастающей нагрузке, целью нагрузочного тестирования является также определение максимальной нагрузки, которую может выдержать система. Например, мы рассчитываем, что одновременно приложением будет пользоваться 500 пользователей, и через специальные программы (например Jmeter) создаются условия, которые моделируют использование приложения одновременно чуть менее 500 пользователями. |
| 30 |
Стресс-тестирование — используется для определения устойчивости системы или модуля при пороговых значениях рабочей нагрузки или за ее пределом. К примеру моделируются условия одновременного использования 500 или немногим более пользователей. |
| 31 |
Объемное тестирование — тестирование позволяет оценить производительность системы при увеличении объемов данных как самого приложения, так и его базы данных. Когда те же 500 пользователей отправляют одновременно какой-то объем информации. |
| 32 |
Тестирование надежности — проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки. |
| 33 |
Тестирование безопасности — оценка уязвимости приложения к различным атакам. Оценка безопасности пользовательских данных, на сколько просто неавторизованный пользователь может получить доступ к системе или данным. |
| 34 |
Тестирование установки — проверка успешной инсталляции, настройки, обновления и удаления. |
| 35 |
Тестирование совместимости — проверка корректной работы приложения в определенном окружении, например, устройстве, операционной системе (кроссплатформенное тестирование) или браузере (кроссбраузерное тестирование). |
| 36 |
Тестирование на отказ и восстановление — проверка насколько хорошо приложение может оправиться от аварий и сбоев оборудования. |
| 37 |
Тестирование локализации — тестирования локализованной версии приложения: проверка правильности перевода интерфейса пользователя, системных сообщений и ошибок, раздела "Помощь"/"Справка", документации, контроль формата даты и времени. |
| 38 |
Тестирование интернационализации — Насколько продукт может адаптироваться для той или иной локали при выходе на другие рынки. Например, возможность поддержки вертикального текста Азиатских стран, чтение справа налево в арабских странах. |
| 39 |
сновная задача тестирования - это проверка ПО на соответствие между реальным поведением программы и её ожидаемым поведением на конечном наборе тестов, выбранных определенным образом. Ожидаемое поведение описывается в спецификации - это документ, описывающий реализацию программы в виде требований. |
| 40 |
Спецификация должна соответствовать следующим критериям: Корректность — точное описание. Проверяемость — описание требований таким образом, чтобы можно было однозначно понять, выполнено все в соответствии с требованиями или нет. Полнота — в требовании должна содержаться вся необходимая информация для реализации. Недвусмысленность — требование должно однозначно описываться. Непротиворечивость — требования не должны противоречить другим требованиям и документам. Приоритетность — у каждого требования должен быть приоритет, что позволит грамотно управлять ресурсами на проекте. Атомарность — требование нельзя декомпозировать на отдельные части без потери деталей. Модифицируемость — каждое требование можно изменить без потери цели требования. Прослеживаемость — требование должно иметь уникальный идентификатор, по которому на него можно сослаться. |
| 41 |
Общие требования к ПО на рынке: Функциональная пригодность - программа должна решать заявленные задачи пользователя. Надежность - программа должна работать стабильно, так как любой сбой потенциально приносит убытки. Защищенность - программа должна сохранять пользовательские данные в безопасности. Удобство использования - программа должна быть приятна и эффективна. |
| 42 |
Гайдлайн - это руководство по использованию фирменного стиля, которое содержит инструкцию о том, как работать с элементами дизайна. Например, у iOS и Android есть свои гайдлайны. Здравый смысл. Бывают баги и в самой спецификации, связанные с нерациональным использованием или реализацией определенной функциональности. В случае расхождения предполагаемой реализации функциональности со здравым смыслом, необходимо предложить улучшения продукта. Конкуренты. Исследование конкурентов — постоянный процесс. Суть конкурентного анализа — всегда знать, куда движется рынок, что делают конкуренты, как меняются интересы аудитории. Результаты анализа нужно обновлять регулярно, раз в квартал или в год. |
| 43 |
В процессе тестирования любого продукта создается документация, которая помогает организовать работу отдела тестирования и держать всех членов команды в курсе дела. Такая документация создается до начала или в процессе тестирования. В хорошо оформленной документации любой член команды может найти всю необходимую информацию. |
| 44 |
Тест-кейс — это документ с описанными четкими действиями, которые нужно выполнить, чтобы проверить какую-либо функцию продукта. Эти действия направлены на проверку того, что функция работает должным образом и соответствует стандартам, и требованиям клиента. Простыми словами тест-кейс — это проверка получения ожидаемого результата. Тест-кейс «Проверить ввод отрицательных чисел в поле "Возраст"» означает, что нужно попробовать ввести отрицательные числа в указанное поле и в ответ, например, получить сообщение, что такие данные вводить недопустимо. Тест-кейсы, проверяющие одну функциональность, могут быть объединены в тест-сьюты (тест-наборы). |
| 45 |
1. ID — обязательный атрибут. Это номер тест-кейса. 2. Заголовок (название) — обязательный атрибут. 3. Предусловия — необязательный атрибут. 4. Шаги — обязательный атрибут. 5. Постусловия — необязательный атрибут. 6. Ожидаемый результат — обязательный атрибут. 7. Требования к среде — необязательный атрибут. 8. История редактирования — необязательный атрибут. |
Комментарии