文章加密

;

2019年12月20日 星期五

mocha... BDD,TDD... scrum,cucumber

https://mochajs.org/
很常改的程式才適合做自動化測試
有寫測試並不等於不用ＱＡ
測試程式涵蓋到80%已經算很高了

http://www.ruanyifeng.com/blog/2015/12/a-mocha-tutorial-of-examples.html
测试框架 Mocha 实例教程


https://www.jianshu.com/p/9c78548caffa  chinese ver


相較jest開箱即用的特性(針對react，最初就是設計給facebook使用，其他語言當然也可以用，但是需再作配置config且相關資料沒有mocha多)，而mocha有robust documents

Chai is a BDD / TDD assertion library for node and the browser that can be delightfully paired with any javascript testing framework.

 continous integration(CI)：持續整合，是一種軟體工程流程，是將所有軟體工程師對於軟體的工作副本持續整合到共享主線的一種舉措。

 Travis CI 是一個已經建置好而且免費的持續整合系統，並且支援多種語言。只支持 Github，不支持其他代码托管服务。
detail: http://www.ruanyifeng.com/blog/2017/12/travis_ci_tutorial.html

 cucumberjs 

https://cucumber.io/docs/guides/overview/  (ING..https://cucumber.io/docs/bdd/  Read the topics below to dig deeper and learn more about BDD.)

https://www.youtube.com/watch?v=yiMGanbHdko
what is e2e testing??以使用者端角度對程式系統端做測試

gherkins:一種語法，像是When, Then, ...
Gherkin Syntax:

Feature: Title of the Scenario
Given [Preconditions or Initial Context]
When [Event or Trigger]
Then [Expected output]

Important Terms used in Gherkin
Feature
Background
Scenario
Given
When
Then
And
But
Scenario Outline Examples

Protractor: http://www.protractortest.org/#/tutorial
it is a node.js program built on top of WebDriverJS, there are browser, element, by that we can use.
it is an end to end(e2e) test framework for Angular and AngularJS applications(but it can also be used to test non-angular applications).
https://www.youtube.com/watch?v=p8ENoeZENhk Protractor Beginner Tutorial 1 |
Tool: protractor recorder. (Tired of Writing E2E Test? Try Recorders)
https://www.youtube.com/watch?v=emISX35OnKo

WebDriverJS  (Drivier 可能指驅動器, chrome driver, safari driver)
it is the Official javascript implementation of selenium.
it helps to interact with elements on the web.
Protractor extends WebDriverJS functionalities to enable automation of user actions on browser applications.



Selenium(未看)這先算拉，先學mocha
https://learngeb-ebook.readbook.tw/intro/selenium.html
https://selenium.dev/ 

tool website用來攥寫BBD邏輯: https://relishapp.com/kirkchen/cucumber-js-sample/docs/calculator

scrum （vs Kanban 經常會有臨時插件的工作比起用scrum更適合Kanban）只要公司的安排好，並沒有說用哪個才真的好，但公司本身混亂，那用哪個都不好
daily standup：每位 Scrum team 更新自己昨天完成的事項、今天預計完成的事項以及是否有遇到什麼 block 阻礙
Sprint Review ：會議由 Scrum Master 簡介這次 Sprint 所完成的 Shippable Product Increment（可交付的產品增量）和 Dev Team 展示開發成果
sprint retrospective Sprint ：結束時的閉門會議
Planning poker ：這個過程可以讓大家對於 Story 的認知和知識可以 align 到同一條線上（例如估計點數（Story Point）不一致時彼此說明和討論，增進對於 Story 和系統的了解）
User Stroy Mapping / workshop：一般不能算是標準的 Sprint Event，通常是 Product Owner 在對於開發新產品的掌握度比較低，需要開發成員一起協助定義 User Story 所召開的會議
A burn down chart is a graphical representation of work left to do versus time
Artifact 產出物
User Story 是用使用者需求角度撰寫的有商業價值的一段敘述，而 Acceptance criteria 則是更為細部的補充描述。當有數個 story 隸屬於某一個相關 feature 時通常會把它歸為同一個 Theme，若是一個大的產品或是系統需要橫跨數個 sprint 時會把這些 Story 都歸類為同一個 Epic
detail: https://blog.kdchang.cc/2019/01/04/what-is-the-experience-of-be-a-scrum-master/  scrum的解析
detail: https://progressbar.tw/posts/66  Kanban(看板)的說明

