Какво е вградено тестване в софтуерното тестване?
Томас Хамилтън
Какво представляват вградените системи?
Вградените системи са електронно управлявани устройства, при които софтуерът и хардуерът са тясно свързани. Вградените системи могат да съдържат различни изчислителни устройства. Това са персонални компютри, включени в други устройства за работа със специфични за приложения функции. Крайният потребител обикновено дори не знае за тяхното съществуване.
Вградено тестване
Вградено тестване е процес на тестване за проверка на функционални и нефункционални атрибути на софтуера и хардуера във вградена система и гарантиране, че крайният продукт е без дефекти. Основната цел на вграденото тестване е да провери и валидира дали крайният продукт от вграден хардуер и софтуер отговаря на изискванията на клиента или не.
Тестването на вграден софтуер проверява и гарантира, че съответният софтуер е с добро качество и отговаря на всички изисквания, на които трябва да отговаря. Тестването на вграден софтуер е отличен подход за гарантиране на сигурността в критични приложения като медицинско оборудване, железопътен транспорт, авиация, автомобилна индустрия и т.н. Стриктното и внимателно тестване е от решаващо значение за предоставяне на софтуерен сертификат.
Как да извършите тестване на вграден софтуер
Като цяло тествате по четири причини:
- За намиране на грешки в софтуера
- Помага за намаляване на риска както за потребителите, така и за компанията
- Намалете разходите за разработка и поддръжка
- За подобряване на производителността
Във вграденото тестване се извършват следните дейности:
1. Софтуерът се предоставя с някои входове.
2. Част от софтуера се изпълнява.
3. Наблюдава се състоянието на софтуера и изходните данни се проверяват за очаквани свойства, като например дали изходът съответства на очаквания резултат, съответствие с изискванията и липса на системни сривове.
Типове тестване на вграден софтуер
По принцип има пет нива на тестване, които могат да бъдат приложени към вграден софтуер
Тестване на софтуерни единици
Единичният модул е функция или клас. Единичното тестване се извършва от екипа за разработка, предимно от разработчика, и обикновено се извършва в модел за партньорска проверка. Въз основа на спецификацията на модула се разработват тестови случаи.
Тестване на интеграцията
Интеграционното тестване може да се класифицира в два сегмента:
- Тестване на софтуерната интеграция
- Тестване на софтуерна/хардуерна интеграция.
В крайна сметка се тества взаимодействието на хардуерния домейн и софтуерните компоненти. Това може да включва изследване на взаимодействието между вградени периферни устройства и софтуер.
Разработката на вграден софтуер има уникална характеристика, която се фокусира върху действителната среда, в която се изпълнява софтуерът, обикновено се създава успоредно със софтуера. Това причинява неудобство за тестване, тъй като цялостното тестване не може да се извърши в симулирани условия.
Тестване на системния модул
Сега модулът, който ще се тества, е пълна рамка, която се състои от пълен софтуерен код, освен всички операционна система в реално време (RTOS) и елементи, свързани с платформата, като прекъсвания, механизми за задачи, комуникации и т.н. Протоколът Point of Control вече не е извикване на функция или извикване на метод, а по-скоро съобщение, изпратено/получено, използвайки опашките за съобщения на RTOS.
Системните ресурси се наблюдават, за да се оцени способността на системата да поддържа изпълнение на вградена система. За този аспект, тестване в сивата кутия е предпочитаният метод за тестване. В зависимост от организацията, тестването на системния модул е или задължение на разработчика, или на специален екип за системна интеграция.
Тестване на системната интеграция
Модулът, който ще се тества, започва от набор от компоненти в рамките на един възел. Точките за контрол и наблюдение (PCOs) са комбинация от свързани с мрежата комуникационни протоколи и RTOS, като например мрежови съобщения и RTOS събития. В допълнение към компонент, виртуалният тестер може също да играе ролята на възел.
Тестване за валидиране на системата
Модулът, който ще се тества, е подсистема с цялостна реализация или пълна вградена система. Целта на този финален тест е да се изпълнят функционалните изисквания на външен обект. Обърнете внимание, че външен обект може да бъде или човек, или устройство в телеком мрежа, или и двете.
Разлика: Вградено тестване и Тестване на софтуер
| Тестване на софтуер | Вградено тестване |
|---|---|
| Софтуерното тестване е свързано само със софтуера. | Вграденото тестване е свързано както със софтуер, така и с хардуер. |
| Средно 90% тестове, извършени в света, са чисто ръчни тестове с черна кутия. | Вграденото тестване се извършва на вградени системи или чипове и може да бъде тестване с черна кутия или бяла кутия. |
| Основните области на тестване са GUI проверки, функционалност, валидиране и известно ниво на тестване на база данни. | Основните области на тестване са поведението на хардуера за no. на входовете, дадени му. |
| Софтуерното тестване се извършва предимно на клиент-сървър, уеб и мобилни приложения. | Вграденото тестване обикновено се извършва на хардуера. |
| например Google Mail, Yahoo Mail, Android приложения. | напр. Машини от областта на здравеопазването, Микроконтролери, използвани в компютри. |
Предизвикателства: Тестване на вграден софтуер
Някои от предизвикателствата, с които човек може да се сблъска по време на тестването на вграден софтуер:
Хардуерна зависимост
Хардуерната зависимост е сред основните трудности, срещани по време на тестване на вграден софтуер поради ограничения достъп до хардуер. Емулаторите и симулаторите обаче може да не представят точно поведението на действителното устройство и могат да дадат грешна представа за производителността на системата и използваемостта на приложението.
Софтуер с отворен код
По-голямата част от вградените софтуерни компоненти са с отворен код по природа, не са създадени вътрешно и липсва пълен тест за тях. Има широк набор от тестови комбинации и произтичащи сценарии.
Софтуер срещу хардуерни дефекти
Друг аспект е, че когато софтуерът се разработва за прясно създаден хардуер, по време на този процес може да се идентифицира голям процент хардуерни дефекти. Откритият дефект просто не се ограничава до софтуера. Може да е свързано и с хардуера.
Възпроизводими дефекти
Дефектите са по-трудни за възпроизвеждане/пресъздаване в случай на вградена система. Това принуждава вградената процедура за тестване да оценява всяка поява на дефект значително по-високо, отколкото в стандартен случай, освен да събере толкова много данни, колкото е разумно необходимо, за да се промени системата, за да се намери основата на дефекта.
Непрекъснати софтуерни актуализации
Вградените системи изискват редовни софтуерни актуализации, като надграждане на ядрото, корекции на защитата, различни драйвери на устройства и т.н. Ограниченията, идентифицирани с влиянието на софтуерните актуализации, затрудняват идентифицирането на грешки. Освен това увеличава значението на процедурата за изграждане и внедряване.
Oбобщение
Има някои трудности при тестването на тестването на вграден софтуер, което го прави по-трудно от редовното тестване на софтуер. Най-фундаменталният проблем е тясната зависимост от хардуерната среда, която се подготвя едновременно със софтуера и която редовно се изисква за извършване на надеждно софтуерно тестване. Понякога дори е трудно да се тества софтуерът без персонализирани инструменти, което без усилие прави концентрирането върху тестването в късните етапи изключително привлекателно.
Едно от най-важните неща, за което трябва да помислите, е фактът, че често трябва да избирате автоматизирано софтуерно тестване. Вграденото автоматизирано тестване е по-бърз процес, който ще отнеме няколко часа и по този начин проблемът с вашия софтуер е решен.
