雲端工作術
各類應用示範
案例故事
逃離惡夢
關於 Ragic
初步建立好資料庫，功能都有了，可以喜孜孜上線給大家用了嗎？等一下！在「做好功能」跟「正式啟用」之間，別漏了一個重要的步驟——它叫做「上線前測試」。
僅管你很可能不是工程師，但當你用 Ragic 建立一張張的表單、設計出表單連結關係、按鈕、公式時，你其實就是在「開發資訊系統（開發軟體）」了，而「測試」其實是軟體開發到上線之間不可或缺的流程。
為什麼需要測試？就像做菜端上桌之前要先試口味一樣，你可能會在煮湯時舀一小口試喝、炒肉時切一小塊試吃，確認做出來的菜符合預期，沒有不小心少放了鹽、炒不夠久，不合預期的話可以馬上調整。如果菜都上了一桌、大家都坐好準備開始吃才發現湯味道不夠、肉也沒熟，那不只掃興，這時才重新處理這些菜也很麻煩。
資訊系統也是一樣，我做的表單、功能到底能不能如同預期地運轉？有沒有設計錯了或考量不周全的地方？如果沒有跑跑看、甚至新增一些測試資料，用其他使用者（非系統管理員）的視角、實際操作的邏輯跑過整個流程，其實很難知道。
即使相較於其他資訊系統，Ragic 非常彈性好調整，可以「邊做邊改」，但先透過測試確認某些東西真的可以執行、排除基本問題，儘量讓使用者從比較好的體驗開始，還是有其必要。
資料庫整體大致設計完畢、還沒「正式上線使用」之前，該做測試。但除此之外，在 Ragic 其實你隨時可以測試：每次設計完一個功能，例如一組公式、一個按鈕、一組連結與載入、一個提醒或寄信功能......，設計存檔之後，都可以順手新增資料，測一下這個你剛做出來的「單一功能」是否合意。等到一切大致完成要上線之前，再做一次整體的測試。
這邊要提到一個我們常常跟 Ragic 用戶溝通的觀念，就是不一定要強求「一次到位」。假如你還不熟悉 Ragic，想從零開始在 Ragic 建置的應用有非常多不同類型（例如想管一點人事資料、派工單，也想做一點設備管理、庫存扣減，又想有一張專案預算管理的表單），那並不需要一次就把所有類型的表單、所有設想中的功能都做好。
可以在確定大概架構後，先選擇一部分比較好入手（或最亟需改善流程）的區塊開始設計、導入，讓大家試用並調整後再慢慢拓展到其他應用，這樣比較容易掌握狀況 / 比較容易測試。
——當然，這個「不一定要一次到位」，也要配合表單架構來考慮，架構上會有密切關連/依存的一組表單，還是最好一開始就一起考量/設計，以免未來修改牽一髮動全身。舉例來說，你想要導入人事、行政管理、訂單管理的應用，其中訂單處理最迫切，那麼可以先設計訂單管理應用，以免開太多戰場，但訂單管理應用上一開始就設想好要相互連結的表單最好一開始就決定與設計好。
我們特別建議表單中的連結欄位最好一開始就設計好，因為在表單中已經有資料後，錯誤變更連結欄位，可能會造成資料遺失或是被取代成錯誤的資料。如果真的在第一波設計時沒想到某些地方，日後要修改連結欄位，也請務必先將該張表單的資料匯出來備份、或做整份資料庫備份，以防萬一。
不過，如果是一些其他的進階欄位設定（例如條件式格式），或自動化流程的設計（自動寄信、按鈕、公式），那就不一定需要一次到位，可以在架構階段釐清最簡單必要的基本功能是哪些後，把基礎、好上手、邏輯不那麼複雜的流程設計出來，有比較穩定的使用習慣後，再從一個一個小地方調整。
在 Ragic，因為修改調整的門檻低，資料庫不需要一次建置定生死，建置、測試、使用、調整、擴充，可以是動態循環的流程，這樣可以根據使用者回饋或公司需求（規模）的更動而彈性調整。只要每一次的調整上線前，搭配完善的測試、完善備份原有資料，就可以減少潛在問題。
環境與資源準備好了，有些人可能還是沒頭緒，不確定測試流程上實際到底怎麼走比較好？其實可以回歸到簡單的大原則，既然測試是為了避免「實際使用時發生不如預期的狀況」，那麼，最重要的就是像演習一樣，走一次實際運作的流程、把遇到問題的地方抓出來。
除了前面提到的：「設計完一個小功能，就可以順手測試一下該功能是否確實能運作」，確認單一功能運作都沒問題，設計完全部表單之後，最好也從預設中的使用者角度，模擬實際流程，從新增資料、點擊連結載入、拋轉等...依序跑過一次，看看是否運作正確。
一方面，這樣實際走過一次流程，可以抓到設計時可能遺漏的「功能與功能之間的銜接問題」（例如設計了「更新別張表單欄位值」後觸發目的表單公式的流程，有可能「更新別張表單欄位值」和「目的表單公式」設定都沒問題，卻沒考慮到若想「透過更新別張表單欄位值來觸發公式」，情況跟「手動在目的表單上修改資料觸發公式」情況不同，需要在「進階設定」中做相關勾選）。
另一方面，模擬走一遍實際使用的流程，也可以測試出一些「非關功能」的使用體驗，例如用起來是否直覺、是否順手、預設中的使用者是否能領悟如何使用。如果功能沒問題，但用起來卡卡的、體驗不順，也可以考慮要不要調整。
先前架構資料庫雛形的教學文章提到「繪製流程圖」的方法，如果在建置資料時有繪製出對應的流程圖，就可以直接依照這個流程順序，模擬不同的主要角色，依序建立資料，看看有沒有什麼不順的地方。
以「招募管理模組」為例，如果我自己設計出了這樣一組表單，要完整測試流程時，首先我會把流程圖找出來：
然後依照流程圖，從「內部提報徵才需求」開始，先在「徵才職缺提報與進度（內部用）」表單新增一筆模擬的徵才需求資料，然後到它對應的多版本工作表：「職缺說明（對外）」表單中確認有沒有自動新增一筆對應的資料、此表單有沒有不適合給外部查看的欄位資訊；並且確認以非 HR 的其他部門員工身份登入時，是否確實看不到「徵才職缺提報與進度（內部用）」的所有詳細資料。
接著，模擬求職者的身份進入「履歷表」表單填寫資料時，檢驗先前輸入的徵才需求在履歷表表單中點選「應徵職務（徵才編號）」時是否有正確出現....，另外，分別模擬「部門聯絡人」、「面試主管」、「人資」角色的流程，一一確認對應流程。
不管是測試單一功能，或整個走一遍流程時，都可能遇到這樣的狀況：測出某段流程（功能）好像有問題，但不知道為什麼發生問題、導致也不知道怎麼修正。
此時，你可以把出問題的流程盡量切成範圍更小的一個個環節，一一測試，確認哪個環節沒問題、哪個環節有問題，藉以縮小問題的範圍。
舉例來說，假設你設計了一個「最低庫存水位提醒」功能，希望系統每天固定時間檢查商品庫存表中的庫存數量，並在庫存數量低於表單中設定的「最低庫存數量」時，寄提醒信給自己，但測試時發現自己沒收到應該要收到的信。
假設這個功能是用類似我們部落格這篇教學文的方法，利用 Ragic 的公式、每日公式重算 Workflow、提醒組合而成的話，上述任何一個環節出錯，都會造成「沒收到信」的結果。
因此，可以先挑選其中「提醒」這個環節，把問題拆解成：是系統寄了提醒信但我沒有收到，還是系統根本沒寄信？
由於在 Ragic，你可以查看資料庫中所有系統信件的寄信紀錄（帳號設定 > 資料庫維護 > 下載系統記錄區塊），因此可以先查看這個系統紀錄，如果有找到對應的寄信紀錄，代表信有寄出，在 Ragic 這邊的流程沒問題，問題出在收信端（例如擋信、把信歸類到垃圾信件夾等）。
而如果沒有寄信紀錄，代表提醒可能沒有觸發，這時可以聚焦在「提醒沒有觸發」的問題，進一步分類問題並分頭測試，確認提醒沒觸發是提醒設定的問題、公式觸發的問題、還是公式本身設錯了？
例如，手動在「提醒日期」欄位輸入日期並在「排程管理」手動點擊「馬上執行提醒」，有正確寄出信件的話，那代表不是提醒功能這邊的問題。
同理，如果手動輸入（或修改）「最低庫存數量」欄位值，「提醒日期」欄位的公式有正確觸發，但利用另一筆資料在「排程管理」點「馬上執行 Daily Workflow」沒觸發公式的話，代表是每日公式運算 Workflow 上的問題。如果手動修改欄位值時公式就沒有正確觸發，那就是公式編寫問題，要看看語法是否錯誤。
這樣一步一步的把問題拆解成多個環節，每個環節都排除其他變數（例如盡可能搭配比較單純的「手動輸入資料」方式）來測試，可以比較快縮小範圍並找到出問題的嫌疑犯。
Ragic 提供了很多「檢查目前設定」與「查詢歷史紀錄」的工具，是揪錯時的一大幫手。另外，如果多知道一些大家常犯的錯誤，對找出自己的盲點也有幫助。這兩個部分因為細節較多，我們另文介紹，請參考此篇連結。
怎麼做測試呢？在已經有部分表單上線使用的情況下，如果你是想局部新增一些功能，例如加一個公式、按鈕、連結關係......你可以新開一個頁籤建立測試表單，測試完功能之後，再把新增的設定加在原表單、或將測試表單轉換成正式版。
不過，如果你要改動的東西牽涉到比較多表單，不方便在原有資料庫裡建立那麼多測試表單，也覺得「穿著衣服改衣服」不夠方便，其實你有另一個「建立測試環境」的方法。
你可以用另外一個 email 註冊一個全新的資料庫當作「測試環境」，利用 Ragic 備份還原的功能就可以快速將既有資料庫的設定備份到這個「測試資料庫」，修改、測試完沒問題之後，將測試資料庫的定義檔（不包含資料的設計架構）還原回正式資料庫就可以無縫接軌地使用了。
「另外建立測試資料庫」的建議步驟如下：
步驟一：註冊建立一個新的空白資料庫，這個資料庫會是之後的測試環境（測試用資料庫）。由於一個 email 只能註冊一個資料庫帳號，不能使用你之前用來註冊 Ragic 的 email ，要找一個沒有註冊過帳號的 email 來另外申請，有需要的話請在這個新的測試資料庫申請免費試用 30 天專業版。如果以前已經註冊過測試用的資料庫，付一名使用者（測試人員）的專業版費用直接使用即可。
（備註：我們之後規劃推出更適合建立「測試資料庫」的機制，到時這個流程會更方便一些～）
步驟二：利用 Ragic 備份還原的功能，在你原本正式使用的資料庫執行手動備份。
建議勾選下方的僅下載資料庫定義檔（僅下載資料庫的設計框架，不包含資料，檔案副檔名為 .ragic）。
備註：如果你希望資料也連帶放到測試資料庫做測試，且單純匯出、匯入資料有點麻煩的話，也可以不勾選，代表直接備份完整的資料庫（檔案附檔名為 .ragicdb），但由於「備份、還原完整資料庫」代表原本資料庫的一些流程性設定，如邀請使用者、提醒信件等也會被複製過去，所以得記得後續還原時，要將提醒刪除（以免測試環境寄出提醒信件讓使用者困惑）、將不需登入測試環境的使用者停權（以免使用者被邀請加入測試資料庫衍生困惑）。
步驟三：將下載好的備份檔案手動還原到測試資料庫。這樣就可以用比較輕鬆的方式，不需要重新建立表單就設定好你的測試環境。
步驟四：在測試資料庫中直接新增想要的新功能、新設定、新表單與連結等，完成並測試確認一切 OK 後，在測試資料庫中執行手動備份，此次一定要選僅下載資料庫定義檔。
步驟五：在正式資料庫中上傳新的資料庫定義檔、還原。這樣就可以將新的設計架構放進原本的正式資料庫，同時保留正式資料庫原有的資料。
要注意的是，另外建立測試資料庫的情況下，就不要在正式環境也同時都操作設計修改了，以免兩邊內容不同步而出現問題，詳細可能出現的問題請參考這篇文件。另外，如果你的新設計有包含「新增使用者群組」的話，由於群組也是系統表單的表單資料，新增的群組在還原定義檔時並不會自動被還原進來。不過，只要到群組表單中將新的群組手動加入或匯入就可以了。
如果你需要測試的功能跟「權限」有關，例如設定一般使用者只能看到自己的人事資料、人資群組的人才能看到完整資料且有編修權限，那麼你可能需要建立多個「測試用的使用者帳號」，用「一般使用者」以及「人資群組」的角色分別登入看看權限設定是否如預期運作。
此時，如果沒有那麼多 email 帳號可用於測試，該怎麼辦呢？ Gmail 有一個可以讓你「建立分身帳號」的小技巧，在此時就很好用！這部分我們已經有一篇詳細的教學文章，請參考這個連結。
這邊再次提醒：測試不同使用者身份時，記得使用不同的瀏覽器，或是開啟無痕分頁（例如 Chrome或 Safari的無痕模式），以免搞錯使用者身份喔！
