Phenquestions
Одиничне тестування
Модульне тестування - це тестування, проведене на окремій функції, класі чи модулі незалежно від тестування повністю працюючого програмного забезпечення. Використовуючи фреймворк для модульного тестування, програміст може створювати тестові кейси з введенням та очікуваним результатом. Наявність сотень, тисяч або десятків тисяч модульних тестів для великого програмного проекту гарантує, що всі окремі блоки працюють належним чином, оскільки ви продовжуєте змінювати код. При зміні блоку, який має тестові кейси, слід вивчити тестові кейси для цього модуля та визначити, чи потрібні нові тестові кейси, чи змінився вихід, або поточні тестові кейси можуть бути видалені як не актуальні. Створення великого обсягу модульних тестів - це найпростіший спосіб досягти високого охоплення тестових випадків для бази програмного коду, але не гарантує, що кінцевий продукт працює як система, як очікувалося.
Функціональне тестування
Функціональне тестування - найпоширеніша форма тестування. Коли люди посилаються на тестування програмного забезпечення без особливих подробиць, вони часто мають на увазі функціональне тестування. Функціональне тестування перевірить основні функції роботи програмного забезпечення, як очікувалося. Можна скласти план тестування для опису всіх функціональних тестів, які будуть тестуватися, що відповідає основним особливостям та можливостям програмного забезпечення. Первинним тестуванням функціональності буде “щасливий шлях ” тестування, яке не намагається зламати програмне забезпечення або використовувати його в будь-яких складних сценаріях. Це має бути абсолютний мінімум тестування для будь-якого програмного проекту.
Інтеграційне тестування
Після модульного тестування та функціонального тестування може бути кілька модулів або вся система, яка ще не перевірена в цілому. Або можуть бути компоненти, які в основному незалежні, але зрідка використовуються разом. Будь-які часові компоненти або модулі перевіряються незалежно, але не як цілісна система, тоді слід провести інтеграційне тестування, щоб перевірити функціонування компонентів як робочу систему відповідно до вимог та очікувань користувача.
Стрес-тестування
Подумайте про стрес-тестування, як ви тестуєте космічний човник або літак. Що означає поставити своє програмне забезпечення чи систему під “СТРЕС”? Стрес - це не що інше, як інтенсивне навантаження певного типу, яке найімовірніше зламає вашу систему. Це може бути схоже на "Тестування навантаження" в тому сенсі, що ваша система має високий рівень паралельності з багатьма користувачами, які отримують доступ до системи. Але наголошення на системі може трапитися і на інших векторах. Наприклад, запуск мікропрограми на апаратному компоненті, коли апаратне забезпечення зазнало фізичних пошкоджень і працює в погіршеному режимі. Стрес унікальний для всіх типів програмного забезпечення, і системи та проектування стрес-тестів повинні розглядатися з урахуванням того, які природні чи неприродні причини, найімовірніше, наголошують на вашому програмному забезпеченні чи системі.
Тестування навантаження
Тестування на навантаження - це специфічний тип стрес-тестування, як обговорювалося вище, за допомогою якого велика кількість одночасних підключень та доступу користувачів автоматизується для створення імітації ефекту великої кількості автентичних користувачів, що одночасно отримують доступ до вашої програмної системи. Мета полягає в тому, щоб дізнатись, скільки користувачів може одночасно отримати доступ до вашої системи без зламу вашої програмної системи. Якщо ваша система може легко обробляти звичайний трафік 10 000 користувачів, що станеться, якщо ваш веб-сайт або програмне забезпечення стане вірусним і отримає 1 млн? Буде це несподівано “ЗАВАНТАЖИТИ” зламати ваш веб-сайт або систему? Тестування навантаження буде імітувати це, тож вам буде зручно в майбутньому збільшувати кількість користувачів, оскільки ви знаєте, що ваша система може впоратися зі збільшеним навантаженням.
Тестування продуктивності
Люди можуть розчаруватися і зневіритися, коли програмне забезпечення не відповідає їхнім вимогам до продуктивності. Ефективність, як правило, означає, як швидко можна виконати важливі функції. Чим складніші та динамічніші функції, доступні в системі, тим важливішими та не очевидними стає перевірка її продуктивності, візьмемо базовий приклад, операційна система Windows або Linux. Операційна система - це дуже складний програмний продукт, і тестування продуктивності в її системі може включати швидкість і синхронізацію функцій, таких як завантаження, установка програми, пошук файлу, запуск обчислень на графічному процесорі та / або будь-який інший мільйони дій, які можна виконати. Слід бути обережним при виборі кейсів для тестування продуктивності, щоб переконатися у важливих та можливих несправностях перевірених характеристик.
Тестування масштабованості
Тестування на своєму ноутбуці - це добре, але насправді недостатньо добре, коли ви будуєте соціальну мережу, систему електронної пошти або суперкомп’ютерне програмне забезпечення. Коли ваше програмне забезпечення призначене для розгортання на 1000 серверах, всі вони функціонують в унісон, тоді тестування, яке ви виконуєте локально в одній системі, не виявить помилок, які виникають, коли програмне забезпечення розгортається «в масштабі» на сотнях тисяч екземплярів. Насправді ваше тестування, швидше за все, ніколи не зможе працювати в повному обсязі перед випуском у виробництво, оскільки було б занадто дорого і не практично побудувати тестову систему з 1000 серверами, що коштує мільйони доларів. Таким чином, тестування масштабованості проводиться на декількох серверах, але, як правило, не повна кількість робочих серверів, щоб спробувати виявити деякі дефекти, які можуть бути виявлені, оскільки ваші системи використовуються на більшій інфраструктурі.
Тестування статичного аналізу
Статичний аналіз - це тестування, яке проводиться шляхом перевірки програмного коду без його фактичного запуску. Як правило, для статичного аналізу ви б використовували інструмент, їх існує багато, одним із відомих інструментів є Coverity. Статичний аналіз легко запустити перед випуском вашого програмного забезпечення, і він може знайти багато проблем із якістю у вашому коді, які можуть бути виправлені до випуску. Помилки пам’яті, помилки обробки типів даних, переназначення нульових покажчиків, неініціалізовані змінні та багато інших дефектів. Такі мови, як C і C ++, отримують велику користь від статичного аналізу, оскільки мови надають програмістам велику свободу в обмін на велику потужність, але це також може створити великі помилки та помилки, які можна знайти за допомогою тестування статичного аналізу.
Випробування на впорскування несправності
Деякі умови помилок дуже важко змоделювати або викликати, тому програмне забезпечення може бути розроблене для штучного введення проблеми або несправності в систему без природних дефектів. Мета тестування нагнітання несправностей - побачити, як програмне забезпечення обробляє ці несподівані несправності. Чи витончено реагує на ситуацію, чи не спрацьовує, чи не дає несподіваних і непередбачуваних проблемних результатів? Наприклад, припустимо, у нас є банківська система, і існує модуль для внутрішнього переказу коштів з РАХУНКУ А на РАХУНОК Б. Однак ця операція передачі викликається лише після того, як система вже перевірила наявність цих облікових записів до виклику операції передачі. Незважаючи на те, що ми припускаємо, що обидва облікові записи справді існують, операція передачі має випадок відмови, коли одна цільова або вихідна обліковий запис не існує, і що вона може спричинити помилку. Оскільки за звичайних обставин ми ніколи не отримуємо цієї помилки через попереднє тестування входів, тому для перевірки поведінки системи, коли передача не вдається через неіснуючий обліковий запис, ми вводимо в систему помилкову помилку, яка повертає неіснуючий рахунок для передачі та протестуйте, як у цьому випадку реагує решта системи. Дуже важливо, щоб код усунення несправностей був доступний лише в сценаріях тестування і не передавався до виробництва, де він може створити хаос.
Тестування перевитрати пам'яті
При використанні таких мов, як C або C ++, програміст несе велику відповідальність безпосередньо звертатися до пам'яті, і це може спричинити фатальні помилки в програмному забезпеченні, якщо будуть допущені помилки. Наприклад, якщо вказівник нульовий і дереференційований, програмне забезпечення вийде з ладу. Якщо пам’яті виділено об’єкт, а потім рядок скопійовано над простором пам’яті об’єкта, посилання на об’єкт може спричинити збій або навіть невизначену неправильну поведінку. Тому вкрай важливо використовувати інструмент для виявлення помилок доступу до пам'яті в програмному забезпеченні, яке використовує такі мови, як C або C ++, які можуть мати ці потенційні проблеми. Інструменти, які можуть проводити цей тип тестування, включають відкритий код Valgrind або власні інструменти, такі як PurifyPlus. Ці інструменти можуть заощадити день, коли незрозуміло, чому програмне забезпечення аварійно працює або працює неправильно, і безпосередньо вказують на місце в коді, що містить помилку. Чудово, так?
Тестування межових випадків
Легко робити помилки в кодуванні, коли ви знаходитесь на так званому кордоні. Наприклад, банківський банкомат повідомляє, що ви можете зняти максимум 300 доларів. Отже, уявіть, що кодер написав такий код природним чином, будуючи цю вимогу:
Якщо (amt < 300)startWithdrawl ()
ще
помилка ("Ви можете зняти% s", amt);
Ви можете помітити помилку? Користувач, який намагається зняти $ 300, отримає повідомлення про помилку, оскільки воно становить не менше $ 300. Це помилка. Тому граничне тестування проводиться природним шляхом. Тоді межі вимог гарантують, що по обидва боки межі та межі програмне забезпечення функціонує належним чином.
Нечітке тестування
Швидкісне генерування вхідних даних у програмне забезпечення може створити якомога більше можливих комбінацій вхідних даних, навіть якщо ці комбінації вхідних даних є цілковитою нісенітницею і ніколи не будуть надані реальним користувачем. Цей тип нечіткого тестування може виявити помилки та уразливості системи безпеки, не виявлені іншими способами через великий обсяг вхідних даних та сценаріїв, що швидко тестуються без генерації ручного тестування.
Пошукове тестування
Закрийте очі і уявіть собі, що означає слово «Дослідити». Ви спостерігаєте та досліджуєте систему, щоб з’ясувати, як вона справді функціонує. Уявіть, що ви отримуєте новий стіл на столі поштою, і в ньому 28 деталей у всіх окремих пластикових пакетах без інструкцій. Ви повинні вивчити своє нове прибуття, щоб з’ясувати, як воно функціонує та як воно складено. Завдяки цьому духу ви можете стати дослідником. У вас не буде чітко визначеного плану тестування тестів. Ви дослідите і дослідите своє програмне забезпечення, шукаючи речі, які змусять вас сказати чудове слово: “ЦІКАВО!". Дізнавшись, ви досліджуєте далі і знаходите способи зламати програмне забезпечення, про яке дизайнери ніколи не думали, а потім надаєте звіт, в якому детально описуються численні погані припущення, помилки та ризики в програмному забезпеченні. Дізнайтеся більше про це в книзі під назвою Explore It.
Випробування на проникнення
У світі програмної безпеки тестування на проникнення є одним з основних засобів тестування. Усі системи, будь то біологічна, фізична чи програмна, мають межі та межі. Ці межі призначені для того, щоб в систему могли потрапляти лише певні повідомлення, люди або компоненти. Більш конкретно, давайте розглянемо систему Інтернет-банкінгу, яка використовує автентифікацію користувачів для входу на сайт. Якщо сайт можна зламати та увійти у серверну систему без належної автентифікації, це буде проникненням, яке потрібно захистити від. Метою тестування на проникнення є використання відомих та експериментальних методів для обходу нормальних меж безпеки програмної системи або веб-сайту. Тестування на проникнення часто передбачає перевірку всіх портів, які прослуховують, та спробу входу в систему через відкритий порт. Інші поширені методи включають введення SQL або злом пароля.
Регресійне тестування
Після того, як у вас є робоче програмне забезпечення, яке розгортається в полі, дуже важливо запобігти введенню помилок у функціонал, який вже працював. Метою розробки програмного забезпечення є збільшення можливостей вашого продукту, введення помилок або переставання працювати старих функціональних можливостей, що називається РЕГРЕСІЯ. Регресія - це помилка або дефект, які були введені, коли раніше функціонування функціонувало належним чином. Ніщо не може зруйнувати репутацію вашого програмного забезпечення чи бренду швидше, ніж впровадження помилок регресії у ваше програмне забезпечення та надання реальним користувачам цих помилок після випуску.
Випадки регресійного тестування та плани тестування повинні будуватися навколо основної функціональності, яка повинна продовжувати працювати, щоб користувачі мали хороший досвід роботи з вашим додатком. Усі основні функції вашого програмного забезпечення, які користувачі очікують працювати певним чином, повинні мати тест на регресію, який можна виконати, щоб запобігти порушенню функціональності нового випуску. Це може бути від 50 до 50 000 тестових випадків, які охоплюють основні функції вашого програмного забезпечення чи програми.
Тестування бісекцій вихідного коду
У програмному забезпеченні була введена помилка, але не очевидно, яка версія випуску внесла нову помилку. Уявіть, що було 50 комітів програмного забезпечення з останнього відомого часу, коли програмне забезпечення працювало без помилки, і дотепер, коли ..
Тестування локалізації
Уявіть програму погоди, яка показує поточну та прогнозовану погоду у вашому місцезнаходженні, а також опис погодних умов. Перша частина тестування на локалізацію полягає у забезпеченні належного відображення правильної мови, алфавіту та символів, залежно від геолокації користувача. Додаток у Великобританії повинен відображатися англійською мовою з латинськими символами; той самий додаток у Китаї повинен відображатися китайськими символами на китайській мові. Більш складне тестування на локалізацію зробить, і ширший спектр людей з різних геолокацій буде взаємодіяти з додатком.
Перевірка доступності
Деякі громадяни нашої громади мають інвалідність, а отже, можуть мати проблеми із використанням програмного забезпечення, що створюється, тому тестування доступності проводиться для того, щоб населення з інвалідністю все ще мало доступ до функціональних можливостей системи. Наприклад, якщо ми припустимо, що 1% населення є дальтоніком, а наш програмний інтерфейс передбачає, що користувачі можуть розрізняти червоний та зелений, але ці дальтоніки НЕ МОЖУТЬ сказати різницю. Отже, добре програмний інтерфейс матиме додаткові сигнали, крім кольору, щоб вказати значення. Інші сценарії, крім тестування дальтонізму, також будуть включені в тестування доступності програмного забезпечення, такі як повна візуальна сліпота, глухота та багато інших сценаріїв. Хороший програмний продукт повинен бути доступним для максимального відсотка потенційних користувачів.
Тестування оновлення
Прості додатки на телефоні, операційні системи, такі як Ubuntu, Windows або Linux Mint, і програмне забезпечення, яке працює на атомних підводних човнах, потребують частого оновлення. Сам процес оновлення може спричинити помилки та дефекти, яких не було б при новій установці, оскільки стан навколишнього середовища був іншим, а процес впровадження нового програмного забезпечення поверх старого міг спричинити помилки. Візьмемо простий приклад: у нас є ноутбук під управлінням Ubuntu 18.04, і ми хочемо перейти на Ubuntu 20.04. Це інший процес встановлення операційної системи, ніж безпосереднє очищення жорсткого диска та встановлення Ubuntu 20.04. Отже, після встановлення програмного забезпечення або будь-якої з його похідних функцій воно може працювати не на всі 100%, як очікувалося, або так само, як коли свіже встановлене програмне забезпечення. Отже, спочатку слід розглянути тестування самого оновлення у багатьох різних випадках та сценаріях, щоб переконатися, що оновлення працює до кінця. А потім ми також повинні розглянути можливість тестування фактичної системи після оновлення, щоб переконатися, що програмне забезпечення було встановлене та функціонувало належним чином. Ми не будемо повторювати всі тести свіжовстановленої системи, що було б марною тратою часу, але ми ретельно продумаємо, знаючи систему, що МОЖЕ зламати під час оновлення та стратегічно додати тестові кейси для цих функцій.
Тестування Black Box & White Box
Чорний ящик та білий ящик є менш специфічними методологіями тестування та більшою кількістю типів тестування за категорізаціями. По суті, тестування чорної скриньки, яке передбачає, що тестувальник нічого не знає про внутрішню роботу програмного забезпечення, і складає план тестування та тестові кейси, які просто дивляться на систему ззовні, щоб перевірити її функціонування. Тестування «білої скриньки» проводять архітектори програмного забезпечення, які розуміють внутрішню роботу програмної системи та розробляють кейси зі знанням того, що може, що, що потрібно, і що може призвести до порушення. І тестування чорного, і білого ящиків може виявити різні типи дефектів.
Блоги та статті про тестування програмного забезпечення
Тестування програмного забезпечення - це динамічне поле, і багато цікавих публікацій та статей, які оновлюють спільноту про сучасне мислення щодо тестування програмного забезпечення. Ми всі можемо отримати користь від цих знань. Ось зразок цікавих статей з різних джерел блогу, за якими ви, можливо, захочете стежити:
- 7 порад, яким слід дотримуватися перед тестуванням без вимог; http: // www.тестування журналів.com /
- 60 найкращих засобів тестування автоматизації: Посібник з остаточного списку; https: // testguild.com /
- Засоби тестування бази даних з відкритим кодом; https: // www.журнал тестування програмного забезпечення.com /
- 100 відсотків одиниці тестового покриття недостатньо; https: // www.липкі розуми.com /
- Нестабільні тести в Google і як ми їх пом’якшуємо; https: // тестування.googleblog.com /
- Що таке тестування на регресію? ; https: // тест.io / blog /
- 27 найкращих розширень Chrome для розробників у 2020 році; https: // www.лямбдатест.com /
- 5 ключових етапів тестування програмного забезпечення, які повинен виконати кожен інженер; https: // techbeacon.com /
Продукти для тестування програмного забезпечення
Більшість цінних завдань тестування можна автоматизувати, тому не дивно, що використання інструментів та продуктів для виконання безлічі завдань забезпечення якості програмного забезпечення є гарною ідеєю. Нижче ми перелічимо деякі важливі та дуже цінні програмні засоби для тестування програмного забезпечення, які ви можете вивчити та побачити, чи можуть вони допомогти.
JUnit
Для тестування програмного забезпечення на базі Java JUnit надає комплексний набір тестів для модульного та функціонального тестування коду, дружнього до середовища Java.
Селен
Для тестування веб-додатків Selenium надає можливість автоматизувати взаємодію з веб-браузерами, включаючи тестування сумісності між браузерами. Це найкраща інфраструктура тестування для автоматизації веб-тестування.
Огірок
Структура тестування, керована поведінкою, дозволяє бізнес-користувачам, менеджерам продуктів та розробникам пояснити очікувані функціональні можливості натуральною мовою, а потім визначити цю поведінку в тестових випадках. Це робить більш читабельними тестові приклади та чітким відображенням очікуваних функціональних можливостей користувача.
Очистити
Знайдіть витоки пам’яті та пошкодження пам’яті під час виконання, виконуючи програмне забезпечення за допомогою вбудованого приладу Purify Plus, який відстежує використання пам'яті та вказує на помилки у коді, які непросто знайти без інструментарію.
Вальгрінд
Інструменти з відкритим кодом, які виконуватимуть ваше програмне забезпечення та дозволять вам взаємодіяти з ним, одночасно вказуючи на звіт про помилки кодування, такі як витоки пам'яті та пошкодження. Не потрібно перекомпілювати або додавати контрольно-вимірювальні прилади в процес компіляції, оскільки Valgrind має інтелект для динамічного розуміння вашого машинного коду та безперешкодного введення контрольно-вимірювальних приладів, щоб знайти помилки кодування та допомогти вам покращити ваш код.
Покриття
Засіб статичного аналізу, який виявить помилки кодування у вашому програмному забезпеченні ще до того, як ви навіть скомпілюєте та запустите свій код. Покриття може знайти вразливості безпеки, порушення правил кодування, а також помилки та дефекти, які ваш компілятор не знайде. Можна знайти мертвий код, неініціалізовані змінні та тисячі інших типів дефектів. Дуже важливо очистити свій код за допомогою статичного аналізу, перш ніж випустити його у виробництво.
JMeter
Фреймворк з відкритим кодом для тестування продуктивності, орієнтований на розробників на базі Java, звідси і назва J. Тестування веб-сайтів є одним з основних випадків використання JMeter на додаток до тестування продуктивності баз даних, поштових систем та багатьох інших серверних додатків.
Метасплойт
Для тестування на безпеку та проникнення, Metasploit - це загальний фреймворк з тисячами функцій та можливостей. Використовуйте консоль взаємодії для доступу до попередньо закодованих експлойтів та спробуйте перевірити безпеку своєї програми.
Академічні дослідження з тестування програмного забезпечення
- Тестова дослідницька група університету Шеффілда
- Лабораторія верифікації та перевірки програмного забезпечення Університету Кентуккі
- Дослідницька група з тестування програмного забезпечення Державного університету Північної Дакоти
- Тестування системи Intelligent Lab; Чеський технічний університет Прага
- NASA: Джон Макбрайд Тестування та дослідження програмного забезпечення (JSTAR)
- Університет Макмастера; Лабораторія досліджень якості програмного забезпечення
- Технічний університет Онтаріо; Лабораторія дослідження якості програмного забезпечення
- Техаський університет @ Даллас; STQA
Висновок
Роль програмного забезпечення в суспільстві продовжує зростати, і в той же час програмне забезпечення у світі стає більш складним. Щоб світ функціонував, ми повинні мати методи та стратегії для тестування та перевірки програмного забезпечення, яке ми створюємо, виконуючи функції, які він призначений виконувати. Для кожної складної програмної системи повинна бути встановлена стратегія тестування та план тестування, щоб продовжувати перевіряти функціональність програмного забезпечення, оскільки вони продовжують вдосконалюватися та забезпечувати його функціонування.
