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