Определение на теста за приемане. Разработване на документация, производство и тестване на прототипи. Набор от стандарти за автоматизирани системи

Обикновено това тестване се извършва от друг екип, който повтаря много от това, което е обхванато от автоматичното тестване за приемане ръчно или с друг инструмент. Това може да се направи, защото тестовете за приемане не могат да се изпълняват лесно в различни среди или екипът за разработка не може лесно да разбере какво правят тестовете, а използваните данни са скрити в кода, което затруднява намирането или промяната. Скриването на целта на теста в код затруднява разбирането какво се опитва да направи тестът.

Това също така означава, че нетехническите членове на екипа не могат лесно да допринесат за тестването и техническите хора отделят повече време за автоматизиран тестов код. Когато тестовете трябва да бъдат рефакторирани, което е неизбежно, тъй като те отделят намерението от средствата за изпълнение, можете да се съсредоточите върху рефакторинг на изпълнението на теста, а не върху това, което тестът трябва да направи.

Разделяне на намерение, изпълнение и данни

По-долу е дадена диаграма, илюстрираща идеята за разделяне на намерение, изпълнение и данни. Средата също е включена, тъй като е важно да се разбере в каква среда ще се изпълняват тестовете и, ако е необходимо, да промените данните и да стартирате теста. Създаването на намерение може да се извърши от нетехнически членове на екипа на език, който е независим от изпълнението. Това е важно, защото означава, че реализацията може да бъде рефакторирана, без да се налага да се променя целта на теста. Обратното също е вярно; възможно е да се промени намерението на теста, без да се засяга изпълнението, при условие че има реализация, която удовлетворява всички думи в параграфа за намерение.

Ако в най-лошия случай решите да изхвърлите цялата реализация и да започнете отначало, все пак можете да запазите намерението на теста и следователно да не загубите най-важната част от автоматизираните тестове, какви тестове се опитват да направят. Данните също трябва да бъдат разделени на намерения и реализации, като по този начин данните могат да бъдат посочени в теста чрез абстракция и след това реализацията се премахва. Например, тест може да показва, че „Gold Client“, тъй като клиентът е идентифициран, не е част от теста, но е част от слоя данни.

Създаването на слой данни и абстракцията на данни не са нови техники; те обикновено се използват за код на приложението и трябва да се прилагат към автоматизирани тестове, тъй като ползите все още са валидни. В тестовия случай слоят данни се извиква, за да извлече данни от източника на данни за съответния тип клиент.

След това тестовият случай преглежда всички записи в списъка и извършва тест за всеки клиентски запис. Системните тестове отговарят на едно от нивата на софтуерно тестване, комбинирано с различни тестове като възстановяване, сигурност, устойчивост, производителност, свързаност, обем, напрежение, наличност на данни, лекота на използване, работа, Заобикаляща среда, съхранение, конфигурация, инсталация и документация. Всеки има различна цел и има обща цел, която демонстрира системната визия на проекта. Тестването за приемане е друг тип ниво, което се допълва от нива на тестване на софтуера, тези тестове са много фундаментални, тъй като те са тези, които ще ни позволят да получим продукт, който отговаря на изискваните стандарти и който същевременно удовлетворява изискванията на потребителите в съответствие с изисквания, които те повдигнаха от самото начало. Това принуждава системата да тества жизненоважния процес на тестване, тъй като по отношение на продукта, броя на грешките и сериозността на тези грешки, това е стъпката в разработката, която обикновено е предразположена към повечето грешки. Фигура 1: Проверка на итеративни системи Системните тестове не са процеси за проверка на функционалността на системата или пълна програма, тъй като би било излишно с процеса на функционален тест. Системните тестове имат специфична цел: да сравнят система или програма с нейните първоначални цели. За тази цел са представени две стойности. Системното тестване не се ограничава до системи. Ако продуктът е програма, системното тестване е опит да се демонстрира как програмата напълно не отговаря на своите цели или изисквания. Системните тестове по дефиниция не са възможни, освен ако няма писмени изисквания, които са измерими за продукта. Системното тестване е фазата на изследване, в която се гарантира, че всеки компонент или модул взаимодейства с други компоненти или модули, както е предвидено. Системните тестове са насочени към дълбоко внедряване на системата, проверка на интеграцията на информационна система по света, проверка на правилното функциониране на интерфейсите между различните подсистеми, които я изграждат, и с други информационни системи, с които комуникира. Класическият проблем на системния тест е "соченето с пръст". Това се случва, когато бъде открита грешка и разработчикът на всеки системен елемент обвинява другите. Вместо да изпада в този абсурд, софтуерният инженер трябва да предвиди възможни проблемис интерфейс:  път за обработка на грешки при проектирането, който проверява цялата информация, идваща от други елементи на системата. Системно тестване и тестване 6  Приложете серия от тестове, които симулират лоши данни или други възможни грешкив софтуерния интерфейс.  Регистрирайте резултатите от теста като доказателство в случай на вина.  Участвайте в планирането и разработването на системно тестване, за да гарантирате, че софтуерът е тестван правилно. Всъщност системният тест обхваща серия от различни тестове, чиято основна цел е дълбоко изчисление на системата по време на изчисление. Въпреки че всеки тест има различна цел, всички те работят, за да се уверят, че всички елементи на системата са правилно интегрирани и че изпълняват съответните функции. 2 Системен преглед на теста. Когато трябва да се извърши тестване, е необходимо да се поддържа система, тоест интегрален подход към разработката на софтуер. Прилагането на тези концепции към софтуерен тест дава набор от принципи, които ще послужат като основа за теста: трябва да сте сигурни, че знаете точно целите на тествания софтуер, както и вашия процент на успех. Тези елементи се намират в документите, получени по време на фазата на събиране на изискванията, както и в спецификациите на софтуера. Тази информация ще е необходима за изготвяне на тестовия план и ще формира основата за започване на разработване на тестов случай. Входовете и изходите на одобрената система трябва да бъдат определени. Този аспект е необходим при подготовката на тестови случаи, както и при създаването на тестови процедури, особено ориентирани към тестове, които показват изпълнението на целите. Помислете за основната система, на която се изпълнява тестваният софтуер. Обикновено това е организационна среда, която се състои от хардуер, софтуер и хора. Всички тези елементи оказват голямо влияние върху системата и особено помагат при подготовката на тестови случаи на нежелани ситуации, свързани с неадекватни данни, липса на необходими елементии появата на изключения. 3 Общ преглед на системното тестване Процесът на тестване на системата се състои от две фази, които могат да бъдат много отделни във времето: подготовка на теста и прилагане на теста. Първият е тясно свързан с изискванията, така че се случва в началото на проекта, а вторият изисква пълната система или поне една интеграция, тъй като се казва, че частичният продукт не е пуснат, за да може да прилага тестове, така че това се случва в напредналите етапи на проект. Точното положение с тези части зависи от избрания модел. жизнен цикъл. За извършване на втората и третата дейност е необходим документ с изисквания. Първата фаза на тестване предоставя обратна връзка за анализиране на изискванията, идентифициране на пропуски, неясноти и други проблеми. Той също така предоставя ценни съвети относно проектирането и внедряването на системата, ако тепърва разработвате такава. Фазата на тестово приложение изисква тестов план и изпълнима версия на системата. В този случай подготвените тестови случаи ще бъдат приложени, резултатите ще бъдат анализирани и всички дефекти ще бъдат идентифицирани. Тази втора стъпка предоставя обратна връзка за внедряването и дизайна, показвайки възможни дефекти, които трябва да бъдат отстранени. Той също така предоставя информация, която ще бъде полезна при пускането на система, приемането й, оценката на нейната надеждност и поддържането й. Фигура 1 показва процеса на тестване на системата и връзката му с други процеси. Втората точка е важна, защото понякога системният тест се бърка с теста на интерфейса. Първият проверява взаимодействието на всички части, а вторият анализира елементите на интерфейса и евентуално обработката на свързани събития. Въпреки това инструментите, които помагат за тестване на интерфейса, могат да се използват за стартиране на системни тестове. Възникват няколко въпроса: колко случая ще са достатъчни? Как да генерираме възможно най-малко? Какви стойности са подходящи? Системно тестване и тестване 9 1 План за тестване Планът за тестване е много важен документпо време на тестване на софтуера. Обяснява целите и подходите към тестването, работния план, оперативните процедури, необходими инструментии отговорности. Тестване и тестване на системата 10 Документът с изискванията трябва да съдържа списък с функции, които трябва да се изпълняват от софтуера, като ги описва и приоритизира; трябва да включва и нефункционални изисквания, които могат да включват организационни, оперативни и други аспекти. Един добре подготвен документ с изискванията трябва да предоставя начин за всяко изискване да провери дали то е изпълнено. В случай на характеристики това би било описание, а в случай на нефункционални изисквания може да са много точни спецификации като време за реакция. Засега ще се съсредоточим върху функционалните изисквания, оставяйки останалото за следващ раздел. Системните тестове са важни поради следните фактори:  Това е системата, която се тества като цяло в рамките на жизнения цикъл на разработка на системата.  Системата се проверява за съответствие с нейните функционални и Технически изисквания .  Системата е тествана в среда, която е възможно най-близка до производствената среда.  Системните тестове ви позволяват да тествате, валидирате и валидирате както бизнес изискванията, така и архитектурата на приложението. 6Вид системни тестове. Функционални тестове  Тест за интеграция. - При което тестовото оборудване има достъп до изходния код на системата. Когато се открие проблем, интеграционният екип се опитва да намери източника на проблема и да определи компонентите, които трябва да бъдат отстранени. Тестването на интеграция се занимава основно с намиране на дефекти в системата.  Доказателство за доставка. Ето версията на системата, която може да бъде доставена на потребителя. Тук тестовият екип се занимава с проверка дали системата отговаря на изискванията й и гарантира надеждността на системата. Тестовете за доставка обикновено са тестване на черна кутия, при което тестовото оборудване просто се занимава с това дали системата функционира правилно. Компонентите, които могат да бъдат интегрирани, могат да бъдат търговски компоненти, компоненти за многократна употреба, пригодени за конкретна система, или новоразработени компоненти. За много големи системи те вероятно ще използват и трите типа компоненти. Тестът за интеграция потвърждава, че тези компоненти действително работят заедно, извиква се правилно и предава правилните данни в точното време през техните интерфейси. Системната интеграция включва идентифициране на групи от компоненти, които осигуряват някаква функционалност на системата и интегрирането им чрез добавяне на кодове за съвместна работа. Понякога първо се разработва скелетът на цялата система и се добавят компонентите. Това се нарича пост-интеграция. Това е възходяща интеграция. На практика за много системи стратегията за интеграция е комбинация от двете, добавяйки допълнителни инфраструктурни компоненти и функционални компоненти. И двата подхода на интеграция изискват допълнителен код за моделиране на други компоненти и да даде възможност на системата да стартира. Основната трудност, срещана по време на интеграционните тестове, е местоположението на грешки. Съществуват сложни взаимодействия между компонентите на системата и когато се открие аномален изход, може да е трудно да се определи къде е възникнала грешката. За да улесните изолирането на грешки, винаги трябва да използвате постепенен подход към системната интеграция и тестване. Основната цел на този процес е да се повиши увереността на доставчика, че системата отговаря на неговите изисквания. Ако е така, може да бъде доставен като продукт или доставен на клиент. За да се демонстрира, че дадена система отговаря на изискванията си, трябва да се докаже, че предоставя определената функционалност, производителност и надеждност и че не се проваля при нормална употреба. Тестовете за доставка обикновено са процес на тестване в черна кутия, при който тестовете се извличат от спецификацията на системата. Системата се разглежда като черна кутия, чието поведение трябва да се определя само чрез изследване на съответните й входове и изходи. Друго име за това е функционално тестване, тъй като тестерът се интересува само от функционалността, а не от внедряването на софтуера. На следващата фигура ще видим илюстрация на модела на системата, който позволява при валидиране на черна кутия. Тестерът представя входове към компонент или система и разглежда входовете. В някои случаи системата трябва да е устойчива на грешки; т.е. неуспехите при обработката не трябва да водят до откази на системата като цяло. Системи за изпитване и тестове за приемане 14 Неизправността на системата трябва да бъде коригирана в рамките на определен период от време или ще доведе до сериозни икономически щети. Тестът за възстановяване е системен тест, който кара софтуера да се провали по няколко начина и проверява дали възстановяването е извършено правилно. Ако възстановяването се случи автоматично, трябва да проверите дали повторното инициализиране, механизмите за архивиране на системата, възстановяването на данни и рестартирането са правилни. Ако възстановяването изисква човешка намеса, трябва да се определи средното време за възстановяване, за да се определи дали е в приемливи граници. Целта е да се установят крайни точки, където системата започва да работи под определените изисквания. Това не трябва да се бърка с теста за обем; високо напрежение е максималното количество данни или активност на кратко време. Аналогията би била да се оцени машинописецът. Ще бъде определен обемен тест, ако машинописецът е изправен пред чернова на голям доклад; стрес тестът ще определи дали машинописецът може да пише с индекс от 50 думи в минута. Нарушението включва широк спектър от дейности:  Хакер, който се опитва да влезе на игра. Тестът за сигурност потвърждава, че вградените в системата защитни механизми действително я защитават от неподходящи прониквания. „Системите трябва да бъдат тествани за сигурността на системата, за да бъдат имунизирани срещу челни атаки, но също и за тези, които правят флангове или отзад.“ По време на теста за сигурност всеки, който го приложи, играе ролята на лицето, което иска да влезе. Всичко това си заслужава! Трябва да опитате да получите пароли външни средства; може да атакува системата с помощта на специален софтуер, предназначен да заобикаля всяка защитена архитектура; той може да насити системата, като по този начин откаже услуга на другите; може да доведе до умишлени грешки в системата, за да се опитате да получите достъп по време на възстановяване: можете да преглеждате данните без защита, с идеята да търсите паролата за системата. Ако се отделят достатъчно време и ресурси, системата в крайна сметка ще стане добър тестза безопасност. Ролята на системния дизайнер е, че цената на прекъсването е по-голяма от цената на получената информация. Анализът на човешките фактори обаче остава изключително субективен проблем. Тестовите случаи имат за цел да покажат, че тези цели за съхранение не са открити. Често броят на възможните конфигурации е твърде голям, за да тествате всяка една, но ако е възможно, трябва да тествате програмата с всеки тип хардуерно устройство и с минималната и максималната конфигурация. Ако самата програма може да бъде конфигурирана да пропуска компоненти или ако може да работи на няколко компютъра, всяка конфигурация трябва да бъде тествана. Тестването на инсталационните процедури е важна част от процеса на тестване на системата. Това е особено вярно за системата автоматична инсталация включени в софтуерния пакет. Неправилно стартиран инсталатор може да попречи на потребителя да има успешен опит със системата. Първият опит на потребителя е, когато той или тя инсталира приложението. Един от начините да постигнете това е да използвате документацията, за да дефинирате изглед на предишни системни тестови случаи. Тоест, след като искате да разработите случай на претоварване, трябва да използвате документацията като ръководство за писане на действителния тестов случай. В допълнение, потребителската документация трябва да бъде обект на проверка за точност и яснота. Всеки от примерите, показани в документацията, трябва да бъде тестван и добавен към списъка със задачи и включен в програмата. Тестване и тестване на системата 17 операционна гледна точка, след приемането на системата в реалната среда и на базата на съответствие с определените нефункционални изисквания. Тестването на устойчивост е предназначено да противодейства на програми в необичайни ситуации. По същество човекът, който прави теста за устойчивост, ще пита. Колко далеч стигате, преди да се провали? Тестът за съпротивление провежда системата по такъв начин, че изисква необичайно количество, честота или количество ресурси. Например:  са разработени специални тестове, които генерират 10 прекъсвания в секунда, когато средната чаша е една или две.  Честотата на въвеждане на данни се увеличава с количество, което ще позволи отговори на функциите за въвеждане.  Стартирайте тестови случаи, които изискват максимална памет или други ресурси.  Тестовите случаи са предназначени за отстраняване на проблеми с управлението на паметта. Създават се тестови случаи, които причиняват прекомерно търсене на диск. Фигурата е пример за тест за устойчивост. Тестът за ефективност се прилага на всички етапи от процеса на тестване. Дори на ниво единица. Производителността на отделния модул трябва да бъде оценена по време на тестването. Въпреки това, само след като всички елементи на системата са напълно интегрирани, може да се постигне истинска производителност на системата. Тестовете за производителност често включват тестване на устойчивост и често изискват софтуерни и хардуерни инструкции. Тоест често е необходимо точно да се измери използването на ресурсите. Използвайки външни инструменти, можете редовно да наблюдавате интервалите на изпълнение, регистрираните събития и състоянието на хардуерните проби. Тези тестове се извършват така, че клиентът да потвърди, че системата е валидна за него. Детайлното планиране на тези тестове трябва да се извърши в началото на фазата на разработка с цел използването на резултатите като индикация за тяхната валидност: ако документираните тестове се извършват за удовлетворяване на клиента, продуктът се счита за правилен и следователно подходящ за въвеждане в експлоатация производство. 6 Тестовете за приемане2 са основно функционални тестове на цялата система и имат за цел да проверят дали установени изисквания . Изпълнението му е по избор за клиента, а в случай, че не са изрично посочени, се включват в системните тестове. Тоест, тестовете за приемане често са отговорност на потребителя или клиента, въпреки че всеки, който участва в бизнеса, може да ги извърши. Тестването за приемане изисква тестова среда, която представлява производствената среда. Тази фаза или ниво като отправна точка определя базовата линия за приемане на продукта, която вече е установена в средата за сертифициране. Тестване и приемане на системата 19 Фигура - Контрол на приемането. 1 Разглеждане на текущата ситуация при приемни тестове. Като част от тестовете трябва да проверим софтуера, един от най-важните е тестването за приемане. Това са тестовете, които се разработват от самия екип за разработка въз основа на функционалните изисквания, посочени във фазата на анализа, за да покрият целия спектър и да бъдат извършени от крайния потребител, но не всички, а няколко потребители имат значителен резултат, който дава валидност и съответствие с продукта, който им се доставя въз основа на първоначално договореното. В зависимост от сложността на изследваната система, независимо дали е разделена на модули и т.н. изпълнението на тези тестове се извършва по различни начини. Ако приложението беше разделено на модули, те биха се считали за подсистеми и биха били достатъчно сложни, за да могат да се обработват по различен начин, ще трябва да се провеждат различни сесии за тест за приемане. 2 Цел на теста за приемане Тестването за приемане има за цел да получи крайно приемане от клиента преди доставката на продукта, за да влезе в производство. Когато една организация е провела системни тестове и е отстранила повечето от нейните дефекти, системата ще бъде доставена на потребителя или клиента за одобрение. Целта на тестването за приемане е да се провери дали системата отговаря на очакваната производителност и позволява на потребителя на тази система да определи нейното приемане по отношение на нейната функционалност и производителност. Тестовете за приемане се определят от потребителя на системата и се подготвят от екипа за разработка, въпреки че окончателното изпълнение и одобрение зависи от потребителя. Валидирането на системата се постига чрез провеждане на тестове за черна кутия, които демонстрират съответствие и са включени в тестов план, който определя валидациите, които трябва да бъдат извършени, и свързаните с тях тестови случаи. Този план е предназначен да гарантира, че всички функционални изисквания, посочени от потребителя, са изпълнени, както и нефункционални изисквания, свързани с производителност, сигурност на системния достъп, данни и процеси, както и различни системни ресурси, 3 Генериране на тестване за приемане. Системата трябва да бъде приета от потребителя. Поради тази причина, въз основа на структурираните спецификации на системата, анализаторът създава набор от тестови случаи, които трябва да преминат задоволително. Тъй като тестовете за приемане могат да бъдат разработени успоредно с дейностите по проектиране и практика, нормално е тези дейности да бъдат инициирани от анализатора веднага щом дейността по структуриран анализ приключи. 4 Стратегии за тестване на приемане Ако системата е проектирана за масовия пазар, тогава не би било практично да се тества за отделни потребители или клиенти, в някои случаи не би било възможно. В тези случаи е необходима обратна връзка, преди продуктът да бъде пуснат за продажба. Често такива системи имат два етапа на тестване за приемане. Алфа и бета тестване Когато персонализиран софтуер е създаден за клиент, се извършват поредица от тестове за приемане, за да се позволи на клиента да тества всички изисквания. Изпълнява се от клиента на сайта за разработка. Софтуерът се използва естествено с разработчика като наблюдател на потребителя, заедно с грешки при регистрация и проблеми с използването. Алфа тестовете се провеждат в контролирана среда. Вие работите в контролирана среда и клиентът винаги има експерт, който да ви помогне да използвате системата. Разработчикът следи намерените грешки и проблеми с използването. Β-бета тестовете се провеждат след α-алфа теста и се разработват в клиентска среда. В този случай клиентът остава сам с продукта и се опитва да намери грешки, които информират разработчика. Те се извършват от крайните потребители на софтуера на работните станции на клиента. За разлика от алфа теста, разработчикът обикновено не присъства. По този начин бета тестът е приложение на софтуера на живо в среда, която не може да бъде контролирана от разработчика. Клиентът регистрира всички проблеми, възникнали по време на бета тестването и докладва на разработчиците на редовни интервали. 5 Входове, изходи, задачи и роли на теста за приемане. Спецификация на изискванията за влизане. Задачи Подгответе тестовата среда. Препоръчваме да имате специфична тестова среда за този тип тестване. Инсталиране в тестова среда. Системно тестване и тестване 22 Идентифицирайте тестовете, които трябва да се извършат. Възможните зависимости, които съществуват между тестовете, ще бъдат установени и редът или последователността, в която ще бъдат изпълнени тестовете, ще бъдат установени въз основа на тези зависимости. Получаване и записване на резултати. Поправени бъгове и бъгове. Повторете задачата, докато преминете всички тестове. Изготвяне на протокол за приемане от изпитване. Преглед на правилното изпълнение и резултатите от всички подадени тестове. Създаване на производствена база. Официално приключване на дейностите. Резултати от тестовете. Приет доклад за приемане на продукта. Ръководител проект. Фокусът върху тестването за приемане е свързан с опит да се затвърди мнението, че потребителят, интегриран в този етап, на ранен етап, би помогнал за подобряване на този процес във фазата на планиране и проектиране на теста, с последващи подобрения в много количествени и желани аспекти , като: Подобряване на качеството на интегрираната софтуерна защита. Минимизиране на разходите. Повишена надеждност в резултатите от проекта. При използване на софтуер с по-малко грешки се наблюдава повишаване на удовлетвореността на клиентите. Това подобрява ефективността на процеса на разработка. 7 Критерии за изпитване за приемане. Приемането на софтуера се постига чрез серия от тестове, които показват, че отговарят на изискванията. Планът за изпитване описва вида на теста, който трябва да се приложи, а процедурата за изпитване определя конкретните тестови случаи, както планът, така и процедурата са проектирани така, че да гарантират, че отговарят на всички функционални изисквания, че са постигнати всички поведенчески характеристики, всички изисквания за ефективност са изпълнени, документация е правилен и спазва всички изисквания за лекота на използване и други определени изисквания. 8 Инструменти за приемни тестове. Това позволява на клиентите, тестери и програмисти да знаят какво трябва да прави техният софтуер и автоматично да сравняват какво всъщност прави. Позволява ви да пишете тестове, които са лесни за четене и лесни за поддръжка. Тази дейност е известна като окончателен тест или тест за приемане. Това изисква въвеждането на данни от тестовете за приемане и интегрирана система, създадена по време на тази дейност. Тестът ще се проведе от член или отдел на потребителя или дори от независим отдел за контрол на качеството. Важно е да се отбележи, че е важно да се извършват дейности по контрол на качеството във всяка от предишните аналитични, проектни и внедрителни дейности, за да се гарантира, че те са извършени до подходящо ниво на качество. Това гарантира, че анализаторът произвежда спецификации за качество, че дизайнерът произвежда качествени проекти и че програмистът произвежда качествени програми за кодиране. В компютърните науки реализацията е техническа спецификация или алгоритми, като програма, софтуерен компонент или друга компютърна система. Много реализации се предоставят в съответствие със спецификация или стандарт. Обобщаваме предишната работа на авторите за получаване на тестови цели, които са отправна точка за разработване на автоматизирани тестове. В контекста на системното тестване от случаи на употреба, целта на тестването може да бъде изразена като случай на употреба. Този сценарий ще се състои от последователност от стъпки без възможна алтернатива и набор от тестови стойности и предпоставкии постконференции, свързани с този сценарий. За генериране на тестови сценарии първо се изгражда диаграма на дейността от главната последователност и грешките и алтернативните последователности на случая на използване. В диаграмата на дейностите действията, извършвани от системата, и действията, извършвани от участниците, са стереотипни. След това се извършва анализ на пътя и всяка пътека на диаграмата на дейността ще бъде сценарий на употреба и следователно потенциална цел за тестване. 2 Изпълнение на системни тестове. Архитектура за тестване на системата. Архитектурата за изпълнение и автоматично валидиране на системни тестове е показана на Фигура 7. Тази архитектура е подобна на архитектурата, необходима за автоматизиране на други типове тестове, като тестове за единици. Основната разлика е, че при единичен тест самият тест извиква изпълнимия код, докато функционалният тест на тестовата система и приемането на теста 27 изисква посредник, който знае как да манипулира външния му интерфейс. Изпълнение на тестови случаи. Тест-тест е реализацията на целта на тестването. Общото поведение за тестов случай е посочено в таблицата за поведение на общия тест. Всеки случай на употреба ще бъде свързан с тестов пакет. Този пакет ще съдържа тестове за всички сценарии на споменатия случай на употреба. Както може да се види от целите на теста, всяка стъпка трябва да бъде уточнена дали се изпълнява от участник или от изследваната система. Тази информация е много уместна при кодиране на методите за тестване на пакета. Всички действия, извършени от актьора, трансформират кода на тестовия код във взаимодействие между тестовия случай и системата. Системно тестване и тестване за приемане 29 Методологията за оперативна и категорийна променлива ще бъде приложена за определяне на необходимите стойности за изпитване. Идентифицирани са трима различни видовеоперативни променливи. Всеки тип ще бъде приложен по различен начин в тестовите случаи. Първият тип се състои от онези оперативни променливи, които показват прехвърлянето на информация към системата от външен обект. За всяка променлива от този тип ще бъде дефиниран нов клас, чиито обекти ще съдържат различни тестови стойности за тази променлива. Пример за този тип работна променлива е показан в казуса. Вторият тип се състои от онези оперативни променливи, които показват избор между множество опции, достъпни за външния участник. Вместо това такъв избор ще бъде реализиран директно като част от кода, който реализира взаимодействието между актьора и системата. Третият тип се състои от онези работни променливи, които показват състоянието на системата. За да приложите метода за настройка на тестовия случай, напишете необходимия код, за да зададете правилно стойността на оперативните променливи, които описват състоянията на системата, или за да проверите дали стойностите съвпадат. По същия начин методът break трябва да възстанови тези стойности до първоначалните им състояния. Освен това методът за проследяване трябва да изключи, ако е необходимо, информацията, въведена от тестовия случай в системата по време на изпълнението на тестовия случай. Няколко примера за оперативни променливи от този тип са показани в казуса. В този случай първото нещо, което трябва да направите, е да приложите видяното, за да получите набора от тестови цели от случая на употреба. След това се определят характеристиките на използвания тестов колан. Накрая прилагаме това, което видяхме предишни разделиза изпълнение на тестовия случай от тестовата цел. Тестваната система е идентифицирана на артефакти английски език, дотолкова доколкото испански език не се поддържа от използваните инструменти. Случаят на използване в таблица 2 описва въвеждането на нова връзка в системата. Като допълнение е показано и изискване за съхраняване на информация, описваща информацията, обработвана от всяка връзка. От случая на употреба и автоматично генерира набор от сценарии, които ще бъдат целта за тестване на споменатия случай на употреба. Като се има предвид, че случаят на използване има неограничен брой цикли с безкраен брой потенциални повторения, критерият за покритие, избран за получаване на пътища, е критерий 01, който проверява и тества тестовете на система 30, се състои в получаване на всички възможни пътища за повторение нито едно или еднократно всеки от бримките. Всички скриптове, получени по този критерий и преведени на испански, са изброени в таблицата. За този казус избрахме Сценарий 09, който е подробно описан в Таблица 5 за неговото прилагане. Тестване и тестване при тестване 31 Таблица Изисквания за информация за препратки. Можете също да приложите метода за разделяне на категории. Разделите за всяка от тези променливи са изброени в таблицата. Системно тестване и тестване 32 Таблица с променливи, дефинирани за случая на употреба. Тестване и тестване в тестване 33 Таблица с категории за идентифицирани променливи. Както е описано на фигура 7, тестът на сбруята е предназначен да симулира поведението на потребителя и да предлага набор от изявления за оценка на резултата. Този превод в момента се извършва ръчно и е показан в таблицата. Тестване и тестване на трансивъра 35 Фигура Реализация на тестовия случай. Превод в изпълним код на стъпки, извършени от потребителя в основния сценарий. Тоест, за да се уверите, че категориите съществуват и че няма обстоятелства, причиняващи грешка при възстановяване на категориите или вмъкване на нова връзка. Изпълнението на метода на прекъсване беше да се възстанови оригиналният набор от връзки, съхранени в системата. 2 Изпълнение на приемни тестове. Тестовете за приемане работят само с поддръжка на клиенти или поне прокси за клиента, за да определи критериите. Без критерии за приемане на драйвери, става трудно да се провери дали създавате правилния софтуер. Клиентът, заедно с всички членове на екипа за разработка, трябва да се съберат, за да дефинират системата по отношение на серия от „скриптове“, които описват какво трябва да прави системата и как трябва да го прави. Чрез създаването на тестове с ясни изисквания и критерии за одобрение е по-вероятно софтуерът да отговори на очакванията на клиентите. Това обаче означава, че някой ръчно проверява дали изискванията са изпълнени и дали приложението работи според очакванията. Тук идват автоматизираните тестове за приемане вместо изисквания в наследен документ, изискванията се дефинират като примери и сценарии, защитени в контрола на източниците с артефакти за внедряване и могат да се изпълняват по всяко време, за да се провери дали отговарят на изискванията и работят правилно. Можете да използвате същия подход за писане на тестове, но вместо да ги пишете в софтуер за управление на тестови случаи или електронна таблица, ги напишете директно в кода. Тестване и тестване на системата 37 1 Автоматично тестване за приемане. Следователно, първата стъпка при внедряването на всяка нова функционалност е да опишете вашите очаквания с тест. Други не са и намират, че се борят с контрола на процеса с течение на времето, особено с нарастването на доказателствата и гъвкавостта на тестването започва да се влошава. Подходът, управляван от тестове, се основава на това кои тестове трябва да ръководят разработването на софтуерен продукт. В индустриалните софтуерни продукти, когато се използват методи за инженеринг на изисквания, те се поддържат предимно от естествен език, което води до добре известното неудобство на двусмислието. Въпреки това, необходимостта от валидиране може да надвиши ползите, които може да предложи по-официална и строга спецификация на изискванията. Клиентът трябва да може да чете и разбира изискванията, за да може да се съгласи с тях. Най-популярните методи за дефиниране на изисквания са изброени в раздела Случаи на употреба и потребителски истории. Определянето на изискванията е ключът към привличането на клиента. Изисквания - целта на постигането, тоест това, което клиентът очаква от софтуерния продукт. Тестване и тестване на системата 38 роли, свързани със спецификация на изискванията и валидиране и тестване за приемане. Концепцията за изисквания се превръща в контейнер за тестове за приемане и това са тези, които заемат централно място като спецификация на всяко изискване. Помислете за изискването „Теглене на пари“ в контекста на банкомат. Типична описателна спецификация може да бъде следната: Клиентът трябва да може да тегли пари в брой от касата в избрани суми. Винаги получавайте разписка, ако на касата не е останала хартия. Когато става въпрос за предпочитан клиент, можете да се оттеглите повече париотколкото имате в акаунта си, но трябва да бъдете предупредени, че ще бъдете таксувани с процент. Клиентът трябва да може да анулира по всяко време, преди да потвърди оттеглянето. Сумите трябва да могат да се обслужват от сметките, които касиерът има към момента, а други суми не трябва да се приемат. Фигура - Алтернативи на спецификациите Фигура 10 показва някои алтернативи на спецификациите за това изискване. Иконите отразяват удобството на всяка спецификация. Може да е интересно да се разработи диаграма на последователност за дефиниране на всеки сценарий за изпълнение на изискване, но като цяло това не е подходящо поради Голям бройгенерирани диаграми. По-интересно е да се идентифицират сценариите, отколкото да се илюстрира всеки един в диаграма. Описанието на повествованието не е еднократно, поне за кратко определениеизисквания, който се фокусира върху дефинирането на включените понятия. Моделът на използване обаче не е подходящ за илюстриране на подробната структура на изискванията на софтуерен продукт в среда за дългосрочна поддръжка, тъй като средният софтуерен продукт може да има хиляди изисквания. Необходими са по-подходящи механизми за визуализиране и управление на много изисквания. Шаблоните са една от най-често използваните алтернативи за използване в случаи на употреба. Шаблоните са елегантни и осигуряват усещане за ред според спецификацията. Въпреки това, те обикновено са контрапродуктивни, тъй като са склонни да предоставят едно ниво на детайлна обработка за всички изисквания. В тези много прости случаи те включват неща, които са очевидни или неуместни, само за да покрият всички секции на шаблона. Когато изискването включва множество скриптове, опитът да се синтезират всички скриптове в шаблон обикновено води до объркващи спецификации. По този начин изискванията действат като контейнери за страната. В зависимост от изискването, други допълнителни форми на спецификация могат да бъдат полезни. Например диаграма на дейност, ако поведението, свързано с изискване, има алгоритъм, или диаграма на състоянието, ако поведението включва разрешаващи или деактивиращи действия според системни твърдения и тестове за приемане на системата. Съществена предпоставка е прагматизмът по отношение на спецификацията, който не изключва споделянето на алтернативи на спецификацията, но основният критерий трябва да бъде желанието да бъде печеливш и да допринася за поддържането на тази спецификация. От друга страна, по отношение на усилията за поддръжка, особено по отношение на последователността, важно е да не се използва прекомерно дублиране или дублиране на спецификации в различни средства представителство. Насочената графика е адекватно представяне за прецизиране на нивото. Тази графика ви позволява да визуализирате връзките и зависимостите на разлагане между изискванията. По този начин всеки възел е функционално или нефункционално изискване. Дъгите между възлите установяват връзки между родители и деца или връзки на зависимост „възли, засягащи възли“. По този начин, в горния пример, изискването „Теглене на пари“ може да бъде възел от структурата на изискванията. Връщане с въведеното от клиента количество. Няма налични билети. Няма хартия за получаване. Времето за комуникация с централната система е превишено. Уведомяване за вътрешните операции на касата. Изтече времето за започване на действие. Това може да е свързано с функционално или нефункционално изискване. Не е задължително и се използва за задаване на предварителни условия преди прилагане на тестови стъпки. Това са действията на взаимодействие на актьора със системата. Когато извършват множество действия, те могат да бъдат поставени в номериран списък. Това е ефектът от взаимодействията на актьорите. Всяко действие може да доведе до един или повече резултати. Важно е, че когато става въпрос за съобщения до потребителя, текстът е включен като част от очаквания изход, така че програмистът вече има тази информация, проверена с клиента. Това, както ще посочим по-долу, ще установи зависимостта между изискванията. Състояние Трябва да е нормален клиент. Стъпки  Опитайте се да възстановите сумата на нормален клиент и поискайте сума, надвишаваща баланса.  Очакван резултат. Тестване и приемане на системата 42  Показва се съобщението „Исканото количество надвишава текущото Ви салдо, въведете отново количеството“ и се връща в прозореца за въвеждане на количеството. Тестването за приемане ще ви помогне да потвърдите, че създавате приложението, което клиентът иска, докато автоматизирането на тези скриптове ви позволява непрекъснато да тествате приложението през целия процес на разработка и да ги използвате като част от вашия пакет за регресионно тестване, за да гарантирате, че бъдещите промени няма да нарушат текущите изисквания. Въпреки това, наличието на клиент, свързан със събирането на доказателства, особено автоматизирано тестване, представлява редица потенциални проблеми. Като цяло клиентите не са технически и са склонни да се дистанцират от самата разработка на софтуер. Клиентът може да предостави данни и примери, докато тестери или разработчици могат бързо да кодират скриптове и изпълними спецификации. Тестове за приемане на потребителския интерфейс В примерите тестовете за приемане се фокусираха върху бизнес логиката и обектите на домейна, за да се види дали логиката работи успешно. Но какво да кажем за това как потребителят взаимодейства с приложението? Тези тестове за приемане трябва да са там, за да тестват правилността на логиката от гледна точка на потребителя, а гледната точка на потребителя е потребителският интерфейс. Ако приложението има добро отделяне и добро разделяне на логиката от кода на потребителския интерфейс, това би трябвало да улесни прилагането на тестове. Ако тествате на това ниво, тестовете няма да се променят в потребителския интерфейс. Въпреки че тестването трябва да се фокусира единствено върху логиката, това не означава, че не трябва да преминавате тестове за приемане на целия потребителски интерфейс. Обичам да имам набор от тестове за дим, които са насочени към основен потребителски интерфейс" щастлив път". Те се фокусират върху частите на приложението, които потребителите най-вероятно ще използват, за да извлекат максимума от опита си. най-малко количествотестване. Ако се опитате да покриете всичко възможни начинии използването на потребителския интерфейс и ако потребителският интерфейс се промени, ще трябва да промените всички тестове. Например, ако тествате потребителския интерфейс за сайт за електронна търговия, пътят ще се радва да избере артикул, да го добави в количката, да го провери и да види потвърждение за покупка. Ако този сценарий се провали, наистина искате да разберете възможно най-скоро. За определени приложения, в зависимост от сложността и продължителността на живота, може да искате да имате повече тестове за приемане в потребителския интерфейс, за да сте сигурни, че имате повече доверие в слоя на потребителския интерфейс. Въпреки това, успешното тестване на потребителския интерфейс е труден въпроси нямам място да го покрия. Тестване и приемане на системи 43 3Интелигентни тестове. След като разкажете историята и сценариите в ясен и разбираем формат, следващата стъпка е да автоматизирате историята и скриптовете. Това им позволява да работят по време на разработката, за да проследяват напредъка и да улавят грешки в регресията. Заключения и препоръки. От друга страна, имаме системни тестове, които са отговорни за оценката на операцията през целия процес, за да се открият грешки, които могат да възникнат за това, е необходимо да се разработи стратегия с тестове и отделно разработване на код от разработването на интерфейс, така че най-добре е да се прилагат системни тестове. Изпълнението на тези два софтуерни теста трябва да се извърши със строги тестове, които отговарят на определени стандарти и с координацията на заинтересованите страни, участващи в разработването на системата. Системно тестване и приемане 44 Библиография 1. Изабел Рамос Роман, Хосе Хавиер Доладо Косин. Количествени методи на управление в разработката на софтуер. Алонсо Амо, Лоик Мартинес Норманд. Въведение в разработката на софтуер. Тестване на системи и тестване за приемане 45 8. -Катедра по компютърни езици и системи. Структурни системен анализ. Методи за идентифициране на бактерии в лабораторията по микробиология.