Modeling Techniques, Business Process Modeling(BPM), Data modeling

Business Process Modeling Notation(BPMN) is a standard with well-defined syntax. So many business analysts are familiar with it which makes collaboration much easier. 
BPMN consists of the following basic building blocks;
  • Flow objects: events (circles), activities (rectangles with rounded corners), and gateways (diamonds)
  • Connecting objects: mainly comprising arrows, these indicate sequence flow (filled arrows), message flow (dashed arrows), and associations
  • Swim lanes: pools (graphic container) and lanes (sub-partition of the pool)
  • Artifacts: data objects, groups, and annotations

more BPMN example: https://creately.com/diagram-community/examples/t/bpm

User Story(使用者敘述)是一段簡單的功能敘述，以客戶或使用者的觀點撰寫下有價值的功能(functionality/feature)。與其說它是規格文件(documentation)，不如說它代表(represent)客戶的一個需求而已，因為實做細節將延後至開發時才會確定。

幾個 User Stories 的範例如下：

使用者可以在網站上張貼履歷
使用者可以搜尋有哪些工作
公司可以張貼新工作
使用者可以限制誰可以看到他的履歷
初學的範本可以是：作為一個 (某個角色) 使用者，我可以做 (某個功能) 事情，如此可以有 (某個商業價值) 的好處。

As a (role of user), I want (some feature) so that (some business value).

建議能在每次開發週期(Iteration)開始的會議中(最慢也要在Iteration中期前)，把會有哪些驗收測試都提供給程式設計師，並且提供必要的測試資訊。

Stories 非常適合搭配 Iteration 的開發方式，在一個開發週期內(例如兩週)內做好分析/設計/實做/測試，然後得到 feedback。我們會將 User stories 分配到各個 Iteration 中，而一個 Iteration 可以放多少 User stories 呢? 我們會估計團隊 Velocity 開發速度(一個 Iteration 可以完成多少 story points)，然後根據 story 的複雜度跟大小估計 story points，再由客戶依照優先順序排入 Iteration 中。

 User stories 的用意就不在於寫下完整的細節，而是一個文字記錄說提醒開發者跟客戶，這裡需要再討論溝通細節。
經驗談：
採用敏捷方法的軟體開發合約該怎麼簽？ 一文所提，很多時候只能玩成價格固定、交期不變、規模求個大概。而這個規模用 User Stories 來描述，來做為專案估計時程和報價的重要參考。不過這種情況下，嗯，就沒有上述計時合約可以慢慢寫 user stories 的好處，必須一開始就把 user stories 寫比較完整。

 這裡顯然就是一個拉鋸戰啊，如果一開始合約中的 user stories 可以越大概，就可以越偏向 Agile 想要的彈性。但是實際的情況，不把規模定詳細一點又不行。我認為這種所謂的實際情況，並不是單方面客戶的問題。而是號稱敏捷的接案方常常也提不出信心跟有利證明說，這N個月到底可以給出什麼東西跟保證? 如果沒有實際認真在做 Iteration、並測量實際的開發速度，接案方又怎麼能夠讓客戶相信你的 “每個月提供三個人力” 到底是不是真的有三個人在做??? 是不是在呼弄客戶?? 既然沒個辦法可以相信，那還是回到規模固定、價格固定，交期就大家心照不宣(反正十之八九會 delay)，這樣還比較保險心安。detail: https://ihower.tw/blog/archives/2090
tool guide for 配合user story的機制管理專案: https://www.youtube.com/watch?v=MNLBsr657Co(未看)
User stories are more  efficient  than  use  cases  in  agile  processes(敏捷開發)  such  as Scrum and Use Cases models take more time to write.
detail: https://www.youtube.com/watch?v=MNLBsr657Co 大概是scrum的簡易介紹
detail: https://www.researchgate.net/publication/312293252_User_Stories_vs_UML_Use_Cases_in_Modular_Transformation(paper 未完)



UML(Unified Modeling Language)
There are 14 UML diagram types to help you model behaviors, like software solutions, application structures, system behavior and business processes.


