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

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

20.1. Завдання та цілі інтеграційного тестування

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

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

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

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

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

20.2. Організація інтеграційного тестування

20.2.1. Структурна класифікація методів інтеграційного тестування

Як правило, інтеграційне тестування проводиться вже після завершення модульного тестування для всіх інтегрованих модулів. Однак це далеко не завжди так. Існує кілька методів проведення інтеграційного тестування:

висхідне тестування;
монолітне тестування;
низхідне тестування.

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

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

Мал. 20.1.

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

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

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

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

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

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

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

Інтеграційне тестування рідко потрапляє до заголовків статей з розділу «Інформаційні технології». Масштаб помилок інтеграції не зрівняється за ступенем критичності та за розміром завданих збитків із помилками безпеки.

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

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

Що це за тестування і як воно проводиться?

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

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

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

Інтеграційне тестування: огляд проекту

Замовник

До a1qa звернувся представник популярного англомовного журналу. Видання доступне як у друкованому вигляді, так і онлайн. На тестуванні онлайн-порталу та сфокусувалася команда a1qa.

Завдання проекту

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

Для реалізації функції підписки та її управління замовник використав такі програмні рішення:

CMS-рішення eZ Publish. Функція – надавати будь-які дані про підписки із застосуванням різних фільтрів: типу підписки, її тривалості, знижок, бонусів і т.д.
Вебсайт, через який користувач взаємодіє із системою.
CRM Salesforce. Функція – зберігання даних про користувачів та придбані ними підписки. Додаткова надбудова дозволяє команді замовника керувати придбаними передплатами, а також створювати нові та перевіряти старі передплати.
SaaS-рішення Zuora для виставлення рахунків та обробки платежів.
Обмін даними між системами здійснюється за допомогою сервісної шини Mule ESB.
База даних інструментом Business Intelligence.
Salesforce Marketing Cloud – інструмент розсилки кореспонденції та комунікації з користувачами.
Drupal раніше використовувався замість eZ Publish. На даний момент все ще залишається системою, що зберігає дані про зареєстрованих користувачів, та інструментом для публікації статей, відео- та аудіо-контенту.

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

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

Мета клієнта

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

Завдання тестування

Команда a1qa мала підтвердити, що продукт здатний виконувати покладені функції. У ході проекту деякі компоненти розроблялися з нуля, деякі налаштовувалися на готових базі.

Важливо було перевірити, як вони взаємодіють між собою, і відповісти на запитання: чи здатна вся система вирішувати потрібні завдання?

Стратегія проведення інтеграційного тестування a1qa

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

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

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

Проблеми

Більшість труднощів при проведенні тестування інтеграції було викликано недостатнім опрацюванням вимог на початковому етапі проекту. Саме неякісні вимоги стали причиною безлічі дефектів та нестабільності системи загалом.

Пояснимо. Спочатку вимоги виглядали як набір історій користувача (User Story) в JIRA і містили тільки заголовки без будь-якого пояснення. Створювали їх найчастіше розробники.

Команда a1qa ініціювала зміни у підході до написання вимог: тепер для них обов'язково додаються описи та Acceptance Criteria, створюються проміжні завдання з чітким визначенням, хто і за що відповідає.

Автоматизація інтеграційного тестування

Автоматизація тестування – непросте питання, яке потребує уважного зіставлення всіх «за» та «проти».

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

А при оформленні передплати далеко не завжди так відбувається: дані оновлюються регулярно та хаотично. Тому тестування проводилось переважно вручну.
Лише на пізніх стадіях проекту було впроваджено автоматизацію. Які ж тест-кейси було автоматизовано? Було відібрано ключові бізнес-процеси. Для кожного бізнес-процесу було прописано варіації його проходження. Автоматизовано ті тест-кейси, які покривали регулярні та стабільні бізнес-процеси. Тим самим автоматизація забезпечила максимальне покриття при оптимальних витратах зусиль.

Результати

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

Підбиваючи підсумки

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

Для проведення ефективного тестування, виявлення всіх дефектів та недоліків команда з тестування повинна:

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

Як замовити інтеграційне тестування?

Щоб отримати безкоштовну консультацію з інтеграційного тестування, заповніть .

Переклад:Ганна Радіонова

