Обзор

Эта памятка по инструменту содержит обзор четырех основных задач полнофункционального тестирования, выполняемых Rational QualityArchitect:

• Полнофункциональное тестирование
• Тестирование сценариев
• Создание заготовок
• Запись сеансов EJB

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

Даже при наличии у команды разработчиков крепкой уверенности в качестве компонентов системы, общая уверенность в работоспособности целой системы может оказаться неприемлемо низкой. Например, рассмотрим простую систему из пяти компонентов, каждый из которых надежен на 95% (исходя из показателей прогона кода или прочих источников). Так как надежность системы является накопительной, общий коэффициент составит 95% x 95% x 95% x 95%x 95%, то есть чуть более 77%. Таким образом, вероятность возникновения неполадки в одном компоненте составляет 1 к 20, тогда как для системы в сборе она повышается до 1 к 4, и это система с относительно малым числом компонентов.

В свою очередь процесс с тестированием компонентов на стадии итеративной разработки обладает несколькими преимуществами:

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

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

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

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

Эта памятка по инструменту применима для систем с Windows 98/2000/NT 4.0.

Этапы работы с инструментами

В этой памятке по инструменту описаны следующие основные задачи, связанные с реализацией автоматического тестирования компонентов с помощью QualityArchitect:

1. Предварительные действия для полнофункционального тестирования
2. Реализация полнофункционального тестирования
3. Реализация теста сценария
4. Создание компонента заготовки
5. Применение регистратора сеанса EJB

1.   Предварительные шаги для полнофункционального тестирования

Для создания тестов с помощью QualityArchitect, для компонентов COM или EJB, следует создать проект Rational и на строить его с помощью Rational Administrator. Этот проект должен содержать хранилище данных тестов для хранения всех тестовых ресурсов, таких как результаты тестирования и пулы данных. Это описано в Памятке по инструменту: настройка проектов с помощью Rational Administrator.

2.   Реализация полнофункционального тестирования

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

• Создание кода полнофункционального тестирования
• Создание данных полнофункционального тестирования
• Выполнение теста и изучение результатов

Создание кода полнофункционального тестирования

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

Для компонентов COM

1. Выберите тестируемые операции в интерфейсе компонента в логическом виде.
2. Щелкните правой кнопкой мыши на операции, указанной в интерфейсе компонента и выберите Rational Test > Создать полнофункциональное тестирование. При появлении запроса в ходе этого процесса может потребоваться войти в Rational Project.

QualityArchitect создает совместимый с Visual Basic 6 код в качестве вывода процесса.

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

Для компонентов EJB

1. Выберите тестируемую операцию из удаленного интерфейса в логическом виде.
2. Щелкните правой кнопкой мыши на операции и выберите Rational Test > Выбрать шаблон полнофункционального тестирования.
3. Перейдите к соответствующему шаблону для сервера EJB. Для WebSphere выберите websphere_remote.template в папке методов EJBWebSphereBusiness. Для Web Logic выберите weblogic_remote.template в папке методов EJBWeb.
4. Выберите Rational Test > Создать полнофункциональное тестирование. При появлении в ходе этого процесса приглашений вам может понадобиться войти в Rational Project.  

QualityArchitect сгенерирует код Java в качестве вывода этого процесса.

Для изучения кода Java можно воспользоваться IDE или редактором. Rational Rose поставляется с редактором R2, который можно использовать для этой цели.

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

Создание данных полнофункционального тестирования

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

Для компонентов COM

1. Выберите тестируемую операцию в интерфейсе компонента в логическом виде.
2. Щелкните правой кнопкой на операции и выберите Rational Test > Создать пул данных.
3. Выбрав опцию Создать пул данных вы увидите окно Свойства пула данных. В это время можно выбрать пункт Изменить данные пула данных для начала ввода данных или выбрать пункт Задать поля пула данных чтобы QualityArchitect сгенерировал данные теста за вас.

Для компонентов EJB

1. Выберите тестируемую операцию из удаленного интерфейса в логическом виде.
2. Щелкните правой кнопкой мыши на операцию, показанную в удаленном интерфейсе, и выберите Rational Test > Создать пул данных.
3. Выбрав опцию Создать пул данных вы увидите окно Свойства пула данных. В это время можно выбрать пункт Изменить данные пула данных для начала ввода данных или выбрать пункт Задать поля пула данных чтобы QualityArchitect сгенерировал данные теста за вас.

Работа с пулами данных

Если выбрать Задать поля пула данных вы сможете воспользоваться функциями создания данных теста QualityArchitect. QualityArchitect может генерировать различные типы общих данных, указанных в выпадающем списке типов данных в поле Тип.  

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

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

Выполнение теста и изучение результатов

Создав тестовый код и тестовые данные вы готовы к запуску теста. Выполнить тест можно из IDE или запланировать его в комплекте TestManager. См. Памятка по инструменту: выполнение тестового комплекта с помощью Rational TestManager для получения более подробных сведений по этому вопросу.

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

3.   Реализация теста сценария

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

• Создание кода тестирования сценария
• Создание данных тестирования сценария
• Выполнение теста и изучение результатов

