Реферат Тестування програмного забезпечення

Тема: Курсовые проекты

но важче протестувати. Модульне тестування сприяє формуванню чітких і невеликих інтерфейсів. Кожен клас буде виконувати певну роль, як правило невелику. Як наслідок, залежності між класами буде знижуватися, а зачеплення підвищуватися. Контрактне програмування lt; # justify gt; 7.9 Слабкі місця

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

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

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

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

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

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

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

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

. Безперервна інтеграція

. 1 Поняття безперервної інтеграції

Безперервна інтеграція (англ. lt; # justify gt; 8.2 Вимоги до проекту

· Вихідний код і все, що необхідно для побудови та тестування проекту, зберігається в репозиторії системи управління версіями lt; # justify gt; 8.3 Організація

На виділеному сервері організовується служба, до завдань якої входять:

· отримання вихідного коду з репозиторію;

· збірка проекту;

· виконання тестів;

· розгортання готового проекту;

· відправка звітів.

Локальна збірка може здійснюватися:

· по зовнішнім запитом,

· за розкладом,

· за фактом поновлення репозиторію lt; # justify gt; .4 Збірка за розкладом

У разі збірки за розкладом (англ. lt; # justify gt; 8.5 Переваги

· проблеми інтеграції виявляються і виправляються швидко, що виявляється дешевше;