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

[GipsySh]

Есть задача - организовать автоматизированное тестирование.
Занималась раньше автоматизацией GUI, автоматизацией подготовки тестовой среды и проч. С этим более-менее понятно.
Но есть идея (и желание) огранизвать также модульное тестирование (тестирование "белого ящика" или unit testing, как его еще называют).
Вообще везде, где читала, пишут, что модульные тесты разработывают программисты. Включают, мол, отладочные сообщения прямо в код - и все дела. Но я знаю несколько проектов, где модульные тесты разрабатывали специально выделенные для этой задачи тестировщики (т.е. разработчики отдельно кодировали, тестировщики отдельно делали для этого кода unit-тесты). Насколько, я понимаю, код тестов и код продукта были разнесены (да и вообще, тестировать код с отладочными сообщениями, конечно, хорошо, но в итоге получается , что проверяется не такой код, который в итоге будет отправлен заказчику, что рождает определенные риски).

Проект, для которого планируется делать unit-тесты, разрабатывается на C++.
У меня есть некоторый опыт разработки на этом языке, но с чего начать в данном случае и как это организовать (в Visual Studio: отдельным солюшеном, проектом - ?) - не знаю.
Если кто-нибудь поделится идеями и/или опытом в этом вопросе, буду очень признательна!

[samurai08]

Есть задача - организовать автоматизированное тестирование.
Занималась раньше автоматизацией GUI, автоматизацией подготовки тестовой среды и проч. С этим более-менее понятно.
Но есть идея (и желание) огранизвать также модульное тестирование (тестирование "белого ящика" или unit testing, как его еще называют).
Вообще везде, где читала, пишут, что модульные тесты разработывают программисты. Включают, мол, отладочные сообщения прямо в код - и все дела. Но я знаю несколько проектов, где модульные тесты разрабатывали специально выделенные для этой задачи тестировщики (т.е. разработчики отдельно кодировали, тестировщики отдельно делали для этого кода unit-тесты). Насколько, я понимаю, код тестов и код продукта были разнесены (да и вообще, тестировать код с отладочными сообщениями, конечно, хорошо, но в итоге получается , что проверяется не такой код, который в итоге будет отправлен заказчику, что рождает определенные риски).

Проект, для которого планируется делать unit-тесты, разрабатывается на C++.
У меня есть некоторый опыт разработки на этом языке, но с чего начать в данном случае и как это организовать (в Visual Studio: отдельным солюшеном, проектом - ?) - не знаю.
Если кто-нибудь поделится идеями и/или опытом в этом вопросе, буду очень признательна!

Можно для начала задать простой вопрос? Какого рода ошибки вы хотите находить модульными тестами? На самом деле все зависит от системы, и все покрывать модульными тестами не то что не надо, а даже не нужно.

[Tuchka_84]

Есть задача - организовать автоматизированное тестирование.
Занималась раньше автоматизацией GUI, автоматизацией подготовки тестовой среды и проч. С этим более-менее понятно.
Но есть идея (и желание) огранизвать также модульное тестирование (тестирование "белого ящика" или unit testing, как его еще называют).
Вообще везде, где читала, пишут, что модульные тесты разработывают программисты. Включают, мол, отладочные сообщения прямо в код - и все дела. Но я знаю несколько проектов, где модульные тесты разрабатывали специально выделенные для этой задачи тестировщики (т.е. разработчики отдельно кодировали, тестировщики отдельно делали для этого кода unit-тесты). Насколько, я понимаю, код тестов и код продукта были разнесены (да и вообще, тестировать код с отладочными сообщениями, конечно, хорошо, но в итоге получается , что проверяется не такой код, который в итоге будет отправлен заказчику, что рождает определенные риски).

Проект, для которого планируется делать unit-тесты, разрабатывается на C++.
У меня есть некоторый опыт разработки на этом языке, но с чего начать в данном случае и как это организовать (в Visual Studio: отдельным солюшеном, проектом - ?) - не знаю.
Если кто-нибудь поделится идеями и/или опытом в этом вопросе, буду очень признательна!

У нас основу Unit-тестов делают разработчики .Тестеры только дополняют тесты различными вариантами . Как что устанавливается я точно не скажу, может сами разберитесь.
Знаю, что для юнит-тестов в Visual Studio у нас используется cppunit-1.12.1. Проект для тестов создается в том же Solution-e что и основной проект. Все cpp и h файлы, которые необходимо протестить кладутся в соответствующие папки в проекте Unit-тестов. Далее создается тест в отдельном файле с подключением необходимых модулей. В заголовочном файле для теста прописывается подключение(у нас) cppunit/extension/HelperMacros.h а все создаваемые классы тестов являются наследниками класса CPPUNIT_NS::TestFixture.
По крайней мере у нас так. Но я думаю без помощи разработчиков тестеру тут не обойтись, так как приходится разбираться в каждой функции, что она делает и можно ли её тестить отдельно, а это, конечно, лучше знает сам разработчик.

