[工作日誌] #9 整合測試系統

開發時期的整合測試

請認真想想，如果製作一個拿來驗證開發成果的整合測試系統，與上篇提到的自動化整合測試與驗證系統，他們的差別在哪裡？

後者其實就是前者的延續，甚至開發者製作了測試開發用的整合系統，後續的自動化驗證系統，也可交由非原開發者去製做。

前者應該已經要把有什麼對象，有什麼流程，有什麼料都寫好了。

後者只要拿來應用，組裝，加上一些驗證的程序即可。

但無論無何，這個部分一定要是原開發者製作，因為他最懂，因為他是作者，細節怎麼搞？為什麼那樣搞？

考量是原作者考量出的方案，當然要怎麼驗證要他去想。

不然維運人員何其無辜，就真的不懂呀。

我們的不足

這部分獲得開發者的保證，開發與維護應該就可以切開了。

當然非常可能有漏考慮的部分，有時候還是得回過來靠原開發者補足，一定還是有開發與維護人員一起討論的情況。

其實也是我們部門沒有自動化測試人員。

我知道外面有的是把這類的人員，有的是編在開發人員上，有的是算再維運人員身上，但我們就是沒有。

送測部門，只能做人為操作測試，呵呵呵..........

當然模擬使用者操作也是非常非常重要，送測部門也很熟練怎麼去擬訂人為操作的案例或SOP。

但有些東西，尤其是扯到大資料，大量處理，沒有自動化測試，沒有環境沒有條件，沒有拼死都要做mock銜接現實環境的限制然後作整合測試。

令人非常擔心，好幾萬的資料，好幾萬的request同時過來會不會錯，人工是無法測的。

上線 = 另一種送測，有爆掉的可能，多少心理可以有所準備。

當然自己上線前有時間就人工的code review，工作時間外常常也在思考會不會哪邊有意外，用自己本機有限的條件做片面或有限的測試等，努力了，也是非常不希望上線出問題。

這樣也好累，沒有令人心安的保證。

人類有人類的優點，機器有機器的，互相難取代。

所以，事發後......公司方面的反應，有的沒心理準備的感覺，在下面的我也是覺得非常無言。

要馬兒好，要又馬兒不吃草。