- Sai trong logic thiết kế (EDL)
- Thử nghiệm sai hoặc không đầy đủ (IET). . .
28. Nêu công thức khiếm khuyết của một sản phẩm ở một pha phát triển? và công thức tính khiếm khuyết của sản phẩm cuối cùng? Giải thích ý nghĩa của nó? thức tính khiếm khuyết của sản phẩm cuối cùng? Giải thích ý nghĩa của nó?
- Người phát triển cần phải tính chỉ số khiếm khuyết cho mỗi bước chính phát triển phần mềm phần mềm
- Các thông tin để tính mức độ khiếm khuyết+ Di= tổng số các khiếm khuyết + Di= tổng số các khiếm khuyết
+ Si= số các khiếm khuyết nghiêm trọng + Mi= Số các khiếm khuyết vừa phải + Ti =số các khiếm khuyết nhỏ
- Với mỗi bước chính trong phát triển phần mềm cần tính chỉ số pha PIi:PIi=w1(Si/Di) + w2(Mi/Di) + w3(Ti/Di) PIi=w1(Si/Di) + w2(Mi/Di) + w3(Ti/Di)
Trong đó w1, w2, w3 là trọng số tương ứng với các khiếm khuyết nghiêm trọng, vừa phải và nhỏ.
- Chỉ số khiếm khuyết DI được tính như sau:DI= (PI1 + 2PI2 +. . .+iPIi)/PS DI= (PI1 + 2PI2 +. . .+iPIi)/PS
Trong đó PS là kích cỡ của sản phẩm (là LOC = số dòng mã, hoặc số tuyên bố thiết kế, hoặc số trang tài liệu) tuỳ theo từng bước.
Theo công thức: các khiếm khuyết càng về sau càng về sau càng nhân với hệ số lớn
29. Tiếp cận hình thức cho SQA nghĩa là gì? Quá trình phòng sạch là gì? Phương châm của kỹ thuật này là gì? châm của kỹ thuật này là gì?
Người ta nhận thấy cần phải dùng một cách tiếp cận hình thức hơn trong việc bảo đảm chất lượng phần mềm, cách tiếp cận này sẽ bổ sung cho các hoạt động mô tả ở trên
Tiếp cận hình thức hoá: đặc tả hình thức cho phép chứng minh tính đúng đắn, kiểm tra lỗi, chuyển tự động thành chương trình . . . làm tăng chất lượng.
- Kiểm chứng chương trình một cách hình thức (chứng minh tính đúng đắn) và bảo đảm chất lượng phần mềm thống kê hợp lại với nhau cho ta ta một kỹ thuật cải đảm chất lượng phần mềm thống kê hợp lại với nhau cho ta ta một kỹ thuật cải thiện chất lượng sản phẩm, được gọi là quá trình phòng sạch.
- Phương châm của kỹ thuật này là: Phòng khiếm khuyết hơn là trừ khiếm khuyết
2.2. Các độ đo về sự tin cậy và an toàn
30. Độ tin cậy của phần mềm là cái gì? Đo độ tin cậy dựa trên những dữ liệu nào?
- Độ tin cậy của phần mềm là một yếu tố quan trọng trong chất lượng phần mềm.
- Độ tin cậy phần mềm được định nghĩa theo thuật ngữ thống kê: “xác suất thao tác không thất bại của chương trình máy tính trong một môi trường đặt biệt với một thời gian đã định rõ”.
- Độ tin cậy của phần mềm được đo trực tiếp và được đánh giá qua các dữ liệu phát triển và các dữ liệu lịch sử.
31. Thế nào là thất bại của phần mềm? Có mấy thang bậc? là những thang bậc nào?
Khi nói đến độ tin cậy phần mềm thì nảy sinh câu hỏi “thất bại” nghĩa là gì? Thất bại là việc không thi hành đúng các yêu cầu phần mềm.
• Có các thang bậc:
- Mức độ: Thất bại có thể đơn thuần chỉ là sự phiền phức, có khi thất bại là cả một thảm họa.
- Thời gian: Để laọi trừ thất bại có khi chỉ mất vài giây, có khi mất cả tuần, cả tháng. - Hậu quả: Khi loại bớt thất bại thì có thể lại sinh ra các lỗi khác và kéo theo thất bại
khác.
32. Nêu chỉ tiêu để tính độ tin cậy? Nêu công thức tính độ sẵn sàng? Giải thích ý nghĩa của nó? thích ý nghĩa của nó?
- Với các hệ thống dựa trên máy tính thì một số đo đơn giản về độ tin cậy chính là thời gian trung bình giữa hai lần thất bại kế tiếp (MTBF- Mean Time Between Failure):
MTBF = MTTF + MTTR
- MTTF (Mean Time To Failure) là thời gian hoạt động liên tục trung bình - MTTR (Mean Time To Repair) là thời gian sửa xong lỗi trung bình • Ý nghĩa: (adsbygoogle = window.adsbygoogle || []).push({});
MTBF là cách đo hữu ích hơn nhiều so với tỷ số “số khiếm khuyết”/KLOC (LOC-Line Of Code) vì người dùng cuối cùng quan tâm tới những thất bại chứ không quan tâm đếm lỗi (nhà nghiên cứu).
Do các lỗi trong chương trình không có cùng mức độ (nặng, nhẹ khác nhau) nên số các lỗi chỉ cho ta một chỉ số nhỏ về độ tin cậy của hệ thống.
VD: Khi đưa 1 chương trình vào vận hành trong 14 tháng , trong các lỗi chưa được phát hiện có lỗi chỉ được phát hiện sau dăm chục năm, các lỗi còn lại với MTBF khoảng 18-24 tháng
- Độ sẵn sàng phần mềm là xác suất để chương trình vận hành đúng với yêu cầu ở các thời điểm đã định và được tính như sau:
MTTF/(MTTF + MTTR) x100% Ý nghĩa
Thể hiện tỷ lệ thời gian làm việc trung bình trong tổng thời gian vận hành
Là độ đo gián tiếp về khả năng bảo trì được (số này càng gần 100 là đã bảo trì tốt)
33. Có những mô hình độ tin cậy nào? Nó dựa trên tham biến nào và trên giả thiết nào? Mô hình độ tin cậy gieo hạt dựa trên ý tưởng nào? Mục tiêu để làm gì Mô hình độ tin cậy gieo hạt dựa trên ý tưởng nào? Mục tiêu để làm gì
• Có hai mô hình độ tin cậy phần mềm:
- Mô hình tiên đoán độ tin cậy như là một hàm của thời gian lịch
- Mô hình tiên đoán độ tin cậy như là một hàm của thời gian xử lý đã trôi qua (thời gian vận hành của CPU). Loại này được coi là tốt hơn.
• Các mô hình độ tin cậy phần mềm dựa trên các giả thiết:
- Thời gian gỡ lỗi giữa các xuất hiện sai có phân phối mũ với nhịp độ xuất hiện sai, nhịp độ này tỷ lệ thuận với số các lỗi còn lại
- Mỗi lỗi bị phát hiện sẽ được loại trừ ngay lập tức và số lỗi còn lại giảm đi 1 - Nhịp độ thất bại giữa các lỗi là không thay đổi
• Các giả thiết này còn phải bàn: vì một lỗi được loại trừ thì có thể nhiều lỗi khác lại được sinh ra.
• Một lớp các mô hình độ tin cậy phần mềm dựa vào các đặc trưng tồn tại của một chương trình và tính toán số dự đoán các sai tồn tại trong phần mềm
• Các mô hình này dựa trên các quan hệ định lưwngj như một hàm của độ đo tính phức tạp, chúng liên kết thiết kế đặc chủng hoặc các thuộc tính hướng mã của chương trình với “một ước định số khải phát các lỗi được tin rằng có trong chương trình đã cho”
Mô hình độ tin cậy gieo hạt dựa trên ý tưởng nào? Mục tiêu để làm gì?
• Ý tưởng: Một chương trình được gieo một cách ngẫu nhiên một số các lỗi(k) hiệu chuẩn (calibration) vào một chương trình; sau đó đem kiểm thử (bằng một số ca thử nghiệm); tính xác suất tìm được j lỗi trong tập J lỗixem như tương ứng với xác suất tìm được k
lỗi đã gieo trong K lỗi đã nhúng vào chương trình. j/J=k/K • Mục đích:
- dùng như một chỉ báo của độ tin cậy phần mềm;
- hoặc một cách thực tiễn hơn như một độ đo “năng lực phát hiện sai” của một tập hợp các ca thử nghiệm.
34 Độ an toàn phần mềm là cái gì?Có những phương pháp nào để phân tích độ an toàn? toàn?
• An toàn phần mềm là một hoạt động bảo đảm chất lượng phần mềm tập trung vào việc minh định và đánh giá các mối nguy hiểm tiềm ẩn có thể gây ảnh hưởng phản tác dụng thậm chí là gây ra thất bại của toàn hệ thống.
• Độ an toàn phần mềm xem xét lại cách thức lỗi nảy sinh trong một điều kiện nào đó có thể dẫn tới rủi ro. Nghĩa là lỗi không được xem xét trong chân không mà được đánh giá trong hoàn cảnh của toàn bộ hệ thống dựa trên máy tính.
Có các phương pháp như: • Phân tích cây lỗi:
dựng lên một mô hình đồ thị các tổ hợp tuần tự và song song các sự kiện dẫn đến một sự kiện hay một trạng thái hệ thống mạo hiểm.
Dùng một cây lỗi phát triển tốt có thể quan sát được hậu quả của một dãy các thất bại liên kết với nhau, xuất hiện trong các thành phần khác nhau của hệ thống.
• Logic thời gian thực: xây dựng mô hình hệ thống bằng các đặc tả các sự kiện và các hành động tương ứng. Mô hình sự kiện – hành động có thể được phân tích bằng cách dùng các toán tử logic để thử nghiệm các quyết đoán an toàn đối với các thành phần của hệ thống và định thời cho chúng
• Mô hình lưới petry: dùng để xác định xem lỗi nào là nghiêm trọng nhất (adsbygoogle = window.adsbygoogle || []).push({});
35. Khảo sát nhu cầu SQA gồm những nội dung gì? nhằm trả lời các câu hỏi gì?nếu có nhu cầu thì mình làm gì? nhu cầu thì mình làm gì?
- Gồm ba nội dung nhằm trả lời ba câu hỏi
+ Kiểm kê các chính sách SQA: chính sách, thủ tục, chuẩn nào đã có trong các pha phát triển?
+ Đánh giá vai trò của kỹ nghệ phần mềm, bảo đảm chất lượng trong tổ chức hiện tại có quyền lực đến đâu?
+ Đánh giá mối quan hệ SQA: Giao diện chức năng giữa SQA với các đơn vị khác như thế nào? với các người thực hiện rà soát kỹ thuật chính thức, quản lý cấu hình và thử nghiệm
- Nếu có nhu cầu thì cần phải tiến hành đánh giá cẩn thận bằng quy tắc bỏ phiếu.
36. Có những vấn đề gì đạt ra khi triển khai SQA? Lợi íchcủa SQA là gì? Nguyên tắc chi phí hiệu quả của SQA là gì? chi phí hiệu quả của SQA là gì?
- SQA có những vấn đề sau đây
+ Khó thiết lập trong một tổ chức nhỏ: khó có nguồn lực để thực hiện các hoạt động cần thiết mà hiện chưa có.
+ Nó biểu thị một thay đổi có tính văn hoá: nên chẳng bao giờ dễ dàng thực hiện + Nó đòi hỏi tiêu tốn không ít tiền
- SQA có những lợi ích sau đây:
+ Phần mềm có ít các khiếm khuyết tiềm ẩn hơn và do đó mất ít công sức và thời gian kiểm thử và bảo trì.
+ Độ tin cậy cao hơn và do đó khách hàng thoả mãn hơn + Giảm phí tổn bảo trì
+ Giảm phí tổn tổng thể toàn bộ vòng đời của phần mềm
- Nguyên tắc chi phí: Ở mức cơ bản SQA được xem là hiệu quả về chi phí nếu C3>C1 + C2
Ở đây:
+ C3 là chi phí từ các sai do không có SQA + C1 là chi phí cho SQA của chương trình
+ C2 là chi phí do các sai không tìm thấy khi chương trình đã có SQA
3. Kiểm thử phần mềm
3.1. Khái niệm về kiểm thử
37. Tại sao phải kiểm thử phần mềm? Mục tiêu kiểm thử là gì? Từ đó có quan niệm già sai về kiểm thử phần mềm? già sai về kiểm thử phần mềm?
Kiểm thử phần mềm là yếu tố quyết định của SQA và khâu điển hình của rá soát đặc tả thiết kế và lập mã
•Lý do cần kiểm thử phần mềm:
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
Hạn chế chi phí phải trả cho các thất bại do lỗi gây ra sau này
có kế hoạch tốt cho suốt quá trình phát triển
o Tầm quan trọng. 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 phần mềm ảnh hưởng tới sinh mạng chi phí có thể gấp từ 3 dến 4 lần tổng chi phí khác cộng lại
•Mục tiêu kiểm thử (Glen Myers): Kiểm thử là một quá trình vận hành chương trình để tìm ra lỗi. Vì vậy:
Một ca kiểm thử tốt là ca kiểm thử có xác suất cao trong việc tìm ra một lỗi chưa được phát hiện (adsbygoogle = window.adsbygoogle || []).push({});
Một ca kiểm thử thắng lợi là một ca kiểm thử làm lộ ra được ít nhất một lỗi còn chưa được phát hiện
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ụ:
chứng tỏ rằng các chức năng phầm mềm làm việc tương ứng với đặc tả,
chứng tỏ các yêu cầu thực thi là phù hợp
có thêm các chỉ số độ tin cậy phần mềm và các chỉ số về chất lượng phần mềm nói chung
“Kiểm thử không thể chứng minh được việc không có khiếm khuyết, nó chỉ có thể chứng minh rằng khiếm khuyết phần mềm hiện hữu”
• Người ta thường có những quan niệm sai gì về kiểm thử phần mềm?
- Người phát triển không tham gia kiểm thử
- Phần mềm được công bố một cách rộng rãi để người lạ kiểm thử nó một cách tàn nhẫn
- Người kiểm thử chỉ quan tâm khi kiểm bắt đầu
- Kiểm thử có thể chứng minh được phần mềm không có khiếm khuyết - Phép kiểm thử thành công là kiểm thử không tìm ra lỗi nào
- Chỉ cần kiểm thử một lần
38. Thế nào là một ca kiểm thử tốt? ca kiểm thử thành công? Lợi ích phụ kiểm thử là gì
Một ca kiểm thử tốt là ca kiểm thử có xác suất cao trong việc tìm ra một lỗi chưa được phát hiện
Một ca kiểm thử thắng lợi là một ca kiểm thử làm lộ ra được ít nhất một lỗi còn chưa được phát hiện
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ụ:
chứng tỏ rằng các chức năng phầm mềm làm việc tương ứng với đặc tả,
chứng tỏ các yêu cầu thực thi là phù hợp
có thêm các chỉ số độ tin cậy phần mềm và các chỉ số về chất lượng phần mềm nói chung
39. Biểu đồ dòng thông tin kiểm thử mô tả cái gì? vẽ biểu đồ của nó?
Biểu đồ dòng thông tin kiểm thử tuân theo hình mẫu được mô tả như sau: Hai lớp được cung cấp cho tiến trình kiểm thử:
(1) Cấu hình phần mềm: Bản Đặc tả yêu cầu phần mềm, bản Đặc tả thiết kế, chương trình gốc
(2) Cấu hình kiểm thử: Kế hoạch và thủ tục kiểm thử, các công cụ kiểm thử dự định dùng, các ca kiểm thử cùng kết quả dự kiến.
Kiểm thử được tiến hành và tất cả các kết quả được đánh giá bằng cách so sánh với kết quả dự kiến. Khi phát hiện lỗi, việc gỡ lỗi bắt đầu được tiến hành.
Tiến trình gỡ lỗi thường không dự kiến được thời gian nên việc lập lịch kiểm thử trở nên khó khăn.Ví dụ: 1 lỗi chỉ ra sự sai biệt độ 0.01% giữa kết quả trông đợi và thực tại có thể mất 1 giờ, 1 ngày hay 1 tháng để chuẩn đoán và sửa chữa.
Khi các kết quả kiểm thử được thu thập và đánh giá thì chất lượng và độ tin cậy phần mềm dần được khẳng định. Nếu hay gặp phải lỗi nghiêm trọng yêu cầu sửa đổi thết kế thì chất lượng và độ tin cậy là đáng ngờ và cần kiểm thử thêm.
Mặt khác, nếu các chức năng phần mềm dường như làm việc đúng và lỗi gặp phải là dễ sửa thì có thể rút ra một trong hai kết luận:
(1) Chất lượng và độ tin cậy phần mềm chấp nhận được
(2) Kiểm thử không tương xứng để làm lộ ra những lỗi nghiêm trọng.
Nếu việc kiểm thử không làm lộ ra lỗi nào thì có thể hoài nghi rằng cấu hình kiểm thử chưa được cân nhắc đúng mức, các lỗi vẫn còn ẩn núp trong phần mềm và sẽ bị phát hiện bởi người dùng. (adsbygoogle = window.adsbygoogle || []).push({});
40. Kể các đối tượng và phương pháp kiểm thử phần mềm? Mỗi phương pháp đó thường được sử dụng vào giai đọan nào của quá trình phát triển? thường được sử dụng vào giai đọan nào của quá trình phát triển?
Đối tượng và phương pháp kiểm thử
Loại Đơn vị Tích hợp Thẩm định Hệ thống
Đối tượng Mã Thiết kế Yêu cầu Toàn hệ thống
Phương pháp Hộp trắng Hộp đen và trắng Hộp đen Mô hình
Mỗi phương pháp đó thường được sử dụng vào giai đoạn nào của quá trình phát triển: