1. 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
www.tinhvan.com
Tel.: +84-4- 5589970,
Fax: 5589971
E-mail:
info@tinhvan.com
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:
hcm@tinhvan.com

2. Effective Software Testing
11/4/2013
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

3. Effective Software Testing
11/4/2013
MỤC LỤC
DANH SÁCH TỪ VIẾT TẮT.......................................................................................................5
1.GIAI ĐOẠN ĐẶC TẢ YÊU CẦU..............................................................................................5
1.1Sự cần thiết của testers khi dự án bắt đầu...............................................................................6
1.2Kiểm tra các yêu cầu...............................................................................................................7
1.3Thiết kế test Procedures ngay khi có đặc tả yêu cầu.............................................................11
1.4Các thay đổi của yêu cầu cần được update...........................................................................13
1.5Developing and Testing dựa trên một hệ thống sẵn có.........................................................15
2.KẾ HOẠCH TEST....................................................................................................................17
2.1.Trách nhiệm và mục tiêu test ..............................................................................................18
2.2.Tính toán các rủi ro..............................................................................................................21
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............27
2.4.Lưu lại phần mềm trong trí nhớ...........................................................................................28
2.5.Bộ dữ liệu test hiệu quả.......................................................................................................29
2.6.Kế hoạch cho môi trường test..............................................................................................32
2.7.Ước lượng thời gian chuẩn bị test và thời gian thực hiện test.............................................34
3.TEST PROCEDURE VÀ THIẾT KẾ TEST..........................................................................42
3.1.Sự phân chia và thực hiện test.............................................................................................43
3.2.Sử dụng Template Test Procedure và các tiêu chuẩn thiết kế test khác..............................48
3.3.Việc chuyển hoá thành các test cases từ yêu cầu của khách hàng.......................................51
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)................................................................................................................................54
3.5.Sử dụng các Prototypes........................................................................................................55
3.7.Các kỹ thuật test được sử dụng khi thiết kế kịch bản test....................................................56
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................................59
3.9.Áp dụng Exploratory Testing (test qua toàn bộ chương trình)............................................60
4.CÔNG CỤ TEST TỰ ĐỘNG...................................................................................................62
4.1.Các loại testing tools............................................................................................................62
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 3/78

4. Effective Software Testing
11/4/2013
4.2.Xây dựng 1 tool thay cho việc mua một tool.......................................................................67
4.3.Ảnh hưởng của Automated Tools đến nỗ lực test................................................................69
4.4. Tập trung vào những gì mà công ty cho là cần thiết...........................................................73
4.5.Kiểm tra tool bằng các Prototype.........................................................................................76
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 4/78

5. Effective Software Testing
11/4/2013
DANH SÁCH TỪ VIẾT TẮT
STT
1
2
3
4
5
TỪ VIẾT TẮT
PM
PL
PQA
SQA
TL
NỘI DUNG
Project Manager
Project Leader
Process quanlity Asurance
Software quanlity Asurance
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.
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 5/78

6. Effective Software Testing
11/4/2013
Đầ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ông ty Tinh Vân – Lưu hành nội bộ
Số trang : 6/78

7. Effective Software Testing
11/4/2013
đượ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
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 7/78

8. Effective Software Testing
11/4/2013
đó 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.
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 8/78

9. Effective Software Testing
11/4/2013
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à
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 9/78

10. Effective Software Testing
11/4/2013
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.
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 10/78

11. Effective Software Testing
11/4/2013
Đố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.
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 11/78

12. Effective Software Testing
11/4/2013
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.
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 12/78

13. Effective Software Testing
11/4/2013
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ông ty Tinh Vân – Lưu hành nội bộ
Số trang : 13/78

14. Effective Software Testing
11/4/2013
đượ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
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 14/78

15. Effective Software Testing
11/4/2013
( 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.
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 15/78

16. Effective Software Testing
11/4/2013
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ũ
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 16/78

17. Effective Software Testing
11/4/2013
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ông ty Tinh Vân – Lưu hành nội bộ
Số trang : 17/78

18. Effective Software Testing
11/4/2013
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
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 18/78

19. Effective Software Testing
11/4/2013
• 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
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 19/78

20. Effective Software Testing
11/4/2013
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.
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 20/78

21. Effective Software Testing
11/4/2013
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
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 21/78

22. Effective Software Testing
11/4/2013
đã đị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).
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 22/78

23. Effective Software Testing
11/4/2013
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ụ.
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 23/78

24. Effective Software Testing
11/4/2013
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.
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 24/78

25. Effective Software Testing
11/4/2013
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.
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 25/78

26. Effective Software Testing
11/4/2013
• 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 độ
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 26/78

27. Effective Software Testing
11/4/2013
ả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.
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 27/78

28. Effective Software Testing
11/4/2013
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 ty Tinh Vân – Lưu hành nội bộ
Số trang : 28/78

29. Effective Software Testing
11/4/2013
• 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.
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 29/78

30. Effective Software Testing
11/4/2013
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.
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 30/78

31. Effective Software Testing
11/4/2013
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
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 31/78

32. Effective Software Testing
11/4/2013
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
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 32/78

33. Effective Software Testing
11/4/2013
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 clientserver)….
• 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.
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 33/78

34. Effective Software Testing
11/4/2013
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.
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 34/78

35. Effective Software Testing
11/4/2013
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 Tỷ lệ của Developers và Số lượng
Developers
Testers
Testers
Sản phầm thương mại
(thị trường lớn)
Sản phầm thương mại
(thị trường nhỏ)
Tích hợp và phát triển
cho máy client
Các phần mềm cho
Chính Phủ, Nhà nước
(trong nước)
Phần mềm cho các tổ
chức trong nước
30
3:2
20
30
3:1
10
30
4:1
7
30
5:1
6
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
Công ty Tinh Vân – Lưu hành nội bộ
Số trang : 35/78