Bài tập lớn môn kiểm thử phần mềm đề tài nghiên cứu và ứng dụng kĩ thuật kiểm thử end to end

Tuy chưa nổi tiếng và phổ biến như chức danh lập trình viên nhưng chuyên viên kiểm thử phần mềm đã, đang và sẽ là một trong những nghề “hot”, một nghề không thể thiếu được trong ngành Cô

TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP HÀ NỘI

KHOA CÔNG NGHỆ THÔNG TIN

-BÀI TẬP LỚN MÔN: KIỂM THỬ PHẦN MỀM

ĐỀ TÀI: NGHIÊN CỨU VÀ ỨNG DỤNG KĨ THUẬT KIỂM THỬ

END-TO-END

Giảng viên hướng dẫn : Ths Hoàng Quang Huy

Sinh viên thực hiện : Phan Tiến Phương 2020602782

Nguyễn Văn Quyết 2020602984

Đỗ Mạnh Cường 2020607195Đinh Thị Tiến 2020607555

Hà Nội, 2023

MỤC LỤC

2.2 Tại sao phải kiểm thử End-To-End (Trịnh Tiến Đạt) 132.3 Quá trình kiểm thử End-To-End (Vũ Quang Đáng) 132.4 Cách thực hiện kiểm thử End-To-End (Nguyễn Phú Nam) 14

2.4.2 Xây dựng điều kiện dựa trên chức năng người dùng 15

2.5 Kết luận về kiểm thử End-To-End 17

CHƯƠNG 3: ỨNG DỤNG KỸ THUẬT KIỂM THỬ END-TO-END

3.1 Công cụ thực hiện kiểm thử End-To-End (Nguyễn Văn Thành) 18

3.2.2 Sử dụng testRigor để record một usecase và phát hiện lỗi 19

MỤC LỤC HÌNH ẢNH

Hình 1 Các loại kiểm thử phần mềm 6

Hình 2 Quá trình kiểm thử End-To-End 13

Hình 3 Cách thực hiện kiểm thử End-To-End 14

Hình 4 Bước 1: Trên trang chủ testRigor tạo một TestSuite mới 19

Hình 5 Bước 2: Bật tiện ích testRigor trên Chrome để record use case 20

Hình 6 Bước 3: Bật tiện ích testRigor trên chrome để record use case, chọn Test Suite và mô tả, chọn “Start new recording” và tiến hành thực hiện use case 21

Hình 7 Bước 4: Chọn vào tiện ích rồi stop recording 22

Hình 8 Bước 5: Sau đó hiện ra một mã lệnh để script của testRigor test và chọn nút“Add and Run” 22

Hình 9 Bước 6: Quay về trang chủ và chọn test suite 23

Hình 10 Bước 7: Chờ Test Complete và xem kết quả, bao gồm các bước thực hiện, lỗi chỗ nào, video 23

LỜI MỞ ĐẦU

Trong những năm gần đây, công nghệ phát triển vô cùng mạnh mẽ , tiên tiến Nhắc đến ngành các công ty phần mềm người ta thường nhắc đến lập trình viên - những người trực tiếp làm ra các sản phẩm phần mềm phức tạp Vậy có phải những sản phẩm do các lập trình viên làm ra có thể ứng dụng ngay hay không? Câu trả lời là không

Bất kỳ một phần mềm hay ứng dụng nào trước khi đưa vào hoạt động đều phải trải qua khâu kiểm tra Những người phụ trách công việc này được gọi là Tester - Chuyên viên kiểm thử phần mềm Tuy chưa nổi tiếng và phổ biến như chức danh lập trình viên nhưng chuyên viên kiểm thử phần mềm đã, đang và sẽ

là một trong những nghề “hot”, một nghề không thể thiếu được trong ngành Công nghiệp phần mềm

Công việc của tester là tìm kiếm các lỗi của hệ thống phần mềm hoặcthẩm định, xác minh xem hệ thống phần mềm có đáp ứng các yêu cầu kỹ thuật

và yêu cầu nghiệp vụ hay không Tester giúp cho sản phẩm được hoàn thiệnnhằm đáp ứng yêu cầu đặt ra của khách hàng Sản phẩm hoàn thiện, chất lượngcao sẽ tạo thêm niềm tin và uy tín của công ty với đối tác Nếu không có khâunày, tình trạng khách hàng trả sản phẩm về sẽ xảy ra thường xuyên Như vậy cóthể thấy người kỹ sư kiểm thử phần mềm (tester) vô cùng quan trọng, có thể nóiđây là khâu sống còn của việc phát triển phần mềm của bất kỳ công ty phầnmềm nào

Trong công việc của một người kiểm thử thì Kiểm thử đầu cuối End Testing) là một phần khá quan trong việc kiểm thử phần mềm Vậy thì hãycùng nhau làm rõ vấn đề này

(End-To-CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM

1.1 Khái niệm (Nguyễn Văn Quyết)

- Kiểm thử phần mềm là một phương pháp để kiểm tra xem sản phẩm phần mềm thực tế có phù hợp với các yêu cầu mong đợi hay không và để đảm bảo rằng không có khiếm khuyết Nó liên quan đến việc thực thi các thànhphần phần mềm hệ thống bằng cách sử dụng thủ công hoặc tự động để đánh giá một hoặc nhiều thuộc tính quan trọng

1.2 Vai trò (Đinh Thị Tiến)

- Đảm bảo chất lượng phần mềm và mang tính sống còn trong các dự án sản xuất phần mềm Vì vậy nó đã trở thành quy trình bắt buộc trong các

dự án phần mềm hiện nay

- Tránh những rủi ro, lỗi phát sinh trong suốt quá trình tạo ra sản phẩm

- Giảm chi phí

1.3 Mục đích (Phan Tiến Phương)

- Để đánh giá phần mềm có đạt yêu cầu mong đợi hay có sai sót gì không

- Tìm cái lỗi phát sinh khi code, khoảng trống hoặc các yêu cầu còn thiếu đối lập với các yêu cầu thực tế

- Ngăn ngừa lỗi 1 cách tối đa

- Đảm bảo được kết quả cuối cùng đáp ứng được nhu cầu người sử dụng

1.4 Các loại kiểm thử (Đỗ Mạnh Cường)

- Kiểm thử chức năng (Functional Testing)

- Kiểm thử phi chức năng (Non-Functional Testing)

- Bảo trì (Maintenance Testing)

Hình 1 Các loại kiểm thử phần mềm

1.4.1 Kiểm thử chức năng

- Kiểm thử chức năng có thể được thực hiện từ 2 góc nhìn: dựa trên yêu cầu

và dựa trên quy trình nghiệp vụ

+ Dựa trên yêu cầu:

● Sử dụng các đặc tả kỹ thuật của các yêu cầu chức năng đểlàm cơ sở cho việc test các thiết kế

● Nội dung của các yêu cầu có thể làm các mục kiểm thử banđầu hoặc sử dụng nó như là một danh sách các mục kiểm thửhoặc không kiểm thử

● Dựa theo yêu cầu để phân mức độ ưu tiên trong quá trìnhkiểm thử Cần ưu tiên các yêu cầu có mức độ rủi ro cao.+ Dựa trên quy trình nghiệp vụ:

● Các quy trình nghiệp vụ mô tả các kịch bản scenarios liênquan đến các nghiệp vụ hằng ngày của hệ thống

● Các usecase được bắt nguồn phát triển theo hướng đối tượngnhưng hiện tại phổ biến trong nhiều trong các vòng đời pháttriển.

● Lấy các quy trình nghiệp vụ làm điểm khởi đầu, các quy trìnhnghiệp vụ xuất phát từ các nhiệm vụ được thực hiện bởingười dùng

● Các use case là một cơ sở hữu ích cho các testcase từ góc độnghiệp vụ

- Kiểm thử chức năng bao gồm 5 bước:

+ Xác định các chức năng mà phần mềm mong muốn sẽ thực hiện.+ Tạo ra các dữ liệu đầu vào dựa trên các tài liệu đặc tả kỹ thuật củacác chức năng

+ Xác định kết quả đầu ra dựa trên các tài liệu đặc tả kỹ thuật của cácchức năng

+ Thực hiện các trường hợp kiểm thử

+ So sánh kết quả thực tế và kết quả mong muốn

- Các loại kiểm thử chức năng:

+ Kiểm thử đơn vị (Unit Testing)

+ Kiểm thử khói (Smoke Testing - check nhanh xem hệ thống có khởiđộng được hay không)

+ Kiểm thử độ tỉnh táo (Sanity Testing - check nhanh xem sau khisửa đổi thì function có hoạt động như mong muốn hay không)

+ Kiểm thử giao diện (Interface Testing)

+ Kiểm thử tích hợp (Integration Testing)

+ Kiểm thử hệ thống (Systems Testing)

+ Kiểm thử hồi quy (Regression Testing)

+ Kiểm thử chấp nhận (Acceptance testing)

1.4.2 Kiểm thử phi chức năng

- Các loại kiểm thử chức năng:

+ Kiểm thử hiệu năng (performance testing)

+ Kiểm thử khả năng chịu tải (load testing)

+ Kiểm thử áp lực (stress testing)

+ Kiểm thử khả năng sử dụng (usability testing)

+ Kiểm thử bảo trì (maintainability testing)

+ Kiểm thử độ tin cậy (reliability testing)

+ Kiểm thử tính tương thích (portability testing)

- Những đặc điểm phụ tương ứng:

+ Độ tin cậy (reliability): được xác định rõ hơn từ các đặc trưng phụ

đã được tính toán cẩn thận (độ bền), khả năng chịu lỗi (faulttolerance), phục hồi (recoverability) và tuân thủ (compliance).+ Khả năng sử dụng (usability): được chia thành các đặc trưng dễhiểu, khả năng học hỏi (learnability), khả năng hoạt động(operability), sự thu hút (attractiveness) và tính tuân thủ(compliance)

+ Tính hiệu quả (efficiency): được chia thành hành vi về thời gian(hiệu suất), sử dụng tài nguyên (resource utilization) và tuân thủ(compliance)

+ Khả năng bảo trì (maintainability): bao gồm 5 đặc điểm phụ: phântích, khả năng thay đổi, tính ổn định, khả năng kiểm tra và tuân thủ

+ Tính tương thích (portability): bao gồm 5 đặc điểm phụ: khả năngthích ứng, khả năng cài đặt, cùng tồn tại, khả năng thay thế và tuânthủ.

1.4.3 Kiểm thử bảo trì

- Phân tích tác động và kiểm thử hồi quy:

+ Thông thường kiểm thử bảo trì gồm 2 phần: kiểm thử các thay đổi

và Kiểm thử hồi quy để cho thấy phần còn lại của hệ thống không

bị ảnh hưởng bởi công việc bảo trì

+ Hoạt động chính và quan trọng trong việc kiểm thử bảo trì là việcphân tích các tác động Từ việc phân tích sẽ quyết định được nhữngphần nào của hệ thống có thể bị ảnh hưởng không mong muốn.+ Phân tích rủi ro sẽ giúp quyết định được nơi cần tập trung kiểm thửhồi quy

- Khởi động cho kiểm thử bảo trì:

+ Kiểm thử bảo trì được thực hiện trên hệ thống đã tồn tại và đượcthực hiện khi có sự thay đổi, di chuyển hoặc rút lui của phần mềmhoặc hệ thống

+ Kiểm thử bảo trì cho việc thay đổi: Các cải tiến bao gồm thay đổităng theo kế hoạch, khắc phục những thay đổi khẩn cấp và thay đổimôi trường

+ Kiểm thử bảo trì cho sự chuyển đổi: Bao gồm kiểm tra hoạt độngcủa môi trường mới, các phần mềm đã thay đổi Kiểm thử dichuyển (kiểm thử chuyển đổi) cũng cần thiết khi dữ liệu từ một ứngdụng khác sẽ được di chuyển vào hệ thống đang được bảo trì

+ Kiểm thử bảo trì đối với hệ thống đã ngừng hoạt động: bao gồmkiểm thử việc chuyển đổi dữ liệu hoặc lưu trữ, nếu cần lưu trữ dữliệu lâu dài.

+ Từ quan điểm của việc chuyển đổi thì có 2 loại:

● Chuyển đổi theo kế hoạch bao gồm: Chuyển đổi hoàn thiện(phần mềm thích nghi được với mong muốn người dùng),Chuyển đổi thích nghi (phần mềm thích nghi được với sựthay đổi của môi trường như phần cứng mới, phần mềm hệthống mới), Chuyển đổi điều chỉnh theo kế hoạch (sửa chữalỗi)

● Những chuyển đổi bột phát không thể lên kế hoạch được: đốivới những lỗi như thế này cần phân tích rủi ro của hệ thốnghoạt động để xác định chức năng hoặc chương trình gây lỗi

1.5 Các phương pháp kiểm thử (Nguyễn Văn Quyết)

- Kiểm thử hộp trắng (white box testing): Trong kiểm thử hộp trắng cấu trúc mã, thuật toán được đưa vào xem xét Người kiểm thử truy cập vào

mã nguồn của chương trình để có thể kiểm tra nó

- Kiểm thử hộp đen (black box testing): Kiểm tra các chức năng của hệ thống dựa trên bản đặc tả yêu cầu

- Kiểm thử hộp xám (gray box testing): Là sự kết hợp giữa black box

testing và white box testing

1.5.1 Kiểm thử hộp đen

- Quy trình kiểm thử hộp đen:

+ Phân tích đặc tả về các yêu cầu chức năng mà TPPM cần thực hiện.+ Dùng 1 kỹ thuật định nghĩa các testcase xác định (sẽ giới thiệu sau)

để định nghĩa các testcase Định nghĩa mỗi testcase là xác định 3 thông tin sau :

● Giá trị dữ liệu nhập để TPPM xử lý (hoặc hợp lệ hoặc khônghợp lệ)

● Trạng thái của TPPM cần có để thực hiện testcase

● Giá trị dữ liệu xuất mà TPPM phải tạo được

+ Kiểm thử các testcase đã định nghĩa

+ So sánh kết quả thu được với kết quả kỳ vọng trong từng testcase,

từ đó lập báo cáo về kết quả kiểm thử

+ Đặc điểm:

● Đây là kiểu kiểm thử thành phần phần mềm và chỉ dựa vào các thông tin đặc tả về yêu cầu, chức năng của các thành phần phần mềm tương ứng

● Việc kiểm thử được thực hiện bên ngoài, không liên quan đến lập trình viên hay các nhà phát triển phần mềm Vì thế người kiểm thử cũng không cần thiết phải biết về cấu trúc bên trong của phần mềm cũng như các kiến thức về lập trình

● Mức test này thường yêu cầu các tester phải viết test case đầy

đủ trước khi test; Các bước tiến hành test khá đơn giản, chỉ cần thực hiện theo các mô tả trong test case, thực hiện nhập

dữ liệu vào, đợi kết quả trả về và so sánh với kết quả dự kiến trong test case.

1.5.2 Kiểm thử hộp trắng

- Đặc điểm:

+ Kiểm thử hộp trắng quan tâm đến việc hệ thống vận hành như thế nào chứ không phải chức năng của hệ thống Vì nó dựa vào những thuật toán cụ thể, vào những cấu trúc dữ liệu bên trong của thành phần phần mềm

+ Trong kỹ thuật kiểm thử này, đòi hỏi người tester phải có kiến thức

và kỹ năng nhất định về ngôn ngữ lập trình được dùng, hiểu thuật toán trong phần mềm, để có thể hiểu được chi tiết về đoạn code cầnkiểm thử

+ Mức test này thường yêu cầu các tester phải viết test case đầy đủ các nhánh trong code; khi test, sẽ set điều kiện và data để chạy vào

đủ tất cả các nhánh trong thuật toán, đảm bảo thực hiện đầy đủ.+ Kiểm thử hộp trắng được dùng để đo độ bao phủ (coverage) và kiểm thử thiết kế (Design test)

+ Bao phủ kiểm thử(test coverage ) là tỷ lệ (tính theo %) testcase đã được thực hiện trên tổng số test case cần thiết cho phần mềm Nếu

tỉ lệ này càng cao thì phần mềm càng được test kỹ Mặc dù việc đảm bảo phần mềm có test coverage là 100% nhưng không có nghĩa là 100% các trường hợp được kiểm thử Độ bao phủ được tính bằng công thức sau:

Coverage = ( Number of coverage items exercised /Total number of

coverage items) * 100%

CHƯƠNG 2: KỸ THUẬT KIỂM THỬ END-TO-END

2.1 Khái niệm (Phan Tiến Phương)

- End To End Testing (Kiểm thử đầu cuối) là một phương pháp kiểm thử phần mềm xác nhận toàn bộ phần mềm từ đầu đến cuối cùng với sự tích hợp của nó với các giao diện bên ngoài

2.2 Tại sao phải kiểm thử End-To-End (Đinh Thị Tiến)

- End To End Testing xác minh luồng hệ thống hoàn chỉnh và tăng độ tin cậy bằng cách phát hiện các sự cố và tăng phạm vi kiểm tra của các hệ thống con Các hệ thống phần mềm hiện đại rất phức tạp và được kết nối với nhau bằng nhiều hệ thống con có thể khác với các hệ thống hiện tại Toàn bộ hệ thống có thể sụp đổ do lỗi của bất kỳ hệ thống con nào, đây là rủi ro lớn có thể tránh được bằng End To End Testing

2.3 Quá trình kiểm thử End-To-End (Đỗ Mạnh Cường)

- Sơ đồ sau đây đưa ra cái nhìn tổng quan về quy trình kiểm thử End to End

Hình 2 Quá trình kiểm thử End-To-End

- Các hoạt động chính liên quan đến Kiểm thử đầu cuối là:

+ Nghiên cứu các yêu cầu thử nghiệm từ đầu đến cuối.

+ Thiết lập môi trường thử nghiệm và yêu cầu phần cứng/phần mềm.+ Mô tả tất cả các hệ thống và các quy trình hệ thống con của nó.+ Mô tả vai trò và trách nhiệm cho tất cả các hệ thống

+ Phương pháp và tiêu chuẩn kiểm tra

+ Theo dõi yêu cầu từ đầu đến cuối và thiết kế các trường hợp thử nghiệm

+ Dữ liệu đầu vào và đầu ra cho từng hệ thống

2.4 Cách thực hiện kiểm thử End-To-End (Phan Tiến Phương)

Hình 3 Cách thực hiện kiểm thử End-To-End.

- Khung thiết kế thử nghiệm từ đầu đến cuối bao gồm ba phần

1 Xây dựng chức năng người dùng

2 Xây dựng điều kiện

3 Xây dựng các trường hợp thử nghiệm

2.4.1 Xây dựng chức năng người dùng

- Các hoạt động sau nên được thực hiện như một phần của chức năng ngườidùng xây dựng:

+ Liệt kê các tính năng của hệ thống và các thành phần được kết nối với nhau của chúng

+ Liệt kê dữ liệu đầu vào, hành động và dữ liệu đầu ra cho từng tính năng hoặc chức năng

+ Xác định mối quan hệ giữa các chức năng

+ Xác định xem chức năng có thể tái sử dụng hay độc lập

- Ví dụ: Xem xét tình huống bạn đăng nhập vào tài khoản ngân hàng của

mình và chuyển một số tiền vào tài khoản khác từ một số ngân hàng khác (hệ thống phụ của bên thứ 3):

1 Đăng nhập vào hệ thống ngân hàng

2 Kiểm tra số dư trong tài khoản

3 Chuyển một số tiền từ tài khoản của bạn sang một số tài khoản ngân hàng khác ( hệ thống phụ của bên thứ 3)

4 Kiểm tra số dư tài khoản mới nhất của bạn

5 Đăng xuất khỏi ứng dụng

2.4.2 Xây dựng điều kiện dựa trên chức năng người dùng

- Các hoạt động sau đây được thực hiện như một phần của điều kiện xây dựng:

+ Xây dựng một tập hợp các điều kiện cho từng chức năng người dùng đã xác định

+ Điều kiện bao gồm trình tự, thời gian và điều kiện dữ liệu

- Ví dụ: Kiểm tra các điều kiện khác như:

+ Trang đăng nhập

● Tên người dùng và mật khẩu không hợp lệ

● Kiểm tra với tên người dùng và mật khẩu hợp lệ

● Kiểm tra độ mạnh mật khẩu

● Kiểm tra thông báo lỗi+ Số dư

● Kiểm tra số dư hiện tại sau 24 giờ (Nếu chuyển khoản được gửi đến một ngân hàng khác)

● Kiểm tra thông báo lỗi nếu số tiền chuyển lớn hơn số dư hiệntại

2.4.3 Xây dựng kịch bản thử nghiệm

- Xây dựng kịch bản thử nghiệm cho chức năng người dùng đã xác định

- Trong trường hợp này,

● Đăng nhập vào hệ thống

● Kiểm tra số dư ngân hàng

● Chuyển số dư ngân hàng

2.4.4 Xây dựng nhiều trường hợp thử nghiệm

- Xây dựng một hoặc nhiều trường hợp thử nghiệm cho từng kịch bản đượcxác định Các trường hợp thử nghiệm có thể bao gồm từng điều kiện như một trường hợp thử nghiệm duy nhất