[samurai08]

Есть задача - организовать автоматизированное тестирование.
Занималась раньше автоматизацией GUI, автоматизацией подготовки тестовой среды и проч. С этим более-менее понятно.
Но есть идея (и желание) огранизвать также модульное тестирование (тестирование "белого ящика" или unit testing, как его еще называют).
Вообще везде, где читала, пишут, что модульные тесты разработывают программисты. Включают, мол, отладочные сообщения прямо в код - и все дела. Но я знаю несколько проектов, где модульные тесты разрабатывали специально выделенные для этой задачи тестировщики (т.е. разработчики отдельно кодировали, тестировщики отдельно делали для этого кода unit-тесты). Насколько, я понимаю, код тестов и код продукта были разнесены (да и вообще, тестировать код с отладочными сообщениями, конечно, хорошо, но в итоге получается , что проверяется не такой код, который в итоге будет отправлен заказчику, что рождает определенные риски).

Проект, для которого планируется делать unit-тесты, разрабатывается на C++.
У меня есть некоторый опыт разработки на этом языке, но с чего начать в данном случае и как это организовать (в Visual Studio: отдельным солюшеном, проектом - ?) - не знаю.
Если кто-нибудь поделится идеями и/или опытом в этом вопросе, буду очень признательна!

У нас основу Unit-тестов делают разработчики .Тестеры только дополняют тесты различными вариантами . Как что устанавливается я точно не скажу, может сами разберитесь.
Знаю, что для юнит-тестов в Visual Studio у нас используется cppunit-1.12.1. Проект для тестов создается в том же Solution-e что и основной проект. Все cpp и h файлы, которые необходимо протестить кладутся в соответствующие папки в проекте Unit-тестов. Далее создается тест в отдельном файле с подключением необходимых модулей. В заголовочном файле для теста прописывается подключение(у нас) cppunit/extension/HelperMacros.h а все создаваемые классы тестов являются наследниками класса CPPUNIT_NS::TestFixture.
По крайней мере у нас так. Но я думаю без помощи разработчиков тестеру тут не обойтись, так как приходится разбираться в каждой функции, что она делает и можно ли её тестить отдельно, а это, конечно, лучше знает сам разработчик.

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

[GipsySh]

samurai08,
разумеется, модульное тестирование не будет основным. Оно планируется как дополнение к существующему процессу тестирования с целью его усиления. В системе постоянно добавляется новый функционал, поэтому модульное тестирование помогло бы в этом случае проверять, что при добавлении этого нового функционала не был "сломан" функционал, реализованный ранее.

Tuchka_84, большое спасибо за описание практической реализации! И отдельное спасибо за ссылку на cppunit! Уже скомплировала для него нужные библиотеки и начала осваивать его.

[Фрося]

История Бага.
(Черный ящик, Белый ящик, модульное тестирование)
Лирика.
После отпуска Головной Мозг (ГМ) категорически отказывается работать. Вчера отлынивала от проверки исправленного функционала до последнего. Сегодня деваться было некуда. Хорошо, что тест был записан. Прогнала тест. УПС!!!!! Вылезла бага на функционале!!! Записала багу кое-как. Ушла пить кофий с чувством выполненного долга.
Пришла. ГМ начал чутка работать. Прогоняю тест. Раз, два. НЕТУ!!! НЕТУУУ бага!!!! Плюнула – порвала записку с багом. Списала на забастовку ГМ. Посидела… ткнулась в другую работу… ГМ бастует. Плюнула. Перешла на работу Спинным Мозгом(СМ). Стала гонять тест, щелкая мышкой по окошкам входных данных. Типа – тестирование методом свободного поиска под управлением СМ.
Через пять часов Баг вылез. И гордо торчал на экране. СМ анализировать ситуацию отказался. Вызвала разработчика.. Тот долго смотрел на баг, пытался спрашивать – на каких входных данных. СМ информацию не выдавал. Но лихо повторял Баг раз за разом. Разработчик бормоча и что-то прикидывая на пальцах ушел в угол…. Просил – не дышать на результаты трудов СМ…Ушла пить кофий…
Нашел – откуда Баг, поправил, принес версию. Уф… убрали баг!!!
Проза.
1.Требований к ПО не было. Еще до отпуска – сформулировала и записала для этого функционала.
2.Тестирование шло "черным ящиком".
3.Тест был записан до отпуска. НО!!! Перебор входных данных был сделан...кое-как.
4.Не зная – как реализовано в софте, найти критичный набор все едино вряд ли б удалось.
Выводы
1."Черный ящик" – не панацея. Без "Белого ящика" не обойдешься.
2.Если "Белым ящиком" тестирование не организовано, то сажайте тестировщика с отключенным ГМ, снабдите его кофием и еще чем надо – авось дырки в тестах прикроет.
3."Белым ящиком" – тоже не панацея. Поскольку (именно для конкретного этого ящика) структуру софта надо было знать до строчки. Что – нереально!
4.Однозначно – при модульном тестировании – баг был бы отловлен. 100%.
Вопросы знатокам
(очень для меня полезная информация – так что заранее Спасибо!)
1.Какова доля трудозатрат модульного тестирования в знакомых вам проектам? Если все тестирование взять за 100%?
2.С вашей точки зрения – каков вклад модульного тестирования в качество софта?

