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

Термінологія Quality assurance

У цій статті ми будемо розглядати QA (Quality Assurance) в розробці програмного забезпечення. Все це ставитися до тестування програмного забезпечення, але в цій статті ми не будемо вивчати тонкощі, а лише розберемося з термінологією. Термінологія в QA дуже важлива, без неї не можливо буде провести тестування продукту. Як вже могли здогадатися, QA розшифровується як Quality Assurance що в перекладі - забезпечення якості (контроль якості). Перейдемо безпосередньо до термінології:

Позитивне тестування (positive testing)

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

Негативний тестування (negative testing)

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

Функціональне тестування (functional testing)

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

Функціональні тестування включають в себе:

• Функціональна придатність (suitability)
• Точність (accuracy)
• Здатність до взаємодії (interoperability)
• Відповідність стандартам і правилам (compliance)
• Захищеність (security)

Тестування продуктивності (performance testing)

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

Тестування продуктивності включають в себе:

• Тестування навантаження (load testing)
• Стрес-тестування (stress testing)
• Тестування стабільності (stability / endurance / soak testing)

Тестування зручності використання (usability testing)

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

Тестування для користувача інтерфейсу (UI testing)

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

Тестування безпеки (security testing)

Процес оцінки вразливості програмного забезпечення до різних атак.

Тестування локалізації (localization testing)

Це процес тестування локалізованої версії програмного продукту. Перевірка правильності перекладу елементів інтерфейсу користувача, перевірка правильності перекладу системних повідомлень і помилок, перевірка перекладу розділу "Допомога" / "Довідка" та супровідної документації.

Тестування сумісності (compatibility testing)

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

Оточення може включати в себе наступні елементи:

• Апаратна платформа;
• Мережеві пристрої;
• Периферія (принтери, CD / DVD-приводи, веб-камери і т.д);
• Операційна система (Unix, Windows, MacOS, ...)
• Бази даних (Oracle, MS SQL, MySQL, ...)
• Системне програмне забезпечення (веб-сервер, файрвол, антивірус, ...)
• Браузери (Internet Explorer, Firefox, Opera, Chrome, Safari)

Тестування чорного ящика (black box)

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

Тестування білого ящика (white box)

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

Тестування сірого ящика (grey box)

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

Ручне тестування (manual testing)

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

Автоматизоване тестування (automated testing)

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

Модульне тестування (component / unit testing)

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

Інтеграційне тестування (integration testing)

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

Системне тестування (system / end-to-end testing)

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

Ми розглянули лише невелику частину термінології, але досить важливу в QA. Можливо, ми ще торкнемося теми тестування, а на сьогодні це все.

Схожі статті:

Рішення проблем Adobe Flash на прикладі YouTube - Читати

1. pidval зробив (а) реблог цього від
2. alexruzhyk сподобалося це
3. anko-777 зробив (а) реблог цього від
4. сподобалося це
5. maryarti сподобалося це
6. dfdor44f сподобалося це
7. eridi зробив (а) реблог цього від
8. seonoptik сподобалося це

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

Багато тестувальники ніколи не забудуть про негативний тестуванні, хоча не всі програмісти цим задоволені. Такий контроль потрібен для захисту від хакерів, ботів, Dos / DDos атак.

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

Позитивне і негативний тестування

Давайте почнемо з самого початку. Є 2 види контролю, коли тест-кейси включені в тестування: позитивний і негативний. Перевага у останнього.

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

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

Позитивно-негативна тестування

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

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

Зрештою, чим ближче час Х, тим швидше йде час і тим швидше треба виконувати завдання, виправляти дефекти, застосовувати бізнес-вимоги (які можуть варіюватися) і зробити ще багато справ. Дедлайн - це самий жаркий час!

Поділ негативного і позитивного тестування просто суперечить природі тестувальника! Його завдання - перевірити систему на всі можливі дії кінцевого користувача.

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

Ми (не такий вже це і секрет) дуже переживаємо за якість своїх продуктів і з трепетом спостерігаємо за обвалювання системи. Це виправдовує існування тестувальників в світі. Це змушує нас відчувати себе героями: прийшов великий Тестер і врятував своїх користувачів від жахливих критичних багів!

