Lenny

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

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

Сеть, которая учитывает цель тестирования состоит из связей между характеристиками – подцелями и характеристикой – успешностью тестирования. Характеристиками подцелями являются наличие или отсутствие ошибок в приложении. Связи между характеристикой-ошибкой – это ненаправленная связь между двумя двузначными характеристиками и означают наличие или отсутствие данной ошибки сейчас. Если цель тестирования достигнута на 100%, далее по этим связям можно синхронизировать систему по учету дефектов.

Пересчет сети.

Пересчет сети начинается с узла-цели. Цель всего пересчета – определение процента достижения цели. Если цель достигнута полностью, это означает, что приложение соответствует нашим представлениям о нем. Достоинством данного подхода в том, что эта характеристика не означает, что приложение не содержит ошибок. Любая программа, в процессе разработки, как правило, имеет ошибки. Задача тестирования – учет этих ошибок, вот почему характеристика достижения цели одинаково уменьшается при появлении новых ошибок и при исправлении старых. Уменьшение этой характеристики – показатель для тестировщика у него есть работа.

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

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

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

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

Следствия новой архитектуры системы тестирования.

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

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

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

Результат тестирования любой функции программы представлен в виде статистики её запуска, а не разделен по отдельным, не связанным между собой тестам. Появляется возможность сравнивать разные версии приложения через сравнение статистики о работе тестируемых функций. Избыточные средства описания интерфейса обеспечивает надежность тестирования даже при частичном изменении в дизайне интерфейса, или функций программы. Например, некоторая функция программы стала работать иначе, система тестирования способна определить неожиданное состояние приложения и продолжить тестирование, скорректировать дальнейшие операции при условии найденной специфики.

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

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

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

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

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