Как мне провести модульное тестирование на относительную производительность?

Question

Учитывая, что я не знаю во время развертывания, на каких типах систем будет работать мой код, как мне написать тест производительности, который использует потенциал системы в качестве критерия.

Я имею в виду, что если система способна запускать фрагмент кода 1000 раз в секунду, я бы хотел, чтобы тест показал, что он подходит как можно ближе к 1000. Если это может сделать только 500, то это скорость, с которой я бы хотел сравнить.

Если это поможет сделать ответ более конкретным, я использую JUnit4.

Спасибо.

Answer 1

Я бы не стал использовать модульное тестирование для тестирования производительности по нескольким причинам.

Во-первых, модульные тесты не должны иметь зависимостей от окружающей системы / кода. Тесты производительности сильно зависят от аппаратного обеспечения / ОС, поэтому трудно получить единые показатели, которые можно будет использовать как на рабочих станциях разработчиков, так и на сервере сборки и т. Д.

Во-вторых, модульные тесты должны выполняться очень быстро. Когда вы выполняете тесты производительности, вы обычно хотите иметь достаточно большие наборы данных и повторять количество прогонов пару раз в среднем порядке / избавиться от накладных расходов и так далее. Все это работает против идеи быстрых тестов.

Answer 2

Тест означает, что у вас есть порог прохождения / неудачи. Для теста производительности это значит слишком медленно, и вы терпите неудачу, достаточно быстро, и вы проходите. Если вы терпите неудачу, вы начинаете делать переделки.

Если вы не можете потерпеть неудачу, значит, вы тестируете, а не тестируете.

Когда вы говорите о «система способна работать», вы должны определить «способна». Вы можете использовать любой из множества тестов производительности оборудования. Брусок, Dhrystone и др., Популярны. Или, может быть, у вас приложение, интенсивно использующее базу данных, тогда вы можете посмотреть на эталонный тест TPC. Или, возможно, у вас есть приложение, интенсивно использующее сеть, и вы хотите использовать netperf. Или приложение с интенсивным графическим интерфейсом и хотите использовать какой-нибудь графический тест.

Любой из них дает вам какое-то измерение "возможностей". Выберите один или несколько. Они все хороши. Не менее спорным. Одинаково предвзято относится к вашему конкуренту и от вас.

Как только вы запустите тестирование, вы сможете запустить свое программное обеспечение и посмотреть, что на самом деле делает система.

Вы можете - если соберете достаточно данных - установить некоторую корреляцию между некоторыми показателями производительности и показателями производительности. Вы увидите все виды изменений в зависимости от рабочей нагрузки, конфигурации оборудования, версии ОС, виртуальной машины, сервера БД и т. Д.

Имея достаточно данных из достаточного количества ящиков с достаточным количеством различных конфигураций, вы в конечном итоге сможете разработать модель производительности, которая говорит: «учитывая это оборудование, программное обеспечение, параметры настройки и конфигурацию, я ожидаю, что мое программное обеспечение будет выполнять [X] транзакций в секунду «. Это твердое определение «способный».

Получив эту модель, вы можете сравнить ее программное обеспечение с номером возможности. Пока у вас нет очень полной модели, вы на самом деле не знаете, какие системы способны даже выполнять фрагмент кода 1000 раз в секунду.

Answer 3

Я согласен с Брайаном , когда он говорит, что модульные тесты не являются подходящим способом для тестирования производительности . Однако я собрал короткий пример, который можно использовать в качестве интеграционного теста для запуска в разных конфигурациях / средах системы.
Обратите внимание, что это просто для того, чтобы дать представление о том, что можно сделать в этом отношении. и не предоставляет результатов, которые являются достаточно точными, чтобы подкрепить какое-либо официальное заявление о производительности системы.

import static org.junit.Assert.*;
import org.junit.Test;

package com.stackoverflow.samples.tests {

    @Test
    public void doStuffRuns500TimesPerSecond() {
        long maximumRunningTime = 1000;
        long currentRunningTime = 0;
        int iterations = 0;

        do {
            long startTime = System.getTimeMillis();

            // do stuff

            currentRunningTime += System.getTimeMillis() - startTime;
            iterations++;
        }
        while (currentRunningTime <= maximumRunningTime);

        assertEquals(500, iterations);
    }
}

Answer 4

Я провожу некоторые измерения времени на тестах для кода, предназначенного для системы реального времени, где правильный ответ, вычисление которого занимает слишком много времени, является ошибкой.

Все, что я делаю, это строю график времени дельта процессора, который тест взял на себя за последние сборки. Обратите внимание, процессорное время не в реальном времени. Фактическое значение не имеет большого значения - важно то, насколько оно изменилось.

Если я фиксирую изменение в алгоритме, который значительно изменил время выполнения теста, я могу легко увеличить конкретный набор изменений, вызвавший его. Что меня действительно волнует, так это эти достопримечательности, а не абсолютные значения. В системе реального времени довольно часто бывает много компромиссов, и они не всегда могут быть представлены в тестовой среде как простое сравнение.

Рассмотрение абсолютного времени и его нормализация на первый взгляд кажется разумным, но на самом деле преобразование между вашей системой и целевой системой будет нелинейным - например, давление в кэш-памяти, использование подкачки, скорость диска в целевой системе и т. Д. Могут вызвать время взрыва теста на другом пороге, чем у вашей системы.

Если вам абсолютно необходим тест, точный в этом отношении, продублируйте целевую систему и используйте ее в качестве ведомого, но в похожей среде, как вы ожидаете.

В моем случае это может быть загрузка микропрограммы в DSP, ее повторное включение, чтение ответа с последовательного порта или отсутствие ответа из-за сбоя!

- jeffk ++