how effectively prepare test bed
Випробувальні умови / Випробувальні умови та найкращі практики:
Кілька разів тестери виявляють, що їх дефекти відхиляються з екологічних питань, або вони постійно повторюють дефекти з подібних причин. Хоча відкриття найбільшої кількості дефектів, безумовно, повинно бути одним із особистих критеріїв для кожного тестера, більшість тестувальників також повинні наголосити на наявності найбільшої кількості дійсних дефектів.
Як цього досягається?
Окрім інших аспектів, таких як планування різноманітних сценаріїв тестування та ретельне розуміння позиції, a на встановлення випробувального стенду або тестового середовища потрібно витратити значну кількість часу . По-друге, незважаючи на те, що вони мають передбачену суму для планування тестових випадків, тестери також повинні зосередити свою енергію на створення ефективних тестових даних .
Особисто, будучи частиною процесу аудиту, я помітив, що найбільша кількість допустимих дефектів виявляється, коли докладено значних зусиль для створення тестового стенду або тестового середовища належним чином і коли тестер має ретельну інформацію розуміння того, яке середовище потрібно.
Крім того, тип даних тесту, що надходять у тестове середовище, може виявити деякі дуже серйозні недоліки в коді / функції, що перевіряються, що може суттєво вплинути на якість продукту.
У цій статті розповідається про те, що саме передбачає тест-тест: це двохетапний процес налаштування середовища тестування та налаштування даних тесту:
Частина 1) У попередній частині статті буде розглянуто загальний процес налаштування тестового середовища , найчастіше стикаються з проблемами налаштування, з якими стикаються тести та вказівники, про які слід пам’ятати, створюючи замість цих випробувальних стендів.
Частина 2) Сказавши стільки про випробувальний стенд у цій статті, варто було трохи пролити світло Тестування середовища аспекти також. В останній частині статті розглядається друга частина налаштування випробувального стенду, яка включає дані тесту, підхід до його встановлення та деякі ефективні Тестуйте методи управління даними .
З постійним «великим вибухом» у розробці та тестуванні програмного забезпечення дедалі більша увага приділяється застосуванню різних методологій, щоб зробити загальний процес забезпечення якості прозорим, ефективним та адекватним.
Різні аудити якості проводяться між організаціями, щоб гарантувати, що результативність роботи групи тестування може бути оцінена належним чином і має вимірювані результати з показниками, визначеними при ініціалізації циклу тестування. Ці результати дають змогу визначити, де стоїть конкретна команда з точки зору забезпечення оптимальної якості програмного забезпечення, яке вони тестують.
Ці звіти також допомагають команді зрозуміти можливості для вдосконалення на основі спостережень, зроблених під час аудиту.
Немає необхідності згадувати, що дуже очевидною метрикою для будь-якої тестової команди буде відношення до загальної кількості відкритих дефектів у порівнянні з кількість допустимих дефектів . Звідси одне з питань, що очевидно з’являється, - що є основою спроби виявити будь-який дефект? По-іншому, на якій основі можна знайти дефект?
Відповідь одностайна - налаштування тестового шару та / або тестового середовища. У командах встановлені показники якості зменшити дефекти, які відкидаються як помилка тестового налаштування / помилка користувача, недійсні конфігурації або в деяких випадках дефекти, що виникають під час виходу конкретної команди через недоступні конфігурації, неперевірені конфігурації.
Давайте для початку детальніше розглянемо визначення того, що таке випробувальний стенд або тестове середовище.
Що ви дізнаєтесь:
Що таке випробувальний стенд та тестове середовище?
У дуже загальному розумінні Test Bed можна було б визначити як своєрідне середовище розробки, завдяки якому реалізатори коду або модулів можуть вільно тестувати свої модулі без будь-яких перешкод з боку команди тестувань, в абсолютному обмеженні.
Однак випробувальний стенд притаманний не тільки команді розробників. З точки зору випробувальної групи або тестувальника, оскільки випробувальний стенд - це не що інше, як платформа, визначена для тестування програмного забезпечення / продукту, його також взаємозамінно називають тестовим середовищем.
Будь-яке тестове середовище або тестове середовище повинні бути налаштовані відповідно до визначеної мети тестування для програми / продукту / програмного забезпечення, що тестується. У певних ситуаціях випробувальний стенд буде порівнянням тестового середовища та тестових даних, з якими він працює.
Компоненти тестового середовища
Будь-який тест повинен мати свої специфічні вимоги до тестового середовища, але в дуже широкому розумінні будь-яке тестове середовище / тестове середовище буде складатися з апаратного забезпечення, програмного забезпечення та мережевих компонентів для підтримки необхідної конфігурації як мінімум для керування та проведення конкретного тесту. .
Загальновідомий факт, що розумну кількість часу тестера витрачають екологічні проблеми, які, в свою чергу, впливають на продуктивність та графіки випробувань. Незважаючи на те, що різновиди випробувань різняться для кожної команди випробувачів, деякі з них можуть бути загальними.
Деякі ключові проблеми, з якими зазвичай стикаються:
# 1) Віддалене середовище
Тестові засоби або середовища в основному розміщуються географічно на віддалених від команд сайтах. Це одна з найбільш часто зустрічаються проблем для тестових груп, як у разі виникнення будь-яких проблем, пов’язаних з обладнанням, прошивкою, програмним забезпеченням, мережею тощо.
Командам, що споживають активи, доведеться значною мірою покладатися на команди підтримки в місці, де активи знаходяться.
У тих самих рядках, якщо якийсь матеріал потребує оновлення мікропрограми або оновлення збірки, знову ж тестовій групі може знадобитися підтримка команд підтримки, що володіють середовищем, відкривши квитки підтримки. Це також може призвести до значного часу випробувань та графіків затримок, особливо у випадках різниці часових поясів.
# 2) Комбіноване використання між командами
Найчастіше команди розробників та випробувачів використовують одні й ті ж ресурси середовища. Хоча загальна норма визначає, що середовища розробки, випробувань та виробництва повинні бути окремими, насправді цей ідеальний сценарій досягається дуже рідко. Організаціям стає надзвичайно недружньо залучати окремі ресурси для кожної команди.
Отже, більшість організацій вимагають спільного використання навколишнього середовища між розробкою та тестуванням. До того ж, якщо ресурси для розробки та тестування претендують на використання одних і тих самих ресурсів одночасно, це призводить до хаосу та розбіжностей між членами.
# 3) Неефективне планування використання ресурсів для інтеграції
У деяких випадках для сценаріїв, що потребують наскрізне тестування внаслідок чого відбувається інтеграція двох або більше компонентів для спільного функціонування, знову ж може виникнути вимога щодо спільного використання ресурсів між тестовими групами. Неефективне планування щодо використання значно сприяє тому, що навколишнє середовище стає нестабільним, крім конфлікту між командами.
Найбільш очевидним наслідком цього є те, що проблема, яка помічається протягом певного разу чи двічі, може спричинити зовсім іншу поведінку в наступних прогонах для того самого сценарію. Якщо дефект для цього вже відкритий, існує велика ймовірність, що розробник його не прийме як дійсного кандидата на виправлення.
# 4) Конфігурація складного тесту
Конфігурація тестового шару або тестового середовища іноді буває занадто складною. Це спричинить за собою кілька викликів, оскільки випробувальна команда потребуватиме необхідних навичок, щоб зрозуміти необхідні конфігурації. Часом для тестувальника бракує бази знань, щоб мати змогу придумати необхідну конфігурацію.
У таких випадках тестери можуть самі викликати помилку в тестовому стенді, неправильно налаштувавши його. Це суттєво вплине на тестовий випадок та результати, які він дає.
# 5) Складний час налаштування
У певний інший час для кожного тестового випадку налаштування тесту може бути надто продуманим щодо кожного виявленого тестового випадку. Це може бути пов’язано з широким розмаїттям співіснуючих технологій, які потрібно поєднати разом, або кількома компонентами для спільної роботи у випадках інтеграційного тестування.
У цих випадках кожен із компонентів повинен працювати бездоганно, щоб забезпечити стабільні результати, оскільки один компонент може входити до наступного.
Найкращі практики налаштування тестового середовища
Ми розглянули широкий план проблем, з якими стикається тестувальник до або під час початку тестування. Більшість із нас стикалися з однією або кількома з цих проблем у певний момент протягом етапів проекту. Ці проблеми існували і, можливо, будуть існувати в різному ступені, оскільки ідеалістичної ситуації не існує.
З огляду на те, що проблеми з налаштуванням є невід’ємною частиною роботи тестувальника і неминучі, ось кілька порад щодо того, як ефективно підготувати установку до тестування. Це може допомогти мінімізувати дефекти, які можуть виникнути через проблеми з налаштуванням.
Порада No1) Зрозумійте Вимоги до тесту ретельно і виховувати себе
найкращий блокувальник спливаючих вікон
Завжди починайте з основ і з найочевиднішого! Коли документ із технічними характеристиками або документ про використання розгортається групою розробників, незмінним кроком для команди тестування є розуміння вимог до позиції, а потім підготовка документа тестування, що деталізує тестові випадки.
Поки здійснюється планування тесту, воно є кращий практика також включати детальну інформацію про тестове середовище в документ тестування. Не можна здогадуватися про те, що тестувальник потім витратить деякий час, аналізуючи тестове середовище, яке може знадобитися, і відповідно необхідні конфігурації.
Цього можна досягти, поговоривши з командою розробників / архітекторами, щоб створити добру базу знань. Це не тільки заощадить деякий час у циклі виконання, але й допоможе тестувальнику ефективно розподілити час виконання між простими та складними тестами.
Особисто хорошим результатом цього є те, що багато з нас виявили проблеми з налаштуванням (що за своєю суттю заважало б послідовному виконанню тесту) на самому початку циклу, що дало нам час, щоб направити та отримати необхідну допомогу для виправлення цих проблем - таким чином не подовжуючи цикл випробувань на неприйнятні періоди.
Ще одним позитивним впливом цього було б те, що це значно покращило б знання групи випробувачів та запобігло б непотрібним дефектам. Незважаючи на те, що ця практика узагальнює майже всі практики, які за своєю суттю необхідні для вирішення зазначених вище випробувальних завдань, все ж варто згадати про інші поради.
Порада No2) Перевірка підключення
Інший найважливіший контрольний пункт - це переконатися, що ресурси чи активи, які ви збираєтесь використовувати для тестування, є доступними. Якщо систему потрібно запускати інтегрованою з іншими машинами, перевірте їх зв’язок між собою за допомогою ping або telnet.
Крім того, якщо системам потрібно взаємодіяти одна з одною та перебувають за брандмауерами, переконайтесь, що вони можуть пройти автентифікацію через ці брандмауери, використовуючи Основні параметри безпеки (BSO), а також перевірити наявність проксі-серверів. Якщо ви помітите, що деякі машини недоступні або потребують автентифікації BSO, можна надіслати відповідні запити на обслуговування, щоб виконати вимогу до служби підтримки.
Це особливо корисно, коли навколишнє середовище знаходиться у віддалених місцях, а також дозволить уникнути ескалації щодо машин та систем. Якщо випробувальна команда потребує доступу до будь-якого ресурсу чи сховища, це допомогло б активно визначати те саме.
Порада No3)Перевірка мережі та / або сховища
Це майже розширення попередньої підказки і потребує ще певної перевірки з більшою технічною глибиною. Переконайтеся, що тестування, яке вам потрібно, має необхідну пропускну здатність, і якщо ваше тестування потребує з’єднання з Інтернетом. Також переконайтеся, що ви знайдете спосіб перевірити правильність топології мережі між системами та ресурсами.
По-друге, якщо ваша мета тестування передбачає необхідність будь-якого сховища, переконайтеся, що є сховище та підключення до мережі. Здебільшого це відповідальність адміністратора - це мати на місці, однак, також має велику цінність мати певні робочі та функціональні знання.
Порада No4) Перевірте наявність необхідного обладнання та програмного забезпечення, ліцензій
Багато разів трапляється так, що тестери починають виконання в системах, не перевіряючи необхідне обладнання та програмне забезпечення, які можуть знадобитися. В результаті цього багато разів тестер майже під час циклу тестування усвідомлює, що певна функціональність доступна лише на вищому рівні апаратного чи програмного забезпечення / прошивки.
У той час тестувальник під час тестування позначить блокатора, який поглинає значний час тестування. Отже, безцінна практика мати контрольно-пропускний пункт, щоб занотувати апаратне та програмне забезпечення, яке потрібно раніше.
Багато разів під час оновлення апаратного / програмного забезпечення можуть бути простої, до яких все зводиться Порада 1 де тестер повинен брати участь у попереджувальному плануванні апаратного забезпечення. Деякому програмному забезпеченню можуть знадобитися ліцензії, які можуть вимагати погодження та дій юридичної групи. Це процес, керований процесом, може знову зайняти кілька днів, щоб його виконати, що потрібно спланувати.
Порада No5)Браузери та версії
Тестування, яке ви робите, має бути дзеркальним що виконуватиме кінцевий користувач . Він міг тестувати на певному браузері останні версії всіх браузерів. Тому обов’язковим є визначення різних типів браузерів, які будуть використовуватися для тестування, та встановлення їх у вашому власному локальному тестовому налаштуванні.
По-друге, також визначте, які версії браузерів потрібно використовувати для тестування. Хорошою практикою було б почати з браузера нижчої версії, тим самим забезпечивши зворотну сумісність, а потім оновити до останньої версії.
Порада No6)Планування використання тестового середовища.
З огляду на той факт, що тестова група ніколи не матиме ситуації з власними тестовими ресурсами, системами та активами - це одна з головних віх у плануванні тестування - ефективне використання тестових ресурсів.
аніме веб-сайти дивитись аніме безкоштовно
Це особливо потрібно, коли більше ніж одна команда повинна отримати доступ до одного і того ж набору ресурсів або через наскрізний сценарій, що складається з двох або більше компонентів, що працюють разом, або ситуації, коли тестова установка є занадто складною або складною для копіювання дуже легко, і в одній команді може бути декілька членів, які мають власні цілі для тестування з однаковим налаштуванням.
Хорошою практикою було б розробити підхід до розподілу часу, коли певна команда або особа використовує його для першої половини, а решта людей для другої половини. Між часом може бути щось загальне, коли кожен із них може проводити незалежні тести, які не заважатимуть іншому.
Це не тільки зменшить хаос і конфлікти всередині членів, але й забезпечить поведінкову стабільність довкілля довше.
Порада No7)Засоби автоматизації та їх конфігурації
Як ми знаємо, кожна позиція в тестуванні матиме кілька повторюваних тестів, які будуть частиною циклу регресії, яку потрібно буде автоматизувати. Тестова група повинна визначити, яку саме автоматизацію вони хотіли б зробити, та необхідні для цього інструменти.
Хоча це не обов'язково повинно бути частиною підготовки до навколишнього середовища, я все-таки перерахував би це як найкращу практику для належного визначення та налаштування засобів автоматизації. Це повністю залежатиме від розсуду тестувальника, коли він хоче виконати цю діяльність, оскільки це не є обов’язковим фактором для забезпечення готовності до тесту.
Висновок
Ці поради та підказки можуть сформувати хороший критерій та слід для забезпечення готовності тестового середовища до тестування. Без сумніву, кожна команда стикається зі своїм унікальним набором проблем, і наведені вище поради можуть бути адаптовані та налаштовані відповідно до власних потреб.
Насправді, джерело для записування цілого скелета підказок походить з одного з моїх завдань, де я зіткнувся з дуже складними проблемами з налаштуванням і взяв у мене майже рік, щоб навіть розпочати тестування!
Хоча обмеження в тестовому середовищі були поза моїм контролем, я відчував, що про ці багато питань можна було б повідомити раніше, якби я застосував ці поради. З тих пір я застосовую його до кожного завдання, яке трапляється мені на шляху, і цей скелет мені дуже допоміг у проактивному пошуку проблем з налаштуванням та спрямуванні моїх зусиль для їх вирішення.
Про автора: Ця стаття написана Сніхою Надіг. Вона працює провідником випробувань з більш ніж 7-річним досвідом роботи в проектах тестування ручного та автоматичного тестування.
У частині 2 цієї статті ми побачимо процес налаштування та обслуговування тестового середовища та поради щодо підготовки та управління тестовими даними. Тим часом, не соромтеся розміщувати свої запити щодо підготовки тест-стенду в коментарях.
Рекомендована література
- Як ефективно проводити тестування після випуску та мінімізувати вплив випуску на реальних клієнтів
- Як ви вирішуєте, які дефекти допустимі для запуску програмного забезпечення?
- Як підготувати та представити команді видатну презентацію з контролю якості
- Процес управління дефектами: як ефективно управляти дефектом
- 9 найкращих ідей для тестувальників, щоб ефективно використовувати час своєї роботи
- Лідерство в тестуванні - Тестуйте відповідальність керівника та як ефективно керувати тестовою групою
- Як ефективно планувати та керувати тестовими проектами (Поради)
- Процес тріації дефектів та способи організації зустрічі з дефектом тріації