Тестування для користувача інтерфейсу

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

РЕФЕРАТ
Тема: "Тестування для користувача інтерфейсу"
По курсу: "Якість програмного забезпечення, тестування на надійність"

Зміст

Введення

1 Функціональне тестування користувацьких інтерфейсів

2 Перевірка вимог до призначеного для користувача інтерфейсу

2.1 Типи вимог до призначеного для користувача інтерфейсу

2.2 тестопригодного вимог до призначеного для користувача інтерфейсу

2.3 Повнота покриття користувальницького інтерфейсу

2.4 Методи проведення тестування користувальницького інтерфейсу, повторюваність тестування користувальницького інтерфейсу

3 Тестування зручності використання користувальницьких інтерфейсів

Висновки

Список використаних джерел


Введення

Частина програмної системи, що забезпечує роботу інтерфейсу з користувачем - один з найбільш нетривіальних об'єктів для верифікації. Нетривіальність полягає у двоякому сприйнятті терміна "призначений для користувача інтерфейс".

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

З іншого боку, призначений для користувача інтерфейс - "обличчя" системи, і від його продуманості залежить ефективність роботи користувача з системою. Фактори, що впливають на ефективність роботи, слабо піддаються формалізації у вигляді конкретних вимог до окремих елементів, проте повинні бути враховані у вигляді загальних рекомендацій та принципів побудови користувальницького інтерфейсу програмної системи. Перевірка інтерфейсу на ефективність людино-машинної взаємодії отримала назву перевірки зручності використання (usability verification; в російськомовній літературі в якості перекладу термінаusability часто використовують слово "практичність").


1. Функціональне тестування користувацьких інтерфейсів

Функціональне тестування користувальницького інтерфейсу складається з п'яти фаз:

а) аналіз вимог до призначеного для користувача інтерфейсу;

б) розробка тест-вимог і тест-планів для перевірки користувальницького інтерфейсу;

в) виконання тестових прикладів та збір інформації про виконання тестів;

г) визначення повноти покриття користувальницького інтерфейсу вимогами;

д) складання звітів про проблеми у випадку розбіжності поведінки системи і вимог або в разі відсутності вимог на окремі інтерфейсні елементи.

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

Так, тест-плани для перевірки користувальницького інтерфейсу, як правило, представляють собою сценарії, описують дії користувача при роботі з системою. Сценарії можуть бути записані або на природному мовою, або на формальній мові будь-якої системи автоматизації користувальницького інтерфейсу. Виконання тестів при цьому виробляється або оператором в ручному режимі, або системою, яка емулює поведінка оператора.

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

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

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


2. Перевірка вимог до призначеного для користувача інтерфейсу

2.1 Типи вимог до призначеного для користувача інтерфейсу

Вимоги до інтерфейсу можуть бути розбиті на дві групи:

- Вимоги до зовнішнього вигляду користувальницького інтерфейсу і форм взаємодії з користувачем;

- Вимоги щодо доступу до внутрішньої функціональності системи за допомогою інтерфейсу користувача.

Іншими словами, перша група вимог описує взаємодію підсистеми інтерфейсу з користувачем, а друга - з внутрішньою логікою системи.

До першої групи можна віднести наступні типи вимог.

• Вимоги до розміщення елементів управління на екранних формах

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

Кожне вікно додатку повинно бути розбите на три частини: рядок меню, робоча область і статусний рядок. Рядок меню повинна бути горизонтальною і притиснутою до верхньої частини вікна, статусний рядок повинна бути горизонтальною і притиснутою до нижньої частини вікна, робоча область повинна знаходитися між рядком меню і статусної рядком і займати всю решту площу вікна.

Під час тестування даної вимоги досить визначити, що в кожному вікні системи дійсно присутні три частини, які розташовані та притиснуті згідно вимогам навіть при зміні розмірів вікна, його згортання / розгортанні, переміщенні по екрану, при перекритті його іншими вікнами.

Прикладом вимог щодо розміщення конкретного елемента може служити наступне:

Кнопка "Почати передачу" повинна знаходитися безпосередньо під рядком меню в лівій частині робочої області вікна.

При тестуванні такої вимоги також необхідно визначити, чи зберігається розташування елемента при зміні розміру вікна, а також при використанні елемента (в даному випадку - при натисненні).

• Вимоги до змісту та оформлення виведених повідомлень

Вимоги до змісту та оформлення виведених повідомлень визначають текст повідомлень, що виводяться системою, його шрифтове і кольорове оформлення. Також часто в таких вимогах визначається, в яких випадках виводиться те чи інше повідомлення.

Так, наприклад, для тестування вимоги

Повідомлення "Неможливо відкрити файл" має виводитися в статусну рядок притиснутим до лівого краю, червоним кольором, напівжирним шрифтом у разі недоступності файлу, що відкривається з читання.

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

Однак у разі тестування вимоги виду

Повідомлення про помилки повинні виводитися в статусну рядок притиснутими до лівого краю червоним кольором напівжирним шрифтом.

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

• Вимоги до форматів введення

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

До другої групи відносяться такі типи вимог.

• Вимоги до реакції системи на введення користувача

Даний тип вимог визначає зв'язок внутрішньої логіки системи та інтерфейсних елементів. Наприклад,

При натисканні кнопки "Скидання" значення таймера синхронізації передачі має скидатися в 0.

Для перевірки такої вимоги в тестовому прикладі повинно бути земітовано натискання на кнопку "Скинути", після чого повинна проводитися перевірка значення таймера. Однак деякі вимоги визначають в якості реакції системи не те, як змінюється її внутрішній стан, а реакцію користувальницького інтерфейсу. Наприклад, у вимозі

При натисканні кнопки "Відкладений скидання" має виводитися вікно "Введення значення часу для відкладеного скидання".

Як реакція на використання одного інтерфейсного елементу визначається появу іншого інтерфейсного елементу. Такі вимоги перевіряються за допомогою імітації введення користувача й аналізу з'являються інтерфейсних елементів.

• Вимоги до часу відгуку на команди користувача

В якості окремого типу вимог можна виділити вимоги до часу відгуку системи на різні користувальницькі операції. Це пов'язано з тим, що підсвідомо користувач сприймає операції тривалістю більше 1 секунди як тривалі. Якщо в цей момент система не повідомляє користувачеві про те, що вона виконує будь-яку операцію, користувач почне вважати, що система зависла або працює в невірному режимі. У зв'язку з цим або кожне граничний час відгуку має бути зазначено у вимогах і призначеної для користувача документації, або під час тривалих операцій повинні виводитися інформаційні повідомлення (наприклад, індикатор прогресу). Значення граничного часу і рівномірність збільшення значень індикатора прогресу повинні перевірятися відповідними тестами.

2.2 тестопригодного вимог до призначеного для користувача інтерфейсу

Деякі вимоги до призначеного для користувача інтерфейсу можуть виявитися тестонепрігоднимі, або їх тестування буде значно ускладнено. До таких вимог в першу чергу відносяться вимоги, що описують суб'єктивні характеристики інтерфейсу, які не можуть бути точно визначені або виміряні при виконанні тестових прикладів. При аналізі вимог до інтерфейсу необхідно чітко уявляти, який елемент інтерфейсу і яким чином буде перевірятися, яка його характеристика буде вимірюватися в ході тестування.

Прикладом тестонепрігодного вимоги може служити класичне вимога

Інтерфейс користувача повинен бути інтуїтивно зрозумілим.

Без визначення чітких критеріїв інтуїтивної зрозумілості перевірка такої вимоги неможлива. При цьому необхідно розуміти, що критерій в даному випадку може бути двох видів: детермінованим або імовірнісним. Прикладом детермінованого критерію може бути додаток до вимоги виду

Під інтуїтивною зрозумілістю інтерфейсу розуміється доступність будь-якої функції системи за допомогою не більше ніж 5 клацань миші по інтерфейсним елементам.

Вимога з таким уточненням піддається як ручному, так і автоматизованого тестування, більше того, результат такого тестування не буде залежати від суб'єктивної думки тестувальника (поняття про інтуїтивної зрозумілості у всіх різні).

