Кабирский цикл в частности и Олди вообще рекомендую.
Дюже годный цикл.
Слово Канеру
Тестируемость это прозрачность и контроль
Любые фичи, позволяющие наблюдать и контролировать ПО улучшают тестируемость. Люди часто просят у нас список таких фич. Вот наш список:
Доступ к исходному коду Многие компании не позволяют тестировщикам изменять исходный код. Тем не менее, вы можете по-прежнему просматривать исходный код. Это особенно важно для просмотра изменений в системе контроля версий.
Логирование Лог сообщений об ошибках, источники ошибок, профили использования, утилизация ресурсов и протоколы связей. Разрешите настройку различных уровней логирования. Механизмы логирования, возможно, уже присутствуют в компонентах вашей системы. Программисты используют их при отладке. Вы могли бы использовать их, чтоб быстрее обнаружить ошибки быстрее, проанализировать ошибку, получить более подробную информацию, оценить покрытие тестами, собрать информацию о использовании ПО клиентами и узнать больше о программе, которую вы тестируете (DiMaggio 2000, Johnson 2001 и Marick 2000).
Диагностика Диагностика может предупредить вас о потенциальных проблемах. Проверки — это первый пример. Проверка целостности данных убедит вас в том, что внутренние данные системы непротиворечивы. Встроенные в код проверки удостоверяют нас, что программа не была переписана или изменена. Проверки памяти проверяют, что память используется согласно распределению. Это может быть мощным инструментом в сочетании с логированием, позволяющим войти в режим отладки или снять дамп памяти при обнаружении ошибки (Kaner 2000b).
Эмуляция ошибки Ваш продукт имеет внутренние состояния, многие из коотрых труднодостижимы, особенно если их нужно систематически воспроизводить. Многие состояния с ошибками — такого типа. Ваше ПО должно быть в состоянии восстановиться после ошибок медиаконтента, нехватки памяти или места в хранилище, задержек сети или дисконнекта и тому подобных проблем. Вам может быть достаточно сложно найти условия для воспроизведения таких ошибок. Триггеры ошибочных состояний могут быть размещены на самом низком уровне продукта для облегчения тестирования и обработки ошибок (Также существуют инструменты для эмуляции подобных ошибок извне продукта (Houlihan, 2001)).
Контрольные точки Разрешите проверку или изменение данных в определенных точках работы системы (Cohen 2000).
Триггеры событий Уведомления о том, что внутренние задачи стартовали или завершились могут помочь синхронизировать тесты.
Чтение устаревших форматов данных Форматы данных могут изменяться несколько раз, пока продукт находится в разработке. Обеспечьте средство для конвертирования данных в новый формат, чтоб не создавать данные заново.
Интерфейсы тестирования Программные интерфейсы — основа тестируемости. Несколько продуктов, в действительности, добавили программные интерфейсы именно по этой причине.
Поддержка пользовательских контролов Поддержка инструментов тестирования через GUI — вероятно, одна из наиболее востребованных функций тестируемости.
Разрешение нескольких экземпляров Разрешите запуск нескольких клиентов или агентов на одном компьютере, даже если это не поддерживается. Это может позволить тестировщикам моделировать большие сети в небольшой лаборатории.
Многие продукты имеют недокументированные фичи тестируемости, которые программисты добавили, чтоб помочь своим тестировщикам. Спросите о них.
Noel Nyman говорит: «Два инструмента Windows используются, чтоб помочь найти ошибки в памяти. (1) Fill buffers with known patterns when they're initialized. Это поможет выявить утечки, дикие указатели и т.д.. (2) Put buffers at the end of allocated heap and work backwards into the heap. Это вызывает переполнение буфера и появления онка Window's с сообщением об ошибке».
В одном проекте встроенного ПО Kaner и Hoffman обнаружили, что группой разработки было написано более 1100 диагностических команд для проверки состояний программы и устройства. Все они были доступны и тестировщикам. Тестировщикам нужно было посто выстроить соответствующие команды для создания теста.
Комментариев нет:
Отправить комментарий