啥也不會還作出了機器學習——測試心得

寫這篇博客的時候真的是，心裏百感交集。

從啥也不會，到如今項目收工。一個學期的研究討論，真的是，全部人都辛苦了。

一羣人從0開始完成項目。主要技術崗們瘋狂看論文，找文檔 ，各類看……你們終於走到了能夠測試的環節了

而後就……喵喵喵？咱們的算法怎麼測試啊？

項目的主要難點在於算法，enas算法自己就是（按照如今的時間算的話）不到一年前才提出的新型算法。測試算法的話只能經過一個代碼測試準確率。而後呢……沒了。

有點不太對啊……

忽然想到咱們還有前端界面——微信小程序和後臺管理系統。

好，咱們能夠測試了。

---

 

 

 

這個測試主要針對的是微信小程序和後臺管理系統。而算法自己的準確率具備不可控性。（關於算法準確率的問題會在下面詳細說明）

因此 ，關於測試的報告就要……到來啦~

 

 

 

（微信小程序部分）

1.0測試用例設計

咱們隨機選取了200張/批次的圖片進行測試，對於結果進行累計統計。覆蓋正例訓練的十個類別。

1.1測試環境

1.1.1硬件環境

Android6.0及以上設備一臺，iPad/iPhone設備一臺：用於測試前端界面對於不一樣系統佈局是否正常，軟件因爲基於微信小程序，故只需正常開啓權限便可使用。

1.1.2軟件環境

基於微信小程序，微信版本須要能支持小程序運行。主要基於不一樣的系統，ios和安卓端的不一樣樣式，以及不一樣的屏幕所展示的不一樣效果。

1.2 測試工具

    本次測試未用到測試工具。 

1.3測試方法

經過人工對如下幾個方面進行測試：

1)   權限測試：因爲小程序在使用過程當中不是很須要用戶的相關信息，用戶的惟一標識也是經過獲取openId獲得的。而openId的獲取並不須要權限與受權。因此用戶給小程序受權與否並不影響小程序的使用和性能，以及數據庫的填充和信息獲取。

2)   UI測試：小程序的界面展現，字體，按鍵的方式位置

經過小組全部成員的手機進行測試，發現小程序的界面比較明確，按鍵也都同時顯示在屏幕上，字體由用戶手機自帶字體決定，因此總體沒有什麼問題。

3)   兼容性：針對不用的操做系統和屏幕尺寸以及微信版本，程序都能較好的適配而且完成既定目標與要求

小組成員的手機牌子較多，包含了安卓平臺和ios平臺，針對兩種大的平臺均可以較好的適應。針對你們的手機的不一樣的版本和不一樣的微信版本，也能夠有較好的適應結果。

4)   性能測試：頁面渲染時間，資源佔用問題——頁面是否會在屢次跳轉後出現長時間卡頓

在人工測試時，並未發現長時間卡頓現象。能夠屢次識別而且繼續識別進行跳轉。頁面渲染時間，在進入小程序後頁面渲染時間人體感知下沒法感知到。結果仍是比較好的。

5)   網絡測試：驗證在各類網絡環境與條件下小程序是否可以照常運行。

在測試過程當中，咱們在移動網絡和Wifi網絡的環境下均可以正常使用。在無網絡鏈接時，小程序能夠正常打開，進行簡單跳轉，可是因爲上傳圖片和文件下載須要網絡，因此小程序的主要功能幾乎沒法實現。只能看一下界面展現了。（能夠在沒網的狀況下把兩個界面跳來跳去）

6)   功能測試：按照數據流向進行測試，好比圖片上傳後在下一界面的展現是否正常完整正確。而後是界面跳轉功能，各界面的跳轉可否正常實現，按鈕的功能可否知足要求。在最後的相關論文查看界面，是否能查看/下載論文，可否成功將論文的相關連接引入。

 

針對功能咱們的結果能夠分爲兩類：

a)   圖片上傳顯示功能：

圖片能夠完整的顯示在要顯示的界面（也就是下一界面）。雖然因爲每一個圖片大小不一樣，會致使顯示時頁面有所變化，好比有的頁面能夠直接看到結果，有的頁面會須要下滑才能看到結果。因爲圖片大小的問題，頁面可能會出現須要下滑的狀況。可是全部的功能及按鍵都能較好的保存下來而且所有展現（圖片顯示這裏咱們爲用戶體驗也沒法進行修改，只能經過下滑進行其他操做）。並且圖片保存較爲完整清晰，能夠很明確的看出來最後結果。

在測試過程當中這個數據流向正確，而且顯示完整。

