這里記錄過去一周我們看到的軟件測試及周邊的行業(yè)動態(tài)，周五發(fā)布。

本周刊開源（GitHub: SoftwareTestingWeekly ），歡迎提交 issue，投稿或推薦軟件測試相關(guān)的內(nèi)容。

文章

1. 單元測試只是測試嗎？

阿里巴巴技術(shù)質(zhì)量

單元測試只是測試嗎？作者認(rèn)為單元測試除了是一種測試手段外，更是一種改善代碼設(shè)計的工具，容易寫單測的代碼往往也具有更加良好的設(shè)計。因而是任何自動化測試工具都無法取代的。

這里需要強(qiáng)調(diào)一下 "工具" 屬性，工具能放大人的智力或者體力，讓干活的時候不會這么累，比如你去種樹帶把鏟子，你肯定不會把鏟子當(dāng)成負(fù)擔(dān)的，因為他是你種樹的工具，你寫 Java，肯定不會因為 IDEA 啟動時間長，就把它當(dāng)成一種負(fù)擔(dān)，因為 IDEA 也是你寫 Java 的一個工具，很多人把寫單測當(dāng)成一種負(fù)擔(dān)，往往就是沒有意識到"單測"是一種工具，單純把他當(dāng)成一種測試。

a. 為什么單測能夠驗證代碼結(jié)構(gòu)的合理性？

b. TDD 和 BDD 會嚴(yán)重拖慢敏捷迭代速度嗎？

人們往往會覺得 TDD 和 BDD 會嚴(yán)重拖慢迭代速度，值得諷刺的是，TDD 和 BDD 恰恰是敏捷開發(fā)實踐的重要組成部分。我們學(xué)習(xí)敏捷開發(fā)的時候，不能只學(xué)習(xí)到它的 “快”，而忽略了敏捷開發(fā)所提出的質(zhì)量保證方法。敏捷開發(fā)所謂的“快”，是指在代碼質(zhì)量充分保證下的“快”，而不是做完功能就直接上線。

c. 如何做單測？

• 執(zhí)行速度：全量跑一次單測要在 30 秒到幾分鐘內(nèi)，否則就失去了單測的意義。
• 數(shù)據(jù)驅(qū)動測試：將測試用例的邏輯與數(shù)據(jù)分離，測試代碼依次讀取測試數(shù)據(jù)，校驗其是否符合預(yù)期。這樣不用寫代碼就實現(xiàn)了用多組測試數(shù)據(jù)進(jìn)行測試的目的。
• 用好Mock工具：Mockito 是用來測試少量的不得不進(jìn)行外部調(diào)用的代碼。PowerMock 是用來測試設(shè)計得不好的遺留代碼的。

d. 如何學(xué)習(xí)寫單測？

多實踐，多看看別人好的單測怎么寫，比如學(xué)習(xí)一些公認(rèn)優(yōu)秀的開源項目。

2. 測試策略模型探索

搜狗測試

測試作為軟件質(zhì)量的把控，經(jīng)常存在這樣的一個誤區(qū)：所有提測的功能都需要進(jìn)行全面的測試，否則上線后就可能存在質(zhì)量風(fēng)險。而此時，也會迎來項目經(jīng)理的質(zhì)疑，此需求開發(fā)一周，為啥測試需要兩周，測試為啥這么久？

迭代中總會遇到測試資源和時間很緊張的狀態(tài)，對我們來說，如何制定一個合理的測試策略，在有限的測試資源下既能保證產(chǎn)品質(zhì)量也能滿足產(chǎn)品迭代周期？

測試策略的理解

?”測試策略“即：”測什么“和”怎么測”。具體可以按照以下6點(diǎn)問題進(jìn)行回答，分別是：

? ① 測試的對象和范圍是什么？

? ② 測試的目標(biāo)是什么？

? ③ 測試的重點(diǎn)和難點(diǎn)是什么？

? ④ 測試的深度和廣度是什么？

? ⑤ 如何安排各種測試活動（先測試什么，再測試什么）？

? ⑥ 如何評價測試的效果？

測試策略的制定思路

3. 從零開始內(nèi)建你的安全測試流程

福祿網(wǎng)絡(luò)研發(fā)團(tuán)隊

安全問題，沒發(fā)生的時候我們可以僥幸，一旦發(fā)生生產(chǎn)安全問題，對很多公司來說可能就是黑天鵝事件了。平臺的安全，是我們測試中不可舍棄的一環(huán)，而且需要長期持續(xù)的關(guān)注。

但是很多公司沒有專職的安全測試，首先是專業(yè)性較強(qiáng)，要做好不容易，其次是不一定比第三方安全平臺更劃算，那我們該怎么做呢？

作者的思路是將安全測試融入日常的測試工作：

需求階段：用破壞性思維去評審需求

代碼層面：使用靜態(tài)代碼掃描和第三方組件掃描

數(shù)據(jù)脫敏：在存儲和傳輸時對敏感數(shù)據(jù)加密

跨目錄權(quán)限

跨站腳本

SQL注入

越權(quán)：對用戶權(quán)限進(jìn)行測試

上傳下載：對文件大小、文件類型和文件內(nèi)容進(jìn)行限制。

服務(wù)器端口：通過nmap進(jìn)行服務(wù)器的端口掃描，非必須的端口要關(guān)閉

業(yè)務(wù)需求維度：如密碼強(qiáng)度、驗證碼等

工具

1. 將文本轉(zhuǎn)換成手寫體的工具 - Text to Handwriting

開源前哨

一個印度小哥說：我討厭編寫作業(yè)，所以我做了這個工具，可以將文本轉(zhuǎn)換成看起來像手寫的一樣。

于是 https://github.com/saurabhdaware/text-to-handwriting 就誕生了。

效果如下：

在線使用 https://saurabhdaware.github.io/text-to-handwriting/

2. 可視化訪談結(jié)果 - 移情圖？

PM搞事情

在訪談中我們很容易引導(dǎo)被訪談?wù)叱约合Ｍ姆较蛉ニ伎?#xff0c;這樣往往會失去一些客觀性，我們更希望的是，對方按照自己的角度去感同身受的思考問題。同時我們也想用一種更好的方式記錄下訪談結(jié)果，將內(nèi)容更方便的傳遞給需要的人。怎么辦呢？ 移情圖（Empathy Mapping）是一個好工具。

?

移情圖，又叫共情圖，是由 XPLANE 公司的創(chuàng)始人 Scott Matthewe 發(fā)明的，是在深入了解用戶需求時會用的一種設(shè)計策略，通常在訪談后立即完成制作。

在進(jìn)行用戶研究時，它不僅可以幫助我們有效的捕獲有關(guān)用戶的行為和態(tài)度，同時還可以幫助我們將其結(jié)果可視化地傳達(dá)給同事，使整個團(tuán)隊都能站在用戶的立場，感同身受的理解需求本身，并以此為共識，對齊目標(biāo)，將整個團(tuán)結(jié)起來。

?

最常見的移情圖模型：一個正方形，被分成了幾個象限，中間一個大圓圈，代表用戶，其他每一個象限都代表了一個維度空間，分別為：所思和所感（Think & Feel）、所聽（Hear）、所看（See）、所說和所做（Say & Do）、痛點(diǎn)（Pain）和收益（Gain）。之所以把痛點(diǎn)和收益單獨(dú)放在底部，是因為這兩個維度將直接決定用戶是否選擇使用我們的產(chǎn)品，我們的產(chǎn)品是否能幫助他們解決痛點(diǎn)或從中獲取收益。

實例請看：https://mp.weixin.qq.com/s/PCjXB_YIfFMdeQJKW8WiAA

3. 一個簡單的 Mock 工具 - Moco

搜狗測試

Moco 本身支持 API 和獨(dú)立運(yùn)行兩種方式。通過使用 API，開發(fā)人員可以在 JUnit、JBehave等 測試測試框架里使用 Moco，極大程度地降低了集成點(diǎn)測試的復(fù)雜度。

Moco 可以提供以下服務(wù)：

• HTTP APIs
• Socket APIs
• REST API

開源地址：https://github.com/dreamhead/moco

方法

1. 團(tuán)隊制勝六步工作法

中生代技術(shù)

三條非常重要的原則：

原則 1：人的問題是技術(shù)團(tuán)隊最根本的問題

原則 2：團(tuán)隊中每個成員都是不錯的

原則 3：能簡單決不復(fù)雜

2. 如何寫出一份優(yōu)秀的軟件設(shè)計文檔

架構(gòu)之家

設(shè)計文檔是確保正確完成工作的最有用工具。它的主要目標(biāo)是通過強(qiáng)迫你思考設(shè)計并收集其他人的反饋來提高你的效率。作為一般經(jīng)驗法則，如果你正在處理可能需要 1 個工程師月或更長時間的項目，那么你應(yīng)該編寫設(shè)計文檔。但不要止步于此 - 許多小型項目也可以從迷你設(shè)計文檔中受益。

?

設(shè)計文檔中應(yīng)該包含哪些內(nèi)容？

• 標(biāo)題和參與者
• 概覽：高度概括且內(nèi)容能讓公司所有人都讀懂，不超過3段。
• 背景：描述項目的必要性以及跟技術(shù)戰(zhàn)略和產(chǎn)品戰(zhàn)略的關(guān)聯(lián)性。
• 目標(biāo)和非目標(biāo)：描述項目的目的和可衡量的目標(biāo)，非目標(biāo)是指不會修復(fù)哪些問題。
• 里程碑：一個可衡量的檢查點(diǎn)列表
• 當(dāng)前解決方案：描述當(dāng)前實現(xiàn)，并提供流程圖/用例圖。
• 推薦解決方案：系統(tǒng)架構(gòu)，有細(xì)節(jié)。
• 替代方案：除了上述的解決方案，你還想到了什么？購買第三方解決方案？或者使用開源的？優(yōu)缺點(diǎn)都有哪些？
• 監(jiān)控和警報
• 跨團(tuán)隊配合方面：工作量？錢？性能？安全漏洞？副作用？
• 討論：任何你不確定的公開問題或有爭議的決定等。

?

應(yīng)該怎么寫呢？

• 寫得盡可能簡單，使用簡單的話、短句、列表、例子等。
• 添加大量的表格和圖示，包括數(shù)字。
• 試著寫的有趣，提前發(fā)給他人審核。

言論

1、程序員最大的謊言是什么？

圖片

1、

這不是 Bug，是一個 Feature。

2、

技術(shù)面試 VS 實際工作

訂閱

本周刊每周五發(fā)布，會同步更新在微信公眾號。

微信搜索“畢小煩”或者掃描下面的二維碼，即可訂閱。

如果文章對你有幫助，請隨手點(diǎn)個贊吧！

(完)

總結(jié)

以上是生活随笔為你收集整理的软件测试周刊（第06期）：程序员最大的谎言是什么？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。