functional testing vs performance testing
Функционално тестване срещу тестване на производителността:
Разлики между Тестване на ефективността, тестване на натоварване и стрес тестване бяха обяснени с примери в последния ни урок.
Софтуерното тестване обхваща широк кръг области, в които може да се извърши всякаква проверка или валидиране на функционалността на софтуера. Понякога нефункционалните аспекти стават по-малко свързани с функционалните аспекти. Те не се изпълняват практически; едновременно по време на тестване на софтуера.
=> Щракнете тук за пълна серия уроци за тестване на ефективността
Тази статия обяснява допълнителните предимства на качеството на софтуерния продукт по време на различни сценарии в жизнения цикъл на софтуерното тестване когато едновременно се вземат както функционални, така и нефункционални.
Какво ще научите:
- Бърза разлика между тестване на ефективността и функционално тестване
- Защо функционалното тестване и тестването на производителността трябва да се извършват едновременно?
- Казус
- Заключение
- Препоръчително четене
Бърза разлика между тестване на ефективността и функционално тестване
Sl NO | Функционално тестване | Тестване на производителността |
---|---|---|
1 | За да проверите точността на софтуера с определени входове спрямо очаквания изход | За да се провери поведението на системата при различни условия на натоварване |
две | Тя може да бъде ръчна или автоматизирана | Той може да се изпълнява ефективно, ако е автоматизиран |
3 | Един потребител, изпълняващ всички операции | Няколко потребители, извършващи желани операции |
4 | Изисква се участие от страна на клиента, тестера и разработчика | Изисква се участие от клиент, тестер, разработчик, DBA и екип за управление на N / W |
5 | Производствената тестова среда не е задължителна и изискванията за В / В са минимални | Изисква близо до производствената тестова среда и няколко H / W съоръжения за попълване на товара |
Защо функционалното тестване и тестването на производителността трябва да се правят едновременно?
Функционалното тестване става много по-важно за всяко издание на софтуера. Действително основано на резултати проверка и валидиране в репликираната производствена или тестова среда са местата, където тестването обикновено се случва.
Изтичането на дефекти може да се превърне в един от най-големите проблеми:
Тестерите носят по-голяма отговорност от разработчиците по отношение на качеството на продукта. По принцип те не искат тестваният продукт да има дефект. Тестерите обикновено са склонни да извършват само функционални тестове, за да постигнат това.
Следва разговор междуТест мениджър и тестер :
(Тестовият мениджър се нарича „TM“, а тестерът - „TR“)
TM : Хей, приятелю ... Как се справяме при тестването на продукта „А“?
TR : Да ... Ние напредваме по-добре.
TM : Това е фантастично ... И какъв е обхватът ни по отношение на тестването на производителността, докато функционалното тестване е в изпълнение?
TR : Ние не ги покриваме, нашите продукти трябва да бъдат само във функционалната област, а не в нефункционалната зона. Освен това тестовата среда, която използваме, не е точно копие на продукцията.
Има няколко въпроса от горния разговор, които трябва да бъдат разгледани:
- Има ли функционално тестване зависим фактор от производителността?
- Какво ще стане, ако производителността на софтуера се влоши, но доставката на продукта се извършва без проверка на производителността?
- Тестване на производителността - съпътства ли се в рамките на процеса на функционално тестване?
Общата практика за тестерите е да не работят по нефункционалните аспекти, освен ако не се изисква от тях. Често се избягва нефункционално тестване докато клиентът не съобщи за проблеми с производителността на тествания софтуер.
И така, има 2 въпроса, които да разгледате:
- Ефективност - влияе ли функционалното тестване?
- Поддържаме ли тестването на производителността като отделен продукт, дори ако това притеснява клиента?
Тестването на производителността е важно !
c и c ++ разлики
Софтуерът работи въз основа на различни архитектури и следните модели, включително:
- Необходими модели за отговор на отговора
- Системи, базирани на транзакции
- Системи, базирани на натоварване
- Системи, базирани на репликация на данни
Поведението на функционалното тестване на гореспоменатия систематичен модел зависи от производителността на системата.
Гледната точка на автоматизацията изисква много внимание към тестването на производителността.
Следва разговор междуклиент и мениджър на тестове.
(Клиентът е наричан „CL“, а мениджърът на тестове - „TM“)
CL : Следователно, стигайки до решението, което поискахме, се надявам да има множество повторения на тестването, което се случва в момента.
TM : Да, това може да се направи. Както казахте, ще има по-голяма вероятност от итеративно тестване, бихме искали да предложим автоматизация за справяне с функционалното (регресивно) тестване.
CL : Добре, чудесно, моля, изпратете ни своя подход, за да можем да го одобрим. Автоматизацията ще има много по-висока производителност с минимални усилия.
TM : Точно. Ще работим по подхода и ще се свържем с вас с доказателство за концепция.
От горния разговор става ясно, че потребността на клиентите е да оптимизират ефективността.
Казус
Компанията ABC работи по проект за разработване на софтуер А. Тестването на софтуера A се извършва от компанията XYZ.
Договорът за компания ABC и XYZ има някои ограничения за тяхното сътрудничество. Всяка дискусия между двете компании трябва да се провежда веднъж седмично или три пъти месечно. Системата работи по модел на режим на заявка-отговор. Фазата на разработка е завършена от компания ABC.
Сега е време компанията XYZ да извърши официалното функционално тестване на Софтуер А. XYZ започва да работи по тестване на Софтуер А. Те са направили чист пристъп към софтуера и са дали „Go“ за изпълнение на живо след 2 цикъла на тестване.
Въпреки сертификата за качество от екипа за тестване, изпълнението на живо не вървеше добре. Имаше много грешки в постпродукцията. Имаше голям брой проблеми, с които се сблъскваха клиентите, включително прекъсване на функционалността за бизнес процесите от край до край.
И така, какво епроблем?
- Проблем ли е с ограничението за сътрудничество между екипа за разработка и тестване?
- Това ли е, че изискванията не са били уловени на 100%?
- Това, че продуктът не е бил тестван в подходяща тестова среда?
- Или някакви други причини?
След внимателно проучване и анализ,следните бяха направени изводи:
- Малко бяха зависимите и взаимозависими приложения, които имаха проблеми с производителността при извличане на отговорите.
- Използваните тестови входове не бяха абсолютни.
- За здравината на софтуера не се погрижи.
- Много проблеми със синхронизирането между множество независими приложения.
- Тестването на софтуера е извършило множество преработки, които не са били взети предвид.
Следователно следкоригиращи действияекипът за планиране се намеси, бяха предложени следните:
- Взаимодействието между екипа за разработка и екипа за тестване трябва да се увеличи.
- Всички зависими приложения трябва да бъдат свързани и включени в системното функционално тестване
- Стойността на времето за изчакване на заявките и отговорите трябва да се увеличи, за да се даде място на непроизводствени среди
- При функционално тестване трябва да се използват различни входове, вариращи от прости до сложни
- Нефункционалното тестване, особено тестването на производителността и натоварването, трябва да се извършва според препоръките на екипа за отстраняване.
- В допълнение към системното тестване трябва да се извърши тестване на системната интеграция.
- Трябва да се осигури минимален интервал от време между всякакви две итерации на тестване. Това е за повторно тестване на предварително идентифицираните грешки.
- Всички грешки, идентифицирани в предишни итерации, трябва да бъдат коригирани в текущата итерация.
Екипът за тестване изпълни всички предложени действия и за малко време бяха открити голям брой дефекти.
Наблюдения:
- Графикът за внедряване на живо на софтуера се подобри значително чрез оптимизиране на времената на тестовия цикъл.
- Постигна се добър напредък в оптимизацията на качеството на софтуера. Следователно имаше значително намаляване на билетите за поддръжка след изпълнението.
- Преработките бяха намалени и тестваше повторения, вместо да преработва. Между различните повторения се наблюдаваха по-добри подобрения в качеството.
Заключение
Извършването на нефункционално тестване по време на изпълнение на функционален тест е по-изгодно и ще добави повече предимства към цялостното качество на софтуера. Това ще идентифицира грешки в производителността (ограничени до тестовата среда и зависимост) и следователно ще намали ситуациите на функционални предположения за проблеми.
Трябва да се направи достатъчно планиране за извършване на функционални и нефункционални тестове (до минимално ниво), за да се запази силна връзка между другите заинтересовани страни от проекта.
За автора: Това е статия, написана от Nagarajan. Той работи като тестов ръководител с над 6 години опит в различни функционални области като банково дело, авиолинии, телеком по отношение на ръчно и автоматизирано.
Предстоящият ни урок ще обясни повече за плана за тестване на ефективността и тестовата стратегия.
=> Посетете тук за пълна серия уроци за тестване на ефективността
Препоръчително четене
- Функционално тестване срещу нефункционално тестване
- Най-добри инструменти за тестване на софтуер 2021 г. [Инструменти за автоматизация на QA теста]
- Тестване на ефективността срещу тестване на натоварване срещу тестване на стрес (разлика)
- Georgia Tech стандартизира своето тестване на производителността на RadView WebLOAD
- Разлика между тестване на настолни компютри, клиентски сървър и уеб тестване
- Изтегляне на eBook за тестване на Primer
- Разликите между модулното тестване, интегрираното тестване и функционалното тестване
- Тестване на производителността в облака: Доставчици на услуги за тестване на натоварване в облак