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

Báo Cáo Môn Học Kiểm Thử Phần Mềm Đề Tài Xây Dựng Website Cho Cửa Hàng Thuốc Thú Y.pdf

53 0 0
Tài liệu đã được kiểm tra trùng lặp

Đ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 53
Dung lượng 5,34 MB

Cấu trúc

  • CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM (5)
    • 1.1. Khái niệm (5)
    • 1.2. Các cấp độ kiểm thử phần mềm (5)
      • 1.2.1. Kiểm thử đơn vị (Unit Test) (6)
      • 1.2.2. Kiểm thử tích hợp (Integration Test) (6)
      • 1.2.3. Kiểm thử hệ thống (System Test) (7)
      • 1.2.4. Kiểm thử chấp nhận sản phẩm (Acceptance Test) (9)
    • 1.3. Kỹ thuật kiểm thử phần mềm (10)
      • 1.3.1. Kỹ thuật kiểm thử hộp đen (Black – box Testing) (10)
      • 1.3.2. Kỹ thuật kiểm thử hộp trắng (White – box Testing) (12)
  • CHƯƠNG 2: CÔNG CỤ KIỂM THỬ TỰ ĐỘNG (13)
    • 2.1. Giới thiệu về Selenium (13)
      • 2.1.1. Đặc điểm của Selenium (13)
      • 2.1.2. Các thành phần của Selenium (14)
      • 2.1.3. Cài đặt Selenium IDE trên trình duyệt Chrome (15)
      • 2.1.4. Cài đặt Selenium IDE trên trình duyệt Firefox (19)
      • 2.1.5. Ký hiệu (22)
      • 2.1.6. Ngôn ngữ viết (23)
      • 2.1.7. Ưu điểm (23)
      • 2.1.8. Nhược điểm (25)
    • 2.2. Các tổ chức chương trình chạy với công cụ (28)
    • 2.3. Áp dụng kiểm thử tự động với chức năng Đăng nhập (29)
  • CHƯƠNG 3: TÀI LIỆU YÊU CẦU (35)
    • 3.1. Các giai đoạn (35)
    • 3.2. Sơ đồ use case (36)
    • 3.4. Mô hình lớp (38)
      • 3.4.1. Mô hình thác nước (38)
      • 3.4.2. Mô hình kiến trúc MicroServices (39)
  • CHƯƠNG 4: KẾT QUẢ KIỂM THỬ (42)
    • 4.1. Bài toán thử nghiệm (42)
    • 4.2. Sự khác nhau giữa kịch bản kiểm thử tự động và kịch bản kiểm thử tự động (42)
    • 4.3. Kịch bản kiểm thử thủ công (43)
      • 4.3.1. Chức năng đăng nhập (43)
    • 4.4. Kịch bản kiểm thử tự động (44)
      • 4.4.1. Test Scenarios & Test Cases (44)
    • 4.5. Kết quả thử nghiệm (48)
      • 4.5.1. Chức năng đăng ký (48)
      • 4.5.2. Chức năng đăng nhập (49)
      • 4.5.3. Chức năng tìm kiếm (50)
      • 4.5.4. Giao diện (51)
  • TÀI LIỆU THAM KHẢO (53)

Nội dung

TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM

Khái niệm

Kiểm thử phần mềm là quá trình thực thi một hệ thống phần mềm để xác định xem phần mềm có đúng với đặc tả không và thực hiện trong môi trường như mong đợi hay không.

Mục đích của kiểm thử phần mềm là tìm ra lỗi chưa được phát hiện, tìm một cách sớm nhất và bảo đảm rằng lỗi sẽ được sửa.

Mục tiêu của kiểm thử phần mềm là thiết kế tài liệu kiểm thử một cách có hệ thống và thực hiện nó sao cho có hiệu quả, nhưng tiết kiệm được thời gian, công sức và chi phí.

Các cấp độ kiểm thử phần mềm

Hình 1.1- Bốn cấp độ cơ bản của kiểm thử phần mềm

1.2.1 Kiểm thử đơn vị (Unit Test)

Một đơn vị (Unit) là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được, ví dụ: các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method).

Kiểm thử đơn vị thường do lập trình viên thực hiện Công đoạn này cần được thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm.

Mục đích của kiểm thử đơn vị là bảo đảm thông tin được xử lý và kết xuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng xử lý của Unit Điều này thường đòi hỏi tất cả các nhánh bên trong Unit đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi.

Cũng như các mức kiểm thử khác, kiểm thử đơn vị cũng đòi hỏi phải chuẩn bị trước các ca kiểm thử (hay trường hợp kiểm thử) (test case) hoặc kịch bản (test script), trong đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong muốn sẽ xuất ra Các test case và test script được giữ lại để sử dụng sau này.

1.2.2 Kiểm thử tích hợp (Integration Test)

Kiểm thử tích hợp kết hợp các thành phần của một ứng dụng và kiểm thử như một ứng dụng đã hoàn thành Trong khi kiểm thử đơn vị kiểm tra các thành phần và Unit riêng lẻ thì kiểm thử tích hợp kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.

Kiểm thử tích hợp có hai mục tiêu chính là:

- Phát hiện lỗi giao tiếp xảy ra giữa các Unit.

- Tích hợp các Unit đơn lẻ thành các hệ thống con (gọi là subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh chuẩn bị cho kiểm thử ở mức hệ thống (system test).

Có 4 loại kiểm thử trong kiểm thử tích hợp như sau:

- Kiểm thử cấu trúc (Structure test): Kiểm thử nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng, chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình, chẳng hạn các lệnh và nhánh bên trong.

- Kiểm thử chức năng (Functional test): Kiểm thử chỉ chú trọng đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong, chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật.

- Kiểm thử hiệu năng (Performance test): Kiểm thử việc vận hành của hệ thống.

- Kiểm thử khả năng chịu tải (Stress test): Kiểm thử các giới hạn của hệ thống.

1.2.3 Kiểm thử hệ thống (System Test)

Mục đích của kiểm thử hệ thống là kiểm thử xem thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không.

Kiểm thử hệ thống kiểm tra cả các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật.

Kiểm thử hệ thống bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp thành công Thông thường loại kiểm thử này tốn rất nhiều công sức và thời gian Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống. Điểm khác nhau then chốt giữa kiểm thử tích hợp và kiểm thử hệ thống là kiểm thử hệ thống chú trọng các hành vi và lỗi trên toàn hệ thống, còn kiểm thử tích hợp chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau Thông thường ta phải thực hiện kiểm thử đơn vị và kiểm thử tích hợp để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện kiểm thử hệ thống.

Sau khi hoàn thành kiểm thử tích hợp, một hệ thống phần mềm đã được hình thành cùng với các thành phần đã được kiểm tra đầy đủ Tại thời điểm này, lập trình viên hoặc kiểm thử viên (Tester) bắt đầu kiểm thử phần mềm như một hệ thống hoàn chỉnh Việc lập kế hoạch cho kiểm thử hệ thống nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu. Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, kiểm thử hệ thống được thực hiện bởi một nhóm kiểm tra viên hoàn toàn độc lập với nhóm phát triển dự án để đảm bảo tính chính xác và khách quan.

Kiểm thử hệ thống thường có các loại kiểm thử sau:

- Kiểm thử chức năng (Functional test): Bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế.

- Kiểm thử khả năng vận hành (Performance test): Bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn,

- Kiểm thử khả năng chịu tải (Stress test hay Load test): Bảo đảm hệ thống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc) Stress test tập trung vào các trạng thái tới hạn, các "điểm chết", các tình huống bất thường như đang giao dịch thì ngắt kết nối (xuất hiện nhiều trong test thiết bị như POS, ATM),

- Kiểm thử cấu hình (Configuration test): Đảm bảo hệ thống hoạt động tương thích với các loại phần cứng khác nhau.

- Kiểm thử khả năng bảo mật (Security test): Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống.

- Kiểm thử khả năng phục hồi (Recovery test): Bảo đảm hệ thống có khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến.

1.2.4 Kiểm thử chấp nhận sản phẩm (Acceptance Test)

Kỹ thuật kiểm thử phần mềm

