Manual Testing
Các định nghĩa và thuật ngữ kiểm thử phần mềm
Bài này bao gồm một danh sách các thuật ngữ và các định nghĩa. Các thuật ngữ này
mô tả những khái niệm nền tảng về quá trình phát triển phần mềm và kiểm thử phần
mềm. Bởi vì chúng thường rất lộn xộn và được sử dụng không hợp lý, chúng được định
nghĩa ở đây như một cặp để giúp bạn hiểu ý nghĩa thật sự chúng và sự khác nhau giữa
chúng. Hãy ý thức rằng nhiều người không bằng lòng về ngành công nghiệp phần mềm
với những khái niệm của nhiều công ty, được phổ biến rộng rãi, (đó là các thuật ngữ).
Là một tester, bạn nên thường xuyên làm rõ ràng ý nghĩa của các thuật ngữ mà đội của
bạn sử dụng. Thường thì đây là cách tốt nhất để một khái niệm được đồng tình hơn là
bạn phải cố gắng để mọi người chấp nhận rằng thuật ngữ đó là đúng.
a) Precision (tập chung) và accuracy (chính xác)
Là một tester, điều quan trọng là bạn phải biết sự khác nhau giữa precision và accuracy.
Hãy coi như bạn đang kiểm thử phần mềm Calculator. Bạn có nên kiểm tra rằng các
câu trả lời phần mềm trả về cho bạn là precise hay accurate? Hay cả hai? Nếu lịch làm
việc của dự án buộc bạn phải đưa ra những quyết định dựa trên sự rủi ro và bạn chỉ được
chọn một trong những từ này, khi đó, bạn sẽ chọn từ nào?
Nếu phần mềm mà bạn kiểm tra là mô phỏng một chò chơi như bóng chày hoặc mô
phỏng một chuyến bay. Trước hết, bạn có nên kiểm tra khả năng precision của nó hoặc
khả năng accuracy của nó?
Hình dưới mô tả một cách hình ảnh về 2 thuật ngữ này. Mục đích của trò phóng phi tiêu
này (dart game) là ném trúng vào tâm của tấm bảng. Phi tiêu trên tấm bảng phía trên bên
trái là không precise mà cũng không accurate. Chúng không được tập chung lại cùng
nhau mà cũng không trúng tâm của tấm bảng.
Những cây phi tiêu trên tấm bảng giải thích về sự khác nhau giữa 2 thuật ngữ Precision
và Accuracy
Tấm bảng phía trên, bên phải biểu diễn những cây phi tiêu precise nhưng không
accurate. Chúng tập chung lại thành một nhóm, vì vậy người ném đã thực hiện
precision, nhưng anh ta không accurate bởi vì các cây phi tiêu không trúng đích.
Tấm bảng ở phía dưới, bên trái là một ví dụ về sự accuracy nhưng lại thiếu sự precision.
Nhưng cây phi tiêu này đều trúng đích. Người ném đã ném trúng mục tiêu mà anh ta
nhắm đến, nhưng những cây phi tiêu không nằm tập chung tại một vị trí.
Tấm bảng ở phía dưới, bên phải là sự kết hợp hoàn hảo của precision và accuracy. Các
cây phi tiêu tập chung tại một chỗ và đều trúng đích.
Phần mềm bạn kiểm tra cần có đạt precise hay accurate hay không phụ thuộc rất nhiều
vào cái đích mà sản phẩm cuối cùng của bạn hướng tới. Phần mềm Calculator giống
là phần mềm đòi hỏi cả hai yêu cầu đều phải đạt được. Nhưng, cũng có thể quyết định
rằng Calculator sẽ chỉ đạt yêu cầu về sự chính xác (accurate) và sự tập chung (precise)
đạt tới chữ số thập phân thứ 5. Sau tất cả, sự tập chung (precision) có thể thay đổi. Tùy
thuộc vào việc tester nhận thức về bản đặc tả như thế nào. Họ có thể tự thiết kế những
bài kiểm tra của họ để chứng minh những nhận định của họ.
b) Verification (sự kiểm tra) và Validation (sự xác nhận)
Verification và Validation thường được sử dụng thay thế cho nhau nhưng thực chất
chúng là các khái niệm khác nhau. Sự khác nhau này rất quan trọng trong kiểm thử phần
mềm.
Verification là quy trình xác nhận rằng một số khía cạnh của phần mềm là phù hợp với
bản đặc tả của nó. Validation là quy trình xác nhận rằng phần mềm phù hợp với yêu cầu.
của người sử dụng.
Chúng có vẻ như rất giống nhau, nhưng một lời giải thích cho các
vấn đề kính thiên văn không gian Hubble (Hubble space telescope) sẽ giúp biểu diễn sự
khác nhau này.
Vào tháng 4 năm 1990, Kính thiên văn không gian Hubble (Hubble space telescope)
được đưa vào quỹ đạo quanh trái đất. Là một thiết bị phản chiều, Hubble sử dụng một
l tấm gương lớn như một phương tiện chính để khuếch đại đối tượng mà nó nhằm tới.
Quá trình chế tạo tấm gương này là đỏi sự chính xác và tập chung tuyệt đối. Kiểm tra
tấm gương rất khó, từ khi chiếc kính thiên văn này được thiết kế để sử dụng trong không
gian và người ta không thể xác định được vị trí, thậm chí là nó có tầm nhìn xuyên suốt
ngay cả khi nó vẫn ở trên trái đất. Với những lý do này thì chỉ có một cách kiểm tra tốt
nhất là đo đạc cẩn thận tất cả các thuộc tính của nó và so sánh với những tiểu chuẩn đã
được chỉ ra. Quá trình kiểm tra này đã được thực thi và Hubble được tuyên bố là đã sẵn
sàng.
Nhưng thật không may, ngay sau khi nó được đưa vào quỹ đạo hoạt động, các bức ảnh
nó gửi về không hề có trung tâm. Tổ chức điều tra đã khám phá ra rằng tấm gương đã
được chế tạo không hợp lý. Khi ở trên mặt đất, tấm gương này đã được sản xuất theo
đúng bản đặc tả, nhưng bản đặc tả này lại sai. Tấm gương vô cùng precise nhưng nó
không accurate. Quá trình kiểm tra đã xác nhận rằng tấm gương được sản xuất đã đáp
ứng được sự kiểm tra của bản đặc tả (spec verification), nhưng nó không xác nhận được
rằng nó đáp ứng được yêu cầu cơ bản (original requirementvalidation).
Năm 1993, một phái đoàn trên tài con thoi đã sửa kính thiên văn Hubble bằng cách cài
đặt một “corrective len” để lấy lại trung tâm của những bức ảnh được chụp bởi Hubble.
Mặc dù không có một ví dụ về phần mềm, verification và validation áp dụng tốt như
nhau với quá trình kiểm thử. Chứa từng có bản đặc tả nào là đúng. Nếu bạn thay đổi bản
đặc tả và thông qua sản phẩm cuối cùng, thì bạn sẽ tránh được những vấn đề như với
chiếc kính thiên văn Hubble.
c) Quality (chất lượng) và reliability (sự đáng tin cậy)
Trong cuốn từ điển của trường cao đẳng Merriam-Webster đã định nghĩa rằng quality là
“độ đo sự hoàn hảo” hoặc “sự vượt chội về thứ hạng”. Nếu sản phẩm phần mềm có chất
lượng cao, nó sẽ đáp ứng được nhu cầu của khách hàng. Khách hàng sẽ cảm thấy sản
phẩm hoàn hảo và nó sẽ được sắp thứ hạng cao hơn trong danh sách lựa chọn của khách
hàng.
Tester có thể cảm thấy 2 khái niệm quality và reliability là gần như nhau. Họ cảm thấy
rằng nếu như họ có thể kiểm tra một chương trình cho đến khi nó chạy ổn định và có
thể tin tưởng được (realiability). Khi đó, họ có thể quả quyết rằng sản phẩm đã đạt chất
lượng tốt. Nhưng thật không may, điều này không hẳn đã đúng. Reliability chỉ là một
khía cạnh của quality.
Quan niệm về quality của người sử dụng phần mềm có thể bao gồm cả sự thoải mái
của các feature, sản phẩm có khả năng chạy trên cả những PC cũ, dịch vụ hậu mãi của
các công ty phần mềm, và thường bao gồm cả giá cả của sản phẩm. Sự tin tưởng hoặc
cách thức mà phần mềm thâm nhập vào dữ liệu của khách hàng, có thể là rất quan trọng,
nhưng không phải lúc nào cũng thế.
Chắc rằng, với một chương trình có chất lượng cao và đáng tin cậy, thì tester phải kiểm
tra và thông qua trong suốt quá trình phát triển sản phẩm.
Testing (Kiểm thử) và quality assurance (đảm bảo chất lượng) (QA)
Cặp khái niệm cuối cùng là testing và quality assurance (có thể viết tắt là QA). Hai thuật
ngữ này, một cái thường được sử dụng để mô tả nhóm hoặc quá trình kiểm tra và xác
nhận chất lượng phần mềm. Bạn sẽ được tìm hiểu nhiều hơn về thước đo chất lượng
phần mềm, nhưng trước tiên hãy xem xét những khái niệm sau:
• Mục đích của testing là tìm ra lỗi, tìm thấy chúng sớm nhất có thể, và đảm bảo
rằng chúng đã được sửa.
• Trách nhiệm chính của người QA là tạo và bắt phần mềm phải tuân theo các
chuẩn để cải tiến quy trình phát triển phần mềm và ngăn chặn các lỗi xuất hiện
bất cứ lúc nào
Dĩ nhiên, 2 khái niệm này vẫn có sự chồng chéo nhau. Một số tester sẽ làm nhiệm ụ QA,
một số thì thực thi việc kiểm tra. Hai công việc này cùng các nhiệm vụ của nó có quan
hệ chặt chẽ với nhau. Tuy nhiên khó mà tránh khỏi sự lộn xộn giữa các thành viên làm
nhiện vụ kiểm thử (testing) và các thành viên đảm bảo chất lượng phần mềm (QA).
Mô hình chữ V
Mô hình chữ V sẽ giúp chúng ta hình dung về quy trình test trong toàn bộ kế hoạch thực
hiện dự án.
Bài này bao gồm một danh sách các thuật ngữ và các định nghĩa. Các thuật ngữ này
mô tả những khái niệm nền tảng về quá trình phát triển phần mềm và kiểm thử phần
mềm. Bởi vì chúng thường rất lộn xộn và được sử dụng không hợp lý, chúng được định
nghĩa ở đây như một cặp để giúp bạn hiểu ý nghĩa thật sự chúng và sự khác nhau giữa
chúng. Hãy ý thức rằng nhiều người không bằng lòng về ngành công nghiệp phần mềm
với những khái niệm của nhiều công ty, được phổ biến rộng rãi, (đó là các thuật ngữ).
Là một tester, bạn nên thường xuyên làm rõ ràng ý nghĩa của các thuật ngữ mà đội của
bạn sử dụng. Thường thì đây là cách tốt nhất để một khái niệm được đồng tình hơn là
bạn phải cố gắng để mọi người chấp nhận rằng thuật ngữ đó là đúng.
a) Precision (tập chung) và accuracy (chính xác)
Là một tester, điều quan trọng là bạn phải biết sự khác nhau giữa precision và accuracy.
Hãy coi như bạn đang kiểm thử phần mềm Calculator. Bạn có nên kiểm tra rằng các
câu trả lời phần mềm trả về cho bạn là precise hay accurate? Hay cả hai? Nếu lịch làm
việc của dự án buộc bạn phải đưa ra những quyết định dựa trên sự rủi ro và bạn chỉ được
chọn một trong những từ này, khi đó, bạn sẽ chọn từ nào?
Nếu phần mềm mà bạn kiểm tra là mô phỏng một chò chơi như bóng chày hoặc mô
phỏng một chuyến bay. Trước hết, bạn có nên kiểm tra khả năng precision của nó hoặc
khả năng accuracy của nó?
Hình dưới mô tả một cách hình ảnh về 2 thuật ngữ này. Mục đích của trò phóng phi tiêu
này (dart game) là ném trúng vào tâm của tấm bảng. Phi tiêu trên tấm bảng phía trên bên
trái là không precise mà cũng không accurate. Chúng không được tập chung lại cùng
nhau mà cũng không trúng tâm của tấm bảng.
Những cây phi tiêu trên tấm bảng giải thích về sự khác nhau giữa 2 thuật ngữ Precision
và Accuracy
Tấm bảng phía trên, bên phải biểu diễn những cây phi tiêu precise nhưng không
accurate. Chúng tập chung lại thành một nhóm, vì vậy người ném đã thực hiện
precision, nhưng anh ta không accurate bởi vì các cây phi tiêu không trúng đích.
Tấm bảng ở phía dưới, bên trái là một ví dụ về sự accuracy nhưng lại thiếu sự precision.
Nhưng cây phi tiêu này đều trúng đích. Người ném đã ném trúng mục tiêu mà anh ta
nhắm đến, nhưng những cây phi tiêu không nằm tập chung tại một vị trí.
Tấm bảng ở phía dưới, bên phải là sự kết hợp hoàn hảo của precision và accuracy. Các
cây phi tiêu tập chung tại một chỗ và đều trúng đích.
Phần mềm bạn kiểm tra cần có đạt precise hay accurate hay không phụ thuộc rất nhiều
vào cái đích mà sản phẩm cuối cùng của bạn hướng tới. Phần mềm Calculator giống
là phần mềm đòi hỏi cả hai yêu cầu đều phải đạt được. Nhưng, cũng có thể quyết định
rằng Calculator sẽ chỉ đạt yêu cầu về sự chính xác (accurate) và sự tập chung (precise)
đạt tới chữ số thập phân thứ 5. Sau tất cả, sự tập chung (precision) có thể thay đổi. Tùy
thuộc vào việc tester nhận thức về bản đặc tả như thế nào. Họ có thể tự thiết kế những
bài kiểm tra của họ để chứng minh những nhận định của họ.
b) Verification (sự kiểm tra) và Validation (sự xác nhận)
Verification và Validation thường được sử dụng thay thế cho nhau nhưng thực chất
chúng là các khái niệm khác nhau. Sự khác nhau này rất quan trọng trong kiểm thử phần
mềm.
Verification là quy trình xác nhận rằng một số khía cạnh của phần mềm là phù hợp với
bản đặc tả của nó. Validation là quy trình xác nhận rằng phần mềm phù hợp với yêu cầu.
của người sử dụng.
Chúng có vẻ như rất giống nhau, nhưng một lời giải thích cho các
vấn đề kính thiên văn không gian Hubble (Hubble space telescope) sẽ giúp biểu diễn sự
khác nhau này.
Vào tháng 4 năm 1990, Kính thiên văn không gian Hubble (Hubble space telescope)
được đưa vào quỹ đạo quanh trái đất. Là một thiết bị phản chiều, Hubble sử dụng một
l tấm gương lớn như một phương tiện chính để khuếch đại đối tượng mà nó nhằm tới.
Quá trình chế tạo tấm gương này là đỏi sự chính xác và tập chung tuyệt đối. Kiểm tra
tấm gương rất khó, từ khi chiếc kính thiên văn này được thiết kế để sử dụng trong không
gian và người ta không thể xác định được vị trí, thậm chí là nó có tầm nhìn xuyên suốt
ngay cả khi nó vẫn ở trên trái đất. Với những lý do này thì chỉ có một cách kiểm tra tốt
nhất là đo đạc cẩn thận tất cả các thuộc tính của nó và so sánh với những tiểu chuẩn đã
được chỉ ra. Quá trình kiểm tra này đã được thực thi và Hubble được tuyên bố là đã sẵn
sàng.
Nhưng thật không may, ngay sau khi nó được đưa vào quỹ đạo hoạt động, các bức ảnh
nó gửi về không hề có trung tâm. Tổ chức điều tra đã khám phá ra rằng tấm gương đã
được chế tạo không hợp lý. Khi ở trên mặt đất, tấm gương này đã được sản xuất theo
đúng bản đặc tả, nhưng bản đặc tả này lại sai. Tấm gương vô cùng precise nhưng nó
không accurate. Quá trình kiểm tra đã xác nhận rằng tấm gương được sản xuất đã đáp
ứng được sự kiểm tra của bản đặc tả (spec verification), nhưng nó không xác nhận được
rằng nó đáp ứng được yêu cầu cơ bản (original requirementvalidation).
Năm 1993, một phái đoàn trên tài con thoi đã sửa kính thiên văn Hubble bằng cách cài
đặt một “corrective len” để lấy lại trung tâm của những bức ảnh được chụp bởi Hubble.
Mặc dù không có một ví dụ về phần mềm, verification và validation áp dụng tốt như
nhau với quá trình kiểm thử. Chứa từng có bản đặc tả nào là đúng. Nếu bạn thay đổi bản
đặc tả và thông qua sản phẩm cuối cùng, thì bạn sẽ tránh được những vấn đề như với
chiếc kính thiên văn Hubble.
c) Quality (chất lượng) và reliability (sự đáng tin cậy)
Trong cuốn từ điển của trường cao đẳng Merriam-Webster đã định nghĩa rằng quality là
“độ đo sự hoàn hảo” hoặc “sự vượt chội về thứ hạng”. Nếu sản phẩm phần mềm có chất
lượng cao, nó sẽ đáp ứng được nhu cầu của khách hàng. Khách hàng sẽ cảm thấy sản
phẩm hoàn hảo và nó sẽ được sắp thứ hạng cao hơn trong danh sách lựa chọn của khách
hàng.
Tester có thể cảm thấy 2 khái niệm quality và reliability là gần như nhau. Họ cảm thấy
rằng nếu như họ có thể kiểm tra một chương trình cho đến khi nó chạy ổn định và có
thể tin tưởng được (realiability). Khi đó, họ có thể quả quyết rằng sản phẩm đã đạt chất
lượng tốt. Nhưng thật không may, điều này không hẳn đã đúng. Reliability chỉ là một
khía cạnh của quality.
Quan niệm về quality của người sử dụng phần mềm có thể bao gồm cả sự thoải mái
của các feature, sản phẩm có khả năng chạy trên cả những PC cũ, dịch vụ hậu mãi của
các công ty phần mềm, và thường bao gồm cả giá cả của sản phẩm. Sự tin tưởng hoặc
cách thức mà phần mềm thâm nhập vào dữ liệu của khách hàng, có thể là rất quan trọng,
nhưng không phải lúc nào cũng thế.
Chắc rằng, với một chương trình có chất lượng cao và đáng tin cậy, thì tester phải kiểm
tra và thông qua trong suốt quá trình phát triển sản phẩm.
Testing (Kiểm thử) và quality assurance (đảm bảo chất lượng) (QA)
Cặp khái niệm cuối cùng là testing và quality assurance (có thể viết tắt là QA). Hai thuật
ngữ này, một cái thường được sử dụng để mô tả nhóm hoặc quá trình kiểm tra và xác
nhận chất lượng phần mềm. Bạn sẽ được tìm hiểu nhiều hơn về thước đo chất lượng
phần mềm, nhưng trước tiên hãy xem xét những khái niệm sau:
• Mục đích của testing là tìm ra lỗi, tìm thấy chúng sớm nhất có thể, và đảm bảo
rằng chúng đã được sửa.
• Trách nhiệm chính của người QA là tạo và bắt phần mềm phải tuân theo các
chuẩn để cải tiến quy trình phát triển phần mềm và ngăn chặn các lỗi xuất hiện
bất cứ lúc nào
Dĩ nhiên, 2 khái niệm này vẫn có sự chồng chéo nhau. Một số tester sẽ làm nhiệm ụ QA,
một số thì thực thi việc kiểm tra. Hai công việc này cùng các nhiệm vụ của nó có quan
hệ chặt chẽ với nhau. Tuy nhiên khó mà tránh khỏi sự lộn xộn giữa các thành viên làm
nhiện vụ kiểm thử (testing) và các thành viên đảm bảo chất lượng phần mềm (QA).
Mô hình chữ V
Mô hình chữ V sẽ giúp chúng ta hình dung về quy trình test trong toàn bộ kế hoạch thực
hiện dự án.
Nhận xét
Đăng nhận xét