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

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?

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.

Checklist Description Expected Output

Môi trường kiểm thử đã được “Clear”? Môi trường kiểm thử đã sẵn sàng

Kiểm tra tổng thể giao diện màn hình?
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
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

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ử
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?
LEVEL KIỂM THỬ:
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ả
- 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

4. Lược đồ chuyển trạng thái
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.
(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ử.
 + 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.