目前的支付寶要想發展的一個框架是：STA寫完測試分析后，交由軟件測試工程師進行用例設計和執行。所以需要測試分析師的輸出要很明確，但實際情況測試分析師和測試工程師的交互可能有盲點。本文檔描述的是STA的產出有哪些原因造成不明析，及建議。
正文：
目前在各個項目中，測試分析擔當的角色從已前的單純PRD translator轉變為更為專業的各業務系統間的分析及各種異常情況分析人員。但有些情況會導致分析師的產出不全面，從而導致測試工程師編寫用例不全面。
情況1
測試分析師的分析沒有明確到測試分析文檔中。有時想到的沒有及時反映到文檔中。過了段時間自己也就忘了。這樣會造成后繼測試工程師的用例覆蓋不全。
解決方案：
養成習慣，在寫文檔時目錄的框架先搭好，突發奇想的可以隨時記錄在文檔中。其實先把各個測試模塊框架先列出來，發散性的編寫測試分析對覆蓋不全有所幫助，同時也最大程度保證了STA的想法全部保留在文檔中。
情況2
需求變更或是其他修改，測試分析師沒有更新文檔�；蛘呤菧y試分析文檔從初版更新來最終版。造成后繼測試工程師也沒有按新的需求來編寫。到后期發現，成本比較大。
解決方案：
養成在文檔中加入修改記錄表的習慣，對于新增或更新都記錄下來，嚴格執行對于后期人員的閱讀有一定的幫助。remember文檔是寫給別人看的J
情況3
有些項目可能涉及到多個產品線，如果有一位測試分析師進行分析時會有一種情況出現：那就是對于不熟悉的業務，測試分析師通過看以前的文檔或是請教熟悉的人進行業務了解，但還是會造成對別的系統的理解錯誤或是遺漏。
解決方案：
對于一些跨產品線的項目由一個測試分測師來負責是不科學的，現在很多情況都是由一個人來分析，我個人覺得在產品KICKOFF或是PM確定資源時就應該把相關測試分析鎖定，跨線的業務由相對的測試分析師提供支持�，F實情況可能做不到幾個測分FULLTIME一個項目，考慮可以讓跨線業務的測試分析分時投入，在測試分析時，在用例REVIEW時投入既可。但很重要一點：多名測分的計劃、配合，需要主要主要測分負責，不能說這塊業務我不懂，你全幫我分析一下。
總結：
有關于測試分析師容易遺忘的想法，我個人就總結了這幾點�？赡懿皇呛苋�，希望大家看過之后能給一下建議或對上述解決方案感覺不對的地方請指正。
STA將來會越來越專業，美好的目標是讓STA DOC可以標準化，最大限度上減少因測分遺漏造成線上BUG。但產品線也決定了STA業務的局限性,所以另一個方向是多個STA在項目中完美的配合。
文章來源于領測軟件測試網 http://www.kjueaiud.com/