Давненько не было переводов. Надо наверстывать.
Поехали:
Урок 252
Мы можем посчитать все возможные пути используя правила, которые мы изучили несколько слайдов назад.
Допустим, переменная V1 содержит все возможные пути от A до X. Их пять.
Теперь допустим, что переменная V2 содержит все пути от A до X, включающие петлю.
Их 25 если мы пройдем петлю дважды. Из 125 если мы пройдем петлю трижды.
Если у нас будет возможность пройти петлю 20 раз, то мы получим больше 100 триллионов последовательностей.
Урок 253
Очевидно, что все эти пути проверить нельзя.
Большинство людей проверит 5 путей от A до X. Затем добавит случай двадцатикратного прохождения петли по одному и тому же пути.
Этот тест проверит все ветви, все простые пути программы. Но будет ли его достаточно?
Допустим, у нас есть утечка памяти на определенном шаге программы. Если мы пройдем его 10 раз подряд, то программа упадет с переполнением. Если только мы не тестируем, используя мониторинг памяти, мы не заметим утечки, пока программа не начнет себя некорректно вести, например медленно работать или падать. И этот баг обнаружит только тест, проходящий через определенный шаг 10 раз. Тест, проходящий любое количество раз через другие шаги не обнаружит этот дефект.
Если у вас нет подозрений на утечку памяти, как много тестов вы проведете, пока не пройдете определенный шаг программы 10 раз и не обнаружите проблему? Их может быть очень много.
Позвольте мне усложнить ситуацию. Допустим на другом пути есть шаг, вызывающий очистку памяти. И он чистит память, утекшую благодаря багу. Теперь программа упадет только в том случае, если мы 10 раз прошли по одному блоку и ни разу не прошли по второму.
Только небольшой процент из 100 триллионов тестов обнаружит этот баг, так что у вас должна быть или большая выборка или большое везение, чтоб найти этот баг.
Допустим, что случай еще более особенный и очистка памяти - наиболее вероятный путь использования программы.
Как вы думаете, в таком случае, вы вообще создадите тест, который сможет найти этот дефект?
Урок 254
Когда я задаю этот вопрос, студенты обычно отвечают "нет". Так говорят очень опытные и профессиональные тестировщики. Если вы говорите нет, что этот тест слишком сложный, слишком редкий и специфический, то вы в хорошей компании.
Итак просуммируем. Я показал вам, что вы не сможете проверить все возможные пути. И продемонстрировал случай, при котором, в теории, вы пропустите серьезный баг.
Но многие люди считают этот случай нереалистичным. Он никогда не случится в реальной жизни и представляет лишь академический интерес.
Отличный момент вспомнить правило о редких случаях. "Никто не будет этого делать" не означает, что никто не будет этого делать. Это значит "Никто, кого я сейчас могу себе представить не имеет причин, которые я сейчас могу себе представить, чтоб так сделать".
Тестирование - опыт скромности, оно раз за разом показывает нам, как на самом деле ограничено наше воображение.
Поехали:
Урок 252
Мы можем посчитать все возможные пути используя правила, которые мы изучили несколько слайдов назад.
Допустим, переменная V1 содержит все возможные пути от A до X. Их пять.
Теперь допустим, что переменная V2 содержит все пути от A до X, включающие петлю.
Их 25 если мы пройдем петлю дважды. Из 125 если мы пройдем петлю трижды.
Если у нас будет возможность пройти петлю 20 раз, то мы получим больше 100 триллионов последовательностей.
Урок 253
Очевидно, что все эти пути проверить нельзя.
Большинство людей проверит 5 путей от A до X. Затем добавит случай двадцатикратного прохождения петли по одному и тому же пути.
Этот тест проверит все ветви, все простые пути программы. Но будет ли его достаточно?
Допустим, у нас есть утечка памяти на определенном шаге программы. Если мы пройдем его 10 раз подряд, то программа упадет с переполнением. Если только мы не тестируем, используя мониторинг памяти, мы не заметим утечки, пока программа не начнет себя некорректно вести, например медленно работать или падать. И этот баг обнаружит только тест, проходящий через определенный шаг 10 раз. Тест, проходящий любое количество раз через другие шаги не обнаружит этот дефект.
Если у вас нет подозрений на утечку памяти, как много тестов вы проведете, пока не пройдете определенный шаг программы 10 раз и не обнаружите проблему? Их может быть очень много.
Позвольте мне усложнить ситуацию. Допустим на другом пути есть шаг, вызывающий очистку памяти. И он чистит память, утекшую благодаря багу. Теперь программа упадет только в том случае, если мы 10 раз прошли по одному блоку и ни разу не прошли по второму.
Только небольшой процент из 100 триллионов тестов обнаружит этот баг, так что у вас должна быть или большая выборка или большое везение, чтоб найти этот баг.
Допустим, что случай еще более особенный и очистка памяти - наиболее вероятный путь использования программы.
Как вы думаете, в таком случае, вы вообще создадите тест, который сможет найти этот дефект?
Урок 254
Когда я задаю этот вопрос, студенты обычно отвечают "нет". Так говорят очень опытные и профессиональные тестировщики. Если вы говорите нет, что этот тест слишком сложный, слишком редкий и специфический, то вы в хорошей компании.
Итак просуммируем. Я показал вам, что вы не сможете проверить все возможные пути. И продемонстрировал случай, при котором, в теории, вы пропустите серьезный баг.
Но многие люди считают этот случай нереалистичным. Он никогда не случится в реальной жизни и представляет лишь академический интерес.
Отличный момент вспомнить правило о редких случаях. "Никто не будет этого делать" не означает, что никто не будет этого делать. Это значит "Никто, кого я сейчас могу себе представить не имеет причин, которые я сейчас могу себе представить, чтоб так сделать".
Тестирование - опыт скромности, оно раз за разом показывает нам, как на самом деле ограничено наше воображение.
Комментариев нет:
Отправить комментарий