1. Trang chủ
  2. » Luận Văn - Báo Cáo

Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth

63 5 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 63
Dung lượng 6,52 MB

Cấu trúc

  • CHƯƠNG 1: TỔNG QUAN VỀ CÔNG TY TMA VÀ VỊ TRÍ TESTER (12)
    • 1.1. Giới thiệu tổng quát về công ty TMA Solutions Bình Định (12)
      • 1.1.2. Tầm nhìn và sứ mệnh (0)
      • 1.1.3. Giá trị cốt lõi (14)
    • 1.2. Tổng quan về vị trí Tester (15)
      • 1.2.1. Mô tả về vị trí Tester (15)
      • 1.2.2. Các kĩ năng cần có của một Tester (0)
      • 1.2.3. Cơ hội nghề nghiệp (16)
  • CHƯƠNG 2: CƠ SỞ LÝ THUYẾT (19)
    • 2.1. Tổng quan về kiểm thử phần mềm (19)
      • 2.1.1. Giới thiệu về kiểm thử phần mềm (19)
      • 2.1.2. Mục tiêu của kiểm thử (0)
      • 2.1.3. Quy trình phát triển phần mềm (0)
      • 2.1.4. Các nguyên tắc của kiểm thử phần mềm (0)
      • 2.1.5. Phân biệt Error/ Fault/ Failure (20)
      • 2.1.6. Phân biệt Verification & Validation (21)
      • 2.1.7. Phân biệt QA & QC (21)
    • 2.2. Vòng đời phát triển phần mềm (0)
      • 2.2.1. Giai đoạn phát triển phần mềm (22)
      • 2.2.2. Mô hình Water Fall (0)
      • 2.2.3. Mô hình V Model (0)
      • 2.2.4. Mô hình Agile (0)
      • 2.2.5. Phương pháp Scrum (25)
      • 2.2.6. Phương pháp Kanban (26)
    • 2.3. Các loại kiểm thử phần mềm (0)
      • 2.3.1. Manual Testing (27)
      • 2.3.2. Automation Testing (27)
    • 2.4. Các phương pháp kiểm thử phần mềm (27)
      • 2.4.1. Static Testing (27)
      • 2.4.2. Dynamic Testing (27)
      • 2.4.3. White Box Testing (28)
      • 2.4.4. Black Box Testing (28)
      • 2.4.5. Gray Box Testing (28)
    • 2.5. Cấp độ của kiểm thử (29)
      • 2.5.1. Unit Testing (29)
      • 2.5.2. Integration Testing (29)
      • 2.5.3. System Testing (29)
      • 2.5.4. Acceptance Testing (29)
    • 2.6. Kỹ thuật thiết kế Test case và vòng đời bug (30)
      • 2.6.1. Kỹ thuật Specification-based (30)
      • 2.6.2. Kỹ thuật Experience-based (30)
      • 2.6.3. Giải thích vòng đời bug (0)
      • 2.6.4. Báo cáo bug trên Jira (32)
      • 2.6.5. Test case là gì? (32)
      • 2.6.6. Các loại kiểm thử ứng dụng Mobile (0)
  • CHƯƠNG 3: TRIỂN KHAI DỰ ÁN (35)
    • 3.1. Tổng quan về ứng dụng (35)
      • 3.1.1. Giới thiệu về ứng dụng (35)
      • 3.1.2. Chức năng của ứng dụng (36)
    • 3.2. Triển khai dự án vHealth (36)
      • 3.2.1. Tài liệu đặc tả yêu cầu (36)
        • 3.2.1.1. Kết nối thiết bị đồng hồ thông minh 25b/25e (36)
        • 3.2.1.2. Theo dõi chỉ số sức khỏe (0)
        • 3.2.1.3. Cuộc gọi khẩn cấp SOS (41)
        • 3.2.1.4. Nhật ký triệu chứng (43)
        • 3.2.1.5. Theo dõi sức khoẻ người thân (0)
      • 3.2.2. Thiết kế và thực thi Test case (46)
        • 3.2.2.1. Test case kết nối thiết bị (46)
        • 3.2.2.2. Test case theo dõi chỉ số sức khoẻ (0)
        • 3.2.2.3. Test case cuộc gọi khẩn cấp SOS (47)
        • 3.2.2.4. Test case nhật ký triệu chứng (48)
        • 3.2.2.5. Test case theo dõi sức khoẻ người thân (0)
    • 3.3. Báo cáo Bug trên Jira (49)
      • 3.3.1. Kết nối thiết bị đồng hồ thông minh 25b/25e (49)
      • 3.3.2. Theo dõi chỉ số sức khỏe (0)
      • 3.3.3. Cuộc gọi khẩn cấp SOS (53)
      • 3.3.4. Nhật ký triệu chứng (55)
      • 3.3.5. Theo dõi sức khoẻ người thân (0)
    • 3.4. Kết quả (60)
    • 3.5. Kết luận (61)
  • TÀI LIỆU THAM KHẢO (63)

Nội dung

TỔNG QUAN VỀ CÔNG TY TMA VÀ VỊ TRÍ TESTER

Giới thiệu tổng quát về công ty TMA Solutions Bình Định

1.1.1 Giới thiệu về công ty

Hình 1: Công ty TMA Solutions Bình Định

TMA Solutions Bình Định là trung tâm phần mềm đầu tiên tại Thung lũng Sáng tạo Quy Nhơn, Công viên Sáng tạo TMA mang sứ mệnh trở thành trung tâm phát triển phần mềm và công nghệ cao hàng đầu tại miền Trung, góp phần quan trọng đưa Thung lũng sáng tạo Quy Nhơn trở thành một điểm đến của công nghệ 4.0 tại Việt Nam Công viên Sáng tạo TMA bao gồm Trung tâm Phát triển Phần Mềm, Xưởng Phần mềm, Trung tâm R&D, Trung tâm Khoa học Dữ liệu, Học viện Công Nghệ… với tổng diện tích sử dụng hơn 15,000m2 Dưới đây là mô tả tổng quan về lịch sử hình thành của Công ty TMA Solutions Bình Định:

 Năm 2017: TMA quyết định đầu tư xây dựng Công viên sáng tạo TMA Bình Định (TMA Innovation Park) tại Thung Lũng Sáng Tạo Quy Nhơn

- Thành lập TMA Bình Định

- Khởi công xây dựng Công viên Sáng tạo TMA Bình Định (TMA Innovation Park

- Thành lập Nhóm Data Science Group

- Tổ chức Ngày hội Công nghệ tại Đại học Quy Nhơn

Hình 2: Nhóm Data Science Group

- Khai trương Công viên Sáng tạo TMA Bình Định

- Khách hàng từ 6 nước (Mỹ, Úc, Pháp, Nhật Bản, Hàn Quốc, Singapore)

Hình 3: Công viên Sáng tạo TMA Bình Định

Qua các giai đoạn phát triển trên, TMA Bình Định đã xây dựng được một danh tiếng và thương hiệu đáng tin cậy trong lĩnh vực công nghệ thông tin và phần mềm. Với tầm nhìn và cam kết về chất lượng, công ty tiếp tục phát triển và đóng góp cho sự phát triển của ngành công nghệ thông tin Việt Nam.

1.1.2 Tầm nhìn và sứ mệnh

Tầm nhìn: Trở thành một trong những công ty hàng đầu về cung cấp giải pháp phần mềm tại Việt Nam và trong khu vực.

Sứ mệnh: Tôn trọng và mang đến cho khách hàng những sản phẩm, giải pháp phần mềm tốt nhất với chi phí hợp lí nhất Đồng thời xây dựng mối quan hệ tin cậy, uy tín, hợp tác cùng phát triển với các đối tác trong lĩnh vực công nghệ thông tin.

Sự cam kết (Commitment): Biến lời hứa thành hiện thực

Sự trung thực (Honesty): Trung thực với người khác và chính mình

Sự Tôn trọng (Respect): Đối xử với người khác theo cách bạn muốn đối xử

 Tài chính, Ngân hàng & Bảo hiểm

Quản lý tài sản (Wealth management, asset management), Thị trường vốn (Capital market), Quản lý vốn (Fund management), Quản lý đầu tư (Investment management), Phân tích tài chính (Financial analysis), Tài chính doanh nghiệp (Corporate finance), Quy trình bảo hiểm (Insurance process and workflow).

 Thương mại điện tử & Phân phối

Tư vấn, thiết kế, phát triển và triển khai hệ thống phần mềm trọn gói về thương mại điện tử, Quản lý phân phối sản phẩm, Phân tích hành vi khách hàng, Dự báo doanh số, POS (Point of Sale).

Phân tích thông tin bệnh nhân và sử dụng thuốc, Hệ thống thông tin y tế, Quản lý và phân tích dịch bệnh, Hồ sơ y tế điện tử, Hỗ trợ chuẩn đoán lâm sàng, Theo dõi sức khỏe người già 24/24, Quản lý người cách ly tại nhà, Phần mềm nhà thuốc.

Thư viện điện tử, Sách điện tử, Phân tích hành vi học online, Phân tích năng lực học sinh, Quản lý và điểm danh tự động, Quản lý trường học.

 Nông nghiệp & Chế biến thực phẩm

Phân tích và tối ưu năng suất chăn nuôi bò, Quản lý quy trình trồng trọt, Hệ thống thông tin nông nghiệp, Truy xuất nguồn gốc sản phẩm nông nghiệp, Tối ưu hiệu suất máy móc chế biến thực phẩm, Nhận dạng bệnh, Đánh giá chất lượng gỗ tự động.

Quản lý giao nhận, Quản lý tài sản, Quản lý xe và tàu biển, Phân tích giao thông.

Web site dịch vụ khách sạn và du lịch, Phần mềm dịch vụ khách sạn, Quản lý khách sạn tự động, POS cho nhà hàng, Trang vàng (yellow pages).

Mạng 3G/4G/5G, IoT, VoIP, Tổng đài số, Các ứng dụng quản lý mạng.

Tổng quan về vị trí Tester

1.2.1 Mô tả về vị trí Tester

Tester là những người kiểm tra chất lượng phần mềm, phát hiện ra các lỗi, sai sót hay bất cứ vấn đề nào có thể ảnh hưởng đến chất lượng phần mềm.

Tùy từng công ty mà tester sẽ có nhiều mảng như QA, QC, đặc biệt là Manual Tester và Automation Tester Manual Tester là người kiểm thử phần mềm một cách thủ công Automation Tester là kiểm thử tự động, được thực hiện bởi các phần mềm kiểm thử tựu động Tester sẽ đảm bảo chất lượng các phần mềm và thực hiện những công tác test bug trước khi giao kết quả cuối cùng cho khách hàng.

Nhiệm vụ của một Tester:

- Tìm kiếm các lỗi của hệ thống phần mềm

- Trực tiếp thẩm định, xác minh xem hệ thống phần mềm này có đáp ứng các yêu cầu kỹ thuật và yêu cầu nghiệp vụ hay không

- Hoàn thiện sản phẩm nhằm đáp ứng tối đa những yêu cầu đặt ra của khách hàng cả về mặt số lượng lẫn chất lượng

1.2.2 Các kĩ năng cần có của một Tester

 Kỹ năng phân tích Đây là kỹ năng mà hầu hết người đi làm cần trang bị cho bản thân Một Tester có kỹ năng phân tích sẽ giúp bạn có thể chia nhỏ một hệ thống phần mềm phức tạp thành các đơn vị nhỏ hơn để hiểu rõ hơn về từng yếu tố riêng lẻ, điều đó sẽ giúp ban nâng cao cả hiệu quả lẫn hiệu suất công việc để đạt kết quả tối đa.

Một Tester giỏi là người biết sẵn sàng chuyển đổi, học hỏi nhanh Các vấn đề có thể đột ngột phát sinh trong quá trình chạy phần mềm Chính vì vậy các Tester sẽ thường xuyên phải tự phân tích, học hỏi thông qua các hội nhóm hoặc đồng nghiệp của mình.

Kỹ năng giao tiếp hay còn được gọi là kỹ năng giải quyết mâu thuẫn Một Tester không thể làm việc độc lập mà thường phải làm việc nhóm hoặc trong các dự án hợp tác Chính vì thế kỹ năng giao tiếp tốt sẽ giúp ích cho bạn rất nhiều khi bạn chuyển tiếp thông tin và cung cấp báo cáo về các khâu kiểm tra bạn đã làm Nếu bạn không giỏi kỹ năng giao tiếp thì sẽ rất khó truyền đạt cho người khác hiểu ý tưởng mà bạn đang theo đuổi.

 Kỹ năng làm việc nhóm

Kỹ năng làm việc nhóm sẽ giúp các Tester dễ dàng kết nối với các thành viên khác, nhất là Developer Công việc của một Tester có thể hiểu là cầu nối giữa nhà phát triển phần mềm và người sử dụng phần mềm, trong đó, Developer đảm nhiệm hoàn thiện phần mềm và Tester sẽ giúp khách hàng an tâm hơn về sản phẩm.

Ngoài những kỹ năng chính trên một Tester còn cần phải có kỹ năng thiết kế, có kĩ năng tiếng Anh và có tính cách cẩn thận, tỉ mỉ, nhạy bén.

Từ một nghề còn khá xa lạ đối với các bạn trẻ, Tester đang dần trở thành một nghề

"HOT" tại Việt Nam với nhu cầu tuyển dụng ngày càng tăng cao Đây cũng được coi là một nghề nghiệp ổn định, đặc biệt là có cơ hội thăng tiến rõ ràng dựa vào năng lực và thâm niên.

Nghề Tester có nhu cầu tuyển dụng cao, cơ hội ổn định sự nghiệp lâu dài Đặc biệt cơ hội tăng tiến với những người có nhiều năm kinh nghiệm là càng kỳ cao Nghề không hề nhàm chán mới công nghệ luôn đổi mới Mỗi ngày các Tester sẽ phải làm việc với những phần mềm khác nhau, mang đến nhiều sự thú vị Nghề Tester quan trọng nhất là kinh nghiệm được tích lũy nhiều năm hơn là tuổi trẻ Càng có nhiều kinh nghiệm thì hiệu quả công việc càng cao và chất lượng phần mềm được kiểm thử càng tốt Nhu cầu tuyển dụng Tester trong những năm gần đây liên tục tăng Nếu khả năng Tiếng Anh tốt thì cơ hội để có những việc làm hấp dẫn càng lớn Không chỉ được làm việc tại các doanh nghiệp công nghệ, bạn còn có cơ hội được làm tại các công ty nước ngoài.

Không chỉ có cơ hội việc làm cực kỳ hấp dẫn mà mức lương cho các vị trí Tester hiện nay cũng được đánh giá là khá cao so với thị trường Ở từng vị trí thu nhập của Tester sẽ khác nhau:

Intern Tester hoặc Test thực tập thường rơi vào trường hợp các bạn sinh viên mới ra trường và hầu như chưa từng có kinh nghiệm chuyên môn ở vi trí Tester, vì vậy mức lương của Intern Tester thường dao động trong khoảng 3-6 triệu đồng/tháng.

Khi bạn đã có một số kinh nghiệm nhất định ở vị trí Fresher và được nhận chính thức sau khi kết thúc thời gian thử việc, bạn sẽ nhận được mức lương dao động trong khoảng 6-8 triệu đồng/tháng.

Junior Tester là những người đã có kinh nghiệm nhất định và trải qua nhiều dự án thực tế trong cương vị là một Tester, họ không chỉ hoàn thành nhiệm vụ mà còn có khả năng sáng tạo và luôn tìm cách cải tiến hiệu quả và hiệu suất công việc Junior Tester sẽ nhận được mức lương trong khoảng 8-15 triệu đồng/tháng.

Senior Tester không chỉ giỏi về chuyên môn mà còn có khả năng quản lý đội nhóm, phân chia công việc cho các thành viên, dẫn dắt họ nhằm đạt được những kết quả xa hơn trong công việc và xây dựng con đường sự nghiệp vững vàng SeniorTester nhận mức lương dao động trong khoảng 20-22 triệu đồng/tháng.

CƠ SỞ LÝ THUYẾT

Tổng quan về kiểm thử phần mềm

2.1.1 Giới thiệu về kiểm thử phần mềm

Kiểm thử phần mềm là quá trình thực thi 1 chương trình với mục đích tìm ra lỗi. Kiểm thử phần mềm đảm bảo sản phẩm phần mềm đáp ứng chính xác, đầy đủ và đúng theo yêu cầu của khách hàng, yêu cầu của sản phẩm đề đã đặt ra

2.1.2 Mục tiêu của kiểm thử

Mục đích của kiểm thử phần mềm là xác định các lỗi, lỗ hổng hoặc các yêu cầu còn thiếu so với yêu cầu thực tế.

2.1.3 Quy trình phát triển phần mềm

Hình 4: Quy trình phát triển phần mềm

Quy trình phát triển phần mềm tuân thủ theo các bước quan trọng cần thiết cho các nhà phát triển như phân tích yêu cầu và tài liệu đặc tả, phân tích và thiết kế hệ thống, thực hiện coding và unit test, kiểm thử và cuối cùng là cài đặt và bảo trì.

2.1.4 Các nguyên tắc của kiểm thử phần mềm

Hình 5: Nguyên tắc của kiểm thử phần mềm

 Kiểm thử cho thấy sự hiện diện của lỗi

Kiểm thử phần mềm chỉ có thể chứng minh được phần mềm có lỗi nhưng không thể chứng minh được phần mềm đó không còn lỗi Kiểm thử phần mềm giúp giảm xác suất lỗi chưa tìm thấy trong phần mềm

 Không thể kiểm thử cạn kiệt

Kiểm thử toàn bộ mọi thứ bao gồm cả điều kiện đầu vào và tiền điều kiện là không khả thi cho các trường hợp có rất nhiều giá trị đầu vào và hệ thống phức tạp

Kiểm thử nên được bắt đầu càng sớm càng tốt trong vòng đời phát triển phần mềm Lỗi càng được tìm ra sớm thì càng tiết kiệm được thời gian và chi phí fix lỗi

Lỗi thường tập trung ở các chức năng chính có liên quan nhiều đến các chức năng khác trong hệ thống Thông thường thì ta sẽ tìm được 80% lỗi của hệ thống trong 20% chức năng chính của hệ thống

 Nghịch lý thuốc trừ sâu

Nếu cùng một bộ test case đó ta test đi test lại nhiều lần sẽ bị nhờn và sẽ không tìm ra được bug mới

 Kiểm thử phụ thuộc vào ngữ cảnh

Kiểm thử là khác nhau trong các ngữ cảnh khác nhau

 Không có lỗi là sai lầm

Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm đã sẵn sàng tung ra thị trường mà bộ test case đó tạo ra chỉ nhằm mục đích kiểm tra xem hệ thống hoạt động có đúng với yêu cầu hay không chứ không nhằm mục đích tìm lỗi mới

2.1.5 Phân biệt Error/ Fault/ Failure

Error: Là hành động của con người dẫn đến kết quả sai.

Fault: Lỗi xảy ra khi làm sai các step, process, hoặc chuẩn bị dữ liệu.

Failure: Lỗi khi có kết quả sai lệch so với yêu cầu đặc tả, là sự khác biệt giữa kết quả thực tế trên màn hình và kết quả mong đợi của một thành phần, hệ thống hoặc service nào đó.

- Xác minh xem việc thực thi sản phẩm (product) đúng theo yêu cầu đã được chỉ định hay chưa?

- Trả lời cho câu hỏi: "Did we build the system right?"

- Ví dụ: xác nhận theo SRS, design thực hiện ở giai đoạn code review trong team, unit test, integration and system test

- Xác nhận, kiểm tra xem chức năng (function) cần thiết và mong đợi của khách hàng đã có trong sản phẩm hiện tại hay chưa?

- Trả lời cho câu hỏi: "Did we build the right system, appropriate, fix for use?"

- Ví dụ: xác nhận theo SRS, Requirement prototype xác nhận theo SRS review bởi customer, acceptance test, beta test, hỗ trợ

Hình 6: QA & QC a QA (Quality Assurance)

Là người chịu trách nhiệm đảm bảo chất lượng sản phẩm thông qua việc đưa ra quy trình làm việc cho các bên liên quan.

Vòng đời phát triển phần mềm

Là kỹ sư quản lý chất lượng Đây là những người trực tiếp làm kiểm tra cho các sản phẩm thực tế từng công đoạn của sản xuất.

Bảng 1: So sánh QA và QC Đảm bảo chất lượng (QA) Kiểm soát chất lượng (QC)

Là một quy trình được cân nhắc thận trọng nhằm cung cấp sự đảm bảo rằng phần mềm sẽ vượt qua được những yêu cầu về chất lượng

Kiểm soát chất lượng là quy trình kiểm tra sự hoàn thành của các yêu cầu về chất lượng phần mềm

Mục tiêu của QA là ngăn ngừa khiếm khuyết

Mục tiêu của QC là xác định và cải thiện các khiếm khuyết

QA không liên quan đến thực hiện chương trình

QC luôn luôn liên quan đến việc thực hiện chương trình Tất cả các thành viên trong nhóm có trách nhiệm đảm bảo chất lượng

Testing team chịu trách nhiệm cho QC

Verification (xác minh) Validation (xác nhận)

QA đảm bảo rằng bạn đang làm đúng điều phải làm

QC đảm bảo kết quả của những gì bạn đã làm là những gì bạn mong đợi

2.2 Vòng đời phát triển phần mềm

2.2.1 Giai đoạn phát triển phần mềm a Pha yêu cầu Ở pha này bộ phận phân tích yêu cầu sẽ gặp gỡ, trao đổi với khách hàng và làm rõ các chức năng, các yêu cầu mà khách hàng muốn xây dựng trong phần mềm của mình. b Pha đặc tả Đây là pha sẽ được thực hiện sau khi đã ghi nhận các yêu cầu của khách hàng về bộ liệu SRS gọi là “Tài liệu đặc tả”. c Pha thiết kế Ở pha này sau khi căn cứ vào tài liệu đặc tả, bộ phận thiết kế sẽ thiết kế đưa ra giao diện chung cũng như bộ phận lập trình sẽ thiết kế giao diện mức chi tiết theo từng chức năng của phần mềm. d Pha lập trình Ở pha này các lập trình viên (developer) sẽ lập trình xử lý chức năng, module theo yêu cầu được giao sau đó sẽ chuyển cho kiểm thử viên thực hiện kiểm tra các chức năng theo testcase được xây dựng dựa trên tài liệu đặc tả. e Pha kiểm thử Ở pha này, kiểm thử viên sẽ thực hiện kiểm tra các chức năng này theo các testcase được xây dựng Trong quá trình kiểm thử theo testcase nếu có phát sinh lỗi, kiểm thử viên sẽ thực hiện báo bug lỗi để lập trình viên xử lý chức năng đó fix lỗi. f Pha triển khai bảo trì

Trong quá trình sử dụng phần mềm của khách hàng, công ty phát triển phần mềm sẽ phải hỗ trợ, xử lý lỗi nếu có phát sinh trong quá trình sử dụng

2.2.2 Mô hình Water Fall

Trong mô hình thác nước, mỗi giai đoạn phải được hoàn thành trước khi giai đoạn tiếp theo có thể bắt đầu và không có sự chồng chéo trong các giai đoạn.

Hình 7: Mô hình Water Fall

Thu thập và phân tích yêu cầu: Tất cả các yêu cầu có thể có của hệ thống được phát triển đều được ghi lại trong giai đoạn này và được ghi lại trong tài liệu đặc tả yêu cầu.

Thiết kế hệ thống: Các đặc điểm kỹ thuật yêu cầu từ giai đoạn đầu tiên được nghiên cứu trong giai đoạn này và thiết kế hệ thống được chuẩn bị

Implement: Với đầu vào từ thiết kế hệ thống, hệ thống được phát triển đầu tiên trong các chương trình nhỏ gọi là đơn vị, được tích hợp trong giai đoạn tiếp theo Mỗi đơn vị được phát triển và kiểm tra chức năng của nó, được gọi là kiểm thử đơn vị.

Tích hợp và Kiểm thử: Tất cả các đơn vị được phát triển trong giai đoạn triển khai đều được tích hợp vào một hệ thống sau khi kiểm tra từng đơn vị

Triển khai hệ thống: Sau khi thử nghiệm chức năng và phi chức năng được thực hiện; sản phẩm được triển khai trong môi trường khách hàng hoặc tung ra thị trường.

Bảo trì: Có một số vấn đề xảy ra trong môi trường khách hàng Để khắc phục những vấn đề đó, các bản vá lỗi sẽ được phát hành.

Mô hình chữ V là một mô hình SDLC trong đó việc thực thi các quy trình diễn ra tuần tự theo hình chữ V Mô hình V là một phần mở rộng của mô hình thác nước và dựa trên sự liên kết của giai đoạn thử nghiệm cho từng giai đoạn phát triển tương ứng.

Phân tích yêu cầu: Giai đoạn này liên quan đến việc trao đổi chi tiết với khách hàng để hiểu những mong đợi và yêu cầu chính xác của họ

Thiết kế hệ thống: Thiết kế hệ thống sẽ có sự hiểu biết và chi tiết hóa thiết lập phần cứng và giao tiếp hoàn chỉnh cho sản phẩm

Thiết kế kiến trúc: Thông số kỹ thuật kiến trúc được hiểu và thiết kế trong giai đoạn này Thiết kế hệ thống được chia nhỏ hơn thành các mô-đun có chức năng khác nhau.

Thiết kế mô-đun: Trong giai đoạn này, thiết kế chi tiết bên trong cho tất cả các mô- đun hệ thống được chỉ định Điều quan trọng là thiết kế phải tương thích với các mô- đun khác trong kiến trúc hệ thống và các hệ thống bên ngoài đơn vị

Giai đoạn coding: Việc coding thực tế của các mô-đun hệ thống được thiết kế trong giai đoạn thiết kế được thực hiện trong giai đoạn coding Code trải qua nhiều lần review code trước khi bản dựng cuối cùng được đưa vào kho lưu trữ.

Unit Testing: Kiểm thử đơn vị được thiết kế trong giai đoạn thiết kế mô-đun được thực thi trên code trong giai đoạn xác thực này.

Integration Testing: Kiểm thử tích hợp được liên kết với giai đoạn thiết kế kiến trúc

System Testing: Kiểm thử hệ thống kiểm tra toàn bộ chức năng của hệ thống và giao tiếp của hệ thống đang được phát triển với các hệ thống bên ngoài

Acceptance Testing: Kiểm thử chấp nhận được liên kết với giai đoạn phân tích yêu cầu kinh doanh và liên quan đến việc kiểm tra sản phẩm trong môi trường người dùng.

Các loại kiểm thử phần mềm

2.3 Các loại kiểm thử phần mềm

Kiểm thử thủ công là một loại kiểm thử phần mềm trong đó người kiểm tra thực hiện chạy test case một cách thủ công mà không dùng bất cứ một công cụ tự động nào Bất kì ứng dụng nào cũng đều phải được kiểm tra một cách thủ công trước khi có thể thực hiện test tự động

Kiểm thử tự động là một quá trình xử lý tự động các bước thực hiện một test case.Kiểm thử tự động được thực hiện bởi phần mềm kiểm thử tự động - hay còn gọi làAutomation Testing Tool.

Các phương pháp kiểm thử phần mềm

Hình 11: Phương pháp kiểm thử Static Testing

Thử nghiệm tĩnh là loại kiểm tra trong thực đó code không được hiện Được thực hiện bằng tay hoặc bằng một công cụ Với thử nghiệm tĩnh, chúng ta cố gắng tìm ra lỗi, các lỗi code và mã độc tiềm ẩn trong ứng dụng phần mềm Static test bắt đầu sớm hơn trong vòng đời phát triển được gọi là thử nghiệm xác minh (verification testing)

Thử nghiệm động được thực hiện khi code đang ở chế độ thực thi Thử nghiệm động được thực hiện trong môi trường thực thi chạy chương trình ứng dụng Thử nghiệm dynamic còn được gọi là thử nghiệm xác nhận (Validation testing), đánh giá sản phẩm

Thử nghiệm động gồm hai loại: Kiểm tra chức năng và Kiểm tra phi chức năng.

Kiểm thử hộp trắng (While box test) là phương pháp thử nghiệm phần mềm, trong đó các thiết kế, cấu trúc giải thuật bên trong, và việc thực hiện các công việc đều được biết đến

Kiểm tra hộp đen (Black box testing) là một phương pháp kiểm thử phần mềm mà việc kiểm tra các chức năng của một ứng dụng không cần quan tâm vào cấu trúc nội bộ hoặc hoạt động của nó.

Gray Box Testing là một phương pháp kiểm thử phần mềm được kết hợp giữa Phương pháp Kiểm thử Black Box (hộp đen) và White Box (hộp trắng) Trong Kiểm thử Hộp xám, cấu trúc bên trong sản phẩm chỉ được biết một phần

Cấp độ của kiểm thử

Kiểm thử đơn vị là loại kiểm thử phần mềm trong đó các đơn vị/thành phần đơn lẻ của phần mềm được kiểm tra như: Hàm (Function), Lớp (Class), Phương thức (Method) Kiểm thử đơn vị được thực hiện trong quá trình phát triển ứng dụng Lỗi ở level này thường được fix ngay sau khi chúng được tìm ra mà không cần lưu lại và quản lý như các test level khác.

Kiểm thử tích hợp là loại kiểm thử trong đó các module phần mềm hay từng chức năng riêng lẻ được tích hợp logic và được kiểm tra theo nhóm Mỗi dự án phần mềm gồm nhiều modules, được code bởi nhiều người khác nhau, vì vậy kiểm thử tích hợp tập trung vào việc kiểm tra truyền dữ liệu giữa các module.

Kiểm thử hệ thống là kiểm thử toàn bộ chức năng và giao diện của hệ thống.

Kiểm thử chấp nhận là kiểm tra xem phần mềm đã thỏa mãn tất cả yêu cầu của khách hàng chưa? Và khách hàng có chấp nhận sản phẩm hay không?

Alpha test: Được thực hiện bởi các thành viên của tổ chức phát triển phần mềm nhưng không liên quan trực tiếp đến dự án (Thường là các thành viên của quản lý sản phẩm) Alpha test thực hiện test tại nơi sản xuất phần mềm, là một hình thức kiểm thử nội bộ, trước khi phần mềm được tiến hành kiểm thử Beta.

Beta test: Được thực hiện bởi người dùng cuối cùng (thường là khách hàng) Beta test thực hiện tại địa điểm của khách hàng, người dùng test hay sử dụng hệ thống trong môi trường riêng của họ - không phải nơi phát triển phần mềm.

Kỹ thuật thiết kế Test case và vòng đời bug

Nhóm kỹ thuật specification-based chỉ tập trung kiểm thử những yếu tố bên ngoài của hạng mục kiểm thử Chúng có thể là các đặc điểm kỹ thuật, thiết kế, cách vận hành bên ngoài,… Nhờ đó, tester có thể test chất lượng bên ngoài mà không làm hỏng cấu trúc bên trong phần mềm

Nhóm kỹ thuật này phụ thuộc vào hiểu biết và năng lực của tester Những kiến thức, kinh nghiệm của tester sẽ là cơ sở để thiết kế test case Do đó, chất lượng của các test case dựa trên kinh nghiệm sẽ hoàn toàn phụ thuộc vào tester

2.6.3 Giải thích vòng đời bug

- Tester tìm thấy bug/defect

- Gán trạng thái cho bug: New/Mới

- Chuyển bug sang cho Quản lý dự án để phân tích

- Quản lý dự án quyết định xem bug có hợp lệ không

- Nếu như lỗi không hợp lệ, trạng thái sẽ được chuyển thành "Rejected/Đã từ chối."

- Nếu lỗi không bị rejected thì bước tiếp theo là kiểm tra xem nó có nằm trong phạm vi không Giả sử chúng ta có một chức năng khác - chức năng email cho cùng một ứng dụng và bạn thấy có vấn đề với điều đó Nhưng nó không nằm trong scope của lần phát hành ứng dụng lần này, trạng thái của bug đó có thể chuyển thành

- Tiếp theo, người quản lý cần xác minh xem đã có bug nào tương tự đã được tìm ra trước đó hay chưa Nếu đã có rồi, bug này được chuyển trạng thái thành

- Nếu không có vấn đề gì phát sinh trong khi dev fix bug thì bug này được chuyển sang trạng thái là “In- progress/đang tiến hành”.

- Khi code được fixed Bug sẽ được gán trạng thái là “Fixed/đã sửa xong”

- Tiếp theo, tester sẽ test lại phần code vừa được sửa Nếu như các phần test cases liên quan đều passed thì bug đó được đóng lại hay được chuyển trạng thái thành

“Closed” Nếu các trường hợp kiểm thử thất bại một lần nữa, lỗi được mở lại/re- opened và lại được chuyển giao sang cho dev.

2.6.4 Báo cáo bug trên Jira

- Jira là một ứng dụng theo dõi và quản lý lỗi / vấn đề trong dự án, được phát triển bởi công ty phần mềm Atlassian của Australia Cách thức hoạt động của JIRA dựa vào trọng tâm là kết quả công việc, có thể sử dụng ngay và linh hoạt

- Báo cáo lỗi Jira tóm tắt các lỗi hoặc lỗi được báo cáo theo các số liệu nhất định.

- Tính năng cơ bản của Jira:

+ Quản lý, theo dõi tiến độ của dự án

+ Quản lý các tasks, bugs, cải tiến, tính năng mới hoặc bất kỳ vấn đề gì xảy ra + Tạo ra và lưu lại những bộ lọc có cấu hình cao (dynamic queries) xuyên suốt mọi vấn đề trong hệ thống; chia sẻ bộ lọc với người sử dụng khác, hoặc đăng ký và nhận được các kết quả qua hệ thống thư điện tử định kỳ

+ Xây dựng quy trình làm việc tương thích với yêu cầu của từng dự án

+ Bảng dashboard cung cấp cho mỗi người dùng một không gian riêng để xem mọi thông tin liên quan đến cá nhân

+ Cung cấp nhiều loại báo cáo thống kê với nhiều loại biểu đồ khác nhau phù hợp với nhiều loại hình dự án và đối tượng người dùng

Test cases là một tài liệu bao gồm một tập hợp các điều kiện hoặc hành động được thực hiện trên ứng dụng phần mềm và xác định kết quả mong muốn của nó Ở đây chúng ta thực hiện mô tả tài liệu với dữ liệu test, điều kiện tiên quyết và kết quả mong đợi.

2.6.6 Các loại kiểm thử ứng dụng Mobile

 Kiểm thử gián đoạn (Interrupt Testing)

Kiểm thử gián đoạn là một quá trình kiểm thử một ứng dụng điện thoại di động mà các chức năng có thể bị gián đoạn trong khi sử dụng các ứng dụng

 Kiểm thử tính sử dụng (Usability testing)

Kiểm thử tính sử dụng được sử dụng để kiểm thử các ứng dụng di động về khả năng sử dụng, tính linh hoạt và thân thiện.

Quá trình kiểm thử đảm bảo rằng các ứng dụng di động là dễ dàng để sử dụng và cung cấp những trải nghiệm của người dùng phù hợp cho khách hàng.

 Kiểm thử bảo mật (Security Testing)

Mục đích của việc kiểm thử bảo mật để kiểm tra dữ liệu của ứng dụng và an ninh mạng, kiểm tra dữ liệu của ứng dụng và an ninh mạng được đáp ứng theo yêu cầu.

 Kiểm thử hiệu năng (Performance Testing)

Quá trình kiểm thử được thực hiện bởi tester kiểm tra hiệu năng và hành động của các ứng dụng để đáp ứng những thiết bị di động khác nhau.

 Kiểm thử tương thích (Compatibility Testing) Định nghĩa: Là loại kiểm thử để xác định xem phần mềm có tương thích với các yếu tố khác của hệ thống hay không, ví dụ: Trình duyệt, Hệ điều hành hoặc phần cứng.

Mục tiêu: đánh giá xem phần mềm có hoạt động tốt hay không trong một trình duyệt, Hệ điều hành, phần cứng hoặc phần mềm cụ thể.

 Kiểm thử giao diện (Interface Testing) Định nghĩa: là loại kiểm thử phần mềm xác minh xem giao tiếp giữa hai hệ thống phần mềm khác nhau có được thực hiện chính xác hay không.

Một kết nối tích hợp hai thành phần được gọi là giao diện Giao diện này trong thế giới máy tính có thể là bất kỳ thứ gì như API, dịch vụ web, v.v Việc kiểm tra các dịch vụ hoặc giao diện kết nối này được gọi là Kiểm tra giao diện.

 Kiểm tra dịch vụ (Service Testing)

TRIỂN KHAI DỰ ÁN

Tổng quan về ứng dụng

3.1.1 Giới thiệu về ứng dụng vHealth là một ứng dụng chăm sóc sức khoẻ di động đầy đủ tính năng và tiện ích. Người dùng kết nối với thiết bị đồng hồ đeo tay để đo các chỉ số sức khoẻ như nhịp tim, huyết áp, nhiệt độ, giấc ngủ, bước đi,…sau đó đồng bộ dữ liệu lên điện thoại, điều này giúp người dùng dễ dàng theo dõi chỉ số sức khoẻ Có thể tìm kiếm tư vấn sức khoẻ trực tuyến từ các bác sĩ chuyên khoa, theo dõi các chỉ số sức khoẻ của mình, quản lý lịch khám bệnh và sử dụng thuốc một cách hiệu quả Bên cạnh đó, ứng dụng còn cung cấp thông tin về sức khoẻ để người dùng có thể cập nhật và học hỏi thêm về các vấn đề liên quan tới sức khoẻ Và với chức năng theo dõi người thân thì người dùng có thể theo dõi tình trạng sức khoẻ của người thân ở mọi lúc mọi nơi. Ứng dụng giúp người dùng có thể chủ động quản lý và cải thiện sức khoẻ của mình một cách dễ dàng và tiện lợi chỉ bằng một chiếc điện thoại và đồng hồ thông minh.

Hình 17: Giao diện ứng dụng vHealth

3.1.2 Chức năng của ứng dụng

Bảng 2: Phân loại chức năng của ứng dụng

STT Chức năng Ghi chú

1 Kết nối với thiết bị đồng hồ thông minh 25b/25e

2 Theo dõi chỉ số sức khoẻ

3 Cuộc gọi khản cấp SOS

5 Theo dõi sức khoẻ người thân

Triển khai dự án vHealth

3.2.1 Tài liệu đặc tả yêu cầu

3.2.1.1 Kết nối thiết bị đồng hồ thông minh 25b/25e

Bảng 3: Thông tin của chức năng Kết nối thiết bị đồng hồ thông minh 25b/25e

Tên chức năng Kết nối thiết bị 25b/25e

Mô tả Người dùng sử dụng chức năng ghép nối thiết bị mC25 để kết nối với đồng hồ 25b/25e.

Tác nhân Người dùng Điều kiện trước Người dùng đã đăng nhập trên app.

Người dùng sử dụng điện thoại đã bật Bluetooth trên điện thoại và có đồng hồ thông minh 25b/25e đã kích hoạt và đang trong trạng thái không kết nối với điện thoại khác. Điều kiện sau Kết nối thành công.

Các yêu cầu đặc biệt N/A

* Luồng kết nối thiết bị 25b/25e

Hình 18: Luồng kết nối thiết bị

Bảng 4: Mô tả luồng chính của chức năng Kết nối thiết bị đồng hồ thông minh

Hành động của tác nhân Tương tác của hệ thống Dữ liệu liên quan

- Nhấn quét thiết bị gần đây - Kiểm tra thiết bị gần đây - N/A

- Nhấn chọn thiết bị cần kết nối.

- Lưu thông tin thiết bị

* Tính năng tích hợp với thiết bị 25b/25e

Bảng 5: Tính năng tích hợp với thiết bị 25b/25e

1 Theo dõi chỉ số sức khỏe Nhịp tim, nồng độ oxy máu, nhiệt độ, bước đi, giấc ngủ.

2 Thông báo ứng dụng Cho phép nhận thông báo của một số ứng dụng trên điện thoại thông qua thiết bị.

3 Nhắc nhở vận động Cài đặt nhắc nhở người dùng vận động.

4 Cài đặt chỉ số đo tự động Cài đặt tự động đo với một số chỉ số:

- Nồng độ oxy máu(SpO2).

5 Ngôn ngữ trên thiết bị Chọn ngôn ngữ thiết bị thông qua ứng dụng:

6 Xóa dữ liệu thiết bị Xóa thông tin và dữ liệu trên thiết bị.

Hình 19: Giao diện kết nối thiết bị

3.2.1.2 Theo dõi chỉ số sức khỏe

Bảng 6: Thông tin của chức năng Theo dõi chỉ số sức khỏe

Tên chức năng Theo dõi chỉ số sức khỏe

Mô tả Chức năng cho phép người dùng xem thông tin chỉ số sức khỏe của mình, bao gồm các chỉ số:

- Độ bão hoà Oxy máu (SpO 2 )

Tác nhân Người dùng Điều kiện trước N/A Điều kiện sau Hiển thị dữ liệu sức khỏe.

Các yêu cầu đặc biệt N/A

* Luồng xem thông tin chỉ số sức khoẻ

Hình 20: Luồng theo dõi chỉ số sức khoẻ

Bảng 7: Mô tả luồng chính cho chức năng Theo dõi chỉ số sức khỏe

Hành động của tác nhân Tương tác của hệ thống Dữ liệu liên quan

- Người dùng chọn chỉ số sức khỏe cần theo dõi

- Hiển thị trang thông tin chỉ số sức khỏe.

* Trang chỉ số sức khỏe

Bảng 8: Mô tả chỉ số sức khoẻ

STT Các chỉ số sức khỏe Mô tả

Rate) - Thông tin chỉ số nhịp tim được thể hiện bằng biểu đồ, thông tin chỉ số nhịp tim cao nhất, thấp nhất, trung bình và mới nhất.

- Người dùng có thể thiết lập ngưỡng cảnh báo chỉ số nhịp tim ở phần cài đặt Ngưỡng cảnh báo.

- Người dùng có thể xem chi tiết ngưỡng nhịp tim được khuyến cáo khi vận động ở phần Nhịp tim khi vận động.

- Trong phần chỉ số nhịp tim chi tiết, người dùng có thể theo dõi lịch sử nhịp tim.

- Ở báo cáo thống kê người dùng có thể xem lại biểu đồ chỉ số nhịp tim theo từng tuần và từng tháng.

- Thông tin chỉ số huyết áp được thể hiện bằng biểu đồ, thông tin chỉ số nhịp tim cao nhất, thâp nhất, trung bình và mới nhất.

- Người dùng có thể thiết lập ngưỡng cảnh báo chỉ số nhịp tim ở phần cài đặt Ngưỡng cảnh báo.

- Trong phần chỉ số huyết áp chi tiết, người dùng có thể theo dõi lịch sử chỉ số huyết áp.

- Ở báo cáo thống kê người dùng có thể xem lại biểu đồ chỉ số huyết áp theo từng tuần và từng tháng.

(Blood Glucose) - Thông tin chỉ số đường huyết được thể hiện bằng biểu đồ, thông tin chỉ số nhịp tim cao nhất, thấp nhất, trung bình và mới nhất.

- Người dùng có thể thiết lập ngưỡng cảnh báo chỉ số nhịp tim ở phần cài đặt Ngưỡng cảnh báo.

- Trong phần chỉ số đường huyết chi tiết, người dùng có thể theo dõi lịch sử chỉ số đường huyết.

- Ở báo cáo thống kê người dùng có thể xem lại biểu đồ chỉ số đường huyết theo từng tuần và từng tháng.

4 Độ bão hoà Oxy máu (SpO2) - Thông tin chỉ số độ bão hoà oxy máu được thể hiện bằng biểu đồ, thông tin chỉ số nhịp tim cao nhất, thấp nhất, trung bình và mới nhất.

- Người dùng có thể thiết lập ngưỡng cảnh báo chỉ số nhịp tim ở phần cài đặt Ngưỡng cảnh báo.

- Trong phần chỉ số độ bão hoà oxy máu chi tiết, người dùng có thể theo dõi lịch sử chỉ số độ bão hoà oxy máu.

- Ở báo cáo thống kê người dùng có thể xem lại biểu đồ chỉ số độ bão hoà oxy máu theo từng tuần và từng tháng.

(Temperature) - Thông tin chỉ số nhiệt độ được thể hiện bằng biểu đồ, thông tin chỉ số nhịp tim cao nhất, thấp nhất, trung bình và mới nhất.

- Người dùng có thể thiết lập ngưỡng cảnh báo chỉ số nhịp tim ở phần cài đặt Ngưỡng cảnh báo.

- Trong phần chỉ số nhiệt độ chi tiết, người dùng có thể theo dõi lịch sử chỉ số nhiệt độ.

- Ở báo cáo thống kê người dùng có thể xem lại biểu đồ chỉ số nhiệt độ theo từng tuần và từng tháng.

6 Cân nặng (Weight) - Thông tin chỉ số cân nặng được thể hiện theo từng mốc thời gian Ngày, Tuần, Tháng, Năm.

- Người dùng có thể thêm dữ liệu thủ công trực tiếp tại màn hình chỉ số cân nặng.

7 Bước đi (Step) - Thông tin chỉ số bước đi (bao gồm lượng calo tiêu thụ) được thể hiện bằng biểu đồ hình tròn Thông tin được thể hiện bao gồm: Tỷ lệ hoàn thành mục tiêu,

Số bước đã đi, Quãng đường, Lượng calo tiêu thụ.

- Người dùng có thể thiết lập mục tiêu bước đi (bao gồm lượng calo tiêu thụ trong ngày).

- Trong phần chỉ số bước đi chi tiết, người dùng có thể theo dõi lịch sử số bước đi.

- Ở báo cáo thống kê người dùng có thể xem lại biểu đồ chỉ số bước đi theo từng tuần và từng tháng.

- Thông tin theo dõi thời lượng giấc ngủ thể hiện bằng biểu đồ bao gồm thông tin Tổng thời gian ngủ và Đánh giá chất lượng giấc ngủ.

- Người dùng có thể thiết lập mục tiêu thời lượng giấc ngủ theo hai mức Cơ bản và Nâng cao

- Ở báo cáo thống kê người dùng có thể xem lại biểu đồ theo dõi giấc ngủ theo từng tuần và từng tháng.

Hình 21: Giao diện theo dõi chỉ số sức khoẻ

3.2.1.3 Cuộc gọi khẩn cấp SOS

Người dùng chủ động gửi cảnh báo khi cảm thấy bản thân cần hỗ trợ kịp thời.

Bảng 9: Thông tin của chức năng Cuộc gọi khẩn cấp SOS

Tên chức năng Cuộc gọi khẩn cấp SOS

Mô tả Người dùng chủ động gửi cảnh báo tới người thân,

Operator, trợ lý y khoa thông qua một số kênh thông báo như thông báo ứng dụng, IVR/callbot.

Tác nhân Người dùng Điều kiện trước Đã đăng nhập ứng dụng vHealth. Đã mua gói cước. Điều kiện sau Thực hiện gửi cảnh báo thành công.

Các yêu cầu đặc biệt N/A

* Luồng cuộc gọi khẩn cấp SOS

Hình 22: Luồng cuộc gọi khẩn cấp SOS

Bảng 10: Mô tả luồng chính cho chức năng Cuộc gọi khẩn cấp SOS

Hành động của tác nhân

Tương tác của hệ thống Dữ liệu liên quan

- Bấm nút SOS, nếu người dùng đã mua gói cước thì sẽ kích hoạt tính năng Nếu người dùng không hủy bỏ trong vòng 5 giây.

- Gửi push notification và IVR call bot đến người thân.

- Gửi push notification, tạo SOS ticket trên Operator web để theo dõi quá trình xử lý của trợ lý y khoa.

- Gửi lệnh tạo ticket qua hệ thống của GoTrust để trợ lý y khoa xử lý.

- Dữ liệu sức khỏe: Chỉ số bất thường và các chỉ số đi kèm tại thời điểm ghi nhận bất thường

- Dữ liệu khác: Thông tin cá nhân, thông tin gói cước, thông tin địa điểm tại thời điểm ghi nhận bất thường

- Trợ lý y khoa kiểm tra trường hợp và thực hiện đổi trạng thái ticket.

- Trạng thái trên Operator web được cập nhập tương ứng.

- Nếu trạng thái cập nhập là Đã hủy, hoặc đã hoàn thành thì sẽ gửi push notification đến người thân.

- Nếu trợ lý y khoa đặt lịch tư vấn với bác sĩ sẽ thông báo đến người dùng.

- Sau khi kết thúc phiên tư vấn, gửi đánh giá đến người dùng

- Trạng thái xử lý ticket.

- Dữ liệu khác: Thông tin cá nhân, thông tin gói cước, thông tin địa điểm tại thời điểm ghi nhận bất thường.

Hình 23: Giao diện cuộc gọi khẩn cấp SOS

Chức năng Nhật ký triệu chứng cho người dùng theo dõi triệu chứng của bản thân.

Bảng 11: Thông tin của chức năng Nhật ký triệu chứng

Tên chức năng Nhật ký triệu chứng

Mô tả Người dùng theo dõi triệu chứng của bản thân: xem triệu chứng, thêm triệu chứng, thêm ghi chú, sửa, xóa triệu chứng trong ngày và quá khứ.

Tác nhân Người dùng Điều kiện trước Đã đăng nhập vào ứng dụng. Điều kiện sau Xem và cập nhật thông tin thành công.

Các yêu cầu đặc biệt N/A

* Luồng cập nhật thông tin cá nhân

Hình 24: Luồng nhật ký triệu chứng

Bảng 12: Mô tả luồng chính cho chức năng Nhật ký triệu chứng

Hành động của tác nhân Tương tác của hệ thống Dữ liệu liên quan

- Người dùng bấm xem triệu chứng.

- Người dùng thêm triệu chứng.

- Người dùng xóa triệu chứng.

- Người dùng sửa ghi chú(optional).

- Lưu thông tin người dùng đã cập nhật.

Hình 25: Giao diện nhật ký triệu chứng

3.2.1.5 Theo dõi sức khoẻ người thân

Bảng 13: Thông tin của chức năng Theo dõi sức khoẻ người thân

Tên chức năng Theo dõi sức khỏe người thân

Mô tả Người dùng theo dõi người được theo dõi chỉ số sức khỏe của người thân.

Tác nhân Người dùng Điều kiện trước Đã đăng nhập ứng dụng vHealth Đã theo dõi người thân. Điều kiện sau Hiển thị thông tin người thân thành công.

Các yêu cầu đặc biệt N/A

* Luồng theo dõi sức khỏe người thân

Hình 26: Luồng theo dõi sức khoẻ người thân

Bảng 14: Mô tả luồng chính cho chức năng Theo dõi sức khoẻ người thân

Hành động của tác nhân Tương tác của hệ thống Dữ liệu liên quan

- Người dùng nhấn xem thông tin chi tiết của người thân.

- Hiển thị thông tin sức khỏe của người thân: Chỉ số sức khỏe, lịch sử khẩn cấp, dữ liệu sức khỏe.

Hình 27: Giao diện theo dõi sức khoẻ người thân

3.2.2 Thiết kế và thực thi Test case

Link Test case: https://docs.google.com/spreadsheets/d/17TpShB5ZlbT7LfEPeNmHT_caIR7VcMAZ zuRUU85VL-I/edit?usp=sharing

3.2.2.1 Test case kết nối thiết bị

Hình 28: Test case kết nối thiết bị

3.2.2.2 Test case theo dõi chỉ số sức khoẻ

Hình 29: Test case theo dõi chỉ số sức khoẻ

3.2.2.3 Test case cuộc gọi khẩn cấp SOS

Hình 30: Test case cuộc gọi khẩn cấp SOS

3.2.2.4 Test case nhật ký triệu chứng

Hình 31: Test case nhật ký triệu chứng

3.2.2.5 Test case theo dõi sức khoẻ người thân

Hình 32: Test case theo dõi sức khoẻ người thân

Báo cáo Bug trên Jira

3.3.1 Kết nối thiết bị đồng hồ thông minh 25b/25e

Hình 33: Bug thiết bị trùng lặp khi quét

Hình 34: Minh chứng cho Bug thiết bị trùng lặp khi quét

Hình 35: Bug ứng dụng không kết nối lại khi người dùng di chuyển

Ngày đăng: 12/12/2023, 19:45

HÌNH ẢNH LIÊN QUAN

Hình 2: Nhóm Data Science Group - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 2 Nhóm Data Science Group (Trang 13)
Hình 16: Vòng đời bug - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 16 Vòng đời bug (Trang 31)
Hình 17: Giao diện ứng dụng vHealth - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 17 Giao diện ứng dụng vHealth (Trang 35)
Hình 18: Luồng kết nối thiết bị - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 18 Luồng kết nối thiết bị (Trang 37)
Bảng 6: Thụng tin của chức năng Theo dừi chỉ số sức khỏe - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Bảng 6 Thụng tin của chức năng Theo dừi chỉ số sức khỏe (Trang 38)
Hỡnh 21: Giao diện theo dừi chỉ số sức khoẻ - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
nh 21: Giao diện theo dừi chỉ số sức khoẻ (Trang 41)
Hình 23: Giao diện cuộc gọi khẩn cấp SOS - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 23 Giao diện cuộc gọi khẩn cấp SOS (Trang 43)
Hình 28: Test case kết nối thiết bị - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 28 Test case kết nối thiết bị (Trang 46)
Hỡnh 29: Test case theo dừi chỉ số sức khoẻ - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
nh 29: Test case theo dừi chỉ số sức khoẻ (Trang 47)
Hình 30: Test case cuộc gọi khẩn cấp SOS - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 30 Test case cuộc gọi khẩn cấp SOS (Trang 47)
Hình 31: Test case nhật ký triệu chứng - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 31 Test case nhật ký triệu chứng (Trang 48)
Hỡnh 32: Test case theo dừi sức khoẻ người thõn - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
nh 32: Test case theo dừi sức khoẻ người thõn (Trang 49)
Hình 33: Bug thiết bị trùng lặp khi quét - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 33 Bug thiết bị trùng lặp khi quét (Trang 49)
Hình 35: Bug ứng dụng không kết nối lại khi người dùng di chuyển <30 phút  và quay lại - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 35 Bug ứng dụng không kết nối lại khi người dùng di chuyển <30 phút và quay lại (Trang 50)
Hình 39: Bug Không hiển thị Báo cáo thống kê về giấc ngủ mặc dù có dữ liệu - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 39 Bug Không hiển thị Báo cáo thống kê về giấc ngủ mặc dù có dữ liệu (Trang 51)
Hình 40: Minh chứng cho Bug Không hiển thị Báo cáo thống kê về giấc ngủ mặc dù có dữ liệu - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 40 Minh chứng cho Bug Không hiển thị Báo cáo thống kê về giấc ngủ mặc dù có dữ liệu (Trang 52)
Hình 41: Bug ứng dụng không hiển thị chất lượng giấc ngủ trước 12 giờ trưa - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 41 Bug ứng dụng không hiển thị chất lượng giấc ngủ trước 12 giờ trưa (Trang 52)
Hình 42: Minh chứng cho Bug ứng dụng không hiển thị chất lượng giấc ngủ trước 12 giờ trưa - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 42 Minh chứng cho Bug ứng dụng không hiển thị chất lượng giấc ngủ trước 12 giờ trưa (Trang 52)
Hình 43: Bug không đánh dấu là đã đọc khi nhấp vào xem trường hợp SOS  lần đầu tiên - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 43 Bug không đánh dấu là đã đọc khi nhấp vào xem trường hợp SOS lần đầu tiên (Trang 53)
Hình 44: Minh chứng cho Bug không đánh dấu là đã đọc khi nhấp vào xem  trường hợp SOS lần đầu tiên - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 44 Minh chứng cho Bug không đánh dấu là đã đọc khi nhấp vào xem trường hợp SOS lần đầu tiên (Trang 53)
Hình 45: Bug người dùng SOS nhưng nhận thông báo rủi ro cao trên tổng đài  điện thoại - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 45 Bug người dùng SOS nhưng nhận thông báo rủi ro cao trên tổng đài điện thoại (Trang 54)
Hình 47: Bug Popup không tự động tắt sau 2 phút người dùng không thao tác - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 47 Bug Popup không tự động tắt sau 2 phút người dùng không thao tác (Trang 55)
Hỡnh 49: Bug Khụng gừ được dấu ở phần ghi chỳ - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
nh 49: Bug Khụng gừ được dấu ở phần ghi chỳ (Trang 55)
Hỡnh 50: Minh chứng cho Bug Khụng gừ được dấu ở phần ghi chỳ - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
nh 50: Minh chứng cho Bug Khụng gừ được dấu ở phần ghi chỳ (Trang 56)
Hình 53: Bug khi thêm nhiều triệu chứng, định dạng ghi chú không đúng như thiết kế - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 53 Bug khi thêm nhiều triệu chứng, định dạng ghi chú không đúng như thiết kế (Trang 57)
Hình 55: Bug mất chỉ số nhân sự trên màn hình quan trọng về sức khỏe ở chế độ xem của Người thân sau khi người dùng nhập BG - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 55 Bug mất chỉ số nhân sự trên màn hình quan trọng về sức khỏe ở chế độ xem của Người thân sau khi người dùng nhập BG (Trang 58)
Hình 57: Bug Người thân không nhận được thông báo trên tổng đài khi người dùng gửi yêu cầu - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 57 Bug Người thân không nhận được thông báo trên tổng đài khi người dùng gửi yêu cầu (Trang 59)
Hình 58: Minh chứng cho Bug Người thân không nhận được thông báo trên tổng đài khi người dùng gửi yêu cầu - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 58 Minh chứng cho Bug Người thân không nhận được thông báo trên tổng đài khi người dùng gửi yêu cầu (Trang 59)
Hình 59: Bug ngắt giao diện người dùng trên tab Danh bạ - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Hình 59 Bug ngắt giao diện người dùng trên tab Danh bạ (Trang 60)
Bảng 15: Kết quả sau khi thực hiện Manual testing - Nghiên cứu và triển khai manual testing trên ứng dụng chăm sóc sức khoẻ vhealth
Bảng 15 Kết quả sau khi thực hiện Manual testing (Trang 60)

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w