Как лучше тестировать приложения

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

vlada_maestro / shutterstock

Евгений Кучерявый

Пишет о программировании, в свободное время создаёт игры. Мечтает открыть свою студию и выпускать ламповые RPG.

Недавно я прочитал рассылку Skillbox о простом способе стать профи, в которой Андрей Коновалов — наш главред — рассказывает о талантливом программисте, который придумывает хорошие решения, но никак не может сдать их с первого раза, потому что не проверяет их. Это мешает ему стать профессионалом.

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

Проверяйте абсолютно всё

Критический баг может затаиться в любом фрагменте кода. Если вы думаете, что какой-то кусочек вашей программы слишком прост, чтобы в нём была ошибка, то вы ошибаетесь. Яркий пример — уязвимость в программе «Блокнот» для Windows, которая позволяет получить доступ к компьютеру жертвы.

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

Тестируйте каждую фичу несколько раз

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

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

Тестируйте фичи вместе

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

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

Вот только тогда будет уже поздно.

Проводите полное тестирование даже после небольшой модификации

Чаще всего я наступал на такие грабли:

фича отлично работает при тестировании;
добавляешь что-нибудь и тестируешь обновление;
через некоторое время узнаёшь, что теперь не работает ничего, кроме самого обновления.

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

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

Будьте новым пользователем

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

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

Продумывайте архитектуру

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

Именно из-за этого появляется куча несовместимого или повторяющегося кода. Особенно печально, если код повторяется, но в нём есть небольшие отличия.

Например, вы могли написать метод UploadProfileImage (), а потом вспомнить, что нужно ещё добавить метод UploadMessageAttachment (). Скорее всего, отличаться в этих методах будут только запросы к базе данных, пути и допустимые форматы.

Поэтому лучше создать универсальный метод UploadFile () и передавать в него путь для сохранения и файл, который прошёл все проверки. Метод может возвращать булево значение, чтобы можно было определить логику для удачной и неудачной загрузки — те же самые запросы к базе данных.

Заключение

Чаще всего проблемы с приложениями возникают именно из-за плохого тестирования. Не зря говорят, что только 10% времени уходит на написание кода, а остальное — на отладку. Поэтому чем тщательнее вы будете подходить к тестированию, тем меньше ошибок будет оставаться.

Читайте также: