#testing #command-line #grammar
#тестирование #командная строка #грамматика
Вопрос:
Утилита / программное обеспечение командной строки потенциально может состоять из множества разных переключателей и аргументов.
Допустим, ваше программное обеспечение называется CLI, и, допустим, CLI обладает следующими функциями:
- Общий синтаксис CLI:
CLI <data structures> <operation> <required arguments> [optional arguments] <data structures>может быть'matrix', 'complex numbers', 'int', 'floating point', 'log'<operation>может быть'add', 'subtract', 'multiply', 'divide'- Я не могу придумать никаких обязательных и необязательных аргументов, но допустим, ваше программное обеспечение поддерживает его
Теперь вы хотите протестировать это программное обеспечение. И вы хотите протестировать сам интерфейс, а не логику. По сути, интерфейс должен возвращать правильные коды успеха и коды ошибок.
По сути, многие программы Real Word по-прежнему представляют интерфейс командной строки с несколькими опциями. Мне любопытно, существует ли для этого какая-либо официальная методология тестирования. Одна из моих идей заключалась в том, чтобы создать грамматику (например, EBNF) и описать «язык» интерфейса. Но я не могу продвинуть эту идею вперед. Для чего в этом случае нужна грамматика? Как это позволяет генерировать множество комбинаций.
Мне любопытно узнать больше о любых теоретических моделях, которые могут быть применены к такой проблеме, или если кто-нибудь здесь действительно провел такое тестирование с удовлетворительным охватом
Комментарии:
1. Не отвечая на ваш фактический вопрос, но мне кажется, что требуемые аргументы будут включать фактические значения, к которым вы хотели применить операции — нет смысла говорить «добавить два комплексных числа» без указания фактических чисел 🙂 Необязательными аргументами могут быть выбор алгоритма для быстрого добавления или безопасного-divide — gcc for one позволяет вам указывать атрибуты вычислений с плавающей запятой, чтобы вы могли делать то же самое.
Ответ №1:
В составе продукта, который я поддерживаю, есть инструмент командной строки, и у меня ситуация, очень похожая на то, что вы описываете. Я использовал платформу модульного тестирования и кодировал каждую комбинацию аргументов как метод тестирования.
Программа реализована на c # / .NET, поэтому я использую платформу тестирования Microsoft, встроенную в Visual Studio, но этот подход будет работать с любой платформой модульного тестирования.
Каждый тест вызывает служебную функцию, которая запускает процесс и отправляет входные данные, а затем обрабатывает выходные данные. Затем каждый тест отвечает за проверку того, что выходные данные CLI соответствуют ожидаемым. В некоторых случаях существует семейство тестовых примеров, которые могут быть выполнены одним методом тестирования с циклом for в нем. Логика должна запускать CLI и проверять выходные данные для каждой итерации.
Набор тестов, которые у меня есть, не охватывает все перестановки аргументов, но он охватывает 80% случаев, и я могу добавлять новые тесты, если когда-либо будут какие-либо дефекты.
Комментарии:
1. Итак, в вашем случае генерация комбинации аргументов является статической? «Обнаруживает» ли компоненты, составляющие конкретную команду, то, что она должна запускать, или у вас есть статический список различных комбинаций команд? Также, что произойдет, если инструмент будет перегружен, когда будут добавлены новые команды или добавлены новые коды ошибок? Это требует ручного вмешательства в утилиту тестирования, а также для ее изменения?
2. Я не знаю, что вы подразумеваете под » Обнаруживает ли оно …». Набор тестов создан специально для тестирования инструмента CLI, и поэтому тесты неявно включают знание того, что делает CLI, какие входные данные он принимает. Входные данные не являются статическими — набор тестов использует систему. Случайный класс для генерации входных данных, и он делает это неоднократно. В некоторых случаях он генерирует ввод случайным образом и повторно запускает тесты, пока не будет достигнут некоторый критерий охвата случая. Это не «статический список комбинаций», но это также не 100% покрытие, которое я посчитал непрактичным в моем случае.
3. Что касается изменения CLI и добавления кодов ошибок, после TDD я сначала пишу новые тесты. Я пишу тест, который определяет наборы входных данных и ожидаемых результатов, затем я пишу код для CLI, затем я запускаю тесты.
Ответ №2:
Использование рекурсивной грамматики для генерации переключателей — интересная идея. Если вы хотите попробовать это, вам нужно сначала написать грамматику таким образом, чтобы можно было использовать все переключатели, а затем выполнить случайное прохождение грамматики. Это обеспечивает простой метод случайного обхода грамматики и вывода результата.