Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

Тестируя вывод, нужно думать о трех основных моментах:

Как отображается результат?

Отличным примером результата, внешний вид которого стоит проверить – это телефонный номер. Когда пользователь добавляет телефонный номер в базу данных вашего приложения, то этот номер (я надеюсь) сохраняется без любых скобок, точек и дефисов. Однако при отображении телефона для пользователя вы, возможно, не захотите выводить его как 8008675309 – это тяжело читается. Вы предпочтете, чтобы номер форматировался так, как этого ожидает пользователь. Для пользователей из США номер будет отображаться как 800-867-5309 или (800) 867-5309.

Другой пример – это значение валюты. Если пользователю выводятся результаты финансовых расчетов, то вы вряд ли захотите, чтобы они выглядели как $45.655 – никто не платит по полпенни. Расчеты должны округляться или обрезаться так, чтобы иметь не более двух знаков после запятой.

Будет ли результат расчетов корректно сохранен в базе данных?

Представьте, что ваше приложение берет значения X и Y от пользователя, складывает их, и хранит как Z. Тип данных для X, Y, Z установлен как tinyint в базе данных. Если вы проводите расчеты с небольшими числами, к примеру, когда X=10, а Y=20, то это не проблема. Но что будет, если X=255, максимальное значение для tinyint, а Y = 1? Теперь ваше Z равно 256, а это больше, нежели может храниться в типе tinyint, и вы получите ошибку сервера.

Схожим образом, стоит убедиться, что ваши расчеты не получатся меньше нуля в определенных ситуациях – например, в приложении интернет-магазина. Если пользователь набрал товаров на $20, и ввел купон на скидку $25, то ваши расчеты не должны показать, что вы должны ему пять долларов!

Правильно ли проводятся расчеты?

Это особенно важно для сложных финансовых приложений. Допустим, мы тестируем налоговое приложение для Республики Джеквониа. Налоговые рамки в ней просты:

Единственный тип налогового вычета в Джеквонии – это вычет на иждивенцев:

Онлайн-калькулятор налогов для жителей Джеквонии имеет поле ввода дохода, которое может содержать любую сумму в долларах от нуля до одного миллиона, и поле для иждивенцев, в котором могут находиться любые целые числа от 0 до 10. Пользователь вводит эти данные и нажимает "Рассчитать", и получает размер налога, который ему нужно заплатить.

Если бы нас попросили тестировать такой калькулятор, как бы мы приступили к задаче? Вот что сделала бы я.

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

Затем я бы проверила, что невозможно задолжать отрицательную сумму налога: к примеру, если человек заработал $25,000, и у него три иждивенца, он должен быть должным ноль долларов, а не минус пятьдесят.

Далее я бы убедилась, что налоговая ставка корректно применяется на граничных значениях каждого налогового диапазона. Человек, заработавший доллар, должен 250. Человек, заработавший $25,001, и не имеющий иждивенцев, должен $750.03 налогов. Я бы продолжала в том же духе для прочих диапазонов, и провела бы тест для миллиона долларов – верхней границы поля ввода.

И, наконец, я бы проверила расчет на иждивенцев. Я бы протестировала расчеты для 1, 2 и 3 иждивенцев в каждом налоговом диапазоне, и убедилась был, что вычеты в $100, $200, или $300 применяются корректно. Я бы также провела тесты для 4, 5 и 10 иждивенцев, чтобы проверить, что вычет в каждом случае - $300.

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

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

Обсудить в форуме