Week 9 : Working with containerization Docker and Kubernetes - Po-Pon/SW-Development-Tool-And-Environments-Group1 GitHub Wiki

Task 9 : Working with containerization Docker and Kubernetes

update pipeline

Update Pipeline : Auto Deploy and Build in target server

มีการเพิ่มขั้นตอน deploy ลงไปใน Jenkins Pipeline ทั้งในส่วนของ Frontend และ Backend ซึ่งเป็นการ deploy ไปยังเครื่อง server เป้าหมาย โดยมีกระบวนการทำงานของขั้นตอนนี้ ดังนี้

Frontend

  1. ทำการกำหนด environment variable เพื่อใช้ในการเชื่อมต่อไปยังเครื่อง target server และทำการเชื่อมต่อกับเครื่อง target server
  2. ทำการ clone git ลงเครื่อง target server ที่เชื่อมต่ออยู่
  3. ทำการ build เลข version โดยใช้ build number ของ jenkins มาช่วยในการกำหนดเลข version
  4. ทำการสร้างไฟล์เพื่อใช้ในการเก็บเลข version ที่ build ขึ้นมา ก่อนจะส่งไฟล์ไปยังเครื่อง target server ที่เชื่อมต่ออยู่
  5. ทำการ build Docker Image บนเครื่อง target server ที่เชื่อมต่ออยู่
  6. ทำการ Run Container บนเครื่อง target server ที่เชื่อมต่ออยู่
  7. ทำการ clear file ที่ clone จาก git ออกจากเครื่อง target server ที่เชื่อมต่ออยู่

Backend

  1. ทำการกำหนด environment variable เพื่อใช้ในการเชื่อมต่อไปยังเครื่อง target server และทำการเชื่อมต่อกับเครื่อง target server
  2. ทำการ clone git ลงเครื่อง target server ที่เชื่อมต่ออยู่
  3. สร้าง file .env ผ่าน jenkins credential เพื่อใช้เก็บข้อมูลที่ secret
  4. ทำการ build เลข version โดยใช้ build number ของ jenkins มาช่วยในการกำหนดเลข version
  5. ทำการสร้างไฟล์เพื่อใช้ในการเก็บเลข version ที่ build ขึ้นมา ก่อนจะส่งไฟล์ไปยังเครื่อง target server ที่เชื่อมต่ออยู่
  6. ทำการ build Docker Image บนเครื่อง target server ที่เชื่อมต่ออยู่
  7. ทำการ Run Container บนเครื่อง target server ที่เชื่อมต่ออยู่
  8. ทำการ clear file ที่ clone จาก git ออกจากเครื่อง target server ที่เชื่อมต่ออยู่

deploy ไปยังเครื่อง server ที่กำหนดให้

 

หมายเหตุ: ในการเข้าใช้งานเว็บแอป Bestbeds จำเป็นที่ต้องอนุญาตการเข้าถึงตำแหน่ง เพื่อค้นหาเตียงที่ใกล้ที่สุด

สรุป top 10 :: docker security จาก OWASP

top 10 :: docker security จาก OWASP คือ เป็นคำแนะนำ 10 ข้อ เพื่อเป็นแนวทางในการวางแผนและสร้าง container ด้วย Docker อย่างปลอดภัย โดยมีทั้งหมด ดังนี้

  • D1 Secure User Mapping : Application ใน container ไม่ควร run ด้วย root
  • D2 Patch Management Strategy : ต้องมีการจัดการในเรื่องของการทำ patching ทั้งในแบบปกติและแบบฉุกเฉินเอาไว้ เพื่อป้องกันการเกิด security bug ในเครื่อง host, base image และเครื่องมือในการจัดการ container
  • D3 Network Separation and Firewalling : ต้องให้ความสำคัญกับการออกแบบระบบ network  ทั้ง network ของเครื่องมือในการจัดการ และ network ของ container ต่างๆ ว่า container ใดจะเข้าถึงได้จากภายในหรือภายนอกเท่านั้น
  • D4 Secure Defaults and Hardening : สิ่งที่ถูกติดตั้งและใช้งานอยู่ ไม่ว่าจะเป็นที่ host, container หรือเครื่องมือในการจัดการ ต้องเป็นสิ่งที่เราใช้งานจริงๆเท่านั้น
  • D5 Maintain Security Contexts : ทำการแยกการทำงานในส่วนของ frontend และ backend ออกจากกัน เพื่อเพิ่มความปลอดภัย และลดข้อผิดพลาดในการทำงานที่อาจเกิดขึ้น
  • D6 Protect Secrets : ต้องมีการจัดการในส่วนของการป้องกันข้อมูลที่เป็นความลับ เช่น การจัดการ password, การจัดการ private key เป็นต้น
  • D7 Resource Protection : ต้องมีการกำหนด limit ของการใช้งาน resource ให้กับแต่ละ container เพื่อให้แน่ใจว่าการทำงานของ container หนึ่ง จะไม่กระทบไปยังการทำงานของ container อื่นๆ
  • D8 Container Image Integrity and Origin : image ต้องได้รับการปกป้องไม่ให้ถูกแก้ไข ตั้งแต่ต้นจนถึงการ deploy
  • D9 Follow Immutable Paradigm : เพื่อช่วยเพิ่มความปลอดภัย ควรกำหนดให้ container มีการทำงานแบบ Read-only เพราะ container ส่วนใหญ่ไม่ต้องการเขียนข้อมูลหรือ mount ไปยัง file system อยู่แล้ว
  • D10 Logging : ควรจะมีการบันทึก log ของการทำงานต่างๆ จากทุก ๆ container, host และเครื่องมือในการ deploy และควรเก็บ log ไว้ในรูปแบบของ remote หรือพวก centralize log

ยกตัวอย่างการใช้งานจาก docker image/container ของ Group1

ในการใช้งาน docker image/container ของ Group1 จะมีรูปแบบของการทำงานที่ตรงกับข้อแนะนำใน top 10 :: docker security จาก OWASP อยู่ทั้งหมด ดังนี้

  1. มีการใช้งานข้อแนะนำ D4 Secure Defaults and Hardening เพราะสิ่งที่ถูกติดตั้งและใช้งานใน container เป็นสิ่งที่ได้ใช้งานจริงๆ
  2. มีการใช้งานข้อแนะนำ D5 Maintain Security Contexts เพราะมีการแยกการทำงานในส่วนของ frontend และ backend ออกจากกัน

สรุปเรื่อง 12-factor

12-factor หรือ THE TWELVE FACTORS เป็นข้อแนะนำ 12 ข้อ ที่ถูกเขียนขึ้นโดยบริษัท Heroku ซึ่งถูกเขียนขึ้นมาเป็นเวลานานแล้ว เพื่อใช้เป็นแนวทางในการพัฒนา application software เพื่อให้บริการผ่านอินเทอร์เน็ต และทำงานร่วมกับ cloud อย่างไรให้มีประสิทธิภาพ โดย 12-factor จำนวน 12 ข้อ สามารถแบ่งออกเป็นกลุ่มๆ ได้ทั้งหมด 3 กลุ่ม ดังนี้

  • build เป็นกลุ่มของแนวคิด 12-factor ที่เกี่ยวข้องกับการจัดการ Source Code จนได้เป็น Software เพื่อให้พร้อมใช้งานได้บน Environment ต่างๆ โดยมีอยู่ทั้งหมด 5 ข้อ ดังนี
  1. Codebase คือ การที่โค้ดมีแหล่งที่อยู่ที่เดียวกันใน control version เช่น git และ sub version เป็นต้น โดย 1 โปรเจคควรอยู่เพียงแค่ที่เดียวถึงแม้ว่าจะมีการทำ microservice หลาย service ก็ควรอยู่ที่ repository เดียวกัน เพื่อลดปัญหาการสื่อสารกันภายใน
  2. Dependencies เป็นการกำหนดตัว Dependency รวมไปถึง version ของ software ที่ถูกใช้งาน ให้ถูกต้อง ซึ่งทุกครั้งที่มีการแก้ไข หรือเปลี่ยนแปลงตัว source code และมีการ build ใหม่ จะต้องทำการเรียกใช้หรือติดตั้ง Dependency ใหม่ ทุกครั้งเสมอ
  3. Config เป็นการแยกตัว configuration ออกจากตัว Application และDatabase ให้มาอยู่ที่ System environment, configuration server หรือ remote configuration เพื่อที่สามารถทำการแก้ไขได้ โดยไม่กระทบกับตัว code ใน Application
  4. Backing services คือการที่ service ต่างๆ ทีถูกเรียกใช้ใน Applicationโดยเรียกใช้ผ่าน Network เช่น Database, Messaging/Queueing Systems และCaching Systems โดย service เหล่านี้ควรจะต้องถูกแยกออกจากตัว Application ซึ่งจะส่งผลให้สามารถนำ service เข้าใช้งาน หรือถอดจากการใช้งาน เพื่อทำการแก้ไขหรือเปลี่ยนใหม่ได้โดยง่าย และไม่ต้องแก้ไขในส่วนของ source code ใหม่
  5. Build, release, run คือการแยก process ในการ Build, ReleaseและRun ออกจากกัน โดยจะเริ่มในส่วนของการ Build คือการเอา source code ทั้งหมด มาแปลงเป็นตัว software ที่พร้อมใช้งาน จากนั้นมาต่อในส่วนของ Release คือการนำ software ที่ได้จากการ Build มารวมกับ config ต่าง ๆ เพื่อเตรียมนำไปใช้งานจริง และส่วนสุดท้ายคือการ Run จะเป็นการนำตัว software ไปใช้ใน Environment ต่าง ๆ ซึ่งการแยกขั้นตอนตามนี้จะส่งผลให้มีการแก้ไขที่งาย และสามารถรับรู้ได้ว่าเกิดข้อผิดพลาดตรงไหนได้ง่ายขึ้น

 

  • scaleable เป็นกลุ่มของแนวคิด 12-factor ที่เกี่ยวข้องกับการรองรับขยายความสามารถของทรัพยากร หรือ Environment เพื่อให้รองรับปริมาณของผู้ใช้งานตามจริง โดยมีอยู่ทั้งหมด 4 ข้อ ดังนี้
  1. Processes คือการกำหนดกระบวนการทำงาน ใน 12-factor ได้มีการแนะนำในส่วนของ processes ให้ทำงานแบบ stateless process เพื่อให้มีการเก็บ session ไว้ใช้ร่วมกันในรูปแบบของ server กลาง ให้สามารถใช้ร่วมกันได้จากทุกๆ cloud server เพื่อให้ยังสามารถใช้งานได้ปกติ แม้ว่าจะมีการเปลี่ยนแปลงของ cloud server ที่ใช้งาน
  2. Port binding คือ ข้อแนะนำในการกำาหนด port เพื่อเรียกใช้งาน ใน 12-factor ได้มีข้อแนะนำ ว่าให้มีการระบุชัดเจนในแต่ละ service ว่าแต่ละตัวใช้งาน port อะไร ทำให้เวลาเรียกใช้งาน เราไม่จำเป็นต้องสนใจว่าอยู่ที่ IP address ไหน รู้แค่ว่าถ้าอยู่วง Network เดียวกัน แต่ต่อด้วย Port นี้ จะต้องได้ Service นี้เสมอ
  3. Concurrency คือ การขยายทรัพยากร (scale out) โดยไม่ได้มีผลกระทบกับการทำงานทั้งระบบ หรือในส่วนอื่นๆของระบบที่ไม่มีความจำเป็นต้องขยาย ซึ่งคำแนะนำในข้อนี้ ถือเป็นส่วนหนึ่งจากคำแนะนำในส่วนของ processes นั่นคือเมื่อเรากำหนดกระบวนการทำงานให้อยู่ในรูปแบบของ stateless process แล้ว เราจึงสามารถขยายทรัพยากรเฉพาะในส่วนที่เกี่ยวข้องได้ โดยไม่ได้กระทบกับส่วนอื่นๆ
  4. Disposability คือ การที่ application ของเราควรจะเริ่มต้นการทำงานได้เร็ว (fast startup) โดยมีผลลัพธ์ในตอนจบของการทำงานที่สมบูรณ์ (graceful shutdown) เพื่อป้องกันข้อผิดพลาดที่อาจจะเกิดขึ้นจากการเปิดหรือปิดของ application ที่ไม่สมบูรณ์

 

  • maintainable เป็นกลุ่มของแนวคิด 12-factor ที่เกี่ยวข้องกับการดูและรักษา software และ environment ต่างๆ โดยมีอยู่ทั้งหมด 3 ข้อ ดังนี้
  1. Dev/prod parity เป็นการทำ Environment ให้มีความแตกต่างกันน้อยที่สุด เช่น หากตัว production มี load balance ที่ตัว dev ก็ควรจะมี load balance ด้วยเช่นกัน รวมถึงการทำ Deployment จาก Environment หนึ่ง ไปยังอีก Environment หนึ่ง จะต้องทำได้อย่างรวดเร็วเช่นกัน
  2. Logs คือการเก็บข้อมูลของเหตุการณ์ต่างๆทั้งหมดที่เกิดขึ้นใน process เพื่อนำมาเก็บเอาไว้ โดยใน 12-factor ได้มีการแนะนำให้ทุกๆเหตุการณ์ มีการปล่อย log ออกมาในรูปแบบของ stdout (standard output) และค่อยทำการนำซอฟแวร์ที่ใช้ในการเก็บ log มา capture ตัว log ที่ปล่อยออกมาในรูปแบบของ stdout อีกทีหนึ่ง
  3. Admin processes แยกชุดคำสั่งที่ใช้ทำงานในระดับ Server Admin อย่างเช่น Database Migrations ,Shell และCommandบางอย่าง ออกจากตัว Application แต่ต้องใช้คำสั่งข้างต้นให้อยู่ในชุดโค้ดเดียวกับ Application ซึ่งเมื่อใช้เสร็จแล้วจะต้องทำลายทิ้งให้หมด รวมถึงปิดการเข้าถึงภายในระบบของ server เพื่อป้องกันการกระทำที่ไม่ผ่านชุดคำสั่งที่ถูกกำหนดไว้ให้ ซึ่งสามารถลดปัญหาในการเปลี่ยนแปลงที่ไม่เหมือนกันในแต่ละ environment ได้