Mục tiêu của kiểm thử là phải thiết kế các trường hợp kiểm thử có khả năng cao nhất trong việc phát hiện nhiều lỗi với thời gian và công sức tối thiểu Do đó có thể chia các kỹ thuật kiểm thử thành hai loại:

- Kỹ thuật kiểm thử hộp đen (Black – box Testing) hay còn gọi là kỹ thuật kiểm thử chức năng (Functional Testing).

- Kỹ thuật kiểm thử hộp trắng (White – box Testing) hay còn gọi là kỹ thuật kiểm thử cấu trúc (Structural Testing).

1.3.1 Kỹ thuật kiểm thử hộp đen (Black – box Testing)

Kiểm thử hộp đen còn được gọi là kiểm thử hướng dữ liệu (data - driven) hay là kiểm thử hướng vào/ra (input/output driven).

Trong kỹ thuật này, người kiểm thử xem phần mềm như là một hộp đen.Người kiểm thử hoàn toàn không quan tâm đến cấu trúc và hành vi bên trong của chương trình Người kiểm thử chỉ cần quan tâm đến việc tìm các hiện tượng mà phần mềm không hành xử theo đúng đặc tả của nó Do đó, dữ liệu kiểm thử sẽ xuất phát từ đặc tả.

Như vậy, cách tiếp cận kiểm thử hộp đen tập trung vào các yêu cầu chức năng của phần mềm Kiểm thử hộp đen cho phép người kiểm thử xây dựng các nhóm giá trị đầu vào sẽ thực thi đầy đủ tất cả các yêu cầu chức năng của chương trình Kiểm thử hộp đen không thay thế kỹ thuật kiểm thử hộp trắng, nhưng nó bổ sung khả năng phát hiện các lớp lỗi khác với các phương pháp hộp trắng.

Kiểm thử hộp đen cố gắng tìm các loại lỗi sau:

- Các chức năng thiếu hoặc không đúng.

- Các lỗi cấu trúc dữ liệu trong truy cập cơ sở dữ liệu bên ngoài.

- Các lỗi khởi tạo hoặc kết thúc.

Không giống với kiểm thử hộp trắng được thực hiện sớm trong quá trình kiểm thử, kiểm thử hộp đen được áp dụng trong các giai đoạn sau của kiểm thử Vì kiểm thử hộp đen không để ý có chủ đích cấu trúc điều khiển, sự quan tâm tập trung trên miền thông tin Nếu người kiểm thử muốn sử dụng phương pháp này để tìm tất cả các lỗi trong chương trình thì điều kiện bắt buộc là phải kiểm thử tất cả các đầu vào, tức là mỗi một điều kiện đầu vào có thể có là một trường hợp kiểm thử Bởi vì nếu chỉ kiểm thử một số điều kiện đầu vào thì không đảm bảo được chương trình đã hết lỗi Vì thế, để đạt được mục tiêu kiểm thử, người ta đã áp dụng một số phương pháp kiểm thử hộp đen như: phân hoạch tương đương, phân tích giá trị biên.

1.3.2 Kỹ thuật kiểm thử hộp trắng (White – box Testing)

Kiểm thử hộp trắng hay còn gọi là kiểm thử hướng logic, cho phép kiểm tra cấu trúc bên trong của phần mềm với mục đích bảo đảm rằng tất cả các câu lệnh và điều kiện sẽ được thực hiện ít nhất một lần Người kiểm thử truy nhập vào mã nguồn chương trình và có thể kiểm tra nó, lấy đó làm cơ sở để hỗ trợ việc kiểm thử.

1.3.2.1 Kiểm thử đường dẫn cơ sở

Kiểm thử đường dẫn cơ sở là một kỹ thuật kiểm thử hộp trắng do Tom McCabe đề xuất Phương pháp đường dẫn cơ sở cho phép người thiết kế trường hợp kiểm thử thực hiện phép đo độ phức tạp logic của thiết kế thủ tục và sử dụng phép đo này như một chỉ dẫn cho việc thiết kế một tập cơ sở các đường dẫn thực hiện.Những trường hợp kiểm thử được suy diễn để thực hiện tập cơ sở Các trường hợp kiểm thử đó được đảm bảo để thực hiện mỗi lệnh trong chương trình ít nhất một lần trong quá trình kiểm thử.

