Chuẩn form PTIT - Không phải ngân hàng ao sen

Chia sẻ: Hashmat Salahuddin | Ngày: | Loại File: PDF | Số trang:14

Thêm vào BST

Báo xấu

19
lượt xem 2
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Tài liệu trình bày về chất lượng phần mềm; đảm bảo chất lượng phần mềm; tiêu chí MC call; review kỹ thuật walkthrough; review kỹ thuật inspection...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Chuẩn form PTIT - Không phải ngân hàng ao sen

Lưu hành nội bộ group - Nghiêm cấm phát tán dưới mọi hình thức CHUẨN FORM PTIT - KHÔNG PHẢI NGÂN HÀNG AO SEN ALLAHU AKBAR! PHẦN MỀM: CHẤT LƯỢNG PHẦN MỀM: ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM: CÁC HÀNH ĐỘNG ĐEM LẠI SỰ TIN CẬY ĐÁP ỨNG CÁC YÊU CẦU VỀ CHỨC NĂNG TRONG LỊCH TRÌNH VÀ TRONG NGÂN SÁCH
Lưu hành nội bộ group - Nghiêm cấm phát tán dưới mọi hình thức 11 TIÊU CHÍ MC CALL: + Tiêu chí vận hành sản phẩm - Tính đúng đắn - Correctness Đưa ra từ tài liệu yêu cầu và đặc tả output, ví dụ: sai số bao nhiêu, thời gian chuẩn… - Tính tin cậy - Reliability Tỉ lệ xảy ra lỗi cho hệ thống…thời gian chếtphút??), time xảy ra 2 lần chết - Tính hiệu quả - Efficiency Tài nguyên phần cứng cần để thực hiện chức năng phần mềm (MHz, đường truyền, bộ nhớ..) - Tính toàn vẹn - Intergrity Bảo mật, phân quyền, ngăn chặn truy cập trái phép - Tính khả dụng - Usability Dễ dùng hay không? Thao tác nhanh không?, quy mô tới nguồn lwujc để tạo nhân viên mới và để sử dụng phần mềm + Tiêu chí sửa đổi sản phẩm - Tính bảo trì được Mức công sức cần để xác định nguyên nhân hỏng hóc và sửa, đề cập tới cấu trúc mô đun phần mềm, tài liệu, kiến trúc chi tiết --> Code dễ đọc dễ sửa, viết cmt chuẩn, tác giả, output… -Tính linh hoạt - Flexibility: Đề cập tới nguồn lực để thay đổi phần mềm cho users khác( cải tiến..) - Tính kiểm thử được: Có lưu lại kq? Tạo file log, backup? +Tiêu chí chuyển giao sản phẩm: - Khả năng di động: portability: Chuyển sang mô trường khác? - Tái sử dụng: Sử dụng cho phần mềm khác? - Tính tương thích - Interroperability Phần mềm có cần giao tiếp với các hệ thống đã có( Có thể giao tiếp với modun khác, tính tiền liên kết xuất hóa đơn…
Lưu hành nội bộ group - Nghiêm cấm phát tán dưới mọi hình thức Review kỹ thuật Walkthrough • Walkthrough: Kỹ thuật đánh giá không chính thức(nên ko có ng quản lý, giám đốc dự án). Những người tham gia phải xem tài liệu trước cuộc họp (ít nhất vài ngày). Tác giả giải thích tài liệu/ sản phẩm đó cho nhóm (tác giả, điều phối viên, giám định viên, đại diện ng dùng, chuyên gia bảo trì). + Mọi người sẽ đặt câu hỏi hoặc cho ý kiến bổ sung về một số lĩnh vực để bảo đảm chất lượng kỹ thuật của tài liệu hoặc sản phẩm. + Buổi giám định có thể xảy ra vào bất kì lúc nào và bất kì đâu trong việc phát triển sản phẩm phần mềm. Mục đích chính của họp giám định chỉ là để tìm lỗi nhanh, ko tìm giải pháp. Sau giám định, tác giả của phải làm lại sửa mọi lỗi. Review kỹ thuật Inspection • Inspection: Kỹ thuật đánh giá chính thức. Tài liệu, sản phẩm... được những người không phải là tác giả hoặc trực tiếp liên quan(Ngươi kiểm duyệt, tác giả, tester, thiết kế, coder) kiểm tra một cách chi tiết để phát hiện lỗi, các vi phạm tiêu chuẩn, hoặc các vấn đề khác (nếu có). + Về cơ bản, nó được tổ chức và thực hiện chặt chẽ hơn walkthrough. Vai trò của những người tham gia được phân định rõ ràng. Tài liệu chuẩn bị cho việc xem xét được chuẩn bị trước chu đáo. + Quá trình duyệt thảo bắt đầu sau giai đoạn code và unit test. Sau buổi họp các lỗi tìm đc sẽ đc sửa lại, rồi đem ra duyệt thảo lại cho đến khi đạt tiêu chuẩn mới kết thúc quá trình này. Checklist GUI CHECK LIST I . AESTHETIC CHECK (Kiểm tra về giao diện) II. VALIDATION CHECK (Kiểm tra tính hợp lệ) Datatype varchar, nvarchar, ntext . NAVIGATION CHECK (Kiểm tra phương pháp di chuyển/duyệt web) 1 . Tất cả các trang web/cửa sổ đều có thể truy cập từ menu. V. DATA INTEGRITY CONDITIONS (Kiểm tra tính ràng buộc dữ liệu) 1 . Data có được lưu khi đóng cửa sổ hay không?
Lưu hành nội bộ group - Nghiêm cấm phát tán dưới mọi hình thức IV. USABILITY CHECK: (Kiểm tra tính thân thiện của chương trình) Checklist là danh sách các đầu mục cần kiểm tra về nghiệp vụ, chức năng của hệ thống. Nó chỉ là các mục mang tính tổng quan. Bạn có thể phát triển nó thành bộ testcase hoàn chỉnh. II. Khi nào cần tạo checklist? Lí do phổ biến nhất để tạo checklist thay vì testcase là không đủ thời gian, dự án yêu cầu phải test trong thời gian ngắn. Navigation - Kiểm tra việc chuyển hướng của tất cả các menu, hyperlink, button Formatting - Kiểm tra các định dạng phù hợp với mỗi đối tượng tương ứng như như các text-box để nhập/ chọn ngày cần hiển thị đúng định dạng, Color and fonts - Kiểm tra tất cả màu sắc, kích thước font của các đoạn văn bản hay các thông báo lỗi trên màn hình. Scrolls - Tất cả thanh cuộn ngang hay thanh cuộn dọc chỉ nên xuất Controls and alignments - Có thể thay đổi kích thước màn hình (re- size window) mà các đối tượng UI sẽ được sắp xế Spelling and grammar - Đối với các đối tượng như đoạn văn bản, chú thích, thông báo lỗi, lời nhắc, thanh trạng thái, Justification - Nếu dữ liệu là số thì nên được canh phải, dữ liệu là các ký tự, chữ cái thì được canh trái (nếu không có ngoại lệ đặc biệt). Tab - Đảm bảo khi người dùng nhấn phím tab trên bàn phím thì theo thứ tự con Opening input - Kiểm tra việc khi tải xong một trang hay một cửa sổ thì con trỏ chuột có focus vào text-box đầu tiên để cho phép người dùng nhập dữ liệu vào nó hay không? Alternatives - Khi menu của ứng dụng có các phím nóng (hot key) thay thế thì chúng nên hoạt động chuẩn xác và không để xảy ra trường hợp trùng lặp hot key trên cùng một cửa sổ Contrast - Các đối tượng như text-box, button,.. khi chúng đang mang thuộc tính disable hay read-only thì nên được đổi màu (màu xám) để phân biệt với các đối tượng khá c. Images - Kiểm tra tất cả các hình ảnh đang có trong ứng dụng. Kiểm tra kích thước, dung lượng của chúng vì có thể ảnh hưởng nhiều đến GUI performance.
Lưu hành nội bộ group - Nghiêm cấm phát tán dưới mọi hình thức Checklist Description Expected Output Môi trường kiểm thử đã được “Clear”? Môi trường kiểm thử đã sẵn sàng 1. Các label, textbox, combo có độ dài, rộng và khoảng cách bằng nhau, không x 2. Các label sử dụng cùng 1 loại font, cỡ chữ, căn lề trái Kiểm tra tổng thể giao diện màn hình? 3. Các trường hợp bắt buộc nhập phải có dấu (*) 4. Kiểm tra tất cả lỗi về chính tả, cấu trúc câu, ngữ pháp trên màn hình 5. Form được bố trí hợp lý và dễ sử dụng Kiểm tra biểu tượng của trỏ chuột khi click vào button hoặc vào link Con trỏ chuột có xuất hiện hình bàn tay khi di đến button hoặc link không? Với các trường nhập Text thì đã test các trường hợp sau chưa: Blank, Max Leng Kiểm tra trường text âm Kiểm tra khi click vào các link Truy cập đến màn hình tương ứng với 1 mục được chọn Màn hình chức năng được mở: – Hiển thị title của chức năng trên màn hình Kiểm tra màn hình ở trạng thái mặc định? – Focus được set vào trường đầu tiên có thể edit – Hiển thị đầy đủ các trường như trong tài liệu thiết kế – Hiển thị các giá trị mặc định của các trường đúng. Kiểm tra thứ tự di chuyển trỏ trên màn hình khi nhấn phím Tab? Con trỏ di chuyển lần lượt theo thứ tự: Từ trái qua phải, từ trên xuống dưới Kiểm tra thứ tự con trỏ di chuyển ngược lại trên màn hình khi nhấn Shift-Tab? Con trỏ di chuyển ngược lại theo thứ tự: từ dưới lên trên, từ phải qua trái 1. Nếu chuột ko focus vào button nào thì Thực hiện chức năng của button chính Kiểm tra thực hiện chức năng chính của màn hình khi nhấn Enter? 2. Nếu đang focus vào 1 button thì sẽ thực hiện chức năng của button 1. Refesh lại màn hình Kiểm tra trường hợp Refresh màn hình (Nhấn F5)? 2. Sau khi refresh, các chức năng vẫn thực hiện đúng Có xuất hiện thành cuộn dọc, và thanh cuộn ngang? Chỉ xuất hiện khi cần thiết Khả năng di chuyển giữa các mục khác nhau trên form? Có thể sử dụng phím tab để di chuyển giữa các mục trên form – Đánh số thứ tự tăng dần và liên tục – Không hiển thị link [Trước] khi ở trang 1 Kiểm tra phân trang – Không hiển thị link [Sau] khi ở trang cuối – Chuyển về trang đầu, trang cuối, trước, sau hoặc 1 trang bất kỳ Thanh điều hướng hiển thị nhất quán trên màn hình? Thiết kế thanh điều hướng trên các màn hình Các phần phải hiển thị rõ ràng: Khi văn bản quá dài thì có thể sử dụng phân tran Các trang có rõ ràng và không bị cắt mất phần văn bản không? cùng một trang Các trang web được hiển thị tốt trên nhiều trình duyệt và nhiều độ phân giải khác nhau không? Kiểm tra giao diện các trang phải hiển thị tốt trên các môi trường yêu cầu
Lưu hành nội bộ group - Nghiêm cấm phát tán dưới mọi hình thức Màu sắc của những siêu liên kết (hyperlink) có đúng chuẩn? Đúng với thiết kế Màu nền chung của toàn bộ màn hình có được set đúng theo yêu cầu không? Đúng với thiết kế Kiểm tra màu chữ, font, font size của tất cả các textbox có set đúng theo yêu cầu không? Hiển thị đúng với yêu cầu Kiểm tra màu chữ, font, font size của tất cả các textbox có set đúng theo yêu cầu không? Kiểm tra màu chữ, font, font size của tất cả các label đúng theo yêu cầu Kiểm tra màu nền Kiểm tra background (màu nền) của tất cả các label có set đúng theo yêu cầu kh Kiểm tra màu chữ và màu nền các textbox Kiểm tra màu chữ và màu nền của các textbox trong chế độ read-only có được Những đường link có sử dụng màu sắc tiêu chuẩn không? Đúng với thiết kế Tất cả các nội dung có cùng font chữ không? Đúng với thiết kế Tất cả các văn bản có thẳng hàng không? Đúng với thiết kế Kiểm tra các control trên màn hình Tất cả các control trên màn hình được căn đều (Label, textbox, checkbox, list , Kiểm tra xem các web/cửa sổ có thể truy cập trực tiếp từ menu không? Tất cả các trang web/cửa sổ đều có thể truy cập từ menu. Kiểm tra Số bản ghi trên 1 trang Hiển thị đúng số bản ghi được thiết lập hiển thị trên 1 trang Kiểm tra title của trang Cần hiển thị title đúng và hợp lý trên các trang khách nhau Kiểm tra Style của paging Thống nhất 1 Style hiển thị chung LỖI PHẦN MỀM: - Lỗi phần mềm(Software Error) là các phần code sai do lôi cú pháp, logic hoăc lỗi do phân tích, thiết kế - Nguyên nhân gây ra lỗi: 1. Lỗi khi định nghĩa yêu cầu 2. Quan hệ Client-developer tồi 3. Sai phạm có chủ ý với yêu cầu phần mềm 4. Lỗi thiết kế logic 5. Lỗi lập trình 6. Không tuân thủ các hướng dẫn viết tài liệu và code 7. Thiếu sót của quá trình kiểm thử
Lưu hành nội bộ group - Nghiêm cấm phát tán dưới mọi hình thức 8. Lỗi giao diện người dùng và thủ tục 9. Lỗi tài liệu 1. Error: Có thể hiển thị không đúng yêu cầu users, hiển sai chính tả, không làm chương trình chạy sai kết quả Fault: Ví dụ là điều kiện nhỏ hơn 0 nhưng lại viết thành lớn hơn 1 mới được thi Failure: VÍ dụ tiềm tàng 1 số fault nhập sai dữ liệu kích hoạt, ví dụ điểm >1 mới được thi, những người 2-10 không vấn đề gì, những người =1 đáng ra được thi nhưng lại bị lỗi KIỂM THỬ LÀ GÌ? TEST CASE?
Lưu hành nội bộ group - Nghiêm cấm phát tán dưới mọi hình thức LEVEL KIỂM THỬ:
Lưu hành nội bộ group - Nghiêm cấm phát tán dưới mọi hình thức 2. Kiểm thử hộp đen: Phương pháp kiểm thử mà không cần biết cài đặt của chương trình - Cần có một bản chương trình chạy được và tài liệu đặc tả
Lưu hành nội bộ group - Nghiêm cấm phát tán dưới mọi hình thức - Phân lớp tương đương: Xác định các lớp tương đương Xác định các ca kiểm thử 3. Kỹ thuật dùng bảng quyết định
Lưu hành nội bộ group - Nghiêm cấm phát tán dưới mọi hình thức 4. Lược đồ chuyển trạng thái
Lưu hành nội bộ group - Nghiêm cấm phát tán dưới mọi hình thức Check độ phủ Kiểm thử biên được sử dụng khi: + Giá trị đầu vào ko ràng buộc lẫn nhau + Có nhiều giá trị đầu vào nhận giá trị trong các miền hoặc các tập hợp + Muốn test đơn giản, test tự động hóa.
Lưu hành nội bộ group - Nghiêm cấm phát tán dưới mọi hình thức (Kiểm thử đơn vị, tích hợp, hệ thống và chấp nhận) Kiểm thử lớp tương đương được sử dụng khi: + Nhiều giá trị đầu vào và nhận giá trị trong các miền/tập + Test thủ công (Kiểm thử đơn vị, tích hợp, hệ thống và chấp nhận) Kiểm thử bảng quyết định được sử dụng khi: + Logic và điều kiện phức tạp. Có các quan hệ logic quan trọng giữa các biến đầu vào. + Đặc tả có thể chuyển về trạng thái bảng(Các chức năng có thể mô tả bằng quyết định) + Thứ tự các hành động xảy ra ko quan trọng + Thứ tự các luật ko ảnh hưởng đến hàng động + Khi một luật thỏa mãn và được chọn thì không cần xét luật khác + Các luật phải đầy đủ(Có mọi tổ hợp) và nhất quán(Mọi tổ hợp chân lý chỉ gây ra 1 tập hành động) Sơ đồ chuyển trạng được sử dụng khi: + Khi muốn kiểm thử trạng thái, sự kiện, chuyển tiếp + Ko hữu dụng khi hệ thống ko có trạng thái hay ko phải đáp trả các sự kiện thời gian thực từ bên ngoài hệ thống Kiểm thử hộp trắng là gì? Nêu các đặc trưng của nó? - Là hình thức kiểm thử mà kiểm thử viên biết được các cấu trúc bên trong của chương trình (mã nguồn, xử lý dữ liệu, …). Việc kiểm thử được dựa trên các phân tích về cấu trúc bên trong của thành phần/hệ thống. Kiểm tra mã nguồn các chi tiết thủ tục (thuật toán), các con đường logic (luồng điều khiển), các trạng thái của chương trình (dữ liệu) - Đặc trưng: + Kiểm thử hộp trắng dựa vào thuật giải cụ thể, vào cấu trúc dữ liệu bên trong của đơn vị phần mềm cần kiểm thử để xác địnhđơn vị phần mềm đó có thực hiện đúng không. + Người kiểm thử hộp trắng phải có kỹ năng, kiến thức nhất định để có thể hiểu chi tiết về đoạn code cần kiểm thử.
Lưu hành nội bộ group - Nghiêm cấm phát tán dưới mọi hình thức + Thường tốn rất nhiều thời gian và công sức nếu mức độ kiểm thử được nâng lên ở cấp kiểm thử tích hợp hay kiểm thử hệ thống. + Do đó kỹ thuật này chủ yếu được dùng để kiểm thử đơn vị. Trong lập trình hướng đối tượng, kiểm thử đơn vị là kiểm thử từng tác vụ của 1 class chức năng nào đó. + Có 2 hoạt động kiểm thử hộp trắng: Kiểm thử luồng điều khiển và kiểm thử dòng dữ liệu.