Конспект лекции дисциплины «Графические системы и интерфейс оператора»


НазваниеКонспект лекции дисциплины «Графические системы и интерфейс оператора»
страница14/17
Дата публикации13.03.2013
Размер1.2 Mb.
ТипКонспект
userdocs.ru > Информатика > Конспект
1   ...   9   10   11   12   13   14   15   16   17
^

P4. Лекция № 12. Использование пакетов автоматизации тестирования


Использование пакетов автоматизации тестирования. Методы проведения тестирования пользовательского интерфейса, повторяемость тестирования пользовательского интерфейса. Ручное тестирование. Сценарии на формальных языках. Система Quick Test.
^

Методы проведения тестирования пользовательского интерфейса, повторяемость тестирования пользовательского интерфейса


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

1) Ручное тестирование


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

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

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

2) Сценарии на формальных языках


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

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

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

И при передаче информации в тестируемый интерфейс, и при получении информации для анализа могут использоваться два способа доступа к элементам интерфейса:

позиционный, при котором доступ к элементу осуществляется при помощи задания его абсолютных (относительно экрана) или относительных (относительно окна) координат и размеров;

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

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

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

Если во второй версии системы после нажатия на кнопку "Передать данные" вначале выводится окно "Вы уверены?" с кнопками "Да" и "Нет", то для проверки работы индикатора прогресса в тестовый сценарий необходимо добавить имитацию нажатия кнопки "Да".

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

Тестирование удобства использования пользовательских интерфейсов.


Удобство использования пользовательского интерфейса (usability) - показатель его качества, который определяет количество усилий, необходимых для изучения принципов работы с программной системой при помощи данного интерфейса, ее использования, подготовки входных данных и интерпретации выходных. Иначе говоря, удобство использования определяет степень простоты доступа пользователя к функциям системы, предоставляемым через человеко-машинный (пользовательский) интерфейс.

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

На удобство использования пользовательского интерфейса влияют следующие факторы:

  1. легкость обучения - быстро ли человек учится использовать систему;

  2. эффективность обучения - быстро ли человек работает после обучения;

  3. запоминаемость обучения - легко ли запоминается все, чему человек научился;

  4. ошибки - часто ли человек допускает ошибки в работе;

  5. общая удовлетворенность - является ли общее впечатление от работы с системой положительным.

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

Выделяют следующие этапы тестирования удобства использования пользовательского интерфейса.

^ 1) Исследовательское - проводится после формулирования требований к системе и разработки прототипа интерфейса. Основная цель на этом этапе - провести высокоуровневое обследование интерфейса и выяснить, позволяет ли он с достаточной степенью эффективности решать задачи пользователя.

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

^ 3) Валидационное - проводится ближе к этапу завершения разработки. На этом этапе проводится анализ соответствия интерфейса программной системы стандартам, регламентирующим вопросы удобства интерфейса (например ISO 13407 [ISO 13407:1999. Human-centred design processes for interactive systems International Organization for Standardization. 01-Jun-1999, 26 p.], ISO 9126 [ISO/IEC 9126-1:2001. Software engineering -- Product quality -- Part 1: Quality model]), проводится общее тестирование всех компонент пользовательского интерфейса с точки зрения конечного пользователя. Под компонентами интерфейса здесь понимается как его программная реализация, так и система помощи и руководство пользователя. Также на данном этапе проверяется отсутствие дефектов удобства использования интерфейса, выявленных на предыдущих этапах.

^ 4) Сравнительное - данный вид тестирования может проводиться на любом этапе разработки интерфейса. В ходе сравнительного тестирования сравниваются два или более вариантов реализации пользовательского интерфейса.

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

Например, Якоб Нильсен в своей работе [Nielsen J Ten Usability Heuristics] выделил 10 эвристических характеристик удобного пользовательского интерфейса, которые с его точки зрения должны проверяться при тестировании удобства использования интерфейса.

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

^ Соотнесение с реальным миром. Терминология, использованная в интерфейсе системы должна соотноситься с пользовательским миром, т.е. это должна быть терминология проблемной области пользователя, а не техническая терминология.

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

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

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

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

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

^ Гибкость и эффективность использования. В интерфейсе должны быть предусмотрены горячие клавиши (не обязательные к использованию начинающим пользователем) - они часто значительно ускоряют работу опытного пользователя. Иными словами, система должна предоставлять два способа работы - для новичков и для опытных пользователей. Желательно при этом давать возможность пользователю автоматизировать часто повторяющиеся действия.

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

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

Все эти эвристики могут использоваться при тестировании удобства использования пользовательского интерфейса. Достаточно очевидно, что при тестировании удобства слабо применимы способы автоматизации тестирования при помощи сценариев и подобные методы. Один из наиболее эффективных методов проверки интерфейса на удобство - использование формальной инспекции. Вопросы в бланке инспекции могут быть как общего характера (так, например, можно использовать в качестве вопросов перечисленные выше 10 эвристик), так и вполне конкретными.
^

Принцип использования коммерческих приложений для тестирования пользовательского интерфейса


Для автоматизированного тестирования пользовательского интерфейса приложения существуют уже готовые средства (программные продукты).

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



Рис. 43 Принцип тестирование пользовательского интерфейса

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



Рис. 44 Шаги процесса тестирования
^

Обзор Quickt Test. Основные понятия


QuickTest Professional (QTP) — программный продукт, предназначенный для автоматизации функционального и регрессионного тестирования, обладающий следующими особенностями:

  1. создание сложных наборов тестов с минимальным обучением;

  2. быстрое изолирование дефектов;

  3. гарантирование правильного функционирования приложения во всех средах, при любых наборах данных, и в любых бизнес-процессах;

  4. полное документирование и копирование дефектов для разработчиков;

  5. легкая реализация регрессионного тестирования;

  6. предоставление возможности организации поставлять программные изделия высокого качества.


QTP позволяет тестировать стандартные Windows приложения, Web приложения, управляющие элементы ActiveX, Visual Basic приложения и мультимедийные объекты на Web страницах.

Можно также приобрести дополнительные модули (add-in) для некоторых специфических рабочих сред, таких как Java, Oracle, SAP solutions, .NET Windows и Web Forms, Siebel, Web services, PeopleSoft и terminal emulator (Рис. 45).



Рис. 45 Окно добавления дополнительных модулей в Mercury QuickTest Professional

QuickTest Professional позволяет даже новичку создавать test-case (test-case — тест-кейсы, тестовые модули) очень быстро. Вы можете создать test-case просто нажав кнопку Record и используя приложение, чтобы выполнить типичный бизнес-процесс. Например, ведение журнала, составление справочников и т.д.

QuickTest Professional может автоматически ставить checkpoints (checkpoints — контрольные точки), чтобы проверить прикладные свойства и функциональные возможности приложения. Для каждого шага в Tree View (Tree View — дерево представления), есть ActiveScreen (ActiveScreen — окно, показывающее текущее состояние теста), в котором представлен вид приложения в данный момент времени. Вы можете также добавить несколько типов checkpoints для любого объекта, проверить, что компоненты ведут себя так, как ожидается, просто, нажимая на объект в ActiveScreen.

Также вы можете переключиться на Data Table (Data Table — таблица данных), включающую таблицу Excel для работы с данными (Рис. 46), и быстро создавать многократные повторения, чтобы расширить охват test-case.

Опытные пользователи могут рассматривать и редактировать test-case в Expert View (Expert View — поле кода), с помощью VBScript (Visual Basic Script), которые QuickTest Professional автоматически записывает (Рис. 46). Любые изменения, сделанные в Expert View автоматически синхронизируются с Tree View.



Рис. 46 Основное окно приложения QuickTest Professional. Представлены поле кода и таблица данных

Как только test-case выполнен, TestFusion показывает все аспекты испытания: краткий обзор результатов, Tree View тестируемого приложения, определяющее точно, где произошли ошибки (отказы), используемые испытательные данные, screenshots (screenshots — скриншоты, снимки экрана) для каждого шага, которые четко показывают любые несоответствия, и детальные пояснения для каждого прохода checkpoint ’ a (Рис. 47).



Рис. 47 Окно вывода результатов выполнения теста в QuickTest Professional

