Советы по поиску в вашей программе вещей, которые не работают, о которых вы не знаете?
Сегодня я работал над чем-то для клиента, когда нашел способ нарушить некоторые функции в нашей программе.
(Код действительно унаследован, он разрабатывался около 10 лет, а я работаю здесь только около года.)
Это не вызвало ошибки или не привело к сбою программы, но если пользователь использовал программу и продублировал ее поведение, я почти уверен, что они задержали бы свой "WTF?" флаг.
В нашей программе мы назвали поля (текстовые поля) и статический текст (метки), которые можно связать с текстовыми полями. Когда текстовое поле не заполнено, ярлыки, связанные с ними, исчезают.
Функциональность, которую я нарушил, заключалась в том, что когда вы изменяете имя текстового поля, которое уже имеет одну или несколько меток, связанных с ним, и сохраняете файл, без повторного связывания одной или нескольких меток, связанных с текстовым полем, ранее связанных меток появляются, когда текстовое поле пустое.
Теперь я думаю о том, что простой шаблон наблюдателя мог бы решить эту проблему в первую очередь, но тогда я не писал код.
Я думал, что, если бы я мог выкопать больше подобных ситуаций с ребятами из моего магазина, что, возможно, я мог бы уговорить их рассмотреть возможность модульного тестирования, развязки, применения шаблонов там, где они нужны, и тому подобное.
Поэтому по этой причине мне было интересно, есть ли у кого-нибудь какие-либо советы по поиску неисправной (но не вызывающей ошибки) функциональности в каком-либо приложении (веб-приложение, рабочий стол и т. Д.)
10 ответов
Чтобы приложение не работало, оно должно иметь определенный набор ожидаемых поведений.
Msgstr "Это текстовое поле ПРЕДПОЛАГАЕТСЯ ничего не делать при нажатии клавиши ввода?" Может быть, а может и нет. Я видел приложения, в которых тестировщик / рецензент сообщает о том, что они предполагают, что он должен работать по-другому, когда на самом деле клиент специально спрашивал, что он не хочет, чтобы форма отправлялась нажатием клавиши возврата, а только нажатием кнопки отправки.
Поэтому в основном вы должны определить правильное поведение, прежде чем сможете определить неправильное поведение.
Проверка кода, то есть чтение исходного кода: если вы потратили время на чтение / проверку исходного кода, в поисках "запахов" или даже просто в поиске кода, поведение которого вы не сразу понимаете и с которым не согласны, возможно, вы придерживались ваш "WTF?" флаг тоже.
Если у него есть интерфейс, то один из моих любимых нетрадиционных тестов - ставить перед ним детей 5-10 лет. Вы будете удивлены тем, что они могут придумать (особенно младшие). Хотя это может звучать как шутка, это не так - это действительно работает, потому что у детей нет ума только идти по пути "мышления".
И да, дети являются экспертами в "ломать вещи" XP.
Вы можете обнаружить, что соединения / сеансы базы данных не освобождаются:
- отработать минимальное количество соединений, которые нужно сделать
- установление ограничений на ресурсы для этого минимального числа
- обеспечение одного "запуска" сценария, который должен использовать именно это число (и выпустить его позже)
- затем запустите его снова несколько раз... у вас закончились соединения?
Раньше я работал в компании, где программисты регулярно забывали об отмене выделения соединений с БД. Стандартный ответ состоял в том, чтобы уменьшить ресурс до минимума, чтобы увидеть, есть ли утечка - и попытаться выяснить, где он находится, перезапустив систему и неоднократно запустив различные сценарии.
Первый час проверки кода с первым рецензентом сделает все возможное, чтобы найти проблемы с качеством. Но вот в чем дело: вам не нужно убеждать людей в проблемах с качеством. Вы должны убедить их в ценности исправления ошибок и переписывания только в том случае, если нынешнее качество абсолютно оправдывает это.
Я имел дело с каким-то серьезно плохим кодом в свое время. Но вы не можете просто переписать. Вам нужна спецификация, прежде чем вы сможете даже сказать, является ли переписывание улучшением.
Иногда вам нужно вывести спецификацию из кода, а затем сравнить ее с каким-нибудь человеком. Но к тому времени, когда вы это сделаете, вы поймете, что код написан, и теперь лучше подготовлены к исправлению, чем к переписыванию - большую часть времени.
Восстановление выполняется путем небольших изменений, сохраняющих поведение, которые делают спецификацию более понятной в коде. Затем, когда вы находите что-то, что выглядит неправильно, вы не просто меняете это. Вы спрашиваете, пока не найдете человека, ответственного за это решение, и попросите его показать вам, где в спецификации указано, что поведение X является правильным. (Этот разговор может принимать разные формы.) Если вам повезет, они скажут вам, что поведение X на самом деле неверно, и тогда вы заработали свою зарплату.
Тест, тест, тест.
Делай неожиданные вещи. Начните выполнять одно задание и переключите другое, чтобы увидеть, что-нибудь не получится. Используйте кнопку назад, когда вы не должны. Откройте его в двух окнах. Позвольте этому время.
Тестируйте во всех браузерах, особенно в IE.
Обзоры кода всегда должны включать обзоры кода модульного теста.
Проблема в том, что при специальном тестировании невозможно узнать, насколько хорошо разработчик тестировал свой код. Итак, вы во власти разных разработчиков определения слова "готово".
Если вы включаете проверку кода модульного теста одновременно с проверкой рабочего кода, у вас должно быть хорошее представление о том, действительно ли код завершен; в это "полное" входит "проверенное". Не просто "Эй, я перекину через стену тестерам!".
Это особенно относится к Visual Studio IDE, хотя, вероятно, также относится и к другим:
Во время тестирования всегда в какой-то момент запускайте в отладчике с включенным параметром "Разорвать при возникновении исключения".
Это часто может помочь выявить исключения, которые неправильно перехвачены и которые представляют ошибки, но в противном случае могут быть неочевидны.