Chương 1.pdf

Chương 1: Tổng quan về kiểm thử phần mềm
1. Lịch sử phát triển kiểm thử phần mềm
1.1. Một số thuật ngữ
- Lỗi ( Error): Lỗi là những vấn đề con người mắc
phải trong quá trình phát triển các sản phẩm phần mềm =>
Con người luôn luôn phạm lỗi, Khi lập trình viên phạm lỗi
lập trình, ta gọi các lỗi đó là Bug. Và lỗi có thể phát tán
- Sai (Fault): Sai là kết quả của lỗi.
- Thất bại (Failure): Thất bại được xuất hiện khi một
lỗi được thực thi
- Sự cố ( Incident): Khi thất bại xuất, nó có thể hiển
thị hoặc không. Sự cố là triệu chứng liên kế với một thất bại
và thể hiện cho người dùng và người kiểm thử về sự xuất
hiện của thát bại này.

1.1. Một số thuật ngữ
- Kiểm chứng và thẩm định: Hay dùng lẫn lộn
+ Kiểm chứng( verification): là quá trình để đảm bảo
rằng một sản phẩm phần mềm thỏa mãn đặc tả của nó.
+Thẩm định (validation): là quá trình đảm bảo rằng
sản phẩm đáp ứng được yêu cầu của người dùng

1.1. Các mốc thời gian phát triển KTPM
- Thuật ngữ kiểm thử phần mềm (Software Testing)
xuất hiện từ những năm 50, khi ngôn ngữ lập trình hiện đại
đầu tiên được thiết kế: FORTRAN, được phát minh bởi
John W. Backus vào tháng 4 năm 1957. Lúc này, KTPM
được xem như là công việc mà các lập trình viên phải làm
để tìm ra lỗi, sau khi tìm ra lỗi thì sửa lỗi và thực hiện một
cách thủ công.
- Đến năm 1960, KTPM có một sự thay đổi là kiểm
tra toàn diện. Lúc này việc tìm lỗi thông qua các mã hoặc
danh sách dữ liệu đầu vào, nhưng có quá nhiều dữ liệu vào
nên kiểm tra toàn diện k được chú ý

- Từ 1960-1970: phần mềm phát triển liên tục( hoạt
động PTPM được gọi là KHMT). KTPM được xem như là
quá trình thực hiện để minh chứng tính đúng đắn của
chương trình.
- Cuối năm 1970: KTPM được xem như là quá trình
đi tìm ra lỗi của chương trình chứ không còn chứng minh
tính đúng đắn nữa.
- Đến những năm 1980, KTPM được xem là để ngăn
ngừa lỗi

- Vào giữa nhưng năm 1980, các công cụ kiểm thử tự
động xuất hiện
- Đến đầu năm 1990, sức mạnh của việc thiết kế các
trường hợp kiểm thử đã được công nhận, nó bao gồm: lập
kế hoạch, thiết kế, xây dựng, bảo trì, tạo lập các môi trường
kiểm thử và thực thi kiểm thử. Lúc này, các công cụ KT tự
động được nâng cấp.
- Từ đầu năm 2000 đến nay, khái niệm tối ưu hóa
công nghệ tự động hóa xuất hiện

1.2. Tầm quan trọng của KTPM
- KTPM đóng vai trò quan trọng trong việc đánh giá
và thu được các sản phẩm PM chất lượng cao. Thông qua
chu trình “kiểm thử - tìm lỗi – sửa lỗi”

