案例1：
測試人員在測試系統發現在系統a和系統b之間通過匯流排通訊，偶爾會出現timeout現象。反饋開發後，開發難以重現。根據簡要分析後，認為是測試系統效能不行，拍胸脯保證在生產系統，用於系統通訊的匯流排不會出現這種問題。測試人員加強了效能測試強度，發現硬體提高後，的確效能測試場景中未能重現timeout。最終否決了缺陷。結果上到生產上後，timeout又出現了，而且對核心業務產生了一定影響（多虧有補救辦法）。最後用生產資料分析，是有些報文過長的時候，的確會產生效能問題。
分析：效能測試雖然模擬了峰值壓力，但是沒有使用真正的生產資料。測試資料中沒有包含生產系統中比較少的那種情況產生的資料。在效能測試過程中，盡可能的選擇與生產資料相近的資料或者直接使用生產系統複製下來的隨機資料可以更有效的檢出問題。
測試人員雖然測出了問題，且有一定機率重現，沒有深究這個bug。其實如果沒有太大的進度壓力，應該推動開發同事找到根因，這在核心交易系統測試的時候尤為重要。大部分有一定規模的公司會有系統分級的定義，較高階別的系統，如果存在這樣的「issue」是不滿足測試出口條件的。
小強觀點：
很多時候我們總被要求造數。。。。。其實一直以來我都不太贊同。一般我們造出來的數都是一定規則的，和真實資料分布是嚴重不符合，這樣有些潛在問題很難發現。所以像我們做效能測試一般都是用線上資料（敏感資料做脫敏處理即可或者引流到線上做）
案例2：
乙個新的功能上線後，發現存在收益漏洞，不得不暫時手工purge異常交易（還好有收益整合系統能及時檢測出）。而這個收益漏洞產生的原因是：有使用者使用了現行系統十幾年前的乙個邊緣功能（早已無人使用）打破了現有業務的完整性。初步推斷是從業的老手所為。
分析：當乙個系統複雜到一定地步（往往涉及多個子系統），不斷修改、運營多年後，肯定會出現業務完整性被打破的情況。這種例子屢見不鮮，舉兩個我有清晰印象的小例子：還記得前幾年聯通玩的幾百個**組合的營銷麼？因為控制不了複雜度，引發了好多bug，包括很多原有系統**bug，最後不得不草草收場。今年6月份我在乙個中型電商**上也親歷了這樣乙個bug，**臨時搞**活動，做組合銷售，買一本高折扣的書，搭配一本指定書籍後，折扣會加15個百分點。你選擇指定書籍後跳轉到到結算頁面後刪除被搭配的書，15個點的折扣還在。
如何解決這個問題呢？能想到的有這麼幾條方法：
1.對於歷史遺留系統：定期找ba做業務完整性檢查，梳理業務交叉可能帶來的影響。這個其實挺難做的，對於大系統，豢養幾個上下業務都精通的ba尤為重要。從外邊找點兒外專幫助做業務***測試也是好辦法，安全測試這麼玩很有效，金融業也有這樣的流動查漏隊伍。看過史泰龍和施瓦辛格這兩年拍的**《金蟬脫殼》麼？
2.大規模自動化回歸測試也是一種不錯的手段，當然回歸測試的用例得專門有一部分是「場景測試案例」（我們一般叫做長流程案例或者業務端到端案例）。
3.採取某種業務建模的方法。如uml系列，bpmn，這兩種東西都能夠從一定程度上識別業務相關性，業務交叉點的資訊，幫助測試人員設計出這種整合測試用例（有時候也叫相容測試用例，關聯測試用例）。
4.基於場景的測試分析建模方法，狀態轉換圖法，基於模型的測試（狀態轉換圖法是基於模型的測試的一種常見實現形式）都是很好的應對這種業務密集型產品滾動演進過程的好方法。
5.實時系統（飛控，機控），醫療裝置，與錢相關的，超高訪問量的，與庫存相關的這樣的系統應該把風險最大的區域做通透的測試，不然出事兒都不是小事兒。
小強觀點：
說個稍微偏離主題的事兒，我經常碰到一些幹了多年測試的朋友，他們經常會問我我現在就是功能測試，其他的會那麼一點點，薪資還是不錯的，沒必要學其他技術了啊。這個話題我在很多場合都說過，現在是什麼就業情況大家自己應該更加明白。這裡我說下另外一點，那就是當你的系統複雜性越來越高的時候（比如，電商，不要覺得簡單，乙個完整的電商大生態是極其複雜的）我們要想減少bug，那只能利用技術的多樣性來，你會更多的測試技能就會從不同角度、場景發現更多的bug，這就是你以後跳槽、加薪的價值。
兩個測試小案例
案例1 測試人員在測試系統發現在系統a和系統b之間通過匯流排通訊，偶爾會出現timeout現象。反饋開發後，開發難以重現。根據簡要分析後，認為是測試系統效能不行，拍胸脯保證在生產系統，用於系統通訊的匯流排不會出現這種問題。測試人員加強了效能測試強度，發現硬體提高後，的確效能測試場景中未能重現time...
兩個小案例測試指標 Go
go指標乙個小案例 package main import fmt func swap2 a,b int func swap a,b int func main 輸出結果 swap2 交換前位址 0xc000014090 0xc000014098 swap2 交換前數值 1 2 swap2 交換後位...
兩個小測試題
1.以1980年1月6日世界協調時0點為開始，計算北京時間2020年6月20日15 53 38是第幾周的多少秒。方法1，利用c的time.h中的標準庫函式mktime 首先計算除每週 7天 一共是多少秒 3600247,作為乙個單位常量 ntick week step1 獲取基準時間的tick數 1...