Nhóm 9: Đề Tài: Tìm Hiểu Về Kiểm Thử Phần Mềm

NHẬP MÔN CÔNG NGHỆ PHẦN MỀM

NHÓM 9:
1.Nguyễn Thị Hiền
2.Nguyễn Thị Hà
3.Vũ Thị Thảo
4.Nguyễn Văn Thuận
                                             Đề Tài:
                              Tìm Hiểu Về Kiểm Thử Phần Mềm


I. Kiểm thử phần mềm là gì?
1. K/N: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ử.
 Đá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.
Hay nói một cách ngắn gọn thì: “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 ra lỗi” – Glen Myers.
2. Các hoạt động của kiểm thử bao gồm: công việc trước và sau khi “chạy” chương trình:
 Lập kế hoạch – điều khiển.
 Chọn điều kiện kiểm tra.
 Thiết kế kịch bản/ Mẫu thử (test case).
 Kiểm tra kết quả.
 Đánh giá các tiêu chuẩn.
 Lập báo cáo quá trình kiểm tra – hệ thống được kiểm tra.
3.Các hướng kiểm tra phần mềm
Có 2 hướng kiểm tra là kiểm tra động và kiểm tra tĩnh. Cả hai hướng đều hướng tới cùng mục tiêu và cung cấp thông tin cải tiến hệ thống lẫn quy trình.
 Mục tiêu:
• Tìm khiếm khuyết
• Ngăn ngừa khiếm khuyết
• Chứng minh được phần mềm hoạt động đúng như đã thiết kế
• Chứng minh được phần mềm đáp ứng yêu cầu của user.
• Tăng độ tin cậy chất lượng sản phẩm.
Khác biệt giữa gỡ rối (debug) và kiểm thử (testing)
 Gỡ rối:
 Hoạt động phát triển.
 Xác định nguyên nhân.
 Sửa chữa mã.
 Kiểm tra lại khiếm khuyết có được sử dụng.
 Developers
 Kiểm thử
 Cho thấy các trường hợp không mong đợi do khiếm khuyết phần mềm.
 Testers.
 Kiểm tra sớm từ lúc thiết kế ngăn ngừa khiếm khuyết khi phát triển mã.
 Rà soát lại tài liệu yêu cầu phần mềm cũng giúp ngăn ngừa các khiếm khuyết.
 Các góc nhìn  khác nhau về kiểm tra tạo ra các mục tiêu khác nhau.
4.Quá trình kiểm thử phần mềm là tốt khi:
 Không dư thừa.
 Có khả năng tìm ra lỗi cao.
 Biết chọn lọc (chỉ kiểm tra những phần nào có khả năng tìm ra lỗi đặc trưng).
 Không quá phức tạp cũng không quá đơn giản.
II.Tại sao phải kiểm thử phần mềm
1.Các hệ thống phần mềm
Dựa trên mục tiêu của nhà sản xuất thì các hệ thống phần mềm:
Gia tăng tiện nghi của cuộc sống.
 Ngân hàng – ATM…
 Sản phẩm tiêu dùng – xe, điện thoại di động…
Tuy nhiên, qua thực tế thì không được như kỳ vọng. Hoạt động không đúng sẽ gây ra nhiều vấn đề về tiền bạc, thời gian, công sức và có thể sẽ tổn hại đến con người…
“Lỗi phần mềm là chuyện hiển nhiên của cuộc sống. Chúng ta có cố gắng đến mức nào thì thực tế là ngay cả những lập trình viên xuất sắc nhất cũng không thể lúc nào cũng viết những đoạn mã không có lỗi. Tính trung bình, ngay cả 1 lập trình viên loại tốt thì cũng có từ 1 đến 3 lỗi trên 100 dòng lệnh. Người ta ước lượng rằng việc tìm ra các lỗi này chiếm phân nửa khối lượng công việc phải làm để có được một phần mềm hoạt động được.”
(Sofware Testing Techniques, Second Edition, by  Boris Beizer, Van Nostrand Reinhold, 1990.)
2.Nguyên nhân các khiếm khuyết.
 Con người tạo ra lỗi (error - mistake).
 Hệ quả là xuất hiện khiếm khuyết (sai lầm/ sai sót – fault, rối - bug).
 Mã, hệ thống, phần mềm, tài liệu đưa ra dư thừa (đưa ra một vài thứ không chính xác vào mô tả yêu cầu phần mềm) hay do bỏ sót, thiếu một số phần đáng ra phải có trong mô tả yêu cầu phần mềm,…
 Khi mã thực thi, hệ thống thực hiện công việc sai xót → thực hiện không mong đợi (failure – hỏng hóc).
Khiếm khuyết có thể xảy ra bởi:
 Áp lực về thời gian
 Mã phức tạp
 Hạ tầng phức tạp
 Thay đổi công nghệ
 Tương tác nhiều hệ thống
3.Vai trò của việc kiểm thử
 Khiếm khuyết tìm thấy được chỉnh sửa trước khi đưa ra sử dụng
 Giảm thiểu rủi ro trong suốt quá trình thực hiện và phân phối với chất lượng phần mềm
 Đáp ứng được các yêu cầu trong hợp đồng, trong luật hay chuẩn công nghiệp…
4. Quan hệ của kiểm thử và chất lượng phần mềm
 Với sự trợ giúp của việc kiểm thử, tìm ra được các khiếm khuyết.
 Tạo sự tin tưởng chất lượng của phần mềm.
 Rút ra bài học từ các dự án thực hiện.
 Hiểu “gốc rễ” của nguyên nhân các khiếm khuyết để cải tiến quá trình với dự án mới và tránh tái diễn sai lầm cũ.
5.Kiểm thử đến mức nào là đủ?
 Việc quyết định bao nhiêu là đủ dựa trên bảng miêu tả các rủi ro.
 Việc kiểm tra nên cung cấp thông tin đủ “thẩm quyền” để đảm bảo ra quyết định chính xác.
6.Các loại kiểm thử
 Kiểm thử phát triển
 Kiểm thử thành phần, tích hợp hệ thống.
 Xác định các nguyên nhân các hoạt động lỗi nhằm sửa khiếm khuyết.
 Kiểm thử chấp nhận
 Chứng thực hệ thống làm việc như yêu cầu của khách hàng.
 Nhằm ước lượng chất lượng phần mềm → có thông tin xác định rủi ro phát hành hệ thống với thời gian đã xác định.
 Kiểm thử bảo trì
 Bao gồm các kiểm tra để bảo đảm không có những khiếm khuyết mới qua việc mở rộng phát triển khi có yêu cầu thay đổi.
 Kiểm thử tác vụ
 Ước lượng các đặc tính của hệ thống: độ tin cậy – tính sẵn sàng.
III.Các nguyên lý tổng quát
 Các nguyên lý tổng quát:
 dẫn tổng quát nhất cho việc kiểm tra.
 Có 7 nguyên lýĐúc kết thông qua quá trình phát triển và qua hướng  chính:
1. Phơi bày biểu hiện của khiếm khuyết
• Cho thấy khiếm khuyết đang tồn tại
• Giảm xác suất xuất hiện khiếm khuyết chưa phát hiện trong phần mềm
2. Không thể vét cạn hết các trường hợp
• Kiểm tra mọi thứ không khả thi.
• Không thể kiểm nghiệm triệt để một phần mềm.
• Ngoại trừ trường hợp không đáng kể
• Thay vào đó phân tích rủi ro, ưu tiên vào nỗ lực kiểm tra, việc nghiên cứu nên hướng về yêu cầu của khách hàng.
3. Kiểm tra sớm
• Nên bắt đầu sớm nhất có thể trong chu kỳ phát triển. Tập trung vào các mục tiêu đã xác định.
4. Gom nhóm các khiếm khuyết
• Thông thường có 1 nhóm nhỏ các module phần mềm gây ra phần lớn các khiếm khuyết của hệ thống.
• Áp dụng nguyên lý Pareto: 80% lỗi có nguyên nhân từ 20% các module
• → Cô lập và kiểm tra nhưng module khả nghi nhất.
5. Nghịch lý thuốc trừ sâu (Pesticide paradox)
• Lặp lại cùng mẫu kiểm tra (Không tìm thấy khiếm khuyết mới)
• Kịch bản cần rà soát và xem xét lại đều đặn.
• Kiểm tra mới – khác cần được viết cho các phần khác để có khả năng tìm nhiều khiếm khuyết.
6. Phụ thuộc ngữ cảnh
• Thực hiện khác nhau trong những ngữ cảnh khác nhau
7. Ảo tưởng “không lỗi” (Absence of errors fallacy)
Tìm và khắc phục khiếm khuyết là vô nghĩa nếu hệ thống xây dựng:
o Vô dụng
o Không đáp ứng yêu cầu cần thiết
o Không đáp ứng yêu cầu người sử dụng
 Các định nghĩa về kiểm thử
• 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)
 Các định nghĩa về kiểm thử
