這里記錄過去一周我們看到的軟件測試及周邊的行業動態，周五發布。

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

文章

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

阿里巴巴技術質量

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

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

a. 為什么單測能夠驗證代碼結構的合理性？

b. TDD 和 BDD 會嚴重拖慢敏捷迭代速度嗎？

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

c. 如何做單測？

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

d. 如何學習寫單測？

多實踐，多看看別人好的單測怎么寫，比如學習一些公認優秀的開源項目。

2. 測試策略模型探索

搜狗測試

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

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

測試策略的理解

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

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

? ② 測試的目標是什么？

? ③ 測試的重點和難點是什么？

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

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

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

測試策略的制定思路

3. 從零開始內建你的安全測試流程

福祿網絡研發團隊

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

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

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

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

代碼層面：使用靜態代碼掃描和第三方組件掃描

數據脫敏：在存儲和傳輸時對敏感數據加密

跨目錄權限

跨站腳本

SQL注入

越權：對用戶權限進行測試

上傳下載：對文件大小、文件類型和文件內容進行限制。

服務器端口：通過nmap進行服務器的端口掃描，非必須的端口要關閉

業務需求維度：如密碼強度、驗證碼等

工具

1. 將文本轉換成手寫體的工具 - Text to Handwriting

開源前哨

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

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

效果如下：

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

2. 可視化訪談結果 - 移情圖？

PM搞事情

在訪談中我們很容易引導被訪談者朝著自己希望的方向去思考，這樣往往會失去一些客觀性，我們更希望的是，對方按照自己的角度去感同身受的思考問題。同時我們也想用一種更好的方式記錄下訪談結果，將內容更方便的傳遞給需要的人。怎么辦呢？ 移情圖（Empathy Mapping）是一個好工具。

?

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

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

?

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

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

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

搜狗測試

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

Moco 可以提供以下服務：

• HTTP APIs
• Socket APIs
• REST API

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

方法

1. 團隊制勝六步工作法

中生代技術

三條非常重要的原則：

原則 1：人的問題是技術團隊最根本的問題

原則 2：團隊中每個成員都是不錯的

原則 3：能簡單決不復雜

2. 如何寫出一份優秀的軟件設計文檔

架構之家

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

?

設計文檔中應該包含哪些內容？

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

?

應該怎么寫呢？

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

言論

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

圖片

1、

這不是 Bug，是一個 Feature。

2、

技術面試 VS 實際工作

訂閱

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

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

如果文章對你有幫助，請隨手點個贊吧！

(完)

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。