Should I separate table with a lot of columns and 3 index column?
I'm doing a bit of guessing here, but I imagine you have a table like:

CREATE TABLE ANSWERS
( USER_ID ...
, TIME_OF_TEST ...
, QUESTION1 ...
, QUESTION2 ...
...
, QUESTION300 ...
,    PRIMARY KEY (USER_ID, TIME_OF_TEST)
);


and now you want to add attributes for  weekScore, monthScore and yearScore.

I think it is a bad idea to add those attributes to this table, and in fact I suggest you rethink your whole design. I would have thought that there is an entity TEST that acts as a placeholder for a number of questions, but since you don't mention it I'm going to ignore that. I would suggest something like:

CREATE TABLE QUESTIONS
( QUESTION_ID ...
, WORDING_OF_QUESTION ...
, SCORE ...
, CORRECT_ANSWER ...
....
)


Dependent of what kind of questions there are, you might even normalize it further with a table QUESTION_ITEMS

CREATE TABLE ANSWERS
( USER_ID ...
, QUESTION_ID ...
, ANSWER ...
, TIME_OF_ANSWER ...
);


It is difficult giving any more specific advise without knowing more details, but hopefully it will give you some ideas.

One common mistake is to think of the database as a spread-sheet that represents the report (your first suggestion above). I suspect that naming a relation table in SQL is the reason for much of this confusion.  

For the new attributes weekScore, monthScore and yearScore, I would start by determining them in runtime, i.e. don't store them anywhere. You can create a view for them, and if it turns out to slow, make a table out of it that you update with a batch-process.