І наші тестувальники ніколи не забувають про негативний тестування, хоча не всіх прогерія це радує. Але такі перевірки не примха «злих тестерів», вони викликані необхідністю закрити уразливості і убезпечитися від проникнення в систему хакерів і ботів, Dos / DDos атак.

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

Розумієте, програмісти-то пишуть софт, націлюючись на результат, на запланований реліз, летять на крилах натхнення! А тут настає етап перевірки і численних виправлень і правок «ідеального» коду. І все, ховайся хто куди, система на тестуванні.

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

Позитивне і негативний тестування

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

позитивне тестування - це перевірка роботи системи на відповідність її нормальному (штатним, очікуваному) поведінки, согласно ТЗ і. Тобто тут ми дивимося, чи робить ПО то, чого від нього чекають, чи відповідає реалізація сучасним вимогам, підтримані чи гайдлайни призначеного для користувача інтерфейсу і т.д.

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

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

Тому, на нашу думку,

Негативний і позитивний тестування взагалі не потрібно розділяти і розносити в часі.

Оскільки можемо ми сказати, що система працює як треба, якщо перевіряємо її реакцію тільки на правильних вхідних даних?

Позитивно-негативна тестування

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

Перевіряє все по ТЗ і тестовим сценаріями, дивиться, як дані обробляються, які користувач повинен ввести в поля (не факт, що введе, до речі) і тут ось воно - осяяння! Йому здається, що якщо ввести ось в це поле для login який-небудь «% адинадин /\u003e», а не звичайний текст, то щось точно відбудеться. Щось темне і похмуре неправильне.

І що? Він повинен сказати собі: «Ні. Зараз я повинен займатися позитивним тестуванням і нічим іншим. Ось у мене призначено негативний наступного тижня, тоді й настане час для% адинадин /\u003e. Напевно"?

Ми вважаємо такий підхід до негативного тестування неефективним, і ось чому:

1. Якщо проводити позитивне і негативне тестування окремо, то це буде довше. Як мінімум тому, що це будуть вже дві ітерації тестування.
2. Тестери і кодери живуть в умовах дедлайнів. І якщо час строго обмежена, то відкладання негативного тестування на потім підвищує ризик того, що про нього взагалі в результаті забудуть. Адже чим ближче до моменту Х, тим швидше летить час, швидше за потрібне виконати поставлені завдання, виправити дефекти, застосувати фінальні бізнес вимоги (які можуть бути змінені) і доробити ще купу справ. Дедлайн - час гаряче!
3. Поділ негативного і позитивного тестування, на нашу думку, просто суперечить природі тестера! Адже основне його завдання - це перевірка системи на всі можливі дії кінцевого користувача. А люди в більшості своїй нелогічні, і можуть робити з софтом найрізноманітніші непристойне;)

Ми, як тестувальники, дуже переживаємо, якщо система містить помилки щодо перевірок з категорії негативних. І особливо, якщо наслідки таких помилок критичні для всієї системи. Але репорт їх не боїмося. Особливо з таким козирем в рукаві - у нас в команді є дівчатка-тестіровщіци. І хто зможе наполегливо відстоювати «ідеальність» коду, коли вони ніжними голосками в пух і прах розносять працездатність проекту? То то же.

Так які висновки ми можемо зробити?

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

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

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

· «Позитивне» тестування ». На цій стадії необхідно перевірити результат роботи програми при отриманні ним «правильних» вхідних даних.

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

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

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

1) перевірте, як працює додаток, коли воно отримує навход коректні дані;

2) якщо все працює правильно, як описано в спеціфікацііследующім кроком є \u200b\u200bперевірка граничних значень (мінімальні і максимальні значення коректних даних);

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

У перших двох пунктах описаний процес, який називається «позитивним» тестуванням.

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

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

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

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

Дайте визначення функціонального, навантажувальних, стрес-тестування і тестування стабільності.

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

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

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

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

Питання до теми 18

