Комментарии 18
Да и не все ошибки тестами можно выявить. Вот как, например, написать тест вот на такое? Как проверить, что память обнулена?
Так что скорее следует говорить, что разные методологии дополняют друг друга. Но никак о том, что вот этот способ — серебряная пуля.
Но никак о том, что вот этот способ — серебряная пуля.
Как говориться +100500. А то посмотришь иногда на сами тесты, оторопь берет. Вопрос — зачем ты столько времени на это убивал? Чтобы написать заветное «покрытие 99%»?
Как обычно из крайности в крайность, лишь бы «на поезд не опоздать», в тренд попасть.
Ну и PVS-Studio, конечно, вообще молодцы и дело говорят.
Даже в тех местах, которые легко покрываются тестами, платный статический анализатор (если он действительно лучше бесплатного аналога) легко окупится. Написание тестов на каждый branch в коде — занятие утомительное и отнимает кучу времени. Проще поднять покрытие тестами с 60% до 80%, чем с 90% до 95%. Мой опенсорсный проект покрыт на 98.6% по строкам кода, я также заморачивался мутационным тестированием (по PITest показатель около 94%) и знаю, о чём говорю. При этом у меня мегабайт исходников и полмегабайта тестов. И это работа в свободное время для души, поэтому я упоролся. По грубым прикидкам написание тестов заняло треть времени работы над проектом. Готовы ли вы на написание тестов потратить 33% времени разработчиков? Именно разработчиков, а не специально выделенных тестеров, которые за еду работают. Чтобы добиться максимального покрытия, придётся и код частенько рефакторить, это не для тестера работа. Если вы готовы, то скорее всего это вам некуда деньги девать. У продукта должно быть вменяемое соотношение качества и трудозатрат. Если вы не пишете систему управления атомным реактором, то важнее выйти вовремя на рынок, чем выпустить продукт без единой ошибки. Однако в отличие от написания тестов использование статического анализатора вам планку качества поднимет практически нахаляву. В крупном и даже среднем проекте вылавливание тех же багов тестами потребовало бы на порядок больше денежных затрат (при пересчёте из человеко-часов в рубли), чем покупка и использование статического анализатора.
Для интересующихся этой темой, выписал ссылки на примеры реальных ошибок для перечисленных здесь CWE:
- CWE-481: Assigning instead of Comparing: V559
- CWE-482: Comparing instead of Assigning: косвенно найдёт V607 (см. например баг в Boost)
- CWE-571: Expression is always true/CWE-570: Expression is always false: V547, V654, V3063, V637, V3022
Так что все эти проблемы совершенно реальны и портят жизнь программистов.
Эм, а это нормально что вы поддерживаете, цитата "PHP 4/5", а на дворе уже 7.1?
P.S. Дополняя коммент jigpuzzled — Scruinizer абсолютно бесплатный для OpenSource.
Сейчас я дополнил код, теперь он выглядит
bool CheckPointer(int value)
{
int* intPtr(new int(value));
std::cout << std::endl << *intPtr << std::endl;
return true;
}
class A {
int x;
public:
void bar() {
std::cout << x << "Test!\n";
}
};
int main()
{
CheckPointer(5);
A* a;
a->bar();
int adminPassword(123456);
int currentUserPassword(123);
if (currentUserPassword = adminPassword)
{
std::cout << "You are admin";
}
else
{
std::cout << "You are not admin";
}
return 0;
}
P.S. Было бы интересно почитать о том, как именно находить такие дефекты в коде и как устроена иерархия ошибок CWE: сначала ожидал, что анализатор найдет CWE-569, а потом уже понял, что CWE-481 является частным случаем CWE-480, а CWE-480, в свою очередь, дочерний дефект от CWE-569.
Дефект, который у Вас в примере — это CWE-457: "Use of Uninitialized Variable". Подобные дефекты AppChecker обнаруживает в настоящее время для языка PHP. Возьмем к примеру тот же Chamilo LMS, о котором написано в статье. Там есть, например, вот такой код:
$ldapuser = extldap_authenticate($login, 'nopass', true);
if ($ldap_user !== false) {
$chamilo_user = extldap_get_chamilo_user($ldapuser);
..
}Здесь как раз используется неинициализированная переменная — значение присваивается переменной $ldapuser, сравнивается $ldap_user, а потом используется $ldapuser.
Этот дефект разработчики также исправили после того как мы им о нем сообщили.
В настоящее время мы дорабатываем продукт, чтобы находить этот дефект и для C/C++
Описанная проблема ловится сама в совершенно бесплатных Scrutinizer и плагине EA (что на порядок удобнее, т.к. всё видно в самой IDE):
В связи с этим и вопрос, т.к. вы продаёте продукт, протестировать я его не могу (не готов тратить столько времени на регистрацию и ожидание аппрува), да ещё и для устаревших версий php (http://php.net/supported-versions.php), какие вообще у вас конкурентные преимущества?
Конкурентные преимущества AppChecker:
- Осуществляет поиск свыше 100 типов дефектов кодирования.
- Классифицирует потенциально опасные конструкции в соответствии со стандартом CWE.
- Web-интерфейс позволяет проводить совместный аудит кода несколькими экспертами, а высокое качество разбора исходных текстов позволяет снизить число ложных срабатываний.
- Гибкая конфигурация анализируемых проектов позволяет учитывать влияние таких особенностей языков программирования, как например директивы прекомпиляции (в C/C++).
- Интеграция с СУВ и CI
- https://www.exakat.io/ (рекомендую посмотреть — разные анализаторы ловят зачастую разные проблемы)
- https://www.sonarqube.org/ (фокус на code quality)
Не вижу у Exakat возможность указания ветки при запросе ссылки на репу — это вообще возможно?
P.S. Написали мне письмо:
Hello,
We have tried to process the code at ...., but it is too big.
May be you can try a smaller repository? There are too many PHP files. Try keeping 1/4 of the PHP scripts
Получается Exakat вообще не вариант для простеньких сайтиков (это был обычный офф сайтик laravel, там только статьи, да документация, ничего особо серьёзного), я уж не говорю про крупные проекты.
— Это ограничения пробной версии, большие проекты тоже можно проверять. Проект приватный или опенсорсный (может ссылку дадите)?
Могу и ссылку дать https://github.com/LaravelRUS/laravel.ru/tree/feature-laravel-5.4
Обнаружение дефектов кода типа «Expression Issues» (CWE-569)