Promiseで非同期処理をする場合の挙動を知りたい

fulfilledになったものから実行される認識

それで合っていると思います。

処理結果の出力順は、Promiseを呼び出す順番によって決まるのかな

そんなはずはないと思います。書いておられる処理自体に何か依存関係があって実行タイミングがずれたりするのではないでしょうか？

setTimeoutを使って実験してみるとPromise自体の動きを確認しやすいと思います。

ところで普通の計算機のtimeoutの分解能はせいぜい10msecぐらいですので、実験するにしてもあまり短期間の非同期処理だと順番が乱れるかもしれません。下記の程度なら15, 10, 5にしても動くようでしたが。

function f(to) {
  return new Promise((resolve, reject) => {
    setTimeout(() => resolve(to), to)
  })
}

f(150).then(r => console.log(r))
f(100).then(r => console.log(r))
f( 50).then(r => console.log(r))

setTimeout(() => {
  f(100).then(r => console.log(r)) // 順番を変えてみる 
  f(150).then(r => console.log(r)) // 順番を変えてみる
  f( 50).then(r => console.log(r))
}, 1000)

結果
50
100
150
50
100
150

追記:短く書くためにES2015で書いてます。最初の回答でvar f = (to) => {...}としましたが特に意図あってのことではなかったのでfを普通のfunction定義に置き換えました。

追記: Javascriptで書いた部分は(Workerを使って意識的に非同期なスレッドで行わない限り)必ず同期的に行われます。Promiseは非同期に何かをしてくれる機構ではなく、非同期に行われる処理が完了してから次のことをするための同期機構にしか過ぎないということが伺えるような例を書いてみました。

const t0 = +new Date()

function log(msg) {
  const elapsed = "   " + (+new Date() - t0)
  const prefix = elapsed.slice(elapsed.length - 4)
  console.log(`${prefix}: ${msg}`)
}

function f(msg, sy, to) {
  log(`invoked ${msg}(${sy} ${to})`)
  return new Promise((resolve, reject) => {
    if (sy == 'sync') {
      const start = +new Date()
      do {} while (+new Date() - start <= to)
      doResolve()
    } else {
      setTimeout(() => doResolve(), to)
    }

    function doResolve() {
      resolve(`${msg} ${sy} ${to}`)
      log(`resolved ${msg} ${sy} ${to}`)
    }
  })

}

function done(r) {
  log(`promise chain done ${r}`)
}

f('A', 'async',   0).then(r => f(`${r}->then`, 'async',   0)).then(done)
f('B', 'async',   0).then(r => f(`${r}->then`, 'async',   0)).then(done)
f('C', 'async', 100).then(r => f(`${r}->then`, 'async', 200)).then(done)
f('D', 'async', 200).then(r => f(`${r}->then`, 'async', 100)).then(done)
f('--', 'async', 1000)
.then(r => {
  f('A', 'sync',   0).then(r => f(`${r}->then`, 'sync',   0)).then(done)
  f('B', 'sync',   0).then(r => f(`${r}->then`, 'sync',   0)).then(done)
  f('C', 'sync', 100).then(r => f(`${r}->then`, 'sync', 200)).then(done)
  f('D', 'sync', 200).then(r => f(`${r}->then`, 'sync', 100)).then(done)
})

結果

   1: invoked A(async 0)
   2: invoked B(async 0)
   2: invoked C(async 100)
   2: invoked D(async 200)
      <--本来の非同期処理の場合、非同期処理の起動は一気に行われる
   2: invoked --(async 1000)
   2: resolved A async 0
   2: resolved B async 0
   2: invoked A async 0->then(async 0)
   2: invoked B async 0->then(async 0)
   2: resolved A async 0->then async 0
   2: resolved B async 0->then async 0
   2: promise chain done A async 0->then async 0
   2: promise chain done B async 0->then async 0
      <--C/Dなど時間がかかる処理があってもそれを非同期に行いさえすればA/BはC/Dの完了前に完了する
      <--これはPromiseによる恩恵ではない。A/B/C/Dの処理(setTimeout)が非同期であることがポイント
 112: resolved C async 100
 112: invoked C async 100->then(async 200)
 206: resolved D async 200
 206: invoked D async 200->then(async 100)
 315: resolved D async 200->then async 100
 315: promise chain done D async 200->then async 100
 315: resolved C async 100->then async 200
 315: promise chain done C async 100->then async 200
1008: resolved -- async 1000
1008: invoked A(sync 0)
1024: resolved A sync 0
1024: invoked B(sync 0)
1039: resolved B sync 0
1039: invoked C(sync 100)
1149: resolved C sync 100
1149: invoked D(sync 200)
      <-- Cは同期的に(ビジーループで)100ms消費するためDはその後に起動される(全然非同期でない)
1359: resolved D sync 200
1359: invoked A sync 0->then(sync 0)
      <-- C,Dが同期的に300ms処理しているためAがとっくに終わっていても
          A/Bのthen部分はC/Dの起動後にしか動けない
1375: resolved A sync 0->then sync 0
1375: invoked B sync 0->then(sync 0)
1391: resolved B sync 0->then sync 0
1391: invoked C sync 100->then(sync 200)
1594: resolved C sync 100->then sync 200
1594: invoked D sync 200->then(sync 100)
      <-- Dのthen部分は1359ms後にresolveされている。しかしCのthen部分を同期的に処理しているため
          それが終わらないとDのthen部分が起動できない
          Dのthen部分はresolveされてから250msも後になってからでないと起動されない(全然非同期でない)
1703: resolved D sync 200->then sync 100
1703: promise chain done A sync 0->then sync 0
1703: promise chain done B sync 0->then sync 0
1703: promise chain done C sync 100->then sync 200
1703: promise chain done D sync 200->then sync 100
      <-- 肝心の処理が同期的になっているとPromiseを使ってもなんら意味がない
          A-Bの処理が全て終わってからでないとpromise chainが完了しないことからもそれがわかる

Javascriptで記述するのは「非同期処理を起動するのに必要なパラメーター計算と非同期処理の起動」「非同期処理が完了した際に結果を料理すること」であり、どちらも一瞬で終わるべき処理内容とするのが普通だと思います。それは基本的に非同期APIを用いて論理を書くからです。もし同期APIを用いて逐次的に処理するような機能を並行して動かしたいのならthink49さんが回答しておられるようにWorkerのようなマルチスレッド機構を用いることになると思います。

一応、一つの可能性として。

 同期処理

「n分かかる処理」の内容が不明ですが、同期処理なら「2->1->3」の順に実行されるのが自然です。
3が出力されるまでに30分かかっていませんか。
「Promiseを通すことで非同期処理化する」と誤解していませんか。

Promiseで非同期処理化されるという認識ですが、違うのですか？

Promiseはコールバック関数によって、非同期処理の実行完了を検知する仕組みです。
同期処理はコードを書いた順に実行されますので、Promiseを通しても実行順は変化しません。

 シングルスレッド

また、おそらく勘違いされていることの一つに「非同期処理 !== 並列処理」があります。
JavaScriptはシングルスレッドなので、setTimeoutで非同期処理化してもマルチスレッドにはなりません。
「タイマー処理処理1」実行中に「タイマー処理2」の実行開始時刻を迎えた場合、setTimeoutは「タイマー処理1」が終了するまで、「タイマー処理2」を待機させます。

マルチスレッド化する為には「Service Worker」を使用します。

(2018/04/18 13:34追記)

以下のようにすれば期待する結果が得られるでしょうか。

なりません。
「4(10分後) -> 2(25分後) -> 6(30分後)」が出力されます。
理由は先程説明したように、シングルスレッドだからです。

実際に検証して確かめることをお勧めします。
new Dateをwhileで繰り返せば、n秒待機するsleep関数を作れます。

Re: miga さん

非同期の処理を単に実行しているだけですから処理が短い方から
順次出力されますよね？
ちょっとPromiseを誤解されているのでは？

非同期処理を順に実効するならたとえばこう

var func1 = function(){
  return new Promise(function(resolve,reject){
    setTimeout(function(){
      var sum = 1+1;
      resolve(sum);
    },1500);
  });
}
var func2 = function(){
  return new Promise(function(resolve){
    setTimeout(function(){
      var sum = 2+2;
        resolve(sum);
    },1000);
  });
}
var func3 = function(){
  return new Promise(function(resolve){
    setTimeout(function(){
      var sum = 3+3;
        resolve(sum);
    },500);
  });
}
func2().then(function(sum){
  console.log(sum);
    func1().then(function(sum){
      console.log(sum);
      func3().then(function(sum){
        console.log(sum)
        });
    });
  });