สรุปเรื่อง 12-factor with docker

ในส่วนของ 12-factor with docker จะเป็นการประยุกต์ใช้ข้อแนะนำ 12-factor เข้ากับการใช้งานของตัว docker โดยจะยังมีข้อแนะนำอยู่ทั้งหมด 12 ข้อ แต่จะมีรายละเอียดโดยคร่าวๆที่เพิ่มเติมเข้ามา ดังนี้

  1. codebase ใน 12-factor with docker ได้มีการแนะนำให้มีการใช้ git versioning system เพื่อควบคุมตัว source code โดยในคำแนะนำนี้ การ update ใดๆ ก็ตามที่เราได้ทำไป จะยังไม่มีการ link เข้ากับตัว docker ของเรา แต่เราจะได้รู้ในข้อแนะนำถัดๆไป
  2. dependencies ใน 12-factor with docker ได้แนะนำให้มีการระบุ dependencies ที่ต้องทำการติดตั้ง รวมเอาไว้ใน file package.json ที่เดียว และทำการติดตั้งตัว dependencies เพิ่มเติม ที่มีชื่อว่า sails-mongo โดยใช้คำสั่ง npm install sails-mongo --save
  3. configuration ใน 12-factor with docker ได้แนะนำให้ใน file config/connections.js มีการระบุตัว mongo connection และให้ใช้ MONGO_URL environment variable เพื่อใช้ในการส่งผ่านตัว mongo connection string จากนั้นใน file config/model.js เราจะทำการตรวจสอบให้แน่ใจว่า mongo connection ที่เราได้ระบุไปก่อนหน้านี้ มีการใช้งานจริง
  4. external services ใน 12-factor with docker นั้น จะมี external service เพียงตัวเดียวที่ถูกใช้งาน นั่นก็คือ MongoDB database โดยที่ถ้าเกิดข้อผิดพลาดขึ้นกับตัว MongoDB instance ของเรา เราก็สามารถเปลี่ยนไปใช้ instance ใหม่ได้ง่าย โดยการเปลี่ยนตัว MONGO_URL environment variable และทำการ restart application
  5. build / release / run ใน 12-factor with docker นั้น จะใช้ Docker ในกระบวนการ development ทั้งหมด เริ่มจากการเพิ่ม Dockerfile เพื่อช่วยระบุขั้นตอนใน build phase หลังจากทำการ build เสร็จ จะได้ตัว image ออกมา ซึ่งจะนำมาใช้ในการ release ออกไปเป็น docker-compose file และทำการ run แบบ manual ผ่านตัว compose CLI
  6. processes ใน 12-factor with docker นั้น ได้ระบุว่าใน config/sessions.js จะต้องมีการปรับแต่งตัว adapter เพื่อใช้ในการเก็บ session ไว้ใน distributed Redis kv store
  7. port binding ใน 12-factor with docker นั้น ได้มีการระบุในส่วนของ port ไว้ให้แล้ว โดยจะถูกระบุไว้ใน docker-compose file
  8. concurrency ใน 12-factor with docker นั้น ระบุว่าในกระบวนการ process จะมีอยู่เพียงแบบเดียวคือ http server ซึ่งสามารถทำงานแบบ multiplexing โดยใช้ Node.js http server ทำให้ง่ายในการทำ scale out
  9. disposability ใน 12-factor with docker นั้น ได้แนะนำให้มีการใช้งาน queueing system เช่น Apache, Kafka เป็นต้น เพื่อช่วยเพิ่มประสิทธิภาพในการ restart application
  10. dev / prod parity ใน 12-factor with docker นั้น ระบุว่าตัว docker-compose file นั้น สามารถ run ได้ทั้งบน local machine หรือบน Docker Host ทำให้ความแตกต่างในการ run บน environment ที่ต่างกันมีน้อย
  11. logs ใน 12-factor with docker นั้น ได้แนะนำว่าถ้าต้องการเก็บ log ในแบบ centralize สามารถเพิ่ม log service ลงใน docker-compose file ได้เลย
  12. admin processes ใน 12-factor with docker นั้น ได้แนะนำว่าควรมีการระบุตัว admin service ลงใน docker-compose file และ service ตัวนั้น ควรจะถูก run ในเวลาเดียวกันกับ application เพอื่ใช้ในการ run admin tasks

 

ยกตัวอย่างการใช้งาน 12-factor with docker ของ Group1

ในการใช้งาน docker image/container ของ Group1 จะมีรูปแบบของการทำงานที่ตรงกับข้อแนะนำใน 12-factor with docker อยู่ทั้งหมด ดังนี้

  1. มีการใช้งานข้อแนะนำในส่วนของ dependencies นั่นก็คือการระบุ dependencies ที่ต้องทำการติดตั้ง รวมเอาไว้ใน file package.json ที่เดียว ตามที่ได้ระบุไว้ใน 12-factor with docker
  2. มีการใช้ข้อแนะนำในส่วนของ build / release / run นั่นก็คือการแยกการทำงานของทั้ง 3 ส่วนออกจากกัน และมีการใช้ Dockerfile ในการกำหนดขั้นตอนภายใน build phase

 

feature ที่ปรับปรุง และเพิ่มเข้ามา

ทำการออกแบบเว็บแอปพลิเคชันใหม่ Bestbeds 2.0 ซึ่งมีฟีเจอร์ ได้แก่

 

1.ปรับปรุงใหม่ ฟีเจอร์: แสดงสถิติข้อมูล Covid-19

User Flow

User Flow ของ feature แสดงสถิติข้อมูล Covid - 19 ประกอบด้วย 2 ขั้นตอน ดังนี้

  1. user ทำการเข้าสู่หน้า Home ของ website
  2. user ทำการกดเลือกข้อมูลสถิติของ Covid - 19 ที่ต้องการให้แสดง
  3. website แสดงสถิติของ Covis - 19 ตามที่ user เลือก

 

UI Flow

UI Flow ของ feature แสดงสถิติข้อมูล Covid - 19 ประกอบด้วย 1 หน้าหลัก ได้แก่ หน้า Home ซึ่งเป็นหน้าแรกของ website ที่จะแสดงสถิติต่างๆของ Covid - 19 รวมอยู่ในหน้านี้นั่นเอง

 

Acceptance Test

case1: การที่ระบบจะสามารถแสดงผลข้อมูลเกี่ยวกับการติดเชื้อโควิดได้นั้นจะต้อง ทำการ Get ข้อมูลจากเว็บปลายทางสำเร็จ
case2: การที่ระบบไม่สามาถแสดงผลข้อมูลเกี่ยวกับการติดเชื้อโควิดได้นั้นสามารถเกิดจากระบบไม่สามารถ Get ข้อมูล จากเว็บปลายทางได้

Technical

ในด้าน technical ของ feature แสดงสถิติข้อมูล Covid-19 สามารถอธิบายและแบ่งออกเป็นหัวข้อย่อยๆได้ ดังนี้

Frontend

ในส่วน Frontend เราจะมีการกำหนดขั้นตอนการพัฒนาอยู่ทั้งหมด 5 ขั้นตอน พร้อมกำหนดรายละเอียดคร่าวๆ ลงในแต่ละขั้นตอน ดังนี้

  1. ออกแบบ UI เป็นการออกแบบหน้าตา UI ของการทำงานต่างๆ ที่เกี่ยวข้องกับ Feature การค้นหาและจองเตียง โดยแบ่งออกได้เป็น 1 หน้าจอหลัก 3 หน้าจอย่อยได้แก่ ได้แก่
    1. หน้า Home (หน้าหลัก)
    2. หน้าแสดงกราฟผู้ติดเชื้อประจำวัน (หน้าย่อยในหน้า Home)
    3. หน้าแสดงรวมทุกกราฟสถิติ Covid - 19 (หน้าย่อยในหน้า Home)
    4. หน้าแสดงสถิติรวมผู้ตืดเชื้อในแต่ละจังหวัด (หน้าย่อยในหน้า Home)
  2. ออกแบบ Business Logic เป็นการออกแบบตัว Frontend ให้ตอบสนองกับตัว Business ที่ต้องการจาก feature ตัวนี้
  3. ทำการเขียนโค้ดเพื่อพัฒนาหน้า UI ต่างๆขึ้นมา ตามที่ได้ออกแบบไว้ใน 2 ขั้นตอนที่กล่าวไปข้างต้น โดยในส่วนนี้จะใช้ Vue.JS ในการพัฒนาเป็นหลัก โดยที่อาจจะมีการใช้เครื่องมืออื่นๆในการพัฒนาร่วมด้วย ยกตัวอย่างเช่น
    • HTML
    • CSS
    • Bootstrap
  4. ทำการ Test หรือก็คือ ทำการทดสอบตัว Frontend ที่พัฒนาจนเสร็จสิ้นแล้วในแต่ละส่วน ว่าสามารถทำงานได้สมบูรณ์ตามที่คาดหวังไว้หรือไม่ ไปจนถึงการทดสอบส่วนของ Frontend ที่เกี่ยวข้องทั้งหมด เพื่อทำการยืนยันความสมบูรณ์ในขั้นสุดท้าย
  5. ทำการ Deploy เป็นขั้นตอนสุดท้ายในขั้นตอนการพัฒนาที่ได้กำหนดไว้ โดยเมื่อทำการทดสอบตัว Frontend จนสมบูรณ์แล้ว จะทำการ Deploy Frontend ในส่วนนั้นๆ โดยใช้ Docker

Backend

API ของทาง Department of Disease Control of Thailand (กรมควบคุมโรค) โดยเราจะใช้ API ที่แตกต่างกันตามสถิติ ดังนี้ 

List of Task

Frontend

Task

เวลาที่กำหนด

ผู้รับผิดชอบ

1.ออกแบบหน้าตา UI ในส่วนของการแสดงสถิติข้อมูล Covid - 19

3 ชั่วโมง

นายอคิราภ์ สีแสนยง

2.ทำการพัฒนาหน้า Home โดยใช้ Vue.JS ในการพัฒนา

5 ชั่วโมง

นายอคิราภ์ สีแสนยง

3.ทำการพัฒนาส่วนแสดงกราฟผู้ติดเชื้อประจำวัน โดยใช้ Vue.JS ในการพัฒนา

3 ชั่วโมง

นายวิชยุตม์ ทวิชัยยุทธ

4.ทำการพัฒนาส่วนแสดงรวมทุกกราฟสถิติของ Covid - 19 โดยใช้ Vue.JS ในการพัฒนา

3 ชั่วโมง

นายวิชยุตม์ ทวิชัยยุทธ

5.ทำการพัฒนาส่วนแสดงสถิติรวมผู้ติดเชื้อในแต่ละจังหวัด โดยใช้ Vue.JS ในการพัฒนา

3 ชั่วโมง

นายพิชญะ สิงห์มีศรี

 

เงื่อนไขในการผ่าน Acceptance Test

Frontend

Task 1 : ออกแบบหน้าตา UI ในส่วนของการแสดงสถิติข้อมูล Covid - 19

  • ต้องมีหน้า UI ของ 1 หน้าหลัก ได้แก่ หน้า Home และ 3 ส่วนย่อย ได้แก่ ส่วนแสดงกราฟผู้ติดเชื้อประจำวัน, ส่วนแสดงรวมทุกกราฟสถิติของ Covid - 19 และส่วนแสดงสถิติรวมผู้ติดเชื้อในแต่ละจังหวัด
  • ในหน้า Home จะต้องมีในส่วนของปุ่มที่ใช้ในการกดเลือกดูสถิติของ Covid - 19 ซึ่งจะมี 3 โหมดในการดู เท่ากับจำนวนส่วนย่อยที่เราใช้ในการแสดงสถิติของ Covid - 19
  • ในส่วนแสดงรวมกราฟสถิติของ Covid - 19 จะต้องมีการแสดงกราฟสถิติทั้งหมด 3 สถิติ ได้แก่่ กราฟสถิติรวมจำนวนผู้ติดเชื้อ, กราฟสถิติรวมจำนวนผู้ป่วยที่ได้รับการรักษาแล้ว และกราฟสถิติรวมจำนวนผู้เสียชีวิตจาก Covid - 19
  • ในส่วนแสดงสถิติรวมผู้ติดเชื้อในแต่ละจังหวัด จะต้องมีช่องค้นหาสำหรับพิมพ์ชื่อจังหวัด เพื่อใช้หาจังหวัดที่ user ต้องการรู้สถิติโดยเฉพาะ

Task 2 : ทำการพัฒนาหน้า Home โดยใช้ Vue.JS ในการพัฒนา

  • หน้า Home ที่ได้ทำการพัฒนาแล้วนั้น ต้องมีรูปแบบ UI ตามที่ได้ออกแบบไว้ครบถ้วน
  • สามารถเลือกดูสถิติต่างๆเกี่ยวกับ Covid - 19 ได้ บนหน้า Home


Task 3 : ทำการพัฒนาส่วนแสดงกราฟผู้ติดเชื้อประจำวัน โดยใช้ Vue.JS ในการพัฒนา

  • ส่วนแสดงกราฟผู้ติดเชื้อประจำวันที่ได้ทำการพัฒนาแล้วนั้น ต้องมีรูปแบบ UI ตามที่ได้ออกแบบไว้ครบถ้วน
  • กราฟผู้ติดเชื้อ Covid - 19 ประจำวันที่แสดงผลออกมานั้น จะต้องเป็นข้อมูลที่อัปเดตในวันที่ปัจจุบัน (Up - to date)

Task 4 : ทำการพัฒนาส่วนแสดงรวมทุกกราฟสถิติของ Covid - 19 โดยใช้ Vue.JS ในการพัฒนา

  • ส่วนแสดงรวมทุกกราฟสถิติของ Covid - 19 ที่ได้ทำการพัฒนาแล้วนั้น ต้องมีรูปแบบ UI ตามที่ได้ออกแบบไว้ครบถ้วน
  • ทุกกราฟสถิติรวมที่แสดงออกมา จะต้องเป็นข้อมูลที่อัปเดตในวันที่ปัจจุบัน (Up - to - date)
  • จะต้องมีการแสดงกราฟสถิติทั้งหมด 3 สถิติ ได้แก่ กราฟสถิติรวมจำนวนผู้ติดเชื้อ, กราฟสถิติรวมจำนวนผู้ป่วยที่ได้รับการรักษาแล้ว และกราฟสถิติรวมจำนวนผู้เสียชีวิตจาก Covid - 19

 

Task 5 : ทำการพัฒนาส่วนแสดงสถิติรวมผู้ติดเชื้อในแต่ละจังหวัด โดยใช้ Vue.JS ในการพัฒนา

  • ส่วนหน้าแสดงสถิติรวมผู้ติดเชื้อในแต่ละจังหวัด ที่ได้ทำการพัฒนาแล้วนั้น ต้องมีรูปแบบ UI ตามที่ได้ออกแบบไว้ครบถ้วน
  • ในช่องค้นหาจังหวัด เมื่อ user ทำการกรอกตัวอักษรลงไปในช่องค้นหา จะต้องปรากฏเฉพาะจังหวัดที่มีตัวอักษรดังกล่าวอยู่ภายในชื่อจังหวัดเท่านั้น

Test Stratergies

ในการทดสอบระบบเพิ่ม - ลดจำนวนเตียงที่ให้บริการ จะมีการแบ่งรูปแบบของการทดสอบออกเป็น 3 ส่วน ดังนี้

Unit test

  • Frontend
    ไม่มีการทำงานที่เป็นฟังก์ชันย่อยๆในส่วนนี้ จึงไม่มีในส่วนของ unit testing
  • Backend
    การทำงานในส่วนนี้เป็นการใช้ service API จากภายนอก จึงทำให้ไม่มีการ test ในส่วนของ Backend

Component test

  • Frontend

เป็นการทดสอบว่าในแต่ละหน้าที่เกี่ยวข้องกับ feature แสดงสถิติข้อมูล Covid - 19 นั้น มีส่วนประกอบ หรือ component ที่ควรจะอยู่ในหน้านั้น ๆ ครบถ้วนหรือไม่ โดยจะเน้นเฉพาะส่วนของ Frontend ที่เกี่ยวข้อง การทดสอบในส่วน Component test จะสามารถแบ่งออกได้เป็น 4 ส่วน ดังนี้

  1. การทำ Component test ในส่วนของหน้าแสดงกราฟผู้ติดเชื้อประจำวัน เป็นการทดสอบเพื่อดูว่าหน้าแสดงกราฟผู้ติดเชื้อประจำวัน มีส่วนประกอบต่างๆครบถ้วนหรือไม่ โดยในหน้าแสดงกราฟผู้ติดเชื้อประจำวัน จะมีส่วนประกอบที่ต้องมีอยู่เพียง 1 ส่วนประกอบ ได้แก่ กราฟแสดงสถิติผู้ติดเชื้อประจำวัน
  2. การทำ Component test ในส่วนของหน้าแสดงรวมทุกกราฟสถิติของ Covid - 19 เป็นการทดสอบเพื่อดูว่าหน้าแสดงรวมทุกกราฟสถิติของ Covid - 19 มีส่วนประกอบต่างๆครบถ้วนหรือไม่ โดยในหน้าแสดงรวมทุกกราฟสถิติของ Covid - 19 จะมีส่วนประกอบที่ต้องมีอยู่ทั้งหมด 3 ส่วนประกอบ ได้แก่
    • กราฟสถิติรวมจำนวนผู้ติดเชื้อ
    • กราฟสถิติรวมจำนวนผู้ป่วยที่ได้รับการรักษาแล้ว
    • กราฟสถิติรวมจำนวนผู้เสียชีวิตจาก Covid - 19

 

  • Backend 

การทำงานในส่วนนี้เป็นการใช้ service API จากภายนอก จึงทำให้ไม่มีการ test ในส่วนของ Backend


E2E test

  • Frontendเป็นการทดสอบตัว feature แสดงสถิติข้อมูล Covid - 19 ซึ่งจะทดสอบที่หน้า main ที่มีหน้าย่อยทั้งหมด 4 หน้าย่อย โดยมีจุดประสงค์เพื่อทดลองว่า feature นี้ สามารถใช้งานได้จริง โดยเริ่มจาก
    1. กดเข้าไปที่หน้าย่อย แท็บ ประจำวัน ในหน้า main จะต้องมีการแสดงข้อมูล ติดเชื้อรายใหม่, ตาย, รักษาหาย และกราฟแสดงผู้ติดเชื้อรายวัน
    2. กดเข้าไปที่หน้าย่อย แท็บ ทั้งหมด ในหน้า main จะต้องมีการแสดงข้อมูล ติดเชื้อสะสม, ตายสะสม และรักษาหายสะสม
    3. กดเข้าไปที่หน้าย่อย แท็บ ทั้งหมด ในหน้า main จะต้องมีการแสดงข้อมูล กราฟสถิติผู้ติดเชื้อเพิ่มในแต่ละวัน, กราฟสถิติการรักษาผู้ป่วยหายเพิ่มในแต่ละวัน และกราฟสถิติผู้เสียชีวิตสะสม
    4. กดเข้าไปที่หน้าย่อย แท็บ ทั้งหมด ในหน้า main จะต้องมีการแสดงข้อมูล รายงานสถานการณ์ Covid-19 ประจำวันของแต่ละจังหวัด และใส่ชื่อจังหวัดเพื่อดูข้อมูลในจังหวัดที่ต้องการ
  • Backendการทำงานในส่วนนี้เป็นการใช้ service API จากภายนอก จึงทำให้ไม่มีการ test ในส่วนของ Backend

 

Test Result

Unit test

  • Frontendไม่มีการทำงานที่เป็นฟังก์ชันย่อยๆในส่วนนี้ จึงไม่มีในส่วนของ unit testing
  • Backendการทำงานในส่วนนี้เป็นการใช้ service API จากภายนอก จึงทำให้ไม่มีการ test ในส่วนของ Backend

Component test

  • Frontendผลการทดสอบ frontend component test จะแบ่งออกเป็น 3 ส่วน เหมือนที่ได้ระบุไว้ใน test stratergies ดังนี้
    1. การทำ Component test ในส่วนของหน้าแสดงกราฟผู้ติดเชื้อประจำวัน
      • กราฟแสดงสถิติผู้ติดเชื้อประจำวัน
        ผลการทดสอบ : success (มี element นี้อยู่จริง)
    2. การทำ Component test ในส่วนของหน้าแสดงรวมทุกกราฟสถิติของ Covid - 19
      • กราฟสถิติรวมจำนวนผู้ติดเชื้อ
        ผลการทดสอบ : success (มี element นี้อยู่จริง)
      • กราฟสถิติรวมจำนวนผู้ป่วยที่ได้รับการรักษาแล้ว
        ผลการทดสอบ : success (มี element นี้อยู่จริง)
      • กราฟสถิติรวมจำนวนผู้เสียชีวิตจาก Covid - 19
        ผลการทดสอบ : success (มี element นี้อยู่จริง)
  • Backend
    การทำงานในส่วนนี้เป็นการใช้ service API จากภายนอก จึงทำให้ไม่มีการ test ในส่วนของ Backend

E2E test

  • Frontend
    ผลการทดสอบของ feature การแสดงข้อมูลสถิ Covid-19 ที่ฝั่ง Frontend มีเพียงผลลัพธ์การทดสอบเดียว คือการที่ผุ็ใช้สามารถเข้าถึงหน้า Home เพื่อดูข้อมูลได้: Success (สามารถเข้าถึงหน้า Home)
  • Backend
    การทำงานในส่วนนี้เป็นการใช้ service API จากภายนอก จึงทำให้ไม่มีการ test ในส่วนของ Backend

 

2.ปรับปรุงใหม่ ฟีเจอร์: การค้นหาและจองเตียง

User Flow


User Flow ของ feature การค้นหาและจองเตียง

  1. ผู้ใช้เลือกเข้าหน้าค้นหาเตียงผ่าน menu ค้นหาเตียง
  2. ผู้ใช้กรอกข้อมูลของสถานที่ ที่ต้องการค้นหาเตียง
  3. ผู้ใช้กดค้นหาเตียง
  4. ผู้ใช้ทำการเลือกเตียงที่ต้องการจอง
  5. ผู้ใช้ตรวจสอบข้อมูลเตียงที่ต้องการจองและเลือกวันที่จากนั้นกดยืนยันการจองเตียง

UI Flow

UI Flow หลักๆที่มีส่วนเกี่ยวข้องกับ feature การค้นหาและจองเตียงได้แก่

  1. หน้า Home เป็นหน้าแรกของ website
  2. หน้าค้นหาเตียง เป็นหน้าที่ user ใช้ในการค้นหาสถานที่ให้บริการเตียง โดยดูจากตำแหน่งของ user หรือตำแหน่งที่ user ต้องการ
  3. หน้าจองเตียง เป็นหน้าที่ user ใช้เพื่อยืนยันการจองเตียงในสถานที่ให้บริการเตียงที่ user ต้องการ

 

Acceptance Test

case1: การค้นหาเตียงนั้นจะมีการแสดงผลก็ต่อเมื่อผู้ใช้ใส่ input ที่เป็นชื่อจังหวัดอย่างถูกต้องและมีในฐานข้อมูล
case2: เมื่อผู้ใช้ใส่ input ที่เป็นชื่อจังหวัดไม่ถูกต้อง หรือไม่มีในฐานข้อมูลระบบจะไม่มีการแสดง ผลลัพธ์ออกมาให้
case3: การจองเตียงที่สำเร็จนั้นจะเกิดจากการกดยืนยันแล้วระบบเช็คได้ว่ามีเตียงเหลือให้
case4: การจองที่ไม่สำเร็จสามารถเกิดจากการกดยืนยันแล้วระบบเช็คได้ว่าเตียงเต็มแล้ว
case5: การจองเตียงที่ไม่สำเร็จสามารถเกิดจากการกดยืนยันแล้วระบบเช็คได้ว่าผู้ใช้นั้นได้ใช้สิทธ์จองไปแล้ว

 

Technical

ในด้าน Technical ของ feature การค้นหาและจองเตียง สามารถอธิบายและแบ่งออกเป็นหัวข้อย่อยๆได้ ดังนี้

Frontend

ในส่วนของ Frontend เราจะมีการกำหนดขั้นตอนการพัฒนาอยู่ทั้งหมด 5 ขั้นตอน พร้อมกำหนดรายละเอียดคร่าวๆ ลงในแต่ละขั้นตอน ดังนี้

  1. ออกแบบ UI เป็นการออกแบบหน้าตา UI ของการทำงานต่างๆที่เกี่ยวข้องกับ Feature การค้นหาและจองเตียง โดยแบ่งออกได้เป็น 2 หน้าจอหลักๆ ได้แก่
    1. หน้าค้นหาเตียง
    2. หน้าจองเตียง
  2. ออกแบบ Business Logic เป็นการออกแบบตัว Frontend ให้ตอบสนองกับตัว Business ที่ต้องการจาก feature ตัวนี้
  3. ทำการเขียนโค้ดเพื่อพัฒนาหน้า UI ต่างๆขึ้นมา ตามที่ได้ออกแบบไว้ใน 2 ขั้นตอนที่กล่าวไปข้างต้น โดยในส่วนนี้จะใช้ Vue.JS ในการพัฒนาเป็นหลัก โดยที่อาจจะมีการใช้เครื่องมืออื่นๆในการพัฒนาร่วมด้วย ยกตัวอย่างเช่น
    • HTML
    • CSS
    • Bootstrap
  4. ทำการ Test หรือก็คือ ทำการทดสอบตัว Frontend ที่พัฒนาจนเสร็จแล้วในแต่ละส่วน ว่าสามารถทำงานได้สมบูรณ์ตามที่คาดหวังไว้หรือไม่ ไปจนถึงการทดสอบส่วนของ Frontend ที่เกี่ยวข้องทั้งหมด เพื่อทำการยืนยันความสมบูรณ์ในขั้นตอนสุดท้าย
  5. ทำการ Deploy เป็นขั้นตอนสุดท้ายในขั้นตอนการพัฒนาที่ได้กำหนดไว้ โดยเมื่อทำการทดสอบตัว Frontend จนสมบูรณ์แล้ว จะทำการ Deploy Frontend ในส่วนนั้นๆ โดยใช้ Docker

Backend

ในส่วนของ Backend เราจะมีการกำหนดขั้นตอนการพัฒนาอยู่ทั้งหมด 4 ขั้นตอน พร้อมกำหนดรายละเอียดคร่าวๆ ลงในแต่ละขั้นตอน ดังนี้

  1. ออกแบบ API ที่ใช้ในการค้นหาและจองเตียงทั้งหมด
  2. ทำการพัฒนาโดยใช้ Express.js ซึ่งเป็นเว็บเฟรมเวิร์คจาก NPM ที่ใช้สำหรับพัฒนาเว็บแอพพลิเคชั่นหรือเว็บไซต์บน Node.js ที่ทำงานที่ฝั่งของ Backend
  3. ทำการ Test หรือก็คือ ทำการทดสอบตัว Backend ที่พัฒนาจนเสร็จแล้วในแต่ละส่วน ว่าสามารถทำงานได้สมบูรณ์ตามที่คาดหวังไว้หรือไม่ ตามหัวข้อดังนี้
    • ตรวจสอบการส่งข้อมูลของผู้ใช้จาก Frontend ไปที่ Backend
    • ตรวจสอบข้อมูลที่ส่งมา ว่าได้รับข้อมูลถูกต้องครบถ้วนหรือไม่
    • ตรวจสอบการเข้าถึงและการเชื่อมต่อกับฐานข้อมูล
  4. ทำการ Deploy เป็นขั้นตอนสุดท้ายในขั้นตอนการพัฒนาที่ได้กำหนดไว้ โดยเมื่อทำการทดสอบตัว Backend จนสมบูรณ์แล้ว จะทำการ Deploy Backend ในส่วนนั้นๆ โดยใช้ Docker

