Search
軟體工程師在某個程度來說是個永遠都嫌學能不足的行業。 技術的更新一年比一年快，且軟體的團隊隨著應用範圍與複雜度的擴大，團隊協作(包含需求管理、版本控制、代碼審核、測試、除錯、部署、自動化)的效能已經是產品開發成功與否的重要關鍵。在這種多方要兼顧還要自修的現實下，軟體工程師更需要懂得如何運用自己的時間。
我們都知道要work smart，不要work hard; 遵循80/20法則，找出”20″高效率的事，讓20分的努力有80分的產出將會是關鍵。
https://softnshare.com/softengineer80-20rule/
BDD 使用調查 2018
(1) 團隊使用 BDD 的比率 2017: 38% --> 2018: 44%
(2) BDD 主要的好處
增加軟體的品質
協作的改善
(3) 導入 BDD 時常見的困難
協作
教育訓練
對的工具
思維的改變
主管支持
使用對的格式
(4) BDD 中落實自動化測試的部分, 由 2017 : 67% 到 2018: 80%
source:
https://cucumber.io/blog/bdd/state-of-behavior-driven-development-2018-the-resu/
如何寫出人人有共識的需求 - 範例描述需求篇
https://kojenchieh.pixnet.net/blog/post/558923197-specbyexamplecourse
報名網址:
https://forms.gle/zqgPBEyCvcEhN6ms5
ref: https://loft-sh.medium.com/11-of-the-best-open-source-kubernetes-tools-2021-edition-b4aa49487845
本文會從三個類別來介紹作者認為跟 Kubernetes 開發維運有關的好用工具，這三個領域分別是
1. Running Kubernetes Environments
a. Minikube 依然好用，可以輕鬆創建環境，作者提到創建一個 cluster 只要 23 秒即可 <--- 我是懷疑加上 VM 時間應該沒辦法，除非單純用 container mode.
b. Helm 目前依然是部署方面最普遍被使用的包裝方式，
c. K3S 目前依然是輕量級 k8s 的選擇，特別是 IoT 等輕量級環境下想要部署k8s叢集則k3s幾乎是唯一選擇。
2. Simplify Feedback Loop
這個領域主要探討的針對開發者來說，如何能夠有效的提升開發流程，如何讓開發者能夠與 k8s 的互動更為抽象與簡單，讓開發者可以不需要學會太多k8s的指令又能夠將開發的結果送到k8s叢集內進行測試。
這類型的反饋資訊也就是標題所述的 Feedback Loop
a. 由 Google 開源維護的 Skaffold 專案目前能夠簡化開發者開發k8s 應用程式的流程，將建置Image,部署到k8s等步驟都自動化，開發者只需要呼叫指令或是存擋即可讓最新的程式碼自動部署到k8s叢集內。
b. 另外一套名為 Tilt 的軟體與 Skaffold 非常類似，不同點是 Tilt 有提供友善的介面，讓使用者可以更快地去知道當前撰寫的程式碼部署到k8s後會有什麼問題，從基本的 YAML 錯誤到部署後哪邊出問題都能夠盡量的點出
c. DevSpace 也是一套針對開發流程的開源專案，跟 Tilt 一樣都有提供介面，而全部的操作都是基於 devspace 這個指令來完成。
d. Lens 這套 Kubernetes 的 GUI 軟體功能愈加強大，作者甚至稱其為 IDE 而非單純的 GUI 功能，透過各式各樣不同的 Plugin 幾乎可以完成你想要達到的任何功能。
3. IDE Dev Tools I Can’t Live Without
a. 作者推薦 VSCODE 上面的 Kubernetes Tool 這個擴功功能，作者認為如果你的 IDE 不能夠有效地分辨 Helm Template 與 K8s vanilla YAML 的差異的話，你的開發速度跟體驗將會奇差無比。
b. VSCODE 上面的 YAML Language Support 這個功能也很好，能夠針對各種 YAML 文件的操作給予自動補齊與偵錯
c. 另外一個作者推薦的 VSCODE 擴充功能是 Footsteps，作者提到對於一個數百行以上的 YAML 檔案來進行修改有時候是厭煩的，而這個擴充功能會幫你把最近修改的內容用顏色給標示強調同時也透過快捷鍵可以讓你快速地跳於最近修改的行數之間往返。
這篇文章主要就是作者分享自己使用的一些工具，有興趣的可以參考原文
Designevo連結網址：https://www.designevo.com/tw/
#logo設計#自動化#連國中生都會的logo設計
更多影片歡迎參考我的頻道分類清單
▶人人都聽得懂的Photoshophttp://yt1.piee.pw/3fuqf2
▶人人都聽得懂的illustrator http://yt1.piee.pw/3h5mrf
▶人人都聽得懂的Lightroom http://yt1.piee.pw/3cknnn
▶生活筆記 http://yt1.piee.pw/LHU98
▶開箱測試筆記 http://yt1.piee.pw/3hgxbz
▶攝影筆記http://yt1.piee.pw/3hjwcd
▶贊助陳志勤(歐付寶):https://p.opay.tw/liKqx
▶贊助完畢後請到粉專或IG私訊給我，讓我知道唷!
個人產品-書籍出版與線上課程
▶ https://www.sharecourse.net/sharecourse/course/view/courseInfo/1878
▶ https://www.books.com.tw/products/0010788281
聯絡資訊
▶eltan1216@gmail.com
臉書粉絲團
▶https://www.facebook.com/hiyachineltan
Instagram
▶https://www.instagram.com/hiyachin/
影片剪接軟體
▶Adobe premiere
Camera & Photo
▶Sony A7III / Gopro Hero 7 / Iphone1 12 / godox sl60 /godox sl200II
「孫在陽」直播-致理科大-外貿數據應用分析
中華民國貿易順差還是逆差，讓我們來看近十年進出口的比較與分析。大數據分析中的數據清理，關乎於大數據分析成敗關鍵。轉置、樞紐、文字清理、數字清理、日期清理等，遺漏值、異常值、雜訊等數據清理。讓數據不是垃圾，就必需做好數據清理。
孫在陽老師主講，[email protected]
範例、講義下載：https://goo.gl/ytzRxT
時間軸
00:00 外貿數據應用分析課程簡介
06:20 什麼是大數據
06:48 大數據分析與統計分析的差別
10:35 範例下載
29:15 Power BI是什麼?
32:41 Power BI如何下載
35:11 安裝Power BI軟體
38:32 Power BI視窗元件介紹
45:45 數據清理-樞紐資料行
01:03:53 建立貨品主分類、貨品子分類
「孫在陽」直播-長榮大學-視覺化分析-1.資料清理的視覺化分析
大數據分析-統計分析從資料取得，資料清理到視覺化分析。如何做大數據分析?
孫在陽老師主講，[email protected]
範例、講義下載：https://goo.gl/ytzRxT
時間軸
00:00:00 視覺化分析課程簡介
00:05:15 數據科學
00:12:02 解壓縮範例檔案
00:18:50 Power BI是什麼?
00:24:20 開啟Power BI軟體
00:27:50 取得資料
00:37:35 資料清理
00:46:46 日期的資料清理
00:56:46 文字的資料清理-產品類別
01:41:26 數值的資料清理-銷售額
02:16:15 認識大數據分析
02:23:44 建立分類-高獲利、一般獲利、負獲利
02:35:40 儲存檔案
自動化測試 不是用來找測試的, 是用來維護的; Bug 都是自動化程式自己的問題, 沒有業績, 只有黑箱; 為了自動而自動; 沒有規劃, 所以不同的QA/Tester ... ... <看更多>
Ans: 就目前軟體業的情況來講，普遍都是選擇python作為主要使用的語言 ... 自動化測試一定優於手動測試？ Ans: 這不是優劣問題，而是選擇哪種工具的 ... ... <看更多>
自動化測試軟體 在 Re: [請益] 軟體測試出路? - 看板Soft_Job 的推薦與評價
※ 引述《msc0953 (殺菌)》之銘言：
:: 測試，可分成手動測試和自動化測試。簡單來說，自動化測試就是把手動測試可以用程
: 式來代替。基本上，自動化測試不一定要使用 C++ 或是 Java，也可以使用一些腳本語
: 言，例如: Python, Javascript, 主要是測試有的時候要跑很久，當測試案例失敗後，
: 改程式碼可以很快地再跑一次測試。
: 推自動化測試要有老闆的支持，還要整個團隊對於產品的品質要有一定的要求。因為除了
: RD 要寫 Unit Test, Integrate Test, 還要有自動化的建置系統, 另外, RD 要寫出可被
: 測試的程式，QA 需要設計模組去驅動測試案例測試 RD 寫的程式，如果只是會看著測試
: 案例去測試 RD 寫出來的軟體，那替代性真的很高。
: 但是如果你有辦法看出測試案例上沒有的Bug，甚至可以給予 RD 沒想到解決方案，或是
: 能夠寫自動化測試處理原本要由人跑得的測試，那這就不是免洗的。這種QA非常靠經驗和
: 個人風格，也不是一般QA可以馬上達到的目標。
: 你可以朝向 QA Leader 的方向去走，主要是安排要怎樣測試軟體，測試範圍要怎樣開，那
: 些測試要做，先訓練自己組織的能力，也許再補充自己的專案知識，接PM的工作，也許會
: 比較適合。
針對自動化測試分享一些東西 ..
自動化測試的目的有幾個:
- 減少人力成本, 資源有效利用
- 找出潛在性問題
- 找出效能問題
- 執行回歸測試, 特別是維護階段, 或者客製化 (Custom Build) 的維護
- 規劃的好, 有所謂認證的價值, 公信力.
不過大部分, 做到後來都不知道在幹嘛 ....
很多案子, 我看到的問題經常是:
- 通常找不到什麼問題, 因為整個自動化程式都是問題
- 自動化測試不是用來找測試的, 是用來維護的
- Bug 都是自動化程式自己的問題, 沒有業績, 只有黑箱
- 為了自動而自動
- 沒有規劃, 所以不同的 QA/Tester 會用不同方式寫,
C/Python/Perl/Java/Shell ... 大亂鬥, 接手的很過癮 ...
- Test case 相依性太高, case 1 跑完後, case 2 就不能跑了,
因為環境爛掉了, 偏偏後面還有 2000 個要跑,
結果你已經下班了, 明天早上要給報告. 發現時已經是隔天進辦公室的時候了.
- Test script 本身沒有 quality. 所以那 2000 個不知道怎麼來的.
- 幾個 cycle/stage 之後, 自動化測試能跑就不錯了
- 通常寫 autotest 的人, 不知道啥叫做 source control ....
- 自動化測試好不容易可以跑了, 結果忘了換 build, 發現時已經是隔天早上.
- Developer 通常不想因為需要配合自動化, 而幫 QA/Tester 在 Code 加東西/開洞,
因為自己的東西都做不完了, 搞不好幫到最後變成自己的 orz ..
- Developer 有時間/願意配合了, 不過找到可以開動的 lib 又是一個大問題
(沒人維護了)
- QA/Tester 通常也沒啥 Coding skill, 也不知道怎麼跟 Developer 提出需求
而且 PM 也不知道那是做啥的, 所以 QA 就是找一些工具 (ex: selenium),
錄一錄, 然後只能跑幾次 ... 或者常常不知道為啥突然不能動了.
- GUI automation 看看就好, 不管是 Web/Window App/Mobile,
因為那些重點都在 **自動**, 但不是在 **測試流程**,
也不是在找問題, 製造的問題不少
- 大部份的 test tools 都只是用來安裝用的
- 自動化程式通常換一個環境就毀了
- 沒有完整的報表/Log, 無法缺陷分析, 更別提和 Issue tracking system,
or test management system 整合
- 自動化測試工具本身的品質堪慮 ... .(ex: RFT, 我不知道現在有沒好一點)
- 自動化測試不只是 test script 而已, 還包含自動部署, flow control/timer,
rework/rerun mechanism, schedule and job contorl, status, report interface
不過九成能動就不錯了, 剩下的都不知道是啥鬼.
- 自動化測試仰賴 PM/Develoer 推動 CI 相關流程, 同時把產品界面定義清楚.
產品界面就是 product name, version, revision, build type .... etc.
一個還好, 當同時有十幾個時候, 就不好玩了.
- 大部分自動化 '程式' 不會當作正式的 '程式', 所以九成九都是垃圾 code ...,
放到 source control 會被排擠.
- .... 不想列了 ...... orz.
我想說的是, 要做軟體自動化, 從頭就要跟 developer 同步進行,
最好是 pair programming + TDD,
developer 提供對應的 config, component key,
然後能夠有不同的 build type (debug, release) ...
- config 是未來自動部署時才有辦法設定在不同的環境;
- component key 指的是自動化工具要取得 UI object 的識別,
html 就是 id, iOS 是 label, andorid ... 我不想說了.
不然自動化程式裡就是一堆 n 度空間的 array ....
然後 developer 隨便調一個 UI, 自動化程式從此自動消失.
- PM 把 version role 定義好, CI 那邊才好串.
阿不然今天 1.3.e-3425, 明天變成 0.1.ab0c-1 ... (不要懷疑, 我真的看過)
- debug 可以讓程式或者 QA/Tester 調整一些參數, 增加測試的廣度與深度
- developer 在 code 寫的 log = input of autotest,
所以不要亂寫一些沒用的東西, 很難趴
# 自動化測試導入
兩個時間點:
- 新的案子, 剛開始. 最好是 prototype 出來的時間
- 案子已經在維護了, 不會有新的需求進來, 但是會修 bug, 最重要是這個案子賺錢.
進行中的案子不要導入自動化, 除非時間很多.
# 開發自動化工具 or Framework 的重點
市面上有很多工具, 不過很多都太過強調 '錄' 一些東西, 特別是 GUI 的,
錄 Web/錄手機/Window App ... 錄下來都不能看 ...
我覺得那只是行銷手法.
以下是我覺得 survey 或者自行開發一套自動化工具時的重點:
- Config / Data-driven
- Report
- Log 分析 / Pattern
- 圖形分析
- Timing control
- 測試流程與文件產出器
- 找物件的 libraries 有完整的封裝 (GUI automation 常出現的問題)
- 資源利用 / 分散式執行 (趕流行)
- 提供 libraries 讓 QA/Tester 也可以參與寫 script / debug
- 提供詳細的 debug 流程方法
- 和 Issue Tracking System / Test Management 整合
- lib 擴充性和文件產生工具
- 工具自己要有品質 (某大公司的 RFT .... )
# 測試角色的定義
- SDET:
- 做過 developer 最好.
- 寫自動化測試 Framework 或者研究老闆指定的工具
- 寫 plugin (像是針對 JMeter 寫 plugin)
- 維護/針對新功能提供 Libraries
- Document / Sample Code
- QA:
- 寫 test spec
- 利用自動化測試框架寫 test script / debug
- 執行寫好的 test script, 跑 overnight
- 回報/驗證爸個
- Tester: 手動執行
- 根據 QA 寫的 test spec 跑測試
- 回報/驗證爸個
# 自動化測試在專案裡的執行注意事項
- 寫 test script 本身也是一件 Coding 的工作,
一樣要 design, coding, unit test, code review, source control ..
要 Q (誰來 Q?)
- 十個 test script 可以一個人執行, 不用 config 一樣可以正常上下班;
2000 個 test script, 怎麼執行? config?
維護? report? (400M 的 log 怎麼分析啊啊阿啊啊啊啊)
這 2000 個要跑 20 次 (因為有 20 個客戶 QQ) ...
其中一個客戶要求每個 case 再跑時, 同時要跑 db access, 增加 concurrent;
另一個客戶說, 某一些 case 參數要調成 0800956956 ...
去把 2000 test script 叫出來重寫嗎? 然後要 concurrent 咧 ... 連 DB ...
對了, 20 客戶有不同的 build, 要記得換 build.
然後下一個 phase 就剩下 20 個可以跑, 因為改爛了 ...
然後你就跑了.
所以 config 的設計與彈性, 比你想像的還重要.
鮮少 autotest tool 會加強這塊的.
- test script 的內容重點在測試流程, 不是一堆找物件的 function ...
那些東西應該是 lib 要寫好, SDET 要搞定的
test script 重點是: 流程 驗證 記錄
- 寫 test script 之前, 要充分了解 requirement / spec
不過大部分 requirement / spec 都不充分 XDD
- 自動化可以和手動測試同步進行最好.
- 以前嚴重的 bug 要盡可能的放到 bucket, 有機會就自動化.
- 如果有 TDD, 那麼就把自動化測試考慮進去吧 ~~
- 如果是自行開發 test framework, 最好用 framework test self.
保證 framework 本身以及 libaries 都是 qualify.
- 文件 文件 文件
- z>b
寫的有點怨念, 大概沒回到原 po 的問題 XDD
BTW: 有興趣去看看一本書叫做 How google tests software, 作者也有一些怨念 XD
--
::: 喝咖啡 聊音樂 :::
https://rickmidi.blogspot.com/
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.231.105.25
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1399479677.A.60D.html
基本上 "自動化程式" 也是程式, 除了要有 Coding 能力,
更重要有 "分析能力", 因為往往 developer 產出的東西,
複雜度會比原本 requirement / spec 更複雜,
我的經驗, 做自動化程式最好就是 developer,
或者要 train developer 測試的基礎概念.
也不見得, DHH 說 TDD 已死 ...
see: https://www.ithome.com.tw/news/87245
TDD 表示: over my dead body
經驗告訴我, TDD 可以讓大家 (Developer/QA/PM) 思考,
產品的樣子應該是什麼, 但這不表示會抹煞工程師的創造力.
garbage code 有很多原因:
* 歷史因素: 交接很多次了, 有時候為了滿足上面的要求, "暫時" 改幾行.
這個 "暫時" 是怎麼一回事? 不要問, 很恐怖.
* 不知道 test framework life cycle: 把 code 裡的 init value
當 config 用, 所以也是 "暫時" ...
* 把 "暫時" 的 commit 了 ...
* 為了某個特別的目的, 改掉整個流程 ... (通常改的人不會知道影響有多大)
因為他自己可以跑就好, 這也是一種 "暫時" ...
有在用 framework 寫產品的常會遇到, 某些時候一些寫法就是不正確,
但是大部份的 developer 不會去改 framework 的 source code,
因為他知道應該是自己使用錯誤, 或者對於 life cycle 不了解.
不過接 auto test 很多時候會直接跑去改 framework 的 code ... 然後 ..
You know ....
... <看更多>