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