The reasons could be various, of course.
The most obvious answer is that, for one reason or another, you cannot be authenticated by the remote system. However, since you are outputting the directory permissions on the remote system, I assume you have the rights and ability to access it by some means (but perhaps not by ssh).
So, the first thing to do is to ssh to the machine and make sure you can actually write to that location (which you may have already tried):
ssh root@remote_host
cd /var/www/html/test/
touch scratch
If you can see the empty file scratch, then you know you can write.
Supposing you can properly access the system but the above does not work, it is also possible there is not actually write permissions on the directory. One example would be if the directory on the remote machine is within a mounted filesystem of a certain type, for example NTFS (which won't give you reliable UNIX-type modes), and the kernel sets it to read-only because it wasn't mounted via fuse to give write permissions. You'd need to check more carefully on the local settings, but this would be a very unusual setup unless it is new (or designed that way).
Debugging the system from here would be hard for me, so I'll just give you an alternate method to try. If you can access the system via ssh and write files from within the system, then a way to do it is just to do the opposite way around, if your local computer is not behind a firewall, etc.
You can easily find the IP of the computer you ssh'd from without even moving to another terminal. Let's just make it an environment variable for simplicity:
export IP="`echo $SSH_CLIENT | awk '{print $1}'`"
I generally include this line in, for example, ~/.bashrc because I find it handy.
In any case, then
scp user@$IP:/var/www/html/file.php /var/www/html/test/
Of course, if you want to be running a program to do these updates automatically on the local machine, this will not resolve your problem just yet! There are ways to resolve that by calling commands via SSH (so you would be calling an scp via ssh, which seems counter-intuitive); however, for it to be fully automated you'd need to set up an ssh key, and make no password for the key. This is not the kind of thing I would recommend for root access to a machine, and some kind of debugging with the remote machine's ssh needs to be done that is blocking scp.
if there's an entry of your local host's pub key in remote_host:/.ssh/authorized_keys, then you'd be authenticated with pki instead of inputting password.
I understand now. I never before logged without password on that server. No, my IP is the same as always. – Jason Paddle Jul 23 '15 at 12:02