b)   跳轉功能：

關於跳轉功能，在跳轉的過程當中咱們的原跳轉界面和跳轉到的界面之間的跳轉都能正確進行，而且能較好的跳轉過去。並且關於界面保留，咱們的界面會保留一些須要比較頻繁的界面（也就是選擇識別內容的界面），其他界面會關閉。而後在識別結束選擇繼續識別時會將其他界面所有關閉，保證識別種類選擇界面是惟一保留的。

這樣的跳轉也保證了咱們的微信小程序可以支持屢次識別，不會由於頁面保留過多，頁面棧滿而致使卡頓。

c)   論文查看功能：
查看論文時會顯示加載中的字樣，讓用戶可以知道本身的已經點擊，論文正在準備中（界面會出現loading欄，提示字樣爲「論文正在趕來…」）。而若是用戶此時沒有鏈接網絡（未鏈接網絡時也能夠到達論文查看界面），則會提示用戶打開論文失敗。經過這樣的顯示可讓用戶對現階段的行動更爲了解，也符合Don’t Make Me Think的須要。

 

（web後臺管理部分）

2.1測試環境

2.1.1硬件環境

裝有瀏覽器且能正常上網的電腦和手機（不一樣系統都可）。

2.1.2軟件環境

web部署在裝有Ubuntu Server 16.04.1 LTS 64系統的服務器上，運行網頁須要設備（手機、電腦）上安裝某類瀏覽器（IE等）。

 

2.2 測試工具

    本次測試未用到測試工具（web安全訪問計劃採用AppScan測試工具）。

2.3測試結果

對後臺管理系統的各項測試結果以下：

1)   權限測試：權限測試：驗證用戶是否能夠未通過登陸直接訪問後臺。驗證時直接請求視圖函數/server等，會默認跳轉到登陸界面，沒法進行登陸。測試結果以下：

  

當用戶錯誤輸入密碼時，有錯誤提示：

  

 

若必填項爲空，會有默認提示： 

 

權限測試經過。

 

2)   UI測試：經過測試不一樣瀏覽器對界面字體圖層位置等的影響，發現對測試覆蓋到的瀏覽器都可以進行正常的顯示，在IE、QQ瀏覽器、360瀏覽器、搜狗瀏覽器，均顯示正常，且在顯示比例135%時，整個窗口適配最爲美觀。

 

3)   兼容性：針對不用的操做系統和屏幕尺寸的pc和平板，程序都能較好的適配而且完成既定目標與要求，可是對於手機的各類瀏覽器，有顯示不兼容的狀況存在，導航欄的顯示存在異常。

 

4)   性能測試：

a)   頁面渲染時間：因爲背景圖較大，在第一次登錄系統時，首頁面的背景會加載較長時間（具體時間與網絡情況相關，網絡正常的狀況下不超過三秒的加載）。

b)   頁面相應時間：各個頁面相應具體時間的測試狀況和分析見本報告的4.3性能數據與分析部分。

c)   資源佔用問題：運行頁面的時候不佔用太多系統資源，一般不會影響機器的運行，也與機器配置和瀏覽器相關。

d)   爲了提升用戶體驗，在數據量較大的部分頁面作了處理，例如在評價展現界面，只展現總體的分佈狀況和最新的20條具體評價內容，不會產生卡頓或者渲染失敗等問題。

 

5)   功能測試：按照功能模塊進行測試，好比點擊導航欄目查看不一樣的反饋數據以及按鈕功能是否出現BUG等。

測試環境：360瀏覽器

左側導航欄按鈕測試均正常，能夠正常跳轉，包括WX一圖識趣 V1.0該home鍵，以及admin鼠標滑過期可默認彈出下拉框按鈕。

點擊左側反饋統計頁面，稍做等待後會加載處頁面信息以下：

 

 

鼠標滑動到餅狀圖上能夠看到詳細信息： 

  

點擊左側日誌查看界面，能夠看到系統的最近日誌文件：

 

帳戶管理頁面默認展現當前管理員用戶信息內容，包括ID，用戶名以及密碼和用戶狀態，具體操做有左側選擇複選框後能夠進行批量刪除，以及添加帳戶和右側對每個ID進行停用操做：

選擇每行左側複選框（可多選）後，點擊上方批量刪除按鈕對用戶進行批量刪除操做：

 

點擊確認後頁面自動刷新並剔除所刪除的行，再也不展現到頁面上。

【注】

當未選擇任何複選框後，會有異常提示：

 

點擊添加按鈕，自動彈出添加窗口，用戶輸入信息後點擊添加會自動跳轉到主頁面，並展現添加一行。

 

【注】當必填項未選擇時，對必填項會有提示操做：

 

停用/啓用測試：

點擊每行後最後一欄對應操做按鈕響應。

 

測試結果及缺陷分析

3.1 覆蓋分析

3.1.1需求覆蓋分析

微信小程序部分：

首先進入界面，接着用戶能夠對須要識別的類型進行選擇（手寫體數字或CIFAR10數據集中的十類物品）。用戶進行點擊後能夠成功跳轉，而且屢次點擊不會出現卡頓與生命週期異常，確認無誤。

用戶選擇從相冊或相機拍照上傳圖片，上傳後能夠成功跳轉到下一個頁面，有相應反饋給用戶，確認無誤。

上傳後能夠正確接收後臺傳來的識別結果，並保存用戶提交的評價數據，識別結果較爲精確，確認無誤。

此外，在模擬單次傳輸後，咱們對後臺進行高IO測試，以200張每批次的測試樣例進行測試，得出正確率約90%，確認無誤。

需求覆蓋率=測試經過需求點/需求總數×100％=5/5×100％=100%

web後臺管理系統部分：

登陸界面驗證，輸入系統所分配的帳號密碼或者超級帳號能夠進行正常登陸；

頁面數據請求，點擊左側導航欄可切換不一樣頁面進行訪問查看，點擊左上方home鍵能夠返回第一頁面，點擊右上方admin正常下拉，點擊切換帳號或者退出可正常退出到登陸界面。

數據展現驗證，服務器狀態頁面可正常顯示後臺服務器信息。反饋統計頁面第一部分正常顯示統計餅狀圖，第二部分正常顯示用戶評價詳細信息。日誌查看頁面正常顯示文件信息和文件內容。帳戶管理可正常查看帳戶列表，點擊刪除按鈕和複選框能夠刪除用戶，點擊添加按鈕能夠正常添加用戶，點擊右側啓用/停用按鈕能夠啓用或停用帳戶。

3.1.2測試覆蓋分析

    略

3.2  缺陷統計與分析

因爲小程序未發佈，沒法進行負載測試與壓力測試。

3.2.1缺陷統計

3.2.1.1全部bug列表

web後臺管理系統部分：

①　在帳戶查看時，未點擊行前複選框就進行批量刪除會致使點擊肯定按鈕無反應（已解決）。

②　左側導航欄出現BUG，沒法正常跳轉。

 

3.2.1.2重要解決bug列表

在帳戶查看時，未點擊行前複選框就進行批量刪除會致使點擊肯定按鈕無反應（已解決）。

網頁左側導航欄出現BUG，第四個選擇的頁面只能在第三個窗口打開，其他窗口沒法打開。（已解決）

3.2.1.3遺留bug列表

暫無

3.2.2缺陷分析

本次測試發現的主要缺陷在於處理時間過長，致使客戶端響應時間太久，用戶體驗較差。

在後臺管理系統的測試中，因爲設計時未考慮手機使用後臺管理系統的相關狀況，因此後臺管理系統的網頁沒法在手機端使用，只能經過電腦網頁運行，手機不能使用。

3.2.2.1缺陷綜合分析

web後臺管理系統部分：

用戶登陸界面考慮安全問題，對密碼進行MD5加密操做，可是加密安全度不高。

在member-add頁面進行添加用戶時，未對密碼和用戶名進行加密操做和特殊字符驗證。

在數據庫評價信息過多時，評價結果展現頁面渲染部分較慢，渲染動畫未正常顯示。

3.2.2.2測試曲線圖

本測試曲線圖主要用於展現測試的正確率。

 

 

按理來講，做爲一個程序識別的準確率應該在95%以上，咱們目前只能達到93%以上。可是正如測試圖像所示，這個識別的準確率是一個波動上升的曲線，只是因爲時間和金錢的限制，致使咱們沒法繼續訓練進行識別。相信若是能夠繼續訓練，這個模型的結果能夠有更好的結果。

3.3 性能數據與分析

3.3.1性能數據

經過運行記錄識別所用的時間，咱們對5000張測試集進行測試，輸出結果時間。能夠看出一次識別的反應時間大概在0.1s左右。對於一個用戶來講，這個時間應該還處於能夠接受的範圍。  

 

 

3.3.2測試結論

測試能夠經過。雖然反應有些遲鈍，可是還能知足用戶的基本識別要求。而關於後臺管理系統，雖然手機端不能適用，可是使用電腦能夠很好地進行使用和查看管理。因此本小組認爲這個程序能夠發佈使用。

 

