494 / 376 / 136
Регистрация: 27.01.2015
Сообщений: 1,588
1

Тестирование программы С++

01.11.2015, 22:24. Показов 6731. Ответов 8
Метки нет (Все метки)

Какие есть программы что бы проверить код на утечку памяти , мусор и другие сюрпризы?

Спасибо!
0
Programming
Эксперт
94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
01.11.2015, 22:24
Ответы с готовыми решениями:

Тестирование потоками данных программы в C++
Как это реализовать? где можно почитать

Тестирование
В литературе по программированию большинство (если не все) авторов указывают на важность проведения...

Unit - тестирование
Есть ли на C03++ стандарте что-то, помогающее в этом? И как это самое использовать? Ну или...

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

8
2548 / 1207 / 358
Регистрация: 30.11.2013
Сообщений: 3,826
01.11.2015, 22:29 2
Цитата Сообщение от _Valera_ Посмотреть сообщение
проверить код на утечку памяти
Visual Studio 2015
Цитата Сообщение от _Valera_ Посмотреть сообщение
мусор
Нефиг гавнокодить Ну и статический анализатор вон готовит Майерс и КО
Цитата Сообщение от _Valera_ Посмотреть сообщение
другие сюрпризы
тут нужны тестеры
1
494 / 376 / 136
Регистрация: 27.01.2015
Сообщений: 1,588
01.11.2015, 22:30  [ТС] 3
Цитата Сообщение от rikimaru2013 Посмотреть сообщение
Visual Studio 2015
не могу, нужно выполнять на 13...

Цитата Сообщение от rikimaru2013 Посмотреть сообщение
тут нужны тестеры
да, но программист же тоже должен как то протестить...
0
2548 / 1207 / 358
Регистрация: 30.11.2013
Сообщений: 3,826
01.11.2015, 22:37 4
Цитата Сообщение от _Valera_ Посмотреть сообщение
тоже должен как то протестить...
Программисты проверяют работает ли если ити от точки А к точки Б напрямую. Все другие пути: это долго и рутино, и явно лучше использовать силу подешевле.

К тому же существуют С++ тесты - вот сейчас сяду читать как их писать. Писал для C#:
- вся их суть. Вы пишите класс, к примеру, дробь и пишите что-то типа:
C++
1
2
3
4
5
6
7
8
9
void test1_toFloatMethod()
{
Fraction a(3, 4);
double temp = a.toFloat();
double expected = 0.75;
Equals(temp, expected);
}
void test2_toFractionMethod()
{}
И таких тестов на разные случаи. Сегодня они прошлись, через неделю дописывания кода и движка - кто-то да не пройдется и надо искать причину. Но это в идеальном мире - на практики, программисты леньтяи.
1
494 / 376 / 136
Регистрация: 27.01.2015
Сообщений: 1,588
01.11.2015, 22:41  [ТС] 5
Цитата Сообщение от rikimaru2013 Посмотреть сообщение
программисты леньтяи
+

Да просто пишу сейчас на cocos2dx - там все на указателях, и память вроде как сама потом убирается, но хотелось бы быть уверены что это так, вот и ищу как проверить потери памяти!
0
541 / 162 / 79
Регистрация: 23.09.2013
Сообщений: 316
01.11.2015, 22:48 6
Лучший ответ Сообщение было отмечено _Valera_ как решение

Решение

_Valera_, На предмет ошибок работы с памятью и потоками, Вам в помощь - valgrind, как не интрузивное средство, а так же address-sanitizer, memory-sanitizer, thread-sanitizer - как интрузивное. Наконец используйте юнит тестирование, отделяйте бизнес логику от вызовов библиотек и проверяйте её в изоляции. Статические анализаторы так же могут дать представление о возможных косяках в коде. Наконец - opensource - тоже неплохой способ проверить код. Чем больше глаз видит Ваше детище, тем больше багов будет найдено.
1
Ушел с форума
Эксперт С++
16448 / 7412 / 1186
Регистрация: 02.05.2013
Сообщений: 11,617
Записей в блоге: 1
02.11.2015, 00:08 7
Лучший ответ Сообщение было отмечено _Valera_ как решение

Решение

Цитата Сообщение от _Valera_ Посмотреть сообщение
Какие есть программы что бы проверить код на утечку памяти , мусор и другие сюрпризы?
Таких инструментов достаточно немало, каждый со своей особой "кухней".
Детально расписывать не буду, просто накидаю из того, чем сам пользуюсь а
ты решай по каждому пункту, нужен ли он тебе или нет.

1. Проверять код следует на конфигурации Debug, т.к. компилятор вставляет в
нее большее количество проверок и меньше вероятность "прозевать" ошибку,
связанную с управлением памятью.

2. Тестировать лучше на Vista и выше, потому что встроенные механизмы работы с
кучей на этих версиях более чувствительны к ошибкам типа переполнения буфера.
Я рекомендую использовать для тестов как минимум Windows 8 (почему - см. ниже).

3. Использовать Application Verifier.

Application Verifier
https://msdn.microsoft.com/en-... s.90).aspx

Инструмент от Microsoft. Позволяет находить дефекты во время выполнения программы,
например, неправильное использование Win32 API функций, утечки, работа с
невалидными дескрипторами и т.п.

4. Использовать SAL Annotations и встроенный в Visual Studio статический анализатор.

SAL Annotations
https://msdn.microsoft.com/en-... 35402.aspx

