shivanikhosa / browserscope

Automatically exported from code.google.com/p/browserscope
Apache License 2.0
0 stars 0 forks source link

Feature: Add ability to send test results via GET/POST #308

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Right now the only way to submit test results is to create a variable with a 
specific name and then include a script after the test results are stored in 
the variable. This makes it more difficult than necessary to have a page that 
submits multiple test results since you need to be careful with the timing of 
when you change the value of the variable.

Storing multiple test results would be much easier if they could be sent via an 
ajax request, or even a script request that included the test results.

Original issue reported on code.google.com by scott.go...@gmail.com on 20 May 2011 at 11:45

GoogleCodeExporter commented 8 years ago
Can you point me at your example test that wants this? 
You can send multiple keys in a beacon.. so you could do value_1, value_2 etc.. 
where each keyname would be the way to differentiate the test conditions - but 
maybe you're running your own test multiple times on a page and wanting to 
capture that?
Part of the trick/hassle of the beacon is that we try to verify the API key and 
the referrer first, and then send back JS to do the cross-domain POST with a 
CSRF token.

Original comment by els...@google.com on 20 May 2011 at 4:32

GoogleCodeExporter commented 8 years ago
My example isn't live yet, but I can explain why I want this. I'm doing tests 
that take a long time to run and I'd like to send the results as each test 
finishes. This means that my counts will be all messed up, but that's not a 
concern for me if the cumulative results are based only on the beacons that 
actually contained a test result.

So if the cumulative result is a mean of all values and I send three beacons:
{ key1: 10 }
{ key1: 20 }
{ key2: 5 }
I'd expect the results to come back as:
{
    key1: 15, // (10 + 20) / 2
    key2: 5 // 5 / 1
}
as opposed to:
{
    key1: 10, // (10 + 20 + 0) / 3
    key2: 2 // (5 + 0 + 0) / 2
}
I haven't done any testing to see if this is how the results are actually 
calculated, but I would assume it is so that you can add new keys at any time.

There's another use case which is having a single page that stores the results 
against different tests. For example, if you wanted to run the Acid3 and JSKB 
tests on the same page back to back.

Original comment by scott.go...@gmail.com on 20 May 2011 at 5:22

GoogleCodeExporter commented 8 years ago
You can do acid3 and jskb back to back today - you just beacon each one at the 
end of their run - they're different tests so I don't think that is a problem.
And yep, you can add new keys at any time.
All in all, I think we should let this one brew - if you can't find a 
workaround that's satisfying with the current constraints let me know cause 
yeah, right now the idea is that every beacon is a whole hog set of test 
results instead of incremental test key updates.

Original comment by els...@google.com on 20 May 2011 at 5:27

GoogleCodeExporter commented 8 years ago
If the Acid3 and JSKB tests run extremely fast, wouldn't you have potential 
problems? They have different test keys, but every test expects the results to 
be in window._bTestResults.

Could you update the script to accept a customizable variable name and just 
default it _bTestResults? That would solve the problem since you could use 
different variables and avoid the race condition.

Original comment by scott.go...@gmail.com on 20 May 2011 at 6:04

GoogleCodeExporter commented 8 years ago
Ah, yes you're right. That sounds like an easy change. Will do.

Original comment by els...@gmail.com on 20 May 2011 at 6:12

GoogleCodeExporter commented 8 years ago
Fixed in r821
See the newly documented test_results_var at 
http://www.browserscope.org/user/tests/howto

Original comment by els...@gmail.com on 20 May 2011 at 6:57

GoogleCodeExporter commented 8 years ago

Original comment by els...@gmail.com on 20 May 2011 at 6:57