Почему Джем Канер считает, что тест не показывает ошибку - пустая трата времени?

15

Как насчет подтверждения функциональности в положительных тестах, доказать, что она работает - я должен сказать, что это пустая трата времени? Какая концепция стоит за этой цитатой?

Неудачные тесты, то есть тесты, которые не находят ошибок, являются пустой тратой времени.

Веб-инжиниринг: Дисциплина систематической разработки веб-приложений, цитируя Cem Kaner .

Джон V
источник
2
На самом деле, нет. Канер утверждает, что в целом тестирование должно просто найти дефекты.
Джон V
4
Это очень академическая позиция. Мистер Канер и мистер Шредингер должны когда-нибудь сесть выпить чашку кофе.
Blrfl
2
Единственная проблема @Blrfl в том, что мистер Шредингер мертв. Ой, подожди ... хм ...
ikmac
1
Это утверждение без контекста звучит безумно глупо ...
Rig
1
«Подтверждение функциональности в положительных тестах» - это принципиально невозможно. Вы не можете доказать что-то правильное, вы можете только доказать, что это неправильно.
Конрад Рудольф

Ответы:

37

Я написал большую часть «Тестирование компьютерного программного обеспечения» более 25 лет назад. С тех пор я указал на несколько частей книги, которые я считаю устаревшими или просто неправильными. Смотрите http://www.kaner.com/pdfs/TheOngoingRevolution.pdf

Вы можете увидеть больше (текущие просмотры, но без явных указателей на TCS) на моем сайте для курса тестирования программного обеспечения Black Box (видео и слайды доступны бесплатно), www.testingeducation.org/BBST

Культура тестирования тогда была в значительной степени подтверждающей.

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

Я думаю, что подтверждающее мышление подходит для модульного тестирования, но представьте себе мир, в котором все тестирование системы было подтверждающим (для людей, которые делают различие, пожалуйста, интерпретируйте «тестирование интеграции системы» и «приемочное тестирование» как включенные в мои комментарии к системе). тестирование.) Цель тестирования состояла в том, чтобы подтвердить, что программа соответствовала своим спецификациям, и доминирующий подход заключался в создании большого количества (или, по крайней мере, нескольких сотен) регрессионных тестов системного уровня, которые отображали части спецификации на поведение программы. (Я думаю, что подтверждение от спецификации к поведению полезно, но я думаю, что это небольшая часть более крупной цели.)

Есть еще тестовые группы, которые работают таким образом, но это больше не доминирующий взгляд. Тогда это было. Я решительно писал и делал резкие контрасты, чтобы подчеркнуть мнение людей, которые постоянно обучались этому мышлению. Сегодня некоторые острые контрасты (включая приведенный здесь) устарели. Их неправильно истолковывают как атаки на неправильные взгляды.

На мой взгляд, тестирование программного обеспечения - это эмпирический процесс для изучения связанной с качеством информации о программном продукте или услуге.

Тест должен быть разработан для выявления полезной информации.

Тогда, кстати, никто не говорил о тестировании как о методе выявления «информации». В то время тестирование проводилось либо для (некоторой версии ...) поиска ошибок, либо для (некоторой версии ...) проверки (проверки) программы на соответствие спецификациям. Я не думаю, что утверждение, что тесты предназначены для выявления полезной информации, вошло в словарь тестирования до этого столетия.

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

Если бы я упростил эту расстановку приоритетов, чтобы она привлекла внимание программиста, менеджера проекта или менеджера процесса, который не имеет никакого понятия о тестировании программного обеспечения, я бы сказал: «ТЕСТ, КОТОРЫЙ НЕ ПРЕДНАЗНАЧЕН ДЛЯ ВЫЯВЛЕНИЯ БАГА, - ТРАТА ВРЕМЕНИ». «. Это не идеальный перевод, но для читателей, которые не могут или не будут понимать какую-либо тонкость или квалификацию, это настолько близко, насколько это возможно.

