軟件質量與測試第6周小組做業：軟件測試和評估

基本任務

一、被測產品：百詞斬、扇貝單詞。

二、測試進度表

項目	內容說明	預估耗時 （分鐘）	實際耗時 （分鐘）
Planning	1.計劃	30	20
· Estimate	· 估計這個任務須要多少時間	30	20
Testing Design	2.測試設計	120	180
· Analysis	· 需求和測試需求分析	60	90
· Design Test Cases	· 設計測試用例	60	90
Testing Environment	3.搭建測試環境（安裝測試工具、管理工具等相關運行和支撐軟件）	30	60
Testing Implementation	4.測試實施	60	60
· Test	· 執行測試	60	60
Reporting	5.報告	60	60
· Test Report	· 測試報告	40	40
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	20	20
合 計	300	360

三、 功能模塊圖：

 

 我負責學習模塊，包括單詞查詢、學習單詞等功能。

四、測試用例：學習模塊主要是在肯定使用者詞彙量以後，進入學習界面，而後按照軟件給定的學習方式進行學習，同時不斷地複習鞏固。設計測試用例的方法以下：

　　（1）等價類測試：查詢單詞分爲中譯英和英譯中。單詞學習分爲點擊答案區域和點擊非答案區域。查詢單詞時考慮查詢專用單詞。

　　（2）邊界值測試：查詢單詞時，輸入複合單詞，或存在一兩個字母的拼寫錯誤的單詞（謬誤單詞），觀察查詢結果。

　　（3）場景測試：給定場景，設計測試用例，以便覆蓋每一個場景，能夠考慮一些特定的場景。。

 

這是單詞學習的事件流，以開始到結束的一條直線爲基本事件流，其它分支爲備選時間流設計測試用例。

 

這是單詞查詢的事件流，以開始到結束的一條直線爲基本事件流，其它分支爲備選時間流設計測試用例。

五、功能測試：

（1）單詞查詢測試截圖（查詢「華中科技大學」，依次爲百詞斬和扇貝單詞）

（2）單詞學習測試截圖（選擇正確答案，依次爲百詞斬和扇貝單詞）

六、測試管理工具：禪道；

     版本號：9.8.3；

     下載連接地址：http://www.zentao.net/download/80072.html

     導出文件（見附件）：需求、測試用例、缺陷；

     界面截圖：（依次爲執行測試用例、導出測試用例、缺陷）

七、測試結論：兩款軟件的單詞查詢功能能知足用戶的基本需求，但在一些專有名詞上顯得有些匱乏。例如在查詢「python」時，兩款軟件都只能獲得「巨蟒」這個解釋，而不能獲得其做爲計算機專用名詞的一個解釋，這對於一些具備特殊需求的用戶來講顯然沒法知足需求。此外，在查詢「華中科技大學」時，百詞斬可以準確地將其英文譯名顯示，但扇貝單詞則只能截取其中部分中文進行翻譯，而沒法將其做爲總體進行翻譯，這應該算是軟件設計的嚴重缺陷，與競品的差距也能夠體現出來。從用戶友好度上來講，百詞斬會保留歷史記錄，而扇貝單詞並無，顯然前者會更受青睞。對於學習單詞的功能，百詞斬很新穎地採用圖片四選一的方法來進行學習，而扇貝單詞會讓使用者選擇是否定識該單詞。前者較注重寓教於樂，然後者則偏於對單詞的深度掌握，兩者在這個功能上不分伯仲。從測試狀況和我的經從來看，我認爲百詞斬在查詢單詞和學習單詞上更具優點。

八、基本功能小組貢獻分：0.29。（小組狀況：17044:0.29;17062:0.21;17064:0.19;17065:0.31）

 

擴展任務

（項目做業和小組貢獻率見附件）

八、我的說明：

工做內容：設計測試任務卡，負責第一批次的採訪，負責結果統計。

心得體會：經過採訪，瞭解了新用戶對於軟件的使用狀況和見解，也對「百詞斬」這款軟件的優缺點有哦了更深刻的瞭解。做爲軟件測試人員，不能閉門造車，僅僅本身對軟件進行評測，要多傾聽其餘人的意見，進行彙總，才能對軟件進行更好的測試。

 

高級任務

（該測試方法無腳本；運行視頻見附件，視頻內容爲測試完成後各部份內容展現；定性和定量分析報告見附件）

九、測試專題：性能測試；

     測試工具：阿里雲測。

十、測試設計：經過阿里雲平臺進行雲端測試，從程序安裝包的安裝速度，程序的運行性能以及程序的後臺性能佔用程度三個方面來評測軟件的性能。

十一、工做感覺：我負責性能測試的執行過程。從測試結果和分析報告中能夠看出，百詞斬CPU佔用率較高，fps較低，電量和內存耗用正常，性能屬於中上水平。除去軟件自己的創新性，其高性能也是吸引用戶的必要條件，畢竟沒有人會願意使用一款使本身手機崩潰的APP。這也給了我啓示：軟件開發人員不只要會寫程序，還要會寫高效的程序。

十二、高級任務小組貢獻率：0.45。（17044:0.45；17062:0.05；17065:0.50）。

 

附加題

1三、實踐做業感覺：

第一次做業斷斷續續作了四五天，到截止時間前一小時所有寫完。最煩的就是需求不明確，頻繁改動，老師博客園的例子一開始也是錯的，加在一塊兒就無從驗證本身的算法正確性。並且以老師說會跑代碼，覺得會跑得很是嚴格，就對於無效輸入作了不少考慮，最終程序正確性卻是滿分。可是當時還沒開始細講測試，對測試用例和測試腳本的設計毫無頭緒，事實證實設計的確實不到位。原本想用C++作的，由於MFC實現圖形界面很方便，但考慮後續做業可能會有影響仍是用了Java（其實根本沒影響，不知道老師爲何第一次非得讓咱們用Java，莫不是需求崩盤因此第二次只能推倒重建）最後來不及了就沒作附加題，後來想一想有點不甘，其實也不難。

第二次做業確實是體會到了分組編程的溫馨，可是編40個測試用例是真的累，只能說分組要謹慎。需求明確就好寫不少，並且簡化了需求，還有隊友分擔輸入輸出部分，單寫核心模塊真的是很溫馨。測試的時候也找出了本身的設計缺陷。而後瞭解了一些代碼規範，性能優化，代碼評審方面的知識，固然我對於左大括號不換行的事實在不能苟同。此次的附加題仍是圖形界面，花了不久就作完了，想一想第一次做業就以爲很惋惜。

第三次做業，一開始對軟件的測試用例想了好久，徹底沒想法。測試真是不如編程簡單，軟件的測試也比單元測試難。後來時間來不及了，只能硬着頭作，照着本身的想法來。可用性測試頗有趣，採訪用戶的確不失爲一種很好的測試方法，並且最實用，最能體現核心需求。

總的來講，三次做業又當編程人員，又當測試人員其實不太好找本身的缺陷，由於會先入爲主地認爲本身的代碼不可能錯。這也體現了測試人員的重要性。軟件測試的做業也算讓我重拾了Java和Github，又學了點測試的知識，顯然是有所進步的。另外寫博客也無可厚非，可是對着要點來寫是不舒服的，比較費時間。

1四、參考文獻：

禪道軟件使用：http://www.zentao.net/book/zentaopmshelp/38.html

用戶調研：http://www.cnblogs.com/xinz/archive/2013/02/03/2890786.html

1五、小組貢獻分（一開始沒注意是整體算分，現統一更改小組內）：

17044:0.35；

17062:0.15；

17064:0.14；

17065:0.36