Effectivesoftwaretesting 131104102937-phpapp01

www.tinhvan.com

CÔNG TY CÔNG NGHỆ TIN HỌC TINH VÂN

Trụ Sở chính

Tầng 8, KS Thể thao,

Làng Sinh viên Hacinco

Quận Thanh Xuân, Hà

Nội

Tel.: +84-4- 5589970,

Fax: 5589971

E-mail:

[email protected]

Văn phòng phía Nam

124 Bắc Hải, phường 6,

Quận Tân Bình, Tp. HCM

Tel.: +84-8-9706066,

Fax.: 9706077

E-mail:

[email protected]

Effective Software Testing 4/14/2023

Hà nội, tháng 06 năm 2006

Công ty Tinh Vân – Lưu hành nội bộ Số trang : 2/78


MỤC LỤC

DANH SÁCH TỪ VIẾT TẮT...........................................................................................4

1. GIAI ĐOẠN ĐẶC TẢ YÊU CẦU.............................................................................5

1.1 Sự cần thiết của testers khi dự án bắt đầu.............................................................5

1.2 Kiểm tra các yêu cầu.............................................................................................6

1.3 Thiết kế test Procedures ngay khi có đặc tả yêu cầu...........................................10

1.4 Các thay đổi của yêu cầu cần được update.........................................................12

1.5 Developing and Testing dựa trên một hệ thống sẵn có.......................................14

2. KẾ HOẠCH TEST...................................................................................................16

2.1. Tráchnhiệm và mục tiêu test...............................................................................17

2.2. Tính toán các rủi ro.............................................................................................20

2.3. Xác định nỗ lực test cần tính đến thời gian bổ sung các chức năng của phần

mềm. 26

2.4. Lưu lại phần mềm trong trí nhớ..........................................................................27

2.5. Bộ dữ liệu test hiệu quả.......................................................................................28

2.6. Kế hoạch cho môi trường test.............................................................................31

2.7. Ước lượng thời gian chuẩn bị test và thời gian thực hiện test............................33

3. TEST PROCEDURE VÀ THIẾT KẾ TEST..........................................................41

3.1. Sự phân chia và thực hiện test.............................................................................42

3.2. Sử dụng Template Test Procedure và các tiêu chuẩn thiết kế test khác.............47

3.3. Việc chuyển hoá thành các test cases từ yêu cầu của khách hàng......................50

3.4. SRS là tài liệu không thể không có (như tài liệu sống còn) của quá trình test

(“Living" Documents)....................................................................................................53

3.5. Sử dụng các Prototypes.......................................................................................54

3.6. Các kỹ thuật test được sử dụng khi thiết kế kịch bản test...................................55

3.7. Tránh sự ràng buộc và chi tiết các yếu tố dữ liệu trong các test cases................58



3.8. Áp dụng Exploratory Testing (test qua toàn bộ chương trình)...........................59

4. CÔNG CỤ TEST TỰ ĐỘNG..................................................................................61

4.1. Các loại testing tools...........................................................................................61

4.2. Xây dựng 1 tool thay cho việc mua một tool......................................................66

4.3. Ảnh hưởng của Automated Tools đến nỗ lực test...............................................68

4.4. Tập trung vào những gì mà công ty cho là cần thiết...........................................72

4.5. Kiểm tra tool bằng các Prototype........................................................................75



DANH SÁCH TỪ VIẾT TẮT

STT TỪ VIẾT TẮT NỘI DUNG

1 PM Project Manager

2 PL Project Leader

3 PQA Process quanlity Asurance

4 SQA Software quanlity Asurance

5 TL Test Leader



1. GIAI ĐOẠN ĐẶC TẢ YÊU CẦU

Chương trình test sẽ hiệu quả nếu được bắt đầu ngay khi dự án bắt đầu, có nghĩa khi này,

các tester đã phải nghiên cứu SRS dần dần, và nó kéo dài cho đến trước khi viết code.

Đầu tiên tài liệu đặc tả yêu cầu sẽ được phê duyệt; tiếp đến trong các giai đoạn sau của dự

án, việc test tập trung vào để đảm bảo việc coding của chương trình là đúng. Như vậy,

việc sửa lại chương trình sẽ có chi phí thấp nhất do sớm loại bỏ được những lỗi không

đúng với yêu cầu khách hàng đưa ra trước khi thiết kế chi tiết hay coding. Một tài liệu

đặc tả yêu cầu cho một ứng dụng hay một hệ thống phần mềm cuối cùng cũng phải mô tả

được các chức năng chi tiết cơ bản của ứng dụng hay hệ thống phần mềm cần phải đạt

được. Một trong những khó khăn lớn nhất để phát triển tài liệu đặc tả là việc giao tiếp,

tiếp xúc với người đưa ra các yêu cầu đó để làm sao hiểu được và nắm được các yêu cầu

họ đưa ra. Từng yêu cầu phải được bắt đầu một cách chính xác, đúng và rõ ràng. Nếu

vậy, thì người đọc các yêu cầu đó sẽ hiểu chúng một cách đúng nhất, và thống nhất. Nếu

có tính nhất quán trong tài liệu đặc tả thì người đi khảo sát sẽ tập hợp được toàn bộ các

yêu cầu một cách hiệu quả nhất. Một yêu cầu được đưa ra càng sớm thì nó sẽ được kiểm

tra và lọc bằng cách hỏi khách hàng những câu hỏi chi tiết. Các dạng câu hỏi đưa ra để

hỏi khách hàng rất đa dạng để đảm bảo rằng các yêu cầu đưa ra phải có tính logic với

nhau và mọi người hiểu chúng theo cùng một nghĩa.

1.1 Sự cần thiết của testers khi dự án bắt đầu.

Các Testers cần phải tham gia từ khi dự án bắt đầu để họ có thể hiểu chính xác những gì

họ phải test và có thể làm việc với các khách hàng khác để tạo ra các yêu cầu có thể test.

Ngăn chặn lỗi là cách sử dụng các kỹ thuật và qui trình để giúp phát hiện ra lỗi và tránh

các lỗi đó trước khi các lỗi đó được nhân rộng trong các giai đoạn phát triển sau đó. Việc

ngăn chặn lỗi hiệu quả nhất là khi bắt đầu viết đặc tả người dùng vì nếu các yêu cầu được

cố định, không thay đổi thì việc phát hiện ra lỗi là thấp nhất: Chỉ có những sự thay đổi

yêu cầu mới được phản ánh vào tài liệu đặc tả và từ đó sẽ thay đổi test plan. Nếu testers

(cùng với các khách hàng khác) được tham gia từ đầu của 1 dự án, họ sẽ giúp nhận ra sự



thiếu xót, sự không nhất quán, sự không rõ ràng và những vấn đề khác có thể ảnh hưởng

đến chất lượng và tính đúng đắn của dự án.

Một yêu cầu có thể được coi như đã thông qua nếu như có thể thiết kế 1 qui trình trong đó

các chức năng có thể test được, và kết quả mong đợi là rõ ràng.

Testers cần hiểu thống nhất về một sản phẩm để từ đó họ có thể test tốt hơn và hoàn

thành test plans, thiết kế, tài liệu, và các test case. Nếu nhóm test được tham gia sớm thì

sẽ loại trừ được sự lộn xộn về các chức năng của phần mềm. Thêm vào đó, sự tham gia

ngay từ đầu sẽ cho phép nhóm test biết được tổng thể chương trình, nhóm test sẽ đóng vai

trò là người cuối cùng để phê bình và hạn chế rủi ro một cách tối đa. Các kiến thức thu

được sẽ đảm báo cho các tester ưu tiên tập trung test các phần quan trọng nhất, tránh việc

test các phần không cần thiết như các phần rất ít khi được sử dụng.

Các tester cần đứng trên vai trò của cả người dùng, người lập trình và khách hàng để test.

Đối với các dự án nhỏ thì có thể các tester sẽ tìm được hết các lỗi mà không cần tham gia

ngay từ đầu dự án. Nhưng đối với các dự án lớn và phức tạp thì không thể mong các

tester tìm hết ra các lỗi quan trọng nếu họ chỉ được tham gia khi phần mềm đã được

coding xong.

Không chỉ cần hiểu về đầu vào và đầu ra của chương trình, các tester cần phải hiểu sâu

hơn về những gì có thể xảy thông qua quá trình sử dụng trong suốt quá trình đặc tả các

chức năng. Việc hiểu kỹ đặc tả không chỉ làm tăng chất lượng phần mềm và phát triển

test Procedure mà còn cho phép các tester phản hồi lại những gì chưa hợp lý hay còn

thiếu trong SRS. Chương này sẽ đưa ra cách làm thế nào để tìm ra các lỗi một cách sớm

nhất và các loại lỗi đó là lỗi như thế nào.

Bảng 1.1 Table 1.1 Phân lớp các chi phí liên quan để sửa lỗi từ khi nó chưa được phát

hiện đến khi được phát hiện.



1.2 Kiểm tra các yêu cầu.

Trong tác phẩm của Christopher Alexander, ông ta đã chỉ ra rằng, việc chỉ ra rõ ràng các

yêu cầu là phải mô tả được cách thức thành lập việc đo lường chất lượng cho mỗi yêu

cầu: “ Ý tưởng đó là mỗi yêu cầu đều có độ chính xác để có thể đưa ra được các giải pháp

cho các yêu cầu đó. Các giải pháp đưa ra được sếp vào một trong hai loại là đáp ứng hay

không đáp ứng yêu cầu”. Hay nói cách khác, một yêu cầu có chất lượng có nghĩa yêu cầu

đó phải được chỉ ra một cách rõ ràng, từ đó đưa ra một số giải pháp cho nó. Một số giải

pháp sẽ được chấp nhận còn một số khác thì không.

Việc đo lường chất lượng yêu cầu được sử dụng để kiểm tra hệ thống mà đi ngược với

các yêu cầu đó.

Sự cố gắng xác định đơn vị đo lường chất lượng để đưa ra các yêu cầu hợp lý, rõ ràng. Ví

dụ, mọi người đồng ý với câu sau: “ hệ thống phải cung cấp các giải pháp tốt” nhưng mỗi

người lại có cách hiểu khác nhau về thế nào là một giải pháp tốt. Đôi khi yêu cầu mà

khách hàng đưa ra sẽ có giải pháp tốt đáp ứng được, nhưng đôi khi chúng lại không có

giải pháp tối ưu để thoả mãn yêu cầu đó. Một giải pháp sẽ chứng tỏ yêu cầu đã rõ ràng

hay chưa rõ ràng.

Điều quan trọng là các nguyên tắc để phát triển yêu cầu và tài liệu phải được xác định từ

khi bắt đầu dự án. Trong các phần mềm nhỏ, việc phân tích kỹ các yêu cầu đảm bảo hệ

thống phát triển đúng cách. Các Use cases là một cách để phản ánh các yêu cầu về chức

năng một phần mềm cần có, từ đó có thể hoàn thiện test hệ thống và các test Procedure.

Trong tài liệu này, hầu như chỉ giới hạn lại ở một số yêu cầu để chứng minh cho một vài



đặc tả để phục vụ cho việc viết các testcase và một số loại tài liệu khác khi mô tả chức

năng của hệ thống.

Ngoài các yêu cầu về chức năng cần có thì một hệ thống cũng phải quan tâm đến các yêu

tố phi chức năng như đảm bảo là chạy được và có tính bảo mật, quá trình thao tác nhanh

chóng, tiện lợi.

Như vậy chúng ta phải lựa chọn công nghệ và mức độ rủi ro. Những yêu cầu phi chức

năng đòi hỏi hệ thống có những chức năng đặc trưng, đòi hỏi phải xác định một cách chặt

chẽ cách thức mà hệ thống thực hiện các chức năng là như thế nào.

Các yêu cầu chức năng phải đi đôi với các yêu cầu phi chức năng.( Chương 9:Thảo luận

về các yêu cầu phi chức năng)

Các tester sẽ liệt kê những mục cần test trong suốt giai đoạn đặc tả yêu cầu nhằm kiểm

tra, xác minh lại các yêu cầu. Xác định những mục cần test là bước đầu tiên để bắt lỗi của

chương trình so với yêu cầu, do đó, các lỗi này sẽ không phát triển được trong các giai

đoạn sau nên việc sửa lỗi sẽ có chi phí thấp hơn và dễ dàng hơn. Tất cả các khách hàng

phải có trách nhiệm với những yêu cầu được đưa ra và thông qua các thuộc tính của các

yêu cầu đó.

Sự chính xác của các yêu cầu.

Sự chính xác của các yêu cầu cần xét đoán dựa trên những gì người dùng muốn. Ví dụ,

như các nguyên tắc hay qui định có cần rõ ràng hay không? Các yêu cầu có phản ánh một

cách chính xác như người dùng đã đưa ra hay không? Điều cấp thiết là khi người dùng

cuối cùng, hay một đại diện thích hợp phải có những liên quan, ràng buộc nhau trong suốt

giai đoạn của các yêu cầu.

Sự chính xác cũng có thể được xem xét trên những tiêu chuẩn nhất định. Vậy những tiêu

chuẩn đó là gì?

Completeness.

Sự hoàn thành đảm bảo rằng tất cả các yêu cầu đều được đáp ứng. Mục tiêu là tránh khỏi

những yêu cầu không rõ ràng một cách đơn giản nhất vì những yêu cầu này thường

không có những câu hỏi đúng hay không được khảo sát đúng đối với các nguồn lực thích

hợp.

Các Testers nên nhấn mạnh vào sự kết hợp với giữa yêu cầu chức năng và các yêu cầu

phi chức năng như việc thực hiện của chương trình, tính bảo mật, các tiện ích, sự tương

thích và khả năng truy cập, vì những yêu cầu phi chức năng được mô tả cùng với các yêu

cầu chức năng. Các yêu cầu phi chức năng thường được chia thành 2 bước:



1. Khi hệ thống có tính mở thì các yêu cầu phi chức năng sẽ được đưa ra. Ví dụ, giao diện

người dùng của hệ thống WEB phải tương thích với cả trình duyệt Netscape

Navigator 4.x hay cao hơn, và trình duyệt Microsoft Internet Explorer 4.x hay cao hơn.

2. Mỗi đặc tả yêu cầu nên có cả đoạn tiêu đề “ tài liệu yêu cầu phi chức năng” để mô tả

một số yêu cầu phi chức năng đặc biệt

Tính ổn định của hệ thống.

Tính ổn định của hệ thống có nghĩa là hệ thống sẽ không có mâu thuẫn giữa yếu tố bên

trong và bên ngoài, giữa các thao tác trong 1 module và giữa các module với nhau. Xét về

câu hỏi “ Sự đặc tả là xác định nội dung bản chất của các yêu cầu. Chúng ta có thể xác

định các yếu tố trong yêu cầu một cách rõ ràng và tỷ mỉ. Ví dụ, một đặc tả sử dụng thuật

ngữ “viewer” ở nhiều nơi trong tài liệu nhưng với các ý nghĩa khác nhau tuỳ thuộc vào

từng văn cảnh và đây là nguyên nhân trong việc thiết kế và coding sẽ có nhiều chỗ không

rõ ràng và nhất quán, khi này yêu cầu đúng nhưng bị thiết kế không chuẩn.

Sự thẩm tra xác minh một yêu cầu.

Sự thẩm tra xác minh một yêu cầu tạo ra các tình huống kiểm thử với kết quả mong đợi là

rõ ràng và có thể thấy ngay được. Nếu một yêu cầu không được test hay nói cách khác là

không được thẩm tra, kiểm thử, về thực tế và theo logic thì rủi ro là rõ ràng và yêu cầu

phải được điều chỉnh.

Tính khả thi của một yêu cầu.

Tính khả thi của một yêu cầu đảm bảo yêu cầu đó được thực hiện với số tiền cần thực

hiện, thời gian thực hiện, công nghệ và những nguồn lực khác được qui định.

Necessity.

Sự cần thiết kiểm thử, thẩm tra mọi yêu cầu trong đặc tả liên quan tới hệ thống. Để test

logic và sự cần thiết, các tester phải test ngược lại với mục tiêu cần đạt được của hệ

thống. Phải chăng yêu cầu này đóng góp vào các kết quả? Hay nó có thể ngăn không cho

hệ thống đạt được mục tiêu? Những yêu cầu khác phụ thuộc vào yêu cầu này? Một số yêu

cầu không thực sự phải là yêu cầu nhưng nó lại đóng góp vào mục tiêu của giải pháp .

Tính ưu tiên.

Tính ưu tiên cho phép mọi người hiểu các giá trị liên quan tới các yêu cầu của khách

hàng. Kết quả của tính ưu tiên được mô tả bởi 5 mức từ 1 đến 5 để đánh giá chất lượng

của một hệ thống là tốt hay không tốt so với yêu cầu đề ra, và nếu không tốt thì sẽ bị phạt

bao nhiêu tiền. Nếu một yêu cầu bắt buộc phải đáp ứng và nó có ý nghĩa sống còn đến sự

thành công của hệ thống thì buộc phải có và phải chuẩn, nhưng nếu yêu cầu đó không



quan trọng đến mức đó thì có thể có hình thức là phạt tiền. Các bên có thể đưa ra thứ tự

ưu tiên cần thiết và các quyết định dựa trên sự thoả hiệp để từ đó thiết kế hệ thống. Cái

đích cần đạt được là phải cân bằng được giữa các yêu cầu của mỗi người dùng, chi phí,

rủi ro liên quan tới các yêu cầu.

Tính rõ ràng.

Tính rõ ràng là đảm bảo các yêu cầu đưa ra phải rõ ràng. Ví dụ một yêu cầu không rõ

ràng như sau: “ Hệ thống phải đáp ứng một cách nhanh chóng mọi yêu cầu của khách

hàng”. Nhanh chóng chỉ mang nghĩa chủ quan và do đó yêu cầu đó là không thể đáp ứng

được. Một khách hàng có thể nghĩ nhanh chóng nghĩa là chỉ trong vòng 5 giây trong khi

người lập trình cần đến 3 phút. Ngược lại, một lập trình nghĩ rằng chỉ cần 2 phút hoàn

thành nhưng kỹ sư thiết kế hệ thống cần nhiều thời gian hơn thế.

hả năng kết hợp và theo dõi các yêu cầu.

Khả năng kết hợp đảm bảo mỗi yêu cầu được xác định theo 1 cách mà nó sẽ kết hợp với

tất cả các phần khác của hệ thống nơi mà nó sẽ được sử dụng. Khi yêu cầu thay đổi có thể

xác định được tất cả các phần khác của hệ thống thay đổi theo.

Đối với đặc tính này, mỗi yêu cầu coi như xác định độc lập. Điều cần thiết là phải liên kết

các yêu cầu lại với nhau để hiểu được ảnh hưởng của nó tới các yêu cầu khác. Như vậy là

phải phân chia một khối lượng lớn các yêu cầu rồi liên kết chúng lại . Suzanne Robertson

đưa ra ý kiến nên cố gắng xử lý đồng thời mọi yêu cầu một lúc, tốt hơn là chia nhỏ các

yêu cầu thành các nhóm để quản lý. Điều này có thể dựa trên nội dung của các yêu cầu

hoặc dựa trên tính ưu tiên. Để làm được điều đó, sự kết nối được hiện theo 2 bước: thứ

nhất là liên kết các yêu cầu trong cùng 1 nhóm, thứ 2 là kết hợp các yêu cầu giữa các

nhóm.Nếu các yêu cầu được nhóm lại sao cho việc kết nối giữa các nhóm là nhỏ nhất thì

sự phức tạp của việc theo dõi, kết hợp các yêu cầu sẽ là nhỏ nhất.

Việc kết hợp, theo dõi cũng cho phép tập hợp các thông tin về những yêu cầu và các phần

khác trong hệ thống có thể bị ảnh hưởng một khi yêu cầu này thay đổi như việc thiết kế,

code, test, help…Khi yêu cầu bị thay đổi, các tester phải chắc chắn rằng các mục, các

phần liên quan sẽ bị ảnh hưởng. Nếu các yêu cầu là đơn lẻ thì có thể xem xét lại và có thể

bắt đầu test lại theo sự thay đổi đó. Phát hiện lỗi sớm có thể giảm được các lỗi gây lên

những phần không đúng với yêu cầu. Từ đó, thiết kế sẽ chặt chẽ hơn và chi phí sửa lỗi sẽ

thấp và việc sửa lỗi dễ dàng hơn.

Sau những bước trên, các ứng dụng sẽ hoàn thiện hơn và sẽ cho phép tổ chức thực hiện,

lập kế hoạch, theo dõi tiến độ và test.



1.3 Thiết kế test Procedures ngay khi có đặc tả yêu cầu.

Các kỹ sư phần mềm thiết kế dựa trên tài liệu đặc tả yêu cầu. Và tài liệu này là rất cần

thiết để nhóm test thiết kế test Procedure. Trong một vài tổ chức, việc thiết kế test

Procedure thực hiện sau khi phần mềm đã được xây dựng xong và cài đặt cho nhóm test,

do vậy sẽ bị thiếu thời gian và thực hiện test không tốt. Điều này là vấn đề cố hữu, và như

vậy sẽ bị bỏ qua một số yêu cầu hay lỗi sẽ bị phát hiện muộn hơn, thậm chí sau khi sự án

kết thúc và không thể test được.

Việc viết test Procedure cố gắng phải thực hiện ngay sau khi có tài liệu đặc tả. Vì như vậy

test Procedure sẽ có ích hơn. Trong quá trình viết test Procedure sẽ thấy, phát hiện được

những thiếu xót, luồng công việc không đúng và những lỗi khác. Khi test thì nên cố gắng

làm ảnh hưởng đến hệ thống với những mức độ đặc biệt, tạo ra các bộ dữ liệu đầu vào

đặc biệt. Quá trình này buộc phải tạo ra các kịch bản cho các yêu cầu. Nếu không bao

quát hết được các trường hợp thì cần phải bổ sung các trường hợp đó khi phát hiện. Nếu

quá trình này sớm được thực hiện thì việc ảnh hưởng đến thiết kế sẽ giảm đi hoặc các giai

đoạn sau sẽ cần ít thời gian hơn.

Như đã nói ở phần 1, việc phát hiện lỗi sớm làm giảm chi phí. Nếu lỗi được phát hiện ở

các giai đoạn sau thì có thể phải thay đổi các yêu cầu, thiết kế, code, mà điều đó làm ảnh

hưởng đến số tiền mà bên nhà cung cấp nhận được, ảnh hưởng đến kế hoạch, và tinh

thần. Tuy nhiên, nếu lỗi được phát hiện ngay khi có đặc tả thì cần xem xét lại tài liệu đó,

xem các đặc tả đó đã đúng hay chưa. Quá trình xác định những lỗi hay thiếu xót khi xây

dựng test Procedure là sự đề cập đến việc thẩm tra lại tài liệu đặc tả đó. Nếu tài liệu đó

mà thiếu thông tin hay thông tin không rõ để có thể xây dựng một test Procedure, cụ thể

là không làm được những test cases thì tài liệu đó không thể test được và có thể không

thiết kế được phần mềm. Test là để đảm bảo yêu cầu được thực hiện và có thể có những

lỗi ngoại lệ trong khi test.

Những ngoại lệ đó phải rõ ràng. Ví dụ, với yêu cầu là “dữ liệu các trường phải được lưu

lại trong các bản ghi trong vòng 3 năm” không thể thông qua ngay lập tức được. Tuy

nhiên, yêu cầu này không nhất thiết phải như vậy.

Nếu một yêu cầu không được thông qua thì không có gì đảm bảo rằng nó sẽ được thực

hiện đúng. Để đảm bảo phát triển test Procedure thì trong test case phải nêu rõ bộ dữ liệu

đầu vào là gì, các bước thao tác và kết quả mong đợi rõ ràng cho mỗi yêu cầu. Như vậy

thì sẽ không bị bỏ qua các yêu cầu quan trọng. Sự phát triển test Procedure càng sớm

được thực hiện sẽ cho phép phát hiện ra những phần chưa được thông qua. Nếu việc này



được thực hiện sau khi phần mềm đã coding xong và ghép xong mới gửi cho các tester thì

test Procedure không tốt là đương nhiên bởi họ không có đủ thời gian. Ví dụ, test

Procedure có thể bị thiếu các trường hợp, hoặc có thể kết quả mong đợi là không đúng

hay bộ dữ liệu đưa vào không chuẩn. Và kết quả là lỗi vẫn xảy ra hay yêu cầu không

được thực hiện, thậm chí phần mềm bị thất bại.

Các đánh giá sớm về các yêu cầu của ứng dụng có thể là nền tảng, cốt lõi cho việc xác

định chiến lược test. Trong khi xem xét các yêu cầu, các tester cần xác định những gì cần

test, ví dụ, họ sử dụng các công cụ test, kỹ thuật test nào để bắt lỗi; phần nào có thể test

thủ công, phần nào cần đến các test tool. Trong quá trình test, họ cần xác định các yêu

cầu tính toán phức tạp, đa dạng để test nhiều hơn hay phải có những kịch bản đặc biệt.

Việc viết test Procedure phải được bắt đầu khi giai đoạn đặc tả yêu cầu kết thúc và sẽ

được lặp lại, bổ sung nếu phát hiện thêm lỗi. Tuy nhiên tài liệu này cũng có mức độ ưu

tiên cho các chức năng nào cần test trước dựa vào tài liệu đặc tả. Theo ý tưởng thì các

yêu cầu sẽ được chuyển cho các tester để họ xác định lại các yêu cầu và tạo kịch bản test.

Quá trình test phải được ưu tiên dựa trên kế hoạch thực hiện của dự án. Nếu thời gian gấp

quá thì ưu tiên cho test xem chương trình có chạy được không rồi mới đến test cụ thể các

yêu cầu sau đó.

Các yêu cầu thường là được lọc và phân tích thông qua việc xem xét, kiểm tra. Thường

thì một yêu cầu mới đưa ra sẽ có một kịch bản rõ ràng trong suốt giai đoạn thiết kế và

phát triển. Mọi người nói rằng tất cả các chi tiết của các yêu cầu nên được giải quyết

trong giai đoạn khảo sát. Tuy nhiên, thực tế các yêu cầu cầu này thường được tiếp tục bổ

sung sau đó. Nếu các yêu cầu này được lặp lại sau đó của quá trình thì quá trình test cũng

cần lặp lại.

Để quản lý hiệu quả các yêu cầu phát sinh mới và việc test chỉ cần quan tâm tới phần phát

sinh đó thì phải có sự gắn kết chặt chẽ giữa các bộ phận trong cả quá trình làm việc của

dự án. Nhìn vào phần 4 dưới đây ta sẽ thấy tầm quan trọng của việc giao tiếp, trao đổi với

khách hàng để nhanh chóng nắm bắt được những thay đổi của yêu cầu.

1.4 Các thay đổi của yêu cầu cần được update.

Khi qui trình test dựa trên tài liệu đặc tả, thì khi yêu cầu thay đổi, nhóm test cần phải

được thông tin ngay. Thật vậy, Nếu thay đổi của yêu cầu mà khác so với hệ thống thì phải

được update vào tài liệu đặc tả. Tester phải chịu trách nhiệm đối với sự phát triển và chạy

được của hệ thống nên nếu trong quá trình test, có sự thay đổi về yêu cầu mà họ không



được thông báo thì dẫn đến báo cáo lỗi sai, không đạt được mục đích của test và lãng phí

thời gian.

Đây là một trong những nguyên nhân dẫn đến quá trình thống kê gặp các vấn đề sau:

Sự thay đổi không có cơ sở.

Ví dụ một người nào đó như PM, người giao dịch với khách hàng, người phân tích biết có

sự thay đổi nhưng không nói và update cho lập trình hay update vào tài liệu thì lập trình

sẽ làm theo cái cũ, và nó là điều không phù hợp, không đúng với yêu cầu của khách hàng

đặt ra. Quá trình, thủ tục cần phải rõ ràng cho các developer, đặc biệt khi có thay đổi của

yêu cầu. Điều này thường được gọi là “Change Control Board”, “Engineering Review

Board” hay cơ chế tương tự sẽ được thảo luận ở bên dưới.

Tài liệu đặc tả cũ, lỗi thời.

Một sự thiếu xót của tester hay sự mô tả nghèo nàn có thể là nguyên nhân dẫn đến một

tester đưa ra một kế hoạch test hay test Procedure không tốt (vì tester này làm việc với

phiên bản cũ của tài liệu đặc tả). Các yêu cầu cần được update vào tài liệu này và phải

được đặt dưới sự quản lý (gọi là các baseline)và cần được sự thông qua của tất cả mọi

người có liên quan.

Lỗi phần mềm.

Các developer có thể lập trình không đúng với yêu cầu đặt ra mặc dù tài liệu đặc tả và các

tài liệu khác tham khảo là đúng. Và cuối cùng thì kết quả test được báo cáo. Tuy nhiên,

nếu các thay đổi của yêu cầu không được update thì các kịch bản trong các test cases

chưa chắc đã xảy ra. Vậy phải chăng vấn đề rắc rối gặp phải của bất kỳ 1 phần mềm nào

là do tài liệu đặc tả, test Procedure hoặc tất cả những điều nêu ra ở trên? Để tránh xa

những vấn đề gặp phải đã nói ở trên thì tất cả các yêu cầu thay đổi phải được update,

đánh giá và thông qua của tất cả mọi người liên quan. Như vậy cần phải có sự quản lý

quá trình thay đổi yêu cầu, và quá trình này phải tạo thuận lợi cho mọi người.

Nếu muốn có 1 yêu cầu chính xác thì quá trình thay đổi yêu cầu cần phải đánh dấu thành

những chương, mục để thuận lợi cho việc thiết kế, coding và các tài liệu khác liên quan

như các test Procedure.

Để quản lý có hiệu quả quá trình này, những thay đổi phải có căn cứ và đánh dấu thành

các version khác nhau.

Sự thay đổi đó phải được xét trên các điểm sau: Yêu cầu đó được thay đổi khi nào, và

thay đổi đó là thay đổi cái gì, do ai yêu cầu và thay đổi đó bắt nguồn từ đâu? Quá trình



thay đổi này có thể phải viết lại tài liệu đặc tả từ đầu và cần được review lại, deign lại,

coding lại, defect tracking, và test lại.

Mỗi 1 yêu cầu thay đổi có thể có 1 tài liệu khác chứa đầy đủ các thông tin cần thiết về sự

thay đổi đó. Và nó được tập hợp lại trong Change Control Board (CCB). Tổ chức 1

CCB để đảm bảo rằng sự thay đổi 1 yêu cầu hay những yêu cầu khác phải tuân theo một

quá trình đặc tả. Một CCB thường chứa các thông tin tiêu biểu về những nhóm quản lý

như nhóm quản lý sản phẩm, quản lý yêu cầu, nhóm QA cũng như nhóm test và quản lý

mạng.

Tất cả các khách hàng đều phải đánh giá các sự thay đổi, các đề xuất theo khía cạnh về độ

ưu tiên, mức độ rủi ro. Ví dụ, khi 1 yêu cầu bị thay đổi, nó có thể ảnh hưởng đến toàn bộ

test Procedure, đến nhiều yêu cầu khác và nỗ lực test hay việc thực hiện yêu cầu thay đổi

đó thì sẽ thay đổi toàn bộ các kỹ thuật test hay công cụ test tự động. Và sự ảnh hưởng đó

phải được xác định, phải được trao đổi trước khi sự thay đổi đó được phê duyệt. CCB xác

định được giá trị của sự thay đổi đó, sự ảnh hưởng của nó, sự cần thiết và mức độ ưu tiên

( Ví dụ, Nếu các thay đổi đó dù được thực hiện ngay lập tức hay không thì nó cũng phải

được thể hiện bằng tài liệu cụ thể trong quá trình thực hiện dự án)

CCB phải đảm bảo rằng, yêu cầu mới được đưa ra phải đánh giá được mức độ rủi ro liên

quan và quá trình ra quyết định phải được thể hiện bằng tài liệu và được thông qua.

Điều cần thiết là tất cả các phần thay đổi đưa ra cần nhận biết được, để cho phép chúng ta

phân tích được độ rủi ro, làm giảm bớt những ảnh hưởng của nó đến các yêu cầu khác.

Để đảm bảo thực hiện được điều này là sử dụng “requirements-management tool”.

Công cụ này có thể được sử dụng để theo dõi sự thay đổi yêu cầu cũng như thay đổi test

Procedure.

Nếu các yêu cầu thay đổi được phản ánh và update trong các tool này thì tool này sẽ đánh

dấu lại chúng và ước lượng được sự ảnh hưởng của chúng đến việc test ra sao (các yếu tố

khác bị ảnh hưởng như design, coding…cũng được đo lường mức độ ảnh hưởng), do đó

các phần tương ứng của sản phẩm cũng bị ảnh hưởng theo. Mọi người sẽ có các thông tin

mới nhất thông qua tool này.

Thông tin thay đổi được quản lý thông qua tool cho phép các testers đánh giá lại khả năng

test theo yêu cầu được thay đổi cũng như ảnh hưởng của nó đến các test Procedure đã làm

như kế hoạch test bị thay đổi ra sao….Khi này tài liệu, test procedure phải được xem xét

và update lại để thích hợp với sự thay đổi đó. Trước khi bắt lỗi thì phải đánh giá lại để

xác định các yêu cầu mới so với các yêu cầu cũ khác nhau như thế nào?



Nếu như kịch bản test hay các cơ chế test đã được thiết lập thì chúng cần được update.

Khi quá trình được xác định là mang lại những thuận lợi, tiện ích khi có sự thay đổi của

yêu cầu thì chương trình test sẽ là hiệu quả và do đó dự án thành công.

1.5 Developing and Testing dựa trên một hệ thống sẵn có.

Trong rất nhiều dự án phát triển phần mềm, sản phẩm được hoàn thành mà không có tài

liệu đặc tả hay tài liệu này rất sơ sài vì nó dựa trên cấu trúc sẵn có và giờ chỉ việc thiết kế

lại và nâng cấp. Hầu hết các tổ chức, module trong các phần mềm này đã có, và việc test

chỉ là test phần thay đổi so với phần mềm đã có mà không mất thời gian phân tích hay

viết tài liệu cho các chức năng. Về hình thức mà nói thì dự án phần mềm này sẽ kết thúc

sớm hơn và giao cho khách hàng sớm hơn.

Nhưng thật tiếc thay, tất cả các dự án dù là dự án nhỏ nhất thì chiến lược sử dụng các ứng

dụng đã có sẵn cũng gặp rủi ro cho dù yêu cầu khác nhau không đáng kể, do chức năng

không thích hợp hay việc test không được thực hiện.

Thật khó có để kiểm tra phần mềm được thiết kế trên phần có sẵn vì dữ liệu đầu vào có

thể khác nhau và phần mềm không thực hiện được.

Trong 1 số trường hợp, nguyên nhân do dữ liệu đầu vào làm ảnh hưởng, rối loạn đến dữ

liệu đầu ra. Và đó sẽ là nguyên nhân mà developers đưa ra phỏng đoán tốt nhất về việc

sai khác giữa 2 phần mềm.

Tuy nhiên, trong nhiều trường hợp thì các phần mềm dựa trên phần có sẵn vẫn hoạt động

và được phát triển mặc dù nó được cấu trúc khác và công nghệ là lỗi thời (ví dụ về màn

hình là khác hay các version Web là khác nhau), và nó tiếp tục được bảo dưỡng và thêm

các chức năng mới cần thiết.

Người có liên quan sẽ chịu trách nhiệm về sản phẩm mới này sẽ không biết trước các lỗi

có thể xảy ra do không có tài liệu đặc tả. Hầu hết các ước lượng lỗi của phần mềm chỉ là

ngẫu nhiên, không chuẩn.

Về hình thức mà nói thì lợi ích khi thiết kế một phần mềm mới dựa trên cái có sẵn là rõ

ràng và rất lớn. Khi này các tester có thể so sánh đầu ra của cái cũ với cái mới, nếu nó

không khác nhau thì 2 phần mềm này là tương tự nhau. Tuy nhiên, điều này là không an

toàn. Vì nếu đầu đầu ra của phần mềm cũ mà sai trong 1 vài kịch bản thì điều gì sẽ xảy

ra? Nếu phần mềm mới đúng thì đầu ra của phần mềm cũ là sai…. hay nếu phần mềm

mới mà chạy được thì test Procedure xây dựng cho nó và đầu ra của 2 sản phẩm này là

khác nhau. Như vậy nếu như các yêu cầu không được thể hiện bằng các tài liệu thì làm

cách nào để tester biết chắc chắn rằng đầu ra là đúng?



Chỉ khi sự phân tích phải được thực hiện trong suốt quá trình tổng hợp yêu cầu để xác

định kết quả mong đợi.

Mặc dù phần mềm mới được dựa trên phần mềm đã có sẵn nhưng có khi các yêu cầu của

chúng lại khác nhau, như vậy cách thức để quản lý trong trường hợp này là xem xét kết

quả mong đợi, tức đầu ra của chúng là gì.

Sử dụng 1 application đã được fix.

Tại sao một ứng dụng mới buộc phải dựa trên một version đặc biệt của 1 ứng dụng cũ?

Dự án mới phải chọn 1 version của ứng dụng đã có và đó là version ban đầu.

Khi làm việc với 1 version của 1 application đã được fix thì việc theo dõi lỗi sẽ thực tế

hơn, chuẩn hơn. Kể từ khi chọn version đó thì phải xác định lỗi của application mới là ở

đâu mà không quan tâm tới việc application cũ đã được nâng cấp, sửa lỗi và lỗi đó không

còn.

.Tài liệu của application cũ

Bứơc tiếp theo để có 1 tài liệu cụ thể về application mới là mỗi một đặc trưng thì viết ít

nhất 1 đoạn thể hiện, đưa ra nhiều kịch bản và kết quả mong đợi. Có thể, sẽ phân tích đầy

đủ các trường hợp có thể xảy ra. Nhưng thực tế lại phải quan tâm tới thời gian và nỗ lực

của người test phải bỏ ra nên việc kiểm tra hết các trường hợp là không thể.

Hầu hết các tài liệu đặc tả của application mới không đầy đủ mà chỉ có giao diện người

dùng. Nếu giao diện này không đủ thì có nghĩa tài liệu này không đạt yêu cầu.

Tài liệu của application cũ nhưng đã được update.

Update có nghĩa là thêm hay thay đổi yêu cầu cho application đó.Và nó sẽ là căn cứ cho 1

application mới sau này mà application dựa trên application này.

Điều này sẽ cho chúng ta sự phân tích rõ ràng các chức năng sẵn có và tạo ra design và

test Procedure thích hợp. Nếu application cũ chạy tốt thì tài liệu đặc tả, test Procedure và

những tài liệu khác vẫn có thể sử dụng cho appliction mới.

Nếu viêc update không được thực hiện thì việc phát triển sản phẩm mới cũng bị ảnh

hưởng. Sự mâu thuẫn giữa cái được kế thừa và application mới sẽ xẩy ra. Một số mâu

thuẫn giữa 2 application này là tương tương, trong khi một số khác thì không, một số mâu

thuẫn thì được dự đoán trước trong khi một số khác thì chỉ được phát hiện ở giai đoạn

test.

Implement an effective development process going forward.

Mặc dù hệ thống cũ được phát triển mà không có tài liệu đặc tả yêu cầu, design hay test

Procedure, nhưng bất kể khi nào có chức năng mới phát sinh thì không chỉ application



trước mà cả application mới các developers phải chắc chắn rằng quá trình phát triển đó

được xác định, và được thông qua để tránh đưa ra những sản phẩm tồi.

Sau những bước trên, các chức năng mới phải được đặt dưới sự kiểm soát để có thể tổ

chức, lập kế hoạch, theo dõi lỗi và test các chức năng thêm mới tốt hơn.

2. KẾ HOẠCH TEST.

Cơ sở nền tảng để có một chương trình test thành công là phải có một kế hoạch test.

Một kế hoạch test thích hợp đòi hỏi phải có hiểu biết chung về quá trình phát triển phần

mềm để đưa ra yêu cầu thực hiện thích hợp.

Kế hoạch phải được đặt ra càng sớm càng tốt khi dự án bắt đầu. Bởi vì khi đó chương

trình test được đặt ra và được thực hiện thành công hiệu quả hơn là khi code xong mới

lên kế hoạch test. Khi này, testers hiểu được trách nhiệm của mình cần làm những gì để

có thể ước lượng được nỗ lực cũng như xác định những test tool nào cần thiết cho việc

test để đề nghị mua hay được đào tạo.Và khi chương trình ra đời là bắt tay vào test được

ngay. Ngoài ra, tester còn biết được yêu cầu phần cứng phải đáp ứng là như thế nào.

Kế hoạch được vạch ra sớm cho phép lịch test và ngân sách được ước lượng, được phê

duyệt và cuối cùng là tập hợp lại thành kế hoạch của toàn bộ dự án.

Khi này, thời gian để mua các test tool và chuẩn bị test hay nói cách khác là thời gian

chuẩn bị môi trường test và cài đặt chương trình để test, database và các phần khác cần có

để test sẽ sớm được hoàn thành.

Không phải các nỗ lực test đều như nhau. Một kế hoạch test hiệu quả yêu cầu phải hiểu

rõ ràng về tất cả các phần vì nó ảnh hưởng đến kết quả test. Thêm vào đó, kinh nghiệm và

sự hiểu biết về test là rất cần thiết, bao gồm kỹ thuật test, quá trình test, và các tool, để

chọn chiến lược test hiệu quả áp dụng vào test chương trình.

Việc xây dựng chiến lược test , rủi ro, ngưồn lực, thời gian và tiền bạc phải được coi

trọng. Sự hiểu biết về các kỹ thuật test và cách thức sử dụng chúng là rất cần thiết để ước

lượng, đánh giá nguồn lực, trách nhiệm, bao gồm số người tham gia test, cần bao nhiêu

người có kinh nghiệm, vai trò và trách nhiệm của mỗi người, thời gian và tiền bạc.

Có nhiều cách để xác định nỗ lực, bao gồm các phương pháp tỷ số và sự so sánh các nỗ

lực trong quá khứ của các dự án tương tự cần test. Việc xác định này sẽ đưa ra một nhóm

testers thích hợp.

2.1. Trách nhiệm và mục tiêu test



Nói chung test là việc kiểm thử phần mềm nhằm đảm bảo chúng phải đạt được tiêu chuẩn

đề ra và thoả mãn yêu cầu của khách hàng. Nếu test tốt thì các lỗi được hạn chế, thậm chí

là hết lỗi sẽ giúp các chức năng của phần mềm này hoạt động đúng, chuẩn, do vậy mức

độ hài lòng của khách hàng là cao nhất. Mục tiêu của test là tìm lỗi và xoá bỏ chúng tạo

lên phần mềm hoàn chỉnh.

Một chương trình với các chức năng chạy đúng khi:

Bộ dữ liệu đầu vào đúng thì đầu ra cũng phải đúng

Bộ dữ liệu đầu vào không đúng thì chương trình sẽ không cho nhập và có thông báo

lỗi hiện lên.

Chương trình không bị treo hay crash khi đưa vào các bộ dữ liệu đúng hay sai

Chương trình chạy đúng và cho kết quả mong đợi

Chương trình đáp ứng được cả các yêu cầu chức năng và yêu cầu phi chức năng.

(chương 9, thảo luận về các yêu cầu phi chức năng)

Không thể test hết được các trường hợp của tất cả các bộ dữ liệu đầu vào, của các kịch

bản, các yêu cầu chức năng và phi chức năng.

Chiến lược Test cần được xác định để hỗ trợ đảm bảo kết quả là cao nhất. Thường thì

không thể fix tất cả các lỗi mà vẫn còn có lỗi trong phần mềm. Vì vậy, phải xác định lỗi

nào cần được ưu tiên test trước. Không nhất thiết và cũng không cần nhiều chi phí để fix

tất cả các lỗi trước khi bàn giao.

Các mục tiêu test các chức năng, vai trò khác nhau là khác nhau. Ví dụ, mục tiêu test các

chức năng của chương trình khác so với test cấu hình. Người lập kế hoạch test thường là

các test leader và họ phải có trách nhiệm xác định mục tiêu test là gì? Nỗ lực test là bao

nhiêu? Mục tiêu test dựa trên tiêu chuẩn của từng hệ thống.

Sự hiểu biết về trách nhiệm, phạm vi và mục tiêu test liên quan, cần thiết là những điểm

đầu tiên cần có trong một kế hoạch test. Kế hoạch test yêu cầu phải rõ ràng trong các

bước, vì như thế mới đạt được mục tiêu của test.

Vậy cách nào để đạt được điều đó? Thứ nhất, tài liệu đặc tả phải chuẩn theo các template

đặt ra, xây dựng kế hoạch test (trong đó bao gồm chiến lược test). Tiếp đến là tách các

yêu cầu thành các chức năng riêng biệt. Và cuối cùng là trao đổi giữa nhóm test với bên

design và developer.

Các yêu cầu để lập 1 Test Plan:

Hiểu hệ thống.



Hiểu toàn bộ hệ thống bao gồm việc hiểu về các yêu cầu chức năng và phi chức năng.

Nhóm test bắt buộc phải hiểu tất cả các yêu cầu này. Đọc những vấn đề rời rạc như “ Hệ

thống nên ….” trong tài liệu đặc tả sẽ cung cấp một bức tranh toàn cảnh bởi vì các kịch

bản và các chức năng đều từ đó mà ra. Tài liệu sẽ bao gồm các yêu cầu, các kết quả mong

đợi cần có. Các tài liệu khác cũng giúp hiểu sâu hơn về hệ thống như tài liệu “high-level

business requirements”, các trường hợp trong quản lý chất lượng sản phẩm và các tình

huống khác trong kinh doanh. Ví dụ, một hệ thống hỗ trợ phân phối thuốc thì yêu cầu hầu

như không được có bất kỳ lỗi nào, còn các hệ thống kinh doanh thì có thể chấp nhận phần

trăm lỗi nhất định.

Sự liên quan, gắn kết và trao đổi trong nhóm test.

Test leader và các thành viên của nhóm test cần có mối quan hệ chặt chẽ với nhau trong

suốt quá trình test kể từ khi quyết định đầu tiên về yêu cầu 1 hệ thống được đưa ra. Khi

sự liên quan với nhau được thực hiện thì mọi người sẽ trao đổi với nhau nhiều hơn, từ đó

rủi ro của phần mềm sẽ giảm xuống.

Hiểu rõ quá phát triển phần mềm.

Kiến thức về những đặc đỉêm chung, cơ bản và quá trình phát triển phần mềm là cần thiết

để thực hiện được mục tiêu test. Mặc dù mỗi thành viên trong nhóm test đều nỗ lực để

phát triền sản phẩm, nhưng một vài giai đoạn trong quá trình phát triển sản phẩm cần có

vai trò của các SQA và PQA.

Test leader cần có cái nhìn xuyên suốt để có thể đưa ra chiến lược test hiệu quả để hoàn

thành mục tiêu của test. Ví dụ:

o Phải chăng nỗ lực test bao gồm nỗ lực của các thành viên độc lập, trái với việc kết hợp

giữa nhóm design và nhóm developer?

o Có phải một "chương trình cuối cùng” (extreme programming) là chương trình đang

thực hiện và testers phải theo phương pháp của chương trình đó hay không?

o Nhóm test là cổng cuối cùng mà một phần mềm phải đi qua và phải chăng nhóm test

chịu hoàn toàn trách nhiệm về chất lượng của phần mềm?

Phạm vi thực hiện.

Ngoài việc hiểu về các vấn đề của hệ thống, còn phải hiểu về các vấn đề chung và phạm

vi mà nhóm test phải làm. Từ đó xác định được phạm vi test.

Kết quả mong đợi.



Những kết quả mong đợi nào cần quản lý? Những kiểu test nào mà khách hàng mong

đợi? Ví dụ, người dùng cuối cùng sẽ yêu cầu những gì khi test? Các kết quả mong đợi tại

các giai đoạn test là gì? Các câu hỏi này được trả lời trong kế hoạch của dự án.

Những bài học.

Các bài học được rút ra từ trước khi có nỗ lực test? Các thông tin quan trọng của các bài

học này rất quan trọng khi xác định chiến lược test và xác định kết quả mong đợi thực tế.

Các mức nỗ lực.

Nỗ lực để xây dựng lên hệ thống là gì? Sẽ cần bao nhiêu developer để thực hiện hệ thống

này? Các thông tin này rất có ích và phục vụ nhiều mục đích khác nhau. Để ước lượng,

tính toán được các chỉ tiêu trên cần xác định mức độ phức tạp của phần mềm yêu cầu? nỗ

lực của test là bao nhiêu? Và điều này dựa trên tỷ lệ của developers và testers là bao

nhiêu? (Xem phần sau của chương thảo luận cách thức đo lường các nỗ lực của test).

Các giải pháp.

Giải pháp cuối cùng và phức tạp nhất sẽ được thực hiện hay những giải pháp mà chi phí

là hiệu quả nhất sẽ được thực hiện? Các giải pháp này yêu cầu thời gian lập trình là ít

nhất?Để biết rõ, chọn lựa được thì người lập kế hoạch phải hiểu được các kiểu test được

yêu cầu.

Lựa chọn công nghệ.

Công nghệ nào sẽ được chọn để thực hiện phát triển phần mềm này? và những yếu tố

tiềm năng nào liên quan khi lựa chọn công nghệ đó? Kiểu kiến trúc hệ thống nào được sử

dụng? sản phẩm là các ứng dụng, hay cấu trúc client –server hay ứng dụng web? Những

thông tin này sẽ được xác định trong chiến lược test và các test tool được chọn.

Budget.

Số tiền bỏ ra là bao nhiêu để thực hiện, làm ra một phần mềm, bao gồm cả tiền đối với nỗ

lực test bỏ ra. Những thông tin này sẽ giúp xác định kiểu test phù hợp với mức độ phù

hợp. Nhưng thực tế, số tiền được xác định làm lên một phần mềm lại không tính đến nỗ

lực test bỏ ra.

Thời gian test (lịch test )

Thời gian dành cho sự phát triển và test là bao nhiêu? Deadline là gì? Nhưng thời gian

cho testing được ước lượng không đúng. Yêu cầu test leader phải lập lịch khít với thời

gian kết thúc dự án.

Giải pháp cho từng giai đoạn.



Việc thực hiện một dự án được chia ra thành nhiều giai đoạn. Và mỗi giai đoạn có các

giải pháp riêng. Việc test có thể thực hiện theo từng giai đoạn và chúng có mức độ ưu

tiên và do đó việc test cũng được thực hiện theo độ ưu tiên đó.

Thêm vào đó, thời gian test là cần thiết để xác định số tiền và lịch test cụ thể và những

phần cần thiết khác. Cũng như phần cứng cần đáp ứng để tạo môi trường hoạt động cho

phần mềm đó, những đánh giá, mua bán và thực hiện của các test tool. Nếu như việc lập

kế hoạch được thực hiện sớm thì cơ hội lựa chọn được test tool thích hợp sẽ rất cao và

vận hành được test tool đó là hoàn toàn có thể làm được.

2.2. Tính toán các rủi ro

Chương trình Test được lập, các điều kiện xảy ra đối với chương trình và những rủi ro

phải được tính toán trước khi đưa ra chiến lược test. Vấn đề này bao gồm các sự kiện,

hoạt động, hoàn cảnh có thể xảy ra đối với chương trình test khi thực hiện test theo lịch

đã định, ví dụ như sự phê duyệt số tiền được thực hiện muộn, trì hoãn việc trang bị các

công cụ, phương tiện để test hay phần mềm ghép xong muộn.

Chiến lược test bao gồm các hoạt động đặc biệt phải được thực hiện để đạt được các

mục tiêu đặt ra. Nhiều yếu tố phải được quan tâm khi đưa ra chiến lược test. Ví dụ, kiến

trúc hệ thống gồm nhiều lớp trồng lên nhau.

Nói chung chiến lược test phải kết hợp chặt chẽ các yếu tố để giảm rủi ro ở mức thấp nhất

về lỗi, chi phí ít nhất, thời gian ít nhất hay những lỗi khác. Trong suốt quá trình lập chiến

lược test thì phải có sự ràng buộc, liên quan của các yếu tố, bao gồm sự rủi ro, nguồn lực,

giới hạn thời gian, giới hạn số tiền.

a. Một chiến lược test tốt sẽ thu hẹp trách nhiệm của bên test với các điểm sau:

Hiểu cầu trúc hệ thống.

Chia nhỏ hệ thống thành những lớp riêng rẽ như giao diện người dùng hay cách thức tiếp

cận database. Hiểu về cấu trúc hệ thống sẽ giúp testers xác định được chiến lược test cho

mỗi lớp hệ thống đó hay sự kết hợp giữa các lớp đó với nhau. (Việc thảo luận, bàn bạc

rộng hơn về vấn đề này sẽ được nghiên cứu tại chương thiết kế cấu trúc hệ thống)

Xác định xem có áp dụng GUI testing hay các chương trình test phụ trợ hay áp dụng

cả hai.

Khi đã hiểu cấu trúc hệ thống thì người ta sẽ tìm ra cách thức tốt nhất để test thông qua

giao diện người dùng ( GUI), chương trình test phụ trợ hay cả hai. Hầu hết các nỗ lực

test yêu cầu việc test được áp dụng trong cả 2 mức độ, ví dụ giao diện người dùng thường

chứa mã, các chuẩn mực được sử dụng và thẩm tra.



Khi xác định được chiến lược test, các testers nên ghi nhớ toàn bộ các trường hợp phức

tạp, các mức yêu cầu mang tính nghiệp vụ, các loại test phụ trợ nhiều hơn là test giao

diện người dùng. Sở dĩ như vậy là do ngôn ngữ và công nghệ để làm nên được một sản

phẩm phần mềm là rất phức tạp. Ví dụ, các testers cũng nên hiểu ngôn ngôn ngữ C++ khi

lập trình chương trình bằng ngôn ngữ C++, hay GUI tools và GUI testing, mặt khác, chưa

kể đến các chương trình rộng hơn, các kỹ năng nói chung, các nghiệp vụ chuyên sâu

(điều này phụ thuộc vào các kiểu test) có thể yêu cầu cao hơn. Khi xác định kiểu test cho

việc triển khai chiến lược test, các testers nên qua tâm đến các bộ dữ liệu đưa vào các

trường khi test.. Ví dụ, mục đích của các application là phát triển, tập trung vào giao diện

người dùng, có khi chiếm tới 75% chức năng của chương trình, còn 25% là test phân lớp

( Vấn đề rủi ro lớn nhất khi test các application).

Không thể sử dụng 75% thời gian để test phân lớp chức năng bởi vì chức năng chính cần

test là test giao diện người dùng.

Theo lý thuyết thì kịch bản GUI sẽ được đề cập nhiều và nó dường như thành thói quen ít

khi bị bỏ qua. Nếu không thì điều cần thiết là phải thực hiện phân lớp chức năng (test

business level).

Chẳng hạn như tỷ lệ cần xứng là 75/25 cho test GUI và business-layer testing có thể yêu

cầu 2 phần test GUI và 1 developer test business-layer . Thêm vào đó, testers test theo

vùng sẽ sử dụng tất cả các kỹ thuật test phụ thuộc vào qui mô và độ phức tạp của các

application ( test tự động sẽ được bàn đến trong chương 8)

Low-level testing có thể không cần thiết tới 75% của application cho các record chuẩn và

các mô hình update các record. Tuy nhiên, test GUI yêu cầu đưa ra các bộ dữ liệu trống

hay những thiếu xót của màn hình tại giao diện đó.

Ví dụ trên đã giải thích được rằng điều quan trọng là tại sao chiến lược test phải quan tâm

tới rủi ro, sự phức tạp và các yếu tố cần thiết. Đây không phải là điều cứng nhắc, tuy

nhiên, mỗi một dự án yêu cầu sự phân tích riêng của dự án đó.

Chọn lựa kỹ thuật test.

Việc thu hẹp các kiểu kỹ thuật test nhằm giúp giảm bớt sự kết hợp và đa dạng của các dữ

liệu đầu vào. Các kỹ thuật test rất đa dạng và nó phải được xác định như một phần của

chiến dịch test. Một vài kỹ thuật test sẽ được bàn đến trong chương 5.

Chọn lựa công cụ test.



Khi chiến lược test được đưa ra, testers phải xác định các công cụ test được sử dụng, bao

gồm test thủ công hay test bằng các tool nào? Nếu cần thiết sẽ xây dựng nên một tool

riêng thay vì phải mua test tool đó. Chương 7 sẽ bàn về các công cụ test tự động.

Tiến hành viết kịch bản và khai thác công cụ test.

Người thiết kế test những gì sẽ quyết định phát triển các công cụ test tự động. Họ sẽ đưa

ra các kiến thức về test thủ công và các loại công cụ test tự động hiện có trên thị trường.

Nếu các thao tác test không thể thực hiện bằng tay thì tiến hành viết kịch bản và khai thác

các công cụ test tự động trên những kịch bản đã viết đó.

Xác định nhân lực và kinh nghiệm yêu cầu.

Căn cứ vào chiến lược test phác thảo sẽ có được yêu cầu về nhân lực và kinh nghiệm của

cá nhân đó cần có. Nếu như một phần chiến lược test phải sử dụng công cụ test tự động

thì buộc phải có người hiểu về công cụ test tự động đó. Và điều cần thiết đặt ra là cần

phải có cả những người test về lĩnh vực đặc biệt đó, hay còn hiểu là test sâu về nghiệp vụ.

Nếu nhóm test không có các kỹ năng test tốt thì sẽ gây nguy hiểm và ảnh hưởng tới sự

thành công của phần mềm đó. Điều này sẽ được bàn đến trong chương 3.

Xác định phạm vi test.

Testers phải hiểu được phạm vi cần test là những gì. Trong một vài trường hợp, ví dụ có

thể có văn bản xác nhận, trong đó liệt kê tất cả các chức năng được yêu cầu test hay phạm

vi test. Trong một số trường hợp khác thì testers phải tự xác định phạm vi test, nguồn lực

test, lịch test, công cụ test, rủi ro, các phần không cần test. Trong đó, đầu tiên testers phải

thể hiện bằng tài liệu những phần cần test và những phần có thể bỏ qua, không cần test.

Thiết lập những phần, những tiêu chuẩn được loại bỏ.

Việc xác định phạm vi test có liên quan mật thiết tới việc xác định các tiêu chuẩn tồn tại.

Release criteria chỉ ra rằng công việc test phải được coi như hoàn thành, do đó, điều

quan trọng là chúng phải được thể hiện dưới hình thức văn bản trước đó.

Ví dụ, Tiêu chuẩn để loại bỏ có thể là những phần có rất ít lỗi và lỗi là rất nhẹ. Bất kể khi

nào thì các lỗi nguy hiểm hay những lỗi làm cho chương trình không chạy được phải

được fix trước khi xác định loại bỏ những phần nào. Những phần có thể bỏ qua khác có

thể được xác định rõ ràng với những chức năng được ưu tiên ở mức độ cao.

Lập lịch test.

Chiến lược test phải được xác định trước để xác định nỗ lực test. Lập lịch chi tiết cho việc

test là rất quan trọng để tránh việc thực hiện chiến lược test không đúng như yêu cầu đặt

ra.



Quan tâm tới các giai đoạn test.

Các giai đoạn test khác nhau áp dụng các chiến lược test khác nhau. Ví dụ, trong suốt giai

đoạn test chức năng của chương trình, việc kiểm thử các chức năng xem nó có hoạt động

được không. Vậy, kế hoạch đặt ra chiến lược test đó áp dụng cho giai đoạn nào của hệ

thống.

Hiểu các giai đoạn test là rất cần thiết để đưa ra các chiến lược test cho mỗi giai đoạn.

Có vài vấn đề cần được quan tâm khi đưa ra chiến lược test.

Nếu không có đủ thời gian để hiểu hệ thống một cách tường tận thì để hiểu được rủi ro

của dự án là rất khó khăn, mà điều này lại rất quan trọng khi xây dựng chiến lược test.

Kịch bản rủi ro phải được lập trước đó và cần được quản lý. Để khắc phục được vấn đề

này thì nhóm test phải ưu tiên cho những yêu cầu và rủi ro cố hữu trong mỗi giai đoạn.

Nhóm test phải xem xét lại các chức năng chuẩn và các phần rủi ro cao của hệ thống, và

quan tâm tới các thông tin này khi xác định mức độ ưu tiên cho các yêu cầu cần test.

Khi xác định thứ tự các phần cần test, nhóm test nên xem xét lại các yêu cầu để đảm bảo

rằng phần nào cần được ưu tiên, kể từ các chức năng chuẩn nhất đến các chức năng

không chuẩn nhất. Dữ liệu đầu vào của người dùng cuối cùng được xác định liên quan

chặt chẽ tới sự quan trọng của chức năng. Danh sách các yêu cầu ưu tiên nên được nhóm

test liệt kê cụ thể. Thêm vào đó, các phần ưu tiên của các chức năng rất có ích để nhóm

các yêu cầu thành các nhóm chức năng liên quan hay thành các kịch bản, các luồng công

việc.

b. Danh sách các các tiêu chuẩn dưới đây nhằm xác định thứ tự các nhóm yêu

cầu dựa trên yêu cầu của Rational Software Corporation.

Mức độ rủi ro.

Sau khi đã đánh giá rủi ro, yêu cầu test ưu tiên được đưa ra nhằm đảm bảo giảm mức rủi

ro cho cho hệ thống. Các khoản mục có độ rủi ro cao có thể là những chức năng nhập mà

không cho nhập dữ liệu vào hệ thống, ví dụ, các nguyên tắc làm việc có thể làm phá vỡ

cấu trúc dữ liệu hay kết quả là vi phạm các nguyên tắc đó.

Tính chất hoạt động.

Một số yêu cầu test được sắp xếp theo thứ tự ưu tiên bởi vì chúng được áp dụng cho các

chức năng thường xuyên được sử dụng hay những phần kiến thức bị thiếu hụt của người

sử dụng cuối cùng. Các chức năng gắn liền với các nguồn lực kỹ thuật hay những người

mới bắt đầu sử dụng hay những chức năng không được thường xuyên sử dụng đến thì sẽ

đứng cuối cùng trong thứ tự ưu tiên.



Yêu cầu người dùng.

Một vài yêu cầu test có tính chất quan trọng, ảnh hưởng tới sự chấp nhận của người dùng.

Nếu việc test không nhấn mạnh vào các yêu cầu này, kết quả phần mềm sẽ gặp lỗi hoặc

đặt công ty sản xuất phần mềm trong tình trạng không có lợi về mặt tài chính. Và điều

quan trọng là nó ảnh hưởng trực tiếp tới người dùng cuối cùng và sẽ ảnh hưởng tới khách

hàng tiềm năng của công ty trong tương lai.

Nguồn lực sẵn có:

Yếu tố đầu tiên trong test Procedure là nguồn lực sẵn có. Như đã thảo luận trước đó, thiết

kế test có sự ràng buộc, bao gồm giới hạn nhân lực tham gia test, giới hạn phần cứng và

tính đối lập của các yêu cầu của dự án. Đây là quá trình khó khăn của việc thoả hiệp thực

hiện.

c. Hầu hết rủi ro xảy ra do các nguyên nhân sau.

Thời gian hoàn thành phần mềm để cài đặt cho khách hàng ngắn.

Thời gian dự án nên dành nhiều hơn cho phía lập trình.

Như đã đề cập trước đó, ngân sách và thời gian xác định cho 1 dự án rất khắt khe, trong

kế hoạch phát triển, không có thời gian cho cho nhân lực test, mà việc hoàn thành và cài

đặt 1 phần mềm cho khách hàng chỉ thông qua việc tham khảo kinh nghiệm hay những kỹ

thuật đo lường hiệu quả khác. Một người quản lý test tốt cần hiểu một cách chắc chắn,

nhanh nhạy về hệ thống khi thời gian xây dựng hệ thống có giới hạn. Chiến lược test phải

thích hợp, vừa khớp với thời gian đã được căn sẵn. Nếu có vấn đề cấp thiết thì cần chỉ ra

ngay lập tức để còn điều chỉnh chiến lược test hoặc chấp nhận rủi ro của hệ thống nếu

không có thời gian dành cho việc test.

Qui trình thiết kế mới.

Giới thiệu về qui trình thiết kế mới, bao gồm các công cụ thiết kế, kỹ thuật thiết kế và độ

rủi ro gia tăng.

Công nghệ mới.

Nếu công nghệ mới được thực hiện, rủi ro xảy ra là có thể công nghệ đó không chạy

được. Nó sẽ hiểu lầm yêu cầu, hay thực hiện không đúng các yêu cầu, mà cũng có thể các

yêu cầu sẽ bị chắp vá.

Sự phức tạp.



Việc phân tích các tài liệu để test phải được thực hiện để xác định chức năng nào là phức

tạp nhất và tập trung tìm kiếm lỗi trong chức năng đó và các phần khác chịu ảnh hưởng

của lỗi đó như thế nào. Nhóm test lên tập trung vào chức năng đó.

Mức độ sử dụng thường xuyên của người dùng.

Các chức năng thường xuyên được sử dụng luôn tiềm ẩn lỗi (lỗi của hệ thống) và có khả

năng rủi ro cao nếu phần này bị lỗi. Vì vậy, phần nào người dùng sử dụng nhiều cần được

test kỹ hơn.

Các yêu cầu không test.

Các yêu cầu chức năng và phi chức năng nếu không được test (bị bỏ xót) thì rủi ro hệ

thống không thành công là rất cao. Tuy nhiên, nếu nhóm test kiểm tra, nghiên cứu các

yêu cầu này trong giai đoạn nghiên cứu đặc tả yêu cầu của phần mềm (được xem xét

trong chương 1), thì những rủi ro này là nhỏ nhất.

Khi rủi ro xảy ra, chúng ta cần đánh giá, sau đó tìm cách khắc phục nhằm giảm rủi ro.

Việc đánh giá rủi ro quan tâm tới khả năng, xác suất xảy ra rủi ro và sử dụng một vài mô

hình để nhận diện rủi ro cũng như lên chiến lược giảm rủi ro. Tầm quan trọng và mức độ

ảnh hưởng của rủi ro cũng cần được đánh giá. Chiến lược giảm rủi ro nên được xác định

cho các yêu cầu có khả năng xảy ra rủi ro cao nhất. Thường thì chương trình cho phép

chứa một vài lỗi, nhưng các lỗi này ít khi xảy ra do người dùng ít khi sử dụng. Vấn đề

khó khăn là làm cách nào để đánh giá rủi ro một cách chi tiết nhất. Mọi người nên tập

trung đóng góp cho quá trình đánh giá này, ngay cả nhóm dại diện khách hàng(quản lý

sản phẩm) , người dùng cuối cùng, các đặc tả yêu cầu, phía lập trình, testers và QA.

Mức độ rủi ro cần được thông báo, đưa ra cho mọi người cùng biết để cùng có quyết định

giảm thiểu, ngăn chặn chúng. Nếu rủi ro quá cao, hệ thống rất có thể không chạy được, bị

tạm ngừng hay gián đoạn.

Phân tích rủi ro đưa ra các thông tin hỗ trợ test manager hay test leader ra quyết định

thích hợp như phân công nhân sự test có kinh nghiệm, có kỹ năng tốt nhằm test kỹ để

tránh, giảm rủi ro.

Sau khi đánh giá rủi ro, xác định được các yếu tố dẫn đến rủi ro là gì, và rủi ro có thể xảy

ra là gì, các phần bị ảnh hưởng. Từ đó, đưa ra hướng giải quyết.

Chiến lược góp phần giảm rủi ro: Test engineer hay test manager cần xác định các phần

rủi ro nhất, các phần có thể có nhiều lỗi nhất, và tập trung vào chúng.

Mặt khác, phải xác định các vấn đề, công việc cần làm để giảm rủi ro, và mức độ ảnh

hưởng là nhỏ nhất.



Việc kiểm tra cẩn thận các mục tiêu cần đạt, độ rủi ro là cần thiết nhằm đưa ra chiến lược test hợp lý.

2.3. Xác định nỗ lực test cần tính đến thời gian bổ sung các chức năng của phần

mềm.

Việc thực hiện các tính năng của phần mềm phải có tính ưu tiên. Sự ưu tiên này dựa vào

yêu cầu của khách hàng hay sự cần thiết phải đưa ra được các yếu tố rủi ro đầu tiên. Tuy

nhiên, kế hoạch test và kế hoạch phát triển không chỉ dựa vào tính ưu tiên và mức độ rủi

ro mà còn dựa vào thời gian bổ sung các tính năng của phần mềm để có thể test tiếp và

hoàn thành công việc test của 1 dự án.

Điều quan trọng là thời gian bổ sung các tính năng của phần mềm, bao gồm thời gian bổ

sung các chuỗi hành động có liên quan tới quá trình test, do vậy, trong kế hoạch test cần

có thời gian cho việc test bổ sung này. Chúng ta sẽ thấy tác dụng của vấn đề này hơn

trong việc thời gian test là có hạn. Không nên thay đổi thường xuyên lịch của các tính

năng vì nếu có 1 thay đổi tính năng dẫn đến thay đổi trong kế hoạch phát triển hay kế

hoạch test.

Chức năng ưu tiên là chức năng chủ yếu và đặc biệt của chương trình. Trong hầu hết các

trường hợp, lịch của phía phát triển nên tập trung cho các chức năng chủ yếu, quan trọng

đầu tiên. Testers cũng sẽ test các chức năng này đầu tiên.

a. Danh sách các chức năng ưu tiên test trước dựa vào các tiêu chuẩn khác

nhau:

Giảm rủi ro:

Như đã thảo luận, chúng ta cần quan tâm đến mức độ rủi ro được xem xét trong kế hoạch

phát triển và chiến lược test ra sao. Các chức năng có độ rủi ro cao thì cần ưu tiên và tốn

nhiều nỗ lực hơn.

Giảm độ phức tạp:

Cả phía phát triển và test cố gắng ưu tiên thực hiện chức năng có tính phức tạp nhất.

Những điều khách hàng yêu cầu và cần thiết.

Khuynh hướng của hầu hết các dự án phần mềm ưu tiên cho các chức năng mà khách

hàng yêu cầu và cần thiết. Các chức năng này sẽ được lấy làm chuẩn, cốt lõi để marketing

và bán sản phẩm.

Ràng buộc về ngân sách.



Phần lớn các dự án phần mềm đều vượt quá ngân sách cho phép đối với phần mềm đó.

Điều cần quan tâm là phải chú trọng vào ngân sách dành cho phía test khi test các chức

năng ưu tiên. Vì các chức năng này mang tính quyết định sự thành công của phần mềm.

Ràng buộc về thời gian.

Vấn đề cần quan tâm là sự ràng buộc về thời gian khi test các chức năng có tính ưu tiên

không được quan tâm đúng mức, không được quản lý rõ ràng.

Ràng buộc về con người.

Khi lập lịch cho các chức năng ưu tiên thì người lập lịch nên chú ý, quan tâm tới nhân lực

đã có sẵn. Những người chủ chốt sẽ thực hiện test các chức năng này sẽ đảm bảo không

bị xót trường hợp vì thời gian và một số vấn đề khác là có giới hạn và bị ràng buộc.

2.4. Lưu lại phần mềm trong trí nhớ.

Khi lên kế hoạch test thì tester phải hiểu được các vấn đề sau của phần mềm:

Bản Beta hay bản trước khi cài đặt chính thức cho khách hàng.

Nhóm phát triển sẽ bổ sung các chức năng còn thiếu vào các bản Beta với công nghệ

riêng rẽ. Nhưng khi test thì phải test chúng trên nhiều công nghệ khác nhau để đưa ra

đánh giá cho phía phát triển càng sớm càng tốt.

Công nghệ mới hay công nghệ sắc bén.

Sự bổ sung, thay đổi công nghệ dễ dẫn đến sự sụp đổ hệ thống. Trong một số trường hợp

công nghệ mới có thể gây ra nhiều vấn đề và phải lập trình lại. Ví dụ, mục đích của lập

trình là thực hiện 1 giải pháp sử dụng phiên bản Beta nhưng khi phiên bản này đã ra đời,

thì việc thay đổi công nghệ đồng nghĩa với việc phải thiết kế, cấu trúc lại hệ thống. Mà

điều này có nghĩa, hệ thống cần phải test lại, nỗ lực test tăng lên.

Thực hiện các giai đoạn.

Ưu tiên thực hiện phiên bản đầu tiên của hệ thống vì các chức năng đã có sẵn. Ví dụ, hệ

thống phải trả ra giao diện người dùng khi nhập dữ liệu vào và giao diện này phải có dữ

liệu đó nếu dữ liệu là hợp lệ. Kế hoạch test phải đưa ra các điều kiện lựa chọn khác nhau

cho việc xử lý và lưu dữ liệu.

Lỗi.

Lỗi có thể được phát hiện từ 1 trong những phần có vấn đề vì test Procedure không thể

thực hiện toàn bộ tất các tình huống cụ thể. Trong giai đoạn cấu trúc hệ thống, phải ưu

tiên việc tìm ra các lỗi nếu hệ thống có nhiều lỗi để sửa. Để vận dụng một cách thích hợp,

đúng đắn giải pháp này, cần có sự trao đổi giữa testers và lập trình để sửa ngay lỗi khi

phát hiện.



Phần mềm đóng gói hay từng phần.

Bên cung cấp phần mềm có trách nhiệm cập nhật chính xác các phiên bản và giới thiệu về

các chức năng mới. Nếu hệ thống chưa được test sẽ thiếu tính chân thực khi cập nhật các

thông tin về chương trình. Do vậy, trong kế hoạch test cũng cần xác định nỗ lực cho các

lần test các phiên bản mới. Ví dụ, khi một phiên bản mới ra đời, nhiều người sẽ cập nhật

phiên bản mới này. Nếu phiên bản mới không được test sẽ không đảm bảo nó tốt hơn cái

cũ.

2.5. Bộ dữ liệu test hiệu quả.

Trong suốt quá trình thiết kế chi tiết các test procedures ( được nói đến trong phần 3), dữ

liệu test cần được kết hợp chặt chẽ trong các test cases, hay nói cách khác nó được tạo

thành một vòng quay dữ liệu. Chiến lược test hiệu quả yêu cầu có bộ dữ liệu cần thận. Sẽ

là không hiệu quả nếu test chức năng với bộ dữ liệu nghèo nàn. Ngược lại, với bộ dữ liệu

tốt giúp nâng cao hiệu quả của việc test chức năng, giảm nỗ lực test. Khi các yêu cầu của

khách hàng còn mơ hồ thì việc chuẩn bị bộ dữ liệu chuẩn sẽ giúp khách hàng tập trung,

hiểu rõ các giao dịch, thao tác mà họ cần.

Một bộ dữ liệu chuẩn và tài liệu thiết kế test chi tiết có ích rất nhiều cho phía phát triển.

Thêm vào đó, bộ dữ liệu chuẩn còn cho thấy cấu trúc của dữ liệu, thành phần của bộ dữ

liệu chuẩn, nguyên tắc sử dụng và những thông tin hữu ích khác. Tài liệu thiết kế, giản đồ

database đặc biệt cũng có thể giúp xác định cách thức ảnh hưởng của hệ thống tới

database ra sao. Không thể test hết sự kết hợp giữa các bộ dữ liệu đầu vào và đầu ra. Tuy

nhiên, các kỹ thuật test cũng giúp giảm bớt các bộ dữ liệu đầu vào và ra và sự kết hợp

giữa chúng. Sự kết hợp luồng dữ liệu trong các test case, giúp cho việc xác định đường

dẫn cho các dữ liệu này.

Test điều kiện biên là một kỹ thuật test khác. Dữ liệu test được chuẩn bị cho từng giá trị

biên (giới hạn số lượng và nội dung dữ liệu, thiết đặt trong phần thiết kế hệ thống). Hệ

thống thường thay đổi giá trị biên của chúng. Lỗi thường xảy ra ở phần giá trị biên nên

vấn đề là phải có kỹ thuật xác định đúng được các giá trị biên. Các giá trị biên nên được

liệt kê thành 1 danh sách trong tài liệu đặc tả yêu cầu. Ví dụ, “hệ thống sẽ cho phép nhập

liệu giá trị từ 1 đến 100 trong danh sách các quyền lựa chọn. Trong ví dụ này, các giá trị

cần test là 101, 99, 100 và 1, không nhập giá trị nào và giá trị 0. Khi giá trị biên không

được mô tả trong SRS, khi lập kế hoạch test, phải tìm hiểu hệ thống và đưa ra các giá trị

biên cần test. Và điều này lại rất phổ biến. Lập trình thường không xác định được giá trị

biên cho đến khi chương trình được test và tester trao đổi lại.



Có cách kiểm tra để phát hiện giá trị biên của chương trình là sử dụng các prototypes.

Chiều sâu của vấn đề.

Nhóm test cần quan tâm tới dung lượng database. Nhóm test cần xác định 10 bản ghi hay

các bảng dữ liệu thích hợp, hay 1000 bản ghi cần thiết để kiểm tra dung lượng database.

Việc test được thực hiện ở các giai đoạn khác nhau và các kiểu test cũng khác nhau, do

vậy, nên tăng dung lượng database để việc test hiệu quả. Ví dụ, việc test performance và

test volume thực hiện được với 100 bản ghi nhưng chưa khẳng định chắc chắn rằng,

database chứa được 1000.000 bản ghi. (Xem thêm chương 9 để hiểu rõ hơn về

performance testing).

Sự đa dạng

Người thiết kế test phải tổng hợp các yêu cầu thay đổi và thể hiện nó thông qua các giá trị

của dữ liệu (ví dụ, 10.000 trường khác nhau chứa các giá trị dữ liệu khác nhau và các

kiểu trường khác nhau thì chứa các kiểu dữ liệu khác nhau). Một người thiết kế test tốt sẽ

tính toán được sự thay đổi của dữ liệu và biết được khoảng dữ liệu tương tự nhau cùng

cho ra 1 kết quả mong đợi.

Testers cần quan tâm tới các bản ghi chứa các dữ liệu khác nhau. Ví dụ, giá trị của 1

trường có thể chứa giá trị âm hay các giá trị nhỏ (ví dụ 100$), giá trị trung bình (ví dụ

1000$) hay giá trị lớn (100.000$) và rất lớn (10.000.000$).

Testers cũng cần quan tâm tới các kiểu dữ liệu khác nhau. Ví dụ, tài khoản của khách

hàng tại ngân hàng cần phân biệt theo nhiều cách khác nhau, bao gồm, tài khoản tiết

kiệm, tài khoản thanh toán séc, tài khoản cho vay…..

Phạm vi.

Phạm vi dữ liệu test cần thích hợp để đảm bảo tính chính xác, các mối liên quan và mức

hoàn thành của dữ liệu. Ví dụ, khi việc test nhằm xác định sự đa dạng các loại tài khoản ở

ngân hàng, như xác định các tài khoản có giá trị lớn hơn 100$ thì không những cần test

việc hiển thị được tất cả các tài khoản có giá trị trên 100$ mà còn test việc nhập thêm dữ

liệu, và xem dữ liệu nhập thêm đó có được phản ánh vào cơ sở dữ liệu không. Việc hoàn

thiện dữ liệu test đảm bảo test được tất cả các dữ liệu validate (các dữ liệu được sử dụng

khi nhập vào cơ sở dữ liệu) và hỗ trợ việc đánh giá kết quả của sản phẩm.

Đảm bảo tính toàn vẹn dữ liệu trong suốt quá trình test.

Nhóm test phải đảm bảo tính toàn vẹn của dữ liệu trong suốt quá trình test. Testers cần

tách bạch, phân chia dữ liệu, sửa dữ liệu và quay trở lại database xem trạng thái ban đầu

của dữ liệu. Nhóm test phải chú ý, khi có nhiều người cùng test 1 lúc thì dữ liệu test của



người này sẽ ảnh hưởng đến dữ liệu của người khác. Ví dụ, nếu 1 người trong số đó sửa

dữ liệu trong khi người khác đang test phần liên quan tới dữ liệu đó thì rất có thể kết quả

test của người thứ 2 sẽ không như mong đợi. Một cách để ngăn chặn sự ảnh hưởng test

của tester này đến tester khác là sự tách bạch về database của 2 testers hoặc phân chia về

các file dữ liệu của mỗi tester. Một cách khác là phân chia mỗi tester sẽ thực hiện test các

chức năng khác nhau để tránh sự chồng chéo về dữ liệu.

Các điều kiện.

Sự thiết lập dữ liệu được tạo ra để phản ánh các điều kiện đặc biệt trong các vùng dữ liệu

khác nhau của hệ thống. Điều này có nghĩa là các kiểu dữ liệu được thiết lập chỉ sau khi

thực hiện các thao tác đặc biệt. Ví dụ, hệ thống tài chính thường được khoá lại cuối năm.

Có nghĩa, cuối năm dữ liệu được lưu lại, điều này đưa ra trường hợp test trạng thái dữ

liệu cuối năm mà không cần nhập dữ liệu đầu năm (cứ cuối năm thì số liệu được chốt lại,

dữ liệu cuối năm nay là dữ liệu đầu năm sau). Việc tạo ra dữ liệu test để có số liệu cuối

năm không bị ràng buộc. khi đó, tester có thể có dữ liệu cuối năm mà không cần nhiều

thao tác nhập dữ liệu vào trạng thái cuối năm (hệ thống tự tính toán và đưa ra con số cuối

năm).

Để xác định được các dữ liệu test theo yêu cầu, cần liệt kê bảng danh sách các dự liệu

trong 1 cột và yêu cầu test dữ liệu trong cột khác. Giữa các yêu cầu, điều quan trọng cần

chú ý tới độ lớn và độ dài dữ liệu cần thiết. Trong khi một nhóm ít dữ liệu đủ thích hợp,

hiệu quả cho việc test chức năng, nhưng để test được hiệu năng thì lại cần số lượng dữ

liệu rất lớn. Để nhập được một số lượng lớn dữ liệu có khi phải mất vài tháng. Nhóm test

cần có kế hoạch về nhân lực, thời gian để đạt được, tạo ra và phát triển dữ liệu test. Cơ

chế cho việc làm mới database để có được trạng thái ban đầu đảm bảo cho việc test tất cả

các tình huống (cho cả việc test lại), cũng phải được xem xét và đưa vào các tài liệu kế

hoạch test của dự án. Testers phải xác định tên và khu vực database thích hợp để test.

Dự liệu thường được chuẩn bị trước khi test. Việc chuẩn bị dữ liệu có thể liên quan tới

việc xử lý dữ liệu thô dạng text hay file, kiểm tra tính chắc chắn của dữ liệu và phân tích

bề sâu các yếu tố dữ liệu. Bao gồm định nghĩa dữ liệu test cho các test case (các tiêu

chuẩn ánh xạ), lọc các định nghĩa về các yếu tố dữ liệu. Xác nhận lại các yếu tố chính,

định nghĩa các tham số dữ liệu cho phép nhập.

Để chuẩn bị dữ liệu, cũng như để chuẩn bị các kịch bản phát triển và kịch bản test, nhóm

test phải vào trong database và sửa những gì cần thiết. Dựa vào điều này, chúng ta thấy

rằng sẽ tồn tại các dữ liệu đã có sẵn mà không phải do 1 tester nào đó nhập vào khi test,



điều này bao hàm cả sự biến đổi của dữ liệu. Điểm thuận tiện của dữ liệu tuỳ thích là có

thể kết hợp và sử dụng các mẫu dữ liệu không có trong phần nhập vào của tester đó.

2.6. Kế hoạch cho môi trường test.

Môi trường test bao gồm tất cả các yếu tố hỗ trợ việc test như dữ liệu test, phần cứng,

phần mềm, mạng và các điều kiện khác.

Kế hoạch về môi trường phải xác định ai và mấy người đưa ra việc tiếp cận môi trường

test, và chỉ định số lượng đầy đủ máy tính cung cấp cho các cá nhân này (Việc thảo luận

giữa các thành viên trong nhóm test được thảo luận trong chương 3).

Trong chương này, thuật ngữ “production environment” liên quan tới môi trường thực

hiện của phiên bản phần mềm cuối cùng. Môi trường này được cài đặt từ máy đơn đến tất

cả các máy trong mạng internet.

Trong khi test unit và test tích hợp được thực hiện bởi môi trường của phía các lập trình

viên thì test hệ thống và test của người dùng cuối cùng được thực hiện bởi việc thiết lập

môi trường test riêng biệt. Môi trường này được cầu hình giống với khi cài đặt cho khách

hàng, hay nói cách khác, nó đảm bảo chương trình sẽ chạy tốt. Cấu hình môi trường test

phải đại diện được cho môi trường của phiên bản cuối cùng đi cài đặt cho khách hàng bởi

vì môi trường test phải là bản sao của cấu hình cơ sở của production environment để mở

ra cấu hình liên quan có thể ảnh hưởng tới hệ thống như phần mềm kỵ với phần mềm

đang test, các nhóm và các phần bị firewall. Tuy nhiên, Cấu hình bản sao một cách đầy

đủ giống hệt với cấu hình của production environment thường không thực hiện được do

sự ràng buộc về nguồn lực và chi phí.

Sau khi đã có các thông tin về môi trường test và các thông tin khác liên quan tới công

việc test, nhóm test phải biên tập được các thông tin và chuẩn bị nguồn lực để thiết kế

môi trường test như sau:

Mô tả kết quả đạt được từ môi trường test tuỳ thích, bao gồm các phần mềm hỗ trợ,

phần cứng …..Mô tả phần cứng bao gồm các yếu tố như độ phân giải của video, khoản

trống của đĩa, tốc xử lý và các thông số về bộ nhớ, cũng như các thông số máy in (bao

gồm, loại máy in, công suất, …)

Xác định môi trường test như ổ đĩa, ổ đĩa ghi CD (CD-R) cho phép lưu trữ các file có

kích thứơc lớn (các file này được ghi theo một cách đặc biệt trên hệ thống máy client-

server)….

Xác định đặc điểm của mạng trong môi trường tuỳ biến như sử dụng đường truyền

thuê, modem, kết nối Internet, và các giao thức như Ethernet, IPX, và TCP/IP.



Trong trường hợp client-server hay Web-based system, xác định các thông số mà

server, database và các thành phần khác yêu cầu.

Xác định các test tool và các licenses cần yêu cầu.

Xác định các phần mềm khác cần có để thực hiện test như các bộ xử lý word, các

bảng tính và các phần mềm về báo cáo.

Khi xác định môi trường phần cứng cần thiết để test, cần quan tâm tới các yêu cầu về

dữ liệu test, bao gồm, độ lớn của database. Điều quan trọng đảm bảo máy móc có đủ

công suất và nguồn lực để cài đặt dữ liệu là dung lượng ổ dĩa và kết nối mạng đã sẵn

sàng.

Quan tâm tới các nguồn lực đặc biệt cần thiết cho việc cấu hình để test như chuyển ổ

cứng và phần mềm xử lý ảnh. Theo các yêu cầu chuẩn bị trên, nhóm test phát triển một

môi trường test bao gồm câu trúc môi trường thiết kế đồ hoạ với một loạt các thành phần

được yêu cầu để hỗ trợ cho cấu trúc trên. Danh sách các thành phần hỗ trợ trên cần được

xem xét để có thể thay thế được, có thể di chuyển từ vùng khác sang và phải mua được.

Danh sách các thành phần có thể mua được bao gồm danh sách các thiết bị test có thể

mua được. Nó liệt kê số lượng các yêu cầu, giá đơn vị, chi phí bảo hành bảo trì. Nhóm

test yêu cầu 1 số phần có thể backup đê đảm bảo thao tác test tiếp tục nếu phần cứng

không đáp ứng.

2.7. Ước lượng thời gian chuẩn bị test và thời gian thực hiện test.

Trước khi hoàn thành kế hoạch test và chiến lược test tốt nhất, điều cần thiết là ước lượng

thời gian của phía phát triển hoàn thành code. Theo dữ liệu lịch sử, nỗ lực của phía phát

triển chiếm nhiều nhất so với nỗ lực của toàn bộ dự án. Thời gian cần cho việc đảm bảo

chất lượng phần mềm cần xác định trong thời gian của dự án, cụ thể là thời gian dành cho

test phần mềm, thời gian test thường được ước lượng thông qua thời gian biết trước của

phía phát triển hay của toàn bộ dự án. Tuy nhiên, việc test có thể thay đổi (thay đổi các

phần cần test ….)nên thời gian test thường không được ước lượng đúng theo cách này.

Có rất nhiều yếu tố ảnh hưởng tới nỗ lực test cần được ước lượng. Nỗ lực test áp dụng

cho dự án đặc biệt phụ thuộc số lượng các biến số ảnh hưởng.



Điều này phụ thuộc cách thức tổ chức và ngày hết hạn test, sự phức tạp của phần mềm,

phạm vi test, kỹ năng của cá nhân thực hiện test. Các điều kiện này được coi như đầu vào

cho việc xác định thời gian test cho một module.

Tuy nhiên, việc đưa ra nhiều yếu tố ảnh hưởng đến nỗ lực test nhằm đưa ra phương trình

xác định thời gian thực hiện test nhưng điều này cũng khá phức tạp. Và người ta thường

ước lượng thời gian test theo cách đơn giản hơn.

Với ý tưởng này, thời gian test luôn được ước lượng bắt đầu bằng việc xác định cấu trúc

phân tầng công việc ( work breakdown structure (WBS)) hoặc danh sách các phần test

chính được xác định dựa vào cấu trúc phân tầng cho test.

Để có hiệu quả nhất, phương pháp được đưa ra ở đây phải đáp ứng được cả quá trình và

sự cần thiết mà công ty cần đạt được.

a. Phương pháp tỷ lệ với phía phát triển.

Xác định nỗ lực test dựa trên nỗ lực của phía phát triển được gọi là “Development Ratio

Method”. Phương pháp này nhanh và dễ dàng cho việc đo lường nỗ lực test. Thuật ngữ

developers trong trường hợp này bao gồm các cá nhân được chỉ định để thực hiện thiết

kế, viết code và test unit.

Kết quả của phương pháp là đưa ra tỷ lệ phụ thuộc của nỗ lực test dựa vào nỗ lực phía

phát triển, và được trình bày ở bảng 12.1. Tỷ lệ trong bảng 12.1 được áp dụng khi phạm

vi test liên quan tới việc test chức năng và test hiệu năng của giai đoạn test tích hợp và

test hệ thống. Chú ý rằng tỷ lệ các thành viên test so với các thành viên phía phát triển

phụ thuộc vào loại và độ phức tạp của phần mềm. Ví dụ, khi phía kinh doanh ký được 1

hợp đồng lớn thì cần tăng nỗ lực test. Khi này, tỷ lệ testers so với deverlopers tăng (nếu

coi các yếu tố ảnh hưởng khác không thay đổi). Ngược lại, tỷ lệ này sẽ nhỏ hơn.

Thêm vào đó, thời gian của quá trình phát triển phần mềm có thể thay đổi nên tỷ lệ này

cũng phải thay đổi theo. Trong suốt giai đoạn test sau đó, khi lịch test quá khít nhau hay

deadline của test sắp đến thì developers, PQA, và PM cần giúp đỡ testers. Trong tình

huống này, tỷ lệ của testers so với developers sẽ tăng, thậm chí số testers còn nhiều hơn

developers.

Tỷ lệ thực tế thực hiện sẽ dựa vào ngân sách sẵn có và phụ thuộc người ra quyết định, sự

phứa tạp của phần mềm, hiệu quả của việc test và nhiều yếu tố khác nữa.

Bảng 12.1. Thời gian test dựa vào phía phát triển.

Loại sản phầm Số lượng

Developers

Tỷ lệ của Developers và

Testers

Số lượng

Testers



Sản phầm thương mại

(thị trường lớn)

30 3:2 20


(thị trường nhỏ)

30 3:1 10

Tích hợp và phát triển

cho máy client

30 4:1 7

Các phần mềm cho

Chính Phủ, Nhà nước

(trong nước)

30 5:1 6

Phần mềm cho các tổ

chức trong nước

30 4:1 7

Note: Tỷ lệ trên sẽ khác vì nó còn phụ thuộc độ phức tạp hay phần mềm đó

có ít lỗi…

b. Phương pháp tỷ lệ giữa các nhân viên trong dự án.

Cách khác để ước lượng thời gian test là dựa vào tỷ lệ nhân viên tham gia dự án đó.

Phương pháp này được chi tiết ở bảng 12.2. Phương pháp này dựa vào số người tham gia

1 dự án, bao gồm tham gia khảo sát yêu cầu khách hàng, cấu hình hệ thống, quản lý qui

trình (PQA), deverlopers và QA để tính toán số người và thời gian test. Phương pháp này

có giá trị đặc biệt khi số người thực hiện công việc phát triển thường xuyên thay đổi hay

rất khó để xác định số người tham gia phát triển.

Trong việc tính toán số người test trong bảng 12.2, giả thiết là phạm vi nỗ lực test bao

gồm cả việc nghiên cứu SRS, test cấu hình hệ thống, test quá trình xử lý liên quan, test

chức năng và test hiệu năng của giai đoạn test tích hợp ve test hệ thống. Việc chọn con số

50 trong cột "Project Staffing Level" nhằm đơn giản hoá việc tính toán giá trị của cột

"Test Team Size". column. Tất nhiên số lượng người tham gia dự án có thể ít hay nhiều

hơn.

Bảng 12.2. Số Tester được tính toán dựa vào số lượng nhân viên toàn dự án.

Type of Produces

(Loại sản phầm)

Project

Staffing

Level

(số nhân viên

Test Team

Size

Số lượng

Testers



tham gia dự án)


(thị trường lớn)

50 27 13


(thị trường nhỏ)

50 16 8

Tích hợp và phát triển

cho máy client

50 14 7

Các phần mềm cho

Chính Phủ, Nhà nước

(trong nước)

50 11 5

Phần mềm cho các tổ

chức trong nước

50 14 7

c. Phương pháp test procedures.

Cách khác để đo lường nỗ lực test là sử dụng khối lượng chương trình test để đo lường,

cụ thể hơn là dựa vào số lượng test procedures của dự án đã được lập kế hoạch để đo

lường. Phương pháp này có phần bị hạn chế do phụ thuộc vào số lượng test procedures

của dự án mà không tính đến các nhân tố ảnh hưởng tới nỗ lực test. Phương pháp này là

sự kết hợp với 1 phương pháp trong hàng loạt các phương pháp khác. Để áp dụng được

phương pháp này, các Test Procedure của dự án cũng như quá trình thực hiện dự án đó

cần được ghi lại ngay từ đầu để có dữ liệu đánh giá, như việc chỉ ra các chức năng, số

lượng test procedures sử dụng và kết quả nỗ lực test được đo lường với đơn vị là “số

giờ/1 tester”

Trị số qui mô phát triển được tài liệu hoá dưới dạng những dòng mã lệnh (lines of code

(LOC)), những dòng mã lệnh tương đương, hàm con trỏ, số lượng các đối tượng được

phát triển.

Nhóm test xác định các yêu cầu và mối liên hệ giữa các trị số qui mô phần mềm trước đó

và số lượng các test procedures được sử dụng trong các dự án đó. Từ đó, chúng ta tính

toán và ước lượng được số lượng các test procedures cho dự án mới. Tiếp đến là nhóm

test xác định mối liên quan giữa số lượng các test procedures và số giờ mỗi tester cần có

dựa vào kinh nghiệm từ các dự án trước.



Phương pháp ước lượng này thành công nhất khi các dự án so sánh với nhau có sự tương

tự về bản chất, công nghệ, yêu cầu về sự thành thạo, cách thức giải quyết vấn đề và các

nhân tố khác.

Bảng 12.3 trình bày ví dụ về việc xác định số giờ test áp dụng phương pháp Test

Procedure (giả thiết, dự án có 1.120 test procedures).

Nhóm test xem xét nỗ lực test của 2 hoặc nhiều hơn 2 dự án có trung bình 860 test

procedures và cần tới 5.300 giờ cho việc test. Trong nố lực test của các dự án trước đó, số

giờ test trên mỗi test procedure là 6.16 giờ là hợp lý (cho toàn bộ vòng đời của dự án). Dự

án cần 5.300 giờ thường kéo dài 9 tháng, trong đó, cần 3,4 tháng thiết kế test. Công việc

bây giờ là xác định số giờ test cho dự án mới có 1.120 test procedures.

Bảng 12.3. Ước lượng thời gian test dựa theo phương pháp Test-

Procedure

Điều quan trọng phải xác định được mối liên quan giữa số lượng các test procedures và

phạm vi các yêu cầu cần test. Ưu điểm của phương pháp này là xác định được yêu cầu

test và phạm vi test sớm hơn so với 2 phương pháp trên. Nhưng nhược điểm của nó là

thời gian ước lượng được tính trước khi hoàn thành xong đặc tả yêu cầu của khách hàng.

d. Phương pháp kế hoạch công việc.



Phương pháp khác ước lượng nỗ lực yêu cầu của chương trình liên quan tới việc xem xét

con số lịch sử về nỗ lực test tương tự. Phương pháp này khác so với phương pháp Test

Procedure ở chỗ nó tập trung vào các task của công việc test.

Bảng 12.4 là 1 ví dụ về việc ước lượng nỗ lực test cho 1 dự án có 1.120 test procedures

dựa vào dự án có 860 test procedures, cần 5.300 giờ cho cả dự án và 6,16 giờ test cho 1

test procedure( Ví dụ này tương tự ví dụ khi sử dụng phương pháp Test Procedure trong

bảng 12.3.)

Bảng 12.4. Ước lượng nỗ lực test dựa theo phương pháp kế hoạch công

việc test (các task công việc test)

Giả thiết:

Nhóm test cần xem xét các con số của các dự án trước để chia số giờ thực hiện thành các

task công việc hay gọi là các giai đoạn test. Tóm lại, số giờ của mỗi giai đoạn test được

trình bày trong bảng 12.5.



Bảng 12.5. Xác định số giờ của mỗi giai đoạn test theo phương pháp kế

hoạch công việc.



Để đưa ra được các con số này, nhóm test phải ước lượng ngay từ khi dự án mới được bắt

đầu (nếu không có các con số của dự án trước thì việc ước lượng thời gian cho mỗi giai

đoạn test sẽ dựa vào kinh nghiệm của người lập kế hoạch).

Trong ví dụ trên, dự án mới có sử dụng công cụ test tự động và việc đưa ra bước 3 và 4 là

không cần thiết. Nhóm test cũng cần thận trọng vì dự án không có ngân quỹ dành cho

việc thực hiện cải tiến qui trình test, vì vậy không có bước 11 trong bảng trên.

Bước tiếp theo trong bảng 12.6, tính toán, ước lượng nỗ lực nhóm test dựa vào sự điều

chỉnh số giờ 6.403. Nỗ lực nhóm test được ước lượng tương đương là 3,1 testers với 1 dự

án 12 tháng. Nhóm test sẽ bố trí chính xác là 3 testers làm toàn thời gian (100%) trong

khoảng thời gian test đã xác định. Các testers phải tập trung test trước các phần có độ rủi

ro cao. Và chiến lược test cần được điều chỉnh theo nỗ lực vừa tính toán ở trên. Nhóm

test có thể bố trí nhân lực test theo các cách khác nhau, có thể bố trí toàn thời gian của 1

tester cho dự án hay phân đoạn thời gian như 80% thời gian tester 1 và 80% tester 2.

Bảng 12.6. Nỗ lực Test dựa vào ước lượng thời gian của nhân viên.

e. Các phương pháp khác.

Trong các tình huống đặc biệt, căn cứ vào kinh nghiệm để xác định nỗ lực test mà không

cần quan tâm tới các phương pháp. Ví dụ, khi sử dụng phương pháp tỷ lệ tester so với

deverloper thì không nhấn mạnh được thời gian test trong các dự án trước đó. Do vậy,

không định nghĩa được quá trình test, nên cần thiết phải điều chỉnh tỷ lệ này. Tương tự

như vậy, khi áp dụng phương pháp kế hoạch công việc, nếu nhóm test có ít kinh nghiệm

thì rất dễ phải điều chỉnh các task công việc, các nhân tố ảnh hưởng. Các nhân tố ảnh

hưởng tới việc ước lượng nỗ lực test bao gồm:

Cách tổ chức.

Phạm vi test.

Có thể test chức năng, test hiệu năng và test giao diện, test tính bảo mật, test tiện ích

(phím tắt…)….

Kỹ năng của người thực hiện test.



Thành thạo các công cụ test.

Khi sử dụng công cụ test tự động sẽ rất khó khăn đối với người chưa thực hiện công cụ

đó bao giờ, do vậy, họ cần được học về tool đó. Muốn sử dụng được các test tool đó cần

có kịch bản test. Điều này là mới với nhóm test vì họ thiếu kinh nghiệm hay thậm chí

không có kinh nghiệm trong viết code. Hay thậm chí, tester đó thành thạo với 1 test tool

này nhưng với 1 tool khác thì hoàn toàn mới với họ.

Kiến thức về nghiệp vụ.

Kiến thức của 1 tester về một ứng dụng nào đó chưa sâu do không phải họ hiểu tất cả các

nghiệp vụ thuộc tất cả các lĩnh vực. Các kiến thức đó còn được gọi là "kiến thức đặc thù”

(domain knowledge)

Tổ chức nhóm test.

Chương 5 sẽ trình bày kỹ hơn về các loại tổ chức công việc test.

Phạm vi chương trình test.

Thời điểm bắt đầu test

Kế hoạch test nên được bắt đầu ngay khi dự án bắt đầu. Điều này có nghĩa là các testers

tham gia vào test dự án đó sẽ nghiên cứu, phân tích và thiết kế test cho dự án đó. Sự tham

gia sớm của tester không những giúp họ hiểu hơn về yêu cầu cũng như thiết kế, cấu trúc

hệ thống. Từ đó, xác định được môi trường test hiệu quả mà còn sớm phát hiện ra lỗi và

ngăn chặn lỗi ngay từ giai đoạn viết đặc tả yêu cầu của phía lập trình (từ đặc tả này sẽ

thiết kế chương trình, và từ thiết kế sẽ viết code).

Sử dụng các test tool.

Với nhiều hãng phần mềm chuyên nghiệp, việc sử các test tool giúp giảm nỗ lực test,

giảm sự phức tạp khi lập kế hoạch test cũng như việc thực hiện test.

Rủi ro của phần mềm cao.

Nếu một phần mềm có độ rủi ro cao, có thể có nhiều lỗi mà xác định nỗ lực test không đủ

thì dẫn đến chất lượng phần mềm đó có xác suất rủi ro cao.

Cuối cùng, khi xác định nỗ lực test, cần quan tâm tới các yếu tố ảnh hưởng để tính đến

các tình huống đặc biệt. Nhằm hỗ trợ cho việc lập kế hoạch test, việc theo dõi số giờ thực

tế của mỗi task công việc thường được sử dụng nhất. Tuy nhiên, vấn đề đối với tất cả các

phương pháp đưa ra là, rất ít khi có 2 phần mềm tương tự nhau. Một sản phẩm phần mềm

phụ thuộc vào độ phức tạp, kinh nghiệm của deverloper, công nghệ và nhiều yếu tố khác

nữa.



3. TEST PROCEDURE VÀ THIẾT KẾ TEST.

Test Procedure và thiết kế Test là 2 công việc quan trọng của nhóm test. Như đã nói ở

chương số lượng hồ sơ đem ra khai thác, hai công việc này test chỉ được bắt đầu khi phần

mềm đã được code xong, nhưng nếu 2 công việc này được bắt đầu càng sớm càng tốt, và

có thể thực hiện, tiến hành ngay khi tài liệu đặc tả yêu cầu được phê duyệt. Khi tài liệu

đặc tả và thiết kế hệ thống được sàng lọc, chọn lựa kỹ hay được lặp lại ( sửa) tài liệu hay

thiết kế lại thì các test Procedure cũng sẽ được hoàn thành tương ứng với việc hoàn chỉnh

tài liệu và thiết kế các chức năng của hệ thống.

Test Procedure mang lại lợi ích rõ ràng, giúp chúng ta đạt được tới đích nhanh chóng và

hiệu quả. Qua tài liệu này sẽ xác định được là test black-box hay gray-box; định dạng cho

tài liệu này, các kỹ thuật test được chọn là gì. Ví dụ, như sự kiểm tra test biên,

exploratory testing. Thêm vào đó, kịch bản test và các test tool sẽ giúp chúng ta đạt được

đích mong muốn.

Trong việc đánh giá các yêu cầu và việc thiết kế phần mềm đòi hỏi phải có hiểu biết

nhiều về cấu trúc, về vấn đề chủ chốt đầu tiên cần xem xét hay các application đã có. Vì

vậy, các testers phải chia và thực hiện từng giai đoạn, thao tác nhỏ trong hàng loạt các

thao tác cần thực hiện nhằm đảm bảo thực hiện đúng lịch test và số tiền giành cho test.

Như vậy, các câu hỏi test cái gì? test bằng cách nào? test như thế nào? test khi nào? và ai

sẽ test là các câu hỏi cần được trả lời trong chiến lược test, phải chia nhỏ thành các giai

đoạn nhỏ, sử dụng các kỹ thuật đặc biệt và phải có mức ưu tiên trong quá trình test song

song hay test lặp.

3.1. Sự phân chia và thực hiện test.

Với tài liệu đặc tả và thiết kế, các testers sẵn sàng để lập ra và phát triển các loại test

Procedure. Khi phần mềm có nhiều yêu cầu, quyết định nơi bắt đầu để lập và phát triển

test Procedure dường như rất khó. Phần này muốn đưa ra phương pháp giúp chia nhỏ các

giai đoạn test.

Trước khi thiết kế test, điều cần thiết là phải quan tâm tới các giai đoạn test cần thực hiện.

Có sự khác nhau giữa các giai đoạn test như test tiện ích, test hiệu năng, test bảo mật, và

các giai đoạn test khác như test chức năng và test phi chức năng.

Test phi chức năng sẽ được bàn đến trong chương 9.

Bước đầu tiên trong việc thiết kế test Procedure là phải xem xét lại kế hoạch test. Nếu kế

hoạch đó không ổn để có thể hiểu được các tình huống hay bản chất của vấn đề thì sẽ



không xác định được mục tiêu test, phạm vi test. Kế hoạch test cũng liệt kê các nguồn lực

tham gia quá trình test như các tool hỗ trợ, các phương pháp test, các tiêu chuẩn test phải

theo hay lịch test. Nếu kế hoạch test không hợp lý hay không được lập trước đó thì các

thông tin về phạm vi test, các mục cần test ….sẽ phải lấy từ các nguồn khác. Để chia nhỏ

các giai đoạn test thì phải trả lời được các câu hỏi sau: test cái gì? test khi nào? test như

thế nào? ai sẽ tham gia vào quá trình test?

Những phần nào cần test?

Trong giai đoạn lập kế hoạch test, phải xác định ngay phần nào cần test, phần nào không

để từ đó xác định được phạm vi cần test.

Khi nào thì test?

Trong phần 3, chúng ta đã đưa ra yêu cầu phải thiết kế test Procedure càng sớm càng tốt

khi có tài liệu đặc tả. Khi đã xác định được phần nào cần nào cần test, phần nào không thì

chúng ta cần xác định được trình tự test. Vậy, vấn đề đặt ra là cái gì cần được test trước

tiên? Tester lên kế hoạch test phải biết được phần nào được ưu tiên test trước, phần nào

test cùng nhau và từ đó đưa ra lịch test cụ thể.

Tiến trình test phải ưu tiên cho mục cần test trước. Trừ khi có ngoại lệ là các chức năng

chắc chắn cần được chạy trước để chuẩn bị cho các chức năng khác. Như vậy, các chức

năng này cần được ưu tiên test trước hay không? vấn đề này sẽ được bàn kỹ hơn trong

các phần, các mục cần được ưu tiên test trước trong phần 8).

Thêm vào đó, việc phân tích rủi ro nên được tính đến khi xét đến các mức độ ưu tiên này.

Nếu không phải test toàn bộ chương trình, các testers chỉ cần quan tâm tới các phần cần

test mà thôi. Việc phân tích rủi ro đưa ra cơ chế để xác định những phần cần test và

những phần có thể bỏ qua không test.

Test Procedure nên được thiết kế như thế nào?

Không có bất kỳ một giải pháp đơn lẻ nào có thể test toàn bộ hệ thống một cách hiệu

quả. Test Procedure cho các phần khác nhau của một hệ thống cần được thiết kế thích

hợp, đặc biệt cho các phần đặc biệt của chương trình.

Để thiết kế test Procedure thích hợp và hiệu quả thì điều cần thiết là phải quan tâm đến

cấu trúc hệ thống và tích hợp hệ thống.

Ví dụ, để xác minh lại các chức năng của hệ thống thì có thể thông qua giao diện người

dùng. Test Procedure sẽ dựa trên các yêu cầu chức năng đã có trong tài liệu, trong đó, các

test cases phải thể hiện đầy đủ các trường hợp xảy ra.



Các test cases sẽ được bắt đầu với các bộ dữ liệu đúng và bộ dữ liệu không đúng cho test

giao diện để xác minh lại định dạng chuẩn của các trường dữ liệu đầu vào. Điều này liên

quan tới một chuỗi các thao tác kiểm thử sau đó. Ví dụ, khi nhập dữ liệu cho một trường

hay màn hình này lại trả ra một màn hình khác mà cũng yêu cầu nhập dữ liệu.

Test Procedure phải thiết kế cho GUI testing hay back-end testing, hay cả hai còn phụ

thuộc vào chiến lược test đã xác định trước đó. GUI tests khác so với back-end tests.

Những ai sẽ tham gia vào test?

Khi đã xác định được phải test phần nào? và test khi nào? test như thế nào thì sẽ dễ dàng

xác định được trách nhiệm của từng người sẽ test phần nào dựa trên khả năng và kinh

nghiệm của các tester. (xem phần 13). should develop the tests? Ngoài ra sẽ có nhiều câu

hỏi được đặt ra trong suốt quá trình lập và thiết kế test Procedure.

ếu không có tài liệu đặc tả thì test Procedure sẽ được thiết kế ra sao?

Nếu không có tài liệu đặc tả để viết test case thì điều cần thiết để có thể viết test cases là

hỏi người đại diện, người có trách nhiệm đối với các yêu cầu đó hay nhân viên kỹ thuật

hay những người review các yêu cầu của khách hàng (nhưng các yêu cầu đó không được

viết thành tài liệu). Ví dụ như hướng dẫn người dùng của hệ thống hiện tại (nếu đã có)

hay những tài liệu hướng dẫn người dùng, đặc tả yêu cầu của các hệ thống trước đó để

hiểu tốt hơn về hệ thống đang thiết kế (xem phần 5 về những vấn đề nguy hiểm thường

gặp phải khi việc test phải dựa trên các tài liệu của các application đã tồn tại. Nếu như có

một hệ thống được kế thừa, thì phải có tài liệu thiết kế của nó. Tuy nhiên, những tài liệu

này có thể không đúng với yêu cầu của khách hàng. Trong một số trường hợp, phải thực

hiện ngược lại so với thiết kế để kiểm tra hệ thống, hay thực hiện exploratory testing (vấn

đề này sẽ được thảo luận ở phần sau)

Black-box and gray-box Testing:

Black-box and gray-box Testing được thực hiện trong tất cả bộ phận của dự án thông qua

test giao diện, và được gọi là black-box. Ví dụ, nếu muốn thêm mới một người dùng vào

database thì người dùng này sẽ được insert vào database thông qua giao diện người dùng,

various layers—Ví dụ như database layer, phân lớp người dùng, business-logic layers—

sẽ được thực hiện. Lỗi thường thể hiện qua giao diện người dùng. (chương 4 sẽ bàn kỹ

hơn về black-box and gray-box testing.

Tuy nhiên, trong một số trường hợp lỗi không được thể hiện qua giao diện người dùng

bởi vì các lỗi này thuộc về cơ chế thông báo lỗi của phần mềm. Ví dụ, khi một

application mà không thêm mới được một bản ghi vào cơ sở dữ liệu, nhưng không có



thông báo trên giao diện người dùng thì lỗi này là do code vì không hiển thị thông báo lỗi

trên màn hình.

Khi có giao diện người dùng, hay black-box, việc test không thể test hết lỗi được. Do đó,

graybox testing cũng phải được áp dụng nhằm tìm hết ra lỗi [1] Gray-box testing được

nói đến trong phần 16.

Will a test harness have to be developed?.

Một số phần của hệ thống chỉ có thể test được bằng công cụ test. Ví dụ, Một phép tính có

thể cho phép kết hợp cùng một lúc hàng nghìn bộ dữ liệu đầu vào. Việc test này yêu cầu

thiết kế test khác so với test giao diện hay black-box testing: Với số lượng đầu vào được

kết hợp cùng với sự thay đổi của dữ liệu đầu vào quá lớn và không thể test bằng cách

nhập nhập liệu qua giao diện người dùng. Thời gian và các vấn đề cần quan tâm, xem xét

khác yêu cầu test phải sử dụng test tool để tính toán với bộ dữ liệu đầu vào lớn đó thì đầu

ra của chúng là gì? Vấn đề này sẽ được nói kỹ hơn tại phần 37.

Các kiểu kỹ thuật test được sử dụng là những kiểu nào?

Các kiểu kỹ thuật test function rất đa dạng và được sử dụng để test data và bộ dữ liệu đầu

vào. Một kiểu kỹ thuật test có thể kiểm tra một số lượng lớn sự kết hợp các bộ dữ liệu là

orthogonal array testing. Orthogonal array testing cho phép tập hợp tất cả sự kết hợp

các tham số để chứng tỏ chỉ cần số lượng test case nhỏ nhất nhưng bao phủ được hết các

trường hợp xảy ra.[2]

Các kiểu kỹ thuật test khác giúp thu hẹp được các trường hợp xảy ra trong cùng một phân

lớp tương đương bằng việc phân tích giá trị biên (xem phần 25). Sự kết hợp các kỹ thuật

này cho phép giảm số lượng test case nhưng vẫn đảm bảo thống kê đầy đủ các trường

hợp xảy ra khi thiết lập các bộ dữ liệu đầu vào. Kỹ thuật test khác xảy ra khi phải có sự

tham ra của commercial off-the-shelf (COTS) tool. Sự pặp lại của COTS tool với giá trị

tuỳ thích được code sẽ được kiểm thử. Ví dụ, nếu một COTS tool được yêu cầu để thực

hiện một lệnh SQL, khi test sẽ phải chạy các kịch bản để chứng tỏ nội dung của lệnh SQL

được sửa là đúng.

Should a capture/playback tool or other testing tool be used? Một capure/playback

hay 1 công cụ test khác nên được sử dụng như thế nào?

Khi một test tool được khai thác, sử dụng để test việc tính toán liên quan tơí yếu tố kỹ

thuật hay

các back-end functions khác, thì công cụ test tự động (capture/playback) sẽ là hữu ích cho

GUI regression testing.



Khi xác định chiến lược test yêu cầu phải xác định các phần của application được test

bằng công cụ test tự động. Các phần khác không cần test bằng automated testing thì

không nhất thiết áp dụng nó, nguyên nhân của vấn đề sẽ được thảo luận trong phần 36.

Which tests should be automated? Việc test tự động được thực hiện như thế nào?

Người thiết kế test nên phân tích kỹ, cần thận application khi đưa ra quyết định áp dụng

công cụ test tự động hay test bằng tay. Điều này giúp tránh xa, loại bỏ những chi phí

không cần thiết. Vì nói chung test bằng công cụ test tự động thì chi phí thường cao hơn so

với test tay.

Sau đây là một số ví dụ áp dụng test tự động:

o Việc test phải được thực hiện nhiều hơn một lần:

Ngược lại, việc test chỉ được thực hiện một lần duy nhất thì việc sử dụng công cụ test tự

động là rất lãng phí.

o Việc test nhằm đánh giá các điều kiện rủi ro cao.

Các nhân tố rủi ro ít thì không nhất thiết phải áp dụng công cụ test tự động. Chúng ta

quan tâm tới test function nơi người dùng thực hiện các kịch bản test đặc biệt. Ví dụ, khi

test, hệ thống cho phép người dùng thực hiện các hành động này (do yêu cầu của bên

kinh doanh) nhưng việc test chúng không thể quan sát hết, rõ ràng bằng trực quan. Rủi ro

liên quan tới các kịch bản của loại test này là thấp nếu số lượng người dùng là ít. Và khi

một hành động nào đó không đơn thuần quan sát được bằng trực quan khi thiết kế test thì

các rủi ro xảy ra là rất cao.

o Tests thực hiện trên nền tảng, cơ sở thông thường (Test that are run on a regular

basis).

Ví dụ, bao gồm smoke (build verification)

tests, regression tests, and mundane tests (tests đơn giản, test lặp và lặp nhiều lần).

o Công việc test đó không thể thực hiện test tay.

Ví dụ, Test tự động được thực hiện khi cần kết quả đầu ra của việc có 1000 người tiếp

cận hệ thống trong một thời điểm.

o Test với nhiều bộ dữ liệu cho cùng một hành động (data-driven

tests).

o Baseline tests(danh giới test) được thực hiện trên các cấu hình khác nhau.

o Test với kết quả có thể đoán trước.

Khi này, áp dụng công cụ test tự động sẽ mang lại chi phí hiệu quả.

o Test xem sự ổn định của hệ thống đạt đến mức nào.



Với functionality, implementation, và công nghệ không thay đổi thường xuyên. Mặt

khác, sự bảo dưỡng của các công cụ test tự động sẽ mang lại các lợi ích nhiều hơn.

What kind of test data is needed?Các kiểu test data cần thiết là gì.

Trước đây, công việc test chưa được phân chia một cách rõ rệt, chưa thể hiện vai trò quan

trọng thì việc test data được thực hiện bắng cách nhập các bộ dữ liệu đầu vào. Điều quan

trọng là test data được chọn lựa rất cẩn thận, nếu test data với bộ dữ liệu đầu vào không

đúng hay quá đơn giản có thể dẫn đến xót các trường hợp hay lỗi sẽ xảy ra do việc test

chứ không phải do chương trình. Như vậy, test data yêu cầu phải đầy đủ các trường hợp

xảy ra ( test data sẽ được nói kỹ hơn trong phần 10).

Việc trả lời các câu hỏi được liệt kê trong phần này sẽ giúp cho người lập kế hoạch chia

nhỏ được các công việc test, quan trọng là phải quan tâm tới lịch test và chi phí giành

cho test là bao nhiêu.

3.2. Sử dụng Template Test Procedure và các tiêu chuẩn thiết kế test khác.

Tính lặp lại, độ chắc chắn, sự hoàn thành, template các test Procedure chuẩn nên được qui

định thích hợp. Sau đây là một số ví dụ về các template test Procedure:

Test Procedure Template



Phương pháp kiểm thử:

Hình 21.1. Template file test case:

Yếu tố đầu tiên của một file test case chuẩn được thể hiện qua hình 21.1, bao gồm:



Mã test case: Thoả thuận cách đặt ID cho test Procedure.

Tên test case: Thể hiện sự mô tả của các test case trong phần đó..

Ngày lập file test case: Ngày bắt đầu tạo các test case.

Tên người thiết kê lên form của file test case: Họ tên của người thiết kế file test case

Người tạo các test case: Họ tên người tạo ra các test case

Mục đích test: Phác thảo mục đích test của test case đó.

Mối liên quan giữa các use case, số lượng các yêu cầu: Thể hiện đầy đủ số lượng các

yêu cầu được xác nhận trong test Procedure.

Sự dự đoán, giả thiết và sự ràng buộc: Đưa ra các tiêu chuẩn hay các điều kiện tiên

quyết cần có trước khi viết các test case, ví dụ như các dữ liệu đặc biệt cho các yêu cầu

đặt ra là gì. Điều này sẽ được hoàn thành khi test case đó phụ thuộc vào các test case

trước đó. Điều này cũng có thể được hoàn thành khi 2 test case này có xung đột nhau nếu

như chúng cùng được thực hiện trong cùng một khoảng thời gian. Cần chú ý rằng điều

kiện tiên quyết của các use case thường là điều kiện tiên quyết của các test case.

Phương pháp kiểm thử: Mục này này có thể bao gồm các kiểu test đã được kiểm

chứng, các công cụ test tự động và test tay, sự kiểm thử, việc thực hiện và phân tích.

User Action (Inputs): Đây là kết quả mong đợi của thao tác và kết quả mong đợi này

phải rõ ràng và cơ sở. Kết quả mong đợi là kết quả sau khi thực hiện các thao tác, các

bước được mô tả. Đầu vào của kết quả mong đợi có thể là như nhau đối với các phần

mềm khác nhau. Việc chỉ rõ trường này làm cho tài liệu rõ ràng, dễ hiểu, dễ kiểm tra. Các

bứơc mô tả phải tuân theo các use case.

Kết quả mong đợi: Xác định kết quả mong đợi khi thực hiện lần lượt các thao tác

được mô tả trước đó.

Thông tin theo dõi Log: Document the behavior of back-end components.

Trong suốt quá trình thực hiện các thao tác, các bước trong hệ thống, sẽ được Log lại chi

tiết các chức năng mà chúng được thực hiện. Quá trình ghi Log cũng được diễn tả trong

file test case.

Kết quả thực tế: Trường kết quả thực tế có thể có các giá trị mặc định để mô tả kết

quả thực tế nếu như test case này bị thất bại không đúng với kết quả mong đợi hay thành

công.

Yêu cầu test data: Sự tham chiếu của việc thiết lập test data sẽ tạo nên các test case

trong file test case. Chúng ta sẽ nghiên cứu phần 26 để biết thêm chi tiết.



Khi xác định nỗ lực test, test các yêu cầu phi chức năng thường được thực hiện sau. Tuy

nhiên, điều quan trọng là phải quan tâm tới test phi chức năng ngay từ khi bắt đầu dự án.

Chú ý, trong phần 21.1, file test case được chia thành 5 phần, một phần giành cho test

chức năng, và 4 phần còn lại giành cho test phi chức năng, bao gồm, test tính bảo mật_an

toàn hệ thống, test hiệu năng, sự tương thích, tiện ích. Xem phần 41 để biết nhiều hơn về

việc cần thiết của test phi chức năng.

Các tiêu chuẩn của một tài liệu thiết kế test phải được thể hiện bằng tài liệu, trao đổi và

buộc phải tuân theo để mọi người liên quan có được những nguyên tắc thiết kế và các

thông tin về yêu cầu của khách hàng.[2]. Việc tạo ra mẫu file test case và các nguyên tắc

là điều cần thiết cho việc test tay và test tự động. Các tiêu chuẩn cho file test case bao

gồm các ví dụ càng chi tiết càng tốt. Mức độ chi tiết nên đơn giản khi thực hiện mô tả các

thao tác. Ví dụ,

Bước 1. Click chọn File menu.

Bước 2. Chọn nút Open.

Bước 3. Chọn một thư mục trên máy tính

Phụ thuộc vào qui mô của application được test và thời gian và số tiền giành cho việc test

mà qui định thời gian cho viết test case nhiều hay ít, và viết kỹ hay không kỹ các trường

hợp.

Một file test case chuẩn bao gồm các nguyên tắc trong việc mô tả kết quả mong đợi. Các

tiêu chuẩn nên chú tâm vào nhiều câu hỏi: kết quả mong đợi sẽ được thể hiện ra màn hình

như thế nào? Yêu cầu test sẽ bị loại bỏ bởi người thứ 2 thực hiện test?

Khi đạt đến việc test tự động theo cái chuẩn thì các chuẩn mực đó phải dựa trên kỹ thuật

Code tốt nhất như sự kết nối rõ ràng, các biến chuẩn,…Việc Code ảnh hưởng lớn đến

chất lượng của phần mềm.

Trong một số trường hợp, không phải kịch bản test được mô tả rõ ràng, chi tiết trong SRS

hay URD. Test case của các ứng dụng khó, phức tạp như hệ thống về tài chính; đối với hệ

thống phần mềm cung cấp cho lĩnh vực tài chính, đầu vào là hàng vạn các phép tính và

kết quả đầu ra là khác nhau.

3.3. Việc chuyển hoá thành các test cases từ yêu cầu của khách hàng.

Mục đích chính của Test chức năng đảm bảo chương trình có và thực hiện đầy dủ các

chức năng theo yêu cầu của khách hàng. Test chương trình theo các kịch bản hay nói

cách khác theo các case và được mô tả trong test Procedure case giúp cho việc test hiệu

quả hơn.



Để đảm bảo mục đích của test chức năng thì tester phải bám sát vào tài liệu đặc tả yêu

cầu khách hàng. Thêm vào đó, phải có các test case để test hiệu năng, test tính bảo mật,

và test tiện ích.

Trong chương 1 đã thảo luận về một SRS chi tiết, hoàn thành và có thể thực hiện test.

Tuy nhiên, trong quá trình thực hiện viết SRS thì không phải trường hợp nào cũng thực

hiện tốt. Để tạo ra các kịch bản test chức năng chuẩn, các tester phải hiểu chi tiết và tính

phức tạp của hệ thống. Muốn vậy, tester phải phân tích được hệ thống.

Thậm chí họ phải đưa ra được luồng test để người khác nhìn vào luồng đó sẽ biết tester sẽ

test như thế nào, đúng hay sai. Do đó, tester phải khảo sát hệ thống để hiểu đầy đủ về hệ

thống.

Nói chung, các tester phải phân tích làm cách nào để hiểu được sự chuyển đổi các phần

của hệ thống, như thay đổi biến và trường thì sẽ ảnh hưởng, thay đổi đến các phần còn

lại. Không nên coi nhẹ việc thay đổi yêu cầu. Ví dụ, hệ thống có tính linh động và cho

phép thay đổi yêu cầu, khi này hệ thống sẽ sử dụng tập con của sự kết hợp và dao động

dữ liệu đầu vào; và sự thay đổi này vẫn cho phép lưu lại một cách chính xác. Khi này, kết

quả test trước đó vẫn không bị ảnh hưởng vào nó vẫn bao gồm tất cả các trường hợp xảy

ra.

Ví dụ, Xem xét yêu cầu sau:

“ Hệ thống phải cho phép người dùng sửa tên tuỳ thích và được thể hiện trên bản ghi với

trường tương ứng”.

Trường tên và sự giới hạn của trường tên cũng phải được thể hiện cụ thể trong SRS. Một

số bước test đảm bảo cho yêu cầu này bao gồm:

1. Kiểm tra hệ thống xem nó có cho phép người dùng sửa tên tuỳ thích trên giao diện

người dùng bằng cách click vào bản ghi có trường tên đó và sửa hay không.

2. Cố gắng kết hợp kiểm tra cả trường hợp đúng và sai, tất cả các phân lớp tương đương,

các giá trị biên.

3. Chạy lệnh SQL để kiểm tra việc update là đúng và được update vào 1 bảng thích hợp.

Ở trên bao gồm các bước kiểm thử cơ bản. Tuy nhiên, trong một số trường hợp vẫn còn

bỏ sót các tình huống của yêu cầu đưa ra.

Ngoài việc test hiệu năng và test phi chức năng khác thì câu hỏi cần phải trả lời là " làm

thế nào để biết được có sự thay đổi trong hệ thống khi một trường nào đó bị thay đổi?”,

“giao diện người dùng, các chức năng hay các mục khác sẽ bị ảnh hưởng, còn các phần

nào không bị ảnh hưởng?”.



Ví dụ:

Kiểm tra chức năng tạo mới 1 đơn đặt hàng trong module đặt hàng là việc kiểm tra xem

đơn đặt hàng đó có được insert vào CSDL và được thể hiện trên giao diện hay không.

Thêm một bản ghi và kiểm tra xem bản ghi đó có được lưu lại với tên đúng như khi

thêm mới hay không.

Thực hiện test chức năng thêm mới và các chức năng khác có liên quan tới chức năng

thêm mới đó để thấy sự ảnh hưởng của việc thêm mới đó.

Tester phải phân tích và test hết các phần liên quan, bị ảnh hưởng. Khi yêu cầu không

được cụ thể hoá chi tiết trong SRS, để test hiệu quả trong trường hợp này rất khó, do đó,

dễ bị bỏ xót. Thực tế, hầu hết các yêu cầu không được viết thành tài liệu một cách đầy đủ,

rõ ràng để có thể thấy ngay mối liên hệ giữa các yêu cầu và các chức năng. Do vậy,

thường thì một test Procedure hiệu quả không được viết lên từ riêng SRS. Tài liệu thiết kế

test hiệu quả không được chồng chéo lên nhau, thay vì đưa ra một quyết định phải test

hiệu quả toàn bộ với nỗ lực cần là gấp đôi ( mặc dù nỗ lực thời gian gấp đôi nhưng vẫn

không tránh khỏi sự thiếu sót khi test). Sẽ không hiệu quả nếu để 2 tester test cùng một

chức năng nhưng trên 2 file test case khác nhau của 2 người, trừ khi điều đó là cần thiết

cho việc test toàn bộ các chức năng ( Ví dụ, khi có 2 phần cùng sử dụng các bước tương

tự nhau)

Vấn đề quan trọng khi phân tích luồng test nhằm đảm bảo trong suốt quá trình test, việc

test được diễn ra đúng theo luồng, và chương trình xử lý có đúng hay không mà không

cần nỗ lực gấp đôi, tester không cần test dữ liệu không hợp lệ với kết quả mong đợi khác,

vì khi này chỉ lãng phí thời gian. Nếu test theo luồng thì lập trình cũng tốn ít thời gian để

sửa lỗi hơn, và tập trung vào những lỗi quan trọng.

Nhóm test nên review kế hoạch test và tài liệu thiết kế test để:

Xác định các kiểu actions hay các events tương tự thường xảy ra. Việc xác định này

giúp cho việc viết test Procedure được tốt hơn, do vậy, có thể tái sử dụng và kết hợp lại

các actions hay events đối với các chức năng, tránh được việc tăng nỗ lực gấp đôi.

Xác định thứ tự hay sơ đồ test. Các vấn đề cần test trước thì phải được ưu tiên thực

hiện test trước, như việc xác định cấu hình database, hay các yêu cầu mà kết quả mong

đợi cần được kiểm soát, hay các work flow.

Tạo ra các mối liên hệ được kết hợp chặt chẽ theo luồng, các phần test cần ưu tiên test

trước trong test Procedure. Sơ đồ mối liên hệ này đưa ra sự ảnh hưởng lẫn nhau của các

chức năng, sơ đồ luồng test được tạo ra từ quá trình thiết kế test và làm tăng hiệu quả test.



Việc phân tích ở trên giúp nhóm test xác định trình tự test thích hợp trong tài liệu thiết kế

và phát triển test.

Các vấn đề khác cần quan tâm khác để tạo ra test Procedure hiệu quả là phải xác định và

review các yêu cầu có độ rủi ro cao để có sự ưu tiên test và test kỹ hơn, chức năng quan

trọng nhất sẽ ưu tiên test sớm hơn. Như vậy, sẽ là lãng phí thời gian đầu tư tạo ra test

Procedure các chức năng rất hiếm khi người dùng sử dụng, trong khi các chức năng quan

trọng lại chưa được test và test kỹ dẫn đến rủi ro cao.

Cần phải xác định ưu tiên test đối với các chức năng có xác suất rủi ro cao và việc sử

dụng là nhiều nhất. Phần 8 sẽ cho chúng ta biết chi tiết hơn)

Để có test case hiệu quả, phải hiểu hệ thống, luồng test và các kịch bản. Vấn đề khó khăn

thường xảy ra là nếu chỉ thông qua 1 tài liệu SRS thì rất khó có thể hiểu hết được sự kết

nối, luồng và mối tương quan giữa các đối tượng.

Suy nghĩ theo logic và quan tâm đến chi tiết các yêu cầu để hiểu được tính phức tạp của

hệ thống. Test Procedure và thiết kế test sẽ bị thiếu các trường hợp nếu thiết kế test không

được chi tiết trong khi test hộp đen.

3.4. SRS là tài liệu không thể không có (như tài liệu sống còn) của quá trình test

(“Living" Documents)

Thường thì người thiết kế test Procedure chỉ thực hiện test các case 1 hoặc 2 lần rồi thôi,

do sự thay đổi yêu cầu, thiết kế, hay việc thực hiện test chỉ diễn ra 2 lần. Do áp lực công

việc, các testers thường không xem lại test Procedure của họ. Các testers dựa vào trực

giác và kỹ năng phân tích để viết các test case, bao quát toàn bộ các trường hợp, các chức

năng quan trọng của hệ thống. Vấn đề là, nếu tài liệu SRS không còn thích hợp, nó trở

nên quá lỗi thời thì công việc trước đó tạo ra các tài liệu này trở nên lãng phí. Vì vậy, vẫn

đề quan trọng là phải coi SRS như tài liệu sống còn của việc test và nó tài liệu động chứ

không phải không có sự thay đổi.

Hầu hết các dự án phần mềm được phát triển theo kiểu lặp lại và phát triển, và tài liệu để

test thường tương tự theo 1 cách.

Trong vòng đời của 1 dự án phát triển, đa số là được xây dựng dựa trên 1 kế hoạch riêng.

Và điều đó rất khó để người viết test Procedure giữ và thừa kế lại các test Procedure

trước đó. Khi phần xây dựng đầu tiên được hoàn thành và giao lại cho phía test, thì tài

liệu này phải dùng để tạo test case được.

Chúng ta sẽ không thể hoàn thành việc test toàn bộ hệ thống nếu nhóm phát triển vẫn

đang trong giai đoạn code hay mới chỉ code xong một số phân hệ của hệ thống đó. Trong



trường hợp này, nhóm test chỉ viết test Procedure cho các phần đã được code xong dựa

vào kế hoạch đã được xây dựng trước đó, và test Procedure này không phải là tất cả các

yêu cầu, thiết kế chi tiết, và tất cả kịch bản test của dự án đó. Rất ít test Procedure liệt kê

được tất cả các các chức năng hay kịch bản của 1 hệ thống. Do đó, test Procedure phải

được phát triển theo từng giai đoạn của phía phát triển. Và theo từng giai đoạn phát triển

từ phía lập trình, test Procedure cũng dần dần được hoàn thiện. Ngoài ra, chúng còn được

hoàn thiện ngay trong quá trình thực hiện test.

Test Procedure cần được thảo luận hay sửa để cập nhật các thông tin mới. Ví dụ, khi yêu

cầu thay đổi, tester phải test theo sự thay đổi, do đó, họ cần điều chỉnh test Procedure.

Các chức năng có thể bị thay đổi hay nâng cấp trong suốt vòng đời phát triển hệ thống.

Điều này ảnh hưởng tới test Procedure, và vì vậy, cần phải thiết kế lại theo chức năng

mới được thay đổi đó.

Khi một lỗi được phát hiện thì nó cần được phản ánh vào test Procedure. Với 1 số chức

năng, việc phát hiện 1 lỗi đôi khi làm ảnh hưởng tới cả hệ thống vì luồng test sẽ không

thực hiện được. Test Procedure phải phản ánh được luồng nghiệp vụ để phát hiện các lỗi

trên.

Khi các testers có đủ thời gian hiểu rõ hệ thống, họ sẽ test được hết các yêu cầu đặt ra.

Tuy nhiên, vấn đề là công việc test sẽ chấm dứt khi nào? Để trả lời được câu hỏi đó, thì

khi một kịch bản test được viết lên cần có sự đánh giá, review và có mức độ ưu tiên.

Test Procedure nên được lưu lại thành các version để kiểm soát sự thay đổi của nó.

3.5. Sử dụng các Prototypes.

Tài liệu Prototypes có rất nhiều mục đích. Chúng cho người dùng biết kết quả mong đợi

khi thực hiện một chức năng. Chúng cho phép người dùng quay trở lại xem xét những gì

được phía phát triển thiết kế.

Prototypes giúp phát hiện ra sự mâu thuẫn trong các yêu cầu. Đôi khi sự mâu thuẫn này

không được giải quyết nếu chúng xuất hiện ở các phần của các trang khác nhau, hoặc khi

có nhiều hơn 1 lập trình tham gia code. Mặc dù yêu cầu rất khắt khe và việc kiểm tra sẽ

làm giảm thiểu sự đối lập, mâu thuẫn nhưng việc thực hiện chúng cũng có giới hạn. Việc

tạo ra các prototypes và thiết kế chúng giúp phát hiện ra các điều trái ngược, mâu thuẫn

và thiếu xót, và đưa ra các công cụ hiệu quả giúp lập trình phát hiện ra những chỗ thiếu

xót.

Khi có Prototypes kiểm tra với các chức năng phức tạp cho phép đạt được cơ chế test ( ví

dụ, tài liệu khai thác test…) và lọc những trường hợp tốt nhất.



Với 1 prototype ra đời, nó xác định các lớp và tiếp cận dần đến tài liệu khai thác test.

Prototypes giúp lọc ra những test Procedure hiệu quả ngay cả với các yêu cầu thêm vào

hay thay đổi, chúng sẽ được hoàn thiện đầy đủ và chi tiết hơn. Prototypes cung cấp thêm

các thông tin cho phép hoàn thiện và cải tiến test Procedure.

Prototypes cung cấp chi tiết thông tin về các yêu cầu tĩnh mà tài liệu đặc tả yêu cầu khách

hàng không có.

Prototypes cũng giúp testers xác định các phần sử dụng công cụ test tự động. Đôi khi 1

prototype còn có thể xác định, phát hiện ra sự thiếu xót của công cụ test tự động.

3.6.

3.7. Các kỹ thuật test được sử dụng khi thiết kế kịch bản test.

Như trên đã thảo luận các vấn đề quan trọng của kế hoạch test. Trong suốt giai đoạn thiết

kế test Procedure, kế hoạch test ngày càng được thể hiện rõ ràng. Việt test sẽ không giải

quyết hết mọi tình huống nếu thiếu kỹ thuật test. Kỹ thuật test giúp giảm số lượng test

case nhưng vẫn đảm bảo hiệu quả, giảm nỗ lực test tới mức tối thiểu. Để sử dụng và áp

dụng hiệu quả kỹ thuật test thì phải hiểu rõ về nó như thế nào. Có 2 loại kỹ thuật test là

kỹ thuật test white-box và black-box .

Sử dụng kỹ thuật test đã được chứng minh, đã từng sử dụng hiệu quả hơn là tập trung vào

1 kỹ thuật test duy nhất. Khi hệ thống yêu cầu xác định đầy đủ các test case thì chỉ một

nửa chúng cần có nỗ lực thích hợp. Khi tester test theo cảm tính thì chất lượng test sẽ

không tốt, khi này chưa chắc họ đã bao quát hết các tình huống của chương trình.

Trong số các kỹ thuật test nhằm giảm số lượng test case test các chức năng thì kỹ thuật

phân lớp tương đương, kỹ thuật biên và giao giữa các ma trận được sử dụng phổ biến.

Sau đây là một vài điều đáng quan tâm về các kỹ thuật này:

Phân tích các chức năng được thảo luận chi tiết trong phần 22. Sự phân tích này liên

quan tới kết quả mong đợi của chức năng đó. Và từ đó nó sinh ra test Procedure cho các

chức năng đó hay các phần đặc trưng khác của hệ thống.

Nếu yêu cầu đưa ra cần có chức năng x; sau đó, việc viết test case nhằm kiểm thử chức

năng đó theo 1 cách thích hợp. Mà cách này được hướng dẫn trong phần 22. Sau khi xác

định các chức năng cần test và các kỹ thuật test thì sẽ giảm được việc nhập nhiều dữ liệu

đầu vào cho các chức năng đó.

Phân lớp tương đương xác định các miền giá trị đầu vào theo điều kiện ban đầu và kết

quả mong đợi của chúng là gì. Kỹ thuật phân lớp tương đương liên quan chặt chẽ tới các



tình huống phổ biến và mẫu thuẫn nhau. Nếu các trường hợp là tương đương nhau, hay

về bản chất là tương tự nhau thì chỉ được test 1 trường hợp, không cần test tất cả.

Mặc dù sự phân lớp tương đương được thực hiện bằng trực quan tốt thì điều cần thiết vẫn

phải chú ý tới các giả định để phân lớp.

Xem xét các ví dụ sau để thấy được sự phân lớp tương đương đối với trường hợp biên:

Trường password cho phép nhập 8 số, nếu nhập nhiều hơn là sai. Khi giá trị nhập vào

nằm trong khoảng đã cho thì chúng gọi là một phân lớp tương đương. Trong trường hợp

này chỉ có 2 phân lớp tương đương mà thôi. Một phân lớp nằm trong đoạn [1,8], và một

phân lớp nữa nằm ngoài đoạn đó.

Phân tích hướng đi, đường dẫn được sử dụng trong việc test bản chất đường dẫn bên

trong, cấu trúc bên trong và kết nối với kết quả của chúng. Nó có thể được áp dụng theo 2

mức độ. Một là dựa vào code và hai là trong giai đoạn test whitebox (unit test). Unit test

nhằm sửa code của chương trình (chương 6 sẽ đi chi tiết về unit testing).

Phân tích đường dẫn cũng có thể được áp dụng ở mức độ thứ 2: mức độ thuộc về chức

năng hay test black-box. Mã nguồn đóng và test black – box được thực hiện ở giai đoạn

system test hay user-acceptance. Thậm chí mã nguồn mở, thì test black-box vẫn được test

theo yêu cầu của khách hàng.

Phân tích giá trị biên (BV) có thể hoàn thành việc phân tích đường dẫn. Test giá trị

biên sử dụng phần lớn dữ liệu đầu vào là invalid. Do đó, còn gọi là test phủ định

(negative testing). Điều kiện giá trị biên xác định phần lớn hiệu quả của các test case giá

trị biên khi có nhiều lỗi xảy ra trong phần giá trị biên.

Giá trị biên xác định 3 kiểu hay 3 lớp dữ liệu là kiểu dữ liệu trong khoảng, ngoài khoảng

và giá trị biên (hay còn gọi là in-bounds, out-of-bounds, and on-bounds).

Ví dụ kiểm tra 1 application, trong đó có đầu vào phải đảm bảo giá trị hơn 10 trường hợp

xảy ra.

o Kiểm tra 1 giá trị nằm trong khoảng giá trị là 13 (lớn hơn 10)

o Kiểm tra 1 giá trị nằm ngoài khoảng giá trị là 5 (nhỏ hơn 10)

o Kiểm tra giá trị

Thêm giá trị trong và ngoài khoảng giá trị biên, như điểm cuối của đoạn/khoảng. Test giá

trị biên sử dụng giá trị lớn nhất và nhỏ nhất, giá trị lớn hơn giá trị lớn nhất hay nhỏ hơn

giá trị nhỏ nhất của đoạn, hay giá trị 0 hoặc không có giá trị nào. Ví dụ, Khi xác định giá

trị đầu vào dạng số, cần quan tâm tới các câu hỏi sau:

o Trường đó chỉ nhận giá trị số hay nhận cả giá trị là anphabel?



o Điều gì sẽ xảy ra nếu nhập giá trị anphabel? hệ thống có cho phép nhập không? Nếu

không thì có thông báo lỗi không?

o WĐiều gì sẽ xảy ra nếu giá trị nhập vào là các ký tự mà các ký tự này thuộc riêng về

ứng dụng đó hay do công nghệ. Ví dụ, khi nhập các ký tự đặc biệt như dấu “&” trong ứng

dụng Web (Web applications)? Khi này hệ thống có bị phá vỡ không?

Hệ thống nên mặc định không cho người dùng nhập các giá trị nằm ngoài khoảng biên

hoặc thay vào đó là hiển thị thông báo lỗi khi họ nhập các giá trị nằm ngoài giá trị cho

phép.

Ma trận trực giao cho phép test với mức bao phủ lớn nhất, các trường hợp có thể xảy

ra đều được test. Ma trận trực giao rất hữu dụng khi khối lượng dữ liệu đầu vào lớn hoặc

sự kết hợp dữ liệu lớn và không thể tạo ra tất cả các test case cho mỗi trường hợp kết hợp.

Để hiểu rõ về nội dung của ma trận trực giao, chúng ta nên tìm hiểu ví dụ cụ thể sau:

Giả thiết có 3 tham số A, B và C. Mỗi tham số có thể nhận 3 giá trị là 1, 2 và 3. Việc test

tất cả sự kết hợp của 3 tham số trên yêu cầu phải có 27 test case. Nhưng 27 test case đó

có thực sự cần thiết không? Điều này là không cần thiết nếu tester nghi ngờ có lỗi xảy ra

thì sẽ thiết đặt giá trị đặc biệt cho 3 tham số trên ( ví dụ, có lỗi xảy ra cho case sau: A=1,

B=1, và C=1).

Tuy nhiên, lỗi còn phụ thuộc vào giá trị 2 trong 3 tham số. Trong trường hợp này, lỗi có

thể xảy ra ở 1 trong 3 test case (A=1, B=1, and C=1); (A=1, B=1, and C=2); và (A=1,

B=1, and C=3). Trong các test case trên, nếu chỉ có giá trị của C là thay đổi thì chỉ cần 1

test case là đủ. Với giả thiết trên thì ma trận trực giao sẽ cần 9 test cases sau:

Ma trận trên gọi là ma trận trực giao vì cứ 2 tham số ( A và B), (B và C) hay ( A và C)

đều được kiểm tra 1 lần. Mỗi 1 test case kết hợp cảu 2 tham số trên có thể được gọi là ma



trận trực giao cảu 2 tham số, chứ không phải của 3 tham số vì không phải tất cả 3 tham số

đều xảy ra sự kết hợp. Ví dụ, sự kết hợp

(A=1, B=2, and C=3) sẽ không xuất hiện. Vậy, điều quan trọng ở đây là cách nào để bao

phủ hết tất cả các trường hợp có thể?

Người thiết kế phải chọn bộ dữ liệu mẫu nằm trong khỏang giá trị chấp nhận. Đôi khi

điều này rất khó khi mối tương quan giữa các tham số là rất lớn, nhiều. Trong những

trường hợp này, tester có thể thêm các mẫu ngẫu nhiên có thể.

Nói chung là không thể, không khả thi và không mang lại hiệu quả khi test một hệ thống

sử dụng tất cả các phép hoán vị là sự kết hợp của các tham số. Do đó, điều quan trọng là

sử dụng cách phân tích giá trị biên với các kỹ thuật test khác như phân lớp tương đương

và ma trận trực giao để đưa ra tất cả các trường hợp test có thể và đầy đủ, chính xác.

3.8. Tránh sự ràng buộc và chi tiết các yếu tố dữ liệu trong các test cases.

Phần trên thảo luận về sự quan trọng của các template cho test Procedure để xác định và

cụ thể hoá các bước trong tài liệu này.

Template nên viết theo cách chung nhất để có thể sử dụng cho nhiều dự án (tái sử dụng).

Test case không nên có các dữ kiện đặc biệt vì điều này dẫn đến sự không cần thiết ở 1

dự án khác. Mối kịch bản, tất cả các bước thao tác phải được lặp lại, chỉ thay đổi duy nhất

là bộ dự liệu đầu vào và kết quả mong đợi. Ví dụ về sự không cần thiết trong template

test Procedure như sau: xem xét URL liên quan tới các test case trong test Procedure ra

sao? Nếu URL thay đổi thì nó phải được sửa trong tất cả các test cases, và điều này rất

mất thời gian và xảy ra lỗi.

Để test Procedure có thể sử dụng lại một cách dễ dàng, các dữ liệu đầu vào đặc biệt và

kết quả mong đợi liên quan nên cho vào tài liệu riêng biệt. Các kịch bản test dữ liệu đặc

biệt nên cho ra các sheet tách rời hay các file riêng nên phải viết các test case riêng. Các

kịch bản test này có thể attach theo test Procedure với các dữ liệu đưa ra cụ thể. Khi xuất

phát từ dữ liệu cụ thể, dữ liệu này phải được lấy từ kho dữ liệu mà nó được tham chiếu

đến và mang tính ràng buộc. Điều này đảm bảo test Procedure được tái sử dụng và tránh

được những khó khăn gặp phải vớicác kịch bản đặc biệt.

Mục 3.7.1 đưa ra các ví dụ đơn giản về sự tách rời các kịch bản test trong việc kiểm tra

các ID và password của người dùng khi test chức năng log on hệ thống.

Khi này, việc kiểm tra log on hệ thống của người dùng có thể sử dụng lại các test case

của các dự án trước. Chú ý việc sử dụng lại file tách rời nên có cột “kết quả thực tế” của



dự án test sau đó (cột này không được hiển thị trong mục 3.7.1). Do đó, testers phải diễn

tả kết quả mong đợi trong khi test mà không cần dựa vào dự án trước.

Mục 3.7.1. Ví dụ về bảng kịch bản test 2 chiều.

Kịch bản test được mô tả trong mục 3.7.1 là test Procedure tách rời mà mục đích của nó

là có hiệu quả cao. Giữ lại dữ liệu test trong các bảng dữ liệu 2 chiều hoặc trong database,

được tham chiếu trong test Procedure chính sẽ cho phép giữ lại test Procedure dễ dàng và

hiệu quả hơn.

Test Procedure với các yếu tố dữ liệu được giữ lại ngoài tài liệu chính sẽ giúp ích rất

nhiều trong test tự động và có thể thiết lập như là nền tảng cho các tài liệu lần sau.

Cả test Procedure hướng dẫn và tự động, các yếu tố dữ liệu nên được tách thàh các kịch

bản khác nhau, sử dụng các biến số thay cho giá trị code cứng, và điều này được thảo

luận trong chương 8.

3.9. Áp dụng Exploratory Testing (test qua toàn bộ chương trình).

Như đã bàn luận phần trên, Khi hoàn thành và chi tiết hoá được các yêu cầu sẽ xác định

được các mối quan hệ và phụ thuộc trong các môi trường phát triển. Thường thì 1 tester

phải sử dụng kỹ năng phân tích của họ để xác định tính phức tạp của ứng dụng. Đôi khi

cần có exploratory testing để có kiến thức vững vàng, cần thiết cho thiết kế test hiệu quả.

Exploratory testing hữu dụng nhất khi kiến thức về hệ thống còn mơ hồ. Ví dụ với các

đặc tả chức năng không đầy đủ, rõ ràng hoặc khi không đủ thời gian để nghiên cứu kỹ

thiết kế chi tiết và tài liệu khác để test thì Exploratory tests rất hữu ích. Exploratory tests

làm tăng cường khả năng test.

Exploratory testing xác định các điều kiện test dựa trên các mục tiêu lặp lại. Vấn đề sớm

được tìm ra trong exploratory testing là giúp tập trung trực tiếp vào nỗ lực test sau đó. Ví

dụ, nếu sự tích hợp hệ thống ban đầu chỉ ra rằng có 1 phần của hệ thống có khá nhiều lỗi,

còn các phần còn lại khá ổn thì sẽ tập trung test lại dựa trên thông tin phản hồi này.

Phần test và xác định ra lỗi trong suốt quá trình exploratory testing nên được đánh giá để

xác định sự tương quan với các phần phức tạp của phần mềm. Không giống với quá trình

test được sự cân nhắc kỹ càng và có kế hoạch, exploratory tests không được xác định

trước hay thực hiện hoàn toàn theo kế hoạch. Tất cả nỗ lực test mong muốn exploratory

testing được test trước hay test thêm, kể cả việc test dựa trên yêu cầu chi tiết nhất hay yêu

cầu đó chỉ trên lý thuyết (không được tài liệu hoá). Khi tester thực hiện test, phát hiện ra

lỗi và cố gắng tạo lại và phân tích chúng, exloratory testing chắc chắn đưa ra nguyên

nhân của vấn đề này. Thêm vào đó, trong suốt quá trình tìm kiếm lỗi, mối liên quan của



của lỗi tới các phần khác của ứng dụng được phát hiện. Điều này thường yêu cầu thực

hiện các bước kiểm tra các giá trị ngoài giá trị biên theo các kịch bản đã được tạo ra.

Một vấn đề khác của exploratory testing khi tester phải xác định các ngưỡng (giá trị lớn

nhất và nhỏ nhất) của các tính năng đặc biệt.

Xem xét ví dụ sau:

Có một yêu cầu như sau: “ Trường đó phải cho phép tạo ra danh sách các quyền lựa

chọn” . Dựa vào danh sách dữ liệu để xác định quyền lựa chọn (“pick-list items") và giới

hạn các quyền đó, câu hỏi đầu tiên của testers là “Có bao nhiêu quyền được lựa chọn?”.

Trong ví dụ này, câu hỏi trên thường bị bỏ qua trong suốt giai đoạn lấy yêu cầu của khách

hàng (thậm chí vấn đề còn bị bỏ qua trong quá trình walk-throughs và kiểm thử)

Tester nghiên cứu sự tồn tại của yêu cầu và hỏi phía phát triển nhưng câu trả lời không

phải lúc nào cũng đáp ứng được vì nhiều khi chính khách hàng cũng mơ hồ về yêu cầu

của họ. Điều cần thiết cho tester để viết test cases và thực hiện test là xác định có bao

nhiêu quyền lựa chọn trong trường cho phép. Khi tester thêm quyền thì hệ thống bắt đầu

suy biến hoặc để đơn giản thì hệ thống không cho phép người dùng thêm mới quyền

khác. Testers phải xác định số lượng quyền giới hạn.

Sau khi kiểm thử với quyền được chấp nhận thì testers khẳng định được tất cả các quyền

còn lại.

Tester tiêp tục test mối liên hệ giữa các trường (và các quyền lựa chọn giữa chúng), điều

này được mô tả trong phần 3.3.

Exploratory tests không được lập kế hoạch trước vì chúng được kiểm soát theo trường

hợp case-by-case. Tuy nhiên, viết tài liệu cho exploratory tests có thể thực hiện trước hay

sau khi test đều được. Thực hiện test hồi qui đối với trường hợp này (test hồi qui

(regression testing) được bàn tới trong phần sau)

Exploratory testing chiếm khá nhiều nỗ lực test: Nó làm tăng việc test chức năng, và

được thảo luận trong phần 3.3.

Khi sử dụng exploratory testing, phạm vi test thường không xác định hay đo lường được

và các chức năng quan trọng có thể bị bỏ xót. Điều quan trọng là các test case về test các

chức năng cần được tăng lên với sự hiểu biết sâu về các chức năng này trong suốt quá

trình exploratory testing, và coi tài liệu này như là "living documents" đã được thảo luận

trong phần 3.4.

Để có thể test hiệu quả nhất thì cần có sự kết hợp giữa kế hoạch test hoàn hảo, chiến lược

test tốt với các test cases đầy đủ và chuẩn, kết hợp với kỹ năng phân tích các chức năng



và sử dụng các kỹ thuật test thích hợp như kỹ thuật phân lớp tương đương, kỹ thuật test

biên và ma trận trực giao (đã được thảo luận trong phần 3.5), và sau đó là tăng việc test

exploratory testing có cơ sở.

Vì không có đủ thời gian để viết tài liệu cho tất cả các kịch bản test, sự thay đổi và kết

hợp của các tài liệu này. Exploratory testing là kỹ thuật test quan trọng, nó đảm bảo độ

bao phủ các tình huống trong 1 chu kỳ test.

4. CÔNG CỤ TEST TỰ ĐỘNG.

Công cụ test tự động có thể làm công việc test hiệu quả hơn vì quản lý được kết quả

mong đợi, công cụ test tự động được hiểu và tương thích với thiết kế hệ thống được chọn.

Điều quan trọng là công cụ test này cũng cho kết quả hợp với trường hợp test thủ công.

Có rất nhiều loại công cụ test tự động khác nhau cho các giai đoạn phát triển, bao gồm

the highly touted capture/playback testing tools.

Công cụ test được xác định sau khi nghiên cứu và đánh giá nhưng đôi khi không tìm

được một công cụ nào thích hợp 1 cách hoàn toàn cho 1 dự án. Trong trường hợp này, về

phương diện thương mại thì có những tool có thể áp dụng vào test được nhưng nó lại thừa

tính năng mà dự án cần thiết nên giá cả rất đắt. Như vậy, cần tìm 1 tool khác thích hợp.

Việc xây dựng và chọn lựa 1 tool phù hợp được uỷ quyền cho người thích hợp; đặc biệt

đối với phần đặc biệt của phần mềm, hay những phần có rủi ro cao hoặc những phần

không test được bằng tool cũ. Trong trường hợp này, đặc biệt khi đầu tư khoản tiền lớn

vào test tool thì cần có sự quan tâm của tất cả mọi người trong công ty. Một tool được

chọn hay xây dựng phải thích hợp với công nghệ được chọn và thích hợp với ngân quỹ

của công ty, cũng như thời gian nghiên cứu nó phải nằm trong giới hạn cho phép. Tiêu

chuẩn đánh giá được thiết lập và tính khả thi của tool đó được đánh giá và kiểm tra trên

các chuẩn đó. Từ đó mới ra quyết định mua hay không. Việc đánh giá và đưa ra lựa chọn

1 tool xác định để test dự án càng được đưa ra sớm càng tốt, vì khi này tránh được sự

thay đổi chi phí của dự án sau này.

4.1. Các loại testing tools

Trong khi các test tool chức năng (còn được gọi là "capture/playback tools") được chào

bàn rất nhiều thì điều quan trọng phải có được kiến thức về các tools khác nhau để chọn

được 1 tool hỗ trợ được việc test phù hợp với dự án. Trong bảng 31.1 cho chúng cái nhìn

tổng quan về các tools hỗ trợ các giai đoạn khác nhau của dự án. Mặc dù có rất nhiều tool

khác nhau, như tool theo dõi lỗi (defect-tracking tools) và tool quản lý cấu hình



(configuration-management) và chúng có thể sử dụng trong hầu hết các dự án phần mềm,

nhưng trong bảng 31.1 cũng chỉ đưa ra các tools tiêu biểu.

Tất cả các tools được đưa ra trong bảng này rất có giá trị trong việc cải thiện chu trình

test. Tuy nhiên, trước khi công ty đi đến quyết định mua 1 tool nào đó thì người được uỷ

quyền phân tích tool đó phải kiểm tra tool đó kỹ nhằm xác định được tool tốt nhất cho

quá trình test. Ưu nhược điểm của 1 tool được kiểm tra qua việc so sánh các kết quả mà

nó mang lại với mục tiêu cần chọn 1 tool. Từ đó đánh giá tiềm năng thực hiện và chỉ đạo

người phân tích lợi ích và chi phí (cost/benefit). Trước khi mua 1 tool thì phải chắc rằng

nó hỗ trợ hoạt động thiết kế, kỹ thuật phần mềm. Quá trình đánh giá 1 testing tool được

mô tả trong phần 34.

Bảng 31.1. Test Tools



Dưới đây là một vài điểm mấu chốt về các tools khác nhau:

Người nghĩ ra Test-procedure.

Một tool quản lý các yêu cầu có thể đi đôi với một người nghĩ ra các test procedures.

Tool quản lý yêu cầu được sử dụng để lấy các thông tin yêu cầu của khách hàng. Sau đó,

đến giai đoạn tạo ra các test procedures. Người này tạo ra các test procedures dựa vào

cách thức thống kê, thuật toán và kinh nghiệm. Trong khi việc tạo ra các test procedures

nhờ việc thống kê thì tool sẽ chọn cấu trúc và giá trị đầu vào trong trường hợp thống kê

ngẫu nhiên, hoặc đưa ra sơ lược các thức sử dụng phần mềm khi test.

Thông thường người thiết kế ra test procedures thực hiện các thao tác, dữ liệu, logic, sự

kiện với tool này. Mỗi 1 hoạt động trên nhằm tìm ra các lỗi khác nhau của phần mềm.

Trong trường hợp tạo ra các test-procedure nhờ vào kinh nghiệm, tool này sẽ sử dụng các

thông tin được cung cấp bởi testers. Các lỗi tester tìm được trong quá khứ sẽ là đầu vào

của tool này (Tool này sử dụng các lỗi trong quá khứ để tạo ra các test procedures).

Người phân tích code và công cụ viết code.

Việc đo lường mức độ bao phủ của code đảm bảo cho nhóm phát triển và nhóm test nhìn

thấu được sự việc, vấn đề để thực hiện viết code và test hiệu quả. Tool để làm được điều

này có thể xác định được độ phức tạp của thiết kế, đo lường số lượng test tích hợp được

test và không được test. Tool khác đo lường độ phức tạp của độ bao phủ test là sự phân

đoạn, chia nhánh và các mức độ điều kiện khác. Mức độ bao phủ của test phụ thuộc từng

phần mềm cụ thể.

Công cụ tìm ra sự thiếu hụt bộ nhớ.

Các tool tìm ra sự thiếu hụt của bộ nhớ được sử dụng trong các mục đích đặc biệt: Kiểm

tra xem phần mềm đó dùng tài nguyên bộ nhớ có phù hợp không. Bộ nhờ liên quan tới

nhiều lỗi của chương trình, bao gồm việc thực hiện các vấn đề đặt ra.



Công cụ đo lường các tiện ích.

Test tiện ích là test phạm vi rộng lớn của chương trình, bao gồm test về thiết kế giao diện,

thiết kế đồ hoạ, nhân tố con người, dân tộc học, tâm lý học… Test tiện ích nhằm mang lại

sự thoải mái, thuận tiện mà các đặc tính, tính năng của giao diện phần mềm mang lại cho

người sử dụng. Do vậy, việc test giao diện phải được test thủ công của con người. Tuy

nhiên, vẫn có một số tool test tự động có thể hỗ trợ quá trình này.

Test-data.

Test dữ liệu hỗ trợ quá trình test thông qua tool test dữ liệu. Có nhiều tool test hỗ trợ việc

test dữ liệu và database. Muốn Test dữ liệu thì phải vào được database. Và điều này thực

hiện được thông qua việc thiết đặt vai trò để có thể thực hiện test chức năng, load testing,

or performance and stress testing.

Công cụ quản lý test.

Công cụ quản lý test hỗ trợ lập kế hoạch test, việc quản lý và phân tích toàn bộ diện mạo

chu kỳ test. Một vài tool quản lý test như Rational's Test Studio. Tool này quản lý bằng

cách kết hợp với việc quản lý các yêu cầu, quản lý cấu hình và tool theo dõi lỗi.

Công cụ test Web

Tính phổ biến của các ứng dụng Web là hoạt động theo mô client server hoặc môi trường

Web. Test Cũng khá phức tạp khi xác định nỗ lực cho test Web. Testers không chỉ test

trên 1 môi trường mà còn phải test trên nhiều môi trường khác. Cấu trúc Client-server

liên quan tới 3 đối tượng tách rời là server, client, và network. Inter-platform. Sự kết nối

giữa chúng có thể gây lên lỗi. Do đó, quá trình test phải bao quát hết được sự thực hiện

của server và network, sự thực hiện của toàn bộ hệ thống cũng như các chức năng liên

quan. Nhiều công cụ test Web cho phép giám sát, đo lường, test và đoán toàn bộ chương

trình.

Tool test GUI (capture/playback tools).

Trên thị trường có rất nhiều tool test GUI. Các tool này thường gồm chức năng record-

and-playback, chức năng cho phép testers tạo ra (record), sửa và chạy (playback) công

việc test tự động trong nhiều môi trường. Các tools này record các đối tượng GUI hay

mức độ “widget” (không phải mức độ ảnh bitmap). Thao tác record chụp lại các thao tác

trên bàn phím mà testers nhập vào, tự động tạo ra các scripts trên nền tảng ngôn ngữ lập

trình bậc cao. Việc record này là chương trình được đề cập đến như 1 kịch bản test. Tuy

nhiên, nếu chỉ sử dụng chức năng capture và playback thì mới chỉ sử dụng 1 phần 10

chức năng của tool. Để có kết quả tốt nhất khi thực hiện chức năng capture/playback,



testers nên tận dụng ngôn ngữ kịch bản đã được xây dựng của tool đó. Xem phần 36 sẽ

cho chúng ta biết nhiều hơn rằng tại sao không chỉ sử dụng mỗi chức năng

capture/playback. Kịch bản record phải do người thiết kế ra nó sửa lại để có thể tái sử

dụng và duy trì kịch bản này trong các procedures. Kết quả của các scripts cho ra các

baseline test. Các script có thể được chạy lại trong nhiều phần mềm sau đó để so sánh kết

quả của các baseline.

Một testing tool cung cấp khả năng record và thường kèm theo đó là công cụ so sánh. Sự

so sánh này là so sánh giữa kết quả đầu ra thực tế với kết quả mong đợi và log lại kết quả

so sánh đó. Tool có thể so sánh giữa các điểm ảnh với nhau (pixel-by-pixel), giữa các ký

tự với nhau (character-by-character), hay các đặc tính với nhau (property-by-property), và

điều này phụ thuộc loại so sánh mà test cần thực hiện. Tool này sẽ tự động xác định sự

khác nhau giữa kết quả mong đợi và kết quả thực tế. Ví dụ, Rational Robot và Mercury's

Winrunner có thể ghi lại kết quả xác thực của việc test là pass và mô tả kết quả pass trong

phần màu xanh lá cây trên màn hình và kết quả fail thì được mô tả bằng màu đỏ.

Load, performance, and stress testing tools .

Performance-testing tools Cho phép testers xem xét thời gian trả về và khả năng load dữ

liệu của một hệ thống hay ứng dụng. Các Tools này có thể được lập trình chạy trên nhiều

máy clients một lúc để đo lường thời gian trả về của hệ thống client-server khi có nhiều

người cùng truy cập hệ thống cùng một thời điểm. Stress testing liên quan tới việc chạy

máy client với rất nhiều kịch bản để xác định xem hệ thống có bị sụp không và khi nào

thì bị sụp.

Công cụ chuyên dụng

Các kiểu ứng dụng và các cấu trúc ứng dụng khác nhau sẽ cần các công cụ test chuyên

dụng cho từng phần kiến trúc đặc biệt. Ví dụ, Web application cần test Web đó không có

đường link bị hỏng, không link được và test tính bảo mật của Web servers.

4.2. Xây dựng 1 tool thay cho việc mua một tool.

Giả định nhóm test sẽ thực hiện test tự động 40% trong việc test dự án bằng công cụ

capture/playback tool. Khi này, để test tự động hiệu quả cần yêu cầu nhóm phát triển hỗ

trợ về code để test thuận lợi hơn. Nhóm test cần quan tâm tới việc xây dựng 1 tool test tự

động mới để làm nổi bật chức năng capture/playback của tool đó.

Sự không tương thích của 1 tool là nguyên nhân dẫn đến test không đầy đủ các trường

hợp của chương trình. Đôi khi 1 ứng dụng không thích hợp với việc sử dụng tool để test



vì không có tool nào thích hợp cho việc test nó hoặc để thực hiện chức năng

capture/playback quá phức tạp và mất nhiều thời gian.

Như vậy, việc mua hay xây dựng 1 tool do người quản lý quyết định, và nó còn phụ thuộc

vào ngân quỹ và nguồn lực được phê duyệt. Quá trình dẫn đến quyết định mua tool cần

được đánh giá cẩn thận. Những ý kiến tán thành hay phản đối cần được cân nhắc kỹ. Việc

xây dựng 1 tool đơn giản thì rất dễ dàng và rẻ hơn là đi mua, nhưng nếu xây dựng không

thành công, xây dựng lên 1 tool lộn xộn thì tính ra lại đắt bằng hoặc thậm chí đắt hơn là

bỏ tiền ra mua

Tính không tương thích của các hệ thống.

Nếu như không có 1 tool nào hiện tại đang có trên thị trường thích hợp với các hệ thống

khác nhau đang chạy thì nên xây dựng 1 tool riêng, theo yêu cầu của mình.

Tính không tương thích của ứng dụng.

Một ứng dụng test có thể chứa 1 yếu tố là có tester biết về chức năng capture/playback

của các tools trên thị trường. Nhưng nếu tool đó không được sử dụng lại trong các phần

mềm sau đó thì tiền bỏ ra mua nó là lãng phí. Việc tái swr dụng nó thông qua việc có thể

tái sử lại các scripts.

Sự cần thiết của công cụ test chuyên dụng.

Để test đạt hiệu quả nhất thì các scipts phải là đại diện nhất. Công việc test phải được

phát triển để làm tăng khả năng test GUI.

Nếu như quyết định là xây dựng 1 tool thì các vấn đề quan trọng cần quan tâm là:

Xác định nguồn lực, ngân quỹ, và thời gian cần thiết cho việc xây dựng tool đó.

Sự phê duyệt của người quản lý về các yếu tố trên.

Coi sự phát triển 1 tool như nỗ lực phát triển 1 phần mềm.

Quản lý mã nguồn của tool trong việc kiểm soát phiên bản của hệ thống. Nếu không

kiểm soát được nó thì không dễ dàng đồng bộ hoá phần mềm và ngừng các chức năng

một cách thích hợp.

Coi việc phát triển 1 tool như mục đích chính. Khi việc phát triển 1 tool không được coi

như 1 dự án thì ít khi nó được phát triển tốt.

Với một số phần codes sẽ được test với tool của công ty phát triển được nhằm kiểm

tra chương trình có đáp ứng các yêu cầu của khách hàng không. Nhược điểm của tool này

là không khẳng định được kết quả fail hay không.

Quá trình xây dựng 1 tool có thể được thực hiện từ bước viết các file đơn giản hoặc ngôn

ngữ kịch bản Perl đến bước tạo ra các ứng dụng phức tạp của ngôn ngữ C++. Ngôn ngữ



thích hợp để xây dựng 1 tool phụ thuộc vào các thao tác cần có và các chức năng cần test.

Ví dụ, nếu chức năng cần test là kiểm tra kỹ càng sự tính toán phức tạp của C++ với hàm

tính toán DLL bằng việc sử dụng một vài hay toàn bộ dữ liệu đầu vào có thể, giải pháp

thích hợp có thể là chương trình C++ gọi trực tiếp DLL, cung cấp sự kết hợp cần thiết để

đánh giá và kiểm tra kết quả test.

Thêm vào đó, việc nghiên cứu testing tool trên thị trường và xem xét việc xây dựng 1 tool

thích hợp sẽ có ích rất nhiều so với việc tập hợp nhiều các phần mềm miễn phí hay cần

bản quyền trên Internet. Một số phần mềm có thể nghiên cứu như DejaGNU, TETware,

xUnit, và Microsoft's Web Application Stress Tool (WAST), trong khi đó, một số phần

mềm không được thiết kế đặc biệt dành riêng cho việc test nhưng chúng có thể có ích

trong 1 tình huống nào đó như macro-recorders, XML editors, và các tool chuyên dụng.

Cuối cùng, hãng cung cấp tool lớn thường chào giá thấp với các phiên bản thấp (tính

năng ít nhất) đối với các tool của họ, vì họ sợ chào giá các phiên bản cao thì kinh phí của

các công ty không đáp ứng được. Ví dụ, Mercury chào bán Astra line, Rational chào bán

Visual Test, và Watchfire chào bán Linkbot Personal Edition. Những versions đơn giản

này có khả năng với nỗ lực việc test trong trường hợp nào đó khi ngân quỹ của 1 công ty

không đủ để mua tool đắt hơn.

4.3. Ảnh hưởng của Automated Tools đến nỗ lực test

Công cụ test tự động chỉ đơn thuần là một phần của giải pháp, chúng không phải là 1 giải

pháp kỳ diệu nhất trong vấn đề test. Công cụ test tự động không thay thế được kỹ năng

phân tích, sự quản lý test cũng như không thay thế được test thủ công. Công cụ test tự

động phải được nhìn nhận như 1 sự nổi bật hơn so với quá trình test thủ công.

Với ý tưởng trên, công cụ test tự động được trông đợi hỗ trợ test thủ công quá nhiều. Một

số người có quan niệm rằng công cụ test tự động không thể thực hiện mọi thứ từ khi có

kế hoạch test đến khi thực hiện test nếu không có test thủ công. Một số người có quan

niệm sai lầm nữa là coi test tool sẽ thực hiện test được tất các yêu cầu của khách hàng,

không phân biệt các thông số của các môi trường khác nhau như về ngôn ngữ lập trình

khác nhau… Tuy nhiên, nhân tố môi trường được đặt ra để xác định giới hạn test thủ

công và test tự động.

Có một số giả thiết không đúng khi cho rằng sử dụng công cụ test tự động sẽ giảm nỗ lực

và thời gian test.

Thỉnh thoảng, sự cố gắng sử dụng test tự động sẽ bị thất bại bởi nó là phi hiện thực,

không thể thực hiện được hay chọn nhầm tool.



Danh sách các yếu tố sau sẽ chấn chỉnh lại các quan điểm sai lệch ở trên về testing

tool và giúp tránh chọn nhầm tool test:

Nhiều tools được yêu cầu.

Nói chung, chỉ 1 tool thì không thể đáp ứng test hết các yêu cầu của tất cả các phần mềm

của 1 công test, trừ khi các phần mềm của công ty đó có cùng 1 kiểu hệ thống hay 1 kiểu

ứng dụng.

Điều này là 1 trong các nguyên nhân giải thích tại sao cần nhiều tool để đáp ứng nhiều

công nghệ khác nhau. Ví dụ, nhiều tool được thừa nhận kiểm soát được giao diện người

dùng. Nó có thể tương thích với ngôn ngữ chính được dùng để phát triển ứng dụng,

nhưng vẫn không thể biết nó có tương thích với tất cả các ngôn ngữ hay không trừ khi

hãng cung cấp khẳng định là tool đó tương thích với tất cả các ngôn ngữ.

Phần 34 sẽ thảo luận việc đánh giá và mua 1 tool thích hợp cho môi trường phát triển

phần mềm.

Nỗ lực test không giảm.

Động cơ thúc đẩy đầu tiên khi muốn sử dụng 1 tool test tự động là giảm nỗ lực test. Kinh

nghiệm chỉ ra rằng, để áp dụng được tool vào thực tế công việc test cần có sự nỗ lực

nghiên cứu và học về công cụ đó. Thời gian đầu sẽ mất rất nhiều nỗ lực cho việc record

các scripts và sau đó là sửa chúng để tái sử dụng lại. Và việc này tốn nhiều nỗ lực hơn so

với test thủ công. Tuy nhiên, một số Test manager hay PM có thể đọc và hiểu được các

tài liệu và cách thức áp dụng tool đó như thế nào nhưng khả năng áp dụng nó vào thực tế

công việc của mình thì lại là vấn đề hoàn toàn khác.

Điều ngạc nhiên là, khi áp dụng tool lần đầu thì nỗ lực test ban đầu sẽ bị tăng lên. Nỗ lực

cần phải tính cho đến khi testers thành thạo tool đó. Người quản lý phải hiểu rằng không

có 1 tool nào có thể thay thế hoàn toàn cho test thủ công.

Thời gian dự án không giảm.

Một quan niệm sai về automated testing là khi áp dụng tool này cho 1 dự án mới thì ngay

lập tức thời gian của dự án sẽ giảm đi. Do nỗ lực test khi áp dụng công cụ test tự động lần

đầu thực tế là tăng nên thời gian của dự án cũng phải tăng theo. Một công cụ test tự động

sẽ cho phép test được đầy đủ hơn các tình huống nhưng nói chung thì thời gian của dự án

không thể giảm ngay lập tức được.

Automated testing dựa vào vòng đời phát triển của phần mềm.

Khi mới áp dụng 1 tool ở giai đoạn đầu thì cần phân tích kỹ ứng dụng dưới góc độ test để

xác định phần nào của ứng dụng có thể test tự động. Và cũng cần thiết phải quan tâm tới



sự phát triển và thiết kế các procedure. Nỗ lực automated test được xem xét như 1 dự án

nhỏ mà kế hoạch của nó có sự kết hợp nỗ lực của cả phía lập trình.

Yêu cầu ứng dụng phù hợp.

Một phần mềm phải thích hợp để test tự động có hiệu quả khi sử dụng chức năng

capture/playback. Việc test tự động không thể thực hiện cho toàn bộ chương trình nhưng

cần thực hiện ở 1 phần nào đó của phần mềm do yêu cầu của phần mềm buộc phải thực

hiện test tự động mà không test thủ công được.

Không nên thực hiện test toàn bộ bằng công cụ test tự động.

Như đã nói ở phần yêu cầu trên, automated testing là công cụ tối ưu hơn test thủ công

nhưng nó không thay thế được test thủ công. Điều quan trọng là phân tích được khi nào

và cái gì thì test tự động, còn lại là test thủ công. Một số trường hợp test không thực hiện

test tự động được như kiểm tra chức năng in của chương trình. Testers có thể tự động gửi

tài liệu đến máy in, khi này hiển thị 1 thông báo là “in thành công”, nhưng testers phải

kiểm tra kết quả bằng cách xem máy in có thực sự in ra tài liệu mà mình mong muốn

không (nếu in ra thì còn phải kiểm tra xem các thông số in và các thiết lập trang in có

đúng mong muốn không, dữ liệu có bị mất hay không…). Sau đó, kiểm tra nội dung dữ

liệu trên giấy in ra bằng thị giác….

Một test tool không cho phép thực hiện test kết hợp của tất cả các trường hợp.

Một suy nghĩ sai lầm phổ biến cho rằng khi sử dụng test tool thì có thể test tự động 100%

các yêu cầu đặt ra, có thể thực hiện được vô số các lần hoán vị và kết hợp vô số các tình

huống khi test cũng như các thao tác của người dùng. Như vậy sẽ không đủ thời gian để

làm được tất cả các điều đó. Thậm chí, về mặt lý thuyết có thể thực hiện việc kết hợp và

hoán vị như trên thì nhóm test cũng không đủ thời gian và nguồn lực để thực hiện test tự

động 100% toàn bộ chương trình.

Trị giá toàn bộ tool không chỉ tính mỗi giá phải trả cho nó, mà còn nhiều hơn nhiều.

Khi áp dụng 1 tool không chỉ chịu giá mua tool đó mà còn bao gồm cả chi phí đào tạo,

chi phí phát triển scripts tự động, và chi phí bảo trì.

"Out-of-the-box" automation is not efficient.

Để bán được sản phẩm, nhiều hãng cung cấp tool thổi phồng cách sử dụng của tool đó,

rằng tool này rất dễ sử dụng…Họ không cần chú ý tới thời gian, nỗ lực học tool khi một

công ty mua nó. Họ nói rằng, với tool của họ, việc record thật đơn giản đối với testers, và

sau đó việc tạo ra các scripts cũng vậy, rất đơn giản khi muốn played back. Nhưng để test

hoàn hảo thì thật chẳng đơn giản chút nào. Nói chung, để tạo ra các scripts test không hề



đơn giản chút nào, trong suốt quá trình record, các scipts này phải sửa và việc sửa phải

tiến hành thủ công bằng tay và người tạo các scripts. Điều quan trọng khi viết scripts là

viết sao cho thật rõ ràng, thiết thực để kiểm tra được; ngoài ra còn phải viết sao để sau

này có thể tái sử dụng nó trong các phần mềm sau.

Training.

Đôi khi 1 tester chỉ có thể biết cách sử dụng tool đó đủ để thực hiện test một số trường

hợp thôi vì họ không được đào tạo về tool đó, nên không thể biết hết các hỗ trợ, chức

năng của nó. Khi đưa 1 tool vào sử dụng test 1 dự án mới, điều sai lầm quan trọng đã

không tính đến thời gian training cách sử dụng tool trong thời gian dự án và không quan

tâm tới các mốc quan trọng (milestones). Do vậy, trong suốt quá trình test từ đầu đến cuối

dự án, việc training tool không được tiến hành trước và sớm nên khó có thể áp dụng

chúng thành công trong dự án. Nếu việc training được tiến hành sớm sẽ đảm bảo áp dụng

tool vào ngay khi bắt đầu test. Khi này các vấn đề của tool cần giải quyết cũng sớm được

phát hiện ra và giải quyết sớm. Theo cách này, khả năng áp dụng test tool được thực hiện

ngay từ đầu dự án.

Đôi khi việc training về tool ngay từ đầu dự án cũng là quá muộn. Ví dụ, chỉ thực hiện

chức năng capture/playback của test tool thì các scripts phải tạo lại, như vậy rất lãng phí

nỗ lực. Nếu như testers được đào tạo sớm và nhiều hơn về test tool thì họ sẽ sử dụng

thành thạo và có khi không phải tạo lại scripts mà có thể tái sử dụng lại scripts của dự án

trước.

Testing tools có thể xâm nhập.

Một số test tool có thể xấm nhập vào phần mềm cần test, để chúng hoạt động tốt cần phải

chèn vào mã đặc biệt vào phần mềm để tích hợp phần mềm với test tool. Khi này phía lập

trình sẽ không thoải mái vì để làm được điều trên thì họ phải thêm code. Họ sợ điều này

vì nếu làm vậy rất có thể phần mềm hoạt động không đúng cách hoặc khi phải sửa code

sẽ rất phức tạp.

Để tránh nhiều xung đột, mâu thuẫn có thể xảy ra, testers lên cùng với phía phát triển

chọn ra 1 test tool. Nếu test tool cần phải thêm code (không phải tool nào cũng cần thêm

code), developers cần được biết trước. Để một lần nữa đảm bảo cho developers không

gặp vấn đề khó khăn cũng như phức tạp thì công ty cần yêu cầu phía cung cấp tool phải

đưa ra kinh nghiệm sử dụng tool và được thể hiện bằng tài liệu.

Testing tools có thể không ổn định.



Testing tool có thể không ổn định với tất cả công nghệ. Ví dụ, với 1 công nghệ nào đó thì

tool này không thực hiện thao tác lưu lại các thao tác, baselines không được lưu lại hay

tool này không cho kết quả như mong muốn. Nếu có nhiều thưòi gian thì cần nghiên cứu

xem tool đó có các vấn đề gì hay xảy ra hay nó có back-up được các thao tác hay không

(repository). Testing tools bản thân nó cũng là 1 phần mềm phức tạp, do vậy, nó cũng có

lỗi và có thể gây trở ngại với nỗ lực test. Chính vì vậy, phải yêu cầu nhà cung cấp sửa lại.

Tất cả các yếu tố trên khiến nỗ lực test tăng lên trong suốt quá trinh test.

Công cụ tự động có thể làm mất đi cách nhìn nhận mục tiêu test cần đạt được là gì.

Thường thì khi 1 công cụ test tự động được sử dụng lần đầu tiên cho 1 chương trình phần

mềm, cần nhiều thời gian cho việc tạo scripts hơn là thời gian test thật sự. Các testers có

thể rất hăm hở tạo các scripts test rất phức tạp, do vậy, có thể làm mất mục tiêu thực sự

cần đạt được khi test. Họ luôn phải nhớ trong đầu rằng các scripts là 1 phần nỗ lực test,

nhưng không thế được chúng. Không phải mọi thứ có thể hay nên tự động. Như đã nói ở

các phần trước, việc đánh giá các phần thích hợp với test tự động là rất quan trọng.

Khi lên kế hoạch test tự động, điều quan trọng là phải xác định rõ ràng sự phân chia trách

nhiệm. Không cần thiết phải cả nhóm test tham gia tạo các scripts mà chỉ cần 1 vài người.

Việc tạo các scripts phải căn cứ vào sự phát triển phần mềm.

4.4. Tập trung vào những gì mà công ty cho là cần thiết

Bất kỳ ai tham gia nhóm test sẽ thường xuyên đỗi mặt với câu hỏi sau: “ Test tool nào là

tốt nhất trên thị trường?”

Người dùng sẽ có những phản ứng với các quan điểm khác nhau trên diễn đàn testing.

Một người dùng có kinh nghiệm nhất về 1 tool cụ thể nào đó sẽ có quan điểm rằng tool

họ đang dùng là tốt nhất. Tuy nhiên, câu trả lời tốt nhất cho câu hỏi trên là “điều đó còn

phụ thuộc”. Tool tốt nhất còn phụ thuộc vào công ty và môi trường thiết kế hệ thống cũng

như môi trường test, phương pháp test và nỗ lực dành cho test tự động.

Những điều sau sẽ hỗ trợ cho việc chọn 1 testing tool.

Xác định loại công cụ vòng đời test cần thiết.

Nếu như vai trò tự động hoá cần nỗ lực lớn của công ty thì công ty sẽ đặt ra câu hỏi:

Công ty muốn tự động hoá để hoàn thành cái gì?. Xác định kết quả mong đợi của quá

trình tự động hoá test để từ đó quản lý được các kết quả mong đợi (điều này đã được thảo

luận trong phần 33).

Đôi khi người quản lý test sẽ chỉ dẫn để tìm ra 1 tool phù hợp với yêu cầu của công ty.

Khi này, TM (test manager) sẽ quan tâm tới môi trường thiết kế hệ thống và các yếu tố



cần thiết khác của công ty để đưa ra 1 loạt danh sách các tiêu chuẩn đánh giá tool. Ví dụ,

môi trường thiết kế hệ thống như thế nào? Công nghệ phát triển phần mềm công ty đang

sử dụng? Việc trả lời những câu hỏi này là 1 phần trong quá trình chọn lựa tool. TM cũng

tìm ra các tool hỗ trợ cho 1 dự án đặc biệt mà họ đang làm, như 1 dự án Web yêu cầu 1

tool test Web riêng. Chúng ta không nên giới hạn các tiêu chuẩn chọn 1 testing tool cho 1

dự án riêng lẻ vì có khi tool này chỉ thích hợp cho 1 dự án tức thời, và sau đó nó bị bỏ đi.

Khi đã quyết định chọn 1 loại testing tool, các tiêu chuẩn có thể được đưa ra nhiều hơn.

Ví dụ, nếu 1 tool được sử dụng nhiều lần cho công ty. testers phải chắc chắn rằng nó có

khả năng chạy được với nhiều hệ thống, ngôn ngữ lập trình và các khía cạnh khác về môi

trường kỹ thuật của công ty. Testers phải xem xét môi trường thiết kế hệ thống bằng cách

đưa ra các câu hỏi và các mối quan tâm đặc biệt như đã được trình bày trong chương này

và các tài liệu tìm thấy.

Xác định các kiến trúc hệ thống khác nhau.

Trong suốt quá trình khảo sát môi trường thiết kế hệ thống, testers phải xác định được cấu

trúc ứng dụng kỹ thuật, bao gồm middle ware (lớp tác nghiệp, thường thuật ngữ này hay

dùng khi lập trình mô hình 3 lớp, lớp 1 presentation là lớp giao diện, lớp 2 là lớp nghiệp

vụ, lớp 3 là lớp database), database và các hệ thống thường được sử dụng nhất trong công

ty hoặc những dự án đặc trưng. Họ cũng nên xác định ngôn ngữ phát triển GUI của mỗi

ứng dụng.

Thêm vào đó, testers cũng cần hiểu chi tiết về thiết kế cấu trúc ảnh hưởng như thế nào tới

việc thực hiện các yêu cầu của khách hàng. Việc xem xét thực hiện 1 yêu cầu phổ biến,

bao gồm thực hiện yêu cầu đó dưới điều kiện heavy loads, cơ chế bảo mật phức tạp, sự đo

lường khả năng và độ tin cậy của hệ thống một cách tốt nhất.

Tiêu chuẩn chọn lựa đặc biệt liên quan tới nỗ lực sẽ phụ thuộc yêu cầu hệ thống thích hợp

của ứng dụng khi test. Nếu không thể sử dụng 1 testing tool cho tất cả các dự án hay ứng

dụng thì có thể thiết lập các tiêu chuẩn chọn lựa liên quan tới các ứng dụng quan trọng

dưới vai trò test.

Xác định chọn 1 hay nhiêu tool.

Khi chọn 1 tool thì tool đó phải đáp ứng các tiêu chuẩn đề ra. Như đã nói ở phần 32, nói

chung 1 tool không thể thoả mãn tất các yêu cầu của 1 công ty. Một tool luôn thay đổi và

phát triển, mức độ bao quát của testing tool đối với các yêu cầu của hệ thống ngày càng

mở rộng và chúng luôn được cải tiến để đáp ứng các yêu cầu mong đợi.



Rút cuộc, 1 tool chỉ lý tưởng cho việc test GUI, tool khác có thể cover khối lượng công

việc test lớn và tool thứ 3 hiệu quả trong việc test các tiện ích. Nhiều tool phụ thuộc vào

các giai đoạn test và tính khả thi của chúng cần được xem xét và tính đến.

Một tool không thể thích ứng với tất cả các phần mềm hay ngôn ngữ lập trình. Ví dụ, khi

test trên máy Client chạy hệ điều hành LINUX kết nối với máy chủ của IBM sử dụng

3270 sessions và máy Java client. Khi này rất khó tìm được 1 tool chạy được cả hệ điều

hành LINUX, Java, và 3270 thiết bị đầu cuối.

Dưới khía cạnh test thì hiểu cách quản lý dữ liệu bằng các ứng dụng như thế nào.

Nhóm test phải hiểu cách quản lý dữ liệu bởi các ứng dụng và xác định cách thức testing

tool hỗ trợ việc kiểm tra dữ liệu như thế nào. Mục đích đầu tiên của hầu hết các ứng dụng

là chuyển đổi dữ liệu thành các thông tin mang ý nghĩa và thể hiện chúng trên giao diện

người dùng hay các form text. Nhóm test phải hiểu việc chuyển đổi dữ liệu được thực

hiện bằng các ứng dụng như thế nào để có chiến lược test đúng với việc kiểm tra sự

chuyển đổi dữ liệu.

Review các thông báo trợ giúp trên màn hình.

Khi 1 ứng dụng hay 1 version của ứng dụng đang hoạt động, nhóm test có thể gặp thông

báo có sự cố gì đó xảy ra được hiện trên màn hình. Các thông báo này thường là những

thông báo lỗi do người dùng nhập liệu. Nếu có 1 version mới, nhóm test tập trung vào

test các báo cáo thường xuyên xuất hiện, bao gồm việc xác định các tool hỗ trợ.

Hiểu rõ các loại test.

Khi 1 dự án được chia thành nhiều giai đoạn, thì điều cần thiết là chọn 1 kiểu test test.

Chiến lược test nên xác định kiểu tesễtm nó là regression testing, stress hay volume

testing, usability testing. Câu hỏi giúp xác định kiểu test phù hợp là: chức năng quan

trọng nhất cần test test bằng tool là gì? Tool sẽ được sử dụng chính để test stress testing?

Có một vài testing tool chuyên dụng trong việc phân tích toàn bộ mã nguồn mở. Chúng

xác định tất cả các đường dẫn mã nguồn mở có thể phải test. Điều này có nên yêu cầu

thành lập 1 dự án đặc biệt hay không? Các tool khác cần quan tâm là các tool hỗ trợ quá

trình tự động và khối lượng dữ liệu load thông qua các file dữ liệu đầu vào. Một số câu

hỏi khác như: Mục tiêu cần đạt được khi test dự án đó là gì? Các chức năng mong đợi là

gì?

Thời gian.



Một điểm khác khi chọn 1 tool là nó ảnh hưởng tới thời gian của dự án. Điều quan trọng

là phải xác định đủ thời gian cần thiết cho testers học về tool. Nếu không có đủ thời gian,

rủi ro nhóm test chọn 1 tool không thích hợp cho dự án, cho công ty.

Ngân quỹ cho phép.

Khi đã xác định được 1 tool thích hợp là điều rất tốt nhưng điều quan trọng là ngân quĩ

của công ty có đáp ứng được hay không. Công ty có thể dành nỗ lực hàng tháng để đánh

giá thế mạnh của tool đó, nhưng chi phí cho nó vượt quá ngân quỹ cho phép. Thêm vào

đó, ngân sách còn phải tính cho cả chi phí training cho testes sử dụng thành thạo tool.

Điều quan trọng nhất testers nên nhớ là không có 1 tool nào tốt nhất cho tất cả các môi

trường phần mềm. Tất cả các tool đều có cái thuận lợi và cái khó khăn với các môi trường

khác nhau. Việc chọn lựa tool nào còn phụ thuộc vào môi trường thiết kế hệ thống và các

yêu cầu cũng như các tiêu chuẩn đặc biệt được công ty đặt ra.

4.5. Kiểm tra tool bằng các Prototype.

Đưa ra 1 loạt các hình ảnh rộng lớn về các kỹ thuật được sử dụng trong khi phát triển

phần mềm. Khi này điều quan trọng là kiểm tra chức năng chỉ dẫn thích hợp của tool với

phần mềm đang phát triển. Cách tốt nhất để hoàn thành việc này là có sự giải thích của

hãng cung cấp tool này về sự tương thích của tool với các phần mềm được test. Tuy

nhiên, điều này thường không thể thực hiện được, do vậy, khi phần mềm được test thì

không được đánh giá về tính tương thích của tool.

Khi có sự lựa chọn, các lập trình viên có thể tạo ra các prototypes để đánh giá các tool

này. Trong suốt quá trình đánh giá, có thể phát hiện ra 1 vài chức năng khác thường của

tool không tương thích với các công nghệ phát triển hiện có của phần mềm. Ví dụ, Nhóm

test không thể thực hiện thao tác capture/playback hay thực hiện các chức năng quan

trọng của tool.

Các prototypes phải dựa vào các phần chính của hệ thống, các phần này là đại diện của

công nghệ dùng phát triển phần mềm. Khả năng thực hiện của tool đặc biệt quan trọng

trong test GUI vì có thể tool rất khó nhận biết các đối tượng trên giao diện. Vấn đề

thường gặp khi các đối tượng là lịch, grids và spin controls được kết hợp trong nhiều ứng

dụng, đặc biệt trên nền Window. Các đối tượng này được gọi duy nhất 1 lần VBXs, sau

đó là OCXs, và bây giờ lại được đề cập đến như Active-X Controls trên Windows và

Web interface. Chúng thường được viết bởi bên thứ 3.

Ví dụ, 1 tool có khả năng nhận ra và tương thích với ngôn ngữ Visual Basic và

PowerBuilder. Nhưng nếu tool này được kiểm soát bởi bên thứ 3 thì rất có thể nó không



nhận biết được các đối tượng trên màn hình. Testers cần xác định được các đối tượng mà

tool này không nhận biết được thông qua cách thức làm việc có trao đổi với nhau để test

các đối tượng này theo cách thủ công.

Những đối tượng không được test bằng tool có thể bị xót không được test nếu testers

không đánh giá được và thực hiện cách test khác thích hợp. Các thành viên đánh giá tool

cũng cần đánh giá trên nền tảng thích hợp.

Thường thì việc đánh giá dựa trên nền tảng kỹ thuật nhằm đảm bảo người thiết kế có thể

sử dụng các prototype để đánh giá các chức năng của tool thích hợp với công nghệ. Hơn

nữa, tính dễ sử dụng, tính mềm dẻo và các đặc tính khác được thảo luận trong phần 34 là

cơ sở đánh giá tốt nhất của các thành viên tham gia đánh giá cho phần mềm đó.

Như vậy là không có gì có thể thay thế trong việc nhìn nhận 1 tool thông qua các

prototype. Một vài hãng có thể đưa ra lời hứa, tool của họ tương thích với nhiều công

nghệ Web, nhưng điều tốt nhất vẫn nên kiểm tra lại. Với công nghệ "churn" trong ngành

công nghiệp phần mềm, không có hãng nào có thể tuyên bố là tool của họ thích hợp với

mọi công nghệ. Công ty phải tự chọn tool mà mình thấy cần thiết.


Effectivesoftwaretesting 131104102937-phpapp01

Technology

Transcript of Effectivesoftwaretesting 131104102937-phpapp01