Tìm hiểu các giai đoạn TEST

Các giai đoạn TEST bao gồm:

- Unit Test

- IntergrationTest

- System Test

- Acceptance Test

Cụ thể:

Thứ nhất: Unit Test (khái niệm)

   Một Unit là thành phần nhỏ nhất của phần mềm, như là: Function, Procedure, Class, Method

   Là kỹ thuật kiểm nghiệm các hoạt động của mọi chi tiết mã với một quy trình tách biệt với QTPTPM giúp phát hiện sai sót kịp thời trước khi đưa ra test.

Unit Test (đặc điểm)

   Test ở mức thấp nhất

   Sử dụng phương pháp test hộp trắng

   Kiểm tra độc lập từng thành phần

   Thường được thực hiện bởi lập trình viên

   Có giá trị khi phát hiện các vấn đề tiềm ẩn hoặc lỗi kỹ thuật

Thứ hai: Intergration Test (khái niệm) 

   Là 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

   Mục đích

ü  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ỏ và cuối cùng là nguyên hệ thống hoàn chỉnh

Intergration Test (Type)

   Kiểm tra cấu trúc (structure): Tương tự White Box Test, 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

   Kiểm tra chức năng (functional): Tương tự Black Box Test, 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 vận hành của hệ thống

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

Intergration -Plan

   Cần được thực hiện tương đương với giai đoạn thiết kế kiến trúc

   Thứ tự tích hợp được xác định theo thứ tự xây dựng

ü  Các thành phần hoàn thành đúng thời hạn

ü  Phát triển các thành phần và test tích hợp được thực hiện song song

Intergration - Guidelines

   Mỗi thành phần sẽ được tích hợp 1 lần (tích hợp theo hướng tăng dần

                   Baseline 0: test thành phần

                   Baseline 1: 2 thành phần

                   Baseline 2: 3 thành phần)

   Tích hợp từng mục nhỏ của từng thành phần tại một thời điểm

ü  Các thành phần chính hoặc thành phần có khả năng nhiều lỗi

ü  Kết hợp các thành phần liên quan đơn giản 

Intergration - Approaches

   Top-down

   Bottom-down

   Big-bang  

(phần này sẽ có 1 bài viết chi tiết từng loại top/bottom down và bigbang, chỉ ra Ưu nhược điểm của 3 phương pháp đó)

Thứ ba: System Test (khái niệm)

   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

   Là Black box test

   Được thực hiện độc lập bởi một nhóm test (test hệ thống) 

   Về chức năng, thỏa mãn:

ü  Requirements-based testing

•          Các yêu cầu là điều kiện đầu tiên cho việc test

•          Phân tích rủi ro để xác định thành phần quan trọng nhất

ü  Business process-based testing

•          Người sử dụng mong đợi: cái gì được sử dụng thường xuyên và quan trọng nhất cho việc kinh doanh

•          Thực hiện các giao dịch kinh doanh quan trọng 

   Yêu cầu phi chức năng:

ü  Usability

ü  Security

ü  Storage

ü  Volume

ü  Configuration/installation

ü  Reliability/qualities

ü  Back-up/recovery

ü  Performance, load, stress

ü  Functional

Thứ tư: Acceptance Test (khái niệm)

   Được thực hiện sau giai đoạn System test, do khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ 3 thực hiện)

   Mục đích: chứng minh phần mềm thỏa mãn tất cả các yêu cầu của khách hàng

   Đối với những PM bán rộng rãi trên thị trường, cần thực hiện: Alpha test và Beta Test

   Alpha test: người sử dụng kiểm tra phần mềm ngay tại nơi PTPM, lập trình viên ghi nhận lỗi hoặc phản hồi và lên kế hoạch sửa chữa

   Beta test: PM được gửi tới cho người sử dụ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 

Phân biệt Tester và QA

- Tester:Thử lại mọi thứ xem vận hành đúng mức hay chưa

- Test dựa vào những kế hoạch test hay chiến lược test được xây dựng trong khi thiết kế nhằm đạt được yêu cầu sử dụng của người sử dụng cuối

- QA là test Quy Trình(hiểu theo nghĩa quy trình làm PM). Quy mô của quy trình này phụ thuộc vào từng công ty và mức CMM (Capability Maturity Model) của công ty đó.

