Максим Франко

Исправить скрипт, чтобы ему для работы не требовалось 4 Gb оперативки.

Дык у вас бесконечный цикл.
1. Получать из базы надо только нужные данные, а не все разом.
2. mysqli_fetch_assoc надо вызывать для получения каждой следующей строки из базы.

--$sql2 = "SELECT * FROM `servers`";
++$sql2 = "SELECT 'id' FROM `servers` WHERE `pay_date` = CURDATE()";
--$ress2 = mysqli_fetch_assoc($res2);
--while($ress2) {
++while ($ress2 = mysqli_fetch_assoc($res2)) {

Я бы ещё добавил условие, что сервер не заморожен.
И вызывать такой скрипт достаточно раз в сутки, так как он завязан только на текущую дату.

Опишу простыми словами для упрощения понимания.

модульное тестирование

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

интеграционное тестирование

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

функциональное тестирование

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

какими инструментами оно делается?

Инструментами автоматизации GUI - для сайтов это Selenium и браузеры. Для десктопных/мобильных приложений аналогичные решения.

приемочное тестирование

в че отличие от интеграционных.. еще видел фразу что тут и фронт и бек тестируются, но яснее не стало, какими инструментами оно делается?

"Бизнес" заказал в "Конторе" разработку сайта, выдал ТЗ, контора сделала сайт, бизнес заплатить денег обещал. Как бизнес проверит что контора сделала именно то, что он хотел? Через приемочное тестировние - бизнес получает доступ к сайту и проверяет, что сайт именно такой, какой он заказывал в ТЗ, а не тот, который сделали индусы за доширак. Если в ТЗ указан конкретный список тестов/фич - используется этот список или так, как прописано в ТЗ само тестирование. Само тестирование проводит соответствующий специалист (инженер отдела качества) - тыкает все кнопочки, нажимает менюшечки и говорит начальству "все окей, подписывай и платим им деньги" или "вот тут и тут не окей, не подписывай, денег не давай". Реальный пример: была заказана и собрана станция спутниковой связи, на приемке были представители заказчика и исполнителя, была толстая пачка бумаги на несколько сотен страниц, по которой первые проверяли что все работает именно так, как там написано в течении нескольких недель (плюс-минус), а вторые исправляли косяки показывали что все окей, потом все поставили свои галочки и крестики и разъехались по домам.

E2E - тут тестируется чрез браузер, с помощью Mocha и тп, те тестируются "требования бизнеса к приложению", тестируются пользовательские сценарии.. а в чем отличие от функциональных тестов тогда?

Сквозное тестирование. Это полная проверка от начала и до конца. Отличие от функционального в том, что это более комплексный тест. Если функциональное тестирование - это проверка конкретной функции, тот сквозное - работа всего приложения, т.е. более комплексное. Например, E2E тест приложения для загрузки файла на сервер: тест включает в себя запуск приложения, авторизация пользователя, выбор файла, указание мета информации, загрузку файла на сервер, выход из приложения. Вот тут неплохая статья на хабре: https://habr.com/ru/company/otus/blog/681066/

Совсем запутался, с unit только понятно, а как уложить и разделить остальные?

Картинка отсюда: https://www.rainforestqa.com/blog/the-layers-of-te...

Бросайте вы эти видеоуроки, они вас плохому научат.
1. Не надо напрямую подставлять переменные в запрос, для этого есть плейсхолдеры. Читать про SQL Injection.
2. Не надо руками ловить ошибки mysqli. Надо устанавливать правильные опции при подключении. Читать https://habr.com/ru/post/662523/
3. Если уж вы ловите ошибки самостоятельно, то выводите полный текст ошибки, а не просто паническое "Ой, что-то случилось!".
4. Не надо хранить в своей базе данные кредитных карт клиентов, да ещё и вместе с CVV. Учитывая пункт 1, это всё равно, что писать их на заборе. Читать про PCI DSS.

Это всё просто ужасно. Начиная прямо с первой строчки, class Register extends Database
Делать отдельный класс для регистрации глупо. Если уж делать класс, то для манипуляции юзером в целом, а не одной только регистрации. Плюс, регистрация пользователя - это не база данных. И не должна наследовать классу Database.
По сути, вы хотите натянуть ООП на обычное процедурное программирование. Не надо этого делать, получится самолёт из соломы. Сделайте простую функцию.

Но это ещё цветочки. Остальных проблем тут выше крыши:

1. Никогда не используйте сокращённый синтаксис INSERT. Всегда надо явно перечислять поля. Это, скорее всего, и является причиной ошибки. Но даже если нет, то проблемы всё равно вылезут в будущем
   
2. Собственно сообщение об ошибке нам и надо получить от базы данных, чтобы понять в чем проблема. для этого к коду соединения с БД надо добавить строчку

   mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

   и после этого смотреть сообщение об ошибке
   
3. Самое главное - SQL инъекция. Какой смысл делать регистрацию вообще, если любой дурак узнает пароли всех остальных пользователей или сможет авторизоваться вообще без пароля? Запросы надо выполнять только через подготовленные выражения
   
4. И по поводу паролей. Пароли надо хранить в фаршированном виде, обработанными функцией password_hash()
   

ты же понимаешь, что в данном случае пхп лишь генерирует html-разметку беря данные из бд? ты можешь сделать этот же слайдер просто на html? если да, то посмотри какую разметку сделал (без применения js)

пишет-Сейчас эта страница не работает,

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

$password = md5($password."ghjsfkld2345");

забыть как страшный сон, читаем про password_hash(), делаем как надо.

$result = $mysql->query("SELECT * FROM `users` WHERE `login` = '$fullname' AND `pass` = '$password'");

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

setcookie('user', $user['fullname'], time() + 3600 * 24 * 90, "/");

работать с куками вместо сессии - отдельный вид некомпетентности, точнее - открытое вредительство.

$mysql->close();

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

$sth = $dbh->prepare("SELECT * FROM `catalog` WHERE `id` = ? ORDER BY `date_add` DESC");
$sth->execute([intval($_GET['id'])]);

Или для читабельности кода, лучше так:

$id = intval($_GET['id']);

$sth = $dbh->prepare("SELECT * FROM `catalog` WHERE `id` = :id ORDER BY `date_add` DESC");
$sth->bindParam('id', $id, PDO::PARAM_INT);
$sth->execute();

https://www.php.net/manual/ru/function.mb-strlen.php

PHP