Поблочное тестирование, в реальном времени / параллельное программное обеспечение [дубликат]
URL сборки для Ajax-запроса, для 2017 - CCC это похоже на
url = 'https://.......com/result.php?mode=edPass&ajax=true&annee=2017&course=ccc'
data = pd.read_html(url, header = 0)
print(data[0])
4 ответа
Большая часть моей работы сейчас связана с многопоточными и / или распределенными системами. Большинство ошибок связаны с ошибками типа «происходит до», когда разработчик предполагает (ошибочно), что событие A всегда будет происходить перед событием B. Но каждый 1000000-й раз, когда программа запускается, событие B происходит первым, и это вызывает непредсказуемое поведение.
Кроме того, на самом деле нет никаких хороших инструментов для обнаружения проблем с синхронизацией или даже повреждения данных, вызванного условиями гонки. Такие инструменты, как Helgrind и drd из набора инструментов Valgrind, отлично подходят для тривиальных программ, но не очень полезны для диагностики больших и сложных систем. Во-первых, они довольно часто сообщают о ложных срабатываниях (особенно Helgrind). Во-вторых, это На самом деле трудно обнаружить определенные ошибки при работе под Helgrind / drd просто потому, что программы, работающие под Helgrind, работают почти в 1000 раз медленнее, и вам часто нужно запускать программу в течение довольно длительного времени, чтобы даже воспроизвести состояние гонки. Кроме того, поскольку работа под Helgrind полностью изменяет синхронизацию программы, может стать невозможным воспроизвести определенную проблему синхронизации. Это проблема тонких таймингов; они почти гейзенберговские в том смысле, что изменение программы для обнаружения проблем с синхронизацией может скрыть исходную проблему.
Печальный факт в том, что человечество все еще недостаточно подготовлено к работе со сложным параллельным программным обеспечением. Так что, к сожалению, нет простого способа протестировать его. Особенно для распределенных систем вам следует тщательно спланировать свою программу, используя диаграммы «происходит до» Лампорта , чтобы помочь вам определить необходимый порядок событий в вашей программе. Но в конечном итоге вы не можете уйти от модульного тестирования методом перебора со случайным образом изменяющимися входными данными. Это также помогает изменять частоту переключения контекста потоков во время модульного тестирования, например, запуском другого фонового процесса, который просто требует циклов ЦП. Кроме того, если у вас есть доступ к кластеру, вы можете запускать несколько модульных тестов параллельно, что может намного быстрее обнаружить ошибки и сэкономить вам много времени.
Это также помогает изменять частоту переключения контекста потоков во время модульного тестирования, например, запуском другого фонового процесса, который просто требует циклов ЦП. Кроме того, если у вас есть доступ к кластеру, вы можете запускать несколько модульных тестов параллельно, что может намного быстрее обнаружить ошибки и сэкономить вам много времени. Это также помогает изменять частоту переключения контекста потоков во время модульного тестирования, например, запуском другого фонового процесса, который просто требует циклов ЦП. Кроме того, если у вас есть доступ к кластеру, вы можете запускать несколько модульных тестов параллельно, что может намного быстрее обнаружить ошибки и сэкономить вам много времени.Я никогда не слышал о чем-либо, что может.
Я думаю, что если бы кто-то спроектировал один, он должен был бы иметь точный контроль над выполнением потоков и выполнять все возможные комбинации степпинга потоков.
Звучит как главная задача, не говоря уже о математических комбинациях для нетривиальных нитей, когда их несколько или более ...
Хотя, быстрый поиск в стеке потока ... Модульное тестирование многопоточного приложения?
Если вы можете запускать тесты под Linux, valgrind включает в себя инструмент под названием helgrind , предназначенный для обнаружения состояний гонки и потенциальных взаимоблокировок в программах, использующих pthreads; вы можете получить некоторую выгоду от запуска вашего многопоточного кода в этом режиме, поскольку он будет сообщать о потенциальных ошибках, даже если они на самом деле не возникали в данном конкретном тестовом запуске.
Если тестируемая система достаточно проста, вы можете довольно хорошо контролировать параллелизм, блокируя операции во внешних системах-макетах. Это блокирование может быть выполнено, например, путем ожидания запуска какой-либо другой операции. Если вы можете контролировать все внешние вызовы, это может сработать достаточно хорошо, реализовав различные последовательности блокировки. Я пробовал это, и он довольно хорошо выявляет ошибки на уровне блокировки, если вы хорошо знаете возможные проблемные последовательности. И по сравнению со многими другими тестами на параллелизм он довольно детерминирован. Однако этот подход не слишком хорошо определяет условия гонки на низком уровне. Обычно я просто иду на нагрузочное тестирование, чтобы найти их, но я думаю, что это не совсем модульное тестирование.
Я видел эти фреймворки для тестирования параллелизма для .net, я ' Я считаю, что это единственный вопрос времени, когда кто-нибудь напишет его для Java (надеюсь).
И не забыть про чтение старого доброго кода. Один из лучших способов найти ошибки параллелизма - просто прочитать код еще раз, полностью сосредоточившись на нем.