• 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)
IV.Quy trình kiểm thử cơ bản
1.Khái quát:Trước khi tìm hiểu một quy trình kiểm tra phần mềm cơ bản, ta cần hiểu hai khái niệm sau: Test Case và Test Script.
• Test Case
Một Test Case có thể coi nôm na 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.
• 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ó khăn hoặc không khả thi.
2.Lập kế hoạch kiểm tra và điều khiển
• Mục đích:
Nhằm chỉ định và mô tả các loại 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, 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 phát triển phần mềm (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ô ta
3.Các bước lập kế hoạch:
• Xác định yêu cầu kiểm tra.
• Khảo sát rủi ro.
• Xác định chiến lược kiểm tra.
• Xác định nhân lực,vật lực.
• Lập kế hoạch chi tiết.
• Tổng hợp và tạo các bản kế hoạch kiểm tra.
• Xem xét các kế hoạch kiểm tra.
• Xác định yêu cầu kiểm tra.
• Khảo sát rủi ro.
• Xác định chiến lược kiểm tra.
• Xác định nhân lực,vật lực.
• Lập kế hoạch chi tiết.
• Tổng hợp và tạo các bản kế hoạch kiểm tra.
• Xem xét các kế hoạch kiểm tra.
4.Phân tích và thiết kế Test
Các bước thiết kế test bao gồm:
 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.
 Kiểm tra Test script.
 Thành lập các bộ dữ liệu ngoài dành cho các Test Script.
 Xem xét và khảo sát độ bao phủ của việc kiểm tra.
5.Hiện thực và việc thực thi
Quá trình thực hiện kiểm tra thường thông qua các bước sau:
 Thực hiện các bước kiểm tra.
 Đánh giá quá trình kiểm tra.
 Thẩm định kết quả kiểm tra.
6.Đánh giá các tiêu chuẩn và lập báo cáo.
• Đánh giá độ bao phủ.
• Phân tích lỗi.
• Xác định quá trình kiểm tra có đạt yêu cầu hay không.
• Báo cáo tổng hợp.
7.Kiểm tra các hoạt động cuối
 Tập hợp các dữ liệu từ các hoạt động kiểm tra thành công để củng cố:
• Kinh nghiệm .
• Testware.
• Sự kiện.
 Công việc chính:
• Kiểm tra công việc đã phân theo kế hoạch.
• Testware hoàn tất, cất giữ; môi trường kiểm tra, cơ sở hạ tầng… được sử dụng sau.
• Bản giao testware đến tổ chức bảo trì.
• Phân tích bài học học được.
V.Triết lý của việc kiểm thử phần mềm
1.Khái quát về triết lý của việc kiểm thử
• Góc nhìn khi kiểm thử - rà xoát khác so với khi phát triển phần mềm. Đứng trên lập trường của người phát triển. Người phát triển có lỗi suy nghĩ đúng → có thể tự kiểm tra mã mình viết. Tuy nhiên, việc tách riêng cho Tester là đặc thù giúp hỗ trợ tập trung và cung cấp lợi ích gia tăng.
• Ở mức độ độc lập nào đó, thường có hiệu quả trong tìm kiếm khiếm khuyết và hoạt động không mong đợi.
2.Các mức độ độc lập:
• Thiết kế kiểm thử bởi người viết mã
• Thiết kế kiểm thử bởi người khác
• Thiết kế kiểm thử bởi người từ tổ chức khác
• Thiết kế kiểm thử bởi nhóm người từ tổ chức khác
3.Kỹ năng cần có cho một Tester
• Một Tester cần có các kỹ năng giao tiếp, quan hệ tốt.
• Bắt đầu từ sự cộng tác hơn là đối đầu. Truyền thông những kết quả lỗi theo ý trung lập, tập trung sự kiện, không chỉ trích.
• Cố gắng hiểu người khác cảm nhận ra sao và tại sao họ phản ứng lại. Xác nhận lại những gì đã hiểu và chưa hiểu.

                                ------       --------

có các điều kiện kiểm tra nào để chọn ?

nhóm bạn cho mình biết kiểm tra động và kiểm tra tĩnh là gì?

Nói rõ ơn cho mình về "Kiểm thử tác vụ"?

Sự giống và khác nhau của Test Case và Test Script?

mình ko hiểu "Đánh giá độ bao phủ" là ntn?

Nguyên nhân sinh ra Lỗi phần mềm là gì??

có 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 ?

Huyền Vũ đã viết: có 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 ?

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.
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.

Kiểm thử hồi quy được tiến hành khi nào?

Kiểm thử tích hợp sử dụng để làm gì?

Tuân Dolce đã viết:Kiểm thử hồi quy được tiến hành khi nào?

Kiểm thử hồi quy được tiến hành khi phần mềm có thay đổi.

Tuân Dolce đã viết:Kiểm thử tích hợp sử dụng để làm gì?

Kiểm thử tích hợp sử dụng để kiểm thử khi tích hợp các thành phần phần mềm dựa trên thiết kế hệ thống. Các thành phần này có thể tích hợp theo phương pháp từ trên xuống, từ dưới lên hoặc tổng hợp 1 lúc (big bang).

Huyền Vũ đã viết:Nguyên nhân sinh ra Lỗi phần mềm là gì??

Lỗi phần mềm có thể sinh ra do nhiều nguyên nhân ví dụ như yêu cầu phần mềm bị thiếu, yêu cầu không rõ ràng.

Lỗi phần mềm có thể chia theo mức độ nghiêm trọng. Lỗi phần mềm xảy ra trong quá trình phát triển có thể không cần sửa nếu mã nguồn không được sử dụng hoặc không được chạy. Ngoài ra lỗi phần mềm có thể trở nên nguy hiểm, chi phí cao hơn nếu thay đổi môi trường phần mềm thay đổi.

Kỹ năng cần có cho một Tester là gì?

Vai trò của việc kiểm thử là gì?

Quá trình kiểm thử phần mềm là tốt khi như thế nào???

Tại sao phải kiểm thử phần mềm?

Tuân Dolce đã viết:Sự giống và khác nhau của Test Case và Test Script?

cảm ơn bạn đã đặt câu hỏi cho nhóm m.thay mặt nhóm t trả lời câu hỏi của bạn.
sự khác nhau giữa tets case và tets script là:
Test Case
Một Test Case có thể coi nôm na 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.
• 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ó khăn hoặc không khả thi.

Thu Hiền đã viết:Quá trình kiểm thử phần mềm là tốt khi như thế nào???

cảm ơn bạn đã đặt câu hỏi cho nhóm m.thay mặt nhóm t trả lời câu hỏi của bạn như sau
Quá trình kiểm thử phần mềm là tốt khi:
 Không dư thừa.
 Có khả năng tìm ra lỗi cao.
 Biết chọn lọc (chỉ kiểm tra những phần nào có khả năng tìm ra lỗi đặc trưng).
 Không quá phức tạp cũng không quá đơn giản.

Huyền Vũ đã viết:nhóm bạn cho mình biết  kiểm tra động và kiểm tra tĩnh là gì?

cảm ơn bạn đã đặt câu hỏi cho nhóm tớ.thay mặt nhóm t trả lời:
_Kiểm thử tĩnh là một hình thức của kiểm thử phần mềm mà không thực hiện phần mềm. Điều này ngược với thử nghiệm động. Thường thì nó không kiểm thử chi tiết mà chủ yếu kiểm tra tính đúng đắn của code (mã lệnh), thuật toán hay tài liệu
_Kiểm thử động bao gồm 2 kỹ thuật : Kiểm thử hộp trắng và kiểm thử hộp đen
+Kiểm thử hộp trắng dựa vào thuật toán, cấu trúc code bên trong của chương trình với mục đích đảm bảo rằng tất cả các câu lệnh và điều kiện sẽ được thực hiện ít nhất một lần.
+Là phương pháp test dựa trên đầu vào và đầu ra của chương trình để test mà không quan tâm tới code bên trong được viết ra sao. Tester xem phần mềm như là một hộp đen

Thu Hiền đã viết:Vai trò của việc kiểm thử là gì?

cảm ơn bạn đã đặt câu hỏi
Vai trò của việc kiểm thử là:
 Khiếm khuyết tìm thấy được chỉnh sửa trước khi đưa ra sử dụng
 Giảm thiểu rủi ro trong suốt quá trình thực hiện và phân phối với chất lượng phần mềm
 Đáp ứng được các yêu cầu trong hợp đồng, trong luật hay chuẩn công nghiệp…

Tuân Dolce đã viết: Nói rõ ơn cho mình về "Kiểm thử tác vụ"?

cảm ơn bạn đã đặt câu hỏi.
_Kiểm thử tác vụ:
Ước lượng các đặc tính của hệ thống: độ tin cậy – tính sẵn sàng.

Thu Hiền đã viết:Kỹ năng cần có cho một Tester là gì?

cảm ơn bạn đã đặt câu hỏi
Kỹ năng cần có cho một Tester là:
• Một Tester cần có các kỹ năng giao tiếp, quan hệ tốt.
• Bắt đầu từ sự cộng tác hơn là đối đầu. Truyền thông những kết quả lỗi theo ý trung lập, tập trung sự kiện, không chỉ trích.
• Cố gắng hiểu người khác cảm nhận ra sao và tại sao họ phản ứng lại. Xác nhận lại những gì đã hiểu và chưa hiểu.

Thu Hiền đã viết:Kỹ năng cần có cho một Tester là gì?

cảm ơn bạn đã đặt câu hỏi
Kỹ năng cần có cho một Tester là:
• Một Tester cần có các kỹ năng giao tiếp, quan hệ tốt.
• Bắt đầu từ sự cộng tác hơn là đối đầu. Truyền thông những kết quả lỗi theo ý trung lập, tập trung sự kiện, không chỉ trích.
• Cố gắng hiểu người khác cảm nhận ra sao và tại sao họ phản ứng lại. Xác nhận lại những gì đã hiểu và chưa hiểu.