發表文章

目前顯示的是有「軟體工程」標籤的文章

TDD(Test Driven Development)之外,還有其他多種軟體開發和測試的方法和實踐

 除了TDD(Test Driven Development)之外,還有其他多種軟體開發和測試的方法和實踐。以下是其中一些常見的方法: 1. **BDD (Behavior Driven Development)**: BDD專注於應用程式的行為而非僅僅是測試功能。它通常使用更自然語言的語法,如Cucumber,來描述應用程式應該如何運行。 2. **DDD (Domain Driven Design)**: DDD是一種專注於業務領域複雜性的軟體開發方法。它主張使用與業務專家共同理解的共同語言進行開發。 3. **ATDD (Acceptance Test Driven Development)**: ATDD專注於事前定義和同意的驗收測試。開發人員、測試人員和業務專家會合作定義這些驗收標準。 4. **FDD (Feature Driven Development)**: FDD是一種迭代方法,強調特定功能的開發。 5. **MDD (Model Driven Development)**: 在MDD中,開發人員使用高級的圖形或文字模型來描述系統的功能,然後這些模型被轉化為實際的代碼。 6. **SBE (Specification by Example)**: SBE是BDD的一個子集,它使用具體的例子來定義應用程式的預期行為。 7. **Continuous Integration (CI)**: CI是一種實踐,要求開發人員經常(每天多次)將其代碼更改集成到主分支中。這通常伴隨著自動測試,以確保集成沒有引入新的錯誤。 8. **Continuous Delivery (CD)**: CD延續CI的思想,通過自動化部署過程,使得新的代碼更改可以快速、可靠地交付給客戶。 9. **Exploratory Testing**: 這不是一種自動化的測試策略,而是一種手工方式,允許測試人員在沒有預定義的測試腳本的情況下探索應用。 以上是各種與TDD相關或不同的開發和測試方法。每種方法都有其獨特的目的和場景,值得開發人員學習和嘗試。

[品質控制] 軟體測試流程是確保軟體品質的關鍵過程,通常包括多個階段和活動

 軟體測試流程是確保軟體品質的關鍵過程,通常包括多個階段和活動。以下是一個詳細的軟體測試流程的示例,附帶相關英文專有名詞: 1. **需求分析 (Requirement Analysis)**:    - 在測試開始前,測試團隊仔細檢查軟體需求文檔 (requirement documents),以確保對軟體功能和性能需求有清晰的理解。 2. **測試計劃 (Test Planning)**:    - 創建測試計劃文檔 (test plan document),其中包括測試範圍 (scope)、目標 (objectives)、策略 (strategy)、時程表 (schedule)、資源需求 (resource requirements) 和風險評估 (risk assessment)。 3. **測試用例設計 (Test Case Design)**:    - 基於需求文檔 (requirement documents),測試團隊設計測試用例 (test cases),描述了要測試的功能、輸入數據 (input data)、預期的輸出 (expected outputs) 和預期的結果 (expected results)。 4. **測試環境設置 (Test Environment Setup)**:    - 建立測試環境 (test environment),包括硬體 (hardware)、軟體 (software)、測試數據 (test data) 和網絡配置 (network configurations)。確保測試環境與生產環境 (production environment) 相似。 5. **執行測試 (Test Execution)**:    - 根據測試計劃 (test plan) 和測試用例 (test cases),執行測試 (execute tests)。這可能包括手動測試 (manual testing)、自動化測試 (automated testing) 或兩者的結合 (combination of both)。 6. **缺陷追蹤 (Defect Tracking)**:    - 如果測試中發現了缺...

[專案管理][敏捷] Scrum與Kanban 的差異

