Test phần mềm

1.1 Định nghĩa
Test phần mềm là quá trình vận hành thử nghiệm một chương trình, một hệ thống phần mềm với mục đích tìm ra lỗi.
1.2 Vai trò
- Testing để tìm ra lỗi, ghi nhận các thông tin về lỗi, nhưng không sửa lỗi.
- Testing giúp kiểm định phần mềm, đảm bảo rằng phần mềm “đủ tốt” với độ rủi ro “thấp nhất” có thể.
1.3 Test thế nào cho đủ
1.3.1 Vấn đề
- Càng test càng tìm ra thêm lỗi, nhất là với các hệ thống lớn.
- Vấn đề không phải là với việc test như vậy tất cả các lỗi đã được tìm ra chưa, mà ở chỗ phần mềm như vậy có đủ “tốt” để ngừng test không?
- Đây là một quyết định mang tính “kinh tế”.
- Và là một trong những vấn đề khó nhất của testing.
1.3.2 Tìm câu trả lời
- Khả năng tìm được thêm lỗi nếu tiếp tục test?
- Chi phí cận biên về thời gian và nhân lực nếu tiếp tục test?
- Khả năng NSD gặp phải các lỗi còn lại?
- Ảnh hưởng, hậu quả những lỗi đó với NSD?
1.3.3 Kết luận
- Không thể có câu trả lời chính xác mang tính công thức cho vấn đề trên.
- Vấn đề này có thể thỏa hiệp, dựa vào kinh nghiệm cụ thể trong từng dự án, từng phần mềm vẫn là điều then chốt.
- Điều quan trọng là cần biết ưu tiên test, biết dành thời gian và nguồn lực cho những test được ưu tiên trước. Tham khảo mục: CÁC PHƯƠNG PHÁP KỸ THUẬT TEST
2 QUI TRÌNH PHÁT TRIỂN PHẦN MỀM VÀ VỊ TRÍ CỦA TESTING
2.1 Mô hình chữ V đối với qui trình test
- Trong các qui trình phát triển phần mềm truyền thống, testing được thực hiện song song cùng với mỗi giai đoạn phát triển, tạo nên mô hình chữ V. Mô hình này phản ánh sự cần thiết việc lập kế hoạch và chuẩn bị sớm cho test.
- Trong mô hình này, mỗi giai đoạn phát triển được liên kết tương ứng với một giai đoạn test.
- Như các giai đoạn phát triển cụ thể, từng giai đoạn test cũng cần phải được lập kế hoạch và chuẩn bị (thiết kế sơ bộ).
- Ở một số công ty, Tester không đảm nhận Unit test.
- Nhiều dự án không có tài liệu hỗ trợ (Requirements Spec., Project Plan…) Qui trình test phải biến đổi linh hoạt theo.
2.2 Các giai đoạn test (Testing Phases)
2.2.1 Unit Testing
- Unit là phần nhỏ nhất của mã nguồn (source code) có thể được biên dịch, liên kết và load (compiled, linked, và loaded)
- Unit testing được thực hiện bởi Lập trình viên (Developers)
- Sử dụng phương pháp test hộp trắng (White box testing)
2.2.2 Intergration Testing – Test tích hợp
- Software Integration là quá trình hợp nhất các unit đơn lẻ vào thành một hệ thống (hoặc một tiểu hệ thống).
- Integration testing là test các liên kết giữa các unit thành phần.
- Integration testing đòi hỏi các module phải được unit test trước.
2.2.3 System Testing – Test hệ thống
- Thực hiện khi integration đã được hoàn tất
- Sử dụng phương pháp test hộp đen (Black box testing)
- Test dựa trên yêu cầu hệ thống (Requirements)
- System testing được thực hiện bởi Nhóm test
2.2.4 User Acceptance Testing
- Nên được gọi là Acceptance Demonstration thay cho Acceptance Test.
- Để chứng minh phần mềm đã sẵn sàng chuyển giao cho khách hàng.
- Khi tất cả các giai đoạn test khác đã được hoàn tất.
- Dựa trên cơ sở là toàn bộ hay một phần của tài liệu yêu cầu hệ thống (system requirements)
- Các thủ tục test/demo phải được khách hàng chấp nhận trước khi thực hiện để nghiệm thu.
2.2.5 Installation Testing
- Test các bước thực hiện cài đặt dựa trên Tài liệu hướng dẫn cài đặt, chứng minh Tài liệu hướng dẫn cài đặt đã qui chuẩn để chuyển giao khách hàng.
- Installation testing được thực hiện bởi Nhóm test
3 CÁC PHƯƠNG PHÁP KỸ THUẬT TEST
[g]3.1 Các kỹ thuật test
3.1.1 Equivalence class partitioning – Phân lớp tương đương[/g]
- Phân các test cases theo nhóm các TEST CASE cùng loại, gọi là class hay lớp các TEST CASE.
- Trong mỗi class chọn test chỉ một vài test case.
- Nên test nhiều class thay cho test nhiều test cases trong cùng một class.
3.1.2 Control flow testing – Luồng điều khiển
- Phân loại các TEST CASE theo sơ đồ mô hình luồng xử lý (Đó là sơ đồ mô hình hoá hành vi của hệ thống, chứ không phải là sơ đồ mô tả các câu lệnh trong code).
- Mỗi rẽ nhánh trong luồng xử ký là 1 TEST CASE.
- Đây là 1 kỹ thuật test căn bản, áp dụng hiệu quả được cho hầu hết các hệ thống, áp dụng được cho mọi giai đoạn test.
3.1.3 Data flow testing – Luồng dữ liệu
- Áp dụng cho loại hệ thống đòi hỏi và xử lý nhiều dữ liệu (data-intensive)
- Phân loại các TEST CASE theo sơ đồ mô hình luồng dữ liệu
3.1.4 Transaction testing – Giao dịch
- Áp dụng cho các hệ thống xử lý giao dịch (các giao dịch trong ngân hàng, đặt vé máy bay, đặt phòng khách sạn…)
- Phân loại TEST CASE theo loại các giao dịch, chú trọng việc xác định điểm khởi đầu, điểm kết thúc, và hàng đợi các điểm giao dịch cần xử lý.
3.1.5 Domain testing – vùng
- Áp dụng cho loại hệ thống xử lý nhiều vùng giá trị của biến.
- Phân loại các TEST CASE theo vùng giá trị của biến, đặc biệt chú trọng các TEST CASE quanh biên ranh giới, nơi hệ thống có những xử lý khác nhau so với các giá trị biến khác.
3.1.6 Loop testing – Vòng lặp
- Áp dụng trong whitebox testing: quan tâm đến vòng lặp trong code.
- Áp dụng trong backbox testing: quan tâm đến vòng lặp trong hành vi của hệ thống.
- Phân loại các TEST CASE theo số giá trị đặc biệt lần rẽ nhánh các vòng lặp.
3.1.7 Syntax testing – Cú pháp
- Áp dụng test các câu lệnh, các trường toán tử có định dạng xác định.
- Phân tích, nắm rõ các cú pháp để thiết kế các TEST CASE, sử dụng kỹ thuật phân lớp tương đương, và theo loại đúng hoặc sai cú pháp.
3.1.8 State machine testing – Trạng thái
- Áp dụng cho loại hệ thống có đặc trưng chuyển đổi trạng thái, các “menu driven application” – Chương trình điều khiển bằng trình đơn, các hệ thống thiết kế bằng phương pháp hướng đối tượng.
- Các TEST CASE được phân loại từ việc lập các biểu đồ chuyển đổi trạng thái của hệ thống, theo loại chuyển đổi trạng thái hợp lệ và không hợp lệ.
3.1.9 Load and stress testing
- Load testing: test hệ thống ở trạng thái chịu tải lớn (thực hiện nhiều xử lý), ví dụ:
o Có nhiều client cùng lúc truy cập
o Có nhiều giao dịch cùng một lúc
o Xử lý file rất lớn
o Xử lý cùng lúc nhiều file
3.1.10 Stress testing
- Stress testing: test hệ thống ở trạng thái vận hành trong điều kiện bất thường, ví dụ:
o Thiếu bộ nhớ
o Kết nối mạng bị ngắt khi đang vận hành
o Kết nối CSDL bị ngắt khi đang vận hành
3.2 Ưu tiên test
3.2.1 Danh sách các ưu tiên test - “where to focus testing”
- Những vùng quan trọng nhất của phần mềm
- Những vùng phần mềm hay được dùng nhất
- Những vùng có đặc trưng riêng, khác biệt hẳn với các vùng khác của phần mềm
- Những vùng phần mềm dễ bị ảnh hưởng nhất của các thay đổi vừa có (khi regression test)
- Những lỗi dễ xảy ra nhất
- Những lỗi (người dùng) dễ nhìn thấy nhất
- Những loại lỗi khó fix nhất
- Những loại lỗi mà tester biết rõ nhất
- Những loại lối mà tester biết lờ mờ nhất
- Positive test trước, negative test sau (test các trường hợp hợp lệ trước, các trường hợp không hợp lệ sau)
3.2.2 Ưu tiên sắp xếp test theo quality dimension
- Số 1: thường là Function testing, và phải bao quát được bussines cycle của hệ thống.
- Số 2: Usability testing, chú ý test GUI, đảm bảo đúng syntax, theo standards và user friendly.

1) Test cấp đơn vị (Unit testing)
2) Test cấu hình (Shakeout testing)
3) Test sơ lượt (Smoke testing (Ad-hoc testing))
4) Test chức năng (Functional testing)
5) Test tích hợp (Integration testing)
6) Test hồi quy (Regression testing)
7) Test hệ thống (System testing)
Test tải dữ liệu (Load testing)
9) Test tải trọng (Stress testing)
10) Test hiệu suất (Performance testing)
11) Test chấp nhận từ người sử dụng (User acceptance testing)
12) Test hộp đen (Black box testing)
13) Test hộp trắng (White box testing)
14) Test Alpha (Alpha testing)
15) Test Beta (Beta testing)

(Ghi chú: Ngoại trừ kiểu test Shakeout và Unit test được thực hiện bởi nhóm quản lý cấu hình (CMT-Configuration Management Team) và người lập trình (coder/developer), tất cả các kiểu test khác được thực hiện bởi Tester QA.

1). Test Unit là gì? Là kiểu test kiểm tra code xem liệu chức năng nó đang thực hiện có đúng cách hay không theo như yêu cầu.

2). Test Shakeout là gì? Kiểu test này cơ bản là kiểu test về khả năng của hệ thống mạng, kết nối dữ liệu và sự tương tác của các module. Thông thường thì kiểu test này là do nhóm quản lý cấu hình chuẩn bị thiết lập các môi trường test thực sự. Họ cũng test xem liệu các thành phần chính của phần mềm có hoạt động bất thường không. Kiểu test này thực hiện trước khi tiến hành thực hiện trong môi trường test. Sau khi test shakeout, bước kế tiếp là test smoke (kiểu test được thực hiện bởi tester sau khi biên dịch, được tiến hành trong môi trường test).

3). Test smoke là gì? Là kiểu test được thực hiện khi phần code được biên dịch mới chỉ được chuẩn bị tiến hành trong môi trường test. Kiểu này cơ bản giống như kiểu ad hoc để kiểm tra đại khái để chắc rằng các chức năng chính có bị bất thường không? Nó mở đầu cho quá trình test bởi Tester QA. Sau khi test smoke, các tester sẽ thực hiện test khả năng thực hiện của các chức năng.

4). Test Chức năng là gì? Là kiểu test liệu mỗi và mọi chức năng của ứng dụng đó đang làm việc có như yêu cầu của tài liệu. Nó là kiểu test chính mà 80% công việc test được thực hiện. Trong kiểu test này thì các testcase được thực hiện (hoặc thi hành).

5). Test Tích hợp là gì? là kiểu test kiểm tra liệu tất cả các module là được kết hợp hoặc chưa kết hợp lại cùng với nhau thực hiện công việc có đạt được kết quả như tài liệu yêu cầu đã được xác định (do mỗi lập trình viên thực hiện trên các module khác nhau. Khi họ hoàn thành đoạn code của họ, nhóm quản lý cấu hình ráp chúng lại với nhau và chuẩn bị biên dịch. Các tester cần chắc rằng các module này bây giờ đã được kết hợp và làm việc theo như yêu cầu - tức là phải test theo như yêu cầu).

6). Test hồi quy là gì? Khi một chức năng mới được thêm vào phần mềm, chúng ta cần chắc chắn rằng phần chức năng mới được thêm vào không phá hỏng các phần khác của ứng dụng. Hoặc khi lỗi đã được chỉnh sửa, chúng ta cần chắc chắn rằng lỗi chỉnh sửa không phá hỏng các phần khác trong ứng dụng. Để test điều này chúng ta thực hiện kiểu test lặp đi lặp lại gọi là test hồi quy.

7). Test hệ thống là gì? Khi tester hoàn thành công việc test (các tester test ứng dụng trong các môi trường test, nghĩa là họ test với dữ liệu test, không test trên dữ liệu thật), ứng dụng (phần mềm) phải được test trên môi trường thật. Nó nghĩa là gì, tức là kể từ khi các tester test nó trong môi trường test với dữ liệu test, chúng ta phải chắc chắn rằng ứng dụng làm việc tốt trong môi trường thật với dữ liệu thật. Trong môi trường test, một vài điều không thể test hoặc thao tác giả. Tất cả sẽ khác nhau và cơ sở dữ liệu khác nhau, một số thao tác có thể không làm việc như mong đợi khi ứng dụng được chuyển từ môi trường test sang môi trường sản phẩm (test enviroment to production environment).

. Test tải dữ liệu? Là kiểu test kiểm tra thời gian đáp lại người dùng với ứng số lượng người dùng bất kỳ trong một ngữ cảnh nào đó của cùng một ứng dụng tại cùng một thời điểm.

9). Test tải trọng là gì? Là kiểu test kiểm tra thời gian đáp lại người dùng với ứng số lượng người dùng bất kỳ trong nhiều ngữ cảnh khác nhau của cùng một ứng dụng tại cùng một thời điểm.

10). Test hiệu suất là gì? Trong loại test này, ứng dụng được test dựa vào sức nặng như sự phức tạp của giá trị, độ dài của đầu vào, độ dài của các câu truy vấn...Loại test này kiểm tra bớt phần tải (stress/load) của ứng dụng có thể được chắc chắn hơn.

11). Test chấp nhận từ người sử dụng là gì? Trong kiểu test này, phần mềm sẽ được thực hiện kiểm tra từ người dùng để tìm ra nếu phần mềm phù hợp với sự mong đợi của người dùng và thực hiện đúng như mong đợi. Trong giai đoạn test này, tester có thể cũng thực hiện hoặc khách hàng có các tester của riêng họ để thực hiện.

12). Test hộp đen là gì? Là kiểu test mà Tester thực hiện test không chú ý gì đến code (hoặc là một hình thức test mà ứng dụng đang test được xem như một hộp đen và hành vi bên trong của chương trình hoàn toàn được bỏ qua. Việc test xảy ra dựa trên các đặc tả bên ngoài. Cũng hiểu như test hành vi, chỉ hành vi bên ngoài của ứng dụng là được đánh giá và phân tích).

13). Test hộp trắng là gì? Là test mà các tester tìm kiếm lỗi bên trong code.

14). Test Alpha là gì? Trong loại test này, các người dùng được mời đến điểm tập trung đề xuất ý kiến, nơi mà họ sẽ sử dụng chương trình và người phát triển chú ý mỗi thông tin liên quan hoặc hành động được đặt ra bởi người dùng. Bất kỳ hành vi bất thường nào của hệ thống cũng phải được ghi nhận và chỉnh sửa bởi người phát triển.

15). Test Beta là gì? Trong loại test này, phần mềm được phân bổ như một phiên bản thử nghiệm (sử dụng thử) để người dùng kiểm tra ứng dụng tại nơi làm việc của họ. Người sử dụng sẽ quan sát phần mềm, trong trường hợp nếu có bất kỳ lỗi xảy ra thì nó được báo cáo đến người phát triển.