Егор Оммоник

dmshar все правильно вам написал, разбивайте число из диапазон 1..100 на интервалы

function foo() {
  let random = Math.floor(Math.random() * 100) + 1; // 1..100
  switch (true) {
    case random < 36: return 1 // 35%
    case random < 61: return 2 // 25%
    case random < 86: return 3 // 25%
    case random < 96: return 4 // 10%
    default: return 5
  }
}

Тест: запустим 10 млн раз и посмотрим распределение

Эта элементарная задача называется "генерирование дискретных случайных величин с заданным законом распределения". Решается классическим образом.
Сначала разбиваем наш диапазон от 1 до 100 на следующие интервалы:
1-35,36-60,61-85,86-95,96-100.
Затем генерируем число, равномерно распределенное в диапазоне от 1 до 100. Номер интервала, в который это число попадает дает ваши генерируемые цифры - от 1 до 5, причем распределены они в точности по вашей таблице распределения.

databaseURL := os.Getenv("DATABASE_URL")
Потому что вы в TestMain объявляете локальную переменную, не трогая глобальную.

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

Наиболее эффективным способом будет использовать этот пакет:
https://github.com/tidwall/gjson
с функцией GetMany.

B450 идеален по соотношению цена/качество.

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

Есть стандарт https://jsdoc.app/
вот тут с примерами
https://ru.wikipedia.org/wiki/JSDoc
https://devdocs.magento.com/guides/v2.3/coding-sta...
https://devhints.io/jsdoc

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

Если на пальцах: очень часто большинство действией на веб-странице сопровождается отправкой http запроса на сервер, что бы получить какой то результат. Посмотреть эти запросы ты можешь и в самом браузере, например в Chrome жмешь на странице правой кнопкой мыши -> Посмотреть код -> Network -> и видишь список всех запросов в таком виде:

Нажимая на запрос ты видишь в колонке справа URL адрес этого запроса, параметры которые он передает на сервер и во вкладке Response то, что при этом запросе ты получаешь от сервера.

Теперь твои действия следующие: ты заходишь в свою онлайн игры, открываешь эти Dev Tools, начинаешь нажимать на различные действия (например баланс) и смотреть какой запрос/запросы при этом отправляются. Твоей задачей будет повторить все необходимые запросы программно.

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

По выбору ЯП по большому счету без разницы, никаких специфических задач у тебя нет, работа с сетью в основном.
Со своей колокольни Python-разработчика могу сказать, что преимуществом этого ЯП будет возможность быстро влиться и начать что-то делать. Самые минимальные знания можешь получить в книге A Byte of Python. Дальше берешь в руки библиотеку requests, или selenium и вперед.

На самом деле всё очень просто. Вы и сами справитесь. Берем классический список оборудования.

1. Материнская плата
   
2. Процессор
   
3. Кулер
   
4. Видеокарта
   
5. Жесткий диск
   
6. SSD
   
7. Оперативная память
   

Идем на сайт производителя конкретного оборудования за характеристиками энергопотребления.
Пример:

1. GIGABYTE Z390 UD, LGA 1151v2, Intel Z390, ATX, Ret
   
2. INTEL Core i5 9600K, LGA 1151v2, OEM - до 200 Вт
   
3. DEEPCOOL GAMMAXX 300 FURY, 92мм, Ret - 1 Вт
   
4. SAPPHIRE AMD Radeon RX 580 , 11265-05-20G PULSE RX 580 8G OC, 8Гб, GDDR5, OC, Ret - до 225 Вт
   
5. WD Blue WD40EZRZ, 4Тб, HDD, SATA III, 3.5" - 5 Вт
   
6. SAMSUNG 860 EVO MZ-76E500BW 500Гб, 2.5", SATA III - 4 Вт
   
7. KINGSTON HyperX Predator HX430C15PB3K2/16 DDR4 - 2x 8Гб 3000, DIMM, Ret
   

Там где не указано энергопотребление обычно оно сравнительно невысокое. MB, RAM - это не критично. Итак, считаем: 200 + 1 +225 + 5 + 4 = 435 Вт. Не забываем, что ещё есть периферия. Добавим 25%. 543 Вт. 543 Вт - это критический предел по энергопотреблению. Так же необходимо учесть, что блок питания имеет энерго-эффективность и КПД. Пусть у вас добротный БП, который даёт не меньше 90% КПД. Итого, на эту систему необходимом минимум 600 Вт (это цифры, которые написаны на коробочке БП). Плюс иметь запас весьма и весьма желательно, учитывая, что китайцы могли запросто обмануть на счет ватт и КПД. А это процентов 15 самый минимум. И уже БП на 700 Вт (это те цифры, что красуются на коробке) это норм и с запасом.
Вот примерный алгоритм подсчета.

На этом вопросе должен висеть огромный знак "Не лезь". Допустим, ты выучил виды тестирования по определенному, ты можешь попасть в следующий кейс:

1. "Опытный" (насидевший большой трудовой мозоль) лентяй скажет тебе, что это все фигня - главное опыт. Причем в чем состоит этот самый опыт сформулировать не сможет.
   
2. Словивший звезду спец скажет тебе, что это все фигня - главное его взгляд на вещи, который он сформировал за годы работы ибо эффективно. Ога, нерепрезентативная статистическая выборка, склонность к подтверждению собственных идей и прочие когнитивные искажения ему в помощь.
   
3. Какой-нибудь автоматизатор или девелопер будет вещать со своей колокольни путая пирамиду автоматизации с тестовыми уровнями и Е2Е тесты с тестами графического интерфейса.
   

Как ты понял, тема крайне противоречивая - херова туча непоняток, субъективностей, и банальных ошибок вызванных ленью.

Если ты еще не поостыл, давай рассмотрим один из вариантов организации.
Согласно стандарту 9126, у программного продукта есть 6 атрибутов качества: performance, reliability, functionality, usability, maintainability, efficiency. Запомнить легко через ассоциацию PaRFUME. Каждый атрибут имеет определенное количество вложенных атрибутов. Вот тебе картинка. Каждый вложенный атрибут покрывается соответствующим видом тестирования. Их совокупность и является всеми видами тестирования.

Едем дальше. Все атрибуты качества кроме функциональности являются нефункциональными. Соответственно любой из видов их тестирования является нефункциональным.

Также есть такое понятие как уровни тестирования. Если в двух словах, то это концепт, который организовывает тест активности по скоупу.

1. Уровень модулей. Тестирование отдельных модулей в изоляции.
   
2. Уровень интеграций. Тестирование общения модулей.
   
3. Уровень системы. Тестирование всей системы в целом. Не возьму "все-все модульные тесты и прогоню их", а выполнение тестовых активностей, скоп которых вся система (нагрузка, юзабилити, ...)
   
4. Уровень пользовательской приемки. Проверка конечным пользователем (сразу после проверки тестером :) выполнения приложением бизнес задач. Я хотел смотреть видосы! Я могу смотреть видосы??
   

Если выучишь изложенный выше подход то при предъявах вроде "ВСЕ ФИГНЯ!" сможешь говорить "мои данные основаны на ISTQB и стандарте ISO-9126, а на чем основаны ваши?" Хотя это не поможет ибо человеческая тупость имеет бесконечный потенциал.

Теперь, зная все это, посмотри еще раз на свое приложение .Net... Не кажется ли тебе, что их описание видов тестирования по уровню тупости находится где то на уровне:
- Расскажи мне что ты знаешь о Марсе.
- Арбуз, гребень, пилот!

Интернет-ноунейм критикует авторов твоей приложухи, норм да?
Субьективность...
Все как и обещал...