Конспект лекцій для студентів напряму підготовки 050102 «Комп’ютерна інженерія» денної та заочної форм навчання



Сторінка3/4
Дата конвертації09.04.2017
Розмір0.59 Mb.
1   2   3   4
ТЕМА: ДОСЛІДНИЦЬКЕ ТЕСТУВАННЯ

Процедура дослідницького тестування

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

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

Дослідницьке тестування – це не метод проектування тестів, а скоріше стратегія зниження ризику в процесі тестування.

Один з методів дослідницького тестування і процедура його застосування для тестування функціональності і стійкості програмних продуктів у середовищі Windows.

Процедура включає наступні кроки.

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

Успіх виконання кроку залежить від наявності інформації про програмний продукт і його потенційних користувачів, а також часу для його вивчення. Для отримання інформації про продукт може використовуватися документація (у тому числі Help), відомості про аналогічні продукти, вивчення продукту шляхом його короткострокового використання. Задачі кроку:

Формування списку функцій (ієрархії функцій).

Розбиття функцій на основні і другорядні. В табл. 7.1 наведено приклад критерію розбиття – за важливістю.

Виявлення областей можливої нестійкості продукту (схильних до відмов функцій і даних).

Таблиця 7.1. Приклад розбиття функцій на основні і другорядні



Визначення

Критерії віднесення

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


1. Функції, що є визначальними для використання продукту за призначенням.

2. Функції, які часто використовують звичайні користувачі в сеансі роботи.

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


Другорядна функція – функція, без якої продукт може використовуватися.

Рідко використовувані функції, відмови при виконанні яких не можуть мати суттєвих наслідків.

Приклади областей можливої нестійкості функцій:

функції обробки зовнішніх подій;

функції, що інтенсивно використовують оперативну пам'ять;

дуже складні функції;

функції, що використовують засоби Windows або змінюють її параметри;

функції, що маніпулюють конфігурацією Windows;

функції аналізу вхідних даних і обробки помилок;

функції, що підміняють базові функції Windows (наприклад, відновлення видалених файлів);

функції або групи функцій, що використовують багато паралельних процесів;

функції, які працюють з багатьма файлами одночасно;

функції, які працюють з файлами, розташованими в мережі.

Приклади областей можливої нестійкості при обробці даних:

документи: довгі, багато одночасно відкритих;

записи: довгі, багато записів, порожні, складні;

списки: довгі, порожні або багатостовпчикові;

поля: введення великої кількості символів; дуже великі значення числових полів;

об'єкти: багато, великі, складні і ін.

Крок 2. Проектування тестів. Визначення стратегій виконання тестів і критеріїв оцінювання результатів (як, наприклад, в табл. 7.2).

Крок 3. Виконання тестів. Виконання тестів, спостереження і фіксація результатів і використання цієї інформації для формування судження про роботу продукту. Задачі кроку:

тестування всіх основних функцій;

тестування ідентифікованих областей потенційної нестійкості;

вибіркове тестування другорядних функцій;

реєстрація відмов;

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

Таблиця 7.2. Приклад критеріїв проходження тестів



Визначення цілі

Критерій проходу

Критерій відмови

Функціональність – здатність продукту виконувати необхідні функції.

Функція виконується у відповідності з її призначенням.

Хоча б одна функція не виконується у відповідності з її призначенням.

Будь-яке неправильне виконання функції не призводить до серйозних наслідків при коректному використанні.

Неправильне виконання призводить до серйозних наслідків навіть при коректному використанні.