Існує багато видів програмного забезпечення тестів. Практики BDD можна застосовувати у будь-яких аспектах тестування, але BDD фреймворки використовуються далеко не у всіх типах тестів. Поведінкові сценарії, по суті, є функціональнимитестами - вони перевіряють, що продукт, що тестується, працює коректно. Для тестування продуктивності можуть використовуватися інструменти, в той час як фреймворки BDD не призначені для цих цілей. Завдання цієї статті в основному полягає в описі ролі BDD автоматизації в Піраміді Тестування. Прочитайте статтю BDD 101: Manual Testing для того, щоб розуміти, як BDD застосовується при ручному тестуванні. (Всю інформацію про BDD можна знайти на сторінці Automation Panda BDD page)

Піраміда Тестування

Проте, BDD практики можуть застосовуватись для юніт-тестів.Кожен юніт-тест має бути спрямований на основну складову: один виклик, поодинока варіація, певна комбінація введення; на поведінка.Надалі розробки специфікація поведінки фічі чітко відокремлює юніт тести від тестів вищого рівня. Розробник функціоналу також відповідальний за написання юніт-тестів, тоді як за інтеграційні та end-to-end тести несе відповідальність інший інженер. Специфікація поведінки є свого роду джентльменською угодою про те, що юніт-тести будуть окремою сутністю.

Інтеграційне та End-to-End тестування

Тестові BDD фреймворки найбільш яскраво проявляють себе на інтеграційних та end-to-end рівнях тестування.

Поведінкові специфікації однозначно та лаконічно описують, на що саме орієнтований тест-кейс. Кроки можуть бути написані на інтеграційному чи end-to-end рівні. Тести сервісу можуть бути написані за допомогою специфікацій поведінки, як, наприклад в Karate . End-to-end тести фактично є багатокроковими інтеграційними тестами. Зверніть увагу на наступний приклад, який на перший погляд здається базовою моделлю взаємодії з користувачем, але, по суті, є об'ємним end-to-end тестом:

Given a user is logged inthe social media site
When the user writes a new post
Then the user"s home feed displays the new post
And the all friends" home feeds display the new post

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

Тривалі End-to-End тести

Терміни часто розуміються різними людьми по-різному. Коли люди кажуть “end-to-end тести”, вони мають на увазі тривалі послідовні тести: тести, які покривають різну поведінку продукту одне за одним. Це твердження змушує здригнутися прихильників BDD, оскільки це суперечить основному правилу BDD: один сценарій, одне поведінка. Звичайно, за допомогою BDD фреймворків можна складати тривалі end-to-end тести, але Потрібно добре подумати, чи варто це робити і як саме.

Існує п'ять основних принципів написання тривалих end-to-end сценаріїв у BDD:

Не варто турбуватися з цього приводу. Якщо BDD процес поставлений правильно, кожна окрема поведінка вже повністю покрито тестовими сценаріями. Кожен сценарій повинен покривати всі класи еквівалентності даних, що вводяться і виводяться. Таким чином, тривалі end-to-end сценарії будуть в основному дублюванням тестового покриття. Замість того, щоб витрачати час на розробку, краще відмовитися від автоматизації тривалих end-to-end сценаріїв, як від тих, які не мають великої цінності і приділити більше часу ручному та дослідному тестуванню.
Об'єднати існуючі сценарії в нові. Кожна When-Then пара є індивідуальна поведінка. Кроки з існуючих сценаріїв можуть бути перевизначені в інші сценарії і для цього буде потрібно лише незначний рефакторинг. Це порушує хороші практики Gherkin і може призвести до появи тривалих сценаріїв, але це найбільш практичний спосіб перевикористовувати кроки для великих end-to-end сценаріїв. Більшість BDD фреймворків не підтримують покроковий порядок, а якщо підтримують, то кроки мають бути переписані, щоб працював код. (Цей підхід є найбільш практичним, але менш традиційним.)
Вбудовуйте перевірки у Given та When кроки. Ця стратегія дозволяє уникнути дуплікування When-Then пар та переконатися, що перевірки проводяться. Коректність кожного кроку перевіряється протягом усього процесу за допомогою тексту Gherkin. Однак, може знадобитися низка нових кроків.
Сприймайте послідовність поведінки як унікальну окрему поведінку. Це найкращий спосіб обмірковування тривалих end-to-end сценаріїв, т.к. він посилює поведінкове мислення. Тривалий сценарій має цінність лише тому випадку, якщо він розцінюється як унікальне поведінка. Сценарій має бути написаний з метою наголосити на цій унікальності. Інакше це не той сценарій, який варто використати. Такі сценарії часто є декларативними та високорівневими.
Не використовуйте BDD фреймворки та пишіть тести виключно за допомогою засобів автоматизації. Gherkin призначений для спільної роботи щодо поведінки, тоді як тривалі end-to-end тести вирішують проблеми інтенсивності роботи QA. Бізнес може надати поведінкові специфікації, але ніколи не писатиме end-to-end тести. Переписування поведінкових специфікацій у довгі end-to-end сценарії може блокувати розробку. Набагато найкращим рішенням є співіснування: приймальні тести можуть бути написані за допомогою Gherkin, а тривалі end-to-end тести – засобами програмування. Для автоматизації обох наборів тестів можна використовувати одну й ту саму базу коду, вони можуть мати єдині модулі підтримки і навіть методи визначення кроків.

