Откатались в Старую линзу. Туда и обратно.
Фотки: Как и зачем на на экскаватор надели покрышку? Она не разрезана.
Общий план:
Там есть откачивающий воду насос. А рядом - водопад:
Вблизи:
Стены карьера состоят из таких вот уступчиков:
А еще там есть адская бензопила, коорую обронил дредноут из вархаммера:
Только она работает не на бензине, а на суровости:
В целом - рекомендую .
Компания - мое почтение, четыре айтишника и сопровождающий их врач-педиатр.
70 километров туда и обратно.
Поехали.
Введение в лекцию.
Эта лекция расскажет об оракулах. Классический взгляд на оракулы говорит о том, что это механизм, позволяющий определить прошла ли программа тест. Например смотри Miller & Howden 1978 или википедию. Вместе с этим классически считается, что тестировщик может (или должен) иметь оракула для каждого теста.
Эта лекция представит различные точки зрения. В идеале, вы узнаете о трех вариантах:
1. Ни у одного теста не может быть настоящего оракула. В лучшем случае у нас есть приближение, которое можно использовать. Мы считаем, что Elaine Weyuker (1980) первый автор этой точки зрения. Douglas Hoffman (1998) опубликовал диаграммы, иллюстрирующие корень проблемы. Мы ждем, что вы поймете и запомните диаграммы и выводы.Когда вы создаете тест, вы примерно представляете, что ПО должно делать и ожидаете от него соответствующего поведения. Но ваши спецификации неполны.
Не обязательно описаны все аспекты аппаратного и программного окружения до и после теста. К примеру, как часто вы описываете степень фрагментации памяти компьютера до и после теста? Поэтому оракулы можно использовать, хотя они могут и ошибаться: программа может пройти тест, но вести себя некорректно в области, не описанной вами. Правило, подверженное ошибкам, но которое при этом можно использовать называется эвристикой. Все оракулы являются эвристиками.
2. Мы можем описать процесс принятия решения о том, прошла ли программа тест, как результат работы некоторых широко используемых компараторов. Например, вы можете решить, что программа провалила тест, так как ее поведение не консистентно тому, как программа вела себя раньше или неконсистентна тому, как программа кажется нам, что должна себя вести или неконсистентно тому, как программа должна себя вести согласно спецификации. Мы ждем, что студенты изучат эвристики консистентности, описанные Bolton (2005) Тестирование без карты.
3. Полезно использовать большой набор специфичных оракулов для поддержки автоматизации. Если программа предполагает вычисление квадратного корня из 4 и в результате дает 3, а не 2, это баг. Когда ты тестируешь программу, вычисляющую квадратный корень, ты можешь использовать другую программу, вычисляющую квадратный корень, которой ты доверяешь. У вас есть возможность делать обратную операцию, чтоб проверить корректность извлечения корня. Ни один из этих тестов не является исчерпывающим, программа может упасть в точке, не покрытой этими тестами, но каждый из этих тестов описывает специфическое сравнение, которое может быть автоматизировано. в лекции будет показано много примеров подобных оракулов.
Самая серьезная слабость этой лекции в абсолютизации (1) и (2) относительно (3). Эвристики консистентности достаточны, так как они описывают и классифицируют большинство (может быть все) типы оракулов. Но они являются обобщением. Они не дают деталей для проектирования тестов, которые можно использовать для автоматизации. Мы вернемся к конкретным оракулам в вопросах и гайдах.
Литература:
Следующая литература обязательна к прочтению:
Фотки: Как и зачем на на экскаватор надели покрышку? Она не разрезана.
Высота граффити метров десять:
Там есть откачивающий воду насос. А рядом - водопад:
А еще там есть адская бензопила, коорую обронил дредноут из вархаммера:
В целом - рекомендую .
Компания - мое почтение, четыре айтишника и сопровождающий их врач-педиатр.
70 километров туда и обратно.
Поехали.
Введение в лекцию.
Эта лекция расскажет об оракулах. Классический взгляд на оракулы говорит о том, что это механизм, позволяющий определить прошла ли программа тест. Например смотри Miller & Howden 1978 или википедию. Вместе с этим классически считается, что тестировщик может (или должен) иметь оракула для каждого теста.
Эта лекция представит различные точки зрения. В идеале, вы узнаете о трех вариантах:
1. Ни у одного теста не может быть настоящего оракула. В лучшем случае у нас есть приближение, которое можно использовать. Мы считаем, что Elaine Weyuker (1980) первый автор этой точки зрения. Douglas Hoffman (1998) опубликовал диаграммы, иллюстрирующие корень проблемы. Мы ждем, что вы поймете и запомните диаграммы и выводы.Когда вы создаете тест, вы примерно представляете, что ПО должно делать и ожидаете от него соответствующего поведения. Но ваши спецификации неполны.
Не обязательно описаны все аспекты аппаратного и программного окружения до и после теста. К примеру, как часто вы описываете степень фрагментации памяти компьютера до и после теста? Поэтому оракулы можно использовать, хотя они могут и ошибаться: программа может пройти тест, но вести себя некорректно в области, не описанной вами. Правило, подверженное ошибкам, но которое при этом можно использовать называется эвристикой. Все оракулы являются эвристиками.
2. Мы можем описать процесс принятия решения о том, прошла ли программа тест, как результат работы некоторых широко используемых компараторов. Например, вы можете решить, что программа провалила тест, так как ее поведение не консистентно тому, как программа вела себя раньше или неконсистентна тому, как программа кажется нам, что должна себя вести или неконсистентно тому, как программа должна себя вести согласно спецификации. Мы ждем, что студенты изучат эвристики консистентности, описанные Bolton (2005) Тестирование без карты.
3. Полезно использовать большой набор специфичных оракулов для поддержки автоматизации. Если программа предполагает вычисление квадратного корня из 4 и в результате дает 3, а не 2, это баг. Когда ты тестируешь программу, вычисляющую квадратный корень, ты можешь использовать другую программу, вычисляющую квадратный корень, которой ты доверяешь. У вас есть возможность делать обратную операцию, чтоб проверить корректность извлечения корня. Ни один из этих тестов не является исчерпывающим, программа может упасть в точке, не покрытой этими тестами, но каждый из этих тестов описывает специфическое сравнение, которое может быть автоматизировано. в лекции будет показано много примеров подобных оракулов.
Самая серьезная слабость этой лекции в абсолютизации (1) и (2) относительно (3). Эвристики консистентности достаточны, так как они описывают и классифицируют большинство (может быть все) типы оракулов. Но они являются обобщением. Они не дают деталей для проектирования тестов, которые можно использовать для автоматизации. Мы вернемся к конкретным оракулам в вопросах и гайдах.
Литература:
Следующая литература обязательна к прочтению:
- Bolton M. (2005, январь) Тестирование без карты.
- Kelly M. (2006) Использование эвристических оракулов тестирования.
- Koen B. (2011) Инженерный метод и эвристики: Персональная история.
- Weyker E. (1982) Тестирование не тестируемых программ.
Комментариев нет:
Отправить комментарий