Тогда, и я вижу это снова здесь, некоторые из людей, которые не понимают тестирование, ответили бы, что тест, предназначенный для поиска угловых случаев, является пустой тратой времени по сравнению с тестом основного использования основной функции. Они не понимают две вещи. Во-первых, к тому времени, когда тестеры находят время для проверки граничных значений, основные виды использования основных функций уже выполнялись несколько раз. (Да, есть исключения, и большинство тестовых групп будут обращать особое внимание на эти исключения.) Во-вторых, причина для тестирования с экстремальными значениями заключается в том, что программа с большей вероятностью потерпит неудачу с экстремальными значениями. Если это не терпит неудачу в крайности, вы проверяете что-то еще. Это эффективное правило. С другой стороны, если он ДЕЙСТВИТЕЛЬНО терпит неудачу при экстремальном значении, тестер может остановиться и сообщить об ошибке, или тестер может продолжить поиск неисправностей, чтобы увидеть, не выходит ли программа из строя таким же образом при более нормальных значениях. Кто устраняет неисправности (тестировщик или программист) - это вопрос корпоративной культуры. Некоторые компании выделяют на это время тестировщика, некоторые - программистов, а некоторые ожидают, что программисты исправят ошибки в каждом конкретном случае независимо от того, являются ли они обобщенными или нет, чтобы устранение неполадок не относилось к делу. Распространенное заблуждение о том, что тестеры тратят время (а не максимизируют эффективность) на тестирование экстремальных значений, является еще одной причиной того, что «тест, не предназначенный для выявления ошибки, является пустой тратой времени» - это подходящее сообщение для тестировщиков. Это противоположность поощрения некоторых программистов (по сути) никогда не запускать тесты, которые могут поставить под сомнение программу. Сообщение слишком упрощено, но все обсуждение упрощено.

Кстати, «информационная ценность» не может быть единственной системой приоритизации. Это не мое правило, когда я разрабатываю юнит-тесты. Это не мое правило, когда я проектирую тесты проверки сборки (или проверки работоспособности). В обоих этих случаях меня больше интересуют типы покрытия, чем сила отдельных тестов. Есть и другие случаи (например, автоматические тесты большого объема, которые дешевы в настройке, запуске и мониторинге), когда мощность отдельных тестов просто не имеет отношения к моей конструкции. Я уверен, что вы можете придумать дополнительные примеры.

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

Джем Канер
источник
4
+1 нашли время , чтобы ответить на вопрос , который вы находитесь авторитетный источник, а также проверки мое использование термина «Строительства по проверке тестов» , которые так много людей смотрят на меня смешно для использования ... Всегда приятно видеть людей , вашего роста и времени, чтобы помочь людям здесь
Джимми Хоффа
1
Эрик Дж .: Думаю, если вы перечитаете, то увидите, что Джем заявляет, что как часть читателей понимает, что его взгляд на эту тему со временем изменился. Или вы можете просто продолжать и игнорировать тонкости и квалификации, перефразируя Cem. (и я принимаю «квалификации» не как его полномочия, а как исключения.)
Джим Холмс
Ваша цитата напоминает мне кое-что, что я наблюдал о науке: никто не может доказать (или даже осмысленно поддержать) научную теорию, проводя эксперименты, которые, как ожидают, дадут результаты, согласующиеся с теорией; способ поддержать теорию состоит в том, чтобы приложить добросовестные усилия к экспериментам с устройствами, которые не поддерживают ее, но не могут этого сделать.
Суперкат
@supercat, вы можете поддержать теорию с помощью теста для чего-то, что согласуется с теорией, если тест не пришел бы к вам раньше теории (например, показать ускорение падения объекта в вакууме, как если бы вы рассчитали его как говорит больше, чем показывает, что он падает). Краевые тесты аналогичны; Я мог бы ожидать, что программное обеспечение будет вести себя правильно при работе с экстремальными значениями, но оно дает больше уверенности в качестве, чтобы увидеть это, чем повторять входные значения, которые оно, вероятно, наблюдало во время разработки, наряду с большей вероятностью найти ошибку.
Джон Ханна
@JonHanna: моя формулировка была плохой: проблема не в ожидании, а в усилии. Невозможно доказать теорию, пытаясь найти тесты, которые она пройдет; Нужно приложить добросовестные усилия, чтобы найти тесты, которые он потерпит неудачу, если окажется недействительным
суперкат
11

По словам Канера, идея заключается в том, что «поскольку у вас не хватит времени, прежде чем закончатся тестовые случаи, важно использовать доступное время как можно более эффективно».

Концепция, лежащая в основе цитаты, о которой вы спрашиваете, представлена ​​и подробно объяснена в статье Джема Фалька, Хунг Куок Нгуена, в статье «Цели тестирования компьютерного программного обеспечения» , в главе «ЦЕЛИ И ОГРАНИЧЕНИЯ ТЕСТИРОВАНИЯ»:

ТАК, ПОЧЕМУ ТЕСТ?

Вы не можете найти все ошибки. Вы не можете доказать правильность программы, и вы не хотите. Это дорого, расстраивает и не выигрывает конкурсы популярности. Итак, зачем тестировать?

ЦЕЛЬ ИСПЫТАНИЯ ПРОГРАММЫ - НАЙТИ ПРОБЛЕМЫ В ЭТОМ

Поиск проблем - это суть вашей работы. Вы должны хотеть найти как можно больше; чем серьезнее проблема, тем лучше.

Поскольку у вас не хватит времени, прежде чем закончатся тестовые случаи, важно использовать доступное время как можно более эффективно. В главах 7, 8, 12 и 13 подробно рассматриваются приоритеты. Руководящий принцип можно выразить просто:


Тест, который выявляет проблему, является успехом. Тест, который не выявил проблемы, был пустой тратой времени.


Рассмотрим следующую аналогию из Myers (1979). Предположим, что с вами что-то не так. Вы идете к врачу. Он должен проводить тесты, выяснять, что не так, и рекомендовать корректирующие действия. Он запускает тест за тестом после теста. В конце концов, он не может найти ничего плохого. Он отличный тестер или некомпетентный диагност? Если вы действительно больны, он некомпетентен, и все эти дорогостоящие тесты были пустой тратой времени, денег и усилий. В программном обеспечении вы диагност. Программа (безусловно) больной пациент ...


Вы видите, суть в том, что вы должны расставить приоритеты в тестировании с умом. Ожидается, что тестирование займет ограниченное количество времени, и невозможно протестировать все за указанное время.

Представьте, что вы провели день (неделю, месяц), выполняя тесты, не находя ошибок и позволяя какой-то ошибке проскользнуть, потому что у вас не было времени запустить тест, который выявил бы ее. Если это произойдет, вы не можете просто сказать «это не моя вина, потому что я был занят проведением других тестов», чтобы оправдать этот промах - если вы так говорите, вы все равно будете нести ответственность.

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

(В случае , если вы задаетесь вопросом , как скучает выше , не являются вообще неизбежны , независимо от того , как вы пытаетесь, и есть способы борьбы с ними, но это было бы еще тема для отдельного вопроса ... и , возможно , лучше подходит для SQA. SE) .

комар
источник
12
Этот ответ правильно отражает его позицию, но стоит отметить, что многие считают его позицию неправильной. Учитывая выбор между тестом, который демонстрирует наиболее важную функцию в приложении, работает правильно (приемочное тестирование, если хотите) и тестом, который обнаруживает тривиальную ошибку (выравнивание на один пиксель) в редко используемом углу приложения, я знаю, что я бы выбрал в свое ограниченное время. И для аналогии с врачом: если я иду на проверку, а не в ответ на симптомы, я подтверждаю, что сердце хорошо, легкие хороши и т. Д. И т. Д. - это хороший результат. Здесь.
Кейт Грегори
@KateGregory Я согласен, я думаю то же самое. Я убежденно считаю, что его мнение неверно, мы проводим тестирование, главным образом, для сбора информации.
Джон V
2
@KateGregory согласен - я не думаю, что это правильно - пометить любой пройденный тест как полный отход. Хотя, я думаю, что одно из его замечаний - вне времени : если ошибка проходит тестирование релиза, QA потребуется нечто большее, чем «о, но мы были заняты выполнением других тестов», чтобы прикрыть их спину. В прошлом я сам проходил через это как тестировщик, и теперь вижу, что я - разработчик, и я не думаю, что это когда-нибудь исчезнет
комнат
4

Ну, я не знаю, мистер Канер, но имхо

тесты, которые потенциально не находят ошибок

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

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

Док Браун
источник
-1

На мой взгляд, эта цитата относится к слишком общим или unrobusts тестам.

Если вы выполняете тест для функции, которая проверяет электронную почту, а в тесте вы предоставляете только действительные электронные письма, этот тест совершенно бесполезен. Вам нужно было бы проверить эту функцию на наличие «любой» возможной строки, недействительных писем, слишком длинных писем, символов Юникод (символы ....)

Если вы кодируете тест, который проверяет только то, что name@dom.com возвращает true, а name @ com возвращает false, этот тест не отличается от теста вообще.

Хуанми Родригес
источник