Прикладом імовірнісного критерію може бути таке доповнення:

Під інтуїтивною зрозумілістю інтерфейсу розуміється, що користувач звертається до керівництва користувача не частіше, ніж раз на п'ять хвилин на етапі навчання і не частіше, ніж раз на 2 години на етапі активного використання системи. Значення повинні бути отримані на репрезентативній вибірці користувачів не менше 1000 чоловік.

Перевірка вимоги з таким доповненням не є завданням класичної верифікації і відноситься вже скоріше до перевірки зручності застосування користувальницького інтерфейсу. Проте тут також запроваджується чіткий критерій, при використанні якого результати тестування можуть бути відтворені.

2.3 Повнота покриття користувальницького інтерфейсу

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

- Функціональне покриття - покриття вимог до призначеного для користувача інтерфейсу;

- Структурний покриття - для забезпечення повного структурного покриття кожен інтерфейсний елемент повинен бути використаний в тестових прикладах хоча б один раз;

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

- Структурний покриття з урахуванням стану елементів інтерфейсу і внутрішнього стану системи - поведінка деяких інтерфейсних елементів може змінюватися в залежності від внутрішнього стану системи. Кожне таке помітне поведінка інтерфейсного елемента має бути перевірено. Наприклад, система може мати два режими роботи - нормальний і для початківців, в якому натискання кожного елемента супроводжується появою підказки. У цьому випадку потрібно перевірити обидва режиму і при цьому перевірити, що підказки з'являються лише в режимі для початківців.

При визначенні ступеня покриття необхідно враховувати, що реакція на деякі інтерфейсні елементи визначається не програмною системою, а на рівні операційної системи або середовища виконання. Так, наприклад, реакція на використання багатьох інтерфейсних елементів стандартного діалогового вікна відкриття файлу визначається операційною системою і може не тестуватися.

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


2.4 Методи проведення тестування користувальницького інтерфейсу, повторюваність тестування користувальницького інтерфейсу

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

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

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

При цьому ручне тестування має й істотний недолік - для його проведення потрібні значні людські і тимчасові ресурси. Особливо сильно цей недолік проявляється при проведенні регресійного тестування і взагалі будь-якого повторного тестування - на кожній ітерації повторного тестування користувальницького інтерфейсу потрібна участь тестувальника-оператора. У зв'язку з цим в останнє десятиліття набули поширення засоби автоматизації тестування користувальницького інтерфейсу, знижують навантаження на тестувальника-оператора.

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

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

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

І при передачі інформації до testing інтерфейс, і при отриманні інформації для аналізу можуть використовуватися два способи доступу до елементів інтерфейсу:

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

- За ідентифікатором, при якому доступ до елемента здійснюється за допомогою отримання інтерфейсного елементу за допомогою його унікального ідентифікатора в межах вікна.

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

Другий метод автоматизації тестування більш стійкий до зміни розташування інтерфейсних елементів, але зміни тестових прикладів можуть знадобитися і тут у разі зміни логіки роботи інтерфейсних елементів. Наприклад, нехай у першій версії системи при натисканні на кнопку "Передати дані" передача даних починалася відразу і виводилася вікно з індикатором прогресу. Сценарій тестового прикладу в цьому випадку включає в себе імітацію натискання на кнопку і звернення до індикатора прогресу для отримання значення прогресу у відсотках.

Якщо у другій версії системи після натискання на кнопку "Передати дані" спочатку виводиться вікно "Ви впевнені?" із кнопками "Так" і "Ні", то для перевірки роботи індикатора прогресу в тестовий сценарій необхідно додати імітацію натискання кнопки "Так".

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


3. Тестування зручності використання користувальницьких інтерфейсів

Зручність використання користувальницького інтерфейсу (usability) - показник його якості, який визначає кількість зусиль, необхідних для вивчення принципів роботи з програмною системою за допомогою даного інтерфейсу, її використання, підготовки вхідних даних та інтерпретації вихідних. Інакше кажучи, зручність використання визначає ступінь простоти доступу користувача до функцій системи, які надаються безпосередньо людино-машинний (призначений для користувача) інтерфейс.

