Kiểm thử phần mềm là công việc nhằm đảm bảo hoạt động của ứng dụng vừa được phát triển. Để thực hiện công việc này tùy theo khả năng, kinh nghiệm mà kiểm thử viên có thể áp dụng các phương pháp kiểm thử phần mềm cơ bản sau: White box testing, Black box testing, Grey box testing.
Nội dung chính
- I. Các Kỹ Thuật Kiểm Thử Phần Mềm
- 1. Phương pháp kiểm thử phần mềm White box testing
- 2. Phương pháp kiểm thử phần mềm Black box testing
- 3. Grey box testing
- 2. Nguyên lý kiểm thử phần mềm
- 2.1 Kiểm thử đưa ra lỗi
- 2.2 Kiểm thử cạn kiệt là không thể
- 2.3 Kiểm thử càng sớm càng tốt
- 2.4 Sự tập trung của lỗi
- 2.5 Nghịch lý thuốc trừ sâu
- 2.6 Kiểm thử phụ thuộc vào ngữ cảnh
- 2.7 Không có lỗi Sai lầm
- Video liên quan
- Khóa Học Tester Cho Người Mới Bắt Đầu ? Chưa Biết Gì Liệu Tham Gia Được Không ?
- Selenium Webdriver Là Gì ? Khái Niệm Và Vai Trò Của Selenium Webdriver
- Unit Test Là Gì ? Khái Niệm Và Vai Trò Của Unit Test
- Các Mô Hình Phát Triển Phần Mềm
Danh Mục Bài Viết
- I. Các Kỹ Thuật Kiểm Thử Phần Mềm
- 1. Phương pháp kiểm thử phần mềm White box testing
- 2. Phương pháp kiểm thử phần mềm Black box testing
- 3. Grey box testing
- 2. Nguyên lý kiểm thử phần mềm
- 2.1 Kiểm thử đưa ra lỗi
- 2.2 Kiểm thử cạn kiệt là không thể
- 2.3 Kiểm thử càng sớm càng tốt
- 2.4 Sự tập trung của lỗi
- 2.5 Nghịch lý thuốc trừ sâu
- 2.6 Kiểm thử phụ thuộc vào ngữ cảnh
- 2.7 Không có lỗi Sai lầm
I. Các Kỹ Thuật Kiểm Thử Phần Mềm
Trong bài học kiểm thử phần mềm này, Tehcacademy giới thiệu 3 kỹ thuật kiểm thử phần mềm phổ biến và thông dụng nhất hiện nay.
Bạn đang đọc: Một số phương pháp kiểm thử
1. Phương pháp kiểm thử phần mềm White box testing
White box testing ( Kiểm tra hộp màu trắng ) là một kỹ thuật kiểm tra cấu trúc bên trong của phần mềm và lấy tài liệu thử nghiệm từ logic / mã chương trình. Là phương pháp kiểm thử mà các chuyên viên tester tập trung chuyên sâu vào các tài liệu nguồn vào và ra, truy vấn thẳng vào bên trong source code. Các tên khác của thử nghiệm hộp trắng là thử nghiệm hộp mở, kiểm tra theo hướng logic hoặc thử nghiệm tinh chỉnh và điều khiển đường dẫn hoặc thử nghiệm cấu trúc .
Phương pháp kiểm thử phần mềm White box testing
Các loại white box testing:
API testing ( application programming interface ) Kiểm thử ứng dụng bằng cách sử dụng các hàm API public và private .Code coverage Là việc tạo các trường hợp test để thỏa mãn nhu cầu 1 số ít điều kiện kèm theo bao trùm code code coverage ( ví dụ như, người phong cách thiết kế test hoàn toàn có thể tạo ra các trường hợp test sao cho tổng thể các câu lệnh của chương trình đều được thực thi tối thiểu 1 lần ) .Fault injection methods nâng cấp cải tiến bao trùm một trường hợp bằng cách đưa 1 số ít lỗi vào để test các đường dẫn code .Mutation testing methods .Static testing White box testing gồm có toàn bộ các phương pháp kiểm thử tĩnh ( ví dụ review code ) .Với phương pháp kiểm thử này, kiểm thử viên không cần hiểu biết về mã lệnh để giải quyết và xử lý tính năng đó thế nào. Các kiểm thử viên sẽ địa thế căn cứ vào tài liệu đặc tả, bản prototype của phần mềm cũng như dựa trên các testcase đã viết để kiểm tra công dụng. Cả hai hình thức trên đề trả về một cách đo độ bao trùm code, sự giám sát được tính bằng Phần Trăm % .
Ưu điểm:
- Dễ dàng tự động hóa
- Cung cấp các quy tắc dựa trên kỹ thuật rõ ràng cho thời gian ngừng thử nghiệm .
- Buộc các chuyên viên thử nghiệm phải suy luận cẩn trọng về việc test lỗi thế cho nên lỗi sẽ được triệt để .
Nhược điểm:
- Khá tốn thời gian và công sức.
- Vẫn sẽ sống sót lỗi .
- Để kiểm tra được bằng phương pháp này cần có kinh nghiệm tay nghề và trình độ sâu xa về kiểm thử .
2. Phương pháp kiểm thử phần mềm Black box testing
Black box testing ( Kiểm thử hộp đen ) là một phương pháp kiểm thử phần mềm kiểm tra tính năng của ứng dụng dựa trên các đặc thù kỹ thuật của nó. Nó còn được gọi là thử nghiệm dựa trên thông số kỹ thuật kỹ thuật .
Phương pháp kiểm thử phần mềm Black box testing
Các loại kiểm thử Black box:
- Equivalence partitioning (phân vùng tương đương)
- Boundary value analysis ( nghiên cứu và phân tích giá trị biên )
- All-pairs testing ( kiểm thử toàn bộ các cặp )
- Fuzz testing ( cách test : nhập vào các điều kiện kèm theo sai hoặc data một cách ngẫu nhiên )
- Model-based testing ( Kiểm thử dựa trên Mã Sản Phẩm )
- Traceability matrix ( các tính năng của chương trình được tạo thành một ma trận, các trường hợp test là sự tích hợp các dòng hoặc các cột có tương quan )
- Exploratory testing ( kiểm thử hầu hết dựa vào kinh nghiệm tay nghề và năng lực focus vào việc test các tính năng của tester )
- Specification-based testing ( kiểm thử dựa vào tính năng ) .
Việc kiểm thử được thực thi dựa vào việc kiểm thử công dụng của phần mềm xem nó có tương thích với nhu yếu của người dùng hay không. Vì vậy, các tester nhập data vào phần mềm và chỉ cần xem tác dụng của phần mềm và các tiềm năng test .
Ưu điểm:
- Các tester khi dùng phương pháp này sẽ không cần liên quan đến code.
-
Có thể tìm được nhiều bug hơn.
- Việc kiểm thử được thực thi bởi một cách độc lập với các Dev, được cho phép quan điểm khách quan và tránh sự thiên vị .
Nhược điểm:
- Chỉ có một số lượng nhỏ các đầu vào có thể được kiểm tra và nhiều đường dẫn chương trình hoặc 1 vài phần cuối sẽ không được kiểm tra.
- Các thử nghiệm hoàn toàn có thể thừa nếu nhà phong cách thiết kế / nhà tăng trưởng phần mềm đã chạy thử nghiệm .
Vì vậy, black box testing có ưu điểm là loại sản phẩm phần mềm được kiểm tra theo một quan điểm độc lập tuy nhiên vẫn còn khá nhiều điểm yếu kém đáng quan tâm .
3. Grey box testing
Phương pháp Gray box testing là một trong các phương pháp test phần mềm thông dụng nhất lúc bấy giờ. Có thể nói phương pháp Gray Box testing là phương pháp của sự phối hợp giữa White box testing và Black box testing. Kiểm tra hộp màu xám cho năng lực kiểm tra cả hai mặt của một ứng dụng, lớp trình diễn cũng như phần mã. Nó đa phần là hữu dụng trong kiểm thử tích hợp và kiểm tra xâm nhập. Trong Kiểm thử Hộp xám, cấu trúc bên trong loại sản phẩm chỉ được biết một phần, Tester hoàn toàn có thể truy vấn vào cấu trúc tài liệu bên trong và thuật toán của chương trình với mục tiêu là để phong cách thiết kế test case, nhưng khi test thì test như là người dùng cuối hoặc là ở mức hộp đen .
Grey box testing
Kỹ thuật kiểm tra hộp xám:
Kiểm tra ma trận : báo cáo trạng thái của dự án Bất Động Sản .Kiểm tra hồi quy : nó ý niệm chạy lại các trường hợp thử nghiệm nếu các thay đổi mới được thực thi .Kiểm tra mẫu : xác định ứng dụng tốt cho phong cách thiết kế hoặc kiến trúc và các mẫu của nó .Kiểm tra mảng trực giao : được sử dụng làm tập hợp con của tổng thể các tích hợp hoàn toàn có thể .
Ưu điểm:
Là sự tích hợp của kiểm thử hộp đen và hộp trắng nên sẽ tối ưu hơn .Kiểm tra bằng phương pháp hộp màu xám hoàn toàn có thể phong cách thiết kế ngữ cảnh thử nghiệm phức tạp một cách mưu trí hơn .
Nhược điểm:
Rất khó để link lỗi khi triển khai kiểm tra hộp xám cho một ứng dụng có mạng lưới hệ thống phân tán .Trên đây là 3 phương pháp kiểm thử phần mềm cơ bản nhất mà bất kỳ một lập trình viên nào cũng cần nắm được. Việc lựa chọn phương pháp nào phụ thuộc vào vào năng lực cũng như dự án Bất Động Sản mà bạn thực thi .
2. Nguyên lý kiểm thử phần mềm
Để đạt được hiệu quả kiểm thử tối ưu trong khi thực thi kiểm thử phần mềm mà không đi lệch khỏi tiềm năng là điều cực kỳ quan trọng, làm thế nào để xác lập rằng bạn đang theo đúng kế hoạch kiểm thử ? Để làm được điều đó, bạn cần tuân thủ 1 số ít nguyên tắc kiểm thử cơ bản. Dưới đây là bảy nguyên tắc kiểm thử phổ cập được vận dụng thoáng đãng trong ngành công nghiệp phần mềm .
+ Kiểm thử đưa ra lỗi
+ Kiểm thử cạn kiệt là không thể
+ Kiểm thử càng sớm càng tốt
+ Sự tập trung của lỗi
+ Nghịch lý thuốc trừ sâu
+ Kiểm thử phụ thuộc vào ngữ cảnh
+ Không có lỗi Sai lầm
7 Nguyên Lý Kiểm Thử Phần Mềm
2.1 Kiểm thử đưa ra lỗi
Kiểm thử hoàn toàn có thể cho thấy rằng phần mềm đang có lỗi, nhưng không hề chứng tỏ rằng phần mềm không có lỗi. Kiểm thử được thực thi bằng những kĩ thuật khác nhau. Kiểm thử làm giảm Phần Trăm lỗi chưa tìm thấy vẫn còn trong phần mềm, ngay cả khi đã kiểm thử khắt khe phần mềm vẫn hoàn toàn có thể còn lỗi. Vì vậy tất cả chúng ta phải tìm được càng nhiều lỗi càng tốt .
2.2 Kiểm thử cạn kiệt là không thể
Nguyên lý này nói rằng, kiểm tra mọi thứ trong phần mềm một cách toàn vẹn là không hề. Kiểm thử với tổng thể các tích hợp nguồn vào và đầu ra, với tổng thể các ngữ cảnh là không hề trừ phi nó chỉ gồm có ít trường hợp thì hoàn toàn có thể kiểm thử hàng loạt. Thay vì kiểm thử hàng loạt, việc nghiên cứu và phân tích rủi ro đáng tiếc và dựa trên sự mức độ ưu tiên tất cả chúng ta hoàn toàn có thể tập trung chuyên sâu việc kiểm thử vào 1 số ít điểm thiết yếu, có rủi ro tiềm ẩn lỗi cao hơn .
2.3 Kiểm thử càng sớm càng tốt
Nguyên lý này nhu yếu khởi đầu thử nghiệm phần mềm trong quá trình đầu của vòng đời tăng trưởng phần mềm. Các hoạt động giải trí kiểm thử phần mềm từ tiến trình đầu sẽ giúp phát hiện bug sớm hơn. Nó được cho phép chuyển giao phần mềm theo nhu yếu đúng thời hạn với chất lượng dự kiến .
2.4 Sự tập trung của lỗi
Thông thường, lỗi tập trung chuyên sâu vào những module, thành phần công dụng chính của mạng lưới hệ thống. Nếu xác lập được điều này bạn sẽ tập trung chuyên sâu vào tìm kiếm lỗi quanh khu vực được xác lập. Nó được coi là một trong những cách hiệu suất cao nhất để triển khai kiểm tra hiệu suất cao .
2.5 Nghịch lý thuốc trừ sâu
Nếu bạn sử dụng cùng một tập hợp các trường hợp kiểm thử liên tục, sau đó một thời hạn các trường hợp kiểm thử không tìm thấy lỗi nào mới. Hiệu quả của các trường hợp kiểm thử khởi đầu giảm xuống sau một số ít lần thực thi, thế cho nên luôn luôn tất cả chúng ta phải luôn xem xét và sửa đổi các trường hợp kiểm thử trên một khoảng chừng thời hạn tiếp tục .
2.6 Kiểm thử phụ thuộc vào ngữ cảnh
Theo nguyên tắc này thì việc kiểm thử phụ thuộc vào vào ngữ cảnh và tất cả chúng ta phải tiếp cận kiểm thử theo nhiều ngữ cảnh khác nhau .Nếu bạn đang kiểm thử ứng dụng web và ứng dụng di động bằng cách sử dụng kế hoạch kiểm thử giống nhau, thì đó là sai. Chiến lược để kiểm thử ứng dụng web sẽ khác với kiểm thử ứng dụng cho thiết bị di động của Android .
2.7 Không có lỗi 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. Việc không tìm thấy lỗi cũng có thể là do bộ trường hợp kiểm thử được tạo ra chỉ nhằm kiểm tra những tính năng được làm đúng theo yêu cầu thay vì nhằm tìm kiếm lỗi mới.
Bài viết này chỉ kỳ vọng giúp các bạn hiểu cơ bản về Phương pháp kiểm thử phần mềm và Nguyên lý kiểm thử phần mềm. Bạn cần khám phá thêm để hoàn toàn có thể hiểu sâu hơn về các phương pháp cũng như những nguyên tắc này cũng như vận dụng hiệu suất cao nó vào việc làm của bạn .
Video liên quan
Source: https://bacxiunong.com
Category: Blog
