【正文】 ————————————————。1) 提示信息文字描述問題。5. Low建議，裝飾性問題，主要是界面方面問題。 2) JavaScript錯誤。 3) 數(shù)據(jù)約束與需求不一致。、排序等。 1) 各選項或按鈕沒有實現(xiàn)其本身的作用，但不影響其它功能的實現(xiàn)。 5) 數(shù)據(jù)丟失或毀壞。如確定按鈕實現(xiàn)了保存功能。如不能保存數(shù)據(jù)。如添加，修改按鈕不起作用。2. Very High嚴重，主要功能未實現(xiàn)或與軟件需求規(guī)格書不符。嚴重11金融統(tǒng)計與前置系統(tǒng)如部署在相同環(huán)境中，在高峰業(yè)務時段CPU會出現(xiàn)持續(xù)100%情況。嚴重7取消合法性的關聯(lián)，導致無論用戶報送數(shù)據(jù)是否正確，系統(tǒng)都能夠進行轉換，需要與用戶確認。建議5機構關系（一對多）導入20人并發(fā)時CPU占用較高超過極限值。建議3前置系統(tǒng)并發(fā)報送1千萬左右數(shù)據(jù)時導致業(yè)務失敗。測試人員測試時間2011年03月16日至2011年04月18日測試地點功能測試：西紅門開發(fā)基地性能測試：右安門機房災備環(huán)境測試人員測試項目負責人負責內容編寫測試報告、協(xié)調測試人員聯(lián)系電話13552823863測試人員負責內容錄制性能腳本，執(zhí)行測試，分析測試結果聯(lián)系電話15811199735測試人員負責內容編制測試數(shù)據(jù)，功能測試聯(lián)系電話602422992218測試人員負責內容編制測試數(shù)據(jù)聯(lián)系電話602422992292附件 問題缺陷列表問題編號問題描述嚴重級別1匯總任務提交效率較低。9）金融統(tǒng)計與前置系統(tǒng)綜合測試時發(fā)現(xiàn)，事務成功率偏低，%，%，%，CPU使用過高（按環(huán)境比例推算總行生產(chǎn)環(huán)境，數(shù)據(jù)庫服務器CPU有可能達到100%占用），建議優(yōu)化匯總執(zhí)行速度和成功率，不建議將前置系統(tǒng)與金融統(tǒng)計系統(tǒng)部署在同一生產(chǎn)環(huán)境下，避免在高峰業(yè)務時段互相影響。7）機構關系（一對多）導入功能滿足10個/分鐘的性能需求，但隨著業(yè)務的增加，系統(tǒng)有可能出現(xiàn)數(shù)據(jù)庫服務器的CPU平均占用過高情況和業(yè)務因超時而失敗現(xiàn)象，建議增加數(shù)據(jù)庫連接池數(shù)量。5）為縮短前置系統(tǒng)生成14位IJ文件階段的執(zhí)行時間，取消了合法性的關聯(lián)，導致無論用戶報送的數(shù)據(jù)是否正確，系統(tǒng)都進行IJ文件生成，并且生成IJ文件不對i文件和j文件進行壓縮，導致系統(tǒng)無法下載生成的后的IJ文件，需要與用戶確認。3）為縮短前置系統(tǒng)上傳14位IJ文件的數(shù)據(jù)校驗階段的執(zhí)行時間，取消了校驗后把14位機構數(shù)據(jù)轉移至臨時表的步驟，導致14位數(shù)據(jù)查詢功能不可用，需要與用戶確認。2）日常業(yè)務DB出表建議提高匯總提交任務響應速度和日常報表的生成速度。%,%，在總行環(huán)境中存在占用率達到100%的風險。機構關系（一對多）導入場景中的事務成功率為98%左右，事務成功率較低。5）前置綜合場景在綜合場景中，%～%，%～%CPU占用率過高，由此推算，在總行環(huán)境中存在達到100%的風險。4）機構關系（一對多）導入并發(fā)用戶由10個增加到20個時，平均響應時間增加，事務成功率降低，所以10個并發(fā)用戶是JDBC連接池30個時系統(tǒng)的處理極限。3）數(shù)據(jù)指標核對后臺數(shù)據(jù)指標核對隨著并發(fā)用戶的增多，系統(tǒng)處理能力增加，平均響應時間增加，數(shù)據(jù)指標核對場景滿足10個/分鐘并發(fā)用戶的性能需求。文件的處理時間雖然滿足性能需求中500條/秒的規(guī)定，但是在實際應用中去掉的功能需要經(jīng)過用戶確認。結果是：大文件（1000萬～1380萬）的處理時間為35分鐘，中文件的處理時間為1分鐘～8分鐘，小文件的處理時間為52秒～60秒。1）加載到臨時表與數(shù)據(jù)轉換由于測試時發(fā)現(xiàn)前置系統(tǒng)的上傳IJ文件功能存在處理時間很慢的情況，約在1小時30分，并發(fā)報送大數(shù)據(jù)量文件（1千萬條數(shù)據(jù)）時會出現(xiàn)業(yè)務失敗情況，為了解決執(zhí)行時間較慢問題，所以去掉了前置系統(tǒng)中14位機構數(shù)據(jù)轉移至臨時表的步驟，同時還去掉了數(shù)據(jù)轉換和生成IJ文件與金融統(tǒng)計系統(tǒng)的合法性關聯(lián)。3）刪除臨時表數(shù)據(jù)通過對系統(tǒng)進行大數(shù)據(jù)文件報送得出，臨時庫存量為9百萬量級時刪除138萬數(shù)據(jù)用時108～210秒，測試環(huán)境滿足開發(fā)提出的5分鐘內刪除數(shù)據(jù)的時間要求。2）日常業(yè)務DB出表由測試結果分析可知，不管是否進行上傳IJ文件的操作,從前臺頁面上手動執(zhí)行，速度都比較慢，且成功率較低，建議優(yōu)化調整。現(xiàn)開發(fā)部門還未提出優(yōu)化說明服務器名稱參數(shù)名稱修改前參數(shù)值修改后參數(shù)值用途描述測試結論及建議在測試環(huán)境中，由此得出的測試結論存在一定的風險?；旌蠄鼍跋到y(tǒng)資源： 從上圖中可以看出：金融統(tǒng)計與前置系統(tǒng)混合場景中，%，% 。結果貼圖：混合場景響應時間： 從上圖中可以看出：；；；機構關系（一對多）； 。當金融統(tǒng)計系統(tǒng)的并發(fā)用戶數(shù)不變，前置系統(tǒng)的并發(fā)用戶增加一倍，%，%。前置系統(tǒng)綜合場景上傳IJ文件：從上圖中可以看出：上傳大數(shù)據(jù)量IJ文件（1千萬數(shù)據(jù)）的時間是1小時18分，且在數(shù)據(jù)校驗階段出錯。前置系統(tǒng)綜合場景服務器資源占用：從上圖中可以看出：%，%。結果貼圖：貼圖中導出EXCEL表示后臺數(shù)據(jù)指標核對，開始上傳機構對照關系表示機構關系（一對多）導入，前置系統(tǒng)綜合場景響應時間：從上圖中可以看出：；前置綜合場景中機構關系（一對多）。經(jīng)分析，在綜合場景中，%～%，%～%,CPU占用率過高，在總行環(huán)境中存在達到100%的風險，建議優(yōu)化。 前置系統(tǒng)機構關系（一對多）導入20個用戶JDBC poolsize 50的系統(tǒng)資源：從上圖中可以看出：機構關系（一對多）%，% 。 前置系統(tǒng)機構關系（一對多）導入20個用戶JDBC poolsize 50的響應時間：從上圖中可以看出：機構關系（一對多）。 前置系統(tǒng)機構關系（一對多）導入20個用戶JDBC poolsize 30的處理能力：從上圖中可以看出：機構關系（一對多）， 。 前置系統(tǒng)機構關系（一對多）導入10個用戶的系統(tǒng)資源：從上圖中可以看出：機構關系（一對多）%，% 。前置系統(tǒng)機構關系（一對多）導入10個用戶的響應時間：從上圖中可以看出：機構關系（一對多）。前置系統(tǒng)機構關系（一對多）導入5個用戶的處理能力：從上圖中可以看出：機構關系（一對多）導入5個并發(fā)用戶JDBC連接池大小為30時的平均每秒成功事務數(shù)（TPS）， 。經(jīng)分析，系統(tǒng)滿足并發(fā)用戶數(shù)10個/分鐘的性能需求。（一對多）導入場景測試結果：場景設定總體情況服務器資源測試場景測試業(yè)務點并發(fā)用戶數(shù)交易平均響應時間（秒）交易成功率（%）CPU利用率(平均%/最高%)內存利用情況paging rate（平均/最高）機構關系（一對多）導入場景前置系統(tǒng)機構關系（一對多）導入JDBC的連接池數(shù)目為305%數(shù)據(jù)庫服務器：%/%數(shù)據(jù)庫服務器：機構關系（一對多）導入場景前置系統(tǒng)機構關系（一對多）導入JDBC的連接池數(shù)目為3010%數(shù)據(jù)庫服務器：%/%數(shù)據(jù)庫服務器：機構關系（一對多）導入場景前置系統(tǒng)機構關系（一對多）導入JDBC的連接池數(shù)目為3020%數(shù)據(jù)庫服務器：%/66%數(shù)據(jù)庫服務器：機構關系（一對多）導入場景前置系統(tǒng)機構關系（一對多）導入，JDBC的連接池數(shù)目調整為5020%數(shù)據(jù)庫服務器：%/%