Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Подводные камни при системном тестировании модулей под Magento

Anna | 29.05.2014 | нет комментариев
Три предыдущих года я работал тестировщиком-мануальщиком в компании, которая дюже удачно разрабатывает модули под Magento. За данный период я сумел собрать довольно огромный список разных подводных камней, о которых тестировщику (да и программисту) никогда невозможно забывать.
Добросовестно говоря, это не какие-то никому не вестимые «подводные камни», о которых никто не знает, либо о которые модуль в боевых условиях никогда не споткнётся. Это скорее каждому знаменитые фичи и места самой Magento, в взаимодействии модуля с которыми всплывает дюже много, кхе-кхе, багов. Причём баги эти дюже даже критичны.


Non-base currency support
Дюже много модулей работают с ценами — от простого отображения в своих блоках, до образования частей (дискаунты, таксы, шипинги) и/или суммы ордера, отправки amount на платёжные системы. Следственно непременно настраиваем на магазине еще одну валюту и наблюдательно глядим. Еще изредка бывают баги с округлением при переводе из одной валюты в иную.
Рекомендуется данный кейс автоматизировать. Впрочем без личного аудита здесь всё же не обойтись, тем больше что цена ошибки дюже крупна.

Big Database
У нас есть sample-data, которую мы обозвали «XXL» — десятки тысяч сгенерированных кастомеров, продуктов и ордеров. Практика показывает, что дюже многие модули на таких «сторах» обнажают свою неудачную реализацию. Почаще каждого это выражается в громадных приходах времени загрузки страниц.

Multi-store
Тут имеется ввиду помощь разных website/store/store-view — разные значения опции для различных локалей «стора», (не)отображение на некоторых локалях, редиректы при смене локали на фронтенде.
Рекомендуется данный кейс автоматизировать.

Single-store
Изредка разработчики забывают о том, что на сторе может быть только один Store View и ID его может отличаться от 1.
Рекомендуется данный кейс автоматизировать.

HTTPS
Почаще каждого встречаются следующие задачи:
— ломается javascript/AJAX модуля
— когда модуль добавляет вкладку в My Account, то Зачастую там не применяется https в URL
— запросы с https отправляются на http, и напротив
— еще дозволено сделать Store Base Unsecure Url c https (Дабы каждый стор применял на фронтенде https)
Рекомендуется данный кейс автоматизировать.

Multi-Address Checkout
«Из коробки» в Magento есть чекаут, тот, что разрешает оформить ордер на несколько адресов. Так что если ваш модуль как-то взаимодействует с чекаутом — не забывайте про multi-address checkout.

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

Register at Checkout
Если модуль как-то работает с логином либо регистрацией, то не забывайте, что чекаут также имеет форму login/register.
Сюда дозволено отнести также допустимые задачи с CAPTCHA.

Require Email Confirmation
В бекенде есть опция «Require Email Confirmation», которая включает надобность удостоверить свой email при регистрации. Верная работа с этой фичей главна для модулей, которые работают с событием регистрации нового пользователя. Исключительно критично это для разных реферальных систем.

Backend Admin Permissions (ACL)
Наверно ваш модуль добавляет какие-то пункты меню в бекенде. Нужно удостовериться, что менеджеры, которые не обязаны иметь доступ к этим пунктам меню, подлинно не имеют к ним доступа. Проверяется проходом по прямой ссылке. Еще необходимо обратить внимание на «спрятанные» ссылки, скажемstore/admin/promo_catalog/delete/id/1/ — эта ссылка удалит Catalog Price Rule c ID=1. Такие ссылки также обязаны рассматривать то, кто по ним проходит.
Рекомендуется данный кейс автоматизировать.

Cross-Browser compatibility
Тут всё легко. Тестируем фронтенд в разных браузерах. Обращать внимание на вертску и отработку скриптов.
В бекенде задачи с кросс-браузерностью дюже редки, следственно бекенд довольно протестировать подFirefox и Chrome.
Рекомендуется данный кейс автоматизировать.

Themes
Не помешает поставить свой модуль на какую-нибудь фронтенд-тему (отменнее на приближенный к «боевому» интернет-магазин) и удостовериться, что там ничего не сломалось.

Full Page Cache
FPC доставит много хлопот разработчику, уж поверьте. Актуально для модулей, которые показывают на фронтенде блоки, содержимое которых может изменяться.

CSV Translations
В папке app/locale/xx_XX/ лежат csv-файлы, которые отвечают на перевод текста. Удостоверитесь, что ваш модуль также имеет такой файл, что все лейблы и сообщения модуля имеются в этом файле, и что метаморфоза этого файла «переводит» лейблы на фронтенде.
Рекомендуется данный кейс автоматизировать.

Update from previous version
При рефакторинге либо изменении конструкции таблиц модуля в БД непременно проверяем апдейт с предыдущей версии.

Проверка на целостность данных 
Что будет с вашим модулем, если удалить пользователя, продукт либо иную сущность, с которой работает ваш модуль?

Product is out of stock
Не забывайте о том, что продукты могут быть либо стать out of stock.

Slow speed connection
Изредка девелоперы забывают о том, что коннект не неизменно радует своим качеством. Для эмуляции неторопливого коннекта дозволено применять программу Fiddler, скажем.

Database prefix
А еще девелоперы изредка забывают, что у таблиц в БД бывают префиксы. Такой баг непременно обронит каждый модуль. Либо даже каждый «стор».

Compilation
В последнее время багов связанных с компиляцией (Backend>Tools>Compilation) в новых модулях стало приметно поменьше. Схоже, что наши программисты вовсе не любят наступать на грабли двукратно.

Flat category / product
Легко включите эти опции в System > Configuration > Catalog, сделайте реиндекс и пойдите в категорию либо на продукт. Классический баг.

Store code to URL / SEO Optimization
Эти опции влияют на URLы. Там где урлы, там и эти опции.

Special symbols & Injections
Проверяем модуль на стабильность к скриптам и прочим XSS/SQL-инъекциям, на отображение и обработку особых символов, на подмену значений в форме и т.д.

Locale / Timezone
Все, что связано с локализацией: формат дат и цен, учитывается ли выставленная в настройках магазина таймзона, и т.д.

Form Save after Error
Отличным тоном является сохранение введенных в форму значений, на случай если сервер при сохранении/отправке формы вернёт ошибку.

Create Order From Backend
Ордер дозволено сделать также и из админки. Об этом тоже Зачастую забывают.

Create Customer From Backend
Подобно предыдущему пункту.

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

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB