Я студент, що працює над моїм BE (CS), і моє запитання таке:

1. Чи потрібно тестування в галузі програмного забезпечення?
2. Якщо ми створюємо програмне забезпечення з великою ретельністю, то навіщо нам тестувати?
3. Після тестування чи можемо ми бути впевнені, що ми досягли цієї мети (продукт / програмне забезпечення працює за призначенням), оскільки ми зробили тестування для цього? Це можливо?

Моє запитання: чи потрібно тестування програмного забезпечення ?

Так. Бо як би ти не був хороший, ти не можеш думати про все.

• Вас також попросять змусити ваше програмне забезпечення робити те, чого ви ніколи не збиралися робити.
• Ви також ніколи не будете мати такі чіткі вимоги, що зможете продумати кожну можливість, щоб переконатися, що код не порушиться.
• Ви також будете працювати з чужим програмним забезпеченням та apis, які не завжди працюватимуть за призначенням, але ви вважатимете, що це робить або має призвести до дефектів у вашому «ідеальному» випадку.

Так

З тієї ж причини, що кухар скуштує свою їжу, готуючи її.

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

ВІДСУТНІСТЬ З ПРАВИЛЬНОГО ВИПРОБУВАНЬ УБИВАЄ .

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

Програмне забезпечення пишуть люди.

Люди недосконалі і допускають помилки.

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

Так що так, тестування потрібне. Це приносить рівновагу та перспективу.

Чи потрапите ви на рейс, який працює з ОС, яку ви знаєте, що використовували на своєму ноутбуку і подарував вам екран смерті в улюбленому кольорі? Подумай над цим.

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

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

А на рівні коледжу ознайомтеся з розробкою тестових розробок, тестуванням підрозділів та спритною практикою, щоб знати, де зараз справи.

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

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

Errare humanum est

Немає такого поняття, як програмне забезпечення без помилок.

Найдосвідченіший розробник пише код з помилками. Навіть якби існував ідеальний розробник, все-таки з’являться помилки через розбіжності між:

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

Ідеальний розробник - лише частина всієї справи. І ідеальних розробників не існує.

Більшість програм із реального життя:

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

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

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

ТАК.

Ось ще одна делікатніша перспектива, яка ще не повністю висвітлена:

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

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

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

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

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

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

Як ви думаєте, що дало йому впевненості зробити це?

Ви постійно тестуєте код, просто складаючи та використовуючи його. У деяких IDE ви отримуєте перевірки санітарності під час введення. Якщо ви ніколи насправді не запустите свій код, ви проводите тестування.

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

Пахне запитанням домашнього завдання.

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

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

Якщо ми створюємо програмне забезпечення з великою ретельністю, то навіщо нам тестувати?

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

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

Після тестування чи можемо ми бути впевнені, що ми досягли цієї мети (продукт / програмне забезпечення працює за призначенням), оскільки ми зробили тестування для цього? Це можливо?

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

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

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

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

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

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

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

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

1.) усунути якнайбільше можливих збоїв за допомогою проектування та належної реалізації 2.) усунути непередбачувані збої на етапі проектування та неправильну реалізацію за допомогою різних форм тестування (одиниця, інтеграція, випадкове) 3.) вирішити будь-які залишені збої через надмірність ( тимчасова => перерахувати, повторити або просторово => зберегти копії, паритет)

Якщо ви усунете фазу тестування, ви залишаєте лише фази проектування та надмірності для усунення несправностей.

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

Усі програми мають помилки, принаймні для початку.

Було проведено кілька досліджень, які сходяться приблизно на 1 помилку на кожні п’ять рядків неперевіреного коду.

Урок історії:

Ще в 1960-х IBM потребувала програми "NOP", щоб вони могли виконувати певні функціональні можливості в JCL без фактичного запуску програми. Розробники розробили програму асемблера з одним рядком, в якій весь код містився під назвою "IEFBR14", а фактичний код:

       BR 14 * brach to return address in register 14

Протягом тривалої роботи цієї однолінійної програми було піддано 2 повідомлення про помилки та п'ять поправок.

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

Коли ви розробляєте TDD (тестова розробка), у вас немає зайвих геттерів / сеттерів тощо. Ви просто створюєте те, що вам потрібно.

Щоб відповісти на №3 вашого запитання:

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

{надягати QA капелюх}

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

{QA hat off]

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

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

Але це не так. ++++++++

Помилки трапляються часто, деякі з них є критичними для роботи проекту. Існує також крос-браузерне тестування (мається на увазі тестування на різних існуючих браузерах, таких як SAFARI, FIREFOX, CHROME та Internet Explorer), і я працював над проектом, де прості кнопки інтерфейсу, як YES і NO, у вікні опитування, де не працюють лише у всіх браузерах. дехто з них.

Я працював над тестуванням Інтернет-сторінок і тестував прості ТЕКСТОВІ ЗМІНИ і думав собі, що жодним чином на землі не може бути дефектів цієї простої роботи, але цього не відбувається.

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

ТАК

Уявіть, що ваше програмне забезпечення - це лише логічна функція AND (b1, b2), де b1 і b2 - лише біти. Для цього вам потрібно 4 тестові випадки, щоб переконатися, що ваше програмне забезпечення не містить помилок, якщо ваше оточення забезпечує саме те, для чого вони були визначені.

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

(далі буде)