In good old days, a program is understood as a functional unit so that testing refers to figuring out its input$/$output relation. However, nowadays, a program $($such as embedded systems code$)$ is often reactive: it constantly interacts with its environment so that when you test it$,$ it will not just give you one pair of input$/$output; instead, it will give you a test; i$.$e$.,$ a sequence of pairs of input$/$output: $($i$1,$ o$1),,($in$,$ on$)$ for some n$.$ Notice that the input sequence i$1,,$ in is called a test case $($provided by a test engineer$)$ and the output sequence o$1,,$ on is the test result. Now, we assume that each of ij and oj is a color in C$.$ The program can be nondeterministic; i$.$e$.,$ one test case may have multiple test results. We now assume that the program is a blackbox $($whose code is not available; not even assembly nor machine code nor design nor requirements. Do not use any code analysis techniques, design analysis techniques, requirements analysis techniques here since they are not applicable and you will get zero.$).$ Sadly, researchers know little about testing a nondeterministic blackbox program! Good news is one can use the most stupid approach in testing such a program: try many many test cases and then collect many many test results. Our experiences are very intuitive: a more highly nondeterministic program is also harder to test. $(3\mathrm{.}1,10$pts$)$ Please develop and justify an algorithm to estimate, from those many many tests, how high the nondeterminism of the blackbox program under test is$.$