Інтеграційне та функціональне тестування в банках. Основи BDD: Юніт, Інтеграційні та End-to-End тести

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

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

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

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

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

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

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

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

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

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

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

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

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

Мал. 20.1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мал. 20.1.

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

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

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

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

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

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

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

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

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

Інтегративний тест тривожності – оригінальна клінічна тестова методика, створена у 2005 році у НІПНІ ім. Бехтерєва к.пс.н. А.П. Бізюком, д.м.н. професором Л.І. Вассерманом та к.м.н. Б.В. Іовлевим для загальної структурної експрес-діагностики тривоги та тривожності, у тому числі у клініці псхосоматичних захворювань.

Теоретичні основи

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

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

Ще одним недоліком багатьох інструментальних методів дослідження є недиференційованість тривоги та тривожності. Тривога та тривожність – різні, але системно пов'язані поняття, аналізувати які слід пов'язано для того, щоб зрозуміти їх особистісний сенс у реальній життєвої ситуаціїлюдини. Саме таким чином у комплексній багатовимірній діагностиці порушень психічної адаптації досліджується патогенез психогеній і соціогеній, що формуються, внутрішньої картини хвороби, тенденцій до саморуйнівної поведінки та ін. Особливо чітко ці загальні механізмиформування клінічної картинихвороби, де тривога – тривожність відіграють суттєву (а нерідко й основну) роль, простежуються переважно при невротичних та неврозоподібних розладах соматоформного типу (F4 – МКХ-10). Універсальність тривоги як афективного регулятора поведінки полягає насамперед у її опосередковучій значущості та включеності до інших психічні феномени, тому позитивна діагностика цього феномену надзвичайно важлива для кваліфікації клінічної картини хвороби, що формується, при тривожно-фобічних (F40), інших. тривожних розладах(F.41), особливо при змішаних тривожних та депресивних розладах(F41.2), при посттравматичних стресових розладах (F43.1) та розладах адаптації (F43.2), соматоформних вегетативних розладах (F45.3), при соматогенних та інших порушеннях афективного кола. Більше того, тривога як емоційний стані тривожність як фундаментальна особистісна характеристика повинна аналізуватися в багатьох сферах функціонування особистості: у спорті, військовій та операторській діяльності фахівців, профвідборі, педагогічному процесіта інших областях, де пред'являються спеціальні вимогидо адаптивних можливостей людини. Порушення психічної адаптації як складної багатовимірної системипристосувальних механізмів особистості виникають у силу різних причині обставин, і в даний час однією з найбільш практично значимих завдань спільної діяльностіпсихіатрів та лікарів загального профілю з клінічними психологамиє діагностика, змістовна кваліфікація та комплексна корекція станів умовно-патологічного типу, до яких належать порушення психічної адаптації.

Особливістю цих розладів є клінічно слабко структуровані, нестійкі, поліморфні симптоми, які мають чіткої нозологічної приналежності. Частота їх встречаемости за даними літератури варіює у межах (22,0%-89,7%), але має чітку тенденцію до збільшення, передусім у зв'язку з змінами якості життя населення нашій країні. У їхньому генезі, поряд із впливом так званих соціально-стресових розладів та соціальної фрустрованості мають місце і особистісні фактори- невміння людей самостійно вирішувати кризові ситуації, внутрішньоособистісні, сімейні та виробничі конфлікти, що неминуче призводить до хронічного стресута дистреси, що супроводжуються тривожними переживаннями.

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

Внутрішня структура

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

З метою диференційованого та деталізації уявлення про впливи різних компонентівсамооцінки випробуваного як носія тривоги, щодо накопиченого емпіричного матеріалу було застосовано метод факторного аналізу, що дозволило у структурі 15 ознак виділити 5 чинників, інтерпретованих, як говорилося, як допоміжних шкал, саме “ емоційний дискомфорт” (ЕД), “астенічний компонент тривожності” (АСТ), “фобічний компонент” (ФОБ), “тривожна оцінка перспективи” (ВП) та “ соціальний захист(СЗ) (фактори дано в порядку зменшення пояснюваної дисперсії – відповідно – 2,082; 1,512; 1,459; 1,458, 1,280). Докладний описеквівалентних їм допоміжних шкал наводиться нижче. Отримані факторні навантаження за ознаками використовуються як діагностичні коефіцієнти нових допоміжних шкал, побудованих на базі вилучених факторів, що підвищує діагностичний потенціал тесту ІТТ. Насамперед це посилює інформативність методики в цілому, а також підвищує її надійність у прийнятті рішення, забезпечуючи тим самим високий рівеньдиференційованості значень окремих ознак як субкомпонентів тривоги-тривожності. Таким чином виявилося можливим розглядати психологічну структурутривоги – тривожності у експериментально заданих рамках.

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

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

Валідність

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

Перевірка емпіричної валідності, пов'язаної, головним чином, з кореляційними співвідношеннями між тестом, що перевіряється, і результатами досліджень за допомогою інших методик, що дозволяють оцінювати досліджувані якості, показала наступні результати. Паралельні дослідження з СТ та 16-факторного опитувальника Кеттелла продемонстрували кореляцію на рівні r= + 0,43 (p<0,01) показателя шкалы общей тревожности и фактора “О” (уверенность в себе – тревожность), причем близкие к такого же уровня значимости корреляции с этим же фактором показали и все вспомогательные шкалы ИТТ (ЭД, АСТ, ФОБ, ОП и СЗ). Кроме того, выявилась отрицательная корреляция шкалы АСТ с фактором QЗ (низкий самоконтроль – высокий самоконтроль или низкая интеграция чувства “Я” – высокая интеграция) r= – 0,406 (р<0,01). Остальные шкалы также имели достаточно отчетливую отрицательную связь с показателем фактора Q3, но не достигшую уровня статистической достоверности. Подобные же на уровне выраженной тенденции отрицательные корреляции продемонстрировали все вспомогательные шкалы и с фактором “С” (эмоциональная неустойчивость – эмоциональная устойчивость или низкая сила “эго” – высокая сила “эго”). Определенный интерес с точки зрения эмпирической валидности представляет и связь шкалы ОП с фактором Q4 (раccлабленность – напряженность) (r= + 0,36; р<0,05), что свидетельствует о наличии общих корней тревожной оценки перспективы в ее содержательном значении по методике СТ и мотивационной неудовлетворенностью, репрезентируемой фактором Q4 теста Кеттелла.

У кореляційній матриці методик СТ і 16 РF виявилася ще одна кореляційна залежність, що підтверджує емпіричну валідність виділених шкал - це позитивний зв'язок шкали ЕД з фактором "L" (довірливість - підозрілість), що відображає, головним чином, насторожено-емоційне + 0.387;<0,01).

Апробація методики

У процесі розробки методика використовувалася щодо особливостей психологічної адаптації учасників вітчизняних антарктичних експедицій на ряді полярних станцій, а також у період їх транспортування на Шостий континент і назад. При цьому проводилися паралельні щомісячні (іноді через два місяці) дослідження емоційного стану за допомогою блоку психологічних методик, до яких входили СТ та широко відома особистісна шкала проявів тривоги J. Тауlоr. Цей матеріал послужив додатковою підставою для судження про концептуальну валідність методу, що розглядається.

