Các mức kiểm thử test levels Các mức kiểm thử là tập hợp các hoạt động test được thực hiện ở một giaiđoạn phát triển cụ thể của sản phẩm, ví dụ từ lúc vài chức năng nhỏ được lập trình,ch
TÌM HIỂU VỀ KIỂM THỬ PHẦN MỀM
Kiểm thử phần mềm là gì?
Kiểm thử phần mềm là quá trình quan trọng nhằm phát hiện và sửa lỗi, đảm bảo phần mềm hoạt động chính xác và đáp ứng đầy đủ yêu cầu của khách hàng Hoạt động này không chỉ giúp nâng cao chất lượng sản phẩm mà còn cung cấp cái nhìn độc lập, từ đó đánh giá và nhận diện các rủi ro tiềm ẩn khi triển khai phần mềm.
Các phương pháp kiểm thử phần mềm:
Kiểm thử hộp trắng (white box testing) là phương pháp kiểm thử trong đó cấu trúc mã và thuật toán được phân tích kỹ lưỡng Người kiểm thử có quyền truy cập vào mã nguồn của chương trình, cho phép họ thực hiện các kiểm tra chi tiết và đảm bảo chất lượng phần mềm.
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
Mục tiêu kiểm thử phần mềm có thể khác nhau tùy thuộc vào quy mô dự án, loại hình công ty và giai đoạn phát triển, nhưng một số mục tiêu kiểm thử thường gặp bao gồm đảm bảo chất lượng sản phẩm, phát hiện lỗi sớm, cải thiện trải nghiệm người dùng và tối ưu hóa hiệu suất hệ thống.
Kiểm tra phần mềm để đảm bảo rằng nó đáp ứng đầy đủ các yêu cầu đã được mô tả, đồng thời xác nhận rằng sản phẩm đã hoàn thiện và hoạt động đúng như mong đợi của người dùng cũng như các bên liên quan khác.
Kiểm thử đóng vai trò quan trọng trong việc ngăn ngừa lỗi bằng cách xem xét kỹ lưỡng tài liệu mô tả yêu cầu và thiết kế hệ thống, bao gồm cả mã nguồn Quá trình này giúp phát hiện lỗi sớm, từ đó cải thiện chất lượng sản phẩm.
Kiểm thử phần mềm là quá trình quan trọng nhằm nâng cao chất lượng sản phẩm, đồng thời tăng cường sự tin tưởng của khách hàng Qua việc phát hiện và sửa lỗi, kiểm thử không chỉ giúp cải thiện hiệu suất của phần mềm mà còn đảm bảo rằng các lỗi đã được khắc phục sẽ được kiểm tra lại để đạt được sự hoàn thiện tối ưu.
Cung cấp thông tin đầy đủ cho các bên liên quan, bao gồm quản lý dự án và khách hàng, là yếu tố quan trọng giúp họ đưa ra quyết định chính xác về việc phát hành phần mềm.
Giảm thiểu rủi ro do lỗi của phần mềm gây ra trong quá trình sử dụng thực tế
Ngoài việc kiểm thử để đảm bảo hệ thống đáp ứng các tiêu chuẩn quốc tế như ISO và CMMI, còn có các mục tiêu khác như tuân thủ các quy định khu vực, điển hình là GDPR (Quy định Bảo vệ Dữ liệu Chung).
Các mức kiểm thử (test levels)
Các mức kiểm thử là tập hợp các hoạt động kiểm tra diễn ra trong từng giai đoạn phát triển của sản phẩm, từ khi chỉ có một số chức năng nhỏ được lập trình cho đến khi sản phẩm hoàn thiện và có khả năng tích hợp với các hệ thống khác Dưới đây là một số mức kiểm thử cơ bản.
1.2.1 Kiểm thử (mức) đơn vị (unit testing) Đây là mức kiểm thử thấp nhất Ở mức kiểm thử này, các thành phần nhỏ nhất của một hệ thống phần mềm như class, function, hay module sẽ được kiểm thử riêng lẻ Phần lớn test case (các trường hợp kiểm thử) ở mức này sẽ gọi trực tiếp đối tượng được kiểm thử (như class, function… nào đó) trong code (mã nguồn) nên cần phải có sự hỗ trợ của các thư viện (unit test framework phổ biến như XUnit, JUnit, Nunit, Jest,… đa phần ngôn ngữ lập trình nào cũng có nhiều thư viện hỗ trợ cho unit testing) để giả lập các cụm chức năng (class, function,…) liên quan nhằm tách riêng phần cần kiểm thử.
Phát hiện lỗi trong giai đoạn kiểm thử sớm giúp tiết kiệm thời gian và chi phí, ngăn ngừa các lỗi tích hợp và sự cố khi đưa sản phẩm vào sử dụng thực tế Nếu lỗi không được phát hiện kịp thời, việc sửa chữa sẽ tốn công sức, bao gồm việc kiểm tra lại (confirmation testing) để xác nhận lỗi đã được khắc phục, đồng thời thực hiện kiểm thử hồi quy (regression testing) để đảm bảo rằng quá trình sửa lỗi không tạo ra các vấn đề mới.
Để kiểm thử đơn vị của code màu vàng, chúng ta cần phải giả lập các đơn vị liên quan trực tiếp đến nó, được biểu thị bằng màu xanh tím.
Hình 1.2.1: Ví dụ về kiểm thử đơn vị
Lập trình viên (dev) chịu trách nhiệm thực hiện kiểm thử đơn vị, dựa vào mã nguồn và tài liệu mô tả yêu cầu chi tiết (SRS) để xác định các trường hợp cần kiểm thử Tài liệu SRS cung cấp thông tin bổ sung, giúp dev xác định kết quả mong đợi cho các test case.
Chương trình kiểm tra số nguyên tố đơn giản trong hình dưới đây không cần giả lập Hai trường hợp kiểm tra cơ bản để xác định một số có phải là số nguyên tố hay không được trình bày rõ ràng.
1 số không phải là số nguyên tố.
Hình 1.2.2: Test case cơ bản kiểm tra số nguyên tố
1.2.2 Kiểm thử tích hợp (integration testing) Ở giai đoạn này, các chức năng (hoặc class, function,…) đã được phát triển và kiểm thử xong, đã đến lúc tích hợp chúng lại với nhau Và phải kiểm thử sự tương tác qua lại giữa các thành phần này Tương tự như vậy, chúng ta cũng cần kiểm thử sự tích hợp giữa các hệ thống khác nhau Hai mức kiểm thử tích hợp thường gặp sau:
Kiểm thử tích hợp là quá trình kết hợp các thành phần hoặc module trong một hệ thống, như kiểm tra sự tương tác giữa các API trong ứng dụng web hoặc ứng dụng di động.
Thường thì lập trình viên (dev) sẽ phụ trách thực hiện mức kiểm thử tích hợp này, hay gọi chung là integration testing.
Ví dụ kiểm thử tích hợp các thành phần trong một hệ thống
Hình 1.2.3: Kiểm thử tích hợp các thành phần trong một hệ thống
Kiểm thử tích hợp hệ thống là quá trình cần thiết khi các hệ thống độc lập tương tác với nhau Mục tiêu của việc này là đảm bảo rằng các hệ thống đáp ứng đúng các luồng nghiệp vụ mong muốn.
Hệ thống bán hàng thương mại điện tử thường sử dụng dịch vụ thanh toán trực tuyến từ bên thứ ba hoặc phát triển hệ thống thanh toán riêng Việc kiểm thử các luồng thanh toán cơ bản như thanh toán thành công và không thành công là rất quan trọng Ngoài ra, cần kiểm thử tích hợp giữa các sàn thương mại điện tử như Tiki, Lazada và các dịch vụ giao hàng như Giao hàng nhanh, Giao hàng tiết kiệm.
Thường thì Tester (QC/QA) là người thực hiện việc kiểm thử ở mức tích hợp các hệ thống này.
Một số phương pháp tiếp cận thường gặp để kiểm kiểm thử tích hợp:
Kiểm thử tích hợp Big-Bang là phương pháp kết hợp tất cả các thành phần cần kiểm thử cùng một lúc, thực hiện kiểm thử theo các kịch bản và trường hợp cần thiết Phương pháp này thường được sử dụng cho các hệ thống đơn giản, nhỏ và ít thành phần Tuy nhiên, khi áp dụng cho các hệ thống lớn, việc xác định vị trí lỗi để sửa chữa sẽ gặp nhiều khó khăn.
Kiểm thử tích hợp theo hướng từ trên xuống (Top-Down integration testing) là phương pháp kiểm thử bắt đầu từ các đơn vị cao nhất trong hệ thống, sau đó tiếp tục kiểm tra từng đơn vị thấp hơn theo luồng điều khiển Quá trình này đảm bảo rằng các chức năng chính được xác minh trước, giúp phát hiện lỗi sớm và cải thiện chất lượng của hệ thống.
Kiểm thử tích hợp Bottom-Up là phương pháp mà trong đó các đơn vị cấp thấp được kiểm tra trước, sau đó mới đến các đơn vị cấp cao hơn Phương pháp này trái ngược với kiểm thử tích hợp Top-Down, nơi các đơn vị cấp cao được kiểm tra trước.
Kiểm thử tích hợp Sandwich/Hybrid là sự kết hợp giữa hai phương pháp kiểm thử tích hợp Top-Down và Bottom-Up Trong phương pháp này, các đơn vị cấp cao được kiểm tra đồng thời với việc tích hợp các đơn vị cấp thấp với các đơn vị cấp cao hơn để tiến hành kiểm thử.
Trên đây là phương pháp tiếp cận dựa vào cấu trúc/kiến trúc của mã nguồn.Ngoài ra chúng ta có thể tích hợp dựa vào luồng chức năng.
Hình 1.2.4: Phương pháp tiếp cận kiểm thử tích hợp top-down
1.2.3 Kiểm thử hệ thống (system testing)
Sau khi hoàn thiện phát triển hệ thống, việc kiểm thử các luồng xử lý chức năng và các khía cạnh phi chức năng như hiệu năng, bao gồm kiểm thử tải, là rất cần thiết Đồng thời, đánh giá tính khả dụng của hệ thống cũng cần được thực hiện để đảm bảo rằng nó dễ sử dụng và dễ hiểu cho tất cả người dùng.
Các loại kiểm thử (test types)
Các loại kiểm thử bao gồm các nhóm hoạt động nhằm đạt được mục đích cụ thể, như đánh giá chức năng, hiệu năng và các khía cạnh khác Dưới đây là một số loại kiểm thử phổ biến.
1.3.1 Kiểm thử chức năng (functional testing)
Các hoạt động kiểm thử chức năng nhằm xác định xem hệ thống có đáp ứng đúng yêu cầu nghiệp vụ hay không Quy trình này tập trung vào việc đánh giá tính đúng đắn, độ chính xác và sự phù hợp của hệ thống với người dùng, cùng với một số khía cạnh khác Kiểm thử chức năng có thể được thực hiện ở mọi cấp độ kiểm thử.
Dưới đây là 2 cách tiếp cận để kiểm thử chức năng:
Requirements-based testing relies on system documentation, such as the Software Requirements Specification (SRS), to create test cases and conduct testing effectively This approach ensures that testing is aligned with the specified requirements, enhancing the overall quality and reliability of the software.
Cách tốt để bắt đầu là:
Sử dụng nội dung của đặc tả yêu cầu để xác định phạm vi kiểm thử (danh sách các hạng mục cần kiểm thử và sẽ không kiểm thử)
Chúng ta cần xác định mức độ ưu tiên cho các yêu cầu dựa trên rủi ro và tầm quan trọng trong kiểm thử Việc này sẽ đảm bảo rằng những chức năng quan trọng nhất được kiểm thử trước tiên.
Kiểm thử dựa trên quy trình nghiệp vụ sử dụng kiến thức về quy trình để viết test case và thực hiện kiểm thử Bằng cách phân tích quy trình nghiệp vụ, chúng ta có thể xác định các kịch bản thực tế, từ đó phát hiện sớm các lỗi liên quan đến xử lý nghiệp vụ.
Khi kiểm thử chức năng chuyển tiền liên ngân hàng, có thể phát hiện lỗi khi ngân hàng của người nhận đang trong tình trạng bảo trì, dẫn đến việc server không thể liên lạc Ngoài ra, tình trạng xử lý chậm do quá tải hệ thống cũng có thể xảy ra, đặc biệt là vào cuối tuần.
1.3.2 Kiểm thử phi chức năng (non-functional testing)
Các hoạt động kiểm thử nhằm đánh giá các đặc điểm chất lượng và thuộc tính phi chức năng như hiệu năng, bảo mật và tính dễ sử dụng.
Kiểm thử hiệu năng tương tự như kiểm thử chức năng và được thực hiện ở tất cả các mức kiểm thử Khi áp dụng kiểm thử hiệu năng ở mức hệ thống, kết quả thường sẽ được trả về.
Kiểm thử tải (load testing) là quá trình thực hiện các hoạt động kiểm thử nhằm đánh giá khả năng chịu tải của hệ thống, tức là xác định số lượng yêu cầu mà hệ thống có thể xử lý đồng thời Để thực hiện kiểm thử hiệu năng, các công cụ hữu ích như JMeter và K6 thường được sử dụng.
Hoặc kiểm thử tính khả dụng (usability testing) là các hoạt động đánh giá xem hệ thống dễ sử dụng như thế nào.
1.3.3 Kiểm thử bảo trì (maintenance testing)
"Kiểm thử bảo trì" đề cập đến các hoạt động kiểm thử được thực hiện trên hệ thống đang hoạt động và sử dụng thực tế Các kỹ thuật và phương pháp kiểm thử không khác biệt nhiều so với kiểm thử trong quá trình phát triển phần mềm Tuy nhiên, có hai khái niệm kiểm thử quan trọng cần chú ý.
Kiểm thử xác nhận (Confirmation testing) là quy trình kiểm tra nhằm xác định xem lỗi (bug/defect) đã được sửa chữa đúng cách hay chưa, cũng như đánh giá xem các thay đổi yêu cầu đã được thực hiện đúng theo mong đợi Kiểm thử này được tiến hành tại các vị trí có sự thay đổi đã được thực hiện.
Kiểm thử hồi quy (Regression testing) là quá trình đánh giá các khu vực không thay đổi để xác định xem chúng có bị ảnh hưởng bởi các thay đổi hoặc sửa lỗi trong hệ thống hay không Thuật ngữ “regression” ám chỉ những tác dụng phụ không mong muốn phát sinh khi thực hiện thay đổi mã nguồn Do đó, kiểm thử hồi quy tập trung vào việc phát hiện những tác dụng phụ này Thông thường, các trường hợp kiểm thử cho loại kiểm thử này được tự động hóa (automated test case) vì chúng cần được thực hiện nhiều lần trong suốt quá trình phát triển và bảo trì phần mềm, bao gồm việc thêm tính năng mới hoặc sửa đổi các tính năng hiện có.
Trong quá trình phát triển phần mềm, các khái niệm kiểm thử áp dụng cho các module đã hoàn thiện trước đó Khi có thay đổi liên quan đến code hoặc chức năng, cần thực hiện kiểm thử lại để đảm bảo mọi thứ vẫn hoạt động bình thường (kiểm thử hồi quy) Bên cạnh đó, việc xác nhận các yêu cầu mới và kiểm tra sửa lỗi cũng cần được thực hiện để đảm bảo tính chính xác (kiểm thử xác nhận).
Ví dụ về phạm vi kiểm thử của confirmation testing và regression testing.
Quy trình kiểm thử phần mềm
Quy trình kiểm thử phần mềm thay đổi tùy thuộc vào quy mô và tính cấp thiết của dự án, nhưng thường bao gồm 5 bước cơ bản.
1.4.1 Lập kế hoạch và kiểm soát
Lập kế hoạch kiểm thử là quá trình tạo tài liệu mô tả phương pháp tổng thể và các mục tiêu cần kiểm tra Quá trình này bao gồm việc xem xét cơ sở kiểm thử, xác định các điều kiện dựa trên phân tích các mục thử, viết các trường hợp kiểm thử và thiết kế môi trường kiểm thử Ngoài ra, tiêu chí hoàn thành được xác định để đánh giá khi nào quá trình kiểm thử có thể coi là hoàn tất ở bất kỳ giai đoạn nào.
Kiểm soát là quá trình so sánh tiến độ thực tế với kế hoạch đã đề ra và báo cáo tình trạng, bao gồm các sai lệch so với kế hoạch Hoạt động này liên quan đến việc thực hiện các biện pháp cần thiết nhằm đạt được mục tiêu của dự án.
Mục đích của bước này là:
Xác định phạm vi, rủi ro và các mục tiêu test
Xác định các tài nguyên test cần thiết như con người, môi trường, v.v.
Lên lịch trình cho các nhiệm vụ phân tích và thiết kế, thực hiện, và đánh giá test
1.4.2 Phân tích và thiết kế
Phân tích và thiết kế kiểm thử có các nhiệm vụ chính sau:
Khi xem xét cơ sở test, cần tập trung vào các thông tin quan trọng như yêu cầu, đặc điểm thiết kế, phân tích rủi ro, kiến trúc và giao diện để đảm bảo tính toàn diện và hiệu quả của quy trình kiểm thử.
Xác định các điều kiện test
Thiết kế các bài test
Thiết kế môi trường thử test, thiết lập và xác định cơ sở hạ tầng và công cụ cần thiết
Kiểm thử là quá trình kiểm tra hệ thống máy tính thông qua phương pháp thủ công hoặc sử dụng công cụ tự động Mục đích chính của việc triển khai kiểm thử là đảm bảo chất lượng và hiệu suất của hệ thống.
Tiến hành các trường hợp test bằng cách sử dụng các kỹ thuật và tạo dữ liệu cho các thử nghiệm đó
Để thực hiện kiểm thử phần mềm hiệu quả, việc tạo ra các bộ kiểm thử từ các trường hợp test là rất quan trọng Bộ kiểm thử bao gồm một tập hợp các trường hợp test được thiết kế để đảm bảo phần mềm hoạt động đúng như mong đợi.
Thực hiện lại các trường hợp test không thành công trước đó để xác nhận bản sửa lỗi
Ghi lại kết quả của việc thực hiện test Ở đó nhật ký kiểm thử ghi lại trạng thái của trường hợp test (đạt / không đạt)
So sánh kết quả thực tế với kết quả mong đợi
1.4.4 Đánh giá tiêu chí hoàn thành và báo cáo Đánh giá tiêu chí hoàn thành là quá trình xác định thời điểm dừng kiểm thử.
Việc đánh giá tiêu chí hoàn thành phụ thuộc vào phạm vi mã code, chức năng và rủi ro liên quan Ngoài ra, các yếu tố như rủi ro kinh doanh, chi phí, thời gian và sự khác biệt giữa các dự án cũng cần được xem xét.
Đánh giá xem có cần test thêm hoặc tiêu chí hoàn thành đã chỉ định có cần thay đổi hay không
Viết một báo cáo tóm tắt kiểm thử cho các bên liên quan
Quy trình hoàn tất kiểm thử diễn ra khi phần mềm đã sẵn sàng để bàn giao Tuy nhiên, kiểm thử cũng có thể bị ngừng lại vì một số lý do khác nhau.
Khi dự án bị hủy bỏ
Khi đạt được một số mục tiêu
Khi bản cập nhật hoặc release bảo trì hoàn thành
Bước này có các nhiệm vụ chính sau:
Kiểm tra xe sản phẩm được bàn giao chưa, theo kế hoạch nào, và để đảm bảo rằng tất cả các báo cáo sự cố đã được giải quyết
Hoàn thiện và lưu trữ phần mềm kiểm thử như scripts, môi trường test, v.v để sử dụng lại sau này
Bàn giao phần mềm kiểm thử cho bên bảo trì
Đánh giá cách test đã thực hiện và rút kinh nghiệm cho các bản release và dự án trong tương lai
Việc thực hiện hoàn hảo toàn bộ quy trình từ lập kế hoạch đến thực hiện và hậu kỳ test có thể gặp nhiều khó khăn Tuy nhiên, xác định quy trình và cải thiện việc kiểm thử là bước quan trọng để kiểm soát chất lượng sản phẩm Hiểu rõ mục đích và các bước của quy trình sẽ giúp đơn giản hóa kiểm thử phần mềm.
KIỂM THỬ HỘP TRẮNG (WHITEBOX TESTING)
Kiểm thử hộp trắng là gì?
Kiểm thử Hộp Trắng, hay còn gọi là Clear Box Testing, Open Box Testing, Glass Box Testing, Transparent Box Testing, Code-Based Testing hoặc Structural Testing, là một phương pháp kiểm thử phần mềm mà trong đó người kiểm tra có hiểu biết về cấu trúc nội bộ và thiết kế của hệ thống Trong quá trình kiểm thử, tester lựa chọn đầu vào để thực hiện các đường dẫn trong mã nguồn và xác định đầu ra phù hợp Để thực hiện kiểm thử hộp trắng hiệu quả, kiến thức lập trình và hiểu biết về cách thực hiện là rất cần thiết.
Kiểm thử hộp trắng là quá trình phân tích dữ liệu và điều khiển dòng thông tin trong phần mềm, bao gồm việc kiểm tra mã thực hành, xử lý ngoại lệ và phát hiện lỗi trình bày Mục tiêu của kiểm thử này là đánh giá các hành động của phần mềm mà không có định hướng trước, từ đó cải thiện chất lượng và hiệu suất của hệ thống.
Mục đích của kiểm thử hộp trắng (White box testing) là đảm bảo rằng mọi câu lệnh và điều kiện trong ứng dụng đều được thực hiện chính xác, với kết quả đầu ra như mong đợi Trong quá trình này, người kiểm thử sẽ xác minh luồng hoạt động của ứng dụng bằng cách kiểm tra một loạt đầu vào đã được xác định trước, nhằm xác định xem đầu ra có khớp với kỳ vọng hay không Nếu đầu ra không phù hợp với mong đợi, điều này cho thấy sản phẩm có thể đang gặp lỗi.
Để thực hiện kiểm thử hộp trắng, hiểu biết về lập trình và công nghệ thông tin là điều kiện tiên quyết cho tester Thông thường, các nhà phát triển (Developers) sẽ đảm nhiệm nhiệm vụ thực hiện kiểm thử White box.
Phương pháp Kiểm tra Hộp trắng áp dụng cho các mức độ kiểm tra phần mềm sau đây:
Unit Testing(Kiểm thử đơn vị): Để kiểm tra đường dẫn trong một đơn vị.
Integration Testing(Test tích hợp): Để kiểm tra đường dẫn giữa các đơn vị.
System Testing(Test hệ thống): Để kiểm tra các đường dẫn giữa các hệ thống con.
Tuy nhiên, nó là chủ yếu áp dụng cho các kiểm thử đơn vị
Các loại kiểm thử hộp trắng
White box testing có 2 loại kiểm thử chính: Kiểm thử đơn vị (Unit Testing) và Kiểm tra rò rỉ bộ nhớ (Testing for Memory Leaks)
2.2.1 Kiểm thử đơn vị (Unit Testing)
Kiểm thử đơn vị là quá trình kiểm tra từng module nhỏ trong hệ thống để đảm bảo rằng mỗi thành phần của phần mềm hoạt động đúng với thiết kế Đây là loại kiểm thử đầu tiên được thực hiện trên ứng dụng, giúp phát hiện lỗi dễ dàng và tiết kiệm chi phí cho dự án Thực hiện kiểm thử đơn vị chủ yếu là các lập trình viên hoặc tester có kinh nghiệm, họ sẽ viết mã, phát triển các chức năng riêng lẻ và kiểm tra lại để đảm bảo tính chính xác trước khi chuyển sang giai đoạn tiếp theo.
Hình 2.2.1: Unit testing là một loại của White box testing
2.2.2 Kiểm tra rò rỉ bộ nhớ (Testing for Memory Leaks)
Rò rỉ bộ nhớ là nguyên nhân chính làm giảm hiệu suất của ứng dụng Để khắc phục vấn đề này, các nhà phát triển cần hợp tác với chuyên gia QA có kinh nghiệm trong việc phát hiện rò rỉ bộ nhớ, nhằm đảm bảo quá trình kiểm thử hiệu quả Việc này rất quan trọng để duy trì chất lượng sản phẩm và nâng cao trải nghiệm người dùng.
Ưu & nhược điểm kiểm thử hộp trắng
Ngoài những ưu điểm nổi bật, White box testing vẫn có những nhược điểm cần được cải thiện trong tương lai.
2.3.1 Ưu điểm của White box testing
Tối ưu hóa mã bằng cách tìm lỗi ẩn.
Tự động hóa dễ dàng các trường hợp kiểm thử
Kiểm tra kỹ lưỡng hơn vì tất cả các đường dẫn mã thường được bao phủ.
Kiểm thử phần mềm có thể bắt đầu ngay từ giai đoạn đầu của quy trình phát triển, ngay cả khi giao diện đồ họa người dùng (GUI) chưa được hoàn thiện.
2.3.2 Nhược điểm của White box testing
Đòi hỏi nguồn lực chuyên nghiệp có kiến thức và tay nghề cao về lập trình.
Việc kiểm tra chi tiết cấu trúc và thuật toán bên trong sản phẩm tốn nhiều thời gian, đặc biệt đối với các ứng dụng có cấu trúc hệ thống lớn, yêu cầu thời gian kiểm tra đầy đủ hơn.
Kiểm thử diễn ra khi sản phẩm chưa được hoàn thiện nên các công cụ phục vụ cho mọi loại triển khai/nền tảng thường không sẵn có.
Kiểm tra hộp trắng được đánh giá khá phức tạp và tốn kém.Developers không kiểm tra hộp trắng chi tiết có thể dẫn đến lỗi sản xuất.
Các Phương Pháp Kiểm Thử Hộp Trắng
2.4.1 Kiểm thử đường cơ bản – Đồ thị dòng
Kỹ thuật kiểm thử hộp trắng do Tom McCabe giới thiệu, được gọi là đồ thị dòng, tương tự như đồ thị luồng điều khiển của chương trình.
Phương pháp miêu tả thuật giải là một trong nhiều cách thức giúp chúng ta hiểu rõ hơn về các thành phần của thuật giải và mối quan hệ giữa chúng Phương pháp này mang tính trực quan, giúp người học dễ dàng nhận diện và nắm bắt cách thức thực hiện các thành phần trong thuật giải.
Kỹ thuật đường cơ bản – đồ thị dòng có thể giúp những người thiết kế ca kiểm thử nhận được một độ phức tạp của 1 logic thủ tục.
Gồm 2 loại thành phần : các nút và các cung nối kết giữa chúng.
Các loại nút trong đồ thị dòng điều khiển :
Hình 2.4.1: Các loại nút trong đồ thị dòng điều khiển
Các kiểu cấu trúc thành phần đồ thị dòng :
Hình 2.4.2: Các kiểu cấu trúc thành phần đồ thị dòng
Đồ thị dòng điều khiển nhị phân chỉ chứa các nút quyết định nhị phân và có thể chi tiết hóa từ bất kỳ đồ thị dòng điều khiển nào Độ phức tạp Cyclomatic C, ký hiệu là V(G), được tính bằng các công thức: V(G) = E – N + 2 (với E là số cung và N là số nút) hoặc V(G) = P + 1 cho đồ thị dòng điều khiển nhị phân, trong đó P là số nút quyết định Cyclomatic C đại diện cho số đường thi hành tuyến tính độc lập của TPPM cần được kiểm thử.
2.4.2 Kiểm thử dựa trên luồng điều khiển
Đường thi hành (Execution path) là kịch bản thực thi của một đơn vị phần mềm, bao gồm danh sách có thứ tự các lệnh được thực hiện trong một lần chạy cụ thể Nó bắt đầu từ điểm nhập và kết thúc tại điểm kết thúc của đơn vị phần mềm.
Mỗi TPPM có từ 1 đến n (có thể rất lớn) đường thi hành khác nhau.
Mục tiêu của phương pháp kiểm thử luồng điều khiển là đảm bảo rằng tất cả các đường thi hành của đơn vị phần mềm đều hoạt động chính xác Tuy nhiên, thực tế cho thấy việc đạt được mục tiêu này đòi hỏi nhiều công sức và thời gian, ngay cả đối với những đơn vị phần mềm có kích thước nhỏ.
Thí dụ đoạn code sau : for (i=1; i