>
Великі проекти дотримуються суворої методології тестування з метою виявлення максимальної кількості дефектів. Системний підхід до тестування включає в себе кілька етапів:
. Вибір методології тестування, придбання необхідного обладнання (комп'ютери, програмне забезпечення), прийняття людей на посаду тестерів;
. Складання тестів з описом виконання і очікуваним результатом;
. Передача наборів тестів тестерам, які вручну виконують тести і записують результати;
. Передача результатів тестів розробникам в докладному доповіді з описом всіх виявлених проблем для обговорення і виправлення дефектів.
Для тестування можуть бути використані статичний і динамічний підходи. Динамічні підхід включає в себе запуск програмного забезпечення. Статистичне тестування включає в себе перевірку синтаксис та інші особливості коду програми.
Тестування може бути функціональним і не функціональним. Функціональне тестування - це перевірка робочої області програмного забезпечення. Чи не функціональне тестування - перевірка продуктивності, сумісності та безпеки тестованої системи.
Ручне тестування може застосовуватися лише до програм, які мають обмежену кількість варіантів використання. При розробці складних програмних систем можливості ручного тестування сильно обмежені, тому що при внесенні змін в код потрібно організувати повторне виконання тестів. Проте при ручному тестуванні можна виявити надзвичайно витончені помилки, що вкрай складно зробити з використанням автоматизованого тестування.
. Розробка через тестування
. 1 Основні поняття TDD.
Розробка через тестування (англ. test-driven development) - техніка програмування, при якій модульні тести для програми або її фрагмента пишуться до самої програми (англ. test-first development) і, по суті, керують її розробкою. Є однією з основних практик екстремального програмування.
Жоден програміст не вважає роботу над деяким фрагментом коду завершеною, не перевіривши перед цим його працездатність. Однак, якщо ви тестуєте свій код, це не означає, що у вас є тести.
Тест - це процедура, яка дозволяє або підтвердити, або спростувати працездатність коду. Коли програміст перевіряє працездатність розробленого ним коду, він виконує тестування вручну. У даному контексті тест складається з двох етапів: стимулювання коду і перевірки результатів його роботи. Автоматичний тест виконується інакше: замість програміста стимулюванням коду і перевіркою результатів займається комп'ютер, який відображає на екрані результат виконання тесту: код працездатний або код непрацездатний.
Методика розробки через тестування (Test-Driven Development, TDD) дозволяє отримати відповіді на питання про організацію автоматичних тестів і виробленні певних навичок тестування.
«Чистий код, який працює» - в цій короткій, але змістовної фразі, криється весь сенс методики розробки додатків через тестування. Чистий код, який працює, - це мета, до якої варто прагнути, і цьому є причини:
· Це передбачуваний спосіб розробки програм. Розробник знає, коли роботу слід вважати закінченою, і можете не турбуватися про довгій низці помилок.
· У розробника з'являється шанс засвоїти уроки, які підносить йому код. Якщо він скористається першій же ідеєю, яка прийшла йому в голову, у нього не буде шансу реалізувати другу, кращу ідею.
· Колеги по команді можуть розраховувати на розробника, а він, у, свою чергу, на них.
· Розробнику приємніше писати такий код.
Однак як ми можемо отримати чистий код, який працює? Дуже багато сили заважають нам добитися цього, а іноді нам не вдається отримати навіть код, який працює. Щоб позбутися від безлічі проблем, ми будемо розробляти код, виходячи з автоматичних тестів. Такий стиль програмування називається розробкою через тестування. У рамках цієї методики ми:
· Пишемо новий код тільки тоді, коли автоматичний код не спрацював.
· Видаляємо дублювання.
Два настільки простих правила насправді генерують складне індивідуальне та групове поведінка з безліччю технічних наслідків:
· Проектуючи код, ми постійно запускаємо його і отримуємо уявлення про те, як він працює, це допомагає нам приймати правильні рішення.
· Ми самостійно пишемо свої власні тести, так як ми не можемо чекати, що хтось інший напише тести для нас.
· Наша середу розробки повинна швидко реагувати на невеликі модифікації коду.
