Софтуерното тестване е изключително сложна и интензивна област, в която всички компании и независими разработчици се стремят да подобрят своите продукти с помощта на различни методи за тестване.
Един от най-разпространените методи, които компаниите използват за тестване, е тестването на черна кутия – техника, която създава дистанция между разработчиците и тестерите, за да се осигурят точни резултати и да се елиминират пристрастията.
Научете повече за това какво представлява тестването на черна кутия, как да извършите тестване на черна кутия и за някои от ползите от прилагането на тестване на черна кутия в софтуерното инженерство с това подробно ръководство.
Какво представлява тестването “черна кутия”?
Тестването на “черна кутия” се отнася до процеса на тестване на система или софтуер, без да имате предварителни познания за начина, по който тя работи вътрешно. Това се отнася не само до непознаването на самия изходен код, но и до това, че не сте виждали никаква документация за дизайна на софтуера. Тестерите просто предоставят входни данни и получават изходни данни, както би направил крайният потребител. Въпреки че това е просто определение за изпитване на черна кутия, то определя общата система.
Целта на тестването на “черната кутия” е да накара потребителите да взаимодействат със софтуера по по-естествен начин от обичайния, без да са предубедени, че вече познават софтуера.
При тази методология хората, отговорни за изпълнението на тестовете, са различни от тези, които са разработили софтуера, което създава разделение между двата екипа.
1. Кога и защо е необходимо да се прави Black Box Testing при тестването на софтуер?
В цикъла на разработката има няколко фази, в които е идеално да се използва тестване на черна кутия, като повечето тестове на черна кутия се провеждат в края на разработката, малко преди пускането на продукта.
Това включва методи като тестване за приемане от потребителите, при което софтуерът се предоставя на членове на целевата аудитория като форма на тестване преди пускането му в експлоатация. Това е по-известно като бета тестване и е идеален инструмент за дадена компания, тъй като по-голямата експозиция означава, че е по-вероятно хората да открият потенциални грешки в софтуера.
Работата с методологията “черна кутия” в края на цикъла на разработка е задължителна, тъй като това е версията, до която потребителят има по-голям достъп. Бихте могли да използвате тестване на “черната кутия” за отделни функции, но това би провалило целта на тестването.
2. Кога не е необходимо да правите тестване на черната кутия
Тестването на “черната кутия” има много малко значение в най-ранните етапи на разработката. Когато една компания изгражда основната функционалност на своя софтуер, тя използва тестване на бялата кутия, за да може разработчикът да види в коя точка на кода има проблеми.
Не е необходимо и тестване на черната кутия, когато софтуерът е с отворен код, сравнително прост уеб инструмент или е предназначен за подпомагане на проекти за кодиране на трети страни, тъй като има сравнително гол потребителски интерфейс и потребителят така или иначе има достъп до изходния код на програмата. Ако очаквате потребителят да получи достъп до изходния код, тестването в черна кутия губи основната си цел.
3. Кой участва в тестването на черната кутия?
Има много роли, които участват в процеса на тестване на черната кутия, като някои от тези роли зависят от естеството на компанията, която извършва тестването.
Значимите роли, които участват в процеса на тестване на черната кутия, включват:
– Тестер
Тестерът отговаря за изпълнението на ръчните тестови случаи в дадена компания, като пише подробни тестови случаи, които изследват приложението в детайли, преди да ги изпълни и да докладва резултатите. Тази роля се изпълнява предимно в процеса на ръчно тестване, като автоматизираните системи поемат ролята, когато е налице автоматизация на тестовете.
– Анализатор на QA
Анализаторът на ОК отговаря за програмирането на тестови случаи в процеса на ОК, най-вече когато компанията използва процес на автоматизация на тестовете за ОК.
Процесът включва както проектиране на задълбочени тестови случаи, които гарантират високо ниво на функционалност, така и изпълнение на тестовите случаи и получаване на резултати след приключването им.
– Разработчик
Лицето, отговорно за разработването на софтуера, който екипът за осигуряване на качеството тества. Разработчикът получава обратна връзка от екипа за тестване и актуализира софтуера по съответния начин, като работи като част от екипа за разработване, но е в постоянна комуникация с тестерите.
– Ръководител QA
Мениджърът по осигуряване на качеството е ръководител на екипа по осигуряване на качеството и отговаря за управлението на всички задачи, които изпълняват тестерите.
Това включва организиране на графика за тестване, изготвяне на списък с неща, които трябва да се свършат от членовете на персонала, и разрешаване на конфликти в екипа. Те също така обясняват тестването на черната кутия в обучението на новите служители.
– Ръководител на проекта
Лицето, отговорно за качеството на крайния проект, ръководител на проекта наблюдава процеса на тестване, както и разработването, като гарантира, че клиентът получава софтуерен пакет, който отговаря на цялото задание.
Предимства на Black Box Testing
Използването на тестване на черната кутия в работата по разработката има няколко съществени предимства. Колкото повече сте наясно с тези предимства, толкова повече можете да се възползвате от тях и да извлечете възможно най-много ползи от техниката.
Някои от основните предимства на използването на тестване на черната кутия при осигуряване на качеството включват:
1. Няма нужда от технически познания
Подходът “черна кутия” означава, че няма нужда от технически познания, когато разглеждате дадено приложение.
Целта на тестването на черната кутия е да се провери как приложението работи за крайния потребител, а в повечето случаи стандартният потребител няма разширени технически познания. Това може да намали разходите за тестване, като помогне на организацията да открие повече грешки с по-малко разходи и да стане по-ефективна от финансова гледна точка.
2. Точно моделиране на потребителя
Крайната цел на процеса на тестване на “черна кутия” е да се разберат проблемите с приложението, когато потребителят взаимодейства с него ежедневно.
Някои видове тестване на черната кутия – които се фокусират върху възпроизвеждането на начина, по който се държи потребителят, моделират поведението на потребителя с висока степен на точност. Това важи с особена сила за тестовете за приемане от страна на потребителите, при които крайните потребители се сблъскват с продукта, като не просто моделират или симулират поведението на потребителя, а действително го прилагат.
Точното моделиране помага да се разкрият всички грешки, които засягат реалните работни процеси на потребителя.
3. Възможност за групово тестване
Тестването “черна кутия” е много достъпна форма на тестване благодарение на сравнително ниските изисквания за умения.
Това означава, че компаниите могат не само да наемат тестери с по-ниско ниво на технически умения, но и да предоставят тестовете си на запалени клиенти. Това е все по-често срещано явление в гейминг индустрията – компаниите предлагат ранен достъп, като с течение на времето актуализират играта, за да разрешат проблемите, които потребителите откриват.
Намирането на грешки в този случай е много по-лесно, тъй като всички функции са изложени на много по-голямо внимание.
Предизвикателства при тестването на черната кутия
Освен ползите от тестването на черната кутия, има и няколко основни предизвикателства, които трябва да вземете предвид. Осъзнаването на тези предизвикателства означава, че можете да се адаптирате към тях, като повишите стандарта на вашето тестване, намалявайки вредните ефекти, които може да има тестването на черната кутия.
Някои от тези предизвикателства включват:
1. Трудно намиране на причините за проблема
Един от основните недостатъци на тестването “черна кутия” е, че може да е по-трудно да се открие причината за проблемите, когато тестващите нямат достъп до изходния код.
Макар че могат да опишат каква е грешката и кога се появява, те не знаят коя част от изходния код причинява проблемите и защо.
Тестващите могат донякъде да смекчат този проблем, като си водят задълбочени записки, а подробните съобщения за грешки от разработчика предлагат и допълнителна информация за бъдещи актуализации.
2. Автоматизацията е по-сложна
Тъй като активно се стремите да възпроизведете начина, по който потребителят взаимодейства с даден софтуерен пакет, може да бъде изключително трудно да автоматизирате процеса на тестване на черна кутия.
Първата причина за това е фактът, че тестерът няма никакъв достъп до изходния код, което затруднява съставянето на точен тестови случай. Това се съчетава с факта, че тестовете са проектирани така, че да възпроизвеждат максимално човешкото поведение, а автоматизацията е специално проектирана да действа по роботизиран начин.
Можете да балансирате този проблем, като автоматизирате по-дребните задачи и комбинирате автоматизацията с ръчни тестове, когато е възможно.
3. Трудности с тестването в голям мащаб
Гореспоменатите трудности с автоматизацията означават, че тестването в по-големи мащаби е по-сложно. Мащабното тестване предоставя на компаниите много повече данни за софтуера и означава, че грешките се откриват и възпроизвеждат по-лесно.
Изискването за приоритетно ръчно тестване означава, че може да е по-трудно да се организира тестване в по-големи мащаби. Някои компании се противопоставят на това, като използват система за “отворена бета”, при която всеки, който се интересува от продукта, може да помогне за тестването преди пускането му на пазара и да подкрепи компанията, като предостави доброволно обратна връзка за ранните версии.
Характеристики на тестовете “черна кутия
Има няколко основни характеристики на тестовете “черна кутия”, които отличават тестовете от всяка друга форма на осигуряване на качеството на софтуера.
Тези характеристики включват:
1. Без предварителни вътрешни познания
Тестовете “черна кутия” не изискват предварително вътрешно познаване на софтуера. В някои случаи това може да бъде трудно, тъй като тестващите имат известна представа за аспектите на софтуера, който тестват, и за някои от функциите, които търсят, но това се определя най-общо като невъзможност да се види каквато и да е вътрешна документация.
Казано по-просто, ако информацията е видима за крайния потребител в магазина за приложения или на страницата за изтегляне на уебсайт, тогава тестерът може да я види.
2. Разделяне на тестери и разработчици
Етапите на тестване и разработка се изпълняват от различни хора в ситуация на тестване на черна кутия. Това разграничение идва от липсата на познания, които имат тестерите, тъй като разработчиците познават изходния код поради факта, че те са отговорни за разработването му.
Компаниите подхождат към това по няколко различни начина в зависимост от конкретната ситуация, като някои избират да използват външна организация за извършване на тестването, а по-големите компании имат специални отдели от тестери, които изпълняват тази задача.
3. Тестване на късен етап
Това се отнася до етапа на развитие, на който се извършва това изпитване. Тестовете “черна кутия” се основават на сравнително усъвършенствана версия на съществуващо приложение с цялостен потребителски интерфейс, който позволява пълна навигация в софтуера и достъп до предната част на всяка функция.
Това означава, че тестовете “черна кутия” са възможни само на някои от по-късните етапи на процеса на тестване, когато всичко това е първоначално разработено. Въпреки че потребителският интерфейс и контролите могат да бъдат променяни с течение на времето, те трябва да съществуват под някаква форма, за да могат тестовете за черна кутия да имат достъп до функционалността.
Какво тестваме в тестовете “черна кутия
Тестването на “черната кутия” изследва специфични аспекти на даден софтуерен пакет, като предоставя допълнителна информация в някои области на софтуера, която води до актуализации, повишаващи общото качество на живот.
Някои от основните части на софтуерния пакет, които тестерите изследват при теста на черната кутия, включват:
1. Функционалност
Някои разработчици използват тестването на “черната кутия” като средство за гарантиране, че даден софтуер работи по предназначение за човек, който няма познания за него.
Огромното мнозинство от хората, които използват даден софтуер за търговски цели, го правят, без да разбират вътрешната му работа, така че тестването с тези познания означава, че знаете как да заобиколите всички съществуващи проблеми.
Това задълбочено тестване на функционалността гарантира, че всеки ще се наслади на най-доброто, което приложението може да предложи, вместо да се сблъска с грешки, които не се забелязват при тестването на бялата кутия.
2. Потребителски интерфейс
Потребителският интерфейс се отнася до всеки начин, по който потребителят практически взаимодейства с дадено приложение, за да го накара да изпълни поредица от задачи. Това включва менютата, с които работи потребителят, специфичните бутони, които се намират в приложението, и маркировката, която съществува в софтуера.
Разработчиците прекарват по-голямата част от времето си, за да се уверят, че самото приложение работи според очакванията им, което означава, че отделят по-малко внимание на потребителския интерфейс.
Тестването на “черна кутия” представя на тестващите само потребителските функции на софтуера, като обръща повече внимание на потребителския интерфейс, отколкото на повечето други етапи на тестване.
3. Изпълнение
Освен нормалното функциониране и добрия външен вид, начинът, по който едно приложение работи, е от съществено значение за удовлетворяване на клиентите.
Производителността се отнася до няколко фактора, включително скоростта, с която приложението реагира на входните данни на потребителя, и ресурсите, които използва на дадено устройство.
Благодарение на форматите за тестване, като например тестването от край до край, при които се изследват всички функции на даден софтуер, разработчиците могат да видят колко памет изразходва приложението и кои функции натоварват най-много съответните устройства, което дава насоки за актуализации, свързани с ефективността и производителността, в по-късните версии на приложението.
Изчистване на някои неясноти:
Тестване на черна кутия срещу бяла кутия срещу сива кутия
Тестването в черна кутия е концепция, която звучи подобно на тестването в сива и бяла кутия, но идеите са коренно различни една от друга. Объркването им може да доведе до сериозни проблеми с комуникацията в процеса на разработване и да забави процеса на актуализация и да го направи по-малко ефективен.
Прочетете нататък, за да разясните някои неясноти около различните видове “box testing”, как се различават един от друг и кога да използвате всеки от тях.
1. Какво представлява тестването на бялата кутия?
Тестването в бяла кутия понякога е известно като “тестване в стъклена кутия” и се отнася до процес на тестване, при който тестерът има пълен достъп до цялата информация зад софтуера. Това включва достъп до изходния код, документите за проектиране и краткото описание на пакета за клиента.
Например, ако тестерът работи в най-ранните етапи на процеса на разработка и проверява една функция, възможността да види изходния код на тази функция означава, че той може да открие причината за проблема незабавно.
Един от най-подходящите моменти за използване на тестване на бялата кутия е при предимно вътрешни задачи. Това се отнася до ранното разработване на функционалната част на приложението, като бързите поправки са идеални, тъй като няма полза от затъмняването на кода, когато не се симулира потребителското изживяване. Тестването на “белия код” се използва и в системите с отворен код, тъй като в тези случаи изходният код е достъпен за всички потребители.
Какви са разликите между тестовете “бяла кутия” и “черна кутия”?
Основната функционална разлика между тестването на черна кутия и тестването на бяла кутия е нивото на достъп, което има тестерът до софтуера, но това има много по-значително въздействие върху аспектите на тестването, като например времето.
Тестването на черната кутия се използва по-често на по-късен етап от процеса, когато продуктът се приближава към пускане на пазара, а по-основните етапи на разработване се възползват от прозрачността и бързината на реакция на тестването на бялата кутия. Когато разглеждате тест на черна кутия срещу тест на бяла кутия, двата вида тестове се различават и по нивото на необходимия опит, тъй като за да бъде по-ефективен, тестът на бяла кутия изисква опит в кодирането и разработването.
2. Какво представлява тестването на сивата кутия?
Тестването в “сивата кутия” е форма на тестване, при която потребителят има известна представа за кода, без да има пълен достъп до него. Това означава да разполагате с изходния код на тестваната функция или да имате достъп до част от проектната документация, така че потребителят да разбере какво е цялостното намерение на софтуерния пакет.
Например, ако тестерът проверява само една от функциите в софтуерен пакет, може да му бъде предоставен достъп до изходния код на тази част от приложението.
Компаниите използват тестване на сивата кутия предимно когато проверяват начина, по който дадено приложение е интегрирано с инструмент на трета страна. Те могат да имат достъп до изходния код само за една част от процеса, което ограничава възможностите им за цялостно тестване на “бялата кутия”. Вместо това те виждат входовете и изходите на интеграцията с трети страни и изходния код, отговорен за интеграцията.
Тестващите използват този метод, за да преценят дали проблемите се дължат на софтуера, на приложението на трета страна или на интеграцията между тях.
Какви са разликите между тестването в черна кутия и тестването в сива кутия?
Основната разлика между тестването в черна и сива кутия отново е нивото на достъп до информация, като видът на тествания софтуер е един от основните фактори за разграничаване на видовете тестване.
Тестването на сивата кутия обикновено включва инструменти на трети страни, като например съхранение на данни в облак или инструменти за външна обработка, докато системите от черната кутия обикновено са едно цяло. Много от тестовете на черната кутия не се прекъсват от трети страни, докато интегрираните приложения нямат друг избор, освен да работят по методология за тестване на сивата кутия.
3. Заключение: Черна кутия срещу бяла кутия срещу сива кутия
В крайна сметка има съществени разлики между тестването на черна, сива и бяла кутия, които се основават на това дали на екипа за тестване е представена информация за задкулисието.
Тестването в черна и бяла кутия са крайните точки на този спектър, а тестването в сива кутия включва всичко, което не позволява да се види целият изходен код, освен този на трети страни, и позволява да се види само кодът зад определена функция.
Всички тези методи за тестване обаче играят важна роля в областта на тестването на софтуер, така че е задължително да отделите време и внимание за тяхното изучаване и ефективно прилагане.
Видове тестове на черната кутия
Съществуват три основни вида тестване на черна кутия, които обхващат всички тестове, които компанията извършва чрез методологията на черната кутия. Те са:
1. Функционално изпитване
Функционалното тестване обхваща всичко, свързано с начина, по който приложението работи механично. Това означава да се гарантира, че тя обработва данните по правилния начин, позволява на потребителите да влизат с правилните идентификационни данни и обработва информацията и входните данни, както се очаква.
Тестването на функционалността е един от най-важните аспекти на процеса и включва както локалната функционалност на приложението, така и начина, по който то си взаимодейства с външни инструменти и програми, като например услуги в облака или инструменти за единна регистрация.
2. Нефункционално тестване
Нефункционалното тестване се отнася до тестване, което изследва всеки аспект на софтуера, който не е изрично свързан с функционалността на приложението. Това включва установяване на това дали дадено приложение е използваемо и лесно за разбиране от потребителите, дали е съвместимо с широк спектър от устройства и операционни системи и как работи при значителни нива на натоварване (въпреки че в някои моменти може да премине във функционално тестване).
Това се случва предимно в края на процеса на разработка, след като цялото приложение е компилирано.
3. Регресионно тестване
След актуализация тестерите преглеждат приложението, за да се уверят, че то е изпълнило предвидената функция и няма непредвидени странични ефекти, които да доведат до регресия на приложението.
Това е известно като регресионно тестване и е основна част от проверката на готовността на приложението да бъде пуснато на пазара.
Тестването за регресия се използва след всяка актуализация, за да се гарантира, че функционалните и нефункционалните аспекти на приложението отговарят на предварително постигнатия стандарт.
Техники за изпитване на черна кутия
Когато преминавате през процеса на тестване на черната кутия, можете да приложите широк набор от техники, за да подобрите стандарта на работата си. Някои от най-значимите техники за тестване на черната кутия, които се използват в среда за осигуряване на качеството, включват:
1. Тестване по двойки
Тестването по двойки е форма на тестване, която се фокусира върху изпробването на всяка възможна комбинация от входни данни в софтуера.
Например, ако числата от едно до десет са всички валидни записи в една колона с всички азбучни знаци в друга, тестването по двойки ще провери всяка възможна комбинация от 1А до 10Z. Това е форма на тестване, която може да отнеме много време и усилия на потребителя, което я прави една от техниките, които са най-отворени за потенциална хиперавтоматизация. Това е изключително задълбочено и открива всички потенциални проблеми при въвеждането на данни.
2. Анализ на граничните стойности
Много софтуери разчитат на въвеждане на данни, като данните имат определени граници, в които клиентът трябва да работи.
Например система, предназначена за изчисляване на стойности от 1 до 100, може да се затрудни при стойности от 0 или по-ниски, или по-високи от 100.
Анализът на граничните стойности включва тестване на тези граници, като се въвеждат числа на и около границите, които софтуерът тества, за да се провери дали има грешки на границата на очаквания работен обхват на софтуерния пакет. Това е от полза най-вече при системи, базирани на изчисления, и може да помогне на разработчиците да коригират границите или да открият причината за евентуални проблеми.
3. Тестване на прехода между състоянията
Много от програмите варират между различни “състояния” или “режими” и изискват преход от един етап на този процес към следващия. Правилното функциониране на тези преходи означава, че сайтът функционира според очакванията на потребителя и няма неочаквани прекъсвания.
Тестването на прехода между състоянията е форма на тестване, която изследва всички преходи между състоянията в даден софтуер, като гарантира, че те са функционални и дава сигурност, че потребителският поток през софтуера работи без непредвидени прекъсвания.
Тестване на черната кутия в жизнения цикъл на софтуерното инженерство
Тестването “черна кутия” е дисциплина, която се използва предимно в края на жизнения цикъл на софтуерното инженерство. Това включва всичко – от тестване на начина, по който потребителите ще взаимодействат със софтуера, до предоставяне на пълен достъп до бета-версията, като тестването на “черната кутия” ще започне, след като всички функции заработят според очакванията.
Това спестява много време и усилия в сравнение с тестването на “бялата кутия”, което изисква високо ниво на експертни познания и се прилага най-добре, когато не е необходим екип от разработчици, за да се направят незабавни промени в начина на работа на системата.
Ръчни или автоматизирани тестове на черната кутия?
Софтуерното тестване се извършва в два различни формата, като ръчното тестване е традиционната форма, при която се използват софтуерни тестери на всеки етап от процеса. Това е в категорично противоречие с автоматизираното тестване, което използва все по-високо ниво на изкуствен интелект и машинно обучение за изпълнение на задачи без човешка намеса.
Прочетете, за да научите повече за това какво представляват ръчното и автоматизираното тестване, какви са предизвикателствата пред всяко от тях и кое от двете е идеално за дадена компания.
1. Ръчно тестване на черната кутия – ползи, предизвикателства, процес
Ръчното тестване на черна кутия се отнася до процеса на самостоятелно извършване на тестване на черна кутия, като за изпълнението на всички задачи се използват служители, а не платформа за автоматизация като част от набора от инструменти на компанията.
Някои от основните предимства на използването на ръчно тестване при разработването на софтуер са по-голямата гъвкавост по отношение на начина, по който се извършва тестването, и начинът, по който разработчиците могат да получат много по-задълбочена обратна връзка, която е качествена по своя характер.
Въпреки това процесът на ръчно тестване се характеризира с няколко естествени предизвикателства. Първата от тях е фактът, че ръчното тестване може да отнеме много време, тъй като хората изпълняват задачите си по-бавно от автоматизираните програми.
Друга причина е по-високото ниво на вероятност за грешки, тъй като хората могат да кликнат неправилно или да направят нещата в грешен ред. Това в крайна сметка може да доведе до неточности в данните от тестовете.
Ръчното тестване е процес, който започва с изучаване на очакванията на компанията за дадено приложение, след което се пишат тестови случаи, които оспорват това кратко описание, изпълняват се тестовите случаи и резултатите се докладват на екипа по разработката.
2. Автоматизация на тестовете с черна кутия – ползи, предизвикателства, процес
Автоматизираните тестове се отнасят до тестовете, които компанията извършва за даден софтуерен пакет чрез попълване на тестови случаи с помощта на автоматизирана система. При тях се използват платформи на трети страни за автоматизиране на софтуерния пакет, като всички автоматизирани стъпки следват специално подготвени тестови случаи.
Основното предимство на автоматизацията на тестове “черна кутия” е нейната бързина, тъй като автоматизираните програми отнемат много по-малко време за всяко едно изпълнение на теста. Това води до значително увеличаване на времето за тестване, което можете да отделите за разработване на приложението.
Друго предимство е точността, тъй като добрият инструмент за автоматизация изпълнява едни и същи задачи в един и същи ред всеки път.
Недостатъците все още могат да причинят проблеми при автоматизацията на тестовете “черна кутия”, като един от основните проблеми е фокусирането върху количествени данни. Това е чудесно за метриките, но означава, че при тест за приемливост от страна на потребителя не може да се получи много ценна информация.
Освен това автоматизираното тестване не е достатъчно гъвкаво, тъй като анализаторите трябва да програмират изцяло нови тестови случаи всеки път, когато искат да направят промяна.
Процесът на автоматизация на тестовете започва с проектирането на серия от тестови случаи, които след това се кодират в системата, преди да се изпълнят тестовете, които дават отчет за завършването им.
3. Заключение: Ръчна или черна кутия за автоматизация на тестовете?
В крайна сметка изборът между ръчно и автоматизирано тестване на черната кутия е сложен и зависи от това какво търсите в една система.
Ако търсите качествена информация от висок клас, която можете да използвате, за да направите промени в дизайна за крайния потребител, ръчното тестване е далеч по-добрият вариант, а автоматизираното тестване е идеално за функционалните етапи и етапите на изпълнение в процеса.
Помислете какво търсите на всеки етап от процеса на тестване и можете лесно да получите данни, които да подобрят ефективността ви.
Какво ви е необходимо, за да започнете тестване на черната кутия?
Има някои предпоставки, до които трябва да имате достъп, преди да започнете тестване на черна кутия, като всяка от тях помага за създаването на по-съгласуван процес на тестване.
Някои от нещата, които трябва да имате, преди да започнете работа по тестване на черната кутия, включват:
1. Изисквания към софтуера
Изискванията към софтуера се отнасят до конкретните точки от заданието за проектиране, които софтуерът трябва да изпълни. Това може да включва редица неща – от необходимостта да се изпълняват определен набор от задачи до необходимостта от определен външен вид и усещане при използването му.
Наличието на тази информация ви дава няколко конкретни цели, към които да се стремите при тестването, а тестерите създават график и план за тестване, които водят до по-съгласуван набор от резултати, които информират разработчиците за проблемите със софтуера.
В някои компании, тъй като това е тест на “черната кутия”, разработчиците ограничават достъпа на тестера до кратката информация.
2. Компилиран софтуер
Преди да тества даден софтуер, екипът за осигуряване на качеството трябва да има достъп до него. Обикновено разработчиците предоставят най-новата версия на софтуера, като екипът се възползва от напълно прясно компилирана версия на софтуера, за да извърши тестовете си.
Наличието на актуална версия означава, че тестовете включват някои от най-новите поправки, което означава, че те дават точна представа за работата на софтуера.
3. Цели на тестването
Тестващите обикновено подхождат към периода на тестване с някои конкретни цели. Тези цели за тестване определят точно за какво ще се тества през следващия период, независимо дали става въпрос за приемливост от страна на потребителите, функционалност от край до край или завършване на тестовете за проникване.
Ръководителите на QA обикновено имат тези цели, като следващият етап на тестване обикновено зависи от това, върху какво е работил екипът по разработката, и от частите на софтуера, които тези разработки засягат.
Процес на изпитване на черната кутия
Процесът на тестване на черна кутия е сравнително прецизен и компаниите могат да се възползват от това да следват стъпките на процеса възможно най-точно. Различните етапи на процеса на тестване на черната кутия включват:
1. Планиране на тестовете
Започнете процеса на тестване на черната кутия със сложен процес на планиране. Това включва обсъждане на всички индивидуални цели, които имате за теста, специфичните аспекти на софтуера, които изследвате, и ресурсите, които отделяте за тестовете.
По-задълбоченото планиране означава, че всеки знае какво трябва да прави и кога да го прави, включително методите, свързани с тестовете.
2. Писане на тестови случаи
Написването на тестови казуси е следващият етап от процеса. Случаят на изпитване се отнася до поредица от стъпки, които трябва да бъдат изпълнени при изпитването, като по-подробните случаи на изпитване осигуряват по-голямо ниво на последователност за потребителя.
В процеса на автоматизирано тестване това включва и кодиране на тестовия случай в инструмента за автоматизация, който планирате да използвате.
Проверете два пъти всички тестови случаи, за да сте сигурни, че са изчерпателни и ясни за стъпките, които трябва да се изпълнят.
3. Изпълнение на тестови случаи
След като сте подготвили тестовите случаи, започнете да ги изпълнявате. Когато използвате автоматизация, това може да бъде сравнително лесна задача, която включва настройване на програмата и изчакване на резултатите. Ръчното тестване се основава на многократното изпълнение на тестовите задачи от служителите, като повече повторения водят до по-последователни и висококачествени данни.
Изпълнявайте всеки тестов случай възможно най-внимателно, тъй като колкото по-прецизно е изпълнението на тестовите случаи, толкова по-голям е шансът данните да бъдат полезни за екипа по разработката.
4. Окончателно отчитане
Окончателният етап на докладване се отнася до частта от процеса, в която екипът за тестване докладва на разработчиците.
Започнете, като включите просто резюме на събраната информация, след което добавете към него всички показатели, които са събрали тестерите. Това дава на разработчиците първоначални насоки за идеалната посока на следващата поредица от актуализации, преди да им бъдат показани пълните данни, което им позволява да разберат по-добре проблемите.
Най-добри практики за изпитване на черна кутия
Независимо от отрасъла, в който работите, спазването на най-добрите практики е задължително за всяка компания. Най-добрите практики се отнасят до поредица от поведения и техники, които са от полза за компанията да използва в ежедневната си работа, като повишават ефективността на компанията и подобряват стандарта на софтуера, който компанията използва.
Някои от тези практики, които помагат на компанията да подобри качеството на своето тестване на черната кутия, включват:
1. Фокус върху развитието на умения
Ако управлявате компания, която работи по няколко софтуера едновременно, помислете дали да не се съсредоточите върху развиването на умения и специализации в областта на тестването. Колкото повече време отделяте за специализация и развиване на подходящи умения, толкова по-големи са шансовете ви да отстраните всички проблеми, които съществуват във вашите продукти.
Това се съчетава с наемането на хора, които имат подходящия набор от умения, но е най-подходящо за компании, които почти постоянно провеждат тестване на софтуер, тъй като винаги има полза от прилагането на тези способности.
2. Балансиране на работното натоварване
Някои екипи за тестване могат да бъдат много големи, с десетки или дори стотици служители, които редовно попълват тестови случаи.
Най-добрата практика за извличане на максимална полза от тези служители е да не бързате и да внимавате, когато им възлагате конкретни задачи. Изгарянето е сериозна причина за проблеми в индустрията за разработване на софтуер, но това е нещо, което може да се избегне с по-добро управление на работното натоварване.
3. Създаване на последователни процеси
Компаниите са изградени на базата на процеси, които служителите им изпълняват ежедневно, като процесите на тестване включват начина, по който компанията пише тестовите си случаи, извършва проучвания и осъществява вътрешна комуникация между отделите.
Последователността в тези случаи е от ключово значение, тъй като това означава, че хората се учат по-бързо, когато навлизат в компанията. Това води до по-бърза адаптация и по-добри резултати много по-рано, отколкото в компания, в която няма последователност на задачите.
Ако можете, създайте тези процеси по начин, който да включва служителите в процеса на вземане на решения, тъй като това гарантира, че те са съгласни със стратегията.
7 грешки и капани при прилагането на тестове “черна кутия
Грешките са естествени за всеки отрасъл, но знанието за тях, преди да сте ги допуснали, може да ви спести много време и усилия.
Някои от най-често срещаните грешки и капани, в които попадат тестерите на черната кутия, включват:
1. Липса на дефиниран обхват на тестване
Някои организации започват да тестват своите продукти, без да планират правилно процесите, което е сериозна грешка.
При липса на планиране компаниите могат да загубят представа за обхвата на тестването. Наличието на съгласуван обхват помага на теста да бъде в правилния мащаб и да постигне ефективни резултати.
Ако не постигнете съгласие относно обхвата на тестването, преди да започнете, съществува сериозен риск да тествате твърде широко и да отделите твърде много време, за да получите резултати, които не са толкова подходящи.
2. Забързани процеси на тестване
Тестването може да изглежда като процес, който отнема много дълго време, особено при сложни тестови случаи, предназначени за проверка на цялото приложение. Някои хора могат да се изкушат да бързат с тестовете, особено при повторни тестове. Това е сериозна грешка. Бързането при тестването може да доведе до грешки при изпълнението на тестовите казуси, което ще влоши стойността на данните и в крайна сметка ще означава, че ще трябва да повторите същите тестове.
3. Автоматизиране без процес на проверка
Автоматизацията на тестовете се фокусира главно върху това да се увери, че въвеждането на стойност на данните ще доведе до правилния резултат в края на процеса. Автоматизирането на тези тестове става чрез проверка на резултатите от автоматизирания процес спрямо това, което трябва да бъде.
Някои тестери допускат съществена грешка, като не изчисляват сами стойността, което означава, че нямат възможност да проверят дали резултатът е правилен или не и потенциално не откриват съществени грешки в цялата система.
4. Неизползване на хибридно тестване
Хибридното тестване се отнася до балансирането на автоматизацията с ръчното тестване, тъй като двата метода работят по начин, който напълно покрива недостатъците на всеки от тях.
Някои организации обаче предпочитат да се съсредоточат върху един от двата метода. По този начин отваряте тестовете си за сериозни проблеми и неточности.
Извършвайте хибридно тестване, за да постигнете по-добро ниво на баланс при тестването и да намалите броя на грешките възможно най-много.
5. Незавършване на регресионното тестване
Тестването за регресия трябва да бъде постоянен процес във всяка ефективна система за тестване на софтуер, като чрез тази форма на тестване се установява дали актуализациите на софтуера са причинили проблеми в други части на системата. Неизвършването на регресионно тестване означава, че функциите, които сте тествали в началото на процеса, може да се провалят, без да разберете.
С извършването на регресионно тестване гарантирате, че ще доставите продукт с по-високо качество, без да влагате твърде много допълнителна работа в процеса на осигуряване на качеството.
6. Активно търсене на грешки
Някои смятат, че целта на тестването на черната кутия е да се открият грешки в даден софтуерен пакет и да се докладва за тях на екипа по разработката, и макар това да е един от аспектите, той не е единственият фокус. Тестването съществува, за да подобри като цяло стандарта на даден софтуерен пакет.
Като се съсредоточавате твърде много върху грешките в софтуера, започвате да се отклонявате от стандартните работни процеси, излизате извън обхвата на тестването и пренебрегвате някои от по-важните проблеми на софтуера в замяна на издирването на потенциално несъществени недостатъци в кода.
7. Пренебрегване на интуицията
При ръчното тестване тестерът играе тази роля, защото има съществуваща интуиция и познания за кода, които го насочват към потенциални проблеми и го информират за областите, които трябва да провери, когато работи.
Въпреки това някои решават напълно да пренебрегнат тази интуиция, когато работят по тестови случаи. Като отбелязвате всичко, което искате да тествате, и го проверявате в нов тестови случай, получавате пълната полза от техническите си познания, като същевременно изпълнявате подготвените тестови случаи.
Видове резултати от тестовете на черната кутия
Съществуват няколко вида резултати, които можете да получите от тестването на черната кутия, като всеки от тях предоставя уникални прозрения за компанията, която иска да направи съответните актуализации на своите продукти и да подобри качеството, което клиентите изпитват.
Някои от основните видове резултати от тестовете на черната кутия включват:
1. Качествени данни
Първата форма на изходни данни, които можете да получите от теста на черната кутия, са качествени данни. Това е информация, която основно описва приложението и е резултат от тестове, като например тестове “от край до край” и тестове за използваемост.
Качествените данни обикновено описват стандарта на приложението, обсъждат опита на хората с приложението и обясняват промените, които тестерът би искал да направи.
При създаването на тези данни тестерът обикновено пише подробен доклад, в който посочва всички доказателства за своите твърдения, като подкрепя качествените становища с допълнителни характеристики, като например снимки на екрана на това, за което се отнася.
2. Количествени данни
Това се отнася до ясни цифрови данни под формата на метрики, като членовете на персонала по тестването или отбелязват конкретни части от приложението, или получават цифрови данни от протокол за автоматизирано тестване.
Количествената информация обикновено е по-полезна за предоставяне на разработчиците на отделни поправки, посочващи части от приложението, като например нивото на производителност, ефективността му по отношение на използваните ресурси и броя на грешките и проблемите, които са налице в приложението.
Количествената информация е по-лесна за анализиране и оценяване от описателния си еквивалент, тъй като не е необходимо тълкуване.
3. Съобщения за грешки
Съобщенията за грешка се появяват, когато функционалността на софтуера не работи според очакванията. Това може да се дължи на хардуерен или софтуерен проблем, като обикновено се изпраща кратко описание на проблема в допълнение към кода за грешка.
Разработчиците създават система от кодове за грешки, която им помага да установят къде точно се появява проблем в системата, като някои идеи за прилагане включват използването на първата цифра, за да се ограничи функцията, при която възниква проблем, втората цифра, за да се опише какво конкретно е отказало, и третата цифра, за да се посочи причината за проблема.
Използването на тази система от кодове за грешки означава, че разработчиците веднага знаят какъв е проблемът и могат да работят по неговото разрешаване.
Примери за тестове “черна кутия
Въпреки че теорията на тестването на черната кутия е сравнително проста, практическото му прилагане може да бъде сложен процес, особено за начинаещи тестери. Виждането на пример за тестване на черната кутия в действие може да ви помогне да организирате тестването си.
Някои примери за методи за тестване на “черна кутия”, включващи множество видове тестване и различни степени на успех, включват:
1. Неефективно тестване за приемане от потребителя
Една компания иска да пусне продукта си през следващите седмици, като все още не е проведено тестване за приемане от потребителите. Приложението представлява урок по плетене за възрастна аудитория.
Разработчиците се стремят да ускорят този процес и бързо да съберат група от тестери, като използват за тестване изключително неплетачи в средата на 30-те години, тъй като те са по-достъпна група. Тази група не вижда проблеми в заявлението и го одобрява за публично публикуване.
Поради противоречивите нива на технически познания между двете групи, целевата аудитория е по-объркана при използването на софтуера и няма достъп до много от функциите. В отговор на това компанията е принудена да извърши спешни актуализации.
Подобни неуспешни тестове показват важността на задълбочената подготовка.
2. Успешно тестване от край до край
Тестването “от край до край” се отнася до тестването, което се извършва, след като функционалността на приложението е напълно компилирана в един софтуерен пакет за първи път.
Компанията е планирала внимателно завършването на процеса на тестване от край до край, като е наела редица служители специално за изпълнение на задачите по тестване, като двама служители са посветени на всеки случай на тестване.
Следвайки внимателен процес, те изпълняват тестовите си казуси и записват всички събрани данни, а в края на тестването мениджърът по качеството събира данните в цялостен доклад.
Разработчиците използват този доклад, за да планират следващите серии от актуализации и промени в приложението, с което значително подобряват продукта.
3. Автоматизирано тестване за регресия
Разработчикът е завършил поредица от актуализации на своя софтуер, който преди актуализациите е работил според очакванията. След актуализациите екипът за тестване преминава през процес на регресионно тестване, като се фокусира върху автоматизацията и получаване на автоматизирана платформа за изпълнение на всички основни функционалности.
Екипът написва кода за даден тестови случай и изпълнява тестовите случаи, като прочита всички резултати от тестовете и открива евентуални проблеми.
Така се предотвратява възникването на проблеми поради това, че организацията прави актуализации и не проверява дали те имат проблем или не.
Видове грешки и бъгове, открити чрез тестване на черна кутия
Въпреки че грешките и бъговете не са всичко в процеса на тестване с черна кутия, те са значителна част от начина, по който компаниите извършват тестването.
Познаването на някои от основните видове грешки и бъгове при тестването “черна кутия” може да ви помогне да категоризирате всички проблеми, на които се натъквате, и да разберете по-добре причините за възникването им.
Някои от основните видове грешки и недостатъци, които могат да бъдат открити чрез тестване на черната кутия, включват:
1. Грешки в ползваемостта
Грешките в ползваемостта се отнасят до недостатъци в програмата, които всъщност не засягат функционалността, но могат да причинят проблеми на потребителя, който се опитва да взаимодейства със софтуера.
Например, ако дадено приложение има сериозен графичен дефект, то все още функционира технически, но без подходящите икони и текст крайният потребител не може да го използва ефективно. Тези проблеми обикновено са свързани с дизайна на приложението и начина, по който дизайнът се зарежда за потребителя, като по-сложните приложения изискват повече графики, които са по-сложни от тези в по-простите потребителски интерфейси.
2. Функционални грешки
Функционалните грешки се отнасят до проблеми, които възникват, когато дадена част от програмата не работи според очакванията.
Например, ако използвате софтуер за бази данни и се опитвате да сортирате информацията по определена категория, но не успявате да го направите. Това се отнася както за функции, които изобщо не работят, така и за такива, които изглежда, че работят, но го правят неправилно.
Това могат да бъдат едни от най-сериозните проблеми за дадено приложение, които причиняват значителни неудобства на потребителите и влошават репутацията на разработчика, тъй като продуктът не работи, както е обявено.
3. Катастрофи
Когато даден софтуер се срине, това означава, че има фундаментален проблем в софтуера, който не му позволява да работи. Има няколко различни форми на сривове, които могат да възникнат, включително когато дадено приложение се затваря изцяло или просто замръзва в даден момент от процеса.
Сривът е един от най-сериозните проблеми, които могат да възникнат, тъй като не съществува начин за възстановяване на функционалността на приложението, освен пълното му затваряне и повторно отваряне. Въпреки че някои приложения все още имат процеси във фонов режим, няма начин да взаимодействате със софтуера след този момент.
Общи показатели за изпитване на черна кутия
Ръчното тестване на черна кутия е отлично за генериране на качествени данни, но когато се фокусирате върху количествени данни, трябва да сте наясно с показателите, които проверявате. Пълното разбиране на тези показатели ви помага да разберете недостатъците на платформата и да определите приоритетите в различните области, върху които да работите.
Някои от най-често срещаните показатели за тестване на черна кутия, които можете да откриете в работата си, включват:
1. Степен на грешка
Процентът на грешките може да се отнася до няколко неща – или до чистия брой грешки, които се появяват по време на цикъла на тестване на софтуера, или до грешките, които се появяват за един час тестване. Почасовите показатели са по-добри, тъй като представят плътността на грешките в софтуера, а не просто число, което може да бъде погрешно представено при по-големи приложения.
Разработчиците се стремят да ограничат процента на грешките в своите приложения, тъй като колкото по-малко грешки има в софтуерния пакет, толкова по-добър ще бъде опитът на клиента при използването на системата.
2. Време за реакция
Когато тестващият иска да разбере повече за нивото на производителност, с което се сблъсква потребителят, времето за реакция е един от основните аспекти, които трябва да се вземат предвид. Това се отнася до времето, което е необходимо на софтуера да изпълни дадена задача, след като потребителят въведе подкана, като по-дългото време за реакция показва относително неефективно приложение. По-голямото време за реакция е причина за безпокойство, тъй като потребителите могат да загубят търпение към приложение, което отнема твърде много време.
3. Удовлетвореност на потребителите
Повечето метрики се фокусират върху чистите числа, които се генерират от софтуерния пакет и софтуера за тестване при теста, но някои метрики се фокусират върху мнението.
Ако например дадена компания проведе бета тест с участието на 1000 тестери, тя може да събере данни за броя на удовлетворените лица и да ги превърне в процент. Това е изключително полезен показател в края на цикъла, тъй като по-високият процент на удовлетвореност на потребителите показва, че програмата се харесва на повече хора и че е по-вероятно тя да се развива добре в бъдеще.
Най-добрите инструменти за тестване на черна кутия
Тестването в черна кутия е вид тестване, което може да разчита значително на наличието на инструменти, както за автоматизиране на тестването в черна кутия, така и за организиране на информацията, получена от тестовете.
Използването на правилната комбинация от инструменти може да помогне на вас и вашия екип да работите много по-ефективно и да изградите по-ефективни процеси в целия отдел за осигуряване на качеството.
Вижте някои от най-добрите инструменти за тестване на черна кутия по-долу и научете как точно всеки от тях може да ви помогне да постигнете успех:
5 най-добри безплатни инструмента за тестване на черна кутия
Малките и нововъзникващите компании, като например независимите разработчици, не разполагат с голям бюджет, с който да работят при създаването на своя софтуер. Това може да доведе до редица предизвикателства, включително намирането на подходящи инструменти за работа.
По-долу са изброени някои от най-добрите безплатни инструменти, достъпни за независими разработчици, които искат да подобрят работните си процеси с ограничен бюджет:
1. ZAPTEST БЕЗПЛАТНО ИЗДАНИЕ
Безплатното издание на ZAPTEST е идеалното въведение в автоматизацията на софтуерни тестове. Този инструмент е специално разработен за автоматизиране на всякакви задачи, като ви помага да работите по-бързо и ефективно, независимо от задачата, която изпълнявате.
Безплатната версия на ZAPTEST разполага с огромно количество функционалност, която подпомага автоматизацията на всяко приложение… 1SCRIPT изпълнение между браузъри, устройства, приложения и паралелно изпълнение са само част от наличните функции.
2. JIRA
Безплатните издания на JIRA са идеални инструменти за записване на грешки, добавяне на подробности към тях в талони и определяне на приоритетите им при комуникация с екипа за разработка.
Въпреки това, вместо да бъде универсален помощник за автоматизация, той е специализиран изключително в управлението на проекти в процеса на тестване.
3. Selenium IDE
Това е приложение с отворен код, което записва и възпроизвежда автоматизация на тестове, и е добър инструмент за проверка на това, което платформата за автоматизация вижда при завършване на тест.
Един от недостатъците на Selenium е относителната липса на усъвършенствани функции, като например междуплатформена интеграция на автоматизирани задачи.
4. AutoHotkey
AutoHotkey е напълно безплатен език за писане на скриптове с отворен код, достъпен за Windows, който помага на потребителите да създават скриптове с различни размери, които изпълняват серия от задачи след въвеждане на едно натискане на клавиш.
Въпреки че е добър за автоматизиране на прости задачи, AutoHotkey може да започне да се справя с някои по-големи скриптове и изисквания за автоматизация.
5. Appium
Инструмент, който се отличава предимно с автоматизиране на приложения за iOS, е идеална програма за използване, когато искате да подобрите качеството на мобилните си приложения.
Най-големият недостатък на Appium е фактът, че сте ограничени до много малък набор от продукти, което значително намалява наличния ви пазар.
5 най-добри инструмента за тестване на черна кутия на предприятието
Безплатните инструменти са много добри, но предприятията и големите компании се нуждаят от повече функции, за да могат да тестват обстойно своя софтуер. За щастие, някои от най-добрите инструменти за тестване на черни кутии в предприятията имат всеобхватна функционалност и помагат на фирмите да получат значителна възвръщаемост на инвестициите в процесите за осигуряване на качеството.
Някои идеални инструменти за тестване на черната кутия на предприятието, в които да инвестирате, включват:
1. ZAPTEST ENTERPRISE EDITION
Изданието Enterprise на ZAPTEST е един от най-значимите инструменти за автоматизация на пазара и може да осигури до 10 пъти възвръщаемост на инвестициите във вашия продукт.
Функции като достъп до експерт на ZAP на пълно работно време като отдалечена част от вашия екип и неограничени лицензи гарантират, че можете да внедрите автоматизация на тестове с черна кутия без нужда от стръмно обучение и на фиксирана цена, независимо от това колко бързо растете.
2. TestRail
TestRail е платформа, фокусирана върху тестването в реално време, с цел да свърже тестовете ви с цялостна платформа за управление на проекти. Макар че това е идеално за централизиране на работата по управление на екипа, функциите за автоматизация далеч не са идеални за екип от разработчици, който иска да наблегне на автоматизираните тестове.
3. Opkey
Opkey е платформа, която се фокусира върху автоматизацията без код, което означава, че хора без технически познания могат да започнат да автоматизират услугите си за тестване.
Един от основните недостатъци на Opkey е липсата на активна общност около софтуера, което може да ви накара да се чувствате сравнително безпомощни, когато се опитвате да автоматизирате по нов за вас начин.
4. Perfecto
Perfecto е инструмент, който помага на потребителите да автоматизират мобилни приложения без сериозни проблеми, като работи с широк набор от устройства и се фокусира върху работата по тестване от край до край.
Приложението обаче работи на реални устройства, а не на виртуални машини, което добавя още един голям разход към и без това сравнително скъпия инструмент за тестване за ограничени платформи.
5. JIRA Enterprise
Освен завършването на автоматизацията на тестването, управлението на проектите продължава да бъде важно и тук се намесва JIRA. Enterprise JIRA има повече място за съхранение и позволява на повече потребители да имат достъп до платформата, но може да предизвика потенциално объркване с необходимостта от индивидуални разрешения и достъп за всеки отделен потребител. Това отнема много административно време.
Кога трябва да използвате
Инструменти от черната кутия на предприятието срещу безплатни инструменти?
Като начало по-голямата част от компаниите ще използват безплатни инструменти от типа “черна кутия”. Това е логично от икономическа гледна точка, тъй като никой интелигентен бизнес не иска да инвестира в продукт, който не разбира напълно, независимо дали става въпрос за управление на проекти или за автоматизация.
Инструментите с безплатен достъп не включват само напълно безплатни приложения, но могат да включват и безплатни версии на корпоративни продукти, които компанията използва, когато се учи как да внедри инструмента в своите процеси.
Идеалният момент, в който една организация може да актуализира своя избор на инструмент с корпоративно издание, е когато компанията започне да изпитва затруднения в процесите на тестване поради използването на безплатния инструмент. Независимо дали става въпрос за безплатен инструмент, който предлага само определен брой лицензи, или за количество тестове, в момента, в който започнете да изпитвате неефективност в процесите си в резултат на инструментите за тестване, трябва да преминете към корпоративна версия, която отговаря на всичките ви нужди.
Контролен списък за тестване на черна кутия, съвети и трикове
Тъй като тестването в черна кутия е изключително сложен метод за тестване с много възможности за натрупване на знания за даден софтуерен пакет, има няколко неща, на които трябва да обърнете внимание.
Някои важни съвети и трикове, които трябва да включите в контролния си списък за тестване на черна кутия, включват:
– Разбиране на заданието
Преди да започнете да правите планове за тестване, уверете се, че сте разбрали по-широката информация за периода на тестване. Това включва разбиране на софтуера дотолкова, доколкото ви е позволено, и научаване на това, което точно трябва да тествате.
– Коригиране на тестовия случай
Опитайте се да накарате всички участници в тестването да оценят тестовите случаи, които използвате при тестването на черна кутия. Колкото повече очи видят тестовия случай преди изпълнението, толкова по-голям е шансът да се отстранят всички грешки.
– Подреждане на списък с нещата, които трябва да се свършат
Нетехническата страна на подготовката за тестване на черна кутия може да бъде също толкова важна, колкото и техническата. Когато планирате, създайте последователен Списък на нещата, които трябва да се свършат, в който се определя кой коя част от софтуера ще тества в определено време. Това намалява объркването, потенциалното прегаряне и забавянията поради поемането на други задачи.
– Незабавно записване на резултатите
Незабавно запишете всички резултати, които генерира даден тест. Ако чакате твърде дълго при ръчните тестове, можете да не запомните правилно проблемите, така че воденето на незабавни бележки увеличава значително точността.
– Свързване с разработчици
Обсъдете с разработчиците сроковете и стратегията си за тестване, за да разберат какво се случва и кога могат да очакват работа по новите актуализации. Това включва установяване на ясни процедури, чрез които отделите да комуникират помежду си.
– Данни, които могат да бъдат използвани
Когато пишете доклад, уверете се, че всички данни, които предоставяте на разработчика, са приложими. Това помага на екипа да разработи продукт, който отговаря на неговите проблеми, а не разработчикът да не разбира промените, които трябва да направи.
– Разберете приоритетите си
Като екип за тестване вашият приоритет е да гарантирате, че компанията предоставя на своите потребители висококачествен продукт. Ако тестването отнема малко повече време от очакваното, не забравяйте, че това е полезна размяна за повишеното качество, което ще изпита клиентът.
– Познаване на йерархията
В една идеална компания за разработка разработчиците и тестерите са на едно и също ниво в йерархията и имат еднакво важна роля в развитието на софтуера. Разберете какъв е начинът на йерархия във вашата организация и се опитайте да се уверите, че всички разбират стойността на доброто тестване.
– Водете последователна документация
Съхранявайте копия на всички данни и отчети, които генерирате по време на тестването. Можете да проследявате промените в приложението, за които отговаря екипът по тестване, както и да преглеждате стари грешки, за да видите дали те се повтарят в бъдещи издания.
Заключение
Тестването на “черната кутия” в крайна сметка е една от най-важните части от процеса на тестване на софтуера. Той помага на компаниите да се уверят, че това, което доставят, е на възможно най-високо ниво, и използва промяната в перспективата, за да предложи уникална информация за начина, по който дадено приложение се възприема и прилага от външен потребител.
Всяка компания, която не добави към процесите си автоматизирано и ръчно тестване на черната кутия, пропуска възможността да подобри значително качеството на своето приложение. Тествайте интелигентно и ще получите плодовете, когато клиентите ви получат достъп до вашия продукт.
Често задавани въпроси и ресурси
Независимо от това колко много знаете за тестването “черна кутия”, може да имате още въпроси и да искате да задълбочите познанията си за метода. Вижте нашите често задавани въпроси по-долу, за да научите повече за тестването на черната кутия и да получите достъп до редица ресурси, които могат да ви разкажат повече за методологията.
1. Най-добрите курсове по автоматизация на тестовете на черната кутия
Съществуват няколко курса за автоматизация на тестове с черна кутия, които можете да следвате, като всеки от тях помага на хората да постигнат различен стандарт на тестване.
Някои от най-високо оценените курсове за тестване на черна кутия включват:
– “Тестване в черна и бяла кутия” от Coursera
– “Серията за тестване на софтуер Black-Box” на BBST
– “Въведение в техниките за тестване на софтуер в черна кутия” от Udemy
– “Софтуерно автоматизирано тестване” от London School of Emerging Technology
– “Три ключови техники за тестване на черната кутия” от Udemy
2. Кои са 5-те най-важни въпроса за интервюта за тестване на черна кутия?
Софтуерното тестване е силно конкурентна област, в която за всяко свободно работно място кандидатстват много кандидати. Ако получите интервю за позиция в областта на тестването на черна кутия, това са някои от въпросите, на които може да се подготвите да отговорите по време на интервюто:
– Какъв опит имате в работата с тестване на черна кутия?
– Какви са основните разлики между тестването в черна и бяла кутия?
– Имате ли опит с автоматизация на софтуера в предишните си роли?
– Можете ли да ни разкажете за момент, в който сте се сблъскали с предизвикателства на работното място, и как сте ги преодолели?
– Какво според вас е бъдещето на тестването на черна кутия и как уменията ви отговарят на дългосрочната кариера в областта на тестването на софтуер?
3. Най-добрите уроци от Youtube за тестване на черната кутия
YouTube е един от най-важните учебни ресурси, достъпни за хората, които развиват уменията си за тестване на софтуер, тъй като предоставя безплатен източник на информация, която можете да използвате, за да развиете техниката си.
Някои от най-добрите уроци, които можете да гледате, когато изучавате тестване на черна кутия, са:
– “Въведение в тестването на черна и бяла кутия – Georgia Tech – Процес на разработка на софтуер” от Udacity
– “Black Box and Glass Box Testing” от MIT OpenCourseWare
– “7 техники за тестване на черната кутия, които всеки QA трябва да знае” от The Testing Academy
– “Тестване на черна кутия | Какво е тестване на черна кутия | Научете тестване на черна кутия” от Intellipaat
– “Какво представлява тестването на бялата и сивата и черната кутия?” от ITProTV
4. Как да поддържаме тестовете “черна кутия”?
Поддържането на тестове на черната кутия, независимо дали става въпрос за ръчни или автоматизирани тестове, е въпрос на внимание към тестовете в хода на тяхното изпълнение и постоянно търсене на поправки, ако има проблеми.
Това означава да се уверите, че всички тестови случаи се изпълняват според очакванията ви всеки път, и да проверите дали автоматизираните инструменти преминават през всички правилни стъпки. Правете това колкото е възможно по-често, за да предотвратите понижаването на стандартите си, тъй като добре поддържаният тест на черната кутия е този, който дава възможно най-точни резултати.
5. Най-добрите книги за тестване на черната кутия
Въпреки че тестването на черна кутия и тестването на софтуер като цяло е постоянно развиваща се област, има няколко книги, които остават актуални и предлагат много информация за подобряване на работата ви по тестване.
Някои от най-добрите книги за тестване на черна кутия включват:
– “Тестване на черната кутия: Техники за функционално тестване на софтуер и системи” от Борис Байзер
– “Тестване на софтуер: Принципи и практика” от Srinivasan Desikan, Gopalaswamy Ramesh
– “Основи на софтуерното тестване” от Ralf Bierig, Stephen Brown, Edgar Galván
– “Въведение в софтуерното тестване” от Пол Амман, Джеф Офът
