-
Thông tin
-
Hỏi đáp
Lý thuyết kiểm tra phần mềm | môn Kỹ thuật đo | trường Đại học Huế
Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho người có lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành khác nhau. Tài liệu giúp bạn tham khảo, ôn tập và đạt kết quả cao. Mời bạn đọc đón xem!
Báo cáo thực hành 6 tài liệu
Đại học Huế 272 tài liệu
Lý thuyết kiểm tra phần mềm | môn Kỹ thuật đo | trường Đại học Huế
Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho người có lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành khác nhau. Tài liệu giúp bạn tham khảo, ôn tập và đạt kết quả cao. Mời bạn đọc đón xem!
Môn: Báo cáo thực hành 6 tài liệu
Trường: Đại học Huế 272 tài liệu
Thông tin:
Tác giả:
Preview text:
lO M oARcPSD| 45467232 lO M oARcPSD| 45467232 Chương 1: khái niệm -
Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm trong đúng môi
trường chúng dự định sẽ được triển khai nhằm cung cấp cho người có lợi ích liên quan những thông tin về
chất lượng của sản phẩm hay dịch vụ phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay
khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành khác nhau. -
Trường hợp thử (Test case): Trường hợp thử được liên kết tương ứng với hoạt động của chương trình.
Một trường hợp thử bao một một tập các giá trị đầu vào và một danh sách các kết quả đầu ra mong muốn. -
Nhiệm vụ của kiểm tra phần mềm Kiểm tra phần mềm phải thực hiện hai nhiệm vụ: xác minh và thẩm
định. -Xác minh và thẩm định một hệ phần mềm là một quá trình liên tục xuyên suốt mọi giai đoạn của quá
trình phần mềm. -Xác minh và thẩm định là từ chung cho các quá trình kiểm tra để đảm bảo rằng phần mềm
thỏa mãn các yêu cầu của chúng và các yêu cầu đó thỏa mãn các nhu cầu của người sắm phần mềm. -Xác
minh và thẩm định là một quá trình kéo dài suốt vòng đời. Nó bắt đầu khi duyệt xét yêu cầu. Xác minh và
thẩm định có hai mục tiêu: i) Phát hiện các khuyết tật trong hệ thống. i) Đánh giá xem hệ thống liệu có
dùng được hay không? -Sự khác nhau giữa xác minh và thẩm định là: i) Thẩm định: Xem xét cái được xây
dựng có là sản phẩm đúng không? Tức là kiểm tra xem chương trình có được như mong đợi của người dùng
hay không. i) Xác minh: Xem xét cái được xây dựng có đúng là sản phẩm không? Như thế, xác minh là
kiểm tra chương trình có phù hợp với đặc tả hay không. -
Mục tiêu kiểm thử • Kiểm thử là một quá trình thực thi chương trình với mục đích là tìm ra lổi/các yếu
điểm của chương trình. • Một trường hợp kiểm thử tốt là một trường hợp có khả năng lớn trong việc tìm ra
những lỗi chưa được phát hiện. • Một trường hợp kiểm không tốt (không thành công) là một trường hợp mà
khả năng tìm thấy những lổi chưa biết đền là rất ít. -Mục tiêu của kiểm thử phần mềm là thiết kế những
trượng hợp kiểm thử để có thể phát hiện một cách có thệ thống những loại lỗi khác nhau và thực hiện việc
đó với lượng thời gian và tài nguyên ít nhất có thể. -
Các loại kiểm thử và phân loại Có 2 mức phân loại kiểm thử: phân biệt theo mức độ chi tiết và phân biệt
theo phương pháp thử nghiệm Phân biệt theo mức độ chi tiết của các bộ phận hợp thành phần mềm. –
Mức kiểm tra đơn vị (Unit) – Mức kiểm tra hệ thống (System) – Mức kiểm tra tích hợp (Integration) Phân
biệt theo phương pháp thử nghiệm – Kiểm thử hộp đen (Black box testing) dùng để kiểm tra chức năng. –
Kiểm thử hộp trắng (White box testing) dùng để kiểm tra cấu trúc. lO M oARcPSD| 45467232 -
vòng đời của kiểm thử PM: -
Sơ lượt các kỹ thuật và phân
loại kiểm thử phần mềm Các
kỹ thuật và công đoạn kiểm thử
có thể chia như sau: Kiểm thử
tầm hẹp và Kiểm thử tầm rộng.
1. Kiểm thử tầm hẹp: kiểm thử
các bộ phận riêng rẽ. a. Kiểm
thử hộp trắng (white-box
testing) Còn gọi là kiểm thử cấu
trúc. Kiểm thử theo cách này là
loại kiểm thử sử dụng các thông
tin về cấu trúc bên trong của ứng
dụng. Việc kiểm thử này dựa
trên quá trình thực hiện xây
dựng phần mềm. Tiêu chuẩn của
kiểm thử hộp trắng phải đáp ứng
các yêu cầu như sau: -Bao phủ dòng lệnh: mỗi dòng lệnh ít nhất phải được thực thi 1 lần. -Bao phủ nhánh:
mỗi nhánh trong sơ đồ điều khiển (control graph) phải được đi qua một lần. -Bao phủ đường: tất cả các
đường (path) từ điểm khởi tạo đến điểm cuối cùng trong sơ đồ dòng điều khiển phải được đi qua. b. Kiểm
thử hộp đen (black-box testing) Còn gọi là kiểm thử chức năng. Việc kiểm thử này được thực hiện mà
không cần quan tâm đến các thiết kế và viết mã của chương trình. Kiểm thử theo cách này chỉ quan tâm đến
chức năng đã đề ra của chương trình. Vì vậy kiểm thử loại này chỉ dựa vào bản mô tả chức năng của chương
trình, xem chương trình có thực sự cung cấp đúng chức năng đã mô tả trong bản chức năng hay không mà
thôi. -Kiểm thử hộp đen dựa vào các định nghĩa về chức năng của chương trình. Các trường hợp thử nghiệm
(test case) sẽ được tạo ra dựa nhiều vào bản mô tả chức năng chứ không phải dựa vào cấu trúc của chương
trình. c. Vấn đề kiểm thử tại biên: Kiểm thử biên (boundary) là vấn đề được đặt ra trong cả hai loại kiểm
thử hộp đen và hộp trắng. Lý do là do lỗi thường xảy ra tại vùng này. 2. Kiểm thử tầm rộng: - Kiểm thử bộ
phận (Module testing): kiểm tra một bộ phận riêng rẽ. - Kiểm thử tích hợp (Itegration testing): tích hợp các
bộ phận và hệ thống con. - Kiểm thử hệ thống (System testing): kiểm thử toàn bộ hệ thống. -
Quá trình kiểm thử Một mô hình cho quá trình kiểm thử được mô tả như hình dưới đây. Thông tin đầu vào
được cung cấp cho quá trinh kiểm thử gồm : Thông tin cấu hình của phần mềm: các thông tin này bao
gồm: mô tả về yêu cầu của phần mềm (Software Requirement Specification). Mô tả về thiết kế của chương
trình (Design Specification) và mã của chương trình. Thông tin cầu hình về kiểm thử bao gồm : kế hoạch
kiểm thử, và thủ tục kiểm thử và các chương trình chạy kiểm thử như: chương trình giả lập môi trương,
chương trình tạo các trường hợp kiểm thử… Các trương hợp kiểm thử phải đi cùng với kềt quả mong muốn,
Trong thực tế những thông tin này cũng là một phần của Thông tin cấu hình của một phần mềm ở trên. -
Testing và Debug: -Testing (Kiểm thử):- Là quá trình thực hiện các ca kiểm thử để kiểm tra xem phần
mềm có hoạt động đúng theo yêu cầu đặt ra hay không. - Ví dụ: kiểm tra chức năng đăng nhập vào ứng
dụng web bằng cách nhập đúng tên đăng nhập và mật khẩu, rồi xác nhận có vào được trang chủ hay không.-
Debug (Gỡ lỗi):- Là quá trình tìm và sửa các lỗi/sai sót trong mã nguồn dẫn đến phần mềm hoạt động không
đúng mong muốn.- Ví dụ: khi kiểm thử phát hiện chức năng đăng nhập bị lỗi, không nhập đúng mật khẩu
vẫn cho vào, lập trình viên sẽ xem xét mã nguồn đăng nhập và sửa lỗi sai sót để đảm bảo chức năng hoạt động đúng. -
Nguyên tắc kiểm thử Để hoạt động kiểm thử đạt kết quả tốt khi kiểm thử cần tuân theo các nguyên tắc sau:
• Một phần quan trọng của ca kiểm thử là xác định đầu ra hoặc kết quả mong muốn. • Lập trình viên nên
tránh tự kiểm tra chương trình của chính mình. • Nhóm lập trình viên không nên kiểm thử chương trình của lO M oARcPSD| 45467232
chính họ. Nên để một nhóm độc lập thực hiện kiểm thử. • Kiểm tra kĩ lưỡng kết quả của mỗi kiểm thử. •
Kiểm tra một chương trình để xem liệu chương trình có thực hiện cái mà nó cần thực hiện chỉ là một phần,
phần còn lại là xem liệu chương trình có thực hiện cái mà nó không cần phải thực hiện hay không. • Tránh
các ca kiểm thử không rỏ ràng trừ khi chương trình thực sự là một chương trình không rỏ ràng. • Không dự
đoán kết quả của kiểm thử theo giả thiết ngầm là không tìm thấy lỗi. • Xác suất tồn tại của các lỗi hơn nữa
trong một đơn vị phần mềm tỉ lệ với số lỗi đã tìm thấy trong đoạn đó. • Kiểm thử là một nhiệm vụ cực kì
sáng tạo và có tính đầy thử thách. -
Vai trò Vì kiểm thử phần mềm thường chiếm 40% tổng công sức phát triển và >=30% tổng thời gian phát
triển. Đối với các phần mềm có ảnh hưởng tới sinh mạng, chi phí của hoạt động này có thể gấp từ 3 đến 5
lần tổng các chi phí khác cộng lại. Chính vì vậy nếu hoạt động kiểm thử phần mềm được thực hiện tốt thì: •
Giảm chi phí phát triển phần mềm • Tăng độ tin cậy của sản phẩm phần mềm. -
Những khó khăn khi kiểm thử Nâng cao chất lượng phần mềm nhưng không vượt quá chất lượng thiết kế.
Chỉ phát hiện các lỗi tiềm tàng trong sản phẩm để sửa chữa và khắc phục chúng. Dễ bị ảnh hưởng vấn đề
tâm lí khi thực hiện quá trình kiểm thử. Vì người kiểm thử đồng thời cũng là người xây dựng phần mềm.
Khi kiểm thử chương trình ta không thể tạo ra tất cả các trường hợp kiểm thử vì đây là một số lượng vô hạn.
Vì vậy khó đảm bảo tính đầy đủ cho quá trình kiểm thử. Quá trình phát hiện lỗi bị hạn chế do hoạt động
kiểm thử được thực hiện bằng thủ công là chủ yếu. Quá trình kiểm thử sẽ khó khăn hơn khi chương trình có
bộ nhớ như hệ điều hành hoặc các ứng dụng cơ sở dữ liệu. Ví dụ trong cơ sở dữ liệu ứng dụng của hệ thống
đặt vé của hãng hàng không, việc thực hiện một giao dịch phụ thuộc vào những gì đã xảy ra trong các giao
dịch 37 trước đó. Do đó, khi kiểm thử ta phải kiểm thử tất cả các trình tự của giao dịch. Chính vì vậy quá
trình kiểm thử sẽ gặp nhiều khó khăn hơn.
-Mục tiêu của hoạt động kiểm thử Quá trình kiểm thử phần mềm gồm 2 mục tiêu cơ bản sau: • Chứng minh
cho người phát triển cũng như khách hàng thấy được các yêu cầu của phần mềm. Nghĩa là thử nghiệm tất cả các
đặc tính của hệ thống được kết hợp trong các sản phẩm. • Phát hiện các lỗi và khiếm khuyết trong phần mềm.
Chính nhờ hoạt động này mà ta tìm ra được các thực hiện không như mong đợi của hệ thống như các tính toán
sai, sai lạc dữ liệu .vv.. Tóm lại, mục tiêu của kiểm thử phần mềm là thuyết phục cho người phát triển phần
mềm và khách hàng thấy rằng phần mềm là đủ tốt cho các thao tác sử dụng. -
Các chiến lược kiểm thử: a. Kiểmthử đơn vị: Khái niệm: Kiểm thử đơn vị là quá trình kiểm thử các thành
phần riêng biệt của hệ thống, như các hàm, thủ tục, phương thức hay các lớp. Kiểm thử đơn vị được thực
hiện bởi người phát triển phần mềm, chứ không phải người kiểm thử phần mềm hay người sử dụng cuối.
Mục đích: Mục đích của kiểm thử đơn vị là so sánh các chức năng của một đơn vị với các đặc tả chức năng
hoặc giao diện xác định các đơn vị. Mục tiêu ở đây không phải là để cho thấy rằng đơn vị đáp ứng được các
đặc tả của nó, mà để thấy rằng đơn vị mâu thuẫn với đặc tả đó. Nội dung kiểm thử: Kiểm thử giao diện,
Kiểm thử cấu trúc dữ liệu cục bộ, Kiểm thử các phép xử lí, Kiểm thử các điều kiện logic, Kiểm thử dòng
điều khiển/ biên, Kiểm thử liên quan đến giá trị vào/ ra. Các kĩ thuật được sử dụng trong kiểm thử đơn vị •
Kiểm thử đường thi hành cơ bản • Kiểm thử giá trị biên • Kiểm thử vòng lặp. b. Kiểm thử tích hợp :
Kiểm thử tích hợp kết hợp các thành phần của một ứng dụng và kiểm thử như một ứng dụng đã hoàn thành.
Người thực hiện kiểm thử có thể là người lập trình, người thiết kế. Mục tiêu Hai mục tiêu chính của kiểm
thử tích hợp: • Phát hiện lỗi giao tiếp xảy ra giữa các đơn vị. • Tích hợp các đơn vị đơn lẻ thành các hệ
thống nhỏ và cuối cùng là nguyên hệ thống hoàn chỉnh chuẩn bị cho kiểm thử ở mức hệ thống. Các phương
pháp áp dụng cho kiểm thử tích hợp. -Phương pháp tích hợp trên xuống: Là quá trình kiểm thử được thực
hiện bằng cách tăng dần việc xây dựng cấu trúc chương trình. (Ưu điểm: Phát hiện sớm các lỗi thiết kế:
chính nhờ ưu điểm này nên khi phát hiện lỗi thì quá trình sửa lỗi sẽ được thực hiện dễ dàng hơn, đồng thời
cũng làm giảm giá thành sửa đổi. Có phiên bản hoạt động sớm . • Nhược điểm: Việc mô phỏng các modul
cấp thấp khó thực hiện. Không kiểm thử đầy đủ các chức năng.). -Phương pháp tích hợp dưới lên: Là quá
trình kiểm thử được bắt đầu xây dựng và kiểm thử với modul ở mức thấp nhất trong cấu trúc chương trình.(
Ưu điểm Có thể tiến hành ca kiểm thử dễ và không cần cuống. • Nhược điểm Luôn chưa có 1 chương trình lO M oARcPSD| 45467232
chỉnh thể cho đến khi modul cuối cùng được thêm vào.). -Phương pháp tích hợp hồi quy:Là quá trình kiểm
thử lại các phép thử đã thành công mỗi khi tích hợp thêm modul hoặc khi cập nhật mã nguồn chương trình.
Khi chúng ta tích hợp thêm modul vào hệ thống hoặc khi tiến hành nâng cấp chương trình thì sẽ tạo ra một
số tổ hợp trạng thái mới. Các trạng thái mới này sẽ gây ra các vấn đề như: • Xuất hiện lỗi ở modul mà trước
đó nó chưa gây ra lỗi. • Khắc phục một lỗi mới có thể làm ảnh hưởng tới lỗi mà chúng ta đã sửa trước đó. •
Sinh ra lỗi mới mà trước đây chưa có. c. Kiểm thử hệ thống:
Kiểm thử hộp đen 1.
Phân lớp tương đương: 1 ca kiểm thử hợp lệ bao gồm kết hợp tất cả các điều kiện phân
lớp tương đương hợp lệ. - ở lớp tương đương không hợp lệ, không được gộp các input đầu vào. - khi
kiểm thử 1 trường, thì tất cả các trường còn lại phải hợp lệ. - trong mỗi trường hợp kiểm tra hợp lệ hay
ko hợp lệ, đều phải đủ các trường 2.
Đồ thị nguyên nhân kết quả:- đẩu vào: nguyên nhân, phải tách nhau ra.- đầu ra: kết quả
(lấy trong đặc tả chương trình PM). - có mối quan hệ giữa các nguyên nhân với nhau
Kiểm thử hộp trắng
Đường thi hành cơ bản: -
Bước 1: Xác định các nút. Nút là các câu lệnh tuần tự, điểm kết thúc của một vòng lặp, điểm kết thúc của
một hàm. (Mới vào FUNCTION ‘{‘ nút 1, mỗi câu lệnh tuần tự là 1 nút, mỗi 1 điều kiện là 1 nút, điểm
kết thúc loop, hàm là 1 nút, ( if else do while không tính)
Bước 2: Vẽ đồ thị thể hiện đường diễn tiến của chương trình. Từ các nút đã xác định ở bước 1, xây dựng
đồ thị dòng điều khiển tương ứng. -
Bước 3: Xác định số đường kiểm thử: Số đường kiểm thử = số cạnh – số nút + 2
=> Xác định các đường kiểm thử: tập các đường độc lập tuyến tính
Bước 4: Dựa vào các trường hợp kiểm thử xác định các TestCase tương ứng
Phân lớp tương đương:
a) Xác định các lớp tương đương: Các giá trị
Lớp tương đương hợp lệ
Lớp tương đương không đầu vào hợp lệ maHocSinh
Kiểu String có độ dài 10 ,không chứa ký - có độ dài > 10 (6)
tự đặc biệt , không nul (1)
- chứa ký tự đặc biệt (7) - null (8) maMonHoc
Kiểu String có độ dài 7, không chứa ký - có độ dài > 7 (9)
tự đặc biệt, không nul (2)
- chứa ký tự đặc biệt (10) - null (11) ……. ………..
b) Xác định các ca kiểm thừ: 1.
Ca kiểm thử cho dữ liệu đầu vào hợp lệ: (1), (2), (3), (4), (5) maHocSinh = "21T1021234" maMonHoc = "TIN4953" maHocKy = "HocKy1" maNamHoc = "NH2023" maLop = "CNTTK45A" 2.
Ca kiểm thử cho dữ liệu đầu vào không hợp lệ:
(7): mã sinh viên chưa ký tự đặc biệt maHocSinh = "@123JQK" maMonHoc = "TIN4953" …
(13): mã học kỳ chưa ký tự đặc biệt lO M oARcPSD| 45467232 maHocKy = "!@#$%^&" maNamHoc = "NH2023" maLop = "CNTTK45A" ….
Câu 2: Khái niệm kiểm thử bằng phương pháp đồ thị nguyên nhân kết quả. Cách thức để xác định các ca
kiểm thử của phương pháp này.
Đồ thị nguyên nhân-kết quả hỗ trợ cho việc lựa chọn một cách có hệ thống tập các ca kiểm thử có hiệu quả
cao. Nó tác động tới việc chỉ ra các tình trạng chưa đầy đủ hoặc nhập nhằng trong đặc tả. Ngoài ra nó còn cung
cấp cách biểu diễn chính xác cho các điều kiện logic và hành động tương ứng.
Các bước được sử dụng để xây dựng các test-case sử dụng đồ thị nguyên nhân – kết quả: 1.
Đặc tả được chia thành các phần có thể thực hiện được. Điều này là cần thiết vì kĩ thuật này sẽ khó sử
dụng khi được sử dụng trên những đặc tả quá lớn 2.
Nguyên nhân và kết quả trong đặc tả được nhận biết. Một nguyên nhân là một trạng thái đầu vào nhất
định hoặc cũng có thể là một lớp tương đương của các trạng thái đầu vào. Một kết quả là một trạng thái đầu ra
hoặc một sự biến đổi hệ thống nào đó. Để nhận biết các nguyên nhân và kết quả bạn phải đọc phần đặc tả, sau
đó gạch chân các từ hoặc cụm từ mô tả nguyên nhân và kết quả. Khi đó mỗi nguyên nhân và kết quả này sẽ
được gán bởi một số duy nhất. 3.
Xây dựng đồ thị nguyên nhân-kết quả bằng cách phát triển và biến đổi nội dung ngữ nghĩa của đặc tả
thành đồ thị Boolean nối giữa nguyên nhân và kết quả. 4. Chuyển đồ thị thành một bảng quyết định mục vào
giới hạn.Mỗi cột trong bảng mô tả một ca kiểm thử.
5. Các cột trong bảng quyết định được chuyển thành các ca kiểm thử.
Câu 3 : Phương pháp phân lớp tương đương là 1 phương pháp kiểm thử hộp đen dựa trên nguyên tắc chia
miền đầu vào của một chương trình thành các lớp dữ liệu, để từ đó lập ra các ca kiểm thử theo mỗi lớp đó. Mục
tiêu của phương pháp này là tìm ra 1 ca kiểm thử mà làm lộ ra 1 lớp lỗi. Vì vậy sẽ giảm tổng số các trường hợp
kiểm thử phải được xây dựng. Thiết kế ca kiểm thử cho phân lớp tương đương dựa trên sự đánh giá về các lớp
tương đương với 1 điều kiện nào đó. Lớp tương đương biểu thị cho tập trạng thái hợp lệ (tập trạng thái mô tả
các đầu vào hợp lệ của chương trình) hay không hợp lệ (tập trạng thái mô tả tất cả các trạng thái có thể khác của
điều kiện) đối với các điều kiện vào. Chẳng hạn như thông tin về tên của một người Việt, lớp tương đương hợp
lệ bao gồm tập các tên riêng tiếng việt hợp lệ có độ dài từ 1 đến 7 kí tự. Lớp tương đương không hợp lệ là tập
các tên riêng không có trong tiếng Việt hoặc được viết bằng số hay kí tự đặc biệt.
Thiết kế trường hợp thử bằng lớp tương đượng được tiến hành theo 2 bước:
1. Xác định các lớp tương đương
Các lớp tương đương được xác định bằng cách lấy mỗi trạng thái đầu vào và phân chia nó thành 2 hay nhiều
nhóm. Các nhóm này có thể là các lớp tương đương hợp lệ, các lớp tương đương không hợp lệ,...Với 1 đầu vào
hay 1 điều kiện bên ngoài đã cho, việc xác định các lớp tương đương hầu như là một quy trình mang tính kinh
nghiệm. Để xác định các lớp tương đương có thể áp dụng theo các nguyên tắc sau: 1.
Nếu 1 trạng thái đầu vào định rõ giới hạn của các giá trị, xác định 1 lớp tương đương hợp lệ và 2 lớp
tương đương không hợp lệ. 2.
Nếu 1 trạng thái đầu vào xác định số giá trị, xác định 1 lớp tương đương hợp lệ và 2 lớp tương đương bất hợp lệ. 3.
Nếu 1 trạng thái đầu vào chỉ định một tình huống “chắc chắn”, xác định 1 lớp tương đương hợp lệ và 1
lớp tương đương không hợp lệ. Nếu chương trình xử lí các phần tử trong cùng một lớp là khác nhau thì phải
chia lớp tương đương đó thành các lớp tương đương nhỏ hơn.
2. Xác định các ca kiểm thử
Với các lớp tương đương được xác định ở bước trên, bước tiếp theo là dựa vào các lớp tương đương đó để xác
định các ca kiểm thử. Quá trình này được thực hiện như sau:
1. Gán 1 số duy nhất cho mỗi lớp tương đương. lO M oARcPSD| 45467232
2. Cho đến khi tất cả các lớp tương đương hợp lệ được bao phủ bởi các ca kiểm thử, viết 1 ca kiểm thử mới
baophủ càng nhiều các lớp tương đương đó chưa được bao phủ càng tốt .
3. Cho đến khi các ca kiểm thử của bạn đã bao phủ tất cả các lớp tương đương không hợp lệ, viết 1 ca kiểm
thửbao gồm 1 và chỉ 1 trong các lớp tương đương không hợp lệ được bao phủ. Câu 4-Module: lO M oARcPSD| 45467232
B1. Ta có chương trình P và được đánh dấu các ký hiệu như trên.
B2. Đầu vào {A}, đầu ra {B} theo đề bài ra. Ta cần chứng tỏ {A} P {B}
B3. Dự trù {C} là bất biến của đoạn trình Q1 trong điều kiện E2
B4. Cần có {A} if E1 then P1;P2;P3;{C}, thì chứng minh: i, {A, E1} P1, P2, P3 {C}
Có {A, E1} P1 {A} và {A} P2 {A} và {A}
P3 {C} ii, {A, !E1} P2, P3 {C}
Có {A, !E1} P2 {A} và {A} P3 {C}
Do đó {A} if E1 then P1;P2;P3; {C}
B5. Để chứng minh {C} là bất biến của đoạn trình Q1 ta cần có {C,
E2} if E3 then P3 else P4; Q2 {C} 5.1 Dự trù {D} là bất biến của
đoạn trình Q2 trong điều kiện E4.
5.2 Chứng minh {C, E2 } if E3 then P3 else P4; {D} i, {C, E2, E3} P3 {D} ii, {C, E2, !E3} P4 {D}
Do đó {C, E2 } if E3 then P3 else P4; {D}
5.3 Chứng minh {D, E4} P5,x=F1 {D}
Theo tính chất phép gán ta có: {D1} ≡ {D[x| F1]} Ta lại có: {D, E4} P5 {D1}
Vậy {D} là bất biến của Q2. Nên kết thúc Q2, ta có mệnh đề {D, !E4}. 5.5 Có {D, !E4}
5.6 Theo logic ta có {D, !E4} =>L {C}
5.7 Do đó {C} là bất biến của Q1. Kết thúc Q1, ta có mệnh đề {C, !E2} B6. Có {C, !E2}
B9. Để chứng tỏ {G} là bất biến
B7. Dự trù {G} là bất biến của đoạn trình Q3 trong điều
của đoạn trình Q3. Ta cần có {G, kiện E2.
E3} y = F2;if E4 then P5 else P3;
B8. Cần có {C, !E2} if E1 then P1 else P2; {G}
{G} i, {C, !E2, E1} P1 {G} ii, {C, !E2, !E1} P2
Theo tính chất phép gán ta {G} có: {G } ≡ {G[y|F2]}
Suy ra: {C} if E1 then P1 else P2; {G} 1
Cần chứng tỏ: {G, E3} if E4 then P5 else P3; {G1} Dễ dàng ta có: i, {G, E3, E4} P5 {G1}. ii, {G, E3, ! E4} P3 {G1}
Vậy {G} là bất biến của Q3.
Nên kết thúc Q3 ta có mệnh đề {G, !E3}
B10. Dễ dàng ta có {G, !E3} =>L {B}
Vậy {A} P {B} , hay đoạn trình trên là đúng Câu 5: Sắp xếp chọn lO M oARcPSD| 45467232 -
Gọi mệnh đề thể hiện tính chất dữ liệu vào là
{A} và mệnh đề thể hiện tính chất dữ liệu ra cần có {B}, ta có:
{A: a ∈ R; n ∈ N; Array(n) = a; n = Count(a); a … 1 an;}
{B: a ∈ R; n ∈ N; Array(n) = a; n = Count(a); a …a 1 n; a=Selection_Sort(a, n)} -
Mệnh đề bất biến {C: a ∈ R, i, j, t ∈ N; a …a 1 n} - Ta có {A} i=0;{C} -
Để chứng tỏ {C} là bất biến của đoạn trình Q1
trong điều kiện E1 (iTrong đoạn trình Q2:
+Dự trù {C2} là bất biến của đoạn trình Q2 trong
điều kiện E2 (j+Ta có {C} j=i+1 {C2}
+Ta cần chứng minh {C2,E2,E3} P1 {C2}
+Theo tính chất phép gán ta có: {C2 }≡{C2[a[j]|t]]: a ∈ …a 1 R; i,j,t∈N; a1 n;a[j]=t;} {C2 }≡{C2 … 2
1[a[i]|a[j]]:a∈R;i,j, t∈N;a1 an;a[j]=t;a[i]=a[j];} {C2 }≡{C2 3
2[t|a[i]]:a∈R;i,j, t∈N; a[j]=t; a[i]=a[j];t=a[i];}
+Ta có: {C2,E2,E3}=>L{C2 }, kết thúc ta được 3
{C2,E2,!E3}=>L{C2}. Suy ra {C2} là bất biến của Q2
+Ta có: {C2,!E2}=>L{C}. Kết thúc ta có
{C,E1}=>L{C}. Suy ra {C} là bất biến của Q1. Ta được {C, !E1}. Ta có {C,!E1}
- Dễ dàng chứng tỏ {C,!E1} =>L {B}
Vậy ta có {A} P {B}, hay đoạn chương trình trên là đúng.
Câu 6: Tìm kiếm nhị phân lO M oARcPSD| 45467232 -
Gọi mệnh đề thể hiện tính chất dữ liệu
vào của đoạn chương trình là {A}, mệnh đề thể
hiện tính chất dữ liệu ra cần có là {B}:
{A: a ∈ R; n ∈ N; Array(n) = a; Count(a) = n;
a1...an; x ∈ R; vitri, l, r ∈ N}
{B: a ∈ R; n ∈ N; Array(n) = a; Count(a) = n;
a1...an; x ∈ R; vitri, l, r ∈ N; vitri = TimKiemNP(a, n, x)} -
Với {C: k, l, r ∈ N, x ∈ R, vitri ∈ N;} là mệnh đề bất biến -
Chứng minh {A} int vitri=-1, k, l=0, r=n-1; {C}
Theo tính chất phép gán ta có: {C } ≡ {C[r|n 1
-1]: k, l, r ∈ N, x ∈ R, vitri ∈ N; r=n-1;} {C } ≡ {C 2
1[l|0]: k, l, r ∈ N, x ∈ R, vitri ∈ N; r=n-1; l=0;} {C } ≡ {C 3
2[vitri|-1]: k, l, r ∈ N, x ∈ R, vitri ∈ N; r=n-1; l=0; vitri = -1;}
Dễ dàng ta có {A}=>L {C3}
Do đó {A} int vitri=-1, k, l=0, r=n-1; {C} -
Để chứng tỏ {C} là bất biến của đoạn
trình Q trong điều kiện E (l <= r) ta cần chứng minh: {C, E} Q2 {C}
Theo phép gán, ta có {C } ≡ {C 4
3[k|(l+r)/2]: k, l, r ∈ N, x ∈ R, vitri ∈ N; r=n-1; l=0; vitri = -1; k=(l+r)/2;}
Nên cần chứng tỏ {C, E} P1 {C }, với P1 là đoạn trình 4 if(x==a[k]) {vitri E = k; break;} Else if(xE r=k-1; else l=k+1;
Dễ dàng ta có: i, {C, E, E1} vitri = k; break; {C4}
ii, {C, E, !E1, E2} r = k -1; {C4}
iii, {C, E, !E1, !E2} l = k+1; {C4}
Vậy {C} là bất biến của Q. Nên kết thúc Q, ta có mệnh đề {C, !E}.
- Dễ dàng chứng tỏ: {C, !E} =>L {B}
Vậy ta có {A}P{B}, hay chương trình trên là đúng.
Vẽ đồ thị chỉ ra các đường diễn tiến cần kiểm thử lO M oARcPSD| 45467232 lO M oARcPSD| 45467232
Câu 7: Sắp xếp tuần tự -
Gọi mệnh đề thể hiện tính chất dữ liệu vào
của đoạn chương trình là {A}, và mệnh đề thể hiện
tính chất dữ liệu ra cần có là {B}, ta có:
-{A: n ∈ N; a ∈ R; Array(n) = a, Count(a) = n; a , … 1
an; x ∈ R; vitri ∈ N}
-{B: n ∈ N; a ∈ R; Array(n) = a, Count(a) = n; a1,
… an; x ∈ R; vitri ∈ N; vitri = TimKiemTT(a, n, x)}
- Mệnh đề bất biến {C: k ∈ N, x ∈ R, vitri ∈ N;} -
Chứng minh{A} int vitri = -1; int k =
0;{C} -Theo tính chất phép gán ta có: -{C } ≡ {C[k|0]: k ∈ 1
N, x ∈ R, vitri ∈ N; k=0} - {C } ≡ {C 2
1[vitri|-1]: k ∈ N, x ∈ R, vitri ∈ N; k=0; vitri=-1}
Dễ dàng ta có {A}=>L {C2}
Suy ra {A} int vitri = -1; int k = 0;{C}
- Để chứng tỏ {C} là bất biến của đoạn trình Q trong điều kiện E (kk++; {C}
Theo tính chất phép gán ta có: {C } ≡ {C 3
2[k|k+1]: k ∈ N, x ∈ R, vitri ∈ N; k=k+1; vitri=-1}
Nên cần chứng tỏ: {C, E} if(a[k]==X)vitri = k;{C3}
Trong đó ta có: i, {C, E, a[k]==X} vitri = k;{C3}
ii, {C, E, !a[k]==X} =>L {C3}
Vậy {C} là bất biến của Q. Nên kết thúc ta có mệnh đề {C, !E}
- Dễ dàng chứng tỏ {C, !E} =>L {B}
Vậy ta có {A} P {B} hay đoạn trình trên là đúng.
Vẽ đồ thị chỉ ra các đường diễn tiến cần kiểm thử
Câu 8: SACH Bảng dữ liệu lO M oARcPSD| 45467232
SACH(MASACH, TENSACH, TACGIA, NAMXB)
SACH ORDER BY NAMXB, TENSACH ASC
Thêm mới một cuốn sách vào bảng SACH yêu cầu người dùng nhập dữ liệu trên giao diện của hệ thống. Từ bài toán ta có: Nguyên nhân là: 1.
MASACH là dữ liệu vào khác rỗng. 2.
Dữ liệu vào của MASACH không chứa ký tự đặc biệt 3.
Dữ liệu vào của MASACH chưa tồn tại trong bảng. 4.
TENSACH là dữ liệu vào khác rỗng. 5.
TACGIA là dữ liệu vào khác rỗng. 6.
Dữ liệu vào của TACGIA không chứa ký tự đặc biệt hoặc chữ số. 7.
NAMXB là dữ liệu khác rỗng. 8.
NAMXB là chữ số và không chứa ký tự đặc biệt. 9.
Dữ liệu vào của NAMXB là số nguyên dương. Kết quả là:
R1. Thông báo “Mã sách không được để trống”.
R2. Thông báo “Mã sách không hợp lệ”.
R3. Thông báo “Mã sách đã tồn tại.”
R4. Thông báo “Tên sách không được để trống”.
R5. Thông báo “Tên tác giả không được để trống”.
R6. Thông báo “Tên tác giả không hợp lệ”.
R7. Thông báo “Năm xuất bản không được để trống”.
R8. Thông báo “Năm xuất bản không hợp lệ”.
R9. Thông báo “Năm xuất bản phải là số nguyên dương.”
R10. Hệ thống thêm mới một cuốn sách vào cơ sở dữ liệu và cập nhật lại bảng dữ liệu được sắp xếp theo Năm
xuất bản và Tên tác giả. BẢNG QUYẾT ĐỊNH lO M oARcPSD| 45467232 1 2 3 4 5 6 7 8 9 10 1 0 1 2 0 1 3 0 1 4 0 1 5 0 1 6 0 1 7 0 1 8 0 1 9 0 1 R1 1 0 0 0 0 0 0 0 0 0 R2 0 1 0 0 0 0 0 0 0 0 R3 0 0 1 0 0 0 0 0 0 0 R4 0 0 0 1 0 0 0 0 0 0 R5 0 0 0 0 1 0 0 0 0 0 R6 0 0 0 0 0 1 0 0 0 0 R7 0 0 0 0 0 0 1 0 0 0 R8 0 0 0 0 0 0 0 1 0 0 R9 0 0 0 0 0 0 0 0 1 0 R10 0 0 0 0 0 0 0 0 0 1
BẢNG CÁC TRƯỜNG HỢP KIỂM THỬ ST Các điều kiện Các ca kiểm thử Hành động T 1
Mã sách là dữ liệu rỗng Mã sách: “” R1 2
Mã sách chứa ký tự đặt biệt Mã sách: “£@$£@%£$”. R2 3
Mã sách nhập vào đã tồn tại trong
Trong bảng đã có dữ liệu Mã sách R3 bảng = “MS001”. Mã sách: “MS001” 4
Tên sách là dữ liệu rỗng Tên sách: “” R4 5
Tác giả là dữ liệu rỗng Tác giả: “” R5 lO M oARcPSD| 45467232 6
Tác giả chứa ký tự đặc biệt và chữ Tác giả: “Nguyễn @£! 213” R6 số 7
Năm xuất bản là dữ liệu rỗng Năm xuất bản: “” R7 8
Năm xuất bản không phải là chữ
Năm xuất bản: “!@£@!” R8
số và chứa ký tự đặc biệt 9
Năm xuất bản là số âm Năm xuất bản: -2017 R9 10
Mã sách là một chuỗi ký tự, chỉ Mã sách: “MS002” R10
bao gồm chữ cái và chữ số,
Tên sách: “Hạt giống tâm hồn”
phải bắt đầu bằng chữ cái có độ
dài giới hạn quy định và chưa
Tác giả: “Nguyễn Văn Mã” tồn tại Năm xuất bản: “2017” -
Tên sách một chuỗi ký tự,
chỉ bao gồm ký tự chữ, ký tự số và
có thể có ký tự đặc biệt, có độ dài
thuộc giới hạn quy định -
Tác giả một chuỗi ký tự,
chỉ bao gồm ký tự chữ, có khoảng
trắng và có độ dài thuộc giới hạn quy định. -
Năm xuất bản là một chuỗi
ký tự dạng số và là số nguyên dương Câu 3
Bước 1: Ta có đoạn chương trình P sau: P1; if E1 then P1 else { while E5 do P4; P6; } while E2 do { P3; While E3 do P4; if E4 then x := F3; } P2; while E2 do { x1 := F4; P2; } x1 := F1; x2 := F3;
Bước 2: Ta có đầu vào {A} và đầu ra {B}. Ta cần chứng tỏ {A} P {B}
Bước 3: Dự trừ {C} là bất biến của đoạn trình: While E2 do { P3; while E3 do P3; if E4 then x := F3; lO M oARcPSD| 45467232 } Với điều kiện E2
Bước 4: Ta cần chứng minh {A} P1; if E1 then P1 else { while E5 do P4; P6; } {C}
Dự trù D là bất biến của đoạn trình: while E5 do P4; với điều kiện
E5 Mà ta có Q1 là đoạn trình while E5 do P4; P6 Ta có:
Cần có {A} P1; if E1 then P1 else Q1; {C} thì chứng minh
• {A} P1 {A’} và {A’, E1} P1 {C}
• {A} P1 {A’} và {A’, !E1} Q1 {C} ta cần chứng tỏ {A, !E1} Q1 {C} o Chứng tỏ: {A, !E1, E5}
P4 {D} o Có {A, !E1, !E5} o {A, !E1, !E5} P6 {C} nên {A, !E1} =>L {C}
• Vậy ta có thể nói rằng {A, !E1} Q1 {C} Để chứng tỏ {C}bất biến qua đoạn trình while E2 do { P3; while E3 do P4; if E4 then x := F3; }
Ta cần chứng tỏ: {C, E2} P3; while E3 do P4; if E4 then x := F3; {C} Ta có:
• {F} là dự trù của đoan chương trình while E3 do P4 với điều kiện E3 • Ta có {C, E2}P3{F}
• Ta có cần chứng tỏ: {F, E3} P4 {F} • Có {F, !E3} • {F, !E3, E4} x:= F3 {C} • {F, !E3, !E4} =>L{C}
Do đó: {C, E2} P3; while E3 do P4; if E4 then x := F3; {C} Bước 5: Có {C, !E2}
Bước 6: Dự trù {G} là bất biến của đoạn chương trình sau while E2 do { x1 := F4; P2; } Với điều kiện E2
Bước 7: Để chứng minh {G} là bất biến của đoạn chương trình while E2 do {x1 := F4; P2} Ta cần có: {C, !E2} P2 {G}
Ta có chứng minh{G, E2} x1 := F4; P2; {G}
• {G} P2 {G’} và {G’[x|F4]} = {G1}
Mà {G1} => L {G} nên {G, E2} => L {G} Do đó {G, E2} x:=F4; P2 {G} Bước 7: Có {G, !E}
Bước 8: Ta chứng tỏ {G, !E} x1: F1, x2:=F3
{B} Theo tính chất của phép gán: {B[x2|F3]} = {B1} • {B1[x1|F1]} = {B2}
Do đó{B2} => L {B} nên {G, !E} => L {B}
Vậy {A} =>L {B} nên {A} P {B} lO M oARcPSD| 45467232
Kiểm thử phần mềm
Trường hợp thử (Test case):
Nhiệm vụ của kiểm tra phần mềm
Mục tiêu kiểm thử
Các loại kiểm thử và phân loại vòng
đời của kiểm thử PM:
Sơ lượt các kỹ thuật và phân loại kiểm thử phần mềm
Quá trình kiểm thử Testing và Debug:
Nguyên tắc kiểm thử Vai trò
Những khó khăn khi kiểm thử Mục
tiêu của hoạt động kiểm thử Các
chiến lược kiểm thử:
Kiểm thử hộp đen Kiểm thử hộp trắng
Phân lớp tương đương:
Khái niệm kiểm thử bằng phương pháp đồ thị nguyên nhân kết quả. Cách thức để xác định các ca kiểm
thử của phương pháp này.
Phương pháp phân lớp tương đương VD Module Sắp xếp chọn
Tìm kiếm nhị phân
Vẽ đồ thị chỉ ra các đường diễn tiến cần kiểm thử
Sắp xếp tuần tự