Home

Автор: Алан Ричардсон (Alan Richardson)
Оригинал статьи
Перевод: Ольга Алифанова

Краткое содержание: для испытаний системы в тестировании используются модели, и наша информация ограничена теми моделями, которые мы используем и строим. Мы можем варьировать их, чтобы увеличить вероятность нахождения информации, связанной с багами. Надо быть осторожными, чтобы не впасть в ложную уверенность.

Заметки о тестировании, вдохновленные цитатами Акоффа, Эшби, Дейкстры и Вайнберга.

Баги

"Дейкстра: Тестирование показывает наличие, а не отсутствие багов".

Конференция разработки программного обеспечения НАТО, 1969 г.

Как нам могут помочь такие утверждения?

Мы можем подумать "Что нам сделать, чтобы продемонстрировать наличие багов?"

И… Что такое "баги"?

Баги могут означать, что "это не всегда работает так, как мне нужно".

Проблема: Оно вообще работает?

Что значит "работает"?

Нам надо определить, что значит "работает" – и это можно сделать через модель взаимодействия.

Мы можем смоделировать взаимодействие ПО с внешним интеграционным компонентом – пользователем или другой системой.

Я могу смоделировать или определить "работу" так: "ПО работает, если у меня есть цель, и я могу использовать ПО для достижения этой цели".

Я могу определить цель и "использовать ПО" способом, который, по моему мнению, подойдет для достижения этой цели. Если я увижу, что цель достигнута, тогда оно "работает". Но… я не могу сказать, что оно всегда работает, из-за:

• Специфической версии ПО
• Специфического пользовательского взаимодействия.
• Специфической конфигурации окружения
• Специфических данных.

Если изменится любая из этих переменных, могу ли я быть уверен, что ПО продолжит работать?

• Что, если мои наблюдения были ложными?
• Что, если я недостаточно глубоко всматривался в систему, чтобы увидеть проблему?

Я наблюдал за отдельным проявлением "работы", но я не могу экстраполировать это и сказать, что оно работает всегда.

"С самого начала было понятно, что тестирование довольно неэффективно в качестве способа повышения уверенности".

"Дисциплина программирования", Эдсгер В. Дейкстра.

Модели

Когда мы тестируем, мы сравниваем модель системы с самой системой.

Когда я говорю "с системой", я имею в виду "со своими наблюдениями или нашим восприятием реальности системы".

Мы можем использовать фокус на "наблюдении" в качестве рычага, помогающего нам улучшать наше тестирование.

• Настолько ли мы понимаем технологию, чтобы наблюдать за всеми ее уровнями?
• Понимаем ли мы, как приложение использует технологию, достаточно хорошо, чтобы заметить возникновение проблемы?
• Есть ли у нас инструментарий, позволяющий наблюдать за системой на более глубоком уровне технологии? К примеру, для веб-тестирования – XHR-запросы, HTTP-трафик, использование куки, использование локального хранилища, памяти, и т. д.

Тестирование – это процесс моделирования, а не "решения" или "доказательства". Я смоделировал взаимодействие в определенный момент времени, и в результате тестирования я получил исправленную версию системы.

Для тех путей, в которых проблем не наблюдалось, я усилил модель, пометив, что в этой части приложения снижена субъективная вероятность ошибок – это значит, что я не встретил проблем и теперь сильнее убежден, что оно "работает".

Я могу приравнять это к повышению уверенности. Если я приравниваю это к уверенности, то могу начать думать о моей модели системы, как о реальной системе, а о ПО – как о "беспроблемном".

Как тестировщик, я должен сохранять скептицизм по отношению к системе. Самый простой способ этого добиться – осознавать, что я строю модель системы и взаимодействую с моделью системы, а не работаю с "реальной системой".

"Экстремальный скептицизм – единственный верный подход".

"Основы компьютерного программирования", Герберт Лидс, Джеральд Вайнберг. Глава 11 – тестирование программ.

Что нужно, чтобы показать присутствие багов?

"Тестирование может быть довольно эффективным для демонстрации присутствия багов, но безнадежно неадекватно для демонстрации их отсутствия".

С. 20 "Дисциплины программирования", Эдсгер В. Дейкстра.

Найдите данные, взаимодействие, путь через систему и варьируйте их.

Если мы будем использовать одни и те же данные, взаимодействия и пути, мы не максимизируем свою возможность "продемонстрировать присутствие багов". Вместо этого мы повышаем риск ложного повышения "уверенности".

