Phần mềm là gì?
Phần mềm là một (bộ) chương trình được cài đặt trên máy tính nhằm thực hiện một nhiệm vụ tương đối độc lập, phục vụ cho một ứng dụng cụ thể việc quản lý họat động của máy tính hoặc áp dụng máy tính trong các họat động kinh tế, quốc phòng, văn hóa, giáo dục, giải trí,…
Thế nào là lỗi phần mềm?
Có rất nhiều định nghĩa khác nhau về lỗi phần mềm, nhưng tựu chung, có thể phát biểu một cách tổng quát: “Lỗi phần mềm là sự không khớp giữa chương trình và đặc tả của nó.”
Dựa vào định nghĩa, chúng ta có thể thấy lỗi phần mềm xuất hiện theo ba dạng sau:
- Sai: Sản phẩm được xây dựng khác với đặc tả.
- Thiếu: Một yêu cầu đã được đặc tả nhưng lại không có trong sản phẩm được xây dựng.
- Thừa: Một yêu cầu được đưa vào sản phẩm mà không có trong đặc tả.
Cũng có trường hợp yêu cầu này có thể là một thuộc tính sẽ được người dùng chấp nhận nhưng khác với đặc tả nên vẫn coi là có lỗi.
Một hình thức khác nữa cũng được xem là lỗi, đó là phần mềm khó hiểu, khó sử dụng, chậm hoặc dễ gây cảm nhận rằng phần mềm họat động không đúng.
Kiểm thử phần mềm là gì?
Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới những điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía cạnh nào đó của hệ thống hay thành phần đó.
Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm lỗi.
Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho người có lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành khác nhau.
Có thể định nghĩa một cách dễ hiểu như sau: Kiểm thử phần mềm là một tiến trình hay một tập hợp các tiến trình được thiết kế để đảm bảo mã hóa máy tính thực hiện theo cái mà chúng đã đư ợc thiết kế để làm, và không thực hiện bất cứ thứ gì không mong muốn. Đây là một pha quan trọng trong quá trình phát triển hệ thống, giúp cho người xây dựng hệ thống và khách hàng thấy được hệ thống mới đã đáp ứng yêu cầu đặt ra hay chưa.
Quy trình kiểm thử phần mềm
Quy trình kiểm thử này gồm các công đoạn như sau:
- Dựa vào tài liệu thiết kế (dữ liệu đầu vào) để viết (thiết kế) test case, kết quả đầu ra là test case
- Dựa vào test case đã viết, tiến hành tạo data test - là dữ liệu để thực hiện test theo test case đã viết, kết quả là data test - dữ liệu dùng để test.
Ví dụ:
Với test case "nhập vào ô Mã Nhân viên giá trị app, click search => kết quả mong muốn là hiển thị thông tin chi tiết của nhân viên tvn.
Để test trường hợp trên ta cần phải tạo data test như sau: vào DB, table NhanVien, thêm mới thông tin một nhân viên như sau:
- Mã nhân viên: app
- Tên nhân viên: tbit_staff
- Ngày sinh: 26/03/2014
- ...
- Thực hiện chạy chương trình theo các test case đã tạo, kết quả đầu ra là kết quả test (trạng thái trên màn hình, hoặc trong DB)
- So sánh kết quả test và kết quả mong đợi trong test case, lầnn lượt tất cả test case được test sẽ có kết quả pass hay fail, kết quả đầu ra là báo cáo kết quả test test report.
Vậy Quy trình kiểm thử phần mềm là gì ?
Chế độ kiểm thử được định nghĩa bởi tổ chức phát triển.
Cần nhận dạng cái gì là quan trọng đối với tổchức (chi phí, chất lượng, thời gian, phạm vi,..) và cách nào, bởi ai và khi nào việc kiểm thử sẽ được thực hiện.
Tất cả các thông tin trên sẽ được lập thành tài liệu cho hoạt động kiểm thử và ta có thể gọi qui trình tạo lập tài liệu này là qui trình kiểm thử phần mềm (Test Process).
Tạo sao cần phải thực hiện qui trình kiểm thử phần mềm ?
- Cần làm rõ vai trò và trách nhiệm của việc kiểm thử phần mềm.
- Cần làm rõ các công đoạn, các bước kiểm thử.
- Cần phải hiểu và phân biệt các tính chất kiểm thử(tạo sao phải kiểm thử), các bước kiểm thử(khi nào kiểm thử), và các kỹthuật kiểm thử(kiểm thửbằng cách nào).
Mô hình phát triển và kiểm thử phần mềm chữ V
Các tính chất cần ghi nhận trên mô hình chữ V :
Các hoạt động hiện thực và các hoạt động kiểm thử được tách biệt nhưng độ quan trọng là như nhau. Chữ V minh họa các khía cạnh của hoạt động Verificationvà Validation.
Cần phân biệt giữa các mức độ kiểm thử ở đó mỗi mức kiểm thử là kiểm thử trên mức phát triển phần mềm tương ứng.
Mô hình phát triển tăng tiến-tương tác :
- Qui trình thiết lập các yêu cầu phần mềm, thiết kế, xây dựng, kiểm thử hệ thống phần mềm được thực hiện như 1 chuỗi các chu kỳ phát triển ngắn hơn.
- Hệ thống có được từ 1 bước lặp được kiểm thử ở nhiều cấp trong việc phát triển hệ thống đó.
- Kiểm thử hồi quy có độ quan trọng tăng dần theo các bước lặp (không cần trong bước đầu tiên).
- Thanh kiểm tra và kiểm định có thể được thực hiện theo kiểu tăng dần trên từng bước lặp.
Các tính chất của qui trình kiểm thử tốt :
- Cần có 1 mức độ kiểm thử cho mỗi công đoạn phát triểnphần mềm.
- Các mục tiêu kiểm thử sẽ bị thay đổi, mỗi mức kiểm thử nên có các mục tiêu đặc thù của mình.
- Việc phân tích và thiết kế testcase cho 1 mức độ kiểm thử nên bắt đầu sớm nhất như có thể có.
- Các tester nên xem xét các tài liệu sớm như có thể có, ngay sau khi các tài liệu này được tạo ra trong chu kỳ phát triển phần mềm.
- Số lượng và cường độ của các mức kiểm thử được điều khiển theo các yêu cầu đặc thù của project phần mềm đó.
Thiết kế Test Case
Thiết kế test – case trong kiểm thử phần mềm là quá trình xây dựng các phương pháp kiểm thử có thể phát hiện lỗi, sai sót, khuyết điểm của phần mềm để xây dựng phần mềm đạt tiêu chuẩn.
Vai trò của thiết kế test – case:
- Tạo ra các ca kiểm thử tốt nhất có khả năng phát hiện ra lỗi, sai sót của phần mềm một cách nhiều nhất.
- Tạo ra các ca kiểm thử có chi phí rẻ nhất, đồng thời tốn ít thời gian và công sức nhất.
Các thành phần cơ bản của 1 test case:
- Mô tả: đặc tả các điều kiện cần có để tiến hành kiểm tra
- Nhập: đặc tả đối tượng hay dữ liệu cần thiết được sử dụng làm đầu vào để thực hiện việc kiểm tra
- Kết quả mong chờ : kết quả trả về từ đối tượng kiểm tra, chứng tỏ đối tượng đạt yêu cầu
Những thứ cơ bản phải có trong bản test case:
- Test case id: mã của test case
- Tester name : tên người test
- Input data and/or events: dữ liệu nhập vào
- Expected output data and/or events: dữ liệu mong chờ
Test script
- Một test script là một nhóm mã lệnh dạng đặc tả kịch bản dùng để tự động hóa một trình tự kiểm tra, giúp cho việc kiểm tra nhanh hơn, hoặc cho những trường hợp mà kiểm tra bằng tay sẽ rất khó khan hoặc không khả thi.
- Các test script có thể tạo thủ công hoặc tạo tự động dùng công cụ kiểm tra tự động.
Test plan (lập kế hoạch kiểm thử )
Test plan để chỉ định và mô tả các kế hoạch sẽ được triển khai và thực hiện trong quy trinh kiểm thử phần mềm.
Kết quả của bước lập kế hoạch là bản tài liệu kế haochj kiểm thử phần mềm bao gồm:
- Các loại kiểm tra
- Chiến lược kiểm tra
- Thời gian kiểm tra
- Phân định lực lượng kiểm tra viên
Lập kế hoạch test
Bản kế hoạch kiểm tra đầu tiên được phát triển rất sớm trong chu trình phát triển phần mềm, ngay từ khi các yêu cầu đã tương đối đầy đủ, các chức năng và luồng dữ liệu chính đã được mô tả.
Bản kế hoạch này có thể được coi là bản kế hoạch chính (master test plan).Trong đó cả các kế hoạch chi tiết cho các mức kiểm tra và loại kiểm tra khác nhau đều được đề cập như sau.
Các bước lập kế hoạch test:
- Xác định yêu cầu kiểm tra: chỉ rõ phạm vi và giới hạn của đối tượng kiểm tra
- Khảo sát rủi ro : phân tích lường trước những yếu tố ảnh hưởng đến quá trình kiểm tra
- Xác định chiến lược kiểm tra : chỉ rõ các phương pháp sử dụng trong qua trình kiểm tra
- Xác định nhân lực vật lực : xác định rõ kinh nghiêm của người kiểm thử, các công cụ hỗ trợ khác
- Lập kế hoạch chi tiết : xây dựng bản kế hoạch chi tiết như các công việc cần làm, thời gian …
- Tổng hợp và tạo các bản kế hoạch kiểm tra : xây dựng bản kế hoạch chung bên cạnh là bản kế hoạch chi tiết
- Xem xét các kế hoạch kiểm tra : cần có sự tham gia của nhiều người liên quan đến dự án như người quản lí dự án, khách hàng lập trình viên , kiểm thử để đánh giá được tính khả thi và sai sót của bản kiểm thử
Thiết kế test
Thiết kế test nhằm chỉ định các test case và các bước kiểm tra chi tiết cho mỗi phiên bản phần mềm.
Giai đoạn thiết kế test hết sức quan trọng, nó đảm bảo tất cả các tình huống kiểm tra “quét” hết tất cả yêu cầu cần kiểm tra.
Nó không chi làm một lần, nó sẽ được chỉnh sửa, cập nhật, thêm hoặc bớt xuyên suốt chu kỳ phát triển phần mềm, vào bất cứ lúc nào có sự thay đổi yêu cầu hoặc sau khi phân tích thấy cần được sửa chữa hoặc bổ sung.
Các bước thiết kế test:
- Xác định và mô tả test case
- Mô tả các bước chi tiết để kiểm tra
- Xem xét và khảo sát độ bao phủ của việc kiểm tra
- Xem xét test case và các bước kiểm tra
Phát triển test script
Thường không bắt buộc trong các loại và mức kiểm tra, chỉ yêu cầu trong những trường hợp đặc thù cần thiết kế, tạo ra các test script có khả năng chạy trên máy tính giúp tự động hóa việc thực thi các bước kiểm tra đã định nghĩa ở bước thiết kế test.
Các bước thiết kế test script bao gồm:
- Tạo test script
- Kiểm tra test script
- Thành lập các bộ dữ liệu ngoài dành cho test script
- Xem xét và khảo sát độ bao phủ của việc kiểm tra
Đánh giá kết quả test: là việc đánh giá toàn bộ quá trình kiểm thử bao gồm xem xét và đánh giá kết quả kiểm thử, liệt kê lỗi, chỉ định các yêu cầu thay đổi và tính toán các số liệu liên quan đến quá trình kiểm thử, số lượng lỗi, phân loại lỗi….
Nó được tiến hành song song với bất kì lần kiểm thử nào và chỉ chấm dứt khi quá trình kiểm thử đã hoàn thành
Các công cụ kiểm thử
Vai trò của công cụ kiểm thử:
- Giảm nhân lực kiểm thử và công sức thự hiện kiểm thử
- Giảm thời gian kiểm thử
- Giảm sai sót và tang độ tin cậy
- Giảm sự nhàm chán
- Rèn luyện kỹ năng lập trình cho kiểm thử viên
- Giúp thực hiện việc kiểm thử phần mềm một cách tự động và nó thường được sử dụng khi :
- Không đủ tài nguyên
- Kiểm tra khả năng vận hành trong một môi trường đặc biệt
Các bước kiểm thử tự động:
- Tạo test script
- Chỉnh sửa test script
- Chạy test script để kiểm thử tự động
- Đánh giá kết quả
Thuận lợi khó khăn trong kiểm thử tự động:
Thuận lợi:
- Không cần sự can thiệp của kiểm thử viên
- Giảm chi phí thực hiện khi kiểm thử với số lượng lớn hoặc phải lập lại nhiều lần
- Giả lập được các tình huống khó có thể làm thủ công
Khó khăn:
- Mất các chi phí để tạo các script
- Yêu cầu kiểm thử viên có kỹ năng cao để tạo các script kiểm thử tự động
- Không áp dụng khi tìm lỗi mới của phần mềm
Các công cụ kiểm thử như selenium, quick test professional, jtest, junit, winrunner…
Phân loại kiểm thử
Căn cứ vào kỹ thuật kiểm thử (Testing Techniques).
- Kiểm thử tĩnh (Static Testing)
Là phương pháp kiểm thử phần mềm đòi hỏi phải duyệt lại các yêu cầu và các đặc tả bằng tay, thông qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết mà không cần chạy chương trình. Kiểu kiểm thử này thường được sử dụng bởi chuyên viên thiết kế người mà viết mã lệnh một mình.
Kiểm thử tĩnh cũng có thể được tự động hóa. Nó sẽ thực hiện kiểm tra toàn bộ bao gồm các chương trình được phân tích bởi một trình thông dịch hoặc biên dịch mà xác nhận tính hợp lệ về cú pháp của chương trình.
- Kiểm thử động (Dynamic Testing)
Là phương pháp kiểm thử phần mềm thông qua việc dùng máy chạy chương trình để điều tra trạng thái tác động của chương trình. Đó là ki ểm thử dựa trên các ca kiểm thử xác định bằng sự thực hiện của đối tượng kiểm thử hay chạy các chương trình. Kiểm thử động kiểm tra cách thức hoạt động của mã lệnh, tức là kiểm tra sự phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian.
Trong kiểm thử động, phần mềm phải thực sự được biên dịch và chạy. Kiểm thử động thực sự bao gồm làm việc với phần mềm, nhập các giá trị đầu vào và kiểm tra xem liệu đầu ra có như mong muốn hay không. Các phương pháp kiểm thử động gồm có kiểm thử Unit – Unit Tests, Kiểm thử tích hợp – Intergration Tests, Kiểm thử hệ thống –System Tests, và Kiểm thử chấp nhận sản phẩm – Acceptance Tests.
Căn cứ vào mức độ giai đoạn (Testing Level)
Kiểm thử phần mềm gồm có các cấp độ: Kiểm thử đơn vị, Kiểm thử tích hợp, Kiểm thử hệ thống và Kiểm thử chấp nhận sản phẩm.
- Kiểm tra mức độ, đơn vị (Unit Test)
Một đơn vị là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được. Ví dụ, các hàm (Function), thủ tục (Procedure), lớp (Class) hay 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 thử, ghi nhận và phân tích kết quả kiểm thử. 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 thử và sửa lỗi ở các mức kiểm thử 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ỳ phát triển phần mềm.
Thông thường, Unit Test đòi hỏi kiểm thử 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 thử 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 với các mục kiểm thử khác, Unit Test c ũng đòi h ỏi phải chuẩn bị trước các ca kiểm thử (Test case) hoặc kịch bản kiểm thử (Test script), trong đó chỉ định rõ dữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn. Các Test case và Test script này nên được giữ lại để tái sử dụng.
- Kiểm tra tích hợp (Intergration Test)
Integration testing là một loại kiểm thử phần mềm mà tìm kiếm để kiểm tra các giao diện giữa các thành phần dựa vào thiết kế của phần mềm. Các thành phần phần mềm có thể được tích hợp lại với nhau theo cách lặp đi lặp lại (từng phần nhỏ ghép lại với nhau, rồi ghép tiếp phần nhỏ khác vào nữa, hành động này lặp lại cho đến khi kết hợp toàn bộ phần mềm) hoặc tất cả các thành phần cùng tích hợp một lần (gọi là “big bang”). Thông thường trước đây được xem là một cách làm tốt hơn từ khi nó cho phép các vấn đề về giao diện được xác định vị trí nhanh hơn và cố định.
Integration testing làm việc để tìm ra lỗi (defect) trong các giao diện và giao tiếp giữa các thành phần (mô-đun). Các nhóm thành phần phần mềm đã được kiểm thử lớn dần từng bước tương ứng với các yếu tố của thiết kế kiến trúc đã được tích hợp và kiểm thử cho đến khi phần mềm hoạt động như một hệ thống.
- Kiểm tra mức hệ thống (System Test)
System testing kiểm thử một hệ thống đã được tích hợp hoàn chỉnh để xác minh rằng nó đáp ứng được yêu cầu. Kiểm thử tích hợp hệ thống chứng thực rằng hệ thống đã được tích hợp với các hệ thống bên ngoài hoặc hệ thống thứ ba đã được xác định trong các yêu cầu hệ thống.
- Kiểm tra hồi quy (Regression Test)
Regression testing tập trung vào việc tìm kiếm lỗi sau khi xảy ra việc thay đổi code. Đặc biệt, nó tìm kiếm theo cách hồi qui (đệ qui) hoặc kiểm tra các bug cũ có bị lại hay không. Hồi qui như vậy xảy bất cứ khi nào mà chức năng phần mềm trước đây làm việc đúng đã ng ưng làm việc theo mong đợi. Điển hình, hồi qui xảy ra như là một kết quả không mong muốn của việc thay đổi chương trình, khi phần code của phần mềm mới được phát triển xung độ với code cũ đang có. Phương pháp thông thường của kiểm tra hồi quy là bao gồm việc chạy lại các kiểm thử trước đây và kiểm tra xem có lỗi đã đư ợc fixed trước đây bị lỗi lại (bị lại các lỗi cũ đã fixed rồi). Độ sâu của việc kiểm thử phụ thuộc vào các giai đoạn trong quá trình phát hành và rủi ro của các tính năng được thêm vào. Chúng có thể được hoàn thành – vì việc thay đổi đã thêm vào sau bản phát hành hoặc coi nó là mạo hiểm, rất hời hợt,bao gồm các kiểm thử trường hợp đúng (positive) trên từng chức năng – nếu các thay đổi được thêm vào trước khi phát hành hoặc coi nó ít rủi ro.
- Kiểm tra chấp nhận sản phẩm (Acceptance Testing)
Kiểm thử chấp nhận có thể có là một trong hai điều sau đây:
- Một smoke test được sử dụng như là một acceptance test trước khi giới thiệu bảnbuild mới để thực hiện việc kiểm thử chính, có nghĩa là trư ớc khi thực hiện kiểm thử tích hợp hoặc hồi qui.
- Acceptance testing được thực thi bởi khách hàng, thường được thực hiện trong môi trường thí nghiệm trên phần cứng của họ, được biết như là kiểm thử chấp nhận người dùng (viết tắt là UAT). Acceptance testing có thể được thực hiện như là một phần của quá trình chuyển giao (hand-off) giữa 2 pha của quá trình phát triển phần mềm.
- Alpha Test:
Alpha testing là việc kiểm thử hoạt động chức năng thực tế hoặc giả lập do người dùng/khách hàng tiềm năng hoặc một nhóm test độc lập thực hiện tại nơi sản xuất phần mềm. Alpha testing thường dùng cho phần mềm đóng gói sẵn để bán (ví dụ như MS office, window, chương trình diệt virus) là một hình thức kiểm thử chấp nhận nội bộ, trước khi phần mềm được tiến hành kiểm thử beta.
- Beta Test:
Beta testing được thực hiện sau alpha testing. Các phiên bản của phần mềm -được biết như là các phiên bản beta – chúng được phát hành tới một số lượng giới hạn khán giả bên ngoài nhóm sản xuất phần mềm. Sản phẩm được phát hành đến một số nhóm người để test nhiều hơn nữa có thể chắc chắn rằng sản phẩm có một số bug. Thỉnh thoảng, các phiên bản beta được phát hành rộng rãi để tăng phạm vi phản hồi từ một lượng người sử dụng tương lai lớn nhất.
Căn cứ vào phương pháp kiểm thử (Testing Methods)
Ba trong số những chiến lược kiểm thử thông dụng nhất bao gồm: Kiểm thử hộp đen, Kiểm thử hộp trắng, và Kiểm thử hộp xám.
- Kiểm thử hộp trắng
Kiểm thử hộp trắng hay kiểm thử hướng logic cho phép khảo sát cấu trúc bên trong của chương trình. Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chương trình (và cả mã lệnh thực hiện chúng).
Các phương pháp kiểm thử hộp trắng:
- Kiểm thử giao diện lập trình ứng dụng - API testing (application programming interface): là phương pháp kiểm thử của ứng dụng sử dụng các API công khai và riêng tư.
- Bao phủ mã lệnh – Code coverage: tạo các kiểm tra để đáp ứng một số tiêu chuẩn về bao phủ mã lệnh.
- Các phương pháp gán lỗi – Fault injection.
- Các phương pháp kiểm thử hoán chuyển – Mutation testing methods.
- Kiểm thử tĩnh – Static testing: kiểm thử hộp trắng bao gồm mọi kiểm thử tĩnh.Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sự hoàn thành của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử hộp đen.
- Kiểm thử hộp đen
Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen, hướng dữ liệu, hay hướng vào/ra. Kiểm thử hộp đen xem chương trình như là một “hộp đen”. Mục đích của kiểm thử viên là hoàn toàn không quan tâm về cách cư xử và cấu trúc bên trong của chương trình. Thay vào đó, tập trung vào tìm các trư ờng hợp mà chương trình không th ực hiện theo các đặc tả của nó.
Theo hướng tiếp cận này, dữ liệu kiểm tra được lấy chỉ từ các đặc tả.
Các phương pháp kiểm thử hộp đen:
- Phân lớp tương đương – Equivalence partitioning.
- Phân tích giá trị biên – Boundary value analysis.
- Kiểm thử mọi cặp – All-pairs testing.
- Kiểm thử fuzz – Fuzz testing.
- Kiểm thử dựa trên mô hình – Model-based testing.
- Ma trận dấu vết – Traceability matrix.
- Kiểm thử thăm dò – Exploratory testing.
- Kiểm thử dựa trên đặc tả – Specification-base testing.
Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềm theo những yêu cầu thích hợp. Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra từ đối tượng kiểm thử. Mức kiểm thử này thường yêu cầu các kiểm thử viên xác minh là đối với dữ liệu đầu vào đã cho, giá trị đầu ra (hay cách thức hoạt động) có giống với giá trị mong muốn trong ca kiểm thử đó hay không. Kiểm thử dựa trên đặc tả là cần thiết, nhưng không đủ để để ngăn chặn những rủi ro chắc chắn.
Ưu điểm và nhược điểm: Các tester kiểm thử theo phương pháp black box không có “mối ràng buộc” nào với code, và nhận thức của một tester rất đơn giản: một source code có nhiều lỗi. Sử dụng nguyên tắc, "Hỏi và bạn sẽ nhận" các tester black box tìm được nhiều bug ở nơi mà các DEV không tìm thấy. Mặt khác, việc kiểm thử black box được xem như "là bước đi trong mê cung tối đen mà không mang đèn pin” bởi vì tester không biết phần mềm đang test đã đư ợc xây dựng như thế nào.
Vì vậy, black box testing có ưu điểm là "an unaffiliated opinion" (một quan điểm độc lập), mặt khác, nó có nhược điểm là "blind exploring" (khám phá mù).
- Kiểm thử hộp xám
Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuật bên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở mức người sử dụng hay mức hộp đen. Việc thao tác tới dữ liệu đầu vào và định dạng dữ liệu đầu ra là không rõ ràng, giống như một chiếc “hộp xám”, bởi vì đầu vào và đầu ra rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống được kiểm tra. Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp –Intergartion testing giữa 2 modun mã lệnh được viết bởi hai chuyên viên thiết kế khác nhau, trong đó chỉ giao diện là được đưa ra để kiểm thử. Kiểm thử hộp xám có thể cũng bao g ồm cả thiết kế đối chiếu để quyết định, ví dụ, giá trị biên hay thông báo lỗi.