Прибыль:
- Способность читать такие показатели, как покрытие линий, ветвей и условий, как карту, а не доверие, и понимать, что высокое покрытие может дать псевдодоверие.
- Возможность разместить область требований рядом с областью кода и сделать пробелы в отслеживаемости видимыми с помощью искусственного интеллекта.
- Способность оценивать функции по формуле риск = вероятность × влияние, направлять ограниченные усилия по тестированию на самый высокий риск и документировать намеренное исключение из области применения.
Вы не можете тестировать каждое программное обеспечение вечно; Время и ресурсы ограничены. Итак, реальный вопрос: куда направить ограниченные усилия по тестированию? На этот вопрос отвечают две концепции. Тестовое покрытие — показатель, который измеряет, какая часть кода или требований затрагивается тестами, — представляет собой то, что тестируется. Тестирование на основе риска – подход к определению приоритета тестирования в зависимости от вероятности ухудшения состояния области и ущерба, который оно причинит в случае ухудшения, – направляет усилия на наибольшую степень риска. Искусственный интеллект (ИИ) является мощным партнером по анализу в обоих случаях: он делает видимыми пробелы в охвате, указывает на области риска. Но главное предостережение остается: количество прицелов, которые видит ИИ, может вводить в заблуждение; Даже 100% покрытия строк можно достичь с помощью тестов, которые ничего не проверяют. Ваша задача — воспринимать масштабы как карту, а не как доверие.
Правильно считываем показатели покрытия
Существует несколько типов области видимости, и не все они одинаково значимы:
- Покрытие строк: сколько строк кода было выполнено хотя бы один раз. Самый распространенный, но самый слабый критерий; Тот факт, что линия работает, не является доказательством того, что она ведет себя правильно.
- Покрытие ветвей: проверена ли каждая ветвь if (как истинная, так и ложная). Более значимо, чем линия.
- Покрытие условий: тестирование каждого подусловия в сложных условиях отдельно.
- Покрытие путей: комбинации логических путей внутри кода. Это наиболее всеобъемлющий, но трудноосуществимый в полной мере практический подход.
Внимание: процент покрытия не является «показателем качества». 100%-ное покрытие строк говорит о том, что строки работают; не то, чтобы он давал правильный результат (псевдопроход в модуле 1). Используйте прицел как ответ на вопрос «куда я никогда не смотрел», а не как гарантию того, что «все проверено».
Область слепых зон
Метрики покрытия измеряют только то, какая часть кода была выполнена; не может увидеть: (1) непроверенные требования (код существует, но бизнес-правила неверны), (2) отсутствующий код (нет возможности для элемента управления, который никогда не был написан), (3) комбинации данных/состояния, (4) удобство использования, производительность, безопасность. Поэтому покрытие требований (каждому критерию приемки должен соответствовать хотя бы один тест) должно быть помещено рядом с покрытием кода. ИИ очень полезен при составлении карты требований и тестов (матрицы прослеживаемости).
Тестирование на основе рисков: куда мы прилагаем усилия?
Риск = вероятность (вероятность поломки) × воздействие (вред в случае поломки). С помощью ИИ вы можете оценить список функций по этим двум осям и создать тепловую карту. Высокая вероятность × высокие домены (платеж, аутентификация, целостность данных) заслуживают самого тщательного тестирования; низкие × низкие области (редко используемый экран предпочтений) достаточно светового тестирования.
площадь
вероятность
Воздействие
Риск
Плотность теста
Поток платежей
средний
очень высокий
высокий
Глубокая + автоматизация
аутентификация
средний
очень высокий
высокий
Глубокий + безопасность
Поиск продукта
высокий
средний
Средне-высокий
Автоматизация + открытие
Фото профиля
низкий
низкий
низкий
управление светом
Страница помощи
низкий
слишком низко
слишком низко
обзор
Ловушка погони за размахом
Если сделать процент покрытия целью (например, правило «команда должна пройти 90% покрытия»), это имеет опасный побочный эффект: разработчики и тестировщики сосредотачиваются на увеличении процента, а не на устранении фактического риска. В результате часто получается раздутая область видимости без утверждений и тривиальных тестов — число выглядит красиво, но нет защиты. Это феномен искажения критерия, когда он сам становится целью: «когда мера становится целью, она перестает быть хорошей мерой». Используйте осциллограф как диагностический инструмент, а не как отчет о производительности.
Более здоровый подход — читать объем работ прямо: «Почему покрытие отделений в критическом платежном модуле застряло на уровне 40%?» Вопрос в том, "является ли общий охват 90%?" Это гораздо ценнее самого вопроса. Попросите ИИ разбить отчет по объему работ по модулям и уровням риска; Выделите области высокого риска с низким охватом. Таким образом, объем становится компасом, который направляет труд, а не слепым процентом.
Внимание: лозунг «100% охват» — это ловушка. Тестирование некоторого кода (простых средств доступа, автоматически генерируемых частей) не имеет большого значения; затраченные на это усилия украдены из бизнес-правил высокого риска. Цель состоит в том, чтобы проверить каждое важное поведение и риск, а не каждую линию.
Слабая подсказка / Сильная подсказка
Слабое: «Увеличьте охват тестированием».
Сильный: «Учитывая этот список критериев приемки и эти существующие тестовые примеры. (1) Таблица, в которой критерии приемки не были выполнены ни одним тестом (пробел в покрытии требований). (2) Оцените каждую функцию от 1 до 5 по осям вероятности и воздействия; ранжирование по риску = вероятность × влияние. (3) В течение моего ограниченного времени предложите, какие 5 пробелов я должен закрыть в первую очередь, начиная с самого высокого риска. Не принимайте покрытие строки кода в качестве единственного критерия; расставьте приоритеты бизнес-рисков. Критерии: [...] Тесты: [...]"
Мощная подсказка; сочетает масштабы с бизнес-рисками и отдает приоритет ограниченному труду.
Четыре копируемых шаблона
1) Разрыв в объеме требований:
Учитывая следующие критерии приемки и эти тестовые примеры. Создайте таблицу прослеживаемости: каждый критерий -> тест(ы), которые ему соответствуют. Критерии, не имеющие каких-либо тестов, называются «ПРЕВЫШЕНИЕ ПОКРЫТИЯ», а тесты, которые не связаны ни с какими критериями, называются «НЕОБХОДИМЫ?» Оценка: Критерии: [...] / Тесты: [...]
2) Оценка риска:
Оцените этот список функций/модулей от 1 до 5 по осям вероятности (вероятность поломки) и воздействия (ущерб в случае поломки). Риск = вероятность × воздействие. Отсортируйте таблицу и укажите рекомендуемый тип тестирования (модуль/API/UI/разведка/безопасность) для каждой области высокого риска. Список: [...]
3) Интерпретация объема:
Был предоставлен следующий отчет по покрытию (линия %, ветвь %). Скажите мне следующее: - Что НЕ доказывают эти цифры? - Какие области могут подвергаться риску, несмотря на большое покрытие строк? - Какое дополнительное тестирование вы бы порекомендовали для устранения пробелов, которые не видит покрытие (требования, комбинация данных, безопасность)? Отчет: [вставить]
4) Ограниченный по времени план:
До трансляции осталось [X часов]. Приводятся следующие ранжирование рисков и пробелы в покрытии. В течение этого периода в порядке приоритета составляется план испытаний, который снизит максимальный риск. Четко укажите, что НЕ следует сознательно тестировать, и допустимый риск, связанный с этим. Данные: [...]
три мини-кейса
Кейс 1 — 100% охват, нулевое доверие. Одна команда могла похвастаться 94% покрытием линии. Анализ «интерпретации области действия» показал, что большинство тестов были без утверждений, то есть они запускали строки, но ничего не проверяли. Фактическое защитное покрытие было намного ниже. Команда сосредоточилась не на цифрах, а на тестировании мутаций (блок 10); фактическая частота обнаружения ошибок удвоилась.
Случай 2 — Исправлен приоритет карты рисков. Одна команда тратила 40% усилий по тестированию на редко используемый экран отчетов, пропуская поток платежей, потому что он «просто работает». Оценка рисков ИИ показала этот дисбаланс. Труд был перераспределен; Две недели спустя в потоке платежей была обнаружена серьезная ошибка, которая была закрыта перед запуском.
Случай 3 — Сознание вне поля зрения. Спустя 4 часа после выпуска команда решила, что протестировать, а что сознательно пропустить с помощью шаблона «ограниченное расписание». Два потока высокого риска были проверены на глубине; экран предпочтений с низким уровнем риска был задокументирован как «принятый риск» и пропущен. Решение было прозрачным и аргументированным; Версия вышла благополучно.
Распространенные ошибки
- Принимаем процент покрытия за качество. Чтение покрытия верхних строк как «проверенная» гарантия.
- Просто смотрю на покрытие кода. Пропуск покрытия требований (тестирование каждого критерия приемки).
- Тестирование одинаково без учета риска. Распределение рабочей силы в районы с низким уровнем риска и игнорирование критических потоков.
- Скрывается за пределами видимости. Не документировать то, что не было протестировано, когда было недостаточно времени; Сюрпризы после релиза.
- Безоговорочное принятие оценки риска ИИ. ИИ не полностью знает контекст продукта; Корректируйте оценки экспертным взглядом.
В итоге
Тестовое покрытие и тестирование на основе рисков — это два инструмента, позволяющие направить ограниченные усилия в нужное место. Метрики покрытия (линия, ветвь, условие, путь) показывают, что было затронуто, но не доказывают, что оно вело себя правильно; Масштаб — это карта, доверие — нет. Поместите покрытие требований рядом с покрытием кода. Оцените характеристики по формуле риск = вероятность × воздействие и направьте усилия на наибольший риск. ИИ делает видимыми пробелы, оценивает риск, планирует ограниченное время; но окончательный приоритет и решение о «сознательном отказе» остается за экспертом, который знает бизнес-контекст.
Задача приложения
Выберите модуль из своего проекта. Запустите шаблон «Пробел в объеме требований» с помощью ИИ и выясните, какие критерии приемки не проверяются. Затем проранжируйте подфункции модуля по осям вероятность × воздействие с помощью «оценки риска». Распределите (гипотетические) 3 часа тестирования, которые у вас есть, с «ограниченным графиком»; Запишите то, что вы сознательно не будете тестировать, и принятый риск. Добавьте конкретный тест, который закроет обнаруженный вами пробел в покрытии самого высокого риска.
контрольный список
- [ ] Я рассматриваю процент покрытия как карту, а не качество.
- [ ] Помимо покрытия кода, я также удалил покрытие требований.
- [ ] Я оценил функции по вероятности × влияние и ранжировал их по риску.
- [ ] Я перенаправил усилия по тестированию на самый высокий риск.
- [ ] Я задокументировал области, которые сознательно не проверялись и не признавали риск.
- [ ] Я просмотрел оценки риска ИИ на основе контекста моего продукта.