Меня интересует книга или ресурс по тестированию, где описаны практики применения модульного тестирования, интеграционного тестирования ну и другие виды в крупных компаниях, в крупных проектах, в сильно связанных проектах.
Есть у нас проект, очень большой. Много компонент, все компоненты связаны между собой, связаны с системными либами всякими. Компоненты могут сами состоять из кучи модулей, библиотек и прочего. Входные данные не простые: xml файлы (формат позволяет создать миллионы входных данных), комманд лайн.
Хотел бы узнать как в подобных проектах модульное тестирование организуется. И как вообще лучше тестить. На каком уровне. Может есть в какой книжке что-то подобное.
Здравствуйте, Minimaxus, Вы писали:
M>Привет всем.
M>Меня интересует книга или ресурс по тестированию, где описаны практики применения модульного тестирования, интеграционного тестирования ну и другие виды в крупных компаниях, в крупных проектах, в сильно связанных проектах.
M>Есть у нас проект, очень большой. Много компонент, все компоненты связаны между собой, связаны с системными либами всякими. Компоненты могут сами состоять из кучи модулей, библиотек и прочего. Входные данные не простые: xml файлы (формат позволяет создать миллионы входных данных), комманд лайн.
M>Хотел бы узнать как в подобных проектах модульное тестирование организуется. И как вообще лучше тестить. На каком уровне. Может есть в какой книжке что-то подобное.
M>Спасибо.
Дело в том, что сильно связанные компоненты почти невозможно адекватно покрыть юнит тестами.
Обычно все дают совет — сначала просто начинать писать новый код уже с тестами или начинать с какого нибудь модуля/мини проекта.
Тогда будет понимание того и как нужно будет рефакторить основной проект. И потом потихоньку начать покрывать его тестами.
Вот несколько статей по модульным тестам на OpenQuality.ru: Модульные тесты
Самое главное: важно понять, что нет одинаковых проектов. Нет серебряной пули. Вам нужно формировать свою систему тестов исходя из специфики вашего проекта. То, что проект большой — это не специфика. Кстати, тот факт, что в роли входных данных выступают XML-файлы, сильно облегчит вашу задачу. А если и на выходе XML-файлы, то можно добиться 100% покрытия модульными тестами.
Успехов,
OpenQuality.ru | Качество программного обеспечения
Re[2]: Посоветуйте книгу или ресурс по тестированию
Здравствуйте, OpenQuality, Вы писали:
OQ>Самое главное: важно понять, что нет одинаковых проектов. Нет серебряной пули. Вам нужно формировать свою систему тестов исходя из специфики вашего проекта. То, что проект большой — это не специфика. Кстати, тот факт, что в роли входных данных выступают XML-файлы, сильно облегчит вашу задачу. А если и на выходе XML-файлы, то можно добиться 100% покрытия модульными тестами.
OQ>Успехов
Да,то что входные данные в XML-формате облегчит задачу, но это больше интеграционных тестов касается.
Для юнит тестов придется решать проблемы сильной связности (если мы с автором одиново понимаем этот термин).
Тут впринципе должны помочь мок фреймворки. Желательно typemock — он может подменять сразу классы — не придеться существующюю инфраструктуру рефакторить для создания интерфейсов. Можно будет проще начать юнит тестирование новго кода.
инфу искать тут: http://typemock.com/learn_about_dotnet_unit_testing_with_Typemock.php
по книгам — стандартный набор: К. Бек Test-Driven Development, М. Фаулер "Рефакторинг".
Еще сам хочу достать Roy Osherove "The art of unit testing". На русском еще не издавалась. Автор заслуженный эксперт в ТТД.
Re[2]: Посоветуйте книгу или ресурс по тестированию
Здравствуйте, Gmoorick, Вы писали:
G>Здравствуйте, Minimaxus, Вы писали:
M>>Привет всем.
M>>Меня интересует книга или ресурс по тестированию, где описаны практики применения модульного тестирования, интеграционного тестирования ну и другие виды в крупных компаниях, в крупных проектах, в сильно связанных проектах.
M>>Есть у нас проект, очень большой. Много компонент, все компоненты связаны между собой, связаны с системными либами всякими. Компоненты могут сами состоять из кучи модулей, библиотек и прочего. Входные данные не простые: xml файлы (формат позволяет создать миллионы входных данных), комманд лайн.
M>>Хотел бы узнать как в подобных проектах модульное тестирование организуется. И как вообще лучше тестить. На каком уровне. Может есть в какой книжке что-то подобное.
M>>Спасибо.
G>Дело в том, что сильно связанные компоненты почти невозможно адекватно покрыть юнит тестами.
G>Обычно все дают совет — сначала просто начинать писать новый код уже с тестами или начинать с какого нибудь модуля/мини проекта. G>Тогда будет понимание того и как нужно будет рефакторить основной проект. И потом потихоньку начать покрывать его тестами.
Видимо я зря не объяснил, что я понимаю под "сильно связанными компонентами".
Есть к примеру ехе файл, который мне надо протестить. Так вот этот ехе файл хотелось бы тестить как отдельный модуль, причем отдельно от всего продукта. Так вот сегодня выяснилось, что вне продукта он вообще не работает. Ему нужны какие-то dll продуктовые, которые раскиданы по разным папкам, ему нужны какие-то конфигурационные файлы, ему нужен реестр кажется еще Также какие-то системные библиотеки.
Еще этот модуль не просто так что-то получает на вход, а на выходе выдает результат. В процессе работы он вызывает кучу других ехе файлов, они тоже в свою очередь что-то делают, настраивают на сервере службы всякие. И вот эти ехе файлы, которые он вызывает хочется тестировать тоже как отдельные модули.
Я ответственнен за определенную компоненту, она состоит из 6 таких ехе файлов, которые взаимодействуют друг с другом, другими файлами и что-то при этом еще с системой делают.
Так понятно? Это вообще нормально?
Т.е. рефакторинг тут пока не причем, им отдельно наши программисты занимаются, меня пока это не интересовала что они там рефакторят. Но после рефакторинга они бы тоже хотели очень быстро запускать тесты.
Re[2]: Посоветуйте книгу или ресурс по тестированию
Здравствуйте, OpenQuality, Вы писали:
OQ>Вот пара больших ресурсов для обретения теоретических познаний:
OQ>1. Software Testing Portal (En)
OQ>2. Тестирование Программного Обеспечения (Ru)
OQ>Вот несколько статей по модульным тестам на OpenQuality.ru: Модульные тесты
OQ>Самое главное: важно понять, что нет одинаковых проектов. Нет серебряной пули. Вам нужно формировать свою систему тестов исходя из специфики вашего проекта. То, что проект большой — это не специфика. Кстати, тот факт, что в роли входных данных выступают XML-файлы, сильно облегчит вашу задачу. А если и на выходе XML-файлы, то можно добиться 100% покрытия модульными тестами.
OQ>Успехов,
Спасибо за ссылки, гляну на досуге.
Я понимаю ваш оптимизм насчет XML файлов, но они очень здоровенные и вариабельные. Выход зависит не только от входа, но и от состояния системы, а таких состояний тоже море. Видимо тут глубокий анализ входных данных нужен, чтобы понять закономерности. Пока мне видится порядка миллиона тестов, т.е. очень много! Но я подумаю над этим.
Re[3]: Посоветуйте книгу или ресурс по тестированию
Здравствуйте, Gmoorick, Вы писали:
G>Здравствуйте, OpenQuality, Вы писали:
OQ>>Самое главное: важно понять, что нет одинаковых проектов. Нет серебряной пули. Вам нужно формировать свою систему тестов исходя из специфики вашего проекта. То, что проект большой — это не специфика. Кстати, тот факт, что в роли входных данных выступают XML-файлы, сильно облегчит вашу задачу. А если и на выходе XML-файлы, то можно добиться 100% покрытия модульными тестами.
OQ>>Успехов
G>Да,то что входные данные в XML-формате облегчит задачу, но это больше интеграционных тестов касается.
G>Для юнит тестов придется решать проблемы сильной связности (если мы с автором одиново понимаем этот термин). G>Тут впринципе должны помочь мок фреймворки. Желательно typemock — он может подменять сразу классы — не придеться существующюю инфраструктуру рефакторить для создания интерфейсов. Можно будет проще начать юнит тестирование новго кода. G>инфу искать тут: http://typemock.com/learn_about_dotnet_unit_testing_with_Typemock.php
G>по книгам — стандартный набор: К. Бек Test-Driven Development, М. Фаулер "Рефакторинг". G>Еще сам хочу достать Roy Osherove "The art of unit testing". На русском еще не издавалась. Автор заслуженный эксперт в ТТД.
Спасибо. Очень сильно интересует как все это делается в микрософт.
По разному понимаем сильную связность Вы с точки зрения хорошегго кода это понимаете. Вобщем я писал выше, повторюсь:
-------------
Видимо я зря не объяснил, что я понимаю под "сильно связанными компонентами".
Есть к примеру ехе файл, который мне надо протестить. Так вот этот ехе файл хотелось бы тестить как отдельный модуль, причем отдельно от всего продукта. Так вот сегодня выяснилось, что вне продукта он вообще не работает. Ему нужны какие-то dll продуктовые, которые раскиданы по разным папкам, ему нужны какие-то конфигурационные файлы, ему нужен реестр кажется еще Также какие-то системные библиотеки.
Еще этот модуль не просто так что-то получает на вход, а на выходе выдает результат. В процессе работы он вызывает кучу других ехе файлов, они тоже в свою очередь что-то делают, настраивают на сервере службы всякие. И вот эти ехе файлы, которые он вызывает хочется тестировать тоже как отдельные модули.
Я ответственнен за определенную компоненту, она состоит из 6 таких ехе файлов, которые взаимодействуют друг с другом, другими файлами и что-то при этом еще с системой делают.
Так понятно? Это вообще нормально?
Т.е. рефакторинг тут пока не причем, им отдельно наши программисты занимаются, меня пока это не интересовала что они там рефакторят. Но после рефакторинга они бы тоже хотели очень быстро запускать тесты.
-------------
Re[4]: Посоветуйте книгу или ресурс по тестированию
Здравствуйте, Minimaxus, Вы писали:
M>Есть к примеру ехе файл, который мне надо протестить. Так вот этот ехе файл хотелось бы тестить как отдельный модуль, причем отдельно от всего продукта. Так вот сегодня выяснилось, что вне продукта он вообще не работает. Ему нужны какие-то dll продуктовые, которые раскиданы по разным папкам, ему нужны какие-то конфигурационные файлы, ему нужен реестр кажется еще Также какие-то системные библиотеки. M>Еще этот модуль не просто так что-то получает на вход, а на выходе выдает результат. В процессе работы он вызывает кучу других ехе файлов, они тоже в свою очередь что-то делают, настраивают на сервере службы всякие. И вот эти ехе файлы, которые он вызывает хочется тестировать тоже как отдельные модули.
M>Я ответственнен за определенную компоненту, она состоит из 6 таких ехе файлов, которые взаимодействуют друг с другом, другими файлами и что-то при этом еще с системой делают.
M>Так понятно? Это вообще нормально?
Да, так понятней и имхо это совсем не нормально
Сразу по терминологии:
вот это: > вне продукта он вообще не работает. Ему нужны какие-то dll продуктовые, которые раскиданы по разным папкам, ему нужны какие-то конфигурационные файлы, ему нужен реестр кажется еще Также какие-то системные библиотеки.
Вот это интеграционные тесты. Ты должен проверить, что при установки программы все кладется куда надо и компоненты друг с другом взаимодействуют
M>Я ответственнен за определенную компоненту, она состоит из 6 таких ехе файлов, которые взаимодействуют друг с другом, другими файлами и что-то при этом еще с системой делают.
Это уже функциональные. Ты берешь собранную систему и даешь её команды и отслеживаешь поведение всей системы по какимто параметрам.
Входные параметры могут передаваться например и через UI, имитируя работу пользователя. Или вызовами через порты с какимито данными, если приложение сетевое. Как ты будешь отлавливать результаты зависит от тебя. Т.е. для такого рода тестов уже нужны или средства тетсирования УИ или свои подпрограммы.
M>Т.е. рефакторинг тут пока не причем, им отдельно наши программисты занимаются, меня пока это не интересовала что они там рефакторят. Но после рефакторинга они бы тоже хотели очень быстро запускать тесты.
И зря не интересует. Если тестированием занимаются разные люди, то тестировщики все равно должны принимать участие в разработке и создании архитектуры.
Ибо сделать продукт нетестируемым слишком легко. Т.е. если заранее представлять то,что модуль будет выполнять, откуда брать входящие данные и куда отправлять. В твоем случае, когда работа одного модуля начинает ворошить десятки других — это совсем не хорошо. Модули потому и разделяют на разные сборки, что предполагается, что они друг от друга почти не зависят.
По поводу того как делают в майкрософте:http://ru.wikipedia.org/wiki/Microsoft_Solutions_Framework.
На эту тему есть майкрософтовские же книжки. Только там не будет рецептов, как писать и как тестировать, а просто методология — больше рассказывают о том как организовать командную работу и процесс разработки. На что тебе надо обратить внимание, так это на то, что тестировщики принимают непосредственное участие в разработки архитектуры программы.
Re[5]: Посоветуйте книгу или ресурс по тестированию
G>И зря не интересует. Если тестированием занимаются разные люди, то тестировщики все равно должны принимать участие в разработке и создании архитектуры. ...
G>По поводу того как делают в майкрософте:http://ru.wikipedia.org/wiki/Microsoft_Solutions_Framework.
Задачи ролевого кластера «Тестирование» на разных фазах проекта
Фаза выработки концепции
Стратегии тестирования; критерии приемлемости, их влияние на разработку решения.
Фаза планирования
Оценка дизайна; требования тестирования; план и календарный график тестирования.
Фаза разработки
Функциональное тестирование; выявление проблем; тестирование документации; доработка плана тестирования.
Фаза стабилизации
Тестирование; сообщение об ошибках и их статусе; тестирование конфигурации.
Фаза внедрения
Тестирование производительности.
Где участие в разработке архитектуры? "Критерии приемлемости" — это скорее предъявляемые ограничения.
Я не говорю, что это не нужно делать. Просто при чём здесь MSF?
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[2]: Посоветуйте книгу или ресурс по тестированию
Также какие-то системные библиотеки. 
Автор(ы): И. Винниченко