軟件測試：一名合格測試的必知必會

我這里不想給大家說一些可以很容易就在網(wǎng)上找到的東西，其實測試許多的理論應(yīng)該是基于你對業(yè)務(wù)系統(tǒng)的流程、業(yè)務(wù)場景的基礎(chǔ)上進(jìn)行總結(jié)的。

這才是真正的干貨。

立足業(yè)務(wù)場景

測試任何功能點，不能單純的看需求、設(shè)計文檔就盲目的開始測試，無論是編寫測試用例、還是執(zhí)行測試用例都一定要把業(yè)務(wù)場景放在首位。即常說的 “User Story”(用戶故事)。

我們一定要模擬、分析出這條測試用例、這個測試思路是基于用戶的哪種操作，并且要把自己定位于那種計算機盲，然后站在他們的角度去使用被測系統(tǒng)。舉個例子：

本來正確的系統(tǒng)操作流程應(yīng)該是先 A 后 B 在 C，那我們就應(yīng)該模擬先 B 后 C 在 A、先 C 后 A 在 B、先 B 后 A 在 C 等等非正常流程操作下的系統(tǒng)響應(yīng)。

順便說一下，這里我設(shè)計用例的思維方式并不是憑空而來，而是排列組合思維。

注意歷史數(shù)據(jù)

這個主要只我們對正在維護(hù)的系統(tǒng)，每次有改動點，一定要考慮其流程、改動對歷史數(shù)據(jù)的影響。

中國有句老話：“打江山容易，守江山難”，映射到測試工作上也是對于新功能的測試一般都很少出問題，往往對于歷史數(shù)據(jù)，或者新功能點對老功能點的影響沒有考慮到，才會導(dǎo)致 BUG 的產(chǎn)生。

所以作為一名合格的測試，測試任何一個優(yōu)化功能，一定要拿歷史數(shù)據(jù)和新數(shù)據(jù)一同進(jìn)行測試。

這里也引申出我的第二個思維模式，對比思維。

極端情況

另外，測試任何一個功能點，我們一定要考慮到極端情況。例如：

QQ 登錄首頁，我們誰都不陌生，假設(shè)你作為一名騰訊的登錄首頁測試人員，此時叫你測試【注冊賬號】這個功能，我們常規(guī)思維肯定會考慮以下情況：

錄入的長度是否有限制；

容錯性，是否支持特殊符號；

兼容性，各個瀏覽器下是否都可以正常使用；

跨平臺性。APP、平板、電腦、乃至智能電視機是不是都支持；

安全性，是否有 SQL 注入風(fēng)險。

此時我們肯定會認(rèn)為自己設(shè)計的用例涵蓋了其主要功能，這個時候我們就漏掉了一種極端情況，即客戶上來之后不錄入任何情況，就點擊【登錄】按鈕。

遇到這種極端問題特別多的測試同仁肯定有感受，這種極端情況下暴露的 BUG 往往是最為致命、最為常見的 “空指針異常”。

綜合類似上述的場景，引出我們合格的測試人必須要有的第三個思維模式，逆向思維。

MySQL 語句的書寫能力

SQL 語句其實在 IT 行業(yè)里比較難的技術(shù)，如果你不認(rèn)同，那說明你接觸的還比較淺薄。當(dāng)然也絕不是只掌握了簡單的增、刪、改、查就可以的。那么我們應(yīng)該掌握哪些方面呢?

第一組：基本語句的書寫，包括：select from(查詢)、delete from(刪除)、where(條件子句)、in(在 … 里)、not in(不在 … 里)、from(從)、between …and、update(更新)..set、Alter(修改表、列)、insert(插入)..values;

第二組：進(jìn)階語句的書寫：group ..by(分組)、count(*) 與 count(1)、having(分組條件語句)、left ..join on(左連接)、ringht(右連接)、等值連接。

函數(shù)學(xué)習(xí)：sum 等數(shù)學(xué)函數(shù)，還有一個必須要掌握的 case…when..then…end。

除了上述的基本語句的書寫外，還應(yīng)該掌握：

視圖的建立。

存儲過程的書寫，會存儲過程，可以方便我們造數(shù)。

介于 SQL 這部分的知識在網(wǎng)上都可以找到，不在詳述。

Linux 基本命令的掌握

