Проверка разработанного программного продукта?

Question

[beginer123]

Вот разработал я какой-нибудь программный продукт
сайт, плагин, модуль, парсер, какой либо функционал и тд.
Не важно что
Как правильно проверять работоспособность продукта?
Какая общая схема?
Можно ли как то автоматизировать это?
Допустим я разработал систему отчета
Как проверить продукт на 100% работоспособность?
Что все ошибки обрабатываются правильно, что на 100% не будет исключений в коде.
Что все ограничения и квоты учтены
Что данные показанные в отчете на 100% совпадают с реальностью.
Т.е допустим не округляются дробные числа, что все складыватеся и делится как надо
Что нет каких то недопустимх форматов ну и тд

Answer 1

[blugamire]

На 100% ты не проверишь никак.
И никогда.
Если это что то не совсем уж тривиальное и никому не нужно.
К этому нужно стремиться.
Но крылья твоему стремлению подрезает экономика - ибо по мере все более и более тщательной проверки сложность её возрастает радикально.

Методов куча.
Ручные, автоматические. Тестируют и частями и в сборе.
Это слишком разные методы и слишком обширная тема, чтобы вот так их все рассказать.

Решают индивидуально - а нужно ли автоматические или ручное тестирование или в каком объеме в данной конкретной задаче.

Все более менее сложные программные системы содержат ошибки.
Их нужно пытаться исправить, но даже 99% свободы от ошибок хрен получишь. А не то что 100%

Тот кто найдет способ избавить от ошибок хотя бы на 99% - озолотится.

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

Comments

[beginer123]

Какие то есть примеры тестирования продукта?
Допустим парсера.
И под тестированием я скорее имею ввиду логику работы приложения.
Что она именно такая как и должна быть

[blugamire]

beginer123:
Начни с простого и мега-полезного: unit-тесты.

[Alexej Simakov]

beginer123: с парсером довольно очевидно, сравниваешь два значения то что ты ожидаешь получить от фунцкии парсинга при определенном вводе и то что выдает функция парсера. например если задать в функцию парсера код html, результат не должен содержать треугольных скобок. Каким условиям должна удовлетворять ваша программа? Вот их и проверяйте.
Большинство юнит тестов у меня написано чтобы вообще попробовать те функции которые я написал, потому что я думаю что сделал все правильно, но как убедиться в этом? То что оно компилируется или запускается - ничего не значит. Нужно поставить эксперимент. Если сунем в фунцкию вот это, то, если она работает как надо, должно выйти вот-это. Проверим ... мммм .. и так далее. Самое важное понять, что вы не знаете как поведет себя программа, вы знаете только как она должна себя вести. Как невозможно сходу напечатать текст и ни разу не опечататься, так невозможно написать программу в которой не будет побочных эффектов.

В тестирования как я люблю говорить, два вопроса "что" и "как", если на первый у вас есть ответ, то ответ на второй: зависит от приложения, для веб приложений свои средства автоматизированного тестирования например selenium, для мобильных приложений свои, например appium. Если у вас вопрос по "как" то его и задавайте, с указанием какой тип приложения хотите тестировать.

[beginer123]

Alexej Simakov:
Какое есть универсальное средство?
Т.к приходится писать всякие разные вещи.
Интересует именно единный подход

[blugamire]

beginer123:

Unit testing
Integration testing
Smoke testing - (Assures that there is no severe problem that prevents further testing. Smoke tests (or Sanity Tests) are used to verify that the software build is ready for System Test (or more extensive testing).)
Function Testing
User Interface Testing
Performance Profiling
Configuration Testing
Installation Testing
Regression testing
Bug fixes testing
Data and Database Integrity Testing
Load Testing
Stress Testing
Volume Testing
Security and Access Control Testing
Failover and Recovery Testing
Conversion testing
Job stream testing
Interface testing
Acceptance testing
Beta testing
User documentation verification

И все это - свой небольшой мирок, свои правила и свои инструменты.
По каждому пункту.

[beginer123]

blugamire:
Ну хорош а если условно бюджет у проекта 5-10 тыс.
Как просто и быстро все протестировать?

[blugamire]

beginer123: все упирается только в степень твоей лени.
откуда я знаю эту степень?

[Alexej Simakov]

beginer123: просто и быстро и при бюджете 10 тыс, еще и дешево я так понимаю. это невозможно.

хотя наверное есть один способ: отдайте продукт не тестируя. заказчик и пользователь за вас все найдут. Если скажут что продукт за 10 тысяч должен быть протестированным, скажите что бюджет придется увеличить до 15 тыс а по хорошему удвоить. Почему вы вообще задались этим вопросом, вы подсознательно сами понимаете что пожелания заказчика не реалистичны, и пытаетесь найти легкий/дешевый выход. Его нет.

Answer 2

[Saboteur]

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

Простые продукты можно потестировать на основной функционал на коленке.
Сложные - этим занимаются аналитики с тестировщиками. Первые уточняют ТЗ, вторые создают тесты и пользуются этим.
А вообще, почитайте базовые книжки и статьи о тестировании.

Comments

[beginer123]

"Простые продукты можно потестировать на основной функционал на коленке."
А это как?
Можно какой то пример привести?
Как делаю я сейчас:
Пишу функцию, допустим найти пользователя по имени.
пусть назвается getUsers
Допустим она должна отдавать json
я создаю фкнцию примерно так

test(user_name){
 getUsers( user_name );
}

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

[Saboteur]

Да, таких функций может быть десятки.
В нормальной ситуации, вы пишете автоматические тесты, которые вызывают эту функцию с разными заранее подобранными параметрами и сверяют полученный результат. Это называется unit-тестирование.
Юнит тесты обычно пишут программисты, и они выполняются в процессе сборки продукта.
Затем идет интеграционное тестирование, когда уже разные компоненты тестируются с разными компонентами.
Затем могут идти еще какие-то тесты, о чем есть целая наука.
Именно поэтому существует направление тестирования, соответсвенно junior QA, regular QA, senior QA, senior automation engineer
и программисты - junior developer, regular developer, senior developer, architect

Answer 3

[index0h]

Как правильно проверять работоспособность продукта?

Тестировать:
unit - обычно пишет программист на свой же код, все зависимости мокаются, чаще всего по белому ящику. При покрытии 95+% добрых 3/4 вашего кода - это тесты.
functional - тоже, обычно пишет программист, но уже с задействованием внешних сервисов, например БД. Тут главное не переборщить, функциональные тесты пишутся быстрее, но они на порядки медленнее, чем юнит тесты.
appearance - чаще пишут QA, иногда проводят мануально, цель - быстро понять, что продукт в принципе работает и ничего критичного не поломали
regration - чаще пишут QA, и проводят мануально - это полная проварка того, что продукт работает согласно ТЗ.

Какая общая схема?

1. Написал код по таске
2. Покрыл тестами
3. Отправил на код ревью
4. Сделал исправления, если нужно
5. Залил в рабочую ветку

Можно ли как то автоматизировать это?

Во многом - да, конечно, берете и пишете тесты.

Как проверить продукт на 100% работоспособность?

Покрыть тестами все возможные неполадки вашего продукта. Но, до всех вы не додумаетесь, и не защититесь от них, так что 100% - это довольно эфимерная цифра. Например, как вы гарантируете, что продукт будет работоспособен, если все ДЦ, в которых он размещен разом выйдут из строя?))

Что все ошибки обрабатываются правильно, что на 100% не будет исключений в коде.

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

Comments

[beginer123]

Спасибо, а что значит:
"2. Покрыл тестами"
Можно какой то пример привести?
Как делаю я сейчас:
Пишу функцию, допустим найти пользователя по имени.
пусть назвается getUsers
Допустим она должна отдавать json
я создаю фкнцию примерно так

test(user_name){
 getUsers( user_name );
}

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

[index0h]

beginer123 во время выполнения тестов выполняется та, или иная часть вашего тестируемого кода.
Отношение количества строк, которые выполнялись к общему количеству и есть "покрытие кода".

Например:

// Рабочий код
class SomeClass
{
    public function assertPositive(int $positive): void
    {
        if ($positive <= 0) {
            throw new \InvalidArgumentException('');
        }
    }
}

// Тест
(new SomeClass())->assertPositive(100);

В результате

class SomeClass                                         // покрыта
{                                                       // покрыта
    public function assertPositive(int $positive): void // покрыта
    {                                                   // покрыта
        if ($positive <= 0) {
            throw new \InvalidArgumentException('');
        }
    }                                                   // покрыта
}                                                       // покрыта

Покрыто 6/9 кода - 66,67%

[Алексей Шумкин]

beginer123:

Какой есть более простой и надежный способ?

это, как уже сказал Saboteur, называется unit-тестирование,
в них как раз все упомянутые варианты и тестируются
читайте про TDD всё, что найдёте... первым делом - книгу основателя сего принципа - Кента Бека "Test Driven Development" (Разработка через тестирование), там принцип тестирования хорошо изложен
дальше - уже могут вариации: чистое TDD (Test first), Test last, etc, но главное тут - наличие тестов... автоматических