Стійкість – здатність продукту функціонувати без відмов при підвищених навантаженнях (часу, пам'яті).


Робота продукту при підвищених навантаженнях не призводить до руйнування Windows.

Робота продукту не призводить до втрати даних, зависання, відмови.

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


Робота продукту руйнує реєстр Windows.

Робота продукту може призвести до втрати даних, зависання, відмови.

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

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

Крок 5. Визначення критерію покриття. В процедурі використовується наступний критерій покриття:

протестовані всі основні функцій;

протестовані вибрані другорядні функції;

протестовані вибрані області можливої нестійкості (слід вибрати від п'яти до десяти функцій і протестувати їх на тестових даних, які можуть привести до нестійкої роботи продукту).

Рекомендований розподіл часу тестування складає: 80% часу – на основні функції, 10% - на другорядні і 10% - на області потенційної нестійкості.

Процедура тестування по даному методу виконується циклічно.




ЛЕКЦІЯ № 8
ТЕМА: ТЕСТУВАННЯ WEB-ЗАСТОСУВАНЬ

Рівні тестування Web-застосування

Web-застосування можна розглядати як клієнт/серверні системи, в яких функціональність реалізується як на серверній, так і на клієнтській стороні, а інтерфейс користувача має стандартизовану архітектуру, в якій:

1) для взаємодії з користувачем використовується Web-браузер;

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

3) для опису інтерфейсу застосовується стандартне представлення;

4) взаємодія між браузером і застосуванням здійснюється по стандартному протоколу (HTTP) і чітко формалізована;

5) функціональність Web-застосування розподілена між віддаленим сервером і клієнтськими комп'ютерами користувачів.

Тестування Web-застосувань проводиться на трьох рівнях:

- інтерфейсу користувача;

- серверу (серверів);

- протоколів їх взаємодії.

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



Функціональне тестування

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

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

В табл. 8.1 наведені типові питання для перевірки зручності застосування інтерфейсу Web-сайту, який є корисними для планування тестування (на основі опублікованого компанією IT-Online).


Таблиця 8.1. Контрольні питання для перевірки зручності Web- застосувань

Архітектура і навігація сайту

Чи відповідає структура сайту цілям, для досягнення яких він призначений?

Чи зрозуміла схема навігації?

Чи можна визначити, в якому місці сайту ви знаходитеся?

Чи легко знайти на сайті потрібну інформацію?

Чи розумною є кількість елементів в панелях навігації?

Чи логічно відсортовані елементи?

Чи відповідають назви гіперпосилань назвам сторінки?

Чи виразно виділені гіперпосилання ?

Чи виразно виділено посилання на головну сторінку?

Чи існує можливість пошуку інформації на сайті?

Чи існує карта сайту?

Чи кожна сторінка дозволяє зрозуміти, на якому сайті ви знаходитеся?

Чи можна управляти навігацією по сайту?

Планування і дизайн сайту

Чи не перевищує розмір сторінки розмір вікна?

Чи повторюється схема планування на всіх сторінках?

Чи існує чіткий фокус на кожній сторінці?

Чи видно візуально планування?

Чи ефективно використовується вирівнювання і угрупування?

Чи достатньо хороший контраст?

Чи не громіздке планування?

Чи подобається вам сайт естетично?

Зміст (контент) сайту

Чи зрозумілі і лаконічні тексти на сайті?

Чи організований текст у вигляді невеликих блоків?

Чи зустрічаються в тексті граматичні і орфографічні помилки і друкарські помилки?

Чи містять сторінки ввідний текст?

Чи підтримують мультимедійні компоненти задачі користувача?

Чи зрозумілі одиниці вимірювання, використовувані на сайті?

Чи присутні на сайті час і дата створення сторінок?

Чи присутні на сайті номери контактних телефонів?

Чи присутні на сайті адреси з поштовими індексами?

Форми і взаємодія

Чи відповідають форми задачам користувача?

Чи підтримують діалоги логічну послідовність кроків?

Чи очевидна кнопка або посилання для переходу до наступного кроку діалогу?

Чи всі елементи форм використовуються за призначенням?

Чи згруповані елементи форми за призначенням?

Чи зрозуміло виглядає кнопка відправки форми?

Графіка

Чи прийнятна якість використовуваної графіки ?

Чи всі графічні елементи мають альтернативні текстові надписи?

Чи містять графічні елементи інформацію про розмір файла?

Чи оптимізовані графічні елементи для передачі по Інтернету?

Чи реагують графічні елементи на рухи мишки?

Чи використовується анімація? Чи прийнятний об'єм графічних файлів?

Кольори

Чи вдалим є вибір кольорів для сайту?

Чи не дуже багато кольорів?

Чи використовуються кольори логічно і послідовно?

Чи адекватно розрізняються кольори в чорно-білому режимі?

Оформлення тексту

Чи зрозумілі тексти?

Чи прийнятний розмір шрифту?

Чи має шрифт відповідний колір і чи достатньо він контрастний?

Чи відформатовано текст таким чином, щоб в рядку було від 10 до 12 слів?

Чи достатня ширина поля навкруги тексту?

Стійкість до помилок

Чи повинен користувач що-небудь запам'ятовувати, переходячи між сторінками?

Чи виникає попередження при спробі здійснення дій, які не можна відмінити?

Чи можна відмінити ризиковані дії?

Чи перехоплюються помилки, що виникають, без звернення до серверу?

Чи містять сторінки з повідомленнями про помилки корисну інформацію?

Чи містять сторінки з порожніми результатами пошуку поради стосовно розширення умов пошуку?

Чи існує система контекстної допомоги (довідки)?

Чи структурована допомога по задачах користувача? Чи пояснює вона користувачу, як виконати ту або іншу дію?

Платформа і особливості реалізації

Чи достатньо швидко відбувається завантаження сторінок (від 3 до 15 секунд)?

Чи всі гіперпосилання працюють правильно?

Чи існують пошкоджені графічні елементи?

Чи написаний текст на сторінках так, щоб його могли знайти пошукові системи?

Чи працює сайт з різними браузерами користувача?

Чи працює сайт на моніторах з високою і низькою роздільною здатністю?

Чи використовуються нестандартні plug-іn? Чи є вони необхідними і корисними?


Тестування технічних характеристик сайту

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

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

Так, в запропонована методологія систематичного тестування, що охоплює наступні аспекти перевірки:

1. Ідентифікація оточення web-застосування. Включає аналіз інформації про використовувані мови скриптів, Web-сервер, операційну систему. Для отримання такої інформації рекомендується:

проаналізувати відгук на HTTP-запити HEAD і OPTIONS (із заголовка або будь-якої сторінки, що містить рядок SERVER);

досліджувати формат і текст інформації про 404-й помилку серверу (і інших). Деякі системи часто дозволяють взнати версії використовуваних мов. Можна навмисно запитати сторінки, що призводять до подібних помилок, а також використати альтернативні методи запиту (POST, PUT і т.п.) для отримання інформації з серверу;

перевірити типи файлів/розширення/каталоги. Багато Web-серверів по-різному реагують на запити файлів з підтримуваними і невідомими розширеннями. Слід спробувати запитати файли із стандартними розширеннями, такими як “.ASP” “.HTM” “.PHP” “.EXE”, і стежити за появою якого-небудь незвичайного результату або кодів помилок;

перевірити початкові тексти доступних сторінок. Початковий текст сторінки, згенерований Web-застосуванням, може вказувати на використовуване програмне оточення;

спробувати спотворити вхідні дані для отримання помилок в скриптах. Це також дозволить отримати інформацію про оточення Web- застосування;

використовувати сканування TCP/ICMP і сервісів. Для цього рекомендується використовувати аналізатори застосувань (зокрема, WebServerFP).

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

3. Визначення механізмів аутентифікації. Необхідно перевірити, як вибраний механізм застосовується до кожного ресурсу, використовуваного Web- застосуванням. Для цього слід спробувати отримати доступ до всіх ресурсів через кожну точку входу. Багато Web-систем пропонують засоби підтримки сесій, засновані на збереженні в cookie або Session-ІD псевдоунікального рядка, що характеризує їх статус. В тому випадку, якщо даний рядок є простим хешем або рядком, складеним з відомих елементів, система може виявитися вразливою до таких видів атаки, як, наприклад, прямий перебір, повторна відправка, або спроба відновлення.