Насамперед, спостерігалося загальне, практично синхронне, збіг профілю кривих динаміки оцінки тривожності за обома методиками, що відображають один і той же процес емоційного пристосування до екстремальних умов як на рівні включення в специфічне природне середовище, так і незвичайні соціально-психологічні умови, властиві подібним . З іншого боку, результат приватного аналізу зміни основної та допоміжних шкал методики СТ та їх піки повністю відповідають ситуації, що характеризувалася психологічною напругою та специфікою різних етапів зимівлі, раніше відписаних у літературі та спостерігаються лікарями експедицій (перший місяць роботи, вершина полярної ночі, період виходу суден за партією, що відзимувала і т.д.). При цьому емоційна реактивність визначалася як особливостями особистісно-середовищної взаємодії, так і тлом інтерперсональної взаємодії. Для підтвердження загальної чутливості методики до специфічних особистісних особливостей, що привертають або включають тривожність як один з основних компонентів клініко-психологічного статусу, було проведено порівняльне дослідження практично здорових осіб і групи хворих з різними формами неврозів і неврозоподібних розладів з клінічно підтвердженими структуру розладів тривожного компонента Дослідження показали, що загальний рівень самооцінки досліджуваних властивостей серед групи хворих статистично значимо відрізняється від контрольної – середній показник ситуативної тривожності у них становив 20,0, а особистісної 26,8 бала (в обох випадках достовірність відмінностей із р<0,001), что может свидетельствовать и о способности методики улавливать более общие характеристики адаптивности человека как многокомпонентного (системного) образования, биопсихосоциального по своей сущности.

У зв'язку із завданнями практичної апробації методику ІТТ було включено до програми скринінгового дослідження педагогів загальноосвітніх шкіл Челябінська з метою первинної психопрофілактики. Обстежено 7300 педагогів за допомогою формалізованих анкет, опитувальників та різних медико-психологічних тестів. У 89% відзначалися порушення здоров'я рівня групи ризику, тобто. виявляли ознаки психічної дезадаптації, у 43% виявлено порушення рівня підвищеного ризику або початкових проявів хвороби. Серед них з ознаками неврозів – 60%, патології серцево-судинної системи – 34 7%, судин головного мозку – 38,2%, травного тракту – 28,6% та ін. вигляді тривоги, астенії, зниження настрою та працездатності.

Дослідження особливостей та рівня тривожності за допомогою методики Ч. Спілбергера проведено у 349 педагогів, виявлено в середньому достовірно високі рівні ситуативної та особистісної тривожності (відповідно 49,3±5,4 бала та 47,0±5,9 балів) при високому рівні їх взаємної кореляції. Для уточнення структури тривожності було виділено репрезентативну групу з 86 осіб із високими показниками рівня тривожності. Ця група була обстежена за допомогою тесту ІТТ.

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

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

Інтерпретація

Загальні принципи

Оцінки виразності симптомів переводяться в числові значення наступним чином: 0 – відсутність даної ознаки, дві інші пов'язуються з наявністю слабо та помірно виражених ознак (бали 1 та 2) та останній – як надзвичайний, з точки зору випробуваного, ступінь виразності – 3 бали. Таким чином, за кожним субтестом випробуваний може набрати не більше 45 балів.

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

Нормативні показники

Середній фактичний бал, отриманий для нормативної групи з 540 практично здорових осіб віком від 22 до 55 років, дорівнює 11,91 (стандартне відхилення – 4,58). Статистично достовірних відмінностей для СТ-Л і СТ-С, а також окремо для чоловіків і жінок отримано не було, хоча тенденцію вищої тривожності жінок все ж таки слід зазначити, що, як відомо, зазначається і в літературі.

Нормативні матеріали для підлітків (12-15 років – 520 осіб) дали середній бал 12,88 (сигма = 5,5), проте тут, на відміну від дорослого контингенту, різниця середніх для юнаків та дівчат виявилася статистично достовірною з надійністю р.<0,001 (соответственно, юноши – 11,64 и девушки – 14,13 балла).

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

Клінічна значимість

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

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

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

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

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

Інтеграційне тестування як частина великої роботи

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

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

Методи збирання модулів

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

У такому разі її замінюють додатково розробленими "заглушками" або драйверами.

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

Інкрементальний метод включає два способи додавання модулів:

• зверху-вниз або висхідний,
• знизу-вгору - низхідний.

Особливості монолітного та інкрементального тестування

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

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

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

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

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

Інтеграційне тестування програмного забезпечення має низку переваг:

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

Виправлення дефектів

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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