KIỂM TRA PHẦN MỀM LÀ GÌ?

Thực ra KTPM là công việc mà bất cứ người nào từng tham gia phát triển phần mềm (PTPM) đều biết và từng làm. Theo nghĩa thông thường nhất, KTPM bao gồm việc “chạy thử” PM hay một chức năng của PM, xem nó “chạy” đúng như mong muốn hay không. Việc kiểm tra này có thể thực hiện từng chặng, sau mỗi chức năng hoặc module được phát triển, hoặc thực hiện sau cùng, khi PM đã được phát triển hoàn tất.

KTPM đứng ở vị trí hết sức nhạy cảm, nó là bước đệm giữa giai đoạn xây dựng PM và sử dụng PM, trước khi giao sản phẩm hoàn chỉnh cho khách hàng. Bạn có thể tham khảo bài “Tổng quan các mô hình phát triển phần mềm” trong TGVT A số tháng 8/2005 (ID: A0508_106) để biết vị trí của KTPM trong các mô hình PTPM.

Hình 1: 4 mức độ cơ bản của kiểm tra phần mềm

CÁC MỨC ĐỘ CỦA KTPM

Thực tế, KTPM không đơn giản như nhiều người thường nghĩ, công việc này có nhiều mức độ khác nhau và có mối tương quan với các chặng phát triển trong dự án PTPM. Hình 1 cho thấy 4 mức độ cơ bản của KTPM và hình 2 cho thấy mối tương quan với các chặng PTPM trong mô hình V-model.

Phần sau sẽ làm rõ chi tiết về các mức độ KTPM, do một số thuật ngữ không có từ tương đương sát nghĩa trong tiếng Việt, mặt khác để các bạn tiện tham khảo sau này, chúng tôi xin giữ nguyên một số thuật ngữ gốc tiếng Anh.

1. Unit Test – Kiểm tra mức đơn vị

Để có thể hiểu rõ về Unit Test, khái niệm trước tiên ta cần làm rõ: thế nào là một đơn vị PM (Unit)?

Một Unit là một thành phần PM nhỏ nhất mà ta có thể kiểm tra được. Theo định nghĩa này, các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method) đều có thể được xem là Unit.

Vì Unit được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn giản, chúng ta không khó khăn gì trong việc tổ chức, kiểm tra, ghi nhận và phân tích kết quả kiểm tra. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể Unit đang kiểm tra. Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit Test sẽ được đền bù bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm tra và sửa lỗi ở các mức kiểm tra sau đó.

Unit Test thường do lập trình viên thực hiện. Công đoạn này cần được thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ PTPM. Thông thường, Unit Test đòi hỏi kiểm tra viên có kiến thức về thiết kế và code của chương trình. Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của Unit. Điều này thường đòi hỏi tất cả các nhánh bên trong Unit đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các lệnh được thực thi trong một Unit, ví dụ: chuỗi các lệnh sau điều kiện If và nằm giữa then … else là một nhánh. Thực tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm tra và quét hết Unit đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa.

Cũng như các mức kiểm tra khác, Unit Test cũng đòi hỏi phải chuẩn bị trước các tình huống (test case) hoặc kịch bản (script), trong đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong chờ sẽ xuất ra. Các test case và script này nên được giữ lại để tái sử dụng.

2. Integration Test – Kiểm tra tích hợp

Integration test kết hợp các thành phần của một ứng dụng và kiểm tra như một ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.

Integration Test có 2 mục tiêu chính:

Phát hiện lỗi giao tiếp xảy ra giữa các Unit.

Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm tra ở mức hệ thống (System Test).

Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu trúc nội tại của Unit. Có một số phép kiểm tra đơn giản trên giao tiếp giữa Unit với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit thật sự được kiểm tra đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện Integration Test.

Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã được kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được sửa chữa. Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao tiếp giả lập thì không cần phải thực hiện Integration Test nữa. Thực tế việc tích hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác.

Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit. Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp trước đó và đã hoàn tất (passed) các đợt Integration Test trước đó. Lúc này, ta chỉ cần kiểm tra giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này làm cho số lượng kiểm tra sẽ giảm đi rất nhiều, sai sót sẽ giảm đáng kể.

Có 4 loại kiểm tra trong Integration Test:

Kiểm tra cấu trúc (structure): Tương tự White Box Test (kiểm tra nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng), chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình chẳng hạn các lệnh và nhánh bên trong.

Kiểm tra chức năng (functional): Tương tự Black Box Test (kiểm tra chỉ chú trọng đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong), chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật.

Kiểm tra hiệu năng (performance): Kiểm tra việc vận hành của hệ thống.

Kiểm tra khả năng chịu tải (stress): Kiểm tra các giới hạn của hệ thống.

3. System Test - Kiểm tra mức hệ thống

Mục đích System Test là kiểm tra thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không.

System Test bắt đầu khi tất cả các bộ phận của PM đã được tích hợp thành công. Thông thường loại kiểm tra này tốn rất nhiều công sức và thời gian. Trong nhiều trường hợp, việc kiểm tra đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ hệ thống, người kiểm tra cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống.

Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. Thông thường ta phải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test.

Sau khi hoàn thành Integration Test, một hệ thống PM đã được hình thành cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trình viên hoặc kiểm tra viên (tester) bắt đầu kiểm tra PM như một hệ thống hoàn chỉnh. Việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu. Phần sau ta sẽ nói rõ hơn về một quy trình System Test cơ bản và điển hình.

System Test kiểm tra cả các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật. Mức kiểm tra này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với PM hoặc phần cứng bên ngoài, chẳng hạn các lỗi “tắc nghẽn” (deadlock) hoặc chiếm dụng bộ nhớ. Sau giai đoạn System Test, PM thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm tra để chấp nhận (Acceptance Test) hoặc dùng thử (Alpha/Beta Test).

Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test thường được thực hiện bởi một nhóm kiểm tra viên hoàn toàn độc lập với nhóm phát triển dự án.

Bản thân System Test lại gồm nhiều loại kiểm tra khác nhau (xem hình 3), phổ biến nhất gồm:

Kiểm tra chức năng (Functional Test): bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế.

Kiểm tra khả năng vận hành (Performance Test): bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn…

Kiểm tra khả năng chịu tải (Stress Test hay Load Test): bảo đảm hệ thống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc). Stress Test tập trung vào các trạng thái tới hạn, các “điểm chết”, các tình huống bất thường…

Kiểm tra cấu hình (Configuration Test)

Kiểm tra khả năng bảo mật (Security Test): bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống.

Kiểm tra khả năng phục hồi (Recovery Test): bảo đảm hệ thống có khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến.

Nhìn từ quan điểm người dùng, các kiểm tra trên rất quan trọng: bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực.

Lưu ý không nhất thiết phải thực hiện tất cả các loại kiểm tra nêu trên. Tùy yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập kế hoạch, trưởng dự án sẽ quyết định áp dụng những loại kiểm tra nào.

Hình 2: Mối tương quan giữa phát triển và kiểm tra phần mềm

4. Acceptance Test - Kiểm tra chấp nhận sản phẩm

Thông thường, sau giai đoạn System Test là Acceptance Test, được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của Acceptance Test là để chứng minh PM thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng).

Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các phép kiểm tra của System Test và Accepatnce Test gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt.

Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người sử dụng, thông thường sẽ thông qua hai loại kiểm tra gọi là Alpha Test và Beta Test. Với Alpha Test, người sử dụng (tiềm năng) kiểm tra PM ngay tại nơi PTPM, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa. Với Beta Test, PM sẽ được gửi tới cho người sử dụng (tiềm năng) để kiểm tra ngay trong môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa chữa.

Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình PTPM thì kết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù PM đã trải qua tất cả các kiểm tra trước đó. Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong chờ của khách hàng. Ví dụ đôi khi một PM xuất sắc vượt qua các phép kiểm tra về chức năng thực hiện bởi nhóm thực hiện dự án, nhưng khách hàng khi kiểm tra sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng v.v…

Gắn liền với giai đoạn Acceptance Test thường là một nhóm những dịch vụ và tài liệu đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v… Tất cả tài liệu đi kèm phải được cập nhật và kiểm tra chặt chẽ.

Hình 3: Các loại kiểm tra khác nhau trong System Test

5. Regression Test - Kiểm tra hồi quy

Trước tiên cần khẳng định Regression Test không phải là một mức kiểm tra, như các mức khác đã nói ở trên. Nó đơn thuần kiểm tra lại PM sau khi có một sự thay đổi xảy ra, để bảo đảm phiên bản PM mới thực hiện tốt các chức năng như phiên bản cũ và sự thay đổi không gây ra lỗi mới trên những chức năng vốn đã làm việc tốt. Regression test có thể thực hiện tại mọi mức kiểm tra.

Ví dụ: một PM đang phát triển khi kiểm tra cho thấy nó chạy tốt các chức năng A, B và C. Khi có thay đổi code của chức năng C, nếu chỉ kiểm tra chức năng C thì chưa đủ, cần phải kiểm tra lại tất cả các chức năng khác liên quan đến chức năng C, trong ví dụ này là A và B. Lý do là khi C thay đổi, nó có thể sẽ làm A và B không còn làm việc đúng nữa.

Mặc dù không là một mức kiểm tra, thực tế lại cho thấy Regression Test là một trong những loại kiểm tra tốn nhiều thời gian và công sức nhất. Tuy thế, việc bỏ qua Regression Test là “không được phép” vì có thể dẫn đến tình trạng phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng, mặc dù ta “tưởng rằng” những lỗi đó hoặc không có hoặc đã được kiểm tra và sửa chữa rồi!

TÓM TẮT

Trên đây là tổng quan về các mức và loại kiểm tra PM cơ bản. Thực tế nếu đi sâu vào từng mức và loại kiểm tra, còn có rất nhiều kiểm tra đặc thù khác nữa, mang tính chuyên biệt cho từng vấn đề hoặc từng loại ứng dụng. Tuy nhiên, những mức độ và loại kiểm tra nêu trên là cơ bản nhất và có thể áp dụng trong hầu hết các loại ứng dụng PM khác nhau.

Trong số báo tới chúng tôi sẽ giới thiệu những bước cơ bản của một quy trình KTPM, làm thế nào để đánh giá và cải tiến năng lực KTPM của một tổ chức thông qua mô hình TMM (Testing Maturity Model), một mô hình được các chuyên gia đánh giá khá tốt dành cho hoạt động KTPM.

1. Kỹ thuật kiểm thử phần mềm

Có thể chia các kỹ thuật kiểm thử thành hai loại: kỹ thuật kiểm thử chức năng (Functional Testing) hay còn gọi là kỹ thuật kiểm thử hộp đen (Black-box Testing) và kỹ thuật kiểm thử cấu trúc (Structural Testing) hay còn gọi là kỹ thuật kiểm thử hộp trắng (White-box Testing).

1.1. Kỹ thuật kiểm thử chức năng

Trong kỹ thuật kiểm thử chức năng, dữ liệu kiểm thử được xuất phát từ đặc tả phần mềm bao gồm: đặc tả các yêu cầu (đối với kiểm thử hệ thống), đặc tả thiết kế (đối với kiểm thử tích hợp) và đặc tả chi tiết mô đun (đối với kiểm thử đơn vị). Trong kỹ thuật này, kiểm thử viên xem phần mềm như là một hộp đen. Kiểm thử viên hoàn toàn không quan tâm cấu trúc và hành vi bên trong của phần mềm. Kiểm thử viên chỉ cần quan tâm đến việc tìm các hiện tượng mà phần mềm không hành xử theo đúng đặc tả của nó. Kiểm thử viên chỉ biết những gì phần mềm dự kiến thực hiện và những gì dự kiến không thực hiện, mà không thể nhìn vào bên trong xem nó hoạt động như thế nào. Vì thế, dữ liệu kiểm thử sẽ xuất phát từ đặc tả.

Kiểm thử chức năng cố gắng tìm các loại lỗi sau: thiếu chức năng, lỗi giao diện, lỗi cấu trúc dữ liệu, lỗi truy cập cơ sở dữ liệu, lỗi thi hành, lỗi khởi tạo hoặc kết thúc, …

1.2. Kỹ thuật kiểm thử cấu trúc

Kỹ thuật kiểm thử cấu trúc là kỹ thuật dựa trên sự phân tích mã chương trình hoặc một mô hình của mã chương trình để xây dựng các phép thử theo các tiêu chuẩn bao phủ.

Kỹ thuật kiểm thử cấu trúc cho phép chúng ta kiểm thử cấu trúc bên trong của phần mềm, với mục đích kiểm tra tất cả các câu lệnh và điều kiện tồn tại trong phần mềm đó. Trong kỹ thuật này kiểm thử viên lấy dữ liệu thử xuất phát từ việc kiểm tra logic của chương trình (không quan tâm đến đặc tả).

2. Chiến lược kiểm thử

Một chiến lược kiểm thử (test strategy) là một kế hoạch định nghĩa mục tiêu các giai đoạn kiểm thử cũng như các kỹ thuật kiểm thử sử dụng. Chiến lược kiểm thử thường được quyết định dựa vào tiêu chuẩn về độ tin cậy của phần mềm và chi phí cho việc phát triển phần mềm. Ngoài ra, một chiến lược kiểm thử sẽ phụ thuộc kích thước của đối tượng được kiểm thử cũng như quan điểm về đối tượng được kiểm thử.

Nếu chúng ta muốn kiểm thử một cách độc lập các thành phần/đơn vị cấu tạo nên phần mềm, chúng ta gọi là kiểm thử đơn vị. Nếu chúng ta muốn kiểm thử sự kết hợp các thành phần cấu tạo nên phần mềm, chúng ta gọi là kiểm thử tích hợp. Nếu chúng ta muốn bảo đảm rằng một phần mềm đang được phát triển một cách đúng đắn và các thành phần cấu tạo nên phần mềm cũng được phát triển một cách đúng đắn, chúng ta gọi là xác minh (verification). Tuy nhiên, một phần mềm không chỉ đơn thuần là đáp ứng yêu cầu của nhà sản xuất, mà nó chỉ trở nên hữu ích nếu đáp ứng được nhu cầu của người sử dụng cuối cùng. Việc bảo đảm một phần mềm đáp ứng nhu cầu của người sử dụng được gọi là hợp thức hoá (validation).

3. Các giai đoạn kiểm thử

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

Phần lớn các phương pháp thiết kế phần mềm đều dẫn đến chia phần mềm thành những mô- đun hay chương trình nhỏ có các dữ liệu vào và kết quả riêng. Chúng ta gọi các mô-đun hay chương trình đó là các đơn vị (unit) phần mềm. Trên các đơn vị này chúng ta sẽ tiến hành kiểm thử đơn vị.

Một khi đơn vị phần mềm đã được mã hoá, nghĩa là lập trình và hồ sơ kiểm thử đơn vị tương ứng đã được hoàn thành thì kiểm thử đơn vị có thể được tiến hành.

Kiểm thử đơn vị chủ yếu là thực hiện các trường hợp kiểm thử (test case) đã được mô tả trong hồ sơ kiểm thử đơn vị và điền các thông tin cần thiết vào các phiếu báo cáo kiểm thử. Nếu một lỗi hay sự không tương thích được phát hiện, cần phải chỉnh sửa lại đơn vị phần mềm. Sau đó, kiểm thử đơn vị được thực hiện lại. Kiểm thử đơn vị sẽ kết thúc khi mà tất cả các trường hợp kiểm thử được mô tả trong hồ sơ kiểm thử đơn vị đã được thực hiện thành công và kết quả được lưu lại trong hồ sơ.

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

Kiểm thử tích hợp được tiến hành một khi kiểm thử đơn vị các thành phần cần thiết cho kiểm thử tích hợp kết thúc và hồ sơ kiểm thử tích hợp đã được chuẩn bị sẵn sàng. Trong giai đoạn kiểm thử tích hợp, ý tưởng là các thành phần đã được kiểm thử đơn vị sẽ được tích hợp lại dần dần cho đến khi có được toàn bộ phần mềm. Phần mềm càng phức tạp thì đòi hỏi giai đoạn kiểm thử tích hợp phải trải qua các giai đoạn trung gian, là các giai đoạn mà các nhóm các thành phần sẽ được kiểm thử.

Mục tiêu của giai đoạn kiểm thử tích hợp là kiểm tra sự giao tiếp và trao đổi dữ liệu giữa các thành phần phần mềm. Trong giai đoạn tích hợp, có thể có khả năng phải sử dụng các thành phần không được phát triển trong dự án phần mềm, mà là những thành phần được cung cấp sẵn bởi các thư viện hay thậm chí là các thành phần được cung cấp bởi hệ điều hành.

Khi tích hợp các thành phần tạo thành tập hợp, chúng ta có thể tiến hành theo các chiến lược:

- Tích hợp từ trên xuống (top-down) bằng cách kiểm thử tích hợp các thành phần chính trước, sau đó thêm vào các thành phần được gọi trực tiếp bởi các thành phần vừa kiểm thử.

- Tích hợp từ dưới lên (bottom-up) bằng cách kiểm thử các thành phần không gọi các thành phần khác, sau đó thêm vào các thành phần gọi các thành phần vừa kiểm thử.

3.3. Kiểm thử hợp thức hoá (Validation Testing)

Kiểm thử hợp thức hoá có thể bắt đầu ngay sau khi kiểm thử tích hợp kết thúc và hồ sơ kiểm thử hợp thức hoá đã sẵn sàng. Mục tiêu của kiểm thử hợp thức hoá là cần chỉ ra rằng phần mềm thực hiện đúng những gì mà người sử dụng mong đợi. Vì thế, ở giai đoạn này, kiểm thử được thực hiện dưới góc nhìn của người sử dụng, chứ không phải dưới góc nhìn của người phát triển như các giai đoạn kiểm thử đơn vị hay kiểm thử tích hợp.

Vì kiểm thử được thực hiện dưới góc nhìn của người sử dụng nên giai đoạn này chỉ sử dụng các kỹ thuật kiểm thử chức năng, tức là các kỹ thuật kiểm thử hộp đen. Các bộ dữ liệu thử sẽ được tạo ra dựa trên các tài liệu đặc tả. Thông thường các tài liệu đặc tả sẽ được phân tích để xác định các yêu cầu chứa đựng các hành vi mong đợi của phần mềm.

3.4. Kiểm thử chấp nhận (Acceptance Testing)

Được thực hiện khi tất cả các giai đoạn kiểm thử được hoàn tất nhằm để chứng minh phần mềm đã đủ sẵn sàng xuất xưởng. Các thủ tục kiểm thử hoặc chạy thử phải được người đặt hàng chấp nhận trước khi thực hiện để nghiệm thu.

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

Phần mềm là một trong những loại sản phẩm thay đổi rất nhanh. Người sử dụng luôn có yêu cầu cải tiến phần mềm và các chức năng mới. Vì vậy, sự chỉnh sửa phần mềm sau khi đưa vào sử dụng là cần thiết. Mặt khác, bất kỳ sự sửa đổi nào cùng có thể dẫn đến các lỗi mới. Phần mềm nhất thiết phải được kiểm thử lại sau khi sửa đổi, giai đoạn kiểm thử này gọi là kiểm thử hồi quy.

Giai đoạn kiểm thử hồi quy thường tái sử dụng các bộ dữ liệu thử đã sử dụng trong các giai đoạn trước nhằm kiểm tra rằng không có các lỗi mới được đưa vào. Vấn đề đặt ra ở đây là trong giai đoạn này, các bộ dữ liệu thử nào được tái sử dụng: kiểm thử đơn vị, kiểm thử tích hợp hay kiểm thử hệ thống?

4. Một số vấn đề khác của kiểm thử phần mềm

4.1. Các hạn chế của kiểm thử

Do kiểm thử là chạy thử chương trình với tập dữ liệu giả nên không thể khẳng định tính đúng của chương trình do bản chất quy nạp không hoàn toàn của nó.

Trong nhiều trường hợp, việc kiểm thử thường được thực hiện từ những giai đoạn đầu của quá trình cài đặt sản phẩm.

Một chương trình được cho tuyệt đối đúng phải được thực hiện thông qua: tính đúng đắn của thuật toán và tính tương đương của chương trình với thuật toán (được thể hiện ở chứng minh thông qua văn bản chương trình).

Việc kiểm thử chương trình chỉ là nhìn sự kiện đưa ra kết luận do vậy không thể khẳng định một chương trình tuyệt đối đúng bằng kiểm thử. Tuy vậy, bộ dữ liệu kiểm thử phải phủ kín mọi trường hợp cần đánh giá.

Thêm vào đó, trong quá trình kiểm thử, ta thường mắc phải các đặc trưng của nguyên lý chủ quan như sau:

+ Bộ dữ liệu kiểm thử không thay đổi trong quá trình xây dựng phần mềm.

+ Chỉ kiểm thử các trường hợp chính thống, hợp lệ, không quan tâm đến các cận và các sự cố.

+ Cài đặt chức năng nào thì chỉ kiểm thử riêng chức năng đó, không kiểm thử tổng hợp chức năng vừa cài đặt với các chức năng đã cài đặt trước đó.

+ Người kiểm thử đồng thời là người xây dựng phần mềm tức vừa đá bóng, vừa thổi còi.

4.2. Các nguyên tắc kiểm thử

Các nguyên tắc luôn đóng vai trò quan trọng trong lĩnh vực công nghệ phần mềm. Các nguyên tắc trong công nghệ phần mềm là các luật hay quy tắc hướng dẫn làm thế nào để xây dựng (thiết kế, phát triển, kiểm thử và bảo trì) phần mềm. Kiểm thử là một trong những lĩnh vực của công nghệ phần mềm, kiểm thử cũng có các nguyên tắc riêng dành cho các kiểm thử viên. Chúng ta sẽ xem xét một số nguyên tắc cơ bản liên quan đến kiểm thử động:

- Kiểm thử là tiến trình thực thi phần mềm và sử dụng các trường hợp kiểm thử để phát hiện lỗi.

- Với mục đích của kiểm thử nhằm phát hiện lỗi, một ca kiểm thử tốt là ca kiểm thử có khả năng cao phát hiện những lỗi chưa được tìm thấy.

- Một ca kiểm thử phải định nghĩa kết quả mong muốn.

- Kiểm thử nên được thực hiện bởi một nhóm độc lập với nhóm phát triển.

- Kết quả kiểm thử nên được kiểm tra một cách cẩn thận.

- Các ca kiểm thử nên được thiết kế cho cả những dữ liệu vào hợp lệ và không hợp lệ.

- Các ca kiểm thử phải được tái sử dụng.

- Xác suất tồn tại của các lỗi hơn nữa trong một đơn vị phần mềm tỷ lệ với số các lỗi đã được phát hiện trong đơn vị phần mềm đó.

- Kiểm thử nên phải được lập kế hoạch.

- Các hoạt động kiểm thử nên phải được tích hợp vào tiến trình phát triển phần mềm.

- Kiểm thử là một công việc đầy sáng tạo và thách thức.

4.3. Phân loại một số công cụ kiểm thử tự động

Vì kiểm thử phần mềm thường chiếm tới 40% tất cả các nỗ lực dành cho một dự án xây dựng phần mềm, nên công cụ có thể làm giảm thời gian kiểm thử sẽ rất có giá trị. Thừa nhận lợi ích tiềm năng này, các nhà nghiên cứu và người thực hành đã phát triển một số thế hệ các công cụ kiểm thử tự động:

Bộ phân tích tĩnh: Các hệ thống phân tích chương trình này hỗ trợ cho việc chứng minh các lý lẽ tĩnh - những mệnh đề yếu kém về cấu trúc và định dạng của chương trình.

Bộ thanh tra mã nguồn: Những bộ lọc chuyên dụng này được dùng để kiểm tra chất lượng của phần mềm để đảm bảo rằng nó đáp ứng các chuẩn mã hoá tối thiểu.

Bộ xử lý khẳng định: Những hệ thống tiền xử lý/hậu xử lý này được sử dụng để cho biết liệu những phát biểu do người lập trình nêu, được gọi là các khẳng định, về hành vi của chương trình có thực sự được đáp ứng trong việc thực hiện chương trình thực hay không.

Bộ sinh trường hợp kiểm thử: Những bộ xử lý này sinh ra, và điền các giá trị đã xác định vào các trường hợp kiểm thử cho chương trình đang được kiểm thử.

Bộ sinh dữ liệu kiểm thử: Những hệ thống phân tích tự động này hỗ trợ cho người dùng trong việc chọn dữ liệu kiểm thử làm cho chương trình hành xử theo một cách đặc biệt.

Bộ kiểm chứng kiểm thử: Những công cụ này đo mức bao quát kiểm thử bên trong, thường được diễn tả dưới dạng có liên quan tới cấu trúc điều khiển của sự vật kiểm thử, và báo cáo về giá trị bao quát cho chuyên gia đảm bảo chất lượng.

Dụng cụ kiểm thử: Lớp các công cụ này hỗ trợ cho việc xử lý các phép kiểm thử.

Bộ so sánh kết quả đầu ra: Công cụ này làm cho người ta có thể so sánh một tập kết quả đầu ra từ một chương trình này với một tập kết quả khác (đã được lưu giữ trước) để xác định sự khác biệt giữa chúng.

Hệ thống thực hiện ký hiệu (symbolic execution system): Công cụ này thực hiện việc kiểm thử chương trình bằng cách dùng “dữ liệu vào” đại số, thay vì giá trị dữ liệu số. Phần mềm được kiểm thử xuất hiện để kiểm thử các lớp dữ liệu, thay vì chỉ là một trường hợp kiểm thử đặc biệt. “Dữ liệu ra” là đại số và có thể được so sánh với kết quả trông đợi cũng được xác định dưới dạng đại số.

Bộ mô phỏng môi trường: Công cụ này là một hệ thống dựa trên máy tính giúp người kiểm thử mô hình hoá môi trường bên ngoài của phần mềm thời gian thực và rồi mô phỏng các điều kiện vận hành thực tại một cách động.

Bộ phân tích luồng dữ liệu: Công cụ này theo dõi dấu vết luồng dữ liệu đi qua hệ thống và cố gắng tìm ra những tham khảo dữ liệu không xác định, đặt chỉ số sai và các lỗi khác có liên quan tới dữ liệu.