Создание кода тестирования сценария

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

Для компонентов EJB

1. Выберите в браузере диаграмму кооперации.
2. Щелкните правой кнопкой мыши на диаграмме и выберите Rational Test > Выбрать шаблон ScenarioTest.
3. Перейдите к соответствующему шаблону для сервера EJB. Для WebSphere выберите websphere_{_}scenario.template в папке EJBWebSphereScenario. Для Web Logic выберите weblogic_scenario.template в папке EJBWeb.
4. Откройте данную диаграмму последовательностей или кооперации, моделирующей тестируемый сценарий. Важно чтобы сообщения для компонентов были указаны для компонентов тестируемой диаграммы. Для указания сообщения дважды щелкните на линии сообщений и задайте имя в выпадающем списке на вкладке Общие. Имя должно соответствовать тестируемой операции. Более того, эти спецификации можно изменить для добавления данных тестового сценария.
   
   Например, по умолчанию Rose будет обрабатывать спецификацию сообщения как:
   getTransactions(ИДзаказчика : String)
   
   Эту спецификацию можно изменить для добавления одного тестового сценария следующим образом:
   getTransactions(ИДзаказчика : String="BBryson")
   
   Для каждого теста сценария QualityArchitect автоматически создает пул данных для данных тестового сценария. Данные на диаграмме будут заполнены в первой строке. На этом этапе можно добавить дополнительные строки.
5. Для начала теста щелкните правой кнопкой на диаграмме в браузере и выберите Rational Test > Создать тест сценария. При появлении приглашения войти в проект, сделайте это.  
6. Появится диалоговое окно с приглашением выбрать цели тестирования сценария. Выберите все компоненты диаграммы, принимающие участие в тесте. Для каждого выбранного компонента будет вызвана соответствующая операция, указанная в сообщении компонента.  

Для компонентов COM

1. Откройте данную диаграмму последовательностей или кооперации, моделирующей тестируемый сценарий. Важно чтобы сообщения для компонентов были указаны для компонентов тестируемой диаграммы. Для указания сообщения дважды щелкните на линии сообщений и задайте имя в выпадающем списке на вкладке Общие. Имя должно соответствовать тестируемой операции. Более того, эти спецификации можно изменить для добавления данных тестового сценария.
   
   Например, по умолчанию Rose будет обрабатывать спецификацию сообщения как:
   getTransactions(ИДзаказчика : String)
   
   Эту спецификацию можно изменить для добавления одного тестового сценария следующим образом:
   getTransactions(ИДзаказчика : String="BBryson")
   
   Для каждого теста сценария QualityArchitect автоматически создает пул данных для данных тестового сценария. Данные на диаграмме будут заполнены в первой строке. На этом этапе можно добавить дополнительные строки.
2. Для начала теста щелкните правой кнопкой на диаграмме в браузере и выберите Rational Test > Создать тест сценария. При появлении приглашения войти в проект, сделайте это.  
3. Появится диалоговое окно с приглашением выбрать цели тестирования сценария. Выберите все компоненты диаграммы, принимающие участие в тесте. Для каждого выбранного компонента будет вызвана соответствующая операция, указанная в сообщении компонента.  

Точки проверки

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

 Можно реализовать собственный точки проверки с помощью действий, описанных в электронной справке QualityArchitect.

1. Выберите Да для вставки точки проверки.
2. Выберите подходящий тип точки проверки для вставки. Если вы не используете собственные точки проверки, необходимо выбрать VP базы данных.
3. Откроется конструктор запросов, с помощью которого можно установить параметры соединения с базой данных и создать запрос, исполняемый для проверки верного функционирования вызываемых операций. Для установки этого соединения и создания запроса необходимы базовые знания о структуре базы данных и знакомство с синтаксисом SQL.

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

Создание данных тестирования сценария

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

Для просмотра и изменения этой информации выполните следующие действия:

1. В Rose выберите Инструменты > Rational Test > Панель инструментов.
2. На панели инструментов выберите второй элемент панели инструментов для редактирования пула данных. QualityArchitect создаст пул данных, содержащий имя диаграммы сценариев, заканчивающееся на _D. Алгоритм, использованный для присвоения имени пулу данных, является довольно сложным что затрудняет возможность предсказания имен пулов данных в данной документации.

Для изменения этих данных выполните те же базовые действия, что и описаны в разделе Работа с пулами данных.

Выполнение теста и изучение результатов

Создав тестовый код и тестовые данные вы готовы к запуску теста. Выполнить тест можно из IDE или запланировать его в комплекте TestManager. См. Памятка по инструменту: выполнение тестового комплекта с помощью Rational TestManager для получения более подробных сведений по этому вопросу.

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

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

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

4.   Создайте компонент заготовки

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

QualityArchitect может легко создать заготовки для компонентов COM и EJB. Эти заготовки полагаются на таблицы поиска для копирования бизнес-логики заменяемых ими компонентов. Таблица, реализующая пул данных, определяет каким должно быть возвращаемое значение для заданного набора вводов.

Процесс создания и развертывания заготовки состоит из следующих трех этапов:

• Создание компонента заготовки
• Создание таблицы поиска заготовки
• Развертывание заготовки

Создание компонента заготовки

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

Для компонентов Com

1. Выберите интерфейс компонента в логическом виде.
2. Щелкните правой кнопкой мыши на интерфейсе и выберите Rational Test > Создать заготовку. Появится предложение указать расположение для кода новой заготовки. Выберите расположение, после чего код будет сгенерирован.

Для компонентов EJB

1. Выберите класс реализации объекта в логическом виде.  
2. Щелкните правой кнопкой мыши на классе и выберите Rational Test > Создать заготовку. Появится предложение указать расположение для кода новой заготовки. Выберите расположение, после чего код будет сгенерирован.

Создание таблицы поиска заготовки

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

Для компонентов Com

1. Выберите операцию в интерфейсе компонента в логическом виде.
2. Щелкните правой кнопкой мыши на интерфейсе и выберите Rational Test > Создать таблицу поиска. Появится диалоговое окно Свойства пула данных.
3. Для создания этой таблицы поиска выполните те же базовые действия, что и описаны в разделе Работа с пулами данных. С помощью таблицы можно указать значения или исключения для возврата на определенный набор аргументов.

Для компонентов EJB

1. Выберите операцию из класса реализации объекта в логическом виде.  
2. Щелкните правой кнопкой на классе и выберите  
3. Rational Test > Создать таблицу поиска. Появится диалоговое окно Свойства пула данных.
4. Для создания этой таблицы поиска выполните те же базовые действия, что и описаны в разделе Работа с пулами данных. С помощью таблицы можно указать значения или исключения для возврата на определенный набор аргументов.

Развертывание заготовки

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

5.   Применение регистратора сеанса EJB

Регистратор сеанса EJB является приложением Java, позволяющим взаимодействовать с активными развертываемыми компонентами EJB. Эта функция доступна только для Enterprise JavaBeans, но не для компонентов COM.

Процесс применения регистратора сеанса EJB состоит из следующих этапов:

• Запуск сеанса записи XML
• Подключение к серверу EJB
• Создание экземпляра тестируемого объекта
• Вызов операции над объектом
• Вставка точек проверки и кода java
• Создание кода теста из записи сеанса EJB

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

1. Для соединения с сервером EJB необходимо предоставить URL поставщика и InitialContextFactory. Эти сведения должны быть такими же, как и информация, используемая в клиентском коде для подключения к серверу. Информацию о подключении по умолчанию для WebSphere и Web Logic можно найти в электронной документации продукта.  
2. Предоставив сведения о подключении выберите Подключиться, после чего появится список объектов, развернутых на сервере. Во время сеанса можно взаимодействовать с одними или несколькими объектами, на этом этапе нужно выбрать первый объект для взаимодействия.
3. Здесь можно создать экземпляр первого тестируемого объекта. Выберите подходящий метод создания в верхней части окна Методы. Если для метода создания требуются определенные параметры, укажите их в разделе Параметры. После завершения выберите опцию Вызвать для создания экземпляра объекта.
4. После создания экземпляра объекта регистратор сеансов EJB отобразит различные доступные для объекта операции. В верхней половине окна Методы вы увидите собственные операции объекта, наследуемые операции будут показаны в нижней половине окна. Как правило наследуемые операции не тестируются. Выбрав тестируемые операции вы сможете задать обязательные параметры для этой операции в окне Свойства.
5. Если параметр является сложным объектом, появится кнопка Создать. При ее нажатии будет открыто последующее окно, в котором можно создать экземпляр требуемого объекта. В окне будут показаны конструкторы и необходимые атрибуты для создания экземпляра объекта. Указав сведения конструктора необходимо будет присвоить объекту имя, чтобы ссылаться на него в дальнейшем при записи, если это необходимо.  
6. Имеет смысл присваивать имена параметрам, если эти значения будут использованы повторно в ходе записи сеанса. Если вы указали имя, QualityArchitect сможет заполнить значение в полях параметров при щелчке на них правой кнопкой мыши.
7. При выборе опции Вызвать будет вызвана операция с заданными параметрами. Значение возврата будет показано в поле Последнее значение возврата. Если значение является обязательным в качестве ввода для последующего вызова, можно переместить его в требуемое поле. Можно также щелкнуть правой кнопкой мыши на поле параметра, в которое требуется вставить значение. Для определения значений, отображаемых при щелчке правой кнопкой мыши, регистратор сеанса EJB сопоставляет тип параметра с предыдущим типом, использованным при тестировании.  
8. В любой момент выполнения сеанса можно вставить код java или точки проверки с помощью меню Вставка. Точки проверки совпадают с точками проверки, использованными при создании кода теста сценария. Точно также кож java можно вставить для выполнения дополнительной обработки.
9. Если вы находитесь в режиме записи, вы сможете преобразовать запись на базе XML в код java после выполнения всех этапов теста. Щелкните на опции Остановить для выполнения этого действия. Появится предложение преобразовать код XML в код java, вам потребуется указать имя сеанса и имя сценария. Код Java, который можно выполнить для воссоздания действий, выполненных при записи, является выводом данного процесса.