圖片
敏捷軟體開發(英語:Agile software development),又稱敏捷開發,是一種從1990年代開始逐漸引起廣泛關注的一些新型 軟體開發 方法,是一種應對快速變化的需求的一種軟體開發能力。它們的具體名稱、理念、過程、術語都不盡相同,相對於「非敏捷」,更強調程式設計師團隊與業務專家之間的緊密協同運作、面對面的溝通(認為比書面的文件更有效)、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法,也更注重軟體開發過程中人的作用。 敏捷軟體開發(或稱快速程式開發RAD)描述了一套 軟體開發 的價值和原則,在這些開發中,需求和解決方案皆通過自組織 跨功能團隊 達成 [1] 。敏捷軟體開發主張適度的計畫、進化開發、提前交付與持續改進,並且鼓勵快速與靈活的面對開發與變更。這些原則支援許多 軟體開發方法 的定義和持續進化。 「敏捷」(Agile或agile [2] )一詞由「敏捷軟體開發宣言」(Manifesto for agile software development)中開始推廣,「敏捷軟體開發宣言」定義了相關的價值和原則。敏捷軟體開發的 框架 不斷的發展,兩個最廣泛被使用的是 Scrum 與 Kanban 。 於是常常大家想知道你有真正用敏捷的第一個問題就是 你知道  Scrum 與 Kanban  的差異嗎? Scrum和Kanban是兩種常見的敏捷開發和專案管理方法。它們各自有自己的特點和適用情況。以下是Scrum和Kanban之間的主要差異: 1. **迭代 vs. 連續流**:    - **Scrum**: 是一種迭代和增量的方法,通常在固定長度的迭代(稱為Sprint,通常為2-4周)中完成工作。每個迭代開始時,團隊會選擇一個工作集合來完成,並在迭代結束時交付可用的產品增量。    - **Kanban**: 是一種連續流的方法,不是按迭代來組織工作,而是在工作項目準備好時就開始進行。它強調將工作視覺化並限制正在進行中的工作項目的數量,以保持流動性並降低交付時間。 2. **角色**:    - **Scrum**: 有明確定義的角色,如Scrum Master、Product Owner和Dev...

Scrum Master 證照越來越搶手 有哪些國際認可的Scrum Master認證課程和考試

Scrum Master是一項越來越受歡迎的證照,許多國際認可的機構都提供Scrum Master認證課程和考試。以下是一些推薦的地方: Scrum Alliance :Scrum Alliance是一個全球性的Scrum社群,提供Certified ScrumMaster(CSM)認證。他們提供由訓練師提供的課程,並在課程結束後提供考試。 Scrum.org :Scrum.org提供Professional Scrum Master(PSM)認證。他們的課程和考試都是在線上進行,不需要參加課堂培訓。 Project Management Institute(PMI) :PMI提供Agile Certified Practitioner(PMI-ACP)認證,其中包括Scrum Master的知識和技能。PMI的課程和考試都是在線上進行,不需要參加課堂培訓。 Agile Alliance :Agile Alliance是一個全球性的Agile社群,提供Certified Agile Leadership(CAL)認證,其中包括Scrum Master的知識和技能。他們提供由訓練師提供的課程,並在課程結束後提供考試。 Scaled Agile :Scaled Agile提供SAFe 4.0 Scrum Master認證,這是針對大型企業實施Scrum的認證。他們提供由訓練師提供的課程,並在課程結束後提供考試。 以上這些地方都是受到國際認可的Scrum Master認證機構,你可以選擇符合自己需求的課程和考試。

轉錄矽谷阿雅 談準備scrum master