При тестуванні програмного продукту застосовують велику кількість різних видів тестів. Найбільш широку і детальну класифікацію запропонував автор книги «Тестування Дот Ком» Роман Савін. Він об'єднав види тестування за такими ознаками, як об'єкт, суб'єкт тестування, рівень, позитивність тестування, і ступінь автоматизації тестування. Класифікація була доповнена на підставі таких джерел, як книга Сема Канера, «Тестування програмного забезпечення» та інтернет-ресурс, присвячений тестуванню, «Про Тестінг - Тестування Програмного Забезпечення».

По об'єкту тестування

• · Функціональне тестування. Функціональне тестування на сьогоднішній день є одним з найбільш часто вживаних видів тестування. Завдання такого тестування - це встановити на скільки відповідає розроблене програмне забезпечення (ПО) вимогам замовника з точки зору функціоналу. Інакше кажучи, проведення функціональних тестів дозволяє перевірити здатність інформаційної системи вирішувати завдання користувачів.
• · Нефункціональні тестування. Дозволяє перевірити відповідність властивостей програмного забезпечення з поставленими нефункціональними вимогами. Таким чином, нефункціональне тестування - це тестування всіх властивостей програми, що не відносяться до функціональності системи. Такими властивостями можуть бути пред'явлені характеристики з точки зору таких параметрів як:
• - Надійність (здатність системи реагувати на непередбачені ситуації).
• - Продуктивність (здатність системи працювати під великими навантаженнями).
• - Зручність (дослідження зручності роботи користувача з додатком).
• - Масштабованість (можливість масштабувати додаток як вертикально, так і горизонтально).
• - Безпека (дослідження можливості порушення роботи програми та крадіжки призначених для користувача даних зловмисниками).
• - портіруемость (можливість перенести додаток на певний набір платформ)

І багато інших якостей.

• · Тестування для користувача інтерфейсу. Це тестування коректності відображення елементів призначеного для користувача інтерфейсу на різних пристроях, правильності реагування на них на вчинення користувачем різних дій наскільки і оцінка того, наскільки очікувано поводиться програма в цілому. Таке тестування дає можливість оцінити, наскільки ефективно користувач зможе працювати з додатком і наскільки зовнішній вигляд програми відповідає затвердженим документам, створеними дизайнерами. При проведенні тестування користувальницького інтерфейсу основним завданням тестувальника є виявлення візуальних і структурних недоліків в графічному інтерфейсі додатка, перевірці можливості і зручності навігації в додатку і коректність обробки додатком введення даних з клавіатури, миші та інших пристроїв введення. Тестування для користувача інтерфейсу необхідно для того, щоб переконатися в тому, що інтерфейс відповідає затвердженим вимогам і стандартам, і гарантувати можливість роботи користувача з графічним інтерфейсом програми.
• · Тестування зручності використання. Це спосіб тестування, що дозволяє оцінити ступінь зручності використання програми, швидкість навчання користувачів при роботі з програмою, а також наскільки користувачі продукту, що розробляється знаходять її зрозумілою і привабливою в контексті заданих умов. Таке тестування необхідно для забезпечення максимально позитивного користувацького досвіду при роботі з додатком.
• · Тестування захищеності. Дозволяє виявити головні уразливості програмного забезпечення по відношенню до різних атак з боку зловмисників. Комп'ютерні системи досить часто піддаються кібер атак з метою порушення працездатності інформаційної системи або крадіжки конфіденційних даних. Тестування безпеки дає можливість проаналізувати реальну реакцію і дієвість захисних механізмів, використаних в системі, при спробі проникнення. В процесі тестування безпеки тестувальник намагається виконувати ті ж дії, які виконував би справжній зломщик. При спробі тестувальником зламати систему можуть використовуватися будь-які засоби: атаки системи за допомогою спеціальних утиліт; спроби дізнатися логіни і паролі за допомогою зовнішніх засобів; DDOS атаки; цілеспрямована генерація помилок для виявлення можливості проникнення в систему в процесі її відновлення; використання відомих незакритих уразливостей системи.
• · Інсталяційне тестування. Під цим терміном мають на увазі тестування коректності установки (інсталяції) певного програмного продукту. Таке тестування зазвичай відбувається в штучно створених середовищах з метою виявити ступінь готовності програмного забезпечення до експлуатації. Основні причини проведення таких тестів пов'язані з необхідністю перевірити коректність поведінки програмного продукту при автоматизованому розгортанні або оновленні. Забезпечення правильної та стабільної установки програмного забезпечення є дуже важливим фактором при створенні програмного продукту, оскільки дозволяє користувачам швидше і з меншими зусиллями почати використовувати продукт, при цьому забезпечуючи однаково коректну поведінку цього продукту у всіх протестованих програмних середовищах.
• · Конфігураційне тестування. Конфігураційне тестування призначене для оцінки працездатності програмного забезпечення при різноманітних конфігураціях системи. Залежно від типу тестованого програмного продукту, конфигурационное тестування може переслідувати різні цілі. Зазвичай це або визначення оптимальної конфігурації обладнання, що забезпечує достатні для роботи ПО параметри продуктивності, або перевірка певної конфігурації устаткування (або платформи, що включає в себе крім обладнання, стороннє ПО, необхідне для роботи програми) на сумісність з тестованим продуктом. Якщо мова йде про клієнт-серверному програмному забезпеченні, то конфигурационное тестування проводиться окремо для сервера і окремо для клієнта. Зазвичай при тестуванні сумісності сервера з певною конфігурацією стоїть завдання знайти оптимальну конфігурацію, оскільки важлива стабільність роботи і продуктивність сервера. У той час як при тестуванні клієнта, навпаки, намагаються виявити недоліки ПО при будь-яких конфігураціях і по можливості усунути їх.
• · Тестування надійності і відновлення після збоїв (стресове тестування). Такий вид тестування досить часто проводиться для програмного забезпечення, що працює з цінними даними користувачів, безперебійність роботи і швидкість відновлення після збоїв якого критичні для користувача. Тестування на відмову і відновлення здійснює перевірку здатності програми швидко і успішно відновлюватися після відмови обладнання, перебоїв мережі або критичних помилок в самому програмному забезпеченні. Це дає можливість оцінити можливі наслідки відмови і час, необхідний для подальшого відновлення системи. На основі отриманих в ході тестування даних може бути оцінена надійність системи в цілому, і, за умови незадовільних показників, відповідні заходи, спрямовані на поліпшення систем відновлення, можуть бути прийняті
• · Тестування локалізації. Тестування локалізації дає можливість з'ясувати наскільки добре пристосований продукт для населення певних країн і наскільки він відповідає її культурним особливостям. Зазвичай, розглядаються культурний і мовний нюанси, а саме переклад користувацького інтерфейсу, супутньої документації та файлів на певну мову, також тестується правильність форматів валют, чисел, часу і телефонних номерів.
• · Тестування навантаження. Тестування навантаження дозволяє виявити максимальну кількість однотипних завдань, які програма може виконувати паралельно. Найпопулярніша мета навантажувального тестування в контексті клієнт-серверних додатків - це оцінити максимальну кількість користувачів, які зможуть одночасно користуватися послугами програми.
• · Тестування стабільності. Тестування стабільності перевіряє працездатність додатки при тривалому використанні на середніх навантаженнях. Залежно від типу програми, формуються певні вимоги до тривалості його безперебійної роботи. Тестування стабільності прагне виявити такі недоліки додатки як витоку пам'яті, наявність яскраво виражених стрибків навантаження та інші фактори, здатні перешкодити роботі програми протягом тривалого періоду часу.
• · Об'ємне тестування. Завданням об'ємного тестування поставлено виявлення реакції додатка і оцінка можливих погіршень в роботі ПО при значному збільшенні кількості даних в базі даних програми. Зазвичай в таке тестування входить:
• - Вимірювання часу виконання операцій, пов'язаних з отриманням або зміною даних БД при певній інтенсивності запитів.
• - Виявлення залежності збільшення часу операцій від обсягу даних в БД.
• - Визначення максимальної кількості користувачів, які мають можливість одночасно працювати з додатком без помітних затримок з боку БД.
• Тестування масштабованості. Це вид тестування програмного забезпечення, призначений для перевірки здатності продукту до збільшення (іноді до зменшення) масштабів певних нефункціональних можливостей. Деякі види додатків повинні легко масштабироваться і, при цьому, зрозуміло, залишатися працездатними і витримувати певну призначену для користувача навантаження.

