Меню

Підручник зі структурних випробувань - що таке структурні випробування

  • Головна
  • Інший
  • Підручник зі структурних випробувань - що таке структурні випробування

structural testing tutorial what is structural testing

Спробуйте Наш Інструмент Для Усунення Проблем

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

Швидкий пошук в Google деяких найдорожчих програмних помилок залишив мене в голові - 500 мільярдів доларів. Так, ось наскільки дорогою може бути помилка. Читання всього, що пов’язано з втратою життя на транспорті та в галузі охорони здоров’я через помилку програмного забезпечення, може також викликати жах.

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

Структурні випробування

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

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

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

Що ви дізнаєтесь:

Чому тестування програмного забезпечення є важливим

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

Нижче наведено кілька причин:

# 1) Забезпечити дотримання передбачених вимог перед початком побудови проекту. Зацікавлені сторони (наприклад, розробники та клієнти) повинні узгодити всі аспекти рішення / продукту / програмного забезпечення, які необхідні для побудови проекту.

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

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

# 3) Він перевіряє ефективність: Наприклад, щоб визначити загальний час, який пройшов під час запуску коду. Якщо ми використовуємо кілька Для петель у нашому коді знадобиться багато часу, щоб отримати запланований результат, а іноді може навіть таймаут.

# 4) Це допомагає досягти кращого досвіду для користувачів. Користувачам не сподобається користуватися програмним забезпеченням, яке працює неправильно, з помилками або «занадто повільно». Користувачі, ймовірно, стануть нетерплячими і кидатимуть програмне забезпечення. Тестування дає нам кращий досвід у забезпеченні того, щоб користувачі могли легко використовувати наші продукти.

# 5) Він перевіряє масштабованість. Розробник повинен прагнути до створення програмного забезпечення, яке можна масштабувати.

# 6) Він перевіряє наявність вразливостей у коді. Тестування дозволяє нам виявляти вразливі місця безпеки, Наприклад, код, який може скомпрометувати ІПІ (Особиста інформація), що є пріоритетом для GDPR.

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

Структурні випробування проти інших типів випробувань

Існує багато видів тестування програмного забезпечення. Однак, СТОП (Міжнародна комісія з кваліфікації тестування програмного забезпечення), визначає 4 основні типи тестування програмного забезпечення, а саме

  • Функціональний
  • Не функціональний
  • Структурні
  • На основі змін

Пояснити відмінності можна так:

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

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

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

Припустимо, ми повинні перевірити, чи ми визначили код, який відрізняє парні числа від непарних. Тут ми можемо мати умовне твердження, наприклад, якщо елемент масиву ділиться на два без залишку, якщо (arr (i)% 2 === 0) тоді число можна сказати як парне число.

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

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

Що таке структурні випробування - це не таке

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

Що таке структурні випробування

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

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

Як проводити структурні випробування

Щоб перевірити різні аспекти коду, нам потрібно спочатку зрозуміти потоки управління.

Тестування контрольного потоку

Це виведення тестів із потоків управління кодом (порядок, у якому реалізовані оператори, функції та різні аспекти коду).

Процес контролю потоку контролю:

Графік управління потоком

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

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

Давайте розглянемо ці компоненти нижче:

Вузли та краї

# 1) Блок процесу

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

Приклад блоку процесу:

Блок процесу

(зображення джерело )

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

# 2) Пункти рішення

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

Рішення, прийняте тут, може бути умовними операторами, такими як оператори if-else (які мають два можливі результати) та оператори case (які можуть мати більше двох результатів).

CFG

(зображення джерело )

На наведеній вище схемі є пункт прийняття рішення (від умовного «вік = 18»), за яким слідують варіанти «так» або «ні».

# 3) Точки з'єднання

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

Найкращі практики управління графіками потоків:

Є кілька речей, на які слід звернути увагу при побудові графіків керуючих потоків:

  • Спробуйте якомога більше, щоб CFG був простим. Ми можемо зробити це, об’єднавши частини, які можна вважати „менш важливими”, наприклад, технологічні блоки.
  • Переконайтеся, що в пунктах рішення приймається лише одне рішення. У більш складних CFG існують 'наслідки', які настають після прийняття рішення. У наведеному вище прикладі ми також можемо додати, що якщо особі 18 років і старше, тоді вона має право і повинна заплатити за квиток. Якщо їх немає, то вхід безкоштовний. Рішення 'інакше' повинно 'пропустити' кілька вузлів, і всі ці кроки повинні бути показані в нашій CFG.

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

Визначення кількості тесту:

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

Якщо ми кажемо, що ми прагнемо протестувати 50% нашого коду, то це може означати, що ми визначимо всі виконувані оператори коду і прагнемо протестувати принаймні половину з них. Однак питання, яке тут виникає, полягає в тому, 'чи потрібно нам тоді визначати всі можливі виконувані шляхи?'

Це знову може бути практично неможливим. Кращий підхід може бути спрямований на тестування 50% шляхів, які ми можемо ідентифікувати в кожному розділі коду.

Існують різні рівні покриття, а саме виписка, галузь та охоплення шляху. Ми коротко розглянемо їх пізніше.

Створення тестових кейсів:

Наступним кроком є ​​створення тестових кейсів, які ми будемо використовувати. Тестові випадки при структуроване тестування базуються на таких факторах:

  • Виконувані оператори.
  • «Рішення», які потрібно прийняти.
  • Можливі шляхи, якими можна йти.
  • Умови, яким потрібно відповідати (вони можуть бути множинними або логічними).

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

Виконання тестових кейсів:

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

Аналіз результатів:

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

Припущення щодо контролю потоку

Важливо зазначити, що для проведення контрольного тестування потоку існує кілька припущень. До них належать:

  • Єдині помилки - це ті, які можуть вплинути на керування потоком.
  • Усі змінні, функції та елементи точно визначені.

Рівні покриття в потоках управління

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

Давайте розглянемо їх коротко.

# 1) Покриття заяви

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

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

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

# 2) Покриття філії

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

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

# 3) Покриття шляху

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

Типи структурних випробувань

Типи структурних випробувань
(зображення джерело )

Тестування мутацій

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

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

Тестування на основі зрізів

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

Як робити нарізку

Приклад нарізки в SBT: Код для друку парних і непарних чисел (Python)

num_list = range(1,12) even_nums = () odd_nums = () for var in num_list: if var%2==0: even_nums.append(var) print(f'Even numbers: {even_nums}') elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')

Тестування на зрізах

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

У нашому прикладі, якщо ми подивимося на вихід непарних чисел, ми можемо простежити частину коду, яка веде нас до цього виводу.

У критеріях нарізування, наданих Марком Вайзером (який представив SBT), зріз визначається за такою формулою: S (v, n) , де, v посилається на відповідну змінну ( наприклад, де визначена змінна), і п заява про інтерес ( наприклад, де дається вихід), і S означає фрагмент.

У наведеному вище прикладі, щоб отримати зріз, ми починаємо з нашого виводу в рядку 10, який стає нашим п . Наша змінна: де .

Отже, нашими критеріями нарізки є:

S(v,n) = S(var,10)

Наше занепокоєння - це твердження, які ведуть нас до результату.

Це:
10,9,8,4,3,1

Отже, наш фрагмент у цьому коді:

num_list = range(1,12) odd_nums = () for var in num_list: elif var%3==0: odd_nums.append(var) print(f'Odd numbers: {odd_nums}')

SBTSlice

Типи тестування на зрізах

Існує два типи SBT: статичний і динамічний

# 1) Динамічне тестування на зрізах

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

Ми виконуємо код і використовуємо тестові дані, щоб переконатися, що він працює так, як передбачається. Ми могли б збільшити діапазон до діапазону (1,50), наприклад, щоб побачити, чи все ще він генерує лише непарні числа. Динамічний SBT також відомий як перевірка на валідацію.

# 2) СтатичнийТестування на основі зрізів

На відміну від Dynamic SBT, статичне тестування зосереджується на певній змінній. Якщо ми думаємо про наш результат у наведеному вище прикладі як де , ми можемо простежити фрагмент, який впливає на нього, як 10,9,8,7,6,5,4,3,2,1

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

Важливо зазначити, що динамічний SBT 'менший' у порівнянні зі своїм статичним аналогом. Це також більш конкретно.

Найкращі практики / керівні принципи тестування на зрізах

Критерії нарізки повинні визначатися:

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

Переваги тестування на зрізах включають:

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

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

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

Тестування потоку даних

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

Аномалії потоку даних

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

Давайте розглянемо їх нижче:

Тип 1: Змінна визначається і їй присвоюється значення двічі.

Приклад коду: Python

lst_1 = (1,2,3,4) lst_1 = (5,6,7,8) for var in lst_1: print(var)

Тип1

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

Тип 2: Значення змінної використовується або посилається до того, як воно буде визначено.

Приклад коду: Python

for var in lst_1: print(var)

Тип 2

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

питання та відповіді на співбесіду для тестування soapui

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

Приклад коду: Python

lst_1 = (1,2,3,4) lst_2 = (5,6,7,8) for var in lst_1: print(var)

Тип 3

Змінна lst_2 не було посилання. Аномалії типу 3 можуть не спричинити збій програми.

Процес тестування потоку даних

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

Крок 1) Накресліть графік управління потоком

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

Приклад коду: Python

cost = 20 y = int(input('How many visitor seats did you reserve? ')) x = int(input('How many member seats did you reserve? ')) if y>x: bill = cost -1 else: bill = cost print(bill)

Тестування потоку даних

У наведеному вище прикладі коду учасник повинен отримати знижку, якщо запросить відвідувача.

Графік потоку управління (CFG):

Графік управління потоком

Крок No2) Дослідіть визначення та використання змінних та значень даних.

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

Якщо ми розглянемо змінну вартість у CFG, то це визначальні та використання вузли:

ВузолТипКод
1 Визначальний вузолвартість = 20
5 Вузол використаннярахунок = вартість -1
7 Вузол використаннявексель = вартість

Крок No3) Визначте шляхи використання визначень.

Існує два типи шляхів використання визначень: du шляхи та шляхи постійного струму. du path - це шляхи визначення, які починаються з вузла визначення та закінчуються вузлом використання. Це стосується шляху щодо посилання на змінну вартість вище.

Прикладом шляху постійного струму, шляху чіткого прийняття рішення, є шлях щодо змінної рахунку, як показано нижче:

ВузолТипКод
5 Визначальний вузолрахунок = вартість -1
7 Визначальний вузолвексель = вартість
8 Вузол використаннядрук (рахунок)

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

Крок No4) Створіть набір тестів.

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

Типи тестування потоку даних

Є два типи - Статичний та динамічний .

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

Переваги та недоліки тестування потоку даних:

  • Тестування потоку даних ідеально підходить для виявлення аномалій потоку даних, що робить його дуже ефективним методом структурного тестування.
  • Його мінус полягає в тому, що існує необхідність добре володіти мовою, яка використовується для написання коду для використання тестування потоків даних. Це також трудомістко.

Переваги та недоліки структурних випробувань

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

Переваги:

  • Дозволяє ретельне тестування коду, що призводить до мінімальних помилок. Структурне тестування дає можливість програмному забезпеченню ретельно перевірятися. Різні рівні охоплення - заява за заявою, кожна точка рішення та шлях спрямовані на досягнення 100% покриття, що значно зменшує шанси помилок не виявити.
  • Здатність до автоматизації . Існує кілька інструментів, які ми можемо використовувати для автоматизації тестування. Це допоможе нам досягти максимального охоплення коду і за коротший час порівняно з тестуванням вручну.
  • Це призводить до вищої якості коду . Розробники мають можливість вивчити структуру та реалізацію коду та виправити помилки, а також вдосконалити ці аспекти. Це дозволяє нам пам’ятати про велику структуру, коли ми пишемо наступні частини коду або реалізуємо решту функцій.
  • Це можна зробити через кожну фазу SDLC - Структурні випробування можна проводити на кожному етапі SDLC, не чекаючи завершення розробки на 100%. Це полегшує виявлення помилок на ранній стадії і тим самим економить багато часу у порівнянні з тестуванням після завершення розробки.
  • Це допомагає позбутися мертвого коду . Це можна розглядати як 'зайвий' або непотрібний код, наприклад, код, який буде обчислювати результат, але ніколи не використовує його в жодному з наступних обчислень.
  • Ефективність - Оскільки розробники, що пишуть код, ті самі, що тестують його, немає необхідності залучати інших людей, таких як QA.

