Конечно, всегда есть больше сценариев для рассмотрения. Откровенно говоря, существует практически неограниченный пул сценариев. Это действительно очень открытый вопрос.
Что касается сценариев злонамеренного хакерства, вам действительно нужно беспокоиться только об очевидных точках переполнения буфера, а затем продолжать тестирование на наличие подтвержденных уязвимостей, чтобы случайно не открыть их снова. И каждый раз, когда вы получаете подтвержденную уязвимость, выслеживаете все места в коде, где используются похожие методы и шаблоны программирования, и также их преимущественное тестирование / исправление. Однако во многих случаях фаззинг даст вам лучшие результаты. Автоматическое тестирование является важной частью решения проблем безопасности, но оно ни в коем случае не должно быть основным инструментом в наборе инструментов.
Другие вопросы, которые следует учитывать, могут быть связаны с конкретными данными. Например, при разборе дат обязательно обрабатывайте такие вещи, как 29.02.2009 или 31.09.2009. Если вы можете, попробуйте разобраться с 01.01.1900 и 31.12.2038 (ваша библиотека может не позволить вам).
Одна вещь, которую вы можете сделать, это проверить документацию для всех библиотечных вызовов, которые вы делаете, выяснить, какие исключения генерируются при каких условиях, и преднамеренно попытаться найти входные данные, которые вызовут эти исключения, а затем убедиться, что вы ' у нас есть тесты, которые подтверждают, что эти исключения либо обработаны, либо, в случае библиотечного кода, задокументированы.
Инструменты покрытия кода и мутация кода также могут помочь вам определить сценарии, которые ранее не освещались.