Nhóm 8- Chương 4: Kiểm Thử Phần Mềm (slile 1- 39)

 Kiểm thử phần mềm
 I. Tổng quan
 1.Khái niệm:
 Kiểm thử là khâu điển hình của rà soát đặc tả thiết kế & lập mã.
 kiểm thử phần mềm theo GlenMyers: Là quá trình vận hành chương trình để tìm ra lỗi.
 Cần vận hành như thế nào để hiệu suất tìm ra lỗi là cao nhất ? và chí phí (thời gian, công sức) ít nhất?
 I.2.Lý do
 Muốn nhìn thấy phần mềm như là một phần tử của hệ thống hoạt động (xem sản phẩm)
 Hạn chế chi phí phải trả cho các thất bại do lỗi gây ra sau này (hiệu quả)
 Có kế hoạch tốt nâng cao chất lượng cho suốt quá trình phát triển (giải pháp).
 I.3.Vai trò
 Chi phí của kiểm thử chiếm:
 40% tổng công sức phát triển
 ≥ 30% tổng thời gian phát triển
 Với các phần mềm có ảnh hưởng tới sinh mạng, chi phí có thể gấp từ 3 đến 5 lần tổng các chi phí khác cộng lại.
 Kiếm thử tốt sẽ:
 Giảm chi phí phát triển
 Tăng độ tin cậy của sản phẩm phần mềm
 I.4.Mục tiêu
 Mục tiêu trước mắt: cố gắng tạo ra các ca kiểm thử để chỉ ra lỗi của phần mềm được xây dựng (tức là “đánh đổ” phần mềm)
 Nghe ra có vẻ mang tính “phá hoại”, => dễ gây ra những vấn đề về tâm lý.
 Mục đích cuối cùng: có một chương trình tốt, chi phí ít => xây dựng

 I.5.Lợi ích
 Một ca kiểm thử thắng lợi làm lộ ra khiếm khuyết, đồng thời mang lại các lợi ích phụ:
 Thuyết minh rằng các chức năng phần mềm tương ứng với đặc tả (xác minh),
 Yêu cầu thực thi là phù hợp (thẩm định),
 Cung cấp thêm các chỉ số độ tin cậy và chỉ số chất lượng phần mềm nói chung (thẩm định).
 Tuy nhiên, kiểm thử không thể khẳng định rằng phầnmềm không có khiếm khuyết
 I.6.Tiến trình kiểm thử
 I.7.Các loại hình kiểm thử
 Kiểm thử đơn vị (unit testing)
 Kiểm thử tích hợp (integration testing)
 Kiểm thử hệ thống (system testing)
 Kiểm thử phục hồi (recovery testing)
 Kiểm thử áp lực (stress testing)
 Kiểm thử thi hành (performance testing)
 Kiểm thử an ninh (security testing)
 Kiểm thử chấp nhận (aceptance testing)
 Kiểm thử alpha (alpha testing)
 Người phát triển thực hiện
 Trong môi trường được quản lý
 Kiểm thử beta (beta testing)
 Người dùng thực hiện
 Trong môi trường thực
 I.8.Các phương pháp và chiến lược
 Hai phương pháp phổ biến:
 Kiểm thử hộp trắng (white box)
 Kiểm thử hộp đen (black box)
 Các chiến lược Kiểm thử
 Với mỗi loại kiểm thử thường sử dụng các phương pháp và chiến lược thích hợp.
 Một số chiến lược:
 Kiểm thử từ trên xuống/dưới lên (tích hợp)
 Kiểm thử vụ nổ lớn (big bang –tích hợp)
 Kiểm thử hồi quy (quá trình tích hợp)
 Kiểm thử luồn sợi (hệ thời gian thực)
 I.9.Ca kiểm thử
 Mục tiêu thiết kế ca kiểm thử nhằm:
 tìm ra nhiều sai nhất
 với nỗ lực & thời gian nhỏ nhất.
 Trong các thập kỷ 80-90 đã nghiên cứu nhiều loại phương pháp thiết kế ca kiểm thử.
 Các phương pháp tốt phải cho một cơ chế:
 bảo đảm tính đầy đủ (không sót phần nào) và
 cung cấp khả năng thật sự phát hiện được các sai trong phần mềm.
 II.Kiểm thử hộp trắng
 1.Khái niệm kiểm thử hộp trắng
 Thực hiện trực tiếp trên mã nguồn
 Khám xét các chi tiết thủ tục; các con đường logic, các trạng thái của chương trình.
 Số con đường lôgíc là rất lớn. một chươngv trình nhỏ:
 với 100 dòng PASCAL
 với một vòng lặp
 số con đường logic có thể tới:1014.
 cần 3170 năm để kiểm thử tất mọi con đường và mọi ràng buộc lôgic trên nó!
 II.2.Đối tượng kiểm thử hộp trắng
 Cách thức: Sử dụng cấu trúc điều khiển của thiết kế thủ tục để hình thành các ca kiểm thử
 kiểm thử cái gì?
 mọi lệnh được thực hiện
 mọi điều kiện được kiểm tra
 mọi chu trình được duyệt qua
 mọi cấu trúc dữ liệu được dùng
 Mọi tiến trình được lần vết => a. được thực hiện
 II.3.Yêu cầu kiểm thử hộp trắng
 Yêu cầu đặt ra:
 Mọi con đường độc lập trong một môđun cần được thực hiện ít nhất một lần.
 Mọi ràng buộc logic được thực hiện cả hai phía đúng (true) & phía sai (false).
 Tất cả các vòng lặp ở biên của nó & cả các biên vận hành phải được thực hiên.
 Mọi cấu trúc dữ liệu nội tại được dùng để bảo đảm tính hiệu lực của nó
 II.4.Lý do kiểm thử hộp trắng
 Vì sao cần tốn tiền cho kiểm thử hộp trắng?
 Các sai logic & giả thiết không đúng đắn tỷ lệ nghịch với xác suất để một con đường logic được thi hành.
 Thực tế: mọi con đường lôgic đều có thể được thi hành trên 1 cơ sở nhất định (ta cho rằng 1con đường logic nào đó là không thể được thi hành).
 Có những sai chính tả có thể là ngẫu nhiên trên đường ta không kiểm tra.
 II.5. Kỹ thuật đường cơ bản-đồ thị dòng
 Được Tom McCabe đưa ra đầu tiên
 Đồ thị dòng gần giống đồ thị luồng điều khiển của chương trình.
 Nó nhận được từ đồ thị luồng điều khiển của chương trình bằng cách:Gộp các lệnh tuần tự và thay lệnh rẽ nhánh và điểm kết thúc của các đường điều khiển bằng 1 nút vị từ
 Cấu trúc đồ thi dòng gồm:
 mỗi nút (hình tròn) biểu thị một hay một số lệnh tuần tự, hoặc thay cho điểm hội tụ các đường điều khiển.
 mỗi cạnh nối hai nút biểu diễn dòng điều khiển,
 Kết quả: đồ thi dòng
 Chia mặt phẳng thành nhiều miền.
 Có nút vị từ biểu thị sự phân nhánh hoặc hội nhập của các cung.
 III.Kiểm thử hộp đen
 Phương pháp kiểm thử hộp đen tập trung vào các yêu cầu chức năng của phần mềm..
 Đặc trưng:
 Nhằm thuyết minh: các chức năng phần mềm đủ & vận hành đúng
 Thực hiện các phép thử qua giao diện
 Cơ sở: đặc tả, các điều kiện vào/ra và cấu trúc dữ liệu
 Ít chú ý tới cấu trúc logic nội tại của nó
 III.2.Mô hình kiểm thử hộp đen
 III.3.Mục tiêu
 Kiểm thử hộp đen nhằm tìm ra các loại sai:
 Chức năng thiếu hoặc không đúng đắn.
 Sai về giao diện.
 Sai trong cấu trúc hoặc trong truy cập dữ liệu ngoài.
 Sai thực thi chức năng.
 Sai khởi đầu hoặc kết thúc mô đun.
 III.4.Thiết lập câu hỏi
 Kiểm thử hộp đen tập trung trả lời các câu hỏi:
 Hiệu lực chức năng (chức năng, hiệu suất) được kiểm thử đến đâu?
 Lớp đầu vào nào cho các ca kiểm thử tốt?
 Sự nhạy cảm của môđun với giá trị vào nào?
 Các biên của lớp dữ liệu được cô lập chưa?
 Dung thứ lỗi đối với các nhịp điệu/khối lượng dữ liệu như thế nào?
 Tổ hợp dữ liệu đặc biệt ảnh hưởng gì đến hoạt động hệ thống.
 III.5.Tiêu chuẩn
 Áp dụng kỹ thuật kiểm thử hộp đen, cần tìm ra các ca kiểm thử thoả mãn các tiêu chuẩn:
 Thu gọn (ít, đơn giản).
 Cho biết về sự tồn tại hoặc vắng mặt của một lớp sai (không phải về một sai cụ thể gắn với một kiểm thử riêng biệt)
 III.6.Kỹ thuật phân hoạch tương đương
 Là một kỹ thuật của kiểm thử hộp đen
 Nguyên tắc: chia miền vào của chương trình thành các lớp dữ liệu để lập ra các ca kiểm thử theo mỗi lớp đó.
 Cơ sở: dữ liệu trong 1 lớp tương đương tác động như nhau lên chương trình, tạo ra cùng một tráng thái: đúng hay sai của chương trình
 Mục tiêu: tìm ra 1 ca kiểm thử để bộc lộ 1 lớp sai, => rút gọn số ca kiểm thử cần phát triển.
 Ca kiểm thử được thiết kế cho từng lớp tương đương
 III.7. Kỹ thuật đồ thị nhân quả
 Đồ thị nhân quả là một kỹ thuật thiết kế ca kiểm thử. Nó cung cấp một biểu diễn chính xác các điều kiện logic và các hành động tương ứng.
 Kỹ thuật đồ thị nhân quả gồm 4 bước:
 Lập danh sách các nguyên nhân (ĐK vào) và kết quả (hành động thực hiện) cho từng môđun và gán định danh cho chúng.
 Phát triển một đồ thị nhân quả.
 Chuyển đồ thị đó thành bảng quyết định.
 Sử dụng các quy luật của bảng quyết định để xây dựng các ca kiểm thử.
 IV.Kiểm thử so sánh
 kiểm thử so sánh (comparision testing) còn được gọi là kiểm thử dựa vào nhau (back-to-back testing):
 Khi triển khai nhiều bản phần mềm từ cùng 1 đặc tả. Kiểm thử hộp đen cho các sản phẩm này được thực hiện với cùng ca kiểm thử & cùng các dữ liệu vào.
 So sánh các kết quả thu được: nếu có khác biệt nghĩa là có sai trong một sản phẩm nào đó!
 IV.Kiểm thử hệ thời gian thực
 Hệ thời gian thực là hệ thống đáp ứng đúng, chính xác các sự kiện của môi trường
 Mô hình chung:
 V.Chiến lược kiểm thử
 Một chiến lược kiểm thử phần mềm là sự tích hợp các kỹ thuật thiết kế ca kiểm thử tạo thành một kế hoạch gồm dãy các bước để hướng dẫn quá trình kiểm thử phần mềm thành công.
 Nó đưa ra một bản đồ các đường đi để:
 Nhà phát triển tổ chức bảo đảm chất lượng
 Khách hàng: biết các phần việc kiểm thử với công sức, thời gian và nguồn lực cần thiết.
 V.1.Yêu cầu chiến lược kiểm thử
 Phải tích hợp được việc lập kế hoạch thử nghiệm, việc thiết kế ca kiểm thử, việc tiến hành kiểm thử và việc thu thập và đánh giá các thông tin kết quả.
 Phải đủ mềm dẻo để cổ vũ óc sáng tạo và việc theo ý khách hàng (mà tất cả các hệ thống lớn dựa trên máy tính đều cần kiểm thử tương xứng).
 Kiểm thử là một tập các hoạt động có thể lập kế hoạch trước và được tiến hành một cách có hệ thống. Chính vì thế mà cần xác định một khuôn mẫu (template) kiểm thử phần mềm trong tiến trình kỹ nghệ phần mềm.
 V.2.Đặc trưng
 Các đặc trưng có tính khuôn mẫu:
 Bắt đầu ở mức môđun và tiếp tục cho đến khi tích hợp ở mức hệ thống dựa trên máy tính trọn vẹn.
 Các kỹ thuật kiểm thử khác nhau là thích hợp cho những thời điểm khác nhau.
 Được cả người phát triển và nhóm kiểm thử độc lập cùng tiến hành.
 kiểm thử đi trước gỡ lỗi, song việc gỡ lỗi phải thích ứng với từng chiến lược kiểm thử .
 VII.Tổ chức kiểm thử
 Kiểm thử phần mềm là một phần của hoạt động lớn hơn là “xác minh và thẩm định”:
 Xác minh là một tập hợp các hoạt động để bảo đảm rằng phần mềm thực hiện đúng chức năng đã được đặc tả
 Thẩm định là một tập hợp các hoạt động để bảo đảm rằng phần mềm đã được đáp ứng đúng yêu cầu của khách hàng.
 VII.1 Tiến trình kiểm thử
 Tiến trình kiểm thử theo sát tiến trình phát triển (chẳng hạn như tiến trình xoắn ốc).
 Tiến trình kiểm thử thông thường
 VII.2 Đối tượng và phương pháp
 VII.3 Kiểm thử đơn vị
 kiểm thử đơn vị có các nội dung sau :
 kiểm thử giao diện
 khám nghiệm cấu trúc dữ liệu cục bộ.
 kiểm thử với các điều kiện biên.
 Các đường Độc lập.
 Các đường xử lý sai.
 VII.4 Kiểm thử tích hợp
 Kiểm thử tích hợp (integration testing) nhằm nhận được một phần hay toàn bộ hệ thống như mong đợi. Khi tích hợp các thành phần có thể gặp các sai:
 Dữ liệu bị mất khi đi qua một giao diện.
 hiệu ứng bất lợi 1 môđun vô tình gây ra đối các môđun khác.
 Sự kết hợp các chức năng phụ có thể không sinh ra chức năng chính mong muốn.
 Sự phóng đại các sai sót riêng rẽ có thể bị đến mức không chấp nhận được.
 Vấn đề của cấu trúc dữ liệu toàn cục có thể để lộ ra .
 VII.4 Kiểm thử tích hợp
 Kiểm thử tích hợp (integration testing) nhằm nhận được một phần hay toàn bộ hệ thống như mong đợi. Khi tích hợp các thành phần có thể gặp các sai:
 Dữ liệu bị mất khi đi qua một giao diện.
 hiệu ứng bất lợi 1 môđun vô tình gây ra đối các môđun khác.
 Sự kết hợp các chức năng phụ có thể không sinh ra chức năng chính mong muốn.
 Sự phóng đại các sai sót riêng rẽ có thể bị đến mức không chấp nhận được.
 Vấn đề của cấu trúc dữ liệu toàn cục có thể để lộ ra .
 VII.4 Kiểm thử tích hợp (t)
 kiểm thử tích hợp là một lỹ thuật có tính hệ thống để xây dựng cấu trúc chương trình (ngay khi đang tiến hành kiểm thử để phát hiện sai liên kết với giao diện).
 Mục đích là tận dụng các môđun đã kiểm thử đơn vị và xây dựng cấu trúc chương trình sao cho nó đảm bảo tuân theo thiết kế.
 Có hai hướng tích hợp chương trình
 Tích hợp dần
 Tích hợp đồng thời 1 lúc: “big bang”
 VII.5 Kiểm thử thẩm định
 Khi kết thúc kiểm thử tích hợp, phần mềm đã hoàn toàn được lắp ráp trong một gói, các sai giao diện đã chỉnh sửa, và một loạt các kiểm thử phần mềm cuối cùng bắt đầu - kiểm thử thẩm định (validation testing)
 Thẩm định là thắng lợi nếu các chức năng phần mềm ở một chừng mức nào đó là có thể thoả mãn mongđợi hợp lý của người đặt hàng
 Mục tiêu thẩm định: xem phần mềm có đáp ứng được yêu cầu khách hàng không?
 VII.5 Kiểm thử thẩm định (t)
 Cái “mong đợi hợp lý” của khách hàng đã được xác định trong Đặc tả yêu cầu phần mềm bao gồm cả mô tả được gọi là tiêu chuẩn kiểm thử phần mềm
 Thẩm định phần mềm được thực hiện thông qua một loạt các kiểm thử hộp đen để thuyết minh sự phù hợp của nó với các yêu cầu.
 Gồm chiến lược kiểm thử Alpha và Beta
 kiểm thử alpha được bên phát triển tiến hành . Phần mềm sẽ được người dùng dùng trong bối cảnh tự nhiên để người phát triển “nhòm qua vai” người sử dụng và báo cáo các sai và các vấn đề sử dụng (vì thế còn gọi là kiểm thử sau lưng).
 kiểm thử bêta được nhiều người đặt hàng tiến hành, không có mặt Người phát triển.
 VII.6 Kiểm thử hệ thống
 Hệ thống dựa vào máy tính do nhiều bên xây dựng, người phát triển phần mềm chỉ là một
 Việc kiểm thử hệ thống dễ có nguy cơ “đổ lỗi cho nhau”.
 Người phát triển phần mềm cần đoán trước các vấn đề giao diện có thể nảy ra, và
 Phát hiện các thiết kế đường xử lý sai thông qua kiểm thử tất cả các thông tin đến từ các phần tử khác của hệ thống.
 VII.6 Kiểm thử hệ thống (t)
 Tiến hành các kiểm thử mô phỏng các dữ liệu xấu hoặc các sai tiềm tàng khác tại giao diện phần mềm.
 Báo cáo các kết quả kiểm thử để làm chứng cứ phòng ngừa đổ lỗi cho nhau.
 Những người tham gia vào trong việc hoạch định vàthiết kế các kiểm thử hệ thống sao cho kế hoạch vàkiểm thử bảo đảm phần mềm được kiểm thử đầy đủ
 Các chiến lược: Kiểm thử phục hồi, kiểm thử an ninh, kiểm thử áp lực, kiểm thử thi hành
 VII.7 Kiểm thử chấp nhận
 Là sự minh chứng cuối cùng sự đúng đắn của một đặc điểm phần mềm.
 Được viết bởi khách hàng, hoặc
 Được viết bởi sự phối hợp giữa khách hàng và nhóm phát triển phần mềm vì mục đích chung.
 Hai hoạt động chính là kiểm thử alpha và kiểm thử beta

Tổng Kết bài học:
Hiểu rõ về phương pháp Kiểm thử hộp đen và những vấn đề liên quan.
Kiểm thử so sánh, kiểm thử thời gian thực.
Chiến lược kiểm thử.


Cảm ơn các bạn đã đọc bài của nhóm chúng tôi

Cho t hỏi khái niệm kiểm thử là gì???

Các loại hình kiểm thử là những loại nào???

dathn95 đã viết:Cho t hỏi khái niệm kiểm thử là gì???

Cảm ơn bạn đạt 09 đặt câu hỏi

Khái niệm:
 Kiểm thử là khâu điển hình của rà soát đặc tả thiết kế & lập mã.
 kiểm thử phần mềm theo GlenMyers: Là quá trình vận hành chương trình để tìm ra lỗi.
 Cần vận hành như thế nào để hiệu suất tìm ra lỗi là cao nhất ? và chí phí (thời gian, công sức) ít nhất?

dathn95 đã viết:Các loại hình kiểm thử là những loại nào???

Mình xin trả lời:
Kiểm thử đơn vị (unit testing)
Kiểm thử tích hợp (integration testing)
Kiểm thử hệ thống (system testing)
Kiểm thử phục hồi (recovery testing)
Kiểm thử áp lực (stress testing)
Kiểm thử thi hành (performance testing)
Kiểm thử an ninh (security testing)
Kiểm thử chấp nhận (aceptance testing)
Kiểm thử alpha (alpha testing)
Người phát triển thực hiện
Trong môi trường được quản lý
Kiểm thử beta (beta testing)
Người dùng thực hiện
Trong môi trường thực

kiểm thử phần mềm là gì? vai trò của nó

kiểm thử hộp trắng là gì và kiểm thử hộp đen là gì?

tổ chức kiểm thử thường được chia ra làm mấy phần?

đầu tiên là các bạn chỉnh sửa lại bài cho dễ nhìn.
thứ 2 là mình muốn hỏi các bạn: kiểm thử hộp trắng và kiểm thử hộp đen có giống nhau hay không?
nếu có điểm giống nhau thì bạn có thể nói rã cho mình và các bạn cùng biết điểm khác nhau của 2 cái này

chiến lược về kiểm thử như thế nào?

nói rõ hơn về Kiểm thử so sánh?

nói rõ hơn về kiểm thử thời gian thực.

bạn thông nguyễn hỏi: kiểm thử hộp trắng là gì và kiểm thử hộp đen là gì?


mình xin trả lời:
kiểm thử hộp trắng (kiểm thử hướng logic)là: cho phép kiểm tra cấu truc bên trong của phần mềm 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ẽ dk thực thi ít nhất 1 lần.
kiểm thử hộp đen là: 1 phương pháp mà người kiểm thử xem phần mềm như 1 hộp đen, không quan tâm đến cách thức làm việc,  cấu trúc, hành vi bên trong  của hệ thống.
- Người kiểm thử chi quan tâm đến việc tìm ra hiện tượng mà phần mềm không xử lý theo đúng đặc tả của nó và vì  thế dữ liệu kiểm thử sẽ xuất phát từ đặc tả

nói kĩ hơn về chiến lược kiểm thử Alpha và Beta.

Đối tượng và phương pháp kiểm thử ở đây là cái gì?

bạn thông nguyễn hỏi:
kiểm thử phần mềm là gì và vai trò của nó?

mình xin trả lời:
Kiểm thử phần mềm là:
Kiểm thử là khâu điển hình của rà soát đặc tả thiết kế & lập mã.
kiểm thử phần mềm theo GlenMyers: Là quá trình vận hành chương trình để tìm ra lỗi.
Vai trò của kiểm thử:
Kiếm thử tốt sẽ:
Giảm chi phí phát triển
Tăng độ tin cậy của sản phẩm phần mềm

bạn luân lee hỏi:
nói kĩ hơn về chiến lược kiểm thử Alpha và Beta

mình xin trả lời:
- Kiểm thử alpha được bên phát triển tiến hành . Phần mềm sẽ được người dùng dùng trong bối cảnh tự nhiên để người phát triển “nhòm qua vai” người sử dụng và báo cáo các sai và các vấn đề sử dụng (vì thế còn gọi là kiểm thử sau lưng).
Kiểm thử bêta được nhiều người đặt hàng tiến hành, không có mặt Người phát triển.

bạn dadthn95 hỏi: các loại hình kiểm thử là những loại nào:

mình xin trả lời: có 4 loại hình kiểm thử
-Kiểm thử đơn vị (unit testing)
-Kiểm thử tích hợp (integration testing)
-Kiểm thử hệ thống (system testing)
+Kiểm thử phục hồi (recovery testing)
+Kiểm thử áp lực (stress testing)
+Kiểm thử thi hành (performance testing)
+Kiểm thử an ninh (security testing)
-Kiểm thử chấp nhận (aceptance testing)
+Kiểm thử alpha (alpha testing)
+Kiểm thử beta (beta testing)

bạn luân lee hỏi: chiến lược về kiểm thử như thế nào?

mình xin trả lời:
Một chiến lược kiểm thử phần mềm là sự tích hợp các kỹ thuật thiết kế ca kiểm thử tạo thành một kế hoạch gồm dãy các bước để hướng dẫn quá trình kiểm thử phần mềm thành công

Nêu những yêu cầu đặt ra khi kiểm thử hộp trắng ?

cho t hỏi có những chiến lược kiểm thử nào?

so sánh kiểm thử hộp đen và kiểm thử hộp trắng.

trong kiểm thử tích hợp:khi tích hợp các thành phần có thể gặp các lỗi gì?

kiểm thử hộp đen , kiểm thử hộp trắng là j

đặc điểm và đối tương của kiểm thử là j