Виберіть підхід, який найбільше підходить вашій команді.

Класи та види тестів.

Існують два основні класи тестів: традиційніі нетрадиційні.

Тест має складом, цілісністюі структурою. Він складається з:

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

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

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

Традиційний тест є єдністю щонайменше трьох систем:

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

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

ті ст - це система завдань, що утворюють найкращу методичну цілісність. Цілісність тесту - це стійка взаємодія завдань, що утворюють тест як систему, що розвивається.

Гомогенні тести

До традиційних тестів належать тести гомогенніі гетерогенні.

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

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

Гетерогенні тести

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

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

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

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

Інтегративні тести

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

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

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

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

Адаптивні тести

Доцільність адаптивного контролю випливає із необхідності раціоналізації традиційного тестування.

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

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

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

· Підвищення швидкості перевірки якості засвоєння знань та умінь учнями;

· Здійснення хоча і поверхневого, але повного охоплення всього навчального матеріалу;

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

· Висока об'єктивність і, як наслідок, більший позитивний стимулюючий вплив на пізнавальну діяльність учня;

· орієнтованість на сучасні технічні засоби, використання у середовищі комп'ютерних навчальних і контролюючих систем;

· Можливість математико-статистичної обробки результатів контролю, і як наслідок, підвищення об'єктивності педагогічного контролю;

· Здійснення принципу індивідуалізації та диференціації навчання завдяки використанню адаптивних тестів;

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

· Полегшення процесу інтеграції системи освіти країни в європейську.

Тести можна класифікувати з таких підстав:

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

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

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

4.Орієнтація на певний етап контролю: тести попереднього контролю, тести поточного контролю, тести підсумкового контролю

5. Домінуюча діяльність випробуваного під час виконання тестів- Усні, письмові, комп'ютерні.

6. Кількість об'єктів контролю: тести, що мають один об'єкт контролю (наприклад, кількість операцій, що виконуються на належному рівні) або кілька (якість, кількість, швидкість, строгу послідовність, усвідомленість тих же операцій).

7. Ступінь гомогенності тестових завдань: тести з однорідними чи різнорідними формами побудови завдань.

8. Швидкісний фактор: швидкісні (з обов'язковим фіксуванням часу виконання) та нешвидкісні.

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

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

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

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

Завдання, яке вирішується методом інтеграційного тестування, - Тестування міжмодульних зв'язків, що реалізуються при виконанні програмного забезпечення комплексу K. Інтеграційне тестування використовує модель "білого ящика" на модульному рівні. Оскільки тестувальнику текст програми відомий з детальністю до виклику всіх модулів, що входять до комплексу, що тестується, застосування структурних критеріїв на даному етапі можливе і виправдане.

Інтеграційне тестування застосовується на етапі складання модульно відтестованих модулів у єдиний комплекс. Відомі два методи складання модулів:
Монолітний, що характеризується одночасним об'єднанням всіх модулів у комплекс, що тестується
Інкрементальний, що характеризується покроковим (помодульним) нарощуванням комплексу програм з покроковим тестуванням комплексу, що збирається. В інкрементальному методі виділяють дві стратегії додавання модулів:
o "Зверху вниз" і відповідне йому висхідне тестування.
o "Знизу вгору" і відповідно низхідне тестування.

Особливості монолітного тестуванняполягають у наступному: для заміни нерозроблених до моменту тестування модулів, крім найвищого, необхідно додатково розробляти драйвери (test driver) та/або заглушки (stub), які замінюють відсутні на момент сеансу тестування модулі нижніх рівнів.

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

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

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

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

Особливості інтеграційного тестування для процедурного програмування

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

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