Database

ในส่วนของ database เราเลือกใช้เป็น MySQL เพื่อง่ายต่อการเข้าถึงข้อมูลที่มีความสัมพันธ์กันได้เป็นอย่างดี โดยเราจะทำการกำหนดข้อมูลที่ต้องการจัดเก็บและออกแบบตารางและความสัมพันธ์บนระบบคลาวด์ AWS Amazon RDS

 

List of Task

Frontend

Task

เวลาที่กำหนด

ผู้รับผิดชอบ

1. ออกแบบหน้า UI ในส่วนของการค้นหาและจองเตียง

3 ชั่วโมง

นายวิชยุตม์ ทวิชัยยุทธ

2. ทำการพัฒนาหน้าค้นหาเตียงโดยใช้ Vue.JS ในการพัฒนา

3 ชั่วโมง

นายอคิราภ์ สีแสนยง

3. ทำการพัฒนาหน้าการจองเตียงโดยใช้ Vue.JS ในการพัฒนา

3 ชั่วโมง

นายพิชญะ สิงห์มีศรี

 

Backend

Task

เวลาที่กำหนด

ผู้รับผิดชอบ

1. ออกแบบ Backend เพื่อรองรับในส่วนของการค้นหาและจองเตียง

3 ชั่วโมง

นายพลัฏฐ์ วงศ์สิทธิพรรุ่ง

2. พัฒนา Backend เพื่อรองรับการเข้าถึงข้อมูลสถานที่ให้บริการเตียงโดยใช้ Node.js ในการพัฒนา

3 ชั่วโมง

นายพลัฏฐ์ วงศ์สิทธิพรรุ่ง

3. พัฒนา Backend สำหรับจัดเก็บข้อมูลการจองเตียง เพื่อรองรับการจองเตียงของ User โดยใช้ Node.js ในการพัฒนา

3 ชั่วโมง

นายประธาน นาเวียง

 

Database

Task

เวลาที่กำหนด

ผู้รับผิดชอบ

1. ออกแบบ Database สำหรับเก็บข้อมูลของสถานที่ให้บริการเตียง, ผู้ให้บริการ และจำนวนเตียงที่ให้บริการ

3 ชั่วโมง

นายปภัส เงาธัมมะสกุล

2. พัฒนา Database สำหรับเก็บข้อมูลของสถานที่ให้บริการเตียง, ผู้ให้บริการ และจำนวนเตียงที่ให้บริการ โดยใช้ MySQL ในการพัฒนา

3 ชั่วโมง

นายประธาน นาเวียง

 

เงื่อนไขในการผ่าน Acceptance Test

Frontend

task 1: ออกแบบหน้า UI ในส่วนของการค้นหาและจองเตียง

  • ต้องมีหน้า UI ทั้ง 2 หน้าครบได้แก่ หน้าค้นหาเตียง และ หน้าจองเตียง
  • ในส่วนหน้า UI ของหน้าค้นหาเตียง ต้องมีการแสดงผล UI Elements ต่างๆที่ช่วยให้ User สามารถ Interact ในการเข้าถึงฟังก์ชั่นการค้นหาเตียงที่ User ต้องการ
  • ในส่วนหน้า UI ของหน้าจองเตียง ต้องมีการแสดงผล UI Components ที่แสดงรายละเอียดของเตียงที่ User ต้องการจองครบถ้วน และมี UI Components ที่เป็นช่อง Input ที่ User สามารถเลือกวันที่ต้องการจองได้

task 2: ทำการพัฒนาหน้าค้นหาเตียงโดยใช้ Vue.JS ในการพัฒนา

  • feature ค้นหาเตียงต้องที่ได้พัฒนาแล้วนั้น ต้องมีหน้า UI ตามที่ได้ออกแบบไว้ครบถ้วน
  • ต้องสามารถใช้งานฟังก์ชั่นการค้นหาเตียงที่ user ต้องการได้อย่างถูกต้อง
  • ต้องมีการแสดงผลลัพธ์ของการค้นหาเตียงที่ user ต้องการได้อย่างถูกต้อง

task 3: ทำการพัฒนาหน้าการจองเตียงโดยใช้ Vue.JS ในการพัฒนา

  • feature การจองเตียงที่ได้พัฒนาแล้วนั้นต้องมีหน้า UI ตามที่ได้ออกแบบไว้ครบถ้วน
  • ต้องมีการแสดงผลรายละเอียดของเตียงที่ user ต้องการจองได้ครบถ้วน
  • ต้องมีการ validate ช่อง Input วันที่ ที่ user ต้องการจอง

 

Backend

task 1: ออกแบบ Backend เพื่อรองรับในส่วนของการค้นหาและจองเตียง

  • Backend ที่ได้ออกแบบมีรูปแบบการทำงานที่รองรับการเรียกใช้จากฝั่ง Frontend
  • Backend ที่ได้ออกแบบแล้วต้องมีรูปแบบของ API ที่เข้าใจง่ายไม่ซับซ้อนเพื่อง่ายต่อการเรียกใช้งาน
  • Backend ที่ได้ออกแบบแล้วต้องมีการรองรับฟังก์ชั่นการค้นหาและจองเตียงทั้งหมด

task 2: พัฒนา Backend เพื่อรองรับการเข้าถึงข้อมูลสถานที่ให้บริการเตียงโดยใช้ Node.js ในการพัฒนา

  • สามารถเข้าถึงข้อมูลสถานที่ให้บริการเตียงในฐานข้อมูลได้
  • สามารถส่งข้อมูลสถานที่บริการเตียงที่ผู้ใช้ทำการค้นไปแสดงที่ฝั่ง Frontend ได้อย่างถูกต้อง

task 3: พัฒนา Backend สำหรับจัดเก็บข้อมูลการจองเตียง เพื่อรองรับการจองเตียงของ User โดยใช้ Node.js ใน

  • สามารถเข้าถึงและแก้ไขข้อมูลในฐานข้อมูลของการจองเตียงได้
  • สามารถนำข้อมูลการจองเตียงของผู้ใช้จัดเก็บลงฐานข้อมูลได้ ที่ใช้จัดเก็บข้อมูลการจองเตียงได้อย่างถูกต้อง

 

Database

task 1: ออกแบบ Database สำหรับเก็บข้อมูลของสถานที่ให้บริการเตียง, ผู้ให้บริการ และจำนวนเตียงที่ให้บริการ

  • ฐานข้อมูลที่ได้ทำการออกแบบต้องเป็นรูปแบบของ SQL
  • ฐานข้อมูลที่ได้ทำการออกแบบต้องมีการเก็บข้อมูลแยกกันเป็น 2 ตาราง ได้แก่ ข้อมูลสถานที่ให้บริการเตียง (beds) และ ข้อมูลการจองเตียงของผู้ใช้ (bedsdealing)

task 2: พัฒนา Database สำหรับเก็บข้อมูลของสถานที่ให้บริการเตียง, ผู้ให้ บริการ และจำนวนเตียงที่ให้บริการ โดยใช้ MySQL ในการพัฒนา

  • ฐานข้อมูลที่ได้ทำการพัฒนาขึ้นจะต้องมีชนิดของข้อมูล หรือ Data type ที่เหมาะสมกับชนิดข้อมูลนั้นๆ
  • ฐานข้อมูลที่ได้ทำการพัฒนาขึ้นมาสามารถจัดเก็บข้อมูลที่จำเป็นในการใช้งานฟีเจอร์ ค้นหาและจองเตียงได้ ตามที่ได้ออกแบบไว้

Test Stratergies

Unit test

  • Frontend
    เป็นการทดสอบตัว feature การค้นหาและจองเตียง ของระบบ โดยจะทำการทดสอบในส่วนของ วันเดือนปี ซึ่งมีขั้นตอนดังนี้
    1. ทดสอบการเปลี่ยน format วันที่แบบปกติให้อยู่ในรูปแบบ ไทย โดยมีขั้นตอนย่อยดังนี้
      1. ทดสอบในส่วนของวันที่ ตั้งแต่วันที่ 1 - 31 (31 cases)
      2. ทดสอบในส่วนของเดือน ตั้งแต่มกราคม - ธันวาคม (12 cases)
      3. ทดสอบในส่วนของปี ตั้งแต่ 1970 - 2021 (51 cases)
  • Backend
    เป็นการทดสอบส่วนย่อยของระบบ โดยจะเน้นไปที่การทดสอบ Request ที่เข้ามา โดยที่เป็นส่วนสำคัญของระบบค้นหาและจองเตียง โดยจะแบ่งออกเป็น 2 ส่วน และมีการทดสอบด้วย Test case ต่างๆ ดังนี้
    1. ทดสอบการเรียกข้อมูลของสถานที่ให้บริการเตียง
      การทดสอบในส่วนนี้จะใช้การ Get และ Post ในรูปแบบต่าง ๆ ในการทดสอบโดยแบ่งออกเป็น 3 รูปแบบ ดังนี้
      • ทำการเรียกข้อมูลสถานที่ให้บริการเตียงที่มีเตียงพร้อมให้บริการ
        เป้าหมายในการทดสอบ : เพื่อทดสอบการเรียกข้อมูลของสถานที่ให้บรอการเตียงทั้งหมดที่มีเตียงพร้อมให้บริการได้จริงหรือไม่ (GET: /beds/available)
      • ทำการเรียกข้อมูลสถานที่ให้บริการเตียงที่มีเตียงพร้อมให้บริการด้วยการค้นหา
        เป้าหมายในการทดสอบ : เพื่อทดสอบการเรียกข้อมูลของสถานที่ให้บริการที่มีเตียงพร้อมให้บริการด้วยการค้นหาได้จริงหรือไม่ (GET: /beds/search)
      • ทำการเรียกข้อมูลสถานที่ให้บริการเตียงโดยใช้เลขประจำตัวของผู้ให้บริการเตียง
        เป้าหมายในการทดสอบ : เพื่อทดสอบการเรียกข้อมูลของสถานที่ให้บริการว่าสามารถใช้เลขประจำตัวของผู้ให้บริการเตียงในการเรียกข้อมูลได้จริงหรือไม่ (GET: /bedsByUser)
      • ทำการเรียกดูข้อมูลรายละเอียดของสถานที่โดยใช้ ID ของเตียง : เพื่อทดสอบการเรียกดูข้อมูลรายละเอียดของเตียงโดยใช้ ID ของเตียงนั้น ๆว่าทำได้จริงหรือไม่
    2. ทดสอบระบบการจองเตียง  และเรียกดูประวัติการจองเตียง
      • ทำการจองเตียงโดยที่สถานที่ให้บริการนั้น ๆ ไม่มีเตียงเพียงพอ: เพื่อทดสอบว่าสามารถทำการจองเตียงในขณะที่สถานที่ให้บริการมีจำนวนเตียงไม่เพียงพอได้หรือไม่ (POST: /bedsdealing)
      • ทำการจองเตียงโดยใส่ข้อมูลทุกอย่างให้ถูกต้อง: เพื่อทดสอบว่าสามารถทำการจองเตียงได้หรือไม่ถ้าได้กรอกข้อมูลทุกอย่างถูกต้องแล้ว (POST: /bedsdealing)
      • ทำการจองเตียงโดยที่ไมสามารถระบุข้อมูลของสถานที่ให้บริการ: เพื่อทดสอบว่าสามารถทำการจองเตียงได้หรือไม่ถ้าไม่สามารถระบุข้อมูลของสถานที่ให้บริการ (POST: /bedsdealing)
      • ทำการเรียกดูประวัติการจองเตียงของผู้ใช้: เพื่อทดสอบว่าสามารถเรียกดูข้อมูลประวัติการจองเตียงของผู้ใช้ได้หรือไม่ (GET: /bedsdealingByUser)
      • ทำการเรียกดูประวัติการจองเตียงโดย ID ของผู้ใช้: เพื่อทดสอบว่าสามารถเรียกดูข้อมูลประวัติการจองเตียงผ่าน ID ของผู้ใช้ได้หรือไม่ (GET: /bedsdealing/customer/51)
      • ทำการทดสอบการเปลี่ยนสถานะของสถานที่ให้บริการผ่าน ID ของสถานที่ให้บริการนั้น ๆ: เพื่อทดสอบว่าสามารถทำการเปลี่ยนสถานะของสถานที่ให้บริการได้หรือไม่

Component test

  • Frontend

    เป็นการทดสอบว่าในแต่ละหน้าที่เกี่ยวข้องกับ feature การค้นหาและจองเตียงนั้น มีส่วนประกอบ หรือ component ที่ควรจะอยู่ในหน้านั้น ๆ ครบถ้วนหรือไม่ โดยจะเน้นเฉพาะส่วนของ Frontend ที่เกี่ยวข้อง การทดสอบในส่วน Component test จะสามารถแบ่งออกได้เป็น 1 ส่วน ดังนี้

    1. การทำ Component test ในส่วนของหน้าค้นหาเตียง เป็นการทดสอบเพื่อดูว่าหน้าค้นหาเตียง มีส่วนประกอบต่างๆครบถ้วนหรือไม่ โดยในหน้าค้นหาเตียง จะมีส่วนประกอบที่ต้องมีอยู่ทั้งหมด 2 ส่วนประกอบ ได้แก่
      • ช่องค้นหาสถานที่ให้บริการเตียง
      • กล่องแสดงข้อมูลสถานที่ให้บริการเตียง
  • Backend
    การทดสอบ component test ของ feature การค้นหาและจองเตียง ของฝั่ง Backend มี 2 ส่วนดังนี้
  • ส่วนที่ 1: การทดสอบการเรียกข้อมูลของสถานที่ให้บริการเตียง
    • สามารถเรียกดูจำนวนเตียงที่เหลือได้
    • สามารถเรียกดูสถานที่ให้บริการผ่าน ID ได้
    • สามารถเรียกดูข้อมูลสถานที่ให้บริการผ่าน User ได้
    • สามารถตอบสนองต่อรายละเอียดของสถานที่ให้บริการได้
    • สามารถทำการค้นหาเตียงได้
  • ส่วนที่ 2: ทดสอบระบบการจองเตียง  และเรียกดูประวัติการจองเตียง
    • สามารถทำการจองเตียงได้
    • สามารถเรียกดูประวัติการจองผ่าน bed_id ได้
    • สามารถเรียกดูประวัติการจองของผู้ใช้
    • สามารถเรียกดูประวัติการจองผ่าน user id ได้
    • สามารถเรียกดูประวัติการจองของผู้ใช้ทุกคนได้

E2E test

  • Frontend
    เป็นการทดสอบตัว feature ระบบการค้นหาและจองเตียง ตั้งแต่เริ่มต้น จนจบ ซึ่งจะเริ่มตั้งแต่หน้า Login เข้าสู่ระบบ => หน้า main => หน้าค้นหาเตียง => หน้าจองเตียง โดยมีจุดประสงค์เพื่อทดลองว่า feature นี้ สามารถใช้งานได้จริง โดยมีขั้นตอนดังนี้ โดยเริ่มจาก
    1. การกรอกข้อมูล email และ รหัสผ่านให้ถูกต้อง เพื่อลงชื่อเข้าใช้งานที่หน้า login
    2. กดปุ่ม ค้นหาเตียง ที่แถบ Nav bar เพื่อไปที่หน้า ค้นหาเตียง
    3. กรอกชื่อจังหวัด หรือคำที่ใกล้เคียง เพื่อค้นหาสถานที่ ที่ต้องการ
    4. กดปุ่ม ดูรายละเอียด ในช่องสถานที่ที่ต้องการ เพื่อไปที่หน้า จองเตียง
    5. เลือกวันที่ต้องการจองให้ถูกต้อง
    6. กดปุ่ม จอง และยืนยัน
  • Backend
    เป็นการทดสอบการเรียก API ทั้งหมดที่เกี่ยวข้องกับ feature การค้นหา และจองเตียง ตั้งแต่การ Signin จนถึง การจองเตียง ดังนี้
    • POST: user/signin
    • GET: bedsByUser
    • POST: /users/signin
    • POST: bedsdealing
    • GET: bedsdealingByUser
    • POST: /users/logout
    • PUT: /bedsdealing/customer/104

 

Test Result

Unit test

  • Frontend

    ผลการทดสอบ unit test ของ function การเปลี่ยน format วันที่แบบปกติให้อยู่ในรูปแบบ ไทย มีผลลัพธ์จากการทดสอบ ดังนี้

    • ทดสอบในส่วนของวันที่ ตั้งแต่วันที่ 1 - 31 (31 cases)
      ผลการทดสอบ : success (ผ่านทั้ง 31 case)
    • ทดสอบในส่วนของเดือน ตั้งแต่มกราคม - ธันวาคม (12 cases)
      ผลการทดสอบ : success (ผ่านทั้ง 12 case)
    • ทดสอบในส่วนของปี ตั้งแต่ 1970 - 2021 (51 cases)
      ผลการทดสอบ : success (ผ่านทั้ง 51 case)

  • Backend
    1. ทดสอบการเรียกข้อมูลของสถานที่ให้บริการเตียง
      การทดสอบในส่วนนี้จะใช้การGet และ Post ในรูปแบบต่าง ๆ ในการทดสอบโดยแบ่งออกเป็น 3 รูปแบบ ดังนี้
      • ทำการเรียกข้อมูลสถานที่ให้บริการเตียงที่มีเตียงพร้อมให้บริการ
        เป้าหมายในการทดสอบ : เพื่อทดสอบการเรียกข้อมูลของสถานที่ให้บรอการเตียงทั้งหมดที่มีเตียงพร้อมให้บริการได้จริงหรือไม่ (GET: /beds/available) => Success (เรียกได้)
      • ทำการเรียกข้อมูลสถานที่ให้บริการเตียงที่มีเตียงพร้อมให้บริการด้วยการค้นหา
        เป้าหมายในการทดสอบ : เพื่อทดสอบการเรียกข้อมูลของสถานที่ให้บริการที่มีเตียงพร้อมให้บริการด้วยการค้นหาได้จริงหรือไม่ (GET: /beds/search) => Success (เรียกได้)
      • ทำการเรียกข้อมูลสถานที่ให้บริการเตียงโดยใช้เลขประจำตัวของผู้ให้บริการเตียง
        เป้าหมายในการทดสอบ : เพื่อทดสอบการเรียกข้อมูลของสถานที่ให้บริการว่าสามารถใช้เลขประจำตัวของผู้ให้บริการเตียงในการเรียกข้อมูลได้จริงหรือไม่ (GET: /bedsByUser) => Success (เรียกได้)
      • ทำการเรียกดูข้อมูลรายละเอียดของสถานที่โดยใช้ ID ของเตียง : เพื่อทดสอบการเรียกดูข้อมูลรายละเอียดของเตียงโดยใช้ ID ของเตียงนั้น ๆว่าทำได้จริงหรือไม่ (GET: bed/125) => Success (เรียกได้)
    2. ทดสอบระบบการจองเตียง และเรียกดูประวัติการจองเตียง
      • ทำการจองเตียงโดยที่สถานที่ให้บริการนั้น ๆ ไม่มีเตียงเพียงพอ: เพื่อทดสอบว่าสามารถทำการจองเตียงในขณะที่สถานที่ให้บริการมีจำนวนเตียงไม่เพียงพอได้หรือไม่ (POST: /bedsdealing) => Success (ต้องจองไม่ได้)
      • ทำการจองเตียงโดยใส่ข้อมูลทุกอย่างให้ถูกต้อง: เพื่อทดสอบว่าสามารถทำการจองเตียงได้หรือไม่ถ้าได้กรอกข้อมูลทุกอย่างถูกต้องแล้ว (POST: /bedsdealing)  => Success (ต้องจองได้)
      • ทำการจองเตียงซำ้ ในสถานที่ให้บริการที่เดียวกัน: เพื่อทดสอบว่าสามารถจองเตียงในสถานที่ให้บริการเตียงที่ซำ้กันได้หรือไม่ (POST: /bedsdealing)  => Success (ต้องจองไม่ได้)
      • ทำการจองเตียงโดยที่ไมสามารถระบุข้อมูลของสถานที่ให้บริการ: เพื่อทดสอบว่าสามารถทำการจองเตียงได้หรือไม่ถ้าไม่สามารถระบุข้อมูลของสถานที่ให้บริการ (POST: /bedsdealing) => Success (ต้องจองไม่ได้)
      • ทำการเรียกดูประวัติการจองเตียงของผู้ใช้: เพื่อทดสอบว่าสามารถเรียกดูข้อมูลประวัติการจองเตียงของผู้ใช้ได้หรือไม่ (GET: /bedsdealingByUser) => Success (เรียกได้)
      • ทำการเรียกดูประวัติการจองเตียงโดย ID ของผู้ใช้: เพื่อทดสอบว่าสามารถเรียกดูข้อมูลประวัติการจองเตียงผ่าน ID ของผู้ใช้ได้หรือไม่ (GET: /bedsdealing/customer/51) => Success (เรียกได้)
      • ทำการทดสอบการเปลี่ยนสถานะของสถานที่ให้บริการผ่าน ID ของสถานที่ให้บริการนั้น ๆ: เพื่อทดสอบว่าสามารถทำการเปลี่ยนสถานะของสถานที่ให้บริการได้หรือไม่ => Success (เปลี่ยนได้)

Component test

  • Frontend

    ผลการทดสอบ frontend component test จะแบ่งออกเป็น 2 ส่วน เหมือนที่ได้ระบุไว้ใน test stratergies ดังนี้

    1. การทำ Component test ในส่วนของหน้าค้นหาเตียง
      • ช่องค้นหาสถานที่ให้บริการเตียง
        ผลการทดสอบ : success (มี Element นี้อยู่จริง)
      • กล่องแสดงข้อมูลสถานที่ให้บริการเตียง
        ผลการทดสอบ : success (มี Element นี้อยู่จริง)

  • Backend
    • ส่วนที่ 1: การทดสอบการเรียกข้อมูลของสถานที่ให้บริการเตียง
      • สามารถเรียกดูจำนวนเตียงที่เหลือได้ (Success)
      • สามารถเรียกดูสถานที่ให้บริการผ่าน ID ได้ (Success)
      • สามารถเรียกดูข้อมูลสถานที่ให้บริการผ่าน User ได้ (Success)
      • สามารถตอบสนองต่อรายละเอียดของสถานที่ให้บริการได้ (Success)
      • สามารถทำการค้นหาเตียงได้ (Success)
    • ส่วนที่ 2: ทดสอบระบบการจองเตียง และเรียกดูประวัติการจองเตียง
      • สามารถทำการจองเตียงได้ (Success)
      • สามารถเรียกดูประวัติการจองผ่าน bed_id ได้ (Success)
      • สามารถเรียกดูประวัติการจองของผู้ใช้ (Success)
      • สามารถเรียกดูประวัติการจองผ่าน user id ได้ (Success)
      • สามารถเรียกดูประวัติการจองของผู้ใช้ทุกคนได้ (Success)

E2E test

  • Frontend
    ผลการทดสอบของ feature กาค้นหาและจองเตียง ที่ฝั่ง Frontend มีเพียงผลลัพธ์การทดสอบเดียว คือการที่สามารถค้นหาสถานที่ที่ต้องการ และทำการจองได้ หลังจากกรอกวันที่อย่างถูกต้อง: Success (สามารถค้นหา และจองเตียงได้)
  • Backend

 

3.เพิ่มฟีเจอร์ใหม่ : การเพิ่มสถานที่ให้บริการเตียง

User Flow

User Flow ของ feature เพิ่มสถานที่ให้บริการเตียง ประกอบด้วยขั้นตอนดังนี้

  1. User ทำการ Login เข้าสู่หน้า Home ของ website
  2. User กดไปที่ปุ่ม ฉันต้องการลงเตียง ที่แถบ Nav bar เพื่อเข้าไปที่หน้า จัดกานสถานที่
  3. User กดไปที่ปุ่ม เพิ่มสถานที่ เพื่อไปที่หน้า เพิ่มสถานที่
  4. User ทำการกรอกจำนวนเตียง และระบุพิกัดที่อยู่
  5. User กดปุ่ม เพิ่มสถานที่เดี๋ยวนี้ และกดยืนยัน

 

UI Flow

UI หลักๆที่เกี่ยวข้องกับ feature นี้ ประกอบด้วย

  1. หน้า bedsmanage (หน้าการจัดการเตียง) ในหน้านี้จะมีการแสดงผลของสถานที่ให้บริการเตียงทั้งหมดที่เปิดให้บริการโดย user ซึ่ง user สามารถเลือกสถานที่ให้บริการเตียงที่ต้องการแก้ไขข้อมูลได้ผ่านทางหน้านี้
  2. หน้าเพิ่มสถานที่ให้บริการเตียง ในหน้านี้จะมีฟอร์มให้ user กรอกข้อมูล เพื่อใช้้ในการเปิดสถานที่ให้บริการเตียงเพิ่ม

 

Acceptance Test

Technical

ในด้าน technical ของ feature เพิ่มสถานที่ให้บริการเตียง สามารถอธิบายและแบ่งออกเป็นหัวข้อย่อยๆได้ ดังนี้

Frontend
ในส่วน Frontend เราจะมีการกำหนดขั้นตอนการพัฒนาอยู่ทั้งหมด 5 ขั้นตอน พร้อมกำหนดรายละเอียดคร่าวๆ ลงในแต่ละขั้นตอน ดังนี้

  1. ออกแบบ UI เป็นการออกแบบหน้าตา UI ของการทำงานต่างๆ ที่เกี่ยวข้องกับ Feature การเพิ่มสถานที่ให้บริการเตียง โดยแบ่งออกเป็น 2 หน้าจอหลัก
    1. หน้าจัดการสถานที่
    2. หน้าเพิ่มสถานที่
  2. ออกแบบ Business Logic เป็นการออกแบบตัว Frontend ให้ตอบสนองกับตัว Business ที่ต้องการจาก feature ตัวนี้
  3. ทำการเขียนโค้ดเพื่อพัฒนาหน้า UI ต่าง ๆ ขึ้นมา ตามที่ได้ออกแบบไว้ใน 2 ขั้นตอนที่กล่าวไปข้างต้น โดยในส่วนนี้จะใช้ Vue.JS ในการพัฒนาเป็นหลัก โดยที่อาจจะมีการใช้เครื่องมืออื่นๆในการพัฒนาร่วมด้วย ยกตัวอย่างเช่น
    • HTML
    • CSS
    • Bootstrap
  4. ทำการ Test หรือก็คือ ทำการทดสอบตัว Frontend ที่พัฒนาจนเสร็จสิ้นแล้วในแต่ละส่วน ว่าสามารถทำงานได้สมบูรณ์ตามที่คาดหวังไว้หรือไม่ ไปจนถึงการทดสอบส่วนของ Frontend ที่เกี่ยวข้องทั้งหมด เพื่อทำการยืนยันความสมบูรณ์ในขั้นสุดท้าย
  5. ทำการ Deploy เป็นขั้นตอนสุดท้ายในขั้นตอนการพัฒนาที่ได้กำหนดไว้ โดยเมื่อทำการทดสอบตัว Frontend จนสมบูรณ์ในแต่ละส่วนแล้ว จะทำการ Deploy Frontend ในส่วนนั้น ๆ โดยใช้ Docker

Backend
ในส่วนของ Backend เราจะมีการกำหนดขั้นตอนการพัฒนาอยู่ทั้งหมด 4 ขั้นตอน พร้อมกำหนดรายละเอียดคร่าวๆ ลงในแต่ละขั้นตอน ดังนี้

  1. ออกแบบ API ที่ใช้ในการเพิ่มสถานที่ให้บริการเตียง
  2. ทำการพัฒนาโดยใช้ Express.js ซึ่งเป็นเฟรมเวิร์คจาก NPM ที่ใช้พัฒนาเว็บแอพพลิเคชั่นหรือเว็บไซต์บน Node.js ที่ทำงานที่ฝั่งของ Backend
  3. ทำการ Test หรือก็คือ ทำการทดสอบตัว Backend ที่พัฒนาจนเสร็จแล้วในแต่ละส่วน ว่าสามารถทำงานได้สมบูรณ์ตามที่คาดหวังไว้หรือไม่ ตามหัวข้อดังนี้
    • ตรวจสอบการส่งข้อมูลของผู้ใช้จาก Frontend ไปที่ Backend
    • ตรวจสอบข้อมูลที่ส่งมา ว่าได้รับข้อมูลมูลถูกต้องครบถ้วนหรือไม่
    • ตรวจสอบการเข้าถึงและการเชื่อมต่อฐานข้อมูล
  4. ทำการ Deploy เป็นขั้นตอนสุดท้ายในขั้นตอนการพัฒนาที่ได้กำหนดไว้โดยเมื่อ ทำการทดสอบตัว Backend จนสมบูรณ์แล้ว จะทำการ Deploy Backend ในส่วนนั้นๆ โดยใช้ Docker

Database

ในส่วนของ database เราเลือกใช้เป็น MySQL เพื่อง่ายต่อการเข้าถึงข้อมูลที่มีความสัมพันธ์กันได้เป็นอย่างดี โดยเราจะทำการกำหนดข้อมูลที่ต้องการจัดเก็บและออกแบบตารางและความสัมพันธ์บนระบบคลาวด์ AWS Amazon RDS

List of Task

Frontend

Task

เวลาที่กำหนด

ผู้รับผิดชอบ

1.ออกแบบหน้า UI ในส่วนของการเพิ่มสถานที่ให้บริการเตียง

3 ชั่วโมง

นายอคิราภ์ สีแสนยง

2.ทำการพัฒนาหน้าการจัดการสถานที่ โดยใช้ Vue.JS ในการพัฒนา

2 ชั่วโมง

นายวิชยุตม์ ทวิชัยยุทธ

3.ทำการพัฒนาหน้าเพิ่มสถานที่ให้บริการเตียงโดยใช้ Vue.JS ในการพัฒนา

4 ชั่วโมง

นายพิชญะ สิงห์มีศรี

Backend

Task

เวลาที่กำหนด

ผู้รับผิดชอบ

1.ออกแบบ backend เพื่อรองรับในส่วนของการเพิ่มสถานที่ให้บริการเตียง

3 ชัวโมง

นายพลัฏฐ์ วงศ์สิทธิพรรุ่ง

2.พัฒนา Backend เพื่อรองรับการเข้าถึงข้อมูลสถานที่ให้บริการเตียงโดยใช้ Node.js ในการพัฒนา

3 ชั่วโมง

นายพลัฏฐ์ วงศ์สิทธิพรรุ่ง

3.พัฒนา Backend สำหรับการเพิ่มสถานที่ให้บริการเตียง โดยใช้ Node.js ในการพัฒนา

3 ชั่วโมง

นายประธาน นาเวียง

Database

Task

เวลาที่กำหนด

ผู้รับผิดชอบ

1.ออกแบบ Database สำหรับเก็บข้อมูลของสถานที่ให้บริการเตียง, ผู้ให้บริการ และจำนวนเตียงที่ให้บริการ

3 ชัวโมง

นายปภัส เงาธัมมะสกุล

2.พัฒนา Database สำหรับเก็บข้อมูลของสถานที่ให้บริการเตียง, ผู้ให้บริการ และจำนวนเตียงที่ให้บริการ โดยใช้ MySQL ในการพัฒนา

3 ชั่วโมง

นายประธาน นาเวียง

เงื่อนไขในการผ่าน Acceptance Test

Frontend

Task 1 : ออกแบบหน้า UI ในส่วนของการเพิ่มสถานที่ให้บริการเตียง

  • ต้องมีหน้า UI ของ 2 หน้าหลักครบ ได้แก่ หน้าการจัดการสถานที่ และเพิ่มสถานที่ให้บริการเตียง
  • หน้าการจัดการเตียงที่ออกแบบออกมา จะต้องมีการแสดงผลข้อมูลสถานที่ให้บริการเตียงที่ user เป็นผู้ให้บริการทั้งหมด
  • หน้าการจัดการเตียงที่ออกแบบออกมา จะต้องมี Element ปุ่มที่ใช้ในการกด เพิ่มสถานที่ และปุ่มยกเลิก
  • หน้าเพิ่มสถานที่ให้บริการเตียง จะต้องมีการช่องกรอกข้อมูลทั้งหมด 5 ช่อง โดยจะสามารถกรอกได้เฉพาะ 2 ช่อง คือ ช่องจำนวนเตียง และช่องพิกัดที่อยู่
  • ในหน้าเพิ่มสถานที่ให้บริการเตียง จะต้องมีการแสดง แผนทีีที่อยู่ หลังจากระบุพิกัดที่อยู่ที่ถูกต้อง

Task 2 : ทำการพัฒนาหน้าการจัดการเตียง โดยใช้ Vue.JS ในการพัฒนา

  • หน้าการจัดการสถานที่ที่ได้ทำการพัฒนาแล้วนั้นต้องมีรูปแบบ UI ตามที่ได้ออกแบบไว้ครบถ้วน
  • หน้าการจัดการสถานที่ที่ได้ทำการพัฒนาแล้วนั้น จะต้องมีปุ่มที่สามารถลิ้งค์ไปที่หน้า เพิ่มสถานที่ให้บริการเตียงได้

Task 3 : ทำการพัฒนาหน้าเพิ่มสถานที่ให้บริการเตียง โดยใช้ Vue.JS ในการพัฒนา

  • หน้าเพิ่มสถานที่ให้บริการเตียงที่ได้ทำการพัฒนาแล้วนั้นจะต้องมีรูปแบบ UI ตามที่ได้ออกแบบไว้ครบถ้วน
  • หน้าเพิ่มสถานที่ให้บริการเตียงที่ได้ทำการพัฒนาแล้วนั้นจะต้องสามารถกรอกข้อมูล จำนวนเตียง และพิกัดที่อยู่ได้
  • หน้าเพิ่มสถานที่ให้บริการเตียงที่ได้ทำการพัฒนาแล้วนั้นจะต้องมีการแสดงผลในรูปแบบแผนที่ หลังจากระบุพิกัดเสร็จ
  • หน้าเพิ่มสถานที่ให้บริการเตียงที่ได้ทำการพัฒนาแล้วนั้นจะต้องสามารถกดปุ่มเพื่อยืนยันความถูกต้องของข้อมูล และเพิ่มสถานที่ได้

Backend

Task 1: ออกแบบ backend เพื่อรองรับในส่วนของการเพิ่มสถานที่ให้บริการเตียง

  • backend ที่ได้ออกแบบมีรูปแบบการทำงานที่รองรับการเรียกใช้งานจากฝั่ง frontend
  • backend ที่ออกแแบบออกมาต้องมีรูปแบบของ API ที่เข้าใจได้ง่าย เพื่อง่ายแก่การเรียกใช้งาน
  • Backend ที่ออกแบบมาจะต้องมีการรองรับฟังก์ชันทั้งหมด 2 ฟังก์ชันหลัก ได้แก่ การดึงข้อมูลขอลสถานที่ให้บริการเตียงที่ user เป็นผู้ให้บริการ และการเพิ่มข้อมูลสถานที่บริการเตียงใหม่ที่ user ต้องการเพิ่ม

Task 2: พัฒนา Backend เพื่อรองรับการเข้าถึงข้อมูลสถานที่ให้บริการเตียงโดยใช้ Node.js ในการพัฒนา

  • สามารถเข้าถึงข้อมูลของสถานที่ให้บริการเตียงใน database ที่ user เป็นผู้ให้บริการได้
  • สามารถส่งข้อมูลสถานที่ให้บริการเตียงดังกล่าว กลับไปยังฝั่งของ frontend ได้อย่างถูกต้อง

Task 3: พัฒนา Backend สำหรับการเพิ่มสถานที่ให้บริการเตียง โดยใช้ Node.js ในการพัฒนา

  • สามารถเพิ่มข้อมูลสถานที่ให้บริการเตียงที่ user เป็นผู้ให้บริการลงใน database ได้
  • สามารถ check ของสถานที่ให้บริการเตียงที่จะเพิ่มว่ามีความถูกต้องหรือไม่ ก่อนทำการเพิ่มข้อมูลเข้าไปยัง database ได้

Database

Task 1: ออกแบบ Database สำหรับเก็บข้อมูลของสถานที่ให้บริการเตียง, ผู้ให้บริการ และจำนวนเตียงที่ให้บริการ

  • Database ที่ออกแบบจะต้องเป็นในรูปแบบของ MySQL
  • Database ที่ออกแบบจะต้องมีการเก็บข้อมูลทั้งหมด 2 ส่วน ได้แก่ ข้อมูลสถานที่ให้บริการเตียง user ที่เป็นเจ้าของสถานที่ และจำนวนเตียงที่ให้บริการ

Task 2: พัฒนา Database สำหรับเก็บข้อมูลของสถานที่ให้บริการเตียง, ผู้ให้บริการ และจำนวนเตียงที่ให้บริการ โดยใช้ MySQL ในการพัฒนา

  • Database ที่พัฒนาขึ้นมาสามารถจัดเก็บข้อมูลที่จำเป็นทั้งหมดได้ ตามที่ออกแบบไว้
  • Database ที่พัฒนาขึ้นมาจะต้องมีการใช้ชนิดข้อมูล (Data Type) ที่เหมาะสมกับข้อมูลนั้น

 

Test Stratergies

ในการทดสอบระบบเพิ่มสถานที่ให้บริการเตียง จะมีการแบ่งรูปแบบของการทดสอบออกเป็น 3 ส่วน ดังนี้

Unit Test

  • Frontend
    เป็นการทดสอบตัว feature เพิ่มสถานที่ให้บริการเตียง ของระบบ โดยจะทำการทดสอบในส่วนของ พิกัดที่อยู่ ซึ่งมีขั้นตอนดังนี้
    1. ทดสอบการเปลี่ยนค่าจาก องศา(Degree) ไปเป็น เรเดียน
      1. ทดสอบค่าองศาที่ 0
      2. ทดสอบค่าองศาที่ 90
      3. ทดสอบค่าองศาที่ 180
      4. ทดสอบค่าองศาที่ 360
    2. ทดสอบการแปลงค่า Latitude และLongtitude เพื่อหาระยะทางในกิโล
      1. ทดสอบค่า Latitude1 = 0 , Longtitude1 = 0, Latitude2 = 0 ,Longtitude2 = 0
      2. ทดสอบค่า Latitude1 = 0 , Longtitude1 = 0, Latitude2 = 0 ,Longtitude2 = 90
      3. ทดสอบค่า Latitude1 = 0 , Longtitude1 = 0, Latitude2 = 0 ,Longtitude2 = 180
      4. ทดสอบค่า Latitude1 = 0 , Longtitude1 = 0, Latitude2 = 0 ,Longtitude2 = 360
  • Backend
    เป็นการทดสอบส่วนย่อยของระบบ โดยจะเน้นไปที่การทดสอบ Request ที่เข้ามา โดยที่เป็นส่วนสำคัญของระบบการเพิ่มสถานที่ให้บริการเตียง โดยมี test case คือ
    • สามารสร้างสถานที่ให้บริการเตียงเพิ่มขึ้นใหม่ได้หรือไม่  (POST: /beds)

Component Test

  • Frontend

    เป็นการทดสอบว่าในแต่ละหน้าที่เกี่ยวข้องกับ feature การเพิ่มสถานที่ให้บริการเตียงนั้น มีส่วนประกอบ หรือ component ที่ควรจะอยู่ในหน้านั้น ๆ ครบถ้วนหรือไม่ โดยจะเน้นเฉพาะส่วนของ Frontend ที่เกี่ยวข้อง การทดสอบในส่วน Component test จะสามารถแบ่งออกได้เป็น 1 ส่วน ดังนี้

    1. การทำ Component test ในส่วนของหน้าการจัดการเตียง เป็นการทดสอบเพื่อดูว่าหน้าการจัดการเตียง มีส่วนประกอบต่างๆครบถ้วนหรือไม่ โดยในหน้าการจัดการเตียง จะมีส่วนประกอบที่ต้องมีอยู่เพียง 1 ส่วนประกอบ ได้แก่ ปุ่มสำหรับกดเพื่อเข้าถึงหน้าเพิ่มสถานที่ให้บริการเตียง
  • Backend
    การทดสอบ component test ของ feature การเพิ่มสถานที่ให้บริการเตียง ของฝั่ง Backend มี test case คือ
    • การทดสอบการสร้างสถานที่ให้บริการเตียงเพิ่ม

E2E Test

  • Frontend

    เป็นการทดสอบตัว feature ระบบเพิ่มสถานที่ให้บริการเตียง ตั้งแต่เริ่มต้น จนจบ ซึ่งจะเริ่มตั้งแต่หน้า Login เข้าสู่ระบบ => หน้า main => หน้าจัดการสถานที่ => หน้าเพิ่มสถานที่ให้บริการเตียง โดยมีจุดประสงค์เพื่อทดลองว่า feature นี้ สามารถใช้งานได้จริง

    โดยเริ่มจาก

    1. การกรอกข้อมูล email และ รหัสผ่านให้ถูกต้อง เพื่อลงชื่อเข้าใช้งานที่หน้า login
    2. กดปุ่ม ฉันต้องการลงเตียง ที่แถบ Nav bar เพื่อไปที่หน้า จัดการสถานที่
    3. กดปุ่ม เพิ่มสถานที่ เพื่อไปที่หน้า เพิ่มสถานที่
    4. กรอกข้อมูล จำนวนเตียง และระบุพิกัดที่อยู่ ให้ถูกต้อง
    5. กดปุ่ม เพิ่มสถานที่เดี๋ยวนี้ และกดยืนยัน

  • Backend

    เป็นการทดสอบการเรียก API ทั้งหมดที่เกี่ยวข้องกับ feature การเพิ่มสถานที่ให้บริการเตียง ตั้งแต่การ Signin จนถึง การแก้ไขจำนวนเตียง ดังนี้

    • POST: user/signin
    • POST: /beds

Test Result

Unit Test

  • Frontend

    ผลการทดสอบ unit test ในส่วนของ function ที่เกี่ยวข้องกับพิกัดที่อยู่ ซึ่งจะมีการทดสอบทั้งหมด 2 ส่วน ดังนี้

    1. ทดสอบการเปลี่ยนค่าจาก องศา(Degree) ไปเป็น เรเดียน
      • ทดสอบค่าองศาที่ 0
        ผลการทดสอบ : success (เปลี่ยนองศาไปเรเดียนได้จริง)
      • ทดสอบค่าองศาที่ 90
        ผลการทดสอบ : success (เปลี่ยนองศาไปเรเดียนได้จริง)
      • ทดสอบค่าองศาที่ 180
        ผลการทดสอบ : success (เปลี่ยนองศาไปเรเดียนได้จริง)
      • ทดสอบค่าองศาที่ 360
        ผลการทดสอบ : success (เปลี่ยนองศาไปเรเดียนได้จริง)
    2. ทดสอบการแปลงค่า Latitude และLongtitude เพื่อหาระยะทางในกิโล
      • ทดสอบค่า Latitude1 = 0 , Longtitude1 = 0, Latitude2 = 0 ,Longtitude2 = 0
        ผลการทดสอบ : success (สามารถหาระยะทางได้จริง)
      • ทดสอบค่า Latitude1 = 0 , Longtitude1 = 0, Latitude2 = 0 ,Longtitude2 = 90
        ผลการทดสอบ : success (สามารถหาระยะทางได้จริง)
      • ทดสอบค่า Latitude1 = 0 , Longtitude1 = 0, Latitude2 = 0 ,Longtitude2 = 180
        ผลการทดสอบ : success (สามารถหาระยะทางได้จริง)
      • ทดสอบค่า Latitude1 = 0 , Longtitude1 = 0, Latitude2 = 0 ,Longtitude2 = 360
        ผลการทดสอบ : success (สามารถหาระยะทางได้จริง)
  • Backend
    เป็นการทดสอบส่วนย่อยของระบบ โดยจะเน้นไปที่การทดสอบ Request ที่เข้ามา โดยที่เป็นส่วนสำคัญของระบบการเพิ่มสถานที่ให้บริการเตียง โดยมี test case คือ สามารถทำการสร้างสถานที่ให้บริการเตียงเพิ่มได้ (POST: /beds) => (Success)

Component Test

  • Frontend

    ผลการทดสอบ frontend component test จะแบ่งออกเป็น 2 ส่วน เหมือนที่ได้ระบุไว้ใน test stratergies ดังนี้

    1. การทำ Component test ในส่วนของหน้าการจัดการเตียง
      • ปุ่มสำหรับกดเพื่อเข้าถึงหน้าเพิ่มสถานที่ให้บริการเตียง
        ผลการทดสอบ : success (มี Element นี้อยู่จริง)

  • Backend
    การทดสอบ component test ของ feature การเพิ่มสถานที่ให้บริการเตียง ของฝั่ง Backend มี test case คือ
    • การทดสอบการสร้างสถานที่ให้บริการเตียงเพิ่ม (Success)

E2E Test

  • Frontend
    ผลการทดสอบของ feature การเพิ่มสถานที่ให้บริการเตียง ที่ฝั่ง Frontend มีเพียงผลลัพธ์การทดสอบเดียว คือการเพิ่มสถานที่จองเตียง หลังจากกรอกจำนวนเตียง และระบุพิกัดอย่างถูกต้อง: Success (สามารถเพิ่มสถานที่จองเตียงได้)
  • Backend

4.เพิ่มฟีเจอร์ใหม่ : ผู้ให้บริการเตียงเพิ่ม/ลดจำนวนเตียงที่ให้บริการได้

User Flow

User Flow ของ feature ผู้ให้บริการเตียงเพิ่ม/ลดจำนวนเตียงที่ให้บริการได้ประกอบด้วย  ขั้นตอน ดังนี้

  1. ผู้ให้บริการเตียงเลือกเข้าหน้าการจัดการเตียง และทำการเลือกสถานที่ให้บริการเตียงที่ต้องการแก้ไข
  2. เมื่อเข้ามาที่หน้าของการแก้ไขข้อมูลเตียงแล้ว ทำการเพิ่ม - ลดจำนวนเตียงตามที่ต้องการ
  3. ทำการยืนยันการเพิ่ม - ลดจำนวนเตียง

UI Flow

ในส่วนของ UI Flow จะประกอบไปด้วย 2 หน้าหลัก ดังนี้

  1. หน้า bedsmanage (หน้าการจัดการเตียง) ในหน้านี้จะมีการแสดงผลของสถานที่ให้บริการเตียงทั้งหมดที่เปิดให้บริการโดย user ซึ่ง user สามารถเลือกสถานที่ให้บริการเตียงที่ต้องการแก้ไขข้อมูลได้ผ่านทางหน้านี้
  2. หน้า bedsedit (หน้าแก้ไขข้อมูลสถานที่ให้บริการเตียง) หน้านี้จะปรากฏขึ้น เมื่อผู้ใช้เลือกสถานที่ให้บริการเตียงที่จะทำการแก้ไขข้อมูล จากรายชื่อสถานที่ในหน้าการจัดการเตียงเรียบร้อยแล้ว ในหน้านี้จะมีการแสดงผลปุ่ม + และปุ่ม - สำหรับกดเพื่อเพิ่มลดจำนวนเตียง จำนวนเตียงที่ให้บริการได้ในปัจจุบัน และปุ่มยืนยันการแก้ไขข้อมูลสถานที่ให้บริการเตียง

Acceptance Test

Technical

ในด้าน technical ของ feature การเพิ่ม/ลดจำนวนเตียงที่ให้บริการของผู้ให้บริการ สามารถอธิบายและแบ่งออกเป็นหัวข้อย่อย ๆได้ ดังนี้


Frontend
ในส่วน Frontend เราจะมีการกำหนดขั้นตอนการพัฒนาอยู่ทั้งหมด 5 ขั้นตอน พร้อมกำหนดรายละเอียดคร่าวๆ ลงในแต่ละขั้นตอน ดังนี้

  1. ออกแบบ UI เป็นการออกแบบหน้าตา UI ของการทำงานต่างๆ ที่เกี่ยวข้องกับ Feature การเพิ่ม/ลดจำนวนเตียงที่ให้บริการของผู้ให้บริการ โดยแบ่งออกได้เป็น 2 หน้าจอหลัก ได้แก่
    1. หน้าการจัดการเตียง
    2. หน้าแก้ไขข้อมูลสถานที่ให้บริการเตียง
  2. ออกแบบ Business Logic เป็นการออกแบบตัว Frontend ให้ตอบสนองกับตัว Business ที่ต้องการจาก feature ตัวนี้
  3. ทำการเขียนโค้ดเพื่อพัฒนาหน้า UI ต่าง ๆ ขึ้นมา ตามที่ได้ออกแบบไว้ใน 2 ขั้นตอนที่กล่าวไปข้างต้น โดยในส่วนนี้จะใช้ Vue.JS ในการพัฒนาเป็นหลัก โดยที่อาจจะมีการใช้เครื่องมืออื่นๆในการพัฒนาร่วมด้วย ยกตัวอย่างเช่น
    • HTML
    • CSS
    • Boostrap
  4. ทำการ Test หรือก็คือ ทำการทดสอบตัว Frontend ที่พัฒนาจนเสร็จสิ้นแล้วในแต่ละส่วน ว่าสามารถทำงานได้สมบูรณ์ตามที่คาดหวังไว้หรือไม่ ไปจนถึงการทดสอบส่วนของ Frontend ที่เกี่ยวข้องทั้งหมด เพื่อทำการยืนยันความสมบูรณ์ในขั้นสุดท้าย
  5. ทำการ Deploy เป็นขั้นตอนสุดท้ายในขั้นตอนการพัฒนาที่ได้กำหนดไว้ โดยเมื่อทำการทดสอบตัว Frontend จนสมบูรณ์ในแต่ละส่วนแล้ว จะทำการ Deploy Frontend ในส่วนนั้น ๆ โดยใช้ Docker

Backend
ในส่วนของ Backend เราจะมีการกำหนดขั้นตอนการพัฒนาอยู่ทั้งหมด 4 ขั้นตอนพร้อมกำหนดลายละเอียดคร่าวๆ ลงในแต่ละขั้นตอน ดังนี้

  1. ออกแบบ API ที่ใช้ในการเพิ่ม/ลดจำนวนเตียงที่ให้บริการของผู้ให้บริการเตียง
  2. ทำการพัฒนาโดยใช้ Express.js ซึ่งเป็นเว็บเฟรมเวิร์คจาก NPM ที่ใช้สำหรับพัฒนาเว็บแอพพลิเคชั่นหรือเว็บไซต์บน Node.js ที่ทำงานที่ฝั่งของ Backend
  3. ทำการ Test หรือก็คือ ทำการทดสอบตัว Backend ที่พัฒนาจนเสร็จแล้วในแต่ละส่วน ว่าสามารถทำงานได้สมบูรณ์ตามที่คาดหวังไว้หรือไม่ ตามหัวข้อดังนี้
    • ตรวจสอบการส่งข้อมูลของผู้ใช้จาก Frontend ไปที่ Backend
    • ตรวจสอบข้อมูลที่ส่งมา ว่าได้รับข้อมูลถูกต้องครบถ้วนหรือไม่
    • ตรวจสอบการเข้าถึงและการเชื่อมต่อกับฐานข้อมูล
  4. ทำการ Deploy เป็นขั้นตอนสุดท้ายในขั้นตอนการพัฒนาที่ได้กำหนดไว้ โดยเมื่อทำการทดสอบตัว Backend จนสมบูรณ์แล้ว จะทำการ Deploy Backend ในส่วนนั้นๆ โดยใช้ Docker

Database
ในส่วนของ database เราเลือกใช้เป็น MySQL เพื่อง่ายต่อการเข้าถึงข้อมูลที่มีความสัมพันธ์กันได้เป็นอย่างดี โดยเราจะทำการกำหนดข้อมูลที่ต้องการจัดเก็บและออกแบบตารางและความสัมพันธ์บนระบบคลาวด์ AWS Amazon RDS

List of Task

Frontend

Task

เวลาที่กำหนด

ผู้รับผิดชอบ

1.ออกแบบหน้า UI ในส่วนของการเพิ่ม - ลดจำนวนเตียง

3 ชั่วโมง

นายอคิราภ์ สีแสนยง

2.ทำการพัฒนาหน้าการจัดการเตียง โดยใช้ Vue.JS ในการพัฒนา

4 ชั่วโมง

นายวิชยุตม์ ทวิชัยยุทธ

3.ทำการพัฒนาหน้าแก้ไขข้อมูลสถานที่ให้บริการเตียง โดยใช้ Vue.JS ในการพัฒนา

4 ชั่วโมง

นายพิชญะ สิงห์มีศรี

Backend

Task

เวลาที่กำหนด

ผู้รับผิดชอบ

1.ออกแบบ backend เพื่อรองรับในส่วนของการเพิ่ม - ลดจำนวนเตียง

3 ชัวโมง

นายพลัฏฐ์ วงศ์สิทธิพรรุ่ง

2.พัฒนา Backend เพื่อรองรับการเข้าถึงข้อมูลสถานที่ให้บริการเตียงโดยใช้ Node.js ในการพัฒนา

3 ชั่วโมง

นายพลัฏฐ์ วงศ์สิทธิพรรุ่ง

3.พัฒนา Backend สำหรับแก้ไขข้อมูสถานที่ให้บริการเตียง โดยใช้ Node.js ในการพัฒนา

3 ชั่วโมง

นายประธาน นาเวียง

Database

Task

เวลาที่กำหนด

ผู้รับผิดชอบ

1.ออกแบบ Database สำหรับเก็บข้อมูลของสถานที่ให้บริการเตียง, ผู้ให้บริการ และจำนวนเตียงที่ให้บริการ

3 ชัวโมง

นายปภัส เงาธัมมะสกุล

2.พัฒนา Database สำหรับเก็บข้อมูลของสถานที่ให้บริการเตียง, ผู้ให้บริการ และจำนวนเตียงที่ให้บริการ โดยใช้ MySQL ในการพัฒนา

3 ชั่วโมง

นายประธาน นาเวียง

 

เงื่อนไขในการผ่าน Acceptance Test

Frontend

Task 1 : ออกแบบหน้า UI ในส่วนของการเพิ่ม - ลดจำนวนเตียง

  • ต้องมีหน้า UI ของ 2 หน้าหลักครบ ได้แก่ หน้าการจัดการเตียง และหน้าแก้ไขข้อมูลสถานที่ให้บริการเตียง
  • หน้าการจัดการเตียงที่ออกแบบออกมา จะต้องมีการแสดงผลข้อมูลสถานที่ให้บริการเตียงที่ user เป็นผู้ให้บริการทั้งหมด
  • หน้าการจัดการเตียงที่ออกแบบออกมา จะต้องมี Element ปุ่มที่ใช้ในการกดเลือกสถานที่ให้บริการเตียงที่ต้องการแก้ไขข้อมูล
  • หน้าแก้ไขข้อมูลสถานที่ให้บริการเตียง จะต้องมีการแสดงผลจำนวนเตียงที่ให้บริการ ของสถานที่ให้บริการเตียงที่เลือกมา และสามารถพิมพ์ค่าเพื่อแก้ไขจำนวนเตียงได้

Task 2 : ทำการพัฒนาหน้าการจัดการเตียง โดยใช้ Vue.JS ในการพัฒนา

  • หน้าการจัดการเตียงที่ได้ทำการพัฒนาแล้วนั้นต้องมีรูปแบบ UI ตามที่ได้ออกแบบไว้ครบถ้วน
  • หน้าการจัดการเตียงที่ได้ทำการพัฒนาแล้วนั้น ต้องสามารถกดปุ่มเพื่อเลือกสถานที่ให้บริการเตียงที่จะทำการแก้ไขข้อมูลได้

Task 3 : ทำการพัฒนาหน้าแก้ไขข้อมูลสถานที่ให้บริการเตียง โดยใช้ Vue.JS ในการพัฒนา

  • หน้าแก้ไขข้อมูลสถานที่ให้บริการเตียงที่ได้ทำการพัฒนาแล้วนั้นต้องมีรูปแบบ UI ตามที่ได้ออกแบบไว้ครบถ้วน
  • หน้าแก้ไขข้อมูลสถานที่ให้บริการเตียงที่ได้ทำการพัฒนาแล้วนั้น ต้องสามารถพิมพ์ค่าเพื่อเพิ่ม - ลดจำนวนเตียงที่ให้บริการได้
  • หน้าแก้ไขข้อมูลสถานที่ให้บริการเตียงที่ได้ทำการพัฒนาแล้วนั้น ต้องสามารถกดปุ่มเพื่อยืนยันการแก้ไขข้อมูลสถานที่ให้บริการเตียงนั้นๆได้

 

Backend

Task 1: ออกแบบ backend เพื่อรองรับในส่วนของการเพิ่ม - ลดจำนวนเตียง

  • Backend ที่ได้ออกแบบมีรูปแบบการทำงานที่รองรับการเรียกใช้งานจากฝั่ง frontend
  • Backend ที่ออกแแบบออกมาต้องมีรูปแบบของ API ที่เข้าใจได้ง่าย เพื่อง่ายแก่การเรียกใช้งาน
  • Backend ที่ออกแบบมาจะต้องมีการรองรับฟังก์ชันทั้งหมด 2 ฟังก์ชันหลัก ได้แก่ การเข้าถึงข้อมูลสถานที่ให้บริการเตียงที่ user เป็นผู้ให้บริการ และการจัดเก็บและแก้ไขข้อมูลสถานที่ให้บริการเตียงที่ user เป็นผู้ให้บริการ

Task 2: พัฒนา Backend เพื่อรองรับการเข้าถึงข้อมูลสถานที่ให้บริการเตียงที่ user เป็นผู้ให้บริการ โดยใช้ Node.js ในการพัฒนา

  • สามารถเข้าถึงข้อมูลของสถานที่ให้บริการเตียงที่ user เป็นผู้ให้บริการใน database ได้
  • สามารถส่งข้อมูลสถานที่ให้บริการเตียงกลับไปยังฝั่งของ frontend ได้อย่างถูกต้อง

Task 3: พัฒนา Backend สำหรับแก้ไขข้อมูสถานที่ให้บริการเตียงที่ user เป็นผู้ให้บริการ โดยใช้ Node.js ในการพัฒนา

  • สามารถเข้าถึงและแก้ไขข้อมูลใน Database ของสถานที่ให้บริการเตียงที่ user เป็นผู้ให้บริการได้
  • สามารถนำข้อมูลการจองเตียงของ User จัดเก็บลง database ที่ใช้จัดเก็บข้อมูลของสถานที่ให้บริการเตียงที่ user เป็นผู้ให้บริการได้

 

Database

Task 1: ออกแบบ Database สำหรับเก็บข้อมูลของสถานที่ให้บริการเตียง, ผู้ให้บริการ และจำนวนเตียงที่ให้บริการ

  • Database ที่ออกแบบจะต้องเป็นในรูปแบบของ MySQL
  • Database ที่ออกแบบจะต้องมีการเก็บข้อมูลทั้งหมด 2 ส่วน ได้แก่ ข้อมูลสถานที่ให้บริการเตียง user ที่เป็นเจ้าของสถานที่ และจำนวนเตียงที่ให้บริการ

Task 2: พัฒนา Database สำหรับเก็บข้อมูลของสถานที่ให้บริการเตียง, ผู้ให้บริการ และจำนวนเตียงที่ให้บริการ โดยใช้ MySQL ในการพัฒนา

  • Database ที่พัฒนาขึ้นมาสามารถจัดเก็บข้อมูลที่จำเป็นทั้งหมดได้ ตามที่ออกแบบไว้
  • Database ที่พัฒนาขึ้นมาจะต้องมีการใช้ชนิดข้อมูล (Data Type) ที่เหมาะสมกับข้อมูลนั้น

 

Test Stratergies

ในการทดสอบระบบเพิ่ม - ลดจำนวนเตียงที่ให้บริการ จะมีการแบ่งรูปแบบของการทดสอบออกเป็น 3 ส่วน ดังนี้

Unit Test

  • Frontend

    ไม่มีการทำงานที่เป็นฟังก์ชันย่อยๆในส่วนนี้ จึงไม่มีในส่วนของ unit testing

  • Backend
    เป็นการทดสอบส่วนย่อยของระบบ โดยจะเน้นไปที่การทดสอบ Request ที่เข้ามา โดยที่เป็นส่วนสำคัญของระบบการเพิ่ม - ลดจำนวนเตียง โดยมี test case คือ สามารถทำการแก้ไข เพิ่ม - ลดจำนวนเตียงได้ (PUT: /bed/amount/125)

Component Test

  • Frontend

    เป็นการทดสอบว่าในแต่ละหน้าที่เกี่ยวข้องกับ feature ผู้ให้บริการเตียงเพิ่ม/ลดจำนวนเตียงที่ให้บริการได้นั้น มีส่วนประกอบ หรือ component ที่ควรจะอยู่ในหน้านั้น ๆ ครบถ้วนหรือไม่ โดยจะเน้นเฉพาะส่วนของ Frontend ที่เกี่ยวข้อง การทดสอบในส่วน Component test จะสามารถแบ่งออกได้เป็น 2 ส่วน ดังนี้

    1. การทำ Component test ในส่วนของหน้าการจัดการเตียง เป็นการทดสอบเพื่อดูว่าหน้าการจัดการเตียง มีส่วนประกอบต่างๆครบถ้วนหรือไม่ โดยในหน้าการจัดการเตียง จะมีส่วนประกอบที่ต้องมีอยู่ทั้งหมด 2 ส่วนประกอบ ได้แก่
      • กล่องแสดงรายละเอียดของสถานที่ให้บริการเตียง
      • ปุ่มสำหรับกดเพื่อเลือกสถานที่ให้บริการเตียงที่ต้องการแก้ไขข้อมูล
  • Backend
    การทดสอบ component test ของ feature การเพิ่มเพิ่ม - ลดจำนวนเตียง ของฝั่ง Backend มี test case คือ
    1. การทดสอบการ Update เพิ่ม - ลดจำนวนเตียงของสถานที่ได้

E2E Test

  • Frontend
    เป็นการทดสอบตัว feature ระบบเพิ่ม - ลดจำนวนเตียง ตั้งแต่เริ่มต้น จนจบ ซึ่งจะเริ่มตั้งแต่หน้า Login เข้าสู่ระบบ => หน้า main =>หน้าจัดการสถานที่ => หน้าแก้ไขสถานที่ จำนวนเตียง โดยมีจุดประสงค์เพื่อทดลองว่า feature นี้ สามารถใช้งานได้จริง โดยเริ่มจาก
    1. การกรอกข้อมูล email และ รหัสผ่านให้ถูกต้อง เพื่อลงชื่อเข้าใช้งานที่หน้า login
    2. กดปุ่ม ฉันต้องการลงเตียง ที่แถบ Nav bar เพื่อไปที่หน้า จัดการสถานที่
    3. กดปุ่ม แก้ไข ที่ช่องของสถานที่ ที่ต้องการแก้ไข เพื่อไปที่หน้า แก้ไขสถานที่ จำนวนเตียง
    4. กรอกเลขจำนวนเตียงให้ถูกต้อง
    5. กดปุ่มบันทึก
  • Backend
    เป็นการทดสอบการเรียก API ทั้งหมดที่เกี่ยวข้องกับ feature การเพิ่ม - ลด จำนวนเตียง ตั้งแต่การ Signin จนถึง การแก้ไขจำนวนเตียง ดังนี้
    • POST: user/signin
    • PUT: /bed/amount/51

Test Result

Unit test

  • Frontend

    ไม่มีการทำงานที่เป็นฟังก์ชันย่อยๆในส่วนนี้ จึงไม่มีในส่วนของ unit testing

  • Backend
    เป็นการทดสอบส่วนย่อยของระบบ โดยจะเน้นไปที่การทดสอบ Request ที่เข้ามา โดยที่เป็นส่วนสำคัญของระบบการเพิ่ม - ลดจำนวนเตียง โดยมี test case คือ สามารถทำการแก้ไข เพิ่ม - ลดจำนวนเตียงได้ (PUT: /bed/amount/125) => (Success)

Component test

  • Frontend

    ผลการทดสอบ frontend component test จะแบ่งออกเป็น 2 ส่วน เหมือนที่ได้ระบุไว้ใน test stratergies ดังนี้

    1. การทำ Component test ในส่วนของหน้าการจัดการเตียง
      • กล่องแสดงรายละเอียดของสถานที่ให้บริการเตียง
        ผลการทดสอบ : success (มี Element นี้อยู่จริง)
      • ปุ่มสำหรับกดเพื่อเลือกสถานที่ให้บริการเตียงที่ต้องการแก้ไขข้อมูล
        ผลการทดสอบ : success (มี Element นี้อยู่จริง)

  • Backend
    การทดสอบ component test ของ feature การเพิ่มเพิ่ม - ลดจำนวนเตียง ของฝั่ง Backend มี test case คือ
    • การทดสอบการ Update เพิ่ม - ลดจำนวนเตียงของสถานที่ได้ (Success)

 

E2E test

  • Frontend
    ผลการทดสอบของ feature การแก้ไขสถานที่ให้บริการเตียง ที่ฝั่ง Frontend มีเพียงผลลัพธ์การทดสอบเดียว คือ การแก้ไขสถานที่จองเตียง หลังจากกรอกข้อมูลที่ต้องการแก้ไขอย่างถูกต้อง: Success (สามารถแก้ไขข้อมูลสถานที่จองเตียงได้)
  • Backend

สรุปจำนวนครั้งในการ build แบบอัตโนมัติของทุกวันในสัปดาห์นี้

Frontend

Date

Build

Build success

Build failure

2022/04/11

0

0

0

2022/04/12

0

0

0

2022/04/13

0

0

0

2022/04/14

0

0

0

2022/04/15

0

0

0

2022/04/16

0

0

0

2022/04/17

5

4

1

Backend

Date

Build

Build success

Build failure

2022/04/11

0

0

0

2022/04/12

0

0

0

2022/04/13

0

0

0

2022/04/14

0

0

0

2022/04/15

0

0

0

2022/04/16

0

0

0

2022/04/17

5

3

2

Line change and Number commit of Group (wiki)

Student No.

Name

Line Change (%)

No. of Commit (%)

62070112

นายปภัส  เงาธัมมะสกุล

 16.63% 13.98%

62070113

นายประธาน นาเวียง

 16.74% 8.60%

62070134

นายพลัฏฐ์  วงศ์สิทธิพรรุ่ง

 16.66% 11.29%

62070139

นายพิชญะ  สิงห์มีศรี

 16.65% 15.59%

62070168

นายวิชยุตม์  ทวิชัยยุทธ

 16.66% 15.59%

62070215

นายอคิราภ์  สีแสนยง

 16.65% 34.95%

Code (ก่อนเพิ่ม feature)

Student No.

Name

Line Change (%)

No. of Commit (%)

62070112

นายปภัส  เงาธัมมะสกุล

2.68% (2,357)

12%

62070113

นายประธาน นาเวียง

4.15% (3,644)

7%

62070134

นายพลัฏฐ์  วงศ์สิทธิพรรุ่ง

18.09% (15,891)

12%

62070139

นายพิชญะ  สิงห์มีศรี

1.73% (1,523)

8%

62070168

นายวิชยุตม์  ทวิชัยยุทธ

2.04% (1,795)

14%

62070215

นายอคิราภ์  สีแสนยง

71.30% (62,665)

41%

Code (หลังเพิ่ม feature)

Student No.

Name

Line Change (%)

No. of Commit (%)

62070112

นายปภัส  เงาธัมมะสกุล

4.37% (2,357 => 4815) +

14.77%

62070113

นายประธาน นาเวียง

4.88% (3,644 => 5,380) +

9.66%

62070134

นายพลัฏฐ์  วงศ์สิทธิพรรุ่ง

14.40% (15,891)

9.66%

62070139

นายพิชญะ  สิงห์มีศรี

9.84% (1,523 => 10,861) +

7.95%

62070168

นายวิชยุตม์  ทวิชัยยุทธ

9.72% (1,795 => 10,728) +

17.05%

62070215

นายอคิราภ์  สีแสนยง

56.79% (62,665 => 63,544) +

40.91%

 

Coding with team

Trello คลิกที่นี่

 

⚠️ **GitHub.com Fallback** ⚠️