NGÂN HÀNG CÂU HỎI CÔNG NGHỆ PHẦN MỀM + BTL
NHÓM CÂU HỎI 3 ĐIỂM
ĐÁP ÁN NHÓM CÂU HỎI 3 ĐIỂM – PHẦN II
Câu 1
Câu hỏi: Tại sao phải kiểm thử phần mềm? Mục tiêu kiểm thử là gì? Những quan niệm sai về kiểm thử phần mềm?
3đ
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:
smuốn nhìn thấy phần mềm như là một phần tử của hệ thống hoạt động
sHạn chế chi phí phải trả cho các thất bại do lỗi gây ra sau này
scó 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:
s 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
s 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ụ:
schứ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ả,
schứng tỏ các yêu cầu thực thi là phù hợp
scó 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 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
- 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
3đ
Câu 2
Câu hỏi: 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ì
sMộ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
sMộ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ụ:
schứ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ả,
schứng tỏ các yêu cầu thực thi là phù hợp
scó 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
Câu 3
Câu hỏi: Biểu đồ dòng thông tin kiểm thử mô tả cái gì? vẽ biểu đồ của nó?
3đ
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.
3đ
Câu 4
Câu hỏi: Rà soát phần mềm được hiểu là gì (khái niệm, mục tiêu, cách thức áp dụng)? Nêu các lợi ích của việc ra soát?
3đ
· Khái niệm: Rà soát là việc xem xét, đánh giá sản phẩm được tiến hành mỗi giai đoạn để phát hiện ra những khiếm khuyết cần sửa chữa trước khi sang giai đoạn sau.
· Mục tiêu:
• Chỉ ra các chỗ khiếm khuyết cần phải cải thiện
• Khẳng định những sản phẩm đạt yêu cầu
• Kiểm soát việc đạt chất lượng kỹ thuật tối thiểu của sản phẩm
· Cách thức áp dụng: Rà soát được áp dụng tại các thời điểm khác nhau trong quá trình phát triển phầm mềm.
· Có nhiều kiểu rà soát khác nhau:
• Các cuộc họp xét duyệt không chính thức
• Cuộc trình bày chính thức trước cử tọa gồm khách hàng, nhà quản lý, nhân viên kỹ thuật. (chỉ tập trung vào các rà soát kỹ thuật chính thức FTR-Format Technical Review)
· Các lợi ích của việc ra soát
s Lợi ích hiển nhiên của FTR là sớm phát hiện các “khiếm khuyết” phần mềm để có thể chỉnh sửa từng khiếm khuyết một trước khi bước sang bước tiếp theo của quá trình phần mềm.
s Các nghiên cứu của công nghiệp phần mềm đã chỉ ra rằng: các hoạt động thiết kế tạo ra đến 50%-60% tổng số các khiểm khuyết tạo ra trong phát triển phần mềm.
s Chi phí chỉnh sửa một khiếm khuyết tăng lên nhanh chóng sau mỗi giai đoạn. VD: Lỗi không được phát hiện trong thiết kế tốn phí 1.0 để sửa chữa, trước kiểm thử nghiệm: 6.5; trong thử nghiệm: 15 và sau khi phân phát sẽ là từ 60.0 đến 100.0
3đ
Câu 5
Câu hỏi: Các hình thức của hoạt động rà soát? trình bày khái niệm, mục tiêu của rà soát kỹ thuật chính thức?
3đ
· Có nhiều kiểu rà soát khác nhau:
• Các cuộc họp xét duyệt không chính thức
• Cuộc trình bày chính thức trước khách hàng, nhà quản lý, thành viên kỹ thuật
· Rà soát do các kỹ sư phần mềm thực hiện, là một phương tiện hiệu quả để cải thiện chất lượng phần mềm.
Rà soát kỹ thuật chính thức(FTR):
- Khái niệm: là hoạt động đảm bảo chất lượng phần mềm do những người đang tham gia phát triển phần mềm thực hiện.
- Mục tiêu:
(1) Phát hiện các lỗi trong chức năng, trong logic, trong triển khai.
(2) Kiểm thử sự phù hợp của phần mềm với yêu cầu
(3) Bảo đảm rằng phần mềm phù hợp với các chuẩn đã định sẵn
(4) Đảm bảo “ phần mềm đã được phát triển theo một cách thức nhất quán.
(5) Làm cho dự án dễ quản lý hơn
Ngoài ra dùng để làm cơ sở huấn luyện các kỹ sư trẻ và có ích ngay cả cho những kỹ sư đã có kinh nghiệm.
3đ
Câu 6
Câu hỏi: Vẽ sơ đồ tiến trình hoạt động rà soát và giải thích sơ bộ nội dung mỗi bước?
3đ
Giải thích:
- Mỗi cá nhân phát triển phải thông báo cho lãnh đạo dự án biết rằng sản phẩm đã hoàn tất và cần phải rà soát.
- Lãnh đạo dự án thông báo cho người chịu trách nhiệm rà soát biết
- Người chịu trách nhiệm lãnh đạo rà soát:
o Xem xét sản phẩm để đọc, rà soát
o Tạo ra các bản sao của sản phẩm, phân cho 2,3 người ra soát
o Thiết lập chương trình họp rà soát
o Thực hiện rà soát: thường tốn 1-2 giờ để rà soát viết các bản ghi chú : tham gia cuộc họp rà soát.
3đ
Câu 7
Câu hỏi: Trình bày nội dung cơ bản một cuộc họp rà soát: thành phần, thời gian, công việc cần làm, phương châm, sản phẩm?
3đ
Bất kể thế nào, mọi cuộc họp rà soát phải có:
· Thành phần: Có từ 3 đến 5 người liên quan tới việc rà soát, gồm có:
• lãnh đạo rà soát
• tất cả các cá nhân rà soát
• người tạo ra sản phẩm được rà soát
· Thời gian:
• Phải có sự chuẩn bị trước, tuy nhiên mỗi người không quá 2 giờ chuẩn bị.
• Cuộc họp nên ít hơn 2 giờ. Mỗi cuộc họp rà soát chỉ hạn chế trong một phần nhỏ, cụ thể.
· Công việc cần làm:
• Trọng tâm của các cuộc họp rà soát là về sản phẩm: một thành phần (một thành phần của đặc tả yêu cầu, một thiết kế modul chi tiết, một danh sách mã nguồn cho một modul)
• Phải đưa ra một trong 3 quyết định sau đây:
- Chấp nhận sản phẩm không cần chỉnh sửa
- Khước từ sản phẩm vì những lỗi nghiêm trọng
- Chấp nhận cho chỉnh sửa sản phẩm, sau khi chỉnh sửa phải có cuộc họp rà soát lại
• Mọi thành viên tham gia cuộc họp phải ký vào quyết định
· Phương châm rà soát:
• Cần thiết lập trước phương châm rà soát, phân phát cho những người làm nhiệm vụ rà soát, thống nhất tán thành và tuân thủ. Một rà soát mà không khống chế được thì có thể còn xấu hơn là không rà soát
• 10 điều tối thiểu trong phương châm rà soát kỹ thuật chính thức:
(1) rà soát sản phẩm, không rà soát người làm nó
(2) Lập chương trình nghị sự và duy trì nó.
(3) Hạn chế tranh luận và bác bỏ: các vấn đề tranh luận nên để ghi nhớ cho các thảo luận tiếp tục
(4) Trình bày rõ ràng mạch lạc các vùng có vấn đề nhưng không được gượng ép giải quyết mọi vấn đề nhận thấy: FTR không giải quyết vấn đề, việc giải quyết vấn đề sau FTR và thường do chính người làm ra sản phẩm thực hiện, có thể nhờ sự trợ giúp của vài cá nhân khác.
(5) Nên có ghi chú trên bảng tường
(6) Giới hạn số người tham dự và kiên trì các dự kiến
(7) Lập một danh sách các kiểm tra cho từng sản phẩm sẽ được rà soát:
s Giúp nhà lãnh đạo rà soát cấu trúc các cuộc họp FTR
s Giúp người rà soát tập trung vào các vấn đề quan trọng
s Danh sách kiểm tra lập cho từng loại sản phẩm:ành cho việc phân tích, thiết kế, mã hoá kiểm tra và bảo trì
s Một tập thể các đại diện sẽ xem lại danh sách này để trình.
(8) Cấp phát nguồn lực và thời biểu cho các FTR: xem nó là một nhiệm vụ trong quá trình phát triển phần mềm, và cũng phải dự tính các cải biên cần thiết cho sự kiện chưa dự đoán được
(9) Cần phải tiến hành huấn luyện chính thức cho các cá nhân ra soát
(10) Rà soát lại các rà soát trước đây.
3đ
Câu 8
Câu hỏi: Các sản phẩm của cuộc họp rà soát là gì? Tiến trình ra soát gồm?
3đ
* Sản phẩm của cuộc họp rà soát là:
• Báo cáo các vấn đề nảy sinh do các cá nhân rà soát nêu ra
• Một danh sách các vấn đề cần giải quyết do cuộc họp thống nhất.
s để nhận ra vùng có vấn đề trong sản phẩm được rà soát
s dùng như một danh sách các khoản mục hành động để chỉ cho người làm ra sản phẩm cần chỉnh sửa
s Cần thiết lập một thủ tục để bảo đảm rằng các khoản mục trong danh sách đó sẽ được chỉnh sửa thực sự
• Một văn bản tổng kết cuộc họp rà soát đó, văn bản này phải chỉ rõ
s Rà soát cái gì
s Ai rà soát
s Tìm thấy cái gì? và kết luận
* Tiến trình phát triển chung nhất gồm 4-5 giai đoạn:
§ Kỹ nghệ hệ thống
§ Phân tích, xác định yêu cầu phần mềm
§ Thiết kế phần mềm
§ Kiểm thử phần mềm
§ Bảo trì (với sản phẩm đặt hàng)
3đ
Câu 9
Câu hỏi: Trình bày những nội dung cơ bản (mục tiêu, nội dung, danh mục) của rà soát phân tích yêu cầu phần mềm
3đ
· rà soát phân tích yêu cầu phần mềm
¨ Mục tiêu: thẩm định và xác minh yêu cầu phần mềm
- phải chỉ ra các nhu cầu của người dùng là được thoả mãn
- Các yêu cầu phải nhất quán, nghĩa là không mâu thuẫn nhau
- Các yêu cầu phải đầy đủ: chúng phải chứa mọi chức năng và mọi ràng buộc mà người dùng đã nhắm đến
- Các yêu cầu phải là hiện thực, tức là có khả năng thực hiện được
¨ Nội dung:
- tập trung vào khả năng viết ra các yêu cầu hệ thống phần mềm (chức năng, phi chức năng, ngoại lai)
- sự phù hợp và tính đúng đắn của mô hình phân tích.
- Với các hệ thống lớn cần tăng cường: đánh giá các nguyên mẫu cũng như các cuộc họp với khách hàng
¨ Danh mục: xem xét các chủ đề sau:
(1) Phân hoạch vấn đề (hệ con) có đầy đủ hay không?
(2) Các giao diện trong và ngoài đã thực sự được xác định chưa?
(3) Phân tích lĩnh vực thông tin có đầy đủ, phi mâu thuẫn và chính xác hay ko?
(4) Mô hình dữ liệu đã thực sự phản ánh các đối tượng dữ liệu, các thuộc tính và các quan hệ?
(5) Tất cả các yêu cầu có thể lần vết được ở mức hệ thống không?
(6) Đã làm bản mẫu dành cho người sử dụng (khách hàng) chưa?
(7) Liệu có thực hiện được với những ràng buộc quy định bởi các phần tử hệ thống khác hay không?
(8) Các yêu cầu có phù hợp với lịch biểu, nguồn lực và kinh phí hay không?
(9) Các chuẩn thẩm định có đầy đủ hay không?
3đ
Câu 10
Câu hỏi: Trình bày những nội dung cơ bản (mục tiêu, nội dung, danh mục) của rà soát thiết kế phần mềm ( tương ứng với từng giai đoạn thiết kế)
3đ
¨ Mục tiêu: Hướng đến thiết kế đảm bảo hai yêu cầu
- Phản ánh đúng các yêu cầu đặc tả
§ Đủ các phần
§ Đủ chức năng và ràng buộc
§ Dữ liệu đủ, phù hợp
- Có chất lượng tốt
§ Cấu trúc tốt (phân hoạch, giao diện, modul hoá)
§ Thuật toán tốt (ít phức tạp, tốc độ cao, dễ hiểu)
§ Dữ liệu tốt (cấu trúc, biểu diễn)
§ Có thể lần vết được (dễ hiểu, dễ kiểm tra)
¨ Nội dung:
- Rà soát kỹ thuật chính thức cho khâu thiết kế tập trung vào:
§ thiết kế dữ liệu
§ thiết kế kiến trúc
§ thiết kế thủ tục.
- Có 2 kiểu rà soát thiết kế (phù hợp với bước triển khai):
§ rà soát thiết kế sơ bộ - preliminary design review (đánh giá việc dịch các yêu cầu thành thiết kế dữ liệu và thiết kế kiến trúc),
§ rà soát thiết kế trọn vẹn - design walkthrough (tập trung vào tính đúng đắn của thuật toán).
¨ Danh mục
- Rà soát thiết kế sơ bộ
(1) Các yêu cầu phần mềm có được phản ánh trong kiến trúc phần mềm hay không?
(2) Có đạt được sự môđun hoá hiệu quả không? Các môđun có độc lập chức năng hay không
(3) Kiến trúc chơng trình có được phân tách không?
(4) Các giao diện đã được xác định cho các môđun và các phần tử hệ thống ngoại lai chưa?
(5) Cấu trúc dữ liệu có phù hợp với lĩnh vực thông tin chưa?
(6) Cấu trúc dữ liệu có phù hợp với yêu cầu phần mềm chưa?
(7) Khả năng bảo trì đã được xem xét chưa?
(8) Các nhân tố chất lượng đã được đánh giá rõ ràng chưa?
- Rà soát thiết kế toàn bộ
(1) Thuật toán có hoàn thành chức năng mong muốn không?
(2) Thuật toán có đúng đắn logic không?
(3) Giao diện có phù hợp với thiết kế kiến trúc không?
(4) Độ phức tạp logic có phải chăng hay không?
(5) Xử lý sai đã được đặc tả chưa?
(6) Cấu trúc dữ liệu cục bộ có thật sự đã được xác định?
(7) Kiến tạo lập trình cấu trúc đã xuyên suốt chưa?
(8) Các chi tiết thiết kế đã tuân theo ngôn ngữ thực hiện chưa?
(9) Dùng các đặc điểm hệ điều hành hay là phụ thuộc ngôn ngữ?
(10) Đó dùng logic compound hoặc logic inverse?
(11) Khả năng bảo trì đã được xét tới chưa
3đ
Câu 11
Câu hỏi: Trình bày những nội dung cơ bản (mục tiêu, danh mục) của rà soát lập mã phần mềm
3đ
¨ Mục tiêu: rà soát hướng đến mã nguồn đạt được
- phản ánh đầy đủ, phù hợp với thiết kế
- phù hợp với ngôn ngữ sử dụng (chuẩn, cú pháp, khai báo dữ liệu...)
- Văn bản chương trình tốt (không lỗi chính tả, có cấu trúc, nhất quán ...)
¨ Danh mục
(1) Thiết kế có thực sự được dịch thành mã chưa?
(2) Có các sai sót chính tả hoặc in ấn nào không?
(3) Có thực sự dùng các quy ước ngôn ngữ hay không?
(4) Có phục tùng về các chuẩn mẫu lập mã đối với phong cách ngôn ngữ, ghi chú ...
(5) Có ghi chú nào không đúng đắn hoặc mơ hồ?
(6) Kiểu dữ liệu và khai báo dữ liệu có chính xác hay không?
(7) Các hằng số vật lý có đúng đắn hay không?
(8) Có phải tất cả các khoản mục của danh sách rà soát thiết kế trọn vẹn là được áp dụng lại hay không?
3đ
Câu 12
Câu hỏi: Trình bày những nội dung cơ bản (mục tiêu, nội dung, danh mục) của rà soát kiểm thử phần mềm (tương ứng với kế hoạch và thủ tục kiểm thử)
3đ
¨ Mục tiêu:
- Đánh giá một cách phê phán các kế hoạch kiểm thử và các thủ tục kiểm thử
- hướng đến đảm bảo các phương pháp, các chiến lược và các kỹ thuật được sử dụng và kế hoạch tốt
¨ Nội dung:
- chiến lược kiểm thử
§ từ trên xuống
§ từ dưới lên
§ vụ nổ lớn (big bang)
- kỹ thuật kiểm thử
§ kiểm thử hộp đen
§ kiểm thử hộp trắng
§ kiểm thử tải trọng
§ kiểm thử luồn sợi (cho hệ thời gian thực)
§ sử dụng CASE
- Kế hoạch kiểm thử tổng thể
§ Giới thiệu chung
§ Mô tả hệ thống cần kiểm thử
§ Các mục tiêu kiểm thử
§ Phương pháp sử dụng
§ Tài liệu hỗ trợ
§ Kế hoạch
§ Thời gian, địa điểm
§ Tài liệu kiểm thử: các ca kiểm thử, tiến trình, lịch trình
§ Điều kiện
§ Các yêu cầu: phần cứng, phần mềm, nhân sự
§ Kiểm soát quá trình kiểm thử
¨ Danh mục:
(1) Các pha thử nghiệm chủ yếu có thực sự được định rõ và được xắp xếp tuần tự hay không?
(2) Theo dõi các yêu cầu (tiêu chuẩn) có được thiết lập như một phần của pha phân tích yêu cầu phần mềm hay không?
(3) Các chức năng chủ yếu có được trình diễn sớm không?
(4) Kế hoạch thử nghiệm có phù hợp với kế hoạch dự án tổng thể hay không?
(5) Lịch trình thử nghiệm có được xác định rõ ràng hay không?
(6) Nguồn lực và công cụ thử nghiệm đã đợc minh định và đã sẵn sàng hay chưa?
(7) Đã thiết lập cơ chế lưu trữ các báo cáo chưa?
(8) Các bộ lái (driver) và các cuống (stub) thử nghiệm đã được minh định chưa?; công việc phát triển chúng đã được lập lịch chưa?
(9) Thử nghiệm cường độ chịu áp lực cho phần mềm đã được đặc tả chưa?
(10) Cả hai loại thử nghiệm hộp trắng và hộp đen đã được đặc tả chưa?
(11) Có phải tất cả các đường logic độc lập đều được thử nghiệm?
(12) Có phải tất cả các ca thử nghiệm đều đã được minh định và lập danh sách với đủ các kết qủa chờ mong?
(13) Việc xử lý sai có được thử nghiệm?
(14) Các giá trị biên có được thử nghiệm?
(15) Các yêu cầu thời gian và sự diễn tiến có được thử nghiệm?
(16) Các biến thể chấp nhận được của kết quả thử nghiệm mong đợi đã được đặc tả chưa?
3đ
Bạn đang đọc truyện trên: Truyen2U.Pro