Система і спосіб для здійснення керування віддаленими комп’ютерами

1. Мережна система, сконфігурована так, щоб забезпечити можливість одночасного керування множиною цільових обчислювальних пристроїв з одного обчислювального пристрою перегляду, причому система включає в себе: пристрій перегляду з дисплеєм, причому пристрій перегляду сконфігурований так, щоб генерувати множину графічних вікон на дисплеї, пристрій перегляду також сконфігурований так, щоб мати прямий зв'язок з: серверним пристроєм, причому серверний пристрій сконфігурований так, щоб мати прямий зв'язок з кожним з: множини клієнтських цільових пристроїв, кожний з множини цільового пристрою сконфігурований так, щоб приймати вхідні команди від серверного пристрою, причому кожний цільовий пристрій сконфігурований так, щоб генерувати інформацію відображення для перенаправлення в серверний пристрій і, причому серверний пристрій сконфігурований так, щоб приймати введення, виконане в одному з вікон пристрою перегляду, і, щоб дублювати це введення так, щоб надавати вхідні команди в кожний з цільових пристроїв, і, додатково сконфігурований так, щоб приймати від цільових пристроїв інфор 2 (19) 1 3 даних, в якій зберігається множина попередньо заданих користувачем записів, і сервер інтерпретації сконфігурований так, щоб мати зв'язок з серверним пристроєм і приймати команди, які перенаправляються з пристрою перегляду, і, щоб надавати цифрову обробку зображення і операції пошуку в базі даних по цих командах, так, щоб інтерпретувати ці команди для подальшого виконання на кожному з цільових пристроїв. 11. Система за п. 10, в якій пристрій інтерпретації сконфігурований так, щоб виконувати сегментацію зображення і виконувати команди обробки зображення, які приймаються від пристрою перегляду. 12. Система за п. 11, в якій пристрій інтерпретації сконфігурований так, щоб забезпечити оптичне розпізнавання символів на командах, які приймаються від пристрою перегляду, так, щоб визначати розпізнані символи із зображень, що приймаються з пристрою перегляду. 13. Система за п. 12, в якій пристрій перегляду і щонайменше один з клієнтських цільових пристроїв надають відображення на різних мовах, причому серверний пристрій сконфігурований так, щоб виконувати переклад розпізнаних символів з пристрою перегляду на мову, прийнятну для цільового пристрою, причому перекладені символи використовуються для виконання відповідної команди на цільовому пристрої. 14. Система за будь-яким з попередніх пунктів, сконфігурована так, щоб працювати в режимі імітації, причому при роботі в режимі імітації користувач на клієнтському пристрої може вибирати одне з вікон, що відображаються на клієнтському пристрої, як вікно контролера, причому виконувані в цьому вікні команди дублюються на кожний цільовий пристрій, і результати цих команд в кожному цільовому пристрої відображаються в особливих інших вікнах на клієнтському пристрої, причому кожне з особливих інших вікон однозначно асоційоване з конкретним цільовим пристроєм. 15. Система за п. 14, в якій надається множина команд, причому згадані команди надаються в формі сценарію, який записується в перший момент часу і може відтворюватися пізніше у визначений користувачем момент часу. 16. Система за п. 14, додатково сконфігурована так, щоб при виконанні команди в контролері здійснювати етап запису графічної інформації ділянки навколо позиції виконання команди, причому графічна інформація генерується і зберігається для кожної взаємодії між користувачем і вікном контролера, і ця графічна інформація може бути збережена в серверному пристрої. 17. Система за п. 15, додатково сконфігурована так, щоб при виконанні команди в контролері здійснювати етап запису графічної інформації ділянки навколо позиції виконання команди, причому ця графічна інформація генерується і зберігається для кожної взаємодії між користувачем і вікном контролера, і вона може бути збережена в серверному пристрої, причому система додатково включає в себе сервер інтерпретації, який сконфігурований так, щоб протягом відтворення сценарію порівнювати зображення, одержувані в результаті виконання команд в кожному з цільових пристроїв, 94731 4 з зображеннями, одержуваними при виконанні початкового запису сценарію. 18. Система за п. 17, в якій сервер інтерпретації сконфігурований так, щоб при визначенні наявності відповідності між зображеннями, одержуваними з початкового запису сценарію, і зображеннями, одержуваними при виконанні сценарію, виконувати відображення на клієнтському пристрої, яке вказує на успішне виконання сценарію. 19. Система за п. 16, яка додатково включає в себе сервер інтерпретації, причому сервер інтерпретації сконфігурований так, щоб використовувати зображення, одержувані в результаті виконання команди в керуючому пристрої, щоб визначати екранні координати для введення користувача на цільових пристроях. 20. Система за п. 14, додатково сконфігурована так, щоб при виконанні команди в контролері здійснювати етап запису графічної інформації ділянки навколо позиції виконання цієї команди, причому ця графічна інформація генерується і зберігається для кожної взаємодії між користувачем і вікном контролера, і система, додатково, включає в себе сервер інтерпретації, причому сервер інтерпретації сконфігурований так, щоб аналізувати графічну інформацію, пов'язану з кожною командою, виконуваною у вікні контролера, і визначати прийнятну команду для виконання на кожному з цільових пристроїв. 21. Система за п. 20, в якій визначення прийнятної команди включає в себе етап, на якому визначають еквівалентну ділянку у вікні, асоційованому з кожним тестованим пристроєм, для застосування команди, виконуваної у вікні контролера. 22. Система за п. 21, в якій визначення еквівалентної ділянки реалізовується шляхом виконання функції оптичного розпізнавання символів на вікні тестованого пристрою. 23. Спосіб, що реалізовується за допомогою комп'ютера, забезпечення можливості одночасного керування множиною цільових обчислювальних пристроїв з одного обчислювального пристрою перегляду, причому спосіб включає в себе етапи, на яких: надають перший програмний модуль, причому перший програмний модуль може виконуватися на пристрої перегляду з дисплеєм, причому перший програмний модуль сконфігурований так, щоб генерувати множину графічних вікон на дисплеї, надають другий програмний модуль, причому другий програмний модуль може виконуватися на серверному пристрої і надає комунікаційний інтерфейс між пристроєм перегляду і множиною клієнтських цільових пристроїв, надають третій програмний модуль, причому третій програмний модуль може виконуватися на одному або більше клієнтських цільових пристроях, причому другий цільовий модуль сконфігурований так, щоб надавати можливість кожному з множини клієнтських цільових пристроїв, на якому він виконується, приймати вхідні команди від серверного пристрою і генерувати інформацію відображення для перенаправлення в серверний пристрій, і причому виконання кожного з трьох програмних модулів і реалізація інтерфейсу між ними надає 5 94731 6 можливість передачі команди, виконаної в одному з вікон пристрою перегляду, через серверний пристрій для дублювання в кожний цільовий пристрій, генерації інформації відображення з цільових пристроїв, яка є результатом виконання команди, і перенаправлення цієї інформації для кожного цільового пристрою в пристрій перегляду за допомогою серверного пристрою, щоб забезпечити відображення в окремому вікні на пристрої перегляду для підтвердження дублювання даної коман ди, який відрізняється тим, що надають модуль інтерпретації, сконфігурований так, щоб виконувати цифрову обробку зображення над інформацією відображення, яка генерується цільовими пристроями. 24. Комп'ютерний запам'ятовуючий пристрій, який містить множину окремих модулів, що зберігаються на ньому, які сконфігуровані так, щоб при їх виконанні на одному або більше обчислювальних пристроях виконувати етапи способу за п. 23. Даний винахід належить до об'єднаних в мережу комп'ютерів і, зокрема, до системи і способу для здійснення керування віддаленими комп'ютерами в мережному комп'ютерному оточенні. Більш конкретно, дана система належить до методології, яка може використовуватися при одночасному виконанні або виконанні одного і того ж комп'ютерного додатка на одному або більше віддалених комп'ютерах, щоб забезпечити можливість оцінки і тестування продуктивності цієї програми на кожному з віддалених комп'ютерів. Відомо, що в мережній архітектурі окремі комп'ютери можуть здійснювати зв'язок один з одним, використовуючи спеціальні мережні протоколи, такі як протокол TCP/IP. Використовуючи ці протоколи особа, яка застосовує програмний додаток на першому комп'ютері, може використовувати дані, які зберігаються на іншому комп'ютері, наприклад файловому сервері і т. п. У техніці також відомі програмні додатки, які надають можливість віддаленому користувачеві ефективно керувати іншим комп'ютером так, щоб виконувати комп'ютерні додатки, які зберігаються на віддаленому комп'ютері, з його локального комп'ютера. З подібних додатків можна згадати рішення від компанії MicrosoftTM під брендом Remote Desktop і програмний додаток з відкритим кодом під ім'ям VNC (Virtual Network Computing). Ці додатки дають можливість переглядати і повноцінно взаємодіяти з одним комп'ютером, виконуючи керування з будь-якого іншого комп'ютера або мобільного пристрою в будь-якій точці з доступом в Інтернет. Програмне забезпечення VNC є кросплатформним ПЗ, перевага якого полягає в тому, що воно надає можливість дистанційного керування між різними типами комп'ютерів, однак є і обмеження, яке полягає в тому, що в заданий момент часу кінцевий користувач може керувати тільки однією віддаленою машиною, тобто для кожного кінцевого користувача забезпечується схема 1-1. AnyplaceControl є продуктом, який дозволяє користувачеві виконувати з'єднання одночасно з множиною машин. Проте, хоч користувач може одночасно з'єднуватися з множиною машин, він обмежений тим, що в заданий момент часу він може керувати тільки однією машиною, тобто він не може керувати множиною машин шляхом передачі однієї дії одночасно множині машин. Отже, дане рішення відрізняється від рішення VNC тим, що воно забезпечує можливість з'єднання по схемі 1-множина, але не дозволяє виконувати керування по схемі 1-множина. Ці програмні додатки можуть використовуватися для адміністрування системи, додатків технічної підтримки і довідкового стола, де постачальник технічної підтримки може увійти в систему комп'ютера, який викликає проблему, і опитати його без необхідності фізичної присутності біля даного комп'ютера. Ці системи забезпечують можливість декількох з'єднань з одним комп'ютером, тим самим, забезпечуючи колективну або спільну роботу, але в заданий момент часу як контролер діє тільки один комп'ютер. Додатки віддаленого доступу до комп'ютера також можуть використовуватися для цілей навчання, коли інструктор може бачити машину одного учня або машини декількох учнів, але і в цьому випадку одночасне керування множиною машин неможливе. Подібне керування віддаленим комп'ютером за допомогою локального комп'ютера може використовуватися в галузі тестування програмного забезпечення. Тестування програмного забезпечення включає в себе роботу системи або додатка в керованих умовах і оцінку результатів. Керовані умови повинні включати в себе як нормальні, так і анормальні умови. При тестуванні деякі процеси навмисно виконуються некоректно, щоб визначити, чи мають місце події, коли вони повинні мати місце, і - що найбільш важливо - чи відбуваються події, коли вони не повинні відбуватися. Вимоги до якісного тестування програмного забезпечення визначають з достатньою точністю, щоб забезпечити процес контролю якості з використанням групи визначених способів і критеріїв оцінки разом з керівництвом до їх застосування, і, отже, щоб забезпечити достатньо високу якість програмних продуктів або модулів. Тестування, яке необхідне для одержання якісного програмного забезпечення, повинно бути достатньо жорстким, і очевидно, що воно збільшує загальну вартість розробки програмного забезпечення. Можуть застосовуватися наступні види тестування: - Тестування стійкості, надійності і безпеки. - Забезпечення безвідмовної роботи програмного забезпечення в особливих апаратних і програмних середовищах. - Тестування відповідності і сертифікації логотипа. 7 - Підтвердження відповідності тестованого додатка з такими стандартами, як "JavaVerified" компанії Sun або "Designed for Windows" компанії Microsoft. - Тестування сумісності. - Тестування сумісності додатка і апаратного забезпечення для нових версій платформ і системного програмного забезпечення. Тестування функціональної сумісності/інтеграції. - Підтвердження нормальної спільної роботи різних компонентів системи у вибраних сценаріях. - Глобалізація/локалізація. - Тестування для підтвердження відповідності загальновизнаним стандартам глобалізації. Оскільки додаток тестування програмного забезпечення охоплює всю архітектуру комп'ютерного програмного забезпечення, було б корисно автоматизувати деякі частини стратегії тестування. Незважаючи на переваги з точки зору вартості і часу, сучасне автоматизоване тестування недосконале. Було реалізовано декілька варіантів так званого автоматизованого тестування інтерфейсу користування, де використовується одна або більше з наступних дій: - Захоплення елементів керування. - Маніпуляція елементами керування. - Одержання даних від елементів керування. При захопленні елементів керування необхідно знати, що шукати. Наприклад, в середовищі Windows існує три типи елементів керування: 1. Стандартні елементи керування Windows кнопки, вікна для введення тексту, спеціальні керуючі елементи. 2. Спеціальні користувацькі елементи керування являють собою елементи керування, які мають функціональність стандартних елементів керування, до якої розробником додається спеціальна функція. У середовищі Windows забезпечується підтримка " користувацьких" елементів керування і меню, щоб надати розробнику можливість змінити способи в базових класах меню або діалогів і реалізувати новий вид і поведінку елемента керування або меню. 3. Забарвлені елементи керування є елементами керування, які мають функціональність стандартних елементів керування, до якої розробником додається спеціальна функція. На доповнення до "Користувацьких елементів керування", забарвлені елементи керування самі відповідальні за обробку повідомлень вікон, таких як WM_PAINT. Існуючі інструменти автоматизованого тестування розділяються на наступні три основні категорії, де кожна категорія має різні режими роботи: - Просте захоплення - запис і відтворення. - Об'єктно-орієнтована автоматизація. - Виявлення компонентів на основі зображення. Потрібно розуміти, що кожний з цих способів має специфічну архітектуру і характеристику. Спосіб Простого Захоплення з Записом/Відтворенням має перевагу, яка полягає в тому, що він досить простий, але разом з тим його недолік полягає в тому, що він чутливий до графічних змін інтерфейсу користувача, до положення додатка на екрані, а 94731 8 також в проблемах синхронізації відтворення. Програмний підхід може більш легко виконувати регулювання змін в інтерфейсі користування, ніж колишній підхід, а також він може краще обробляти проблеми синхронізації відтворення. Проте, в цьому випадку від тестуючого фахівця потрібні навички розробника. Проблема розробки сценарію тесту несе з собою необхідність контролю версії і керування змінами, що більше схоже на процес розробки програмного забезпечення. Третій підхід використовує зображення, які генеруються і використовуються протягом виконання тестованої програми. Захоплюються зображення областей навколо миші під час деякої дії мишею. Далі, це зображення зберігається. Пізніше збережене зображення аналізується, щоб визначити, де повинна була бути виконана дія мишею протягом відтворення тестового сценарію, або де повинна була бути виконана дія на деякій іншій системі. Прикладом доступного продукту, який використовує виявлення компонентів на основі зображення в контексті автоматизованого тестування, є продукт Eggplant компанії Redstone. Eggplant є інструментом тестування програмного забезпечення, який використовує рішення VNC (описане вище), яке спеціально націлене на тестування того, що буде випробовувати людина при використанні програмного додатка. Програмне забезпечення Eggplant діє шляхом розділення задач знаходження цікавлячої області і знаходження області, де повинно бути застосоване введення користувача. Крім того, рішення Eggplant не розпізнає об'єкти в значенні об'єкта для об'єктноорієнтованого автоматизованого тестування. "Об'єкти" для Eggplant являють собою моментальні знімки екрана ідентифікуючих функцій, і вони не є об'єктами в значенні інтерфейсного елемента керування з визначеними даними і поведінкою. "Об'єкти" Eggplant визначаються користувачем за допомогою рухомого вікна із змінними розмірами, яке визначає цікавлячу область. Відповідно, існує необхідність в наданні системи і методології, яка забезпечує керування множиною обчислювальних пристроїв через робочий стіл першого обчислювального пристрою, причому робочі столи керованих пристроїв відображаються на екрані, пов'язаному з першим пристроєм. Крім того, існує необхідність в тестуючому додатку з функцією виявлення на основі зображення, який з легкістю може бути розгорнутий на множині комп'ютерів і який надає надійну і безпечну архітектуру тестування. Розв'язання цих і інших проблем є метою системи і способу згідно з даним винаходом, який забезпечує автоматизацію тестування і віддалене керування комп'ютерами в мережному оточенні. Мережна архітектура згідно з даним винаходом забезпечує з'єднання по схемі 1-множина і керування між першим обчислювальним пристроєм і множиною інших обчислювальних пристроїв. Архітектура забезпечує можливість з'єднання по схемі 1-множина шляхом надання клієнтського цільового модуля, який може виконуватися на одній або більше тестованих системах, кожна з яких визнача 9 ється як цільовий пристрій, клієнтського модуля перегляду, який може виконуватися на локальному комп'ютері і який надає можливість користувачеві переглядати і керувати кожною тестованою системою на локальному робочому столі, і диспетчерського серверного модуля (на який посилаються як на серверний пристрій), який забезпечує інтерфейс між клієнтськими модулями перегляду і клієнтськими цільовими модулями. Диспетчерський серверний модуль являє собою серверний додаток, виконуваний на комп'ютері і сконфігурований так, щоб бути посередником всіх взаємодій між користувачем і кожною з тестованих систем. На інтерфейсі з диспетчерським серверний модулем може бути наданий серверний модуль інтерпретації, який може бути сконфігурований так, щоб активувати одну або більше з множини задач, що включають в себе, наприклад, обробку зображення, сегментацію зображення, інтерпретацію зображення, пошук в базі даних і генерацію загальної інформації, такої як XML-описи опитуваного зображення. Використання мережної архітектури згідно з даним винаходом дозволяє користувачеві виконувати автоматизоване тестування або віддалене керування одним або більше віддаленими комп'ютерами одночасно. Інтерфейс, наданий між користувачем і тестованими системами, забезпечує можливість одночасного з'єднання з кожною з тестованих систем і одночасного керування ними. Очевидно, що термін комп'ютер використаний в даному описі в загальному значенні, і він охоплює будь-який обчислювальний пристрій або електронний пристрій, на якому діє операційна система, і в даному винаході термін комп'ютер охоплює будь-який обчислювальний пристрій, такий як Персональні Цифрові Секретарі (Personal Digital Assistant, PDA), мобільні телефони і т. п., а також звичайні персональні комп'ютери або ноутбуки. Даний винахід надає систему згідно з п. 1 формули винаходу з корисними варіантами здійснення, вказаними в залежних пунктах формули винаходу. Даний винахід також надає спосіб згідно з п. 23 формули винаходу. Ці і інші відмітні ознаки будуть очевидні з подальшого опису з посиланням на прикладені креслення. Фіг. 1 - схематична ілюстрація мережної архітектури згідно з даним винаходом; Фіг. 2 - ілюстрація прикладу обробки, реалізованої по мережній архітектурі згідно з даним винаходом; Фіг. 3 - ілюстрація модифікації архітектури з Фіг. 1, в якій додано додатково клієнтський пристрій перегляду; Фіг. 4А-4С - ілюстрації сокет-зв'язків між компонентами даного винаходу; Фіг. 5 - миттєвий знімок екрана з клієнтського пристрою, який ілюструє роботу системи згідно з даним винаходом з двома з'єднаними машинами. Нижче, система згідно з даним винаходом описана з посиланням на наступні терміни, які надані для простоти опису, і не треба робити якихнебудь висновків з найменувань використаного тут протоколу. Як показано на Фіг. 1, система 100 згід 94731 10 но з даним винаходом включає в себе наступні компоненти: - Одна або більше Тіньових Клієнтських Цілей 105 (ТКЦ). - Тіньовий Диспетчерський Сервер 110 (ТДС), сполучений з пристроєм 110А зберігання даних. - Тіньовий Клієнтський Переглядач 115 (ТКП). - Тіньовий Сервер Інтерпретації 120 (ТСІ), сполучений з пристроєм 120А зберігання даних. ТСІ може розглядатися як опціональна функція в даній архітектурі, оскільки він забезпечує можливість використання додаткових підпрограм обробки і функцій при з'єднанні 1-множина. У наступних розділах окремо описані окремі компоненти. Тіньова Клієнтська Ціль 105 (ТКЦ) ТКЦ являє собою програмний модуль, який діє на тестованій системі або машині, якою користувач хоче керувати віддаленим чином. Даний модуль наданий як багатопотоковий модуль програмного забезпечення, який виконується на тестованій системі і виконує наступні функціональні етапи: - ТКЦ відкриває порт, який необхідно прослуховувати. - ТКЦ створює сокет для передачі даних. - ТКЦ активно намагається встановити з'єднання з ТДС. ТКЦ може бути запущена або виконана в одному з двох режимів. ТКЦ може бути запущена як звичайний виконуваний файл. Альтернативно, вона може бути встановлена на операційну систему як служба, яка автоматично запускається, коли виконується перезавантаження машини ТКЦ. Якщо ТКЦ запущена як звичайний виконуваний файл, то ТКЦ представляє користувачеві діалогове вікно, яке запитує користувача специфікувати ТДС з переліку можливих ТДС. Альтернативно, якщо ТКЦ виконується як служба операційної системи, то ТКЦ буде використовувати дані конфігурації, щоб визначити ТДС, з яким треба встановити з'єднання. Дані конфігурації можуть бути встановлені за допомогою файла ініціалізації (INI-файла), який користувач може редагувати. Під час роботи системи згідно з даним винаходом ТКЦ одержує від ТДС пакети, що містять дані, які визначають введення команд, такі як інформацію введення миші і натиснення клавіш. ТКЦ генерує і посилає ТДС послідовність графічних файлів, таких як бітові карти, які являють собою миттєві знімки з машини в її поточному стані. ТКЦ виконує дію згідно з командним введенням і на доповнення до послідовності графічних файлів, що регулярно надається, надає графічний файл, що ілюструє результат цього командного введення, як підтвердження результату цієї дії. Очевидно, що інформація, що передається з ТКЦ, являє собою періодично генеровані миттєві знімки екрана поточного відображення на даній ТКЦ і - при зміні відображення внаслідок деякої команди - додаткове оновлення, що ілюструє, як змінилося відображення. Очевидно, що система згідно з даним винаходом може бути розгорнута на множині різних ма 11 шин і операційних систем, хоч в будь-який конкретний момент часу використовується тільки підгрупа цих машин. ТКЦ може встановити з'єднання з одним ТДС, який входить до групи доступних ТДС. ТКЦ може бути з'єднана з одним ТДС в активному режимі, але вона може бути з'єднана з множиною ТДС одночасно. Протягом роботи системи, ТКЦ приймає вхідні дані від ТДС через сокет даних. Очевидно, що зв'язок між окремими компонентами системи здійснюється за допомогою мережних протоколів, таких як протокол TCP/IP. Ці дані можуть містити, але не обмежені перерахованим, один або більше з наступних компонентів: - Вхідні і допоміжні дані клавіатури. - Вхідні і допоміжні дані миші/покажчика. - Запит інформації про апаратну настройку ТКЦ. - Запит на зняття миттєвого знімка екрана. - Запит на витягання вмісту буфера обміну. - Запит на вставлення даних в буфер обміну. Дії клавіатури або миші передаються в чергу операційної системи. Якщо введення також включає в себе запит на зняття миттєвого знімка екрана, тобто, якщо ТКП знаходиться в режимі запису, то ТКЦ чекає поки операційна система обробить введення, і тільки після цього знімає миттєвий знімок екрана. Фіг. 2 ілюструє приклад подібного запиту на зняття миттєвого знімка екрана. На етапі 1 в ТКП 115 генерується запит. Цей запит приймається в ТДС, де ідентифікуються відповідні ТКЦ (етап 2). Далі, запит ретранслюється у відповідні ТКЦ (етап 3), де він обробляється, і знімається відповідний миттєвий знімок екрана (етап 4). Останній піддається стисненню в ТКЦ і направляється зворотно в ТДС (етап 5). При одержанні знімок перенаправляється з ТДС в ТКП в стисненому форматі (етап 6). При одержанні в ТКП знімок розтискається і відображається у відповідному вікні для ТКЦ на дисплеї ТКП (етап 7). ТСІ має функціональну можливість виявлення графічного елемента інтерфейсу. Якщо допоміжна інформація, яка супроводжує запит введення користувача, вказує, що повинна використовуватися підпрограма виявлення графічного елемента інтерфейсу, то ТСІ виконує підпрограму виявлення графічного елемента інтерфейсу, і передає необхідну інформацію в ТКЦ через ТДС, який застосує введення користувача у придатному місці. Якщо вміст буфера обміну ТКЦ модифікується, то в ТДС передається повідомлення, яке вказує цю подію. Це повідомлення також включає в себе вміст буфера обміну і будь-яку необхідну допоміжну інформацію. Очевидно, що виконання задач, які первісно виконуються в іншій частині даної архітектури, є тільки однією частиною з'єднання по схемі 1множина. Також необхідно, щоб підтвердження цих задач було повернуте в керуючий пристрій ТКП. Отже, ТКЦ потрібно вивести послідовність виведення даних, відповідних процесу, який локально виконується на пристрої ТКЦ. Це досягається шляхом зняття одного або більше миттєвих знімків екрана, які можуть бути потім стиснуті за допомогою відомих бібліотек стиснення, таких як ZLIB і т. 94731 12 п. Стиснений файл передається через сокет даних в ТДС. Кінцевий користувач, тобто особа, що керує ТКП, може настроїти частоту оновлення кадрів, тобто кількість миттєвих знімків екрана, які повинні бути зняті за одну секунду. За умовчанням частота оновлення кадрів може становити, наприклад, 5 кадрів в секунду. ТКЦ передає зворотно відповіді, основані на прийнятому запиті на обробку введення користувача. Ці відповіді можуть включати в себе допоміжну інформацію, таку як позиція миші, що вказує, де була застосована дія. Крім того, ці дані можуть включати в себе стиснений миттєвий знімок екрана, який представляє стан екрана після застосування цієї дії. Якщо підпрограма виявлення графічного елемента інтерфейсу ТСІ знаходить більше ніж один потенційний результат, то ТСІ передає зворотно запит, який вказує, що необхідна додаткова допоміжна інформація. ТКЦ також може передати зворотно повідомлення, яке містить інформацію про її апаратні настройки і/або вміст її буфера обміну. Тіньовий Диспетчерський Сервер 110 (ТДС) ТДС являє собою багатопотоковий модуль програмного забезпечення, який надає інтерфейс між одним або більше ТКЦ і ТКП, і який виконує наступні функціональні кроки: - При запуску він чекає з'єднань від ТКЦ і ТКП. - ТДС створює сокет і потік для кожної ТКЦ. - ТДС створює сокет і потік для кожного ТКП. - ТДС створює інші потоки для внутрішніх задач. ТДС з'єднується з підгрупою доступних машин, кількість яких складає щонайменше 1. Як згадувалося вище, з посиланням на ТКЦ, деякі впровадження системи згідно з даним винаходом можуть включати в себе інсталяцію на множину машин і операційних систем, однак в будь-який заданий момент часу можуть існувати деякі машини, які не з'єднані з яким-небудь ТДС. ТДС має вхідні і вихідні з'єднання з множиною ТКП і цілями ТКЦ, які забезпечуються за допомогою мережних протоколів для передачі даних, таких як TCP/IP. По суті, він надає інтерфейс між ТКП і ТКЦ. Незважаючи на те, що можливе з'єднання ТДС з множиною ТКП, має місце випадок, коли тільки один з множини ТКП має повне керування якою-небудь ТКЦ. Інші ТКП, які сполучені через ТДС з цією ТКЦ, можуть тільки спостерігати і приймати "потік" миттєвих знімків екрана від ТДС тільки для цілей відображення. Кожний потік ТДС, виділений одній ТКЦ, виконує наступні функції: - Підтримує з'єднання з ТКЦ. Насправді ТКЦ виконує з'єднання з ТДС. - Приймає запити від ТКП. - На основі вмісту повідомлення запиту ТКП, ТДС може вирішити передати цей запит в ТСІ для обробки. Якщо має місце такий випадок, то поточний потік буде чекати відповіді від ТСІ до обробки інших запитів від ТКП, пов'язаного з цим потоком. - Запит перенаправляється у відповідні цілі. Потрібно зазначити, що один і той же запит від ТКП може бути переданий множині ТКЦ. Цей сце 13 нарій типу однин-множина має місце, коли ТКП знаходиться в режимі контролера і керує множиною машин одночасно. - Приймає запити від ТКЦ. - На основі запиту від ТКЦ, ТДС може перенаправляти запит в ТСІ для подальшої обробки. - Якщо ТКП знаходиться в режимі запису, то ТДС збереже цей запит в своєму пристрої зберігання даних. Дані зберігаються в електронному форматі так, щоб їх можна було з легкістю витягнути і використати для цілей відтворення на пізньому етапі. - ТДС може вирішити перенаправляти запит від ТКЦ у відповідний ТКП. - Приймає дані від ТКП в формі XML з описом рухів миші і клавіатури. - Ретранслює XML-дані в ТКЦ. - Ретранслює дані стисненого миттєвого знімка екрана в ТКП. Очевидно, що як інтерфейсний модуль ТДС приймає і передає множину введень і виведень як від ТКЦ, так і від ТКП. Нижче наведений перелік типів введень, які властиві для ТДС: - Запит від ТКП на зняття миттєвого знімка асоційованої ТКЦ. - Запит від ТКП на надання інформації апаратного і програмного забезпечення ТКЦ. - Запит від ТКП на обробку введення користувача разом з допоміжною інформацією. - Повідомлення від ТКП, яке вказує, що поточна віддалена машина в даний момент є контролером. - Повідомлення від ТКП, яке вказує, що стан запису поточної віддаленої машини був змінений. - Повідомлення від ТКП, яке вказує, що стан відтворення поточної віддаленої машини був змінений. - Запит від ТКП на передачу списку всіх з'єднаних ТКЦ. - Запит від ТКП на закриття цього з'єднання. - Повідомлення від ТКП, яке вказує, що вміст буфера обміну цього ТКП був змінений, а також інформація буфера обміну. - Запит від ТКП на зняття миттєвого знімка екрана вручну. - Відповідь від ТСІ. - Стиснений миттєвий знімок ТКЦ і допоміжна інформація. - Інформація апаратного і програмного забезпечення ТКЦ. - Повідомлення від ТКЦ, яке вказує, що вміст буфера обміну цього ТКЦ був змінений, а також інформація буфера обміну. - Відповідь на введення користувача ТКЦ і допоміжна інформація. - Відповідь миттєвого знімка екрана ТКЦ, знятого вручну. - Запит від ТКЦ на закриття цього з'єднання. Що стосується виведень, то ТДС збереже записані дані в своє джерело даних, таким чином надаючи функцію кеш-пам'яті. Ці дані зберігаються в електронній формі і пізніше можуть використовуватися з метою відтворення. Типові виведення з ТДС включають в себе: 94731 14 - Запит в ТКЦ на зняття миттєвого знімка пов'язаної ТКЦ. - Запит в ТКЦ на надання інформації апаратного і програмного забезпечення ТКЦ. - Запит в ТКЦ на обробку введення користувача разом з допоміжною інформацією. - Повідомлення в ТКЦ, яке вказує, що вміст буфера обміну цього ТКП був змінений, а також інформація буфера обміну. - Запит в ТКЦ на зняття миттєвого знімка екрана вручну. - Запит в ТСІ на виконання аналізу даних. - Стиснений миттєвий знімок ТКЦ і допоміжна інформація. - Інформація апаратного і програмного забезпечення ТКЦ. - Повідомлення від ТКЦ, яке вказує, що вміст буфера обміну цієї ТКЦ був змінений, а також інформація буфера обміну. - Відповідь на введення користувача ТКЦ і допоміжна інформація. - Відповідь миттєвого знімка екрана ТКЦ, знятого вручну. - Запит від ТКЦ на закриття цього з'єднання. Тіньовий Клієнтський Переглядач 115 (ТКП) ТКП також є багатопотоковим додатком. ТКП з'єднується з одним ТДС, що може бути виконано в режимі перегляду або в активному режимі. ТКП може з'єднуватися з множиною ТДС, хоч в активному режимі буде тільки один з них. У активному режимі ТКП керує роботою ТКЦ. У режимі перегляду ТКП просто приймає інформацію відображення від кожної з'єднаної ТКЦ і відображає кожну ТКЦ, і ТКП не передає яких-небудь введень користувача в яку-небудь ТКЦ. Фіг. 1 ілюструє приклад однієї групової конфігурації, де один ТКП 115 з'єднаний з одним ТДС 110. Всі ТКЦ 105 знаходяться в керуванні ТКП, і в цій конфігурації даний ТКП знаходиться в активному режимі. У прикладі з двома групами з Фіг. 3, два ТКП 115А, 115В з'єднані з одним ТДС 110. У цій конфігурації один з двох ТКП, наприклад ТКП 115А, керує всіма машинами своєї групи. У Групі 1 асоційований з цією конфігурацією ТКП керує всіма машинами в Групі 1. Існує три ТКЦ, які є членами обох груп. У цьому прикладі, асоційований з Групою 2 ТКП, тобто ТКП 115В, може тільки переглядати ТКЦ в групі 1, і він не керує нею. Однак, ТКП 115В має повне керування іншими ТКЦ в Групі 2. Для цілей даного опису, "відповідною" ТКЦ в контексті з'єднання з ТКП є ТКЦ, для якої ТКП має повне керування над ТКЦ в активному режимі. Фіг. 4 ілюструє сокети зв'язку для даних, що передаються в і від ТКП і ТДС. Також проілюстровані сокети зв'язку між ТДС і кожним окремою ТКЦ. ТКП має один потік для кожного сокет-з'єднання до ТДС, відповідної ТКЦ. Через ці сокети ТКП здійснює зв'язок з ТКЦ через ТДС. Фіг. 4А ілюструє присутні сокети зв'язку, тоді як Фіг. 4В ілюструє потоки даних для сокетів, коли перша ТКЦ (ТКЦ_1) є контролером, а друга ТКЦ (ТКЦ_2) взаємодіє напряму через ТКП, а не через контролер. Фіг. 4С ілюструє потік даних для сокетів, коли ТКЦ_1 є контролером. 15 Для ефективного керування кожнаю ТКЦ важливо, щоб користувачеві були відомі дії, що мають місце на кожній з цільових машин. Система згідно з даним винаходом досягає цього шляхом надання на ТКП відображення вікна кожної ТКЦ, з якою він з'єднаний. На Фіг. 5 показаний приклад миттєвого знімка екрана, де очевидно, що ТКП має вікно для кожної ТКЦ 505, 510, які були вибрані. Також можливо надати друге вікно 505А, 510А, збільшувальне вікно для кожної ТКЦ, де активна область на кожній ТКЦ збільшена. Збір інформації миші і клавіатури для кожного вікна здійснюється з використанням стандартних приймачів подій для цих типів подій. У ТКП, вікно контролера, відповідне визначеній ТКЦ, може бути специфіковане, використовуючи опцію меню або комбінацію клавіш. ТКП надає цю інформацію в ТДС. Це вікно машиниконтролера в ТКП передає свої події в ТДС через сокети даних. ТДС передає події в ТКЦ, відповідну вікну контролера, але він також передає ці події в кожну (не керуючу) ТКЦ, яка з'єднана з ним. ТДС не передає всі події всім ТКЦ, сполученим з ним, оскільки деякі з цих подій можуть бути незв'язані з конкретним ТКП. Наприклад, ТКП 115В з Фіг. 3 не потрібно бачити активність в Групі 1. У даній ситуації користувач одночасно дистанційно керує всіма відповідними ТКЦ (машинами) за допомогою дій на одному вікні ТКП. У випадку, коли присутній набір вікон контролера і користувач переміщує мишу на інше вікно в ТКП, то має місце інша ситуація. У цьому випадку дані події передаються через сокет, що належить до ТКЦ і ТДС, і тільки звідти - в ТКЦ. Проте, в цьому випадку ТДС не ретранслює події у всі відповідні (в значенні, описаному в попередньому параграфі) ТКЦ, які з'єднані з ним. Таким чином, користувач дистанційно керує однією єдиною машиною (див. Фіг. 4В). ТДС має два сокети даних на кожну (відповідну) ТКЦ. Кожний сокет даних є односпрямованим і служить різним цілям. Один сокет містить повідомлення даних, такі як запити на зняття миттєвого знімка екрана, дані миші і клавіатури, повідомлення закриття і інші текстові дані. Інший сокет містить дані, що приходять від ТКЦ, такі як повідомлення і стиснені миттєві знімки екрана. Тіньовий Сервер Інтерпретації 120 (ТСІ) Як описано вище, деякі впровадження даного винаходу будуть достатніми при використанні тільки одного ТКП і одного ТДС, через який ТКП з'єднується з однією або більше ТКЦ. У тих випадках, коли при взаємодії потрібна додаткова функціональність, даний винахід надає сервер інтерпретації - Тіньовий Сервер Інтерпретації 120 (ТСІ). ТСІ сполучається з ТДС. Він являє собою багатопотоковий додаток. Метою ТСІ є виконання цифрової обробки зображення і виконання операцій пошуку в базі даних. Функції ТСІ включають в себе наступне: - Сегментація зображення з використанням способів цифрової обробки зображень, таких як, але не обмежуючись перерахованим, сегментація границь, сегментація, основана на краї, збільшення області, зв'язування областей з нелінійним ма 94731 16 сштабуванням і/або інші функції. Області, на які сегментується зображення, містять графічний елемент інтерфейсу, на якому користувач виконав натиснення. У цьому випадку одержується область з визначеним розміром і границями, з якої можна витягнути іншу інформацію. - Витягання вектора ознак: використовуючи визначену область зображення, можуть бути застосовані різні технології, такі як гістограми відтінків сірого і кольорові гістограми, моменти n-ого порядку і/або вейвлети, щоб одержати міру, яка описує область зображення. Ця міра може бути виражена як векторна величина, так що до неї можуть бути застосовані математичні методи. Подібні вектори ознак можуть бути потрібними для декількох суміжних сегментів. - Розпізнавання об'єктів з використанням векторів ознак. Ідентифікація об'єкта регулюється за допомогою розмитої логіки, нейронних мереж, підтримувальних векторних машин і/або мислення, основаного на прецедентах, які застосовуються до групи векторів ознак. Еталонні об'єкти можуть бути збережені у форматі бази даних, з яким будуть порівнюватися невідомі ознаки. Однією з функцій ТСІ є знаходження об'єкта, асоційованого з визначеною точкою, при заданих координатах в зображенні. ТСІ виконує це таким чином: - Зображення сегментується, використовуючи метод сегментації з цифровою обробкою зображення. - Для сегментів (областей) навколо миші витягується вектор ознак, такий як, але не обмежуючись перерахованим, гістограма або вимірювання руху. - Ці вектори ознак визначають "об'єкт" в зображенні, з якого були визначені координати. - Ці вектори ознак порівнюються з еталонними векторами ознак, щоб оцінити схожість, використовуючи міру відстані, таку як, але не обмежуючись перерахованим, евклідова метрика, метрика Манхеттена (Manhattan metric) або відстань Earthmover distance. - Еталонні вектори ознак зберігаються в базі даних. База даних вручну формується так, щоб включати в себе такі дані, які можуть бути необхідними при дослідженні набору миттєвих знімків екрана. - Еталонні вектори ознак витягуються з використанням SQL. Еталонні вектори ознак мають ідентифікатор застосовно до "об'єктів", які можна зустріти при дослідженні набору миттєвих знімків екрана, таких як "меню", "панель інструментів". - Ідентифікація об'єкта виконується шляхом надання набору об'єктів-кандидатів, вектори ознак яких найбільш близько нагадують (в значенні, використаному вище) вектори ознак, витягнуті з вихідного зображення. Для більшої частини зображень довжина списку ідентифікацій об'єктів-кандидатів буде становити 1. Якщо список довше ніж 1, то процес не завершився однозначною ідентифікацією об'єкта. Для одержання однозначної ідентифікації потрібно або втручання користувача, щоб визначити коректну ідентифікацію, або потрібно збільшити кількість використовуваних векторів 17 ознак і повторювати процес, поки не буде одержана однозначна ідентифікація. Прототип описаної функції виглядає таким чином: Object findWidget(point p) {return Object widget}. Ще однією функцією TCI є ідентифікація точки на зображенні заданого об'єкта. Процес здійснюється таким чином: - Вектор ознак шуканого об'єкта визначається шляхом опиту бази даних. Дана ознака позначається терміном "ознака опиту". - Зображення сегментується, використовуючи метод сегментації з цифровою обробкою зображення. - Для всіх сегментів (областей) зображення витягуються вектори ознак, такі як, але обмежуючись перерахованим, гістограми або міри моменту. Ці вектори ознак описують якість зображення у визначеній області. Передбачається, що області зображення зі схожими векторами ознак будуть схожі і мають схожий вміст. - Кожний елемент зі списку векторів ознак порівнюється з вектором ознак опиту об'єкта, які потрібно ідентифікувати. Щоб оцінити схожість векторів ознак з ознакою опиту, можна використовувати метрику відстані, таку як, але не обмежуючись перерахованим, евклідова метрика, метрика Манхеттена (Manhattan metric) або відстань Earthmover distance. - При виявленні ознаки з найбільшою відповідністю, повертаються координати центра ваги даного сегмента. Прототип описаної функції виглядає таким чином: point findCoordinates(Object widget) {return point p}. Приклади роботи Використовуючи взаємодію по схемі 1множина, система згідно з даним винаходом може бути розгорнута множиною різних способів. Нижче викладений опис прикладу застосування методології даного винаходу в першому режимі, тобто в режимі імітації. Дана конкретна послідовність потоку ілюструє приклад однієї клієнтської цілі і вимагає наявності однієї тестованої системи з виконуваним на ній клієнтським цільовим модулем, однієї системи з виконуваним на ній клієнтським модулем переглядача і одного сервера з виконуваним на ньому диспетчерським модулем. Кожний модуль наданий на визначеній апаратній машині, і модулі здійснюють зв'язок один з одним, використовуючи протокол TCP/IP. Як показано на миттєвому знімку екрана з Фіг. 5, при виконанні базового набору вказаних вище кроків, користувач може локально бачити "тестовану систему", тобто систему, на якій виконується додаток Клієнтської Цілі - ТКП. Коли користувач застосовує дії миші/покажчика або клавіатури на вікні переглядача, тестована система (ТКЦ) відповідним чином реагує на це введення. У ТКП користувач також може бачити два інших вікна - вікно 520 реєстрації і збільшувальне вікно 505А, 510А. Вікно 520 реєстрації відображає інформацію, зібрану з вікна робочого стола тестованої системи, таку як координати позиції миші, дія миші (одинар 94731 18 не натиснення, подвійне натиснення і т. п.) і координати або введення клавіатури. Збільшувальне вікно відображає область екрана, видиму навколо миші тестованої системи, і оновлює цю інформацію із заданою швидкістю оновлення. Якщо присутня тільки одна ТКЦ, і вона за умовчанням є "контролером", то користувач керує системою за допомогою ТКП (див. Фіг. 5). Якщо присутні більше однієї ТКЦ, то один контролер визначається користувачем, який і керується користувачем. Інші ТКЦ використовують введення користувача, яке приймається контролером, тобто введення миші і клавіатури. Розміри збільшувального вікна визначаються користувачем. Збільшувальне вікно некритичне для функціонування додатка, і воно показує тільки частину всього екрана, як додаток Екранна Лупа (MS Magnifier), який як частина спеціальних можливостей системи показує область екрана навколо миші. Позиція миші, тобто екранні координати (х, у) і дія миші, тобто натиснення або подвійне натиснення, передаються від ТКП в ТДС. Аналогічним чином інші дії користувача, такі як дії натиснень клавіш, передаються від ТКП в ТДС. ТДС передає цю інформацію в ТКЦ, яка в свою чергу передає повідомлення в чергу своєї операційної системи. Коли черга операційної системи обробляє це повідомлення, миша переміщається у відповідні координати і застосовується відповідна дія. Дія оновлення проводиться постійно і незалежно від взаємодії користувача. Проте, збережені миттєві знімки одержуються за запитом користувача. Поряд з тим, що це корисне при визначенні того, як діє одна тестована система, даний винахід може бути розширений для одночасного застосування до множини тестованих систем. У цьому режимі роботи користувач може бачити робочий стіл "тестованих систем", тобто систем, на яких виконується додаток ТКЦ, і він вибирає будь-яку з них як "контролер". Не має бути причин, через які одній машині буде віддана перевага. Насправді, як частина вимог настройки, як правило, кожна машина, здатна діяти як ТКЦ, повинна бути ідентична з точки зору установок апаратного і програмного забезпечення. Однак очевидно, що ТДС і ТКП не потрібно мати ідентичну специфікацію (одного відносно одного або відносно ТКЦ). Шляхом призначення однієї з ТКЦ контролером, інші ТКЦ приймають конфігурацію за умовчанням як "послідовники", в точності імітуючи те, що відбувається у вікні контролера. Користувач може бачити кожний робочий стіл тестованих систем в окремих вікнах в ТКП. Коли користувач переміщує мишу і застосовує одинарні або подвійні натиснення, або коли користувач вводить текст у вікна переглядача "Контролера", всі тестовані системи відповідним чином реагують на це введення. Кожне вікно, яке відображає робочий стіл системи "послідовника", в точності імітує дії, які застосовуються до вікна Контролера. У будь-який момент часу користувач може від'єднати тестовані системи від системи Контролера. Це може бути зроблене шляхом вибору елемента меню "Вимкнути Контролер". Кожне вікно стає доступним для взаємодії користувача по 19 окремості. Насправді, навіть тоді, коли встановлений контролер, користувач може маніпулювати кожною окремою машиною шляхом вибору відповідного вікна в ТКП і безпосередньої взаємодії з цим вікном. У ТКП, користувач може бачити два інших вікна для кожного вікна робочого стола - вікно реєстрації і збільшувальне вікно. Вікно реєстрації відображає інформацію, зібрану з вікна робочого стола тестованої системи, таку як координати позиції миші, дія миші (одинарне натиснення, подвійне натиснення) і координати або введення клавіатури. Збільшувальне вікно відображає область екрана, видиму навколо миші тестованої системи, і оновлює цю інформацію із заданою швидкістю оновлення. Існує два варіанти вирішення задачі захаращення на робочому столі. Згідно з першим, вікна, що відображають тестовані системи, масштабуються і для тестування систем для відповідних машин використовуються збільшувальні вікна. Згідно з другим варіантом на машині, де виконується програмне забезпечення клієнтського переглядача, використовується відеокарта, яка підтримує множину моніторів, що збільшує поверхню робочого стола до 2, 4, 8 моніторів. Існують карти, які підтримують два монітори, наприклад відповідні рішення компаній ATI і nVidia. Matrox постачає графічні карти, які підтримують 4 монітори, a Xentera GT8 PCI 8 постачає графічні карти, які підтримують 8 моніторів. Поряд з тим, що корисно взаємодіяти з множиною віддалених комп'ютерів одночасно і виконувати моніторинг поведінки одного комп'ютера або інших комп'ютерів, щоб забезпечити ідентичні характеристики поведінки, даний винахід надає можливість запису сценаріїв. Згаданий запис корисний для ряду цілей, включаючи ситуацію, коли потрібно, наприклад, виконувати визначену дію в перший момент часу і повторно виконати ідентичну дію пізніше на тому ж або на іншому комп'ютері, щоб гарантувати однакову поведінку. Інші причини, через які можуть бути записані сценарії, включають в себе: для навчальних і демонстраційних цілей (крізний контроль продукту) або для зняття миттєвих знімків екрана змінного інтерфейсу користувача для систем технічної підтримки або документування. Вибирається система "Контролера" згідно з вищезазначеною імітацією 1-множина (де кількість систем може бути більшою або рівною 1). Щоб почати запис, користувач вибирає опцію меню запису. Далі, користувач додержується етапів тесту і при завершенні вибирає елемент меню "Зупинити запис". Багато в чому даний процес схожий на запис макроса в середовищі Visual Basic і т. п. Форматом записаного сценарію є XML. Сценарій за умовчанням зберігається в ТДС. Для кожної ТКЦ буде по одному сценарію. Причиною цього є те, що множина ТКЦ може виконуватися на різних платформах, і в записаних сценаріях можуть бути присутніми невеликі відмінності. Крім того, в деякій точці в процесі запису користувач може побажати застосувати деяке введення тільки у визначені тестовані машини. 94731 20 Запис елемента сценарію може виглядати таким чином: MOVE 7488 21333 0 15 1 . Вищевикладений приклад ілюструє захоплення руху миші в позиції на екрані, позначеній координатами :. Введення з клавіатури можуть бути захоплені і вставлені в мітки . Поряд з тим, що корисно застосовувати запис сценарію, основна перевага забезпечується при відтворенні цього записаного сценарію на більш пізньому етапі. Це особливо корисне, коли потрібно автоматизувати визначені задачі, які можуть бути виконані шляхом однократного запису і його багаторазового відтворення за потреби. У режимі відтворення кожний рядок тестового сценарію аналізується по окремості, і далі дії передаються у відповідну ТКЦ для виконання. Сценарій контролера може бути відтворений на машині-контролері одним з наступних двох способів: відтворення як контролера множини ТКЦ, або відтворення як самої автономної ТКЦ. Протягом процесу запису встановлюється контролер і кожна окрема ТКЦ "додержується" його. Сценарій записується для цього контролера і кожної ТКЦ. Ці сценарії зберігаються в ТДС. Сценарій контролера містить інформацію, про те, що він є контролером і що існують інші ТКЦ. Відтворення сценарію контролера на контролері приводить до відкривання вікон ТКЦ його підлеглих, пов'язаних із записом сценарію. Можна застосувати відтворення одночасно у множині окремих ТКЦ. Також можливо відтворити сценарій окремої ТКЦ на окремій клієнтській цілі. Коли записується сценарій типу 1-множина, має місце наступне: Сценарій записується для машиниконтролера. - Окремі сценарії записуються для кожної Клієнтської Цілі. Сценарій може бути відтворений на будь-якій машині. Немає ніяких особливих обмежень, які б нерозривно зв'язували сценарій з конкретною машиною. Якщо система розгорнута в режимі імітації по схемі 1-множина і сценарій відтворюється на контролері, то всі інші ТКЦ додержуються його. Сценарій, записаний на одній ТКЦ, буде відтворений на другій ТКЦ. Чи буде він відтворений успішно на другій ТКЦ залежить від того, чи ідентичні Інтерфейси Користувача для обох ТКЦ. Потрібно розуміти, що система даного винаходу вище була описана застосовно до реалізації, де кожний з окремих комп'ютерів в мережній архітектурі настроєний так, щоб імітувати поведінку одного іншого комп'ютера. За допомогою виконуваної оператором візуальної перевірки, яка порів 21 нює реакції кожної системи, надається можливість визначати, чи діє кожна система коректно. Даний винахід також може працювати в іншій конфігурації - в режимі точної відповідності. У режимі точної відповідності використання системи по схемі 1-1 схоже з режимом імітації по схемі 1-1 з додаванням того, що кожного разу, коли має місце взаємодія користувача, знімається миттєвий знімок області навколо миші. У цьому випадку як ознака використовується область з розміром 'n x m' пікселів по центру курсору миші, що дозволяє ідентифікувати місце, де відбувається взаємодія користувача. У режимі імітації точні координати миші і позиція курсору передаються в Клієнтську Ціль за допомогою Диспетчерського Сервера. У Тіньовому режимі до цієї інформації додається графіка, зображення опиту, яке зберігається в Диспетчерському Сервері. Інформація в графіку не використовується протягом використання Онлайн схеми 1-1, а використовується протягом застосування Онлайн Тіні 1-множина, а також протягом відтворення записаного сценарію. Якщо система виконується в цьому режимі, то кожного разу, коли користувач взаємодіє з тестованою системою, генерується графіка, яка зберігається в диспетчерському сервері. Користь зберігання окремої графіки, пов'язаної з кожною керуючою послідовністю, очевидна в конфігурації відтворення і, зокрема, в конфігурації відтворення, де записаний сценарій відтворюється на системі, яка фізично відрізняється (фізичні відмінності можуть включати в себе, але не обмежуються перерахованим, зміни розкладки інтерфейсу користувача і зміни розділення екрана), але яка повинна бути сконфігурована ідентично вихідній системі, яка служила для запису. Режим Точної Відповідності може розглядатися як окремий випадок Тіньового Режиму. Послідовність подій, які мають місце, коли користувач передає введення в керуючу ТКЦ в Тіньовому Режимі, має наступний вигляд: - Користувач застосовує введення в керуючу ТКЦ. - ТКП генерує інформацію зображення опиту для цього введення. - За допомогою ТКП введення користувача і інформація зображення опиту передаються в ТДС. - Для кожної не керуючої ТКЦ, ТДС запитує миттєвий знімок екрана. - Не керуюча ТКЦ повертає миттєвий знімок екрана в ТДС. - ТДС передає в ТСІ миттєвий знімок екрана ТКЦ разом із зображенням опиту і допоміжною інформацією. - ТСІ намагається знайти екранні координати введення користувача на основі введення, яке ТСІ одержав від ТДС. Це може бути точна відповідність або прийнятна відповідність. - Якщо ТСІ знаходить унікальні координати, то ТСІ передає знайдені координати в ТДС, і ТДС, в свою чергу, передає ці координати в ТКЦ. ТСІ також може передати текст графічного елемента інтерфейсу в ТДС. - ТКЦ вводить координати і інформацію команди в чергу повідомлень операційної системи, 94731 22 щоб взаємодія користувача мала місце в коректній позиції. - Якщо унікальні координати не вдається знайти, то ТСІ запитує у ТДС додаткову допоміжну інформацію. ТДС запитує у ТКП додаткову допоміжну інформацію, і ТКП повертає запитувану інформацію. ТДС передає нову допоміжну інформацію в ТСІ і процес пошуку повторюється. ТКП також може передати зворотно відповідь на скасування цього введення. - Введення користувача з керуючої ТКЦ передається в ТКЦ точно таким же чином, що і в режимі імітації. Протягом відтворення Клієнтський Переглядач виконує наступні кроки: - Зчитується елемент сценарію. - Елемент списку аналізується на предмет дій. - Елемент сценарію аналізується на предмет найменування графічного зображення опиту і допоміжної інформації. Допоміжна інформація може включати в себе текст, що виводиться на графічному елементі інтерфейсу. - ТДС виконує пошук в базі даних перекладацької пам'яті, щоб знайти переклад тексту графічного елемента інтерфейсу. - У ТКЦ за допомогою ТДС посилається запит на зняття миттєвого знімка екрана. - ТКЦ повертає миттєвий знімок екрана в ТДС. - ТДС повертає миттєвий знімок екрана в ТСІ разом із зображенням опиту і допоміжною інформацією. - ТСІ намагається визначити, чи містить миттєвий знімок екрана прийнятний збіг для графічного зображення опиту. - Якщо виявляється прийнятна відповідність, то ТСІ передає знайдені координати в ТДС, і ТДС в свою чергу передає ці координати в ТКЦ. - ТКЦ вводить цю інформацію в чергу повідомлень операційної системи, щоб взаємодія користувача мала місце в коректній позиції. - Якщо прийнятну відповідність не вдається виявити, то ТКП виконує одну з наступних дій: (і) зупинення відтворення і запис прапора помилки в журналі реєстрації; (іі) спроба автоматично надати додаткову допоміжну інформацію; або(ііі) запит допоміжної інформації у користувача. У поточний час аналіз виконується тільки на ТКЦ, і він є функцією Сервера Інтерпретації. Вищеописаний режим точної відповідності корисний для автоматизованого тестування. Деякі з переваг режиму точної відповідності в порівнянні з режимом імітації перераховані нижче. - Додатки або графічні елементи інтерфейсу можуть з'являтися в різних позиціях при кожній обробці. Сценарій режиму імітації не може забезпечити належну роботу в ситуації, коли додаток працює досконало, але елементи не розташовані там, де передбачається їх наявність. - Легко забезпечити роботу додатків, при якій весь екран розміщується на одному і тому ж місці при кожній обробці, таких як багато які мультимедіадодатки. Складно забезпечити роботу, при якій всі інші типи додатків, діючих на множині машин одночасно, розміщуються на одній і тій же позиції при кожному використанні. У режимі імітації пе 23 редбачається, що додатки незмінні при кожному запуску на різних системах. Режим точної відповідності може враховувати відмінності між системами, і в цьому аспекті він краще. - При опиті інтерфейсу користувача менше імовірність виникнення помилок синхронізації в режимі відтворення. Помилки виникають в режимі Точної Відповідності аналогічно режиму Імітації через такі причини, як: - Помилки операційної системи. - Помилки додатка. - Помилки синхронізації сценарію. Коли Клієнтська Ціль не може знайти на екрані цікавлячий графічний елемент інтерфейсу, до якого повинна бути застосована дія, виникає помилка синхронізації сценарію, що може відбуватися через наступні причини: 1. графічний елемент інтерфейсу неунікальний, і існує множина позицій точної відповідності; 2. графічний елемент інтерфейсу відсутній, і позицій точної відповідності не існує. Випадок 1, коли графічний елемент інтерфейсу неунікальний, може мати місце внаслідок помилки програми, або це може відбуватися легітимно. У будь-якому випадку користувач буде повідомлений, що виникла помилка. Користувачеві буде виведений запит втрутитися і визначити деяку інформацію (область екрана), якої буде достатньо, щоб забезпечити унікальність графічного елемента інтерфейсу, або користувач повинен указати, що це дійсно помилка. У першому випадку сценарій продовжить роботу, а в останньому - буде зареєстрована помилка. У випадку 2, коли графічний елемент інтерфейсу відсутній, реєстрація помилки буде виконана автоматично. "Часовий порядок" перетворюється в об'єктивну часову шкалу за допомогою еврістики, керованої на основі швидкості системного процесора, пам'яті і допоміжної інформації, яка визначає, скільки часу зайняло виконання задачі на іншій системі (тобто, коли сценарій був записаний). Під час запису які-небудь проблеми, пов'язані з часом, відсутні, оскільки користувач має всі необхідні візуальні сигнали, і він надає введення тільки тоді, коли додаток генерує відповідний запит. Вище даний винахід був описаний з посиланням на два ілюстративних режими додатка - режим імітації і режим точної відповідності. Нижче іде опис з посиланням на переважний режим роботи - тіньовий режим. У цьому режимі роботи показана на Фіг. 1 система розширяється шляхом додавання ТСІ - серверного модуля інтерпретації, який має інтерфейс з диспетчерським серверним модулем, а також здійснює зв'язок всередині мережі за допомогою протоколу TCP/IP. Серверний модуль інтерпретації діє шляхом одержання записаного тестового сценарію і виконання аналізу цього сценарію по кожному запису автоматичним чином. Для кожного запису він аналізує ім'я миттєвого знімка екрана і координат, в яких мала місце взаємодія користувача. Далі, серверний модуль інтерпретації відкриває даний миттєвий знімок екрана і застосовує множину методів обробки зо 94731 24 браження, щоб сегменту вати зображення на області. У ТСІ вектори ознак витягуються з кожної області і, далі, використовуються для ідентифікації об'єктів з бази даних. Потрібно розуміти, що база даних попередньо заповнюється користувачем, оскільки користувач повинен заповнити базу даних зразками для кожного типу графічного елемента інтерфейсу, який може бути розпізнаний. База даних заповнюється за допомогою вручну наданих прикладів, взятих з тестованої операційної системи. Виконується ручний процес зняття миттєвих знімків екрана і ручної сегментації зображень на об'єкти. База даних заповнюється об'єктами за допомогою, наприклад, технології Великих Двійкових Об'єктів (Binary Large Object Database-BLOB). Для опису зображення може використовуватися опис зображення на рівні об'єктів, нечітка логіка, геометрія об'єктів і XML-схема. Зокрема, опис зображення на рівні об'єктів надає можливість ідентифікації графічного елемента інтерфейсу, який з'являється в координатах з тестового запису. За допомогою інформації з тестового сценарію може бути одержана наступна інформація: - Дія користувача. - Координати на миттєвому знімку екрана, в яких відбулася взаємодія. - Контекст дії користувача. Відомим стає те, на якому графічному елементі інтерфейсу (об'єкті) користувач виконав натиснення. За допомогою опису зображення на рівні об'єктів, наданого серверним модулем інтерпретації, дія користувача і ідентичність об'єкта в заданих координатах надають необхідний контекст для відтворення сценарію. Ще одне застосування з використанням функціональних можливостей, доступних за допомогою серверного модуля інтерпретації, полягає в здатності перетворювати дії, записані через сервер інтерпретації, в "англійську" версію тестового сценарію. Часто це необхідне для розподілу іншим членам тестової організації, які знаходяться поза заданою тестовою групою. Для режиму відтворення можна сформулювати протилежне питання "Де знаходиться заданий графічний елемент інтерфейсу в зображенні?". Надається можливість взяти зображення з відтворення і координати, що вказують, де відбулася взаємодія користувача, і визначити місцеположення графічного елемента інтерфейсу. Те, як буде знайдений графічний елемент інтерфейсу, залежить від режиму, в якому працює користувач - режим Точної Відповідності або Тіньовий режим. З математичної точки зору серверний модуль інтерпретації виконує дві функції: 1. Ідентифікація графічного елемента інтерфейсу в позиції з координатами (х, у); 2. Визначення координат (х, у) заданого графічного елемента інтерфейсу. Ці функції можуть бути виражені таким чином: 1. Object findWidget(point p) {return Object widget}. 2. point findCoordinates(Object widget) {return point p}. Використовуючи архітектуру даного винаходу можна забезпечити можливість одночасного тестування множини машин одним тестуючим фахів 25 цем. Оскільки всі зв'язки між машиноюконтролером, на якій виконується ТКП, і тестованими системами ТКЦ виконуються через диспетчерський сервер ТДС, який транслює прийняті команди в синтаксис і формат, необхідний для тестованої системи, то надається можливість забезпечення інтерфейсу одночасно з множиною операційних систем. При роботі в режимі імітації або режимі Точної Відповідності або Тіньовому режимі, по суті, користувачеві надається можливість передавати дії клавіатури і миші одночасно (псевдо) у всі цільові машини. Система згідно з даним винаходом дозволяє приймати відповідні задачі, які виконуються послідовно, і виконувати їх паралельно. Дана інновація має безпосередній ефект відносно забезпечення якості, деяких аспектів зняття миттєвих знімків екрана і поствиробництва, а також Настільного Видавництва (включаючи графіку для інструкцій і т. п.). Шляхом одночасної взаємодії і візуалізації роботи множини ТКЦ надається можливість значно прискорити виконуване вручну тестування, навіть коли відсутня інтерпретація зображення тестованого інтерфейсу користувача. Потрібно розуміти, що даний винахід був описаний з посиланням на ілюстративні компоненти мережної архітектури, які зручні для розуміння винаходу. Ці приклади здійснення не треба розглядати як обмежувальні, оскільки вони надані виключно для опису роботи згідно з даним винаходом, і об'єм даного винаходу визначається тільки прикладеною формулою винаходу. Кожний з клієнтських модулів перегляду ТКП і клієнтських цільових модулів ТКЦ надані на окремих комп'ютерах в мережі. Незважаючи на те, що переважно диспетчерський серверний модуль ТДС і серверний модуль інтерпретації ТСІ надаються на окремих машинах, щоб вони могли використовувати потужність свого власного виділеного процесора, визначені додатки можуть бути використані в умовах, де один або більше з серверних модулів і клієнтських модулів перегляду працюють на одній машині. Зв'язок між модулями бажано забезпечується за допомогою протоколу TCP/IP. Що стосується комп'ютерів/машин, то також доречне застосування технології VMWare, яка дозволяє даній машині (головному комп'ютеру) одночасно виконувати множину операційних систем (гостьових операційних систем). Ці операційні системи будуть діяти як окремі комп'ютери в мережі, що іноді позначають терміном "віртуалізація комп'ютерів". Клієнтський Переглядач конфігурується так, щоб забезпечити можливість відображення робочого стола систем(и), працюючих на Клієнтському Цільовому модулі. Якщо присутні більше однієї тестованої системи, то в Клієнтському Переглядачі буде по одному вікну для кожної машини. Миттєві знімки екрана усього робочого стола Клієнтської Цілі стискуються в SDT і передаються за допомогою протоколу TCP/IP в Диспетчерський Сервер. Диспетчерський Сервер передає стиснені миттєві знімки екрана в Клієнтський Переглядач, тим часом зберігаючи копію цих миттєвих знімків. Клієнтський Переглядач розархівовує і відображає мит 94731 26 тєві знімки екрана. Частота оновлення, тобто кількість миттєвих знімків екрана, що передаються Клієнтською Ціллю в Клієнтський Переглядач (через Диспетчерський Сервер), за умовчанням становить приблизно 5 кадрів/секунду, і вона може змінюватися користувачем. Частота оновлення належить тільки до миттєвих знімків екрана, що передаються в Клієнтський Переглядач. Присутній окремий потік миттєвих знімків екрана, що знімаються в інші моменти часу за запитом користувача. Після з'єднання машин користувач взаємодіє тільки з Клієнтським Переглядачем, який через диспетчерський сервер передає введені через клієнтський переглядач інструкції в клієнтську ціль. Таким чином, потік інформації протягом сесії мінімізується до рівня особливих дій з клавіатури/миші, які проводяться для кожної взаємодії. Оскільки потік обміну в такому випадку буде набагато меншим, використання смуги пропускання мінімізується і швидкість передачі даних збільшується, так що дії, виконувані в перший момент часу на клієнтському переглядачі, виконуються в клієнтській цілі в режимі псевдореального часу. Крім того, використовуючи систему згідно з даним винаходом, користувачу, що працює на системі з інтерфейсом на англійській мові, надається можливість тестувати інші системи, що працюють з інтерфейсами на інших мовах. Це одночасне керування системою, яка використовує інші мови, має очевидні переваги з точки зору локалізації. Для забезпечення подібної функціональності система діє у вищезазначеному "Тіньовому режимі". Характеристикою деяких графічних елементів інтерфейсу є те, що їх ідентифікуючою ознакою є текст. Це також застосовно до випадку, коли для виявлення в локалізованій операційній системі графічних елементів інтерфейсу, еквівалентних елементам з англійським текстом, необхідна наявність в системі деякого механізму перекладу. База 120А даних в ТСІ 120 заповнюється вмістом пам'яті перекладу для кожної мови, яка буде використовуватися системою. Коли протягом відтворення сценарію або в режимі онлайн знімається миттєвий знімок екрана контролера ТКЦ, він передається в ТСІ для обробки. ТСІ крім ідентифікації графічного елемента інтерфейсу (як описано вище), може також ідентифікувати пов'язаний з цим елементом текст, використовуючи оптичне розпізнавання символів. ТСІ надає в ТДС знайдену інформацію графічного елемента інтерфейсу. ТДС опитує базу даних пам'яті перекладу, щоб знайти переклад тексту графічного елемента інтерфейсу. Пам'ять перекладу повертає переведений текст. ТДС передає в локалізовану ТКЦ запит на зняття миттєвого знімка екрана. Локалізована ТКЦ повертає графічний миттєвий знімок екрана в ТДС. ТДС надає в ТСІ локалізовану графіку миттєвого знімка екрана і інформацію тексту локалізованого графічного елемента інтерфейсу, які потрібно знайти в цільовому зображенні. ТСІ намагається видати координати придатного локалізованого графічного елемента інтерфейсу, на якому повинна бути виконана дія користувача. 27 Додавання функції оптичного розпізнавання символів доповнює функціональні можливості ТДС. У базі даних програмних рядків повинен бути виконаний пошук тексту, який був знайдений на графічному елементі інтерфейсу, щоб знайти його аналог в локалізованій системі. ТДС виконує цей пошук. Текст графічного елемента інтерфейсу і відповідний переклад зберігаються в XML-сценарії як допоміжна інформація. У режимі відтворення або режимі онлайн в ТСІ надається локалізована графіка і локалізований текст, який потрібно знайти на ній, і ТСІ повертає позицію, де виявляється відповідність. Потрібно зазначити, що цей конкретний приклад застосування системи даного винаходу має очевидні переваги при виконанні локалізації - процесу адаптації продукту або служби до визначеної мови, культури і бажаного локального "відчуття і вигляду". В ідеальному випадку продукт або служба розробляються так, щоб мати можливість відносно легко виконати локалізацію, тобто так, щоб продукт був "готовий до локалізації". Наприклад, це може бути виконане шляхом створення ресурсів в програмному забезпеченні, так що текст може бути з легкістю змінений на іншу мову, а також забезпечення деякої області для розширення в цих цілях. Пам'ять перекладу являє собою технологію, яка використовується в області локалізації. Вона являє собою структуру даних, яка надає список всіх фрагментів тексту, який повинен бути переведений, разом з еквівалентними перекладами. Дана технологія надає спосіб, згідно з яким текст 94731 28 може бути механічно переведений. Спочатку структура даних повинна бути заповнена перекладачем, який надає переклад для кожного елемента пам'яті перекладу. Якщо пізніше текст оновлюється додатковим новим вмістом, то перекази, надані раніше, можуть бути механічно відновлені і використані повторно. Подібна структура даних перекладу може бути імпортована в ТСІ і використана в контексті даного винаходу. Незважаючи на те, що даний винахід був описаний з посиланням на конкретні варіанти здійснення і застосування, потрібно розуміти, що вони надані як приклади роботи системи даного винаходу, і даний винахід не треба обмежувати якимнебудь набором прикладів. Також потрібно розуміти, що, якщо у вищевикладеному описі визначені компоненти і функціональні елементи описуються з посиланням на приклад режиму роботи, то подібні компоненти і функціональні елементи можуть бути з легкістю використані в інших прикладах режиму роботи. Отже, кожний описаний приклад роботи не треба розглядати як незалежний приклад, оскільки реалізації або застосування системи даного винаходу можуть включати в себе функціональні елементи або компоненти з інших прикладів архітектури, які тут детально не описані. Використовувані в даному описі терміни «містить/включає в себе» визначають наявність викладених ознак, цілей, етапів або компонентів, але не виключає наявності або додавання однієї або більше інших ознак, цілей, етапів, компонентів або їх груп. 29 94731 30 31 Комп’ютерна верстка А. Крижанівський 94731 Підписне 32 Тираж 24 прим. Міністерство освіти і науки України Державний департамент інтелектуальної власності, вул. Урицького, 45, м. Київ, МСП, 03680, Україна ДП “Український інститут промислової власності”, вул. Глазунова, 1, м. Київ – 42, 01601