CÔNG CỤ KIỂM THỬ TỰ ĐỘNG

Giới thiệu về Selenium

Selenium là một bộ công cụ chuyên dụng trong kiểm thử tự động opensource dành cho các ứng dụng web, cũng như hỗ trợ hoạt động trên các trình duyệt có nền tảng khác nhau như Mac, Linux, Windows, Với Selenium thì bạn hoàn toàn có thể viết các test script bằng nhiều ngôn ngữ lập trình khác nhau như: Java, PHP, C#, Ruby hoặc Python

Selenium được sử dụng để có thể automate cho các thao tác với trình duyệt hoặc dễ hiểu hơn là nó hỗ trợ giả lập lại các tương tác nằm trên trình duyệttương tự như một người dùng thực thụ Chính vì thế, bạn có thể lập trình để có thể bật tự động các trình duyệt, để open một link, input cho dữ liệu, upload, download dữ liệu từ web page hoặc thậm chí get info page.

Mã nguồn mở Phải nói điểm này là điểm mạnh nhất của Selenium khi so sánh với các test tool khác Vì là mã nguồn mở nên chúng ta có thể sử dụng mà không phải lo lắng về phí bản quyền hay thời hạn sử dụng.

Cộng đồng hỗ trợ Vì là mã nguồn mở nên Selenium có một cộng đồng hỗ trợ khá mạnh mẽ Bên cạnh đó, Google là nơi phát triển Selenium nên chúng ta hoàn toàn có thể yên tâm về sự hổ trợ miễn phí khi có vấn đề về Selenium.Tuy nhiên, đây cũng là một điểm yếu của Selenium Cơ bản vì là hàng miễn phí, cộng đồng lại đông nên một vấn đề có thể nhiều giải pháp, và có thể một số giải pháp là không hữu ích Mặc khác,chúng ta không thể hối thúc hay ra deadlines cho sự hỗ trợ.

Selenium hỗ trợ nhiều ngôn ngữ lập trình.

Selenium hỗ trợ chạy trên nhiều OS khác nhau với mức độ chỉnh sửa script hầu như là không có Thực sự thì điều này phụ thuộc phần lớn vào khả năng viết script của chúng ta.

Chạy test case ở backround Khi chúng ta thực thi một test scrpit, chúng ta hoàn toàn có thể làm việc khác trên cùng một PC Điều này hỗ trợ chúng ta không cần tốn quá nhiều tài nguyên máy móc khi chạy test script.

Không hỗ trợ Win app Selenium thực sự chỉ hỗ trợ chúng ta tương tác với Browser mà không hỗ trợ chúng ta làm việc với các Win app, kể cả Windialog như Download/Upload – ngoại trừ Browser Alarm Vậy nên, để xử lý các trường hợp cần tương tác với hệ thống hay một app thứ ba, cần một hay nhiều thư viện khác như AutoIt hay Coded UI.

2.1.2 Các thành phần của Selenium

Selenium là một trong những khái niệm chung để miêu tả một phần dụng trong automation Mà ở đó, mỗi loại trong nó sẽ đáp ứng được các yêu cầu testing khác nhau. Còn về cơ bản thì Selenium bao gồm 4 thành phần chính là:

- Selenium IDE (IDE là từ viết tắt của Integrated DeveloperEnvironment): là một plug-in nằm trên trình duyệt Fire-fox, ta có thể sử dụng để record và play lại các thao tác đó dựa theo một quy trình hay một test case nào đó

- Selenium RC: Selenium Remote Control, Selenium server sẽ khởi chạy và tương tác với các trình duyệt web

- WebDriver: Selenium WebDriver có nhiệm vụ gửi lệnh khởi chạy rồi thực hiện tương tác trực tiếp với các trình duyệt mà không cần thông qua bất cứ server nhưSelenium RC

