Your SlideShare is downloading. ×
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.ti...
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
Effective Software Testing

11/4/2013

MỤC LỤC

DANH SÁCH TỪ VIẾT TẮT........................................................
Effective Software Testing

11/4/2013

4.2.Xây dựng 1 tool thay cho việc mua một tool........................................
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
Projec...
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 sa...
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á...
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ố ...
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ụ,...
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ê...
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 ...
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ệ...
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 gi...
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...
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 p...
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 ...
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ì ...
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...
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ư...
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, ...
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 p...
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ị...
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...
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...
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...
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...
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 đị...
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 ...
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ự...
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 p...
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...
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 ...
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 t...
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ể...
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...
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Effective software testing
Upcoming SlideShare
Loading in...5
×

Effective software testing

726

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
726
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
72
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Effective software testing"

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

×