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

Trong bài viết này mình xin giới thiệu với các bạn cái loại kiểm thử phần mềm , trong phần 1 này mình xin giới thiệu với các bạn 3 loại đầu tiên :

1.Test smoke (test sơ lược)

Định nghĩa: Test sơ lược còn được gọi là "Build Verification Testing" là một loại kiểm thử bao gồm một tập các bài kiểm thử khoogn đầy đủ với những test cases giới hạn nhằm đảm bảo rằng các chức năng quan trọng nhất hoạt động.Kết quả của thử nghiệm này sẽ quyết định phần mềm đó đủ ổn định để có thể kiểm tra thêm. Từ khóa ‘smoke’ testing có nguồn gốc từ việc kiểm tra các phần cứng.Khi thiết bị lần đầu tiên được kiểm tra thì kiểm tra sơ lược các thành phần cơ bản , quan trọng của phần cứng đó có hoạt động tốt và khoogn có sự cố nghiêm trọng nào xảy ra.Nói 1 cách đơn giản là khi kiểm thử 1 phần mềm hay 1 hệ thống theo kiểu sơ lược có nghĩa là chúng ta chắc chắn , đảm bảo khoogn có vấn đề nào gây hại trước khi xây dựng 1 bản kiểm thử đầy đủ. Đặc điểm:

• Mục đích của việc kiểm tra sơ lược này là để đmr bảo các chức năng quan trọng của một ứng dụng đang làm việc tốt
• Đây là một loại kiểm thử không đầy đủ với số lượng rất hạn chế các trường hợp kiểm thử.
• Nó còn được gọi là Xây dựng xác minh kiểm tra tức là nơi xây dựng được xác minh bằng các thử nghiệm các tính năng quan trọng của ứng dụng sau đó tuyên bố nó là tốt để đi kiểm tra chi tiết hơn nữa
• Kiểm tra loại này có thể thực hiện bởi các nhà phát triển trước khi chuyển cho người kiểm tra
• Nó là một loại thử nghiệm vừa hẹp vừa rộng vì nó bao gồm tất cả các chức năng cơ bản và quan trọng của 1 ứng dụng.
• Thông thường việc kiểm tra sơ lược được ghi lại vào tài liệu.
• Kiểm tra sơ lược giống như kiểm tra sức khỏe bình thường của việc xây dựng một ứng dụng Ví dụ: Giả sử rằng có một phầm mềm ứng dụng như "Quản lí giáo viên".Ứng dụng này có 4 trang quan trọng nhất : Trang Login , trang thêm thông tin giáo viên, Trang Cập nhật, và Xóa nó.Như vậy để kiểm tra sơ lược về hệ thống đó.Chúng ta phỉa kiểm tra:
• Đăng nhập thành công với đầu vào hợp lệ
• Thực hiện việc thêm giáo viên thành công
• Thực hiện việc Sửa giáo viên thanh công
• Thực hiện việc Xóa giáo viên thành công Nếu cả 4 việc trên đều không có vấn đề gì xảy ra , hệ thống hoạt động tốt và ổn định thì có thể tiếp tục kiểm tra thêm các trường hợp đầy đủ. Khi nào thì sử dụng kiểm thử sơ lược:
• Được thực hiện bởi các nhà phát triển trước khi đưa ra đội xây dựng.
• Được thực hiện bởi các nhà kiểm thử trước khi bắt đầu kiểm thử chi tiết
• Được thực hiện khi chắc chắc rằng các chức năng cơ bản của ứng dụng hoạt dộng tốt. Ưu điểm :
• Giúp việc tìm kiếm các lỗi trong gia đoạn đầu việc kiểm thử
• Giúp việc tìm kiếm các vấn đề sau khi tích hợp các thành phần
• Giúp việc xác minh các vấn đề cố đinhk trong xây dựng phần mềm trước đó mà không ảnh hưởng đến chức năng chính của ứng dụng
• Rất ít trường hợp thử nghiệm được yêu cầu phải thực hiện kiểm thử sơ lược.
• Kiểm thử sơ lược có thể được thực hiện trong thời gian nhỏ. **Nhược điểm: **
• Không bao gồm được kiểm thử chi tiết
• Kiểm thử không đầy đủ với số lượng nhỏ testcases bở vì không thể tìm thấy những vấn đề quan trọng khác . Kết luận : Nếu chúng ta không thực hiện kiểm thử sơ lược => điều gì sẽ xảy ra , bugs sẽ xuất hiện giai đoạn sau và nó có thể ảnh hưởng đến các thành phần khác của hệ thống , cũng như chi phí , thời gian, sức lực,...

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

Định nghĩa: Kiểm thử chức năng là 1 loại kiểm thử phần mềm nơi mà hệ thống được kiểm thử so với yếu cầu chức năng/ chi tiết kỹ thuật. Đặc điểm:

• Chức năng(tính năng) được kiểm thử bằng việc cho nó đầu vào và thu được đầu ra
• Kiểm thử chức năng đảm bảo thỏa mãn yêu cầu của ứng dụng.
• Loại kiểm thử này không quan tâm là từ đầu vào đó được xử lí như thế nào mà chỉ quan tâm đến kết quả đầu ra mà thôi.
• Kiểm thử hộp đen là kỹ thuật được sử dụng cho loiaj kiểm thử này bởi vì người kiểm thử sẽ không biết được logic hệ thống như thế nào.
• Loại kiểm thử này được sử dụng ở mức kiểm thử hệ thống và kiểm thử chấp nhận Kiểm tra những gì ?
• Các chức năng chính: Kiểm tra các chức năng chính và quan trọng của ứng dụng
• Khả năng sử dụng cơ bản: Bao gồm việc kiểm tra khả năng sử dụng cơ bản của hệ thống.Nó kiểm tra xem người dùng có thể tự do điều hướng qua màn hình mà không gặp bất cứ khó khăn gì.
• Khả năng tiếp cận: Kiểm tra tính khả dụng của hệ thống cho người dùng
• Điều kiện lỗi: Sử dụng các kỹ thuật kiểm tra để kiểm tra các điều kiện lỗi .Kiểm tra xem các thông báo lỗi thích hợp có được hiển thị hay không . Các bước tiến hành:
• Xác định các chức năng của phần mềm cần được thực hiện
• Identify test input (test data) - Xác định dữ liệu đầu vào:
• Compute the expected outcomes with the selected test input values - Tìm các kết quả dự kiến với các đầu vào đã chọn
• Execute test cases - Thực thi kiểm thử
• Comparison of actual and computed expected result - So sánh kết quả thực tế với kết quả dự kiến. **Ưu điểm: **
• Nó mô phỏng việc sử dụng hệ thống thực tế Nhược điểm:
• Các lỗi logic trong phần mềm có thể bị bỏ qua
• Khả năng kiểm thử dư thừa rất cao So sánh kiểm thử chức năng và kiểm thử phi chứ năng:

3.Usability Testing (Kiểm thử khả năng sử dụng)

Định nghĩa: Đây là loại kiểm thử được thực hiện bởi quan điểm người dùng cuối để xác định xem hệ thống có sử dụng dễ dàng hay không. Đặc điểm:

• Hệ thống có thể được xây dựng 100% theo yêu cầu kỹ thuật, yêu cầu của khách hàng.Tuy nhiên, chúng có thể khoogn sử dụng được hoặc không khả thi ,không tiện dụng đối với người dùng cuối.Ví dụ giả sử người dùng cần in báo cáo cập nhật tài chính, cứ 30 phút một lần và phải thực hiện các bước sau:

• Đăng nhập vào hệ thống
• Click báo cáo
• Từ list báo cáo, chọn báo cáo tài chính
• Từ list báo cáo tài chính chọn báo cáo cập nhật tài chính
• Điền các thông số sau: Phạm vi ngày, giờ , phòng ban, các đơn vị
• Click vào tạo báo cáo
• Click vào in
• Click vào tùy chọn : in bằng PDF, in bằng real Đó là trường hợp hệ thống sẽ khoogn sử dụng được trong thực tế mặc dù nó hoạt động hoàn hảo.Nếu báo cáo được in thường xuyên , nó sẽ không dược thuận tiện nếu người dùng phải làm qua nhiều bước trên, mặt khác chúng ta có thể ladm một tính năng lwuu báo cáo thường xuyên và chúng ta có thể in từ trang chủ. Rất khó để đánh giá khả năng sử dụng nhưng thông thường chúng ta đánh giá dựa trên :

• Mức độ kỹ năng cần thiết để học/ sử dụng phần mềm.Nên cân bằng cho cả người dùng hay người đã biết trc phần mềm.
• Thời gian bắt buộc ddeer làm quen với việc sử dụng phần mềm.
• Các biện pháp tăng năng suất của người sử dụng nếu có.
• Đánh giá thái độ của người sử dụng đối với việc sử dụng phần mềm. Những mức độ có thể áp dụng: Kiểm thử hệ thống và kiểm thử chấp nhận. **Lợi ích của kiểm thử khả năng sử dụng: ** Kiểm thử khả năng sử dụng cho phép đội thiết kế và phát triển xác định các vấn đề trước khi chúng ta lập trình.Các vấn đề trước đây được xác định và cố định , lỗi sẽ ít hớn => tiết kiệm chi phí, thời gian , sức lực Tips:
• Hiểu người dùng của hệ thống
• Hiểu được nhu cầu kinh doanh của họ là gì
• Cố gắng bắt trước hoạt động của họ

Mình xin dừng bài tại đây.Trong phần 2 mình sẽ tiếp tục giới thiệu với các bạn 4 loại kiểm thử tiếp theo.Hẹn gặp lại các bạn trong phần 2 ^^