繼續對《炮轟“測試左移”，向軟件測試領域的“歪理邪說”宣戰》的評論進行整理，評論的第一部分請看
評論內容請見下文：
評論9：佚名
這個評論應該是在某個微信群中一位朋友有感而發，具體是誰記不得了！
? ? ? ? 看了這篇文章，感觸很深，一直從事測試行業相關工作，也經歷了測試行業的各種變遷，談談個人一點感受。不管從瀑布，到V， 到敏捷或DevOps開發模式，個人感覺核心就是市場需求推動了IT從業者技術要不停的變遷，特別是當前這種信息變化傳遞快而爆炸的時 代，客戶功能需求越來越多，加上競爭對手給你的市場時間要求越來越短，傳統的開發模式或測試模式是無法滿足當前時代的變化 了（當然一些民生類求穩的還是適用），才有了微服務，容器等新技術的出現。因需要適應用戶的需求多而快的變化，這也要求測試人員的 思維需要調整而不能僅停在功能測試層面（當然一些金融、保險、電力等行業功能測試是很香的，因子系統很多，功能測試對全局業務非常了解 ，所以一般這幾個行業職位提升的都是懂業務的）。但大部分從業者不在這個行業里（這些行業也在IT信息化），所以個人認為測試左移這件事是個好事，只是看個人和組織怎么去理解，結合自已公司本身組織和公司財力去實施，而不是否定。如從流程上左移：需求時就介入一些評審，可測性需求提出，或者工程能力上左移：如單元測試開發自測，接口由測試者完成（試想當前中國的開發環境大部分996怎么讓開發人員能認真測試，有時間測試）。另外測試者能做一些服務化的平臺供給開發測使用，測試和開發人員相互認可度也會倍增。所以個人認為測試具有代碼能力是市場環境倒逼的（這個市場不是培訓機構或認證機構），否則無法適應這個IT技術變化的時代，業務量和子系統的倍增不可能還停在功能測試，否則交付周期延期影響的是老板口袋中的銀子，或急著上線影響的是質量。
領測老賀回復：
?????? 這個評論中的觀點我是認同的，如果你通篇看了老賀的《炮轟測試左移》這篇文章，應該知道我并不是反對“測試左移”的最原始的意義，因為這個理念貫穿最早可以追溯到V模型。我反對的是曲解測試左移含義的人。
?????? 軟件測試的終極問題就是在無窮無盡的測試用例里面，抽取那些作為本輪實施的測試用例，怎么執行這些用例是效率最高的！
?????? 這兩個問題看似簡單，但是展開幾乎就是軟件測試領域探討的所有問題的全部。
評論9：裂痕
領測老賀回復：
?????? 其實作為從事軟件測試工作的人員，確實應該想一想軟件測試的基本原理是什么，不管外界如何變化，軟件測試工作如何做，都在處理著基本的問題。所有的技術，手段，無非是解決兩個問題：如何抽取出覆蓋效率最高的測試用例出來，如何高效的執行這些用例。
?????? 抽取的方法涵蓋了眾多的測試策略，如基于風險的分析，基于需求的分析，質量模型等等。
?????? 覆蓋的效率涵蓋了眾多的測試設計技術，如等價類，邊界值，結對，域測試，正交分析等等。
?????? 高效的執行涵蓋了測試用例優先級劃分，自動化測試，接口測試等等一系列問題。
?????? 所以作為測試工程師你到底在那個方向努力？解決整個測試體系中的那個問題？??????
??????
簡單說好的評論就合并到一起了
在此感謝上面朋友對本文的支持，就不一一致謝了
文章評論