Розробка комп'ютерних тестів з математики з урахуванням Конструктора Distance Learning Studio. Тестування. Але мені здається, що писати як зазвичай набагато швидше
Викладач у своїй роботі не завжди користується готовими тестами з низки причин, однією з головних серед них є проста відсутність якісно складених тестів різного виду. Тому часто викладачеві необхідно самому розробляти ті чи інші тести, а тому володіти методикою їх складання. Зупинимося на деяких її моментах.
Необхідно знати, що створення стандартизованих тестів – це тривалий та копіткий процес. Впровадженню тестів передує попередня робота щодо їх складання та апробації. При розробці тестів виділяють три складові: теоретичну, практичну та експериментальну (рис.3.1.).
Теоретична частина роботи включає вивчення літератури, на основі якої здійснюється розробка тестів, змісту та вимог програм, підручників. Тут визначається структура тестів, характерні їх особливості, ознаки, якісні показники, виділяються ті методи математичної статистики, які будуть потрібні в експериментальній частині.
У ході реалізації практичного етапу здійснюється виклад інструкцій для тестованого та особи, яка проводить тестування, складання тестових завдань та відповідей до них. Важливе місце у своїй приділяється поэлементному структурно-функциональному аналізу навчального матеріалу. В результаті виділяються елементи знань, умінь та навичок, які необхідні для оволодіння навчальним матеріалом та мають найбільшу застосовність. Отже, тести будуються з урахуванням включення до них основних смислових частин змісту навчання, тобто необхідних понять, визначень, фактів, операцій, алгоритмів. У цьому враховується ступінь сформованості в учнів різних розумових операцій (аналіз, синтез, конкретизація, узагальнення, порівняння тощо.), з вікових особливостей піддослідних. Значна увага приділяється специфіці та характеру типових помилок тестованих, на основі чого складаються варіанти відповідей до тестових завдань.
У процесі практичного етапу розробки тестів відбувається початкова прикидка шкали оцінок, розглядається механізм переведення кількості балів у результуючу оцінку.
На практичному етапі розробляються також інструкції для вчителя та бланки відповідей, що тестуються.
Таблиця 3.1. Технологія проектування дидактичних тестів
|
Теоретичний етап |
Практичний етап |
Експериментальний етап |
|
||
|
||
|
||
|
На основі теоретичного та практичного етапів будується експериментальний етап розробки тестів. Тут оцінюється якість змісту тестів, перевіряється відповідність завдань вимогам тестової форми, виявляються статистичні характеристики розроблених тестів, робляться висновки щодо придатності тестів для намічених цілей.
На експериментальному етапі розробки тесту часто доводиться повертатися до попередніх етапів, тому всі три етапи – теоретичний, практичний та експериментальний – тісно пов'язані між собою та чинять один на одного певний вплив (див. рис.3.1.).
Більш детально технологію розробки дидактичних тестів представлено в таблиці 3.1.
Створення тестів - це тривалий процес, який вимагає роботи колективу фахівців (методистів, психологів, статистів тощо.), і водночас затребуваність тестів, розроблених вчителями-практиками окремо взятого класу, школи досить висока. У зв'язку з цим вчителеві доцільно при розробці тестів дотримуватися наведених нижче рекомендацій.
Пам'ятка викладачеві з розробки тесту
Визначте цілі тестування.
Виділіть знання, вміння, навички, що визначаються програмою і дають інформацію про рівень засвоєння теми або розділу, що розглядається.
Визначте види тестових завдань, що відповідають виділеним знанням, умінням та навичкам.
4. Спрогнозуйте або виділіть труднощі об'єктивні (навчальні) та суб'єктивні (психологічні та методичні) і виявите типові помилки учнів щодо теми, проаналізуйте причини їх виникнення. Використовуйте цю роботу для складання дистракторів до тестових завдань.
Розробте набір тестових завдань для засвоєння теми.
Проведіть експертизу тестових завдань, запропонувавши своїм колегам висловити свою думку про тест.
Проведіть у разі потреби коригування тестових завдань.
Розробте критерії оцінки, методику обробки результатів, побудуйте відповідну шкалу з переведення тестового бала на оцінку шкільної успішності.
Розробіть інструкцію для викладача та інструкцію для учнів щодо роботи з тестом.
Варіант 1
1. Упорядкована послідовність команд (інструкцій) комп'ютера на вирішення конкретної задачи.
A. Властивість програми
B. Програмне забезпечення
C. Постановка задачі
D. Програма
E. Мова програмування
2. З позиції специфіки розробки та виду програмного забезпечення, на які два класи діляться завдання?
A. Позиційні та функціональні
B. Технологічні та функціональні
C. Позиційні та непозиційні
D. Технологічні та параметричні
E. Немає правильної відповіді
3. Якими послідовними діями можна уявити процес створення програм?
A. Програмування, постановка задачі, побудова алгоритму
B. Побудова алгоритму, розв'язання задачі
C. Побудова алгоритму, програмування
D. Програмування, побудова алгоритму, постановка задачі
E. Постановка задачі, побудова алгоритму розв'язання, програмування
4. Постановка задачі – це …
A. упорядкована послідовність команд комп'ютера на вирішення завдань
B. точне формулювання рішення задачі на комп'ютері з описом вхідних та вихідних даних
C. сукупність пов'язаних між собою функцій, завдань управління, за допомогою яких досягається виконання поставлених цілей
D. система точно сформульованих правил
E. Всі відповіді вірні
5. Алгоритм – це …
A. розбиття процесу обробки інформації на простіші етапи
B. завдання, що підлягає реалізації з використанням засобів інформаційних технологій
C. точне формулювання рішення задачі на комп'ютері з описом вхідних та вихідних даних
E. немає правильної відповіді
6. Розбиття процесу обробки інформації на простіші етапи (кроки виконання), виконання яких комп'ютером або людиною не викликає труднощів
A. Дискретність
B. Визначеність
C. Масовість
D. Алгоритм
E. Всі відповіді вірні
7. Виконаність - це …
A. кінцівка дій алгоритму вирішення завдань, що дозволяє отримати бажаний результат за допустимих вихідних даних за кінцеве число кроків
B. розбиття процесу обробки інформації на простіші етапи (кроки виконання), виконання яких комп'ютером або людиною не викликає труднощів
C.Дія алгоритму вирішення завдань, що дозволяє отримати небажаний результат при допустимих вихідних даних за нескінченну кількість кроків
D. система точно сформульованих правил, що визначає процес перетворення допустимих вихідних даних у бажаний результат за кінцеве число кроків
Є. немає правильної відповіді
8. Здійснює розробку та налагодження програм для вирішення функціональних завдань
A. Системний програміст
B. Програміст-аналітик
C. Прикладний програміст
D. Адміністратор
E. Постановник завдань
9. Займається розробкою, експлуатацією та супроводом системного програмного забезпечення, що підтримує працездатність комп'ютера та створює середовище для виконання програм
A. Прикладний програміст
B Програміст-аналітик
C. Системний програміст
D. Адміністратор БД
E. немає правильної відповіді
A. Прикладний програміст
B. Програміст-аналітик
C. Системний програміст
D. Постановник завдань
E. Адміністратор
A. Адміністратор БД
B. Прикладний програміст
C. Постановник завдань
D. Системний програміст
E. всі відповіді вірні
A. Прикладний програміст
B. Програміст-аналітик
C. Системний програміст
D. Кінцевий користувач
E. Немає правильної відповіді
A. Дискретність
B. Економічність
C. Готовність
D. Працездатність
E. Надійність
A. Визначеність
B. Працездатність
C. Надійність
D. Економічність
E. Готовність
A. Економічність
B. Готовність
C. Надійність
D. Визначеність
E. Працездатність
16. Стійкість – …
E. Немає правильної відповіді
A. Стійкість
B. Перезапуск
C. Готовність
D. Надійність
E. Всі відповіді вірні
З яким етапом життєвого циклу програмного продукту пов'язано з алгоритмізацією
18.Процеса обробки даних, деталізацією функцій обробки, розробкою структури ПП, вибором методів та засобів створення програм?
A. Документування
B. Програмування
C. Супровід
D. Проектування
E. немає правильної відповіді
A. Документування
D. Супровід ПП
E. Всі відповіді вірні
20.На якому етапі життєвого циклу програмного продукту складаються необхідні відомості щодо встановлення та забезпечення надійної роботи ПП тощо?
A. Проектування
B. Експлуатація
C. Документування
D. Програмування
E. немає правильного об'єкта
21. Життєвий цикл ПЗ - …
E. Немає правильної відповіді
E. Немає правильної відповіді
B. Процес постачання, процес забезпечення якості, процес верифікації
C. Процес управління, процес створення інфраструктури, процес навчання
E. Процес управління, процес розробки, процес навчання
Процес документування, процес забезпечення якості, процес верифікації
E. немає правильної відповіді
27.На які дві групи ділиться документація, створювана у процесі розробки програмних засобів?
28. Код групи 1 стандарту ЄСПД означає …
A. Загальні положення
D. Резервні групи
E. немає правильної відповіді
29. Код групи 0 стандарту ЄСПД означає …
A. Інші стандарти
B. Резервні групи
C. Основні стандарти
E. Загальні положення
30. ЕСПД – це …
A. комплекс програм, що встановлюють правила розробки документації
B. впорядкована послідовність команд (інструкцій) комп'ютера на вирішення конкретної завдання
C. система точно сформульованих правил
D. система точно сформульованих правил, що визначає процес перетворення допустимих вихідних даних у бажаний результат за кінцеве число кроків
E. комплекс державних стандартів, що встановлюють взаємопов'язані правила розробки, оформлення та обігу програм та програмної документації
31. Розшифруйте ЕСПД
A. Єдиний зв'язок програмної документації
В. Єдина свобода програмної документації
C. Єдина система програмної документації
D. Єдність системної програмної документації
Є. Немає вірної відповіді
32. Навіщо призначено Посібник з управління ПС?
A. Посібник з управління дає коротку характеристику функціональних можливостей ПС
B. Посібник з управління описує повідомлення, що генеруються, коли ПС взаємодіє з іншими системами, і як реагувати на ці повідомлення, також пояснює, як супроводжувати системну апаратуру, якщо вона використовується ПС
C. Посібник з управління слушно наказує, як встановлювати системи в конкретному середовищі
D. Посібник з управління містить необхідну інформацію щодо застосування ПС
E. немає правильної відповіді
33. На які групи поділяються документи, що входять до складу ПС
A. Документація, що допомагає вносити зміни до ПС та документація з супроводу ПС
B. Документи управління розробкою ПС та документація з супроводу ПС
C. Користувальницька документація та документи управління розробкою ПС
D. Документи управління розробкою ПС та користувальницька документація
E. Користувальницька документація ПС та документація з супроводу ПС
34. Документи, які фіксують різні деталі взаємодії між менеджерами та розробниками
A. Стандарти
B. Плани, оцінки, розклади
C. Звіти
D. Робочі документи
E. Нотатки та листування
35. Документи, які містять фіксацію ідей та проблем, що виникають у процесі розробки, опис використовуваних ідей та підходів
A. Звіти
B. Стандарти
C. Плани, оцінки, розклади
D. Робочі документи
Є. Нотатки, листування
36. Документи, створювані менеджерами для прогнозування та управління процесами розробки та супроводу
A. Стандарти
B. Плани, оцінки, розклади
C. Робочі документи
D. Нотатки
E. Звіти
37. Виберіть тип документів, які розпоряджають розробникам, яких принципів, правил, угод вони повинні дотримуватися в процесі розробки ПС
A. Звіти
В. Робочі документи
C. Плани, оцінки, розклади
D. Стандарти
Е. Нотатки та листування
38. Навіщо необхідні документи, які входять до складу ПС?
A. Даний вид документів містить фіксацію ідей і проблем, що виникають у процесі розробки, опис ідей та підходів, що використовуються.
B. Ці документи наказують розробникам, яких принципів, правил, угод вони повинні дотримуватися в процесі розробки ПС
C. Забезпечують зв'язок усередині колективу розробників та між колективом розробників та менеджерами
E. Описують програми як з погляду їх застосування користувачами, так і з точки зору їх розробників та супровідників
39. Навіщо необхідні документи управління розробкою ПС?
A. Описують програми як з погляду їх застосування користувачами, так і з точки зору їх розробників та супровідників
40. B. Забезпечують зв'язок усередині колективу розробників та між колективом розробників та менеджерами
C. Пояснює користувачам, як вони повинні діяти, щоб застосовувати дане ПС
D. Забезпечують зв'язок між самою програмою та вхідними даними
E. немає правильної відповіді
Варіант 2
1. Код групи 2 стандарту ЄСПД означає …
A. Інші стандарти
C. Правила виконання документації розробки
Є. Резервні групи
2. Пояснювальна записка. Вимоги до змісту та оформлення
A. ГОСТ 19.508-79
B. ГОСТ 19.501-78
C. ГОСТ 19.402-78
D. ГОСТ 19.202-78
Е. ГОСТ 19.404-79
3.Технічне завдання. Вимоги до змісту та оформлення
A. ГОСТ 19.203-78
B. ГОСТ 19.201-78
C. ГОСТ 19.106-78
D. ГОСТ 19.404-79
E. немає правильної відповіді
4. Вимоги до програмних документів, виконані друкованим способом
A. ГОСТ 19.105-78
B. ГОСТ 19.106-78
C. ГОСТ 19.201-78
D. ГОСТ 19.101-77
E. ГОСТ 19.301-79
5. Загальні положення
A. ГОСТ 19.101-77
B. ГОСТ 19.002-77
C. ГОСТ 19.001-77
D. ГОСТ 19.001-78
E. Немає правильної відповіді
6. Код групи 9 стандарту ЄСПД означає …
A. Резервні групи
B. Основні стандарти
C. Правила виконання експлуатаційної документації
D. Правила виконання документації супроводу
Є. Немає вірної відповіді
7. Код групи 8 стандарту ЄСПД означає …
A. Інші стандарти
C. Резервні групи
D. Правила звернення програмної документації
Є. Немає вірної відповіді
8. Код групи 7 стандарту ЄСПД означає …
A. Основні стандарти
B. Правила звернення програмної документації
C. Інші стандарти
E. Резервні групи
9. Код групи 6 стандарту ЄСПД означає …
A. Правила звернення програмної документації
В. Загальні положення
C. Правила виконання документації виготовлення
D. Резервні групи
Е. Правила виконання документації супроводу
10. Аналізує та проектує комплекс взаємопов'язаних програм для реалізації функцій предметної галузі
A. Прикладний програміст
B. Програміст-аналітик
C. Системний програміст
D. Постановник завдань
E. Адміністратор
11. Бере участь у процесі створення програм на початковій стадії робіт
A. Адміністратор БД
B. Прикладний програміст
C. Постановник завдань
D. Системний програміст
E. всі відповіді вірні
12. Є основним споживачем програм
A. Прикладний програміст
B. Програміст-аналітик
C. Системний програміст
D. Кінцевий користувач
E. Немає правильної відповіді
13. Властивість системи зберігати у часі у встановлених межах значення всіх характеристик, що визначають здатність системи виконувати необхідні функції в умовах заданих режимів експлуатації
A. Дискретність
B. Економічність
C. Готовність
D. Працездатність
E. Надійність
14. Можливість доступу до послуг АІС з використанням відповідних технологій завжди, коли в ній виникає потреба
A. Визначеність
B. Працездатність
C. Надійність
D. Економічність
E. Готовність
15. Кількість та ступінь зайнятості ресурсів, процесів, ВП, зовнішньої та внутрішньої пам'яті, каналів введення/виводу, терміналів та каналів мережі
A. Економічність
B. Готовність
C. Надійність
D. Визначеність
E. Працездатність
16. Стійкість – …
A. характеризує здатність до безвідмовного функціонування за наявності збоїв
B. можливість доступу до послуг АІС з використанням відповідних технологій завжди, коли в ній виникає потреба
C. Властивість системи зберігати у часі у встановлених межах значення всіх характеристик, що визначають здатність системи виконувати необхідні функції в умовах заданих режимів експлуатації
D. кількість та ступінь зайнятості ресурсів, процесів, ВП, зовнішньої та внутрішньої пам'яті, каналів введення/виводу, терміналів та каналів мережі
E. Немає правильної відповіді
17. Процес забезпечує відновлення нормального функціонування АІС
A. Стійкість
B. Перезапуск
C. Готовність
D. Надійність
E. Всі відповіді вірні
18. З яким етапом життєвого циклу програмного продукту пов'язано з алгоритмізацією процесу обробки даних, деталізацією функцій обробки, розробкою структури ПП, вибором методів та засобів створення програм?
A. Документування
B. Програмування
C. Супровід
D. Проектування
E. немає правильної відповіді
19. З яким етапом життєвого циклу програмного продукту пов'язане з технічною реалізацією проектних рішень та виконання за допомогою обраного інструментарію розробника (алгоритмічні мови та системи програмування тощо)?
A. Документування
B. Проектування структури ПП
C. Програмування, тестування та налагодження
D. Супровід ПП
E. Всі відповіді вірні
20. На якому етапі життєвого циклу програмного продукту складаються необхідні відомості щодо встановлення та забезпечення надійної роботи ПП тощо?
A. Проектування
B. Експлуатація
C. Документування
D. Програмування
E. немає правильного об'єкта
21. Життєвий цикл ПЗ - …
A. безперервний процес, який починається з моменту його повного вилучення з експлуатації та закінчується в момент прийняття рішення про необхідність його створення
B. процес, який починається з моменту його повного опису та закінчується в момент прийняття рішення про необхідність його створення
C. безперервний процес, який починається з моменту прийняття рішення про необхідність його створення та закінчується в момент його повного вилучення з експлуатації
D. процес, що переривається, який починається з моменту написання структури програми і закінчується в момент його повного вилучення з експлуатації
E. Немає правильної відповіді
22. На які групи процесів ділиться структура життєвого циклу ПЗ за стандартом ISO/IEC 12207?
A. Складові, діючі та допоміжні процеси
B. Основні, додаткові та інші процеси
C. Допоміжні, основні та додаткові процеси
D. Основні, допоміжні та організаційні процеси
E. Немає правильної відповіді
23. Основні процеси життєвого циклу ПЗ поділяються на …
A. Процес документування, процес забезпечення якості, процес верифікації
B. Процес постачання, процес забезпечення якості, процес верифікації
C. Процес управління, процес створення інфраструктури, процес навчання
D. Процес придбання, процес постачання, процес розробки*
E. Процес управління, процес розробки, процес навчання
24. Допоміжні процеси життєвого циклу ПЗ поділяються на …
A. Процес документування, процес забезпечення якості, процес верифікації*
B. Процес постачання, процес забезпечення якості, процес верифікації
C. Процес управління, процес створення інфраструктури, процес навчання
D. Процес придбання, процес постачання, процес розробки
E. Процес управління, процес розробки, процес навчання
25. Організаційні процеси життєвого циклу ПЗ поділяються на …
A. Процес управління, процес створення інфраструктури, процес навчання, процес удосконалення
В. Процес документування, процес забезпечення якості, процес верифікації
C. Процес придбання, процес постачання, процес розробки
D. Процес управління, процес створення інфраструктури, процес документування
E. немає правильної відповіді
26. Що має на увазі процес документування?
A. Процес складається з дій та завдань замовника, що набуває ПП
B. Процес охоплює дії та завдання, що виконуються постачальником, який забезпечує замовника ПП
C. Процес забезпечує відповідні гарантії того, що ПЗ у процесі його ЖЦ відповідає заданим вимогам та затвердженим планам
D. Процес охоплює дії та завдання, що виконуються розробником, та охоплює роботи зі створення ПЗ та його компонентів відповідно до заданих вимог
Е. Процес передбачає формалізований опис інформації, створеної протягом ЖЦ ПЗ
27. На які дві групи ділиться документація, створювана у процесі розробки програмних засобів?
A. Документи, що входять до складу ПС та документи, що допомагають вносити зміни до ПС
B. Користувальницька документація та документація з супроводу ПС
C. Документи управління розробкою ПС та документи, що входять до складу ПС
D. Загальна документація та допоміжна документація
E. Документи управління розробкою ПС та документи з супроводу ПС
28. Код групи 1 стандарту ЄСПД означає …
A. Загальні положення
B. Правила виконання експлуатаційної документації
C. Основні стандарти
D. Резервні групи
E. немає правильної відповіді
29. Код групи 0 стандарту ЄСПД означає …
A. Інші стандарти
B. Резервні групи
C. Основні стандарти
D. Правила виконання документації розробки
E. Загальні положення
30. ЕСПД – це …
A. Комплекс програм, що встановлюють правила розробки документації
B. Упорядкована послідовність команд (інструкцій) комп'ютера для вирішення конкретного завдання
C. Система точно сформульованих правил
D. Система точно сформульованих правил, що визначає процес перетворення допустимих вихідних даних у бажаний результат за кінцеве число кроків
E. Комплекс державних стандартів, що встановлюють взаємопов'язані правила розробки, оформлення та обігу програм та програмної документації
31. Код групи 5 стандарту ЄСПД означає …
A. Правила виконання документації розробки
B. Резервні групи
C. Основні стандарти
D. Правила виконання експлуатаційної документації
Є.Правила звернення програмної документації
32. Код групи 4 стандарту ЄСПД означає …
A. Резервні групи
B. Правила виконання документації супроводу
C. Загальні положення
D. Правила виконання документації виготовлення
E. Правила виконання документації розробки
33. Код групи 3 стандарту ЄСПД означає …
A. Правила виконання документації супроводу
B. Правила виконання документації розробки
C. Правила звернення програмної документації
D. Правила виконання документації виготовлення
E. Правила експлуатаційної документації
34. Керівництво програміста
A. ГОСТ 19.506-79
B. ГОСТ 19.404-79
C. ГОСТ 19.505-79
D. ГОСТ 19.604-78
E. немає правильної відповіді
35. Заголовки розділів записують …
A. Терміновими літерами та розміщують по правому краю
B. Строчними літерами та розміщують симетрично щодо правої та лівої меж тексту
C. Великі літери і розміщують по лівому краю
D. З абзацу малими літерами (крім першої великої)
E. Прописними літерами і розміщують симетрично щодо правої та лівої меж тексту
36. Що не входить до більшості програмного документа?
A. Текст документа
B. Перелік скорочень
C. Аркуш змісту
D. Програми
E. Предметний покажчик
37. Інформаційна частина програмного документа містить:
A. Предметний покажчик та лист змісту
B. Лист затвердження та лист змісту
C. Титульний лист та лист затвердження
D. Анотацію та лист змісту
E. Лист затвердження та анотацію
38. Титульна частина програмного документа містить:
A. Титульний лист
B. Аркуш затвердження та титульний лист
C. Титульний лист та анотацію
D. Титульний лист та лист змісту
E. Немає правильної відповіді
39. Де мають бути зазначені вимоги до інформаційних структур на вході та виході та методів рішення, вихідних кодів, мов програмування
A. Вимоги до складу та параметрів технічних засобів
B. Вимоги до функціональних характеристик
C. Вимоги до інформаційної та програмної сумісності
D. Вимоги до надійності
E. Спеціальні вимоги
40. Де мають бути зазначені вимоги щодо забезпечення сталого функціонування, контроль вхідної та вихідної інформації, час відновлення після відмови тощо.
A. Вимоги до функціональних характеристик
B. Вимоги до складу та параметрів технічних засобів
C. Вимоги до надійності
D. Спеціальні вимоги
E. немає правильної відповіді
Паспорт
1 варіант
Строювання № № питання
Қіндидиқтиң дәрежесі
Рівень складності
Дріс жауаби
Правильні відповіді
Тестування програмного забезпечення - це оцінка програмного забезпечення/продукту, що розробляється, щоб перевірити його можливості, здібності та відповідність очікуваним результатам. Існують різні типи методів, що використовуються в галузі тестування та забезпечення якості про них і йтиметься у цій статті.
Тестування програмного забезпечення є невід'ємною частиною циклу програмного забезпечення.
Що таке програмне забезпечення?
Тестування програмного забезпечення - це не що інше, як випробування шматка коду до контрольованих та неконтрольованих умов експлуатації, спостереження за виходом, а потім вивчення, чи відповідає він попередньо визначеним умовам.
Різні набори тест-кейсів та стратегій тестування спрямовані на досягнення однієї загальної мети – усунення багів та помилок у коді, та забезпечення точної та оптимальної продуктивності програмного забезпечення.
Методика тестування
Широко використовуваними методами тестування є модульне тестування, інтеграційне тестування, приймальне тестування та тестування системи. Програмне забезпечення піддається цим випробуванням у порядку.
3) Системне тестування
4) Приймальні випробування
Насамперед проводиться модульний тест. Як нагадує назва, це метод випробування на об'єктному рівні. Окремі програмні компоненти тестуються на помилки. Для цього тесту потрібне точне знання програми та кожного встановленого модуля. Отже, ця перевірка здійснюється програмістами, а чи не тестерами. Для цього створюються тест-коди, які перевіряють, чи поводиться програмне забезпечення так, як замислювалося.
Окремі модулі, які вже були піддані модульному тестуванню, інтегруються один з одним і перевіряються на наявність несправностей. Такий тип тестування насамперед виявляє помилки інтерфейсу. Інтеграційне тестування можна здійснювати за допомогою підходу "згори донизу", дотримуючись архітектурної споруди системи. Іншим підходом є підхід знизу вгору, який здійснюється з нижньої частини потоку управління.
Системне тестування
У цьому тестуванні вся система перевіряється на наявність помилок і багів. Цей тест здійснюється шляхом сполучення апаратних та програмних компонентів усієї системи, а потім виконується її перевірка. Це тестування числиться під способом тестування " чорного ящика " , де перевіряються очікувані користувача умови роботи програмного забезпечення.
Приймальні випробування
Це останній тест, який проводиться перед передачею програмного забезпечення клієнту. Він проводиться, щоб гарантувати, що програмне забезпечення, яке було розроблено відповідає всім вимогам замовника. Існує два типи приймально-здавальних випробувань - те, що здійснюється членами команди розробників, відомо, як внутрішнє приймальне тестування (Альфа-тестування), а інше, яке проводиться замовником, відомо, як зовнішнє приймальне тестування.
Якщо тестування проводиться за допомогою передбачуваних клієнтів, воно називається приймальними тестами клієнта. Якщо тестування проводиться кінцевим користувачем програмного забезпечення, воно відомо, як приймальне тестування (бета-тестування).
Існує кілька основних методів тестування, які формують частину режиму тестування програмного забезпечення. Ці тести зазвичай вважаються самодостатніми у пошуку помилок і багів у всій системі.
Тестування методом чорної скриньки
Тестування методом чорної скриньки здійснюється без будь-яких знань внутрішньої роботи системи. Тестер буде стимулювати програмне забезпечення для користувача середовища, надаючи різні входи і тестуючи згенеровані виходи. Цей тест також відомий як Black-box, closed-box тестування чи функціональне тестування.
Тестування методом білої скриньки
Тестування методом "Білої скриньки", на відміну від "чорної скриньки", враховує внутрішнє функціонування та логіку роботи коду. Для виконання цього тесту тестер повинен мати знання коду, щоб дізнатися точну частину коду, що має помилки. Цей тест також відомий як White-box, Open-Box чи Glass box тестування.
Тестування методом сірої скриньки
Тестування методом сірої скриньки або Gray box тестування, це щось середнє між White Box і Black Box тестуванням, де тестер має лише загальні знання даного продукту, необхідні для виконання тесту. Ця перевірка здійснюється за допомогою документації та схеми інформаційних потоків. Тестування проводиться кінцевим користувачем, або користувачам, які видаються як кінцеві.
Нефункціональні тести
Безпека програми є одним із головних завдань розробника. Тестування безпеки перевіряє програмне забезпечення на забезпечення конфіденційності, цілісності, автентифікації, доступності та безвідмовності. Індивідуальні випробування проводяться з метою запобігання несанкціонованому доступу до програмного коду.
Стрес-тестування є методом, при якому програмне забезпечення піддається впливу умов, що виходять за межі нормальних умов роботи програмного забезпечення. Після досягнення критичної точки отримані результати записуються. Цей тест визначає стійкість усієї системи.
Програмне забезпечення перевіряється на сумісність із зовнішніми інтерфейсами, такими як операційні системи, апаратні платформи, веб-браузери тощо. Тест на сумісність перевіряє, чи сумісний продукт із будь-якою програмною платформою.
Як підказує назва, ця методика тестування перевіряє обсяг коду чи ресурсів, що використовуються програмою під час однієї операції.
Це тестування перевіряє аспект зручності та практичності програмного забезпечення для користувачів. Легкість, з якою користувач може отримати доступ до пристрою, формує основну точку тестування. Юзабіліті-тестування охоплює п'ять аспектів тестування, - навчання, ефективність, задоволеність, запам'ятовування та помилки.
Тести у процесі розробки програмного забезпечення
Каскадна модель використовує підхід "зверху-вниз", незалежно від того, чи використовується вона для розробки програмного забезпечення або для тестування.
Основними кроками, що беруть участь у даній методиці тестування програмного забезпечення, є:
- Аналіз потреб
- Тест дизайну
- Тест реалізації
- Тестування, налагодження та перевірка коду або продукту
- Впровадження та обслуговування
У цій методиці ви переходите до наступного кроку тільки після того, як ви завершили попередній. У моделі використовується не-ітераційний підхід. Основною перевагою даної методики є її спрощений, систематичний та ортодоксальний підхід. Тим не менш, вона має багато недоліків, так як баги та помилки в коді не будуть виявлені до етапу тестування. Найчастіше це може призвести до втрати часу, грошей та інших цінних ресурсів.
Agile Model
Ця методика заснована на виборчому поєднанні послідовного та ітеративного підходу, на додаток до досить великого розмаїття нових методів розвитку. Швидкий та поступальний розвиток є одним із ключових принципів цієї методології. Акцент робиться на отримання швидких, практичних та видимих виходів. Безперервна взаємодія з клієнтами та участь є невід'ємною частиною всього процесу розробки.
Rapid Application Development (RAD). Методологія швидкої розробки додатків
Назва говорить сама за себе. І тут методологія приймає швидкий еволюційний підхід, використовуючи принцип компонентної конструкції. Після розуміння різних вимог даного проекту готується швидкий прототип, а потім порівнюється з очікуваним набором вихідних умов та стандартів. Необхідні зміни та модифікації вносяться після спільного обговорення із замовником або групою розробників (у контексті тестування програмного забезпечення).
Хоча цей підхід має свою частку переваг, він може бути невідповідним, якщо проект великий, складний або має надзвичайно динамічний характер, в якому вимоги постійно змінюються.
Спіральна модель
Як видно з назви, спіральна модель заснована на підході, в якому є ціла низка циклів (або спіралей) із усіх послідовних кроків у каскадній моделі. Після того, як початковий цикл буде завершено, виконується ретельний аналіз та огляд досягнутого продукту або виходу. Якщо вихід не відповідає зазначеним вимогам або очікуваним стандартам, провадиться другий цикл, і так далі.
Rational Unified Process (RUP). Раціональний уніфікований процес
Методика RUP також схожа на спіральну модель, тому вся процедура тестування розбивається на кілька циклів. Кожен цикл складається з чотирьох етапів - створення, розробка, будівництво та перехід. В кінці кожного циклу продукт/вихід переглядається, і далі цикл (що складається з тих же чотирьох фаз) слід за необхідності.
Застосування інформаційних технологій зростає з кожним днем, також важливість правильного тестування програмного забезпечення зросла в рази. Багато фірм містять для цього штат спеціальних команд, можливості яких перебувають на рівні розробників.
Як і процес розробки, процес подальшого тестування програмного забезпечення також слідує певній методології. Під методологією в даному випадку ми розуміємо різноманітні комбінації принципів, ідей, методів та концептів, яких ви вдаєте під час роботи над проектом.
В даний час існує досить велика кількість різноманітних підходів до тестування, кожен зі своїми відправними точками, тривалістю виконання та методами, що використовуються на кожному етапі. І вибір того чи іншого з них може бути досить непростим завданням. У цій статті ми розглянемо різні підходи до тестування програмного забезпечення та поговоримо про їх основні особливості, щоб допомогти вам зорієнтуватися в існуючому різноманітті.
Каскадна модель (Лінійна послідовна модель життєвого циклу)
Каскадна модель (Waterfall Model) є однією з найстаріших моделей, яку можна застосовувати не тільки для розробки або тестування програмного забезпечення, але також практично для будь-якого іншого проекту. Його базовим принципом є послідовний порядок виконання завдань. Це означає, що ми можемо переходити до наступного кроку розробки або тестування лише після того, як попередній був успішно завершений. Ця модель підходить для невеликих проектів і може бути застосована тільки в тому випадку, якщо всі вимоги точно визначені. Головними перевагами цієї методології є економічна ефективність, простота використання та управління документацією.
Процес тестування ПЗ починається після завершення процесу розробки. На цій стадії всі необхідні тести переносяться з юнітів на системне тестування для того, щоб контролювати роботу компонентів як окремо, так і комплексно.
Крім згаданих вище переваг, даний підхід до тестування також має свої недоліки. Завжди існує можливість виявлення критичних помилок у процесі тестування. Це може призвести до необхідності повністю змінити один із компонентів системи або навіть усю логіку проекту. Але подібне завдання неможливе у разі каскадної моделі, оскільки повернення на попередній крок у цій методології заборонено.
Дізнайтесь більше про каскадну модель з попередньої статті.
V-Model (Модель верифікації та валідації)
Як і каскадна модель, методика V-Model базується на прямій послідовності кроків. Основною відмінністю між цими двома методологіями є те, що тестування у цьому випадку планується паралельно з відповідною стадією розробки. Відповідно до цієї методології тестування ПЗ, процес починається як тільки визначені вимоги і стає можливим розпочати статичне тестування, тобто. верифікацію та огляд, що дозволяє уникнути можливих дефектів на пізніх стадіях. Відповідний план тестування створюється для кожного рівня розробки програмного забезпечення, що визначає очікувані результати, а також критерії входу та виходу для даного продукту.
Схема цієї моделі показує принцип поділу завдань на дві частини. Ті, що відносяться до дизайну та розробки, розміщені ліворуч. Завдання, що стосуються тестування програмного забезпечення, розміщені праворуч:
Основні етапи цієї методології можуть змінюватися, проте зазвичай вони включають такі:
- Етап визначення вимог. Приймальний тест відноситься до цього етапу. Його основне завдання полягає в оцінці готовності системи до фінального використання
- Етап, на якому відбувається високорівневе проектування, або High-Level Design (HDL). Цей етап відноситься до системного тестування та включає оцінку дотримання вимог до інтегрованих систем
- Фаза детального дизайну(Detailed Design) паралельна до фази інтеграційного тестування, під час якої відбувається перевірка взаємодій між різними компонентами системи
- Після етапу написання кодупочинається інший важливий крок – юніт-тестування. Дуже важливо переконатися в тому, що поведінка окремих частин та компонентів ПЗ коректна та відповідає вимогам
Єдиним недоліком розглянутої методології тестування є відсутність готових рішень, які можна було б застосувати, щоб позбутися від дефектів ПЗ, виявлених на етапі тестування.
Інкрементна модель
Дана методологія може бути описана як мультикаскадна модель тестування ПЗ. Робочий процес поділяється на кілька циклів, кожен з яких також ділиться на модулі. Кожна ітерація додає певний функціонал ПЗ. Інкремент складається із трьох циклів:
- дизайн та розробка
- тестування
- реалізація.
У цій моделі можлива одночасна розробка різних версій продукту. Наприклад, перша версія може проходити етап тестування у той час, як друга версія знаходиться на стадії розробки. Третя версія в той же час може проходити етап дизайну. Цей процес може тривати до завершення проекту.
Очевидно, що дана методологія вимагає виявлення максимально можливої кількості помилок у тестованому програмному забезпеченні настільки швидко, наскільки це можливо. Так само, як і фаза реалізації, яка вимагає підтвердження готовності продукту до доставки кінцевого користувача. Усі ці фактори суттєво збільшують вагомість вимог до тестування.
Порівняно з попередніми методологіями, інкрементна модель має кілька важливих переваг. Вона гнучкіша, зміна вимог веде до менших витрат, а процес тестування ПЗ є більш ефективним, оскільки набагато простіше проводити тестування та дебаггінг за рахунок використання невеликих ітерацій. Тим не менш, варто відзначити, що загальна вартість все ж таки вище, ніж у випадку каскадної моделі.
Спіральна модель
Спіральна модель це методологія тестування ПЗ, яка заснована на інкрементному підході та прототипуванні. Вона складається з чотирьох етапів:
- Планування
- Аналіз ризиків
- Розробка
- Оцінка
Відразу після завершення першого циклу починається другий. Тестування програмного забезпечення починається ще на етапі планування і триває до стадії оцінки. Основною перевагою спіральної моделі є те, що перші результати тестування з'являються відразу після появи результатів тестів на третьому етапі кожного циклу, що допомагає гарантувати коректну оцінку якості. Проте важливо пам'ятати про те, що ця модель може бути досить витратною і не підходить для маленьких проектів.
Незважаючи на те, що ця модель досить стара, вона залишається корисною як для тестування, так і для розробки. Більш того, головна мета багатьох методологій тестування програмного забезпечення, включаючи спіральну модель, змінилася останнім часом. Ми використовуємо їх не тільки для пошуку дефектів у додатках, але також і для з'ясування причин, що їх спричинили. Такий підхід допомагає розробникам працювати більш ефективно та швидко усувати помилки.
Читайте докладніше про спіральну модель у попередньому блог посту.
Agile
Методологія гнучкої (Agile) розробки та тестування ПЗ може бути описана як набір підходів, орієнтованих на використання інтерактивної розробки, динамічного формування вимог та забезпечення їх здійснення як результату постійної взаємодії всередині робочої групи, що самоорганізується. Більшість гнучких методологій розробки програмного забезпечення націлені на мінімізацію ризиків за допомогою розробки в рамках коротких ітерацій. Одним із головних принципів цієї гнучкої стратегії є можливість швидкого реагування на можливі зміни, ніж прагнення покластися на довгострокове планування.
Дізнайтесь більше про Agile(Прим. - Стаття англійською мовою).
Екстремальне програмування (XP, Extreme Programming)
Екстремальне програмування є одним із прикладів гнучкої розробки ПЗ. Відмінною особливістю цієї методології є "парне програмування", ситуація, коли один розробник працює над кодом, тоді як його колега постійно проводить огляд написаного коду. Процес тестування ПЗ є досить важливим, оскільки починається навіть раніше, ніж написано перший рядок коду. Кожен модуль програми повинен мати юніт-тест, щоб більшість помилок могла бути виправлена на стадії написання коду. Іншою відмінністю є те, що тест визначає код, а не навпаки. Це означає, що певна частина коду може бути визнана завершеною лише в тому випадку, якщо всі тести успішно пройдені. В іншому випадку код відхиляється.
Головними перевагами такої методології є постійне тестування та короткі релізи, що допомагає забезпечити високу якість коду.
Scrum
Scrum - Частина методології Agile, ітеративний інкрементний фреймворк, створений для управління процесом розробки програмного забезпечення. Згідно з принципами Scrum, команда тестувальників має брати участь у наступних етапах:
- Участь у плануванні Scrum
- Підтримка у юніт-тестуванні
- Тестування історій користувача
- Співпраця із замовником та власником продукту для визначення критеріїв прийнятності
- Надання автоматичного тестування
Більше того, учасники QA-відділу мають бути присутніми на всіх щоденних зборах, як і інші члени команди, щоб обговорити, що було протестовано та зроблено вчора, що буде протестовано сьогодні, а також загальний прогрес тестування.
У той же час принципи Agile методології у Scrum до появи специфічних особливостей:
- Оцінка зусиль, необхідних для кожної історії користувача є обов'язковою
- Тестувальник повинен бути уважним до вимог, оскільки вони можуть постійно змінюватись
- Ризик регресії зростає разом із частими змінами коду
- Одночасність планування та виконання тестів
- Нерозуміння між членами команди у разі якщо вимоги замовника не до кінця зрозумілі
Дізнайтесь більше про методологію Scrum з попередньої статті.
Висновок
Насамкінець важливо відзначити, що сьогодні практика використання тієї чи іншої методології тестування ПЗ передбачає мультиверсальний підхід. Іншими словами, не варто розраховувати на те, що якась одна методологія виявиться придатною для всіх типів проектів. Вибір однієї з них залежить від багатьох аспектів, таких як тип проекту, вимоги замовника, поставлені терміни, а також багатьох інших. З точки зору тестування ПЗ, для деяких методологій характерно приступати до тестування на ранніх етапах розробки, у той час як при роботі з іншими прийнято очікувати, поки система не готова повністю.
Якщо вам потрібна допомога з розробкою програмного забезпечення або тестуванням, виділена команда розробників та інженерів QA готова до роботи.
Дуже важливо розуміти, що QA, це не лише безпосередній пошук помилок у ПЗ. Це процес складається з безлічі етапів, які виконуються практично протягом усього життєвого циклу розробки програмного забезпечення: від аналізу та тестування початкових вимог до приймання та тестування інцидентів з продуктивного середовища. У цій статті розглянуто етапи, процеси та підходи до тестування. Загалом, методи тестування це досить об'ємна тема і вона буде обов'язково розібрана окремо. А зараз я виокремлю лише найголовніші з етапів процесу QA, які потрібно собі добре уявляти і не буде зайвим згадати їх перед проходженням співбесіди.
1. Аналіз документації: бізнес вимог та функціональних специфікацій
На цьому етапі ми розуміємо, із чим маємо справу. У процесі аналізу документації, щоб розібратися з функціональністю, ми ставимо питання іншим членам команди, наприклад аналітику або розробнику. Часто ці питання дозволяють виявити якісь нелогічні моменти у вимогах, протиріччя, можливий негативний вплив нових вимог на поточний функціонал ПЗ. Все це – потенційні помилки, які ми можемо помітити та виключити ще на етапі документації.
2. Оцінка та планування тестування
- На основі знань, отриманих на етапі аналізу ми оцінюємо час тестування. Оцінка також широка та важлива тема, їй присвячений цілий розділ даного керівництва ( Вимоги до тестувальника ч.9: оцінка часу на тестування)
- Далі виконується планування. Докладно про планування я розповім у статті для менеджерів та керівників груп тестування. Проте, тестувальнику необхідно знати, що на цьому етапі формуються (зазвичай тест менеджером) стратегія та план тестування, в яких зводитись воєдино вся інформація про те, який функціонал ми тестуємо, на якому оточенні, з якими даними, хто бере участь у процесі, які критерії якості використовуємо і т.д. Детально – у статті про тестову стратегію. На інтерв'ю тестувальнику часто ставлять питання, що таке стратегія тестування, з чого вона складається і для чого потрібна. Тому рекомендую ознайомитись з матеріалом, щоб отримати виставу.
Якщо процес, за яким ми працюємо, досить сильно формалізований і включає безліч звітів, репортів та інших супровідних документів, то на цьому етапі ми також готуємо всі необхідні шаблони для цих документів
3. Розробка сценаріїв тестування
На даному етапі ми описуємо сценарії, за якими тестуватимемо продукт. Тут важливими є дві теми: як визначити необхідні сценарії та як їх описати.
- Для того, щоб визначити, які перевірки необхідно виконати, існує безліч технік і способів. У цій статті я не описуватиму їх (можна за назвою знайти докладний опис на WiKi), тільки перерахую деякі з них:
- Traceability matrix
- Decision Table
- Boundary value analysis and Equivalence partitioning
- Pairwise Technique
- Use-Case
Для проходження інтерв'ю найголовніше відповісти на запитання:
- Як плануєте формувати перелік перевірок?
- Як зрозумієте, наскільки повно цей список перевірок охоплює функціонал, який необхідно перевірити?
Якщо якимись техніками раніше не користувалися, інтерв'юеру відразу буде ясно, що знання лише теоретичні, а ви можете легко заплутатися. У цьому випадку обов'язково розберіться з методом тестування граничних значень та класами еквівалентності (Boundary value analysis and Equivalence partitioning) та відштовхуйтеся від функцій ПЗ. Слідкуйте, щоб на кожну функцію та стан продукту був щонайменше один тест. Якщо функціональність має складну логіку роботи, то робіть перевірку на кожну умову алгоритму. Також обов'язково орієнтуйтеся на бізнес сенс функціоналу, на те, як ПЗ в реальності буде використовуватися (Use-Case), створюючи тест на кожен сценарій.
- Опис сценаріїв тестування або тест дизайн також має безліч реалізацій: від використання спеціальних програмних засобів типу HP ALM до опису сценаріїв в Excel або Word. Тут важливо чітко розуміти основні параметри тесту, які повинні бути завжди незалежно від інструмента. Швидше за все вам поставить приблизно таке запитання: «Як виглядає ідеальний тест кейс? Із чого він складається?». Власне основні складові тесту такі:
- Версія тестованого програмного забезпечення, посилання на вимоги, автор тест кейсу
- Початкові умови, кроки для підготовки до тестування: стан системи, налаштування середовища, дані
- Заголовок тест кейсу з його основною ідеєю
- Кроки тестування, що включають: дію, очікуваний результат, фактичний результат
- Статус тест (тут також потрібна дата виставлення статусу і хто його змінив)
- Посилання на виявлені помилки
- Дії щодо повернення системи у вихідний стан
Звичайно тест кейс може містити і безліч інших параметрів, я навів тільки найважливіші без яких точно не обійтися. Більше повний опис складових тесту наведено тут.
4. Виконання тестування ПЗ
Безпосередньо тестування проводитись у кілька етапів, а всередині кожного етапу – цикл (тестування -> аналіз та виправлення помилки -> ретест), або загальна перевірка працездатності (постачання\функціональність працює або не працює). Поки розглянемо лише ручне тестування, а автоматизацію залишимо на окремій темі. Як основні етапи тестування ПЗ, які виконує QA команда, можна виділити наступні:
- Smoke testing та Sanity testing – попередня перевірка системи та постачання ПЗ. На цьому етапі наше завдання переконатися, що тестове середовище налаштоване та працює, а отриманий білд містить необхідний функціонал чи зміни та з ним можна продовжувати працювати. Т.о. ми робимо основні, базові перевірки.
- Functional & non-functional testing – основний етап тестування, який включає все різноманіття перевірок різних типів розібраних у розділі «3 - Базові знання з тестування», спрямованих на зміни, додані в рамках поставки. На цьому етапі ми проводимо кілька циклів тестування, як правило, більше 2.
- Regression testing – проводимо цикл регресійного тестування та перевіряємо, що нові фічі та зміни не зламали поточний функціонал. Тут також кілька циклів. У принципі, цей етап можна вважати другою фазою попереднього блоку - Functional & non-functional testing.
- Integration & end-to-end testing – на цьому етапі ми перевіряємо як наш модуль, система чи продукт взаємодіятиме з іншими модулями, системами та продуктами. Тут ми перевіряємо весь ланцюжок дій користувача під час роботи з системою. Наприклад, користувач робить заявку через сайт інтернет магазину, далі заявка записується в базу, далі обробляється та передається в систему для закупівель тощо. У цьому випадку ми повинні налаштувати необхідне оточення та перевірити весь життєвий цикл заявки, навіть якщо ми допрацювали лише одну систему у ланцюзі.
- Demo testing & User Acceptance Testing – етап демонстрації ПО замовнику \ користувачам, які також можуть (і в ідеалі повинні) проводити своє тестування продукту – UAT
Більш наочно етапи тестування ПЗ представлені на схемі Етапи та учасники процесу тестування . Також там вказані інші команди, які також беруть участь у процесі тестування, щоб вийшла повніша картина.
5. Підбиття підсумків та підготовка результатів тестування
На цьому етапі ми робимо таке:
- Проводимо якісний та кількісний аналіз виявлених під час тестування помилок та проблем
- Формалізуємо ці результати у вигляді метрик тестування
- Готуємо звіт про результати тестування з висновком, чи рекомендується даний білд до поставки в продукти, які є ризики, яких заходів необхідно вжити для того, щоб запобігти або мінімізувати збої.
Як результати та метрик тестування ми можемо використовувати такі показники як (докладніше про метрики тестування в окремій статті):
- Кількість відкритих дефектів за рівнем їх критичності
Наприклад, у нас можуть бути чіткі критерії, що з відкритими дефектами рівня Critical ми не виходимо в продуктив, а відкритий дефект рівня High може бути тільки один і при цьому має бути додаткова інструкція як боротися з його наслідками та план усунення
- Кількість відкритих дефектів до загальної кількості дефектів
Так ми показуємо яка частина помилок не виправлена і яка кількість таких помилок, щоб ухвалити рішення про продовження тестування або реліз ПЗ
- Кількість дефектів до загальної кількості тестів
Ця метрика показує середню ефективність одного тесту
- Число разів, яке в середньому перевідкривався дефект
Ця метрика показує складність та якість коду. Якщо показник високий, значить високі потенційні ризики, особливо якщо згодом у продукт будуть вноситись зміни
6. Підтримка під час встановлення в продуктив
На даному етапі завдання тестування надати команді підтримки, яка буде проводити встановлення в продуктив всю необхідну інформацію про тестування продукту, можливі ризики, складнощі.
7. Підтримка під час супроводу продукту
