Lenny

Кто виноват?

Целью тестирования является определение неисправностей в программе. Для того, что бы организовать тестирование, необходимы шаблоны правильной или неправильной работы тестируемой программы. Несоответствие тестируемой программы шаблону это факт неисправности программы. Однако, в случае автоматизации тестирования, неисправными могут быть как тестируемое приложение, так и сама система тестирования. Главным источником неправильной работы тестирующей системы является изменение требований к программе. Встает вопрос, какими должны быть шаблоны для самотестирования системы тестирования и как их получить. К сожалению, не существует универсальных средств для тестирования тестирующей системы на соответствие новым требованиям. Эта задача может быть решена или при помощи анализа тестов вручную или если тесты для системы тестирования будут генерироваться из требований автоматически. 

Используя вероятностно-сетевое программирование можно описывать работу тестируемого приложения в виде отдельных требований-связей объединенных в сеть. Алгоритм пересчета вероятностных сетей может самостоятельно протестировать приложение, порождая тесты, руководствуясь этой сетью. Результатом должно быть вычисление вероятности для каждого требования, что приложение соответствует этому требованию. В процессе работы алгоритм вычисляет несоответствие тестируемого приложения требованиям уменьшая вероятность шаблона. Если шаблон состоит из одного требования, то уменьшая вероятность, что приложение соответствует шаблону алгоритм или уменьшает вероятность, что приложение соответствует требованию. Если шаблон состоит из логической цепочки требований, то алгоритм уменьшает вероятности равномерно для каждого из требований в цепочке. Если цепочка требований содержит цикл, то есть является графом,  то алгоритм строит деревья, исключая связи из этого графа. Таким образом, используя исключение требований для циклов и распределяя вероятности ошибки между всеми требованиями в цепочках, алгоритм находит вероятности, что приложение соответствует этим требованиям.

Что делать?

Вторая задача для тестирования является поиск последовательности действий для тестирования. При ручном тестировании эти операции могут быть не описаны или описаны нечетко, при автоматизации тестов эти шаги необходимо описать на языке программирования. Обычно последовательность подготовительных шагов превышает количество шагов для проверки. Это вынуждает программистов объединять тесты. Однако объединение тестов уменьшает качество тестирования при наличии дефектов в программе. Кроме того, при наличии дефектов в навигации программист должен, для увеличения стабильности тестирования, предусмотреть альтернативные шаги, что увеличивает затраты на разработку тестов и, как правило, не выполняется.

Используя вероятностно-сетевое программирование, программист может не описывать последовательность шагов четко. Последовательность шагов неразрывно связана с последовательностью состояний, в которые эти шаги приводят. Программист может указать промежуточные состояния, которые необходимо достичь для выполнения теста. Также он может указать стоит ли искать другие пути до следующего промежуточного состояния, если невозможно достичь текущего. Поиск пути между состояниями можно выполнить при помощи любого алгоритма для поиска пути в сети. Алгоритм может искать минимальный по времени путь в сети при условии, что для каждого шага, для каждой операции известно время её выполнения. От алгоритма требуется оптимальное соотношение времени его работы к качеству генерируемого им пути. Систему тестирования устроит путь, достаточно близкий к оптимальному. В работе предлагается использовать для этого “жадный” алгоритм поиска пути в ширину. Необходим алгоритм поиска в ширину для того, что бы, сперва, убедиться, есть ли прямая связь между текущим состоянием и целевым.