Намедни испытал немного радости и хорошего настроения.
Отцепляю велик от парковки у спортэка, подходит мужичок, начинает выяснять за то, какой у меня велосипед, аккие стоит брать, что на них вешать и все такое.
Я рассказываю и ненавязчиво так намекаю, что вот тут за дверями магазина томятся в одиночестве минимум три консультанта, у них можно послушать, потрогать товар и незамедлительно приобрести. Специалисты и вообще.
Мужичок и говорит в том смысле, что неизвестно, что там внутри в тепле сидят за люди, а по мне видно, что я явно катать люблю и умею, ибо кто еще будет по снегу в 11 в воскресенье рассекать?
Приятно, черт побери.
Поехали.
Урок 5. Невозможность завершения тестирования.
Введение.
В пятом уроке мы рассмотрим, что мы понимаем под достижением полного тестирования. Четвертая лекция дала понимание концепции покрытия. Некоторые люди пришли к нам на курс, считая, что тестирование будет полным, если они достигнут 100% структурного покрытия. Этот урок продемонстрирует им, как серьезно они ошибаются.
Мы ждем, что вы запомните на этом уроке шесть вещей:
Два ключевых определения:
- два теста отличаются, если один находит баг, а другой нет
- чтоб достичь полного тестирования нужно провести все отличающиеся тесты
Два ключевых примера:
- В примере MASPAR для функции извлечения корня пришлось прогнать 4294967296 тестов, чтоб найти два бага.
- В примере переполнения стека Telenova покрыть все ветви, операторы и независимые подпути невозможно. Для воспроизведения убивающего систему бага тестировщику нужно создать последовательность такую длинную и сложную, что ее создание практически невозможно.Видеолекция обращает внимане на то, что персонал Telenova в конечном счете создал эмулятор который передает программе длинные случайно сгенерированные последовательности и диагностирует состояние системы. Они нашли много других багов, используя этот вид тестирования, таких которые лишь иногда воспроизводятся в боевых условиях, но при этом достаточно серьезных. В лекции мы рассмотрим диаграммы последовательностей. Они похожи на знаменитые диаграммы Glen Myers из книги Искусство тестирования ПО. Myers что проверка всех последовательностей на примере простой программы потребует больш 100 триллионов тестов. Для поиска бага Telenova понаюдобится еще больше тестов.
Одна ключевая формула:
Если у нас есть V(1-k) (k независимых переменных) и если N1 это число возможных значений Vi, то количество комбинаций тестов на все переменные составит N1*N2*...*Nk
Один вывод:
Полное тестирование невозможно, поэтому все тестирование состоит из компромиссов. Тестирование включает в себя множество задач, таких как проектирование и проведение тестов, написание эффективных багрепортов, документирование идей тестирования, создание инструментов и так далее. Они требуют времени значительно больше, чем у тестировщиков есть. У вас есть время только на то, чтоб проделать небольшую часть этой работы и время, которое вы потратите на одну задачу будет потеряно для остальных. Негибкие приказы наподобие "вы должны написать все ожидаемые результаты для каждого теста" бессмысленны, так как они требуют отвлечь много времени всего на одну задачу тестирования, без рассмотрения того, что остальные задачи сделаны не будут. Оптимальный баланс будет меняться от проекта к проекту.
Отцепляю велик от парковки у спортэка, подходит мужичок, начинает выяснять за то, какой у меня велосипед, аккие стоит брать, что на них вешать и все такое.
Я рассказываю и ненавязчиво так намекаю, что вот тут за дверями магазина томятся в одиночестве минимум три консультанта, у них можно послушать, потрогать товар и незамедлительно приобрести. Специалисты и вообще.
Мужичок и говорит в том смысле, что неизвестно, что там внутри в тепле сидят за люди, а по мне видно, что я явно катать люблю и умею, ибо кто еще будет по снегу в 11 в воскресенье рассекать?
Приятно, черт побери.
Поехали.
Урок 5. Невозможность завершения тестирования.
Введение.
В пятом уроке мы рассмотрим, что мы понимаем под достижением полного тестирования. Четвертая лекция дала понимание концепции покрытия. Некоторые люди пришли к нам на курс, считая, что тестирование будет полным, если они достигнут 100% структурного покрытия. Этот урок продемонстрирует им, как серьезно они ошибаются.
Мы ждем, что вы запомните на этом уроке шесть вещей:
Два ключевых определения:
- два теста отличаются, если один находит баг, а другой нет
- чтоб достичь полного тестирования нужно провести все отличающиеся тесты
Два ключевых примера:
- В примере MASPAR для функции извлечения корня пришлось прогнать 4294967296 тестов, чтоб найти два бага.
- В примере переполнения стека Telenova покрыть все ветви, операторы и независимые подпути невозможно. Для воспроизведения убивающего систему бага тестировщику нужно создать последовательность такую длинную и сложную, что ее создание практически невозможно.Видеолекция обращает внимане на то, что персонал Telenova в конечном счете создал эмулятор который передает программе длинные случайно сгенерированные последовательности и диагностирует состояние системы. Они нашли много других багов, используя этот вид тестирования, таких которые лишь иногда воспроизводятся в боевых условиях, но при этом достаточно серьезных. В лекции мы рассмотрим диаграммы последовательностей. Они похожи на знаменитые диаграммы Glen Myers из книги Искусство тестирования ПО. Myers что проверка всех последовательностей на примере простой программы потребует больш 100 триллионов тестов. Для поиска бага Telenova понаюдобится еще больше тестов.
Одна ключевая формула:
Если у нас есть V(1-k) (k независимых переменных) и если N1 это число возможных значений Vi, то количество комбинаций тестов на все переменные составит N1*N2*...*Nk
Один вывод:
Полное тестирование невозможно, поэтому все тестирование состоит из компромиссов. Тестирование включает в себя множество задач, таких как проектирование и проведение тестов, написание эффективных багрепортов, документирование идей тестирования, создание инструментов и так далее. Они требуют времени значительно больше, чем у тестировщиков есть. У вас есть время только на то, чтоб проделать небольшую часть этой работы и время, которое вы потратите на одну задачу будет потеряно для остальных. Негибкие приказы наподобие "вы должны написать все ожидаемые результаты для каждого теста" бессмысленны, так как они требуют отвлечь много времени всего на одну задачу тестирования, без рассмотрения того, что остальные задачи сделаны не будут. Оптимальный баланс будет меняться от проекта к проекту.
Комментариев нет:
Отправить комментарий