Đồ Án Tốt Nghiệp ĐẠI HỌC ĐÀ NẴNG TRƯỜNG ĐẠI HỌC BÁCH KHOA KHOA CÔNG NGHỆ THÔNG TIN Tel (84 511) 736 949, Fax (84 511) 842 771 Website itf ud edu vn, E mail cntt@edu ud vn LUẬN VĂN TỐT NGHIỆP KỸ SƯ NGÀ[.]
Vòng đời phát triển phần mềm
Quy trình phát triển phần mềm gồm các thao tác liên kết chặt chẽ để tạo ra sản phẩm phần mềm chất lượng cao, do các kỹ sư phần mềm thực hiện Các công cụ hỗ trợ máy tính về kỹ thuật phần mềm đóng vai trò quan trọng, giúp tối ưu hóa các bước trong quy trình phát triển Việc áp dụng quy trình rõ ràng giúp đảm bảo quá trình phát triển phần mềm hiệu quả và đáp ứng yêu cầu của người dùng.
Có 4 thao tác là nền tảng của hầu hết các quy trình phần mềm là:
1 Đặc tả phần mềm: Các chức năng của phần mềm và điều kiện để nó hoạt động phải được định nghĩa.
2 Sự phát triển phần mềm: Để phần mềm được đặc tả thì phải có quy trình phát triển này.
3 Đánh giá phần mềm: Phần mềm phải được đánh giá để chắc chắn rằng nó làm những gì mà khách hàng muốn.
4 Sự tiến hóa của phần mềm: Phần mềm phải tiến hóa để thỏa mãn sự thay đổi các yêu cầu của khách hàng.
Mô hình thác nước
Là 1 mô hình phát triển phần mềm tuần tự.
Chuyển đổi giữa các giai đoạn trong quy trình phát triển phần mềm được thực hiện qua các đánh giá chính thức để đảm bảo tiến trình đúng hướng Đánh giá này đóng vai trò như một điểm kiểm tra quan trọng để xác nhận rằng dự án đang đi đúng theo kế hoạch Trong mô hình phát triển phần mềm này, giai đoạn kiểm thử bắt đầu ngay sau khi hoàn thành giai đoạn lập trình, giúp đảm bảo chất lượng và phát hiện sớm các lỗi còn tồn đọng.
Hình 1: Mô hình thác nước
Mô hình này làm cho ý nghĩa việc sản xuất được rõ hơn.
Trong quá trình phát triển hệ thống dịch vụ, việc phân tích các yêu cầu và định nghĩa rõ ràng là rất quan trọng để đảm bảo sự hiểu biết chung giữa người phát triển và người tiêu dùng Hệ thống dịch vụ cần xác định các khó khăn encountered và mục tiêu cụ thể nhằm nâng cao trải nghiệm người dùng Các yếu tố này được định nghĩa một cách rõ ràng và dễ hiểu, giúp tạo ra sự phù hợp giữa mong đợi của người tiêu dùng và khả năng cung cấp của hệ thống, từ đó đảm bảo thành công cho dự án.
Trong giai đoạn thiết kế phần mềm và hệ thống, các chuyên gia xây dựng kiến trúc tổng thể của quy trình, bộ phận và yêu cầu về phần mềm cùng phần cứng để đảm bảo hệ thống hoạt động hiệu quả Thiết kế hệ thống bao gồm việc hoàn thiện tất cả các kiến trúc liên quan, tạo nền tảng vững chắc cho dự án Phần mềm được thiết kế để thể hiện các chức năng chính của hệ thống, nhằm chuyển đổi thành nhiều chương trình khả thi, đáp ứng các yêu cầu hoạt động và mở rộng trong tương lai.
Trong giai đoạn thực hiện và thử nghiệm các đơn vị phần mềm, thiết kế cần được chứng minh là gồm nhiều chương trình hoặc đơn vị nhỏ phù hợp Quá trình thử nghiệm các đơn vị giúp xác minh rằng mỗi thành phần đều đáp ứng đầy đủ các đặc tả kỹ thuật đề ra, đảm bảo chất lượng và tính chính xác của phần mềm trước khi tiến hành tích hợp.
Sau khi các chương trình riêng lẻ hoặc hệ thống tích hợp được tổng hợp và thử nghiệm toàn diện, chúng đảm bảo đáp ứng đầy đủ các yêu cầu của phần mềm Việc thử nghiệm hệ thống hoàn chỉnh giúp xác nhận tính khả thi và hiệu quả của phần mềm trước khi được cung cấp cho người tiêu dùng, đảm bảo chất lượng và độ tin cậy của sản phẩm cuối cùng.
Giai đoạn sản xuất và bảo trì thường là phần dài nhất trong chu kỳ sống của sản phẩm, trong đó phần mềm được cài đặt và sử dụng trong thực tế Bảo trì bao gồm việc sửa chữa các lỗi chưa được phát hiện trong các giai đoạn trước và cập nhật hệ thống để nâng cao hiệu suất, cũng như đáp ứng các yêu cầu mới về dịch vụ.
Chỗ yếu của mô hình này là thiếu tính linh hoạt, vì các bộ phận của dự án thường được chia thành các giai đoạn riêng biệt, gây khó khăn trong quá trình điều chỉnh và mở rộng Hệ thống phân phối đôi khi không đáp ứng đủ yêu cầu của khách hàng, ảnh hưởng đến hiệu quả của dự án Tuy nhiên, mô hình này phản ánh đúng thực tế công nghệ và vẫn giữ vai trò nền tảng trong phát triển phần mềm và phần cứng Chính vì vậy, mặc dù có những hạn chế, mô hình này vẫn là cơ sở quan trọng cho hầu hết các hệ thống công nghệ hiện nay.
Mô hình Agile
I.3.1 Giới thiệu của mô hình
Phương pháp Agile (phát triển phần mềm linh hoạt) bắt đầu xuất hiện vào giữa những năm 1990 nhằm tạo ra phần mềm có khả năng mở rộng và thích ứng theo thời gian mà không cần phải xây dựng lại từ đầu Agile tập trung vào việc phát triển phần mềm đơn giản, phù hợp với nhu cầu hiện tại của khách hàng, đồng thời có khả năng mở rộng và sẵn sàng thay đổi để đáp ứng các yêu cầu trong tương lai.
Phương pháp Agile tập trung vào việc giảm thiểu rủi ro bằng cách phát triển phần mềm trong các khung thời gian ngắn, giúp liên tục tạo ra sản phẩm hoàn chỉnh qua từng vòng lặp Mỗi vòng lặp bao gồm các bước như lấy yêu cầu, phân tích thiết kế, lập trình, kiểm thử và lập tài liệu, nhằm đảm bảo luôn có phần mềm mới sau mỗi chu kỳ Mặc dù mỗi vòng lặp có thể không đủ chức năng để tạo ra sản phẩm cuối cùng, nhưng mục tiêu là xây dựng giá trị liên tục và điều chỉnh dự án dựa trên kết quả thực tế Cuối mỗi vòng lặp, nhóm phát triển tiến hành đánh giá lại ưu tiên của dự án để tối ưu hóa tiến trình phát triển phù hợp với nhu cầu thực tế.
Phương pháp Agile nhấn mạnh vai trò quan trọng của giao tiếp thời gian thực, trong đó giao tiếp mặt đối mặt được coi là hiệu quả hơn so với các tài liệu viết Các đội phát triển theo phương pháp Agile thường hoạt động trong môi trường thuận lợi để thúc đẩy giao tiếp liên tục, gồm các lập trình viên và khách hàng hợp tác chặt chẽ để đảm bảo dự án thành công.
I.3.2 Đặc điểm của mô hình
- Chu kỳ giao hàng ngắn Phát triển rất tập trung
- Mô hình, uses case, user stories, index card, hay đặc tả chức năng được sử dụng như tài liệu để test.
- Dự án thực hiện với mô hình Agile thường có rất nhiều test unit được thực hiện bởi những người phát triển.
- Do cấu trúc năng động của mô hình này nên việc phát triển cũng cần sử dụng phương pháp kiểm thử hồi quy.
- Mô hình phát triển phần mềm này rất hoan nghênh sự thay đổi cho ứng dụng đến từ khách hàng
TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
Kiểm thử phần mềm
Lợi ích
- Cố gắng tạo ra các ca kiểm thử để chỉ ra lỗi của phần mềm được xây dựng
- Có một chương trình tốt, chi phí ít.
- Thuyết minh rằng các chức năng phần mềm tương ứng với đặc tả (xác minh).
- Yêu cầu thực thi là phù hợp (thẩm định),
- Cung cấp thêm các chỉ số độ tin cậy và chỉ số chất lượng phần mềm nói chung (thẩm định).
- Tuy nhiên, kiểm thử không thể khẳng định rằng phần mềm không có khiếm khuyết
Các giai đoạn kiểm thử và điểm xác định
Giai đoạn phát triển phần mềm là khoảng thời gian trong vòng đời dự án, trong đó các hoạt động chính như phân tích yêu cầu, thiết kế, lập trình và kiểm thử được thực hiện để xây dựng sản phẩm hoàn chỉnh.
Mốc phát triển là các điểm quan trọng đánh dấu sự chuyển đổi trong tiến trình phát triển phần mềm, giúp xác định vị trí của ứng dụng trong vòng đời của dự án Những mốc này giúp nhóm phát triển theo dõi tiến trình, đánh giá sự hoàn thành các giai đoạn và điều chỉnh kế hoạch phù hợp Việc nhận biết các mốc phát triển chính là chìa khóa để đảm bảo quá trình phát triển phần mềm diễn ra suôn sẻ, đúng tiến độ và đạt chất lượng cao.
Các giai đoạn kiểm thử và mốc:
Pre- Alpha Alpha Beta GM/Release
User Acceptance (chấp nhận sản phẩm) Thực hiện Developer Developer/
Technical Tester Tester User Định nghĩa
Kiểm thử một đơn vị code trong 1 thời gian
Lặp đi lặp lại 1 hệ thống hoàn chỉnh.
Kiểm tra các đơn vị code khi nó làm việc chung môi trường với nhau.
Kiểm thử toàn bộ chức năng hệ thống để đảm bảo sản phẩm hoạt động đúng như thiết kế Đánh giá phần mềm xem có đáp ứng đầy đủ các yêu cầu của người dùng đã đề ra hay không Kiểm tra khả năng triển khai của phần mềm vào công việc thực tế để đảm bảo tính khả thi và hiệu quả trong sử dụng.
Kết quả Ít lỗi Tìm lỗi Tìm lỗi/QC QC
Mục đích Xác nhận giá trị các modun độc lập
Tìm lỗi và biết về sản phẩm, xác nhận giá trị các yêu cầu tích hợp
Tìm lỗi, xác nhận giá tri hệ thống, luồng dữ liệu…
Xác nhận các yêu cầu của người sử dụng.
Tùy thuộc vào ứng dụng dự kiến, mà chúng ta sẽ chọn mô hình phát triển phần mềm cho phù hợp
Quá trình phát triển phần mềm theo mô hình vòng đời (SDLC) gồm nhiều giai đoạn chính, mỗi giai đoạn có các mốc và tiêu chí rõ ràng để đảm bảo tiến trình diễn ra thuận lợi Các tiêu chí và mốc quan trọng giúp xác định tiến độ và chất lượng của từng giai đoạn, từ phân tích yêu cầu đến kiểm thử và triển khai Việc tuân thủ các tiêu chí và mốc này không chỉ đảm bảo ứng dụng phát triển đúng hướng, phù hợp với mục tiêu đề ra mà còn giúp tiết kiệm thời gian, nâng cao hiệu quả và giảm thiểu rủi ro trong quá trình phát triển phần mềm.
Tổng Quan Về Kiểm Thử Phần Mềm
Tìm hiểu Testing, QA, QC
- Testing : Tiến trình thực thi chương trình để tìm ra những thiếu sót của chương trình.
Chất lượng đảm bảo (QA) là tập hợp các hoạt động được thiết lập nhằm đảm bảo quá trình phát triển và duy trì hệ thống phù hợp, từ đó đảm bảo hệ thống đáp ứng các mục tiêu đề ra QA đóng vai trò quan trọng trong việc kiểm tra và xác nhận chất lượng sản phẩm, giúp giảm thiểu lỗi và nâng cao hiệu quả của toàn bộ quy trình phát triển phần mềm Các hoạt động QA liên tục theo dõi và cải tiến quy trình, đảm bảo hệ thống hoạt động ổn định, tin cậy và đáp ứng yêu cầu khách hàng.
- Quality Control (QC): Tập hợp các hoạt động được tạo ra để đánh giá sản phẩm đang được tiến hành.
Nhóm kiểm thử
- Tìm và viết báo cáo lỗi.
- Xác định các vùng yếu của chương trình.
- Xác định các vung nguy cơ cao của chương trình.
- Giải thích những gì vừa tìm được.
II.3.2.2 Trách nhiệm của Tester
Tìm vấn đề về thiết kế.
Tìm nhiều cách hiệu quả để tìm lỗi.
- Vấn đề về giao tiếp.
Báo cáo lỗi và thiết kế lại vấn đề
Báo cáo về tiến trình kiểm thử.
Đánh giá và báo cáo tính ổn định của chương trình.
- Trách nhiệm của quản lý và team leader.
Sửa chữa kế hoạch và lịch trình kiểm thử
Dự toán công việc kiểm thử, thời gian, và tiền của ứng dụng.
Xác nhận và báo cáo tiến trình kiểm thử qua các giai đoạn các cột mốc.
Dạy cho các tester khác để tìm lỗi.
Mục tiêu của kiểm thử
II.3.3.1 Lớp tương đương và phân tích giá trị biên
- Lớp tương đương : hai lớp được gọi là tương đương nếu kết quả dự kiến của hai lớp này là như nhau.
- Biên: Điểm đánh dấu hay vùng chuyển tiếp từ 1 lớp tương đương đến 1 lớp khác gọi là biên.
Kiểm thử điều kiện biên có ưu điểm vượt trội khi lớp tương đương được sử dụng.
II.3.3.2 Thiết kế kiểm thử
- Xác định giá trị biên
- Xác định dự kiến đầu vào đầu ra
- Xác định dự kiến các lỗi với giá trị vào không phù hợp.
- Tạo bảng kiểm thử. a.Mục tiêu của kiểm thử
- Mục tiêu của kiểm thử không phải là xác minh chương trình làm việc đúng.
- Mục tiêu của kiêm thử chương trình là tìm ra các vấn đề trong phần mềm.
- Mục đích của việc tìm ra vấn đề là để sửa lại chúng cho phù hợp. b Bạn không thể kiểm thử mọi thứ , vì thế:
- Chúng ta tập trung và sử dụng thời gian test để tìm nhiều lỗi nhất có thể.
- Chúng ta cần bao phủ hết vùng của ứng dụng với thời gian xác định.
- Tìm các lỗi nghiêm trọng 1 cách nhanh nhất có thể.
Các phương pháp kiểm thử
Hai phương pháp phổ biến:
Kiểm thử hộp trắng (white box)
Kiểm thử hộp đen (black box)
II.3.4.1 Kiểm thử hộp trắng
II.3.4.1.1 Khái niệm kiểm thử hộp trắng
Kiểm thử hộp trắng, hay còn gọi là kiểm thử theo cấu trúc, là phương pháp kiểm thử phần mềm thực hiện trực tiếp trên mã nguồn để khám phá các chi tiết thủ tục và luồng thực thi Phương pháp này giúp xác định các con đường logic, trạng thái của chương trình nhằm đảm bảo tất cả các phần của mã đều được kiểm tra kỹ lưỡng Kiểm thử hộp trắng là bước quan trọng để phát hiện lỗi tại các phần code phức tạp hoặc chưa được kiểm tra, nâng cao chất lượng phần mềm và tối ưu hóa hiệu suất hoạt động.
Phương pháp kiểm thử này thường dựa trên công thức toán học và lý thuyết đồ thị để đảm bảo tính chính xác và hiệu quả trong quá trình kiểm thử phần mềm Nó được thực hiện ở cấp độ kiểm thử đơn vị, giúp xác định các trường hợp kiểm thử một cách chính xác hơn Tuy nhiên, việc xác định các trường hợp kiểm thử phù hợp không phải lúc nào cũng dễ dàng, đòi hỏi sự phân tích kỹ lưỡng và kiến thức chuyên môn cao.
- Số đường lôgíc là rất lớn Một chương trình nhỏ:
+ với 100 dòng PASCAL + với một vòng lặp
số con đường logic có thể tới: 1014.
cần 3170 năm để kiểm thử tất mọi con đường và mọi ràng buộc lôgic trên nó!
II.3.4.1.2 Đối tượng kiểm thử hộp trắng
- Cách thức: Sử dụng cấu trúc điều khiển của thiết kế thủ tục để hình thành các ca kiểm thử
Mọi lệnh được thực hiện
Mọi điều kiện được kiểm tra
Mọi chu trình được duyệt qua
Mọi cấu trúc dữ liệu được dùng
Mọi tiến trình được lần vết
II.3.4.1.3 Yêu cầu kiểm thử hộp trắng
+ Mọi con đường độc lập trong một module cần được thực hiện ít nhất một lần.
Trong quá trình xây dựng logic, mọi ràng buộc đều cần được thực hiện cả hai phía, bao gồm phía đúng và phía sai, nhằm đảm bảo tính chính xác và toàn diện của hệ thống Ngoài ra, tất cả các vòng lặp tại biên của hệ thống cũng như các biên vận hành phải được thực hiện đầy đủ để đảm bảo hoạt động suôn sẻ và ổn định của quy trình.
+ Mọi cấu trúc dữ liệu nội tại được dùng để bảo đảm tính hiệu lực của nó
II.3.4.1.4 Lý do kiểm thử hộp trắng
- Vì sao cần tốn tiền cho kiểm thử hộp trắng?
+ Các lỗi logic & giả thiết không đúng đắn tỷ lệ nghịch với xác suất để một con đường logic được thi hành.
Trong thực tế, mọi con đường lôgic đều có thể được thi hành trên một nền tảng nhất định, điều này cho thấy rằng việc xem một con đường logic nào đó là không thể thực hiện chỉ dựa trên những giả định ban đầu là không chính xác.
+ Có những sai sót chính tả có thể là ngẫu nhiên trên đường ta không kiểm tra.
II.3.4.1.5 Kiểm thử theo đường dẫn
- Các đường dẫn được xác định bằng việc xây dựng
- Các đường dẫn được xác định bằng việc xây dựng đồ thị chương trìnhđồ thị chương trình
- Mỗi trường hợp kiểm thử sẽ tương ứng với một đường dẫn
- Mỗi trường hợp kiểm thử sẽ tương ứng với một đường dẫn
- Đồ thị chương trình là một đồ thị có hướng trong đó:
- Đồ thị chương trình là một đồ thị có hướng trong đó:
+ Mỗi nút (hình tròn) biểu thị một hay một số lệnh tuần tự, hoặc thay cho điểm hội tụ các đường điều khiển.
+ Mỗi cạnh nối hai nút biểu diễn dòng điều khiển.
Nghĩa là, có một cạnh từ đỉnh i đến đỉnh j nếu câu lệnh tương ứng với
Trong đồ thị lập trình, có một cạnh từ đỉnh i đến đỉnh j khi câu lệnh tương ứng tại đỉnh j có thể được thực thi ngay sau câu lệnh tại đỉnh i Điều này nghĩa là, đỉnh j phụ thuộc vào đỉnh i trong quá trình thực thi, cho phép các câu lệnh được thực hiện theo trình tự hợp lý Hiểu rõ đặc điểm này giúp tối ưu hóa thứ tự thực thi của các câu lệnh, đảm bảo hiệu quả và chính xác trong quá trình lập trình.
+ Kết quả: đồ thị dòng
Chia mặt phẳng thành nhiều miền.
Có nút vị từ biểu thị sự phân nhánh hoặc hội nhập của các cung.
* Cách xây dựng đồ thị chương trình:
+ IF+ IF + IF-Then-Else
Hình 3: Luồng điều khiển của lập trình theo cấu trúc
Ví dụ : Vẽ đồ thị chương trình của bài toán tam giác có chương trình như sau:
Hình 4: Đồ thị chương trình của bài toán tam giác
Kiểm thử theo đường dẫn dựa vào phương pháp của Tom McCabe được
Kiểm thử theo đường dẫn dựa vào phương pháp của Tom McCabe được sử dụng cho kiểm thử đơn vị, giúp xác định các đường dẫn thực thi trong mã nguồn Tuy nhiên, phương pháp này có hạn chế là đòi hỏi người kiểm thử phải có kỹ năng lập trình vững để hiểu rõ mã nguồn và luồng điều khiển của chương trình Điều này làm tăng độ phức tạp và yêu cầu kỹ năng cao trong quá trình kiểm thử đơn vị.
II.3.4.2 Kiểm thử hộp đen
- Kiểm thử hộp đen dựa trên việc xem xét một chương trình như là một hàm ánh xạ miền giá trị dữ liệu vào thành miền kết quả ra
- Còn được gọi là kiểm thử theo chức năng
- Phương pháp kiểm thử này chỉ dựa vào các chức năng trong chương trình, bỏ qua cấu trúc bên trong của mã lệnh
+ Nhằm thuyết minh: các chức năng phần mềm đủ & vận hành đúng+ Thực hiện các phép thử qua giao diện
- Cơ sở: đặc tả, các điều kiện vào/ra và cấu trúc dữ liệu
+ Ít chú ý tới cấu trúc logic nội tại của nó
Chúng độc lập với cách thức cài đặt phần mềm, giúp khả năng kiểm thử không bị ảnh hưởng bởi quá trình cài đặt Điều này cho phép chúng ta thay đổi phương pháp cài đặt mà vẫn duy trì khả năng thực hiện các trường hợp kiểm thử một cách hiệu quả Ngoài ra, bạn có thể tiến hành kiểm thử song song với quá trình cài đặt phần mềm, giúp tiết kiệm thời gian phát triển dự án đáng kể.
Hình 5: Mô hình kiểm thử hộp đen
* Các kỹ thuật kiểm thử hộp đen:
- Kiểm thử theo giá trị biên
- Kiểm thử theo các lớp tương đương
- Kiểm thử dựa vào bảng quyết định
- Kiểm thử dựa vào đồ thị nguyên nhân-kết quả
- Kiểm thử hộp đen nhằm tìm ra các loại sai:
+ Chức năng thiếu hoặc không đúng đắn.
+ Sai trong cấu trúc hoặc trong truy cập dữ liệu ngoài.
+ Sai thực thi chức năng.
+ Sai khởi đầu hoặc kết thúc module.
- Kiểm thử hộp đen tập trung trả lời các câu hỏi:
+ Hiệu lực chức năng (chức năng, hiệu suất) được kiểm thử đến đâu? + Lớp đầu vào nào cho các ca kiểm thử tốt?
+ Sự nhạy cảm của module với giá trị vào nào?
+ Các biên của lớp dữ liệu được cô lập chưa?
+ Dung thứ lỗi đối với các nhịp điệu/khối lượng dữ liệu như thế nào? + Tổ hợp dữ liệu đặc biệt ảnh hưởng gì đến hoạt động hệ thống.
II.3.4.2.3 Tiêu chuẩn Áp dụng kỹ thuật kiểm thử hộp đen, cần tìm ra các ca kiểm thử thoả mãn các tiêu chuẩn:
+ Rút gọn (ít, đơn giản).
+ Cho biết về sự tồn tại hoặc vắng mặt của một lớp sai (không phải về một sai cụ thể gắn với một kiểm thử riêng biệt)
II.3.4.2.4 Kiểm thử theo giá trị biên Khi một hàm chức năng F với hai biến x1 và x2 được cài đặt trong
Khi một hàm chức năng F với hai biến x1 và x2 được cài đặt trong chương trình, các biến đầu vào này sẽ có các giới hạn rõ ràng Việc xác định giới hạn cho x1 và x2 là rất quan trọng để đảm bảo tính chính xác và hiệu quả của hàm chức năng Điều này giúp tối ưu hóa quá trình xử lý dữ liệu và nâng cao hiệu suất của chương trình Hiểu rõ các giới hạn của biến đầu vào góp phần đảm bảo tính an toàn và độ tin cậy của hệ thống.
Các miền giá trị của biến x1 và x2 được xác định bởi các đoạn [a, b] và [c, d], giúp xác định phạm vi các giá trị mà các biến này có thể nhận Ý tưởng chủ đạo của kiểm thử theo giá trị biên là sử dụng các giá trị của biến ở các điểm quan trọng như giá trị nhỏ nhất, nhỏ hơn giá trị nhỏ nhất, giá trị bình thường, lớn hơn giá trị nhỏ nhất, và lớn nhất, nhằm đảm bảo kiểm thử bao phủ các trường hợp biên và biên giới của hệ thống Phương pháp này giúp xác định tính đúng đắn của hệ thống một cách toàn diện hơn, đặc biệt trong các tình huống có các giới hạn hoặc ràng buộc về giá trị biến.
Hình 6: Kiểm thử theo giá trị biên với một biến a ≤ x ≤ b x a b
X(min) X(min+) X(nom) X(max-) X(max)
Hình 7: Kiểm thử theo giá trị biên với hai biến x1 và x2
* Kiểm thử theo giá trị biên đầy đủ
- Là một mở rộng của kiểm thử theo giá trị biên bao gồm các giá trị nhỏ
Kiểm thử biên mở rộng là phương pháp kiểm thử bao gồm các giá trị nhỏ hơn giá trị nhỏ nhất và lớn hơn giá trị lớn nhất của phạm vi dữ liệu chính, nhằm đảm bảo hệ thống xử lý chính xác cả trong các trường hợp vượt quá giới hạn Phương pháp này giúp phát hiện các lỗi liên quan đến giới hạn đầu vào, tăng độ tin cậy của phần mềm Việc thực hiện kiểm thử biên mở rộng giúp kiểm tra khả năng xử lý ngoại lệ của hệ thống khi gặp dữ liệu vượt ra ngoài phạm vi dự kiến Đây là bước cần thiết để đảm bảo phần mềm hoạt động ổn định và chính xác trong mọi tình huống thực tế.
- Là một hình thức kiểm thử với lỗi để biết được chương trình sẽ thực
Kiểm thử lỗi là một phương pháp kiểm thử phần mềm nhằm xác định cách chương trình phản ứng khi gặp dữ liệu đầu vào có lỗi, giúp đảm bảo tính ổn định và độ chính xác của ứng dụng Phương pháp này giúp phát hiện các lỗi tiềm ẩn trong hệ thống và đảm bảo rằng chương trình xử lý các dữ liệu không hợp lệ một cách hợp lý Việc kiểm thử lỗi đóng vai trò quan trọng trong quy trình kiểm tra chất lượng phần mềm, tăng độ tin cậy và trải nghiệm người dùng.
- Có thể không được áp dụng với một số ngôn ngữ lập trình có ràng buộc
- Có thể không được áp dụng với một số ngôn ngữ lập trình có ràng buộc kiểukiểu
Hình 8: Kiểm thử theo giá trị biên đầy đủ với 1 biến a ≤ x ≤ b x2 a b c d x1 x a b x1 x2 a b c d
Hình 9: Kiểm thử theo giá trị biên đầy đủ với 2 biến x1 và x2
* Số lượng trường hợp kiểm thử:
* Số lượng trường hợp kiểm thử:
- Kiểm thử theo giá trị biên: 4n+1
- Kiểm thử theo giá trị biên: 4n+1
- Kiểm thử theo giá trị biên đầy đủ: 6n+1
- Kiểm thử theo giá trị biên đầy đủ: 6n+1
Với n là số lượng các biến
* Nhược điểm của kiểm thử theo giá trị biên
* Nhược điểm của kiểm thử theo giá trị biên
- Các biến phải độc lập với nhau
- Các biến phải độc lập với nhau
- Không áp dụng được cho các biến thuộc kiểu logic
- Không áp dụng được cho các biến thuộc kiểu logic
II.3.4.2.5 Kỹ thuật phân hoạch tương đương (kiểm thử theo các lớp tương đương)
+ Nguyên tắc: chia miền vào của chương trình thành các lớp dữ liệu để lập ra các ca kiểm thử cho mỗi lớp đó.
+ Cơ sở: dữ liệu trong 1 lớp tương đương tác động như nhau lên chương trình, tạo ra cùng một trạng thái: đúng hay sai của chương trình
+ Mục tiêu: tìm ra 1 ca kiểm thử để bộc lộ 1 lớp sai, từ đó rút gọn số ca kiểm thử cần phát triển.
- Ca kiểm thử được thiết kế cho từng lớp tương đương
* Các trường hợp kiểm thử theo kỹ thuật phân hoạch tương đương:
+ Kiểm thử theo phân hoạch tương đương- lỗi đơn
+ Kiểm thử theo phân hoạch tương đương- lỗi kết hợp
+ Kiểm thử theo phân hoạch tương đương- lỗi đơn đầy đủ
+ Kiểm thử theo phân hoạch tương đương- lỗi kết hợp đầy đủ
- Hãy xem xét một hàm F với các biến đầu vào x1, x2 có giá trị được giới hạn và nằm trong các khoảng sau:
a