Таки лекции вернулись и никуда не денутся, просто занят был.
Пару дней работе почти ничего не мешало, сегодня вечером споткнулся на верстке. И кстати, начинаю ощущать нехватку теоретических знаний.
Где-то читал, что самая большая необходимость в обучении для профессиональной реализации у врачей - вроде как быстрее и кардинальней меняются методы диагностики и лечения.
Если отбросить аспект критичности их работы, то у них хотя бы объект работы - организм - остается более менее один.
Хорошая песня, про выборы.
Выбери любого, главное выбери, не зря же тебе право выбирать, блядь, выбили!
Слово Канеру:
Классификация техник тестирования зависит от того, что вы о них думаете.
You might be puzzled about why we placed particular techniques where we did (ну не получилось у меня это перевести). Если так, то у меня для вас хорошая новость - ваш мозг включен. Вспомните, любое тестирование включает в себя все пять аспектов Five-Fold System. Мы перечислили техники по категориям, чтобы просто дать вам почувствовать разницу и выделить случаи, когда одни виды мышления превалируют над другими. Ваше мнение может быть иным. Например, один читатель спорил с нами о том, что нагрузочное тестирование может быть классифицировано как проблемно-ориентированное тестирование, а не как тестирование, основанное на активности(виде деятельности). Наш ответ - вы можете думать об этом в любом ключе.
Давайте посмотрим на это в проблемно-ориентированном ключе:
- Вы можете думать о нагрузочном тестировании в терминах эффекта от атак на отказ в обслуживании. Атакующий может попытаться добиться отказа сервиса путем создания большого количества соединений или используя большое количество памяти (одновременно выполняя каждым пользователем действия, интенсивно использующие память) или вызывая задачи, активно использующие процессор. Вы должны выполнить разные тесты для каждого из этих рисков.
Теперь рассмотрим эту деятельность в перспективе активности:
- Используете инструмент для отслеживания моделей поведения ваших клиентов. Какие команды они выполняют чаще всего? Какие задачи чаще всего пытаются решить? Какой процент клиентов проявляет ту или иную активность? Когда у вас появится модель поведения пользователей, используйте инструмент для нагрузочного тестирования и выполните тест по сценариям, которые согласованы с видами деятельности пользователя. Этот инструмент может случайным образом выбирать сценарий - по сути, создавать различные сессии. которые соответствуют различным типам поведения пользователей. Продолжайте добавлять сессии и наблюдайте как производительность и надежность системы уменьшаются с увеличением нагрузки. По необходимости - вносите в ваш продукт изменения.
Если вы думаете в терминах рисков, вы думаете о слабых местах программы и спрашиваете, как спроектировать тесты, которые эти слабости выявят. Когда вы знаете, какой тип теста вы хотите запустить, думайте о пути. которым вы его хотите провести. Если вы тестируете телефонию, вам может понадобиться инструмент или десять друзей, которые создадут серию звонков. Критерий проектирования теста - он должен иметь возможность обнаружить проблему, которую вы ищете.
В противоположность этому, если вы мыслите в терминах активностей, вы спрашиваете себя, как провести нагрузочное тестирование. Каким инструментом? Что делает этот инструмент? И так далее. Ожидается, что если вы используете инструмент грамотно, модель поведения клиентов составлена верно, а также поведены остальные мероприятия, связанные с качественным нагрузочным тестированием, то вы, вероятно, найдете те типы ошибок, которые способно выявить нагрузочное тестирование.
Классификация может не быть точной, но сам факт ее проведения может много вам дать. Однако, как бы вы ни классифицировали технику, например, нагрузочное тестирование, когда придет время, перед вами будут стоять все те же пять вопросов:
1. Кто будет тестировать?
2. Какие аспекты программы будут тестироваться?
3. Какие типы проблем мы будем искать?
4. Какие задачи будут выполнены при тестировании?
5. Как вы будете оценивать результаты?
Показаны сообщения с ярлыком chapter 3. Показать все сообщения
Показаны сообщения с ярлыком chapter 3. Показать все сообщения
суббота, 17 декабря 2011 г.
Lesson 53
Слово Канеру:
Техники тестирования основанные на том, как вы оцениваете результаты теста.
Техники, основанные на оценках описывают способы, с помощью которых можно определить, прошла ли программа тест. Они не говорят о том, как будет проходить тест или какую информацию мы будем собирать. Они говорят о том, как мы будем оценивать собранные данные.
Самопроверяющиеся данные Собранные данные несут в себе информацию, позволяющую определить, были ли выходные значения программы корректными.
Сравнение с ранее сохраненными результатами Регрессионное тестирование (обычно, но не всегда автоматизируемое) определяет прошел тест или нет путем сравнения результатов, которые мы получили сегодня с результатами, полученными на прошлой неделе. И если результаты были верны на прошлой неделе и изменились сегодня, то разница дает нам повод подозревать наличие нового дефекта.
Сравнение со спецификацией или надежным документом Несоответствие спецификации, вероятно, означает ошибку.
Эвристическая согласованность Согласованность - важный критерий оценки программы. Несогласованность может быть причиной регистрации дефекта или отражать изменения в архитектуре программы. Мы выделяем семь основных согласованностей:
1. Согласованность с историей. Нынешнее поведение функции соответствует ее прошлому поведению.
2. Согласованность с вашим представлением. Функция ведет себя согласно тому, как вы себе представляете организацию продукта.
3. Согласованность с аналогичными продуктами. Функция ведет себя подобно тому, как ведут себя такие функции в аналогах продукта.
4. Согласованность претензий. Функция ведет себя так, как люди говорят, что она должна себя вести.
5. Согласованность с ожиданиями пользователя. Поведение функция соответствует тому, что мы думаем, что хотят пользователи.
6. Согласованность с продуктом. Поведение функции соответствует поведению сопоставимых функций продукта или функциональных моделей продукта.
7. Согласованность с целями. Функция ведет себя согласно ее прямому назначению.
тестирование по оракулу Оракул - это инструмент оценки, который может сообщить, прошла ли программа тест или нет. В высоконагруженных автоматизированных системах оракулом часто является другая программа, которая генерирует результаты или проверки. Оракулу обычно больше доверяют, чем тестируемой программе, поэтому проблемы, выявленные им, как правило, стоят времени и сил для проверки.
Техники тестирования основанные на том, как вы оцениваете результаты теста.
Техники, основанные на оценках описывают способы, с помощью которых можно определить, прошла ли программа тест. Они не говорят о том, как будет проходить тест или какую информацию мы будем собирать. Они говорят о том, как мы будем оценивать собранные данные.
Самопроверяющиеся данные Собранные данные несут в себе информацию, позволяющую определить, были ли выходные значения программы корректными.
Сравнение с ранее сохраненными результатами Регрессионное тестирование (обычно, но не всегда автоматизируемое) определяет прошел тест или нет путем сравнения результатов, которые мы получили сегодня с результатами, полученными на прошлой неделе. И если результаты были верны на прошлой неделе и изменились сегодня, то разница дает нам повод подозревать наличие нового дефекта.
Сравнение со спецификацией или надежным документом Несоответствие спецификации, вероятно, означает ошибку.
Эвристическая согласованность Согласованность - важный критерий оценки программы. Несогласованность может быть причиной регистрации дефекта или отражать изменения в архитектуре программы. Мы выделяем семь основных согласованностей:
1. Согласованность с историей. Нынешнее поведение функции соответствует ее прошлому поведению.
2. Согласованность с вашим представлением. Функция ведет себя согласно тому, как вы себе представляете организацию продукта.
3. Согласованность с аналогичными продуктами. Функция ведет себя подобно тому, как ведут себя такие функции в аналогах продукта.
4. Согласованность претензий. Функция ведет себя так, как люди говорят, что она должна себя вести.
5. Согласованность с ожиданиями пользователя. Поведение функция соответствует тому, что мы думаем, что хотят пользователи.
6. Согласованность с продуктом. Поведение функции соответствует поведению сопоставимых функций продукта или функциональных моделей продукта.
7. Согласованность с целями. Функция ведет себя согласно ее прямому назначению.
тестирование по оракулу Оракул - это инструмент оценки, который может сообщить, прошла ли программа тест или нет. В высоконагруженных автоматизированных системах оракулом часто является другая программа, которая генерирует результаты или проверки. Оракулу обычно больше доверяют, чем тестируемой программе, поэтому проблемы, выявленные им, как правило, стоят времени и сил для проверки.
суббота, 26 ноября 2011 г.
Lesson 52
Ах, да.
Благодаря конторе и начальству еду на sqa days 10. Еще едут 2 тестировщицы.
Хорошо.
Екб, кто-нибудь еще будет там?
Не екб: Феликс? Редфокс? Думтест? Кто там еще-то... Вас увижу?
4-го буду в мск. Там есть что-нибудь интересное?
Слово Канеру:
Техники тестирования основанные на том, как вы тестируете.
Регрессионное тестирование Регрессионное тестирование включает в себя переиспользование однажды уже созданных и проведенных тестов после изменений в продукте. Вы поводите регрессионное тестирование фикса после того, как узнали о том, что баг был исправлен. Цель регрессионного тестирования в том, чтобы убедиться, что баги исправлены и изменения не внесли новых ошибок в старый функционал. Побочный эффект регрессии называется стабилизация, включающая перетестирование важных частей продукта. Цель в том, чтоб доказать, что предыдущие изменения не сломали важных компонент продукта.
Тестирование по плану Ручное тестирование, обычно выполняемое новичками, которые шаг за шагом следуют плану тестирования, написанному старшим тестировщиком.
Смок-тест Это тип регрессионного тестирования выполняется с целью проверить, готов ли новый билд к тестированию. Смок-тест часто автоматизируется и стандартизируется. Он проверяет вещи, которые должны работать, и если они не функционируют, то мы подозреваем, что программа была создана полностью некорректно.
Исследовательское тестирование Мы ждем, что тестировщик знает весь проект, продукт, целевую аудиторию, риски, сценарии, которые привели к предыдущим сбоям, Новые тесты постоянно создаются и используются. Они гораздо эффективней, чем старые, так как основываются на том, что тестировщик постоянно увеличивает объем знаний о проекте.
Партизанское тестирование Быстрая и грязная атака продукта. Форма исследовательского тестирования, ограниченная во времени, выполняемая опытным тестировщиком-исследователем. Например старший тестировщик может потратить один день на область, которая в противном случае игнорировалась бы. Он пробует на продукте самые мощные свои атаки. И если находит серьезную проблему, то область будет перетестирована и может быть изменен весь план тестирования. Если он не находит проблем, то и в дальнейшем область будет игнорироваться или походить лишь небольшие испытания.
Тестирование по сценарию Обычно обладает четырьмя атрибутами. 1) Тесты должны быть реалистичны. Они должны повторять то, что обычно делают с продуктом заказчики. 2) Тесты должны быть сложными, включать в себя использование нескольких функций. 3) По ним должно быть просто определить, прошла программа тест или нет. 4) Заинтересованные лица должны согласиться, что программа должна быть исправлена если не выдержит этой проверки. Тест, обладающий всеми четырьмя атрибутами будет убедительным, и давать на выходе реальные баги. Однако вам придется долго создавать и поддерживать качественные сценарии.
Тестирование по сценарию (прим. w_bf: это не я ошибся, это у Канера повтор) Тесты, основанные на кейсах использования продукта обычно называют тестами по сценарию (Jacobson 1992, Collard 1999) или юзкейс-тестами. (Многие люди классифицировали бы их как тесты основанные на покрытии важных сценариев использования)
Тестирование установки Установка ПО различными путями на различных системах. Проверка того, какие файлы добавлены и изменены на диске. Работает ли установленная программа? Что случится при удалении программы?
Стресс тестирование Тестирование системы, находящейся под атакой\нагрузкой и требующей для работы большого количества ресурсов. Под высокой нарузкой система имеет высокую вероятность падения, но картина событий, предшествующих падению может указывать на уязвимость в ПО, которая может быть использована. Asbock (2000) - отличная инструкция по нагрузочному тестированию.
Тестирование длинных последовательностей Выполняется всю ночь или весь день или всю неделю. Цель - обнаружить ошибки, которые не смогли найти короткие последовательности тестов. Пример ошибок, которые находят таким образом - дикие указатели, утечки памяти, переполнения стека, плохое взаимодействие нескольких функций. Часто такой вид тестирования называют продолжительным тестированием, тестированием выносливости или испытанием на надежность.
Тестирование производительности Такие тесты проводят для определения того, как быстро работает программа, чтоб решить, нуждается ли ПО в оптимизации. Но такие тесты могут найти и многие другие баги. Значительные изменения в производительности по сравнению с предыдущим релизом могут идентифицировать эффект от ошибки в программе. Например, если проверите, как долго работает некая функция сегодня, а затем проверите то же самое завтра, вы вероятно, сможете проверить это вместе с программистом и написать отчет об ошибке, в случае если тест прошел значительно быстрее или медленнее. Либо считать эти изменения подозрительными, так как произошли фундаментальные изменения в программе.
Sam Guckenheimer заметил: "Разница в производительности также может означать изменения в сторонних компонентах ПО или изменения в конфигурации. Например изменения в JVM с различными релизами JDK. Так тестирование производительности может даль удивительные результаты, даже если ваш код не менялся вообще."
Благодаря конторе и начальству еду на sqa days 10. Еще едут 2 тестировщицы.
Хорошо.
Екб, кто-нибудь еще будет там?
Не екб: Феликс? Редфокс? Думтест? Кто там еще-то... Вас увижу?
4-го буду в мск. Там есть что-нибудь интересное?
Слово Канеру:
Техники тестирования основанные на том, как вы тестируете.
Регрессионное тестирование Регрессионное тестирование включает в себя переиспользование однажды уже созданных и проведенных тестов после изменений в продукте. Вы поводите регрессионное тестирование фикса после того, как узнали о том, что баг был исправлен. Цель регрессионного тестирования в том, чтобы убедиться, что баги исправлены и изменения не внесли новых ошибок в старый функционал. Побочный эффект регрессии называется стабилизация, включающая перетестирование важных частей продукта. Цель в том, чтоб доказать, что предыдущие изменения не сломали важных компонент продукта.
Тестирование по плану Ручное тестирование, обычно выполняемое новичками, которые шаг за шагом следуют плану тестирования, написанному старшим тестировщиком.
Смок-тест Это тип регрессионного тестирования выполняется с целью проверить, готов ли новый билд к тестированию. Смок-тест часто автоматизируется и стандартизируется. Он проверяет вещи, которые должны работать, и если они не функционируют, то мы подозреваем, что программа была создана полностью некорректно.
Исследовательское тестирование Мы ждем, что тестировщик знает весь проект, продукт, целевую аудиторию, риски, сценарии, которые привели к предыдущим сбоям, Новые тесты постоянно создаются и используются. Они гораздо эффективней, чем старые, так как основываются на том, что тестировщик постоянно увеличивает объем знаний о проекте.
Партизанское тестирование Быстрая и грязная атака продукта. Форма исследовательского тестирования, ограниченная во времени, выполняемая опытным тестировщиком-исследователем. Например старший тестировщик может потратить один день на область, которая в противном случае игнорировалась бы. Он пробует на продукте самые мощные свои атаки. И если находит серьезную проблему, то область будет перетестирована и может быть изменен весь план тестирования. Если он не находит проблем, то и в дальнейшем область будет игнорироваться или походить лишь небольшие испытания.
Тестирование по сценарию Обычно обладает четырьмя атрибутами. 1) Тесты должны быть реалистичны. Они должны повторять то, что обычно делают с продуктом заказчики. 2) Тесты должны быть сложными, включать в себя использование нескольких функций. 3) По ним должно быть просто определить, прошла программа тест или нет. 4) Заинтересованные лица должны согласиться, что программа должна быть исправлена если не выдержит этой проверки. Тест, обладающий всеми четырьмя атрибутами будет убедительным, и давать на выходе реальные баги. Однако вам придется долго создавать и поддерживать качественные сценарии.
Тестирование по сценарию (прим. w_bf: это не я ошибся, это у Канера повтор) Тесты, основанные на кейсах использования продукта обычно называют тестами по сценарию (Jacobson 1992, Collard 1999) или юзкейс-тестами. (Многие люди классифицировали бы их как тесты основанные на покрытии важных сценариев использования)
Тестирование установки Установка ПО различными путями на различных системах. Проверка того, какие файлы добавлены и изменены на диске. Работает ли установленная программа? Что случится при удалении программы?
Стресс тестирование Тестирование системы, находящейся под атакой\нагрузкой и требующей для работы большого количества ресурсов. Под высокой нарузкой система имеет высокую вероятность падения, но картина событий, предшествующих падению может указывать на уязвимость в ПО, которая может быть использована. Asbock (2000) - отличная инструкция по нагрузочному тестированию.
Тестирование длинных последовательностей Выполняется всю ночь или весь день или всю неделю. Цель - обнаружить ошибки, которые не смогли найти короткие последовательности тестов. Пример ошибок, которые находят таким образом - дикие указатели, утечки памяти, переполнения стека, плохое взаимодействие нескольких функций. Часто такой вид тестирования называют продолжительным тестированием, тестированием выносливости или испытанием на надежность.
Тестирование производительности Такие тесты проводят для определения того, как быстро работает программа, чтоб решить, нуждается ли ПО в оптимизации. Но такие тесты могут найти и многие другие баги. Значительные изменения в производительности по сравнению с предыдущим релизом могут идентифицировать эффект от ошибки в программе. Например, если проверите, как долго работает некая функция сегодня, а затем проверите то же самое завтра, вы вероятно, сможете проверить это вместе с программистом и написать отчет об ошибке, в случае если тест прошел значительно быстрее или медленнее. Либо считать эти изменения подозрительными, так как произошли фундаментальные изменения в программе.
Sam Guckenheimer заметил: "Разница в производительности также может означать изменения в сторонних компонентах ПО или изменения в конфигурации. Например изменения в JVM с различными релизами JDK. Так тестирование производительности может даль удивительные результаты, даже если ваш код не менялся вообще."
среда, 23 ноября 2011 г.
Lesson 51
Что-то уроки у Сэма пошли немаленькие, быстренько перевести уже не получается, эх.
Слово Канеру:
Техники тестирования, основанные на проблемах сфокусированы на причинах тестирования (каких рисков мы хотим избежать)
Тестирование основанное на рисках имеет по крайней мере два основных значения.
Amland (1999) предоставил замечательное описание менеджмента тестирования основанного на рисках. Согласно его точке зрения, анализ рисков необходим для определения следующих шагов тестирования. Тесты приоритезируются с точки зрения вероятности того, что фича сломается и с точки зрения вероятной цены поломки фичи. И чем больше вероятность поломки, тем важнее тест и тем раньше его нужно проводить.
По другомум мнению, анализ рисков можно делать собственно для поиска ошибок. Когда мы изучаем особенности продукта, мы спрашиваем себя, как он может ломаться. Этот вопрос распадается на на множество дополнительных вопросов, таких как: Как будет выглядеть бага? Почему эта фича сломалась? (Мы опишем наш подход к тестированию основанному на рисках в дополнении к книге)
Оба этих подхода обсуждались в James Bach on Risk-Based Testing (1999c).
Whittaker и Jorgensen (1999 and 2000) предоставили отличное обсуждение и примеры широких классов ошибок, включающих нарушения ограничений:
Ограничения ввода Ограничение на ввод данных, с которыми программа может работать. Если программа работает с 32-разрядными числами, программист должен обеспечить защитные процедуры, которые смогут обнаружить и отклонить ввод более, чем 32-разрядных чисел. Если такого ограничения не будет, то программа упадет при попытке обработать такие числа.
Ограничения вывода Ввод был корректным, но он привел к выходным значениям, которые не могли быть обработаны. Программа может упасть при попытке отобразить, распечатать или сохранить эти данные.
Ограничения компиляции Ввод и вывод корректен, но в ходе расчета выходной величины программа падает. Например, умножение двух больших чисел может дать число, которое программа не может обработать.
Ограничения хранения Входные, выходные и внутренние значения корректны, но запуск программы приводит к переполнению данных или созданию слишком больших файлов.
Whittaker (2002) дал детальные рекомендации по тестированию этих ограничений.
Вот несколько полезных советов для проектирования тестов с учетом риска:
- Вы должны также сделать сопоставимые тесты, не основанные на рисках, для проверки тех рисков, которые вы не изучили достаточно хорошо.
- Тестируйте проблемы связанные со временем. Удивительно, но многие американские образованные тестировщики не учитывают временные проблемы. Классические проблемы сроков включают в себя вопрос гонок, и неожиданный порядок событий.
- Когда вы создаете тест, всегда создавайте процедуру испытаний, заставляющую программу использовать тестовые данные, которые вы ввели и позволяющую вам проверить, корректно ли вы используете данные.
Настроение дня:
Готовая тема попутчика Декстера.
Слово Канеру:
Техники тестирования, основанные на проблемах сфокусированы на причинах тестирования (каких рисков мы хотим избежать)
Тестирование основанное на рисках имеет по крайней мере два основных значения.
Amland (1999) предоставил замечательное описание менеджмента тестирования основанного на рисках. Согласно его точке зрения, анализ рисков необходим для определения следующих шагов тестирования. Тесты приоритезируются с точки зрения вероятности того, что фича сломается и с точки зрения вероятной цены поломки фичи. И чем больше вероятность поломки, тем важнее тест и тем раньше его нужно проводить.
По другомум мнению, анализ рисков можно делать собственно для поиска ошибок. Когда мы изучаем особенности продукта, мы спрашиваем себя, как он может ломаться. Этот вопрос распадается на на множество дополнительных вопросов, таких как: Как будет выглядеть бага? Почему эта фича сломалась? (Мы опишем наш подход к тестированию основанному на рисках в дополнении к книге)
Оба этих подхода обсуждались в James Bach on Risk-Based Testing (1999c).
Whittaker и Jorgensen (1999 and 2000) предоставили отличное обсуждение и примеры широких классов ошибок, включающих нарушения ограничений:
Ограничения ввода Ограничение на ввод данных, с которыми программа может работать. Если программа работает с 32-разрядными числами, программист должен обеспечить защитные процедуры, которые смогут обнаружить и отклонить ввод более, чем 32-разрядных чисел. Если такого ограничения не будет, то программа упадет при попытке обработать такие числа.
Ограничения вывода Ввод был корректным, но он привел к выходным значениям, которые не могли быть обработаны. Программа может упасть при попытке отобразить, распечатать или сохранить эти данные.
Ограничения компиляции Ввод и вывод корректен, но в ходе расчета выходной величины программа падает. Например, умножение двух больших чисел может дать число, которое программа не может обработать.
Ограничения хранения Входные, выходные и внутренние значения корректны, но запуск программы приводит к переполнению данных или созданию слишком больших файлов.
Whittaker (2002) дал детальные рекомендации по тестированию этих ограничений.
Вот несколько полезных советов для проектирования тестов с учетом риска:
- Вы должны также сделать сопоставимые тесты, не основанные на рисках, для проверки тех рисков, которые вы не изучили достаточно хорошо.
- Тестируйте проблемы связанные со временем. Удивительно, но многие американские образованные тестировщики не учитывают временные проблемы. Классические проблемы сроков включают в себя вопрос гонок, и неожиданный порядок событий.
- Когда вы создаете тест, всегда создавайте процедуру испытаний, заставляющую программу использовать тестовые данные, которые вы ввели и позволяющую вам проверить, корректно ли вы используете данные.
Настроение дня:
Готовая тема попутчика Декстера.
вторник, 22 ноября 2011 г.
Lesson 50 (часть 2)
Часть первая
Слово Канеру:
Техники тестирования основанные на том, что тестируется.
Тестирование репрезентативных значений Репрезентативные значения класса эквивалентности те, которые чаще приводили к ошибкам. В тестировании граничных значений - граничные значения всегда наиболее репрезентативны. Но предположим, что вы не можете отобразить класс эквивалентности на числовую ось. Например принтеры Hewlett-Packard PCL-5 являются классом эквивалентности, потому как должны работать одним и тем же образом. Теперь предположим, что для конкретной задачи один из принтеров имеет немного больше шансов заполучить проблему, чем другие. Это принтер и будет репрезентативным значением класса, и если он нас не подведет - не подведут и остальные.
Тестовая матрица для полей ввода Для каждого типа поля ввода ты можешь разработать достаточно стандартный набор кейсов и использовать их в этом и других продуктах. Пример мы приведем далее в этой главе.
Карта и проверка всех способов редактирования полей Часто есть возможность изменить значение переменной несколькими путями. Например, есть способ импортировать данные в поле, ввести значение напрямую, скопировать результат в поле, поле может программно вычисляться и перевычисляться автоматически и так далее. Поле имеет ограничения. Некоторые ограничения могут быть постоянными, друггие могут меняться в зависимости от значений в соседних полях. Например, если J и K - целые положительные числа, они ограничены значениями от 0 до MaxInt. Это постоянное ограничение, зависящее от языка программирования. Предположим, что N тоже положительное целое, N = J + K, и если N=5, то J = 5 − K, и J не может быть больше 5(значение N). Это меняющееся ограничение, чей диапазон допустимых значений зависит от N. Чтоб проверить, что J находится в диапазоне допустимых значений (5-K) мы должны попытаться изменить его значение в каждом возможном направлении.
Логическое тестирование Переменные имеют зависимости в программе. Например, в программе может быть правило, которое говорит, что если PERSON-AGE больше 50 и если SMOKER = YES, то OFFER-INSURANCE должно быть равно NO. Правило выражает логическую зависимость. Логическое тестирование пытается проверить все логические зависимости в программе. График причинно-следственных связей - техника проектирования широкого набора тестов основанных на логике системы.
Тестирование состояний Программа двигается от состояния к состоянию. В данном состоянии некоторые входные данные корректны, другие будут проигнорированы или отклонены. В ответ на валидные входные данные тестируемая программа делает то, что может и не пытается делать то, что не должна. В тестировании состояний мы ходим по программе согласно большому набору переходов между состояниями и тщательно проверяем результаты на каждом шаге.
Тестирование путей Путь включает все шаги, что ты совершил и все состояния через которые прошел, чтоб дойти до текущего состояния. Тестирование путей включает в себя тестирование множества путей в пhограмме. Нельзя проверить все пути в нетривиальной программе. Некоторые тестировщики проводят тестирование "подпутей" - тестирование частей пути. Тестирование базовых путей включает в себя все подпути одного типа, предполагая, что вы тестируете эти длинные пути, чтоб найти ошибки, которые пропустили более мелкие тесты.
Покрытие линий и ветвей кода Вы достигли 100% покрытия, если ваши тесты исполняют каждую линию или ветвь кода программы. Проектирование тестов для достижения покрытия называют "Тестирование основанное на покрытии" (После того, как вы достигли этого вы можете прекратить тестирование или прекратить создание новых тестов). Мы называем это покрытием строк и ветвей кода, чтоб отличить от других типов тестирования, основанных на покрытии. Покрытие конфигураций - отличный пример техники, которая проверяет один и тот же код несколько раз, но при этом все равно может потенциально привести к отличным результатам. Есть много других примеров. Для тестирования основанного на достижении высокого покрытия строк и ветвей кода характерно упущение многих видов ошибок, таких как(но не только) баги с участием пропущенного кода, баги некорректного обращения с граничными значениями, проблемы со временем, проблемы с совместимостью с железом и ПО, баги delayed-fuse, такие как дикие указатели, утечки памяти или stack corruption, которые в конечном счете ведут к переполнению стека, проблемы юзабилити и другие неисправности с точки зрения заказчика. Эта техника является более ценной в плане выявления неполноты тестирования (какой код сейчас не тестируется), как стандарт минимального необходимого объема тестирования. И в действительности опасно, если тестировщики останавливаются только потому, что они достигли определенного процента покрытия (Marick 1999).
Покрытие конфигураций Вам нужно протестировать совместимость 100 принтеров, а вы проверили 10, вы достигли 10% покрытия конфигураций. В общем виде, покрытие конфигураций означает процент конфигураций, на которых запускались и успешно прошли ваши тесты в сравнении с общим числом конфигураций, на котором вы запланировали запустить тесты. Почему мы назвали это техникой тестирования? Обычно мы считаем, что это просто мера - сколько определенных типов тестов мы повели. Однако сами тестировщики создают специальные серии тестов, которые работают с большим объемом конфигураций быстро и просто. В их руках оптимизация тестов для достижения большого покрытия становится техникой.
Тестирование спецификаций Тестирование, сфокусированное на каждом минимальном фактическом требовании к продукту, которое можно получить из спецификаций (Фактическое требование - это то, что для определенного состояния продукта может быть представлено в виде "да" или "нет"). Оно часто включает в себя проверку всех утверждений, сделанных в руководстве пользователя, рекламе, технической литературе или письме заказчику.
Тестирование требований Тестирование сфокусированное на том, насколько программа удовлетворяет требованиям (как вариант доказательство того, что требования выполнить нельзя).
Комбинированное тестирование Тестирование двух или более переменных в комбинации. Мы поговорим об этом позднее в этой главе. Это важный вид тестирования, но многие тестировщики пренебрегают им. Профит от программ обычно заключается как раз во взаимодействии множества переменных и если вы не не учитываете это в тестах, то имеете шанс пропустить множество ошибок, вызванных сочетанием значений нескольких переменных, а не значением одной.
Слово Канеру:
Техники тестирования основанные на том, что тестируется.
Тестирование репрезентативных значений Репрезентативные значения класса эквивалентности те, которые чаще приводили к ошибкам. В тестировании граничных значений - граничные значения всегда наиболее репрезентативны. Но предположим, что вы не можете отобразить класс эквивалентности на числовую ось. Например принтеры Hewlett-Packard PCL-5 являются классом эквивалентности, потому как должны работать одним и тем же образом. Теперь предположим, что для конкретной задачи один из принтеров имеет немного больше шансов заполучить проблему, чем другие. Это принтер и будет репрезентативным значением класса, и если он нас не подведет - не подведут и остальные.
Тестовая матрица для полей ввода Для каждого типа поля ввода ты можешь разработать достаточно стандартный набор кейсов и использовать их в этом и других продуктах. Пример мы приведем далее в этой главе.
Карта и проверка всех способов редактирования полей Часто есть возможность изменить значение переменной несколькими путями. Например, есть способ импортировать данные в поле, ввести значение напрямую, скопировать результат в поле, поле может программно вычисляться и перевычисляться автоматически и так далее. Поле имеет ограничения. Некоторые ограничения могут быть постоянными, друггие могут меняться в зависимости от значений в соседних полях. Например, если J и K - целые положительные числа, они ограничены значениями от 0 до MaxInt. Это постоянное ограничение, зависящее от языка программирования. Предположим, что N тоже положительное целое, N = J + K, и если N=5, то J = 5 − K, и J не может быть больше 5(значение N). Это меняющееся ограничение, чей диапазон допустимых значений зависит от N. Чтоб проверить, что J находится в диапазоне допустимых значений (5-K) мы должны попытаться изменить его значение в каждом возможном направлении.
Логическое тестирование Переменные имеют зависимости в программе. Например, в программе может быть правило, которое говорит, что если PERSON-AGE больше 50 и если SMOKER = YES, то OFFER-INSURANCE должно быть равно NO. Правило выражает логическую зависимость. Логическое тестирование пытается проверить все логические зависимости в программе. График причинно-следственных связей - техника проектирования широкого набора тестов основанных на логике системы.
Тестирование состояний Программа двигается от состояния к состоянию. В данном состоянии некоторые входные данные корректны, другие будут проигнорированы или отклонены. В ответ на валидные входные данные тестируемая программа делает то, что может и не пытается делать то, что не должна. В тестировании состояний мы ходим по программе согласно большому набору переходов между состояниями и тщательно проверяем результаты на каждом шаге.
Тестирование путей Путь включает все шаги, что ты совершил и все состояния через которые прошел, чтоб дойти до текущего состояния. Тестирование путей включает в себя тестирование множества путей в пhограмме. Нельзя проверить все пути в нетривиальной программе. Некоторые тестировщики проводят тестирование "подпутей" - тестирование частей пути. Тестирование базовых путей включает в себя все подпути одного типа, предполагая, что вы тестируете эти длинные пути, чтоб найти ошибки, которые пропустили более мелкие тесты.
Покрытие линий и ветвей кода Вы достигли 100% покрытия, если ваши тесты исполняют каждую линию или ветвь кода программы. Проектирование тестов для достижения покрытия называют "Тестирование основанное на покрытии" (После того, как вы достигли этого вы можете прекратить тестирование или прекратить создание новых тестов). Мы называем это покрытием строк и ветвей кода, чтоб отличить от других типов тестирования, основанных на покрытии. Покрытие конфигураций - отличный пример техники, которая проверяет один и тот же код несколько раз, но при этом все равно может потенциально привести к отличным результатам. Есть много других примеров. Для тестирования основанного на достижении высокого покрытия строк и ветвей кода характерно упущение многих видов ошибок, таких как(но не только) баги с участием пропущенного кода, баги некорректного обращения с граничными значениями, проблемы со временем, проблемы с совместимостью с железом и ПО, баги delayed-fuse, такие как дикие указатели, утечки памяти или stack corruption, которые в конечном счете ведут к переполнению стека, проблемы юзабилити и другие неисправности с точки зрения заказчика. Эта техника является более ценной в плане выявления неполноты тестирования (какой код сейчас не тестируется), как стандарт минимального необходимого объема тестирования. И в действительности опасно, если тестировщики останавливаются только потому, что они достигли определенного процента покрытия (Marick 1999).
Покрытие конфигураций Вам нужно протестировать совместимость 100 принтеров, а вы проверили 10, вы достигли 10% покрытия конфигураций. В общем виде, покрытие конфигураций означает процент конфигураций, на которых запускались и успешно прошли ваши тесты в сравнении с общим числом конфигураций, на котором вы запланировали запустить тесты. Почему мы назвали это техникой тестирования? Обычно мы считаем, что это просто мера - сколько определенных типов тестов мы повели. Однако сами тестировщики создают специальные серии тестов, которые работают с большим объемом конфигураций быстро и просто. В их руках оптимизация тестов для достижения большого покрытия становится техникой.
Тестирование спецификаций Тестирование, сфокусированное на каждом минимальном фактическом требовании к продукту, которое можно получить из спецификаций (Фактическое требование - это то, что для определенного состояния продукта может быть представлено в виде "да" или "нет"). Оно часто включает в себя проверку всех утверждений, сделанных в руководстве пользователя, рекламе, технической литературе или письме заказчику.
Тестирование требований Тестирование сфокусированное на том, насколько программа удовлетворяет требованиям (как вариант доказательство того, что требования выполнить нельзя).
Комбинированное тестирование Тестирование двух или более переменных в комбинации. Мы поговорим об этом позднее в этой главе. Это важный вид тестирования, но многие тестировщики пренебрегают им. Профит от программ обычно заключается как раз во взаимодействии множества переменных и если вы не не учитываете это в тестах, то имеете шанс пропустить множество ошибок, вызванных сочетанием значений нескольких переменных, а не значением одной.
пятница, 18 ноября 2011 г.
Lesson 50 (часть 1)
День сегодня какой-то неспокойный.
Процитирую Славу П.:
- Кто ее блин создает эту обстановку нервную, которая в проекте? Леша? По Леше можно приборы калибровать!
И еще сэра Терри:
- Нельзя сказать, что Витинари был расистом. Он одинаково ненавидел все расы.
(вроде так)
Слово Канеру:
Техники тестирования основанные на том, что тестируется.
Ты мог бы классифицировать эти техники по иному, как сфокусированные на проблемах, это зависит от того, что ты имеешь в виду, используя эту технику. Например, интеграционное тестирование фич - техника ориентированная на то, что тестируется, если ты используешь ее для проверки каждой фичи - тестирует поведение фичи в связке с другими. И оно же будет техникой, ориентированной на проблемы, если у вас есть идея или предположение о взаимодействии функций и вы хотите проверить эту идею. (Например, это будет тестирование ориентированное на проблемы, если ваша цель в демонстрации ошибки, которая возникает при передаче данных от одной функции к другой.)
Мы отводим много места тестированию областей определений функций в этой главе, так как основанные на этом техники широко используются и очень важны в нашей сфере. Вы должны знать это.
Функциональное тестирование Тестировать функции, одну за другой. Тестируйте функции тщательно, до такой степени, пока вы не сможете с уверенностью сказать, что функция работает. Функциональное тестирование методом белого ящика обычно называется юнит-тестированием и концентрируется на функциях в том виде, в каком мы их видим в коде. Функциональное тестирование черного ящика концентрируется на командах и фичах, которые видит или может использовать пользователь. Желательно проводить функциональное тестирование до того, как будут проводиться более сложные тесты, вовлекающие несколько функций. В сложных тестах первая сломавшаяся функция может остановить весь тест и не позволить вам искать ошибки дальше. Если вы полагаетесь на комплексные испытания, не используя тестирование отдельных функций, вы можете до самого конца не узнать, что одна из функций сломана и тратить огромное количество времени на поиск неисправности в сложном тесте для поиска неисправности в одной маленькой функции.
Интеграционное функциональное тестирование Тестирование совместной работы нескольких функций.
Хождение по меню Проход по всем пунктам меню в графическом интерфейсе пользователя, выбирая каждый пункт меню.
Тестирование областей определений данных Область определения переменной - математическое понятие, включающее все возможные значения переменной какой-либо функции. В тестировании областей определения ты определяешь функции и их переменные. Переменные могут быть входящими и исходящими (с точки зрения математики между ними разницы нет, в тестировании анализ проводится в обоих случаях). Для каждой переменной набор ее значений делится на классы эквивалентности и выбирается небольшой набор примеров (обычно граничных значений) для каждого класса. Допущение метода в том, что вы тестируя несколько примеров для каждого класса, вы можете найти все баги, которые вы нашли бы, тестируя все значения класса. Обратите внимание, что в отличие от функционального тестирования, мы тестируем переменные, а не функции. Многие переменные используются более, чем одной функцией. Тестировщик анализирует переменную, и затем, основываясь на этом анализе, проводит тесты, в которых переменная используется каждой функцией - на входе или на выходе.
Анализ классов эквивалентности Класс эквивалентности это набор значений переменной, которые вы рассматриваете как эквивалентные. Сценарии эквивалентны, если вы верите, что а) они тестируют одно и то же б) если один из них нашел баг, который, скорее всего, найдут и другие в) один из них не нашел баг, которые не найдут и другие. Как только вы нашли класс эквивалентности - протестируйте один или два его члена.
Тестирование граничных значений Класс эквивалентности это набор переменных. Если вы можете отразить их на числовой оси, то граничными значениями будут наибольшие и наименьшие значения класса. В тестировании граничных значений вы тестируете их, а также те граничные значения близлежащих классов, которые лишь ненамного меньше, чем наименьшее значение вашего класса и ненамного больше, чем наибольшее значение вашего класса. Рассмотрим поле ввода, принимающее целые значения от 10 до 50. Значения, представляющие интерес, это: 10(меньшее значение), 9(наибольшее неподходящее значение), 50(наибольшее), 51(наименьшее неподходящее).
Часть вторая
Процитирую Славу П.:
- Кто ее блин создает эту обстановку нервную, которая в проекте? Леша? По Леше можно приборы калибровать!
И еще сэра Терри:
- Нельзя сказать, что Витинари был расистом. Он одинаково ненавидел все расы.
(вроде так)
Слово Канеру:
Техники тестирования основанные на том, что тестируется.
Ты мог бы классифицировать эти техники по иному, как сфокусированные на проблемах, это зависит от того, что ты имеешь в виду, используя эту технику. Например, интеграционное тестирование фич - техника ориентированная на то, что тестируется, если ты используешь ее для проверки каждой фичи - тестирует поведение фичи в связке с другими. И оно же будет техникой, ориентированной на проблемы, если у вас есть идея или предположение о взаимодействии функций и вы хотите проверить эту идею. (Например, это будет тестирование ориентированное на проблемы, если ваша цель в демонстрации ошибки, которая возникает при передаче данных от одной функции к другой.)
Мы отводим много места тестированию областей определений функций в этой главе, так как основанные на этом техники широко используются и очень важны в нашей сфере. Вы должны знать это.
Функциональное тестирование Тестировать функции, одну за другой. Тестируйте функции тщательно, до такой степени, пока вы не сможете с уверенностью сказать, что функция работает. Функциональное тестирование методом белого ящика обычно называется юнит-тестированием и концентрируется на функциях в том виде, в каком мы их видим в коде. Функциональное тестирование черного ящика концентрируется на командах и фичах, которые видит или может использовать пользователь. Желательно проводить функциональное тестирование до того, как будут проводиться более сложные тесты, вовлекающие несколько функций. В сложных тестах первая сломавшаяся функция может остановить весь тест и не позволить вам искать ошибки дальше. Если вы полагаетесь на комплексные испытания, не используя тестирование отдельных функций, вы можете до самого конца не узнать, что одна из функций сломана и тратить огромное количество времени на поиск неисправности в сложном тесте для поиска неисправности в одной маленькой функции.
Интеграционное функциональное тестирование Тестирование совместной работы нескольких функций.
Хождение по меню Проход по всем пунктам меню в графическом интерфейсе пользователя, выбирая каждый пункт меню.
Тестирование областей определений данных Область определения переменной - математическое понятие, включающее все возможные значения переменной какой-либо функции. В тестировании областей определения ты определяешь функции и их переменные. Переменные могут быть входящими и исходящими (с точки зрения математики между ними разницы нет, в тестировании анализ проводится в обоих случаях). Для каждой переменной набор ее значений делится на классы эквивалентности и выбирается небольшой набор примеров (обычно граничных значений) для каждого класса. Допущение метода в том, что вы тестируя несколько примеров для каждого класса, вы можете найти все баги, которые вы нашли бы, тестируя все значения класса. Обратите внимание, что в отличие от функционального тестирования, мы тестируем переменные, а не функции. Многие переменные используются более, чем одной функцией. Тестировщик анализирует переменную, и затем, основываясь на этом анализе, проводит тесты, в которых переменная используется каждой функцией - на входе или на выходе.
Анализ классов эквивалентности Класс эквивалентности это набор значений переменной, которые вы рассматриваете как эквивалентные. Сценарии эквивалентны, если вы верите, что а) они тестируют одно и то же б) если один из них нашел баг, который, скорее всего, найдут и другие в) один из них не нашел баг, которые не найдут и другие. Как только вы нашли класс эквивалентности - протестируйте один или два его члена.
Тестирование граничных значений Класс эквивалентности это набор переменных. Если вы можете отразить их на числовой оси, то граничными значениями будут наибольшие и наименьшие значения класса. В тестировании граничных значений вы тестируете их, а также те граничные значения близлежащих классов, которые лишь ненамного меньше, чем наименьшее значение вашего класса и ненамного больше, чем наибольшее значение вашего класса. Рассмотрим поле ввода, принимающее целые значения от 10 до 50. Значения, представляющие интерес, это: 10(меньшее значение), 9(наибольшее неподходящее значение), 50(наибольшее), 51(наименьшее неподходящее).
Часть вторая
среда, 16 ноября 2011 г.
Lesson 49
Слово Канеру:
Техники тестирования основанные на людях
Вот некоторые примеры общих методов, зависящих от того, кто тестирует.
Пользовательское тестирование Тестирование с помощью тех типов людей, которые обычно пользуются вашим продуктом. Оно может быть проведено в любой момент разработки, на вашем или внешнем стенде, особое внимание уделяется мнению, опыту и особенностям пользователя. Некоторые типы пользовательского тестирования, такие как анализ задач, больше похожи на совместное исследование(с участием как минимум одного пользователя и как минимум одного тестировщика), чем на тестирование одним человеком.
Альфа-тест Внутреннее тестирование выполняется командой тестировщиков (и, возможно, других заинтересованных, дружественных инсайдеров).
Бета-тест Использует тестировщиков, которые не являются сотрудниками вашей организации, но являются целевой аудиторией вашего продукта. Продукт во время такого тестирования уже близок к готовности. Многие компании считают, что любой предварительный выпуск версии для клиентов это бета-тестирование. Они называют этап разработки "бета". Это ошибка. Действительно, есть много различных видов бета-тестирования. Бета тестирование дизайна, которое просит пользователей(особенно у экспертов) оценить дизайн продукта, должно пройти как можно раньше, для того, чтоб оставить время внести изменения по результатам тестирования. Маркетинговое бета-тестирование, которое необходимо для того, чтоб уверить крупных клиентов в том, что они должны купить продукт, когда он станет доступным и установить его в своей большой сети, должно выйти достаточно поздно, когда продукт будет уже стабилен. На бета-тесте совместимости заказчики запускают продукт в своем программном и аппаратном окружении - на том, которое вы бы не смогли протестировать самостоятельно. Этот вид тестирования важно провести до того как станет слишком поздно исправлять проблемы совместимости. Для любого вида бета-теста вы должны определить цели до того, как вы начнете планировать и выполнять что-либо.
Удар по багам Внутреннее тестирование с привлечением секретарей, программистов, маркетологов и всех, кого только можно. Обычно оно длится полдня и проводится когда продукт уже близок к релизу. (Замечание: мы описываем эту технику, но не одобряем ее, некоторые компании сочли эту технику полезной, другие нет).
Экспертное тестирование Дайте продукт экспертам в той или иной области ПО и получите от них фидбек (баги, критику и комплименты). Эксперт может быть, но может и не быть тем кто использует продукт - смысл в его знаниях, а не принадлежности к целевой аудитории.
Парное тестирование Два тестировщика ищут баги вместе. Как правило, они используют один компьютер и передают друг другу контроль во время тестирования.
Попробуйте корм вашей собаки Ваша компания может использовать в своей работе релизную или предрелизную версию своего продукта, обычно происходит ожидание того момента, когда продукт будет достаточно надежен, чтоб продать его.
Техники тестирования основанные на людях
Вот некоторые примеры общих методов, зависящих от того, кто тестирует.
Пользовательское тестирование Тестирование с помощью тех типов людей, которые обычно пользуются вашим продуктом. Оно может быть проведено в любой момент разработки, на вашем или внешнем стенде, особое внимание уделяется мнению, опыту и особенностям пользователя. Некоторые типы пользовательского тестирования, такие как анализ задач, больше похожи на совместное исследование(с участием как минимум одного пользователя и как минимум одного тестировщика), чем на тестирование одним человеком.
Альфа-тест Внутреннее тестирование выполняется командой тестировщиков (и, возможно, других заинтересованных, дружественных инсайдеров).
Бета-тест Использует тестировщиков, которые не являются сотрудниками вашей организации, но являются целевой аудиторией вашего продукта. Продукт во время такого тестирования уже близок к готовности. Многие компании считают, что любой предварительный выпуск версии для клиентов это бета-тестирование. Они называют этап разработки "бета". Это ошибка. Действительно, есть много различных видов бета-тестирования. Бета тестирование дизайна, которое просит пользователей(особенно у экспертов) оценить дизайн продукта, должно пройти как можно раньше, для того, чтоб оставить время внести изменения по результатам тестирования. Маркетинговое бета-тестирование, которое необходимо для того, чтоб уверить крупных клиентов в том, что они должны купить продукт, когда он станет доступным и установить его в своей большой сети, должно выйти достаточно поздно, когда продукт будет уже стабилен. На бета-тесте совместимости заказчики запускают продукт в своем программном и аппаратном окружении - на том, которое вы бы не смогли протестировать самостоятельно. Этот вид тестирования важно провести до того как станет слишком поздно исправлять проблемы совместимости. Для любого вида бета-теста вы должны определить цели до того, как вы начнете планировать и выполнять что-либо.
Удар по багам Внутреннее тестирование с привлечением секретарей, программистов, маркетологов и всех, кого только можно. Обычно оно длится полдня и проводится когда продукт уже близок к релизу. (Замечание: мы описываем эту технику, но не одобряем ее, некоторые компании сочли эту технику полезной, другие нет).
Экспертное тестирование Дайте продукт экспертам в той или иной области ПО и получите от них фидбек (баги, критику и комплименты). Эксперт может быть, но может и не быть тем кто использует продукт - смысл в его знаниях, а не принадлежности к целевой аудитории.
Парное тестирование Два тестировщика ищут баги вместе. Как правило, они используют один компьютер и передают друг другу контроль во время тестирования.
Попробуйте корм вашей собаки Ваша компания может использовать в своей работе релизную или предрелизную версию своего продукта, обычно происходит ожидание того момента, когда продукт будет достаточно надежен, чтоб продать его.
суббота, 12 ноября 2011 г.
Lesson 48
Уже часть третья.
Слово Канеру:
Тестирование сочетает в себе людей, объекты, способы, потенциальные проблемы и оценку.
Главная цель этой части - показать систему классификации техник тестирования. Мы называем это пятью измерениями тестирования. Любой вид тестирования описывается в терминах пяти измерений:
- Тестировщики. Те, кто занимается теcтированием. Например, пользовательское тестирование фокусируется на тестировании силами целевой аудитории, теми, кто обычно использует продукт.
- Покрытие. То, что тестируется. Например, в функциональном тестировании мы тестируем каждую функцию.
- Потенциальные проблемы. Почему мы тестируем (какие риски мы проверяем). Например, тестирование на ошибку с максимальными значениями.
- Активности. Как вы тестируете. Например, исследовательское тестирование.
- Оценка. Как определить, что тест прошел или сработал. Например, сравнение с известным правильным результатом.
Также мы детально описали несколько техник в этой части и понимание того, как использовать еще несколько других, но наша главная цель - объяснить систему классификации.
Во всех тестах есть все пять измерений. Техника тестирования фокусирует ваше внимание на одном из пяти измерений, обходя другие. Вы могли бы комбинировать технику, которая сфокусирована на одном измерении с техникой, которая сфокусирована на другом для достижения требуемого результата. Вы могли бы назвать результат этого действия новой техникой тестирования (некоторые так и делают), но мы думаем, что процесс мышления более полезен, чем добавление новых имен в постоянно расширяющийся перечень непоследовательно определенных техник, используемый в нашей области. Наша схема классификации поможет комбинировать сознательно и вдумчиво.
Задачи тестирования часто концентрируются на одном измерении, но мы работаем во всех пяти. Например:
- Кто-то может попросить вас сделать функциональное тестирование (тщательно поверить все функции). Это говорит вам, что тестировать. Вы все еще должны решить, кто будет тестировать, какие типы багов вы будете искать, как тестировать каждую функцию, и как вы будете определять, что в программе есть ошибка.
- Кто-то может попросить вас повести тестирование "предельных значений" (тест, на ошибки, появляющиеся, когда мы вводим экстремальное значение переменной). Это говорит нам, какой тип проблем мы будем искать. Но нам до сих пор нужно решить, кто тестирует, какие переменные мы будем поверять, и как мы оценим результаты.
- Кто-то может попросить нас заняться бета-тестированием (если есть внешние потребители вашего продукта). Это говорит вам, кто будет тестировать, на какие проблемы вы будете обращать внимание (и какие игнорировать). В некоторых случаях, вы могли бы сообщить бета-тестерам, как распознавать определенные типы проблем, а также попросить их выполнить определенные тесты и пойти определенным путем. В других бета-тестах, вы могли бы оставить на усмотрение бета-тестеров и оценку результатов.
Техники не обязательно соответствуют какому-то одному измерению. Они и не должны: любое тестирование включает все пять измерений, и мы должны ждать от техник тестирования более глубокого охвата измерений.
Вот пример того, как техника может быть многомерной: если кто-то вас просит провести тестирование основанное на требованиях, он говорит тебе о комбинации трех идей:
- Покрытие: мы тестируем все, что описано в требованиях.
- Потенциальные проблемы: тестировать в направлениях, на которых эти требования могут быть не выполнены.
- Оценка: тесты будут спроектированы так, что спецификация будет определять ожидаемое поведение программы.
Разные тестировщики подразумевают разные комбинации этих идей, когда говорят: "тестирование по требованиям". Нет "правильного" понимания этой фразы.
Несмотря на двусмысленность (и, в некоторой степени, благодаря ей), мы находим нашу классификацию хорошим генератором идей.
Сохраняя во время тестирования в голове все пять измерений, вы можете подобрать лучший выбор комбинаций. Например, в бета-тестировании вы могли бы жестко не оговаривать одно или несколько измерений. Вы могли бы не определять способ оценки результатов или последовательности действий. Однако мы предлагаем, чтоб вы сознательно сделали этот выбор, приняв саму технику, а не сосредотачиваясь на каком-либо из аспектов.
Ремарка: неоднозначное понимание тестирования по требованиям дает нам пример главной проблемы в разработке ПО.
Слово Канеру:
Тестирование сочетает в себе людей, объекты, способы, потенциальные проблемы и оценку.
Главная цель этой части - показать систему классификации техник тестирования. Мы называем это пятью измерениями тестирования. Любой вид тестирования описывается в терминах пяти измерений:
- Тестировщики. Те, кто занимается теcтированием. Например, пользовательское тестирование фокусируется на тестировании силами целевой аудитории, теми, кто обычно использует продукт.
- Покрытие. То, что тестируется. Например, в функциональном тестировании мы тестируем каждую функцию.
- Потенциальные проблемы. Почему мы тестируем (какие риски мы проверяем). Например, тестирование на ошибку с максимальными значениями.
- Активности. Как вы тестируете. Например, исследовательское тестирование.
- Оценка. Как определить, что тест прошел или сработал. Например, сравнение с известным правильным результатом.
Также мы детально описали несколько техник в этой части и понимание того, как использовать еще несколько других, но наша главная цель - объяснить систему классификации.
Во всех тестах есть все пять измерений. Техника тестирования фокусирует ваше внимание на одном из пяти измерений, обходя другие. Вы могли бы комбинировать технику, которая сфокусирована на одном измерении с техникой, которая сфокусирована на другом для достижения требуемого результата. Вы могли бы назвать результат этого действия новой техникой тестирования (некоторые так и делают), но мы думаем, что процесс мышления более полезен, чем добавление новых имен в постоянно расширяющийся перечень непоследовательно определенных техник, используемый в нашей области. Наша схема классификации поможет комбинировать сознательно и вдумчиво.
Задачи тестирования часто концентрируются на одном измерении, но мы работаем во всех пяти. Например:
- Кто-то может попросить вас сделать функциональное тестирование (тщательно поверить все функции). Это говорит вам, что тестировать. Вы все еще должны решить, кто будет тестировать, какие типы багов вы будете искать, как тестировать каждую функцию, и как вы будете определять, что в программе есть ошибка.
- Кто-то может попросить вас повести тестирование "предельных значений" (тест, на ошибки, появляющиеся, когда мы вводим экстремальное значение переменной). Это говорит нам, какой тип проблем мы будем искать. Но нам до сих пор нужно решить, кто тестирует, какие переменные мы будем поверять, и как мы оценим результаты.
- Кто-то может попросить нас заняться бета-тестированием (если есть внешние потребители вашего продукта). Это говорит вам, кто будет тестировать, на какие проблемы вы будете обращать внимание (и какие игнорировать). В некоторых случаях, вы могли бы сообщить бета-тестерам, как распознавать определенные типы проблем, а также попросить их выполнить определенные тесты и пойти определенным путем. В других бета-тестах, вы могли бы оставить на усмотрение бета-тестеров и оценку результатов.
Техники не обязательно соответствуют какому-то одному измерению. Они и не должны: любое тестирование включает все пять измерений, и мы должны ждать от техник тестирования более глубокого охвата измерений.
Вот пример того, как техника может быть многомерной: если кто-то вас просит провести тестирование основанное на требованиях, он говорит тебе о комбинации трех идей:
- Покрытие: мы тестируем все, что описано в требованиях.
- Потенциальные проблемы: тестировать в направлениях, на которых эти требования могут быть не выполнены.
- Оценка: тесты будут спроектированы так, что спецификация будет определять ожидаемое поведение программы.
Разные тестировщики подразумевают разные комбинации этих идей, когда говорят: "тестирование по требованиям". Нет "правильного" понимания этой фразы.
Несмотря на двусмысленность (и, в некоторой степени, благодаря ей), мы находим нашу классификацию хорошим генератором идей.
Сохраняя во время тестирования в голове все пять измерений, вы можете подобрать лучший выбор комбинаций. Например, в бета-тестировании вы могли бы жестко не оговаривать одно или несколько измерений. Вы могли бы не определять способ оценки результатов или последовательности действий. Однако мы предлагаем, чтоб вы сознательно сделали этот выбор, приняв саму технику, а не сосредотачиваясь на каком-либо из аспектов.
Ремарка: неоднозначное понимание тестирования по требованиям дает нам пример главной проблемы в разработке ПО.
Подписаться на:
Сообщения (Atom)