Также подразумевается интеграция с TestDirector для регистрации ошибок.

QuickTest Professional поддерживает фактически любое приложение.
^

Использование Actions, Iterations


Action — это независимый скрипт в составе теста. Он имеет свой контекст имен переменных, свой локальный Object Repository (хранилище описаний объектов пользовательского интерфейса тестируемого приложения), свой Action Sheet (называемый, также Local Sheet — таблица для хранения значений параметров; его можно вызывать из других тестов. Кроме того, начиная с QTP 8.0 у Actions есть свои параметры (не путать с Data Table parameters: в данном случае имеются в виду значения переменных, передающихся в action извне, либо выходные параметры, аналогично параметрам функций).

В свойствах Action можно указать, сколько раз подряд его надо запустить (количество итераций) — это имеет смысл делать при активном использовании параметризации. При использовании параметризации, при каждой следующей итерации Action, все локальные параметры принимают новое значение — значение из ряда Action Sheet, совпадающего с номером итерации. Следует иметь в виду, что кроме Action Sheet, существует Global Sheet (один на весь тест) — значения параметров, описанные в нём, изменяются при переходе к следующей итерации теста, а не Action.

В Mercury считают, что один Action должен примерно соответствовать одной бизнес операции, или одному Use Case. То есть, использование Actions (по Mercury) — основной способ функциональной декомпозиции. В реальности, вместо Actions для этих целей часто бывает удобнее использовать функции. Впрочем, это зависит от стиля Ваших тестов, в частности, от того, используете ли Вы параметризацию.

Для вызова Action из другого теста (либо из другого Action) необходимо, чтобы в свойствах action (Action Properties) была выставлена галочка "Reusable action".

Каждый Action имеет свой контекст имён, поэтому переменные одного Action не видны из другого. Универсальный способ передачи переменных, начиная с версии QTP 6.0 — использование объекта Environment. Кроме того, начиная с версии 8.0 у Actions появились параметры (см. Help: Action properties, Action call properties, Action parameters). То есть, Action, — это в некотором смысле аналог функции с входными и выходными параметрами.
^

Использование объекта DataTable и параметризация


Для того, чтобы вместо фиксированных значений параметров функций (например, текста, вводимого в поле ввода) использовать (в цикле) значения из таблицы, используется подход, называемый Data-Driven тестирование. При параметризации, исполнение теста происходит в форме исполнения двух вложенных циклов — по всему тесту целиком и по отдельным Actions. Соответственно, есть 2 типа параметров: глобальные — для всего теста, и локальные — для отдельных Actions. В начале каждой итерации все параметры приобретают значения, хранящиеся в строчке соответствующей таблицы (Global Sheet/Action Sheet), номер которой равен номеру итерации (теста или Action соответственно).

Кроме использования Data Table для хранения входных тестовых данных (параметры), QTP позволяет использовать его для хранения выходных данных (Output Values). Во время выполнения теста, значения в Data Table можно менять, однако они не будут сохранены в тесте. Зато их можно будет увидеть в отчёте об исполнении теста (логе).

^

Распознавание объектов в QTP и уникальность их свойств


При записи теста QTP записывает описания объектов интерфейса тестируемого приложения (Application Under Test, AUT), с которыми тест взаимодействует, в Object Repository. Если QTP что-то не распознаёт, с 99.9% вероятности это означает, что свойства распознавания в Object Repоsitory указаны неверно. Это происходит потому, что при записи QTP записывает в Object Repository совершенно определённый набор свойств объекта, одинаковый для каждого отдельного типа объектов. Какие именно свойства QTP записывает для каждого типа объектов определяется настройками Object Idenfication (Tools>Object Identification...).Для настройки свойств уникальности распознавания объектов следует:

  1. Спомощью Object Spy выяснить, какие именно свойства, из тех что записываются в Object Repository для объекта, меняются от сессии к сессии;

  2. Выяснить, какие свойства не меняются - их можно использовать для распознавания;

  3. Пойти в Object Identification Settings (Tools>Object Identification) и для соответствующего типа объектов правильно настроить свойства распознавания (которые будут прописываться в Object Repository при записи).



Рис. 48 Окно Object Identification

Mandatory Properties — свойства, которые QTP прописывает для этого типа объектов в Object Repository ВСЕГДА.

^ Assistive Properties — свойства, которые QTP прописывает в Object Repository ТОЛЬКО если во время записи объекта в Object Repository в приложении еcть более одного объекта, удовлетворяющих Mandatory Properties.

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

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

Настройки QTP по умолчанию не слишком удачны для работы с Win32 GUI приложениями, написанными НЕ на MFC и для динамических страниц Web.

Практически для всех типов объектов в качестве Assistive свойства указано window id. Для приложений, написанных без использования Microsoft Fundation Classes это приводит к тому, что объекты не распознаются при воспроизведении, так как window id меняется от сессии к сессии.
^

Rational RobotJ


RobotJ – это новейшая разработка Rational Software, предназначенная для тестирования Java- или веб-приложений, работающих на платформах Microsoft Windows и Unix. 4 RobotJ встраивается в открытую интегрированную среду разработки (Integrated Development Environment, IDE) фирмы IBM, известную как Eclipse. Используя IDE-среду IBM, как показано на Рис. 49, RobotJ оказывается в одном ряду с другими программными решениями, разрабатываемыми Rational Software и прочими производителями, которые обеспечивают простую интеграцию инструментария в общий интерфейс.



Рис. 49 Интерфейс Rational RobotJ

Регистратор RobotJ хранит рабочие копии всех объектов, задействованных во время сеанса записи. Большинство этих объектов помещается в группу с названием Test Object Map (Схема тестируемого объекта).

Другие элементы, например, те, что созданы в процессе определения контрольной точки, добавляются в раздел Verification Points (Контрольные точки).

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

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

1   ...   9   10   11   12   13   14   15   16   17

Похожие:

Конспект лекции дисциплины «Графические системы и интерфейс оператора» iconПлан-конспект лекции Тема лекции «Культура Античности»
Зелинский Ф. Ф. Древний мир и мы. Научно популярные статьи [1904]. Спб., 1997. ("Из жизни идей", т. 2)
Конспект лекции дисциплины «Графические системы и интерфейс оператора» iconВопросы к зачёту (1-й семестр)
Прикладное программное обеспечение: системы управления базами данных, графические редакторы
Конспект лекции дисциплины «Графические системы и интерфейс оператора» iconЛабораторная работа Оценка соответствия эргономических параметров рабочего места оператора пэвм
Рассмотреть составляющие элементы рабочего места оператора персонального компьютера (ПК). Ознакомиться с принципами оптимальной организации...
Конспект лекции дисциплины «Графические системы и интерфейс оператора» iconКонспект лекции План лекции Цель, задачи и объекты анализа финансовой...
Одним из видов экономического анализа является финансовый анализ, который с определенной долей условности подразделяется на внутренний...
Конспект лекции дисциплины «Графические системы и интерфейс оператора» iconС. П. Филин Концепции современного естествознания: конспект лекций
Конспект лекций соответствует требованиям Государственного образовательного стандарта высшего профессионального образования РФ и...
Конспект лекции дисциплины «Графические системы и интерфейс оператора» iconДжеф Раскин, Интерфейс: новые направления в проектировании компьютерных систем
...
Конспект лекции дисциплины «Графические системы и интерфейс оператора» icon«Психодиагностика. Конспект лекций»: Эксмо; Москва; 2008 isbn 978-5-699-26681-4
Книга предназначена длястудентов-психологов и представляет собой конспект лекций по психодиагностике. Подробное изложение материала...
Конспект лекции дисциплины «Графические системы и интерфейс оператора» iconПрограмма лекции Адрес Время проведения лекции Участники лекции 12...

Конспект лекции дисциплины «Графические системы и интерфейс оператора» iconТема №1 Первичные графические элементы композиции и основные принципы ее организации
Онятие. Система, структура. Психологические особенности восприятия визуальной информации. Зоны активного восприятия. Взаимосвязь...
Конспект лекции дисциплины «Графические системы и интерфейс оператора» iconДисциплины
Всего часов 108, из них аудиторных занятий 48 (лекции – 32, практические занятия –16)
Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2015
контакты
userdocs.ru
Главная страница