Метод сравнения во время выполнения объектов двух программ
Я работаю над определенным типом тестирования кода, которое довольно неприятно и может быть автоматизировано, но я не уверен в лучших практиках. Прежде чем описывать проблему, я хочу пояснить, что я ищу соответствующую терминологию и понятия, чтобы я мог прочитать больше о том, как ее реализовать. Конечно, приветствуются предложения о лучших практиках, но моя цель конкретна: как называется такой подход?
В простейшем случае у меня есть две программы, которые собирают кучу данных, создают различные промежуточные объекты и затем возвращают окончательный результат. При сквозном тестировании конечные результаты отличаются, поэтому необходимо выяснить, где эти различия возникают. К сожалению, даже промежуточные результаты могут отличаться, но не всегда в значительной степени (то есть некоторые расхождения допустимы). Последний недостаток заключается в том, что промежуточные объекты могут не обязательно иметь одинаковые имена между двумя программами, а два набора промежуточных объектов могут не полностью перекрываться (например, одна программа может иметь больше промежуточных объектов, чем другая). Таким образом, я не могу предположить, что между объектами, созданными в двух программах, существует взаимно-однозначное отношение.
Подход, который я собираюсь использовать для автоматизации этого сравнения объектов, заключается в следующем (он примерно основан на подсчете частот в текстовом корпусе):
- Для каждой программы A и B: создайте список объектов, созданных в процессе выполнения, который можно очень просто проиндексировать, например, a001, a002, a003, a004, ... и аналогично для B (b001, ...).
- Пусть Na = # уникальных имен объектов, встречающихся в A, аналогично для Nb и # объектов в B.
- Создайте две таблицы, TableA и TableB, со столбцами Na и Nb соответственно. Записи будут записывать значение для каждого объекта в каждом триггере (т.е. для каждой строки, определенной следующим).
- Для каждого назначения в A самый простой подход состоит в том, чтобы захватить значение хеш-функции всех элементов Na; конечно, можно использовать LOCF (последнее перенесенное наблюдение) для тех элементов, которые не меняются, и любые пока еще ненаблюдаемые объекты просто получают NULL-запись. Повторите это для Б.
- Сопоставьте записи в TableA и TableB через их хэш-значения. В идеале, объекты будут поступать в "словарь" примерно в одном и том же порядке, так что порядок и значение хеша позволят идентифицировать последовательности значений.
- Найти расхождения в объектах между A и B на основе того, когда последовательности значений хеш-функции расходятся для любых объектов с расходящимися последовательностями.
Теперь это простой подход, и он мог бы работать замечательно, если бы данные были простыми, атомарными и не были подвержены проблемам числовой точности. Тем не менее, я считаю, что числовая точность может привести к расхождению значений хеш-функции, хотя влияние будет незначительным, если расхождения будут примерно на уровне допуска машины.
Во-первых: как называются такие типы методов и концепций тестирования? Ответ не обязательно должен быть описанным выше методом, но отражает класс методов для сравнения объектов из двух (или более) разных программ.
Второе: Какие существуют стандартные методы для того, что я описал в шагах 3 и 4? Например, "значение" должно быть не только хешем: можно также хранить размеры объектов - в конце концов, два объекта не могут быть одинаковыми, если они сильно различаются по размеру.
На практике я склонен сравнивать небольшое количество элементов, но я подозреваю, что при автоматизации это не требует большого количества ввода от пользователя.
Редактировать 1: Этот документ связан с точки зрения сравнения следов выполнения; в нем упоминается "сравнение кода", что связано с моими интересами, хотя меня интересуют данные (то есть объекты), а не реальный код, который создает объекты. Я только что просмотрел его, но рассмотрю его более тщательно для методологии. Что еще более важно, это говорит о том, что сравнение трассировок кода может быть распространено на сравнение трассировок данных. В этой статье анализируются некоторые сравнения следов кода, хотя и в совершенно не связанной области тестирования безопасности.
Возможно, методы отслеживания данных и трассировки стека связаны. Контрольная точка немного связана, но ее типичное использование (т.е. сохранение всего состояния) излишне.
Редактировать 2: Другие связанные концепции включают в себя дифференциальный программный анализ и мониторинг удаленных систем (например, космических зондов), где кто-то пытается воспроизвести расчеты с использованием локальной реализации, обычно клона (вспомните HAL-9000 по сравнению с его клонами, привязанными к земле), Я просмотрел маршруты модульного тестирования, реверс-инжиниринга, различных видов криминалистики и еще много чего. На этапе разработки можно было бы обеспечить согласие с модульными тестами, но это не кажется полезным для инструментального анализа. Для обратного инжиниринга целью может быть согласование кода и данных, но методы оценки точности переработанного кода не кажутся особенно легкими для поиска. Криминалистику для каждой программы найти очень легко, но сравнение между программами, похоже, не так уж часто.
1 ответ
(Создание этого ответа в вики сообщества, потому что программирование потока данных и реактивное программирование не мои области знаний.)
Область программирования потока данных, кажется, связана, и, таким образом, отладка программ потока данных может быть полезна. Эта статья 1981 года дает несколько полезных идей высокого уровня. Хотя это трудно перевести на непосредственно применимый код, он предлагает метод, который я упустил из виду: при подходе к программе в качестве потока данных можно статически или динамически определить, где изменения входных значений вызывают изменения других значений в промежуточной обработке. или в выходных данных (не только изменениях в исполнении, если нужно проверить поток управления).
Хотя программирование потока данных часто связано с параллельными или распределенными вычислениями, похоже, что оно согласуется с реактивным программированием, которое позволяет осуществлять мониторинг объектов (например, хеширование).
Этот ответ далек от адекватности, отсюда и тэг CW, так как он не называет метод отладки, который я описал. Возможно, это форма отладки для парадигмы реактивного программирования.
[Также обратите внимание: хотя этот ответ - CW, если у кого-то есть намного лучший ответ относительно потока данных или реактивного программирования, пожалуйста, не стесняйтесь опубликовать отдельный ответ, и я удалю этот.]
Примечание 1: У Хенрика Нильссона и Питера Фрицсона есть ряд статей об отладке для ленивых функциональных языков, которые в некоторой степени связаны: цель отладки состоит в оценке значений, а не в выполнении кода. Эта статья, кажется, имеет несколько хороших идей, и их работа частично вдохновила эту статью на отладчик для реактивного языка программирования под названием Luster. Эти ссылки не отвечают на первоначальный вопрос, но могут быть интересны всем, кто сталкивается с такой же проблемой, хотя и в другом контексте программирования.