Сообщений в теме: 8

[step]

Приветствую участников,
надеюсь пополнить список постоянных посетителей форума...
После исправления багов и довеска новых фич неизменно возникает вопрос - где и что "потрогать" на предмет "не отвалилось ли". Речь идет о проверки работоспособности старого функционала. (кажется все присутствующие здесь называют это "регрессионным тестом"). Наверное, есть какая-то теория для этого случая, но я пока подхожу по-сермяжному - для исправленного компонента надо посмотреть на все вызовы, все линки и пр. relations. В моем мозгу появляется идея - найти анализатор кода который быстренько сканирует сорсы и говорит, что и откуда вызывается и создает какой-нибудь удобоваримый отчет. Что-нибудь посоветуете?

[Олешка]

Добрый день :).

Мне кажется, анализатор кода - вещь хорошая, но этого мало для обоснованного подтверждения работоспособности старого кода. Как первый этап в тестировании - годится. Вы получите подтверждение, что все вызовы и связи прописаны правильно и сможете подготовить информацию, позволяющую определить область системного (интеграционного) тестирования. Но не более.

[SALar]

На мой взгляд, есть три подхода к проблеме "А не отвалилось ли чего в ранее отлаженных кусках?".
1) Полный ретест. После того как внесено последнее изменение в код, доступ разработчикам закрывается. Далее проходим по всем сценариям. Метод конечно дает хорошие результаты, но его трудоемкость, а главное время, необходимое на проведение, выходят за все разумные пределы.
2) Прогон автоматических тестов. Идеально, если поле покрытия - полное. Требует огромной подготовительной работы, но зато позволяет быстро вынести вердикт по релизу.
3) Проход приемочных тестов. Самое главное - достаточно хорошо сузить поле тестирования и объединить сценарии в тест сьюты.

При хроническом недостатке ресурсов, а это почти все российские конторы, реализовать удается только последний вариант.
-- Пример -------------
Был у нас форум. Мы внесли туда крохотные изменения. Он работает?

Основные юз-кейсы форума:
1) Просмотр тем
2) Просмотр сообщений
3) Логирование
4) Добавление темы
5) Добавление сообщения

Составляем тест-сьют из этих сценариев. Проходим.
Все.
В стороне остаются проверки на граничные, некорректные данные и т.д. и т.п.
--------------------------
С высокой долей вероятности можно утверждать, что если ранее форум был хорошо оттестирован и отлажен и, если данный тест сьют успешно прошел, то форум работает.
Причина этого заключается в следующем: Если внесение небольших изменений (имя столбца БД, удаление класса,...) привело к появлению новых багов, то, как правило, эти баги блокируют основную функциональность.
Редко это приводит к появлению минорных багов, а критические легко заметны...

Автоматизацию регресионного тестирования также рекомендую начинать с таких сьютов. И только потом увеличивать глубину.

[Case]

Если внесение небольших изменений (имя столбца БД, удаление класса,...) привело к появлению новых багов, то, как правило, эти баги блокируют основную функциональность.

Да будет вам! Сменим имя таблицы и вывалится не основной функционал, а скажем процедура архивации.
Выстроенное на данной предпосылке обоснование не является валидным. Софистика.

[SALar]

Если внесение небольших изменений (имя столбца БД, удаление класса,...) привело к появлению новых багов, то, как правило, эти баги блокируют основную функциональность.

Да будет вам! Сменим имя таблицы и вывалится не основной функционал, а скажем процедура архивации.
Выстроенное на данной предпосылке обоснование не является валидным. Софистика.

Добавьте один юз кейс на архивацию.

Поле тестирование сужается не за счет исклюцения прецендентов, а за счет уменьшение тест кейсов по одному преценденту.

[step]

Добрый день.

2 Олешка
Конечно, список измененных компонент и список компонент, связанных с измененными, это лишь первый шаг. Следующий шаг - провести анализ "подозрительной" части кода (пальчиками по экрану:-), но не всего, а только в связанных компонентах . Затем на основании личных сомнений тестировщика надо сформировать список тестов. В него войдут приемочные тесты измененных компонент (скорее всего их источник менеджер или заказчик) и регриссионные тесты связанных компонент (это именно их составил тестировщик, анализируя код)

2 SALar
Приемочный тест - это неминуемое явление, о нем и рассуждать нечего. Другое дело "минорные" баги (это общий термин или Ваша собственность?) - не видимые в основном функционале (и в приемочном тесте тоже), но заявляющие о себе в самый неприятный момент. Глупо ждать наступления инцидента у заказчика (на примере того же резервного копирования), желательно провести упреждающую атаку на баг. Понимаю, что идеальный вариант это объемный набор тестов, но все вынужденны сокращать его. Я пытаюсь сузить их список опираясь на автоматизированный анализ кода.

2 Все.
И все-таки, есть ли у кого опыт работы с анализаторами кода? Не могли бы Вы что-либо посоветовать?

[Олешка]

Затем на основании личных сомнений тестировщика надо сформировать список тестов.

Лучше на основе информации об изменениях ;)

[step]

2 Олешка
Так оно так и получится - смотришь по списку изменений и заглядываешь в связанные компоненты и чешешь репу - "проверить надо бы". С одной стороны есть список изменений в компонентах, а с другой стороны в связанных компонентах тоже не все тесты проводить надо, а только некоторые. Вот и пытаешся по характеру изменения и по характеру связи с измененной компоненте прикинуть какие тесты желательно провести...
....А по сути просьбы есть что-нибудь?

[терапевт]

Наверное, есть какая-то теория для этого случая, но я пока подхожу по-сермяжному - для исправленного компонента надо посмотреть на все вызовы, все линки и пр. relations. В моем мозгу появляется идея  - найти анализатор кода который быстренько сканирует сорсы и говорит, что и откуда вызывается и создает какой-нибудь удобоваримый отчет. Что-нибудь посоветуете?

Можно поиграться с этими тулами:

- AQTime
- DevPartner
- Purify and Quantify