Оригинал статьи Баха.
RST методология: "Ответственный тестировщик"
В методологии Быстрого тестирования мы выделяем три основные роли: Лидер. Ответственный тестировщик и Помощник. Различия этих ролей ситуационны. Одно и то же лицо может быть помощником в одной ситуации, лидером в другой и ответственным тестировщиком в третьей.
Ответственный тестировщик
Быстрое тестирование - человекоцентрированная методология, так как тестирование это работа, которую может выполнять только человек. Таким образом, тестирование должно происходить под наблюдением людей, в противном случае это буквально и фигурально безответственно. Таким образом ответственный тестировщик - это тестировщик, который берет на себя ответственность за тестирование определенной вещи определенным образом для конкретного проекта. Ответственный тестировщик отвечает за качество теститрования, что значит, что он может оправдать и отстоять тестирования, а также сделать его лучше, если это необходимо. Ответственные тестировщики могут также запрашивать и контролировать помощников, если это необходимо (см. ниже).
Это контрастирует с заводским стилем тестирования, который опирается на инструменты и тексты, а не на людей. В заводской школе тестирования неважно, кто выполняет работу, так как люди взаимозаменяемы. Ответственность в таком мире не мантия на чьих-то плечах, а что-то вроде смога, которым стремятся много не дышать.
пример тестирования без ответственного тестировщика: Человек А пишет текст, называет его "тест-кейс", передает его Человеку Б. Этот человек читает текст и выполняет инструкции. Это может хорошо звучать, но что делать, если у Человека Б недостаточно квалификации, чтоб оценить, правильно ли он понял и провел тест, в то же время, как Человек А не наблюдает за ним, а значит не в состоянии оценить его работу. Это все равно, что машина без водителя. Никто не берет на себя ответственность. Никто не может сказать было ли тестирование проведено хорошо и никто не пример мер, если оно было плохим. Если проблема объявится позже, то каждый из этих людей может справедливо обвинить в ней другого.
такая ситуация является "грехом" в быстром тестировании. Чтоб практиковать RST, для каждой работы есть ответственный тестировщик, на которого опирается проект (конечно, студенты и непрофессиональные тестировщики могут работать без присмотра в надежде найти ошибку. Но они не будут опорой проекта).
Ответственный тестировщик подобен водителю автомобиля или командиру воздушного судна.
Помощник
помощник это тот, кто вносит свой вклад в тестирования, не принимая на себя ответственность за качество работы. другими словами, когда ответственный тестировщик просит кого-нибудь сделать что-то простое, нажать на кнопку, помощник может сделать это, не беспокоясь о том, что на самом деле выполняет миссию тестирования. Помощников не стоит путать с неопытными или неквалифицированными сотрудниками. они могут быть опытными или иметь полезные навыки. главному архитектору, который пришел потестировать, может быть предложено проверить часть продукта и найти интересные ошибки, не ожидая от него обоснования стратегии тестирования. Это работа ответственного тестировщика - наблюдение за людьми, которые предлагают помощь и оценка степени пригодности их работы.
Бета-тестирование происходит исключительно за счет помощников. Но без ответственного тестировщика невозможно глубоко оценить, что было достигнуто. Хороший способ использования бета-тестеров - их организация одним или несколькими ответственными тестировщиками.
Лидер
лидер, это тот, чьи обязанности заключаются в поддержании проекта в состоянии, в котором возможно тестирование, обучение, поддержка и оценка ответственных тестировщиков. Есть по крайней мере два вида лидеров, тест-лид и тест-менеджер. тест-менеджер это тест-лид с дополнительной ответственностью за найм, увольнение, аттестацию и , возможно, бюджет.
В некоторых ситуациях, когда лидер отвечает за тестирование, но у него еще нет ответственных тестировщиков в команде, он сам становится таковым. Лидер в окружении помощников и является ответственным тестировщиком команды.
Показаны сообщения с ярлыком терминология. Показать все сообщения
Показаны сообщения с ярлыком терминология. Показать все сообщения
вторник, 21 января 2014 г.
понедельник, 10 октября 2011 г.
Воскресный потрындец.
О тестировании.
Вот тут мне сказали:
.. в процессе тестирования найдутся баги, которые
а) тянут за собой время на исправление и перепроверку
б) могут заблокировать проверку какой-то фичи
в) создают при фиксинге новые баги
и так может повториться и еще раз, и еще раз..
Соответственно, сразу желательно закладывать надо время (как минимум): [testing_iteration_1_time] + [fixing_time] + [testing_iteration_2_time]. Но и этого часто недостаточно, а у менеджера будет вопрос "А почему так много - 2 месяца на тестирование?"
На что я ответил, не претендуя при этом на какую-то вселенскую истину, а просто рассказывая как есть:
... побить на микросервисы (у нас - именно так). То есть прогнать автотесты на клиенте стоит столько то часов, пробить это же руками - столько то, протестить фичу перед релизом, протестить весь жизненный путь фичи и так далее. Этакий прайс. И по отдельности - вполне допустимые трудо-и-времязатраты. И еще и объяснимые. Приемлемые.
А потом наши ПМы хотят что-то сделать с клиентом - поставить фичу - подходят к прайсу и "покупают" набор того, чего им нужно. Какую-то фичу можно смотреть перед релизом. Какую-то надо сопровождать. А какая-то затрагивает слишком много.
И в сумме набегают те же самые месяцы. Но они состоят из понятных - а главное самостоятельно купленных частей. Не будешь же спорить сам с собой.
Перечитал я свой ответ и мне аж блин самому понравилось.
Взгуглил. Пояндексил. 84 и 24 ссылки. Нифига себе. Подумал и взгуглил на мунспике. 800 миллионов ссылок. Черт, так и знал, страна ориджинал контента, чтоб ее. Даже книжку написали, супостаты.
Ну, что поделаешь, тогда я расскажу, как это работает у нас. Ну или как мне бы хотелось, чтоб оно работало. Мою версию.
Waterfall нам говорит, что тестирование это этап. До своего этапа тестировщики пишут сценарии и прочие автотесты, а после - пьют горькую и проводят ретроспективы по кабакам. Как то так:
Продвинутый ватерфалл предлагает чуть допилить схему:
Мы реально нормальные и понимаем, что люди эту схему выстрадали, потому и мы ее применяем. То есть имеется тестирование на всех этапах - тестирование требований, юниты, персональный тестер программиста, дейли, предрелиз - все честь по чести. Это в масштабах продукта.
А в масштабе групп разработки нормальный такой скрам - с планированием, итерациями, митингами и демо:
Это - дано. А потом Реальность донесла свое видение ситуации:
1. Интеграционное автоматизированное тестирование ну никак не вписывалось в скрам программистов, а потому работало на викли и дейли версии и релизы.
2. Полное(и не очень) ручное тестирование релиза - не укладывалось в ежедневный и еженедельный ритм жизни и требовало себе несколько дней, несколько людей и отдельную очередь, прием по записи, крупным провайдерам, пенсионерам и сотовым операторам - без очереди и скидки
3. Тестирование требований оказалось очень мощной практикой(хитрожопые аналитики моментально прочухали, что тут есть люди, которые могут делать их работу), поэтому стало отдельной от полного сопровождения фичи опцией
горжусь и хвастаюсь: слева от меня сидит девочка, ПМы подкрадываются к начальству и шепотом просят - а можно Наташу на эту задачку? Быть может, будут предлагать денег, цветы и коньяк в виде взятки
Теперь умножаем это на количество клиентов и получаем достаточно интересную реальность, в которой вполне жизнеспособен например такой сценарий:
ПМ желает клиенту пару фич и фиксов. И организует заявку, с блоком "задание на тестирование", который ПМ составляет как из кубиков.
Эта фича требует полного сопровождения, от постановки до релиза, двум фиксам хватит ретеста в рамках скрама и дейли автотестов, этот фикс - нужно ручками проверить перед релизом. Полного тестирования релиза не надо, хватит интеграционных.
Заявка - пакет работ - попадает на ответственного тестировщика,
который выбирает незанятый народ(выгрызает время у занятого), узнает ссылки, явки и пароли, просит натравить на стенд боевые скрипты, потом суммирует результаты и высылает инфу ПМу. Который и ведет заявку дальше...
То есть получается этакий тестировщик микроПМ, клиентом которого становятся ПМы.
Ну а равномерность загрузки обеспечивается большим количеством клиентов, ПМов, собственно тестировщиков (9 штук, это целое отделение), а так же здоровым пофигизмом последних.
Пока что мы еще не полностью перешли на принцип TaaS - хотя бы потому, что а) не планировали этого делать б) вообще не знали, что этим занимаемся, просто работали.
Плюсы - удовлетворенность клиентов - ПМов. Они вроде как вовлечены в процесс и сами собирают конструктор тестирования. А значит и претензий меньше.
Еще - постоянная ротация задач и клиентов тестировщика. Возможность поруководить другими, заняться организацией и планированием.
Выводы: надо почитать, что народ пишет по ссылкам, что я нагуглил. Ну и всегда интересны ваши версии на все эти счета.
P.S. Близким манером вроде бы в Иннове работают тестировщики. У Юли Нечаевой. Вот тут она рассказывает. Ну, у нее конечное все связней и по пунктам написано. Зато у меня хендмейд картинки.
P.P.S. Это не я такой прям заебись молодец, все так красиво (или не очень) настроил. Это создавалось до меня, вместе со мной, помимо меня и кое-что против моей воли :). Ну я в том смысле что у меня замечательные коллеги, да.
P.P.P.S. Я сейчас отнюдь не занимался описанием процесса тестирования в отдельно взятомвоображении отделе. Я развивал мысль о том, как мы идем в сторону Testing as a Service.
Вот тут мне сказали:
.. в процессе тестирования найдутся баги, которые
а) тянут за собой время на исправление и перепроверку
б) могут заблокировать проверку какой-то фичи
в) создают при фиксинге новые баги
и так может повториться и еще раз, и еще раз..
Соответственно, сразу желательно закладывать надо время (как минимум): [testing_iteration_1_time] + [fixing_time] + [testing_iteration_2_time]. Но и этого часто недостаточно, а у менеджера будет вопрос "А почему так много - 2 месяца на тестирование?"
На что я ответил, не претендуя при этом на какую-то вселенскую истину, а просто рассказывая как есть:
... побить на микросервисы (у нас - именно так). То есть прогнать автотесты на клиенте стоит столько то часов, пробить это же руками - столько то, протестить фичу перед релизом, протестить весь жизненный путь фичи и так далее. Этакий прайс. И по отдельности - вполне допустимые трудо-и-времязатраты. И еще и объяснимые. Приемлемые.
А потом наши ПМы хотят что-то сделать с клиентом - поставить фичу - подходят к прайсу и "покупают" набор того, чего им нужно. Какую-то фичу можно смотреть перед релизом. Какую-то надо сопровождать. А какая-то затрагивает слишком много.
И в сумме набегают те же самые месяцы. Но они состоят из понятных - а главное самостоятельно купленных частей. Не будешь же спорить сам с собой.
Перечитал я свой ответ и мне аж блин самому понравилось.
Взгуглил. Пояндексил. 84 и 24 ссылки. Нифига себе. Подумал и взгуглил на мунспике. 800 миллионов ссылок. Черт, так и знал, страна ориджинал контента, чтоб ее. Даже книжку написали, супостаты.
Ну, что поделаешь, тогда я расскажу, как это работает у нас. Ну или как мне бы хотелось, чтоб оно работало. Мою версию.
Waterfall нам говорит, что тестирование это этап. До своего этапа тестировщики пишут сценарии и прочие автотесты, а после - пьют горькую и проводят ретроспективы по кабакам. Как то так:
 |
| Альбом: bug |
Продвинутый ватерфалл предлагает чуть допилить схему:
 |
| Альбом: bug |
Мы реально нормальные и понимаем, что люди эту схему выстрадали, потому и мы ее применяем. То есть имеется тестирование на всех этапах - тестирование требований, юниты, персональный тестер программиста, дейли, предрелиз - все честь по чести. Это в масштабах продукта.
А в масштабе групп разработки нормальный такой скрам - с планированием, итерациями, митингами и демо:
 |
| Альбом: bug |
Это - дано. А потом Реальность донесла свое видение ситуации:
1. Интеграционное автоматизированное тестирование ну никак не вписывалось в скрам программистов, а потому работало на викли и дейли версии и релизы.
2. Полное(и не очень) ручное тестирование релиза - не укладывалось в ежедневный и еженедельный ритм жизни и требовало себе несколько дней, несколько людей и отдельную очередь, прием по записи, крупным провайдерам, пенсионерам и сотовым операторам - без очереди и скидки
3. Тестирование требований оказалось очень мощной практикой(
горжусь и хвастаюсь: слева от меня сидит девочка, ПМы подкрадываются к начальству и шепотом просят - а можно Наташу на эту задачку? Быть может, будут предлагать денег, цветы и коньяк в виде взятки
Теперь умножаем это на количество клиентов и получаем достаточно интересную реальность, в которой вполне жизнеспособен например такой сценарий:
ПМ желает клиенту пару фич и фиксов. И организует заявку, с блоком "задание на тестирование", который ПМ составляет как из кубиков.
 |
| Альбом: bug |
Эта фича требует полного сопровождения, от постановки до релиза, двум фиксам хватит ретеста в рамках скрама и дейли автотестов, этот фикс - нужно ручками проверить перед релизом. Полного тестирования релиза не надо, хватит интеграционных.
Заявка - пакет работ - попадает на ответственного тестировщика,
 |
| Альбом: bug |
который выбирает незанятый народ(выгрызает время у занятого), узнает ссылки, явки и пароли, просит натравить на стенд боевые скрипты, потом суммирует результаты и высылает инфу ПМу. Который и ведет заявку дальше...
То есть получается этакий тестировщик микроПМ, клиентом которого становятся ПМы.
 |
| Альбом: bug |
Ну а равномерность загрузки обеспечивается большим количеством клиентов, ПМов, собственно тестировщиков (9 штук, это целое отделение), а так же здоровым пофигизмом последних.
Пока что мы еще не полностью перешли на принцип TaaS - хотя бы потому, что а) не планировали этого делать б) вообще не знали, что этим занимаемся, просто работали.
Плюсы - удовлетворенность клиентов - ПМов. Они вроде как вовлечены в процесс и сами собирают конструктор тестирования. А значит и претензий меньше.
Еще - постоянная ротация задач и клиентов тестировщика. Возможность поруководить другими, заняться организацией и планированием.
Выводы: надо почитать, что народ пишет по ссылкам, что я нагуглил. Ну и всегда интересны ваши версии на все эти счета.
P.S. Близким манером вроде бы в Иннове работают тестировщики. У Юли Нечаевой. Вот тут она рассказывает. Ну, у нее конечное все связней и по пунктам написано. Зато у меня хендмейд картинки.
P.P.S. Это не я такой прям заебись молодец, все так красиво (или не очень) настроил. Это создавалось до меня, вместе со мной, помимо меня и кое-что против моей воли :). Ну я в том смысле что у меня замечательные коллеги, да.
P.P.P.S. Я сейчас отнюдь не занимался описанием процесса тестирования в отдельно взятом
среда, 29 апреля 2009 г.
Уровни тестирования (Test Levels)
Это заметка для меня.
2.1 Над чем производятся тесты (The target of the test)
Тестирование обычно производится на протяжении всей разработки и сопровождения на разных уровнях. Уровень тестирования определяет “над чем” производятся тесты: над отдельным модулем, группой модулей или системой, в целом. При этом ни один из уровней тестирования не может считаться приоритетным. Важны все уровни тестирования, вне зависимости от используемых моделей и методологий.
2.1.1 Модульное тестирование (Unit testing)
Этот уровень тестирования позволяет проверить функционирование отдельно взятого элемента системы. Что считать элементом – модулем системы определяется контекстом. Наиболее полно данный вид тестов описан в стандарте IEEE 1008-87 “Standard for Software Unit Testing”, задающем интегрированную концепцию систематического и документированного подхода к модульному тестированию.
2.1.2 Интеграционное тестирование (Integration testing)
Данный уровень тестирования является процессом проверки взаимодействия между программными компонентами/модулями.
Классические стратегии интеграционного тестирования – “сверху-вниз” и “снизу-вверх” – используются для традиционных, иерархически структурированных систем и их сложно применять, например, к тестированию слабосвязанных систем, построенных в сервисно-ориентированных архитектурах (SOA).
Современные стратегии в большей степени зависят от архитектуры тестируемой системы и строятся на основе идентификации функциональных “потоков” (например, потоков операций и данных).
Интеграционное тестирование – постоянно проводимая деятельность, предполагающая работу на достаточно высоком уровне абстракции. Наиболее успешная практика интеграционного тестирования базируется на инкрементальном подходе, позволяющем избежать проблем проведения разовых тестов, связанных с тестированием результатов очередного длительного этапа работ, когда количество выявленных дефектов приводит к серьезной переработке кода (традиционно, негативный опыт выпуска и тестирования только крупных релизов называют “big bang”).
2.1.3 Системное тестирование (System testing)
Системное тестирование охватывает целиком всю систему. Большинство функциональных сбоев должно быть идентифицировано еще на уровне модульных и интеграционных тестов. В свою очередь, системное тестирование, обычно фокусируется на нефункциональных требованиях – безопасности, производительности, точности, надежности т.п.
На этом уровне также тестируются интерфейсы к внешним приложениям, аппаратному обеспечению, операционной среде и т.д.
2.2 Цели тестирования (Objectivies of Testing)
Тестирование проводится в соответствии с определенными целями (могут быть заданы явно или неявно) и различным уровнем точности. Определение цели точным образом, выражаемым количественно, позволяет обеспечить контроль результатов тестирования.
Тестовые сценарии могут разрабатываться как для проверки функциональных требований (известны как функциональные тесты), так и для оценки нефункциональных требований. При этом, существуют такие тесты, когда количественные параметры и результаты тестов могут лишь опосредованно говорить об удовлетворении целям тестирования (например, “usability” – легкость, простота использования, в большинстве случаев, не может быть явно описана количественными характеристиками).
Можно выделить следующие, наиболее распространенные и обоснованные цели (а, соответственно, виды) тестирования:
2.2.1 Приёмочное тестирование (Acceptance/qualification testing)
Проверяет поведение системы на предмет удовлетворения требований заказчика. Это возможно в том случае, если заказчик берет на себя ответственность, связанную с проведением таких работ, как сторона “принимающая” программную систему, или специфицированы типовые задачи, успешная проверка (тестирование) которых позволяет говорить об удовлетворении требований заказчика.
Такие тесты могу проводиться как с привлечением разработчиков системы, так и без них.
2.2.2 Установочное тестирование (Installation testing)
Из названия следует, что данные тесты проводятся с целью проверки процедуры инсталляции системы в целевом окружении.
2.2.3 Альфа- и бета-тестирование (Alpha and beta testing)
Перед тем, как выпускается программное обеспечение, как минимум, оно должно проходить стадии альфа (внутреннее пробное использование) и бета (пробное использование с привлечением отобранных внешних пользователей) версий. Отчеты об ошибках, поступающие от пользователей этих версий продукта, обрабатываются в соответствии с определенными процедурами, включающими подтверждающие тесты (любого уровня), проводимые специалистами группы разработки.
Данный вид тестирования не может быть заранее спланирован.
2.2.4 Функциональные тесты/тесты соответствия (Conformance testing/Functional testing/Correctness testing)
Эти тесты могут называться по разному, однако, их суть проста – проверка соответствия системы, предъявляемым к ней требованиям, описанным на уровне спецификации поведенческих характеристик.
2.2.5 Достижение и оценка надежности (Reliability achievement and evaluation)
Помогая идентифицировать причины сбоев, тестирование подразумевает и повышение надежности программных систем. Случайно генерируемые сценарии тестирования могут применяться для статистической оценки надежности. Обе цели – повышение и оценка надежности – могут достигаться при использовании моделей повышения надежности. Эти вопросы затрагиваются и в тематическом фрагменте 4.1.4 “Life test, reliability evaluation”.
2.2.6 Регрессионное тестирование (Regression testing)
Определение успешности регрессионных тестов (IEEE 610-90 “Standard Glossary of Software Engineering Terminology”) гласит: “повторное выборочное тестирование системы или компонент для проверки сделанных модификаций не должно приводить к непредусмотренным эффектам”. На практике это означает, что если система успешно проходила тесты до внесения модификаций, она должна их проходит и после внесения таковых. Основная проблема регрессионного тестирования заключается в поиске компромисса между имеющимеся ресурсами и необходимостью проведения таких тестов по мере внесения каждого изменения. В определенной степени, задача состоит в том, чтобы определить критерии “масштабов” изменений, с достижением которых необходимо проводить регрессионные тесты.
2.2.7 Тестирование производительности (Performance testing)
Специализированные тесты проверки удовлетворения специфических требований, предъявляемых к параметрам производительности. Существует особый подвид таких тестов, когда делается попытка достижения количественных пределов, обусловленных характеристиками самой системы и ее операционного окружения.
2.2.8 Нагрузочное тестирование (Stress testing)
Необходимо понимать отличия между рассмотренным выше тестированием производительности с целью достижения ее реальных (достижимых) возможностей производительности и выполнением программной системы c повышением нагрузки, вплоть до достижения запланированных характеристик и далее, с отслеживанием поведения на всем протяжении повышения загрузки системы.
2.2.9 Сравнительное тестирование (Back-to-back testing)
Единичный набор тестов, позволяющих сравнить две версии системы.
2.2.10 Восстановительные тесты (Recovery testing)
Цель – проверка возможностей рестарта системы в случае непредусмотренной катастрофы (disaster), влияющей на функционирование операционной среды, в которой выполняется система.
2.2.11 Конфигурационное тестирование (Configuration testing)
В случаях, если программное обеспечение создается для использования различными пользователями (в терминах “ролей”), данный вид тестирования направлен на проверку поведения и работоспособности системы в различных конфигурациях.
2.2.12 Тестирование удобства и простоты использования (Usability testing)
Цель – проверить, насколько легко конечный пользователь системы может ее освоить, включая не только функциональную составляющую – саму систему, но и ее документацию; насколько эффективно пользователь может выполнять задачи, автоматизация которых осуществляется с использованием данной системы; наконец, насколько хорошо система застрахована (с точки зрения потенциальных сбоев) от ошибок пользователя.
2.2.13 Разработка, управляемая тестированием (Test-driven development)
По-сути, это не столько техника тестирования, сколько стиль организации процесса разработки, жизненного цикла, когда тесты являются неотъемлемой частью требований (и соответствующих спецификаций) вместо того, чтобы рассматриваться независимой деятельностью по проверке удовлетворения требований программной системой.
Иногда говорят о таком стиле разработки как о самостоятельной методологии – TDD. Насколько это верно, зависит от того, что именно понимать под методологией разработки. Скорее, с точки зрения автора, это техника, практика или стиль организации работы, чем самостоятельная методология.
В меньшей степени это относится к FDD – Feature-Driven Development (разработка на основе функциональных возможностей). TDD может естественно рассматриваться как составная часть XP или, как минимум Agile-методов. В свою очередь, FDD может рассматриваться как один из методов гибкой разработки.
В чем отличие столь близких, на первый взгляд, подходов (и, кстати, соответствующих аббревиатур)? Причина – проста. Тесты – инструмент достижения характеристик системы, удовлетворяющей заданным требованиям, то есть потребностям пользователей, а “возможности” (features) – практически сами (чаще – функциональные) требования, воплощенные (в идеальном случае) в код.
Копирайт http://it4business.ru/?p=41&print=1
2.1 Над чем производятся тесты (The target of the test)
Тестирование обычно производится на протяжении всей разработки и сопровождения на разных уровнях. Уровень тестирования определяет “над чем” производятся тесты: над отдельным модулем, группой модулей или системой, в целом. При этом ни один из уровней тестирования не может считаться приоритетным. Важны все уровни тестирования, вне зависимости от используемых моделей и методологий.
2.1.1 Модульное тестирование (Unit testing)
Этот уровень тестирования позволяет проверить функционирование отдельно взятого элемента системы. Что считать элементом – модулем системы определяется контекстом. Наиболее полно данный вид тестов описан в стандарте IEEE 1008-87 “Standard for Software Unit Testing”, задающем интегрированную концепцию систематического и документированного подхода к модульному тестированию.
2.1.2 Интеграционное тестирование (Integration testing)
Данный уровень тестирования является процессом проверки взаимодействия между программными компонентами/модулями.
Классические стратегии интеграционного тестирования – “сверху-вниз” и “снизу-вверх” – используются для традиционных, иерархически структурированных систем и их сложно применять, например, к тестированию слабосвязанных систем, построенных в сервисно-ориентированных архитектурах (SOA).
Современные стратегии в большей степени зависят от архитектуры тестируемой системы и строятся на основе идентификации функциональных “потоков” (например, потоков операций и данных).
Интеграционное тестирование – постоянно проводимая деятельность, предполагающая работу на достаточно высоком уровне абстракции. Наиболее успешная практика интеграционного тестирования базируется на инкрементальном подходе, позволяющем избежать проблем проведения разовых тестов, связанных с тестированием результатов очередного длительного этапа работ, когда количество выявленных дефектов приводит к серьезной переработке кода (традиционно, негативный опыт выпуска и тестирования только крупных релизов называют “big bang”).
2.1.3 Системное тестирование (System testing)
Системное тестирование охватывает целиком всю систему. Большинство функциональных сбоев должно быть идентифицировано еще на уровне модульных и интеграционных тестов. В свою очередь, системное тестирование, обычно фокусируется на нефункциональных требованиях – безопасности, производительности, точности, надежности т.п.
На этом уровне также тестируются интерфейсы к внешним приложениям, аппаратному обеспечению, операционной среде и т.д.
2.2 Цели тестирования (Objectivies of Testing)
Тестирование проводится в соответствии с определенными целями (могут быть заданы явно или неявно) и различным уровнем точности. Определение цели точным образом, выражаемым количественно, позволяет обеспечить контроль результатов тестирования.
Тестовые сценарии могут разрабатываться как для проверки функциональных требований (известны как функциональные тесты), так и для оценки нефункциональных требований. При этом, существуют такие тесты, когда количественные параметры и результаты тестов могут лишь опосредованно говорить об удовлетворении целям тестирования (например, “usability” – легкость, простота использования, в большинстве случаев, не может быть явно описана количественными характеристиками).
Можно выделить следующие, наиболее распространенные и обоснованные цели (а, соответственно, виды) тестирования:
2.2.1 Приёмочное тестирование (Acceptance/qualification testing)
Проверяет поведение системы на предмет удовлетворения требований заказчика. Это возможно в том случае, если заказчик берет на себя ответственность, связанную с проведением таких работ, как сторона “принимающая” программную систему, или специфицированы типовые задачи, успешная проверка (тестирование) которых позволяет говорить об удовлетворении требований заказчика.
Такие тесты могу проводиться как с привлечением разработчиков системы, так и без них.
2.2.2 Установочное тестирование (Installation testing)
Из названия следует, что данные тесты проводятся с целью проверки процедуры инсталляции системы в целевом окружении.
2.2.3 Альфа- и бета-тестирование (Alpha and beta testing)
Перед тем, как выпускается программное обеспечение, как минимум, оно должно проходить стадии альфа (внутреннее пробное использование) и бета (пробное использование с привлечением отобранных внешних пользователей) версий. Отчеты об ошибках, поступающие от пользователей этих версий продукта, обрабатываются в соответствии с определенными процедурами, включающими подтверждающие тесты (любого уровня), проводимые специалистами группы разработки.
Данный вид тестирования не может быть заранее спланирован.
2.2.4 Функциональные тесты/тесты соответствия (Conformance testing/Functional testing/Correctness testing)
Эти тесты могут называться по разному, однако, их суть проста – проверка соответствия системы, предъявляемым к ней требованиям, описанным на уровне спецификации поведенческих характеристик.
2.2.5 Достижение и оценка надежности (Reliability achievement and evaluation)
Помогая идентифицировать причины сбоев, тестирование подразумевает и повышение надежности программных систем. Случайно генерируемые сценарии тестирования могут применяться для статистической оценки надежности. Обе цели – повышение и оценка надежности – могут достигаться при использовании моделей повышения надежности. Эти вопросы затрагиваются и в тематическом фрагменте 4.1.4 “Life test, reliability evaluation”.
2.2.6 Регрессионное тестирование (Regression testing)
Определение успешности регрессионных тестов (IEEE 610-90 “Standard Glossary of Software Engineering Terminology”) гласит: “повторное выборочное тестирование системы или компонент для проверки сделанных модификаций не должно приводить к непредусмотренным эффектам”. На практике это означает, что если система успешно проходила тесты до внесения модификаций, она должна их проходит и после внесения таковых. Основная проблема регрессионного тестирования заключается в поиске компромисса между имеющимеся ресурсами и необходимостью проведения таких тестов по мере внесения каждого изменения. В определенной степени, задача состоит в том, чтобы определить критерии “масштабов” изменений, с достижением которых необходимо проводить регрессионные тесты.
2.2.7 Тестирование производительности (Performance testing)
Специализированные тесты проверки удовлетворения специфических требований, предъявляемых к параметрам производительности. Существует особый подвид таких тестов, когда делается попытка достижения количественных пределов, обусловленных характеристиками самой системы и ее операционного окружения.
2.2.8 Нагрузочное тестирование (Stress testing)
Необходимо понимать отличия между рассмотренным выше тестированием производительности с целью достижения ее реальных (достижимых) возможностей производительности и выполнением программной системы c повышением нагрузки, вплоть до достижения запланированных характеристик и далее, с отслеживанием поведения на всем протяжении повышения загрузки системы.
2.2.9 Сравнительное тестирование (Back-to-back testing)
Единичный набор тестов, позволяющих сравнить две версии системы.
2.2.10 Восстановительные тесты (Recovery testing)
Цель – проверка возможностей рестарта системы в случае непредусмотренной катастрофы (disaster), влияющей на функционирование операционной среды, в которой выполняется система.
2.2.11 Конфигурационное тестирование (Configuration testing)
В случаях, если программное обеспечение создается для использования различными пользователями (в терминах “ролей”), данный вид тестирования направлен на проверку поведения и работоспособности системы в различных конфигурациях.
2.2.12 Тестирование удобства и простоты использования (Usability testing)
Цель – проверить, насколько легко конечный пользователь системы может ее освоить, включая не только функциональную составляющую – саму систему, но и ее документацию; насколько эффективно пользователь может выполнять задачи, автоматизация которых осуществляется с использованием данной системы; наконец, насколько хорошо система застрахована (с точки зрения потенциальных сбоев) от ошибок пользователя.
2.2.13 Разработка, управляемая тестированием (Test-driven development)
По-сути, это не столько техника тестирования, сколько стиль организации процесса разработки, жизненного цикла, когда тесты являются неотъемлемой частью требований (и соответствующих спецификаций) вместо того, чтобы рассматриваться независимой деятельностью по проверке удовлетворения требований программной системой.
Иногда говорят о таком стиле разработки как о самостоятельной методологии – TDD. Насколько это верно, зависит от того, что именно понимать под методологией разработки. Скорее, с точки зрения автора, это техника, практика или стиль организации работы, чем самостоятельная методология.
В меньшей степени это относится к FDD – Feature-Driven Development (разработка на основе функциональных возможностей). TDD может естественно рассматриваться как составная часть XP или, как минимум Agile-методов. В свою очередь, FDD может рассматриваться как один из методов гибкой разработки.
В чем отличие столь близких, на первый взгляд, подходов (и, кстати, соответствующих аббревиатур)? Причина – проста. Тесты – инструмент достижения характеристик системы, удовлетворяющей заданным требованиям, то есть потребностям пользователей, а “возможности” (features) – практически сами (чаще – функциональные) требования, воплощенные (в идеальном случае) в код.
Копирайт http://it4business.ru/?p=41&print=1
вторник, 3 марта 2009 г.
На полях.
Диверсификация — (от лат. diversus — разный и fасеrе — делать) —
1) распределение инвестируемых или ссужаемых денежных капиталов между различными объектами вложений с целью снижения риска возможных потерь капитала или доходов от него. Такую Д. называют Д. кредитов. В области банковских операций принцип Д. проявляется в распределении ссудного капитала между большим числом клиентов. Иногда банковское законодательство запрещает коммерческим банкам предоставлять одной фирме кредит на сумму, превышающую 10 % собственного капитала банка. На принципе Д. базируется деятельность инвестиционных компаний и фондов.
2) Расширение ассортимента, изменение вида продукции, производимой предприятием, фирмой, освоение новых видов производств с целью повышения эффективности производства, получения экономической выгоды, предотвращения банкротства.
©http://ru.wikipedia.org
1) распределение инвестируемых или ссужаемых денежных капиталов между различными объектами вложений с целью снижения риска возможных потерь капитала или доходов от него. Такую Д. называют Д. кредитов. В области банковских операций принцип Д. проявляется в распределении ссудного капитала между большим числом клиентов. Иногда банковское законодательство запрещает коммерческим банкам предоставлять одной фирме кредит на сумму, превышающую 10 % собственного капитала банка. На принципе Д. базируется деятельность инвестиционных компаний и фондов.
2) Расширение ассортимента, изменение вида продукции, производимой предприятием, фирмой, освоение новых видов производств с целью повышения эффективности производства, получения экономической выгоды, предотвращения банкротства.
P.S. Как правильно назвать должность человека, который в цикле разработки ПО занимается поддержкой среды коллективной разработки, в частности настройкой билдов, режимы компиляции, target'ами, наличием библиотек и много остального, чего я пока не знаю и не понимаю?
воскресенье, 25 января 2009 г.
Вопросы тестировщику
Еще несколько вопросов к тестировщику, ответы на которые не помешало бы мне знать.
Это к заметкам на полях.
1. Что такое приемочное тестирование (Acceptance Testing)?
2. Что такое тестирование доступности (Accessibility Testing)?
3. Что такое специальное тестирование (Ad Hoc Testing)?
4. Что такое гибкое тестирование (Agile Testing)?
5. Что такое бинарный интерфейс приложения (Application Binary Interface (ABI))?
6. Что такое программный интерфейс приложения (Application Programming Interface (API))?
7. Что такое программное обеспечение автоматизации качества (Automated Software Quality (ASQ))?
8. Что такое автоматизированное тестирование (Automated Testing)?
9. Что такое форма Бэкуса-Наура (Backus-Naur Form)?
10. Что такое базовый блок (Basic Block)?
11. Что такое тестирование базового пути (Basis Path Testing)?
12. Что такое базовый набор тестов (Basis Set)?
13. Что такое основание тестирования (Baseline)?
14. Что вы будете делать в течение первого рабочего дня?
15. Что такое бета-тестирование (Beta Testing)?
16. Что такое тестирование бинарной портативности (Binary Portability Testing)?
17. Что такое тестирование черного ящика (Black Box Testing)?
18. Что такое восходящее тестирование (Bottom Up Testing)?
19. Что такое тестирование границ (Boundary Testing)?
20. Что такое баг (Bug)?
21. Что такое дефект (Defect)?
22. Что такое анализ граничных значений (Boundary Value Analysis)?
23. Что такое тестирование ветвей (Branch Testing)?
24. Что такое широкое тестирование (Breadth Testing)?
25. Что такое компьютерные инструменты для тестирования программного обеспечения (Computer Aided Software Testing (CAST))?
26. Что такое инструментарий записи/воспроизведения (Capture/Replay Tool)?
27. Что такое модель зрелости разработки программного обеспечения (Capability Ma-turity Model (CMM))?
28. Что такое график причин и следствий (Cause Effect Graph)?
29. Что такое завершенный код (Code Complete)?
30. Что такое покрытие кода (Code Coverage)?
31. Что такое инспекция кода (Code Inspection)?
32. Что такое скозной контроль кода (Code Walkthrough)?
33. Что такое кодирование (Coding)?
34. Что такое сравнительное тестирование (Compatibility Testing)?
35. Что такое компонент (Component)?
36. Что такое компонентное тестирование (Component Testing)?
37. Что такое тестирование совместного доступа (Concurrency Testing)?
38. Что такое тестирование соответствия (Conformance Testing)?
39. Что такое тестирование управления контекстом (Context Driven Testing)?
40. Что такое тестирование преобразования (Conversion Testing)?
41. Что такое цикломатическая сложность (Cyclomatic Complexity)?
42. Что такое словарь данных (Data Dictionary)?
43. Что такое диаграмма потоков данных (Data Flow Diagram)?
44. Что такое тестирование управления данными (Data Driven Testing)?
45. Что такое отладка (Debugging)?
46. Что такое дефект (Defect)?
47. Что такое тестирование зависимости (Dependency Testing)?
48. Что такое глубокое тестирование (Depth Testing)?
49. Что такое динамическое тестирование (Dynamic Testing)?
50. Что такое эмулятор (Emulator)?
©Оригинал и перевод
Это к заметкам на полях.
1. Что такое приемочное тестирование (Acceptance Testing)?
2. Что такое тестирование доступности (Accessibility Testing)?
3. Что такое специальное тестирование (Ad Hoc Testing)?
4. Что такое гибкое тестирование (Agile Testing)?
5. Что такое бинарный интерфейс приложения (Application Binary Interface (ABI))?
6. Что такое программный интерфейс приложения (Application Programming Interface (API))?
7. Что такое программное обеспечение автоматизации качества (Automated Software Quality (ASQ))?
8. Что такое автоматизированное тестирование (Automated Testing)?
9. Что такое форма Бэкуса-Наура (Backus-Naur Form)?
10. Что такое базовый блок (Basic Block)?
11. Что такое тестирование базового пути (Basis Path Testing)?
12. Что такое базовый набор тестов (Basis Set)?
13. Что такое основание тестирования (Baseline)?
14. Что вы будете делать в течение первого рабочего дня?
15. Что такое бета-тестирование (Beta Testing)?
16. Что такое тестирование бинарной портативности (Binary Portability Testing)?
17. Что такое тестирование черного ящика (Black Box Testing)?
18. Что такое восходящее тестирование (Bottom Up Testing)?
19. Что такое тестирование границ (Boundary Testing)?
20. Что такое баг (Bug)?
21. Что такое дефект (Defect)?
22. Что такое анализ граничных значений (Boundary Value Analysis)?
23. Что такое тестирование ветвей (Branch Testing)?
24. Что такое широкое тестирование (Breadth Testing)?
25. Что такое компьютерные инструменты для тестирования программного обеспечения (Computer Aided Software Testing (CAST))?
26. Что такое инструментарий записи/воспроизведения (Capture/Replay Tool)?
27. Что такое модель зрелости разработки программного обеспечения (Capability Ma-turity Model (CMM))?
28. Что такое график причин и следствий (Cause Effect Graph)?
29. Что такое завершенный код (Code Complete)?
30. Что такое покрытие кода (Code Coverage)?
31. Что такое инспекция кода (Code Inspection)?
32. Что такое скозной контроль кода (Code Walkthrough)?
33. Что такое кодирование (Coding)?
34. Что такое сравнительное тестирование (Compatibility Testing)?
35. Что такое компонент (Component)?
36. Что такое компонентное тестирование (Component Testing)?
37. Что такое тестирование совместного доступа (Concurrency Testing)?
38. Что такое тестирование соответствия (Conformance Testing)?
39. Что такое тестирование управления контекстом (Context Driven Testing)?
40. Что такое тестирование преобразования (Conversion Testing)?
41. Что такое цикломатическая сложность (Cyclomatic Complexity)?
42. Что такое словарь данных (Data Dictionary)?
43. Что такое диаграмма потоков данных (Data Flow Diagram)?
44. Что такое тестирование управления данными (Data Driven Testing)?
45. Что такое отладка (Debugging)?
46. Что такое дефект (Defect)?
47. Что такое тестирование зависимости (Dependency Testing)?
48. Что такое глубокое тестирование (Depth Testing)?
49. Что такое динамическое тестирование (Dynamic Testing)?
50. Что такое эмулятор (Emulator)?
©Оригинал и перевод
Есть вопросы
Это к моим заметкам
Тестовые вопросы на вакансию "Тестировщик (QA)":
1. Перечислите основные цели тестирования.
2. Перечислите основные цели обеспечения качества.
3. В чем заключается принцип тестирования по методу "черного ящика"?
4. В чем заключается принцип тестирования по методу "прозрачного ящика"?
5. В чем заключается тестирование сборки?
6. Какие стратегии сборки вы знаете? Перечислите их достоинства и недостатки.
7. Какие типы ошибок позволяет обнаружить тестирование сборки?
8. В чам заключается тестирование компонентов?
9. Какие типы ошибок позволяет обнаружить тестирование компонентов?
10. В чем заключается тестирование системы?
11. Какие типы ошибок позволяет обнаружить тестирование системы?
12. Расположите тестирование компонентов, тестирование сборки и тестирование системы в том порядке, в каком эти методы применяются в жизненном цикле разработки.
13. Что такое "граничные условия"? Приведите примеры граничных условий.
14. Перечислите известные вам методы обеспечения качества.
15. Перечислите известные вам принципы организации процесса производства ПО.
16. В чем особенность "водопадной" модели организации процесса производства ПО? На каком принципе она базируется?
17. В чем особенность модели унифицированного процесса (UP) организации производства ПО? На каком принципе она базируется?
18. В чем особенность модели производства ПО? применяемой в экстремальном программировании (XP)? На каком принципе она базируется?
19. Что является основой для создания тестовых сценариев?
20. Перечислите известные вам средства автоматизации тестирования. Дайте их сравнительную характеристику.
21. Перечислите известные вам автоматизированные средства отслеживания дефектов и (или) изменений. Дайте их сравнительную характеристику.
22. Перечислите известные вам автоматизированные средства управления версиями. Дайте их сравнительную характеристику.
23. Перечислите нефункциональные характеристики программных средств (категории нефункциональных требований), которые могут быть подвергнуты тестированию. Опишите, как вы будете проводить тестирование каждой из этих характеристик.
24. Что такое "покрытие"?
25. Какие вы знаете виды покрытий?
26. Для чего используется анализ покрытия?
27. Как оценить степень покрытия?
28. Что представляет собой диаграмма переходов? Для чего она используется?
29. Что представляет собой матрица перекрестных ссылок? Для чего она используется?
30. Когда используется метод тестирования ортогональных массивов?
31. В чем заключается тестирование наследования? Для чего оно используется?
32. Для чего используются тесты категории "нет данных"?
33. Для чего используются тесты категории "повторное выполнение"?
34. Для чего используются тесты категории "верные данные"?
35. Для чего используются тесты категории "неверные данные"?
36. Для чего используются тесты категории "потери мощности"?
37. Для чего используются тесты категории "создание напряжений в системе"?
38. Для чего используются тесты категории "тестирование характеристик"?
39. Что собой представляет тестовый пример (TestCase в UP)?
40. Что собой представляет план тестирования?
©it4business.ru
Надо будет для себя ответить, сдается мне, не лишнее. Навскидку отвечу менее, чем на треть вопросов, хотя с большинство понятий знаком. Слегка, хех.
Тестовые вопросы на вакансию "Тестировщик (QA)":
1. Перечислите основные цели тестирования.
2. Перечислите основные цели обеспечения качества.
3. В чем заключается принцип тестирования по методу "черного ящика"?
4. В чем заключается принцип тестирования по методу "прозрачного ящика"?
5. В чем заключается тестирование сборки?
6. Какие стратегии сборки вы знаете? Перечислите их достоинства и недостатки.
7. Какие типы ошибок позволяет обнаружить тестирование сборки?
8. В чам заключается тестирование компонентов?
9. Какие типы ошибок позволяет обнаружить тестирование компонентов?
10. В чем заключается тестирование системы?
11. Какие типы ошибок позволяет обнаружить тестирование системы?
12. Расположите тестирование компонентов, тестирование сборки и тестирование системы в том порядке, в каком эти методы применяются в жизненном цикле разработки.
13. Что такое "граничные условия"? Приведите примеры граничных условий.
14. Перечислите известные вам методы обеспечения качества.
15. Перечислите известные вам принципы организации процесса производства ПО.
16. В чем особенность "водопадной" модели организации процесса производства ПО? На каком принципе она базируется?
17. В чем особенность модели унифицированного процесса (UP) организации производства ПО? На каком принципе она базируется?
18. В чем особенность модели производства ПО? применяемой в экстремальном программировании (XP)? На каком принципе она базируется?
19. Что является основой для создания тестовых сценариев?
20. Перечислите известные вам средства автоматизации тестирования. Дайте их сравнительную характеристику.
21. Перечислите известные вам автоматизированные средства отслеживания дефектов и (или) изменений. Дайте их сравнительную характеристику.
22. Перечислите известные вам автоматизированные средства управления версиями. Дайте их сравнительную характеристику.
23. Перечислите нефункциональные характеристики программных средств (категории нефункциональных требований), которые могут быть подвергнуты тестированию. Опишите, как вы будете проводить тестирование каждой из этих характеристик.
24. Что такое "покрытие"?
25. Какие вы знаете виды покрытий?
26. Для чего используется анализ покрытия?
27. Как оценить степень покрытия?
28. Что представляет собой диаграмма переходов? Для чего она используется?
29. Что представляет собой матрица перекрестных ссылок? Для чего она используется?
30. Когда используется метод тестирования ортогональных массивов?
31. В чем заключается тестирование наследования? Для чего оно используется?
32. Для чего используются тесты категории "нет данных"?
33. Для чего используются тесты категории "повторное выполнение"?
34. Для чего используются тесты категории "верные данные"?
35. Для чего используются тесты категории "неверные данные"?
36. Для чего используются тесты категории "потери мощности"?
37. Для чего используются тесты категории "создание напряжений в системе"?
38. Для чего используются тесты категории "тестирование характеристик"?
39. Что собой представляет тестовый пример (TestCase в UP)?
40. Что собой представляет план тестирования?
©it4business.ru
Надо будет для себя ответить, сдается мне, не лишнее. Навскидку отвечу менее, чем на треть вопросов, хотя с большинство понятий знаком. Слегка, хех.
воскресенье, 18 января 2009 г.
Регрессионное тестирование
Очередное продолжение заметок на полях.
При корректировках программы необходимо гарантировать сохранение качества. Для этого используется регрессионное тестирование - дорогостоящая, но необходимая деятельность в рамках этапа сопровождения, направленная на перепроверку корректности измененной программы. В соответствии со стандартным определением, регрессионное тестирование - это выборочное тестирование, позволяющее убедиться, что изменения не вызвали нежелательных побочных эффектов, или что измененная система по-прежнему соответствует требованиям.
Главной задачей этапа сопровождения является реализация систематического процесса обработки изменений в коде. После каждой модификации программы необходимо удостовериться, что на функциональность программы не оказал влияния модифицированный код. Если такое влияние обнаружено, говорят о регрессионном дефекте. Для регрессионного тестирования функциональных возможностей, изменение которых не планировалось, используются ранее разработанные тесты. Одна из целей регрессионного тестирования состоит в том, чтобы, в соответствии с используемым критерием покрытия кода (например, критерием покрытия потока операторов или потока данных), гарантировать тот же уровень покрытия, что и при полном повторном тестировании программы. Для этого необходимо запускать тесты, относящиеся к измененным областям кода или функциональным возможностям.
Другая цель регрессионного тестирования состоит в том, чтобы удостовериться, что программа функционирует в соответствии со своей спецификацией, и что изменения не привели к внесению новых ошибок в ранее протестированный код. Эта цель всегда может быть достигнута повторным выполнением всех тестов регрессионного набора, но более перспективно отсеивать тесты, на которых выходные данные модифицированной и старой программы не могут различаться.
Важной задачей регрессионного тестирования является также уменьшение стоимости и сокращение времени выполнения тестов.
Виды регрессионного тестирования
Поскольку регрессионное тестирование представляет собой повторное проведение цикла обычного тестирования, виды регрессионного тестирования совпадают с видами обычного тестирования. Можно говорить, например, о модульном регрессионном тестировании или о функциональном регрессионном тестировании.
Другой способ классификации видов регрессионного тестирования связывает их с типами сопровождения, которые, в свою очередь, определяются типами модификаций. Выделяют три типа сопровождения:
• Корректирующее сопровождение, называемое обычно исправлением ошибок, выполняется в ответ на обнаружение ошибки, не требующей изменения спецификации требований. При корректирующем сопровождении производится диагностика и корректировка дефектов в программном обеспечении с целью поддержания системы в работоспособном состоянии.
• Адаптивное сопровождение осуществляется в ответ на требования изменения данных или среды исполнения. Оно применяется, когда существующая система улучшается или расширяется, а спецификация требований изменяется с целью реализации новых функций.
• Усовершенствующее (прогрессивное) сопровождение включает любую обработку с целью повышения эффективности работы системы или эффективности ее сопровождения.
В процессе адаптивного или усовершенствующего сопровождения обычно вводятся новые модули. Чтобы отобразить то или иное усовершенствование или адаптацию, изменяется спецификация системы. При корректирующем сопровождении, как правило, спецификация не изменяется, и новые модули не вводятся. Модификация программы на фазе разработки подобна модификации при корректирующем сопровождении, так как из-за обнаружения ошибки вряд ли требуется менять спецификацию программы. За исключением редких моментов крупных изменений, на фазе сопровождения изменения системы обычно невелики и производятся с целью устранения проблем или постепенного расширения функциональных возможностей
Соответственно, определяют два типа регрессионного тестирования: прогрессивное и корректирующее.
• Прогрессивное регрессионное тестирование предполагает модификацию технического задания. В большинстве случаев при этом к системе программного обеспечения добавляются новые модули.
• При корректирующем регрессионном тестировании техническое задание не изменяется. Модифицируются только некоторые операторы программы и, возможно, конструкторские решения.
Прогрессивное регрессионное тестирование обычно выполняется после адаптивного или усовершенствующего сопровождения, тогда как корректирующее регрессионное тестирование выполняется во время тестирования в цикле разработки и после корректирующего сопровождения, то есть после того, как над программным обеспечением были выполнены некоторые корректирующие действия. Вообще говоря, корректирующее регрессионное тестирование должно быть более простым, чем прогрессивное регрессионное тестирование, поскольку допускает повторное использование большего количества тестов.
Подход к отбору регрессионных тестов может быть активным или консервативным. Активный подход во главу угла ставит уменьшение объема регрессионного тестирования и пренебрегает риском пропустить дефекты. Активный подход применяется для тестирования систем с высокой исходной надежностью, а также в случаях, когда эффект изменений невелик. Консервативный подход требует отбора всех тестов, которые с ненулевой вероятностью могут обнаруживать дефекты. Этот подход позволяет обнаруживать большее количество ошибок, но приводит к созданию более обширных наборов регрессионных тестов.
Управляемое регрессионное тестирование
Для обеспечения управляемости регрессионного тестирования необходимо выполнение ряда условий:
• Как при модульном, так и при интеграционном регрессионном тестировании в качестве модулей, вызываемых тестируемым модулем непосредственно или косвенно, должны использоваться реальные модули системы. Это легко осуществить, поскольку на этапе регрессионного тестирования все модули доступны в завершенном виде.
• Информация об изменениях корректна. Информация об изменениях указывает на измененные модули и разделы спецификации требований, не подразумевая при этом корректность самих изменений. Кроме того, при изменении спецификации требований необходимо усиленное регрессионное тестирование изменившихся функций этой спецификации, а также всех функций, которые могли быть затронуты по неосторожности. Единственным случаем когда мы вынуждены положиться на правильность измененного технического задания, является изменение технического задания для всей системы или для модуля верхнего (в графе вызовов) уровня, при условии, что кроме технического задания, не существует никакой дополнительной документации и/или какой-либо другой информации, по которой можно было бы судить об ошибке в техническом задании.
• В программе нет ошибок, кроме тех, которые могли возникнуть из-за ее изменения.
• Тесты, применявшиеся для тестирования предыдущих версий программного продукта, доступны, при этом протокол прогона тестов состоит из входных данных, выходных данных и траектории. Траектория представляет собой путь в управляющем графе программы, прохождение которого вызывается использованием некоторого набора входных данных. Ее можно применять для оценки структурного покрытия, обеспечиваемого набором тестов.
• Для проведения регрессионного тестирования с использованием существующего набора тестов необходимо хранить информацию о результатах выполнения тестов на предыдущих этапах тестирования.
Обоснование корректности метода отбора тестов
• Некоторые участки кода программы не получают управление при выполнении некоторых тестов.
• Если участок кода реализует требование, но измененный фрагмент кода не получает управления при выполнении теста, то он и не может воздействовать на значения выходных данных программы при выполнении данного теста.
• Даже если участок кода, реализующий требование, получает управление при выполнении теста, это далеко не всегда отражается на выходных данных программы при выполнении данного теста. Действительно, если изменяется первый блок программы, например, путем добавления инициализации переменной, все пути в программе также изменяются, и, как следствие, требуют повторного тестирования. Однако может так случиться, что только на небольшом подмножестве путей действительно используется эта инициализированная переменная.
• Не каждый тест, проверяющий код, находящийся на одном пути с измененным кодом, обязательно покрывает этот измененный код.
• Код, находящийся на одном пути с измененным кодом, может не воздействовать на значения выходных данных измененных модулей программы.
• Не всегда каждый оператор программы воздействует на каждый элемент ее выходных данных
Классификация тестов при отборе
Создание наборов регрессионных тестов рекомендуется начинать с множества исходных тестов. При заданном критерии регрессионного тестирования все исходные тесты подразделяются на три подмножества:
• Множество тестов, пригодных для повторного использования. Это тесты, которые уже запускались и пригодны к использованию, но затрагивают только покрываемые элементы программы, не претерпевшие изменений. При повторном выполнении выходные данные таких тестов совпадут с выходными данными, полученными на исходной программе. Следовательно, такие тесты не требуют перезапуска.
• Множество тестов, требующих повторного запуска. К ним относятся тесты, которые уже запускались, но требуют перезапуска, поскольку затрагивают, по крайней мере, один измененный покрываемый элемент, подлежащий повторному тестированию. При повторном выполнении такие тесты могут давать результат, отличный от результата, показанного на исходной программе. Множество тестов, требующих повторного запуска, обеспечивает хорошее покрытие структурных элементов даже при наличии новых функциональных возможностей.
• Множество устаревших тестов. Это тесты, более не применимые к измененной программе и непригодные для дальнейшего тестирования, поскольку они затрагивают только покрываемые элементы, которые были удалены при изменении программы. Их можно удалить из набора регрессионных тестов.
• Новые тесты, которые еще не запускались и могут быть использованы для тестирования.
Классификация тестов по отношению к изменениям в коде требует анализа последствий изменений. Тесты, активирующие код, затронутый изменениями, могут требовать повторного запуска или оказаться устаревшими. Чтобы тест был включен в класс тестов, требующих повторного запуска, он должен быть затронут изменениями в коде, а также должен способствовать увеличению степени покрытия измененного кода по используемому критерию. Затронутым элементом теста может быть траектория, выходные значения, или и то, и другое. Чтобы тест был включен в класс тестов, пригодных для повторного использования, он должен вносить вклад в увеличение степени покрытия кода и не требовать повторного запуска.
Степень покрытия кода определяется для тестов, пригодных для повторного использования, поскольку к этому классу относятся тесты, не требующие повторного запуска и способствующие увеличению степени покрытия до желаемой величины. Если имеется компонент программы, не задействованный пригодными для повторного использования тестами, то вместо них выбираются и выполняются с целью увеличения степени покрытия тесты, требующие повторного запуска. После запуска такой тест становится пригодным для повторного использования или устаревшим. Если тестов, требующих повторного запуска, больше не осталось, а необходимая степень покрытия кода еще не достигнута, порождаются дополнительные тесты и тестирование повторяется.
Окончательный набор тестов собирается из тестов, пригодных для повторного использования, тестов, требующих повторного запуска, и новых тестов. Наконец, устаревшие и избыточные тесты удаляются из набора тестов, поскольку избыточные тесты не проверяют новые функциональные возможности и не увеличивают покрытие.
Возможности повторного использования тестов
К изменению существующих тестов могут привести три следующих вида деятельности программистов:
• Создание новых тестов.
• Выполнение тестов.
• Изменение кода.
Поскольку каждый тест содержит входные данные, выходные данные и траекторию, эти компоненты могут подвергнуться изменению в любой комбинации. При изменении входных данных существующего теста будем считать, что старый тест прекращает существование, и создается новый тест. Таким образом, к числу разрешенных изменений теста относятся всевозможные пертурбации выходных данных или траекторий. Изменение выходных данных без изменения траектории и/или входных данных невозможно. Следовательно, существует только два возможных варианта изменения теста: изменение траектории или изменение траектории и выходных данных.
В соответствии с приведенными выше рассуждениями можно выделить четыре уровня повторного использования теста:
• Уровень 1. Тест не допускает повторного использования. Требуется создание нового набора тестов (например, путем удаления или изменения этого теста).
• Уровень 2. Повторное использование возможно только входных данных теста. Во многих случаях цель тестирования состоит в активизации некоторых покрываемых элементов программы. Если из траектории существующего теста видно, что элементы программы, подлежащие покрытию, задействуются до измененных команд, входные данные теста могут быть использованы повторно для покрытия этих элементов. В результате изменений в программе и/или техническом задании новая траектория и выходные данные теста могут отличаться от результатов предыдущего выполнения. Таким образом, тесты первого уровня должны быть запущены повторно для получения новых выходных данных и траекторий.
• Уровень 3. Возможно повторное использование как входных, так и выходных данных теста. Очевидно, что на этом уровне обычно располагаются функциональные тесты. Если модуль подвергся только изменению кода с сохранением функциональности, возможно повторное использование существующих функциональных тестов для проверки правильности реализации. Поскольку траектория может измениться, а выходные данные - подвергнуться воздействию со стороны изменений кода, такие тесты должны быть запущены повторно, но ожидается получение идентичных результатов.
• Уровень 4. Наивысший уровень повторного использования теста, предусматривающий повторное использование входных данных, выходных данных и траектории теста. В этом случае на траектории теста не изменяется ни один оператор. Следовательно, в повторном запуске этих тестов необходимости нет, так как выходные данные и траектория останутся неизменными.
Классификация выборочных методов
Для проверки корректности различных подходов к регрессионному тестированию используется модель оценки методов регрессионного тестирования. Основными объектами рассмотрения стали полнота, точность, эффективность и универсальность.
• Полнота
• Точность
• Эффективность
• Универсальность
©www.intuit.ru
При корректировках программы необходимо гарантировать сохранение качества. Для этого используется регрессионное тестирование - дорогостоящая, но необходимая деятельность в рамках этапа сопровождения, направленная на перепроверку корректности измененной программы. В соответствии со стандартным определением, регрессионное тестирование - это выборочное тестирование, позволяющее убедиться, что изменения не вызвали нежелательных побочных эффектов, или что измененная система по-прежнему соответствует требованиям.
Главной задачей этапа сопровождения является реализация систематического процесса обработки изменений в коде. После каждой модификации программы необходимо удостовериться, что на функциональность программы не оказал влияния модифицированный код. Если такое влияние обнаружено, говорят о регрессионном дефекте. Для регрессионного тестирования функциональных возможностей, изменение которых не планировалось, используются ранее разработанные тесты. Одна из целей регрессионного тестирования состоит в том, чтобы, в соответствии с используемым критерием покрытия кода (например, критерием покрытия потока операторов или потока данных), гарантировать тот же уровень покрытия, что и при полном повторном тестировании программы. Для этого необходимо запускать тесты, относящиеся к измененным областям кода или функциональным возможностям.
Другая цель регрессионного тестирования состоит в том, чтобы удостовериться, что программа функционирует в соответствии со своей спецификацией, и что изменения не привели к внесению новых ошибок в ранее протестированный код. Эта цель всегда может быть достигнута повторным выполнением всех тестов регрессионного набора, но более перспективно отсеивать тесты, на которых выходные данные модифицированной и старой программы не могут различаться.
Важной задачей регрессионного тестирования является также уменьшение стоимости и сокращение времени выполнения тестов.
Виды регрессионного тестирования
Поскольку регрессионное тестирование представляет собой повторное проведение цикла обычного тестирования, виды регрессионного тестирования совпадают с видами обычного тестирования. Можно говорить, например, о модульном регрессионном тестировании или о функциональном регрессионном тестировании.
Другой способ классификации видов регрессионного тестирования связывает их с типами сопровождения, которые, в свою очередь, определяются типами модификаций. Выделяют три типа сопровождения:
• Корректирующее сопровождение, называемое обычно исправлением ошибок, выполняется в ответ на обнаружение ошибки, не требующей изменения спецификации требований. При корректирующем сопровождении производится диагностика и корректировка дефектов в программном обеспечении с целью поддержания системы в работоспособном состоянии.
• Адаптивное сопровождение осуществляется в ответ на требования изменения данных или среды исполнения. Оно применяется, когда существующая система улучшается или расширяется, а спецификация требований изменяется с целью реализации новых функций.
• Усовершенствующее (прогрессивное) сопровождение включает любую обработку с целью повышения эффективности работы системы или эффективности ее сопровождения.
В процессе адаптивного или усовершенствующего сопровождения обычно вводятся новые модули. Чтобы отобразить то или иное усовершенствование или адаптацию, изменяется спецификация системы. При корректирующем сопровождении, как правило, спецификация не изменяется, и новые модули не вводятся. Модификация программы на фазе разработки подобна модификации при корректирующем сопровождении, так как из-за обнаружения ошибки вряд ли требуется менять спецификацию программы. За исключением редких моментов крупных изменений, на фазе сопровождения изменения системы обычно невелики и производятся с целью устранения проблем или постепенного расширения функциональных возможностей
Соответственно, определяют два типа регрессионного тестирования: прогрессивное и корректирующее.
• Прогрессивное регрессионное тестирование предполагает модификацию технического задания. В большинстве случаев при этом к системе программного обеспечения добавляются новые модули.
• При корректирующем регрессионном тестировании техническое задание не изменяется. Модифицируются только некоторые операторы программы и, возможно, конструкторские решения.
Прогрессивное регрессионное тестирование обычно выполняется после адаптивного или усовершенствующего сопровождения, тогда как корректирующее регрессионное тестирование выполняется во время тестирования в цикле разработки и после корректирующего сопровождения, то есть после того, как над программным обеспечением были выполнены некоторые корректирующие действия. Вообще говоря, корректирующее регрессионное тестирование должно быть более простым, чем прогрессивное регрессионное тестирование, поскольку допускает повторное использование большего количества тестов.
Подход к отбору регрессионных тестов может быть активным или консервативным. Активный подход во главу угла ставит уменьшение объема регрессионного тестирования и пренебрегает риском пропустить дефекты. Активный подход применяется для тестирования систем с высокой исходной надежностью, а также в случаях, когда эффект изменений невелик. Консервативный подход требует отбора всех тестов, которые с ненулевой вероятностью могут обнаруживать дефекты. Этот подход позволяет обнаруживать большее количество ошибок, но приводит к созданию более обширных наборов регрессионных тестов.
Управляемое регрессионное тестирование
Для обеспечения управляемости регрессионного тестирования необходимо выполнение ряда условий:
• Как при модульном, так и при интеграционном регрессионном тестировании в качестве модулей, вызываемых тестируемым модулем непосредственно или косвенно, должны использоваться реальные модули системы. Это легко осуществить, поскольку на этапе регрессионного тестирования все модули доступны в завершенном виде.
• Информация об изменениях корректна. Информация об изменениях указывает на измененные модули и разделы спецификации требований, не подразумевая при этом корректность самих изменений. Кроме того, при изменении спецификации требований необходимо усиленное регрессионное тестирование изменившихся функций этой спецификации, а также всех функций, которые могли быть затронуты по неосторожности. Единственным случаем когда мы вынуждены положиться на правильность измененного технического задания, является изменение технического задания для всей системы или для модуля верхнего (в графе вызовов) уровня, при условии, что кроме технического задания, не существует никакой дополнительной документации и/или какой-либо другой информации, по которой можно было бы судить об ошибке в техническом задании.
• В программе нет ошибок, кроме тех, которые могли возникнуть из-за ее изменения.
• Тесты, применявшиеся для тестирования предыдущих версий программного продукта, доступны, при этом протокол прогона тестов состоит из входных данных, выходных данных и траектории. Траектория представляет собой путь в управляющем графе программы, прохождение которого вызывается использованием некоторого набора входных данных. Ее можно применять для оценки структурного покрытия, обеспечиваемого набором тестов.
• Для проведения регрессионного тестирования с использованием существующего набора тестов необходимо хранить информацию о результатах выполнения тестов на предыдущих этапах тестирования.
Обоснование корректности метода отбора тестов
• Некоторые участки кода программы не получают управление при выполнении некоторых тестов.
• Если участок кода реализует требование, но измененный фрагмент кода не получает управления при выполнении теста, то он и не может воздействовать на значения выходных данных программы при выполнении данного теста.
• Даже если участок кода, реализующий требование, получает управление при выполнении теста, это далеко не всегда отражается на выходных данных программы при выполнении данного теста. Действительно, если изменяется первый блок программы, например, путем добавления инициализации переменной, все пути в программе также изменяются, и, как следствие, требуют повторного тестирования. Однако может так случиться, что только на небольшом подмножестве путей действительно используется эта инициализированная переменная.
• Не каждый тест, проверяющий код, находящийся на одном пути с измененным кодом, обязательно покрывает этот измененный код.
• Код, находящийся на одном пути с измененным кодом, может не воздействовать на значения выходных данных измененных модулей программы.
• Не всегда каждый оператор программы воздействует на каждый элемент ее выходных данных
Классификация тестов при отборе
Создание наборов регрессионных тестов рекомендуется начинать с множества исходных тестов. При заданном критерии регрессионного тестирования все исходные тесты подразделяются на три подмножества:
• Множество тестов, пригодных для повторного использования. Это тесты, которые уже запускались и пригодны к использованию, но затрагивают только покрываемые элементы программы, не претерпевшие изменений. При повторном выполнении выходные данные таких тестов совпадут с выходными данными, полученными на исходной программе. Следовательно, такие тесты не требуют перезапуска.
• Множество тестов, требующих повторного запуска. К ним относятся тесты, которые уже запускались, но требуют перезапуска, поскольку затрагивают, по крайней мере, один измененный покрываемый элемент, подлежащий повторному тестированию. При повторном выполнении такие тесты могут давать результат, отличный от результата, показанного на исходной программе. Множество тестов, требующих повторного запуска, обеспечивает хорошее покрытие структурных элементов даже при наличии новых функциональных возможностей.
• Множество устаревших тестов. Это тесты, более не применимые к измененной программе и непригодные для дальнейшего тестирования, поскольку они затрагивают только покрываемые элементы, которые были удалены при изменении программы. Их можно удалить из набора регрессионных тестов.
• Новые тесты, которые еще не запускались и могут быть использованы для тестирования.
Классификация тестов по отношению к изменениям в коде требует анализа последствий изменений. Тесты, активирующие код, затронутый изменениями, могут требовать повторного запуска или оказаться устаревшими. Чтобы тест был включен в класс тестов, требующих повторного запуска, он должен быть затронут изменениями в коде, а также должен способствовать увеличению степени покрытия измененного кода по используемому критерию. Затронутым элементом теста может быть траектория, выходные значения, или и то, и другое. Чтобы тест был включен в класс тестов, пригодных для повторного использования, он должен вносить вклад в увеличение степени покрытия кода и не требовать повторного запуска.
Степень покрытия кода определяется для тестов, пригодных для повторного использования, поскольку к этому классу относятся тесты, не требующие повторного запуска и способствующие увеличению степени покрытия до желаемой величины. Если имеется компонент программы, не задействованный пригодными для повторного использования тестами, то вместо них выбираются и выполняются с целью увеличения степени покрытия тесты, требующие повторного запуска. После запуска такой тест становится пригодным для повторного использования или устаревшим. Если тестов, требующих повторного запуска, больше не осталось, а необходимая степень покрытия кода еще не достигнута, порождаются дополнительные тесты и тестирование повторяется.
Окончательный набор тестов собирается из тестов, пригодных для повторного использования, тестов, требующих повторного запуска, и новых тестов. Наконец, устаревшие и избыточные тесты удаляются из набора тестов, поскольку избыточные тесты не проверяют новые функциональные возможности и не увеличивают покрытие.
Возможности повторного использования тестов
К изменению существующих тестов могут привести три следующих вида деятельности программистов:
• Создание новых тестов.
• Выполнение тестов.
• Изменение кода.
Поскольку каждый тест содержит входные данные, выходные данные и траекторию, эти компоненты могут подвергнуться изменению в любой комбинации. При изменении входных данных существующего теста будем считать, что старый тест прекращает существование, и создается новый тест. Таким образом, к числу разрешенных изменений теста относятся всевозможные пертурбации выходных данных или траекторий. Изменение выходных данных без изменения траектории и/или входных данных невозможно. Следовательно, существует только два возможных варианта изменения теста: изменение траектории или изменение траектории и выходных данных.
В соответствии с приведенными выше рассуждениями можно выделить четыре уровня повторного использования теста:
• Уровень 1. Тест не допускает повторного использования. Требуется создание нового набора тестов (например, путем удаления или изменения этого теста).
• Уровень 2. Повторное использование возможно только входных данных теста. Во многих случаях цель тестирования состоит в активизации некоторых покрываемых элементов программы. Если из траектории существующего теста видно, что элементы программы, подлежащие покрытию, задействуются до измененных команд, входные данные теста могут быть использованы повторно для покрытия этих элементов. В результате изменений в программе и/или техническом задании новая траектория и выходные данные теста могут отличаться от результатов предыдущего выполнения. Таким образом, тесты первого уровня должны быть запущены повторно для получения новых выходных данных и траекторий.
• Уровень 3. Возможно повторное использование как входных, так и выходных данных теста. Очевидно, что на этом уровне обычно располагаются функциональные тесты. Если модуль подвергся только изменению кода с сохранением функциональности, возможно повторное использование существующих функциональных тестов для проверки правильности реализации. Поскольку траектория может измениться, а выходные данные - подвергнуться воздействию со стороны изменений кода, такие тесты должны быть запущены повторно, но ожидается получение идентичных результатов.
• Уровень 4. Наивысший уровень повторного использования теста, предусматривающий повторное использование входных данных, выходных данных и траектории теста. В этом случае на траектории теста не изменяется ни один оператор. Следовательно, в повторном запуске этих тестов необходимости нет, так как выходные данные и траектория останутся неизменными.
Классификация выборочных методов
Для проверки корректности различных подходов к регрессионному тестированию используется модель оценки методов регрессионного тестирования. Основными объектами рассмотрения стали полнота, точность, эффективность и универсальность.
• Полнота
• Точность
• Эффективность
• Универсальность
©www.intuit.ru
воскресенье, 11 января 2009 г.
Индустриальное тестирование
Продолжение заметок на полях о тестировании.
Тестирование, с технической точки зрения, есть процесс выполнения приложения на некоторых входных данных и проверка получаемых результатов с целью подтвердить их корректность по отношению к результату.
Итак, основная последовательность действий при выборе и оценке критериев качества программного продукта включает:
1. Определение всех лиц, так или иначе заинтересованных в исполнении и результатах данного проекта.
2. Определение критериев, формирующих представление о качестве для каждого из участников.
3. Приоритезацию критериев, с учетом важности конкретного участника для компании, выполняющей проект, и важности каждого из критериев для данного участника.
4. Определение набора критериев, которые будут отслежены и выполнены в рамках проекта, исходя из приоритетов и возможностей проектной команды. Постановка целей по каждому из критериев.
5. Определение способов и механизмов достижения каждого критерия.
6. Определение стратегии тестирования исходя из набора критериев, попадающих под ответственность группы тестирования, выбранных приоритетов и целей
Процесс тестирования
1. Модульное тестирование.
2. Интеграционное тестирование.
3. Системное тестирование.
Фазы процесса тестирования
1. Определение целей (требований к тестированию), включающее следующую конкретизацию: какие части системы будут тестироваться, какие аспекты их работы будут выбраны для проверки, каково желаемое качество и т.п.
2. Планирование: создание графика (расписания) разработки тестов для каждой тестируемой подсистемы; оценка необходимых человеческих, программных и аппаратных ресурсов; разработка расписания тестовых циклов. Важно отметить, что расписание тестирования обязательно должно быть согласовано с расписанием разработки создаваемой системы, поскольку наличие исполняемой версии разрабатываемой системы (Implementation Under Testing (IUT) или Application Under Testing (AUT) – часто употребляемые обозначения для тестируемой системы) является одним из необходимых условий тестирования, что создает взаимозависимость в работе команд тестировщиков и разработчиков.
3. Разработка тестов , то есть тестового кода для тестируемой системы, если необходимо - кода системы автоматизации тестирования и тестовых процедур (выполняемых вручную).
4. Выполнение тестов: реализация тестовых циклов.
5. Анализ результатов.
Тестовый цикл
Тестовый цикл – это цикл исполнения тестов, включающий фазы 4 и 5 тестового процесса. Тестовый цикл заключается в прогоне разработанных тестов на некотором однозначно определяемом срезе системы (состоянии кода разрабатываемой системы). Обычно такой срез системы называют build. Тестовый цикл включает следующую последовательность действий:
1. Проверка готовности системы и тестов к проведению тестового цикла включающая:
• Проверку того, что все тесты, запланированные для исполнения на данном цикле, разработаны и помещены в систему версионного контроля.
• Проверку того, что все подсистемы, запланированные для тестирования на данном цикле, разработаны и помещены в систему версионного контроля.
• Проверку того, что разработана и задокументирована процедура определения и создания среза системы, или build.
• Проверки некоторых дополнительных критериев.
2. Подготовка тестовой машины в соответствии с требованиями, определенными на этапе планирования (например, полная очистка и переустановка системного программного обеспечения). Конфигурация тестовой машины, так же, как и срез системы, должны быть однозначно воспроизводимыми.
3. Воспроизведение среза системы.
4. Прогон тестов в соответствии с задокументированными процедурами.
5. Сохранение тестовых протоколов (test log). Test log может содержать вывод системы в STDOUT, список результатов сравнения полученных при исполнении данных с эталонными или любые другие выходные данные тестов, с помощью которых можно проверить правильность работы системы.
6. Анализ протоколов тестирования и принятие решения о том прошел или не прошел каждый из тестов (Pass/Fail).
7. Анализ и документирование результатов цикла.
Последний перед выпуском продукта тестовый цикл не должен включать изменений кода build или кода продукта тестируемой системы. Этот цикл называется " финальным ". Таким образом обеспечивается ситуация, когда финальный цикл полностью повторяем, а выпускаемый продукт полностью совпадает с продуктом, который прошел тестирование. Финальный цикл необходим для гарантии достоверности результатов тестирования.
Планирование тестирования
Тестовый план - это документ, или набор документов, содержащий следующую информацию:
1. Тестовые ресурсы.
2. Перечень функций и подсистем, подлежащих тестированию.
3. Тестовую стратегию, включающую:
• Анализ функций и подсистем с целью определения наиболее слабых мест, то есть областей функциональности тестируемой системы, где появление дефектов наиболее вероятно.
• Определение стратегии выбора входных данных для тестирования. Так как множество возможных входных данных программного продукта, как правило, практически бесконечно, выбор конечного подмножества, достаточного для проведения исчерпывающего тестирования, является сложной задачей. Для ее решения могут быть применены такие методы, как покрытие классов входных и выходных данных, анализ крайних значений, покрытие модели использования, анализ временной линии и тому подобные. Выбранную стратегию необходимо обосновать и задокументировать.
• Определение потребности в автоматизированной системе тестирования и дизайн такой системы
4. Расписание тестовых циклов.
5. Фиксацию тестовой конфигурации: состава и конкретных параметров аппаратуры и программного окружения.
6. Определение списка тестовых метрик, которые на тестовом цикле необходимо собрать и проанализировать. Например, метрик, оценивающих степень покрытия тестами набора требований, степень покрытия кода тестируемой системы, количество и уровень серьезности дефектов, объем тестового кода и другие характеристики.
Типы тестирования
В тестовом плане определяются и документируются различные типы тестов. Типы тестов могут быть классифицированы по двум категориям: по тому, что подвергается тестированию (по виду подсистемы) и по способу выбора входных данных.
Типы тестирования по виду подсистемы или продукта:
1. Тестирование основной функциональности, когда тестированию подвергается собственно система, являющаяся основным выпускаемым продуктом
2. Тестирование инсталляции включает тестирование сценариев первичной инсталляции системы, сценариев повторной инсталляции (поверх уже существующей копии), тестирование деинсталляции, тестирование инсталляции в условиях наличия ошибок в инсталлируемом пакете, в окружении или в сценарии и т.п.
3. Тестирование пользовательской документации включает проверку полноты и понятности описания правил и особенностей использования продукта, наличие описания всех сценариев и функциональности, синтаксис и грамматику языка, работоспособность примеров и т.п.
Типы тестирования по способу выбора входных значений:
1. Функциональное тестирование, при котором проверяется:
• Покрытие функциональных требований.
• Покрытие сценариев использования.
2. Стрессовое тестирование, при котором проверяются экстремальные режимы использования продукта.
3. Тестирование граничных значений.
4. Тестирование производительности.
5. Тестирование на соответствие стандартам.
6. Тестирование совместимости с другими программно-аппаратными комплексами.
7. Тестирование работы с окружением.
8. Тестирование работы на конкретной платформе
В реальных разработках используются и комбинируются различные типы тестов для обеспечения спланированного качества продукта.
Подходы к разработке тестов
Тестирование спецификации
При разработке тестов, основанной на функциональной спецификации продукта, требования к продукту являются основным источником, определяющим, какие тесты будут разработаны. Для каждого требования пишется один или более тестов, которые в совокупности должны проверить выполнение данного требования в продукте.
Тестирование сценариев
Разработка тестов, основанных на использовании сценариев, осуществляется по следующей методике:
1. Определяется модель использования, включающая операционное окружение продукта и "актеров". Актером может быть пользователь, другой продукт, аппаратная часть и тому подобное, то есть все, с чем продукт обменивается информацией. Разделение на окружение и актеров условно и служит для описания оптимальных способов использования продукта.
2. Разрабатываются сценарии использования продукта. Описание сценария в зависимости от продукта и выбранного подхода может быть строго определенным, параметризованным или разрешать некоторую степень неопределенности. Например, описание сценария на языке MSC допускает задание параметризованных сценариев с возможностью переупорядочивания событий.
3. Разрабатывается набор тестов, покрывающих заданные сценарии. С учетом степени неопределенности, заложенной в сценарии, каждый тест может покрывать один сценарий, несколько сценариев, или, наоборот, часть сценария.
Использование сценариев не требует наличия полной формальной спецификации требований, но зато может потребовать больше времени на разработку и анализ.
Еще одна особенность тестирования сценариев заключается в том, что этот метод направляет тестирование на проверку конкретных режимов использования продукта, что позволяет находить дефекты, которые метод тестирования по требованиям может пропустить.
Ручная разработка тестов
Наиболее распространенным способом разработки тестов является создание тестового кода вручную. Это наиболее гибкий способ разработки тестов, однако характерная для него производительность труда инженеров-тестировщиков в создании тестового кода не намного выше скорости создания кода продукта, а объемы тестового кода на практике зачастую превышают объем кода продукта в 10 раз. Учитывая этот факт, в современной индустрии все больше склоняются к более интеллектуальным способам получения тестового кода, таким как использование специальных тестовых языков (скриптов) и генерации тестов.
Генерация тестов
Использование методики генерации тестового кода по формализованным MSC диаграммам позволяет значительно поднять производительность тестирования, а также преобразовать формализацию (кодировку) сценариев в достаточно интеллектуальную деятельность.
©www.intuit.ru
Тестирование, с технической точки зрения, есть процесс выполнения приложения на некоторых входных данных и проверка получаемых результатов с целью подтвердить их корректность по отношению к результату.
Итак, основная последовательность действий при выборе и оценке критериев качества программного продукта включает:
1. Определение всех лиц, так или иначе заинтересованных в исполнении и результатах данного проекта.
2. Определение критериев, формирующих представление о качестве для каждого из участников.
3. Приоритезацию критериев, с учетом важности конкретного участника для компании, выполняющей проект, и важности каждого из критериев для данного участника.
4. Определение набора критериев, которые будут отслежены и выполнены в рамках проекта, исходя из приоритетов и возможностей проектной команды. Постановка целей по каждому из критериев.
5. Определение способов и механизмов достижения каждого критерия.
6. Определение стратегии тестирования исходя из набора критериев, попадающих под ответственность группы тестирования, выбранных приоритетов и целей
Процесс тестирования
1. Модульное тестирование.
2. Интеграционное тестирование.
3. Системное тестирование.
Фазы процесса тестирования
1. Определение целей (требований к тестированию), включающее следующую конкретизацию: какие части системы будут тестироваться, какие аспекты их работы будут выбраны для проверки, каково желаемое качество и т.п.
2. Планирование: создание графика (расписания) разработки тестов для каждой тестируемой подсистемы; оценка необходимых человеческих, программных и аппаратных ресурсов; разработка расписания тестовых циклов. Важно отметить, что расписание тестирования обязательно должно быть согласовано с расписанием разработки создаваемой системы, поскольку наличие исполняемой версии разрабатываемой системы (Implementation Under Testing (IUT) или Application Under Testing (AUT) – часто употребляемые обозначения для тестируемой системы) является одним из необходимых условий тестирования, что создает взаимозависимость в работе команд тестировщиков и разработчиков.
3. Разработка тестов , то есть тестового кода для тестируемой системы, если необходимо - кода системы автоматизации тестирования и тестовых процедур (выполняемых вручную).
4. Выполнение тестов: реализация тестовых циклов.
5. Анализ результатов.
Тестовый цикл
Тестовый цикл – это цикл исполнения тестов, включающий фазы 4 и 5 тестового процесса. Тестовый цикл заключается в прогоне разработанных тестов на некотором однозначно определяемом срезе системы (состоянии кода разрабатываемой системы). Обычно такой срез системы называют build. Тестовый цикл включает следующую последовательность действий:
1. Проверка готовности системы и тестов к проведению тестового цикла включающая:
• Проверку того, что все тесты, запланированные для исполнения на данном цикле, разработаны и помещены в систему версионного контроля.
• Проверку того, что все подсистемы, запланированные для тестирования на данном цикле, разработаны и помещены в систему версионного контроля.
• Проверку того, что разработана и задокументирована процедура определения и создания среза системы, или build.
• Проверки некоторых дополнительных критериев.
2. Подготовка тестовой машины в соответствии с требованиями, определенными на этапе планирования (например, полная очистка и переустановка системного программного обеспечения). Конфигурация тестовой машины, так же, как и срез системы, должны быть однозначно воспроизводимыми.
3. Воспроизведение среза системы.
4. Прогон тестов в соответствии с задокументированными процедурами.
5. Сохранение тестовых протоколов (test log). Test log может содержать вывод системы в STDOUT, список результатов сравнения полученных при исполнении данных с эталонными или любые другие выходные данные тестов, с помощью которых можно проверить правильность работы системы.
6. Анализ протоколов тестирования и принятие решения о том прошел или не прошел каждый из тестов (Pass/Fail).
7. Анализ и документирование результатов цикла.
Последний перед выпуском продукта тестовый цикл не должен включать изменений кода build или кода продукта тестируемой системы. Этот цикл называется " финальным ". Таким образом обеспечивается ситуация, когда финальный цикл полностью повторяем, а выпускаемый продукт полностью совпадает с продуктом, который прошел тестирование. Финальный цикл необходим для гарантии достоверности результатов тестирования.
Планирование тестирования
Тестовый план - это документ, или набор документов, содержащий следующую информацию:
1. Тестовые ресурсы.
2. Перечень функций и подсистем, подлежащих тестированию.
3. Тестовую стратегию, включающую:
• Анализ функций и подсистем с целью определения наиболее слабых мест, то есть областей функциональности тестируемой системы, где появление дефектов наиболее вероятно.
• Определение стратегии выбора входных данных для тестирования. Так как множество возможных входных данных программного продукта, как правило, практически бесконечно, выбор конечного подмножества, достаточного для проведения исчерпывающего тестирования, является сложной задачей. Для ее решения могут быть применены такие методы, как покрытие классов входных и выходных данных, анализ крайних значений, покрытие модели использования, анализ временной линии и тому подобные. Выбранную стратегию необходимо обосновать и задокументировать.
• Определение потребности в автоматизированной системе тестирования и дизайн такой системы
4. Расписание тестовых циклов.
5. Фиксацию тестовой конфигурации: состава и конкретных параметров аппаратуры и программного окружения.
6. Определение списка тестовых метрик, которые на тестовом цикле необходимо собрать и проанализировать. Например, метрик, оценивающих степень покрытия тестами набора требований, степень покрытия кода тестируемой системы, количество и уровень серьезности дефектов, объем тестового кода и другие характеристики.
Типы тестирования
В тестовом плане определяются и документируются различные типы тестов. Типы тестов могут быть классифицированы по двум категориям: по тому, что подвергается тестированию (по виду подсистемы) и по способу выбора входных данных.
Типы тестирования по виду подсистемы или продукта:
1. Тестирование основной функциональности, когда тестированию подвергается собственно система, являющаяся основным выпускаемым продуктом
2. Тестирование инсталляции включает тестирование сценариев первичной инсталляции системы, сценариев повторной инсталляции (поверх уже существующей копии), тестирование деинсталляции, тестирование инсталляции в условиях наличия ошибок в инсталлируемом пакете, в окружении или в сценарии и т.п.
3. Тестирование пользовательской документации включает проверку полноты и понятности описания правил и особенностей использования продукта, наличие описания всех сценариев и функциональности, синтаксис и грамматику языка, работоспособность примеров и т.п.
Типы тестирования по способу выбора входных значений:
1. Функциональное тестирование, при котором проверяется:
• Покрытие функциональных требований.
• Покрытие сценариев использования.
2. Стрессовое тестирование, при котором проверяются экстремальные режимы использования продукта.
3. Тестирование граничных значений.
4. Тестирование производительности.
5. Тестирование на соответствие стандартам.
6. Тестирование совместимости с другими программно-аппаратными комплексами.
7. Тестирование работы с окружением.
8. Тестирование работы на конкретной платформе
В реальных разработках используются и комбинируются различные типы тестов для обеспечения спланированного качества продукта.
Подходы к разработке тестов
Тестирование спецификации
При разработке тестов, основанной на функциональной спецификации продукта, требования к продукту являются основным источником, определяющим, какие тесты будут разработаны. Для каждого требования пишется один или более тестов, которые в совокупности должны проверить выполнение данного требования в продукте.
Тестирование сценариев
Разработка тестов, основанных на использовании сценариев, осуществляется по следующей методике:
1. Определяется модель использования, включающая операционное окружение продукта и "актеров". Актером может быть пользователь, другой продукт, аппаратная часть и тому подобное, то есть все, с чем продукт обменивается информацией. Разделение на окружение и актеров условно и служит для описания оптимальных способов использования продукта.
2. Разрабатываются сценарии использования продукта. Описание сценария в зависимости от продукта и выбранного подхода может быть строго определенным, параметризованным или разрешать некоторую степень неопределенности. Например, описание сценария на языке MSC допускает задание параметризованных сценариев с возможностью переупорядочивания событий.
3. Разрабатывается набор тестов, покрывающих заданные сценарии. С учетом степени неопределенности, заложенной в сценарии, каждый тест может покрывать один сценарий, несколько сценариев, или, наоборот, часть сценария.
Использование сценариев не требует наличия полной формальной спецификации требований, но зато может потребовать больше времени на разработку и анализ.
Еще одна особенность тестирования сценариев заключается в том, что этот метод направляет тестирование на проверку конкретных режимов использования продукта, что позволяет находить дефекты, которые метод тестирования по требованиям может пропустить.
Ручная разработка тестов
Наиболее распространенным способом разработки тестов является создание тестового кода вручную. Это наиболее гибкий способ разработки тестов, однако характерная для него производительность труда инженеров-тестировщиков в создании тестового кода не намного выше скорости создания кода продукта, а объемы тестового кода на практике зачастую превышают объем кода продукта в 10 раз. Учитывая этот факт, в современной индустрии все больше склоняются к более интеллектуальным способам получения тестового кода, таким как использование специальных тестовых языков (скриптов) и генерации тестов.
Генерация тестов
Использование методики генерации тестового кода по формализованным MSC диаграммам позволяет значительно поднять производительность тестирования, а также преобразовать формализацию (кодировку) сценариев в достаточно интеллектуальную деятельность.
©www.intuit.ru
суббота, 27 декабря 2008 г.
Критерии тестирования
Продолжение заметок, на сегодня хватит, я так думаю
Требования к идеальному критерию тестирования
• Критерий должен быть достаточным.
• Критерий должен быть полным.
• Критерий должен быть надежным.
• Критерий должен быть легко проверяемым
Для нетривиальных классов программ в общем случае не существует полного и надежного критерия, зависящего от программ или спецификаций.
Поэтому мы стремимся к идеальному общему критерию через реальные частные.
Классы критериев
• Структурные
• Функциональные
• Критерии стохастического тестирования формулируются в терминах проверки наличия заданных свойств у тестируемого приложения, средствами проверки некоторой статистической гипотезы.
• Мутационные критерии ориентированы на проверку свойств программного изделия на основе подхода Монте-Карло.
Структурные критерии
- используют модель программы в виде "белого ящика", что предполагает знание исходного текста программы или спецификации программы в виде потокового графа управления. Данный класс критериев часто используется на этапах модульного и интеграционного тестирования (Unit testing, Integration testing)
Структурные критерии базируются на основных элементах УГП, операторах, ветвях и путях.
• Условие критерия тестирования команд (критерий С0) - набор тестов в совокупности должен обеспечить прохождение каждой команды не менее одного раза. Это слабый критерий, он, как правило, используется в больших программных системах, где другие критерии применить невозможно.
• Условие критерия тестирования ветвей (критерий С1) - набор тестов в совокупности должен обеспечить прохождение каждой ветви не менее одного раза. Это достаточно сильный и при этом экономичный критерий, поскольку множество ветвей в тестируемом приложении конечно и не так уж велико. Данный критерий часто используется в системах автоматизации тестирования.
• Условие критерия тестирования путей (критерий С2) - набор тестов в совокупности должен обеспечить прохождение каждого пути не менее 1 раз. Если программа содержит цикл (в особенности с неявно заданным числом итераций), то число итераций ограничивается константой (часто - 2, или числом классов выходных путей)..
Функциональные критерии
- важнейший для программной индустрии критерий тестирования. Он обеспечивает, прежде всего, контроль степени выполнения требований заказчика в программном продукте. Отражают взаимодействие тестируемого приложения с окружением. Используется модель "черного ящика". Проблема:трудоемкость; дело в том, что документы, фиксирующие требования к программному изделию (Software requirement specification, Functional specification и т.п.), достаточно объемны.
• Тестирование пунктов спецификации - набор тестов в совокупности должен обеспечить проверку каждого тестируемого пункта не менее одного раза.
• Тестирование классов входных данных - набор тестов в совокупности должен обеспечить проверку представителя каждого класса входных данных не менее одного раза. При создании тестов классы входных данных сопоставляются с режимами использования тестируемого компонента или подсистемы приложения, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов. Следует заметить, что мы вынуждены применять мощные тестовые наборы. Действительно, наряду с ограничениями на величины входных данных, существуют ограничения на величины входных данных во всевозможных комбинациях, в том числе проверка реакций системы на появление ошибок в значениях или структурах входных данных. Учет этого многообразия - процесс трудоемкий, что создает сложности для применения критерия
• Тестирование правил - набор тестов в совокупности должен обеспечить проверку каждого правила, если входные и выходные значения описываются набором правил некоторой грамматики.
• Тестирование классов выходных данных - набор тестов в совокупности должен обеспечить проверку представителя каждого выходного класса, при условии, что выходные результаты заранее расклассифицированы, причем отдельные классы результатов учитывают, в том числе, ограничения на ресурсы или на время (time out). При создании тестов классы выходных данных сопоставляются с режимами использования тестируемого компонента или подсистемы, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов.
• Тестирование функций - набор тестов в совокупности должен обеспечить проверку каждого действия, реализуемого тестируемым модулем, не менее одного раза. Не обеспечивает покрытия части функциональности тестируемого компонента, связанной со структурными и поведенческими свойствами, описание которых не сосредоточено в отдельных функциях (т.е. описание рассредоточено по компоненту). Критерий тестирования функций объединяет отчасти особенности структурных и функциональных критериев. Он базируется на модели "полупрозрачного ящика", где явно указаны не только входы и выходы тестируемого компонента, но также состав и структура используемых методов (функций, процедур) и классов.
• Комбинированные критерии для программ и спецификаций - набор тестов в совокупности должен обеспечить проверку всех комбинаций непротиворечивых условий программ и спецификаций не менее одного раза.
Стохастические критерии
- применяется при тестировании сложных программных комплексов - когда набор детерминированных тестов имеет громадную мощность. В случаях, когда подобный набор невозможно разработать и исполнить на фазе тестирования
Необходимо разработать программы - имитаторы случайных последовательностей входных сигналов{x}. Вычислить независимым способом значения {y} для соответствующих входных сигналов {x} и получить тестовый набор (X,Y). Протестировать приложение на тестовом наборе (X,Y), используя два способа контроля результатов:
• Детерминированный контроль - проверка соответствия вычисленного значения y значению y, полученному в результате прогона теста на наборе {x} - случайной последовательности входных сигналов, сгенерированной имитатором.
• Стохастический контроль - проверка соответствия множества значений {y}, полученного в результате прогона тестов на наборе входных значений {x}, заранее известному распределению результатов F(Y).
В этом случае множество Y неизвестно (его вычисление невозможно), но известен закон распределения данного множества..
Критерии стохастического тестирования
• Cтатистические методы окончания тестирования - стохастические методы принятия решений о совпадении гипотез о распределении случайных величин. К ним принадлежат широко известные: метод Стьюдента, метод Хи-квадрат.
• Метод оценки скорости выявления ошибок - основан на модели скорости выявления ошибок, согласно которой тестирование прекращается, если оцененный интервал времени между текущей ошибкой и следующей слишком велик для фазы тестирования приложения.
Мутационный критерий (класс IV).
- Постулируется, что профессиональные программисты пишут сразу почти правильные программы, отличающиеся от правильных мелкими ошибками или описками типа - перестановка местами максимальных значений индексов в описании массивов, ошибки в знаках арифметических операций, занижение или завышение границы цикла на 1 и т.п. Предлагается подход, позволяющий на основе мелких ошибок оценить общее число ошибок, оставшихся в программе.
Мутации - мелкие ошибки в программе.
Мутанты - программы, отличающиеся друг от друга мутациями.
Метод мутационного тестирования - в разрабатываемую программу P вносят мутации, т.е. искусственно создают программы-мутанты P1, P2... Затем программа P и ее мутанты тестируются на одном и том же наборе тестов (X,Y).
Если на наборе (X,Y) подтверждается правильность программы P и, кроме того, выявляются все внесенные в программы-мутанты ошибки, то набор тестов (X,Y) соответствует мутационному критерию, а тестируемая программа объявляется правильной.
.
За материал спасибо ©intuit.ru
Требования к идеальному критерию тестирования
• Критерий должен быть достаточным.
• Критерий должен быть полным.
• Критерий должен быть надежным.
• Критерий должен быть легко проверяемым
Для нетривиальных классов программ в общем случае не существует полного и надежного критерия, зависящего от программ или спецификаций.
Поэтому мы стремимся к идеальному общему критерию через реальные частные.
Классы критериев
• Структурные
• Функциональные
• Критерии стохастического тестирования формулируются в терминах проверки наличия заданных свойств у тестируемого приложения, средствами проверки некоторой статистической гипотезы.
• Мутационные критерии ориентированы на проверку свойств программного изделия на основе подхода Монте-Карло.
Структурные критерии
- используют модель программы в виде "белого ящика", что предполагает знание исходного текста программы или спецификации программы в виде потокового графа управления. Данный класс критериев часто используется на этапах модульного и интеграционного тестирования (Unit testing, Integration testing)
Структурные критерии базируются на основных элементах УГП, операторах, ветвях и путях.
• Условие критерия тестирования команд (критерий С0) - набор тестов в совокупности должен обеспечить прохождение каждой команды не менее одного раза. Это слабый критерий, он, как правило, используется в больших программных системах, где другие критерии применить невозможно.
• Условие критерия тестирования ветвей (критерий С1) - набор тестов в совокупности должен обеспечить прохождение каждой ветви не менее одного раза. Это достаточно сильный и при этом экономичный критерий, поскольку множество ветвей в тестируемом приложении конечно и не так уж велико. Данный критерий часто используется в системах автоматизации тестирования.
• Условие критерия тестирования путей (критерий С2) - набор тестов в совокупности должен обеспечить прохождение каждого пути не менее 1 раз. Если программа содержит цикл (в особенности с неявно заданным числом итераций), то число итераций ограничивается константой (часто - 2, или числом классов выходных путей)..
Функциональные критерии
- важнейший для программной индустрии критерий тестирования. Он обеспечивает, прежде всего, контроль степени выполнения требований заказчика в программном продукте. Отражают взаимодействие тестируемого приложения с окружением. Используется модель "черного ящика". Проблема:трудоемкость; дело в том, что документы, фиксирующие требования к программному изделию (Software requirement specification, Functional specification и т.п.), достаточно объемны.
• Тестирование пунктов спецификации - набор тестов в совокупности должен обеспечить проверку каждого тестируемого пункта не менее одного раза.
• Тестирование классов входных данных - набор тестов в совокупности должен обеспечить проверку представителя каждого класса входных данных не менее одного раза. При создании тестов классы входных данных сопоставляются с режимами использования тестируемого компонента или подсистемы приложения, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов. Следует заметить, что мы вынуждены применять мощные тестовые наборы. Действительно, наряду с ограничениями на величины входных данных, существуют ограничения на величины входных данных во всевозможных комбинациях, в том числе проверка реакций системы на появление ошибок в значениях или структурах входных данных. Учет этого многообразия - процесс трудоемкий, что создает сложности для применения критерия
• Тестирование правил - набор тестов в совокупности должен обеспечить проверку каждого правила, если входные и выходные значения описываются набором правил некоторой грамматики.
• Тестирование классов выходных данных - набор тестов в совокупности должен обеспечить проверку представителя каждого выходного класса, при условии, что выходные результаты заранее расклассифицированы, причем отдельные классы результатов учитывают, в том числе, ограничения на ресурсы или на время (time out). При создании тестов классы выходных данных сопоставляются с режимами использования тестируемого компонента или подсистемы, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов.
• Тестирование функций - набор тестов в совокупности должен обеспечить проверку каждого действия, реализуемого тестируемым модулем, не менее одного раза. Не обеспечивает покрытия части функциональности тестируемого компонента, связанной со структурными и поведенческими свойствами, описание которых не сосредоточено в отдельных функциях (т.е. описание рассредоточено по компоненту). Критерий тестирования функций объединяет отчасти особенности структурных и функциональных критериев. Он базируется на модели "полупрозрачного ящика", где явно указаны не только входы и выходы тестируемого компонента, но также состав и структура используемых методов (функций, процедур) и классов.
• Комбинированные критерии для программ и спецификаций - набор тестов в совокупности должен обеспечить проверку всех комбинаций непротиворечивых условий программ и спецификаций не менее одного раза.
Стохастические критерии
- применяется при тестировании сложных программных комплексов - когда набор детерминированных тестов имеет громадную мощность. В случаях, когда подобный набор невозможно разработать и исполнить на фазе тестирования
Необходимо разработать программы - имитаторы случайных последовательностей входных сигналов{x}. Вычислить независимым способом значения {y} для соответствующих входных сигналов {x} и получить тестовый набор (X,Y). Протестировать приложение на тестовом наборе (X,Y), используя два способа контроля результатов:
• Детерминированный контроль - проверка соответствия вычисленного значения y значению y, полученному в результате прогона теста на наборе {x} - случайной последовательности входных сигналов, сгенерированной имитатором.
• Стохастический контроль - проверка соответствия множества значений {y}, полученного в результате прогона тестов на наборе входных значений {x}, заранее известному распределению результатов F(Y).
В этом случае множество Y неизвестно (его вычисление невозможно), но известен закон распределения данного множества..
Критерии стохастического тестирования
• Cтатистические методы окончания тестирования - стохастические методы принятия решений о совпадении гипотез о распределении случайных величин. К ним принадлежат широко известные: метод Стьюдента, метод Хи-квадрат.
• Метод оценки скорости выявления ошибок - основан на модели скорости выявления ошибок, согласно которой тестирование прекращается, если оцененный интервал времени между текущей ошибкой и следующей слишком велик для фазы тестирования приложения.
Мутационный критерий (класс IV).
- Постулируется, что профессиональные программисты пишут сразу почти правильные программы, отличающиеся от правильных мелкими ошибками или описками типа - перестановка местами максимальных значений индексов в описании массивов, ошибки в знаках арифметических операций, занижение или завышение границы цикла на 1 и т.п. Предлагается подход, позволяющий на основе мелких ошибок оценить общее число ошибок, оставшихся в программе.
Мутации - мелкие ошибки в программе.
Мутанты - программы, отличающиеся друг от друга мутациями.
Метод мутационного тестирования - в разрабатываемую программу P вносят мутации, т.е. искусственно создают программы-мутанты P1, P2... Затем программа P и ее мутанты тестируются на одном и том же наборе тестов (X,Y).
Если на наборе (X,Y) подтверждается правильность программы P и, кроме того, выявляются все внесенные в программы-мутанты ошибки, то набор тестов (X,Y) соответствует мутационному критерию, а тестируемая программа объявляется правильной.
.
За материал спасибо ©intuit.ru
Тестирование
Я тут по необходимости начал читать одну книжку с сайта, и думаю, а вдруг она пропадет куда? Я то ее и сохраню. Здесь и далее по тэгу лекции будут мои заметки на полях.
Хотя в современном программировании автоматизация тестирования является широко распространенной практикой, в то же время технология верификации требований и спецификаций пока делает только свои первые шаги. Задачей ближайшего будущего является движение в сторону такого распределения трудоемкости, чтобы суммарная цена обнаружения большинства дефектов стремилась к минимуму за счет обнаружения преимущественного числа на наиболее ранних фазах разработки программного продукта.
Отладка (debug, debugging)– процесс поиска, локализации и исправления ошибок в программе [IEEE Std.610-12.1990].
Статическое тестирование выявляет формальными методами анализа без выполнения тестируемой программы неверные конструкции или неверные отношения объектов программы (ошибки формального задания) с помощью специальных инструментов контроля кода – CodeChecker.
Динамическое тестирование (собственно тестирование) осуществляет выявление ошибок только на выполняющейся программе с помощью специальных инструментов автоматизации тестирования – Testbed или Testbench.
При выявлении несовпадения ожидаемых и полученных результатов запускается процедура исправления ошибки, которая заключается во внимательном анализе (просмотре) протокола промежуточных вычислений, приведших к некорректным данным с помощью следующих методов:
А) "Выполнение программы в уме" (deskchecking).
Б) Вставка операторов протоколирования (печати) промежуточных результатов (logging).
В) Пошаговое выполнение программы (single-step running).
•Step Into – если выполняемая строчка кода содержит вызов функции, процедуры или метода, то происходит вызов, и программа останавливается на первой строчке вызываемой функции, процедуры или метода.
•Step Over - если выполняемая строчка кода содержит вызов функции, процедуры или метода, то происходит вызов и выполнение всей функции и программа останавливается на первой строчке после вызываемой функции.
•Step Out – предназначена для выхода из функции в вызывающую функцию. Эта команда продолжит выполнение функции и остановит выполнение на первой строчке после вызываемой функции.
Г) Выполнение с заказанными остановками (breakpoints), анализом трасс (traces) или состояний памяти - дампов (dump).
Д) Реверсивное (обратное) выполнение (reversible execution)
Тестирование – это:
•Процесс выполнения ПО системы или компонента в условиях анализа или записи получаемых результатов с целью проверки (оценки) некоторых свойств тестируемого объекта. The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component [9].
•Процесс анализа пункта требований к ПО с целью фиксации различий между существующим состоянием ПО и требуемым (что свидетельствует о проявлении ошибки) при экспериментальной проверке соответствующего пункта требований. The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate features of software items [[IEEE Std.610-12.1990], [9].
•Контролируемое выполнение программы на конечном множестве тестовых данных и анализ результатов этого выполнения для поиска ошибок [IEEE Std 829-1983].
Реализация тестирования разделяется на три этапа:
•Создание тестового набора (test suite) путем ручной разработки или автоматической генерации для конкретной среды тестирования (testing environment).
•Прогон программы на тестах, управляемый тестовым монитором (test monitor, test driver [IEEE Std 829-1983], [9]) с получением протокола результатов тестирования (test log).
•Оценка результатов выполнения программы на наборе тестов с целью принятия решения о продолжении или остановке тестирования.
Основная проблема тестирования - определение достаточности множества тестов для истинности вывода о правильности реализации программы, а также нахождения множества тестов, обладающего этим свойством.
Сегодня материал взят отсюда: http://www.intuit.ru/department/se/testing/
Ну или так: ©www.intuit.ru
Хотя в современном программировании автоматизация тестирования является широко распространенной практикой, в то же время технология верификации требований и спецификаций пока делает только свои первые шаги. Задачей ближайшего будущего является движение в сторону такого распределения трудоемкости, чтобы суммарная цена обнаружения большинства дефектов стремилась к минимуму за счет обнаружения преимущественного числа на наиболее ранних фазах разработки программного продукта.
Отладка (debug, debugging)– процесс поиска, локализации и исправления ошибок в программе [IEEE Std.610-12.1990].
Статическое тестирование выявляет формальными методами анализа без выполнения тестируемой программы неверные конструкции или неверные отношения объектов программы (ошибки формального задания) с помощью специальных инструментов контроля кода – CodeChecker.
Динамическое тестирование (собственно тестирование) осуществляет выявление ошибок только на выполняющейся программе с помощью специальных инструментов автоматизации тестирования – Testbed или Testbench.
При выявлении несовпадения ожидаемых и полученных результатов запускается процедура исправления ошибки, которая заключается во внимательном анализе (просмотре) протокола промежуточных вычислений, приведших к некорректным данным с помощью следующих методов:
А) "Выполнение программы в уме" (deskchecking).
Б) Вставка операторов протоколирования (печати) промежуточных результатов (logging).
В) Пошаговое выполнение программы (single-step running).
•Step Into – если выполняемая строчка кода содержит вызов функции, процедуры или метода, то происходит вызов, и программа останавливается на первой строчке вызываемой функции, процедуры или метода.
•Step Over - если выполняемая строчка кода содержит вызов функции, процедуры или метода, то происходит вызов и выполнение всей функции и программа останавливается на первой строчке после вызываемой функции.
•Step Out – предназначена для выхода из функции в вызывающую функцию. Эта команда продолжит выполнение функции и остановит выполнение на первой строчке после вызываемой функции.
Г) Выполнение с заказанными остановками (breakpoints), анализом трасс (traces) или состояний памяти - дампов (dump).
Д) Реверсивное (обратное) выполнение (reversible execution)
Тестирование – это:
•Процесс выполнения ПО системы или компонента в условиях анализа или записи получаемых результатов с целью проверки (оценки) некоторых свойств тестируемого объекта. The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component [9].
•Процесс анализа пункта требований к ПО с целью фиксации различий между существующим состоянием ПО и требуемым (что свидетельствует о проявлении ошибки) при экспериментальной проверке соответствующего пункта требований. The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate features of software items [[IEEE Std.610-12.1990], [9].
•Контролируемое выполнение программы на конечном множестве тестовых данных и анализ результатов этого выполнения для поиска ошибок [IEEE Std 829-1983].
Реализация тестирования разделяется на три этапа:
•Создание тестового набора (test suite) путем ручной разработки или автоматической генерации для конкретной среды тестирования (testing environment).
•Прогон программы на тестах, управляемый тестовым монитором (test monitor, test driver [IEEE Std 829-1983], [9]) с получением протокола результатов тестирования (test log).
•Оценка результатов выполнения программы на наборе тестов с целью принятия решения о продолжении или остановке тестирования.
Основная проблема тестирования - определение достаточности множества тестов для истинности вывода о правильности реализации программы, а также нахождения множества тестов, обладающего этим свойством.
Сегодня материал взят отсюда: http://www.intuit.ru/department/se/testing/
Ну или так: ©www.intuit.ru
Подписаться на:
Сообщения (Atom)