2. 2
Nội dung
Vòng đời phát triển phần mềm (SDLC)
Giai đoạn phát triển phần mềm
Yêu cầu
Kiểm thử và các yêu cầu
Học suy nghĩ như một tester
Một số ví dụ
Viết yêu cầu kiểm thử
3. 3
Vòng đời phát triển phần mềm
Software Development Life Cycle
(SDLC)
4. 4
Vòng đời phát triển phần mềm
(SDLC)
SDLC là một cách tiếp cận có kỷ luật và có hệ
thống phân chia quá trình phát triển phần mềm
thành các giai đoạn khác nhau, chẳng hạn như
thiết kế, yêu cầu, và mã hóa
Quá trình phát triển phần mềm theo các giai đoạn
giúp bạn theo dõi tiến độ, chi phí và chất lượng
của các dự án phần mềm
5. 5
Vòng đời phần mềm(SDLC)
Có sáu giai đoạn của SDLC:
Giai đoạn phân tích tính khả thi bao gồm việc phân tích các yêu
cầu dự án.
Giai đoạn phân tích và đặc tả yêu cầu bao gồm thu thập, phân
tích, thẩm định, và đặc tả yêu cầu.
Giai đoạn thiết kế bao gồm việc biên dịch các yêu cầu xác định
trong SRS thành một cấu trúc logic mà có thể được thực hiện
trong một ngôn ngữ lập trình.
Giai đoạn mã hóa bao gồm việc cài đặt thiết kế đặc tả trong các
tài liệu thiết kế thành mã thực thi trên một ngôn ngữ lập trình cụ
thể.
Giai đoạn kiểm thử bao gồm phát hiện lỗi trong phần mềm.
Giai đoạn bảo trì bao gồm thực hiện các thay đổi và yêu cầu mới
trong phần mềm tại vị trí của khách hàng.
6. 6
Các mô hình SDLC
Là một hình thức phù hợp của các giai đoạn
SDLC.
Cung cấp một cơ sở để phân loại và kiểm
soát các hoạt động khác nhau cần thiết để
phát triển và bảo trì hệ thống phần mềm
Loại điển hình của mô hình SDLC
Mô hình tuyến tính
Mô hình lặp
7. 7
Mô hình tuyến tính
Mô hình tuyến tính phù hợp cho các dự án
mà tất cả các yêu cầu được xác định và hiểu
rõ trước khi thiết kế của phần mềm bắt đầu.
Hai loại mô hình tuyến tính là:
mô hình thác nước
mô hình nguyên mẫu
8. 8
Mô hình thác nước
Mô tả quá trình phát triển phần mềm theo luồng
trình tự tuyến tính.
Xác định quá trình phát triển phần mềm trong
bảy giai đoạn:
Khái niệm
bắt đầu
Phân tích
Thiết kế
Xây dựng
Tích hợp và kiểm thử
Triển khai và bảo trì
10. 10
Mô hình nguyên mẫu
Là một cài đặt mẫu của hệ thống cho thấy
hạn chế và khả năng chức năng chính của
hệ thống được đề xuất.
Giúp khách hàng xác định các tính năng này
sẽ hoạt động trong các phần mềm cuối cùng.
12. 12
Mô hình lặp
Mô hình lặp được sử dụng khi yêu cầu cho
phần mềm có khả năng phát triển trong suốt
quá trình phát triển.
Các loại khác nhau của mô hình lặp
Mô hình xoắn ốc
Mô hình phát triển dựa trên thành phần
Quy trình hợp nhất
13. 13
Mô hình xoắn ốc
Bao gồm các tính chất lặp đi lặp lại của mô hình
nguyên mẫu và tính chất tuyến tính của mô hình
thác nước.
Lý tưởng cho phát triển phần mềm được phát
hành trong các phiên bản khác nhau.
Sáu giai đoạn của mô hình xoắn ốc là:
Giao tiếp khách hàng
Lập kế hoạch
Phân tích rủi ro
Kỹ thuật
Xây dựng và phát hành
khách hàng đánh giá
15. 15
Mô hình phát triển dựa trên
thành phần
Trong một mô hình phát triển dựa trên thành
phần:
Các thành phần được tái sử dụng và kết hợp với các
thành phần khác trong cùng một máy tính khác hoặc
trong máy tính khác trong một mạng lưới phân phối
để tạo thành một ứng dụng.
Tất cả các mô-đun có liên quan hình thành nên một
thành phần được kiểm tra để đảm bảo rằng họ làm
việc cùng nhau
16. 16
Ưu điểm: Các mô hình tuyến
tính
Yêu cầu là trong tay của các kiểm thử viên
sớm
Dự án được thiết kế tốt hơn, tập trung tốt
hơn
Thay đổi muộn cho các yêu cầu hoặc thiết kế
được giới hạn
Nhiệm vụ kiểm tra lịch biểu, lập kế hoạch, vv,
được thực hiện dễ dàng hơn
17. 17
Ưu điểm: Mô hình lặp
Một sản phẩm có thể bản giao là sớm sẵn
sàng
Tiến độ ("chúng ta đang ở đâu?") Là dễ theo
dõi
Nhiều cơ hội để thẩm định lại các yêu cầu
hoặc xem xét lại thiết kế
Dễ dàng bỏ qua các tính năng
18. 18
Nhược điểm: Mô hình tuyến
tính
Quyết định lớn phải được thực hiện sớm
Không biết những gì sẽ là khó khăn để thực
hiện
Thay đổi một đặc điểm kỹ thuật ảnh hưởng
đến tất cả mọi người
Áp lực lớn cho các kiểm thử viên để chứng
minh rằng sản phẩm là không sẵn sàng cho
phát hành
19. 19
Nhược điểm: Mô hình lặp
Sản phẩm thiết kế có thể trở thành một nút cổ chai
Sản phẩm thường phân phối với một nửa các tính năng
thiếu
Sự cám dỗ lớn cho các nhà phát triển viết mã mới chứ
không phải là sửa chữa những gì bị hỏng
Thiếu quy hoạch sớm có thể gây ra vấn đề khi các tính
năng sau được thêm vào
Làm thế nào để tiếp thị sản phẩm?
Liên tục thực thi lại cùng các kiểm thử
Vòng đời sản phẩm dài
20. 20
Ảnh hưởng trên kiểm thử: Mô
hình tuyến tính
Các yêu cầu phải được xem xét sớm
Kế hoạch kiểm thử có thể được viết sớm
Khi kiểm thử hệ thống bắt đầu, bạn đang trên
đường dẫn tới hạn
21. 21
Ảnh hưởng trên kiểm thử: Mô
hình lặp
Kiểm thử bắt đầu ngay sau khi mức độ đầu
tiên của chức năng đạt được
Kế hoạch thử nghiệm được viết như cách
bạn đi
Yêu cầu thay đổi thiết kế có thể được dễ
dàng hơn
23. 23
Các giai đoạn phát triển phần
mềm
Kế hoạch dự án / sản phẩm
Yêu cầu và thiết kế
mã hoá và tài liệu
Kiểm thử và sửa lỗi
Bảo trì và nâng cao
24. 24
Tại sao dự án bị hủy bỏ
Nhân tố khiếm khuyết % của Responses
1. Không đầy đủ yêu cầu 13,1%
2. Thiếu sự tham gia người dùng 12,4%
3. Thiếu Tài nguyên 10,6%
4. Kỳ vọng không thực tế 9,9%
5. Thiếu Hỗ trợ thực thi 9,3%
6. Thay đổi Yêu cầu & đặc tả 8,7%
7. Thiếu kế hoạch 8,1%
8. Không cần nó dài hơn 7,5%
9. Thiếu quản lý CNTT 6,2%
10. Thiếu Công nghệ 4.3%
Loại khác 9,9%
25. 25
Tại sao dự án bị thách thức?
Nhân tố thách thức của dự án % of Responses
1.Thiếu đầu vào của người dùng 12,8%
2. Yêu cầu và đặc tả không đầy đủ 12,3%
3. Thay đổi Yêu cầu & đặc tả 11,8%
4. Thiếu Hỗ trợ thực thi 7,5%
5. Thiếu năng lực về công nghệ 7,0%
6. Thiếu Tài nguyên 6,4%
7. Kỳ vọng không thực tế 5,9%
8. Mục tiêu không rõ ràng 5,3%
9. Khung Thời gian không thực tế 4,3%
10. Công nghệ mới 3,7%
Loại khác 23,0%
26. 26
Tại sao dự án hoàn thành
Project Success Factors % of Responses
1. Người sử dụng sự tham gia 15,9%
2. Hỗ trợ quản lý thực thi 13,9%
3. Phát biểu Yêu cầu rõ ràng 13,0%
4. Kế hoạch hợp lí 9,6%
5. Kỳ vọng thực tế 8,2%
6. Mốc dự án nhỏ hơn 7,7%
7. Nhân viên giỏi 7,2%
8. Quyền sở hữu 5,3%
9. Tầm nhìn & Mục tiêu rõ ràng 2,9%
10. Làm việc chăm chỉ, nhân viên tập trung 2,4%
Loại khác 13,9%
27. 27
Các yêu cầu phần mềm
Theo lý thuyết công nghệ phần mềm, các yêu
cầu phần mềm chứa một danh sách hữu hạn
các hành vi và các tính năng, và mỗi yêu cầu
phải được kiểm chứng.
Với một danh sách hữu hạn các yêu cầu và
tập ràng buộc, kiểm thử dựa trên yêu cầu trở
thành một qui trình có tính khả thi.
28. 28
Các yêu cầu đặc trưng
Chức năng - làm những gì tôi cần?
Khả dụng - nó dễ dàng để làm những gì tôi
cần?
Độ tin cậy - có thể làm những gì tôi cần khi
tôi cần nó?
Hiệu suất - làm những gì tôi cần trong một
khoảng thời gian hợp lý?
Supportability – hỗ trợ cái gì nếu KHÔNG
làm những gì tôi cần?
29. 29
Yêu cầu chức năng
chính xác
Mức độ mà một chương trình đáp ứng các chi tiết
kỹ thuật của nó và đáp ứng mong đợi của khách
hàng
Tính năng / khả năng
Tổng quát
an ninh
Mức độ truy cập vào phần mềm hoặc dữ
liệu của người trái phép có thể được kiểm
soát
30. 30
Yêu cầu khả dụng
Dễ sử dụng
Các biện pháp nỗ lực cần thiết để tìm hiểu, vận
hành, chuẩn bị đầu vào, và giải thích đầu ra của
một chương trình
"Trực quan”
Nhân tố con người
Tính nhất quán
Tài liệu
31. 31
Yêu cầu độ tin cậy
Tần số và mức độ nghiêm trọng của thất bại
– MTBF
khả năng phục hồi
Khả năng dự đoán
Độ chính xác
32. 32
Yêu cầu hiệu năng
Tốc độ
Hiệu quả
tài nguyên tiêu thụ
thông lượng
Thời gian đáp ứng
33. 33
Yêu cầu hỗ trợ
Khả năng kiểm thử
Khả năng thích nghi
Bảo trì
Nỗ lực cần thiết để xác định vị trí và sửa chữa
các lỗi
Khả năng giúp đỡ
Nỗ lực cần thiết để sửa đổi / cập nhật một
chương trình
Khả năng cài đặt
Khả chuyển
35. 35
Các yêu cầu kiểm thử
Thông thường thực hiện bằng cách xem xét
Có hoàn thành?
Có hợp lý không?
Có thể được kiểm tra?
36. 36
Kiểm thử các yêu cầu
Xác định tất cả các yêu cầu có thể kiểm thử
Xác định tất cả các yêu cầu không thể kiểm
thử được
Viết và thực hiện các bài kiểm thử
37. 37
Xét duyệt các yêu cầu phần
mềm
Tìm hiểu để nhận ra những gì chưa được
quy định (giới hạn, hậu quả)
Tìm hiểu để nhận ra những gì là mơ hồ hoặc
không rõ ràng ("đôi khi", "nhanh hơn“)
Là một kiểm thử viên:
Hãy chắc chắn rằng các kiểm thử viên được bao
gồm trong các ý kiến!
Nỗ lực để có được yêu cầu làm rõ
Hãy luôn suy nghĩ "tôi sẽ thử điều này như thế
nào ?“
38. 38
Xét duyệt thiết kế
Giúp xác định làm thế nào để kiểm tra
Cho thấy những gì cần tìm
Bạn cần phải đọc mã không?
39. 39
Một số ví dụ
Một số phát biểu yêu cầu
Một số ví dụ “Test Cases”
40. 40
Ví dụ yêu cầu 1
Sau khi nhiệt độ cao được phát hiện, báo
động phải được nâng lên một cách nhanh
chóng
41. 41
Các yêu cầu có thể kiểm thử:
VD. 1
Nếu nhiệt độ ngưỡng đã đạt được, cảnh báo
được kích hoạt.
Nếu là nhiệt độ vẫn dưới ngưỡng nhiệt độ,
cảnh báo không được kích hoạt.
Nếu nhiệt độ xuống dưới ngưỡng (đã ở trên
nó), cảnh báo ngừng / không ngừng.
42. 42
Ví dụ yêu cầu 2
người dùng chưa thành thạo sẽ có thể tìm
hiểu giao diện với huấn luyện nhỏ
Khi nghĩ về một thử nghiệm cho vấn đề này,
hãy tự hỏi: Điều gì sẽ là tiêu chí để nói rằng
các kiểm thử thông qua? thất bại?
43. 43
Ví dụ yêu cầu 3
Có một yêu cầu "ẩn“ trong tính năng thay đổi
này:
"Tùy chọn trình đơn '6. Utilities | 1. Security‟
sẽ hiển thị một menu con mới chứ không
phải là một hộp thoại bảo mật. Trình đơn phụ
sẽ có 3 mục - '1. CSM ', '2. CIS, '3. Options '.
“
44. 44
Ví dụ yêu cầu 4
Có bao nhiêu yêu cầu có thể kiểm chứng được
ở đây?
“Sự lựa chọn Access Profile cho '2. CIS 'và
'3. Options„ sẽ được chuyển sang màu xám
trừ khi những tùy chọn đã được mua và cài
đặt. “
45. 45
Yêu cầu có thể kiểm thử cho
VD. 4
Sự lựa chọn Access Profile cho CIS có sẵn
nếu và chỉ nếu các tính năng CIS đã được
cài đặt.
Sự lựa chọn Access Profile cho Options có
sẵn nếu và chỉ nếu các tính năng Options đã
được cài đặt.
46. 46
Một vài testcase cho VD. 4
1. Nếu tùy chọn 'CIS được cài đặt, lựa chọn
Access Profile sẽ được sẵn sàng cho' CIS „
2. Nếu tùy chọn 'Options' được cài đặt, lựa
chọn Access Profile sẽ được sẵn sàng cho
'Options‟
3. Nếu tùy chọn 'CIS không được cài đặt, các
lựa chọn Access Profile cho' CIS sẽ không
có sẵn
4. Nếu tùy chọn 'Options' là không được cài
đặt, sự lựa chọn Access Profile cho
'Options' sẽ không có sẵn
47. 47
Ví dụ các yêu cầu 5
Một hệ thống bảo mật nâng cấp đã được cài
đặt với mật khẩu bảo vệ tăng cường. Dưới
đây là một yêu cầu:
"Mật khẩu hiện tại không phù hợp với các
hạn chế mới sẽ được thiết lập lại User ID, và
một danh sách của những người dùng có
mật khẩu đã thiết lập lại sẽ được tạo ra.”
48. 48
Ví dụ các yêu cầu 6
Phát hiện các yêu cầu không kiểm thử được
"Số cố gắng không hợp lệ trước khi một
người dùng bị đình chỉ: số này được thiết lập
lại khi đăng nhập thành công là hoàn thành
cho người sử dụng. Mặc định rằng người
dùng sẽ không bao giờ bị đình chỉ. Phạm vi
hợp lệ là từ 0 (không bao giờ) đến 10 lần. “
49. 49
Yêu cầu có thể kiểm thử cho
VD. 6
Yêu cầu: Số lượng của những nỗ lực không hợp lệ trước
khi đình chỉ có thể được thiết lập là 2
Trường hợp kiểm thử1: Sau 2 lần cố gắng 'xấu„ đăng nhập
vào, USERID của người dùng bị đình chỉ.
Trường hợp Kiểm thử 2: Một cố gắng 'xấu', theo sau là một
nỗ lực tốt, sau đó có thể được theo sau bởi 2 'xấu' cố
gắng một lần nữa trước khi đình chỉ.
Áp dụng tương tự cho 1, 3-10
Yêu cầu: Số lượng của những nỗ lực không hợp lệ trước
khi đình chỉ có thể được thiết lập đến 11
Trường hợp kiểm thử 3: Cố gắng để thiết lập những nỗ lực
không hợp lệ đến 11, hoặc xác minh nó không thể được
thực hiện.
50. 50
Ví dụ yêu cầu 7
Sự mơ hồ trong các khác nhau:
"Module Advanced Color sẽ cải thiện chất
lượng in của mô-đun".
“ Mô-đun Advanced Color sẽ làm tăng số
lượng các sắc thái màu sắc trên mỗi bảng từ
4-9 màu thành 25 - 30 sắc thái"
Module Advanced Color sẽ làm giảm hiệu
ứng ốp lát kết hợp với các mô-đun trước. “
51. 51
Ví dụ yêu cầu 8
Rất nhiều trường hợp thử nghiệm từ một câu:
"Tất cả các màn hình mới và được sửa đổi
sẽ cung cấp trợ giúp trực tuyến.”
52. 52
Ví dụ 9
3.3.1.3.2. User Name và Password quy tắc
Tên có tối đa 24 ký tự. Các kí tự với các giá trị ASCII 0
đến 31, kí tự trống, '*', và ',' là không hợp lệ.
Mật khẩu có tối đa 24 ký tự. Mật khẩu là chữ số. Dấu
chấm câu không được cho phép. Quản trị có thể thiết
lập các tùy chọn để tiếp tục hạn chế việc xây dựng mật
khẩu, xem Tùy chọn User / Password.
Tất cả các ký tự mở rộng trên ASCII 255 có sẵn cho các
tên người dùng và mật khẩu. Điều này bao gồm tất cả
các ký tự double-byte.
Tên người dùng và mật khẩu là trường hợp nhạy cảm.
Tên Người dùng sẽ luôn luôn được hiển thị dạng chữ
hoa
53. 53
Ví dụ 10
Giao diện người sử dụng phải được dễ dàng
sử dụng.
Trong trường hợp thất bại, hệ thống phải
được dễ dàng để phục hồi và phải chịu tổn
thất tối thiểu của dữ liệu quan trọng.
54. 54
Bài học
Theo dõi các từ như "luôn luôn", „không bao giờ
',' tất cả ',.. Chúng rất khó để xác minh.
Những từ như "phải", "nên", "phải", "sẽ", “cần
phải",... tín hiệu yêu cầu tiềm năng.
Quan sát các yêu cầu ẩn hoặc không được nhắc
đến.
Watch cho các yêu cầu mơ hồ: "cao", "nhanh
chóng", "tốt hơn", "nhanh", "sẽ có thể đến“.
Đối với thử nghiệm tiêu cực, hãy hỏi "Điều gì sẽ
xảy ra nếu các trường hợp thử nghiệm không
thành công?”
Hãy tự hỏi mình câu hỏi: "Làm sao tôi biết nếu
yêu cầu không được đáp ứng?”