測試python/django中的神祕加載錯誤

Question

這與Configure Apache to recover from mod_python errors有關，儘管我已經停止假設這與mod_python有關。從本質上講，我有一個問題，我無法一直重現，我想獲得一些關於是否可能提出解決方案的反饋意見，以及嘗試重現此問題的一些潛在方法。

設置：django支持的站點在使用幾天後會開始拋出錯誤。它們始終是ImportError s或ImproperlyConfigured錯誤，這相當於同樣的事情，因爲消息始終指定加載某些在settings.py文件中引用的模塊的問題。這通常不是同一班。我正在使用帶8個分叉子的preforked apache，每當這個問題出現時，一個進程會被中斷，七個會被罰。一旦中斷，每次請求（在apache conf中都帶有Debug On），每次請求都會顯示相同的跟蹤，即使負載失敗與特定請求無關。在短期內，httpd restart總是讓問題消失。

注意到的問題：安裝和更新通過svn與一些更新後的腳本執行。幾個.pyc文件意外地被檢入到存儲庫中。另外，項目本身是由一個用戶擁有的（不是apache，儘管apache對這個項目有權限），並且有一個持久性插件，最終以root身份進行後臺操作。我將這些問題稱爲這些問題，因爲我是否注意到這個錯誤是錯誤的，因此我修復了它們。該項目由apache擁有，該插件作爲apache背景。所有.pyc文件都不在存儲庫中，並且在服務器和插件停止運行時，每次簽出後都會強制重新編譯這些文件。

我想知道的是

1. 做這些配置的災難似乎是零星ImportError個可能的解釋？
2. 如果有是在我的代碼中還有其他問題，我該如何最好地重現它？

至於2，我到目前爲止的方法是編寫一些壓力測試，重複請求同一頁面以執行通用代碼路徑。

順便說一下，自修復以來，這已經運行了大約2天，但問題發生時間爲1到10天。

Answer 1

「做這些配置的災難似乎是零星ImportErrors一個可能的解釋」

是。舊的.pyc文件是第一大災難。

我們在Windows上開發，但在Red Hat Linux上運行生產。一個意外移動的.pyc文件是調試的絕對祕密，因爲（1）它通常運行，（2）它具有用於原始源的Windows文件名，使得回溯錯誤絕對沒有意義。我花了幾個小時盯着日誌 - 在linux上 - 想知道爲什麼文件是「C：\ This \ N \ That」。

「如果在我的代碼的其他地方還有問題，我該如何最好地重現它？」

重現錯誤之前，您應該嘗試阻止它們。

首先，創建單元測試來鍛鍊一切。

從Django開始tests.pytesting。然後將所有非Django組件擴展爲unittest。然後給自己寫一個「run_tests」腳本，運行你所擁有的每一個測試。定期運行。每日通常不夠。

其次，請確保您使用的是logging。重。第三，在這樣的通用異常日誌塊中包裝任何使用外部資源的東西。

try: 
    some_external_resource_processing() 
except Exception, e: 
    logger.exception(e) 
    raise 

這將幫助您查明外部資源的問題。由於權限或訪問問題，文件和數據庫通常是不良行爲的來源。

在這一點上，你已經防止了大量的錯誤。如果你想運行循環負載測試，那也不是一個壞主意。爲此使用unittest。

class SomeLoadtest(unittest.TestCase): 
    def test_something(self): 
     self.connection = urllib2.urlopen("localhost:8000/some/path") 
     results = self.connection.read() 

這不是最好的方式做的事情，但它顯示了一種方法。您可能想要開始使用Selenium來測試網站「從外部」作爲您的單元測試的補充。