Позитивний тест кейс. Позитивний тест в один клік! По суб'єкту тестування

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Картинка-основа нашого тесту виглядає так.

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

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

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

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

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

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

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

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

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

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

12.10.2016 03:32

Всім відомо, що події, що відбуваються з нами, багато в чому обумовлені нашими думками. І навіть якщо ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вільний переклад статті "Top 10 Negative Test Cases" Steve Miller.

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

Внутрішні одинарні лапки (Embedded Single Quote) - У більшості SQL баз даних виникають проблеми при наявності одинарних лапок в запиті (наприклад, Jones's car).
Використовуйте одиничні лапки при перевірці кожного поля введення працюючого з базою даних.

Обов'язковий введення (Required Data Entry) - У специфікації вашого додатки повинні бути чітко визначені поля вимагають обов'язкового введення даних.
Перевіряйте, що форми, які мають поля, визначені як обов'язкові для введення, не можуть бути збережені при відсутності даних в них.

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

Розмір поля (Field Size Test) - У специфікації вашого застосування повинно бути чітко визначено максимально допустиму кількість символів в кожному з полів (наприклад, кількість символів в поле з ім'ям користувача не повинно перевищувати 50).
Перевіряйте, що програма не дозволяє вводити або зберігати більшу кількість символів, ніж вказано в специфікації. Не забувайте і про те, що дані поля, не тільки повинні правильно функціонувати, а й попереджати користувача про обмеження, наприклад, за допомогою пояснювальних написів або повідомлень про помилки.

Числові граничні значення (Numeric Bounds Test) - Числові поля вашого додатки можуть мати обмеження допустимих числових значень. Ці обмеження можуть бути вказані в специфікації вашого застосування або випливати з логіки роботи програми (наприклад, якщо ви тестируете функціональність пов'язану з нарахуванням відсотків на рахунок, то цілком логічним буде припущення, що нараховані відсотки не можуть приймати від'ємне значення).
Перевіряйте, що додаток видає повідомлення про помилку в разі, якщо значення лежать за межами допустимого діапазону (наприклад, повідомлення про помилку повинно з'являтися при введенні значень 9 або 51 в поле з допустимим діапазоном значень від 10 до 50, або при введенні негативного значення в поле , значення якого повинні бути позитивними).

Числові обмеження (Numeric Limits Test) - Більшість баз даних і мов програмування визначають числові значення як змінні з деяким типом (наприклад, integer або long integer), які, в свою чергу, мають обмеження допустимих числових значень (наприклад, значення integer повинні знаходитися в діапазоні від -32768 до 32767, а long integer від -2147483648 до 2147483647).
Перевіряйте граничні значення використовуваних змінних, для числових полів, граничні значення яких чітко не визначені специфікацією.

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

Валідність дати (Date Validity) - Поля дати завжди повинні мати перевірку валідності введених значень (наприклад, 31-11-2009 - не правильна дата). Також, не забувайте і про перевірку дат у високосному році (роки кратні 4м і кратні 100 і 400 одночасно - високосні).

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