【有些事你不熱愛它,還是可以收穫滿滿 - Scrum到底講什麼?】 今天考過了Scrum Master的證照!坦白說,我一直都沒有想過要去考證照,因為我是一個熱愛挑戰、有時喜歡破壞規則的人,總覺得這種規則很多的東西不適合我。但剛好 HowAgile 請我給他們的課程一些反饋、天下文化 請我做 #SCRUM敏捷實戰手冊 書評,大人學、MasterTalks 請我開產品管理、專案管理的課程,「是時候好好研究一下我沒有特別熱愛的事!」我想。 雖然面試過上百Scrum Master(敏捷導師)、陸續有十多個敏捷導師在我團隊上,也用敏捷開發十多年,但我其實沒有考過證照,也不知道竟然還有手冊! 抱著踢館的心態,開始了證照課程,發現自己用敏捷開發就像是騎腳踏車,會騎(用敏捷十年)、也在國家隊裡(臉書),但其實不知道原理,了解原理以後,感覺事情都串連起來的感覺!  幾個簡單的摘要給大家,不過切記,重點是團隊自動自發、有自主權的精神和背後的道理,倒不是這些規則喔! 【團隊】 📌 Product Owner管Product Backlog,負責讓Development Team做的事發揮最大的價值 📌 Scrum Master提倡、觀察、指導、協助團隊用Scrum  📌 Development Team決定Sprint Backlog,負責達成Sprint Goal、每個Sprint產出可以使用、上線的產品「Done Increment」,所有需要完成Backlog都在Development Team上,可能不只有工程師 【Sprint】不超過四週,矽谷軟體公司通常是兩週 【會議】 📌 Sprint Planning:決定Sprint要做什麼、Sprint Goal,一月不超過8小時。在業界通常分為「Backlog Grooming」讓團隊了解要做什麼、「Sprint Planning」決定Sprint 要做什麼。 📌 Daily Scrum:在業界常被叫做「Daily Standup每日站會」,固定15分鐘,只有Development Team參加。 Sprint Review:在業界常被叫做「Demo」,每月不超過4小時。不只是「看喔!我做好了!」還有評估調整剩下的東西。 📌 Sprint Retro:檢討會,每月不超過3小時。不只是檢討,還有選出一樣...

[品質控制] 什麼是Sanity test ? 軟體測試常見名詞整理 包含不同部門的測試人員負責範圍

圖片
什麼是Sanity test ?  從維基百科查詢定義  http://en.wikipedia.org/wiki/Sanity_testing 基本上: 是測試範圍更窄的回歸測試,它只關心​​一部分功能。 sanity test通常窄而深。 主要用來驗證在系統經過一個小的改動後其某一部分小功能沒有問題。    用來驗證系統是否滿足規格說明 對於軟體開發而言,是必要的。在開發流程中,會有針對開發項目,由RD產生的Unit Test,及自動化測試的Auto Test 來作為function 的正常性驗證。 另一方面如 白箱測試(White box testing)﹐ 又稱Glass box testing 或 Clear box testing 所謂白箱測試是軟體測試的一種﹐在了解軟體內部流程的情況下﹐針對邏輯流程設計測試實例,目的是找出極限邊緣以及內在的邏輯錯誤。 及所謂 黑箱測試(Black box testing) 是軟體測試的一種﹐基本上把軟體當作一黑箱﹐根據軟體之輸出入要求﹐由不了解其內部構造與流程之使用者進行測試﹐通常由品管部門進行此一測試。 在這些過程中產生的issue 再回推到產品開發中,如果issue可以被依照function而分類,下一階段RD會針對issue產生test build 當然在一般來說一個test build 可能針對一或一類的issue,而回歸到下一階段驗證,就會是Sanity test 協助的地方。 最後這些大大小小的test build 再過了不同的小關卡之後,又再次整合回來一個版本要來送測。這時候就會需要  回歸測試 (Regression Testing) 重新驗證一遍。 PM到RD以及測試人員,一起努力把產品的品質提升,以測試人員的組織而言還有區分: 隸屬於RD team的測試,協助軟體開發階段的測試。 軟體專案的測試,以Android 手機為例,開發app 會有對 自己功能的測試。 產品整合的測試,一樣以Android手機為例,等過了app測試這一關,就會把app 跟手機作業系統整合測試,主要測試跨app的應用,以及與作業系統的其他功能是否正常。 對應客戶回饋的測試,當收到客戶回報會需要分析驗證測試,是功能建議的...

Google Search

推薦內容橫式

本月熱門文章

什麼是 OTA ?

北京故宮首訪,一窺清宮秘史 大玉兒 & 甄嬛

水電行介紹---台北市中正區臨沂街71巷5上的友來來水電行---水電、廚具、爐具相關服務都有服務喔~~

中聯油脂後台有多硬? 台中市食安問題疑點重重

[隨筆] 也太多陰錯陽差的眼淚

新手自建監控雲最快的方式:推薦QNAP NAS 搭配QVR Pro

PTT企業綽號列表

兩億公務員排行榜:連戰 以及馬英九