По времени проведения тестирования
· Альфа-тестирование
· Дымовое тестирование (англ. smoke testing)
· Тестирование новой функции (new feature testing)
· Подтверждающее тестирование
· Регрессионное тестирование
· Приёмочное тестирование
· Бета-тестирование
По признаку позитивности сценариев
· Позитивное тестирование
· Негативное тестирование
По степени подготовленности к тестированию
· Тестирование по документации (формальное тестирование)
· Интуитивное тестирование (англ. ad hoc testing)
Билет №2
1. Что такое тестирование на основе рисков?
Для обеспечения качества информационного продукта в медицине, страховании, банкинге и других отраслях, наряду с другими методами тестирования, важно использовать тестирование, основанное на рисках. Для проверки выбирают самые рискованные области создаваемого программного обеспечения. Это позволяет предусмотреть негативные сценарии и успешно реализовать бизнес-цели заказчика.
Например, рассмотрим тестирование мобильного и веб-приложения для банка. На старте проекта мы подобрали стратегию, основанную на требованиях с невысоким уровнем детализации. Мы использовали чек-листы, чтобы сократить время на тестирование и поддержку тестового базиса. По мере роста функциональности, добавления эквайринга, sms-авторизации и оповещения, более сложных систем чек-листы уже не справлялись со своей задачей. Со временем в команду подключалось все больше QA-специалистов, нужно было передавать информацию и координировать их действия. С усложнением продукта любое изменение могло повлиять на смежные функции, то есть возрастал риск регрессии. Назревала необходимость автоматизации регрессионных тестов, поэтому мы переключились на тест-кейсы.
|
|
|
Вывод: в зависимости от проекта, его специфики или этапа разработки стратегия тестирования меняется.
2. Что такое раннее тестирование?
Тестовые активности должны начинаться как можно раньше в цикле разработки и быть сфокусированы на определенных целях.
Этот принцип связан с понятием «цена дефекта» (cost of defect). Цена дефекта существенно растет на протяжении жизненного цикла разработки ПО. Чем раньше обнаружен дефект, тем быстрее, проще и дешевле его исправить.
Дефект, найденный в требованиях, обходится дешевле всего. Если дефект обнаружен на этапе разработки архитектурного решения, исправить его тоже не составляет большого труда. Если же дефект, внесенный еще на уровне требований, «дожил» до этапа системного или приемочного тестирования, исправление его будет очень дорогим – ведь придется внести изменения не только в код, но, возможно, и в архитектуру, и в требования. Кроме того, один дефект в требованиях может проявиться во множественных дефектах на уровне архитектуры и кода, а после внесения исправлений нужно вновь проводить тестирование.
Порой дефекты, обнаруженные на слишком поздней стадии, вообще не исправляются, потому что это обошлось бы слишком дорого.
|
|
|
Случается, и так, что ПО поставляется и формально соответствует согласованным требованиям, но не соответствует нуждам и потребностям пользователей. Это также вызывает целый ряд проблем – нежелание пользователей переходить на новую систему, сложности с продажей и внедрением и так далее. Это значит, что требования изначально были неполны, но этот изъян не был обнаружен.
Вот почему важно начинать тестирование как можно раньше, со статических техник.
Что такое исчерпывающее тестирование?
Это очень долгий и утомительный метод тестирования. В нём все типы входов передаются программному обеспечению для проверки выходов. С помощью этого метода тестирования проверяется каждая строчка кода . Испытание может быть утомительным, но это самый практичный и надежный метод. Таким образом проверяется стойкость программного обеспечения, а также его способность работать в экстремальных условиях.
|
|
|
Исчерпывающее тестирование уместно только для небольших проектов. В сложных проектах этот метод будет катастрофой, поскольку он требует много времени и затрат. Следовательно, этот метод не является надежным для крупных проектов. Исчерпывающее тестирование - это процесс тестирования абсолютно всего, чтобы убедиться, что продукт не может быть разрушен или поврежден случайными событиями. После того, как программное обеспечение проходит тестирование, оно становится наиболее совершенным и надежным для своего применения.
Тестировщики применяют каждую перестановку и комбинации для определения дефектов или ошибок в программном приложении. Говорят, что полное тестирование невозможно из-за больших затрат времени и денег. Чем раньше работа будет завершена, тем продуктивнее считается программное обеспечение. Невозможно предсказать, что в любой ситуации конкретное программное обеспечение будет работать так, как ожидается . Практически невозможно описать каждый аспект, через который может пройти программное обеспечение в будущем. Столь быстрый прогресс в технологиях делает это еще сложнее.
Билет №3
1. Что такое скопление дефектов?
|
|
|
Скопление дефектов – совокупность внутренних дефектов, состоящих из трех или более дефектов, не лежащих на одной прямой, при условии, что расстояние между соседними дефектами не превышает3-х кратного размера наибольшего из дефектов.
О том, где «кучкуются» дефекты, можно узнать еще на ранних этапах, когда проводится статическое тестирование (например, code review и анализ кода при помощи специальных инструментах). Когда дойдет дело до динамического тестирования, можно сфокусироваться на тех областях, где было обнаружено больше дефектов статическими методами.
Также полезно проводить анализ первопричин (root cause analysis), чтобы предотвратить повторное появление дефектов, обнаружить причины возникновения скоплений дефектов и спрогнозировать потенциальные скопления дефектов в будущем.
2. Что такое «парадокс пестицида»?
Прогоняя одни и те же тесты вновь и вновь, Вы столкнетесь с тем, что они находят все меньше новых ошибок. Поскольку система эволюционирует, многие из ранее найденных дефектов исправляют и старые тест-кейсы больше не срабатывают.
Чтобы преодолеть этот парадокс, необходимо периодически вносить изменения в используемые наборы тестов, рецензировать и корректировать их с тем, чтобы они отвечали новому состоянию системы и позволяли находить как можно большее количество дефектов.
3. Что такое статическое тестирование?
Статическое тестирование – тип тестирования, который предполагает, что программный код во время тестирования не будет выполняться. При этом само тестирование может быть как ручным, так и автоматизированным.
Статическое тестирование начинается на ранних этапах жизненного цикла ПО и является, соответственно, частью процесса верификации. Для этого типа тестирования в некоторых случаях даже не нужен компьютер – например, при проверке требований.
Большинство статических техник могут быть использованы для «тестирования» любых форм документации, включая вычитку кода, инспекцию проектной документации, функциональной спецификации и требований.
Даже статическое тестирование может быть автоматизировано – например, можно использовать автоматические средства проверки синтаксиса программного кода.
Виды статического тестирования:
– вычитка исходного кода программы;
– проверка требований.
Билет №4
1. Что такое позитивное тестирование?
Позитивное тестирование - это тип тестирования, который проверяет, что тестируемое приложение правильно работает для положительного набора входов.
Другими словами, позитивное тестирование - это тестирование, которое выполняется в границах, и это тестирование проверяет, что продукт / приложение работает согласно документу спецификации с допустимым набором тестовых данных.
Пример 1. Веб-приложение имеет форму для заполнения.
2. Пользователь должен ввести имя пользователя, пароль и нажать «Отправить». Когда пользователь вводит правильное имя пользователя и пароль и нажимает кнопку «Отправить», должен осуществиться переход на следующую страницу.
Сценарий положительного тестирования:
Введите правильное имя пользователя и пароль, нажмите на кнопку отправки и убедитесь , что пользователь переходит к следующей странице , как ожидалось.
Дата добавления: 2019-11-16; просмотров: 157; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!