"Теории можно тестировать, используя данные прошлого, настоящего и будущего, в результате прогрессивно улучшая их. Однако используемые для тестирования теории данные должны отличаться от тех, которые породили теорию".

С. 73 "Концепции корпоративного планирования", Рассел Л. Экофф, 1969

При помощи варьирования мы можем наткнуться на комбинацию переменных, демонстрирующую присутствие багов. Почему?

"Только вариативность может уничтожить вариативность".

"Введение в Кибернетику", У. Росс Эшби (11/7), 1964

Мы используем вариации, чтобы найти такую комбинацию ввода, при которой система не варьирует результаты обработки, и результат попадает в пределы толерантности нашего оракула.

Но тут есть проблемы:

• При повышении вариативности и отсутствии проблем "уверенность" может возрасти.
• Мы можем ввести такую высокую вариативность, что оракул, с которым мы сравниваем наши наблюдения, не покрывает масштабы вариаций – то есть мы не знаем, а что тут должно происходить.
• Мы можем ограничить вариативность пределами оракула, и, следовательно, искусственно снизить вероятность нахождения проблемы, в то же время повышая "уверенность".

Достаточно, чересчур

Один из ключевых вопросов тестирования – какого уровня вариативности достаточно? Это одна из самых сложных штук в тестировании. Как узнать, когда остановиться?

Ряд эвристик для этого:

• Когда мы чувствуем, что дальнейшие действия не приносят ценности.
• Когда время вышло.
• Когда мы перестаем узнавать что-то новое – все наши наблюдения усиливают модель, а не расширяют ее и не заставляют ее пересмотреть.
• Когда что-то другое получило более высокий приоритет.
• Когда мы достигли обговоренного покрытия.

Легче сказать, когда не надо останавливаться.

• Когда все, что мы использовали – это данные из примеров.
• Когда мы всего один раз продемонстрировали совпадение с оракулом.
• Когда наше наблюдение было поверхностным, а не глубоким технологическим – что, если оно только с виду "работает"?
• Когда мы даже не покрыли обговоренные приемочные критерии и примеры.
• Когда мы не взялись за противоречия в приемочных критериях.

Автоматизация уверенности

Автоматизация зачастую используется как инструмент повышения уверенности.

"Если мы прогоним автотесты, и все работает, то мы, как минимум, ничего не сломали".

Если мы понимаем, что это верно в пределах:

• Данных на входе
• Методов взаимодействия
• Наблюдений
• Сравнения с оракулом,

то мы можем добавить в автоматизацию вариативности.

"Данные на входе" кажутся простейшей точкой внедрения вариаций. Оставьте путь и метод взаимодействия без изменений, и варьируйте данные. Нам часто приходится ограничивать вариации в данных оракулом, что в целом означает рандомный выбор значений из набора классов эквивалентности, или исчерпывающее тестирование с набором входных значений.

Идентификация ограничений данных на входе может привести к обнаружению новых путей или пробелов в покрытии оракула.

Мы несем риск упустить что-то за пределами наборов данных, или же неверного определения классов эквивалентности. Этот риск существует, потому что мы моделируем, а не решаем задачу. Тестирование ограничено моделью, и наши оценки ей ограничены.

Риск еще в том, что это занимает много времени, поэтому варьирующиеся тесты можно прогонять параллельно прочим автотестам.

Мы несем риск генерации большого объема вариаций. Затем нам нужно убедить себя, что вариации не нужны, или определить, где они могут нам помочь, пересмотрев существующее покрытие автотестами в свете вариаций, которые мы хотим внедрить. Но надо быть осторожными, чтобы последующие изменения не повлияли и не обесценили нашу оценку.

Если в автотестах нет вариаций, мы создали фиксированную модель приложения, и должны быть бдительными и скептичными к ее покрытию. Этот скептицизм может привести к более частому пересмотру автотестов и проверки, что они покрывают достаточную часть модели системы. Относитесь к ним, как к "дырявой страховочной сетке", а не к "увеличителю уверенности".

Тестирование

Я могу смотреть на тестирование, как на процесс построения и сравнения модели.

Мы стараемся повысить вероятность нахождения значимой информации. Вариации помогают нам в этом. Будьте осторожны, используя тестирование для повышения уверенности, сохраняйте здоровый скептицизм.

Обсудить в форуме