明天就是微信搶票的ddl了，總算快熬出頭了！
本次軟工三大作業，自己花了不少於150小時，可以這是我耗時最多的一個大作業。其實原本我是不打算在一門課的大作業上面花那么多時間的，但是由於劉強老師對我們組期望比較高，群主大腿又實力超群，自己不能拖太多后腿，於是只能用時間去拼成果。最后的結果還算滿意。提交的PR節省了全班許多人的寶貴的時間，1800的並發應該是全班最高了（並發提高過程詳見群主博客），郵箱驗證的安全性的確比info賬號密碼高很多，功能測試最終也達到了很高的覆蓋率（adminpage/views:90%，userpage/views:100%， wechat/handlers:97%）。
根據課程要求，總結主要收獲如下：
- 框架
- 體會到了一個好的框架有多么重要
- 體會到在一個別人開發的有不少bug的框架下調試有多鬧心
- 功能測試
- 學習了selenium，包括phantomjs、expected_conditions、WebDriverWait、By，Keys等。
- 學習了Django的LiveServerTestCase進行功能測試。
- 了解功能測試和單元測試的聯系和區別，學習了mock和fixture的運用
- 了解了測試覆蓋率
- 團隊協作
- 性能優化
- 了解JMeter的運用
- Linux系統參數
- uWsgi參數
- nginx參數
- mysql參數
- 嘗試了Docker部署
- 嘗試了搭建二維碼服務器
- 嘗試了使用celery實現異步定時任務
不過，在這次作業中讓我感到很遺憾的是我有三個預期的功能沒有實現。
第一個沒有實現的功能是搭建二維碼服務器。最初，我們想的是為了使用戶能在不點進電子票詳情頁的情況下檢票，因此需要將電子票二維碼顯示在我的電子票列表中。這就需要一個一個二維碼的url，我總共想了4種方法。
- 最簡單的就是利用python的相關庫如PyQRCode（此處手動感謝王永赫同學），直接生成一張圖保存在搶票服務器上，並返回該圖片的鏈接。但是這會導致服務器里存儲大量的二維碼圖片，對內存消耗較大。因此我並沒有去實現這種做法。
- 另一個是采用現有的二維碼服務器，如清華大學圖書館采用的二維碼服務器。這樣只需要將需要電子票的unique_id使用get方法的參數傳過去便能獲得一張二維碼圖片。但是這樣會導致電子票的unique_id泄露，不安全，因此我們也沒有使用這種方法。（此處手動感謝群主）
- 第三種方法是使用dataurl，這樣能解決上訴兩個方法存在的所有問題，可是，悲傷的消息是微信不支持dataurl，於是只能放棄。
- 最后一種方法是自己搭建一個二維碼服務器。該二維碼服務器收到get請求時根據參數返回一張二維碼圖片。我們采用的正是這種方法。經過遴選，我最后決定使用PHP Qr Code。可是，由於對nginx和apache都很不熟悉，配置apache的過程中我遇到了很多問題。最后的結果是我花了一天的時間還是沒有配好，由於時間緊張就放棄了這項功能。
這次失敗給我的教訓是配環境時盡可能一步一步的來，每一步都最好能確認確實配置成功了在進行下一項配置，否則最后出現了問題也不知道具體哪一步錯了，就很耽誤時間了。
第二個沒有實現的是docker部署。由於助教給的ppt中講得比較簡略，其中還不少拼寫錯誤，因此我在按照助教給的ppt中的教程一步一步往下配置的過程中遇見了很多問題。折騰了一天之后決定先自己好好學習一下docker在進行部署，於是第二天自己看了一遍docker的教程並重新開始配置。這一次，我解決了前一天沒有解決的許多問題，當然也遇到了很多新的問題，最后卡在了mysql密碼錯誤無法登陸，無論我們設置MYSQL_ROOT_PASSWORD也好，設置USER_PASSWORD也罷，甚至進入進入容器內嘗試各種密碼，最終都無法登陸mysql。為此我和群主連續兩天調到深夜，還是沒有解決。最后由於時間緊張不得不放棄使用docker部署。（此處手動感謝璠神在我配置docker過程中給予的幫助，感謝群主堅持到深夜仍不放棄我和我的bug）
這次失敗讓我明白一個靠譜的教程有多么重要。當然，自己輕視docker配置的難度，在不了解docker的情況下草草動工，以至於浪費了較多時間，這才是這次失敗的主要原因。
第三個沒有實現的功能是搶票前30分鍾提醒用戶功能。搶票提醒是一個異步任務，我采用了celery來實現。最終由於在測試過程中微信的access_token調用次數達到上限而無法繼續調試。比較不合理的是access_token的有效時間是兩小時，每天可調用的次數是兩千次，因此按理說不可能不夠用。最終發現框架果然實現得有問題，於是我修改了框架並提交了PR。但是，這時已經到星期三晚上了，第二天就得展示，雖然功能已經實現但是還有bug，我只能選擇放棄該搶票提醒功能。
這次失敗，可以說主要原因是因為我的調試方法不太好，應該先測試異步任務，確保其實現正確后再測試完整的功能，導致測試效率較低，甚至觸發access_token上限。當然，由此發現了框架中的bug也算一點補償吧。
當然，使用selenium進行自動化測試的過程中我們也遇到了一些問題，這里做一個簡略的記錄。
| 遇到的問題 | 解決方案 |
| 測試過程中無法直觀的看到效果。 | 輸出截圖：self.browser.get_screenshot_as_file("pic.png") |
| phantomjs默認分辨率太低，導致部分按鈕被響應式布局藏起來。 | 設置瀏覽器分辨率：self.browser.set_window_size(1024, 768) |
| 頁面跳轉需要時間，不能立即響應 | 使用WebDriverWait和expected_conditions |
| send_keys只能在文本框的原有文本后添加keys | send_keys之前先調用clear清楚文本框中的當前內容 |
| 文本框會有回調函數，導致每次修改文本框內容之后都不能立刻見效 | 每次修改文本框內容之后都調用sleep |
| 不同測試函數之間存在數據干擾 | 在測試函數開始之間刪除可能會產生干擾的數據並重新生成一遍所需數據 |
| 在測試與微信交互的過程中，從xml中解析出來的url和測試環境中的url不一致 | 將解析出來的url中的相關參數解析出來，並結合self.live_server_url手動生成正確的url |
最后，在這次項目開發過程中，像群主學習到了很多，在此表示感謝。