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

[mrjazz]

Как правильно организовать тестирование списков?
Возьмем банальную задачу - протестировать правильную работу постраничного списка данных. Необходимо убедиться что в списке именно те данные что нам нужны, ну и проверить порядок сортировки.
Очень желателен пример на любом язяке/инструменте который Вы используете для тестирования. Т.е. как сделать что бы было максимально просто, быстро и гибко?

[dlg99]

стянуть содержимое грида в массив.

на "псевдокоде":

grid_data = grid_as_array( grid_id );

expected_data = get_expected_content( ... );

//check that grid shows correct data, 
assert( compare( grid_data, expected_data, ignore_sort = true ) );

//check sorting

sorted_grid_data = grid_data.sort( ... )
assert( compare( grid_data, sorted_grid_data, ignore_sort = false ) );

на QuickTest-е грид утягивался в массив примерно так (man, i hate vbscript....):

   Public function get_webtable_content( table )
        logger "core", "core.qtp.get_webtable_content"
        logger.inc_indent
    
        dim row_num
        row_num = table.RowCount
        
        Dim intLen
        intLen = row_num
        
        dim column_num
        dim header_column_num
        dim res()
        redim preserve res( intLen-1 )
        dim row()
        dim is_empty
        dim rows_added
        rows_added = 0
        
        for i = 1 to row_num
            column_num = table.ColumnCount( i )
            intLen = column_num
            
            Erase row
            ReDim preserve row( intLen-1 )
            
            is_empty = True
            for c = 1 to column_num
                row( c-1 ) = Trim( table.GetCellData( i, c ) )
                if "" <> row( c-1 ) then
                    is_empty = False
                end if                          
            next

            if not is_empty then        
                res( rows_added ) = row
                rows_added = rows_added + 1
            end if
        next
        redim preserve res( rows_added - 1 )
        
        get_webtable_content = res
        logger.dec_indent
    end function

[mrjazz]

Спасибо за примеры, так я себе это и представлял, но насколько я понял вы предлагаете сравнивать множество данных с каким то эталоном (expected_data). А тут мы рискуем видеть ошибку в каждом случае изменения данных. Либо правильно устраивать прогон только на тестовой базе? Но ведь в тестовую базу сами тесты постоянно вносят изменения. Т.е. интересна сама методология, подход к выполнению тестирования. Если можно где то об этом почитать был бы очень признателен, т.к. то что попадалось мне в руки это только теоретические изыскания неприменимые в реальных условиях.

[dlg99]

Необходимо убедиться что в списке именно те данные что нам нужны, ну и проверить порядок сортировки.

Спасибо за примеры, так я себе это и представлял, но насколько я понял вы предлагаете сравнивать множество данных с каким то эталоном (expected_data). А тут мы рискуем видеть ошибку в каждом случае изменения данных. Либо правильно устраивать прогон только на тестовой базе?

1. гхм. Ну и пусть compare проверяет на "contains" вместо "equal".
expected_data не обязана быть статической, а вполне может вычисляться динамически от теста к тесту (и для каждого запуска теста). О чем "expected_data = get_expected_content( ... )" и говорит.
А уж как - это зависит от того что/как/... тестируется. Кстати как сравнивается - тоже зависит от...
Это иожет быть результат запроса к базе данных. Это может быть результат подготовки теста. Или mock object (for unit tests).

2. тестировать на тестовой базе... а на какой еще - не на production же?
все таки для тестов частенько в базе нужно что-нибудь создать/удалить...

3. да, тесты не должны зависеть от результатов других тестов.
Как это сделать? не зная Вашего конкретного случая сказать сложно.
Предположим, что

протестировать правильную работу постраничного списка данных. Необходимо убедиться что в списке именно те данные что нам нужны, ну и проверить порядок сортировки.

означает, что тестируется поиск. например, по подстроке.

тогда есть варианты:

а. создать запись с заданной подстрокой, создать запись без подстроки, запустить поиск. Убедиться, что одна запись вошла в результат, а другая нет. проверить сортировку.

б. создать запись с заданной подстрокой, создать запись без подстроки, запустить поиск. Запросить базу и получить список записей, сравнить два списка. Можно еще убедиться, что одна запись вошла в результат, а другая нет.

в. создать запись с некоторой уникальной подстрокой, создать запись без подстроки, запустить поиск. Убедиться, что результат == одной записи с подстрокой.

г. очистить базу, добавить необходимые данные, .......

д. просто запросить базу - получить ожидаемый результат, запустить поиск, сравнить.

и т.д., и т.п.

Надеюсь, что не слишком сумбурно описал и все понятно.
Если нет - спрашивайте еще.
Будет время - отвечу.

[Mike]

По-поводу изменения тестовых данных это проблема глобальная. На самом деле, существует всего 2 подхода к тестированию данных, отображаемых приложением.

1. Чисто регрессионный - входные данные НИКОГДА не меняются, или по-крайней мере не меняются в промежутке времени между захватом baseline и проведением теста. Основной плюс этого подхода - тестируется всё и сразу. Такие тесты очень легко и писать, и отлаживать. Основных проблем 2 - как обеспечить неизменность входных данных, и как анализировать результаты (если разница между отобрахаемыми данными разными версиями програмы всё же есть). Однако, плюсы настолько серьёзны, что они перевешивают даже серьёзнейшие накладные расходы при обеспечении неизменности данных. В случае с приложением - клиентом СУБД прийдётся иметь отдельную "регрессионную" БД, небольшого размера, которую легко можно сохранять и восстанавливать из бэкапов (как раз потому,что тесты сами могут менять там данные), и накатывать на эту базу те-же install-scripts, что и на обычную тестовую базу. Возможно, прийдётся так-же переводить часы и на сервере, и на клиенте - тоже, между прочим, серьёзнейшие входные данные!

2. "Функциональный подход". В двух словах, идея состоит в том, что если мы хотим протестировать систему, то мы должны создать вторую систему на основе тех же спецификаций, и имея на входе одни и те-же данные сравнить данные на выходе. Вопрос только заключается в том, какую часть системы мы будем "эмулировать", какие данные считать входными, и т.д. От этого будет зависеть полнота покрытия. Вот некоторые примеры:
1) Сравнивать данные в гриде на экране с результатом запроса из БД.
2) Проверять данные в гриде на соответствие неким правилам. Это может быть формат данных, а может - зависимость между данными в разных колонках
3) Можно сохранять данные, полученные на одном экране и сравнивать их с теми же данными, показываемыми на другом экране
4) Внутри скрипта расчитывать данные, которые должны отображаться на основе данных других колонок, других экранов, либо запросов к БД.

Как нетрудно видеть - покрытие в любом случае будет слабенькое, зато работы - очень много, и поддерживать такие тесты будет проблематично. В примере 1 мы хотя-бы можем полностью протестировать клиентскую часть, остальные же не дают нам и этого. Все варианты тестирования с использованием запросов к БД не являются в чистом виде тестированием "чёрного ящика".

Вывод простой - либо всё-таки организовывать регрессионное тестирование, либо увеличить штат тестеров раза в 3 по-прежнему не имея гарантий тестового покрытия...

[Mike]

Хотелось бы добавить пару слов насчёт "функционального" подхода. К сожалению, большинство скриптовых языков используемых в инструментах автотестирования слабо подходят для сложных манипуляций с данными, которые понадобятся при внедрении функционального тестирование. Исключение Rational Functional Tester (из которого, в свою очередь, "кликалка" очень посредственная). Кроме того, отлаживать вместе взаимодействие с тестируемым приложением и тестирование данных, получаемых из этого приложения - задача не для слабонервных. Прежде всего, из-за того что полный прогон скрипта занимает обычно ВАГОН времени...

Поэтому есть альтернативный подход - сохранять "вывод" приложения (то есть, содержимое таблиц) в файлах, не анализируя его во время прогона. А потом анализировать его уже из другого теста, написанного уже не на, скажем VBScript, а на чём-то более серьёзном - на Java, например. Так убивается сразу целый полк зайцев - и возможность писать сложные классы для манипуляции данными, и отсутствие необходимости для отладки "функциональной" части каждый раз взаимодействовать с тестируемым приложением, и, наконец, возможность очень легко преобразовывать рагрессионные тесты в функциональные - просто дописывая "сбоку" обработчик данных, собранных регрессионным тестом. Есть, конечно и минусы. Прежде всего - то что каждый раз при изменении логики работы "кликательного " скрипта, прийдется переписывать "функциональный".

[mrjazz]

Еще раз хочу поблагодарить dlg99 и mike за массу интересной информации, спасибо.

[dlg99]

1. Чисто регрессионный - входные данные НИКОГДА не меняются, или по-крайней мере не меняются в промежутке времени между захватом baseline и проведением теста. Основной плюс этого подхода - тестируется всё и сразу. Такие тесты очень легко и писать, и отлаживать. Основных проблем 2 - как обеспечить неизменность входных данных, и как анализировать результаты (если разница между отобрахаемыми данными разными версиями програмы всё же есть).
............
Возможно, прийдётся так-же переводить часы и на сервере, и на клиенте - тоже, между прочим, серьёзнейшие входные данные!

В случае unit-tests (реже - functional tests) используют простой трик сохранения базы неизменной: просто запускают тест "внутри" transaction, а по завершении теста транзакцию просто откатывают (rollback).

а вот подготовка environment (см. "прийдётся так-же переводить часы и на сервере, и на клиенте") такой делает такой подход неприемлимым во многих случаях.

2. "Функциональный подход". В двух словах, идея состоит в том, что если мы хотим протестировать систему, то мы должны создать вторую систему на основе тех же спецификаций, и имея на входе одни и те-же данные сравнить данные на выходе.

Все таки не "создать вторую систему", а скорее создать упрощенную модель тестируемой подсиситемы. (да, я видел "Вопрос только заключается в том, какую часть системы мы будем "эмулировать", какие данные считать входными, и т.д.")

на примере простого поиска все легко сводится к:
Исходя из спецификации определяем 2 набора данных: то что должно быть найдено, и то что не должно.
добавляем их в базу.
запускаем поиск.
убеждаемся, что не нашли "то что не должны".
убеждаемся, что нашли "то что должны".
игнорируем все остальное найденное.

Моделью это назвать тяжело

при поиске по нескольким параметрам появляются еще проблемы связанные с оптимизацией test set/test data generation. Вот тут уже можно и модель писать.

Еще. по-моему такой "подход" все-таки называют model-based, а не functional.

рекомендуемое чтиво:
http://www.geocities..._based_testing/
и Testing Object-Oriented Systems: Models, Patterns, and Tools by Robert V. Binder

Как нетрудно видеть - покрытие в любом случае будет слабенькое, зато работы - очень много, и поддерживать такие тесты будет проблематично.

не так все страшно. Если к "правильному" куску функциональности приложено.

[Mike]

Спасибо за ссылочки! Что касается терминологии... Да, я был не совсем точен - сначала описал "model-based" тестирование, а потом в качестве примеров привёл функциональное... Как я понимаю функциональное (автоматизированное) тестирование - это тестирование _отдельных_ аспектов работы системы с использованием use-cases. То есть, скажем так, это несистематически организованное model-based тестирование. И таким образом очень сложно добиться хорошего покрытия - проверяем то, что можем проверить - "ищем под фонарём".

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

[dlg99]

  Методики, описанные в статьях, ссылочку на которые Вы дали - прекрасны, но, увы, слабо применимы к тестированию сложных систем, работающих с большим объемом данных - то ести, клиентов БД, систем автоматизирующих сложные рассчёты, систем имеющих и на входе и на выходе огромные массивы данных... 

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

никто же не моделирует поведение всей системы на всех уровнях.

У нас - достаточно сложная система. ERP + DAM + WF + еще кое-что
например при тестировании частей DAM (digital asset management) приходится еще учитывать и поведение OS в различных ситуациях (и описывать это в модели).

test cases генерятся автоматически. (комбинаций очень много - так что минимизация test set тоже автоматическая. отсев невалидных комбинаций - тоже автоматический. на выходе - порядка 3-4 тысяч test cases, насколько я помню).

Модель позволяет автоматически "предсказать" ожидаемый результат.
Модель может "загрузить" текущее состояние (databse + file system), так что можно легко и с высокой степенью детализации сравнить current vs. expected. И потом легко troubleshoot это.

весь цикл не только запуска, но и "создания" тестов - автоматический.
при добавлении поддержки новой OS (и/или новой file system) все намного легче "расширить" чем при "безмодельном" процессе.

это к тезису о "Слабо применимы потому, что речь идёт .... о тестировании выходных данных."

Не знаю, стоит ли подробнее описывать.
В любом случае сейчас времени нет

[Mike]

Спасибо, Андрей! Впечатляет... Увы, одним авто-тестером и без соответствующей помощи аналитиков такую громаду не потянуть. И потом, у Вас, судя по всему какой-то мощнейший framework вокруг Uniteska или чего-то подобного (как-то вы ведь описываете спецификации для последующей генерации тестов)?

В общем завидую. Идея автоматической генерации тесткейсов из модели хороша. Но без формально описаной спецификации неприменима. И в любом случае, подобное тестирование требует колоссальных ресурсов. Сколько у Вас тестеров? А аналитиков? В общем, не верю что Ваш подход можно безболезненно и быстро внедрить в средних размеров проекте.

Поэтому (вспомнив тему топика), думаю что оптимально (по ресурсам) иметь авто-генерацию функциональных тестов "нетабличных данных" - на основе GUI (перебрать все критерии поиска например; повводить всякую ерунду во все edit-box'es и прочее) - для этого никакая формально описанная модель не требуется - вместо неё используем сам пользовательский интерфейс приложения + набор правил, основанных на стандартах этого самого интерфейса. А вот данные тестировать, всё-же, регрессионно (в смысле, на основе baseline, срхранённого при предыдущем прогоне).

[mrjazz]

test cases генерятся автоматически. (комбинаций очень много - так что минимизация test set тоже автоматическая. отсев невалидных комбинаций - тоже автоматический. на выходе - порядка 3-4 тысяч test cases, насколько я помню).

Модель позволяет автоматически "предсказать" ожидаемый результат.
Модель может "загрузить" текущее состояние (databse + file system), так что можно легко и с высокой степенью детализации сравнить current vs. expected. И потом легко troubleshoot это.

весь цикл не только запуска, но и "создания" тестов - автоматический.
при добавлении поддержки новой OS (и/или новой file system) все намного легче "расширить" чем при "безмодельном" процессе.

Ууух! Если можно, хотелось бы узнать как сие работает? Существует какой то GUI который позволяет описывать модель приложения на основании которого генерируются тесты? Либо тесты генерируются на основании исходного кода? Но как они тогда могут тестировать логику приложения? Какой инструментарий используется, технологии? Хотя боюсь это сильно выходит за рамки топика, но жутко интересно!

[dlg99]

Увы, одним авто-тестером и без соответствующей помощи аналитиков такую громаду не потянуть. И потом, у Вас, судя по всему какой-то мощнейший framework вокруг Uniteska или чего-то подобного (как-то вы ведь описываете спецификации для последующей генерации тестов)?

Все самописное. никакого "Uniteska".
framework - да, накопилось уже кое-чего
Всевозможная комбинаторика, pairwise generation, с filtering чтобы отсеивать невалидные комбинации и и.п.
Когда это писалось, QA-цев было 2 (два), включая меня.

Основная помощь девелоперов заключалась в "выдаче" interfaces: COM on wndows, AlppleScript on Mac. Чтобы "отвязаться" от GUI.

used tools: javascript (WSH) + remote calls of applescript on mac.

сейчас кое-что "переведено" на python + SOAP.

Идея автоматической генерации тесткейсов из модели хороша. Но без формально описаной спецификации неприменима. И в любом случае, подобное тестирование требует колоссальных ресурсов. Сколько у Вас тестеров? А аналитиков? В общем, не верю что Ваш подход можно безболезненно и быстро внедрить в средних размеров проекте.

см. выше.
Девелоперов тогда было ~8.
2 клиентских продукта под 2 платформы + web + сервера + integration with third-party software.
Проект в моем понимании "средний" - не мелочь, но бывают и сильно больше.

все затевялось чтобы "decrease qa workload, increase test coverage, improve quality of end product".

P.S. work smarter, not harder
P.P.S. ушел работать

[Mike]

Андрей, извиняюсь за настойчивость... Но мне показалось, что у Вас скорее Unit- тестирование чем функциональное со стороны GUI? В топике-то речь шла о тестировании таблиц в вёбе с помощью соответствующих инструментов... И кроме того

Всевозможная комбинаторика, pairwise generation, с filtering чтобы отсеивать невалидные комбинации и и.п.

это всё-же скорее генерация тестовых данных, а не самих тестов?

Вот если Вы расскажите, как генерировать такие умные тесты (со стороны GUI), которые будут сами проверять валидность выходных данных в виде таблицы 40*4000....

[mrjazz]

Но мне показалось, что у Вас скорее Unit- тестирование чем функциональное со стороны GUI? В топике-то речь шла о тестировании таблиц в вёбе с помощью соответствующих инструментов...

Стоп. А что на JS нельзя тестировать GUI - можно. Только как в данном случае сгенерировать тесты автоматически (в конкретном случае с grid)? Был бы очень признателен за объяснение.

[Mike]

Насколько я понял Андрея, они предпочитают дёргать API Com-объектов (или что у них там в приложении), а не тестировать со стороны GUI. С моей точки зрения, это не есть тестирование методом "черного ящика" со стороны пользовательского интерфейса. А под генрацией тестов в данном случае, опять-таки, как я понял, понимается генерация тестовых данных. На что я и указал. К тестированию гридов в вёбе всё это никакого отношения не имеет.

Кстати, на JS действительно можно без проблем тестировать Web-приложения методом "почти" чёрного ящика, и без всякого применения специализированных тулов. Но это отдельная тема.

[dlg99]

мне показалось, что у Вас скорее Unit- тестирование чем функциональное со стороны GUI? В топике-то речь шла о тестировании таблиц в вёбе с помощью соответствующих инструментов...

Насколько я понял Андрея, они предпочитают дёргать API Com-объектов (или что у них там в приложении), а не тестировать со стороны GUI. С моей точки зрения, это не есть тестирование методом "черного ящика" со стороны пользовательского интерфейса.

Нет, не юнит-тестирование.
Не черный ящик, не через UI? Давайте посмотрим.
есть приложение.
есть функцональность (сложная).
есть UI (простой) и некий путь "напрямую". Есть определенная уверенность что код там таки не был злонамеренно продублирован =)
есть задача теста UI и теста функциональности.