[MeSaNei]

Есть задача - организовать автоматизированное тестирование.
Занималась раньше автоматизацией GUI, автоматизацией подготовки тестовой среды и проч. С этим более-менее понятно.
Но есть идея (и желание) огранизвать также модульное тестирование (тестирование "белого ящика" или unit testing, как его еще называют).
Вообще везде, где читала, пишут, что модульные тесты разработывают программисты. Включают, мол, отладочные сообщения прямо в код - и все дела. Но я знаю несколько проектов, где модульные тесты разрабатывали специально выделенные для этой задачи тестировщики (т.е. разработчики отдельно кодировали, тестировщики отдельно делали для этого кода unit-тесты). Насколько, я понимаю, код тестов и код продукта были разнесены (да и вообще, тестировать код с отладочными сообщениями, конечно, хорошо, но в итоге получается , что проверяется не такой код, который в итоге будет отправлен заказчику, что рождает определенные риски).

Проект, для которого планируется делать unit-тесты, разрабатывается на C++.
У меня есть некоторый опыт разработки на этом языке, но с чего начать в данном случае и как это организовать (в Visual Studio: отдельным солюшеном, проектом - ?) - не знаю.
Если кто-нибудь поделится идеями и/или опытом в этом вопросе, буду очень признательна!

Здравствуйте,

Для организации Unit тестирования вам понадобится:

1) Знание ООП (прочитайте философию ООП, кажется так книга называется)
2) Знание STL/Boost
3) Классы и всё с этим связанное (полиморфизм(ADT, интерфейс), виды наследования)
4) Знание о том, как целевая система (вы не уточнили для какой архитектуры/ОС приложение) управляет памятью.

После этого, вы поймете как писать Unit тесты. Если у вас нет таких навыков присмотритесь к методике TDD. Методика TDD предоставляет несколько подходов, но все они завязаны на тестах.
В кратце. У разработчика есть задача, Вы, до того как он начнет её реализовывать пишите тестовые сценарии для данной задачи и разработчик на этапе написания кода, подстраивает код так, чтобы проходить тестовые сценарии написанные Вами. Это подход "тест-код-тест".

По написанию Unit тестов есть замечательная книжка "The Art of Unit testing".

Для использования Unit тестов в качестве страховочной сетки для продукта вам в любом случае понадобится помощь разработчиков. Unit тесты это всего лишь инструмент, работайте с людьми и не выступайте в качестве "полиции качества", не нужно говорить программисту что в этом куске он не соблюдает Венгерскую Нотацию или использует не оптимальный контейнер для данных.

Добавлено:

По поводу отладочных сообщений. Я использую GoogleTest для Unit тестов. У нас отдельная конфигурация для проекта на сборочной машине.

[Фрося]

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

Это просто размышления. Полагаю - что спорные.
Модульное тестирование - вещь затратная.
Порою - абсолютно необходимая.

Если Ваше ПО таково, что модульное тестирование необходимость - то скорее всего есть необходимость накладывать ограничения на применение неких конструкций языка программирования. Возможно, нужны ограничения при проектировании ПО.
В этом случае - и венгерскую нотацию придется проверять.

Как пример - Правила Misra.
Оттуда:

"Функции не должны вызывать себя прямо или косвенно".

Т.е. мне кажется, что чтобы модульное тестирование было эффективно, может потребоваться введение органичений в части проекта ПО и использования конструкция языка программирования