測試總結和建議

4.1軟件質量

軟件開發成功達到預期目標，能夠交付使用。

4.2軟件風險

目前對於後臺的管理審計未進行安全性檢查，前端因爲託付在微信小程序端，故數據安全性受到微信限制。

4.3測試結論

對測試計劃執行狀況以及測試結果進行總結，包括：

1．主要測試方面均已涉及，但較爲淺層，對於安全性問題未深刻考慮，主要功能實現並獲得良好測試

2．在測試風險應對方面，積極給出測試方案與樣例設計，對可能遇到的邊界狀況以及數據通路進行了檢查

3．完成了預約的測試目標並測試經過

4．能夠進行下一階段的檢查

 

---

 

經過設計，對後臺管理系統和微信小程序作了一系列的基本測試。

在測試的過程當中，咱們儘量的將全部能想象到的內容完成。可是可能有的時候尚未 很考慮到一些奇葩用戶的奇葩需求。已經儘量的將特殊狀況進行想象和測試，而且對過程當中出現的bug進行了解決。可是由於沒有學過測試的相關內容，對測試實在是不夠了解。沒法清楚地對項目進行測試，也沒法很專業系統的進行測試工做。

自己因爲咱們項目的特殊性，在完成過程當中也屢次感受到了咱們的特殊。咱們的項目其實需求很簡單。名字解釋了一切——基於Pytorch圖像識別的ENAS。重點在於算法實現，所用框架爲Pytorch，其中沒有寫的就是，網絡架構爲CNN（卷積神經網絡）。簡單的需求也註定了咱們所獲得的結果簡單，自己就不具有很高的表面工做量。而最爲核心的部分又有代碼幫忙進行測試。因此咱們的測試結果具體如何仍是有些未知的。也算是一系列的未知數。

總結一下——在進行測試的過程當中，仍是感受到咱們的許多不專業性。最後，就有點玄學了……一切看玄學吧。

 

---

 

 

2019.1.4補充

偶然狀況下，咱們發現原來微信小程序能夠自動測試。微信開發者工具也具有測試功能。

因此咱們抓緊最後機會使用自動測試對微信小程序進行了一個測試。可是因爲測試具備冷卻期（24小時）。因此只生成了一個測試報告。

下面展現的是微信開發者工具進行測試所獲得的測試結果：

 

將其中主要內容放大，這裏主要是針對性能進行測試而且獲得及彙報結果：

 

接着，因爲第一個界面存在渲染，因此只有這個界面出現了加載時間。

 

其他全部界面都能正常顯示，就是數據信息幾乎都不存在。應該也是這個測試工具的不成熟與不完善吧。（或許是自己這些信息在這個小程序中就沒有顯示與測試的必要） 

使用下來感受微信小程序的自動測試結果還不如人工測試。不過在針對性能的測試中微信小程序的自動測試有數據支持，更具有說服力和可信度。

 

---

 

 

最後再說一些心得吧。

咱們在進行測試的過程當中，一開始因爲種種問題，有些bug沒有測試出來（也是因爲咱們對測試的不熟練與不熟悉）。而後還有咱們在使用微信的過程當中遇到的種種反人類的設計，對用戶至關不友好。後來經過修改，讓小程序幾乎是教學式操做，這樣處理後小程序也就比較的友好外加比較符合Don't make me think的基本要求了。

其實小程序在使用的過程當中仍是發現了一些設計上的不完美的，好比說物品識別返回結果是英文，不夠貼合用戶，可是因爲時間限制不太敢進行更改了（從週三開始進入項目冷卻期，避免bug的出現，可是週五才以爲這裏實在是反人類……但是已經要上交服務器了），這也是咱們下一步要對這個項目進行更改和完善的內容。

作項目的過程真的是體會到了開天闢地，測試的時候也是人心惶惶。當時測試的時候測出了一個bug就一羣人特別緊張，怎麼辦，要怎麼處理，五我的這幾天一直在集中開發，而後集中測試，一我的測出了bug，就有一羣人圍着開發人員，瘋狂改代碼，解決bug。尤爲是今天上午和昨天，感受就體會到項目上線前開發者們的瘋狂。不過在測試的過程當中依舊感受咱們的測試不夠專業完美具體，仍是有很大的改進空間。這個項目雖然實現，可是不能否認它有二期的可能性。不過一切可能性都留給將來就好。

 

此次測試也算是告一段落，這個學期也走向了終結，人生中第一個項目也就塵埃落定。咱們這個「啥也不會還作機器學習」開發小組，終因而從啥也不會到勒作出了機器學習。