Недоліки:

  • Розробники, які проводять структуроване тестування, повинні добре розуміти мову . Інші розробники та служби контролю якості, які недостатньо добре знаються на цій мові, не можуть допомогти з тестуванням.
  • Це може стати досить дорогим з точки зору часу та грошей . Для ефективного проведення тестування потрібно багато часу та ресурсів.
  • Це спричиняє затримки у наданні функцій . Це пов’язано з тим, що розробники відмовляються від створення програмного забезпечення для тестування.
  • Масштабування є проблемою, особливо там, де задіяні великі програми . Велика програма дорівнює надмірно великій кількості маршрутів, які потрібно пройти. Досягнення 100% покриття стає неможливим.
  • Можуть бути пропущені випадки та маршрути , наприклад, у випадку, коли ознаки розроблені не повністю або ще мають бути розроблені. Це означає, що його потрібно поєднувати з іншими типами тестування, такими як тестування вимог (де ми перевіряємо відповідність зазначеним особливостям, які потрібно було створити).

Найкращі практики структурного тестування

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

  • Чітко позначте і назвіть тести . Якщо комусь іншому потрібно провести тести, він повинен мати можливість легко їх знайти.
  • Перш ніж вдосконалювати код, тобто переробляючи його та оптимізуючи для використання в різних середовищах, переконайтеся, що його структура та потік ідеальні.
  • Запустіть тести окремо . Таким чином, легко виявити помилки та виправити їх. З іншого боку, ми рідше пропускаємо помилки або шляхи в результаті перекриття розділів коду, блоків або шляхів.
  • Створіть тести перед внесенням змін . Тести потрібно проводити належним чином. Таким чином, якщо щось зламається, то легко відстежити та усунути проблему.
  • Зберігайте тести для кожного розділу або блоку коду окремо . Таким чином, якщо є зміни по лінії, нам не потрібно змінювати багато тестів.
  • Виправте помилки, перш ніж продовжувати тестування . Якщо ми виявимо помилки, краще виправити їх, перш ніж перейти до тестування наступного розділу або блоку коду.
  • Ніколи не пропускайте структурні випробування з припущенням, що система контролю якості «все одно проведе тестування». Навіть якщо помилки спочатку можуть здаватися незначними, кумулятивно, вони можуть спричинити код помилки, який ніколи не може досягти прямого призначення.

Поширені запитання щодо структурного тестування

Тут ми розглянемо найпоширеніші запитання щодо структурного тестування.

Q # 1) Яка різниця між функціональним випробуванням та структурним випробуванням?

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

Q # 2) Які існують типи структурних випробувань?

Відповісти типи включають:

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

Q # 3) Що таке приклад структурного випробування?

Відповідь: Ось приклад, що демонструє висвітлення висловлень:

const addNums = (num) => { let sum = num.reduce ((a,b) => a+b); if (sum > 0) { alert(sum); } else { alert(‘please enter positive numbers’); } }; addNums();

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

Q # 4) Яка різниця між тестуванням потоку даних та контрольним тестуванням потоку?

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

Q # 5) Для чого використовується тестування потоку даних?

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

Запитання №6) Яка різниця між нарізанням та нарізуванням у тестуванні програмного забезпечення?

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

Q # 7) Яка різниця між тестуванням мутацій та покриттям коду?

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

Висновок

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

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

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

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

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

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

Рекомендована література

^