Analyzing C/C++ Code Quality by Using Code Analysis
https://msdn.microsoft.com/en-... 82025.aspx

5. Всегда компилировать код с опцией /W4 (выдавать все предупреждения).

Появляющиеся предупреждения в своем коде не подавлять (#pragma warning: disable), а
разбираться с ними.

6. Компилировать код в режиме x64 (всплывают другие ошибки, как правило,
связанные с усечением типов).

7. Использовать отладочную кучу (debug heap).

Поиск ошибок при работе с памятью
https://rsdn.ru/article/vcpp/vcdebug-5.xml

8. Использовать специальные аллокаторы для отслеживания утечек и других дефектов.

Ссылок не привожу, таких аллокаторов полно на каждом углу.

9. Использовать VirtualAlloc/VirtualProtect с искусственно созданным "заграждением".

Отличное средство находить дефекты при работе с буферами.
Суть: выделяете память под буфер с помощью VirtualAlloc, причем так, чтобы сразу за
концом буфера начиналась следующая страница памяти (размер = 4096 байт).
Далее VirtualProtect-ом ставите на эту дополнительную страницу атрибут PAGE_NOACCESS.
Все, теперь если код попытается выйти за пределы буфера хотя бы на один байт, даже просто
на чтение, то немедленно будет выброшено исключение access violation (0xC0000005).
Разумеется, заграждение можно ставить не только за концом буфера, но и с другой стороны.
Дополнительно можно поставить на сам буфер атрибут PAGE_READONLY если, к примеру,
известно, что он используется только на чтение.

10. Запускать тестируемый процесс со специальными ограничениями (Windows 8 и выше).

Есть такая функция:

UpdateProcThreadAttribute
https://msdn.microsoft.com/en-... s.85).aspx

Интересующие опции:

PROCESS_CREATION_MITIGATION_POLICY_HEAP_TERMINATE_ALWAYS_ON

Позволяет более резко реагировать на повреждение кучи.

PROCESS_CREATION_MITIGATION_POLICY_STRICT_HANDLE_CHECKS_ALWA YS_ON

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

Можно написать свой test runner, который будет запускать подопытный процесс с
данными флагами, тем самым заставляя его реагировать более жестко на возможные
ошибки данного класса.

11. Применять fuzzing.

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

Есть инструменты типа Microsoft CHESS, LibFuzzer, dfuzz, и другие.

12. Использовать assert-ы, как в compile time, так и в runtime.

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

13. Использовать Global Flags (WinDBG).

GFlags
https://msdn.microsoft.com/en-... s.85).aspx

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

14. Конечно же, писать тесты.

Юнит-тесты, функциональные тесты, стресс-тесты, интеграционные тесты,
тесты совместимости и т.д.

Не могу здесь не порекомендовать Boost.Test и google test / google mock.

15. Проектировать свой софт и писать свой код по принципу "design by contract".

Design by contract
https://en.wikipedia.org/wiki/Design_by_contract

Суть данной идеологии: проектирование на основе "контрактов" между компонентами.
Как только один из компонентов нарушает контракт, приложение останавливает
свою работу и выдает соответствующее сообщение об ошибке.
Каких-либо попыток "угадать, что имел в виду" сбойный компонент, подстроиться под
изменение протокола и продолжить работу и т.п. не предпринимается, реакция на
любой сбой в системе, даже малейший, должна быть максимально резкой.

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

Понимание этой простой, на вид, идеологии, является очень трудным и приходит с опытом.

16. Использовать сторонние инструменты для статического и динамического анализа.

PVS-Studio
CppDepend
ClocWork
Coverity
Intel Inspector
Relacy Race Detector

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

17. Как средство значительно снизить вероятность появления утечек хорошо помогает RAII.
Все ресурсы (не только память, но и, например, пары функций типа open/close) оборачиваются в
классы-обертки и далее работа ведется только через них. Простой пример - std::string и
std::vector как полная замена строковым функциям и работе с "сырыми" буферами.
Накосячить со сложением строк в std::string гораздо труднее, чем с strcpy/cat.

--------

Все это лишь частные меры, которые дают скромный результат по отдельности, но могут
существенно помочь, когда используются в комплексе. Да, и плохой код, написанный
"размазанно" и архитектурно неграмотно, никакие средства не спасут.
5
494 / 376 / 136
Регистрация: 27.01.2015
Сообщений: 1,588
02.11.2015, 01:02  [ТС] 8
Убежденный, спасибо.
0
1384 / 1015 / 322
Регистрация: 28.07.2012
Сообщений: 2,801
02.11.2015, 02:56 9
_Valera_, я уже давно использую Intel Parallel.
Есть версия под Win, Linux, OSX.
Inspector помогает определить утечки памяти и ошибки доступа к ней.
VTune позволяет анализировать производительность программы.
Все это добро можно получить бесплатно, являясь студентов, либо украсть.
1
IT_Exp
Эксперт
87844 / 49110 / 22898
Регистрация: 17.06.2006
Сообщений: 92,604
02.11.2015, 02:56
Помогаю со студенческими работами здесь

Юнит-тестирование
Всем доброго времени суток! В последнее время меня начал сильно интересовать вопрос о...

Тестирование Hello World
Вот попалась задачка. Новая для меня. Хотелось бы разобраться, но пока не могу понять с чего...

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

Модульное тестирование c++
Здравствуйте. Подскажите, пожалуйста, документацию или пример по написанию таких тестов. Сам...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
9
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin
Copyright ©2000 - 2022, CyberForum.ru