Тестування, пов'язане зі змінами

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

За рівнем тестування

• · Модульне тестування (Unit тести). Полягає в перевірці кожного окремого модуля (самобутнього елементу системи) шляхом запуску автоматизованих тестів в штучному середовищі. Реалізації таких тестів часто використовують різні заглушки і драйвери для імітації роботи реальної системи. Модульне автоматизоване тестування - це найперша можливість запустити і перевірити вихідний код. Створення Unit тестів для всіх модулів системи дозволяє дуже швидко виявляти помилки в коді, які можуть з'явитися в ході розробки.
• · Інтеграційний тестування. Це тестування окремих модулів системи на предмет коректної взаємодії. Основна мета інтеграційного тестування - знайти дефекти і виявити некоректну поведінку, пов'язане з помилками в інтерпретації або реалізації взаємодії між модулями.
• · Системне тестування. Це тестування програми в цілому, таке тестування перевіряє відповідність програми заявленим вимогам.
• · Приймальне тестування. Це комплексне тестування, що визначає фактичний рівень готовності системи до експлуатації кінцевими користувачами. Тестування проводиться на підставі набору тестових сценаріїв, що покривають основні бізнес-операції системи.

За виконання коду

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

По суб'єкту тестування

• · Альфа-тестування. Це тестування проводиться для найбільш ранніх версій комп'ютерного програмного забезпечення (або апаратного пристрою). Альфа-тестування майже завжди проводиться самими розробниками ПЗ. В процесі альфа-тестування розробники програми знаходять і виправляють помилки і проблеми, наявні в програмі. Зазвичай, під час Альфа-тестування відбувається імітація роботи з програмою штатними розробниками, рідше має місце реальна робота як потенційних користувачів, так і замовників з продуктом. Як правило, альфа-тестування проводиться на самому ранньому етапі розробки ПО, однак в окремих випадках може бути застосоване для закінченого або близького до завершення продукту, наприклад, в якості приймального тестування.
• · Бета-тестування. Тестування продукції, як і раніше знаходиться в стадії розробки. При бета-тестуванні цей продукт надається для деякої кількості користувачів, для того щоб вивчити і повідомити про виникаючі проблеми, з якими стикаються користувачі. Таке тестування необхідно щоб знайти помилки, які розробники могли пропустити. Зазвичай бета-тестування проводиться в дві фази: закритий бета-тест і відкрите бета-тестування. Закритий бета-тест - це тестування на строго обмеженому колу обраних користувачів. Такими користувачами можуть виступати знайомі розробників, або їх колеги, які не пов'язані безпосередньо з розробкою тестованого продукту. Відкрите бета-тестування полягає в створенні і розміщенні у відкритому доступі публічної бета-версії. В даному випадку будь-який користувач може виступати бета-тестером. Зворотній зв'язок від таких бета-тестерів здійснюється за допомогою відгуків на сайті і вбудованих в програму систем аналітики і логування призначених для користувача дій, ці системи необхідні для аналізу поведінки користувачів і виявлення труднощів і помилок, з якими вони стикаються.

За позитивності сценарію

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

За ступенем автоматизації

• · Ручне тестування. Ручне тестування проводиться без використання додаткових програмних засобів, воно дозволяє перевірити програму або сайт за допомогою імітації дій користувача. У цій моделі тестувальник виступає в якості користувача, дотримуючись певних сценаріями, паралельно аналізуючи висновок програми і її поведінка в цілому.
• · Автоматизоване тестування. Таке тестування дозволяє за рахунок використання додаткового програмного забезпечення для автоматизації тестів значно прискорити процес тестування. Таке додаткове ПО дозволяє контролювати і управляти виконанням тестів і порівнювати очікуваний і фактичний результати роботи програми. Більш докладно буде розглянуто пізніше.