軟體測試第4周小組作業 WordCount優化

2022-07-16 14:36:17 字數 3498 閱讀 9138

psp2.1

psp階段

預估耗時

(分鐘)

實際耗時

(分鐘)

planning計畫5

5· estimate

· 估計這個任務需要多少時間55

development

開發235

340· analysis

· 需求分析 (包括學習新技術)

1530

· design spec

· 生成設計文件

————

· design review

· 設計複審 (和同事審核設計文件)

————

· coding standard

· **規範 (為目前的開發制定合適的規範)

1010

· design

· 具體設計

3030

· coding

· 具體編碼

120180

· code review

· **複審

3030

· test

· 測試(自我測試,修改**,提交修改)

3060

reporting

報告45

45· test report

· 測試報告

3030

· size measurement

· 計算工作量55

· postmortem & process improvement plan

· 事後總結, 並提出過程改進計畫

1010

合計285

390我負責輸入控制模組,概況如下:

實現步驟分為兩步:

(1)、第一步對命令列輸入的檔名字串進行處理,識別是否是有效的txt並給出提示,考慮了如下幾種情況:

a.一次僅處理乙個檔案:若用空格隔開輸入多個檔名,僅處理第乙個,即args陣列第乙個元素args[0],並會提示輸入了多個檔案。

1

//一次僅處理乙個檔案,不同時處理多個檔案。有多個檔案時輸出提示

2if(args.length >= 2)

3

b.通過pattern匹配正規表示式判斷是否是.txt,不是則輸出提示並退出程式。

1

//判斷輸入的是否是txt檔案,是則開啟並提取單詞

2if (pattern.matches(".*\\.txt", args[0]))36

else

7

c.ioexception含有『系統找不到檔案』提示,故未寫

d.對檔案中有無單詞的判斷寫在main函式裡

(2)第二步對檔案中的內容提取單詞

當if判斷輸入的是txt檔案,則開啟檔案並提取單詞,以下**為提取單詞部分。

按照作業要求中判斷單詞的兩個條件運用正規表示式匹配進行提取,

「[a-za-z]+-?[a-za-z]+」為0或1個「-」前後有1或多個英文本母,考慮到「這種情況night-,帶短橫線的單詞,視為1個單詞,即night。」

「[a-za-z]」為只有乙個字母的時候的補充,因為上式最少情況下有兩個字母。

因為是按照條件直接抽取的單詞,不是像第二週一樣根據分隔符用spilt()方法劃分單詞,數字和常見字元就不需考慮在內。

1

//檔案內容以行為單位提取單詞

2while((line = br.readline()) != null)3

12 }

採用黑盒測試的等價類劃分設計測試用例,分為兩大類,一類是對檔案讀取錯誤時會產生的提示的測試,一類是對含不同字元的文字進行單詞提取的結果。因為寧寧已經對第一類測試用例進行了設計,所以我僅對第二類進行設計,對易產生問題的規定的常見字元都覆蓋了進去,字母和數字挑選了部分,提高測試效率。以下為例子,全部20個測試用例在github的「測試用例.xlsx」檔案裡。

挑選了其中十個測試用例進行執行。因不知道如何將被測單元的控制台輸出重定向進行對比,所以沒有測試第一類是對檔案讀取錯誤時產生的提示,僅測試了第二類對單詞的提取。人工對第一類進行測試也出現了一些問題,如發現對檔名引數處理的部分,若使用者輸入時用空格隔開多個檔名且第乙個檔案不是txt,第二個檔案是txt,由於只處理args[0],會提示輸入的不是txt。若用其他字元隔開多個檔名則一同被存進args[0],則會提示系統找不到檔案,這都是考慮有所欠缺的地方。所以測試質量和被測模組的質量均有待改進。

所有小組成員已經完成擴充套件功能。

採用的鄒欣老師的講義「現代軟體工程講義 3 **規範與**複審」

分析了組員17010的**。

首先她的優點是,每行**都有良好的注釋說明,縮排也很工整,讀起來簡明易懂。

缺點有如下幾條:

運用的工具是findbugs,idea外掛程式中安裝的,安裝方法如:

發現了乙個問題:函式名首字母應該是小寫。但是根據鄒欣老師的**規範,所有的型別/類

/函式名都用

pascal

形式,即所有單詞的第乙個字母都大寫。

我遵循了

類名和函式名首字母都大寫,大括號每個佔一行。

經過審查,發現整個小組大部分存在以下問題:

所有小組成員均完成高階功能

採用了兩種型別的資料測試集:

小組分工:

我們對每個人**規範,**中可以提出的優化進行評審,最終認為影響效能指標的主要因素如下:輸入檔案大小

輸入檔案中包含特殊字元比例

輸入檔案中包含由空格隔開的字串數量

排序時所採用的演算法是否高效。

硬體制約因素如:磁碟i/o,cpu效能等。

單詞重複率,treemap中是否有該單詞,如果乙個單詞重複率很高,那每次在treemap中找單詞的時間並加一的時間要比直接新增到treemap中的時間長。 

在均是由**隨機生成txt的情況下,檔案越大,時間越長。

但是對於英文**txt,在檔案大一倍的情況下執行時間卻少一半,這是因為英文**由規律的有限數量的單詞和字元組成,單詞種模擬隨機生成的字串種類少,在統計計數階段,由於要在map容器中查詢該單詞是重複出現的單詞還是新出現的單詞,隨機生成的txt的樹節點多,查詢代價大,所以所需時間長。

同時不同成員電腦上執行的時間不一樣,說明與電腦硬體也有關係。

本次作業實踐中,基本任務完成了軟體開發和軟體的動態測試,擴充套件功能完成對**的靜態測試,高階功能對效能進行測試和優化,進一步提高軟體質量。

軟體開發、軟體測試、軟體質量之間的關係應該是:

沒有軟體開發就沒有測試,軟體開發提供軟體測試的物件。

軟體開發和軟體測試都是軟體生命週期中的重要組成部分

軟體測試是保證軟體質量的重要手段。

第6周小組作業 軟體測試和評估

小組成員 胡浪,謝奇光,羅小虎,郭子賢 窗體頂端 1 計畫說明 a.我們組選擇的兩個對比產品是百詞斬與扇貝。b.psp 專案 內容說明 預估耗時 分鐘 實際耗時 分鐘 planning 計畫 estimate 估計這個任務需要多少時間 testing design 測試設計 analysis 需求和...

第6周小組作業 軟體測試和評估

本次作業我們小組選擇的對比測試產品是百詞斬和扇貝單詞兩款產品。測試進度表如下 專案 內容說明 預估耗時 分鐘 實際耗時 分鐘 planning計畫3 4 estimate 估計這個任務需要多少時間34 testing design 測試設計 6070 analysis 需求和測試需求分析 3030 ...

第6周小組作業 軟體測試和評估

小組成員 胡浪,謝奇光,羅小虎,郭子賢 1 計畫說明 a.我們組選擇的兩個對比產品是百詞斬與扇貝。b.psp 專案內容說明 預估耗時 分鐘 實際耗時 分鐘 planning 計畫estimate 估計這個任務需要多少時間 160220 testing design 測試設計 3040 analysi...