Когато работите в областта на тестването на софтуер, има десетки различни методи за тестване, които трябва да разгледате.
Тестването на софтуер помага на разработчиците да отстранят всички недостатъци, които могат да съществуват в даден софтуерен пакет, за да могат да доставят продукт, който отговаря на нуждите и очакванията на всички заинтересовани страни. Използването на подходящото решение за тестване ви дава всички необходими знания, но правилният избор на тест може да отнеме време.
Тестването на сивата кутия е една от най-универсалните форми на тестване, които са на разположение на тестващите, тъй като предлага много информация, без да отнема прекалено много ресурси.
Научете повече за това какво представлява тестването в сивата кутия, за някои от спецификите на работа на тестването в сивата кутия и за някои от причините, поради които компаниите използват този метод на тестване.
Какво представлява тестването в сивата кутия?
Тестването на сивата кутия е форма на тестване, която съчетава тестване на бялата кутия и тестване на черната кутия, като се използва частично разбиране на основния дизайн и начина, по който е реализирана системата.
Тази комбинация означава, че тестерът знае част от това, което се случва във фонов режим, без да познава изцяло кода, което дава повече информация за потенциалните причини за проблеми в софтуера, когато те възникнат.
Завършването на тестовете на сивата кутия е отговорност на тестерите, като екипът за осигуряване на качеството работи независимо от екипа по разработката на проекта.
1. Кога и защо е необходимо да се прави тестване на сивата кутия при тестването на софтуер?
В процеса на разработка компаниите използват няколко пъти тестване на сивата кутия.
Например, когато дадено приложение трябва да взаимодейства с инструмент на трета страна, за да работи правилно, тестерите нямат достъп до изходния код, който е част от външния софтуер. Това е принудително ограничение на достъпа на QA тестерите и превръща тестването в сива кутия без възможност за избор.
2. Кога не е необходимо да правите тестване на сивата кутия
Има няколко момента в процеса на тестване, в които не е необходимо тестване на сивата кутия, първият от които е в началото на процеса на разработка.
Функционалното тестване се извършва, когато разработчиците първоначално тестват, за да се уверят, че техният код изпълнява най-основните си задачи, което е напълно прозрачно. Тъй като кодът или документацията не са скрити от тестващия, това не се счита за тестване в сива кутия.
Друг случай, в който не се нуждаете от тестване на сивата кутия, е тестването в самия край на разработката, когато имате завършен продукт. Това е случаят, когато крайният потребител помага при тестването и е известен още като “бета тестване” или “тестване от край до край“.
Потребителите тестват приложението без никакъв достъп до кода или документите за проектиране, като вместо това приемат софтуера на базата на собствените му качества. Това е форма на изпитване “черна кутия”, тъй като процесът е напълно непрозрачен.
3. Кой участва в тестването на сивата кутия?
Има няколко души и роли, които участват в тестването на сивата кутия, като някои от най-важните роли в процеса включват:
– Ръководител на QA:
Мениджърът по осигуряване на качеството или мениджърът по осигуряване на качеството е служител в процеса на разработване на софтуер, който отговаря за възлагането на задачи на екипа за тестване.
Това включва изготвяне на графици, разглеждане на доклади и справяне с конфликти, възникнали в екипа.
– Тестер:
Тестерът е професионалист, който отговаря за изпълнението на тестовите случаи, които са част от процеса на тестване на сивата кутия.
Това изисква високо ниво на внимание към детайлите при писането на доклади и многократното провеждане на точни тестови случаи.
– Разработчик:
Разработчиците са професионалистите, които отговарят за създаването на кода и неговото коригиране в зависимост от резултатите от тестването в сивата кутия.
Въпреки че не е задължително те да участват в самото тестване, те получават съобщения от тестващите за резултатите.
– Анализатор на качеството:
Ролята на QA анализатор е често срещана в процеси на тестване, които използват много автоматизация. Анализаторът пише кода на тестовите случаи за автоматичните тестове и освен това анализира данните, които тестовете връщат в края на процеса.
Предимства на тестването на сивата кутия
Има няколко основни предимства от използването на тестване в сивата кутия при проверката на софтуера. Като се възползвате максимално от тези предимства, вие подобрявате стандарта на вашето приложение с течение на времето.
Някои от причините, поради които компаниите използват тази форма на тестване, включват:
1. Познаването на вътрешните механизми помага за разработването на тестове
Едно от основните предимства на използването на тестване на сивата кутия на работното място е фактът, че знаете за някои от вътрешните механизми на приложението. Това включва разбиране на функциите и на това кои от тях са готови модули в сравнение с написания по поръчка код за някои от другите функции.
Познаването на вътрешната функционалност означава, че тестерът разбира по-добре какво тества и може да насочи тези тестове към дизайна на приложението. Компаниите получават по-точни резултати, които представят софтуера правилно.
2. Води до незабавно разрешаване на проблемите
В някои случаи, когато в даден тест възникне проблем и тестерът има достъп до кода, който стои зад проблема, той може да бъде решен незабавно.
Това противоречи на методологията за тестване “черна кутия”, при която тестващите не могат да видят кода зад кулисите на софтуера, който проверяват. Виждайки кода, тестерите с голям опит в разработката могат да посочат на разработчиците какъв точно е проблемът и как бъдещата актуализация може да го реши.
Тестването на сивата кутия спестява много време, което иначе би било изразходвано за разследване на проблеми, и помага на компаниите да изразходват времето си по-ефективно.
3. Разделя тестери и разработчици
Използването на тестване в сива кутия води до ясно разделение между разработчиците на приложението и хората, които тестват софтуера.
Това е така, защото провеждането на тестове в сивата кутия зависи от това дали тестерите имат познания за начина, по който работи софтуерът, като дистанцията между двете се превръща в необходимост за по-точни резултати от тестовете, които не са повлияни от пристрастия.
Тестерите в сценариите на сивата кутия са в напълно различен екип от разработчиците, като предлагат точна информация, без съществуващите възгледи да влияят на резултатите им.
Разработчиците също имат полза от това, тъй като получават по-критична гледна точка към работата си, което им помага да подобрят както съществуващото приложение, така и уменията си за в бъдеще.
Предизвикателства при тестването в сивата кутия
Има няколко основни недостатъка на използването на тестване в сивата кутия в работата по разработката.
Като разбирате тези недостатъци и работите за тяхното намаляване, когато е възможно, повишавате цялостния стандарт на работата си в края на етапа на осигуряване на качеството.
Някои от основните недостатъци на тестването в сивата кутия включват:
1. Възможност кодът да не бъде видян
Тестването в “сива кутия” означава, че има някои аспекти на кода, които са скрити за тестващия, и в случай на проблеми, възникнали при теста, това може да доведе до допълнителни проблеми.
При невидим код служителите, участващи в тестването, се затрудняват да насочат тестовете си така, че да използват максимално приложението, и губят предимството да видят причината за проблема веднага.
Процесът на отстраняване на грешки става все по-неясен, което води до необходимост от по-дълго време за актуализация, а компаниите се борят да открият проблемите в своя код.
В резултат на този невидим код крайните продукти могат да бъдат с повече грешки и с по-нисък стандарт.
2. Тестовете могат да бъдат неточни, ако операциите са неуспешни
Наличието на точни тестове е задължително условие при всяка форма на тестване на софтуер, като по-високата степен на точност насочва екипите към актуализации, които могат да се извършат в бъдещи версии, и освен това помага на екипа за разработка да бъде по-уверен в своите продукти.
Тази точност намалява, когато операциите се провалят при тестване в сивата кутия. Ако нямат достъп до кода, тестерите просто получават от софтуера съобщение “Операцията е неуспешна”, което им пречи да предоставят обратна информация за начина, по който той работи.
За да получат полезни показатели, разработчиците трябва да коригират софтуера преди следващия етап на тестване. В противен случай единственото, което може да направи тестерът, е да заяви, че функцията не работи в сегашния си вид.
3. Борби с разпределените системи
Разпределените системи се отнасят до софтуерни системи, които се хостват на няколко различни места или разчитат на функции като услуги за обработка на данни и обработка в облак.
Това прави тестването изключително трудно, тъй като значителна част от софтуера е скрита зад тяло на трета страна, а тестващите просто получават изход от неизвестен процес.
Когато възникнат проблеми със софтуер, който използва системи на трети страни, може да е трудно да се установи дали проблемът е в самото приложение, във функционалността на третата страна или в начина, по който те се интегрират, особено когато тестерът не може да види кода по време на работа.
Характеристики на тестовете на сивата кутия
Съществуват няколко общи характеристики, които тестовете на сивата кутия споделят помежду си, като разпознаването на тези тестове ви помага да подготвите стратегия за вашата организация.
Някои от основните примери за характеристики на тестовете на сивата кутия, както и за това как тези характеристики са важна част от процеса на тестване на сивата кутия, включват:
– Увеличен обхват:
Достъпът до част от изходния код осигурява по-висока степен на покритие на тестовете, а по-подробните данни позволяват по-точно откриване на грешки.
– Потоци от данни:
В много от тестовете на сивата кутия се набляга на потока от данни и на разбирането на начина, по който информацията се движи през системата.
– Неалгоритмични:
Тестването в сива кутия не работи при изследване на алгоритми, тъй като това е още едно ниво на замазване на кода.
Какво тестваме в тестовете на сивата кутия?
Всеки различен тип тестване е най-подходящ, когато е насочен към конкретни части от въпросния софтуер. Същото важи и за тестването на сивата кутия, като методологията е най-полезна в някои характерни части на приложението.
Някои примери за това, което тестващите оценяват, когато извършват тестове на сивата кутия, включват:
1. Сигурност на приложението
Тестовете “сива кутия” са идеални за тестове за проникване, които проверяват сигурността на дадено приложение. Тестерите могат да видят целия код и да търсят потенциални уязвимости в процеса.
Етичните хакери са идеалните тестери за тестване на сигурността на приложенията, тъй като те разпознават потенциалните слабости и недостатъци в софтуера по-естествено от тези, които нямат опит в нарушаването на сигурността на софтуера.
2. Тестване на базата данни
Много компании използват тестване в сивата кутия за тестване на бази данни, тъй като можете да проследите данните през всяка подфункция в софтуера.
Тестерите могат да видят всички промени, които софтуерът прави, и да преценят дали те са правилни.
Това е полезна реализация на тестването на сивата кутия, тъй като тестовете на бази данни са предвидими по своята същност, а компаниите използват бази данни за организиране на съществуваща информация, а не за генериране на нови данни.
3. Уеб приложения
Уеб приложенията се възползват от използването на тестване в сивата кутия поради универсалността на метода за тестване.
Тестовете на сивата кутия могат да се използват за тестване на сигурността, базата данни, интеграцията, потребителския интерфейс и браузъра, като всеки един от тези аспекти е ключов за уеб приложенията.
Не е необходимо да променяте методологиите за тестване, така че се възползвате от по-голямо ниво на приемственост.
Изчистване на някои неясноти:
Тестване на сива кутия срещу бяла кутия срещу черна кутия
Тестването в сивата кутия е форма на тестване, близка до тестването в бялата и в черната кутия, което означава, че има голям потенциал за объркване между методологиите.
Научете повече за това какво представляват тестовете “бяла” и “черна кутия” и за някои от основните разлики между тях и тестовете “сива кутия” при разработването на софтуер:
1. Какво представлява тестването на бялата кутия?
Тестването в бяла кутия е форма на тестване на приложения, която предоставя на тестера изчерпателна информация за приложението.
Това включва пълен достъп до изходния код и всички документи за проектиране на софтуера, което дава на тестера много по-добра представа за начина, по който работи софтуерът.
Тестерите използват това разбиране, за да видят повече от проблемите, които са налице в приложението, като представят по-точна перспектива за това как приложението работи за потребителите.
Пример за използване на тестване на бялата кутия е да се види потокът от конкретни данни, въведени през дадено приложение, за да се види къде се появява проблем в процесите на приложението, а не просто да се провери дали има проблем или не.
В процеса на разработка има няколко момента, в които компаниите използват тестване на бялата кутия.
Първата от тях е при провеждането на тестване на единици, което оценява дали всяка отделна част от кода или модул в софтуерния пакет изпълнява работата, която разработчикът очаква.
Тестването на единици помага на тестващите да открият повечето проблеми в дадено приложение, тъй като при него се проверяват всички функционалности в приложението.
Тестването в бялата кутия също помага при откриването на изтичане на памет. Чрез подробно разглеждане на целия код анализаторът по осигуряване на качеството открива къде приложението използва паметта на устройството и потенциални области, в които тя е твърде много.
Това помага на приложението да работи по-бързо и по-ефективно при бъдещи итерации, тъй като проблемът с изтичането на памет се решава възможно най-скоро.
Какви са разликите между тестовете в сивата и бялата кутия?
Има няколко основни разлики между тестовете в бяла и сива кутия, като първата промяна е нивото на информация, до която някой има достъп.
Тестването на “бялата кутия” има пълен достъп до изходния код и документите за проектиране на програмата, докато тестването на “сивата кутия” има само частичен достъп до част от тази информация, най-вече до документите за проектиране.
Тази промяна означава, че има разлика и в хората, които изпълняват тестовете, като самите разработчици са основно отговорни за тестовете на бялата кутия.
За разлика от това, тестването на “сивата кутия” е отговорност на екипа по осигуряване на качеството, тъй като тестерите не могат да познават кода отблизо.
Тестването на сивата кутия също отнема по-малко време от тестването на бялата кутия. Тестването на “бялата кутия” е от край до край и изследва както потребителската част на софтуера, така и самия код. Това отнема много повече време и означава, че процесът на тестване в сивата кутия е много по-бърз начин за постигане на напредък.
Все пак “бялата кутия” има по-голям потенциал за автоматизация, тъй като тестерите познават начина, по който работи вътрешният код.
2. Какво представлява тестването “черна кутия”?
Тестването на “черна кутия” се отнася до случаите, когато тестерът изследва софтуерен пакет, без да има представа за начина, по който работи системата.
Това означава, че нямате достъп до никакъв код, който е част от приложението, нито до наличните документи за проектиране или справки. Тестерите просто имат списък с функциите, които тестват, и поредица от тестови случаи, които трябва да изпълнят.
Пример за тестване на “черна кутия” е тестването “от край до край”, при което тестерът получава пълния софтуерен пакет и тества цялото приложение, за да се увери, че функционалността работи така, както е проектирана.
Повечето от идеалните тестови случаи за изпитване на черна кутия са тези в края на процеса и включват клиенти и тяхната гледна точка към продукта, като липсата на достъп до кода предотвратява всякаква пристрастност, засягаща мнението на потребителя.
Компаниите използват тестване на черната кутия предимно след приключване на всички функционални тестове на приложението. След като всички тестове на единици и тестове на функции са завършени, разработчиците разбират, че приложението работи според очакванията им, поне когато всички модули работят изолирано.
Тестването на “черната кутия” гарантира, че цялостното приложение работи според очакванията след компилирането му, като теоретично целият изходен код вече е наред.
Какви са разликите между сивата и черната кутия на тестовете?
Основната разлика между тестването в сива и черна кутия е в размера на достъпа, който тестерът получава до информацията.
В някои случаи тестерът на черна кутия може да подходи към приложението, без да има никакви предварителни познания за софтуера, като просто премине през процеса на тестване и използва софтуера като стандартен потребител.
От друга страна, тестерът на сивата кутия има достъп до някои от документите за проектиране и може да сравни замисленото приложение с реалното му изпълнение, като предоставя на разработчиците обратна информация за това кои конкретни части на приложението не отговарят на стандартите.
Друга разлика е времето, което е необходимо за решаване на даден проблем, като тестовете на сивата кутия отнемат малко повече време.
Кръстосаното сравняване на документацията и кода с начина, по който изпитвате приложението, може да отнеме известно време, което е в разрез с начина, по който работят тестерите на черната кутия, като просто изследват самото приложение и всички проблеми с функционалността. Тази комбинация прави тестването на черната кутия идеален процес за използване в края на процеса на разработка, когато се подготвя пускането на продукта, а сивата кутия работи по-добре, когато сте в етапа на разработване на потребителския интерфейс и компилиране.
3. Заключение: Сива кутия срещу бяла кутия срещу черна кутия
В заключение, тестването в “бяла кутия”, “сива кутия” и “черна кутия” са част от един и същи спектър, в който различният фактор е нивото на достъп, което има тестерът по време на процеса.
Тъй като формата за тестване става все по-“черна”, тестването става все по-непрозрачно, а достъпът до информацията зад софтуера е ограничен.
Тестването на “бялата кутия” е идеално за най-ранните етапи на процеса, а тестването на “черната кутия” – за етапи като тестване “от край до край”, при което се изследва цялото приложение от гледна точка на потребителя.
Тестването в сива кутия е междинно звено между двете концепции, като помага за откриването на проблеми в средата на процеса на разработка, предлагайки по-добра представа, но запазвайки част от изходния код скрит за тестващия.
Техники за тестване на сивата кутия
Тестването на сивата кутия включва широк набор от техники, всяка от които повишава стандарта на тестване, открива повече грешки за разработчика и води до по-завършен продукт в края на процеса.
Някои от най-често срещаните техники за тестване на сивата кутия, които екипите за осигуряване на качеството използват, включват:
1. Изпитване на матрицата
Матричното тестване изследва доклада за състоянието на проекта, който е в процес на изпълнение. В някои случаи това включва просто състояние PASS/FAIL, а текущите процеси предоставят повече подробности за това как процесите работят непрекъснато.
Докато повечето тестове се фокусират върху входовете и изходите на даден код, матричните тестове изследват състоянието на самите процеси, а не резултатите от тях.
Използването на матрично тестване осигурява по-голям фокус върху самото приложение, като помага да се открият грешки и проблеми, дори ако резултатите изглеждат правилни.
2. Регресионно тестване
Тестването на регресията съществува, за да се тества софтуерът след поредица от актуализации. Това включва както функционални, така и нефункционални тестове, които гарантират, че приложението продължава да работи по достатъчно висок стандарт при промяна на кода.
Тестерите, които използват регресионно тестване, обикновено използват автоматизация, тъй като обхватът на регресионните тестове нараства с откриването на все повече дефекти от екипа за осигуряване на качеството.
В някои случаи обаче е необходимо ръчно тестване, като компаниите, които тестват потребителския интерфейс, използват ръчни тестове, за да видят как реагира човешкият потребител на промените, направени в менютата, бутоните и опциите за навигация.
3. Изпитване на модела
Тестването по модел е форма на тестване, която се фокусира върху следването на определен модел при всеки тест, който организацията извършва.
Екипите за тестване проектират тези тестове така, че да са насочени към всяка функция на софтуера, като всеки тест предоставя на компанията последователно ниво на информация за начина, по който функционират отделните функции.
Използването на тестването на модели понякога зависи от модифицирането на модела с течение на времето, за да сте сигурни, че оценявате всяка от действащите системи, но след като веднъж сте установили работещ модел, избягвайте отклоненията, за да осигурите по-голяма последователност на резултатите.
4. Тестване на ортогонални масиви
Тестването на ортогонални масиви е предимно техника за тестване, ориентирана към черната кутия, която се използва, когато тестващите използват значителен брой входове, който е твърде голям, за да се тества изчерпателно всяка отделна система в процеса.
В тези случаи всяка отделна част от данните предоставя своя собствена уникална информация поради потенциална липса на корелация между конкретни части от информацията. Това е ортогоналният аспект на системата, като уникалните части от информацията се използват, за да се осигури максимално ниво на данни при минимални усилия.
Намалява се времето за тестване и имате идеален баланс на данните, които да предоставите на екипа за разработка.
Тестване на сивата кутия в жизнения цикъл на софтуерното инженерство
Тестването на сивата кутия попада в определен етап от жизнения цикъл на софтуерното инженерство. Този жизнен цикъл представлява сложна поредица от стъпки, които компаниите следват при разработването на своите продукти, като всяка стъпка води до повишаване на стандарта на продукта.
Въпреки че тестването е част от процеса, която се извършва постоянно, времето за тестване на “сивата кутия” е много ограничено.
Това се случва, след като първоначалната функционалност е завършена и тествана чрез тестване на “бялата кутия” и преди софтуерът да е готов за публично пускане, като компаниите предпочитат тестването на “черната кутия” на най-късните етапи.
Сивата кутия е идеалният инструмент за интегриране на функции заедно и гарантиране на правилната им работа в тандем, както и самостоятелно.
Ръчни или автоматизирани тестове на сивата кутия?
Както при всяка форма на тестване на софтуер, екипите за осигуряване на качеството избират между ръчно тестване с помощта на експертни служители и автоматично, което включва кодиране на серия от тестови случаи и многократното им попълване, за да се гарантира точен набор от резултати.
Научете повече за ръчното и автоматизираното тестване, за някои от ползите и предизвикателствата при всяко от тях, както и за това коя от двете форми на тестване е идеална за компания, която иска да разбере по-добре проблемите със своя продукт.
Ръчно тестване на сивата кутия – ползи, предизвикателства, процес
Ръчното тестване е основна част от много видове тестване, включително тестването в сивата кутия.
Този процес включва тестване на даден софтуер от хора, като се проверява дали софтуерът работи според очакванията ви и се сравнява с предварително съществуващите документи за проектиране и видим код, за да се провери дали в тази информация има очевидни недостатъци, които биха могли да причинят проблеми.
Случаите, в които ръчното тестване е често срещано, включват по-сложни части от софтуера, които изискват човек да предостави качествена информация.
Други приложения включват по-малки компании, които искат да оценят обстойно своя софтуер, тъй като малките приложения и пакети изискват сравнително малко ресурси за оценка в сравнение с по-големите програми, създадени от по-големи компании.
1. Предимства на ръчното тестване на сивата кутия
Има няколко предимства на ръчното тестване на сивата кутия за всеки софтуер. Познаването на тези предимства означава, че можете да насочите тестването си към тях, да откриете повече проблеми в софтуера си и да повишите стандарта на работата си благодарение на по-добър режим на тестване.
Основните предимства на ръчното тестване на сивата кутия са:
Подробна обратна връзка
Първото голямо предимство на ръчното тестване на сиви кутии е, че тестерите могат да предоставят значителна обратна връзка на разработчика.
Когато се използва автоматизирано тестване, тестовите случаи са проектирани така, че да дават много специфични показатели отново и отново, които дават на анализаторите представа, когато имат време да оценят данните.
Това е малко по-различно, когато се използва ръчно тестване, тъй като тестерът може да предостави по-задълбочена обратна връзка за това коя конкретна функция не работи и за потенциалните причини за проблема, след като го сравни с документацията за проекта.
Използването на подробна обратна връзка насочва не само към актуализации на съществуващите функции, но и към потенциални нови функции, които тестерът препоръчва на потребителите.
По-добри тълкувания
Автоматизираното тестване означава, че всички заключения са въпрос на оценка на данните, които получавате от теста, и на рационално заключение за това какво означава това за софтуера.
Точно обратното, ръчните тестери имат много по-добра представа за начина, по който работи самото приложение.
Те могат да сравняват кода на сивата кутия с това, което се случва в реално време, като правят точна оценка в този момент, вместо да се налага да правят изводи след това.
Някои платформи за автоматизация могат да работят по подобен начин, като разполагат с функция за преиграване, но това все пак изисква ръчна намеса.
Гъвкаво изпитване
Автоматизацията на тестовете включва кодиране на много специфични тестови случаи в платформа, което означава, че софтуерът изпълнява този специфичен набор от задачи отново и отново.
Макар че това е идеално за повторение, то представлява уникално предизвикателство, тъй като няма гъвкавост при тестването.
В тези случаи е идеално да се използва тестер, тъй като той допринася за по-голяма гъвкавост на процеса. Ако човекът, който извършва тестването, забележи потенциален проблем, който е малко извън тясно дефинирания тестови случай, той може да го разгледа и да докладва резултатите в края на процеса.
Това осигурява на компаниите по-обширно покритие на софтуера, като открива грешки, които автоматизираната система не може да открие.
2. Предизвикателства при ръчното тестване на сивата кутия
Използването на ръчно тестване в процеса на разработване на софтуер има много предимства, но и няколко недостатъка. Те варират в зависимост от няколко фактора, включително конкретния софтуер, върху който работи компанията, размера на екипа за разработка и стандарта на уменията, които притежават членовете на екипите за тестване и разработка.
Значителните предизвикателства при ръчното тестване включват:
Високи разходи за труд
Разходите за труд са едни от най-значимите разходи, които всяка компания прави, тъй като тя плаща, за да получи най-добрия наличен персонал и да подобри стандарта на работата си.
Тъй като ръчното тестване на сивата кутия може да отнеме много време, компанията трябва да плати на своите тестери да работят по време на целия процес. За някои от най-големите приложения това може да отнеме часове и да доведе до увеличаване на разходите за ръчни тестери.
Разработчиците могат да се опитат да смекчат този проблем, като балансират автоматизацията на тестовете в сивата кутия с ръчно тестване или като намалят почасовите разходи за труд, но това крие риск от понижаване на качеството на тестовете.
Човешка грешка
Автоматизираното тестване ефективно изпълнява прости процеси, като ги повтаря с висока степен на точност по начин, по който човек не може да го направи.
Човешките същества допускат грешки и дребни грешки, които могат да бъдат резултат от всичко – от случайно натискане на грешен бутон до изпускане на вниманието за няколко секунди.
Подобни грешки могат да доведат до неточни данни и да накарат разработчиците да насочат вниманието си към грешна част от софтуера, което отнема ценно време за разработка и влошава продукта.
Постарайте се да разрешите този проблем, като по възможност повторите тестовете в сивата кутия, за да проверите резултатите си в хода на тестването.
Отнема много време
Докато компютрите могат да изпълняват задачи за миг, на хората им е необходимо малко повече време.
Това се дължи на различни фактори – от времето за реакция до това, че в някои моменти просто работят по-бавно от оптималната си скорост, което забавя процеса на тестване.
По-бавният процес на тестване означава, че екипите за разработка имат по-малко време да работят за отстраняване на грешки и недостатъци в продукта, тъй като цялото време отива за откриване на проблемите на първо място.
Това не е лесно да се смекчи, като едно от възможните решения е хибриден режим на тестване, например балансиране на ръчните тестове с автоматизирани тестове на сивата кутия.
Автоматизация на тестовете в сивата кутия – предимства, предизвикателства, процес
Автоматизацията на тестовете се отнася до процеса на използване на платформа за автоматизация, за да се автоматизират някои от частите на процеса на тестване в сивата кутия.
Процесът се осъществява, като от проектантите на тестове се изисква да създадат поредица от тестови случаи, а анализаторите на качеството или други подобни специалисти кодират тези тестове в програмите за автоматизация, като някои използват автоматизация на роботизирани процеси като допълнителен инструмент.
В тези случаи анализаторите на ОК вече разбират част от кода или документите за проектиране.
Този тип тестване е по-често срещан при много по-големи софтуерни пакети, тъй като тестерите на сивата кутия нямат време да тестват обстойно всички аспекти на процеса ръчно.
След автоматизирания процес платформата връща отчет за анализатора на качеството, в който се отбелязват местата, където има грешки, и редица важни показатели.
1. Предимства на автоматизираното тестване на сивата кутия
Има няколко ясни предимства от използването на автоматизирано тестване на сивата кутия в процесите на екипа за осигуряване на качеството.
Като се фокусира върху тези предимства и ги използва максимално, компанията може да повиши ефективността на своето тестване на сивата кутия и да разреши възможно най-много проблеми на този етап от работния процес.
Някои от основните предимства на използването на автоматизация при тестването на сивата кутия включват:
Бързо тестване
Автоматизираните системи са проектирани така, че да тестват изключително бързо, преминавайки през поредица от процеси възможно най-бързо. Това предимство става още по-осезаемо при провеждането на повтарящи се тестове на сивата кутия, тъй като всяко отделно изпълнение отнема по-малко време.
Времето, което спестявате от пускане в експлоатация, се увеличава значително, като компанията ви разполага с много повече време за изпълнение на неотложни задачи, като например актуализиране на самия софтуер и предоставяне на обратна връзка на клиенти и потенциални клиенти.
По-бързото тестване е особено полезно при работа след пускане на версията, тъй като възможно най-бързото пускане на поправки на функционалността е задължително за подобряване на начина, по който хората виждат бизнеса.
Точни показатели
Метриките са важна част от начина, по който работи тестването на софтуер, като предоставят на тестващия цифрова информация, която показва потенциални проблеми.
Компютрите и платформите за автоматизация предлагат много точни показатели, като например времето за реакция се измерва до милисекунда.
Наличието на по-точни показатели означава, че можете да проследявате малки промени в начина, по който работи дадено приложение, което ви помага да разберете дали дадена актуализация е подобрила производителността или е довела до това, че стандартните работни процеси отнемат повече време.
Намалени разходи
Един от най-големите разходи за тестване в условията на разработване на софтуер в “сивата кутия” е този за самите тестери в “сивата кутия”.
Наемането на експерти по тестване на софтуер е скъпо, особено когато търсите тестери от сивия сектор, които изискват по-голямо разнообразие от умения, за да осигурят най-високите възможни стандарти за вашата организация.
Автоматизацията означава, че има по-малко хора, които извършват ръчни тестове на сивата кутия, което елиминира много разходи за персонал от процеса.
Въпреки че платформите за автоматизация имат някои разходи, повечето от които се таксуват с месечен абонамент, те са много по-ниски, отколкото да плащате на служители, които да вършат работата вместо вас.
2. Предизвикателства при автоматизираното тестване на сивата кутия
Използването на автоматизация в процесите на тестване на сивата кутия е свързано с много предизвикателства.
Докато някои организации се фокусират върху ползите, има много предимства да познавате предизвикателствата на тестването на сивата кутия и да ги вземате предвид, докато работите.
Можете да приложите тестване на сивата кутия по начин, който избягва предизвикателствата и ви предпазва от това да се борите с ограниченията занапред.
Основните предизвикателства пред автоматизираното тестване на сивата кутия са:
Първоначална настройка
Първоначалната настройка е едно от най-големите предизвикателства в процеса на автоматизация. Това се отнася до времето, необходимо за преминаване към нова платформа за тестване, включително инсталиране на платформата, обучение на потребителите как да работят с нея и кодиране на първите тестове на софтуера.
Всичко това е непродуктивно време, което компанията иска да ограничи колкото е възможно повече.
Използването на първокласен софтуер за автоматизация с експерти, които са на разположение, когато имате нужда, е идеално в този случай, тъй като разполагате с поддръжка от трета страна, която гарантира, че автоматизацията на сивата кутия и други видове тестване от самото начало вървят гладко.
Високи изисквания за умения
Въпреки че ръчното тестване изисква високи нива на умения, анализаторите на ОК, които работят с автоматизация, все още трябва да притежават високо ниво на умения.
Това е под формата на умения за кодиране, които се използват предимно за създаване на тестови случаи и разчитане на кода, наличен в сценария на сивата кутия.
Разработчиците могат да намалят този проблем, като наемат специално тестери, които имат опит в разработването или са работили в миналото по проекти за кодиране. Ограничавате времето за обучение на работното място и гарантирате, че всеки новоназначен служител има способността да се адаптира към изискванията на автоматизираното тестване в сивата кутия.
Някои компании се стремят да използват безкодова система за автоматизация за провеждане на тестване на сивата кутия като алтернатива, но това може да доведе до по-малка гъвкавост на работното място.
Постоянен надзор
Автоматизираното тестване отчасти съществува, за да се премахне акцентът от разчитането на хора, тъй като при ръчното тестване в процесите постоянно участват хора.
Това не се отнася за автоматизацията на тестове, но все пак компаниите трябва да имат добро ниво на надзор.
Надзорът включва проверка на резултатите от тестовете на сивата кутия и тяхното поддържане, за да се гарантира, че всичко продължава да работи според очакванията на разработчика.
Дружествата могат да помогнат за подобряване на стандарта на надзор по няколко начина, като идеалният вариант е един специалист да отговаря за надзора на тестовете.
Това води до по-високо ниво на специализация, като този служител се превръща в експерт по тестване на сиви кутии за по-бърза и ефективна работа с автоматизация.
Заключение: Ръчна или сива автоматизация на тестовете?
В заключение, както ръчното тестване в сива кутия, така и автоматизираното тестване имат своето място в процеса на тестване на софтуер.
По-малките компании и стартиращите предприятия имат полза от прилагането на ръчно тестване в сивата кутия, когато кодът им е сравнително малък и управляем, а автоматизацията става все по-полезна, когато приложенията продължават да растат и да имат повече функции.
Въпреки това ръчното тестване винаги ще има място благодарение на повишеното ниво на разбиране, детайлност и гъвкавост, които то предлага на компаниите.
Идеалното решение за “сивата кутия” за всяка компания е хибриден модел, който използва ръчно и автоматизирано тестване в различни моменти, за да отчете силните и слабите страни на двете техники.
Цялостният подход разкрива повече от проблемите, които има даден софтуерен пакет, като помага за по-ефективното му отстраняване и в крайна сметка предоставя на клиентите много по-добър продукт в края на разработката.
Какво ви е необходимо, за да започнете тестване на сивата кутия?
Съществуват няколко предпоставки, които компаниите изискват, преди да започнат процеса на тестване на сивата кутия. Наличието им или прави процеса на тестване възможен, или значително улеснява тестването на софтуера за екипа за осигуряване на качеството, тъй като той разполага с повече средства.
Предпоставките за провеждане на тестване на сивата кутия включват:
1. Документи за проектиране или изходен код
Първото нещо, от което се нуждаете, за да започнете процеса на тестване на сивата кутия, е документацията за проекта или изходният код. Тестващите трябва да могат да получат достъп до тази информация, за да може тестването да се счита за тест на сивата кутия, който предлага известна представа за вътрешната работа на самия софтуер.
Тази информация трябва да бъде възможно най-подходяща, например низът от код за конкретната функция, която проверява тестерът.
Когато използвате сива кутия вместо бяла кутия, предоставяте само част от кода и документацията за проектиране, затова внимавайте за нивото на достъп, което предоставяте.
2. Кратко описание на продукта
Кратко описание на продукта или кратко описание на приложението е документ, който компаниите използват, за да получат пълна представа за това какво търси клиентът в даден софтуерен пакет. В него подробно се посочват точната функционалност, която клиентът търси от софтуера, дизайнът, който клиентът желае, и всички други необходими спецификации.
Прочитането на краткия текст на продукта означава, че тестерът на “сивата кутия” може да търси всички функции, които клиентът иска, да се увери, че те са налични в софтуера, и да гарантира, че продуктът отговаря на всички цели, които компанията има за своето приложение.
Някои компании ограничават обема на информацията, която могат да видят тестерите на сивата кутия, в зависимост от политиките за поверителност в компанията.
3. Цели на теста
Разработчиците и компаниите имат конкретни цели при изпълнението на тестовете, които понякога се наричат спецификация на теста. Това е изключително важно в процеса на тестване на сивата кутия, тъй като означава, че разработчиците могат да предоставят на тестерите на сивата кутия цялата необходима информация, а екипът за осигуряване на качеството разработва тестове, които отговарят на целите на процеса на тестване.
В този случай всички работят по-ефективно, тъй като знаят какво търсят и как най-добре да постигнат тези цели.
Процес на изпитване на сивата кутия
Тестването на сивата кутия следва сравнително последователен процес с ясни стъпки, в които са отбелязани отделните етапи, които компанията трябва да изпълни, за да постигне целите си за тестване.
Ясното и последователно следване на процеса осигурява точни и последователни резултати, които информират разработчиците за това къде има проблеми и как могат да бъдат разрешени.
Основните етапи на теста на сивата кутия са:
1. Определяне на входовете и изходите
Първата стъпка в процеса е да определите входовете и изходите, които очаквате от приложението.
Изберете входна информация, която е в границите на това, с което приложението може да се справи в нормални условия, за да бъде тестът справедлив, и изчислете резултата, който очаквате от тази входна информация.
Ако направите това прогнозиране в началото на проекта, ще знаете дали нещо не се е объркало в края на тестовете.
2. Идентифициране на основните потоци
Първичните потоци са маршрутите, които данните следват в даден софтуер, за да достигнат до крайния си резултат.
Идентифицирането на основния поток означава, че можете по-добре да проследите начина, по който информацията преминава през процесите на даден софтуер, да установите потенциални области за поява на недостатъци и да работите по отстраняването им, ако има проблем със софтуера.
3. Идентифициране на подфункции с входове и изходи
Подфункциите са основни операции в рамките на основния поток. Всяка подфункция се захранва от друга и се включва в следващата, като в крайна сметка води до крайния резултат от софтуера.
Установете какви трябва да бъдат входните данни за всяка подфункция, както и прогнозните резултати за всяка от тях.
Извършването на това на ниво подфункция осигурява допълнително ниво на разбиране при намирането на софтуерни проблеми.
4. Разработване на тестови случай
Тестовият случай се отнася до набор от събития, които се случват в софтуера и които проверяват дали приложението работи според очакванията ви.
Уверете се, че този случай на тест на сивата кутия изследва правилно частта от софтуера, която разглеждате.
Също така се съсредоточете върху последователността, като се уверите, че тестовият случай е лесен за повторение, за да получите по-точни резултати от теста на сивата кутия.
5. Изпълнение на тестовия случай
Започнете да изпълнявате тестовия случай.
Това включва въвеждане на входните данни във всяка от подфункциите и проверка на изходните данни, като се записват всички резултати.
При автоматизираното тестване на сивата кутия процесът на записване е автоматичен, като ръчните тестери сами записват всички входове и изходи.
Ако можете, тествайте всички подфункции поотделно, преди да стартирате целия поток наведнъж, за да проверите дали всяка функция работи независимо.
6. Проверка на резултатите
След като получите данните от тестовия случай, започнете да проверявате тези резултати.
Това означава да разгледате резултатите, които получавате от софтуера, и да ги сравните с резултатите, които сте очаквали в началото на процеса.
Ако има разлика между двете стойности, това означава, че в софтуера може да има грешка, тъй като той не работи по начина, по който сте прогнозирали първоначално.
7. Създаване на отчет
В края на процеса на тестване на сивата кутия създайте отчет за резултатите от теста.
Това включва основно обобщение на проблемите, свързани със софтуера, оценка на някои потенциални решения на проблемите и, където е възможно, всички данни, получени при тестовете.
Използването на тази структура дава заглавен урок на читателя, преди да предостави всички необходими доказателства, като в крайна сметка представлява цялостен документ, който предлага много насоки.
Най-добри практики за тестване в сивата кутия
Най-добрите практики се отнасят до процесите, задачите и принципите, които служителите изпълняват в рамките на теста за осигуряване на качеството, за да постигнат възможно най-високите стандарти.
Някои от тези най-добри практики за екипите по осигуряване на качеството, които искат да повишат стандарта на работата си, включват:
1. Работете внимателно
Както при всеки метод за тестване, отделете време и работете внимателно. Една-единствена грешка може да доведе до невалидност на теста, така че бавното и постоянно гарантиране на точността на работата ви спестява време в дългосрочен план, като същевременно подобрява стандарта на софтуера. Това е особено вярно при тестването в сивата кутия, тъй като не знаете с кои части от изходния код работите във всеки един момент.
2. Общувайте постоянно
Трябва да има постоянна комуникация между разработчиците и тестерите на “сивата кутия”. Това дава на разработчиците незабавна обратна връзка за всички грешки, които екипът за тестване открива, и означава, че тестерите знаят за какво да внимават.
Ако грешката е част от видимия аспект на сивото поле, уведомете разработчиците къде точно се намира тя.
3. Поставете строги ограничения
Когато при тестването на сивата кутия се използват изкуствени ограничения на информацията, като самата компания решава каква информация да предостави на тестерите, уверете се, че имате строги ограничения.
Предоставете на екипа по осигуряване на качеството само необходимите разрешения, в противен случай рискувате да “надникнат зад завесата” и да видят част от изходния код или документите за разработка, които се опитвате да запазите скрити.
7 грешки и капани при прилагането на тестове на сивата кутия
При стотици хиляди приложения, които преминават през процеса на тестване всяка година, има някои грешки и капани, в които екипите по осигуряване на качеството попадат.
Знаейки за тях, можете ефективно да ги избегнете, да подобрите работата си и да намалите вероятността да похарчите ресурси за лоши стратегии за тестване.
Някои от най-често срещаните грешки и капани при тестовете в сивата кутия включват:
1. Тестване на разпределени системи
Тестването на сивата кутия изисква достъп до изходния код, а разпределените сървъри използват код от други места. Това води до проблеми при тестването на “сивата кутия”, тъй като означава, че има проблеми, които тестващите може да не са в състояние да видят.
2. Завършване на несъгласувано тестване
Непоследователното тестване се отнася до ситуация, при която даден тестови случай се променя между отделните изпълнения. Това може да доведе до неточни резултати, като след това разработчиците се фокусират върху подобряване на производителността въз основа на неверни показатели.
Когато е възможно, направете всеки тест идентичен, за да увеличите прецизността и точността на тестовете.
3. Бързане с тестовете
Ако предложената дата за пускане на продукта наближава, екипите за осигуряване на качеството могат да се изкушат да прибързат с процесите на тестване на сивата кутия.
Това обаче е признак на лошо планиране и не бива да се реагира с още лоши решения. Прибързаното тестване води до неточни резултати и загуба на време в по-късната фаза на разработката.
4. Липса на ръчно управление и автоматизация заедно
Нито ръчното, нито автоматизираното тестване са перфектни методи за тестване на сивата кутия.
Използването на двата метода успоредно означава, че можете да отчитате проблемите на всеки от тях и в крайна сметка да работите по-ефективно.
Най-малкото, помислете за комбиниране на двата метода за по-добро тестване.
5. Работа без инструменти
Инструментите за тестване са създадени, за да улеснят максимално работата на тестерите в сивата кутия. Работата без никакви инструменти е ненужно ограничаване на собствените ви възможности.
Внимателно проучете и придобийте всички инструменти, които биха могли да подпомогнат разработката ви, за да повишите ефективността и да намалите възможността за грешки.
6. Лоша комуникация
Вътрешната комуникация между отделите може да бъде трудна, но възможно най-ясната комуникация между отделите за тестване и разработване е задължителна.
По-добрата комуникация означава, че разработчиците знаят какви подобрения да направят незабавно и да разрешат проблемите, без да се подвеждат по лоши вътрешни съобщения.
7. Активно търсене на грешки
Тестовете на сивата кутия съществуват, за да се открият евентуални грешки, но също така и за да се провери общата производителност на софтуера.
Прекалено дългото търсене на грешки може да отнеме много време и да отклони вниманието ви от основната цел – да подобрите начина, по който работи приложението.
Видове резултати от тестовете на сивата кутия
Тестовете на сивата кутия генерират няколко различни вида информация в края на процеса. Това не се отнася до резултатите от самия софтуер, а по-скоро до данните, които разработчиците могат да използват за подобряване на софтуера.
Основните типове изходи са:
1. Съобщения PASS/FAIL
Обикновено съобщение PASS/FAIL, което информира разработчика за това дали софтуерната операция е била успешна.
Този тип резултати не дават много информация на разработчика, но използването на тестване в сива кутия означава, че тестерът може да види в кой конкретен момент софтуерът се е провалил и защо, което помага за решаването на проблема.
2. Метрики
Метриките се отнасят до прости статистически данни, които отразяват дадено събитие, като например времето, необходимо за изпълнение на определена задача, с точност до милисекунда. Те са често срещани при автоматизираното тестване на сивата кутия, като компютърните платформи автоматично събират тази информация с по-високо ниво на точност, отколкото ръчният тестер би могъл.
Тази информация е полезна за определяне на производителността на дадено приложение.
3. Качествени данни
Описателна информация, която получавате от тестер на сива кутия от неговия опит със софтуера. Не може да се определи количествено, което затруднява анализа, но осигурява по-добро ниво на разбиране на потребителското преживяване и прави клиентите по-удобни за софтуера.
Примери за тестове на сивата кутия
В някои случаи познаването на теорията за дадена форма на тестване не дава достатъчно представа и не осигурява правилно разбиране. Познаването на някои примери за тестове на сивата кутия е от съществено значение за по-доброто разбиране на начина, по който работи методологията за тестване.
Вижте някои примери за тестове в сивата кутия по-долу, които дават повече информация за тестовете в реалния свят и за това как теорията се прилага на работното място.
1. Пример за успешно тестване на сигурността
Компанията създава база данни с много лични данни и планира тестване на сигурността, за да се увери, че данните на потребителите са защитени.
Ръчният тестер преминава през процеса, като търси потенциални грешки в кода и възможности за достъп до части от приложението.
След като открие слабост, тестерът информира разработчика за това къде е слабостта и как я е използвал.
Когато софтуерът бъде поправен, тестерът извършва същия тест отново, за да се увери, че системата е сигурна.
2. Пример за неуспешно тестване на база данни
Разработчиците, които създават база данни, имат кратък срок за пускане и трябва да тестват бързо.
Тестерите набързо събират няколко основни тестови случая и ги изпълняват бързо, като допускат грешки при изпълнението им, не подготвят прогнози за резултатите и не проверяват подфункциите.
Тъй като не изготвят прогнози за изхода, те не осъзнават проблемите с изхода, в резултат на което изпращат продукт, който не работи правилно.
Видове грешки и бъгове, открити чрез тестване на сивата кутия
Една от основните цели на тестването на сивата кутия е да се открият грешки и бъгове в програмата, като компаниите се стремят да доставят висококачествени приложения, на които клиентите им да могат да разчитат, когато е възможно.
Има няколко специфични вида грешки и бъгове, които тестващите могат да открият в процеса на тестване на сивата кутия, като всеки от тях може да показва различен проблем в кода.
Видовете грешки и недостатъци, открити при тестване в сивата кутия, включват:
1. Неуспех на процеса
Първата форма на грешка е провал на процеса.
Това се отнася за случаите, когато тестът не връща никакъв резултат и просто се срива.
Съществуват няколко потенциални причини за тези проблеми и в идеалния случай тестерът на “сивата кутия” може да установи откъде идва проблемът и как разработчикът може да кодира отговор.
2. Неправилен изход
Някои грешки при тестването на сивата кутия се появяват, когато изходът на даден процес не е този, който разработчиците очакват.
Това е сериозен проблем в случаи като базата данни, в която сигурното съхраняване на правилната информация е необходимост.
3. Грешки в сигурността
Грешки в сигурността се появяват, когато приложението на компанията е донякъде несигурно и позволява на трети страни да имат достъп до информацията, която се съхранява в него.
Недостатъците в сигурността на дадено приложение могат да бъдат проблем на GDPR и да направят приложението несъвместимо с редица международни разпоредби.
Общи показатели за тестване на сивата кутия
Метриките се отнасят до постоянни измервания, които изследват определено събитие или поредица от събития, обикновено под формата на количествени данни.
С помощта на метриките тестерите и екипите за осигуряване на качеството могат да изследват софтуера, който се подлага на тест в сивата кутия, и да видят какво точно не е наред, независимо дали става въпрос за повече грешки или за по-дълго зареждане на различни функции.
Някои от най-често срещаните показатели за тестване на сивата кутия, които QA тестерите използват при оценяването на софтуера, включват:
– Време за извеждане:
Количеството време, необходимо на приложението, за да произведе резултат след началото на теста.
– Време за реакция:
Времето, необходимо на софтуера да отговори на въведените от потребителя данни, независимо дали под формата на резултат или просто потвърждение на въвеждането.
– Брой грешки:
Чистият брой на грешките, които софтуерът има в своите процеси.
– Грешки по функции:
Броят на съществуващите грешки, разделен на броя на функциите в софтуера, се използва за определяне на плътността на грешките.
Най-добри инструменти за тестване на сивата кутия
Тестването на сивата кутия може да разчита на външни инструменти за подобряване на качеството на работата ви, като автоматизира някои от процесите и ви помага при създаването на поправки за откритите грешки.
Колкото по-добър инструмент за тестване използвате, толкова повече проблеми ще откриете и толкова по-добър ще бъде стандартът на крайния ви продукт, като същевременно ще спестите време и ресурси по време на тестването.
Вижте някои от най-добрите инструменти за тестване в сивата кутия по-долу, както и предимствата и недостатъците на използването на всяка платформа.
5 най-добри безплатни инструмента за тестване на сивата кутия
Когато една по-малка компания иска да започне тестване на сивата кутия, наличието на подходящи инструменти е задължително, но също толкова важно е те да са на разумна цена. В малкия бизнес всяка стотинка е от значение и разработчикът на приложения не е по-различен – ограничените бюджети водят до трудни решения.
Използването на безплатни инструменти за тестване на сивата кутия е идеално за осигуряване на качеството с минимални ресурси.
Някои от най-добрите безплатни инструменти за тестване на сивата кутия включват:
1. ZAPTEST БЕЗПЛАТНО ИЗДАНИЕ
Безплатното издание на ZAPTEST предлага висококачествено изживяване при автоматизацията за своите потребители, като автоматизацията на софтуера с пълен пакет поддържа тестването от самото начало на разработката.
С паралелното изпълнение можете да извършвате няколко теста едновременно, за да ускорите процесите си, а когато сте готови да преминете на следващото ниво, изданието Enterprise прави прехода възможно най-прост. Като допълнително предимство ZAPTEST предлага и най-съвременната технология RPA без допълнителни разходи.
Перфектният избор за човек в началото на своето тестване.
2. Appium
Инструмент за задълбочено тестване, предназначен да помогне да се уверите, че мобилните приложения отговарят на стандартите, Appium има активна общност за поддръжка, но изпълнява тестовете сравнително бавно. В съчетание с трудна настройка, това не е най-добрият безплатен инструмент за много компании.
3. Инструменти за разработчици на Chrome
Google Chrome предлага редица инструменти за разработка на уеб приложения, а интеграцията в най-популярния браузър изглежда задължителна.
Той обаче е ограничен до тестване на елементи от кутия, което го прави ограничен инструмент за тестване.
4. JUnit
JUnit е рамка с отворен код, която позволява на потребителите да извършват повтарящи се тестове отново и отново в Java, като се ограничава до един-единствен език.
Само по себе си това ограничение не е проблем, но липсата на прост API и интерфейс може да отблъсне по-новите тестери.
5. DBUnit
DBUnit се фокусира върху поддържането на проекти, ориентирани към бази данни, като използва известни състояния за точна проверка на резултатите и цялостно проучване на резултатите.
Това е идеално за бази данни и подобни приложения, но липсата на поддръжка за интеграция означава, че той се справя трудно с междуплатформени задачи.
5 най-добри инструмента за тестване на сивата кутия на предприятието
С разрастването на разработчика се увеличават и изискванията му за тестване, като по-големите компании имат по-големи приложения и в резултат на това изискват по-обширни пакети за тестване.
Съществуват корпоративни инструменти за тестване на сиви кутии, които подпомагат компаниите в тази ситуация, предоставяйки по-голям достъп до разширени функции, от които любителите и малките разработчици може да не се нуждаят.
Някои от най-добрите инструменти за тестване на корпоративния клас при провеждане на тест на сивата кутия включват:
1. ZAPTEST ENTERPRISE EDITION
Изданието Enterprise на ZAPTEST предоставя по-големи възможности за тестване от безплатната версия, като едно от основните предимства е постоянният достъп до експерт на ZAP. Експертът на ZAP действа като съветник и член на екипа ви от разстояние, като подпомага всички нужди на компанията ви от тестване.
Разработчиците, които инвестират в изданието ZAPTEST Enterprise, могат да видят до десет пъти по-висока възвръщаемост на инвестициите си благодарение на усъвършенстваните технологии за компютърно зрение, 1SCRIPT, изпълнението на различни платформи, устройства и браузъри и най-вече на неограничените лицензи.
Неограничените лицензи, в допълнение към най-модерните технологии за тестване и RPA, означават, че предприятията се възползват от фиксирани разходи, независимо от това колко бързо и колко много растат.
2. TestRail
Решение за управление на тестови казуси, което ви позволява да разделяте всички извършени тестове по тестови казуси, за да записвате по-точно данните.
TestRail обаче не е непременно идеален за тестване на сиви кутии, тъй като трудно балансира между ръчното тестване и автоматизираното записване на тестове.
3. Тест
Платформа за тестване, която се фокусира върху предлагането на стабилни персонализирани тестове, като прилага както кодирани тестови случаи, така и некодирани алтернативи.
Тъй като това е безплатно само за определен брой тестове на месец, по-големите организации трудно могат да се възползват максимално от тази платформа.
4. TestRigor
TestRigor е широко призната платформа, която използва двигател с изкуствен интелект за извършване на тестове, като поддръжката на тестовете с изкуствен интелект е една от най-привлекателните характеристики.
Това обаче е свързано със значителна цена, тъй като други платформи осигуряват по-добра възвръщаемост на инвестицията.
5. Kobiton
Kobiton е платформа за тестване, която е сравнително гъвкава по отношение на ценообразуването, като автоматизира тестовете на база потребител след приключване на безплатния пробен период.
Едно от опасенията на някои потребители по отношение на Kobiton е относителната липса на подкрепа от страна на Kobiton, когато става въпрос за разрешаване на запитвания от страна на тестващите.
Кога трябва да използвате инструменти от сивата кутия за корпоративни клиенти спрямо тези за безплатни услуги?
Както корпоративните, така и безплатните инструменти за сиви кутии предоставят на своите потребители много предимства. В идеалния случай компаниите започват с безплатен продукт, за да се запознаят с процеса на тестване, след което преминават към корпоративно издание, когато нуждите им нараснат.
Така се постига приемственост в проекта и се ограничава броят на преквалификациите на персонала.
Точката на преминаване е различна за различните предприятия, но в определен момент възвръщаемостта на инвестициите в даден продукт на предприятието става неизбежна.
Контролен списък за тестване на сивата кутия, съвети и трикове
Извършването на тестване на сивата кутия е доста сложен процес, така че наличието на контролен списък, по който да работите, ви помага да се уверите, че сте направили всичко необходимо за тестването.
Някои от основните характеристики на контролния списък на сивата кутия, в допълнение към някои съвети за подобряване на качеството на вашето тестване, включват:
1. Задълбочено планиране
Цялостното планиране е едно от първите неща, които трябва да се отбележат в теста, тъй като е необходимо да се уверите, че сте планирали абсолютно всеки аспект на теста.
Колкото повече планирате, толкова по-структурирано е вашето тестване, тъй като хората знаят какви тестове изпълняват и кога ги изпълняват.
Това води и до последователни данни, които са идеални за по-добри решения за разработчици.
2. Незабавно отчитане на данни
Когато работите върху процес на тестване на сивата кутия, се опитвайте да докладвате данните незабавно. Създавайки отчети възможно най-скоро, увеличавате точността на процесите на отчитане, тъй като цялата информация е прясна в съзнанието ви.
Това важи особено за качествената информация, тъй като тя трябва да бъде написана от изпитващия, а не просто съхранена в платформата за изпитване.
3. Определяне на отговорностите
По време на процесите на тестване се уверете, че всички на работното място са съсредоточени върху конкретните си отговорности. С така определените отговорности всеки знае каква е неговата роля на работното място и разбира как да изпълнява задачите си продуктивно и с минимални прекъсвания.
Макар че това е по-скоро управленска концепция, отколкото точка от контролния списък за изпитване, тя има голямо въздействие върху резултатите.
4. Постоянно сравнение
Сравнявайте резултатите си с няколко неща почти постоянно. Точките за сравнение включват първоначалната проектна документация, резултатите от предишни тестове и графика на организацията за завършване на проекта.
Наличието на тези референтни рамки постоянно ви информира за това как върви процесът на разработване на софтуер, за областите за подобрение и за потенциалните корекции, които трябва да направите.
Заключение
В заключение, тестването в сивата кутия е една от най-универсалните форми на тестване, която съчетава функционалността на бялата кутия с ограниченията на пристрастията на тестовете в черната кутия.
Чрез комбиниране на методите за ръчно и автоматизирано тестване в сивата кутия, компаниите могат да започнат да намаляват значително въздействието на грешките върху своя софтуер, като въвеждат поправки, които водят до по-добър продукт.
Тестването на сивата кутия е идеалният инструмент за всеки разработчик, а горните съвети могат да ви гарантират, че го използвате правилно.
Често задавани въпроси и ресурси
Ако имате въпроси относно тестването на сивата кутия, разгледайте някои от нашите често задавани въпроси, за да научите повече и да подобрите разбирането си за този тип тестове:
1. Най-добрите курсове за автоматизация на тестовете в сивата кутия
Има сравнително малко курсове, които са насочени специално към автоматизацията на тестовете в сивата кутия, като тези общи курсове за тестване на софтуер са идеален начин да започнете:
– “Software Testing Foundation with Exam”- Предложения за обучение
– “6-седмично обучение по софтуерно тестване”- Futuretrend Technologies Ltd
– “Software Testing Course”- Royal Course
– “Тестване в черна и бяла кутия” – Coursera
– “Софтуерно тестване – Black-Box стратегии и White-Box тестване”- NPTEL
2. Кои са 5-те най-важни въпроса за интервюта за тестване в сивата кутия?
– Какъв опит имате в работата с тестването на сивата кутия и как го открихте?
– Защо компаниите използват тестване на сивата кутия и на кой етап от процеса?
– Сравняване на тестването в “бяла кутия”, “сива кутия” и “черна кутия
– Какви са някои от най-големите предизвикателства при тестването на сивата кутия и как можете да ги преодолеете?
– Как работи автоматизацията на тестовете?
3. Най-добрите уроци в YouTube за тестване на сивата кутия
– “Какво представлява тестването в сивата кутия? Какви са техниките, използвани при тестването на сивата кутия? С обяснен пример”- Software Testing Hacks
– “Тестване на сивата кутия | софтуерно инженерство |”- Education 4u
– “Тестване в черна кутия, бяла кутия и сива кутия”- Miracle Education
– “Съвети за нови ръчни QA тестери | Работа с разработчици + неща, които съм научила като софтуерен тестер”- Madeline Elaine
– “Какво представлява тестването в сивата кутия? (Въпрос за интервю за тестване на софтуер #54)”- QA Fox
4. Как да поддържаме тестовете в сивата кутия?
Поддържането на тестовете на сивата кутия е сравнително лесен процес. При ръчното тестване се уверете, че служителите са добре обучени и изпълняват едни и същи задачи всеки път. При автоматизираното тестване проверявайте целия код за тестовите случаи и проверявайте резултатите, като по възможност използвате постоянен надзор на процесите.
5. Най-добрите книги за тестване на сивата кутия
Този раздел съдържа статии от списания в допълнение към книгите, за да се осигурят най-високите възможни стандарти за писмена помощ за QA тестери:
– “Grey-Box Technique of Software Integration Testing Based on Message”- TanLi M. et al
– “Сравнително изследване на техниките за тестване “бяла кутия”, “черна кутия” и “сива кутия””- Ehmer, M., Khan, F.
– “Стратегии за тестване, базирани на сивата кутия FSM”- Петренко, А.
– “Софтуерно инженерство”- Saleh, K.A.
– “Международна конференция по компютърни приложения 2012”- Kokula Krishna Hari K.