這里我只點出具體我們測試人員需要掌握的常用的 linux 命令，沒有提到的，工作中你 90% 用不到。有興趣可以自行深入研究下。

ll 與 ls(查看當(dāng)前文件)、cd(切換到指定文件夾)、pwd(查看當(dāng)前路徑)。

tail -f 日志名稱(查看后臺日志的時候經(jīng)常使用)。

ps -ef | grep java。查看當(dāng)前 tomcat 下服務(wù)器進(jìn)程的時候使用。

kill -9 進(jìn)程號。殺死當(dāng)前的指定進(jìn)程。

view 顯示正在運行的文件信息。

除了上述的五組命令外，其他的命令基本用不到。

測試分析與測試用例

有些時候時間緊、測試任務(wù)重，這個時候你可以不用詳細(xì)的書寫測試用例，但是一定要有完備的測試分析。分析的內(nèi)容應(yīng)該包含以下方面。

從開發(fā)角度分析

產(chǎn)品和特性是由哪個開發(fā)具體負(fù)責(zé)的 , 可以方便后續(xù)很好的跟蹤問題。

開發(fā)此產(chǎn)品和特性是否采用了新技術(shù)。

自測過得流程有哪些?

是否還有為解決的問題?

認(rèn)為的風(fēng)險點在哪里?

對測試的測試建議是什么?

從測試的角度分析

基于的業(yè)務(wù)場景是什么?

產(chǎn)品面向的人群是誰?

測試工作如何計劃?

測試人員如何分配?

測試完成的衡量目標(biāo)是什么?

采用的測試技術(shù)、工具應(yīng)該有哪些?

還有沒有需要開發(fā)、需求支持的點?

分析出測試重點、難點、分配測試資源。

上面說的分析過程也是我經(jīng)常用到的 68 原則，即充分了解產(chǎn)品，并且認(rèn)真分析之后再去實施，肯定會使得你的測試達(dá)到事半功倍的效果。

測試用例的編寫

這里我只說我寫用例的一個小習(xí)慣，各個公司的測試用例書寫規(guī)范不盡相同，但是請一定要把每一條測試用例執(zhí)行時的 “前提條件” 標(biāo)注清晰。這個 “前提條件” 可以是，這條用例執(zhí)行前的：

環(huán)境準(zhǔn)備。

業(yè)務(wù)流程前提，即做到哪一步，才滿足執(zhí)行這條用例的條件。

數(shù)據(jù)庫狀態(tài)，此時的數(shù)據(jù)庫相關(guān)表的狀態(tài)、存儲是怎樣的。

也可以是網(wǎng)絡(luò)情況，是內(nèi)網(wǎng)下還是外網(wǎng)下。

還可以是介質(zhì)，是手機、電腦、還是平板電腦。

可以是系統(tǒng)，是 windows 下的執(zhí)行測試用例還是 linux 系統(tǒng)下的測試用例。

等等。只有標(biāo)清楚 “前提條件” 后期維護(hù)方便、并且可以叫人閱讀時一目了然。

開發(fā)語言

另外測試最好掌握一門開發(fā)語言，這個語言我只推薦兩種 Java 或者 python。會了開發(fā)語言，請記住你掌握的是技能，請不要轉(zhuǎn)換自己的身份和思維，掌握開發(fā)語言就站在開發(fā)實現(xiàn)角度去思索軟件。配合 sonarqube 的靜態(tài)掃描，你會發(fā)現(xiàn)你會慢慢的深入代碼層去解決測試問題。

溝通技巧

這個不多少了，記住兩點：

與任何項目組的人大家的出發(fā)點都是為了項目，所以要相互理解，學(xué)會換位思考;

要堅持自己原則，不要輕易被開發(fā)的思維所誘導(dǎo)，而放棄自身的思維模式。

總結(jié)

測試的道路上其實充滿挑戰(zhàn)，做的好，你的價值一定遠(yuǎn)遠(yuǎn)高于開發(fā)、產(chǎn)品，你要記住你是每一個項目、每一個產(chǎn)品的質(zhì)檢員，你的能力高低直接關(guān)乎產(chǎn)品的質(zhì)量、價值乃至口碑，所以請從現(xiàn)在開始，加油充電，早早變?yōu)橐幻细竦臏y試！