Деякі особливості тестування Web-застосувань пов'язані з процесом розробки. Як правило, для створення Web- застосувань використовуються методи «прискореної» розробки, в яких:

тестування вбудовано в ЖЦ і виконується паралельно з розробкою;

невеликі проектні групи (або один Web-дизайнер);

активна участь замовника (не завжди можливо);

дуже стислі терміни розробки версій обмежують час на ретельне планування і виконання тестування;

фаза інтеграції Web- застосування звичайно відсутня (немає інтеграційного тестування) тому основна увага приділяється функціональному тестуванню застосувань в модельованому середовищі і системному – в реальному середовищі;

стадія супроводу і розвитку – невід'ємна частина ЖЦ, отже, необхідне постійне регресійне тестування.

Стислі терміни тестування приводять до необхідності його автоматизації. Особливо це стосується тестування продуктивності і надійності серверу.
ЛЕКЦІЯ № 9
ТЕМА: АНАЛІЗ РЕЗУЛЬТАТІВ ТЕСТУВАННЯ

Система відстежування проблем

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

Цілі системи відстежування проблем:

відстежування стану тестування і усунення дефектів;

організація взаємодії між членами команди і вирішення спірних питань щодо класифікації і пріоритетів усунення дефектів;

визначення причин дефектів і виявлення «вузьких місць» в процесах розробки і тестування.

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

Структура звіту про проблему

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

Звіт про проблему

1. Ідентифікатор звіту:_____________2. Ідентифікатор паспорта об'єкту____________

3. Ідентифікатор тесту __________________________

4. Дата: ___________5. Час:___________

6. Проект: ____________

7. Програма/Модуль: _______________ 8. Версія: _______________

9. Середовище|середовище| тестування:____________

10. Апаратне середовище|середовище|: ______

11. Рівень тестування: _______________ 12. Цикл:______

13. Симптом: _____________

14. Серйозність (1-4): _________

15. Частота появи: _______

16. Статус (відкрито/закрито): _______________________

17. Опис: _________________________________________

18. Укладач|складач| звіту ____________19. Переданий: ___________________

20. Коментар:

21. Рішення|вирішення|:______________

22. Пріоритет усунення(1-5): _________

23. Розглянуто|розглядало|:________________ Дата_________

24. Перевірено_________________ Дата:_________

25. Вважати відхиленим (да/ні): __________________


Процес вирішення проблем, знайдених при тестуванні, можна представити наступною послідовністю кроків.

Крок 1. Відкриття проблеми. При виявленні проблеми тестер складає звіт з проблеми («відкриває проблему») і передає його програмісту для аналізу. При автоматизованому веденні звітів тестер заповнює форму звіту і зберігає інформацію у базі даних.

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

Крок 3. Усунення. Програміст виконує усунення дефекту, повторне автономне тестування і повертає звіт з відміткою «Виправлено» тестеру. При автоматизованому веденні звітів тестер знаходить звіти з цією відміткою в базі даних.

Крок 4. Закриття. Тестер виконує перевірку виправлень і закриває проблему. Закрити звіт про проблему може тільки тестер. При автоматизованому веденні звітів про проблеми вони зберігаються в базі даних для подальшого аналізу, формування звітів, а також для накопичення історичних даних.

Кроки 1 - 4 стосуються відстежування кожного окремого дефекту, але для аналізу результатів і керування процесом тестування використовуються узагальнені і класифіковані дані про дефекти. Цей аналіз і узагальнення виконується менеджером групи тестування і менеджером проекту. Узагальнені дані використовуються також групою якості для аналізу поточного стану проекту.


1   2   3   4


База даних захищена авторським правом ©lecture.in.ua 2016
звернутися до адміністрації

    Головна сторінка