Меню

Тестово покритие при тестване на софтуер (Съвети за максимално покритие на тестване)

test coverage software testing

Опитайте Нашия Инструмент За Премахване На Проблемите

Пълно ръководство за тестване на софтуер за тестване: Как да тествате повече, да спестите време и да постигнете по-добри резултати от тестването:

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

В наши дни разработката е по-систематична и организациите търсят мерки за тестване на пълнотата и ефективността, за да покажат критериите за завършване на теста. От всички тях покритието се счита за особено ценно.

Какво ще научите:

Какво е покритие на теста?

Просто казано, покритието е „Какво тестваме и колко тестваме?“

Тестовото покритие помага да се следи качеството на тестването и помага на тестерите да създават тестове, които покриват области, които липсват или не са валидирани.

покритие на теста

Повечето екипи изчисляват покритието си само на функционални изисквания. Справедливо е също така, защото на първо място приложението трябва да прави това, което трябва. Ако не, неговата скорост или сигурност или лекота на използване - нищо от това няма значение.

Ако обаче е посветен и независим нефункционално тестване екипите работят по производителност, сигурност, тестване на използваемостта и т.н., след което ще трябва да проследяват своите изисквания чак до изпълнението чрез анализ на покритието на теста.

Тестово покритие и покритие на кода

Тестовото покритие често се бърка с покритие на кода. Въпреки че основните принципи са едни и същи, това са две различни неща.

Покритие на кода наистина говори за практики за модулно тестване, които трябва да насочват към всички области на кода поне веднъж и се прави от разработчиците.

Тестовото покритие, от друга страна, е тестване на всяко изискване поне веднъж и очевидно е дейност на QA екип.

Това, което наистина отговаря на изискванията за покритие, зависи от интерпретацията на всеки отбор.

Например , Някои екипи наричат ​​покрито изискване, ако има поне един тестов случай срещу него. Понякога се обхваща, ако към него е назначен поне един член на екипа. Или, ако всички тестови случаи, свързани с него, се изпълняват.

  • Ако са създадени 10 изисквания и 100 теста - когато тези 100 теста са насочени към всички 10 изисквания и не пропускат нито едно - ние наричаме това адекватно покритие на тестване на ниво дизайн.
  • Когато се изпълняват само 80 от създадените тестове и са насочени само към 6 от изискванията. Ние казваме, че 4 изисквания не са покрити, въпреки че 80% от тестовете са направени. Това е статистика на покритието на ниво изпълнение.
  • Когато само 90 теста, свързани с 8 изисквания, са назначили тестери, а останалите не, ние казваме, че покритието на тестовото задание е 80% (8 от 10 изисквания).

Също така е важно кога да се изчисли покритието.

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

Прочетете също => Процес на управление на пускане и внедряване

Моят опит

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

Бях прав - и грешен също.

Точно тъй като с опит се научавате да виждате по-голяма картина, разбирате истинското значение на „критична ситуация“ и разбирате повече крайния потребител.

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

Увеличете покритието на теста за по-малко време

Ето моят опит от едно от интервютата по това време:

Как да се уверите, че покритието на теста е пълно или максимално? Попитаха ме.

Ммммм ... Уверявам се, че тествам всяка функционалност , Казах.

С o казвате, че след като тествате всички функционалности, чувствате, че сте покрили максимум приложение / продукт по отношение на тестването , интервюиращият се обърна.

Ъъъъ ... ами ... .ммм ... .да, защото когато тествате всички функционалности, сте уверени в поведението на приложението / продукта, Подкрепих отговора си .

Съгласен съм, но въпросът ми е - ще ви даде ли увереност, че покритието ви за тестване е максимално или пълно? интервюиращият не беше в настроение да ме пусне.

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

Вместо да възпроизвеждам откъсите от интервюто, аз обобщавам тук това, което научих за тестването на покритието, в този ден. Но преди това нека бъдем ясни по една точка - покритието на тестване никога не означава да знаете дали тествате достатъчно или не, нито означава, че тествате перфектно или не.

Значение на покритието на теста

Покритието за тестване може да има различно значение в различен контекст. Нека открием тези контексти един по един:

опашка от указатели c ++

Покритие на продукта - Какви аспекти на продукта разгледахте?

Да, когато обхватът на тестване се измерва по отношение на продукта, основната област, върху която трябва да се съсредоточите, е - кои области на продукта сте тествали и кои остават непроверени?

Пример # 1:

Ако „нож“ е продукт, вие тествате; просто не се концентрирайте върху проверката дали реже зеленчуците / плодовете правилно. Има и други аспекти, които трябва да се търсят, като например - потребителят трябва да може да се справи удобно с него.

Пример # 2:

Ако „notepad“ е приложение, вие тествате, проверката на съответните функции е задължително нещо.

Но други аспекти, за които трябва да се внимава, са - приложението реагира правилно, докато използва други приложения едновременно, приложението не се срива когато потребителят се опитва да направи нещо необичайно , на потребителя се предоставят правилни съобщения за предупреждение / грешка, потребителят е в състояние да разбира и използва приложението лесно, помощното съдържание е достъпно, когато се изисква.

Ако не разгледате споменатите сценарии, не можете да твърдите, че покритието за тестване на приложението е пълно.

Покритие на риска - за какви рискове сте тествали?

Покритието на риска е друг аспект, за да имате пълно покритие на тестването. Не можете да маркирате продукта или приложението като „тествани“, докато не тествате и свързаните рискове. Покритието на свързаните рискове е важен фактор за общото покритие на тестовете.

Пример # 1:

Докато тествате самолет, ако изпитателят ви каже, че е тествал напълно вътрешната система на самолета и работи добре, но само летателната способност на самолета не е била покрита по време на тестването - каква ще бъде вашата реакция?

Е, това означава покритие на риска. Идентифицирането на риска според приложението / продукта и внимателното му тестване винаги е добра практика.

Пример # 2:

Докато тестваше сайт за електронна търговия, тестерът взе предвид всеки ефективен фактор, но не взе предвид риска от брой потребители, които имат достъп до уебсайта едновременно и в деня на Супер ОФЕРТА, неразглежданият риск се оказа огромна грешка.

Препоръчително четене =>

Покритие на изискванията - За какви изисквания сте тествали?

Ако даден продукт или приложение са разработени много добре, но ако не съвпадат с изискванията на клиента, тогава няма полза. Покритието на изискванията по време на тестването е също толкова важно, колкото и покритието на продукта.

Пример # 1:

Развълнувана от семейната функция, помолихте шивача да ви зашие роклята и да сложи онези паунови сини бутони за показване на деколтето.

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

Пример # 2:

Докато тестваше приложение за чат, тестерът се погрижи за всички важни моменти, като много потребители в чата в група, двама потребители в чата независимо, всички видове емотикони, актуализации, изпратени на потребителя веднага и т.н. спомена, че когато двама потребители разговарят независимо, опцията за видео разговор трябва да бъде активирана.

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

Също Прочети => Как да създадете матрица за проследяване на изискванията

Как да възприемете подходящ метод за покритие на теста?

Информираността е всичко:

Първо, екипът за QA трябва да знае колко работа е свързана и къде са задачите по проектиране. По този начин те ще бъдат наясно, ако трябва да се добавят още тестове. За да направите това, можете да използвате RTM, както е типичната практика.

=> Проверете тази статия, за да научите повече за нея и как да я използвате: Как да създам матрица за проследяване на изискванията - точен процес с образец за шаблон

На второ място, проверете разпределението на ресурсите и процес на изпълнение на теста за да видим дали всичко е тествано по по-ефективен начин.

Таблица като по-долу може да бъде полезна:

Тип тестОбщо делаИзпълнени делаСъстояниеКоментари
Функционални1008050 пас, 30 неуспех
Съвместимост100петдесет45 пас, 5 неуспех
Използваемост10010098 пас, 2 се провалят
Финална регресия10010099 пас, 1 неуспех

Как да се уверите, че всичко е тествано?

  • Всеки тестер трябва да е наясно с изискванията и методите за тестване
  • Приоритизирайте изискванията си и насочете енергията си там, където е най-необходима
  • Бъдете информирани за това как определена версия се различава от предишната, за да можете да идентифицирате по-точно критичните изисквания и да се съсредоточите върху максимално положително покритие
  • Адаптирайте автоматизация на теста
  • Използвайте инструментите за управление на тестове да останат винаги в течението
  • Интелигентно работно задание - насочете най-добрите си ресурси към критични задачи и оставете нови тестери да изследват повече за нова перспектива
  • Поддържане на a контролен списък за всички задачи и различни дейности
  • Взаимодействайте повече с вашите екипи на Dev / Scrum / BA, за да получите представа за поведението на приложението
  • Следете всичките си цикли на изграждане и корекции
  • Идентифицирайте най-засягащите проблеми в първоначалните компилации (когато е възможно), за да могат по-късните да работят за по-добра стабилност и да достигнат до областите, блокирани от предишни проблеми

Критични области и методи за ефективно тестване

ефективно тестване

# 1)Разбъркване на ресурсите: Обменяйте задачи между членовете на вашия екип. Това помага да се подобри ангажираността и да се предотврати концентрацията на знания.

# две)Покритие за съвместимост: Уверете се, че сте наясно и включвате различни браузъри и платформи за да тествате приложението си.

# 3)Собственост: Накарайте тестерите да бъдат отговорни и им дайте свобода (с мониторинг и поддръжка, разбира се) за модула / задачата, по която работят. Това помага да се изгради отговорност и им позволява да опитат творчески начини, вместо да следват битите по пътя.

коя е най-добрата защитна стена за Windows 10

# 4)Крайни срокове: Познаването на сроковете за пускане преди началото на фазата на тестване помага за ефективно планиране

# 5)Комуникация : Поддържайте връзка с разработчика и други екипи между циклите на освобождаване, за да разберете какво се случва.

# 6)Поддържайте RTM: Действа като добра производна на Заинтересовани страни или клиенти , въз основа на които графикът за пускане може да бъде потвърден

Предимства на тестването на осведомеността за покритие за тестер:

Заключение

Покритието на теста не завършва със споменатия контекст. Има много други точки, които трябва да се имат предвид, когато става въпрос за покритие на тестването.

Не винаги е вярно, че когато тествате повече, резултатите са по-добри. Всъщност, когато тествате повече без очевидна стратегия, вероятно ще инвестирате много време.

С по-структуриран подход, целящ 100% покритие на изискванията и ефективни методи за тестване, няма да направите компромис с качеството.

Надяваме се, че описаните в тази статия техники ще ви дадат насоки.

Изсипете вашите коментари и мнения за публикацията. Както обикновено, обичаме да чуваме от вас.

Препоръчително четене

^