之前有一個專案
被神奇的上頭說:「正式環境跟測試環境會不一樣,所以正式環境也要創建測試帳號給人測試!」
所有資料都是從測試環境在測試完成後
在上傳到對外伺服器
我們在測試環境測試完之後,要在到正式環境測試一次,
有人會做這種神奇的事情嗎?
(現在的專案是在正式環境,直接進行測試跟修改)
神啊救救我吧~
應該要補上他的特殊要求
正式機已經對外使用,
在正常一兩年後,
為了新增功能,所以新創測試帳號,
新創的測試帳號要求,(因為有分階層,一般人員,部門主管,部門經理,總經理,每個層級看到不一樣,約有21個部門)
所有部門都要在正式機,創建測試帳號,
所有資料結構都要有串接
在正式機使用狀況下
正式帳號登入者不能看到測試帳號的資料
測試帳號登入只能看到測試帳號的資料
基本上來說,正式站有測試用的帳號還是有其必要性的。
只是....
一般在正式站的所謂測試。都是算是最終的測試了。
並不會依此做為修改依據。只是拿來當檢測使用而已。
單純在上架後在做一次全部的檢測。
理論上可以將其當成試機的動作。
如果說在正式機上可以測出bug的情況。
這也代表有機會是系統環境不一致的問題所造成的。
這理論上來說開發者也是需要檢討的地方。
總之,正式站開測試帳號本身並沒有問題,還是有其必要的。
正式機已經對外使用,
在正常一兩年後,
為了新增功能,所以新創測試帳號,
新創的測試帳號要求,(因為有分階層,一般人員,部門主管,部門經理,總經理,每個層級看到不一樣,約有21個部門)
所有部門都要在正式機,創建測試帳號,
所有資料結構都要有串接
在正式機使用狀況下不能看到測試帳號的資料
在正式機使用狀況下不能看到測試帳號的資料
正常這個做法就不是很對。
雖然我說正式機還是有其測試號的必要性。
但它對正式機來說,還是屬於正式號。
雖說的確是拿來測試。但還是得將其數據列入正式處理。
如果是有帳務方面的問題。就得將其列入內帳處理。
而並非用程式處理成看不到或是刪除處理掉。
一切還是得遵重正式環境下的機制才行。不能做例外處理才對。
基本上有做系統管理員帳號的後門就不用擔心了(誰都看不到~只有開發者看的到~限特殊方式進入系統)
正式BD裡面混雜大量測試資料,
這個讓我跟他說這不是測試,
我是認為正式機的測試,是在使用者出現bug的時候,因為同樣環境進行同樣的測試(因為真的有時候某些情況正式機就是出問題,自己環境就是沒事情,可能正式伺服器被限制了某些連結之類的)
但是正式機創建測試帳號進行公開測試,這個是我無法理解的。
其實你也不要無法理解。
你只要這樣想就好。為何自已的環境沒事,正式機有事?
那要怎麼辦呢??
一般來說我會用兩種做法。
一種是做單元測試。這比較可以符合你想要的東西。
一方面可以測試正式機上的問題又不影響正式機的運做。
但一般來說,如果是重新開發的程式,隨手做單位測試是還ok的。
但舊制情況的程式碼。要做單位測試就不是很ok了。
所以我常會用的方式是第二種。
另開一個測試用的平台。在同一環境下。可切換使用正式資料庫,還是測試資料庫。
不過這樣的方式需要浪費資源。很多公司並不太願意這樣做。
上面有大大說 docker 這樣的技術。其實目的也是為了環境統一。
我自已公司的電腦,由於主機規劃都是我在處理的。
所以基本上我本身的環境因素就容易保持一致了。
認真來說,我是可以認同你不要在正式機上做測試。
但這是得建立在你可以不需要在正式機上測試,
就能找出問題跟時間測試的情況下。才能這樣大聲說不行。
你絕對不要說「我這邊測就是沒問題」
你會被打死的。
做不到單位測試或是上線假測試的情況下。
就不要說覺得正式機上開測試帳號是無法理解的事。
因為業主或公司主管,也是跟你一樣無法理解。
你要提出能說服的方法才行,而不是只對自已說無法理解。
在旁人看來會覺得你只是想要省事不想做,怕麻煩的感覺。
懂我說的意思嗎?
還是有其必要,我做的系統上線都十一二年了,也還是有留測試帳號,每筆交易都會留下建立者的id,如果是測試帳號,在出現BUG測試時就會用到,測試完畢,也會用一個storeprocedure,一個指令就清空所有測試帳號所建立的資料
會在正試環境建測試帳號,原因如下: