Підготували студенти групи ІН-94-1
Павло Ніколаєнко
Михайло Крикуненко
Покриття коду (Code Coverage)
У сфері тестування звично говорити про якість самого ПЗ, про його перевірку та оцінку. Але замовникам також важливо знати і контролювати, що і сама перевірка продукту проходить також якісно, перевіряються всі найважливіші аспекти, виконується достатня кількість тестів, виправляється достатня кількість помилок і т. д. Тобто, якість тестування ПЗ, як і багато інших робіт, також має оцінюватися згідно з різними критеріями. Такі критерії називаються QA метриками. Вони являють собою різні коефіцієнти і показники, за допомогою яких можна скласти картину того, що відбувається на проекті, оцінити її та прийняти рішення по покращенню процесів при необхідності. Метрики стосуються різних областей в тестуванні, наприклад, вимог, якості самого продукту, ефективності та якості роботи команди розробки і команди з тестування, та ін.
У цій статті йтиме мова про одну з метрик оцінки якості тестування, такої як тестове покриття. Ця метрика являє собою щільність (охоплення) покриття тестами виконуваного коду програми або вимог до неї. Чим більше тестів буде написано, тим вище буде рівень тестового покриття. Але, потрібно розуміти, що повного 100% тестового покриття бути не може, так як неможливо повністю протестувати весь продукт.
До оцінки тестового покриття в свою чергу є декілька підходів:
Покриття вимог (Requirements Coverage);
Покриття коду (Code Coverage);
Тестове покриття на базі аналізу потоку керування.
Ця метрика показує щільність покриття тестами вимог до продукту. Найкраще вона буде відображати ситуацію, коли вимоги досить атомарні.Метрика обчислюється за формулою:
Тестове покриття = (кількість вимог, покритих тест-кейсами/загальна кількість вимог) х100%
Щоб перевірити таке тестове покриття, вимоги необхідно розбити на пункти і кожен пункт зв'язати з тест-кейсами, які його перевіряють. У тест-кейсах немає необхідності, якщо вони не перевіряють будь-які вимоги в продукті. У свою чергу пункти вимог, для яких не написано жодного тест-кейсу, не будуть протестовані, а значить не можна буде з точністю сказати, чи реалізовані дані вимоги в продукті і як ці функції працюють.
Всі зв'язки між тест-кейсами і пунктами вимог називаються матрицею трасування. Якщо простежити і проаналізувати ці зв'язки, можна зрозуміти, які тест-кейси перевіряють які вимоги і для яких вимог потрібно написати/збільшити кількість тест-кейсів. Для деяких же вимог, можливо, існують зайві тест-кейси.
Дана метрика показує, скільки рядків коду задіюються (виконуваний код) при проходженні написаних для продукту тест-кейсів.
Метрика обчислюється за формулою:
Тестове покриття = (кількість рядків коду, покритих тест-кейсами/загальна кількість рядків коду) х100%
Для визначення того, які рядки коду були виконані при проходженні тест-кейсів існують спеціальні інструменти, наприклад Clover. Вони допомагають визначити, які рядки коли були задіяні для певних тестових сценаріїв. Ця інформація допоможе зрозуміти, які тести дублюють один одного, а для яких рядків коду потрібно додати перевірки. Перевірка тестового покриття коду проводиться при тестуванні білого ящика на модульному, інтеграційному і системному рівнях.
Це також спосіб тестування з доступом до коду, але при якому перевіряється покриття шляхів виконання коду програми. Для покриття цих шляхів також створюються тестові сценарії.
Щоб протестувати потоки управління, потрібно побудувати графік потоків керування (Control Flow Graph).
Він складається з таких основних блоків:
блок процесу (для входу і виходу існує по одній точці);
точка альтернативи (для входу існує одна точка, а для виходу – дві або більше);
точка з'єднання (для виходу існує одна точка, а для входу – дві або більше).
Потоки управління тестуються на декількох рівнях тестового покриття:
Це тільки частина метрик, за якими можна оцінити якість проведеного тестування. Крім описаних в цій статті, існують ще безліч інших, таких як коефіцієнт стабільності вимог, коефіцієнт повторно відкритих дефектів, ефективність тестів і тестових наборів та інші. Всі вони спрямовані як на самовдосконалення якості розробки, тестування ПЗ і підвищення задоволеності продуктом користувача, так і на поліпшення процесу роботи всієї команди в цілому і підвищення її ефективності.