разбив тестирование на 2 части можно облегчить себе работу:
1. убедимся, что UI передает параметры (минимальный набор тестов, не страшно и в ручную проделать, если выхода нет)
2. убедимся, что при различных комбинициях входных параметров и состояния environment все работает "как надо". Возможности где-то что-то проигнорировать нет - есть риск потери данных.

для части 2 UI не критичен. Возможность bypass UI критична, когда есть multiplatform application, причем на Маке есть определенные проблемы с наличием тулов для тестирования, а на виндах - контролки, которые тулы не очень-то и опознают, да к тому же так быстрее.

Не через UI? да. но эффективнее/проше/работает быстрее =)
Не черный ящик? а почему нет? (ну был он "серым", ну и что).

А под генрацией тестов в данном случае, опять-таки, как я понял, понимается генерация тестовых данных. На что я и указал. К тестированию гридов в вёбе всё это никакого отношения не имеет.

к гридам/вебу отношения не имеет. Просто мы в какой-то момент перешли к "методам" ("методикам"? скорее что-то типа patterns) используемым при атоматизации тестирования. В частности - использование "моделей".
Хотя согласен, оффтопик. сворачиваюсь. чуть-чуть потерпите =)

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

генерация тест кейзов:
- некоторым образом получаем набор входных параметров.
- прогнозируем ожидаемый результат (так же автоматически)

потом уже создаем "тестовые данные" если небходимо и/или приводим AUT в некое начальное состояние.

собственно тест: делаем нечто с AUT и проверяем полученный результат.

Дык, на кой черт тут модель? зачем что-то там генерировать?
пропробуйте написать тесты на простую операцию "move file/folder to another destination, it needs confirmation to replace".
для примера, возможные ситуации, что с ходу в голову приходит:

Source:
 - exists: yes/no
 - file/folder
 - is used by active process(locked, canot be deleted): yes/no
 - if folder, has files/folders in it: yes, no
   -- any of those locked: yes/no
   -- any of those read-only: yes/no
 - is read only(files only, afair): yes, no

Destination:
 - exists: yes/no
 - is the same as the source: yes/no
 - is the same as the source's parent folder: yes/no
 - is on the same drive: yes/no
  -- if no, drive is: local, network
   --- network protocol used to access net volume: samba/afp/...
 - contains file with the same name: yes/no
   -- is read-only: yes/no
   -- is locked: yes/no
 - contains folder with the same name: yes/no
   -- has files/folders in it: yes, no
    --- any of those locked: yes/no
    --- any of those read-only: yes/no

etc.

как в данном случае сгенерировать тесты автоматически (в конкретном случае с grid)

"тестируется поиск. например, по подстроке." например, по нескольким полям в бызе.
нужно понять, что собственно влияет на этот поиск.
предположим:

поле пусто или нет
есть "специальнае символы" (a-la %,--, /*, */, % etc.) или нет
есть wildcards (*, ?) или нет, где они расположены

et cetera.

"простенько":
некоторым образом комбинируем их, для всех полей (для простоты - полный перебор всех возможных сочетаний)

все. устал писать.

[dlg99]

не совсем все.
в случаях, когда генерация тестов не помогает и просто автоматизируется "functinal/regression test set" но есть желание писать тесты с бОльшим code reuse and in some simple/understandable manner, то можно использовать то, что я в невежестве своем привык называть просто "application's model".

ссылка ниже, там это называют "Logical Functional Model" which sound ok for me:
http://blogs.msdn.co...sViewpoint.aspx