Список Тестов Для Регрессионного Тестирования
#1
Отправлено 06 ноября 2003 - 09:29
надеюсь пополнить список постоянных посетителей форума...
После исправления багов и довеска новых фич неизменно возникает вопрос - где и что "потрогать" на предмет "не отвалилось ли". Речь идет о проверки работоспособности старого функционала. (кажется все присутствующие здесь называют это "регрессионным тестом"). Наверное, есть какая-то теория для этого случая, но я пока подхожу по-сермяжному - для исправленного компонента надо посмотреть на все вызовы, все линки и пр. relations. В моем мозгу появляется идея - найти анализатор кода который быстренько сканирует сорсы и говорит, что и откуда вызывается и создает какой-нибудь удобоваримый отчет. Что-нибудь посоветуете?
#2
Отправлено 06 ноября 2003 - 10:00
Мне кажется, анализатор кода - вещь хорошая, но этого мало для обоснованного подтверждения работоспособности старого кода. Как первый этап в тестировании - годится. Вы получите подтверждение, что все вызовы и связи прописаны правильно и сможете подготовить информацию, позволяющую определить область системного (интеграционного) тестирования. Но не более.
#3
Отправлено 06 ноября 2003 - 12:37
1) Полный ретест. После того как внесено последнее изменение в код, доступ разработчикам закрывается. Далее проходим по всем сценариям. Метод конечно дает хорошие результаты, но его трудоемкость, а главное время, необходимое на проведение, выходят за все разумные пределы.
2) Прогон автоматических тестов. Идеально, если поле покрытия - полное. Требует огромной подготовительной работы, но зато позволяет быстро вынести вердикт по релизу.
3) Проход приемочных тестов. Самое главное - достаточно хорошо сузить поле тестирования и объединить сценарии в тест сьюты.
При хроническом недостатке ресурсов, а это почти все российские конторы, реализовать удается только последний вариант.
-- Пример -------------
Был у нас форум. Мы внесли туда крохотные изменения. Он работает?
Основные юз-кейсы форума:
1) Просмотр тем
2) Просмотр сообщений
3) Логирование
4) Добавление темы
5) Добавление сообщения
Составляем тест-сьют из этих сценариев. Проходим.
Все.
В стороне остаются проверки на граничные, некорректные данные и т.д. и т.п.
--------------------------
С высокой долей вероятности можно утверждать, что если ранее форум был хорошо оттестирован и отлажен и, если данный тест сьют успешно прошел, то форум работает.
Причина этого заключается в следующем: Если внесение небольших изменений (имя столбца БД, удаление класса,...) привело к появлению новых багов, то, как правило, эти баги блокируют основную функциональность.
Редко это приводит к появлению минорных багов, а критические легко заметны...
Автоматизацию регресионного тестирования также рекомендую начинать с таких сьютов. И только потом увеличивать глубину.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#4
Отправлено 07 ноября 2003 - 10:47
Если внесение небольших изменений (имя столбца БД, удаление класса,...) привело к появлению новых багов, то, как правило, эти баги блокируют основную функциональность.
Да будет вам! Сменим имя таблицы и вывалится не основной функционал, а скажем процедура архивации.
Выстроенное на данной предпосылке обоснование не является валидным. Софистика.
Редактор портала www.it4business.ru
#5
Отправлено 10 ноября 2003 - 07:58
Добавьте один юз кейс на архивацию.Если внесение небольших изменений (имя столбца БД, удаление класса,...) привело к появлению новых багов, то, как правило, эти баги блокируют основную функциональность.
Да будет вам! Сменим имя таблицы и вывалится не основной функционал, а скажем процедура архивации.
Выстроенное на данной предпосылке обоснование не является валидным. Софистика.
Поле тестирование сужается не за счет исклюцения прецендентов, а за счет уменьшение тест кейсов по одному преценденту.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#6
Отправлено 10 ноября 2003 - 10:42
2 Олешка
Конечно, список измененных компонент и список компонент, связанных с измененными, это лишь первый шаг. Следующий шаг - провести анализ "подозрительной" части кода (пальчиками по экрану:-), но не всего, а только в связанных компонентах . Затем на основании личных сомнений тестировщика надо сформировать список тестов. В него войдут приемочные тесты измененных компонент (скорее всего их источник менеджер или заказчик) и регриссионные тесты связанных компонент (это именно их составил тестировщик, анализируя код)
2 SALar
Приемочный тест - это неминуемое явление, о нем и рассуждать нечего. Другое дело "минорные" баги (это общий термин или Ваша собственность?) - не видимые в основном функционале (и в приемочном тесте тоже), но заявляющие о себе в самый неприятный момент. Глупо ждать наступления инцидента у заказчика (на примере того же резервного копирования), желательно провести упреждающую атаку на баг. Понимаю, что идеальный вариант это объемный набор тестов, но все вынужденны сокращать его. Я пытаюсь сузить их список опираясь на автоматизированный анализ кода.
2 Все.
И все-таки, есть ли у кого опыт работы с анализаторами кода? Не могли бы Вы что-либо посоветовать?
#7
Отправлено 10 ноября 2003 - 11:44
Лучше на основе информации об изменениях ;)Затем на основании личных сомнений тестировщика надо сформировать список тестов.
#8
Отправлено 10 ноября 2003 - 12:32
Так оно так и получится - смотришь по списку изменений и заглядываешь в связанные компоненты и чешешь репу - "проверить надо бы". С одной стороны есть список изменений в компонентах, а с другой стороны в связанных компонентах тоже не все тесты проводить надо, а только некоторые. Вот и пытаешся по характеру изменения и по характеру связи с измененной компоненте прикинуть какие тесты желательно провести...
....А по сути просьбы есть что-нибудь?
#9
Отправлено 02 июня 2004 - 13:36
Можно поиграться с этими тулами:Наверное, есть какая-то теория для этого случая, но я пока подхожу по-сермяжному - для исправленного компонента надо посмотреть на все вызовы, все линки и пр. relations. В моем мозгу появляется идея - найти анализатор кода который быстренько сканирует сорсы и говорит, что и откуда вызывается и создает какой-нибудь удобоваримый отчет. Что-нибудь посоветуете?
- AQTime
- DevPartner
- Purify and Quantify
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных