CHUONG 2.pdf

Chương 2: Phát triển kiểm thử phần mềm
NỘI DUNG CHƯƠNG 2:
 Khái niệm về test case
 Các mức kiểm thử ( các giai đoạn kiểm thử)
 Các phương pháp kiểm thử
 Các loại hình kiểm thử

2.1. Trường hợp kiểm thử (testcase)
2.1.1. Khái niệm Testcase
Mỗi testcase gồm bộ 3 thông tin {tập dữ liệu đầu vào,
trạng thái của thành phần phầm mềm, tập kết quả kỳ vọng}.
Trong đó:
 Tập dữ liệu đầu vào (Input): gồm các giá trị dữ liệu cần
thiết để thành phần phầm mềm dùng và xử lý.
 Tập kết quả kỳ vọng: kết quả mong muốn sau khi thành phần
phần mềm xử lý dữ liệu nhập.
 Trạng thái thành phần phần mềm: được tạo ra bởi các giá trị
prefix(tiền tố) và postfix (hậu tố).
Tập các testcase : tập hợp các testcase mà ta có ý định dùng để
kiểm thử thành phần phần mềm để minh chứng rằng TPPM có
đúng các hành vi mong muốn.

2.1. Trường hợp kiểm thử (testcase)
2.1.2. Các nguyên tắc cơ bản khi thiết kế một trường hợp
kiểm thử
Thông tin thiết yếu của mỗi testcase là kết quả hay dữ liệu xuất
được kỳ vọng. Nếu kết quả kỳ vọng của testcase không được
định nghĩa rõ ràng, người ta sẽ giải thích kết quả sai (plausible)
thành kết quả đúng bởi vì hiện tượng “the eye seeing what it
wants to see.”
Vậy nên, một test case phải chứa 2 thành phần thiết yếu:
+ Đặc tả về điều kiện dữ liệu nhập.
+ Đặc tả chính xác về kết quả đúng của chương trình
tương ứng với dữ liệu nhập.
Việc kiểm thử đòi hỏi tính độc lập: lập trình viên nên tránh việc
kiểm thử các TPPM do mình viết.

Nội dung
Testcase
Các giai đoạn điểm
thử ( các mức kiểm
thử
Các phương pháp
kiểm thử

2.1. Các mức độ kiểm thử

Mối tương quan giữa phát triển và kiểm thử phần mềm

2.2.1. Kiểm thử mức đơn vị ( Unit testing):

Vì Unit được chọn để kiểm thử thường có kích thước
nhỏ và chức năng hoạt động đơn giản, chúng ta không khó
khăn gì trong việc tổ chức, kiểm thử, ghi nhận và phân tích
kết quả kiểm thử. Nếu phát hiện lỗi, việc xác định nguyên
nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh
vùng trong một đơn thể Unit đang kiểm thử. Một nguyên lý
đúc kết từ thực tiễn: thời gian tốn cho Unit Test sẽ được đền
bù bằng việc tiết kiệm rất nhiều thời gian và chi phí cho
việc kiểm thử và sửa lỗi ở các mức kiểm thử sau đó.

Sử dụng phương pháp kiểm thử nào?
Ai sẽ thực hiện việc kiểm thử?
Nó được thực hiện khi nào?

Kiểm thử đơn vị giúp làm dễ dàng quá trình thay đổi
hoặc bảo trì mã. Nếu có kiểm thử đơn vị tốt được viết và
được thực thi thì với bất kỳ sự thay đổi nào của mã,
ta cũng có thể kịp thời nhận ra các lỗi khi nó xuất hiện.
Chi phí sửa chữa một khiếm khuyết được phát hiện
trong quá trình kiểm thử đơn vị lá ít hơn so với các khiếm
khuyết phát hiện ở các mức cao hơn như khi kiểm
thử ở mức chấp nhận hoặc khi phần mềm đang hoạt động.
Ưu điểm của kiểm thử đơn vị:

Là một mức kiểm thử phần mềm mà các đơn vị được kết hợp lại và
được kiểm thử như là một nhóm. Mục đích của kiểm thử tích hợp là để tìm
lỗi khi có sự tương tác giữa các đơn vị tích hợp.
Các mục tiêu chính của kiểm thử tích hợp bao gồm:
- 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ỏ (subsystem) và
cuối cùng là nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm tra ở
mức hệ thống (System Test).
- Trong kiểm thử đơn vị, lập trình viên cố gắng phát hiện lỗi liên
quan đến chức năng và cấu trúc nội tại của đơn vị. Có một số phép kiểm tra
đơn giản trên giao tiếp giữa đơn vị với các thành phần liên quan khác, tuy
nhiên mọi giao tiếp liên quan đến đơn vị, thật sự được kiểm tra đầy đủ khi
các đơn vị tích hợp với nhau trong khi thực hiện
- Kiểm thử tích hợp, trừ một số ít ngoại lệ, kiểm thử tích hợp chỉ nên thực
hiện trên những đơn vị đã được kiểm tra cẩn thận trước đó bằng kiểm thử
đơn vị, và tất cả các lỗi mức đơn vị đã được sửa chữa.
Kiểm thử tích hợp (Integration Test):

Kiểm thử tích hợp (Integration Test):

Kiểm thử hệ thống là một mức kiểm thử phần mềm, trong đó một
phần mềm được tích hợp và đã hoàn chỉnh được thực hiện kiểm thử. Mục
đích của kiểm thử này nhằm đánh giá sự tuân thủ của hệ thống với các yêu
cầu đặc tả
Kiểm thử hệ thống bắt đầu khi tất cả các bộ phận của phần mềm đã
được tích hợp thành công. Thông thường loại kiểm tra này tốn rất nhiều
công sức và thời gian. Trong nhiều trường hợp, việc kiểm tra đòi hỏi yên
cầu phải có môi trường kiểm thử thích hợp. Ví dụ như một số thiết bị phụ
trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian
thực, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ của ST (system
test) thì tester cũng tìm kiếm các lỗi, nhưng trọng tâm của loại kiểm thử này
là đánh giá về chức năng, hoạt động, thao tác, sự tin cậy và các yêu cầu khác
liên quan đến chất lượng của toàn hệ thống.
Kiểm thử hệ thống (System test)

Điểm khác nhau then chốt giữa kiểm thử tích hợp và kiểm
thử hệ thống là kiểm thử hệ thống chú trọng các hành vi và
lỗi trên toàn hệ thống, còn kiểm thử tích hợp chú trọng sự
giao tiếp giữa các thực thể hoặc đối tượng khi chúng làm
việc cùng nhau. Trong quy trình kiểm thử thì thông thường
ta phải thực hiện kiểm thử đơn vị và kiểm thử tích hợp để
đảm bảo mọi đơn vị và giao tiếp, tương tác giữa chúng hoạt
động chính xác trước khi thực hiện kiểm thử hệ thống.

- Đây là giai đoạn kiểm tra được khách hàng thực hiện. Mục đích
của kiểm thử chấp nhận là để chứng minh phần mềm thỏa mãn tất cả yêu
cầu của khách hàng và khách hàng chấp nhận sản phẩm và trả tiền thanh
toán hợp đồng.
- Kiểm thử chấp nhận có ý nghĩa hết sức quan trọng, mặc dù
trong hầu hết mọi trường hợp, các phép kiểm tra của kiểm thử hệ thống
và kiểm thử chấp nhận gần như tương tự, nhưng bản chất và cách thức
thực hiện lại rất khác biệt.
- Trên thực tế, nếu khách hàng không quan tâm và không tham
gia vào quá trình phát triển phần mềm thì thường kết quả kiểm thử chấp
nhận sẽ sai lệch rất lớn, mặc dù PM đã trải qua tất cả các kiểm tra trước
đó. Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự
mong chờ của khách hàng. Ví dụ đôi khi một PM xuất sắc vượt qua các
phép kiểm tra về chức năng thực hiện bởi nhóm thực hiện dự án, nhưng
khách hàng khi kiểm tra sau cùng vẫn thất vọng vì bố cục màn hình
nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng của
khách hàng…
Kiểm thử chấp nhận (Acceptance Test)

2.2. Các phương pháp kiểm thử
Phương pháp kiểm thử (Testing Method) là những chiến lược và
biện pháp sử dụng để kiểm tra một sản phẩm cụ thể nhằm đảm bảo nó phù
hợp với mục tiêu ban đầu. Các phương pháp kiểm thử thường liên quan đến
việc kiểm tra các sản phẩm có thực hiện theo đúng đặc tả của nó hay không.
Các phương pháp kiểm thử phần mềm thường bao gồm:
Kiểm thử hộp đen
Kiểm thử hộp trắng
Kiểm thử hộp xám
Kiểm thử nhanh
Kiểm thử tùy hứng

Kiểm thử hộp đen là một phương pháp kiểm thử mà các tester
không cần quan tâm đến các hoạt động bên trong hệ thống chạy ra sao,
không cần quan tâm đến các dòng lệnh bên trong hệ thống hệ thống như thế
nào. mà chỉ cần tập trung vào các giá trị đầu vào và các giá trị đầu ra của hệ
thống có đúng với kết quả mong đợi của các trường hợp kiểm thử không để
từ đó đánh giá chất lượng hệ thống.
Phương pháp này cố gắng tìm ra các lỗi có dạng sau:
Chức năng không chính xác hoặc thiếu
Lỗi giao diện
Lỗi truy cập cơ sở dữ liệu bên ngoài
Lỗi hành vi…
kiểm thử hộp đen là gì?

Ưu và nhược điểm của kiểm thử hộp đen
Ưu điểm Nhựợc điểm
- Rất phù hợp và hiệu quả khi mà số lượng
các dòng lệnh của hệ thống là lớn.
- Bị giới hạn ở độ bao phủ của các trường
hợp kiểm thử.
- Không cần truy cập vào các dòng lệnh. - Sẽ không hiệu quả bởi thực tế các tester
bị giới hạn kiến thức về hệ thống.
- Phân biệt được rõ ràng quan điểm của
người dùng với quan điểm của nhà phát
triển.
- Độ bao phủ sẽ bị thiếu vì tester không
kiểm tra được các đoạn lệnh của hệ thống
hoặc tập trung vào các dòng lệnh dễ xảy ra
lỗi.
- Không cần đòi hỏi những kiến thức về
ngôn ngữ lập trình ở các tester để có thể
kiểm thử hệ thống.
- Sẽ khó để có thể thiết kế đầy đủ các
trường hợp kiểm thử.

 Phân vùng tương đương - Equivalence partitioning
 Phân tích giá trị biên - Boundary value analysis
 Bảng quyết định - Decision Table Bases testing
 Đồ thị nguyên nhân kết quả
 Dựa vào các usecase
Các phương pháp kiểm thử hộp đen

Ý tưởng: Phân hoạch miền dữ liệu vào thành các dữ liệu có
liên hệ với nhau
Mỗi vùng dùng để kiểm thử 1 chức năng , gọi là vùng tương
đương.
Các bước :
- Đối với dữ liệu đầu vào , xác định các vùng tương
đương từ miền dữ liệu.
- Chọn dữ liệu đại diện cho mỗi vùng tương đương
- Kết hợp các dữ liệu thử bởi tích đề các để tạo ra bộ
dữ liệu kiểm thử.

* Nguyên tắc phân hoạch các vùng tương đương
Nếu dữ liệu vào phụ thuộc một khoảng, xây dựng
» 1 vùng các giá trị lớn hơn
» 1 vùng các giá trị nhỏ hơn
» N các giá trị hợp lệ
Nếu dữ liệu là tập hợp các giá trị, xây dựng
» 1 vùng tập rỗng
» 1 vùng quá nhiều các giá trị
» N vùng hợp lệ
Nếu dữ liệu đầu vào là điều kiện ràng buộc, xây dựng
» 1 vùng các ràng buộc được thỏa mãn.
» 1 vùng với ràng buộc không được thỏa mãn.

Ví dụ: Bài toán đặt vé theo giờ
Nếu bạn đi xe điện chuyến trước 9:30 sáng hoặc từ sau
4:00 chiều đến 7:30 tối (giờ cao điểm), thì bạn phải mua vé
thường. Vé tiết kiệm (giá thấp hơn vé thường) có hiệu lực cho các
chuyến xe từ 9:30 sáng đến 4:00 chiều và sau 7:30 tối.

Ví dụ: Bài toán đặt vé theo giờ
============+==== -=========+========-
Vé thường: ________|__________|_________|__________
=================9h30=======16h=====19h30
========== -=======+=======-========+
Vé tiết kiệm: _______|________|_________|___________
=================9h30=====16h======19h30
Các vùng hợp lệ là vùng thuộc dấu (+) và vùng không hợp là vùng
thuộc dấu (-).
Phân theo các vùng hợp lệ và không hợp lệ ta có 4 test case cho phân
vùng tương đương: (0 – 9h30) , (9hh31 – 16h), (16h01 – 19h30),
(19h31 – 23h59).

Ví dụ ta cần kiểm thử 1 TPPM “quản lý nguồn nhân lực” với
đặc tả chức năng như sau : mỗi lần nhận 1 hồ sơ xin việc, TPPM sẽ ra
quyết định dựa vào tuổi ứng viên theo bảng sau :
Tuổi ứng viên Kết quả
0-16 Không thuê
16-18 Thuê dạng bán thời gian
18-55 Thuê toàn thời gian
55-99 Không thuê

Giả sử ta có đoạn code:
if (applicantAge >= 0 && applicantAge <=16) qd ="NO";
if (applicantAge >= 16 && applicantAge <=18) qd ="PART"; if (applicantAge
>= 18 && applicantAge <=55) qd ="FULL"; if (applicantAge >= 55 &&
applicantAge <=99) qd ="NO";
Khi đó, dựa vào kỹ thuật phân vùng tương đương ta sẽ có các
testcase như sau:
1. Testcase 1 : {Input : 2 tuổi, Output : không thuê}
2. Testcase 2 : {Input : 17 tuổi, Output : thuê bán thời gian}
3. Testcase 3 : {Input : 35 tuổi, Output : thuê toàn thời gian}
4. Testcase 4 : {Input : 90 tuổi, Output : không thuê}
Như vậy ta đã kiểm soát hết các lỗi đoạn code trên chưa

Giả sử ta có đoạn code:
Thực ra nếu ta dùng phương pháp vét cạn thì ta sẽ có 100
testcase để kiểm thử đoạn code trên, nhưng với kỹ thuật phân lớp
tương đương thì ta chỉ sử dụng 4 testcase. Dẫn đến tiết kiêm chi phí
rất nhiều. Tuy nhiên, với 4 lớp tương đương ta như trên ta sẽ không
phát hiện hết các lỗi của đoạn code trên. Vậy làm thế nào để phát hiện
hết lỗi đoạn code?

Tuy nhiên nếu người lập trình hiện thực như sau (rất cá biệt vì
đây là người lập trình rất yếu tay nghề) :
if (applicantAge == 0) qd ="NO";
…
if (applicantAge == 16) qd ="PART";
…
if (applicantAge == 53) qd ="FULL";
…
if (applicantAge == 99) qd ="NO";
Thì 4 testcase trên cũng chỉ kiểm tra 4/100 trường hợp kiểm thử.

 Phân tích giá trị biên - (Boundary Value Analysis)
Đây là một kỹ thuật thiết kế kiểm thử phần mềm có liên quan
đến việc xác định giới hạn cho các giá trị vào. Lúc này chọn các giá
trị là ở tại biên, bên trong hoặc bên ngoài biên làm dữ liệu thử.
 Qui trình cụ thể để thực hiện kiểm thử dựa trên các
giá trị ở biên :
Nhận dạng các lớp tương đương dựa trên đặc tả về yêu cầu
chức năng của TPPM.
Nhận dạng 2 biên của mỗi lớp tương đương.
Tạo các testcase cho mỗi biên của mỗi lớp tương đương :
- 1 testcase cho giá trị biên.
- 1 testcase ngay dưới biên.
- 1 testcase ngay trên biên.

 Phân tích giá trị biên - (Boundary Value Analysis)
Như vậy với ví dụ trên ta sẽ có các lớp biên như sau:
{-1,0,1}, {14,15,16}, {15,16,17}, {16,17,18}, {17,18,19},
{53,54,55}, {54,55,56},{98,99,100}.
Có nhiều testcase trùng nhau, nếu loại bỏ các testcase trùng
nhau, ta còn : -1, 0, 1, 14, 15, 16, 17, 18, 19, 53, 54, 55, 56, 98, 99,
100 (16 testcase so với hàng trăm testcase nếu vẹt cạn).
Vậy nếu đoạn code trên thì lập trình viên sẽ phát hiện ra được những
lỗi nào?

2.2. Các phương pháp kiểm thử
2.2.1. Kiểm thử hộp đen
2.2.2. Kiểm thử hộp trắng
2.2.3. Kiểm thử hộp xám
2.2.4. Kiểm thử tùy hứng

2.2.3. Kiểm thử hộp xám (Gray Box testing)
2.2.3.1. Định nghĩa
Gray Box = White Box + Black Box
- Trong Kiểm thử hộp đen, Tester kiểm thử các hạng
mục mà không cần biết cấu trúc bên trong của nó.
-Trong Kiểm thử Hộp trắng thì Tester biết được cấu
trúc bên trong của chương trình.
- Trong Kiểm thử Hộp xám, cấu trúc bên trong sản
phẩm chỉ được biết một phần, Tester có thể truy cập vào cấu
trúc dữ liệu bên trong và thuật toán của chương trình với
mục đích là để thiết kế test case, nhưng khi test thì test như
là người dùng cuối hoặc là ở mức hộp đen.

Được gọi là Gray Box Testing vì trong chương trình phần
mềm, mắt của Tester giống như hộp xám/bán trong suốt -
nhìn qua hộp này ta chỉ có thể thấy được một phần.
Ví dụ: Khi code của 2 unit/module được xem xét
(Phương pháp White Box Testing) dùng để thiết kế test case
và khi test thực tế thì được thực hiện test trên giao diện
người dùng (Phương pháp Black Box Testing).

- Có thể ứng dụng vào nhiều mức test khác nhau
nhưng chủ yếu nó hữu dụng trong mức Integration
Testing - kiểm thử tích

2.2.3.2. Tạo testcase và thực hiện test
Khi viết test case: Dựa vào yêu cầu và nội dung
Source Code (can thiệp vào bên trong Code của
chương trình)
Khi thực hiện test: Thực hiện trên giao diện của
chương trình (yêu cầu chương trình phải chạy được
mới test được, không can thiệp vào code)

2.2.3.2. ưu và nhược điểm của phương pháp
Về khuyết điểm
Bao phủ mã chỉ một phần: Trong kiểm thử hộp xám,
mã nguồn hoặc mã nhị phân bị thiếu bởi việc truy cập có
giới hạn về cấu trúc bên trong của các ứng dụng.
Khó kết hợp: Thật khó để kết hợp các khuyết tật khi
thực hiện kiểm thử hộp xám cho một hệ thống phân tán
Kiểm thử hộp xám phù hợp với các ứng dụng Web.

2.2.4.1 Định nghĩa

2.2.4.2. Đặc điểm
KT tùy hứng tha hồ test theo ý của mình, phán đoán
các testcase hóc búa nhất, hay xảy ra lỗi nhất. Tuy nhiên nó
sẽ không bao phủ hết các trường hợp và cũng không ghi
nhớ các testcase mình đã test. Do đó nó rất khó tái hiện lỗi.
 Ưu điểm của phương pháp này là nhanh chóng và không
bị ràng buộc
 Nhược điểm là bị chỉ trích nhiều nhất do không có cấu
trúc, khó tái hiện lỗi vì không có testcase và khó kiểm
soát.

2.2.4.2. Đặc điểm
- Yêu cầu tester phải có kiến thức tốt về hệ thống, về
ứng dụng đang test
- KT tùy hứng được sử dụng nhiều nhất trong kiểm
thử ứng dụng và trò chơi

2.3. Các loại hình kiểm thử
2.3.1. Kiểm thử khói ( Smoke Testing)
2.3.2. Kiểm thử Chức năng ( Functional Testing)
2.3.3. Kiểm thử tính khả dụng
2.3.4. Kiểm thử bảo mật
2.3.5. Kiểm thử hiệu năng
2.3.6. Kiểm thử hồi quy
2.3.7. Kiểm thử phù hợp

2.3.1. Định nghĩa:
Trong phát triển phần mềm thì smoke test là loại test
nhằm đánh giá xem sản phẩm, build được xây dựng bởi dev
có lỗi gì nghiêm trọng hay không để có thể tiếp tục các hoạt
động khác
Smoke testing là một kịch bản kiểm tra nhỏ và nhanh
chóng để kiểm tra các chức năng cơ bản nhất nhưng quan
trọng nhất của hệ thống. Đó là một phép thử đơn giản cho
thấy sản phẩm đã sẵn sàng để cho QA kiểm tra hay chưa, để
tránh cho QA phải lãng phí thời gian và công sức. Việc thực
hiện Smoke test chỉ từ 30 đế 60 phút, nhanh như xử lí khói.
Nếu lâu hơn thì có gì có nghĩa chất lượng của bản build không
tốt hoặc kịch bản kiểm tra chưa đủ đơn giản.

2.3.1.2. Khi nào thì nên thực hiện Smoke test?

2.3.1.2. Khi nào thì nên thực hiện Smoke test?
Smoke test được thực hiện bất cứ khi nào các chức
năng mới được phát triển và tích hợp với bản build hiện tại
đang được triển khai trong môi trường QA / staging. Nó
đảm bảo rằng tất cả các chức năng quan trọng đang hoạt
động chính xác. Trong phương pháp thử nghiệm này, nhóm
QA sẽ xây dựng các kịch bản kiểm thử đơn giản cho các
chức năng cơ bản nhưng quan trọng. Nếu các bài kiểm tra
này được thông qua thì nhóm QA mới thực hiện test toàn bộ
chức năng mới. Nếu xảy ra lỗi trong quá trình smoke test,
bản build sẽ được trả lại cho đội phát triển để hoàn thiện.

2.3.1.3. Ví dụ: Về một một kịch bản test đơn giản
cho chức năng Login: Tại màn hình đăng nhập, có thể đi
đến màn hình kế tiếp bằng cách nhập Username và
Password hợp lệ rồi click vào Login button

2.3.1.4 Ai là người thực hiện Smoke test?
Sau khi có bản build trên môi trường QA, Smoke
testing sẽ được thực hiện bởi QA hoặc QA leader. Ngoài ra
cũng lập trình viên, quản lí dự án hay bất cứ ai cũng có thể
thể thực hiện Smoke test vì nó đơn giản và nhanh chóng.
2.3.1.5. Tại sao phải thực hiện Smoke test?
- Tiết kiệm chi phí
- Mang đến trạng thái ổn định cho hệ thống
- chỉ khi chúng ta hoàn thành smoke test thì mới tiến
hành test các chức năng cụ thể
- Các lỗi được phát hiện ngay từ đầu của quá trình
phát triển

2.3.1.6.Sơ đồ quá trình thực hiện Smoke test:

2.3.2. Kiểm thử chức năng ( Functional Testing)
Kiểm thử chức năng là một loại kiểm thử hộp đen
(black box) và test case của nó được dựa trên đặc tả của ứng
dụng phần mềm/thành phần đang test. Các chức năng được
test bằng cách nhập vào các giá trị nhập và kiểm tra kết quả
đầu ra, và ít quan tâm đến cấu trúc bên trong của ứng dụng.
Nó là một qui trình cố gắng tìm ra các khác biệt giữa đặc tả
bên ngoài của phần mềm và thực tế mà phần mềm cung
cấp. Với các đặc tả bên ngoài của phần mềm là đặc tả chính
xác về hành vi của phần mềm theo góc nhìn của người
dùng.

2.3.2.2. Mục đích
Với kiểm thử đơn vị ta phát hiện sự khác biệt giữa
đặc tả giao tiếp của đơn vị và thực tế mà đơn vị này cung
cấp.
Với kiểm thử hệ thống ta chỉ ra rằng chương trình
không tương thích với các mục tiêu ban đầu của nó. Thì:
Với kiểm thử chức năng ta sẽ hoàn thiện nốt phần cần
xác minh còn lại là chỉ ra rằng chương trình không tương
thích với các đặc tả bên ngoài của nó.
Các lợi ích : ƒ
tránh kiểm thử dư thừa. ƒ
ngăn chặn sự
quan tâm nhiều vào quá nhiều loại lỗi tại từng thời điểm.

2.3.2.2. Mục đích
Thông thường, kiểm thử chức năng gồm c|c bước sau
đ}y:
+ Xác định các chức năng mà phần mềm sẽ thực
hiện.
+ Tạo dữ liệu vào dựa trên các đặc tả chức năng.
+ X|c định các giá trị ra dựa trên các đặc tả chức
năng.
+ Thực thi các trường hợp kiểm thử.
+ So sánh kết quả thực tế với kết quả mong đợi.

2.3.3. Kiểm thử tính khả dụng (Usability Testing)
Kiểm tra tính khả dụng là một kỹ thuật kiểm thử hộp
đen để xác định sản phẩm của bạn có thân thiện với người
dùng hay không, có dễ sử dụng không. Mục đích của kiểm
thử tính khả dụng là làm cho ứng dụng dễ sử dụng, khiến
cho khách hàng/người dùng yêu thích ứng dụng ngay lần
đầu tiên sử dụng.

Ví dụ: Khách hàng mua hàng trực tuyến ở website
– Khi thực hiện ở hệ thống A phải trải qua các bước sau:
- Step 1: Nhập thông tin mua hàng
- Step 2: Nhập thông tin ship hàng
- Step 3: Nhập thông tin thanh toán
-Step 4: Xác nhận đơn hàng
– Khi thực hiện mua hàng ở hệ thống B trải qua các bước như sau:
- Step 1: Nhập thông tin mua hàng, ship hàng, thanh toán
- Step 2: Xác nhận đơn hơn
Như vậy, với hệ thống B người dùng sẽ tiết kiệm thời gian hơn vì
việc setting các thông tin cần tiết cho đơn hàng được thực hiện trên cùng
một step, một giao diện. Hệ thống B sẽ có tính khả dụng cao hơn hệ
thống A.

2.3.3.2. Các thành phần chính của (Usability Testing)
Usability testing bao gồm 5 phần chính:
● Learnability (Khả năng có thể học được): Bạn có thể học cách
dùng phần mềm nhanh đến mức nào?
● Efficiency (Hiệu quả): Bạn có thể thực hiện công việc mong muốn
nhanh đến mức nào?
● Memorability (Khả năng ghi nhớ): Bạn có thể nhớ cách dùng
phần mềm đó nhanh đến mức nào?
● Errors (Lỗi): Mức độ thường xuyên mà bạn gặp lỗi trong phần
mềm đó là như thế nào?
● Satisfaction (Mức độ hài lòng): Bạn thích dùng phần mềm đó đến
mức nào?

2.3.3.2. Các thành phần chính của (Usability Testing)
Usability testing bao gồm 5 phần chính:
– Sau khi xác định được 5 thành phần chính trên, bạn hoàn toàn có
thể xác định được:
● Tính năng cần đưa vào sản phẩm là gì?
● Làm thế nào để các tính năng sử dụng dễ dàng hơn, đem lại cảm
giác dễ chịu cho người dùng?
● Tính năng hữu ích là gì?

2.3.3.3. Ưu và nhược điểm của (Usability Testing)
Nhược điểm:
Nhược điểm chính của usability testing là “khá tốn kém nguồn lực(thời
gian, nhân lực…) và chi phí” để thực hiện.
Ưu điểm:
● Giúp phát hiện sớm các vấn đề về khả năng sử dụng trước khi sản
phẩm được bán ra thị trường
● Cải thiện sự hài lòng của người dùng
● Giúp đem lại cảm giác dễ chịu cho người dùng cuối khi sử dụng sản
phẩm. Nhờ đó sản phẩm được đánh giá cao hơn.
● Giúp thu thập thông tin phản hồi từ đúng đối tượng mục tiêu sẽ sử
dụng sản phẩm của bạn chứ không phải những người dùng ngẫu nhiên
Mặc dù có nhược điểm về chi phí, nguồn lực khi thực hiện nhưng
Usability testing vẫn luôn được khuyến cáo sử dụng vì các chi phí bỏ ra là cần
thiết cho việc duy trì thương hiệu, giữ lại khách hàng và đem lại lợi nhuận lâu

2.3.4. Kiểm thử tính bảo mật(Security Testing)
Kiểm thử bảo mật (Security Testing) là một loại kiểm thử phần
mềm với mục đích phát hiện ra lỗ hổng của hệ thống nhằm bảo vệ dữ
liệu và tài nguyên khỏi những kẻ xâm nhập
Kiểm thử bảo mật thường tập trung vào bốn lĩnh vực sau:
+ An ninh mạng: liên quan đến việc tìm kiếm các lỗ hổng trong
các cơ sở hạ tầng mạng (nguồn lực và chính sách).
+ Bảo mật phần mềm hệ thống: liên quan đến việc đánh giá các
điểm yếu trong các loại phần mềm (hệ điều hành, hệ cơ sở dữ liệu, các
phần mềm khác) mà ứng dụng phụ thuộc vào.
+ Bảo mật ứng dụng phía Client: liên quan đến việc đảm bảo
rằng phía Client (bao gồm trình duyệt hay công cụ nào đó) không bị thao
túng.
+ Bảo mật ứng dụng phía Server: liên quan đến việc đảm bảo
rằng mã máy chủ và công nghệ của nó là đủ mạnh để chống lại bất kỳ sự

2.3.4. Kiểm thử hiệu năng (performance Testing)
Kiểm thử hiệu năng là một loại hình kiểm thử phần mềm
với mục đích xem xét làm cách nào một hệ thống có thể hoạt
động được trong điều kiện có khả năng đáp ứng và sự ổn định
dưới mức cho phép.
2.3.5. Kiểm thử hồi quy (Regression Testing)
Kiểm thử hồi quy (Regression Testing) là một loại
kiểm thử phần mềm nhằm đảm bảo rằng những thay đổi của
phần mềm (trong khi cải tiến hoặc sửa chữa khiếm khuyết)
không làm ảnh hưởng xấu đến chính nó.
2.3.6. Kiểm thử phù hợp

2.3.6. Kiểm thử phù hợp (Compliance Testing)
Kiểm thử phù hợp còn được gọi là kiểm thử hợp chuẩn
(Conformance Testing), kiểm thử quy định (Regulation Testing),
kiểm thử tiêu chuẩn (Standards Testing). Đây là một loại hình
kiểm thử nhằm xác minh tính phù hợp của một hệ thống với các
chuẩn bên trong hoặc bên ngoài

2.4. Các sản phẩm tạo ra trong quá trình kiểm thử

Ưu điểm của kiểm thử đơn vị:

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

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.?

CHUONG 2.pdf

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to CHUONG 2.pdf

Similar to CHUONG 2.pdf (20)

Recently uploaded

Recently uploaded (19)

CHUONG 2.pdf