Как насчет подтверждения функциональности в положительных тестах, доказать, что она работает - я должен сказать, что это пустая трата времени? Какая концепция стоит за этой цитатой?
Неудачные тесты, то есть тесты, которые не находят ошибок, являются пустой тратой времени.
Веб-инжиниринг: Дисциплина систематической разработки веб-приложений, цитируя Cem Kaner .
Ответы:
Я написал большую часть «Тестирование компьютерного программного обеспечения» более 25 лет назад. С тех пор я указал на несколько частей книги, которые я считаю устаревшими или просто неправильными. Смотрите http://www.kaner.com/pdfs/TheOngoingRevolution.pdf
Вы можете увидеть больше (текущие просмотры, но без явных указателей на TCS) на моем сайте для курса тестирования программного обеспечения Black Box (видео и слайды доступны бесплатно), www.testingeducation.org/BBST
Культура тестирования тогда была в значительной степени подтверждающей.
В современном тестировании подход к модульному тестированию в значительной степени подтверждает - мы пишем большие наборы автоматических тестов, которые просто проверяют, что программное обеспечение продолжает работать как задумано. Тесты служат детекторами изменений - если что-то в других частях кода и в этой части теперь имеет проблемы, или если значения данных, которые раньше были невозможны в реальном мире, теперь достигают приложения, то детекторы изменений срабатывают, оповещая программист к проблеме обслуживания.
Я думаю, что подтверждающее мышление подходит для модульного тестирования, но представьте себе мир, в котором все тестирование системы было подтверждающим (для людей, которые делают различие, пожалуйста, интерпретируйте «тестирование интеграции системы» и «приемочное тестирование» как включенные в мои комментарии к системе). тестирование.) Цель тестирования состояла в том, чтобы подтвердить, что программа соответствовала своим спецификациям, и доминирующий подход заключался в создании большого количества (или, по крайней мере, нескольких сотен) регрессионных тестов системного уровня, которые отображали части спецификации на поведение программы. (Я думаю, что подтверждение от спецификации к поведению полезно, но я думаю, что это небольшая часть более крупной цели.)
Есть еще тестовые группы, которые работают таким образом, но это больше не доминирующий взгляд. Тогда это было. Я решительно писал и делал резкие контрасты, чтобы подчеркнуть мнение людей, которые постоянно обучались этому мышлению. Сегодня некоторые острые контрасты (включая приведенный здесь) устарели. Их неправильно истолковывают как атаки на неправильные взгляды.
На мой взгляд, тестирование программного обеспечения - это эмпирический процесс для изучения связанной с качеством информации о программном продукте или услуге.
Тест должен быть разработан для выявления полезной информации.
Тогда, кстати, никто не говорил о тестировании как о методе выявления «информации». В то время тестирование проводилось либо для (некоторой версии ...) поиска ошибок, либо для (некоторой версии ...) проверки (проверки) программы на соответствие спецификациям. Я не думаю, что утверждение, что тесты предназначены для выявления полезной информации, вошло в словарь тестирования до этого столетия.
Представьте себе рейтинговые тесты с точки зрения их информационной ценности. Тест, который, скорее всего, научит нас чему-то, чего мы не знаем о программном обеспечении, будет иметь очень высокую информационную ценность. Тест, который с большой вероятностью подтвердит то, что мы уже ожидаем и который уже был продемонстрирован много раз ранее, имел бы низкую информационную ценность. Один из способов определения приоритетов тестов - запуск тестов с более высоким информационным значением перед тестами с более низким информационным значением.
Если бы я упростил эту расстановку приоритетов, чтобы она привлекла внимание программиста, менеджера проекта или менеджера процесса, который не имеет никакого понятия о тестировании программного обеспечения, я бы сказал: «ТЕСТ, КОТОРЫЙ НЕ ПРЕДНАЗНАЧЕН ДЛЯ ВЫЯВЛЕНИЯ БАГА, - ТРАТА ВРЕМЕНИ». «. Это не идеальный перевод, но для читателей, которые не могут или не будут понимать какую-либо тонкость или квалификацию, это настолько близко, насколько это возможно.
Тогда, и я вижу это снова здесь, некоторые из людей, которые не понимают тестирование, ответили бы, что тест, предназначенный для поиска угловых случаев, является пустой тратой времени по сравнению с тестом основного использования основной функции. Они не понимают две вещи. Во-первых, к тому времени, когда тестеры находят время для проверки граничных значений, основные виды использования основных функций уже выполнялись несколько раз. (Да, есть исключения, и большинство тестовых групп будут обращать особое внимание на эти исключения.) Во-вторых, причина для тестирования с экстремальными значениями заключается в том, что программа с большей вероятностью потерпит неудачу с экстремальными значениями. Если это не терпит неудачу в крайности, вы проверяете что-то еще. Это эффективное правило. С другой стороны, если он ДЕЙСТВИТЕЛЬНО терпит неудачу при экстремальном значении, тестер может остановиться и сообщить об ошибке, или тестер может продолжить поиск неисправностей, чтобы увидеть, не выходит ли программа из строя таким же образом при более нормальных значениях. Кто устраняет неисправности (тестировщик или программист) - это вопрос корпоративной культуры. Некоторые компании выделяют на это время тестировщика, некоторые - программистов, а некоторые ожидают, что программисты исправят ошибки в каждом конкретном случае независимо от того, являются ли они обобщенными или нет, чтобы устранение неполадок не относилось к делу. Распространенное заблуждение о том, что тестеры тратят время (а не максимизируют эффективность) на тестирование экстремальных значений, является еще одной причиной того, что «тест, не предназначенный для выявления ошибки, является пустой тратой времени» - это подходящее сообщение для тестировщиков. Это противоположность поощрения некоторых программистов (по сути) никогда не запускать тесты, которые могут поставить под сомнение программу. Сообщение слишком упрощено, но все обсуждение упрощено.
Кстати, «информационная ценность» не может быть единственной системой приоритизации. Это не мое правило, когда я разрабатываю юнит-тесты. Это не мое правило, когда я проектирую тесты проверки сборки (или проверки работоспособности). В обоих этих случаях меня больше интересуют типы покрытия, чем сила отдельных тестов. Есть и другие случаи (например, автоматические тесты большого объема, которые дешевы в настройке, запуске и мониторинге), когда мощность отдельных тестов просто не имеет отношения к моей конструкции. Я уверен, что вы можете придумать дополнительные примеры.
Но, как правило, если бы я мог сформулировать только одно правило (например, поговорить с руководителем, чья голова взорвется, если он попытается обработать более одного предложения), то тест с низкой информационной ценностью обычно является пустой тратой времени.
источник
По словам Канера, идея заключается в том, что «поскольку у вас не хватит времени, прежде чем закончатся тестовые случаи, важно использовать доступное время как можно более эффективно».
Концепция, лежащая в основе цитаты, о которой вы спрашиваете, представлена и подробно объяснена в статье Джема Фалька, Хунг Куок Нгуена, в статье «Цели тестирования компьютерного программного обеспечения» , в главе «ЦЕЛИ И ОГРАНИЧЕНИЯ ТЕСТИРОВАНИЯ»:
Вы видите, суть в том, что вы должны расставить приоритеты в тестировании с умом. Ожидается, что тестирование займет ограниченное количество времени, и невозможно протестировать все за указанное время.
Представьте, что вы провели день (неделю, месяц), выполняя тесты, не находя ошибок и позволяя какой-то ошибке проскользнуть, потому что у вас не было времени запустить тест, который выявил бы ее. Если это произойдет, вы не можете просто сказать «это не моя вина, потому что я был занят проведением других тестов», чтобы оправдать этот промах - если вы так говорите, вы все равно будете нести ответственность.
Вы потратили время на выполнение тестов, которые не выявили ошибок, и из-за этого вы пропустили тест, который обнаружил бы ошибку.
(В случае , если вы задаетесь вопросом , как скучает выше , не являются вообще неизбежны , независимо от того , как вы пытаетесь, и есть способы борьбы с ними, но это было бы еще тема для отдельного вопроса ... и , возможно , лучше подходит для SQA. SE) .
источник
Ну, я не знаю, мистер Канер, но имхо
пустая трата времени. Это включает в себя ситуацию, когда у вас уже есть несколько тестов (не имеет значения, являются ли они автоматическими или просто в контрольном списке), и вы добавляете новые тесты, которые проверяют, по существу, те же самые случаи, которые у вас уже есть. Таким образом, ваши новые тесты не найдут больше ошибок, чем существующие.
Такая ситуация может случиться, например, если вы просто просматриваете список случайным образом - я мог бы сказать также «бездумно» (простите мне это слово) - выбирали тестовые примеры в вашей программе, не думая, проверяют ли они новый граничный случай, новую эквивалентность классы ваших входных данных, или если они увеличивают покрытие кода по сравнению с уже написанными тестами.
источник
На мой взгляд, эта цитата относится к слишком общим или unrobusts тестам.
Если вы выполняете тест для функции, которая проверяет электронную почту, а в тесте вы предоставляете только действительные электронные письма, этот тест совершенно бесполезен. Вам нужно было бы проверить эту функцию на наличие «любой» возможной строки, недействительных писем, слишком длинных писем, символов Юникод (символы ....)
Если вы кодируете тест, который проверяет только то, что name@dom.com возвращает true, а name @ com возвращает false, этот тест не отличается от теста вообще.
источник