1.2. Tầm quan trọng của KTPM
Dưới đây là minh họa một số khiếm khuyết phần mềm quan
trọng đã xảy ra trên thế giới:
– Vào tháng 6/1996, chuyến bay đầu tiên của tên lửa Ariane 5 của Cơ quan
Vũ trụ Châu Âu đã bị thất bại ngay sau khi phóng, kết quả là một mất mát
không có bảo hiểm 500.000.000$. Thảm họa đã được truy ra từ việc thiếu
các xử lý ngoại lệ do lỗi dấu phẩy động (floating-point) khi một số nguyên
64-bit được chuyển đổi sang một số nguyên 16-bit.
– Trong th|ng 10/1999, 125.000.000$ bị thất thoát do tàu thăm dò khí hậu Sao
hỏa của NASA - một vệ tinh thời tiết giữa các hành tinh đã bị mất trong
không gian do một lỗi chuyển đổi dữ liệu. Các nhà điều tra phát hiện ra
rằng phần mềm trên tàu vũ trụ đó đã thực hiện các phép tính bằng đơn vị
kilomet trong khi nó phải sử dụng đơn vị mét.
– Vào tháng 7/2001 một lỗ hổng nghiêm trọng đã được tìm thấy trong phần
mềm Off-The-Shelf m{ từ lâu đã được sử dụng trong các hệ thống theo dõi
nguyên liệu hạt nhân của Mỹ. Phần mềm này sau đó đó được tặng cho
mộtnước khác và các nhà khoa học ở nước đó đã phát hiện ra khiếm
khuyết của nó.
– Vào tháng 2/2003, Bộ Tài chính Mỹ gửi 50.000 tấm ngân phiếu An ninh xã
hội mà không có tên người thụ hưởng. Một phát ngôn viên cho biết các tên
mất tích là do một lỗi trong bảo trì chương trình phần mềm.

Tại sao KTPM lại quan trọng?
Kiểm thử phần mềm là một hoạt động giữ vai trò rất
quan trọng để bảo đảm chất lượng phần mềm và là hoạt
động mang tính sống còn trong các dự án sản xuất hoặc gia
công phần mềm. Vì vậy, kiểm thử phần mềm đã trở thành
qui trình bắt buộc trong các dự án phát triển phần mềm trên
thế giới.
Làm gì cũng cần kiểm tra, đánh giá thì mới biết được
liệu nó có đạt được những gì được mong đợi, có sai sót gì
không
Kiểm thử phần mềm để tránh được những rủi ro, lỗi
phát sinh trong suốt quá trình tạo ra sản phẩm. Lỗi phát hiện
càng sớm càng giúp tránh được rủi ro và chi phí.

2. Khái quát về kiểm thử phần mềm
2.1. Định nghĩa về KTPM
- IEEE: Kiểm thử là tiến trình vận hành hệ thống hoặc thành phần dưới
những điều kiện xác định, quan sát hoặc ghi nhận kết quả và đưa ra đánh giá về hệ
thống hoặc thành phần đó.
- Myers: Kiểm thử là tiến trình thực thu chương trình với mục đích tìm
thấy lỗi
Có thể nhận thấy kiểm thử phần mềm là một quá trình lớn bao gồm nhiều
quá trình nhỏ liên kết với nhau. Mục tiêu chính của kiểm thử phần mềm là đo lường
“sức khỏe” phần mềm cùng với các yêu cầu liên quan của nó. Kiểm thử phần mềm
bao gồm các công việc kiểm tra khác nhau thông qua các quy trình kiểm thử khác
nhau. Mục tiêu của các quá trình này có thể bao gồm:
+ Kiểm tra xem phần mềm có đáp ứng được các yêu cầu chức năng hoặc
yêu cầu kinh doanh hay không?
+ Xác định các lỗi kỹ thuật, các sai sót và đảm bảo phần mềm không có lỗi
khi đưa vào sử dụng.
+ Đánh giá khả năng sử dụng, hiệu suất, độ bảo mật, khả năng tương thích
và dễ lắp đặt

2.1. Định nghĩa về KTPM
Kiểm thử phần mềm (software testing) là hoạt động nhằm tìm kiếm,
phát hiện các lỗi của phần mềm
Kiểm thử phần mềm còn hướng đến mục tiêu xa hơn có thể gọi là
“phòng bệnh hơn chữa bệnh”. Tức là nâng cao khả năng kiểm soát và hạn chế
các lỗi xảy ra khi phát triển phần mềm ngay từ ban đầu, chứ không đơn thuần
chỉ là việc tìm những lỗi sẵn có khi nhóm phát triển đã đưa ra những phiên bản
cụ thể của phần mềm.
Kiểm thử phần mềm đảm bảo sản phẩm phần mềm đáp ứng chính xác,
đầy đủ và đúng theo yêu cầu của khách hàng, yêu cầu của sản phẩm đề đã đặt ra.
Software testing cũng cung cấp mục tiêu, cái nhìn độc lập về phần
mềm, điều này cho phép việc đánh giá và hiểu rõ các rủi ro khi thực thi phần
mềm
Kiểm thử phần mềm tạo điều kiện cho bạn tận dụng tối đa tư duy đánh
giá và sáng tạo để bạn có thể phát hiện ra những điểm mà người khác chưa nhìn
thấy.

Mục tiêu của kiểm thử phần mềm?
Để kiểm tra xem phần mềm đáp ứng nhu cầu của khách hàng
và phù hợp với các đặc tả và đảm bảo chất lượng và tính chính xác của
ứng dụng.
Nó thật sự có làm việc như mong muốn?
Nó làm được gì mà người sử dụng mong đợi?
Tiết kiệm thời gian và chi phí bởi xác định/ tìm kiếm những
thiếu sót/ lỗi sớm
Biết rằng chúng ta đã thỏa mãn được những yêu cầu của khách
hàng

Ai có thể tham gia KTPM?
Có nhiều đối tượng có thể tham gia vào kiểm thử:
Software tester
Software developer
Project Leader/ Manager
End User
Điều gì xảy ra nếu việc kiểm thử không tìm được lỗi trong phần mềm
hoặc phát hiện quá ít lỗi
Phần mềm có chất lượng quá tốt
Quy trình/Đội ngũ kiểm thử hoạt động không hiệu quả

Trách nhiệm của một Tester?
Phân tích và tìm hiểu tài liệu Đặc tả yêu cầu phần mềm
Tham gia vào chuẩn bị/ lập Test plans
Thực hiện viết test design, test cases (kịch bản kiểm thử)
Thực hiện test ( test execution)
Theo dõi kết quả test
Báo cáo kiểm thử ( test report)
Giao tiếp với đội phát triển, khách hàng.
Các bài học rút ra để cải thiện chất lượng của ứng dụng

Các mô hình phát triển phần mềm?
(Software Life Cycle - SLC )
Một số mô hình SLC phổ biến trên thế giới:
Waterfall model (thác nước)
V model
Iterative and Incremental model (mô hình lặp và tăng dần)
RAD model (mô hình phát triển ứng dụng nhanh)
Spiral model ( mô hình xoắn)
Agile model (scrum process) mô hình linh hoạt.
RUP model

Các mô hình phát triển phần mềm?
(Software Life Cycle - SLC )

SLC là gì?
Một trong những kiến thức cần thiết của một kỹ sư kiểm thử phần
mềm chuyên nghiệp đó là hiểu biết và nắm rõ SDLC (Software Development
Life-cycle/chu kỳ phát triển phần mềm), bởi vì kiểm thử phần mềm
(software testing) là 1 phần và liên quan chặt chẽ, mật thiết đến SDLC.
Quy trình là một trong những yếu tố cực kỳ quan trọng đem lại sự
thành công cho các nhà sản xuất phần mềm, nó giúp cho mọi thành viên
trong dự án từ người cũ đến người mới, trong hay ngoài công ty đều có thể
xử lý đồng bộ công việc tương ứng vị trí của mình thông qua cách thức
chung của công ty, hay ít nhất ở cấp độ dự án.
Vai trò kiểm thử trong suốt quy trình của phần mềm
Kiểm thử không tồn tại độc lập.
Các hoạt động của kiểm thử luôn gắn liền với các hoạt động phát
triển phần mềm.
Các mô hình phát triển phần mềm khác nhau cần các cách tiếp cận
test khác nhau.

2.2. Vòng đời KTPM

2.3. Sơ đồ tổ chức phổ biến của đội kiểm thử

2.4. Quy trình kiểm thử tổng quát

* Lập kế hoạch kiểm thử:
Test Manager hoặc Test Leader sẽ xây dựng kế hoạch ban đầu về
kiểm thử.
 ƒ
Định nghĩa phạm vi kiểm thử
 Định nghĩa các chiến lược kiểm thử
 Nhận dạng các rủi ro và yếu tố bất ngờ
 Nhận dạng các hoạt ₫ộng kiểm thử nào là thủ công, kiểm thử nào là
tự động hay cả hai.
 Ước lượng chi phí kiểm thử và xây dựng lịch kiểm thử.
 Nhận dạng môi trường kiểm thử.
Kế hoạch kiểm thử cần được:ƒ
 xem lại bởi QC team, Developers, Business Analysis. TA (if need),
PM and Customer
ƒ
Chấp thuận bởi : Project Manager and Customer
ƒ
Hiệu chỉnh trong suốt chu kỳ kiểm thử ₫ể phản ánh các thay đổi nếu

* Phân tích và thiết kế kiểm thử
Test Analyst hoặc Test Designer sẽ thiết kế (₫ịnh nghĩa) các
testcase từ các yêu cầu liên quan (thí dụ từ thông tin trong usecase).
sẽ thiết kế (định nghĩa) các testcase từ các yêu cầu chức năng và các
yêu cầu không chức năng của phần mềm.
Các testcase cần bao phủ tất cả khía cạnh kiểm thử cho từng yêu cầu
phần mềm.
Các testcase cần bao phủ tất cả yêu cầu trong các chiến lược kiểm
thử.
Nếu cần kiểm thử tự động, Test Designer sẽ xây dựng các kịch bản
dựa trên các testcase/Test procedures.

* Phân tích và thiết kế kiểm thử
Các testcase cần được :
 Xem xét lại bởi Project Leader, Developer có liên quan, các Testers
khác, Test Leader, Business Analysis và Customer.
 Chấp thuận bởi Test Leader hoặc Customer
 Hiệu chỉnh/cập nhật nếu Tester ₫ã tìm ₫ược những lỗi mà
không nằm trong các testcase hiện có.

* Thực thi kiểm thử
Testers sẽ được bố trí công việc bởi Test Leader để thi hành
kiểm thử.
Thi hành kiểm thử theo từng testcase.
Thực hiện kiểm thử đặc biệt (ad-hoc)
Thực hiện kịch bản kiểm thử mà không được định nghĩa trong
testcase.
Kiểm thử lại các lỗi đã được sửa.
Tester sẽ tạo các báo cáo về lỗi trong suốt quá trình kiểm lỗi
và theo dõi chúng cho ₫ến khi chúng đã được xử lý.
ƒỞ công đoạn kiểm thử độ chấp thuận, Customer sẽ thi hành
kiểm thử để kiểm định xem hệ thống phần mềm có thỏa mãn các nhu
cầu người dùng không ?

* Tạo báo cáo và đánh giá kiểm thử
Test Manager hoặc Test Leader sẽ phân tích các lỗi trong hệ
thống theo dõi các lỗi.
Tạo các báo cáo lỗi.
Đánh giá các kết quả kiểm thử, thống kê các yêu cầu thay đổi.
Tính và phân phối các thông tin đo lường hoạt động kiểm thử.
Tạo bảng tổng kết đánh giá hoạt động kiểm lỗi.
Xác định xem đã đạt tiêu chí thành công và hoàn thành kiểm
thử chưa.?

3. Những nguyên nhân gây lỗi và chi phí khắc phục lỗi
3.1. Những nguyên nhân
Phần mềm do con người tạo ra, con người có
thể mắc lỗi vì vậy phần mềm có thể có lỗi. Dựa vào
các số liệu thống kê, người ta xác định lỗi phần
mềm xuất hiện từ nhiều nguồn chứ không chỉ do lập
trình. Trong số đó nguyên nhân chính xuất phát từ
đặc tả phần mềm (specification), xem tỉ lệ sau:

Vài lý do làm cho đặc tả dễ gây ra lỗi là:
- Một số bản đặc tả không viết cụ thể, không đủ kỹ
lưỡng.
- Hoặc nó liên tục thay đổi, nhưng lại không có sự
phối hợp, trao đổi thông tin kịp thời với các đội phát
triển dự án.
- Lập kế hoạch cho phần mềm là vô cùng quan
trọng. Nếu nó không được thiết kế đúng, lỗi sẽ phát
sinh,...

Một số nguyên nhân gây ra lỗi:

3.2. Chi phí khắc phục lỗi phần mềm
Chi phí cho việc tìm và sửa lỗi thường rất lớn, thống
kê cho thấy các nhân viên phần mềm tốn đến 50% thời gian
và chi phí cho việc tìm và khắc phục lỗi. Việc tìm ra lỗi
càng sớm càng ít tốn chi phí, nếu lỗi phát sinh trong giai
đoạn đặc tả mà không khắc phục đến khi chuyển giao phần
mềm mới phát hiện thì chi phí khắc phục rất lớn thậm chí
gấp cả 1000 lần, hình sau sẽ cho thấy điều đó.

4. Những tố chất cần thiết cho công việc kiểm thử
Trước đây việc kiểm thử thường được xem nhẹ, và
hay giao cho bộ phận phát triển phần mềm tự kiểm tra luôn
thì ngày có nhiều tổ chức độc lập làm công việc kiểm thử
một cách chuyên nghiệp. Công việc kiểm thử ngày càng
được quan tâm và xem đây là một nghề thực sự. Kiểm thử
viên phần mềm gọi là tester, liên quan đến công việc này, ở
một số tổ chức còn thêm Test Environment, Test Design,
Test Lead,...

- Họ là những người thám hiểm: kiểm thử viên không sợ
mạo hiểm khi ở trong những hoàn cảnh mà họ chưa làm chủ
được. Họ thích những khía cạnh mới của phần mềm, cài đặt
nó trên máy của họ, và xem xét chuyện gì sẽ xảy ra.
- Họ là những người thợ sửa chữa: các kiểm thử viên làm
rất tốt các công việc tính toán xem tại sao một số chức năng
của phần mềm lại không làm việc. Họ rất thích những vấn
đề khó giải quyết

- Nghiêm khắc: Các kiểm thử viên luôn phải thử nghiệm, họ
có thể nhìn thấy một lỗi mà đã nhanh chóng biến mất hoặc
là rất khó để tạo lại tình huống có lỗi đó. Đúng hơn là giải
tán nó như một sự may mắn, họ sẽ cố gắng bằng mọi cách
có thể để tìm ra nó.
- Sáng tạo: Việc kiểm thử những điều hiển nhiên, rõ ràng là
không thể đủ với một kiểm thử viên. Công việc của họ cần
những ý tưởng sáng tạo và thậm chí là các cách tiếp cận
mới mẻ để tìm kiếm lỗi (bug).

- Cầu toàn: Họ cố gắng để đạt đến sự hoàn hảo, nhưng họ
cũng biết rằng điều đó là không thể đạt được và họ chấp
nhận dừng quá trình kiểm thử khi họ thấy có thể.
- Óc phán đoán rất tốt: kiểm thử viên cần đưa ra những
quyết định về những thứ mà họ sẽ phải kiểm tra, và ước
lượng quá trình kiểm tra sẽ diễn ra trong thời gian bao lâu,
nếu như vấn đề mà họ tìm kiếm thật sự là một lỗi.
- Khéo léo và có khả năng ngoại giao: Kiểm thử viên luôn
là người thông báo những tin tức xấu.

Họ phải nói với lập trình viên những lỗi mà họ phát hiện.
Một kiểm thử viên tốt sẽ biết cách để làm việc khéo léo và
rất chuyện nghiệp, và họ cũng biết cách để làm việc với lập
trình viên, những người không phải lúc nào cũng khéo léo
và lịch thiệp.
- Biết cách thuyết phục người khác: các lỗi mà kiểm thử
viên tìm thấy sẽ luôn được xem xét một cách đủ khắt khe để
đảm bảo nó sẽ được sửa. Các kiểm thử viên cần chứng minh
những luận điểm của họ rằng tại sao những lỗi mà họ phát
hiện lại cần được sửa, và những lỗi này có thể gây ra những
gì?

5. Sự khác nhau giữa Testing (Kiểm thử) và
Quality Assurance (đảm bảo chất lượng) (QA)
Testing và quality assurance (có thể viết tắt là QA).
Mục đích của testing là tìm ra lỗi, tìm thấy chúng
sớm nhất có thể, và đảm bảo rằng chúng đã được sửa.
Trách nhiệm chính của người QA là tạo và bắt phần
mềm phải tuân theo các chuẩn để cải tiến quy trình phát
triển phần mềm và ngăn chặn các lỗi xuất hiện bất cứ lúc
nào

5. Sự khác nhau giữa Testing (Kiểm thử) và
Quality Assurance (đảm bảo chất lượng) (QA)
Testing và quality assurance (có thể viết tắt là QA).
Dĩ nhiên, 2 khái niệm này vẫn có sự chồng chéo
nhau. Một số kiểm thử viên sẽ làm nhiệm vụ QA, một số thì
thực thi việc kiểm tra. Hai công việc này cùng các nhiệm vụ
của nó có quan hệ chặt chẽ với nhau. Tuy nhiên khó mà
tránh khỏi sự lộn xộn giữa các thành viên làm nhiệm vụ
kiểm thử và các thành viên đảm bảo chất lượng phần mềm
(QA).

Chương 1.pdf

Recommended

Recommended

More Related Content

Similar to Chương 1.pdf

Similar to Chương 1.pdf (20)

Recently uploaded

Recently uploaded (20)

Chương 1.pdf