一、歐萊雅（中國）開系統
1、以前幫歐萊雅中國做店務通系統，程式中遇到過C++打開檔案操作檔案，不關閉，導致全國的零售終端越來越慢。——操作檔案完成之后，要關閉
2、北京同仁堂的店務通系統，由于資料庫的日志輸出不當，服務器的日志越來越龐大并且塞滿了硬碟，導致一些用戶操作越來越慢——日志輸出問題
3、大量的業務（進貨、入庫、會員、銷售）所有的業務只操作一張表transactionlog表，最后做了分表操作——架構優化問題
二、法院審判軟體
1、資料庫打開不關閉，導致系統要每天都要手工重啟服務，用戶體驗極差——資料庫打開不關閉。
2、并發的問題，導致僅僅有5個人員在進行錄入案子的操作的時候，就能把其他的案件資訊自動帶過來——程式優化。
三：名品打折網
1、特賣會活動，商品的排序規則演算法問題（少量用戶提現不出來），特賣會導致生產線上的專用服務器CPU耗盡到100%，電商網頁打不開——排序演算法程式優化。
2、在高并發測驗程序中發現并發情況庫存賣成負庫存——程式優化。
3、生產環境生產訂單程式很慢，優化后能在相同的時間內生成更多的訂單——程式的優化。
四：華東電腦
1、Web服務死機，網頁打不開,一開始一直找不到原因，測驗和開發累的要吐血，最后定位Weblogic中間件引數錯誤的調成了開發模式（正確的應該是調成作業模式）——中間件配置問題。
2、驗收測驗程序中，1000用戶并發情況下，回應時間超過了需求規格說明書中所要求——定位到圖片過大的問題。
3、上海市學生學分系統，用戶數上不去，登錄時間過長，首頁不是靜態的，并且首頁包含了大量的復雜的計算——程式問題
4、上海市中小學學生安全在線教育視頻，在并發學習情況下，學生的學習時間為負數——資料庫欄位型別設定不當溢位了。
5、上海市學籍檔案查詢系統查詢的回應時間達到33秒——增加索引優化查詢。
6、登錄回應時間長，在執行2000Vusers的學習視頻測驗場景中，登錄步驟的平均回應時間達到12秒。通過資料庫監控工具顯示登錄步驟存在慢的sql，此sql執行全表掃描，未建立索引。解決方案給sys_baseuser表增加索引index_3,增加索引以后，重新執行2000Vusers的學習視頻測驗場景中，登錄的平均時間小于2秒。
7、系統資源存在瓶頸
從上述的結果來看，應用服務器和全文搜索服務器CPU資源使用接近100%，CPU存在瓶頸；應用服務器的記憶體存在換頁現象，記憶體存在瓶頸。將應用服務器以及一臺全文檢索的服務器的資源配置由4C/8GB擴容至8c/16GB。服務器的內容擴充之后，相應的調整JVM虛擬記憶體的大小，最小值由1GB調整為4GB,最大值由4GB調整為12GB。
8、登錄成功率低，登錄成功率低于99%，報錯資訊為“請輸入正確的圖片驗證碼”，此問題是高并發的時候，打開的首頁的時候未生成驗證碼，這個是屬于第三方插件的bug。
9、應用服務器空指標錯誤，java.lang.NullPointerExcepton:null,此問題經過專案組排查，此問題是應用程式的判斷邏輯問題。
五：廈門銀行聯合的P2P系統
1、在測驗環境簡單用jmeter測驗了一下標的串列頁和標的詳情頁，TPS飆升到470多，而且系統平穩。
2、用同樣的測驗場景測驗了一下生產環境，網頁變成白色打不開，后臺的服務不停的報錯。并且有大量的報錯日志輸出。
總結：當時國家在整治P2P，因此沒有用戶量，所以貌似生產環境沒問題平時沒有暴露出問題，其實是有問題了，就像一個人身上有慢性病一樣，平時貌似沒問題，但是在一些極端的情況下，比如這個病人在操場上跑步10圈或者干重活，這個病就有可能會爆發、人就有可能會掛掉。
對應這個P2P系統來說（系統的極端情況就是大并發量，大用戶量的使用），系統的性能瓶頸立即就會爆發出來。
uj5u.com熱心網友回復：
怎么樣去發現這些問題 怎么樣去解決呢轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/23087.html
標籤：軟件測試