- Grid: Selenium Hub được sử dụng để khởi chạy nhiều các test thông qua các máy cũng như các trình duyệt khác nhau tại cùng một thời điểm nhất định Selenium team đã quyết định gộp Selenium RC và WebDriver lại với nhau để có thể khởi tạo ra các Selenium 2 với các tính năng mạnh mẽ hơn và hiện nay thì hầu hết các Selenium Project đều sử dụng chúng.

2.1.3 Cài đặt Selenium IDE trên trình duyệt Chrome

Bước 1: Ở trình duyệt Chrome truy cập đường dẫn: https://www.selenium.dev/downloads/

Bước 2: Chọn trình duyệt cần add Selenium IDE

Bước 3: Click button Thêm vào Chrome

Trên trình duyệt sẽ hiển thị Popup

Bước 4: Click button Thêm tiện ích

Công cụ Selenium IDE sau khi được add thành công sẽ hiển thị trên thanh tìm kiếm

Giao diện của Selenium IDE

2.1.4 Cài đặt Selenium IDE trên trình duyệt Firefox

Bước 1: Ở trình duyệt Firefox truy cập đường dẫn: https://www.selenium.dev/downloads/

Bước 2: Chọn trình duyệt cần add Selenium IDE

Bước 3: Click button Add to Firefox

Trên trình duyệt sẽ hiển thị Popup

Công cụ Selenium IDE sau khi được add thành công sẽ hiển thị trên thanh tìm kiếm

Giao diện của Selenium IDE

- Base URL: Đây là nơi điền URL của ứng dụng web được tiến hành kiểm thử.

- Thanh trượt : Đây là thanh trượt nằm dưới nhãn trên màn hình Dùng để điều chỉnh tốc độ nhanh/chậm khi chạy test case.

- Nút : Chạy tất cả các test case.

- Nút : Chỉ chạy test case được chọn.

- Nút : Tạm dừng một test case đang chạy

- Nút : Bỏ qua một test case khi nó đã bị tạm dừng

- Nút : Nút thu được sử dụng để thu các test case qua những thao tác bạn tác động đến trang web cần kiểm thử.

- Text box Target: Kết quả mong đợi của dòng lệnh

- Text box Value: Giá trị đầu vào của dòng lệnh

Bảng Selenium sẽ lưu lại các lệnh, kết quả mong đợi và giá trị đầu vào của các lệnh.

- Khu vực phía dưới textbox Value sẽ hiển thị các log của Selenium trong khi các test case chạy Nếu có một test case bị thất bại Selenium IDE sẽ log một lỗi.

- Log: Hiển thị thông báo lỗi và các bước được thực thi trong quá trình chạy một test case tự động Ngay cả khi ta không chọn tab log, các thông tin này vẫn hiển thị Các thông tin này giúp ích cho nhân viên kiểm thử cũng như nhân viên lập trình trong quá trình tìm ra nguyên nhân lỗi đã phát hiện trong test case (nếu có).

- UI-Element và Rollup: Tính năng nâng cao của Selenium IDE

 Các test case luôn luôn có điểm bắt đầu Trong ngữ cảnh của Selenium, điều này có nghĩa là mở một trang nào đó để bắt đầu luồng công việc.

 Các test case có thể không cần dựa trên những test case khác để chạy.

 Một test case chỉ nên dùng để kiểm thử một chức năng nhỏ xác định trong một thời gian xác định.

Sử dụng ngôn ngữ Java, Python,

- Hỗ trợ nhiều ngôn ngữ lập trình

Selenium hỗ trợ nhiều ngôn ngữ lập trình khác nhau như Java, C#, Python, Ruby, JavaScript (Node.js), và Kotlin, cho phép các lập trình viên sử dụng ngôn ngữ mà họ quen thuộc và thoải mái nhất.

Các tổ chức chương trình chạy với công cụ

Phần mềm (có thao tác được trên chức năng)

(1): Link URL của trang website

(2): Nút Record (bắt đầu ghi hình website)

(3): Run All Test: Chạy lại tất cả chức năng

(4): Thanh chỉnh tốc độ chạy

Áp dụng kiểm thử tự động với chức năng Đăng nhập

Bước 1: Mở công cụ Selenium IDE, click chọn Create a new Project

Bước 2: Đặt tên cho project

Bước 3: Gán đường dẫn vào URL, sau đó nhấn REC để bắt đầu ghi hình

Lúc này một cửa sổ trang mới sẽ hiển thị và người dùng sẽ thao tác trên cửa sổ mới Các bước sẽ được ghi lại và hiển thị trong phần Command

Bước 4: Click button Run all test để các chức năng được thực hiện lại

Sau khi chạy xong công cụ sẽ hiển thị log

TÀI LIỆU YÊU CẦU

Các giai đoạn

Tên bài tập Nội dung Thời gian

Lab 1 Test Scenario and Test Case (Manual Testing) 19/03/2024 Lab 1.2 Test Scenario and Test Case (Đề tài nhóm) 2/4/2024 Lab 2 Unit Test and Integrated with C# 9/4/2024

Lab 2.2 (B1) Unit Test and Integrated with C# (Đề tài nhóm –

Lab 2.2 (B2) Unit Test and Integrated with C# (Đề tài nhóm –

Viết báo cáo Viết báo cáo đề tài 14/5/2024

Sơ đồ use case

Mô hình lớp

3.4.2 Mô hình kiến trúc MicroServices

Kiến trúc microservices là một phương pháp tiếp cận trong việc phát triển phần mềm, trong đó một ứng dụng được chia nhỏ thành các dịch vụ độc lập, nhỏ gọn và dễ quản lý, mỗi dịch vụ thực hiện một chức năng cụ thể Các dịch vụ này giao tiếp với nhau thông qua các giao thức nhẹ như HTTP/REST hoặc gRPC.

- Tính linh hoạt và khả năng mở rộng.

 Các nhóm phát triển có thể làm việc đồng thời trên các microservice khác nhau mà không ảnh hưởng lẫn nhau, giúp tăng tốc độ phát triển.

 Mỗi microservice có thể được triển khai, nâng cấp hoặc vá lỗi một cách độc lập, giúp giảm thiểu rủi ro khi triển khai.

 Các microservice có thể được mở rộng riêng lẻ tùy theo nhu cầu, giúp tối ưu hóa tài nguyên và chi phí.

- Khả năng chịu lỗi cao.

 Nếu một microservice gặp sự cố, các dịch vụ khác vẫn có thể hoạt động bình thường, giảm thiểu ảnh hưởng đến toàn bộ hệ thống.

 Dễ dàng cô lập và khắc phục sự cố cho từng microservice mà không cần tắt toàn bộ hệ thống.

- Lựa chọn công nghệ đa dạng.

 Có thể sử dụng các ngôn ngữ lập trình, framework và công nghệ khác nhau cho từng microservice, giúp tận dụng tối đa các ưu điểm của từng công nghệ.

- Bảo trì và nâng cấp dễ dàng.

 Vì các microservice nhỏ gọn và thực hiện các chức năng cụ thể, việc bảo trì và nâng cấp từng phần trở nên dễ dàng hơn.

 Các microservice có thể được phát triển và triển khai theo các chu kỳ khác nhau, giúp linh hoạt trong quản lý dự án.

 Tính năng DevOps tốt hơn

 Dễ dàng tích hợp các quy trình tự động hóa như CI/CD, giúp tăng tốc độ triển khai và giảm thiểu lỗi phát sinh từ quá trình thủ công. b Nhược điểm

- Phức tạp trong quản lý.

 Quản lý nhiều microservice đòi hỏi kiến thức về hệ thống phân tán và các công cụ quản lý như Kubernetes, Docker Swarm.

 Cần cơ chế đồng bộ và phối hợp giữa các microservice để đảm bảo dữ liệu nhất quán và hiệu quả.

- Giao tiếp và hiệu suất.

 Các microservice phải giao tiếp qua mạng, có thể dẫn đến độ trễ và cần phải thiết kế API hiệu quả.

 Cần thêm lớp trung gian như API Gateway, Service Mesh để quản lý và tối ưu giao tiếp giữa các microservice.

 Phải bảo vệ nhiều microservice, tăng thêm độ phức tạp trong việc quản lý bảo mật và xác thực.

 Mỗi microservice có thể trở thành một điểm yếu nếu không được bảo mật đúng cách.

 Mỗi microservice quản lý dữ liệu riêng của mình, dẫn đến thách thức trong việc duy trì tính nhất quán và tích hợp dữ liệu.

 Khó khăn trong việc thực hiện các giao dịch bao gồm nhiều microservice, đòi hỏi các cơ chế phức tạp như SAGA pattern.

- Tăng chi phí và yêu cầu hạ tầng.

 Cần đầu tư vào hạ tầng và công cụ quản lý như container orchestration (Kubernetes), monitoring (Prometheus, Grafana).

 Chi phí vận hành và bảo trì có thể tăng do yêu cầu hạ tầng và nhân lực chuyên môn cao.

KẾT QUẢ KIỂM THỬ

Bài toán thử nghiệm

- Link website: https://medicine-frontend-app.onrender.com/

- Chức năng đăng nhập: Chức năng này là một chức năng đăng nhập thuần túy vào các ứng dụng web thông thường giống như các ứng dụng khác như yahoo, google, các forum Các yếu tố cần kiểm tra:

 Nếu đăng nhập đúng email và mật khẩu thì tải đến trang chủ của web.

 Nếu đăng nhập sai tên hoặc mật khẩu thì đưa ra thông báo: “Email hoặc mật khẩu đăng nhập không đúng”.

 Nếu nhập thiếu email thì đưa ra thông báo: “Vui lòng nhập Email!”.

 Nếu nhập thiếu mật khẩu thì đưa ra thông báo: “Vui lòng nhập mật khẩu”.

 Nếu nhập mật khẩu không đủ yêu cầu thì đưa ra thông báo: “Vui lòng nhập mật khẩu đúng định dạng.

Sự khác nhau giữa kịch bản kiểm thử tự động và kịch bản kiểm thử tự động

Trước khi thực hiện kiểm thử ứng dụng, cần phải nói thêm về sự khác nhau giữa một kịch bản kiểm thử thủ công và một kịch bản kiểm thử tự động.

Với kiểm thử thủ công, kịch bản kiểm thử chức năng thông thường được chia thành ba phần chính:

Với kiểm thử tự động, có hai phần chính mà ta cần quan tâm là test case và dữ liệu kiểm thử Trong đó:

- Test case: Có thể là một lớp hoặc một hàm hoặc một lớp ghi lại một chuỗi sự kiện mà ta thao tác với ứng dụng cần kiểm thử Khác với khái niệm test case khi thực hiện kiểm thử thủ công là cứ mỗi giá trị đầu vào khác nhau thì sẽ tạo thành một testcase.

- Dữ liệu kiểm thử: Là dữ liệu nhập vào để kiểm thử.

Kịch bản kiểm thử thủ công

- Ở chức năng đăng nhập, ba phần chính cần kiểm tra là:

 Giao diện: Kiểm thử các yếu tố giao diện chung như kiểm tra giao diện theo thiết kế, kiểm tra việc bị vỡ giao diện hay không, các giá trị mặc định của textbox.

 Chức năng: Có bốn trường hợp chức năng cần chính cần kiểm thử: o Kiểm tra đăng nhập thành công với Email/ Mật khẩu hợp lệ. o Kiểm tra đăng nhập không thành công khi sử dụng sai Email/ Mật khẩu. o Kiểm tra thông báo khi không nhập Email. o Kiểm tra thông báo khi không nhập mật khẩu. o Kiểm tra đăng nhập khi nhập mật khẩu không đủ yêu cầu.

Kịch bản kiểm thử tự động

SCENARIO 1: ĐĂNG KÝ THÀNH CÔNG

- MÔ TẢ: ĐĂNG NHẬP VỚI EMAIL VÀ PASSWORD HỢP LỆ.

- KẾT QUẢ MONG ĐỢI: ĐĂNG NHẬP THÀNH CÔNG, CHUYỂN ĐẾN TRANG CHỦ.

SCENARIO 2: ĐĂNG KÝ THẤT BẠI

- MÔ TẢ: ĐĂNG NHẬP VỚI MẬT KHẨU KHÔNG HỢP LÊ.

- KẾT QUẢ MONG ĐỢI: HIỂN THỊ THÔNG BÁO LỖI "VUI LÒNG NHẬP MẬT KHẨU ĐÚNG ĐỊNH DẠNG".

SCENARIO 3: ĐĂNG NHẬP THÀNH CÔNG

- MÔ TẢ: ĐĂNG NHẬP VỚI MẬT KHẨU HỢP LÊ.

- KẾT QUẢ MONG ĐỢI: “ĐĂNG NHẬP THÀNH CÔNG, CHUYỂN ĐẾN TRANG GIAO DIỆN".

SCENARIO 4: ĐĂNG NHẬP THẤT BẠI

- MÔ TẢ: ĐĂNG NHẬP VỚI MẬT KHẨU KHÔNG HỢP LỆ.

- KẾT QUẢ MONG ĐỢI: HIỂN THỊ THÔNG BÁO LỖI "VUI LÒNG NHẬP MẬT KHẨU ĐÚNG ĐỊNH DẠNG".

SCENARIO 5: TÌM KIẾM VỚI TỪ KHÓA HỢP LỆ

- MÔ TẢ: TÌM KIẾM VỚI TỪ KHÓA CÓ KÝ TỰ ĐẶC BIỆT "đà lạt ".

 Nhập từ khóa "đà lạt" vào ô tìm kiếm.

- KẾT QUẢ MONG ĐỢI: HIỂN THỊ DANH SÁCH KẾT QUẢ LIÊN QUAN, BỎ QUA KÝ TỰ ĐẶC BIỆT.

SCENARIO 6: TÌM KIẾM VỚI TỪ KHÓA KHÔNG HỢP LỆ

- MÔ TẢ: TÌM KIẾM VỚI TỪ KHÓA CÓ KÝ TỰ ĐẶC BIỆT "cà phê ".

 Nhập từ khóa "cà phê" vào ô tìm kiếm.

- KẾT QUẢ MONG ĐỢI: HIỂN THỊ DANH SÁCH KẾT QUẢ LIÊN QUAN, BỎQUA KÝ TỰ ĐẶC BIỆT.

SCENARIO 7: HIỂN THỊ ĐÚNG GIAO DIỆN TRÊN CÁC THIẾT BỊ

- MÔ TẢ: KIỂM TRA HIỂN THỊ TRÊN ĐIỆN THOẠI.

 Mở trang web trên thiết bị có kích thước cửa sổ 360 x 640 pixels.

- KẾT QUẢ MONG ĐỢI: GIAO DIỆN HIỂN THỊ ĐÚNG, CÁC THÀNH PHẦNKHÔNG BỊ TRÀN HOẶC LỖI HIỂN THỊ.

Kết quả thử nghiệm

STT MSSV Họ tên Công việc

1 2111858 Nguyễn Thị Thùy Linh  Nhóm trưởng

2 2115262 Tô Văn Sinh  Thiết kế database

3 2115201 Vy Nhật Duy  Code website

Ngày đăng: 27/06/2024, 15:55

HÌNH ẢNH LIÊN QUAN

Bảng Selenium sẽ lưu lại các lệnh, kết quả mong đợi và giá trị đầu vào của các lệnh. - Báo Cáo Môn Học Kiểm Thử Phần Mềm Đề Tài Xây Dựng Website Cho Cửa Hàng Thuốc Thú Y.pdf
ng Selenium sẽ lưu lại các lệnh, kết quả mong đợi và giá trị đầu vào của các lệnh (Trang 22)
3.2. Sơ đồ use case - Báo Cáo Môn Học Kiểm Thử Phần Mềm Đề Tài Xây Dựng Website Cho Cửa Hàng Thuốc Thú Y.pdf
3.2. Sơ đồ use case (Trang 36)
BẢNG PHÂN CÔNG - Báo Cáo Môn Học Kiểm Thử Phần Mềm Đề Tài Xây Dựng Website Cho Cửa Hàng Thuốc Thú Y.pdf
BẢNG PHÂN CÔNG (Trang 52)

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

TÀI LIỆU LIÊN QUAN

w