- Nhận kết quả từ phòng test

- Đốc thúc các bộ phận khác như Develop Team để đảm bảo tiến độ release theo đúng kế hoạch.

- QA còn chịu trách nhiệm viết User Guide và có thể là thuyết trình trước khách hàng về sản phẩm

Điểm khác biệt giữa Tester & QA

- Một điều quan trọng hơn QA là bộ phận chịu hoàn toàn trách nhiệm về chất lượng của phần mềm khi nó được đưa đến tay người dùng

- QA có phạm vi rộng hơn Tester, có nhiều ràng buộc hơn, tính trách nhiệm cũng cao hơn, và nói chung là mệt hơn

:-)) 

Tìm hiểu về DYNAMIC TESTING

Khái niệm: Kiểm thử tự động phần mềm (Test Automation) là: Quá trình xử lý

một cách tự động các bước thực hiện các TC bằng việc sử dụng các công cụ kiểm

thử (máy tính, chương trình, phần mềm,…)

Kiểm thử phần mềm chiếm đến 40% công sức của một dự án phát triển.Tự

động hóa là nhu cầu thiết yếu. Việc KTTĐ thường được xem xét trong một số tình

huống sau:

-         Không đủ tài nguyên: Khi số lượng TC quá nhiều mà Tester không thể hoàn

tất trong thời gian cụ thể.

-         Kiểm tra hồi quy: Khi phần mềm có sự thay đổi hay nâng cấp tại các phiên

bản.

-         Kiểm tra khả năng vận hành phần mềm trong môi trường đặc biệt: Xác

định các yếu tố về phần cứng, phần mềm ảnh hưởng đến khả năng vận hành của

phần mềm. Một số vấn đề như:

• Tốc độ xử lý trung bình

• Số lượng yêu cầu cùng một lúc tối đa mà phần mềm đáp ứng được

• Cấu hình phần cứng thấp nhất mà phần mềm vẫn có thể hoạt động

được

v Quy trình kiểm thử thường bao gồm các bước:

1. Lập kế hoạch kiểm thử

2. Thiết kế kịch bản (test script) hay trường hợp kiểm thử (test case)

3. Tạo dữ liệu thử

4. Thực hiện kiểm thử và ghi nhận kết quả

5. Kiểm tra, phân tích, đánh giá kết quả

6. Lập báo cáo quá trình kiểm thử

Quy Trình Kiểm thử phần mềm

1) Lập kế hoạch kiểm thử (planning test)

Mục đích: Nhằm chỉ định và mô tả mục tiêu, phạm vi, tài nguyên, ràng buộc,

môi trường, các mạo hiểm, các phương pháp kiểm tra sẽ được triển khai và thực

hiện. Kết quả của bước lập kế hoạch là bản tài liệu kế hoạch KTPM, bao gồm nhiều

chi tiết từ các loại kiểm tra, chiến lược kiểm tra, cho đến thời gian và phân định lực

lượng kiểm tra viên.

Bản kế hoạch kiểm tra đầu tiên được phát triển rất sớm trong chu trình

PTPM, 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 đó tất 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.

Bảng kế hoạch chình và các bản kế hoạch chi tiết.

Tùy theo đặc trưng và độ phức tạp của mỗi dự án, các kế hoạch kiểm tra chi

tiết có thể được gom chung vào bản kế hoạch chính hoặc được phát triển riêng.

Sau khi bản kế hoạch chính được phát triển, các bản kế hoạch chi tiết lần lượt

được thiết kế theo trình tự thời gian phát triển của dự án. Quá trình phát triển các kế

hoạch kiểm tra không dừng lại tại một thời điểm, mà liên tục được cập nhật chỉnh

sửa cho phù hợp đến tận cuối dự án.

Các bước lập kế hoạch:

• Xác định yêu cầu kiểm tra: chỉ định bộ phận, thành phần của phần mềm sẽ

được kiểm tra, phạm vi hoặc giới hạn của việc kiểm tra. Yêu cầu kiểm tra cũng

được dùng để xác định nhu cầu nhân lực.

• Khảo sát rủi ro: Các rủi ro có khả năng xảy ra làm chậm hoặc cản trở quá

trình cũng như chất lượng kiểm tra. Ví dụ: kỹ năng và kinh nghiệm của kiểm tra

viên quá yếu, không hiểu rõ yêu cầu.

• Xác định chiến lược kiểm tra: chỉ định phương pháp tiếp cận để thực hiện

việc kiểm tra trên phần mềm, chỉ định các kỹ thuật và công cụ (tool) hỗ trợ kiểm tra,

chỉ định các phương pháp dùng để đánh giá chất lượng kiểm tra cũng như điều kiện

để xác định thời gian kiểm tra.

• Xác định nhân lực, vật lực: kỹ năng, kinh nghiệm của kiểm tra viên; phần

cứng, phần mềm, công cụ, thiết bị giả lập… cần thiết cho việc kiểm tra.

• Lập kế hoạch chi tiết: ước lượng thời gian, khối lượng công việc, xác định

chi tiết các phần công việc, người thực hiện, thời gian tất cả các điểm mốc của quá

trình kiểm tra.

• Tổng hợp và tạo các bản kế hoạch kiểm tra: kế hoạch chung và kế hoạch

chi tiết.

• Xem xét các kế hoạch kiểm tra: phải có sự tham gia của tất cả những

người có liên quan, kể cả trưởng dự án và có thể cả khách hàng. Việc xem xét nhằm

bảo đảm các kế hoạch là khả thi, cũng như để phát hiện (và sữa chữa sau đó) các sai

sót trong các bản kế hoạch.

2) Thiết kế kịch bản hay trường hợp kiểm thử

Một kịch bản (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ó khăn 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.

• Một trường hợp kiểm thử (Test Case-TC) là một tình huống kiểm tra,

được thiết kế để kiểm tra một đối tượng có thỏa mãn yêu cầu đặt ra hay không. Một

TC thường bao gồm 4 phần cơ bản:

• Điều kiện: đặc tả các điều kiện cần có để tiến hành kiểm tra.

• Đầu vào: đặ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ả mong đợi trả về từ đối tượng kiểm tra.

• Kết quả thực tế: kết quả thực tế trả về từ đối tượng kiểm tra.

a. Thiết kế Test case

Mục đích: Nhằm chỉ định các TC 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 là hết sức quan trọng, nó bảo đảm 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.

Việc thiết kế test không phải chỉ làm một lần, nó sẽ được sửa chữa, cập nhật,

thêm hoặc bớt xuyên suốt chu kỳ PTPM, 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 bao gồm:

• Xác định và mô tả TC: xác định các điều kiện cần thiết lập trước và trong

lúc kiểm tra. Mô tả mục đích, yêu cầu kiểm tra, đối tượng hoặc dữ liệu đầu vào, mô

tả các kết quả mong chờ sau khi kiểm tra, môi trường kiểm tra.

• Mô tả các bước chi tiết để kiểm tra: Thao tác này nhằm chi tiết hóa các

bước của một TC, cũng như chỉ định các loại dữ liệu nào cần có để thực thi các TC,

chúng bao gồm các loại dữ liệu trực tiếp, gián tiếp, trung gian, hệ thống…

• Xem xét và khảo sát độ bao phủ của việc kiểm tra: mô tả các chỉ số và

cách thức xác định việc kiểm tra đã hoàn thành hay chưa? Bao nhiêu phần trăm

phần mềm đã được kiểm tra? Để xác định điều này có hai phương pháp: căn cứ trên

yêu cầu của phần mềm hoặc căn cứ trên số lượng code đã viết.

• Xem xét TC và các bước kiểm tra: Việc xem xét cần có sự tham gia của

tất cả những người có liên quan, kể cả trưởng dự án nhằm bảo đảm các TC và dữ

liệu yêu cầu là đủ và phản ánh đúng các yêu cầu cần kiểm tra, độ bao phủ đạt yêu

cầu, cũng như để phát hiện (và sữa chữa) các sai sót.

Các kỹ thuật thiết kế Test Case:

• Kỹ thuật dựa trên đặc tả – hộp đen: Tìm kiếm lỗi theo cách của hệ thống

thực hiện.

• Kỹ thuật dựa trên cấu trúc – hộp trắng: Tìm kiếm lỗi theo cách hệ thống

được xây dựng.

Hai kỹ thuật trên sẽ được mô tả chi tiết hơn ở phần sau.

• Kỹ thuật dựa trên kinh nghiệm: Tạo kiểm thử chủ yếu nhờ vào sự hiểu biết

về hệ thống, kinh nghiệm quá khứ, phương pháp phỏng đoán về lỗi. Có thể được

hướng dẫn bởi: Danh sách các ý kiểm tra, việc phân loại lỗi, liệt kê các kiểu tấn

công, cách tiếp cận “săn” lỗi, tập các lý do kiểm thử.

b. Phát triển Test Script

Mục đích: Bước này 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 phát triển Test Script bao gồm:

• Tạo Test Script: thủ công hoặc dùng công cụ hỗ trợ để phát sinh script một

cách tự động (tuy nhiên trong hầu hết mọi trường hợp, ta vẫn phải chỉnh sửa ít hoặc

nhiều trên các script được sinh tự động). Thông thường, mỗi bước kiểm tra được

thiết kế trong phần thiết kế test, đòi hỏi ít nhất một Test Script. Các Test Script có

khả năng tái sử dụng càng nhiều càng tốt để tối ưu hóa công việc.

• Kiểm tra Test script: xem có “chạy” tốt không nhằm bảo đảm các Test

Script hoạt động đúng yêu cầu, thể hiện đúng ý đồ của các bước kiểm tra.

• Thành lập các bộ dữ liệu ngoài dành cho các Test Script: bộ dữ liệu này sẽ

được các Test Script sử dụng khi thực hiện kiểm tra tự động. Gọi là “ngoài” vì

chúng được lưu độc lập với các Test Script

• Xem xét và khảo sát độ bao phủ của việc kiểm tra: bảo đảm các Test

Script được tạo ra bao phủ toàn bộ các bước kiểm tra theo yêu cầu.

3) Tạo dữ liệu thử

Kiểm thử với tất cả các dữ liệu vào là cần thiết, nhưng chúng ta không thể

thực hiện kiểm thử “vét cạn” được. Do đó nên chọn tập các dữ liệu thử đại diện từ

miền dữ liệu vào dựa trên các tiêu chuẩn chọn dữ liệu thử. Yêu cầu đối với bộ dữ

liệu kiểm thử là phải phủ kín được mọi trường hợp cần đánh giá.

4) Thực hiện kiểm thử và ghi nhận kết quả

a) Chuẩn bị môi trường

Thực tế bước này thực hiện song song với quá trình thiết kế các TC và Test

Script và được thực hiện bởi cán bộ chuyên trách. Mục đích là khảo sát môi trường

phần cứng cũng như phần mềm phục vụ cho việc thực thi test: phần cứng, phần

mềm, máy chủ, mạng, dữ liệu, …

b) Thực thi test

Thực thi các bước kiểm tra đã thiết kế có thể test không có dữ liệu đầu vào

(test chay) hoặc sử dụng bộ dữ liệu đã chuẩn bị ở bước trước.

Giám sát quá trình này đến khi hoàn thành hay bị treo giữa chừng, đồng thời

ghi nhận các kết quả cần thiết. Nếu quá trình diễn ra trơn tru thì cần xem xét lại độ

tin cậy của kết quả kiểm thử, nhận biết các vấn đề do ảnh hưởng của những yếu tố

ngoài phần mềm như: bộ dữ liệu, môi trường, TC, Test Script,… Nếu quá trình bị

treo hoặc dừng giữa chừng cần phân tích để xác định nguyên nhân và đưa ra hướng

giải quyết.

Vấn đề là Test bao nhiêu là đủ?

Khi nào thì nên dừng việc kiểm thử? Rất khó để xác định điều này. Sau đây

là một vài trường hợp phổ biến:

- Một số lượng lỗi nhất định được tìm thấy

- Tỷ lệ mà lỗi được tìm thấy là quá nhỏ

- Những rủi ro của dự án ở mức chấp nhận được

- Đạt đến yêu cầu phạm vi test

- Ngân sách kiểm thử hết

- Hết thời gian

- …

Nhìn chung, quyết định dừng kiểm thử dựa trên mức độ rủi ro của dự án có

chấp nhận được hay không?

5) Kiểm tra, phân tích, đánh giá kết quả

Bước này mang tính thẩm tra toàn cục, nhằm vào giá trị của các kết quả kiểm

tra. Bao gồm:

-         Phân tích kết quả kiểm tra và đề xuất yêu cầu sửa chữa: Chỉ định và đánh

giá sự khác biệt giữa kết quả mong chờ và kết quả kiểm tra thực tế, tổng hợp và gửi

thông tin yêu cầu sửa chữa đến những người có trách nhiệm trong dự án, lưu trữ để

kiểm tra sau đó.

-         Đánh giá độ bao phủ: Xác định quá trình kiểm tra có đạt được độ bao phủ

yêu cầu hay không, tỷ lệ yêu cầu đã được kiểm tra (tính trên các yêu cầu của phần

mềm và số lượng code đã viết).Tổng hợp và phân tích lỗi: Số lượng lỗi, phân loại lỗi. Đưa ra số liệu phục

vụ cho việc cải tiến các qui trình phát triển, giảm sai sót cho các chu kỳ phát triển

và kiểm tra sau đó. Ví dụ, tính toán tỷ lệ phát sinh lỗi, xu hướng gây ra lỗi, những

lỗi “ngoan cố” hoặc thường xuyên tái xuất hiện.

-         Xác định quá trình kiểm tra có đạt yêu cầu hay không.

-         Tính toán các số liệu khác liên quan đến quá trình kiểm tra chẳng hạn số

giờ, thời gian kiểm tra, …

6) Lập báo cáo

Ở bước này, Tester tổng hợp các kết quả thực thi test, lập tài liệu báo cáo

(Test result report) và gửi cho tất cả những người có liên quan. Nội dung chủ yếu

của tài liệu này:

Giới thiệu tài liệu

Giới thiệu các test item mục tiêu

Các TC dự kiến thực hiện, đã thực hiện

Kết quả chi tiết của việc thực hiện từng TC

Thống kê tỉ lệ TC được thực hiện và tỉ lệ thành công của các TC.

Đưa ra các yêu cầu mới

Ghi chú về các hiện tượng cần theo dõi thêm

Nếu được kết luận đã đủ tốt, sản phẩm sẽ được ứng dụng trong thực tiễn.

Nhận xét

Bảng nhận xét về kiểm thử tự động

Thuận lợi	Khó khăn
KTPM không cần quá nhiều can thiệp của Tester .	Mất chi phí tạo các script để thực hiệnKTTĐ.
Giảm chi phí khi thực hiện kiểm tra sốlượng lớn TC hoặc TC lặp lại nhiều lần	Tốn chi phí dành cho bảo trì các script.
Giả lập tình huống khó có thể thực hiệnbằng tay.	Đòi hỏi Tester phải có kỹ năng tạoscript KTTĐ.
Tăng độ tin cậy bởi nâng cao mức độ baophủ trường hợp kiểm thử.	Không áp dụng được trong việc tìm lỗimới của phần mềm.

Tìm hiểu về STATIC TESTING

Khái niệm: Phương pháp này sử dụng giấy, bút để kiểm tra logic, lần lượt từng logic,

ngay sau khi lập trình xong. Chủ yếu kiểm tra tính đúng đắn của mã lệnh, thuật toán và các tài liệu đặc tả.

-         Ngoài ra có thể xem xét các yêu cầu và thông số kỹ thuật.

-         Kiểm thử tĩnh cũng có thể được thực hiện một cách tự động. Trong các môi

trường lập trình, thường có sẵn một trình thông dịch hay biên dịch kiểm tra tính

đúng đắn của cú pháp chương trình, đó cũng là một cách kiểm thử tĩnh nhưng được

thực hiện tự động.

-         Những người tham gia vào quá trình này thường là các nhà phát triển ứng

dụng, thử nghiệm, các nhà phân tích kinh doanh.

Có hai phương pháp chính là thanh tra và duyệt.

1) Thanh tra

Là phương pháp kiểm tra ngang hàng sản phẩm phần mềm được thực hiện

bởi những người nghiên cứu riêng lẻ để tìm ra những lỗi có thể bằng một tiến trình

chuẩn cho trước.

v Một cuộc thanh tra bao gồm:

Đặc tả phần mềm

Kế hoạch thanh tra

Sản phẩm phần mềm

Điều phối viên

Thanh tra viên

Tác giả phần mềm

v Tiến trình thanh tra:

Lên kế hoạch

Gặp gỡ trước

Chuẩn bị

Gặp gỡ thanh tra

Gia công lại

Bám sát

Chú ý: các khâu 3,4,5 có thể thực hiện lặp lại

2) Duyệt

Là một phương pháp kiểm tra ngang hàng với một người thiết kế hướng

nhóm phát triển đến các hoạt động chú ý của quá trình sản xuất phần mềm, tham gia

đặt câu hỏi và chú thích cho các lỗi có thể có.

v Tiến trình duyệt:

Đánh giá đầu vào

Chuẩn bị quản lý

Lập kế hoạch

Gặp gỡ trước

Chuẩn bị riêng

Duyệt

Gia công / bám sát

Kết thúc

Nhận xét:

Phương pháp kiểm thử tĩnh nhằm tìm kiếm những thiếu sót hơn là tìm kiếm

những hoạt động không mong đợi. Phương pháp này thường tốn chi phí hơn so với

kiểm thử động nhất là khi kiểm thử hồi quy.

Kiến thức tối thiểu về kiểm thử phần mềm

1. Các phương pháp kiểm thử phần mềm (Software Testing Methods)
   • Black Box Testing – Phân vùng tương đương (Equivalence partitioning)
   • White Box Testing
     • Unit Test Case
     • Kiểm thử trong giai đoạn lập trình (Testing at Programming / Coding Phase)
   • Gray Box Testing
2. Các loại kiểm thử phần mềm (Software Testing Types)
   • Build Verification Testing
   • Regression Testing
   • User Acceptance Testing
   • Agile Testing
3. Các chiến lược kiểm thử phần mềm (Software Testing Strategies)
   • Kiểm thử dựa trên yêu cầu (requirements based test)
   • Smoke test / Build verification test
   • User acceptance test
   • Regression test
   • Kiểm thử từ trên xuống so với kiểm thử từ dưới lên (Top Down Testing vs Bottom up Testing)
4. Errors, Defects and Bugs
   • Software Errors
   • Phân loại Defects / Bugs
   • Vòng đời của lỗi (Bug Life Cycle)
   • Thông báo lỗi kiểm thử phần mềm (Software Testing Bug Report)
   • Báo lỗi mẫu kiểm thử phần mềm (Software Testing Bug Report Template)

III. Kiến thức kiểm thử phần mềm nâng cao

1. Các phương pháp kiểm thử phần mềm (Software Testing Methods)
   • Usability Testing
   • Penetration Testing
   • Installation Testing
   • Network Protocol Testing
   • Security Testing
   • Rapid Testing
   • Pairwise Testing
   • Localization Testing
   • Task-Based Software Testing
   • Thread Based Integration Testing
   • Spiral Testing Approach
2. Kiểm thử phần mềm hiệu quả (Effective Software Testing)
   • When requirements are changing continuously
   • Find more bugs while doing Software Testing
   • Shortage of time for thorough software testing
3. Phân tích các nỗ lực kiểm thử (Analyzing the Testing Effort)
   • Software Testing Metrics
   • Defect Removable Efficiency
   • Test Efficiency Vs Test Effectiveness
4. Quản lý và lập kế hoạch kiểm thử phần mềm (Software Testing Management and Planning)
   • Software Testing Estimation Process
   • Organizing the Test Team
   • Test Readiness Review Checklist
   • Identify Testing Types and Exit Criteria
   • Software Test Planning
   • Testing Bible – Software Test Plan Document
   • Test Specification
   • Test Strategy
   • When software is ready to ship or release
5. Những kiến thức kiểm thử phần mềm khác
   • Testware
   • Testing – NAS (Network Attached Storage)
   • Usability Testing Lab
   • Testing Client Server Applications
   • Qualities of a Good Software Test / QA Engineer
   • Qualities of a good QA or Test Lead / Manager
   • Responsibilities of a Test Manager / Lead
   • Software Testing as a Continuous Improvement Process
   • Integration Testing – Four step procedure
   • How to do Integration Testing – writing Integration Testing test cases
   • When software is ready to ship or release
   • Xác nhận (Validation) so với xác minh (Verification), xem lại (Reviews), và kiểm duyệt (Inspections)
   • Kỹ thuật (Techniques) và cấp độ (Levels) kiểm thử phần mềm
6. Từ điển kiểm thử phần mềm (Software Testing Dictionary)

Tổng quan về kiểm thử

Kiểm thử phần mềm là một cuộc kiểm tra được tiến hành để cung cấp cho các bên liên quan thông tin về chất lượng của sản phẩm hoặc dịch vụ được kiểm thử.^[1] Kiểm thử có thể cung cấp cho doanh nghiệp một quan điểm, một cách nhìn độc lập về phần mềm để từ đó cho phép đánh giá và thấu hiểu được những rủi ro trong quá trình triển khaiphần mềm.

Trong kỹ thuật kiểm thử không chỉ giới hạn ở việc thực hiện một chương trình hoặc ứng dụng với mục đích đi tìm cáclỗi phần mềm (bao gồm các lỗi và các thiếu sót) mà còn là một quá trình phê chuẩn và xác minh một chương trình máy tính / ứng dụng / sản phẩm nhằm:

• Đáp ứng được mọi yêu cầu hướng dẫn khi thiết kế và phát triển phần mềm.
• Thực hiện công việc đúng như kỳ vọng.
• Có thể triển khai được với những đặc tính tương tự.
• Và đáp ứng được mọi nhu cầu của các bên liên quan.

Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất cứ lúc nào trong quá trình phát triển phần mềm. Theo truyền thống thì các nỗ lực kiểm thử được tiến hành

sau khi các yêu cầu được xác định và việc lập trình được hoàn tất nhưng trong Agile (là một tập hợp các phương pháp phát triển phần mềm linh hoạt dựa trên việc lặp đi lặp lại và gia tăng giá trị) thì việc kiểm thử được tiến hành liên tục trong suốt quá trình xây dựng phần mềm. Như vậy, mỗi một phương pháp kiểm thử bị chi phối theo một quy trình phát triển phần mềm nhất định.

Kiểm thử không thể xác định hoàn toàn được tất cả các lỗi bên trong phần mềm.^[2] Thay vào đó, nó so sánh trạng thái và hành vi của sản phẩm với các oracle - các nguyên tắc hay cơ chế để phát hiện vấn đề. Các oracle này có thể bao gồm (nhưng không giới hạn ở) các đặc tả phần mềm, hợp đồng,^[3] sản phẩm tương đương, các phiên bản trước của cùng một sản phẩm, phù hợp với mục đích dự kiến nhằm đáp ứng sự kỳ vọng của người dùng, khách hàng, quy định của pháp luật hiện hành và các tiêu chuẩn liên quan khác.

Mục đích chính của kiểm thử là phát hiện ra các lỗi phần mềm để từ đó khắc phục và sửa chữa. Việc kiểm thử không thể khẳng định được rằng các chức năng của sản phẩm đúng trong mọi điều kiện, mà chỉ có thể khẳng định rằng nó không hoạt động đúng trong những điều kiện cụ thể.^[4] Phạm vi của kiểm thử phần mềm thường bao gồm việc kiểm tra mã, thực hiện các mã trong môi trường và điều kiện khác nhau, và việc kiểm thử các khía cạnh của mã: nó có làm đúng nhiệm vụ của nó hay không, và nó có làm những gì cần phải làm hay không. Trong môi trường phát triển phần mềm hiện nay, một đội kiểm thử có thể tách biệt với đội phát triển. Các thành viên trong đội kiểm thử giữ các vai trò khác nhau. Các thông tin thu được từ kiểm thử có thể được sử dụng để điều chỉnh quá trình phát triển phần mềm.^[5]

Mỗi sản phẩm phần mềm có một đối tượng phục vụ riêng. Ví dụ như đối tượng của phần mềm trò chơi điện tử là hoàn toàn khác với đối tượng của phần mềm ngân hàng. Vì vậy, khi một tổ chức phát triển hoặc đầu tư vào một sản phẩm phần mềm, họ có thể đánh giá liệu các sản phẩm phần mềm có được chấp nhận bởi người dùng cuối, đối tượng phục vụ, người mua, hay những người giữ vai trò quan trọng khác hay không. Và việc kiểm thử phần mềm là một quá trình nỗ lực để đưa ra những đánh giá này.

Khiếm khuyết và thất bại[sửa | sửa mã nguồn]

Không phải tất cả các khiếm khuyết của phần mềm bị gây ra bởi lỗi lập trình mà cội nguồn chung của các khiếm khuyết đó nằm ở những thiếu sót trong yêu cầu; ví dụ, yêu cầu không được xác nhận mà gây ra lỗi là sự sơ suất của các nhà thiết kế của chương trình.^[6] Những thiếu sót yêu cầu thường thấy trong những yêu cầu phi chức năng như là khả năng kiểm thử, khả năng mở rộng, bảo trì, tính khả dụng, hiệu suất, và khả năng bảo mật.

Lỗi phần mềm xảy ra thông suốt quá trình như sau: Một lập trình viên làm cho một lỗi (sai lầm), mà kết quả cho ra là một khiếm khuyết (thất bại, sai sót) trong mã nguồn phần mềm. Nếu lỗi này được thực hiện, trong những tình huống nhất định hệ thống sẽ tạo ra kết quả sai, gây ra một sự thất bại.^[7] Không phải tất cả các khiếm khuyết nhất thiết sẽ dẫn đến thất bại. Ví dụ, lỗi trong mã chết sẽ không bao giờ dẫn đến thất bại. Lỗi có thể biến thành một sự thất bại khi môi trường thay đổi. Ví dụ về những thay đổi trong môi trường bao gồm các phần mềm đang chạy trên một nền tảng phần cứng máy tính mới, thay đổi trong nguồn dữ liệu, hoặc tương tác với các phần mềm khác nhau. Một khiếm khuyết duy nhất có thể dẫn đến một loạt các dấu hiệu thất bại.

Kết nối đầu vào và điều kiện tiền đề[sửa | sửa mã nguồn]

Một vấn đề rất cơ bản với kiểm thử phần mềm là việc kiểm thử tất cả các kết nối đầu vào và điều kiện tiền đề (trạng thái ban đầu) là không khả thi, ngay cả với một sản phẩm đơn giản.^[4][8] Điều này có nghĩa rằng số lượng các khiếm khuyết trong một sản phẩm phần mềm có thể rất lớn và có thể xảy ra thường xuyên nên rất khó để tìm thấy trong quá trình kiểm thử. Quan trọng hơn, những yêu cầu phi chức năng về chất lượng (làm nó như thế nào hơn là làm được gì?) như: tính khả dụng, khả năng mở rộng, hiệu suất, khả năng tương thích, độ tin cậy nếu xét về mặt chủ quan thì nó chưa tạo nên giá trị đủ để mọi người có thể chấp nhận được nó.

Các nhà phát triển phần mềm không thể kiểm thử được tất cả mọi thứ, nhưng họ có thể sử dụng tổ hợp thiết kế kiểm thử để xác định số lượng tối thiểu của các kiểm thử cần thiết để bao quát được những điều họ muốn. Dù là kiểm thử tốc độ hay độ sâu thì họ có thể sử dụng phương pháp này để xây dựng được những cơ cấu khác nhau trong từng trường hợp kiểm thử (test case) cụ thể.^[9]

Kinh tế[sửa | sửa mã nguồn]

Một nghiên cứu được tiến hành bởi NIST trong năm 2002 cho biết rằng các lỗi phần mềm gây tổn thất cho nền kinh tế Mỹ 59,5 tỷ đô mỗi năm, hơn một phần ba chi phí này có thể tránh được nếu việc kiểm thử phần mềm được thực hiện tốt hơn.^[10]

Người ta thường tin rằng, một kiếm khuyết nếu được tìm ra sớm hơn thì chi phí để sửa chữa nó sẽ rẻ hơn. Bảng dưới đây cho thấy chi phí sửa chữa các khiếm khuyết tùy thuộc vào giai đoạn nó được tìm ra.^[11] Ví dụ, một vấn đề được tìm thấy sau khi đã ra bản phần mềm chính thức rồi sẽ có chi phí gấp 10-100 lần khi giải quyết vấn đề từ lúc tiếp nhận yêu cầu. Với sự ra đời của cách thức triển khai thực tiễn liên tục và các dịch vụ dựa trên đám mây, chi phí tái triển khai và bảo trì có thể làm giảm bớt theo thời gian.

theo wiki