软件测试第四周作业WordCount优化
1.小組github地址：https://github.com/whoNamedCody
? ?小組成員：17048冷福星 ? 17050李慎綱 ?17039付佳韻 ?17040康之是
2.psp表格：
?
| PSP2.1 | PSP階段 | 預估耗時 （分鐘） | 實際耗時 （分鐘） |
| Planning | 計劃 | ?30 | ?20 |
| · Estimate | · 估計這個任務需要多少時間 | ?30 | ?20 |
| Development | 開發 | ?245 | ?255 |
| · Analysis | · 需求分析 (包括學習新技術) | ?15 | ?20 |
| · Design Spec | · 生成設計文檔 | ?30 | ?30 |
| · Design Review | · 設計復審 (和同事審核設計文檔) | ?20 | ?15 |
| · Coding Standard | · 代碼規范 (為目前的開發制定合適的規范) | ?20 | ?20 |
| · Design | · 具體設計 | ?20 | ?20 |
| · Coding | · 具體編碼 | ?60 | ?60 |
| · Code Review | · 代碼復審 | ?20 | ?20 |
| · Test | · 測試（自我測試，修改代碼，提交修改） | ?60 | ?70 |
| Reporting | 報告 | ?130 | ?120 |
| · Test Report | · 測試報告 | ?50 | ?50 |
| · Size Measurement | · 計算工作量 | ?30 | ?30 |
| · Postmortem & Process Improvement Plan | · 事后總結, 并提出過程改進計劃 | ?50 | ?40 |
| ? | 合計 | ?405 | ?395 |
基本任務：
（1）接口實現：
本次小組作業中我負責的是輸入控制的模塊。和負責核心功能的同學商量后約定好我需要寫的輸入控制wcinput class中：input()函數讀取命令行參數，在input（）函數中進行判斷，不符合要求的輸入會提示重新輸入并退出；符合要求的輸入會作為input（）函數的返回值傳遞給核心模塊。
具體實現過程：
a.先判斷輸入命令行參數是否為空。
?b.再判斷命令行參數個數是否大于1（要求里只接收一個輸入文本）。
c.對命令行參數判斷完成后，判斷輸入參數是否符合形式規范（.txt）.
d.對符合形式規范的輸入，判斷是否為存在的txt文件。
e.篩選得到的正確輸入作為作為返回值，返回給核心模塊
（2）測試用例設計：
白盒測試：應用對路徑的測試，程序中對輸入的命令行參數進行了4次二分判定，圈復雜度為5
測試用例設計分類為：
? a.1-2-10
? b.1-3-4-10
? c.1-3-5-6-10
? d.1-3-5-7-8-10
? e.1-3-5-7-9-10
覆蓋了input()方法中所有的路徑。
?
黑盒測試：使用劃分等價類和邊界測試的方法。
（1）有效等價類：命令行參數為xxx.txt，且該txt文件確實存在
（2）無效等價類：輸入的命令行參數為空；輸入命令行參數內容為空（多個空）；輸入多個文件；輸入無效非txt文件；輸入不存在的txt文件；
（3）邊界測試：對參數個數進行邊界值判定，對參數內容進行邊界判定
(3)單元測試
?
測試質量： ?單元測試覆蓋了程序的所有路徑，對白盒測試和黑盒測試的幾類測試用例都基本實現了覆蓋，每個等價類中典型測試用例選擇了2到3個 。
被測模塊質量：被測模塊基本可以應對各種正確與非正確輸入，單元測試中輸入字符串為{}空時，顯示為“未輸入參數”；輸入字符串為{“”}時，顯示為“未輸入.txt”，該單元測試顯示為失敗。實際上進行命令行輸入時，只會出現args數組內容為空的情況，或者出現內容為多個“ ”的情況，都能被正確判斷輸出，因此被測模塊質量滿足要求。
?
?
擴展任務：
（1）代碼規范：代碼規范與復審（精簡版）現代軟件工程講義 3 代碼規范與代碼復審
選擇部分：代碼風格規范，代碼設計規范中的函數和錯誤處理
（2）規范分析：分析了17048的代碼
對項目中各模塊的靜態分析見（3）
不足之處：代碼中定義了兩個沒有無用變量；對{}的使用沒有另起一行，使得結構清晰標準；
好的規范：寫了詳盡的注釋，并且注釋為英文，格式統一，長注釋在前一行開頭，變量短注釋在定義后；
?變量命名遵循規范，具有一定的實際意義，便于區分；
?變量統一在方法前集中聲明，說明變量含義；
?函數方法設計分工合理；
?對可預料的各種錯誤輸入和異常情況進行處理；
（3）選擇靜態檢查工具：findbugs http://downloads.sourceforge.net/project/findbugs/findbugs%20eclipse%20plugin/1.3.9/edu.umd.cs.findbugs.plugin.eclipse_1.3.9.20090821.zip?use_mirror=ncu
?
findbugs檢查輸入模塊（input）沒有發現問題；
代碼規范上不足之處：{}的使用與小組其他成員不統一；注釋沒有使用英文注釋，平臺移植時可能出現問題；缺乏統一的變量說明注釋
規范之處：變量命名遵循規范，有實際意義；對各種錯誤輸入有所處理，容錯性提高；函數方法設計合理
（4）小組問題：小組成員各模塊函數和類的命名不夠統一（已改進）；代碼風格不統一（以改進）；整合后部分變量和說明有冗余（已改進）；銜接后部分異常處理重合（已改進）
?
?
高級任務：
（1）測試數據集設計思路：a.有140個以上需要根據詞頻排序的單詞
b.每種類型的單詞出現20個以上：純單詞如software；連字符單詞如content-based；單引號單詞如Let’s；帶短橫線的單詞如moon-;帶雙引號的單詞如“aaa;帶數字、常用字符和單詞的情況如(see Box 3–2).8885d_c01_016；帶數字的單詞如bbb-2;
c.5個以上統一單詞的大小寫形式，如apple和APPLE
d.5個以上詞頻相同的不同單詞排序，如：apple 5
camera 5
demo 5
yellow 5
zero 5
（2）優化前：統計從main函數開始運行到統計輸出完成的時間（單位毫秒）
（3）同行評審：
參加者：小組成員：康之是，冷福星，李慎剛，付佳韻
主持，記錄：康之是
評審者：李慎剛，付佳韻
開發者，代碼講解：冷福星
評審對象：核心模塊（kernel）
評審過程：開發者講解代碼邏輯，函數功能等；
開發者運行程序，測試壓力txt文件，反復多次，得到平均運行時間；
評審者提出意見，開發者回答；
達成共識，進行改進
提出意見：核心功能中先進行大小寫轉換再進行判斷，并且更改對單詞的判斷方法函數，采用正則表達式進行詞法分析。
（4）優化后：
改用正則詞法進行單詞判斷，并且先進行了大小寫的轉換
?
（4）影響性能的主要因素是核心功能中對單詞的判斷步驟，判斷語句的多少和嵌套的重數
（5）感悟：通過本次實踐，以及完成基礎任務，擴展任務以及高級任務，我認識到軟件開發要達到預期的要求，提升質量離不開對于軟件的測試。開發過程就像依據需求的圖紙在建一棟房子的基礎輪廓，能完成大致的形狀與功能；而搭好輪廓以后，需要進行測試檢查房子的承重，細節處是否存在偏差等。測試的過程中慢慢暴露基礎輪廓的各種缺陷，再進行調整與修改，經過多次自己的，他人的評審與測試，多次的修改，最終使得軟件質量達標。
?
? ? ? ? 小組貢獻度25%
?
?
轉載于:https://www.cnblogs.com/fujiayuntest/p/8710985.html
總結
以上是生活随笔為你收集整理的软件测试第四周作业WordCount优化的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 机器学习/深度学习 问题总结及解答
- 下一篇： error LNK2038: 检测到“R