畢業5年多的我，再次回過頭來看看剛入行時所寫的文章，感概良多。尤其是文章中的第三個小故事，過了這么久依舊可以激勵到現在的我，通過自動化的手段減少團隊日常測試的時間開銷、開發提高團隊效率的工具都是目前時常思考的事情。自己也從一個職場新人變成了一個職場老人，雖然很多事情處理得游刃有余，但也存在大量需要學習的東西。保持謙遜，繼續前行，也把當時的原文分享到這里吧。
原文如下：
時間從來都是有加速度的，不知不覺已經畢業10個月了，就是說做測試這行也差不多300多天了。我自認為自己算是一個“好總結”的人，雖然離“擅總結”有一定的距離，但還是希望通過我的三則小故事，給新手朋友們幫助，哪怕只是那么微小的一丁點。
1.
那是剛入坑測試的第一個月，萌新到連自己都覺得好笑。有一天，接到一個不緊不急的任務，為某APP寫測試用例。
測試用例？我當然知道是什么，但為什么寫它和怎么才能寫好它這兩件事我當時並不知道。心想應該是個隨便搞搞就能交差的任務，也沒先去理解寫用例的意義和實際方法。只知道那如照本宣科般的幾大用例設計方法，你在入行前多少也聽過，等價類划分法、邊界值法、錯誤推斷法、因果圖法、判定表驅動法等等，這些也許是你作為應屆生搪塞考官的利器。當然，這里我不是想表達這些方法有問題，而是想說當我們真正去設計用例卻只知道這寫些方法時，會感覺手足無措。
沒錯，我當時就感覺到手足無措了，並且做了一件自認為有理的事情，去找人要了一份其他APP的用例，我竟然天真的以為那就是完成此任務最重要的東西，覺得那個APP和我要測的APP還是有幾分相像，應該可以借鑒。
一天過后，快下班時，老大路過我身旁，很好奇的問我為何看着別的APP用例寫自己要測APP的用例，我把我天真的想法告訴了她。結果可想而知，老大對我的印象突然發生了改變，沒說太多，只是簡單的一句話：“我想你需要去買本書系統的學習測試”，就離開了，眼神是失望的。而后聽到她大聲與別人議論我：“他表現很差，連需求可能都沒理解到位！”
天哪，才剛入職就收到這樣的否定，這能忍？於是當天晚上回家就琢磨如何寫用例，在各種測試論壇里搜索，發現自己真的是很傻很天真啊，可能在那天以前，都不知道一份好用例代表了什么。所以，為了新手朋友不像那時的我一樣，特意總結了下面一段滿滿的干貨送給大家。
測試用例是通過提煉測試點，經過歸納整合及科學的方法設計出來的一個給自己也給他人看的執行文檔。其有但不限於以下三種目的：讓寫測試用例的人能夠更加明確需求，對需求的把握更精准；能夠讓其他測試人員在不看需求時，快速進行測試；反思自己的測試思路，通過用例評審能夠了解用例的覆蓋情況。設計用例時，需要先通過划分系統模塊定好測試點，再次發散測試點，為每個測試點以正向逆向兩種思維方式去思考測試步驟，寫好每個測試點的具體測試步驟后，還沒完事，需要去整合精簡用例，免去冗余的步驟，並且反觀用例的編寫規范問題，包括用例的可讀性、可執行性、合理性、顆粒度。每次執行用例時，也需要測試人員理解用例，去思考用例為什么要這樣設計，是否還可以補充，並保持觀察，不僅要注意實際結果與預期結果是否一致，執行過程中遇到的其他不正常現象也要驗證。
2.
下面這個事情依舊發生在我屬於新手期的階段。
有一天，我在項目溝通群里被產品經理叫住，“xx，你過來下，我們看不懂你提的這個BUG”。帶着鄙夷的心情我快步走了過去，心想：“這群人，難道連個簡單的BUG都看不懂？”過去復現完BUG之后，我表達了我的想法，認為自己簡單兩句話的BUG描述沒有問題，然而產品卻和我說，你問問他們（指着程序員）看懂了嗎？並且直接跟我說：“描述清楚BUG是測試人員的基本能力！”聽到這句話，我的心情久久不能平靜，選擇不去理論而是默默回到座位上，站在不懂上下文的角度，再次通讀了幾遍該段BUG描述，原來這段描述確實有幾分晦澀難懂，原本以為言簡意賅的簡短文字原來是那么簡陋，簡陋到都不能把我想表達的意思完全描述清楚。
你可別笑，上述問題不僅可能發生在新手中，還有可能發生在擁有倦怠心理的老手中。以為自己能夠以簡單的一句話或者兩句話把BUG描述清楚，以為開發者都和自己一樣，完全知道BUG出現的環境及操作步驟，其實真相往往並非如此。
所以，在描述BUG時，請不管任務有多繁忙也要竭盡全力把BUG描述清楚，因為提BUG的目的就是讓這個BUG被修改，而被修改的前提是別人能夠讀懂你的描述。我會通過下面兩種方法保證我的BUG描述是清晰的：1.每次按照固定的格式去描述BUG，這個固定的格式包括BUG標題、測試環境、復現步驟、異常現象、期望結果。2.描述完BUG之后，不要慌着提交，而是站在小白的角度去通讀一遍該段描述，力求能夠完全被讀懂。
3.
入行時，大多數人都會從手工測試開始做起，這里有個響亮的綽號—“點點點工程師”，使用鼠標或者手指對着屏幕就是點。開始的新鮮感可能會由於日復一日的上述操作而消磨殆盡。不管你以后會不會是，反正我當時是這樣的。直到有一天，我看到了下面一則故事，這個故事的名字叫做《九段秘書》。
一段秘書的做法:發通知——用電子郵件或在黑板上發個會議通知，然后准備相關會議用品，並參加會議。
二段秘書的做法:抓落實——發通知之后，再打一通電話與參會的人確認，確保每個人被及時通知到。
三段秘書的做法:重檢查——發通知，落實到人后，第二天在會前30分鍾提醒與會者參會，確定有沒有變動，對臨時有急事不能參加會議的人，立即匯報給總經理，保證總經理在會前知悉缺席情況，也給總經理確定缺席的人是否必須參加會議留下時間。
四段秘書的做法:勤准備——發通知，落實到人，會前通知后，去測試可能用到的投影、電腦等工具是否工作正常，並在會議室門上貼上小條:此會議室明天幾點到幾點有會議，會場安排到哪，桌椅數量夠用嗎？音響、空調是否正常？白板、筆、紙、本是否充分？我的准備，在物品上，環境上，可以滿足開會的需求了嗎？
五段秘書的做法:細准備——發通知，落實到人，會前通知，也測試了設備，還先了解這個會議的性質是什么?議題是什么?議程怎么安排，然后給與會者發與這個議題相關的資料，供他們參考(領導通常都是很健忘的，否則就不會經常對過去一些決定了的事，或者記不清的事爭吵）。提前的目的是讓參會者有備而來，以便大家開會時提高效率。
六段秘書的做法:做記錄——發通知，落實到人，會前通知，測試了設備，也提供了相關會議資料，還在會議過程中詳細做好會議記錄(在得到允許的情況下，做一個錄音備份)。
會議開完，就完了嗎？會議上大家討論的問題，做出的承諾，領導的安排，部門之間的配合，都有許多會議的成果，需要有人記錄下來。
七段秘書的做法:發記錄——會后整理好會議記錄(錄音)給總經理，然后請示總經理會議內容沒有問題后，是否發給參加會議的人員，或者其他人員。要求他們按照執行。
八段秘書的做法:定責任——將會議上確定的各項任務，一對一地落實到相關責任人，然后經當事人確認后，形成書面備忘錄，交給總經理與當事人一人一份，以紀要為執行文件，監督，檢查執行人的過程結果和最終結果，定期跟蹤各項任務的完成情況，並及時匯報總經理。
九段秘書的做法:做流程——把上述過程做成標准化的“會議”流程，讓任何一個秘書都可以根據這個流程，復制優秀團隊，把會議服務的結果做到九段，形成不依賴於任何人的會議服務體系！
我開始深層次的思考，我現在的工作真的就沒有上升空間了嗎？我還有哪些地方沒有做好，沒有做到位？就算做到位了以后，我還能如何拓展強化我的工作？不想不要緊，細思則極恐，原來我還能做balabala...一堆事情去改善自己的工作，完善流程，減少溝通成本，幫助團隊更高效的工作。
僅以此文獻給或許迷茫但認真的你。