UML includes Use Cases

  • visualize the functional requirements of a system that will translate into design choices and development priorities.
  • help identify any internal or external factors that may influence the system.
  • provide a good high level analysis from outside the system




  • rectangle(gray here) which contains use cases.
  • ovals are "use cases", which represent the functions within the system.
  • actors are the users of a system, which specify a role played by someone or some other system that interacts with the subject

detail: https://www.youtube.com/watch?v=Omp4RbHbB0s
tool webste: https://app.creately.com/diagram/create


Entity Relationship Diagrams (ERD)


  • a rectangle is an entity, which is an object or concept about which you want o store information.
  • a rectangle with a double outline is a weak entity, which must be defined by a foreign key relationship with another entity.
  • a diamond shape is a action, which show how two entities share information in a database.
  • ovals are attributes, a key attribute is the unique, distinguishing characteristic of the entity.(like ID number)
  • oval with a double outline can have more than one value(like skills)
  • oval with a dotted outline is based on another attribute(like the employee's monthly salary is based on the employee's annual salary)

  • Cardinality specifies how many instances of an entity relate to one instance of another entity, which specifies the maximum number of relationships
  • Ordinality describes the relationship as either mandatory or optional, which specifies the absolute minimum number of relationships.
In some cases, they may self linked. For example, employees can supervise other employees. 

detail:https://www.youtube.com/watch?time_continue=18&v=dUJp0Yoq5eg&feature=emb_logo


https://medium.com/@yurenju/%E8%87%AA%E5%8B%95%E8%BB%9F%E9%AB%94%E6%B8%AC%E8%A9%A6-tdd-%E8%88%87-bdd-464519672ac5  自動軟體測試、TDD 與 BDD
continue .. （ING)


在上面這個例子 labor 物件有 setAge(), setMonthlySalary() 等方法，當在設計這些方法前有測試案例時，我們又可以考慮這些方法都回傳 labor instance 本身，這樣就可以在使用時用 method chaining 的方式呼叫。同時我們也會釐清會有 WorkTime 與 Labor 兩個類別，其中各別包含了一些方法 (method)。(未看完)
  1. BDD ( Behavior-driven Development, 2003得名 )  https://zh.wikipedia.org/wiki/%E8%A1%8C%E4%B8%BA%E9%A9%B1%E5%8A%A8%E5%BC%80%E5%8F%91
  2. TDD ( Test-driven development, 1990提出)：倡導先寫測試程序，然後編碼實現其功能。目的是取得快速反饋並使用「illustrate the main line」方法來構建程序。

    測試驅動開發是戴兩頂帽子思考的開發方式：先戴上實現功能的帽子，在測試的輔助下，快速實現其功能；再戴上重構的帽子，在測試的保護下，通過去除冗餘的代碼，提高代碼質量。測試驅動著整個開發過程：首先，驅動代碼的設計和功能的實現；其後，驅動代碼的再設計和重構。

    正面評價

    • 可以有效的避免過度設計帶來的浪費。但是也有人強調在開發前需要有完整的設計再實施可以有效的避免重構帶來的浪費。
    • 可以讓開發者在開發中擁有更全面的視角。

    負面評價

    • 開發者可能只完成滿足了測試的代碼，而忽略了對實際需求的實現。有實踐者認為用結對編程的方式可以有效的避免這個問題。
    • 會放慢開發實際代碼的速度，特別對於要求開發速度的原型開發造成不利。這裡需要考慮開發速度需要包含功能和品質兩個方面，單純的代碼速度可能不能完全代表開發速度。
    • 對於GUI,資料庫和Web應用而言。構造單元測試比較困難，如果強行構造單元測試，反而給維護帶來額外的工作量。有開發者認為這個是由於設計方法，而不是開發方法造成的困難。
    • 使得開發更為關注用例和測試案例，而不是設計本身。目前，對於這個觀點有較多的爭議。
    • 測試驅動開發會導致單元測試的覆蓋度不夠，比如可能缺乏邊界測試。在實際的操作中，和非測試驅動開發一樣，當代碼完成以後還是需要補充單元測試，提高測試的覆蓋度。

張貼者： 於

沒有留言:

張貼留言

訂閱： 張貼留言 (Atom)