Тестування зручності використання користувальницького інтерфейсу, взагалі кажучи, не відноситься до класичних методів тестування програмних систем. Спеціаліст з тестування користувальницького інтерфейсу повинен поєднувати в собі знання як у сфері програмної інженерії, так і у фізіології, психології та ергономіки.

На зручність використання користувальницького інтерфейсу впливають такі фактори:

- Легкість навчання - чи швидко людина вчиться використовувати систему;

- Ефективність навчання - чи швидко людина працює після навчання;

- Запам'ятовуваність навчання - чи легко запам'ятовується все, чому людина навчилася;

- Помилки - чи часто людина припускається помилок у роботі;

- Загальна задоволеність - чи є загальне враження від роботи з системою позитивним.

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

Виділяють наступні етапи тестування зручності використання користувальницького інтерфейсу [1].

а) Дослідницьке - проводиться після формулювання вимог до системи і розробки прототипу інтерфейсу. Основна мета на цьому етапі - провести високорівневе обстеження інтерфейсу і з'ясувати, чи дозволяє він з достатнім ступенем ефективності вирішувати задачі користувача.

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

в) валідаційної - проводиться ближче до етапу завершення розробки. На цьому етапі проводиться аналіз відповідності інтерфейсу програмної системи стандартів, що регламентує питання зручності інтерфейсу (наприклад ISO 13407 [2], ISO 9126 [3]), проводиться загальне тестування всіх компонентів для користувача інтерфейсу з точки зору кінцевого користувача. Під компонентами інтерфейсу тут розуміється як його програмна реалізація, так і система допомоги і керівництво користувача. Також на даному етапі перевіряється відсутність дефектів зручності використання інтерфейсу, виявлених на попередніх етапах.

г) Порівняльне - даний вид тестування може проводитися на будь-якому етапі розробки інтерфейсу. У ході порівняльного тестування порівнюються два чи більше варіантів реалізації призначеного для користувача інтерфейсу.

Як правило, при тестуванні зручності використання користувальницького інтерфейсу використовуються деякі евристичні критерії і характеристики, які замінюють точні оцінки в класичному тестуванні програмних систем.

Наприклад, Якоб Нільсен у своїй роботі [4] виділив 10 евристичних характеристик зручного для користувача інтерфейсу, які з його точки зору повинні перевірятися при тестуванні зручності використання інтерфейсу.

- Спостережуваність стану системи. Система завжди повинна сповіщати користувача про те, що вона в даний момент робить, причому через розумні проміжки часу.

- Співвіднесення з реальним світом. Термінологія, використана в інтерфейсі системи повинна співвідноситися з призначеним для користувача світом, тобто це повинна бути термінологія проблемної області користувача, а не технічна термінологія.

- Користувача керування і свобода дій. Користувачі часто обирають окремі інтерфейсні елементи і використовують функції системи помилково. У цьому випадку необхідно надавати чітко певний "аварійний вихід", за допомогою якого можна повернутися до попереднього нормального стану. До таких "аварійних виходів" відносяться, наприклад, функції відкоту і зворотного відкоту.

- Цілісність і стандарти. Для позначення одних і тих же об'єктів, ситуацій і дій повинні використовуватися однакові слова у всіх частинах інтерфейсу. Більш того, термінологія повідомлень в інтерфейсі повинна враховувати угоди конкретної платформи.

- Допомога користувачам в розпізнаванні, діагностики та усунення помилок. Повідомлення про помилки повинні бути написані на природній мові, а не замінюватися кодами помилок. Повідомлення про помилки повинні чітко визначати суть проблеми і пропонувати її конструктивне рішення.

- Запобігання помилок. Продуманий дизайн користувальницького інтерфейсу, що запобігає появі помилок користувача, завжди краще добре продуманих повідомлень про помилки. При проектуванні інтерфейсу необхідно або повністю усунути елементи, в яких можуть виникати помилки користувача, або перевіряти введення користувача в цих елементах і повідомляти йому про потенційно можливе виникнення проблеми.

- Розпізнавання, а не згадування. При створенні інтерфейсу необхідно мінімізувати навантаження на пам'ять користувача, роблячи об'єкти, дії і опції ясними, доступними і явно видимими. Користувач не повинен запам'ятовувати інформацію при переході від одного діалогового вікна до іншого. У всіх необхідних місцях повинні бути доступні контекстні інструкції з використання інтерфейсу.

- Гнучкість і ефективність використання. В інтерфейсі повинні бути передбачені гарячі клавіші (не обов'язкові до використання починаючим користувачем) - вони часто значно прискорюють роботу досвідченого користувача. Іншими словами, система повинна надавати два способи роботи - для новачків і для досвідчених користувачів. Бажано при цьому давати можливість користувачу автоматизувати часто повторювані дії.

- Естетичний і мінімально необхідний дизайн. Вікна не повинні містити не стосується справи або рідко використовувану інформацію. Кожен інтерфейсний елемент, що містить марну інформацію, грає роль інформаційного шуму і відволікає користувача від дійсно корисних інтерфейсних елементів.

- Допомога та документація. Незважаючи на те, що в ідеальному випадку краще, коли системою можна користуватися без документації, така все одно необхідна - як у вигляді системи допомоги, так і, можливо, у вигляді друкованого керівництва. Інформація в документації повинна бути структурована таким чином, щоб користувач міг легко знайти потрібний розділ, присвячений розв'язуваної їм завдання. Кожен такий орієнтований на конкретне завдання розділ повинен крім загальної інформації містити покрокові інструкції для виконання завдання і не повинен бути занадто довгим.

Всі ці евристики можуть використовуватися при тестуванні зручності використання користувальницького інтерфейсу. Досить очевидно, що при тестуванні зручності слабо застосовні способи автоматизації тестування за допомогою сценаріїв і подібні методи. Один з найбільш ефективних методів перевірки інтерфейсу на зручність - використання формальної інспекції. Питання в бланку інспекції можуть бути як загального характеру (так, наприклад, можна використовувати в якості питань перераховані вище 10 евристик), так і цілком конкретними. Наприклад, в роботі [5] наводиться список контрольних питань, які бажано перевіряти при тестуванні зручності використання web-сайтів. З деякими змінами ці питання застосовні і для звичайних віконних інтерфейсів.


Висновки

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

Тест-плани для перевірки користувальницького інтерфейсу, як правило, представляють собою сценарії, описують дії користувача при роботі з системою. Сценарії можуть бути записані або на природному мовою, або на формальній мові будь-якої системи автоматизації користувальницького інтерфейсу. Виконання тестів при цьому виробляється або оператором в ручному режимі, або системою, яка емулює поведінка оператора.

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

Як правило, при тестуванні зручності використання користувальницького інтерфейсу використовуються деякі евристичні критерії і характеристики, які замінюють точні оцінки в класичному тестуванні програмних систем.


Список використаних джерел

1. Burnstein I Practical Software Testing. A process-oriented approach Springer-Verlag, New York, 2003, - 732 p

2. ISO 13407:1999. Human-centred design processes for interactive systems International Organization for Standardization. 01-Jun-1999, 26 p.

3. SO / IEC 9126-1:2001. Software engineering - Product quality - Part 1: Quality model International Organization for Standardization / International Electrotechnical Commission. 01-Jun-2001, 25 p

4. Nielsen J Ten Usability Heuristics

5. Загальний оціночний лист тестування usability web-сайту

6. http://www.intuit.ru

Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Реферат
71.6кб. | скачати


Схожі роботи:
Організація інтерфейсу користувача
Основні принципи розробки графічного інтерфейсу користувача
Форми для одержання інформації від користувача Опис основних тегів для встановлення та використ
Використання інтерфейсу Centronics для керування зовнішніми пристроями
Інструменти необхідні для тестування Linux
Використання компютерів для тестування в компютерному класі
Програма для тестування знань з дисципліни Програмування на мові С 2
Програма для тестування знань з дисципліни Програмування на мові С
Сервісне програми для обслуговування дисків форматування дефрагментації тестування
© Усі права захищені
написати до нас