Зависимые тесты
#1
Отправлено 19 декабря 2004 - 09:55
Сегодня задали мне резонный вопрос по тестированию: как протестировать контекстный поиск в списке компаний, если на эту таблицу предварительно можно наложить тучу фильтров (имя = Юкос, дата = не более года итп)?
Причем речь идет именно о тестировании ручками ака "черный ящик". Если делать тесты "в лоб", то придется для 5 разновидностей фильтров (можно их комбинировать) делать (2^5)х(число тестовых условий фильтрации)х(число контекстных строк). Итого примерно 32 х 4 х 3 = 384 теста. Нереально. Что делать в подобной ситуации?
#2
Отправлено 19 декабря 2004 - 22:01
#3
Отправлено 20 декабря 2004 - 07:12
1. Относительно разновидностей фильтров - обязательно - по одному фильтру, все вместе
потом НА СКОЛЬКО ХВАТИТ ВРЕМЕНИ - все возможные сочетания
2. Относительно значений в фильтрах - обычно первого и последнего в списке всегда хватает. Все остальное - опять же на сколько позволяет время.
Итого: обязательных тестов - (5+1)*2 = 12
#4
Отправлено 20 декабря 2004 - 08:25
#5
Отправлено 20 декабря 2004 - 08:34
Упс))
Напишу и сюда :P
Я бы сделала так- конечно протестила бы сначала все фильтры по отдельности - для проверки их функционирования по всем полям. А потом бы проверила 3 случая- выбор данных по первым полям всех фильтров (т.е. задание условий только в первых полях фильтров), потом по средним и наконец по последним. Если фильтры работают сами по себе исправно- то этих тест-кейсов должно хватить
#6
Отправлено 20 декабря 2004 - 09:44
Метод Монте-Карло, как известно, даёт скорость сходимости к решению 1/vN (v - квадратный корень, N - число испытаний). Поэтому под этим скрывается непросто идея от нечего делать, но и теоретически обоснованное решение, приводящее к правильному ответу.
Ну а так, на граничных значениях стоит всё проверить. Например, не используя один из фильтров. Или пустое где-нибудь вводить.
#7
Отправлено 20 декабря 2004 - 15:09
Pairwise Testing for DummiesЕсли делать тесты "в лоб", то придется для 5 разновидностей фильтров (можно их комбинировать) делать (2^5)х(число тестовых условий фильтрации)х(число контекстных строк). Итого примерно 32 х 4 х 3 = 384 теста. Нереально. Что делать в подобной ситуации?
#8
Отправлено 20 декабря 2004 - 15:22
Статья хорошая, только смущает одно:
у них не протестили вариант с прыжком 150-фунтового товарища с 60-см высоты на асфальт. Пружинка-то как раз при таких условиях и сломается... :P
#9
Отправлено 21 декабря 2004 - 07:10
Данный подход еще называют тестированием ортогональных массивов.
"Тестирование ортогональных массивов основывается на статистических методах, заимствованных из промышленности. Для применения этого метода необходимо, чтобы у программы были независимые наборы состояний. Задача состоит в спаривании каждого состояния из одного набора со всеми состояниями из другого набора, по крайней мере, оди раз. Применение комбинаторных методов применяется для снижения количества тестов заключается в определении уникальных пар состояний..."
Цитата из книги Л Тамре.
#10
Отправлено 21 декабря 2004 - 07:13
#11
Отправлено 21 декабря 2004 - 08:01
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#12
Отправлено 21 декабря 2004 - 08:17
#13
Отправлено 21 декабря 2004 - 15:03
Если каждый из них занимает хотя бы 5 минут... После автоматизации...... а вообще-то 384 теста -- это ерунда, не руками же их прогонять ...
384 * 5 = 1920 минут = 32 часа.
Да, за неделю перед релизом их можно прогнать.
Но вот как smoke test их все использовать это уже чересчур.
#14
Отправлено 21 декабря 2004 - 15:08
А если релизы каждую неделю :)Да, за неделю перед релизом их можно прогнать.
#15
Отправлено 21 декабря 2004 - 15:13
5 минут - это очень много.. конечно можно задержки такие поставить, что будет час теститься.. но можно и за 10 секунд прогнать)Если каждый из них занимает хотя бы 5 минут...
#16
Отправлено 21 декабря 2004 - 15:55
программа (на самом деле подсистема программы) получает preview различных графических файлов.
Поддерживаемых форматов почти 30.
У каждого формата есть свои ньюансы - compession level, layers, colors, subformats, has preview embedded (inside or in resource fork), multipage or not и т.д.
Есть кучка настроек - max preview sizes, preview compression level, configuration of how to get preview и т.д.
у большинства файлов превью выдирается быстро, но есть ряд файлов (e.g. very large TIFFs) для которых этот процесс занимает час.
Еще базу нужно сконфигурировать. Проверить результаты.
Тест выполняется не через GUI, так что замечание про "задержки" мы отметем с негодованием как неорганизованное © надеюсь известен.
Релизы каждую неделю просто утомят заказчика (updates of antivarus bases I would not call 'releases').
Так что на каждом билде все тесты гонять - это слишком.
#17
Отправлено 21 декабря 2004 - 18:04
На каждый аргумент можно найти контраргумент. Особенно добавив новых деталей. Речь шла просто про 384 теста, а про 5 минут на каждый и про то, что это smoky test -- это Вы, милостивый государь, домыслили.Если каждый из них занимает хотя бы 5 минут... После автоматизации...... а вообще-то 384 теста -- это ерунда, не руками же их прогонять ...
384 * 5 = 1920 минут = 32 часа.
Да, за неделю перед релизом их можно прогнать.
Но вот как smoke test их все использовать это уже чересчур.
Да, иногда и 10 тестов могут выполняться очень долго. Приведу и другой пример, не умозрительный, а вполне реальный. Как все, конечно, знают ;), мы разрабатываем инстументы тестирования на основе моделей. Есть у нас компилятор языка, на котором описываются модели, это расширение языка программирования. Так вот, для парсера, например, генерируется почти 400000 тестов, и при этом генерация и выполнение вместе взятые занимают меньше часа (машина P4-2700, 512 Mb). Есть и более тяжеловесные с точки зрения объёма тестирования подсистемы, например, для анализатора результатов, который на вход получает трассы в формате XML, общий объём генерируемых тестов (трасс) занимает более 4 Gb, мы их даже не генерируем заранее -- сгенерировали тест, выполнили, удалили, и так несколько часов подряд.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#18
Отправлено 21 декабря 2004 - 18:26
"сферический конь в вакууме". B)Речь шла просто про 384 теста
тогда и 500000000 тестов минимизировать не нужно. В теории и так все хорошо.
Позаолю себе напомнить "оригинальную" постановку вопроса:
Итого примерно 32 х 4 х 3 = 384 теста. Нереально. Что делать в подобной ситуации?
Давайте базироваться на конкретных use-cases, как то:
100000 возможных тестов со средним временкм выполнения каждого < 1 sec.
или: 500 тестов со средним временем выполнения каждого 30 min.
или 100 тестов со средним временем выполнения 5 минут но невозможностью автоматизации.
Давайте добавим информации о том, что произойдет при ошибке - город останется без света или пользователь "испытает легкое неудобство" :unsure:
А потом для конкретного случая обсудим best practicies and methods.
Иначе можно долго спорить. :)
#19
Отправлено 22 декабря 2004 - 11:31
Просто так прокомментирую, что каждый из этих гипотетических тестов на тестовой БД средних размеров выполнялся бы 1-5 секунд максимум.
Итого: примерно 1800 сек или полчаса. А скорее всего и в минут 5-10 уложилось бы.
#20
Отправлено 23 декабря 2004 - 14:52
Я бы построил работу следующим образом. Разбил бы все тесты на две большие группы: тестирование каждого фильтра в отдельности и комплексно.(я здесь новичок, просьба сильно не пинать)
Сегодня задали мне резонный вопрос по тестированию: как протестировать контекстный поиск в списке компаний, если на эту таблицу предварительно можно наложить тучу фильтров (имя = Юкос, дата = не более года итп)?
Причем речь идет именно о тестировании ручками ака "черный ящик". Если делать тесты "в лоб", то придется для 5 разновидностей фильтров (можно их комбинировать) делать (2^5)х(число тестовых условий фильтрации)х(число контекстных строк). Итого примерно 32 х 4 х 3 = 384 теста. Нереально. Что делать в подобной ситуации?
1. Если нет каких-то функциональных особенностей, то с каждым фильтром я бы провел три теста: 1-ое значение фильтра, случайное значение фильтра в середине списка, последнее значение фильтра в списке (или другие граничные значения, если принцип фильтрации основан не на выборе из заданного списка).
Так же необходимо добавить ряд тестов на обработку разного вида информации. Например, фильтрация текстовой информации, цифровой и комбинированной.
Такой подход к подготовке тестов основывается на подходе группировки характерных тестовых данных в различные классы. Затем тестируются только критичные данные для конкретного класса.
После того, как мы убедились, что каждый фильтр в отдельности работает корректно, можно переходить к комплекному тестированию.
2. Здесь не обойтись без дополнительной информации о работе фильтров. Необходимо выяснить у разработчиков по какому принципу происходит фильтрация информации. Это может быть или пересечение, или объединение или еще бог весть как. :)
Далее, строим матрицу тестов исходя из того же принципа классовости ( и в тестировании не обойтись без классового подхода :P ): одно среднее и граничные условия фильтрации. Для каждого вида фильтра оно может быть своим, но общая сумма тестов наверняка будет меньше 384. B)
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных