Ta thấy rằng số lượng lớn các sai sót có thể là nguyên nhân gây ra một lỗi ở bất kỳ giai đoạn nào trong vòng đời phát triển phần mềm và, kết quả của sai sót đó có thể nhỏ cũng có thể là rất nghiêm trọng. Kiểm thử một cách chặt chẽ là cần thiết trong khi phát triển và bảo trì hệ thống nhằm nhận dạng lỗi, giảm thiểu những hỏng hóc trong môi trường vận hành và tăng chất lượng của hệ thống vận hành. Điều này bao gồm cả việc tìm kiếm các sai sót có khả năng xảy ra như khi
nhập dữ liệu đầu vào hoặc đưa ra kết quả dữ liệu đầu ra, và tìm kiếm các điểm yếu của hệ thống trong trường hợp bị tấn công và phá hoại. Thực hiện kiểm thử giúp chúng ta cải thiện dần chất lượng sản phẩm và dịch vụ, đó chỉ là một trong những phương thức kiểm chứng và xác thực được áp dụng cho sản phẩm. Một trong các phương thức kiểm chứng khác có thể được sử dụng kiểm tra công việc, một số trong số chúng được thực hiện bởi chính tác giả, và một số được thực hiện bởi các đối tượng khác nhằm có được một hướng nhìn độc lập.
Chúng ta có lẽ cũng được yêu cầu để tiến hành kiểm thử phần mềm nhằm đạt được các yêu cầu về giao kèo, yêu cầu hợp pháp, hoặc các chuẩn đặc tả công nghiệp. Các chuẩn này có thể đặc tả các kỹ thuật chúng ta sử dụng, hoặc tỷ lệ mã chương trình phải được sử dụng.
2.5.3.1 Kiểm thử bao nhiêu là đủ?
Vậy chúng ta nên tiến hành kiểm thử bao nhiêu? Ta có được lựa chọn kiểm thử một thứ, tất cả mọi thứ, không kiểm thử gì hay chỉ tiến hành kiểm thử một số? Câu trả lời lập tức là “Mọi thứ phải được kiểm thử”. Ta không muốn sử dụng phần mềm mà chưa qua tiến hành kiểm thử. Điều này có nghĩa rằng chúng ta phải thử nghiệm mọi khía cạnh của một hệ thống phần mềm khi tiến hành công việc kiểm thử. Chúng ta cần phải cân nhắc xem phải làm gì, hay có thể làm gì để hoàn thành công việc đó.
Như vậy ta cần tiến hành công việc kiểm thử một cách thấu đáo bao nhiêu là đủ? Ví dụ, có bao nhiêu trường hợp sẽ cần phải tiến hành kiểm thử cho một trường số - một ký tự? Câu hỏi là, „Bạn phải đưa ra các tình huống gì để hoàn thành công việc kiểm thử này?‟ Có 10 khả năng các giá trị số đúng, tất cả các giá trị sai sẽ bị loại bỏ. Có 26 ký tự viết hoa, 26 ký tự viết thường, ít nhất 6 ký tự đặc biệt và các ký tự kết thúc câu, ký tự trắng. Như thế có ít nhất 68 trường hợp để kiểm tra trường số-một ký tự.
Thực tế ta không thể thực hiện kiểm thử quá nhiều như vậy. Các hệ thống thực tế có nhiều hơn một trường nhập liệu, và các trường có độ dài khác nhau. Các trường hợp này sẽ cần thực thi trên các môi trường khác nhau. Nếu ta lấy ví dụ, một màn hình nhập có 15 trường giá trị đầu vào, mỗi trường có 5 khả năng kiểm thử, vậy để kết hợp kiểm thử tất cả các giá trị đầu vào là đúng, ta sẽ cần 515 trường hợp! Điều đó có vẻ không hợp lý để thực hiện được số lượng các ca kiểm thử là quá lớn.
Áp lực trên một dự án bao gồm thời gian, ngân sách, sự cần thiết để đưa ra một giải pháp kỹ thuật đáp ứng được mong muốn của khách hàng. Khách hàng và các nhà quản lý dự án sẽ thực hiện trực tiếp kiểm thử. Công việc này sẽ ngăn
chặn được các hỏng hóc sau khi bàn giao, góp phần vào chi phí sản phẩm. Công việc kiểm tra là hoàn thành - nếu nó đơn giản là những gì khách hàng yêu cầu – hay những gì khác hàng không chấp nhận.
Chúng ta tiếp cận công việc kiểm thử bằng cách sắp xếp công việc kiểm thử
cần làm, đưa ra các rủi ro về phía khách hàng, stackholders, dự án và phần mềm.
Đánh giá và quản lý rủi ro là một trong những hoạt động quan trọng của bất kỳ dự án nào, là hoạt động cơ bản. Quyết định xem kiểm thử bao nhiêu là đủ nên được tính toán dựa trên mức của rủi ro, bao gồm cả rủi ro về kỹ thuật và nghiệp vụ liên quan đến sản phẩm và ràng buộc dự án như thời gian và ngân sách.
Kiểm thử cung cấp thông tin tin cậy cho các stakeholders, để thông báo các quyết định bàn giao phần mềm hoặc hệ thống mà ta kiểm thử, chuyển đến bước phát triển tiếp theo hoặc bàn giao cho khách hàng. Nguồn lực đưa vào đảm bảo chất lượng và các hoạt động kiểm thử cần tính toán đến các rủi ro và các chi phí được kết hợp với dự án. Do sự hạn chế của ngân sách, thời gian và trong khi
kiểm thử chúng ta cần quyết định công việc kiểm thử dựa trên các rủi ro.
2.5.3.2 Cần kiểm thử những gì?
Ta bắt đầu sẽ tìm hiểu về kiểm thử dưới dạng quy trình, sau đó là các đối tượng của quy trình kiểm thử.
- Quy trình - Kiểm thử giống một quy trình hơn một hoạt động đơn lẻ - trên đó là một chuỗi các hoạt động.
- Tất cả các hoạt động theo chu trình - Lỗi được phát hiện càng muộn trong vòng đời tìm lỗi thì chi phí sửa lỗi càng cao. Nếu ta có thể tìm và sửa các lỗi ngay ở giai đoạn tìm hiểu yêu cầu, sẽ giúp cho quy hiệu quả kinh tế của sản phẩm phần mềm được nâng cao. Chúng ta sẽ xây dựng được phần mềm đúng đắn chi phí thấp. Bởi vậy, quy trình kiểm thử được thiết kế ngay từ đầu có thể ngăn chặn được các lỗi sinh ra ở giai đoạn code về sau. Đôi khi
ta liên hệ điều này với việc „kiểm chứng lại cơ sở kiểm thử thông qua thiết
kế ca kiểm thử‟. Cơ sở việc kiểm thử dựa trên các tài liệu như đặc tả yêu cầu, đặc tả thiết kết.
- Cả kiểm thử tĩnh và động – Các ca kiểm thử bằng việc thực thi code để chứng minh kết quả của các bước chạy kiểm thử (thường gọi là kiểm thử động), chúng ta cũng có thể tìm ra các sai sót mà không chay đoạn code nào - cách kiểm thử này gọi là kiểm thử tĩnh. Việc kiểm thử tĩnh bao gồm xem xét tài liệu (gồm cả mã nguồn) và phân tích tĩnh. Đây là lợi ích và hiệu quả chi phí của kiểm thử.
- Lập kế hoạch – Các hoạt động diễn ra trước và sau khi thực thi kiểm thử. Chúng ta cần quản lý công việc kiểm thử; Ví dụ, ta lập kế hoạch cho những công việc cần làm; điều khiển các hoạt động kiểm thử; báo cáo tiến trình kiểm thử và trạng thái phần mềm thông qua việc kiểm thử; và ta kết thúc kiểm thử khi hoàn thành một giai đoạn .
- Sự chuẩn bị - Chúng ta cần chọn cái cần kiểm thử và ta sẽ làm điều đó bằng cách lựa chọn điều kiện kiểm thử, thiết kế các tình huống kiểm thử.
- Đánh giá – Ngay khi thực hiện các công việc kiểm thử, chúng ta phải kiểm tra kết quả và đánh giá phần mềm dưới góc độ kiểm thử và điều kiện hoàn thành giúp ta quyết định xem có kết thúc công việc kiểm thử hay không và sản phẩm phần mềm có vượt qua được công đoạn kiểm thử chưa.
- Dò lỗi – Chúng ta thường nghĩ về kiểm thử phần mềm với ý nghĩa là dò tìm những thiếu sót hoặc nhược điểm trong khi vận hành bắt nguồn từ nguyên nhân không tương thích. Việc tìm ra những nhược điểm giúp ta hiểu được các rủi ro kết hợp trong phần mềm đưa vào việc sử dụng hệ thống, đóng lỗi cải thiện chất lượng sản phẩm. Phân tích được nguyên nhân gốc rễ của lỗi phát sinh cũng giúp ta cải thiện nâng cấp các quy trình phát triển và ít gây lỗi hơn trong công việc tiếp theo.
Đây là định nghĩa phù hợp của kiểm thử ở bất kỳ mức nào, từ kiểm thử đơn vị đến kiểm thử chấp nhận, nó đem lại cho chúng ta dưới nhiều mục tiêu khác nhau, và được lưu lại trong các báo cáo kiểm thử.
2.5.3.3 Khi nào mục tiêu kiểm thử được đáp ứng?
Chúng ta có thể sử dụng cả hai hình thức kiểm thử động và tĩnh để đạt được các mục tiêu kiểm thử. Cả hai đều cung cấp thông tin để cải thiện hệ thống được kiểm thử, các quy trình phát triển và kiểm thử. Kiểm thử nhằm các mục tiêu:
Tìm lỗi
Đảm bảo và cung cấp các thông tin về chất lượng sản phẩm.
Ngăn chặn lỗi (adsbygoogle = window.adsbygoogle || []).push({});
Rất nhiều hoạt động xem xét và kiểm thử diễn ra ở các giai đoạn khác nhau trong vòng đời phát triển phần mềm. Kiểm thử sớm – thiết kế kiểm thử và các hoạt động xem xét – tìm và sửa lỗi cần được thực hiện sớm và kịp thời ngay khi chúng còn ở mức chi phí thấp. Mỗi lần code được viết ra, lập trình viên, nhân viên kiểm thử thường chạy một tập các tình huống để có thể xác định lỗi và sửa lỗi phần mềm.
Trong “kiểm thử phát triển” này (bao gồm kiểm thử từng cấu phần riêng lẻ, tích hợp và kiểm thử hệ thống), mục tiêu chính là để tìm ra các nguyên nhân gây
hỏng hóc, các khả năng phát hiện lỗi và sửa lỗi. Tiếp theo, những người dùng phần mềm có thể tiến hành kiểm thử chấp nhận để xác nhận rằng hệ thống làm việc theo như mong đợi, đáp tứng được đầy đủ các yêu cầu.
Sửa lỗi không phải là mục tiêu kiểm thử hay đưa ra kết quả mong muốn. Đôi khi, ta chỉ muốn tập hợp thông tin và đo được chất lượng phần mềm. Có một số yếu tố đo phần mềm như thời gian giữa hai lần lỗi gặp liên tiếp để đánh giá khả năng tin cậy, hoặc sự đánh giá mật độ lỗi phần mềm từ đó xác định được rủi ro
khi bàn giao sản phẩm.
2.5.3.4 Các yếu tố cơ bản trong kiểm thử [2]
Bảng 2: Các yếu tố cơ bản trong kiểm thử
1 Kiểm thử chỉ ra sự hiện diện
của lỗi.
Kiểm thử chỉ ra rằng sản phẩm có các lỗi, nhưng không thể chứng minh được là sản phẩm đó là không có lỗi. Kiểm thử làm giảm khả năng còn lỗi phần mềm, nhưng khi không tìm thấy lỗi thì cũng không có nghĩa là ta kết luận được phần mềm là chạy đúng.
2 Kiểm thử một cách thấu đáo
là không thể
Kiểm thử mọi thứ (kết hợp đầu vào và các tiền điều kiện) là hoàn toàn không khả thi với các trường hợp tầm thường. Thay vì việc kiểm thử thấu đáo tất cả ta sẽ tập trung nguồn lực vào việc xem xét các rủi ro, và mức độ ưu tiên.
3 Kiểm thử sớm
Các hoạt động kiểm thử hệ thống hoặc vòng đời phát triển phần mềm cần được bắt đầu ngay khi có thể, và tập trung vào mục tiêu đã định nghĩa.
4 Phân vùng lỗi
Một số các module chứa hầu hết các lỗi phát hiện được trong khi tiến hành kiểm thử, hoặc chỉ ra các lỗi thường xuyên nhất.
5 Loại trừ các lỗi lặp
Nếu các lỗi giống nhau lặp đi lặp lại nhiều lần, như vậy người kiểm thử sẽ không tập trung tìm được các lỗi mới. Để phát hiện "loại trừ các lỗi lặp" thì các trường hợp kiểm thử cần được xem xét
thường xuyên và hiệu chỉnh lại, các kiểm thử mới phải được viết ra và thực hành với các phần khác nhau trong phần mềm hoặc hệ thống để tìm các lỗi tiềm năng.
6 Kiểm thử phụ thuộc ngữ
cảnh
Kiểm thử được tiến hành khác nhau trong các hoàn cảnh khác nhau. Ví dụ kiểm thử cho các phần mềm được bảo mật khác với việc kiểm thử các trang thương mại.
7 Thiếu các lỗi giả định
Tìm và sửa lỗi không giúp gì nếu việc xây dựng hệ thống là không tiện lợi, không đáp ứng những gì người dùng cần và mong đợi.
Chương 3: Kiểm thử trên cơ sở các mô hình UML