Советы по поиску в вашей программе вещей, о которых вы ничего не знаете?

Question

Я работал над чем-то для клиента сегодня, когда нашел способ нарушить некоторые функции в нашей программе.

(Код на самом деле является устаревшим кодом, он разрабатывался около 10 лет, и я работаю здесь только около года.)

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

В нашей программе мы назвали поля (текстовые поля) и статический текст (метки), которые можно связать с текстовыми полями. Если текстовое поле не заполнено, ярлыки, связанные с ними, исчезают.

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

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

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

Поэтому по этой причине мне было интересно, есть ли у кого-нибудь советы по поиску неисправной (но не вызывающей ошибки) функциональности в каком-либо приложении (через Интернет, на компьютере и т. Д ...)

Answer 1

Чтобы приложение не работало, оно должно иметь определенный набор ожидаемых действий.

"Разве это текстовое поле ПРЕДПОЛАГАЕТСЯ ничего не делать при нажатии клавиши ввода?" Может быть, а может и нет. Я видел приложения, в которых тестировщик / рецензент сообщает о том, что они предполагают, что он должен работать по-другому, когда на самом деле клиент специально спрашивал, что он не хочет, чтобы форма отправлялась нажатием клавиши возврата, а только нажатием кнопки отправки. 1005 *

Таким образом, в основном вы должны определить правильное поведение, прежде чем сможете определить неправильное поведение.

Answer 2

Наймите несколько тестеров .

Answer 3

Проверка кода, т.е. чтение исходного кода: если вы потратили время на чтение / проверку исходного кода, в поисках «запахов» или даже просто в поиске кода, поведение которого вы не сразу понимаете и с которым не согласны, вы можете держали ваш "WTF?" флаг тоже.

Answer 4

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

И да, дети являются экспертами в "ломать вещи" xP.

Answer 5

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

Я имел дело с каким-то серьезно плохим кодом в свое время. Но вы не можете просто переписать. Вам нужна спецификация, прежде чем вы сможете сказать, является ли переписывание улучшением.

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

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

Answer 6

Вы можете обнаружить, что соединения с базой данных / сеансы не освобождаются:

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

Раньше я работал в компании, где программисты регулярно забывали об отмене выделения соединений с БД. Стандартный ответ состоял в том, чтобы уменьшить ресурс до минимума, чтобы увидеть, есть ли утечка - и попытаться выяснить, где он находится, перезапустив систему и неоднократно запустив различные сценарии.

Answer 7

Тест, тест, тест.

Делай неожиданные вещи. Начните выполнять одно задание и переключите другое, чтобы увидеть, что-нибудь пойдет не так. Используйте кнопку назад, когда вы не должны. Откройте его в двух окнах. Пусть время истекло.

Тест во всех браузерах, особенно в IE.

Answer 8

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

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

Если вы включаете проверку кода модульного теста одновременно с проверкой производственного кода, у вас должно быть хорошее представление о том, действительно ли код завершен; в это «полное» входит «проверенное». Не просто " Эй, я перекину через стену тестерам! ".

Answer 9

Это относится к Visual Studio IDE, хотя, вероятно, также относится и к другим:

Во время тестирования всегда в какой-то момент запускайте в отладчике с включенным параметром «Разорвать при возникновении исключения».

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

Answer 10

утверждают () Также модульное тестирование с анализом покрытия.