轉(zhuǎn)變視角，不讓質(zhì)量評(píng)測成為向白七爺要藥方

時(shí)間：2022-03-29 21:21:01 | 來源：行業(yè)動(dòng)態(tài)

時(shí)間：2022-03-29 21:21:01 來源：行業(yè)動(dòng)態(tài)

怎么既能展示企業(yè)的產(chǎn)品質(zhì)量，又能讓企業(yè)把藥方留?。?9 年參加 iTestin 的一個(gè)測試工具產(chǎn)品發(fā)布，給予作者了極大的啟示。iTestin 發(fā)布的是一個(gè)人工智能的軟件測試工具。這個(gè)工具可以根據(jù)語音或文字直接生成功能測試腳本，對(duì)軟件功能進(jìn)行測試。當(dāng)然了，人工智能雖然是作者關(guān)注的新技術(shù)點(diǎn)，但給作者啟示的不是人工智能，而是功能測試。

功能測試，誰都可以做，在產(chǎn)品展示中，少不了對(duì)產(chǎn)品功能進(jìn)行評(píng)測，可以說是測試中基礎(chǔ)的基礎(chǔ)。但是對(duì)產(chǎn)品的所有功能進(jìn)行測試，這就不是某個(gè)人或某個(gè)評(píng)測機(jī)構(gòu)可以輕易完成的事情了。如此全面的測試做完，基本上產(chǎn)品的藥方也就謄寫出來了。這件事只能是企業(yè)自己做，就算第三方有這個(gè)能力去干，生產(chǎn)企業(yè)肯定也不敢答應(yīng)。

怎么辦？換個(gè)角度看問題，講一個(gè)測試的小故事，大家一聽也許就明白了。有一個(gè)研發(fā)和一個(gè)測試是一對(duì)冤家（貌似研發(fā)和測試從來都是冤家），一天測試又和研發(fā)說，你開發(fā)的代碼有bug。研發(fā)立馬就和測試急了，說你到底會(huì)不會(huì)用，差點(diǎn)就打起來。領(lǐng)導(dǎo)來調(diào)解，說測試的說話方式不對(duì)，應(yīng)該告訴研發(fā)程序在運(yùn)行的時(shí)候CPU、內(nèi)存占用急升，數(shù)據(jù)讀取頻繁但長時(shí)間沒有響應(yīng)這些情況，研發(fā)自然就會(huì)去找他的bug去了。

從中作者明白一個(gè)道理，功能測試不能簡單看一下開發(fā)出來的功能 work 不 work。需要通過一些關(guān)鍵指標(biāo)，來對(duì)功能進(jìn)行一下全面的評(píng)估。對(duì)于測試工作而言，確實(shí)會(huì)多費(fèi)一些手腳，但是可能幫助研發(fā)更好的對(duì)問題進(jìn)行定位。

而這個(gè)道理對(duì)作者的啟發(fā)就是，在做第三方質(zhì)量評(píng)測的時(shí)候，也同樣不需要對(duì)每項(xiàng)功能進(jìn)行逐一的進(jìn)行展示。只需要找到關(guān)鍵性的應(yīng)用性能指標(biāo)，對(duì)關(guān)鍵功能進(jìn)行評(píng)估就可以了。對(duì)于重視質(zhì)量的企業(yè)而言，展示的只是測試項(xiàng)目的數(shù)量，和關(guān)鍵功能的性能指標(biāo)，觸碰不到他們的核心藥方，又可以客觀公正的對(duì)企業(yè)產(chǎn)品質(zhì)量進(jìn)行展示，何樂而不為？

再舉一個(gè)實(shí)際的例子，可能會(huì)更直觀一些。19 年有一個(gè)叫易觀的數(shù)據(jù)庫廠商推出一個(gè)大數(shù)據(jù)分析產(chǎn)品，并為此開了幾次發(fā)布會(huì)，我有幸都去參與了。每次我都會(huì)問一個(gè)同樣的問題，產(chǎn)品需要耗用的計(jì)算資源有多少，年初時(shí)給我的答案是 16 核 64G。嗯，不錯(cuò)，但是上下夠不著。用得起這個(gè)配置的企業(yè)，未必會(huì)用易觀的產(chǎn)品，想用易觀產(chǎn)品的，可能又沒有那么高的硬件配置。年底時(shí)，他們家又有發(fā)布會(huì)，處理性能不變，產(chǎn)品應(yīng)用配置降低到 8 核 16G，數(shù)據(jù)量小一些的話，一個(gè)筆記本就可以跑起來。得到這個(gè)消息后，第一個(gè)反映就是，他們家確實(shí)是在踏踏實(shí)實(shí)的做事情，第二個(gè)想到的是，看來在2020年可以找機(jī)會(huì)一起搞一下了。

2019年的公有云測試也是一樣，單獨(dú)看某項(xiàng)測試指標(biāo)，看不出什么問題，加上系統(tǒng)資源占用，好壞就全出來了。

所以說，未來評(píng)估一套系統(tǒng)的好壞，不是看寫了多少萬行的代碼，而是看有多少功能模塊，每個(gè)模塊的資源占用和響應(yīng)時(shí)間等應(yīng)用指標(biāo)，用它們來做評(píng)估，應(yīng)該更能說明問題。以前看到歐洲已經(jīng)有測試工具可以根據(jù)軟件接口對(duì)系統(tǒng)進(jìn)行功能性判定，自動(dòng)判斷有哪些功能模塊，并且根據(jù)這些功能模塊的連接路徑，對(duì)軟件架構(gòu)和安全性進(jìn)行分析。這種測試手段，個(gè)人感覺還是值得去大力推廣一下的。如果，這種測試工具能進(jìn)一步和APM產(chǎn)品相結(jié)合就更好了。應(yīng)該會(huì)令軟件企業(yè)的代碼質(zhì)量提升到一個(gè)新的階段。