Тестування розгорнутих додатків
Тестування розгортання різних пакетів, створених на етапі розробки, є одним з перших дій на етапі стабілізації. Тестування забезпечує правильну установку і подальше функціонування основних і додаткових додатків. Оскільки основні і додаткові додатки залежать від розгортання образу операційної системи, тестування цих пакетів має бути синхронізоване з тестуванням образу операційної системи. Додаткові відомості про тестування розгорнутих образів см. В розділі під назвою «Виконання лабораторних тестів і пілотне розгортання» (Performing Lab Tests and Pilot Deployment), Керівництва по роботі підгрупи розгортання додатків (Deployment Feature Team Guide.).
Виконайте два типи тестування для спрощення виділення і усунення проблем з сумісністю.
Модульне тестування Протестуйте окремі функції додатків на чистому комп'ютері, щоб переконатися, що додаткові додатки будуть функціонувати в ідеальному середовищі.
Інтеграційне тестування. Протестуйте окремі функції декількох додатків на комп'ютері, в якому встановлено більшу кількість додатків, щоб найкращим чином відтворити виробничі комп'ютери.
Після проведення тестування учасники підгрупи управління додатками повинні оцінювати і записувати отримані результати. Якщо в процесі тестування виявляються які-небудь проблеми, перш за все необхідно переконатися, що це проблеми із сумісністю, а не з середовищем тестування або існуючим додатком. До прийняття рішення про проблему з сумісністю Windows, завжди необхідно виконати наступні два дії.
Переконатися, що проблема не пов'язана з середовищем тестування. Виникла проблема може бути пов'язана з неполадакамі апаратних засобів, програмного забезпечення або мережевими параметрами, а не сумісністю додатків.
Переконайтеся, що проблема не зачіпає використовувані зараз версії Windows. Проведіть таке ж тестування в тій версії Windows, на базі якої працює додаток в даний момент, щоб переконатися, що воно працює правильно. Якщо при роботі з поточної платформою виникає та ж помилка, вона не пов'язана з проблемами з сумісністю.
Тестування є повторюваним процесом, що включає в себе тестування, виявлення проблем, вирішення проблем і повторне тестування. Етапи цього процесу може змінюватися в залежності від виявлених проблем і способах їх вирішення. Наприклад, проблеми, які вирішуються виправленням сумісності додатків, контролюються інакше, ніж проблеми, які вирішуються зміною вихідного коду або отриманням оновлення від постачальника.
Для тих проблем, які вирішуються за допомогою виправлення сумісності додатків, в етап тестування необхідно включити етап дозволу. Це означає, що після того, як учасники підгрупи управління додатками виявляють проблеми, вони повинні виправити проблеми з сумісністю і провести повторне тестування до тих пір, поки додатки не будуть готові до розгортання. Якщо учасники групи змінюють вихідний код, то зазвичай використовується повторюваний цикл, що включає тестування, налагодження, кодування, перекомпіляцію і повторне тестування. Якщо учасники підгрупи управління додатками не можуть визначити виправлення несумісності додатків для вирішення виниклих проблем і не володіють доступом до вихідного коду, вони можуть звернутися до відповідного постачальника і отримати оновлення для цього додатка.
На рис. 21 представлений процес тестування.
Мал. 21 Процес тестування додатків
Успішне проведення тестування в першу чергу грунтується на виявленні проблем і роздільної здатності. Вирішення цих проблем дуже важливо, а додавання цих проблем в базу знань з можливістю пошуку надасть значну допомогу для рольового кластеру Взаємодія з користувачем при навчанні персоналу служби підтримки. Здатність не тільки виявити проблему і знайти її рішення, але і виправити знайдені неполадки є неоціненною. Крім того, краще передати ці знання іншим людям і допомогти їм стати учасниками процесу, а не зробити цю інформацію надбанням декількох обраних.
Таке розгортання додаткових додатків є лише невеликою частиною проекту, успішна реалізація якого відбивається на кожному учаснику всередині і поза організації. Успішна реалізація дозволяє домогтися визнання, а невдале втілення може зашкодити не тільки репутації поточного проекту, але і всіх наступних.
Часто додатки можуть бути несумісні з іншими додатками, особливо, якщо вони переупаковували. Проведіть тестування на можливі проблеми з сумісністю одним з наступних трьох способів.
Проведіть тестування розгортання програм вручну в лабораторному середовищі. Створіть лабораторне середовище, що включає в себе ряд комп'ютерів з вашої організації. Чим більше ці комп'ютери нагадують реальні клієнтські комп'ютери, тим більш надійним стає процес тестування. В ідеалі учасники підгрупи управління додатками повинні використовувати клони дійсних клієнтських ПК для тестування. Оскільки на комп'ютерах різних користувачів встановлені різні додатки, учасники підгрупи повинні протестувати процес розгортання додатків на різних клієнтських ПК.
Тестування за допомогою інструментів інших компаній. AdminStudio Professional Edition і Wise Package Studio дозволяють моделювати процес установки пакета додатків і повідомляти про всі проблеми, обнаружітьва і вирішувати можливі конфлікти додатків, а також здійснювати контроль якості додатків після їх установки на комп'ютери.
Тестування в процесі поетапного розгортання. Після того, як підгрупа управління додатками протестувала процес розгортання додатків в лабораторному середовищі, вони можуть зробити це на виробничих ПК за допомогою обмеженої, поетапної установки. Таке розгортання повинно проводитися лише на декількох комп'ютерів до тих пір, поки група не переконатися, що новий пакет не робить негативного впливу на ПК.
Стратегії усунення несправностей
Перевірка пакетів
Рекомендує перевіряти нові або заново встановлюються пакети до їх первісного розгортання. Підгрупа управління додатками може використовувати більшість засобів розробки установника Windows для перевірки пакетів. Наприклад, для перевірки пакетів за допомогою засобу Orca, включеного в пакет SDK інсталятора Windows, виконайте команду Validate в менюTools.
Більшості засобів розробки установника Windows для перевірки пакетів використовують обробник внутенних узгодженості ICE (Internal Consistency Evaluator). ICE є діями користувача, написаними на VBScript, Microsoft JScript® або у вигляді DLL-або EXE-файлів. При запуску ICE перевіряє базу даних пакетів, щоб виявити елементи, які окремо функціонують нормально, але можуть викликати проблеми при використанні в рамках всієї бази даних.
Вирішення ICE повертають чотири види повідомлень.
Інформаційні. Інформаційні повідомлення надають інформацію від ICE і не вказують на наявність проблем в базі даних. Часто інформація відноситься до самого ICE, як, наприклад, короткий опис. Також в цих повідомленнях можуть надаватися відомості про виконання ICE.
Попереджувальні. У предупежденіях повідомляється про засоби розробки бази даних, які, в певних випадках, призводять до неправильного поводження. У попередженнях також може вказуватися на несподівані побічні ефекти розробки бази даних (наприклад, введення двох умов для одного і того ж імені властивості, яке пишеться однаково, проте відрізняється за наявності букв нижнього і верхнього регістру: High і high). Оскільки інсталятор Windows враховує регістр, він сприймає це, як два різних властивості.
Ошібкі.В повідомленнях про помилки вказується про розробку бази даних, які призводять до неправильного поводження. Наприклад, подвійний компонент ідентифікаторів GUID призводить до неправильної реєстрації компонентів установника Windows.
Збої. Повідомлення про збої сповіщають про збої в діях користувачів ICE. Зазвичай збої викликані серйозними помилками в базі даних, яка в результаті не може запускатися ICE.
Event Logging
Журнал подій в Windows XP Professional і Windows Vista надає стандартний централізований спосіб запису важливих подій програмних засобів і устаткування для додатків і операційних систем. Послуга записи в журналі дозволяє зберігати події з різних джерел в одному місці, яке називається журналом подій.
Інсталятор Windows також зберігає записи в журналі подій, який записує події, як:
успішну або невдалу установку, видалення або налагодження продукту.
Помилки, які відбуваються в процесі настройки продукту.
Виявлення пошкоджених даних конфігурації.
Інформація про пропущені компонентах, які змушують проводити налагодження програми.
Якщо в журнал подій заноситься занадто велика кількість інформації, він може переповниться. Якщо це відбувається, інсталятор Windows відображає таке повідомлення: «Файл журналу додатки полон».
Запис у внутрішній журнал
Інсталятор Windows заносить помилки і події в власний внутрішній журнал (LOG-файл), а також в журнал подій. Вирішення проблем, що записується монтажником в ці файли журналів, може допомогти підгрупі управління додатками і користувачам зрозуміти причини помилок в установці.
Спосіб ведення журналу визначається монтажником Windows після вибору режиму запису. Підгрупа управління додатками може використовувати різні способи включення режиму запису в журналі, як-то:
/ L програма командного рядка Msiexec.exe;
За допомогою програми командного рядка / L Msiexec.exe учасники підгрупи управління додатками можуть точно вказати, яку-саме інформацію реєструвати і в якому місці. У табл. 15 описані аргументи ведення журналу при використанні функції командного рядка / L.
Табл. 15 Параметри командного рядка для ведення журналу / L
Заносити в журнал всі відомості, крім параметра V; щоб занести параметр V. вкажіть / L * V
Щоб створити стандартний файл журналу для установки через командний рядок, додайте / L * LOGFILE.NAME у вікні командного рядка Msiexec. Це дозволяє створити стандартний файл журналу з усіма аргументами, за винятком аргументів з параметром командного рядка V. Для журналу з докладною інформацією додайте / L * V LOGFILE.NAME у вікні командного рядка Msiexec. Наведений далі синтаксис є прикладом стандартної команди журналу.
Наведений далі синтаксис є прикладом докладної команди журналу.
Наведений далі синтаксис підтримує докладний ведення журналу при установці без використання інтерфейсу користувача. Файл журналу Program.log знаходиться в кореневому каталозі диска С:
Якщо функція ведення журналу включена постійно або якщо записується інформація про установку, яка не починається з командного рядка (як, наприклад установка на вимогу або самовідновлюється установка), встановіть значення реєстру REG_SZLogging to icewarmup в розділі реєстру HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ Windows \ Installer. Щоб створити докладний журнал, виберіть значення реєстру icewarmupv
Учасники підгрупи управління додатками повинні використовувати цю політику тільки в тому випадку, якщо функція ведення журналу була підключена через командний рядок / L. Якщо в цьому випадку встановлена групова політика, створюється файл журналу в тимчасовій папці з наступним випадковим ім'ям. msi * .x.LOG.
Читання файлу журналу
Припустимо, що для запуску програми використовується наступна команда:
Послідовність припинена для подальшого відновлення.
Стратегії усунення несправностей
Якщо підгрупа управління додатками використовує користувальницький інтерфейс для установки ПО, і установка не вдається, повідомлення про помилку вказує на причину невдачі. Якщо включена функція ведення докладного журналу, учасники групи можуть отримати додаткову інформацію про помилку в журналі. Файл журналу може допомогти визначити причину проблеми.
Якщо сталася помилка була внутрішньої, то документація про конкретний коді помилки міститься в Windows Installer SDK. Зазвичай внутрішні помилки виникають в результаті проблем з пакетами або служби установки Windows.
Повідомлення про помилки
Почніть з пошуку помилки в слові в файлі журналу установника Windows Installer. Якщо після помилки слід номер, значення повідомлення про помилку потрібно шукати в розділі «Microsoft Windows Installer Error Messages» файлу довідки Msi.chm, включеного в Windows Installer SDK. У файлі журналу за номером помилки визначте, в якому розділі сталася помилка: при записи реєстру або копіюванні файлу.
Оскільки інсталятор Windows не відображує всі повідомлення про помилку і деякі повідомлення не потрапляють в журнали, можливо, підгрупі управління додатками доведеться вибрати іншу тактику для виявлення проблеми. Наприклад, незвичайні переривання в штампах часу тверджень журналів можуть допомогти визначити причину проблеми. Такі переривання вказують на затримки в роботі мережі або апаратного забезпечення.
Пам'ятайте, що в докладних журналах міститься більше інформації, наприклад, був чи не був скопійований певний файл.
Примітка Деякі частини представлених далі фрагментів коду були приведені в декількох рядках тільки з метою підвищення зручності читання. Їх слід відображати в один рядок.