Две тысячи километров в этом году. Нужно больше.
Поехали:
Слайд 97
Проблема в том, что нет гарантированных механизмов проверки корректности результатов теста. Вместо этого, каждый раз, сравнивая результат теста с ожидаемым поведением, мы выносим приговор. Любой наш приговор подвержен ошибкам. Это наша реальность.
Содержимое слайда
Необходимость суждений.
Когда мы описываем тестирование как процесс сравнения эмпирических результатов с ожидаемыми, мы должны учитывать, что процесс сравнения требует принятия человеком решения, основанного на понимании предметной области.
Слайд 98
Если вы посмотрите на стандарты проектирования ПО, такие как IEEE 829, вы заметите, что каждый тест кейс должен быть полностью описан. Он должен включать все входные данные, включая ожидаемый результат и тестовое окружение.
Слайд 99
Но как описать ваше тестовое окружение?
Это скриншот моего диспетчера задач. Все эти процессы находятся в памяти. Большинство запускается, когда я включаю компьютер. У меня нет даже идеи о том, какой как узнать версию всех этих программ. программы, запущенные параллельно с тестируемой могут влиять на ее поведение. Они могут конфликтовать за доступ к ресурсам, работать медленней вместе или даже использовать один и тот же участок памяти.
За годы работы я наблюдал достаточно случаев, когда мы трассировали проблему до программ, находящихся в памяти. Очевидно, это может относиться к любому тесту.
Редко можно увидеть тест, который описывает все версии программ, находящихся в памяти. И подобная спецификация будет бессмысленной, так как любая из этих программ может быть обновлена без вашего ведома.
Поехали:
Слайд 97
Проблема в том, что нет гарантированных механизмов проверки корректности результатов теста. Вместо этого, каждый раз, сравнивая результат теста с ожидаемым поведением, мы выносим приговор. Любой наш приговор подвержен ошибкам. Это наша реальность.
Содержимое слайда
Необходимость суждений.
Когда мы описываем тестирование как процесс сравнения эмпирических результатов с ожидаемыми, мы должны учитывать, что процесс сравнения требует принятия человеком решения, основанного на понимании предметной области.
Слайд 98
Если вы посмотрите на стандарты проектирования ПО, такие как IEEE 829, вы заметите, что каждый тест кейс должен быть полностью описан. Он должен включать все входные данные, включая ожидаемый результат и тестовое окружение.
Слайд 99
Но как описать ваше тестовое окружение?
Это скриншот моего диспетчера задач. Все эти процессы находятся в памяти. Большинство запускается, когда я включаю компьютер. У меня нет даже идеи о том, какой как узнать версию всех этих программ. программы, запущенные параллельно с тестируемой могут влиять на ее поведение. Они могут конфликтовать за доступ к ресурсам, работать медленней вместе или даже использовать один и тот же участок памяти.
За годы работы я наблюдал достаточно случаев, когда мы трассировали проблему до программ, находящихся в памяти. Очевидно, это может относиться к любому тесту.
Редко можно увидеть тест, который описывает все версии программ, находящихся в памяти. И подобная спецификация будет бессмысленной, так как любая из этих программ может быть обновлена без вашего ведома.
Комментариев нет:
Отправить комментарий