今天開啟evernote時，翻到了四年前在anjuke時做的一些bug分析總結。現在回過頭看看也是有些價值所在，挑選出部分bug分享，希望能有所啟發。
一、
*** -[__nsarraym objectatindex:]: index 20 beyond bounds [0 .. 19]
*** -[__nsarraym objectatindex:]: index 40 beyond bounds [0 .. 39]
*** -[__nsarraym objectatindex:]: index 60 beyond bounds [0 .. 59]
*** -[__nsarraym objectatindex:]: index 80 beyond bounds [0 .. 79]
復現過程：
1.根據ama上的log記錄使用者行為進行多次復現操作時，沒能復現出此問題。
2.後來開發說可能是列表的問題，當時改過老功能**，然後我就從列表找起，最後復現出此crash。
操作步驟：
1.新房--地圖找房--點選小區標點（超過20套）；
2.小區**列表，載入出資料後，把網路切為無效網路；
3.再滑動列表載入更多，彈出載入失敗提示框，點選取消，再進行滑動列表；
結果：
再進行滑動列表時發生crash。
根本原因：
請求引數city id、page、pagesize，列表裡有個邏輯是總數》page x pagesize顯示出載入更多，總數<=page x pagesize不顯示載入更多。舉例：總數=25，第一頁顯示1x20=20個，此時切換成無效網路，請求第二頁時，page自動+1，page x pagesize=2x20=40,實際上載入失敗了還是20個，此時「載入更多」需要顯示在41行，但是只有21行，所以發生crash。
解決方法：
修改為總數與快取進行比對，比如總數=25，第一頁顯示1x20=20個，此時切換成無效網路，請求第二頁時，總數與快取的20個進行比對，就不會出現此crash。
總結：
1.在rc階段修改乙個bug，動了底層**導致，測試不知情。（bug一定要搞清楚產生的原因和如何修復）
2.作為qa這個bug當時驗證的時候應該在多檢查一下相關的功能，畢竟是改的老功能的地方不排除有帶出新bug的可能，雖然不一定就能發現那個問題，但是這個習慣還是要養成。
3.另外開發過程中這種對新列表和單頁的網路情況都要做判斷包括兩種網路（無網路和無效網路） 。
二、
量大crash日誌：
*** -[nsplaceholderstring initwithstring:]: nil argument
復現過程：
1.線上發現該問題
2.開發通過log定位到問題的方法和原因： 使用到了initwithstring方法，當cityid取到的城市name為空值時，傳入到該方法中應用crash
3.未想到在何種步驟下cityid會拿到空的name名稱，先在模擬器上模擬城市name為空值傳入的情況，確認該情況報的crash確實和線上一致
4.追究真機上重現步驟，開發給出各種設想（城市名稱錶壞了、使用者越獄了、定位到的城市為未開通城市從安居客拿到cityid但新房沒開通…），邏輯上均說不通
5.根據開發的設想和bug產生的原因，我們最終在真機上找到重現步驟（開始以為跟定位有關係，最終逐個排除step，確定下key step）
操作步驟：
2.假如首頁顯示的當前城市是「北京」，此時，不要做任何操作，直接再切換一次城市「北京」；
3.再進行切換新房tab；
結果：
點選新房tab時發生crash；
根本原因：
1.**中有乙個邏輯cityid等其他一些篩選條件，再切換城市時，會被清掉，另外外面還有一套邏輯是：當切換的城市與當前城市相同時，快取資料（cityid，page等）被清掉了，但是沒有重新賦cityid，導致cityid為空。
2.使用了initwithstring方法，當cityid取到的城市為空值時，傳入到該方法中應用crash（方法使用問題，此方法本身缺陷）。
解決方法：
1.當切換的城市與當前的城市相同時，不清除快取資料。
2.不使用initwithstring方法，改成蘋果系統中的方法lblcityname.text方法，如
if (self.filter.cityid) {
if ([[rtcitymanager sharedinstance] citynameforcityid:self.filter.cityid] == nil) {
// [[rtcitymanager sharedinstance] setselectedcityid:@"11"];
lblcityname.text = @"城市未開通";
else
lblcityname.text = [[rtcitymanager sharedinstance] citynameforcityid:self.filter.cityid];
另外當cityid真的為空時，又打了乙個補丁，城市顯示為「未開通」
總結：
1.此問題之前一直隱藏的問題，當時的表現是按照上面操作，提示載入失敗，當時以為是網路問題，而很容易被忽略掉。
2.如果不能復現出此問題，先根據初步判斷進行在模擬器上模擬一些情況進行是否與線上crash報的錯誤一致，從而再進一步進行問題的定位。
3.之前在戶型選擇的時候曾出現過類似問題，再有選擇項時，一定要對重複選擇項多做測試。
4.在使用initwithstring等方法的時候一定要考慮一些邊界情況，對一些空的情況做下處理。
5.之前4.3版本上存在過渠道包打錯渠道包的問題，在打渠道包時，一定要注意是qa最後測試的版本。這個以後也要引起注意。
6.在rc階段，如果沒有大的問題一定不要輕易的動底層**，如果問題嚴重一定要動底層**的話qa一定要了解清楚可能影響的模組，進行評估風險。
三、
bug描述：ios新房4.5：連續18次進入新房地圖找房時，發生crash。
復現過程：
1.daily build的最後兩天發現的此問題，然後就提了乙個偶發bug：新盤首頁鎖屏放置了大概10分鐘左右，解鎖後進入地圖找房，地圖無法顯示；
2.兩天內出現了3-4次，應該會有必現的規律，找開發確認此問題，當時的猜測是（進入地圖找房請求資料的時候卡住了，api的問題等等）；
3.接下來從地圖入手，新盤地圖找房和新房地圖找房來回切換，讓開發連線真機除錯的時候發現問題所在
操作步驟：
新房tab--地圖找房--返回（連續操作18次--iphone5）
根本原因：
在新房地圖找房返回時，沒有記憶體沒有及時**。
總結：
今後在測試中對於一些新加的功能模組，或改動較大的模組，適當的進行一些類似壓力的測試（觀察記憶體和cpu的使用情況）。
當時的一點思考總結：
1.當你在和開發人員確認問題的時候，一定要搞清楚原因，特別是bug如何產生和如何修復的。
2.專案合作時，要更加的主動（比如在發包的時候，可能郵件描述的不清楚，要主動去確認，修改了那些東西？底層的東西有沒有動，如果動了可能那些模組會受到影響等等），多溝通多確認。
3.花一點時間去挑戰偶發的crash等奇怪現象，其實bug正常來看的話都有必現的步驟。
4.多看**（在空閒的時候多去看看**，了解了解具體的邏輯是怎麼樣的）
以上內容不敢說對所有的人都有所用，但是應該能對部分人有所幫助和啟發。
對於測試人員來說一定要注意：
1.當我們去做某乙個專案時，一定要搞清楚架構、功能等是如何實現的，系統之間是如何互動的，使用到哪些技術，等等（不懂多問、多查資料，多思考，多總結）；
2.測試前準備：資料準備、流程圖、介面、資料庫、相容性等都梳理清楚，搞明白透徹，測試前分析到位；
3.用例設計：按照步驟2的分析進行用例的編寫，除了正常的流程外，多考慮其中的異常場景。說到這裡，可能會有朋友說，小需求我**有時間寫測試用例，時間那麼緊急。用例一定要寫，小需求也要把測試點寫出來，如果沒有測試點，怎麼去測？如何能更好的保證質量？
4.用例評審：保證三方（產品、研發、測試）需求的統一性，另外，盡可能的達到用例的全面性，對遺漏的用例做補充。
要做到：不懂多問、多溝通、多查資料、多思考、多總結。
量子科學家帶給我們的思考
最近中國發 第一顆量子通訊衛星 墨子號，一時之間量子力學 量子糾纏 量子通訊等概念也被大家所熟知。這時候，我突然想起我高中的物理老師，雖然僅僅只是乙個高中很普通的物理老師，但是給我們普及了很多量子力學的概念，為我開拓了視野，導致後來我也一直很關注物理學前言的新聞。最近又看到中國科學技術大學的潘建偉教...
三個問題 帶給我們的思考
今天去公尺老師辦公室，公尺老師知道我們三個是學電子專業的。首先大致說了一下我們的主要課程是plc 微控制器 模電 數電等等 下面公尺老師，a b c 代表著我們三個學生，代表沒有應答。問題一 公尺老師問 三極體的三個工作狀態？公尺老師給出了乙個答案，讓我們回答那兩個。a 高阻態吧 斷斷續續，顯示的不...
三個問題 帶給我們的思考
今天去公尺老師辦公室，公尺老師知道我們三個是學電子專業的。首先大致說了一下我們的主要課程是plc 微控制器 模電 數電等等 下面公尺老師，a b c 代表著我們三個學生，代表沒有應答。問題一 公尺老師問 三極體的三個工作狀態？公尺老師給出了乙個答案，讓我們回答那兩個。a 高阻態吧 斷斷續續，顯示的不...