Uploaded bysong_lachinhminh_smile
DOC, PDF1,585 views

Effective software testing

Tài liệu hướng dẫn kiểm tra phần mềm hiệu quả tại công ty Tinh Vân bao gồm các giai đoạn từ việc phê duyệt yêu cầu, lập kế hoạch và thực hiện kiểm tra cho tới việc sử dụng các công cụ tự động. Quan trọng là tester tham gia từ giai đoạn đầu để xác định và xử lý các yêu cầu một cách chính xác và rõ ràng, đảm bảo sản phẩm cuối cùng đáp ứng đúng yêu cầu. Tài liệu nhấn mạnh đến việc phát triển test procedures và yêu cầu phi chức năng bên cạnh yêu cầu chức năng để nâng cao chất lượng phần mềm.

Downloaded 89 times
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
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.......................................................................................................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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Effective Software Testing 11/4/2013 1 dự án, bao gồm tham gia khảo sát yêu cầu khách hàng, cấu hình hệ thống, quản lý qui trình (PQA), deverlopers và QA để tính toán số người và thời gian test. Phương pháp này có giá trị đặc biệt khi số người thực hiện công việc phát triển thường xuyên thay đổi hay rất khó để xác định số người tham gia phát triển. Trong việc tính toán số người test trong bảng 12.2, giả thiết là phạm vi nỗ lực test bao gồm cả việc nghiên cứu SRS, test cấu hình hệ thống, test quá trình xử lý liên quan, test chức năng và test hiệu năng của giai đoạn test tích hợp ve test hệ thống. Việc chọn con số 50 trong cột "Project Staffing Level" nhằm đơn giản hoá việc tính toán giá trị của cột "Test Team Size". column. Tất nhiên số lượng người tham gia dự án có thể ít hay nhiều hơn. Bảng 12.2. Số Tester được tính toán dựa vào số lượng nhân viên toàn dự án. Type of Produces Project (Loại sản phầm) Staffing Level (số nhân viên tham gia dự án) Sản phầm thương mại 50 (thị trường lớn) Sản phầm thương mại 50 (thị trường nhỏ) Tích hợp và phát triển 50 cho máy client Các phần mềm cho 50 Chính Phủ, Nhà nước (trong nước) Phần mềm cho các tổ 50 chức trong nước Test Team Size Số Testers 27 13 16 8 14 7 11 5 14 lượng 7 c. Phương pháp test procedures. Cách khác để đo lường nỗ lực test là sử dụng khối lượng chương trình test để đo lường, cụ thể hơn là dựa vào số lượng test procedures của dự án đã được lập kế hoạch để đo lường. Phương pháp này có phần bị hạn chế do phụ thuộc vào số lượng test procedures Công ty Tinh Vân – Lưu hành nội bộ Số trang : 36/78
Effective Software Testing 11/4/2013 của dự án mà không tính đến các nhân tố ảnh hưởng tới nỗ lực test. Phương pháp này là sự kết hợp với 1 phương pháp trong hàng loạt các phương pháp khác. Để áp dụng được phương pháp này, các Test Procedure của dự án cũng như quá trình thực hiện dự án đó cần được ghi lại ngay từ đầu để có dữ liệu đánh giá, như việc chỉ ra các chức năng, số lượng test procedures sử dụng và kết quả nỗ lực test được đo lường với đơn vị là “số giờ/1 tester” Trị số qui mô phát triển được tài liệu hoá dưới dạng những dòng mã lệnh (lines of code (LOC)), những dòng mã lệnh tương đương, hàm con trỏ, số lượng các đối tượng được phát triển. Nhóm test xác định các yêu cầu và mối liên hệ giữa các trị số qui mô phần mềm trước đó và số lượng các test procedures được sử dụng trong các dự án đó. Từ đó, chúng ta tính toán và ước lượng được số lượng các test procedures cho dự án mới. Tiếp đến là nhóm test xác định mối liên quan giữa số lượng các test procedures và số giờ mỗi tester cần có dựa vào kinh nghiệm từ các dự án trước. Phương pháp ước lượng này thành công nhất khi các dự án so sánh với nhau có sự tương tự về bản chất, công nghệ, yêu cầu về sự thành thạo, cách thức giải quyết vấn đề và các nhân tố khác. Bảng 12.3 trình bày ví dụ về việc xác định số giờ test áp dụng phương pháp Test Procedure (giả thiết, dự án có 1.120 test procedures). Nhóm test xem xét nỗ lực test của 2 hoặc nhiều hơn 2 dự án có trung bình 860 test procedures và cần tới 5.300 giờ cho việc test. Trong nố lực test của các dự án trước đó, số giờ test trên mỗi test procedure là 6.16 giờ là hợp lý (cho toàn bộ vòng đời của dự án). Dự án cần 5.300 giờ thường kéo dài 9 tháng, trong đó, cần 3,4 tháng thiết kế test. Công việc bây giờ là xác định số giờ test cho dự án mới có 1.120 test procedures. Bảng 12.3. Ước lượng thời gian test dựa theo phương pháp TestProcedure Công ty Tinh Vân – Lưu hành nội bộ Số trang : 37/78
Effective Software Testing 11/4/2013 Điều quan trọng phải xác định được mối liên quan giữa số lượng các test procedures và phạm vi các yêu cầu cần test. Ưu điểm của phương pháp này là xác định được yêu cầu test và phạm vi test sớm hơn so với 2 phương pháp trên. Nhưng nhược điểm của nó là thời gian ước lượng được tính trước khi hoàn thành xong đặc tả yêu cầu của khách hàng. d. Phương pháp kế hoạch công việc. Phương pháp khác ước lượng nỗ lực yêu cầu của chương trình liên quan tới việc xem xét con số lịch sử về nỗ lực test tương tự. Phương pháp này khác so với phương pháp Test Procedure ở chỗ nó tập trung vào các task của công việc test. Bảng 12.4 là 1 ví dụ về việc ước lượng nỗ lực test cho 1 dự án có 1.120 test procedures dựa vào dự án có 860 test procedures, cần 5.300 giờ cho cả dự án và 6,16 giờ test cho 1 test procedure( Ví dụ này tương tự ví dụ khi sử dụng phương pháp Test Procedure trong bảng 12.3.) Bảng 12.4. Ước lượng nỗ lực test dựa theo phương pháp kế hoạch công việc test (các task công việc test) Công ty Tinh Vân – Lưu hành nội bộ Số trang : 38/78
Effective Software Testing 11/4/2013 • Giả thiết: Nhóm test cần xem xét các con số của các dự án trước để chia số giờ thực hiện thành các task công việc hay gọi là các giai đoạn test. Tóm lại, số giờ của mỗi giai đoạn test được trình bày trong bảng 12.5. Bảng 12.5. Xác định số giờ của mỗi giai đoạn test theo phương pháp kế hoạch công việc. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 39/78
Effective Software Testing 11/4/2013 Để đưa ra được các con số này, nhóm test phải ước lượng ngay từ khi dự án mới được bắt đầu (nếu không có các con số của dự án trước thì việc ước lượng thời gian cho mỗi giai đoạn test sẽ dựa vào kinh nghiệm của người lập kế hoạch). Trong ví dụ trên, dự án mới có sử dụng công cụ test tự động và việc đưa ra bước 3 và 4 là không cần thiết. Nhóm test cũng cần thận trọng vì dự án không có ngân quỹ dành cho việc thực hiện cải tiến qui trình test, vì vậy không có bước 11 trong bảng trên. Bước tiếp theo trong bảng 12.6, tính toán, ước lượng nỗ lực nhóm test dựa vào sự điều chỉnh số giờ 6.403. Nỗ lực nhóm test được ước lượng tương đương là 3,1 testers với 1 dự án 12 tháng. Nhóm test sẽ bố trí chính xác là 3 testers làm toàn thời gian (100%) trong khoảng thời gian test đã xác định. Các testers phải tập trung test trước các phần có độ rủi ro cao. Và chiến lược test cần được điều chỉnh theo nỗ lực vừa tính toán ở trên. Nhóm test có thể bố trí nhân lực test theo các cách khác nhau, có thể bố trí toàn thời gian của 1 tester cho dự án hay phân đoạn thời gian như 80% thời gian tester 1 và 80% tester 2. Bảng 12.6. Nỗ lực Test dựa vào ước lượng thời gian của nhân viên. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 40/78
Effective Software Testing 11/4/2013 e. Các phương pháp khác. Trong các tình huống đặc biệt, căn cứ vào kinh nghiệm để xác định nỗ lực test mà không cần quan tâm tới các phương pháp. Ví dụ, khi sử dụng phương pháp tỷ lệ tester so với deverloper thì không nhấn mạnh được thời gian test trong các dự án trước đó. Do vậy, không định nghĩa được quá trình test, nên cần thiết phải điều chỉnh tỷ lệ này. Tương tự như vậy, khi áp dụng phương pháp kế hoạch công việc, nếu nhóm test có ít kinh nghiệm thì rất dễ phải điều chỉnh các task công việc, các nhân tố ảnh hưởng. Các nhân tố ảnh hưởng tới việc ước lượng nỗ lực test bao gồm: • Cách tổ chức. • Phạm vi test. Có thể test chức năng, test hiệu năng và test giao diện, test tính bảo mật, test tiện ích (phím tắt…)…. • Kỹ năng của người thực hiện test. • Thành thạo các công cụ test. Khi sử dụng công cụ test tự động sẽ rất khó khăn đối với người chưa thực hiện công cụ đó bao giờ, do vậy, họ cần được học về tool đó. Muốn sử dụng được các test tool đó cần có kịch bản test. Điều này là mới với nhóm test vì họ thiếu kinh nghiệm hay thậm chí không có kinh nghiệm trong viết code. Hay thậm chí, tester đó thành thạo với 1 test tool này nhưng với 1 tool khác thì hoàn toàn mới với họ. • Kiến thức về nghiệp vụ. Kiến thức của 1 tester về một ứng dụng nào đó chưa sâu do không phải họ hiểu tất cả các nghiệp vụ thuộc tất cả các lĩnh vực. Các kiến thức đó còn được gọi là "kiến thức đặc thù” (domain knowledge) • Tổ chức nhóm test. Chương 5 sẽ trình bày kỹ hơn về các loại tổ chức công việc test. • Phạm vi chương trình test. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 41/78
Effective Software Testing 11/4/2013 • Thời điểm bắt đầu test Kế hoạch test nên được bắt đầu ngay khi dự án bắt đầu. Điều này có nghĩa là các testers tham gia vào test dự án đó sẽ nghiên cứu, phân tích và thiết kế test cho dự án đó. Sự tham gia sớm của tester không những giúp họ hiểu hơn về yêu cầu cũng như thiết kế, cấu trúc hệ thống. Từ đó, xác định được môi trường test hiệu quả mà còn sớm phát hiện ra lỗi và ngăn chặn lỗi ngay từ giai đoạn viết đặc tả yêu cầu của phía lập trình (từ đặc tả này sẽ thiết kế chương trình, và từ thiết kế sẽ viết code). • Sử dụng các test tool. Với nhiều hãng phần mềm chuyên nghiệp, việc sử các test tool giúp giảm nỗ lực test, giảm sự phức tạp khi lập kế hoạch test cũng như việc thực hiện test. • Rủi ro của phần mềm cao. Nếu một phần mềm có độ rủi ro cao, có thể có nhiều lỗi mà xác định nỗ lực test không đủ thì dẫn đến chất lượng phần mềm đó có xác suất rủi ro cao. Cuối cùng, khi xác định nỗ lực test, cần quan tâm tới các yếu tố ảnh hưởng để tính đến các tình huống đặc biệt. Nhằm hỗ trợ cho việc lập kế hoạch test, việc theo dõi số giờ thực tế của mỗi task công việc thường được sử dụng nhất. Tuy nhiên, vấn đề đối với tất cả các phương pháp đưa ra là, rất ít khi có 2 phần mềm tương tự nhau. Một sản phẩm phần mềm phụ thuộc vào độ phức tạp, kinh nghiệm của deverloper, công nghệ và nhiều yếu tố khác nữa. 3. TEST PROCEDURE VÀ THIẾT KẾ TEST. Test Procedure và thiết kế Test là 2 công việc quan trọng của nhóm test. Như đã nói ở chương số lượng hồ sơ đem ra khai thác, hai công việc này test chỉ được bắt đầu khi phần mềm đã được code xong, nhưng nếu 2 công việc này được bắt đầu càng sớm càng tốt, và có thể thực hiện, tiến hành ngay khi tài liệu đặc tả yêu cầu được phê duyệt. Khi tài liệu đặc tả và thiết kế hệ thống được sàng lọc, chọn lựa kỹ hay được lặp lại ( sửa) tài liệu hay thiết kế lại thì các test Procedure cũng sẽ được hoàn thành tương ứng với việc hoàn chỉnh tài liệu và thiết kế các chức năng của hệ thống. Test Procedure mang lại lợi ích rõ ràng, giúp chúng ta đạt được tới đích nhanh chóng và hiệu quả. Qua tài liệu này sẽ xác định được là test black-box hay gray-box; định dạng cho tài liệu này, các kỹ thuật test được chọn là gì. Ví dụ, như sự kiểm tra test biên, Công ty Tinh Vân – Lưu hành nội bộ Số trang : 42/78
Effective Software Testing 11/4/2013 exploratory testing. Thêm vào đó, kịch bản test và các test tool sẽ giúp chúng ta đạt được đích mong muốn. Trong việc đánh giá các yêu cầu và việc thiết kế phần mềm đòi hỏi phải có hiểu biết nhiều về cấu trúc, về vấn đề chủ chốt đầu tiên cần xem xét hay các application đã có. Vì vậy, các testers phải chia và thực hiện từng giai đoạn, thao tác nhỏ trong hàng loạt các thao tác cần thực hiện nhằm đảm bảo thực hiện đúng lịch test và số tiền giành cho test. Như vậy, các câu hỏi test cái gì? test bằng cách nào? test như thế nào? test khi nào? và ai sẽ test là các câu hỏi cần được trả lời trong chiến lược test, phải chia nhỏ thành các giai đoạn nhỏ, sử dụng các kỹ thuật đặc biệt và phải có mức ưu tiên trong quá trình test song song hay test lặp. 3.1. Sự phân chia và thực hiện test. Với tài liệu đặc tả và thiết kế, các testers sẵn sàng để lập ra và phát triển các loại test Procedure. Khi phần mềm có nhiều yêu cầu, quyết định nơi bắt đầu để lập và phát triển test Procedure dường như rất khó. Phần này muốn đưa ra phương pháp giúp chia nhỏ các giai đoạn test. Trước khi thiết kế test, điều cần thiết là phải quan tâm tới các giai đoạn test cần thực hiện. Có sự khác nhau giữa các giai đoạn test như test tiện ích, test hiệu năng, test bảo mật, và các giai đoạn test khác như test chức năng và test phi chức năng. Test phi chức năng sẽ được bàn đến trong chương 9. Bước đầu tiên trong việc thiết kế test Procedure là phải xem xét lại kế hoạch test. Nếu kế hoạch đó không ổn để có thể hiểu được các tình huống hay bản chất của vấn đề thì sẽ không xác định được mục tiêu test, phạm vi test. Kế hoạch test cũng liệt kê các nguồn lực tham gia quá trình test như các tool hỗ trợ, các phương pháp test, các tiêu chuẩn test phải theo hay lịch test. Nếu kế hoạch test không hợp lý hay không được lập trước đó thì các thông tin về phạm vi test, các mục cần test ….sẽ phải lấy từ các nguồn khác. Để chia nhỏ các giai đoạn test thì phải trả lời được các câu hỏi sau: test cái gì? test khi nào? test như thế nào? ai sẽ tham gia vào quá trình test? • Những phần nào cần test? Trong giai đoạn lập kế hoạch test, phải xác định ngay phần nào cần test, phần nào không để từ đó xác định được phạm vi cần test. • Khi nào thì test? Công ty Tinh Vân – Lưu hành nội bộ Số trang : 43/78
Effective Software Testing 11/4/2013 Trong phần 3, chúng ta đã đưa ra yêu cầu phải thiết kế test Procedure càng sớm càng tốt khi có tài liệu đặc tả. Khi đã xác định được phần nào cần nào cần test, phần nào không thì chúng ta cần xác định được trình tự test. Vậy, vấn đề đặt ra là cái gì cần được test trước tiên? Tester lên kế hoạch test phải biết được phần nào được ưu tiên test trước, phần nào test cùng nhau và từ đó đưa ra lịch test cụ thể. Tiến trình test phải ưu tiên cho mục cần test trước. Trừ khi có ngoại lệ là các chức năng chắc chắn cần được chạy trước để chuẩn bị cho các chức năng khác. Như vậy, các chức năng này cần được ưu tiên test trước hay không? vấn đề này sẽ được bàn kỹ hơn trong các phần, các mục cần được ưu tiên test trước trong phần 8). Thêm vào đó, việc phân tích rủi ro nên được tính đến khi xét đến các mức độ ưu tiên này. Nếu không phải test toàn bộ chương trình, các testers chỉ cần quan tâm tới các phần cần test mà thôi. Việc phân tích rủi ro đưa ra cơ chế để xác định những phần cần test và những phần có thể bỏ qua không test. • Test Procedure nên được thiết kế như thế nào? Không có bất kỳ một giải pháp đơn lẻ nào có thể test toàn bộ hệ thống một cách hiệu quả. Test Procedure cho các phần khác nhau của một hệ thống cần được thiết kế thích hợp, đặc biệt cho các phần đặc biệt của chương trình. Để thiết kế test Procedure thích hợp và hiệu quả thì điều cần thiết là phải quan tâm đến cấu trúc hệ thống và tích hợp hệ thống. Ví dụ, để xác minh lại các chức năng của hệ thống thì có thể thông qua giao diện người dùng. Test Procedure sẽ dựa trên các yêu cầu chức năng đã có trong tài liệu, trong đó, các test cases phải thể hiện đầy đủ các trường hợp xảy ra. Các test cases sẽ được bắt đầu với các bộ dữ liệu đúng và bộ dữ liệu không đúng cho test giao diện để xác minh lại định dạng chuẩn của các trường dữ liệu đầu vào. Điều này liên quan tới một chuỗi các thao tác kiểm thử sau đó. Ví dụ, khi nhập dữ liệu cho một trường hay màn hình này lại trả ra một màn hình khác mà cũng yêu cầu nhập dữ liệu. Test Procedure phải thiết kế cho GUI testing hay back-end testing, hay cả hai còn phụ thuộc vào chiến lược test đã xác định trước đó. GUI tests khác so với back-end tests. • Những ai sẽ tham gia vào test? Khi đã xác định được phải test phần nào? và test khi nào? test như thế nào thì sẽ dễ dàng xác định được trách nhiệm của từng người sẽ test phần nào dựa trên khả năng và kinh nghiệm của các tester. (xem phần 13). should develop the tests? Ngoài ra sẽ có nhiều câu hỏi được đặt ra trong suốt quá trình lập và thiết kế test Procedure. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 44/78
Effective Software Testing 11/4/2013 • Νếu không có tài liệu đặc tả thì test Procedure sẽ được thiết kế ra sao? Nếu không có tài liệu đặc tả để viết test case thì điều cần thiết để có thể viết test cases là hỏi người đại diện, người có trách nhiệm đối với các yêu cầu đó hay nhân viên kỹ thuật hay những người review các yêu cầu của khách hàng (nhưng các yêu cầu đó không được viết thành tài liệu). Ví dụ như hướng dẫn người dùng của hệ thống hiện tại (nếu đã có) hay những tài liệu hướng dẫn người dùng, đặc tả yêu cầu của các hệ thống trước đó để hiểu tốt hơn về hệ thống đang thiết kế (xem phần 5 về những vấn đề nguy hiểm thường gặp phải khi việc test phải dựa trên các tài liệu của các application đã tồn tại. Nếu như có một hệ thống được kế thừa, thì phải có tài liệu thiết kế của nó. Tuy nhiên, những tài liệu này có thể không đúng với yêu cầu của khách hàng. Trong một số trường hợp, phải thực hiện ngược lại so với thiết kế để kiểm tra hệ thống, hay thực hiện exploratory testing (vấn đề này sẽ được thảo luận ở phần sau) • Black-box and gray-box Testing: Black-box and gray-box Testing được thực hiện trong tất cả bộ phận của dự án thông qua test giao diện, và được gọi là black-box. Ví dụ, nếu muốn thêm mới một người dùng vào database thì người dùng này sẽ được insert vào database thông qua giao diện người dùng, various layers—Ví dụ như database layer, phân lớp người dùng, business-logic layers— sẽ được thực hiện. Lỗi thường thể hiện qua giao diện người dùng. (chương 4 sẽ bàn kỹ hơn về black-box and gray-box testing. Tuy nhiên, trong một số trường hợp lỗi không được thể hiện qua giao diện người dùng bởi vì các lỗi này thuộc về cơ chế thông báo lỗi của phần mềm. Ví dụ, khi một application mà không thêm mới được một bản ghi vào cơ sở dữ liệu, nhưng không có thông báo trên giao diện người dùng thì lỗi này là do code vì không hiển thị thông báo lỗi trên màn hình. Khi có giao diện người dùng, hay black-box, việc test không thể test hết lỗi được. Do đó, graybox testing cũng phải được áp dụng nhằm tìm hết ra lỗi [1] Gray-box testing được nói đến trong phần 16. • Will a test harness have to be developed?. Một số phần của hệ thống chỉ có thể test được bằng công cụ test. Ví dụ, Một phép tính có thể cho phép kết hợp cùng một lúc hàng nghìn bộ dữ liệu đầu vào. Việc test này yêu cầu thiết kế test khác so với test giao diện hay black-box testing: Với số lượng đầu vào được kết hợp cùng với sự thay đổi của dữ liệu đầu vào quá lớn và không thể test bằng cách nhập nhập liệu qua giao diện người dùng. Thời gian và các vấn đề cần quan tâm, xem xét Công ty Tinh Vân – Lưu hành nội bộ Số trang : 45/78
Effective Software Testing 11/4/2013 khác yêu cầu test phải sử dụng test tool để tính toán với bộ dữ liệu đầu vào lớn đó thì đầu ra của chúng là gì? Vấn đề này sẽ được nói kỹ hơn tại phần 37. • Các kiểu kỹ thuật test được sử dụng là những kiểu nào? Các kiểu kỹ thuật test function rất đa dạng và được sử dụng để test data và bộ dữ liệu đầu vào. Một kiểu kỹ thuật test có thể kiểm tra một số lượng lớn sự kết hợp các bộ dữ liệu là orthogonal array testing. Orthogonal array testing cho phép tập hợp tất cả sự kết hợp các tham số để chứng tỏ chỉ cần số lượng test case nhỏ nhất nhưng bao phủ được hết các trường hợp xảy ra.[2] Các kiểu kỹ thuật test khác giúp thu hẹp được các trường hợp xảy ra trong cùng một phân lớp tương đương bằng việc phân tích giá trị biên (xem phần 25). Sự kết hợp các kỹ thuật này cho phép giảm số lượng test case nhưng vẫn đảm bảo thống kê đầy đủ các trường hợp xảy ra khi thiết lập các bộ dữ liệu đầu vào. Kỹ thuật test khác xảy ra khi phải có sự tham ra của commercial off-the-shelf (COTS) tool. Sự pặp lại của COTS tool với giá trị tuỳ thích được code sẽ được kiểm thử. Ví dụ, nếu một COTS tool được yêu cầu để thực hiện một lệnh SQL, khi test sẽ phải chạy các kịch bản để chứng tỏ nội dung của lệnh SQL được sửa là đúng. • Should a capture/playback tool or other testing tool be used? Một capure/playback hay 1 công cụ test khác nên được sử dụng như thế nào? Khi một test tool được khai thác, sử dụng để test việc tính toán liên quan tơí yếu tố kỹ thuật hay các back-end functions khác, thì công cụ test tự động (capture/playback) sẽ là hữu ích cho GUI regression testing. Khi xác định chiến lược test yêu cầu phải xác định các phần của application được test bằng công cụ test tự động. Các phần khác không cần test bằng automated testing thì không nhất thiết áp dụng nó, nguyên nhân của vấn đề sẽ được thảo luận trong phần 36. • Which tests should be automated? Việc test tự động được thực hiện như thế nào? Người thiết kế test nên phân tích kỹ, cần thận application khi đưa ra quyết định áp dụng công cụ test tự động hay test bằng tay. Điều này giúp tránh xa, loại bỏ những chi phí không cần thiết. Vì nói chung test bằng công cụ test tự động thì chi phí thường cao hơn so với test tay. Sau đây là một số ví dụ áp dụng test tự động: o Việc test phải được thực hiện nhiều hơn một lần: Công ty Tinh Vân – Lưu hành nội bộ Số trang : 46/78
Effective Software Testing 11/4/2013 Ngược lại, việc test chỉ được thực hiện một lần duy nhất thì việc sử dụng công cụ test tự động là rất lãng phí. o Việc test nhằm đánh giá các điều kiện rủi ro cao. Các nhân tố rủi ro ít thì không nhất thiết phải áp dụng công cụ test tự động. Chúng ta quan tâm tới test function nơi người dùng thực hiện các kịch bản test đặc biệt. Ví dụ, khi test, hệ thống cho phép người dùng thực hiện các hành động này (do yêu cầu của bên kinh doanh) nhưng việc test chúng không thể quan sát hết, rõ ràng bằng trực quan. Rủi ro liên quan tới các kịch bản của loại test này là thấp nếu số lượng người dùng là ít. Và khi một hành động nào đó không đơn thuần quan sát được bằng trực quan khi thiết kế test thì các rủi ro xảy ra là rất cao. o Tests thực hiện trên nền tảng, cơ sở thông thường (Test that are run on a regular basis). Ví dụ, bao gồm smoke (build verification) tests, regression tests, and mundane tests (tests đơn giản, test lặp và lặp nhiều lần). o Công việc test đó không thể thực hiện test tay. Ví dụ, Test tự động được thực hiện khi cần kết quả đầu ra của việc có 1000 người tiếp cận hệ thống trong một thời điểm. o Test với nhiều bộ dữ liệu cho cùng một hành động (data-driven tests). o Baseline tests(danh giới test) được thực hiện trên các cấu hình khác nhau. o Test với kết quả có thể đoán trước. Khi này, áp dụng công cụ test tự động sẽ mang lại chi phí hiệu quả. o Test xem sự ổn định của hệ thống đạt đến mức nào. Với functionality, implementation, và công nghệ không thay đổi thường xuyên. Mặt khác, sự bảo dưỡng của các công cụ test tự động sẽ mang lại các lợi ích nhiều hơn. • What kind of test data is needed?Các kiểu test data cần thiết là gì. Trước đây, công việc test chưa được phân chia một cách rõ rệt, chưa thể hiện vai trò quan trọng thì việc test data được thực hiện bắng cách nhập các bộ dữ liệu đầu vào. Điều quan trọng là test data được chọn lựa rất cẩn thận, nếu test data với bộ dữ liệu đầu vào không đúng hay quá đơn giản có thể dẫn đến xót các trường hợp hay lỗi sẽ xảy ra do việc test chứ không phải do chương trình. Như vậy, test data yêu cầu phải đầy đủ các trường hợp xảy ra ( test data sẽ được nói kỹ hơn trong phần 10). Công ty Tinh Vân – Lưu hành nội bộ Số trang : 47/78
Effective Software Testing 11/4/2013 Việc trả lời các câu hỏi được liệt kê trong phần này sẽ giúp cho người lập kế hoạch chia nhỏ được các công việc test, quan trọng là phải quan tâm tới lịch test và chi phí giành cho test là bao nhiêu. 3.2. Sử dụng Template Test Procedure và các tiêu chuẩn thiết kế test khác. Tính lặp lại, độ chắc chắn, sự hoàn thành, template các test Procedure chuẩn nên được qui định thích hợp. Sau đây là một số ví dụ về các template test Procedure: Test Procedure Template Công ty Tinh Vân – Lưu hành nội bộ Số trang : 48/78
Effective Software Testing 11/4/2013 Phương pháp kiểm thử: Hình 21.1. Template file test case: Yếu tố đầu tiên của một file test case chuẩn được thể hiện qua hình 21.1, bao gồm: Công ty Tinh Vân – Lưu hành nội bộ Số trang : 49/78
Effective Software Testing 11/4/2013 • Mã test case: Thoả thuận cách đặt ID cho test Procedure. • Tên test case: Thể hiện sự mô tả của các test case trong phần đó.. • Ngày lập file test case: Ngày bắt đầu tạo các test case. • Tên người thiết kê lên form của file test case: Họ tên của người thiết kế file test case • Người tạo các test case: Họ tên người tạo ra các test case • Mục đích test: Phác thảo mục đích test của test case đó. • Mối liên quan giữa các use case, số lượng các yêu cầu: Thể hiện đầy đủ số lượng các yêu cầu được xác nhận trong test Procedure. • Sự dự đoán, giả thiết và sự ràng buộc: Đưa ra các tiêu chuẩn hay các điều kiện tiên quyết cần có trước khi viết các test case, ví dụ như các dữ liệu đặc biệt cho các yêu cầu đặt ra là gì. Điều này sẽ được hoàn thành khi test case đó phụ thuộc vào các test case trước đó. Điều này cũng có thể được hoàn thành khi 2 test case này có xung đột nhau nếu như chúng cùng được thực hiện trong cùng một khoảng thời gian. Cần chú ý rằng điều kiện tiên quyết của các use case thường là điều kiện tiên quyết của các test case. • Phương pháp kiểm thử: Mục này này có thể bao gồm các kiểu test đã được kiểm chứng, các công cụ test tự động và test tay, sự kiểm thử, việc thực hiện và phân tích. • User Action (Inputs): Đây là kết quả mong đợi của thao tác và kết quả mong đợi này phải rõ ràng và cơ sở. Kết quả mong đợi là kết quả sau khi thực hiện các thao tác, các bước được mô tả. Đầu vào của kết quả mong đợi có thể là như nhau đối với các phần mềm khác nhau. Việc chỉ rõ trường này làm cho tài liệu rõ ràng, dễ hiểu, dễ kiểm tra. Các bứơc mô tả phải tuân theo các use case. • Kết quả mong đợi: Xác định kết quả mong đợi khi thực hiện lần lượt các thao tác được mô tả trước đó. • Thông tin theo dõi Log: Document the behavior of back-end components. Trong suốt quá trình thực hiện các thao tác, các bước trong hệ thống, sẽ được Log lại chi tiết các chức năng mà chúng được thực hiện. Quá trình ghi Log cũng được diễn tả trong file test case. • Kết quả thực tế: Trường kết quả thực tế có thể có các giá trị mặc định để mô tả kết quả thực tế nếu như test case này bị thất bại không đúng với kết quả mong đợi hay thành công. • Yêu cầu test data: Sự tham chiếu của việc thiết lập test data sẽ tạo nên các test case trong file test case. Chúng ta sẽ nghiên cứu phần 26 để biết thêm chi tiết. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 50/78
Effective Software Testing 11/4/2013 Khi xác định nỗ lực test, test các yêu cầu phi chức năng thường được thực hiện sau. Tuy nhiên, điều quan trọng là phải quan tâm tới test phi chức năng ngay từ khi bắt đầu dự án. Chú ý, trong phần 21.1, file test case được chia thành 5 phần, một phần giành cho test chức năng, và 4 phần còn lại giành cho test phi chức năng, bao gồm, test tính bảo mật_an toàn hệ thống, test hiệu năng, sự tương thích, tiện ích. Xem phần 41 để biết nhiều hơn về việc cần thiết của test phi chức năng. Các tiêu chuẩn của một tài liệu thiết kế test phải được thể hiện bằng tài liệu, trao đổi và buộc phải tuân theo để mọi người liên quan có được những nguyên tắc thiết kế và các thông tin về yêu cầu của khách hàng.[2]. Việc tạo ra mẫu file test case và các nguyên tắc là điều cần thiết cho việc test tay và test tự động. Các tiêu chuẩn cho file test case bao gồm các ví dụ càng chi tiết càng tốt. Mức độ chi tiết nên đơn giản khi thực hiện mô tả các thao tác. Ví dụ, Bước 1. Click chọn File menu. Bước 2. Chọn nút Open. Bước 3. Chọn một thư mục trên máy tính Phụ thuộc vào qui mô của application được test và thời gian và số tiền giành cho việc test mà qui định thời gian cho viết test case nhiều hay ít, và viết kỹ hay không kỹ các trường hợp. Một file test case chuẩn bao gồm các nguyên tắc trong việc mô tả kết quả mong đợi. Các tiêu chuẩn nên chú tâm vào nhiều câu hỏi: kết quả mong đợi sẽ được thể hiện ra màn hình như thế nào? Yêu cầu test sẽ bị loại bỏ bởi người thứ 2 thực hiện test? Khi đạt đến việc test tự động theo cái chuẩn thì các chuẩn mực đó phải dựa trên kỹ thuật Code tốt nhất như sự kết nối rõ ràng, các biến chuẩn,…Việc Code ảnh hưởng lớn đến chất lượng của phần mềm. Trong một số trường hợp, không phải kịch bản test được mô tả rõ ràng, chi tiết trong SRS hay URD. Test case của các ứng dụng khó, phức tạp như hệ thống về tài chính; đối với hệ thống phần mềm cung cấp cho lĩnh vực tài chính, đầu vào là hàng vạn các phép tính và kết quả đầu ra là khác nhau. 3.3. Việc chuyển hoá thành các test cases từ yêu cầu của khách hàng. Mục đích chính của Test chức năng đảm bảo chương trình có và thực hiện đầy dủ các chức năng theo yêu cầu của khách hàng. Test chương trình theo các kịch bản hay nói cách khác theo các case và được mô tả trong test Procedure case giúp cho việc test hiệu quả hơn. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 51/78
Effective Software Testing 11/4/2013 Để đảm bảo mục đích của test chức năng thì tester phải bám sát vào tài liệu đặc tả yêu cầu khách hàng. Thêm vào đó, phải có các test case để test hiệu năng, test tính bảo mật, và test tiện ích. Trong chương 1 đã thảo luận về một SRS chi tiết, hoàn thành và có thể thực hiện test. Tuy nhiên, trong quá trình thực hiện viết SRS thì không phải trường hợp nào cũng thực hiện tốt. Để tạo ra các kịch bản test chức năng chuẩn, các tester phải hiểu chi tiết và tính phức tạp của hệ thống. Muốn vậy, tester phải phân tích được hệ thống. Thậm chí họ phải đưa ra được luồng test để người khác nhìn vào luồng đó sẽ biết tester sẽ test như thế nào, đúng hay sai. Do đó, tester phải khảo sát hệ thống để hiểu đầy đủ về hệ thống. Nói chung, các tester phải phân tích làm cách nào để hiểu được sự chuyển đổi các phần của hệ thống, như thay đổi biến và trường thì sẽ ảnh hưởng, thay đổi đến các phần còn lại. Không nên coi nhẹ việc thay đổi yêu cầu. Ví dụ, hệ thống có tính linh động và cho phép thay đổi yêu cầu, khi này hệ thống sẽ sử dụng tập con của sự kết hợp và dao động dữ liệu đầu vào; và sự thay đổi này vẫn cho phép lưu lại một cách chính xác. Khi này, kết quả test trước đó vẫn không bị ảnh hưởng vào nó vẫn bao gồm tất cả các trường hợp xảy ra. Ví dụ, Xem xét yêu cầu sau: “ Hệ thống phải cho phép người dùng sửa tên tuỳ thích và được thể hiện trên bản ghi với trường tương ứng”. Trường tên và sự giới hạn của trường tên cũng phải được thể hiện cụ thể trong SRS. Một số bước test đảm bảo cho yêu cầu này bao gồm: 1. Kiểm tra hệ thống xem nó có cho phép người dùng sửa tên tuỳ thích trên giao diện người dùng bằng cách click vào bản ghi có trường tên đó và sửa hay không. 2. Cố gắng kết hợp kiểm tra cả trường hợp đúng và sai, tất cả các phân lớp tương đương, các giá trị biên. 3. Chạy lệnh SQL để kiểm tra việc update là đúng và được update vào 1 bảng thích hợp. Ở trên bao gồm các bước kiểm thử cơ bản. Tuy nhiên, trong một số trường hợp vẫn còn bỏ sót các tình huống của yêu cầu đưa ra. Ngoài việc test hiệu năng và test phi chức năng khác thì câu hỏi cần phải trả lời là " làm thế nào để biết được có sự thay đổi trong hệ thống khi một trường nào đó bị thay đổi?”, “giao diện người dùng, các chức năng hay các mục khác sẽ bị ảnh hưởng, còn các phần nào không bị ảnh hưởng?”. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 52/78
Effective Software Testing 11/4/2013 Ví dụ: • Kiểm tra chức năng tạo mới 1 đơn đặt hàng trong module đặt hàng là việc kiểm tra xem đơn đặt hàng đó có được insert vào CSDL và được thể hiện trên giao diện hay không. • Thêm một bản ghi và kiểm tra xem bản ghi đó có được lưu lại với tên đúng như khi thêm mới hay không. • Thực hiện test chức năng thêm mới và các chức năng khác có liên quan tới chức năng thêm mới đó để thấy sự ảnh hưởng của việc thêm mới đó. Tester phải phân tích và test hết các phần liên quan, bị ảnh hưởng. Khi yêu cầu không được cụ thể hoá chi tiết trong SRS, để test hiệu quả trong trường hợp này rất khó, do đó, dễ bị bỏ xót. Thực tế, hầu hết các yêu cầu không được viết thành tài liệu một cách đầy đủ, rõ ràng để có thể thấy ngay mối liên hệ giữa các yêu cầu và các chức năng. Do vậy, thường thì một test Procedure hiệu quả không được viết lên từ riêng SRS. Tài liệu thiết kế test hiệu quả không được chồng chéo lên nhau, thay vì đưa ra một quyết định phải test hiệu quả toàn bộ với nỗ lực cần là gấp đôi ( mặc dù nỗ lực thời gian gấp đôi nhưng vẫn không tránh khỏi sự thiếu sót khi test). Sẽ không hiệu quả nếu để 2 tester test cùng một chức năng nhưng trên 2 file test case khác nhau của 2 người, trừ khi điều đó là cần thiết cho việc test toàn bộ các chức năng ( Ví dụ, khi có 2 phần cùng sử dụng các bước tương tự nhau) Vấn đề quan trọng khi phân tích luồng test nhằm đảm bảo trong suốt quá trình test, việc test được diễn ra đúng theo luồng, và chương trình xử lý có đúng hay không mà không cần nỗ lực gấp đôi, tester không cần test dữ liệu không hợp lệ với kết quả mong đợi khác, vì khi này chỉ lãng phí thời gian. Nếu test theo luồng thì lập trình cũng tốn ít thời gian để sửa lỗi hơn, và tập trung vào những lỗi quan trọng. Nhóm test nên review kế hoạch test và tài liệu thiết kế test để: • Xác định các kiểu actions hay các events tương tự thường xảy ra. Việc xác định này giúp cho việc viết test Procedure được tốt hơn, do vậy, có thể tái sử dụng và kết hợp lại các actions hay events đối với các chức năng, tránh được việc tăng nỗ lực gấp đôi. • Xác định thứ tự hay sơ đồ test. Các vấn đề cần test trước thì phải được ưu tiên thực hiện test trước, như việc xác định cấu hình database, hay các yêu cầu mà kết quả mong đợi cần được kiểm soát, hay các work flow. • Tạo ra các mối liên hệ được kết hợp chặt chẽ theo luồng, các phần test cần ưu tiên test trước trong test Procedure. Sơ đồ mối liên hệ này đưa ra sự ảnh hưởng lẫn nhau của các chức năng, sơ đồ luồng test được tạo ra từ quá trình thiết kế test và làm tăng hiệu quả test. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 53/78
Effective Software Testing 11/4/2013 Việc phân tích ở trên giúp nhóm test xác định trình tự test thích hợp trong tài liệu thiết kế và phát triển test. Các vấn đề khác cần quan tâm khác để tạo ra test Procedure hiệu quả là phải xác định và review các yêu cầu có độ rủi ro cao để có sự ưu tiên test và test kỹ hơn, chức năng quan trọng nhất sẽ ưu tiên test sớm hơn. Như vậy, sẽ là lãng phí thời gian đầu tư tạo ra test Procedure các chức năng rất hiếm khi người dùng sử dụng, trong khi các chức năng quan trọng lại chưa được test và test kỹ dẫn đến rủi ro cao. Cần phải xác định ưu tiên test đối với các chức năng có xác suất rủi ro cao và việc sử dụng là nhiều nhất. Phần 8 sẽ cho chúng ta biết chi tiết hơn) Để có test case hiệu quả, phải hiểu hệ thống, luồng test và các kịch bản. Vấn đề khó khăn thường xảy ra là nếu chỉ thông qua 1 tài liệu SRS thì rất khó có thể hiểu hết được sự kết nối, luồng và mối tương quan giữa các đối tượng. Suy nghĩ theo logic và quan tâm đến chi tiết các yêu cầu để hiểu được tính phức tạp của hệ thống. Test Procedure và thiết kế test sẽ bị thiếu các trường hợp nếu thiết kế test không được chi tiết trong khi test hộp đen. 3.4. SRS là tài liệu không thể không có (như tài liệu sống còn) của quá trình test (“Living" Documents) Thường thì người thiết kế test Procedure chỉ thực hiện test các case 1 hoặc 2 lần rồi thôi, do sự thay đổi yêu cầu, thiết kế, hay việc thực hiện test chỉ diễn ra 2 lần. Do áp lực công việc, các testers thường không xem lại test Procedure của họ. Các testers dựa vào trực giác và kỹ năng phân tích để viết các test case, bao quát toàn bộ các trường hợp, các chức năng quan trọng của hệ thống. Vấn đề là, nếu tài liệu SRS không còn thích hợp, nó trở nên quá lỗi thời thì công việc trước đó tạo ra các tài liệu này trở nên lãng phí. Vì vậy, vẫn đề quan trọng là phải coi SRS như tài liệu sống còn của việc test và nó tài liệu động chứ không phải không có sự thay đổi. Hầu hết các dự án phần mềm được phát triển theo kiểu lặp lại và phát triển, và tài liệu để test thường tương tự theo 1 cách. Trong vòng đời của 1 dự án phát triển, đa số là được xây dựng dựa trên 1 kế hoạch riêng. Và điều đó rất khó để người viết test Procedure giữ và thừa kế lại các test Procedure trước đó. Khi phần xây dựng đầu tiên được hoàn thành và giao lại cho phía test, thì tài liệu này phải dùng để tạo test case được. Chúng ta sẽ không thể hoàn thành việc test toàn bộ hệ thống nếu nhóm phát triển vẫn đang trong giai đoạn code hay mới chỉ code xong một số phân hệ của hệ thống đó. Trong Công ty Tinh Vân – Lưu hành nội bộ Số trang : 54/78
Effective Software Testing 11/4/2013 trường hợp này, nhóm test chỉ viết test Procedure cho các phần đã được code xong dựa vào kế hoạch đã được xây dựng trước đó, và test Procedure này không phải là tất cả các yêu cầu, thiết kế chi tiết, và tất cả kịch bản test của dự án đó. Rất ít test Procedure liệt kê được tất cả các các chức năng hay kịch bản của 1 hệ thống. Do đó, test Procedure phải được phát triển theo từng giai đoạn của phía phát triển. Và theo từng giai đoạn phát triển từ phía lập trình, test Procedure cũng dần dần được hoàn thiện. Ngoài ra, chúng còn được hoàn thiện ngay trong quá trình thực hiện test. Test Procedure cần được thảo luận hay sửa để cập nhật các thông tin mới. Ví dụ, khi yêu cầu thay đổi, tester phải test theo sự thay đổi, do đó, họ cần điều chỉnh test Procedure. Các chức năng có thể bị thay đổi hay nâng cấp trong suốt vòng đời phát triển hệ thống. Điều này ảnh hưởng tới test Procedure, và vì vậy, cần phải thiết kế lại theo chức năng mới được thay đổi đó. Khi một lỗi được phát hiện thì nó cần được phản ánh vào test Procedure. Với 1 số chức năng, việc phát hiện 1 lỗi đôi khi làm ảnh hưởng tới cả hệ thống vì luồng test sẽ không thực hiện được. Test Procedure phải phản ánh được luồng nghiệp vụ để phát hiện các lỗi trên. Khi các testers có đủ thời gian hiểu rõ hệ thống, họ sẽ test được hết các yêu cầu đặt ra. Tuy nhiên, vấn đề là công việc test sẽ chấm dứt khi nào? Để trả lời được câu hỏi đó, thì khi một kịch bản test được viết lên cần có sự đánh giá, review và có mức độ ưu tiên. Test Procedure nên được lưu lại thành các version để kiểm soát sự thay đổi của nó. 3.5. Sử dụng các Prototypes. Tài liệu Prototypes có rất nhiều mục đích. Chúng cho người dùng biết kết quả mong đợi khi thực hiện một chức năng. Chúng cho phép người dùng quay trở lại xem xét những gì được phía phát triển thiết kế. Prototypes giúp phát hiện ra sự mâu thuẫn trong các yêu cầu. Đôi khi sự mâu thuẫn này không được giải quyết nếu chúng xuất hiện ở các phần của các trang khác nhau, hoặc khi có nhiều hơn 1 lập trình tham gia code. Mặc dù yêu cầu rất khắt khe và việc kiểm tra sẽ làm giảm thiểu sự đối lập, mâu thuẫn nhưng việc thực hiện chúng cũng có giới hạn. Việc tạo ra các prototypes và thiết kế chúng giúp phát hiện ra các điều trái ngược, mâu thuẫn và thiếu xót, và đưa ra các công cụ hiệu quả giúp lập trình phát hiện ra những chỗ thiếu xót. Khi có Prototypes kiểm tra với các chức năng phức tạp cho phép đạt được cơ chế test ( ví dụ, tài liệu khai thác test…) và lọc những trường hợp tốt nhất. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 55/78
Effective Software Testing 11/4/2013 Với 1 prototype ra đời, nó xác định các lớp và tiếp cận dần đến tài liệu khai thác test. Prototypes giúp lọc ra những test Procedure hiệu quả ngay cả với các yêu cầu thêm vào hay thay đổi, chúng sẽ được hoàn thiện đầy đủ và chi tiết hơn. Prototypes cung cấp thêm các thông tin cho phép hoàn thiện và cải tiến test Procedure. Prototypes cung cấp chi tiết thông tin về các yêu cầu tĩnh mà tài liệu đặc tả yêu cầu khách hàng không có. Prototypes cũng giúp testers xác định các phần sử dụng công cụ test tự động. Đôi khi 1 prototype còn có thể xác định, phát hiện ra sự thiếu xót của công cụ test tự động. 3.6. 3.7. Các kỹ thuật test được sử dụng khi thiết kế kịch bản test. Như trên đã thảo luận các vấn đề quan trọng của kế hoạch test. Trong suốt giai đoạn thiết kế test Procedure, kế hoạch test ngày càng được thể hiện rõ ràng. Việt test sẽ không giải quyết hết mọi tình huống nếu thiếu kỹ thuật test. Kỹ thuật test giúp giảm số lượng test case nhưng vẫn đảm bảo hiệu quả, giảm nỗ lực test tới mức tối thiểu. Để sử dụng và áp dụng hiệu quả kỹ thuật test thì phải hiểu rõ về nó như thế nào. Có 2 loại kỹ thuật test là kỹ thuật test white-box và black-box . Sử dụng kỹ thuật test đã được chứng minh, đã từng sử dụng hiệu quả hơn là tập trung vào 1 kỹ thuật test duy nhất. Khi hệ thống yêu cầu xác định đầy đủ các test case thì chỉ một nửa chúng cần có nỗ lực thích hợp. Khi tester test theo cảm tính thì chất lượng test sẽ không tốt, khi này chưa chắc họ đã bao quát hết các tình huống của chương trình. Trong số các kỹ thuật test nhằm giảm số lượng test case test các chức năng thì kỹ thuật phân lớp tương đương, kỹ thuật biên và giao giữa các ma trận được sử dụng phổ biến. Sau đây là một vài điều đáng quan tâm về các kỹ thuật này: • Phân tích các chức năng được thảo luận chi tiết trong phần 22. Sự phân tích này liên quan tới kết quả mong đợi của chức năng đó. Và từ đó nó sinh ra test Procedure cho các chức năng đó hay các phần đặc trưng khác của hệ thống. Nếu yêu cầu đưa ra cần có chức năng x; sau đó, việc viết test case nhằm kiểm thử chức năng đó theo 1 cách thích hợp. Mà cách này được hướng dẫn trong phần 22. Sau khi xác định các chức năng cần test và các kỹ thuật test thì sẽ giảm được việc nhập nhiều dữ liệu đầu vào cho các chức năng đó. • Phân lớp tương đương xác định các miền giá trị đầu vào theo điều kiện ban đầu và kết quả mong đợi của chúng là gì. Kỹ thuật phân lớp tương đương liên quan chặt chẽ tới các Công ty Tinh Vân – Lưu hành nội bộ Số trang : 56/78
Effective Software Testing 11/4/2013 tình huống phổ biến và mẫu thuẫn nhau. Nếu các trường hợp là tương đương nhau, hay về bản chất là tương tự nhau thì chỉ được test 1 trường hợp, không cần test tất cả. Mặc dù sự phân lớp tương đương được thực hiện bằng trực quan tốt thì điều cần thiết vẫn phải chú ý tới các giả định để phân lớp. Xem xét các ví dụ sau để thấy được sự phân lớp tương đương đối với trường hợp biên: Trường password cho phép nhập 8 số, nếu nhập nhiều hơn là sai. Khi giá trị nhập vào nằm trong khoảng đã cho thì chúng gọi là một phân lớp tương đương. Trong trường hợp này chỉ có 2 phân lớp tương đương mà thôi. Một phân lớp nằm trong đoạn [1,8], và một phân lớp nữa nằm ngoài đoạn đó. • Phân tích hướng đi, đường dẫn được sử dụng trong việc test bản chất đường dẫn bên trong, cấu trúc bên trong và kết nối với kết quả của chúng. Nó có thể được áp dụng theo 2 mức độ. Một là dựa vào code và hai là trong giai đoạn test whitebox (unit test). Unit test nhằm sửa code của chương trình (chương 6 sẽ đi chi tiết về unit testing). Phân tích đường dẫn cũng có thể được áp dụng ở mức độ thứ 2: mức độ thuộc về chức năng hay test black-box. Mã nguồn đóng và test black – box được thực hiện ở giai đoạn system test hay user-acceptance. Thậm chí mã nguồn mở, thì test black-box vẫn được test theo yêu cầu của khách hàng. • Phân tích giá trị biên (BV) có thể hoàn thành việc phân tích đường dẫn. Test giá trị biên sử dụng phần lớn dữ liệu đầu vào là invalid. Do đó, còn gọi là test phủ định (negative testing). Điều kiện giá trị biên xác định phần lớn hiệu quả của các test case giá trị biên khi có nhiều lỗi xảy ra trong phần giá trị biên. Giá trị biên xác định 3 kiểu hay 3 lớp dữ liệu là kiểu dữ liệu trong khoảng, ngoài khoảng và giá trị biên (hay còn gọi là in-bounds, out-of-bounds, and on-bounds). Ví dụ kiểm tra 1 application, trong đó có đầu vào phải đảm bảo giá trị hơn 10 trường hợp xảy ra. o Kiểm tra 1 giá trị nằm trong khoảng giá trị là 13 (lớn hơn 10) o Kiểm tra 1 giá trị nằm ngoài khoảng giá trị là 5 (nhỏ hơn 10) o Kiểm tra giá trị Thêm giá trị trong và ngoài khoảng giá trị biên, như điểm cuối của đoạn/khoảng. Test giá trị biên sử dụng giá trị lớn nhất và nhỏ nhất, giá trị lớn hơn giá trị lớn nhất hay nhỏ hơn giá trị nhỏ nhất của đoạn, hay giá trị 0 hoặc không có giá trị nào. Ví dụ, Khi xác định giá trị đầu vào dạng số, cần quan tâm tới các câu hỏi sau: o Trường đó chỉ nhận giá trị số hay nhận cả giá trị là anphabel? Công ty Tinh Vân – Lưu hành nội bộ Số trang : 57/78
Effective Software Testing 11/4/2013 o Điều gì sẽ xảy ra nếu nhập giá trị anphabel? hệ thống có cho phép nhập không? Nếu không thì có thông báo lỗi không? o WĐiều gì sẽ xảy ra nếu giá trị nhập vào là các ký tự mà các ký tự này thuộc riêng về ứng dụng đó hay do công nghệ. Ví dụ, khi nhập các ký tự đặc biệt như dấu “&” trong ứng dụng Web (Web applications)? Khi này hệ thống có bị phá vỡ không? Hệ thống nên mặc định không cho người dùng nhập các giá trị nằm ngoài khoảng biên hoặc thay vào đó là hiển thị thông báo lỗi khi họ nhập các giá trị nằm ngoài giá trị cho phép. • Ma trận trực giao cho phép test với mức bao phủ lớn nhất, các trường hợp có thể xảy ra đều được test. Ma trận trực giao rất hữu dụng khi khối lượng dữ liệu đầu vào lớn hoặc sự kết hợp dữ liệu lớn và không thể tạo ra tất cả các test case cho mỗi trường hợp kết hợp. Để hiểu rõ về nội dung của ma trận trực giao, chúng ta nên tìm hiểu ví dụ cụ thể sau: Giả thiết có 3 tham số A, B và C. Mỗi tham số có thể nhận 3 giá trị là 1, 2 và 3. Việc test tất cả sự kết hợp của 3 tham số trên yêu cầu phải có 27 test case. Nhưng 27 test case đó có thực sự cần thiết không? Điều này là không cần thiết nếu tester nghi ngờ có lỗi xảy ra thì sẽ thiết đặt giá trị đặc biệt cho 3 tham số trên ( ví dụ, có lỗi xảy ra cho case sau: A=1, B=1, và C=1). Tuy nhiên, lỗi còn phụ thuộc vào giá trị 2 trong 3 tham số. Trong trường hợp này, lỗi có thể xảy ra ở 1 trong 3 test case (A=1, B=1, and C=1); (A=1, B=1, and C=2); và (A=1, B=1, and C=3). Trong các test case trên, nếu chỉ có giá trị của C là thay đổi thì chỉ cần 1 test case là đủ. Với giả thiết trên thì ma trận trực giao sẽ cần 9 test cases sau: Ma trận trên gọi là ma trận trực giao vì cứ 2 tham số ( A và B), (B và C) hay ( A và C) đều được kiểm tra 1 lần. Mỗi 1 test case kết hợp cảu 2 tham số trên có thể được gọi là ma Công ty Tinh Vân – Lưu hành nội bộ Số trang : 58/78
Effective Software Testing 11/4/2013 trận trực giao cảu 2 tham số, chứ không phải của 3 tham số vì không phải tất cả 3 tham số đều xảy ra sự kết hợp. Ví dụ, sự kết hợp (A=1, B=2, and C=3) sẽ không xuất hiện. Vậy, điều quan trọng ở đây là cách nào để bao phủ hết tất cả các trường hợp có thể? Người thiết kế phải chọn bộ dữ liệu mẫu nằm trong khỏang giá trị chấp nhận. Đôi khi điều này rất khó khi mối tương quan giữa các tham số là rất lớn, nhiều. Trong những trường hợp này, tester có thể thêm các mẫu ngẫu nhiên có thể. Nói chung là không thể, không khả thi và không mang lại hiệu quả khi test một hệ thống sử dụng tất cả các phép hoán vị là sự kết hợp của các tham số. Do đó, điều quan trọng là sử dụng cách phân tích giá trị biên với các kỹ thuật test khác như phân lớp tương đương và ma trận trực giao để đưa ra tất cả các trường hợp test có thể và đầy đủ, chính xác. 3.8. Tránh sự ràng buộc và chi tiết các yếu tố dữ liệu trong các test cases. Phần trên thảo luận về sự quan trọng của các template cho test Procedure để xác định và cụ thể hoá các bước trong tài liệu này. Template nên viết theo cách chung nhất để có thể sử dụng cho nhiều dự án (tái sử dụng). Test case không nên có các dữ kiện đặc biệt vì điều này dẫn đến sự không cần thiết ở 1 dự án khác. Mối kịch bản, tất cả các bước thao tác phải được lặp lại, chỉ thay đổi duy nhất là bộ dự liệu đầu vào và kết quả mong đợi. Ví dụ về sự không cần thiết trong template test Procedure như sau: xem xét URL liên quan tới các test case trong test Procedure ra sao? Nếu URL thay đổi thì nó phải được sửa trong tất cả các test cases, và điều này rất mất thời gian và xảy ra lỗi. Để test Procedure có thể sử dụng lại một cách dễ dàng, các dữ liệu đầu vào đặc biệt và kết quả mong đợi liên quan nên cho vào tài liệu riêng biệt. Các kịch bản test dữ liệu đặc biệt nên cho ra các sheet tách rời hay các file riêng nên phải viết các test case riêng. Các kịch bản test này có thể attach theo test Procedure với các dữ liệu đưa ra cụ thể. Khi xuất phát từ dữ liệu cụ thể, dữ liệu này phải được lấy từ kho dữ liệu mà nó được tham chiếu đến và mang tính ràng buộc. Điều này đảm bảo test Procedure được tái sử dụng và tránh được những khó khăn gặp phải vớicác kịch bản đặc biệt. Mục 3.7.1 đưa ra các ví dụ đơn giản về sự tách rời các kịch bản test trong việc kiểm tra các ID và password của người dùng khi test chức năng log on hệ thống. Khi này, việc kiểm tra log on hệ thống của người dùng có thể sử dụng lại các test case của các dự án trước. Chú ý việc sử dụng lại file tách rời nên có cột “kết quả thực tế” của Công ty Tinh Vân – Lưu hành nội bộ Số trang : 59/78
Effective Software Testing 11/4/2013 dự án test sau đó (cột này không được hiển thị trong mục 3.7.1). Do đó, testers phải diễn tả kết quả mong đợi trong khi test mà không cần dựa vào dự án trước. Mục 3.7.1. Ví dụ về bảng kịch bản test 2 chiều. Kịch bản test được mô tả trong mục 3.7.1 là test Procedure tách rời mà mục đích của nó là có hiệu quả cao. Giữ lại dữ liệu test trong các bảng dữ liệu 2 chiều hoặc trong database, được tham chiếu trong test Procedure chính sẽ cho phép giữ lại test Procedure dễ dàng và hiệu quả hơn. Test Procedure với các yếu tố dữ liệu được giữ lại ngoài tài liệu chính sẽ giúp ích rất nhiều trong test tự động và có thể thiết lập như là nền tảng cho các tài liệu lần sau. Cả test Procedure hướng dẫn và tự động, các yếu tố dữ liệu nên được tách thàh các kịch bản khác nhau, sử dụng các biến số thay cho giá trị code cứng, và điều này được thảo luận trong chương 8. 3.9. Áp dụng Exploratory Testing (test qua toàn bộ chương trình). Như đã bàn luận phần trên, Khi hoàn thành và chi tiết hoá được các yêu cầu sẽ xác định được các mối quan hệ và phụ thuộc trong các môi trường phát triển. Thường thì 1 tester phải sử dụng kỹ năng phân tích của họ để xác định tính phức tạp của ứng dụng. Đôi khi cần có exploratory testing để có kiến thức vững vàng, cần thiết cho thiết kế test hiệu quả. Exploratory testing hữu dụng nhất khi kiến thức về hệ thống còn mơ hồ. Ví dụ với các đặc tả chức năng không đầy đủ, rõ ràng hoặc khi không đủ thời gian để nghiên cứu kỹ thiết kế chi tiết và tài liệu khác để test thì Exploratory tests rất hữu ích. Exploratory tests làm tăng cường khả năng test. Exploratory testing xác định các điều kiện test dựa trên các mục tiêu lặp lại. Vấn đề sớm được tìm ra trong exploratory testing là giúp tập trung trực tiếp vào nỗ lực test sau đó. Ví dụ, nếu sự tích hợp hệ thống ban đầu chỉ ra rằng có 1 phần của hệ thống có khá nhiều lỗi, còn các phần còn lại khá ổn thì sẽ tập trung test lại dựa trên thông tin phản hồi này. Phần test và xác định ra lỗi trong suốt quá trình exploratory testing nên được đánh giá để xác định sự tương quan với các phần phức tạp của phần mềm. Không giống với quá trình test được sự cân nhắc kỹ càng và có kế hoạch, exploratory tests không được xác định trước hay thực hiện hoàn toàn theo kế hoạch. Tất cả nỗ lực test mong muốn exploratory testing được test trước hay test thêm, kể cả việc test dựa trên yêu cầu chi tiết nhất hay yêu cầu đó chỉ trên lý thuyết (không được tài liệu hoá). Khi tester thực hiện test, phát hiện ra lỗi và cố gắng tạo lại và phân tích chúng, exloratory testing chắc chắn đưa ra nguyên nhân của vấn đề này. Thêm vào đó, trong suốt quá trình tìm kiếm lỗi, mối liên quan của Công ty Tinh Vân – Lưu hành nội bộ Số trang : 60/78
Effective Software Testing 11/4/2013 của lỗi tới các phần khác của ứng dụng được phát hiện. Điều này thường yêu cầu thực hiện các bước kiểm tra các giá trị ngoài giá trị biên theo các kịch bản đã được tạo ra. Một vấn đề khác của exploratory testing khi tester phải xác định các ngưỡng (giá trị lớn nhất và nhỏ nhất) của các tính năng đặc biệt. Xem xét ví dụ sau: Có một yêu cầu như sau: “ Trường đó phải cho phép tạo ra danh sách các quyền lựa chọn” . Dựa vào danh sách dữ liệu để xác định quyền lựa chọn (“pick-list items") và giới hạn các quyền đó, câu hỏi đầu tiên của testers là “Có bao nhiêu quyền được lựa chọn?”. Trong ví dụ này, câu hỏi trên thường bị bỏ qua trong suốt giai đoạn lấy yêu cầu của khách hàng (thậm chí vấn đề còn bị bỏ qua trong quá trình walk-throughs và kiểm thử) Tester nghiên cứu sự tồn tại của yêu cầu và hỏi phía phát triển nhưng câu trả lời không phải lúc nào cũng đáp ứng được vì nhiều khi chính khách hàng cũng mơ hồ về yêu cầu của họ. Điều cần thiết cho tester để viết test cases và thực hiện test là xác định có bao nhiêu quyền lựa chọn trong trường cho phép. Khi tester thêm quyền thì hệ thống bắt đầu suy biến hoặc để đơn giản thì hệ thống không cho phép người dùng thêm mới quyền khác. Testers phải xác định số lượng quyền giới hạn. Sau khi kiểm thử với quyền được chấp nhận thì testers khẳng định được tất cả các quyền còn lại. Tester tiêp tục test mối liên hệ giữa các trường (và các quyền lựa chọn giữa chúng), điều này được mô tả trong phần 3.3. Exploratory tests không được lập kế hoạch trước vì chúng được kiểm soát theo trường hợp case-by-case. Tuy nhiên, viết tài liệu cho exploratory tests có thể thực hiện trước hay sau khi test đều được. Thực hiện test hồi qui đối với trường hợp này (test hồi qui (regression testing) được bàn tới trong phần sau) Exploratory testing chiếm khá nhiều nỗ lực test: Nó làm tăng việc test chức năng, và được thảo luận trong phần 3.3. Khi sử dụng exploratory testing, phạm vi test thường không xác định hay đo lường được và các chức năng quan trọng có thể bị bỏ xót. Điều quan trọng là các test case về test các chức năng cần được tăng lên với sự hiểu biết sâu về các chức năng này trong suốt quá trình exploratory testing, và coi tài liệu này như là "living documents" đã được thảo luận trong phần 3.4. Để có thể test hiệu quả nhất thì cần có sự kết hợp giữa kế hoạch test hoàn hảo, chiến lược test tốt với các test cases đầy đủ và chuẩn, kết hợp với kỹ năng phân tích các chức năng Công ty Tinh Vân – Lưu hành nội bộ Số trang : 61/78
Effective Software Testing 11/4/2013 và sử dụng các kỹ thuật test thích hợp như kỹ thuật phân lớp tương đương, kỹ thuật test biên và ma trận trực giao (đã được thảo luận trong phần 3.5), và sau đó là tăng việc test exploratory testing có cơ sở. Vì không có đủ thời gian để viết tài liệu cho tất cả các kịch bản test, sự thay đổi và kết hợp của các tài liệu này. Exploratory testing là kỹ thuật test quan trọng, nó đảm bảo độ bao phủ các tình huống trong 1 chu kỳ test. 4. CÔNG CỤ TEST TỰ ĐỘNG. Công cụ test tự động có thể làm công việc test hiệu quả hơn vì quản lý được kết quả mong đợi, công cụ test tự động được hiểu và tương thích với thiết kế hệ thống được chọn. Điều quan trọng là công cụ test này cũng cho kết quả hợp với trường hợp test thủ công. Có rất nhiều loại công cụ test tự động khác nhau cho các giai đoạn phát triển, bao gồm the highly touted capture/playback testing tools. Công cụ test được xác định sau khi nghiên cứu và đánh giá nhưng đôi khi không tìm được một công cụ nào thích hợp 1 cách hoàn toàn cho 1 dự án. Trong trường hợp này, về phương diện thương mại thì có những tool có thể áp dụng vào test được nhưng nó lại thừa tính năng mà dự án cần thiết nên giá cả rất đắt. Như vậy, cần tìm 1 tool khác thích hợp. Việc xây dựng và chọn lựa 1 tool phù hợp được uỷ quyền cho người thích hợp; đặc biệt đối với phần đặc biệt của phần mềm, hay những phần có rủi ro cao hoặc những phần không test được bằng tool cũ. Trong trường hợp này, đặc biệt khi đầu tư khoản tiền lớn vào test tool thì cần có sự quan tâm của tất cả mọi người trong công ty. Một tool được chọn hay xây dựng phải thích hợp với công nghệ được chọn và thích hợp với ngân quỹ của công ty, cũng như thời gian nghiên cứu nó phải nằm trong giới hạn cho phép. Tiêu chuẩn đánh giá được thiết lập và tính khả thi của tool đó được đánh giá và kiểm tra trên các chuẩn đó. Từ đó mới ra quyết định mua hay không. Việc đánh giá và đưa ra lựa chọn 1 tool xác định để test dự án càng được đưa ra sớm càng tốt, vì khi này tránh được sự thay đổi chi phí của dự án sau này. 4.1. Các loại testing tools Trong khi các test tool chức năng (còn được gọi là "capture/playback tools") được chào bàn rất nhiều thì điều quan trọng phải có được kiến thức về các tools khác nhau để chọn được 1 tool hỗ trợ được việc test phù hợp với dự án. Trong bảng 31.1 cho chúng cái nhìn tổng quan về các tools hỗ trợ các giai đoạn khác nhau của dự án. Mặc dù có rất nhiều tool khác nhau, như tool theo dõi lỗi (defect-tracking tools) và tool quản lý cấu hình Công ty Tinh Vân – Lưu hành nội bộ Số trang : 62/78
Effective Software Testing 11/4/2013 (configuration-management) và chúng có thể sử dụng trong hầu hết các dự án phần mềm, nhưng trong bảng 31.1 cũng chỉ đưa ra các tools tiêu biểu. Tất cả các tools được đưa ra trong bảng này rất có giá trị trong việc cải thiện chu trình test. Tuy nhiên, trước khi công ty đi đến quyết định mua 1 tool nào đó thì người được uỷ quyền phân tích tool đó phải kiểm tra tool đó kỹ nhằm xác định được tool tốt nhất cho quá trình test. Ưu nhược điểm của 1 tool được kiểm tra qua việc so sánh các kết quả mà nó mang lại với mục tiêu cần chọn 1 tool. Từ đó đánh giá tiềm năng thực hiện và chỉ đạo người phân tích lợi ích và chi phí (cost/benefit). Trước khi mua 1 tool thì phải chắc rằng nó hỗ trợ hoạt động thiết kế, kỹ thuật phần mềm. Quá trình đánh giá 1 testing tool được mô tả trong phần 34. Bảng 31.1. Test Tools Công ty Tinh Vân – Lưu hành nội bộ Số trang : 63/78
Effective Software Testing Công ty Tinh Vân – Lưu hành nội bộ 11/4/2013 Số trang : 64/78
Effective Software Testing 11/4/2013 Dưới đây là một vài điểm mấu chốt về các tools khác nhau: • Người nghĩ ra Test-procedure. Một tool quản lý các yêu cầu có thể đi đôi với một người nghĩ ra các test procedures. Tool quản lý yêu cầu được sử dụng để lấy các thông tin yêu cầu của khách hàng. Sau đó, đến giai đoạn tạo ra các test procedures. Người này tạo ra các test procedures dựa vào cách thức thống kê, thuật toán và kinh nghiệm. Trong khi việc tạo ra các test procedures nhờ việc thống kê thì tool sẽ chọn cấu trúc và giá trị đầu vào trong trường hợp thống kê ngẫu nhiên, hoặc đưa ra sơ lược các thức sử dụng phần mềm khi test. Thông thường người thiết kế ra test procedures thực hiện các thao tác, dữ liệu, logic, sự kiện với tool này. Mỗi 1 hoạt động trên nhằm tìm ra các lỗi khác nhau của phần mềm. Trong trường hợp tạo ra các test-procedure nhờ vào kinh nghiệm, tool này sẽ sử dụng các thông tin được cung cấp bởi testers. Các lỗi tester tìm được trong quá khứ sẽ là đầu vào của tool này (Tool này sử dụng các lỗi trong quá khứ để tạo ra các test procedures). • Người phân tích code và công cụ viết code. Việc đo lường mức độ bao phủ của code đảm bảo cho nhóm phát triển và nhóm test nhìn thấu được sự việc, vấn đề để thực hiện viết code và test hiệu quả. Tool để làm được điều này có thể xác định được độ phức tạp của thiết kế, đo lường số lượng test tích hợp được test và không được test. Tool khác đo lường độ phức tạp của độ bao phủ test là sự phân đoạn, chia nhánh và các mức độ điều kiện khác. Mức độ bao phủ của test phụ thuộc từng phần mềm cụ thể. • Công cụ tìm ra sự thiếu hụt bộ nhớ. Các tool tìm ra sự thiếu hụt của bộ nhớ được sử dụng trong các mục đích đặc biệt: Kiểm tra xem phần mềm đó dùng tài nguyên bộ nhớ có phù hợp không. Bộ nhờ liên quan tới nhiều lỗi của chương trình, bao gồm việc thực hiện các vấn đề đặt ra. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 65/78
Effective Software Testing 11/4/2013 • Công cụ đo lường các tiện ích. Test tiện ích là test phạm vi rộng lớn của chương trình, bao gồm test về thiết kế giao diện, thiết kế đồ hoạ, nhân tố con người, dân tộc học, tâm lý học… Test tiện ích nhằm mang lại sự thoải mái, thuận tiện mà các đặc tính, tính năng của giao diện phần mềm mang lại cho người sử dụng. Do vậy, việc test giao diện phải được test thủ công của con người. Tuy nhiên, vẫn có một số tool test tự động có thể hỗ trợ quá trình này. • Test-data. Test dữ liệu hỗ trợ quá trình test thông qua tool test dữ liệu. Có nhiều tool test hỗ trợ việc test dữ liệu và database. Muốn Test dữ liệu thì phải vào được database. Và điều này thực hiện được thông qua việc thiết đặt vai trò để có thể thực hiện test chức năng, load testing, or performance and stress testing. • Công cụ quản lý test. Công cụ quản lý test hỗ trợ lập kế hoạch test, việc quản lý và phân tích toàn bộ diện mạo chu kỳ test. Một vài tool quản lý test như Rational's Test Studio. Tool này quản lý bằng cách kết hợp với việc quản lý các yêu cầu, quản lý cấu hình và tool theo dõi lỗi. • Công cụ test Web Tính phổ biến của các ứng dụng Web là hoạt động theo mô client server hoặc môi trường Web. Test Cũng khá phức tạp khi xác định nỗ lực cho test Web. Testers không chỉ test trên 1 môi trường mà còn phải test trên nhiều môi trường khác. Cấu trúc Client-server liên quan tới 3 đối tượng tách rời là server, client, và network. Inter-platform. Sự kết nối giữa chúng có thể gây lên lỗi. Do đó, quá trình test phải bao quát hết được sự thực hiện của server và network, sự thực hiện của toàn bộ hệ thống cũng như các chức năng liên quan. Nhiều công cụ test Web cho phép giám sát, đo lường, test và đoán toàn bộ chương trình. • Tool test GUI (capture/playback tools). Trên thị trường có rất nhiều tool test GUI. Các tool này thường gồm chức năng recordand-playback, chức năng cho phép testers tạo ra (record), sửa và chạy (playback) công việc test tự động trong nhiều môi trường. Các tools này record các đối tượng GUI hay mức độ “widget” (không phải mức độ ảnh bitmap). Thao tác record chụp lại các thao tác trên bàn phím mà testers nhập vào, tự động tạo ra các scripts trên nền tảng ngôn ngữ lập trình bậc cao. Việc record này là chương trình được đề cập đến như 1 kịch bản test. Tuy nhiên, nếu chỉ sử dụng chức năng capture và playback thì mới chỉ sử dụng 1 phần 10 chức năng của tool. Để có kết quả tốt nhất khi thực hiện chức năng capture/playback, Công ty Tinh Vân – Lưu hành nội bộ Số trang : 66/78
Effective Software Testing 11/4/2013 testers nên tận dụng ngôn ngữ kịch bản đã được xây dựng của tool đó. Xem phần 36 sẽ cho chúng ta biết nhiều hơn rằng tại sao không chỉ sử dụng mỗi chức năng capture/playback. Kịch bản record phải do người thiết kế ra nó sửa lại để có thể tái sử dụng và duy trì kịch bản này trong các procedures. Kết quả của các scripts cho ra các baseline test. Các script có thể được chạy lại trong nhiều phần mềm sau đó để so sánh kết quả của các baseline. Một testing tool cung cấp khả năng record và thường kèm theo đó là công cụ so sánh. Sự so sánh này là so sánh giữa kết quả đầu ra thực tế với kết quả mong đợi và log lại kết quả so sánh đó. Tool có thể so sánh giữa các điểm ảnh với nhau (pixel-by-pixel), giữa các ký tự với nhau (character-by-character), hay các đặc tính với nhau (property-by-property), và điều này phụ thuộc loại so sánh mà test cần thực hiện. Tool này sẽ tự động xác định sự khác nhau giữa kết quả mong đợi và kết quả thực tế. Ví dụ, Rational Robot và Mercury's Winrunner có thể ghi lại kết quả xác thực của việc test là pass và mô tả kết quả pass trong phần màu xanh lá cây trên màn hình và kết quả fail thì được mô tả bằng màu đỏ. • Load, performance, and stress testing tools . Performance-testing tools Cho phép testers xem xét thời gian trả về và khả năng load dữ liệu của một hệ thống hay ứng dụng. Các Tools này có thể được lập trình chạy trên nhiều máy clients một lúc để đo lường thời gian trả về của hệ thống client-server khi có nhiều người cùng truy cập hệ thống cùng một thời điểm. Stress testing liên quan tới việc chạy máy client với rất nhiều kịch bản để xác định xem hệ thống có bị sụp không và khi nào thì bị sụp. • Công cụ chuyên dụng Các kiểu ứng dụng và các cấu trúc ứng dụng khác nhau sẽ cần các công cụ test chuyên dụng cho từng phần kiến trúc đặc biệt. Ví dụ, Web application cần test Web đó không có đường link bị hỏng, không link được và test tính bảo mật của Web servers. 4.2. Xây dựng 1 tool thay cho việc mua một tool. Giả định nhóm test sẽ thực hiện test tự động 40% trong việc test dự án bằng công cụ capture/playback tool. Khi này, để test tự động hiệu quả cần yêu cầu nhóm phát triển hỗ trợ về code để test thuận lợi hơn. Nhóm test cần quan tâm tới việc xây dựng 1 tool test tự động mới để làm nổi bật chức năng capture/playback của tool đó. Sự không tương thích của 1 tool là nguyên nhân dẫn đến test không đầy đủ các trường hợp của chương trình. Đôi khi 1 ứng dụng không thích hợp với việc sử dụng tool để test Công ty Tinh Vân – Lưu hành nội bộ Số trang : 67/78
Effective Software Testing 11/4/2013 vì không có tool nào thích hợp cho việc test nó hoặc để thực hiện chức năng capture/playback quá phức tạp và mất nhiều thời gian. Như vậy, việc mua hay xây dựng 1 tool do người quản lý quyết định, và nó còn phụ thuộc vào ngân quỹ và nguồn lực được phê duyệt. Quá trình dẫn đến quyết định mua tool cần được đánh giá cẩn thận. Những ý kiến tán thành hay phản đối cần được cân nhắc kỹ. Việc xây dựng 1 tool đơn giản thì rất dễ dàng và rẻ hơn là đi mua, nhưng nếu xây dựng không thành công, xây dựng lên 1 tool lộn xộn thì tính ra lại đắt bằng hoặc thậm chí đắt hơn là bỏ tiền ra mua • Tính không tương thích của các hệ thống. Nếu như không có 1 tool nào hiện tại đang có trên thị trường thích hợp với các hệ thống khác nhau đang chạy thì nên xây dựng 1 tool riêng, theo yêu cầu của mình. • Tính không tương thích của ứng dụng. Một ứng dụng test có thể chứa 1 yếu tố là có tester biết về chức năng capture/playback của các tools trên thị trường. Nhưng nếu tool đó không được sử dụng lại trong các phần mềm sau đó thì tiền bỏ ra mua nó là lãng phí. Việc tái swr dụng nó thông qua việc có thể tái sử lại các scripts. • Sự cần thiết của công cụ test chuyên dụng. Để test đạt hiệu quả nhất thì các scipts phải là đại diện nhất. Công việc test phải được phát triển để làm tăng khả năng test GUI. Nếu như quyết định là xây dựng 1 tool thì các vấn đề quan trọng cần quan tâm là: − Xác định nguồn lực, ngân quỹ, và thời gian cần thiết cho việc xây dựng tool đó. − Sự phê duyệt của người quản lý về các yếu tố trên. − Coi sự phát triển 1 tool như nỗ lực phát triển 1 phần mềm. − Quản lý mã nguồn của tool trong việc kiểm soát phiên bản của hệ thống. Nếu không kiểm soát được nó thì không dễ dàng đồng bộ hoá phần mềm và ngừng các chức năng một cách thích hợp. − Coi việc phát triển 1 tool như mục đích chính. Khi việc phát triển 1 tool không được coi như 1 dự án thì ít khi nó được phát triển tốt. • Với một số phần codes sẽ được test với tool của công ty phát triển được nhằm kiểm tra chương trình có đáp ứng các yêu cầu của khách hàng không. Nhược điểm của tool này là không khẳng định được kết quả fail hay không. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 68/78
Effective Software Testing 11/4/2013 Quá trình xây dựng 1 tool có thể được thực hiện từ bước viết các file đơn giản hoặc ngôn ngữ kịch bản Perl đến bước tạo ra các ứng dụng phức tạp của ngôn ngữ C++. Ngôn ngữ thích hợp để xây dựng 1 tool phụ thuộc vào các thao tác cần có và các chức năng cần test. Ví dụ, nếu chức năng cần test là kiểm tra kỹ càng sự tính toán phức tạp của C++ với hàm tính toán DLL bằng việc sử dụng một vài hay toàn bộ dữ liệu đầu vào có thể, giải pháp thích hợp có thể là chương trình C++ gọi trực tiếp DLL, cung cấp sự kết hợp cần thiết để đánh giá và kiểm tra kết quả test. Thêm vào đó, việc nghiên cứu testing tool trên thị trường và xem xét việc xây dựng 1 tool thích hợp sẽ có ích rất nhiều so với việc tập hợp nhiều các phần mềm miễn phí hay cần bản quyền trên Internet. Một số phần mềm có thể nghiên cứu như DejaGNU, TETware, xUnit, và Microsoft's Web Application Stress Tool (WAST), trong khi đó, một số phần mềm không được thiết kế đặc biệt dành riêng cho việc test nhưng chúng có thể có ích trong 1 tình huống nào đó như macro-recorders, XML editors, và các tool chuyên dụng. Cuối cùng, hãng cung cấp tool lớn thường chào giá thấp với các phiên bản thấp (tính năng ít nhất) đối với các tool của họ, vì họ sợ chào giá các phiên bản cao thì kinh phí của các công ty không đáp ứng được. Ví dụ, Mercury chào bán Astra line, Rational chào bán Visual Test, và Watchfire chào bán Linkbot Personal Edition. Những versions đơn giản này có khả năng với nỗ lực việc test trong trường hợp nào đó khi ngân quỹ của 1 công ty không đủ để mua tool đắt hơn. 4.3. Ảnh hưởng của Automated Tools đến nỗ lực test Công cụ test tự động chỉ đơn thuần là một phần của giải pháp, chúng không phải là 1 giải pháp kỳ diệu nhất trong vấn đề test. Công cụ test tự động không thay thế được kỹ năng phân tích, sự quản lý test cũng như không thay thế được test thủ công. Công cụ test tự động phải được nhìn nhận như 1 sự nổi bật hơn so với quá trình test thủ công. Với ý tưởng trên, công cụ test tự động được trông đợi hỗ trợ test thủ công quá nhiều. Một số người có quan niệm rằng công cụ test tự động không thể thực hiện mọi thứ từ khi có kế hoạch test đến khi thực hiện test nếu không có test thủ công. Một số người có quan niệm sai lầm nữa là coi test tool sẽ thực hiện test được tất các yêu cầu của khách hàng, không phân biệt các thông số của các môi trường khác nhau như về ngôn ngữ lập trình khác nhau… Tuy nhiên, nhân tố môi trường được đặt ra để xác định giới hạn test thủ công và test tự động. Có một số giả thiết không đúng khi cho rằng sử dụng công cụ test tự động sẽ giảm nỗ lực và thời gian test. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 69/78
Effective Software Testing 11/4/2013 Thỉnh thoảng, sự cố gắng sử dụng test tự động sẽ bị thất bại bởi nó là phi hiện thực, không thể thực hiện được hay chọn nhầm tool. Danh sách các yếu tố sau sẽ chấn chỉnh lại các quan điểm sai lệch ở trên về testing tool và giúp tránh chọn nhầm tool test: • Nhiều tools được yêu cầu. Nói chung, chỉ 1 tool thì không thể đáp ứng test hết các yêu cầu của tất cả các phần mềm của 1 công test, trừ khi các phần mềm của công ty đó có cùng 1 kiểu hệ thống hay 1 kiểu ứng dụng. Điều này là 1 trong các nguyên nhân giải thích tại sao cần nhiều tool để đáp ứng nhiều công nghệ khác nhau. Ví dụ, nhiều tool được thừa nhận kiểm soát được giao diện người dùng. Nó có thể tương thích với ngôn ngữ chính được dùng để phát triển ứng dụng, nhưng vẫn không thể biết nó có tương thích với tất cả các ngôn ngữ hay không trừ khi hãng cung cấp khẳng định là tool đó tương thích với tất cả các ngôn ngữ. Phần 34 sẽ thảo luận việc đánh giá và mua 1 tool thích hợp cho môi trường phát triển phần mềm. • Nỗ lực test không giảm. Động cơ thúc đẩy đầu tiên khi muốn sử dụng 1 tool test tự động là giảm nỗ lực test. Kinh nghiệm chỉ ra rằng, để áp dụng được tool vào thực tế công việc test cần có sự nỗ lực nghiên cứu và học về công cụ đó. Thời gian đầu sẽ mất rất nhiều nỗ lực cho việc record các scripts và sau đó là sửa chúng để tái sử dụng lại. Và việc này tốn nhiều nỗ lực hơn so với test thủ công. Tuy nhiên, một số Test manager hay PM có thể đọc và hiểu được các tài liệu và cách thức áp dụng tool đó như thế nào nhưng khả năng áp dụng nó vào thực tế công việc của mình thì lại là vấn đề hoàn toàn khác. Điều ngạc nhiên là, khi áp dụng tool lần đầu thì nỗ lực test ban đầu sẽ bị tăng lên. Nỗ lực cần phải tính cho đến khi testers thành thạo tool đó. Người quản lý phải hiểu rằng không có 1 tool nào có thể thay thế hoàn toàn cho test thủ công. • Thời gian dự án không giảm. Một quan niệm sai về automated testing là khi áp dụng tool này cho 1 dự án mới thì ngay lập tức thời gian của dự án sẽ giảm đi. Do nỗ lực test khi áp dụng công cụ test tự động lần đầu thực tế là tăng nên thời gian của dự án cũng phải tăng theo. Một công cụ test tự động sẽ cho phép test được đầy đủ hơn các tình huống nhưng nói chung thì thời gian của dự án không thể giảm ngay lập tức được. • Automated testing dựa vào vòng đời phát triển của phần mềm. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 70/78
Effective Software Testing 11/4/2013 Khi mới áp dụng 1 tool ở giai đoạn đầu thì cần phân tích kỹ ứng dụng dưới góc độ test để xác định phần nào của ứng dụng có thể test tự động. Và cũng cần thiết phải quan tâm tới sự phát triển và thiết kế các procedure. Nỗ lực automated test được xem xét như 1 dự án nhỏ mà kế hoạch của nó có sự kết hợp nỗ lực của cả phía lập trình. • Yêu cầu ứng dụng phù hợp. Một phần mềm phải thích hợp để test tự động có hiệu quả khi sử dụng chức năng capture/playback. Việc test tự động không thể thực hiện cho toàn bộ chương trình nhưng cần thực hiện ở 1 phần nào đó của phần mềm do yêu cầu của phần mềm buộc phải thực hiện test tự động mà không test thủ công được. • Không nên thực hiện test toàn bộ bằng công cụ test tự động. Như đã nói ở phần yêu cầu trên, automated testing là công cụ tối ưu hơn test thủ công nhưng nó không thay thế được test thủ công. Điều quan trọng là phân tích được khi nào và cái gì thì test tự động, còn lại là test thủ công. Một số trường hợp test không thực hiện test tự động được như kiểm tra chức năng in của chương trình. Testers có thể tự động gửi tài liệu đến máy in, khi này hiển thị 1 thông báo là “in thành công”, nhưng testers phải kiểm tra kết quả bằng cách xem máy in có thực sự in ra tài liệu mà mình mong muốn không (nếu in ra thì còn phải kiểm tra xem các thông số in và các thiết lập trang in có đúng mong muốn không, dữ liệu có bị mất hay không…). Sau đó, kiểm tra nội dung dữ liệu trên giấy in ra bằng thị giác…. • Một test tool không cho phép thực hiện test kết hợp của tất cả các trường hợp. Một suy nghĩ sai lầm phổ biến cho rằng khi sử dụng test tool thì có thể test tự động 100% các yêu cầu đặt ra, có thể thực hiện được vô số các lần hoán vị và kết hợp vô số các tình huống khi test cũng như các thao tác của người dùng. Như vậy sẽ không đủ thời gian để làm được tất cả các điều đó. Thậm chí, về mặt lý thuyết có thể thực hiện việc kết hợp và hoán vị như trên thì nhóm test cũng không đủ thời gian và nguồn lực để thực hiện test tự động 100% toàn bộ chương trình. • Trị giá toàn bộ tool không chỉ tính mỗi giá phải trả cho nó, mà còn nhiều hơn nhiều. Khi áp dụng 1 tool không chỉ chịu giá mua tool đó mà còn bao gồm cả chi phí đào tạo, chi phí phát triển scripts tự động, và chi phí bảo trì. • "Out-of-the-box" automation is not efficient. Để bán được sản phẩm, nhiều hãng cung cấp tool thổi phồng cách sử dụng của tool đó, rằng tool này rất dễ sử dụng…Họ không cần chú ý tới thời gian, nỗ lực học tool khi một công ty mua nó. Họ nói rằng, với tool của họ, việc record thật đơn giản đối với testers, và Công ty Tinh Vân – Lưu hành nội bộ Số trang : 71/78
Effective Software Testing 11/4/2013 sau đó việc tạo ra các scripts cũng vậy, rất đơn giản khi muốn played back. Nhưng để test hoàn hảo thì thật chẳng đơn giản chút nào. Nói chung, để tạo ra các scripts test không hề đơn giản chút nào, trong suốt quá trình record, các scipts này phải sửa và việc sửa phải tiến hành thủ công bằng tay và người tạo các scripts. Điều quan trọng khi viết scripts là viết sao cho thật rõ ràng, thiết thực để kiểm tra được; ngoài ra còn phải viết sao để sau này có thể tái sử dụng nó trong các phần mềm sau. • Training. Đôi khi 1 tester chỉ có thể biết cách sử dụng tool đó đủ để thực hiện test một số trường hợp thôi vì họ không được đào tạo về tool đó, nên không thể biết hết các hỗ trợ, chức năng của nó. Khi đưa 1 tool vào sử dụng test 1 dự án mới, điều sai lầm quan trọng đã không tính đến thời gian training cách sử dụng tool trong thời gian dự án và không quan tâm tới các mốc quan trọng (milestones). Do vậy, trong suốt quá trình test từ đầu đến cuối dự án, việc training tool không được tiến hành trước và sớm nên khó có thể áp dụng chúng thành công trong dự án. Nếu việc training được tiến hành sớm sẽ đảm bảo áp dụng tool vào ngay khi bắt đầu test. Khi này các vấn đề của tool cần giải quyết cũng sớm được phát hiện ra và giải quyết sớm. Theo cách này, khả năng áp dụng test tool được thực hiện ngay từ đầu dự án. Đôi khi việc training về tool ngay từ đầu dự án cũng là quá muộn. Ví dụ, chỉ thực hiện chức năng capture/playback của test tool thì các scripts phải tạo lại, như vậy rất lãng phí nỗ lực. Nếu như testers được đào tạo sớm và nhiều hơn về test tool thì họ sẽ sử dụng thành thạo và có khi không phải tạo lại scripts mà có thể tái sử dụng lại scripts của dự án trước. • Testing tools có thể xâm nhập. Một số test tool có thể xấm nhập vào phần mềm cần test, để chúng hoạt động tốt cần phải chèn vào mã đặc biệt vào phần mềm để tích hợp phần mềm với test tool. Khi này phía lập trình sẽ không thoải mái vì để làm được điều trên thì họ phải thêm code. Họ sợ điều này vì nếu làm vậy rất có thể phần mềm hoạt động không đúng cách hoặc khi phải sửa code sẽ rất phức tạp. Để tránh nhiều xung đột, mâu thuẫn có thể xảy ra, testers lên cùng với phía phát triển chọn ra 1 test tool. Nếu test tool cần phải thêm code (không phải tool nào cũng cần thêm code), developers cần được biết trước. Để một lần nữa đảm bảo cho developers không gặp vấn đề khó khăn cũng như phức tạp thì công ty cần yêu cầu phía cung cấp tool phải đưa ra kinh nghiệm sử dụng tool và được thể hiện bằng tài liệu. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 72/78
Effective Software Testing 11/4/2013 • Testing tools có thể không ổn định. Testing tool có thể không ổn định với tất cả công nghệ. Ví dụ, với 1 công nghệ nào đó thì tool này không thực hiện thao tác lưu lại các thao tác, baselines không được lưu lại hay tool này không cho kết quả như mong muốn. Nếu có nhiều thưòi gian thì cần nghiên cứu xem tool đó có các vấn đề gì hay xảy ra hay nó có back-up được các thao tác hay không (repository). Testing tools bản thân nó cũng là 1 phần mềm phức tạp, do vậy, nó cũng có lỗi và có thể gây trở ngại với nỗ lực test. Chính vì vậy, phải yêu cầu nhà cung cấp sửa lại. Tất cả các yếu tố trên khiến nỗ lực test tăng lên trong suốt quá trinh test. • Công cụ tự động có thể làm mất đi cách nhìn nhận mục tiêu test cần đạt được là gì. Thường thì khi 1 công cụ test tự động được sử dụng lần đầu tiên cho 1 chương trình phần mềm, cần nhiều thời gian cho việc tạo scripts hơn là thời gian test thật sự. Các testers có thể rất hăm hở tạo các scripts test rất phức tạp, do vậy, có thể làm mất mục tiêu thực sự cần đạt được khi test. Họ luôn phải nhớ trong đầu rằng các scripts là 1 phần nỗ lực test, nhưng không thế được chúng. Không phải mọi thứ có thể hay nên tự động. Như đã nói ở các phần trước, việc đánh giá các phần thích hợp với test tự động là rất quan trọng. Khi lên kế hoạch test tự động, điều quan trọng là phải xác định rõ ràng sự phân chia trách nhiệm. Không cần thiết phải cả nhóm test tham gia tạo các scripts mà chỉ cần 1 vài người. Việc tạo các scripts phải căn cứ vào sự phát triển phần mềm. 4.4. Tập trung vào những gì mà công ty cho là cần thiết Bất kỳ ai tham gia nhóm test sẽ thường xuyên đỗi mặt với câu hỏi sau: “ Test tool nào là tốt nhất trên thị trường?” Người dùng sẽ có những phản ứng với các quan điểm khác nhau trên diễn đàn testing. Một người dùng có kinh nghiệm nhất về 1 tool cụ thể nào đó sẽ có quan điểm rằng tool họ đang dùng là tốt nhất. Tuy nhiên, câu trả lời tốt nhất cho câu hỏi trên là “điều đó còn phụ thuộc”. Tool tốt nhất còn phụ thuộc vào công ty và môi trường thiết kế hệ thống cũng như môi trường test, phương pháp test và nỗ lực dành cho test tự động. Những điều sau sẽ hỗ trợ cho việc chọn 1 testing tool. • Xác định loại công cụ vòng đời test cần thiết. Nếu như vai trò tự động hoá cần nỗ lực lớn của công ty thì công ty sẽ đặt ra câu hỏi: Công ty muốn tự động hoá để hoàn thành cái gì?. Xác định kết quả mong đợi của quá trình tự động hoá test để từ đó quản lý được các kết quả mong đợi (điều này đã được thảo luận trong phần 33). Công ty Tinh Vân – Lưu hành nội bộ Số trang : 73/78
Effective Software Testing 11/4/2013 Đôi khi người quản lý test sẽ chỉ dẫn để tìm ra 1 tool phù hợp với yêu cầu của công ty. Khi này, TM (test manager) sẽ quan tâm tới môi trường thiết kế hệ thống và các yếu tố cần thiết khác của công ty để đưa ra 1 loạt danh sách các tiêu chuẩn đánh giá tool. Ví dụ, môi trường thiết kế hệ thống như thế nào? Công nghệ phát triển phần mềm công ty đang sử dụng? Việc trả lời những câu hỏi này là 1 phần trong quá trình chọn lựa tool. TM cũng tìm ra các tool hỗ trợ cho 1 dự án đặc biệt mà họ đang làm, như 1 dự án Web yêu cầu 1 tool test Web riêng. Chúng ta không nên giới hạn các tiêu chuẩn chọn 1 testing tool cho 1 dự án riêng lẻ vì có khi tool này chỉ thích hợp cho 1 dự án tức thời, và sau đó nó bị bỏ đi. Khi đã quyết định chọn 1 loại testing tool, các tiêu chuẩn có thể được đưa ra nhiều hơn. Ví dụ, nếu 1 tool được sử dụng nhiều lần cho công ty. testers phải chắc chắn rằng nó có khả năng chạy được với nhiều hệ thống, ngôn ngữ lập trình và các khía cạnh khác về môi trường kỹ thuật của công ty. Testers phải xem xét môi trường thiết kế hệ thống bằng cách đưa ra các câu hỏi và các mối quan tâm đặc biệt như đã được trình bày trong chương này và các tài liệu tìm thấy. • Xác định các kiến trúc hệ thống khác nhau. Trong suốt quá trình khảo sát môi trường thiết kế hệ thống, testers phải xác định được cấu trúc ứng dụng kỹ thuật, bao gồm middle ware (lớp tác nghiệp, thường thuật ngữ này hay dùng khi lập trình mô hình 3 lớp, lớp 1 presentation là lớp giao diện, lớp 2 là lớp nghiệp vụ, lớp 3 là lớp database), database và các hệ thống thường được sử dụng nhất trong công ty hoặc những dự án đặc trưng. Họ cũng nên xác định ngôn ngữ phát triển GUI của mỗi ứng dụng. Thêm vào đó, testers cũng cần hiểu chi tiết về thiết kế cấu trúc ảnh hưởng như thế nào tới việc thực hiện các yêu cầu của khách hàng. Việc xem xét thực hiện 1 yêu cầu phổ biến, bao gồm thực hiện yêu cầu đó dưới điều kiện heavy loads, cơ chế bảo mật phức tạp, sự đo lường khả năng và độ tin cậy của hệ thống một cách tốt nhất. Tiêu chuẩn chọn lựa đặc biệt liên quan tới nỗ lực sẽ phụ thuộc yêu cầu hệ thống thích hợp của ứng dụng khi test. Nếu không thể sử dụng 1 testing tool cho tất cả các dự án hay ứng dụng thì có thể thiết lập các tiêu chuẩn chọn lựa liên quan tới các ứng dụng quan trọng dưới vai trò test. • Xác định chọn 1 hay nhiêu tool. Khi chọn 1 tool thì tool đó phải đáp ứng các tiêu chuẩn đề ra. Như đã nói ở phần 32, nói chung 1 tool không thể thoả mãn tất các yêu cầu của 1 công ty. Một tool luôn thay đổi và Công ty Tinh Vân – Lưu hành nội bộ Số trang : 74/78
Effective Software Testing 11/4/2013 phát triển, mức độ bao quát của testing tool đối với các yêu cầu của hệ thống ngày càng mở rộng và chúng luôn được cải tiến để đáp ứng các yêu cầu mong đợi. Rút cuộc, 1 tool chỉ lý tưởng cho việc test GUI, tool khác có thể cover khối lượng công việc test lớn và tool thứ 3 hiệu quả trong việc test các tiện ích. Nhiều tool phụ thuộc vào các giai đoạn test và tính khả thi của chúng cần được xem xét và tính đến. Một tool không thể thích ứng với tất cả các phần mềm hay ngôn ngữ lập trình. Ví dụ, khi test trên máy Client chạy hệ điều hành LINUX kết nối với máy chủ của IBM sử dụng 3270 sessions và máy Java client. Khi này rất khó tìm được 1 tool chạy được cả hệ điều hành LINUX, Java, và 3270 thiết bị đầu cuối. • Dưới khía cạnh test thì hiểu cách quản lý dữ liệu bằng các ứng dụng như thế nào. Nhóm test phải hiểu cách quản lý dữ liệu bởi các ứng dụng và xác định cách thức testing tool hỗ trợ việc kiểm tra dữ liệu như thế nào. Mục đích đầu tiên của hầu hết các ứng dụng là chuyển đổi dữ liệu thành các thông tin mang ý nghĩa và thể hiện chúng trên giao diện người dùng hay các form text. Nhóm test phải hiểu việc chuyển đổi dữ liệu được thực hiện bằng các ứng dụng như thế nào để có chiến lược test đúng với việc kiểm tra sự chuyển đổi dữ liệu. • Review các thông báo trợ giúp trên màn hình. Khi 1 ứng dụng hay 1 version của ứng dụng đang hoạt động, nhóm test có thể gặp thông báo có sự cố gì đó xảy ra được hiện trên màn hình. Các thông báo này thường là những thông báo lỗi do người dùng nhập liệu. Nếu có 1 version mới, nhóm test tập trung vào test các báo cáo thường xuyên xuất hiện, bao gồm việc xác định các tool hỗ trợ. • Hiểu rõ các loại test. Khi 1 dự án được chia thành nhiều giai đoạn, thì điều cần thiết là chọn 1 kiểu test test. Chiến lược test nên xác định kiểu tesễtm nó là regression testing, stress hay volume testing, usability testing. Câu hỏi giúp xác định kiểu test phù hợp là: chức năng quan trọng nhất cần test test bằng tool là gì? Tool sẽ được sử dụng chính để test stress testing? Có một vài testing tool chuyên dụng trong việc phân tích toàn bộ mã nguồn mở. Chúng xác định tất cả các đường dẫn mã nguồn mở có thể phải test. Điều này có nên yêu cầu thành lập 1 dự án đặc biệt hay không? Các tool khác cần quan tâm là các tool hỗ trợ quá trình tự động và khối lượng dữ liệu load thông qua các file dữ liệu đầu vào. Một số câu hỏi khác như: Mục tiêu cần đạt được khi test dự án đó là gì? Các chức năng mong đợi là gì? • Thời gian. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 75/78
Effective Software Testing 11/4/2013 Một điểm khác khi chọn 1 tool là nó ảnh hưởng tới thời gian của dự án. Điều quan trọng là phải xác định đủ thời gian cần thiết cho testers học về tool. Nếu không có đủ thời gian, rủi ro nhóm test chọn 1 tool không thích hợp cho dự án, cho công ty. • Ngân quỹ cho phép. Khi đã xác định được 1 tool thích hợp là điều rất tốt nhưng điều quan trọng là ngân quĩ của công ty có đáp ứng được hay không. Công ty có thể dành nỗ lực hàng tháng để đánh giá thế mạnh của tool đó, nhưng chi phí cho nó vượt quá ngân quỹ cho phép. Thêm vào đó, ngân sách còn phải tính cho cả chi phí training cho testes sử dụng thành thạo tool. Điều quan trọng nhất testers nên nhớ là không có 1 tool nào tốt nhất cho tất cả các môi trường phần mềm. Tất cả các tool đều có cái thuận lợi và cái khó khăn với các môi trường khác nhau. Việc chọn lựa tool nào còn phụ thuộc vào môi trường thiết kế hệ thống và các yêu cầu cũng như các tiêu chuẩn đặc biệt được công ty đặt ra. 4.5. Kiểm tra tool bằng các Prototype. Đưa ra 1 loạt các hình ảnh rộng lớn về các kỹ thuật được sử dụng trong khi phát triển phần mềm. Khi này điều quan trọng là kiểm tra chức năng chỉ dẫn thích hợp của tool với phần mềm đang phát triển. Cách tốt nhất để hoàn thành việc này là có sự giải thích của hãng cung cấp tool này về sự tương thích của tool với các phần mềm được test. Tuy nhiên, điều này thường không thể thực hiện được, do vậy, khi phần mềm được test thì không được đánh giá về tính tương thích của tool. Khi có sự lựa chọn, các lập trình viên có thể tạo ra các prototypes để đánh giá các tool này. Trong suốt quá trình đánh giá, có thể phát hiện ra 1 vài chức năng khác thường của tool không tương thích với các công nghệ phát triển hiện có của phần mềm. Ví dụ, Nhóm test không thể thực hiện thao tác capture/playback hay thực hiện các chức năng quan trọng của tool. Các prototypes phải dựa vào các phần chính của hệ thống, các phần này là đại diện của công nghệ dùng phát triển phần mềm. Khả năng thực hiện của tool đặc biệt quan trọng trong test GUI vì có thể tool rất khó nhận biết các đối tượng trên giao diện. Vấn đề thường gặp khi các đối tượng là lịch, grids và spin controls được kết hợp trong nhiều ứng dụng, đặc biệt trên nền Window. Các đối tượng này được gọi duy nhất 1 lần VBXs, sau đó là OCXs, và bây giờ lại được đề cập đến như Active-X Controls trên Windows và Web interface. Chúng thường được viết bởi bên thứ 3. Ví dụ, 1 tool có khả năng nhận ra và tương thích với ngôn ngữ Visual Basic và PowerBuilder. Nhưng nếu tool này được kiểm soát bởi bên thứ 3 thì rất có thể nó không Công ty Tinh Vân – Lưu hành nội bộ Số trang : 76/78
Effective Software Testing 11/4/2013 nhận biết được các đối tượng trên màn hình. Testers cần xác định được các đối tượng mà tool này không nhận biết được thông qua cách thức làm việc có trao đổi với nhau để test các đối tượng này theo cách thủ công. Những đối tượng không được test bằng tool có thể bị xót không được test nếu testers không đánh giá được và thực hiện cách test khác thích hợp. Các thành viên đánh giá tool cũng cần đánh giá trên nền tảng thích hợp. Thường thì việc đánh giá dựa trên nền tảng kỹ thuật nhằm đảm bảo người thiết kế có thể sử dụng các prototype để đánh giá các chức năng của tool thích hợp với công nghệ. Hơn nữa, tính dễ sử dụng, tính mềm dẻo và các đặc tính khác được thảo luận trong phần 34 là cơ sở đánh giá tốt nhất của các thành viên tham gia đánh giá cho phần mềm đó. Như vậy là không có gì có thể thay thế trong việc nhìn nhận 1 tool thông qua các prototype. Một vài hãng có thể đưa ra lời hứa, tool của họ tương thích với nhiều công nghệ Web, nhưng điều tốt nhất vẫn nên kiểm tra lại. Với công nghệ "churn" trong ngành công nghiệp phần mềm, không có hãng nào có thể tuyên bố là tool của họ thích hợp với mọi công nghệ. Công ty phải tự chọn tool mà mình thấy cần thiết. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 77/78
Effective Software Testing Công ty Tinh Vân – Lưu hành nội bộ 11/4/2013 Số trang : 78/78

More Related Content

PPT
01 tester training - overview
bysong_lachinhminh_smile
 
PPT
Nguyên tắc cơ bản của kiểm thử phần mềm
byNgọc Khánh
 
PPTX
Slide đồ án kiểm thử PM
byNguyễn Anh
 
PPT
Kiem thu phan mem
byTIen Le
 
PPTX
Test plan
byTrung Hiếu Trần
 
DOC
TÌM HIỂU CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM
byNguyễn Anh
 
PDF
Kiểm thử phần mềm
byNguyen Vu
 
PPTX
[Seminar] Hướng dẫn viết test case
byLe Vu Trung Thanh
 
01 tester training - overview
bysong_lachinhminh_smile
 
Nguyên tắc cơ bản của kiểm thử phần mềm
byNgọc Khánh
 
Slide đồ án kiểm thử PM
byNguyễn Anh
 
Kiem thu phan mem
byTIen Le
 
Test plan
byTrung Hiếu Trần
 
TÌM HIỂU CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM
byNguyễn Anh
 
Kiểm thử phần mềm
byNguyen Vu
 
[Seminar] Hướng dẫn viết test case
byLe Vu Trung Thanh
 

What's hot

PPT
Kiem thu
byquynh0330
 
DOC
TÌM HIỂU CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM
byNguyễn Anh
 
PPTX
Sldie TÌM HIỂU CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM
byNguyễn Anh
 
PDF
He thong cong cu kiem thu tu dong va dam bao chat luong phan mem
byViet Hung Vu
 
DOCX
Đồ án kiểm thử phần mềm
byNguyễn Anh
 
PDF
Kiem thu
byVan Tiep Dinh
 
PDF
Ứng dụng công cụ test tự động kiểm thử website
byDotnet Open Group
 
DOC
Nghiên cứu chuẩn ISO/IEC 9126 trong đánh giá chất lượng phần mềm
byNguyễn Anh
 
PPTX
2014/07/07 Software Testing - Truong Anh Hoang
byVu Hung Nguyen
 
PDF
Đồ Án Tìm Hiểu Phần Mềm Loadrunner Kiểm Tra Hiệu Năng Website
bynataliej4
 
DOCX
6 câu hỏi phỏng vấn tester thông dụng năm 2021
byMDuyn83
 
PDF
Bai05 thiet ketestcase-k-trpm@softtesting-nntu
byVan Pham
 
DOCX
Tìm hiểu các kỹ thuật kiểm thử phần mềm ứng dụng trong lập trình Java.
byNguyễn Anh
 
PDF
Luận văn: Kiểm thử tự động tương tác giao diện người dùng, 9đ
byDịch Vụ Viết Bài Trọn Gói ZALO 0917193864
 
DOC
Tailieu.vncty.com t ke-testcase
byTrần Đức Anh
 
DOCX
Tìm Hiểu Các Kỹ Thuật Kiểm Thử Phần Mềm và Một Số Ứng Dụng Trong Thực Tế
byNguyễn Anh
 
PDF
Đề tài: Xây dựng công cụ kiểm thử tự động cho chương trình C
byDịch Vụ Viết Bài Trọn Gói ZALO 0917193864
 
PPT
Cac kythuatktpm
byNhân Nguyễn
 
DOC
Danh gia chat luong san pham mem
byUDCNTT
 
PPT
Cnpmnc ch3 kiem thu ql cau hinh
byKy Vo
 
Kiem thu
byquynh0330
 
TÌM HIỂU CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM
byNguyễn Anh
 
Sldie TÌM HIỂU CÁC KỸ THUẬT KIỂM THỬ PHẦN MỀM
byNguyễn Anh
 
He thong cong cu kiem thu tu dong va dam bao chat luong phan mem
byViet Hung Vu
 
Đồ án kiểm thử phần mềm
byNguyễn Anh
 
Kiem thu
byVan Tiep Dinh
 
Ứng dụng công cụ test tự động kiểm thử website
byDotnet Open Group
 
Nghiên cứu chuẩn ISO/IEC 9126 trong đánh giá chất lượng phần mềm
byNguyễn Anh
 
2014/07/07 Software Testing - Truong Anh Hoang
byVu Hung Nguyen
 
Đồ Án Tìm Hiểu Phần Mềm Loadrunner Kiểm Tra Hiệu Năng Website
bynataliej4
 
6 câu hỏi phỏng vấn tester thông dụng năm 2021
byMDuyn83
 
Bai05 thiet ketestcase-k-trpm@softtesting-nntu
byVan Pham
 
Tìm hiểu các kỹ thuật kiểm thử phần mềm ứng dụng trong lập trình Java.
byNguyễn Anh
 
Luận văn: Kiểm thử tự động tương tác giao diện người dùng, 9đ
byDịch Vụ Viết Bài Trọn Gói ZALO 0917193864
 
Tailieu.vncty.com t ke-testcase
byTrần Đức Anh
 
Tìm Hiểu Các Kỹ Thuật Kiểm Thử Phần Mềm và Một Số Ứng Dụng Trong Thực Tế
byNguyễn Anh
 
Đề tài: Xây dựng công cụ kiểm thử tự động cho chương trình C
byDịch Vụ Viết Bài Trọn Gói ZALO 0917193864
 
Cac kythuatktpm
byNhân Nguyễn
 
Danh gia chat luong san pham mem
byUDCNTT
 
Cnpmnc ch3 kiem thu ql cau hinh
byKy Vo
 

Similar to Effective software testing

DOC
Effectivesoftwaretesting 131104102937-phpapp01
byThanh Danh
 
PDF
001-Tong-quan-kiem-thu_thanhDHTL_244.pdf
byphamquocthoai7a4
 
PDF
Bai11 quan ly-kiemtra-ktrpm@softtesting-nntu
byJenny Nguyen
 
PDF
Bai11 quan ly-kiemtra-ktrpm@softtesting-nntu
byVan Pham
 
PPTX
Quality Management Quality Managementxxxx
byHieuTran12923
 
PDF
Bai03 kiem tratinh-k-trpm@softtesting-nntu
byVan Pham
 
PDF
Bai03 kiem tratinh-k-trpm@softtesting-nntu
byVan Pham
 
PDF
Bai12 too ls-kiemtra-ktrpm@softtesting-nntu
byVan Pham
 
PDF
Bai12 too ls-kiemtra-ktrpm@softtesting-nntu
byJenny Nguyen
 
PDF
Bai01 k tr-pm@softtesting-nntu
byVan Pham
 
PDF
Ngân hàng đảm bảo chất lượng phần mềm PTIT - Chuẩn SQA
byPopping Khiem - Funky Dance Crew PTIT
 
PDF
3-Requirements_VI.pdf
byEllieHuynh3
 
PDF
Giải Ngân Hàng Đảm Bảo Chất Lượng Phần Mềm PTIT - SQA
byPopping Khiem - Funky Dance Crew PTIT
 
DOC
Báo Cáo Chuyên Đề Học Phần Kiểm Thử Mobile App Bán Quần Áo.doc
byDV Viết Luận văn luanvanmaster.com ZALO 0973287149
 
PDF
Bai07 kiem tramuccao-k-trpm@softtesting-nntu
byJenny Nguyen
 
PDF
Bai07 kiem tramuccao-k-trpm@softtesting-nntu
byVan Pham
 
PDF
đề Tài tìm hiểu phần mềm loadrunner kiểm tra hiệu năng web site
byjackjohn45
 
PDF
Bai00 gioi thieu-k-trpm@softtesting-nntu
byVan Pham
 
PPTX
DEV3_TestTraining.pptx
byLmDngNgc
 
PPTX
kiemthuphanmemnhom14 (1)nhomsvk17thuchien.pptx
byLnNguynThnh4
 
Effectivesoftwaretesting 131104102937-phpapp01
byThanh Danh
 
001-Tong-quan-kiem-thu_thanhDHTL_244.pdf
byphamquocthoai7a4
 
Bai11 quan ly-kiemtra-ktrpm@softtesting-nntu
byJenny Nguyen
 
Bai11 quan ly-kiemtra-ktrpm@softtesting-nntu
byVan Pham
 
Quality Management Quality Managementxxxx
byHieuTran12923
 
Bai03 kiem tratinh-k-trpm@softtesting-nntu
byVan Pham
 
Bai03 kiem tratinh-k-trpm@softtesting-nntu
byVan Pham
 
Bai12 too ls-kiemtra-ktrpm@softtesting-nntu
byVan Pham
 
Bai12 too ls-kiemtra-ktrpm@softtesting-nntu
byJenny Nguyen
 
Bai01 k tr-pm@softtesting-nntu
byVan Pham
 
Ngân hàng đảm bảo chất lượng phần mềm PTIT - Chuẩn SQA
byPopping Khiem - Funky Dance Crew PTIT
 
3-Requirements_VI.pdf
byEllieHuynh3
 
Giải Ngân Hàng Đảm Bảo Chất Lượng Phần Mềm PTIT - SQA
byPopping Khiem - Funky Dance Crew PTIT
 
Báo Cáo Chuyên Đề Học Phần Kiểm Thử Mobile App Bán Quần Áo.doc
byDV Viết Luận văn luanvanmaster.com ZALO 0973287149
 
Bai07 kiem tramuccao-k-trpm@softtesting-nntu
byJenny Nguyen
 
Bai07 kiem tramuccao-k-trpm@softtesting-nntu
byVan Pham
 
đề Tài tìm hiểu phần mềm loadrunner kiểm tra hiệu năng web site
byjackjohn45
 
Bai00 gioi thieu-k-trpm@softtesting-nntu
byVan Pham
 
DEV3_TestTraining.pptx
byLmDngNgc
 
kiemthuphanmemnhom14 (1)nhomsvk17thuchien.pptx
byLnNguynThnh4
 

Effective software testing

  • 1.
    CÔNG TY CÔNGNGHỆ 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: [email protected] Văn phòng phía Nam 124 Bắc Hải, phường 6, Quận Tân Bình, Tp. HCM Tel.: +84-8-9706066, Fax.: 9706077 E-mail: [email protected]
  • 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ỤCLỤ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âydự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 DANHSÁ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 Đầutiê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 đượcsẽ đả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 Đốivớ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ậtkhó 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ứơctiế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ảiphá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ôngthể 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ếunhó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 Khixá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 ảnhhưở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ứcnă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ộtbộ 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 Testerscầ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 thaotá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 Danhsá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ếtquả 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
  • 36.
    Effective Software Testing 11/4/2013 1dự án, bao gồm tham gia khảo sát yêu cầu khách hàng, cấu hình hệ thống, quản lý qui trình (PQA), deverlopers và QA để tính toán số người và thời gian test. Phương pháp này có giá trị đặc biệt khi số người thực hiện công việc phát triển thường xuyên thay đổi hay rất khó để xác định số người tham gia phát triển. Trong việc tính toán số người test trong bảng 12.2, giả thiết là phạm vi nỗ lực test bao gồm cả việc nghiên cứu SRS, test cấu hình hệ thống, test quá trình xử lý liên quan, test chức năng và test hiệu năng của giai đoạn test tích hợp ve test hệ thống. Việc chọn con số 50 trong cột "Project Staffing Level" nhằm đơn giản hoá việc tính toán giá trị của cột "Test Team Size". column. Tất nhiên số lượng người tham gia dự án có thể ít hay nhiều hơn. Bảng 12.2. Số Tester được tính toán dựa vào số lượng nhân viên toàn dự án. Type of Produces Project (Loại sản phầm) Staffing Level (số nhân viên tham gia dự án) Sản phầm thương mại 50 (thị trường lớn) Sản phầm thương mại 50 (thị trường nhỏ) Tích hợp và phát triển 50 cho máy client Các phần mềm cho 50 Chính Phủ, Nhà nước (trong nước) Phần mềm cho các tổ 50 chức trong nước Test Team Size Số Testers 27 13 16 8 14 7 11 5 14 lượng 7 c. Phương pháp test procedures. Cách khác để đo lường nỗ lực test là sử dụng khối lượng chương trình test để đo lường, cụ thể hơn là dựa vào số lượng test procedures của dự án đã được lập kế hoạch để đo lường. Phương pháp này có phần bị hạn chế do phụ thuộc vào số lượng test procedures Công ty Tinh Vân – Lưu hành nội bộ Số trang : 36/78
  • 37.
    Effective Software Testing 11/4/2013 củadự án mà không tính đến các nhân tố ảnh hưởng tới nỗ lực test. Phương pháp này là sự kết hợp với 1 phương pháp trong hàng loạt các phương pháp khác. Để áp dụng được phương pháp này, các Test Procedure của dự án cũng như quá trình thực hiện dự án đó cần được ghi lại ngay từ đầu để có dữ liệu đánh giá, như việc chỉ ra các chức năng, số lượng test procedures sử dụng và kết quả nỗ lực test được đo lường với đơn vị là “số giờ/1 tester” Trị số qui mô phát triển được tài liệu hoá dưới dạng những dòng mã lệnh (lines of code (LOC)), những dòng mã lệnh tương đương, hàm con trỏ, số lượng các đối tượng được phát triển. Nhóm test xác định các yêu cầu và mối liên hệ giữa các trị số qui mô phần mềm trước đó và số lượng các test procedures được sử dụng trong các dự án đó. Từ đó, chúng ta tính toán và ước lượng được số lượng các test procedures cho dự án mới. Tiếp đến là nhóm test xác định mối liên quan giữa số lượng các test procedures và số giờ mỗi tester cần có dựa vào kinh nghiệm từ các dự án trước. Phương pháp ước lượng này thành công nhất khi các dự án so sánh với nhau có sự tương tự về bản chất, công nghệ, yêu cầu về sự thành thạo, cách thức giải quyết vấn đề và các nhân tố khác. Bảng 12.3 trình bày ví dụ về việc xác định số giờ test áp dụng phương pháp Test Procedure (giả thiết, dự án có 1.120 test procedures). Nhóm test xem xét nỗ lực test của 2 hoặc nhiều hơn 2 dự án có trung bình 860 test procedures và cần tới 5.300 giờ cho việc test. Trong nố lực test của các dự án trước đó, số giờ test trên mỗi test procedure là 6.16 giờ là hợp lý (cho toàn bộ vòng đời của dự án). Dự án cần 5.300 giờ thường kéo dài 9 tháng, trong đó, cần 3,4 tháng thiết kế test. Công việc bây giờ là xác định số giờ test cho dự án mới có 1.120 test procedures. Bảng 12.3. Ước lượng thời gian test dựa theo phương pháp TestProcedure Công ty Tinh Vân – Lưu hành nội bộ Số trang : 37/78
  • 38.
    Effective Software Testing 11/4/2013 Điềuquan trọng phải xác định được mối liên quan giữa số lượng các test procedures và phạm vi các yêu cầu cần test. Ưu điểm của phương pháp này là xác định được yêu cầu test và phạm vi test sớm hơn so với 2 phương pháp trên. Nhưng nhược điểm của nó là thời gian ước lượng được tính trước khi hoàn thành xong đặc tả yêu cầu của khách hàng. d. Phương pháp kế hoạch công việc. Phương pháp khác ước lượng nỗ lực yêu cầu của chương trình liên quan tới việc xem xét con số lịch sử về nỗ lực test tương tự. Phương pháp này khác so với phương pháp Test Procedure ở chỗ nó tập trung vào các task của công việc test. Bảng 12.4 là 1 ví dụ về việc ước lượng nỗ lực test cho 1 dự án có 1.120 test procedures dựa vào dự án có 860 test procedures, cần 5.300 giờ cho cả dự án và 6,16 giờ test cho 1 test procedure( Ví dụ này tương tự ví dụ khi sử dụng phương pháp Test Procedure trong bảng 12.3.) Bảng 12.4. Ước lượng nỗ lực test dựa theo phương pháp kế hoạch công việc test (các task công việc test) Công ty Tinh Vân – Lưu hành nội bộ Số trang : 38/78
  • 39.
    Effective Software Testing 11/4/2013 •Giả thiết: Nhóm test cần xem xét các con số của các dự án trước để chia số giờ thực hiện thành các task công việc hay gọi là các giai đoạn test. Tóm lại, số giờ của mỗi giai đoạn test được trình bày trong bảng 12.5. Bảng 12.5. Xác định số giờ của mỗi giai đoạn test theo phương pháp kế hoạch công việc. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 39/78
  • 40.
    Effective Software Testing 11/4/2013 Đểđưa ra được các con số này, nhóm test phải ước lượng ngay từ khi dự án mới được bắt đầu (nếu không có các con số của dự án trước thì việc ước lượng thời gian cho mỗi giai đoạn test sẽ dựa vào kinh nghiệm của người lập kế hoạch). Trong ví dụ trên, dự án mới có sử dụng công cụ test tự động và việc đưa ra bước 3 và 4 là không cần thiết. Nhóm test cũng cần thận trọng vì dự án không có ngân quỹ dành cho việc thực hiện cải tiến qui trình test, vì vậy không có bước 11 trong bảng trên. Bước tiếp theo trong bảng 12.6, tính toán, ước lượng nỗ lực nhóm test dựa vào sự điều chỉnh số giờ 6.403. Nỗ lực nhóm test được ước lượng tương đương là 3,1 testers với 1 dự án 12 tháng. Nhóm test sẽ bố trí chính xác là 3 testers làm toàn thời gian (100%) trong khoảng thời gian test đã xác định. Các testers phải tập trung test trước các phần có độ rủi ro cao. Và chiến lược test cần được điều chỉnh theo nỗ lực vừa tính toán ở trên. Nhóm test có thể bố trí nhân lực test theo các cách khác nhau, có thể bố trí toàn thời gian của 1 tester cho dự án hay phân đoạn thời gian như 80% thời gian tester 1 và 80% tester 2. Bảng 12.6. Nỗ lực Test dựa vào ước lượng thời gian của nhân viên. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 40/78
  • 41.
    Effective Software Testing 11/4/2013 e.Các phương pháp khác. Trong các tình huống đặc biệt, căn cứ vào kinh nghiệm để xác định nỗ lực test mà không cần quan tâm tới các phương pháp. Ví dụ, khi sử dụng phương pháp tỷ lệ tester so với deverloper thì không nhấn mạnh được thời gian test trong các dự án trước đó. Do vậy, không định nghĩa được quá trình test, nên cần thiết phải điều chỉnh tỷ lệ này. Tương tự như vậy, khi áp dụng phương pháp kế hoạch công việc, nếu nhóm test có ít kinh nghiệm thì rất dễ phải điều chỉnh các task công việc, các nhân tố ảnh hưởng. Các nhân tố ảnh hưởng tới việc ước lượng nỗ lực test bao gồm: • Cách tổ chức. • Phạm vi test. Có thể test chức năng, test hiệu năng và test giao diện, test tính bảo mật, test tiện ích (phím tắt…)…. • Kỹ năng của người thực hiện test. • Thành thạo các công cụ test. Khi sử dụng công cụ test tự động sẽ rất khó khăn đối với người chưa thực hiện công cụ đó bao giờ, do vậy, họ cần được học về tool đó. Muốn sử dụng được các test tool đó cần có kịch bản test. Điều này là mới với nhóm test vì họ thiếu kinh nghiệm hay thậm chí không có kinh nghiệm trong viết code. Hay thậm chí, tester đó thành thạo với 1 test tool này nhưng với 1 tool khác thì hoàn toàn mới với họ. • Kiến thức về nghiệp vụ. Kiến thức của 1 tester về một ứng dụng nào đó chưa sâu do không phải họ hiểu tất cả các nghiệp vụ thuộc tất cả các lĩnh vực. Các kiến thức đó còn được gọi là "kiến thức đặc thù” (domain knowledge) • Tổ chức nhóm test. Chương 5 sẽ trình bày kỹ hơn về các loại tổ chức công việc test. • Phạm vi chương trình test. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 41/78
  • 42.
    Effective Software Testing 11/4/2013 •Thời điểm bắt đầu test Kế hoạch test nên được bắt đầu ngay khi dự án bắt đầu. Điều này có nghĩa là các testers tham gia vào test dự án đó sẽ nghiên cứu, phân tích và thiết kế test cho dự án đó. Sự tham gia sớm của tester không những giúp họ hiểu hơn về yêu cầu cũng như thiết kế, cấu trúc hệ thống. Từ đó, xác định được môi trường test hiệu quả mà còn sớm phát hiện ra lỗi và ngăn chặn lỗi ngay từ giai đoạn viết đặc tả yêu cầu của phía lập trình (từ đặc tả này sẽ thiết kế chương trình, và từ thiết kế sẽ viết code). • Sử dụng các test tool. Với nhiều hãng phần mềm chuyên nghiệp, việc sử các test tool giúp giảm nỗ lực test, giảm sự phức tạp khi lập kế hoạch test cũng như việc thực hiện test. • Rủi ro của phần mềm cao. Nếu một phần mềm có độ rủi ro cao, có thể có nhiều lỗi mà xác định nỗ lực test không đủ thì dẫn đến chất lượng phần mềm đó có xác suất rủi ro cao. Cuối cùng, khi xác định nỗ lực test, cần quan tâm tới các yếu tố ảnh hưởng để tính đến các tình huống đặc biệt. Nhằm hỗ trợ cho việc lập kế hoạch test, việc theo dõi số giờ thực tế của mỗi task công việc thường được sử dụng nhất. Tuy nhiên, vấn đề đối với tất cả các phương pháp đưa ra là, rất ít khi có 2 phần mềm tương tự nhau. Một sản phẩm phần mềm phụ thuộc vào độ phức tạp, kinh nghiệm của deverloper, công nghệ và nhiều yếu tố khác nữa. 3. TEST PROCEDURE VÀ THIẾT KẾ TEST. Test Procedure và thiết kế Test là 2 công việc quan trọng của nhóm test. Như đã nói ở chương số lượng hồ sơ đem ra khai thác, hai công việc này test chỉ được bắt đầu khi phần mềm đã được code xong, nhưng nếu 2 công việc này được bắt đầu càng sớm càng tốt, và có thể thực hiện, tiến hành ngay khi tài liệu đặc tả yêu cầu được phê duyệt. Khi tài liệu đặc tả và thiết kế hệ thống được sàng lọc, chọn lựa kỹ hay được lặp lại ( sửa) tài liệu hay thiết kế lại thì các test Procedure cũng sẽ được hoàn thành tương ứng với việc hoàn chỉnh tài liệu và thiết kế các chức năng của hệ thống. Test Procedure mang lại lợi ích rõ ràng, giúp chúng ta đạt được tới đích nhanh chóng và hiệu quả. Qua tài liệu này sẽ xác định được là test black-box hay gray-box; định dạng cho tài liệu này, các kỹ thuật test được chọn là gì. Ví dụ, như sự kiểm tra test biên, Công ty Tinh Vân – Lưu hành nội bộ Số trang : 42/78
  • 43.
    Effective Software Testing 11/4/2013 exploratorytesting. Thêm vào đó, kịch bản test và các test tool sẽ giúp chúng ta đạt được đích mong muốn. Trong việc đánh giá các yêu cầu và việc thiết kế phần mềm đòi hỏi phải có hiểu biết nhiều về cấu trúc, về vấn đề chủ chốt đầu tiên cần xem xét hay các application đã có. Vì vậy, các testers phải chia và thực hiện từng giai đoạn, thao tác nhỏ trong hàng loạt các thao tác cần thực hiện nhằm đảm bảo thực hiện đúng lịch test và số tiền giành cho test. Như vậy, các câu hỏi test cái gì? test bằng cách nào? test như thế nào? test khi nào? và ai sẽ test là các câu hỏi cần được trả lời trong chiến lược test, phải chia nhỏ thành các giai đoạn nhỏ, sử dụng các kỹ thuật đặc biệt và phải có mức ưu tiên trong quá trình test song song hay test lặp. 3.1. Sự phân chia và thực hiện test. Với tài liệu đặc tả và thiết kế, các testers sẵn sàng để lập ra và phát triển các loại test Procedure. Khi phần mềm có nhiều yêu cầu, quyết định nơi bắt đầu để lập và phát triển test Procedure dường như rất khó. Phần này muốn đưa ra phương pháp giúp chia nhỏ các giai đoạn test. Trước khi thiết kế test, điều cần thiết là phải quan tâm tới các giai đoạn test cần thực hiện. Có sự khác nhau giữa các giai đoạn test như test tiện ích, test hiệu năng, test bảo mật, và các giai đoạn test khác như test chức năng và test phi chức năng. Test phi chức năng sẽ được bàn đến trong chương 9. Bước đầu tiên trong việc thiết kế test Procedure là phải xem xét lại kế hoạch test. Nếu kế hoạch đó không ổn để có thể hiểu được các tình huống hay bản chất của vấn đề thì sẽ không xác định được mục tiêu test, phạm vi test. Kế hoạch test cũng liệt kê các nguồn lực tham gia quá trình test như các tool hỗ trợ, các phương pháp test, các tiêu chuẩn test phải theo hay lịch test. Nếu kế hoạch test không hợp lý hay không được lập trước đó thì các thông tin về phạm vi test, các mục cần test ….sẽ phải lấy từ các nguồn khác. Để chia nhỏ các giai đoạn test thì phải trả lời được các câu hỏi sau: test cái gì? test khi nào? test như thế nào? ai sẽ tham gia vào quá trình test? • Những phần nào cần test? Trong giai đoạn lập kế hoạch test, phải xác định ngay phần nào cần test, phần nào không để từ đó xác định được phạm vi cần test. • Khi nào thì test? Công ty Tinh Vân – Lưu hành nội bộ Số trang : 43/78
  • 44.
    Effective Software Testing 11/4/2013 Trongphần 3, chúng ta đã đưa ra yêu cầu phải thiết kế test Procedure càng sớm càng tốt khi có tài liệu đặc tả. Khi đã xác định được phần nào cần nào cần test, phần nào không thì chúng ta cần xác định được trình tự test. Vậy, vấn đề đặt ra là cái gì cần được test trước tiên? Tester lên kế hoạch test phải biết được phần nào được ưu tiên test trước, phần nào test cùng nhau và từ đó đưa ra lịch test cụ thể. Tiến trình test phải ưu tiên cho mục cần test trước. Trừ khi có ngoại lệ là các chức năng chắc chắn cần được chạy trước để chuẩn bị cho các chức năng khác. Như vậy, các chức năng này cần được ưu tiên test trước hay không? vấn đề này sẽ được bàn kỹ hơn trong các phần, các mục cần được ưu tiên test trước trong phần 8). Thêm vào đó, việc phân tích rủi ro nên được tính đến khi xét đến các mức độ ưu tiên này. Nếu không phải test toàn bộ chương trình, các testers chỉ cần quan tâm tới các phần cần test mà thôi. Việc phân tích rủi ro đưa ra cơ chế để xác định những phần cần test và những phần có thể bỏ qua không test. • Test Procedure nên được thiết kế như thế nào? Không có bất kỳ một giải pháp đơn lẻ nào có thể test toàn bộ hệ thống một cách hiệu quả. Test Procedure cho các phần khác nhau của một hệ thống cần được thiết kế thích hợp, đặc biệt cho các phần đặc biệt của chương trình. Để thiết kế test Procedure thích hợp và hiệu quả thì điều cần thiết là phải quan tâm đến cấu trúc hệ thống và tích hợp hệ thống. Ví dụ, để xác minh lại các chức năng của hệ thống thì có thể thông qua giao diện người dùng. Test Procedure sẽ dựa trên các yêu cầu chức năng đã có trong tài liệu, trong đó, các test cases phải thể hiện đầy đủ các trường hợp xảy ra. Các test cases sẽ được bắt đầu với các bộ dữ liệu đúng và bộ dữ liệu không đúng cho test giao diện để xác minh lại định dạng chuẩn của các trường dữ liệu đầu vào. Điều này liên quan tới một chuỗi các thao tác kiểm thử sau đó. Ví dụ, khi nhập dữ liệu cho một trường hay màn hình này lại trả ra một màn hình khác mà cũng yêu cầu nhập dữ liệu. Test Procedure phải thiết kế cho GUI testing hay back-end testing, hay cả hai còn phụ thuộc vào chiến lược test đã xác định trước đó. GUI tests khác so với back-end tests. • Những ai sẽ tham gia vào test? Khi đã xác định được phải test phần nào? và test khi nào? test như thế nào thì sẽ dễ dàng xác định được trách nhiệm của từng người sẽ test phần nào dựa trên khả năng và kinh nghiệm của các tester. (xem phần 13). should develop the tests? Ngoài ra sẽ có nhiều câu hỏi được đặt ra trong suốt quá trình lập và thiết kế test Procedure. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 44/78
  • 45.
    Effective Software Testing 11/4/2013 •Νếu không có tài liệu đặc tả thì test Procedure sẽ được thiết kế ra sao? Nếu không có tài liệu đặc tả để viết test case thì điều cần thiết để có thể viết test cases là hỏi người đại diện, người có trách nhiệm đối với các yêu cầu đó hay nhân viên kỹ thuật hay những người review các yêu cầu của khách hàng (nhưng các yêu cầu đó không được viết thành tài liệu). Ví dụ như hướng dẫn người dùng của hệ thống hiện tại (nếu đã có) hay những tài liệu hướng dẫn người dùng, đặc tả yêu cầu của các hệ thống trước đó để hiểu tốt hơn về hệ thống đang thiết kế (xem phần 5 về những vấn đề nguy hiểm thường gặp phải khi việc test phải dựa trên các tài liệu của các application đã tồn tại. Nếu như có một hệ thống được kế thừa, thì phải có tài liệu thiết kế của nó. Tuy nhiên, những tài liệu này có thể không đúng với yêu cầu của khách hàng. Trong một số trường hợp, phải thực hiện ngược lại so với thiết kế để kiểm tra hệ thống, hay thực hiện exploratory testing (vấn đề này sẽ được thảo luận ở phần sau) • Black-box and gray-box Testing: Black-box and gray-box Testing được thực hiện trong tất cả bộ phận của dự án thông qua test giao diện, và được gọi là black-box. Ví dụ, nếu muốn thêm mới một người dùng vào database thì người dùng này sẽ được insert vào database thông qua giao diện người dùng, various layers—Ví dụ như database layer, phân lớp người dùng, business-logic layers— sẽ được thực hiện. Lỗi thường thể hiện qua giao diện người dùng. (chương 4 sẽ bàn kỹ hơn về black-box and gray-box testing. Tuy nhiên, trong một số trường hợp lỗi không được thể hiện qua giao diện người dùng bởi vì các lỗi này thuộc về cơ chế thông báo lỗi của phần mềm. Ví dụ, khi một application mà không thêm mới được một bản ghi vào cơ sở dữ liệu, nhưng không có thông báo trên giao diện người dùng thì lỗi này là do code vì không hiển thị thông báo lỗi trên màn hình. Khi có giao diện người dùng, hay black-box, việc test không thể test hết lỗi được. Do đó, graybox testing cũng phải được áp dụng nhằm tìm hết ra lỗi [1] Gray-box testing được nói đến trong phần 16. • Will a test harness have to be developed?. Một số phần của hệ thống chỉ có thể test được bằng công cụ test. Ví dụ, Một phép tính có thể cho phép kết hợp cùng một lúc hàng nghìn bộ dữ liệu đầu vào. Việc test này yêu cầu thiết kế test khác so với test giao diện hay black-box testing: Với số lượng đầu vào được kết hợp cùng với sự thay đổi của dữ liệu đầu vào quá lớn và không thể test bằng cách nhập nhập liệu qua giao diện người dùng. Thời gian và các vấn đề cần quan tâm, xem xét Công ty Tinh Vân – Lưu hành nội bộ Số trang : 45/78
  • 46.
    Effective Software Testing 11/4/2013 khácyêu cầu test phải sử dụng test tool để tính toán với bộ dữ liệu đầu vào lớn đó thì đầu ra của chúng là gì? Vấn đề này sẽ được nói kỹ hơn tại phần 37. • Các kiểu kỹ thuật test được sử dụng là những kiểu nào? Các kiểu kỹ thuật test function rất đa dạng và được sử dụng để test data và bộ dữ liệu đầu vào. Một kiểu kỹ thuật test có thể kiểm tra một số lượng lớn sự kết hợp các bộ dữ liệu là orthogonal array testing. Orthogonal array testing cho phép tập hợp tất cả sự kết hợp các tham số để chứng tỏ chỉ cần số lượng test case nhỏ nhất nhưng bao phủ được hết các trường hợp xảy ra.[2] Các kiểu kỹ thuật test khác giúp thu hẹp được các trường hợp xảy ra trong cùng một phân lớp tương đương bằng việc phân tích giá trị biên (xem phần 25). Sự kết hợp các kỹ thuật này cho phép giảm số lượng test case nhưng vẫn đảm bảo thống kê đầy đủ các trường hợp xảy ra khi thiết lập các bộ dữ liệu đầu vào. Kỹ thuật test khác xảy ra khi phải có sự tham ra của commercial off-the-shelf (COTS) tool. Sự pặp lại của COTS tool với giá trị tuỳ thích được code sẽ được kiểm thử. Ví dụ, nếu một COTS tool được yêu cầu để thực hiện một lệnh SQL, khi test sẽ phải chạy các kịch bản để chứng tỏ nội dung của lệnh SQL được sửa là đúng. • Should a capture/playback tool or other testing tool be used? Một capure/playback hay 1 công cụ test khác nên được sử dụng như thế nào? Khi một test tool được khai thác, sử dụng để test việc tính toán liên quan tơí yếu tố kỹ thuật hay các back-end functions khác, thì công cụ test tự động (capture/playback) sẽ là hữu ích cho GUI regression testing. Khi xác định chiến lược test yêu cầu phải xác định các phần của application được test bằng công cụ test tự động. Các phần khác không cần test bằng automated testing thì không nhất thiết áp dụng nó, nguyên nhân của vấn đề sẽ được thảo luận trong phần 36. • Which tests should be automated? Việc test tự động được thực hiện như thế nào? Người thiết kế test nên phân tích kỹ, cần thận application khi đưa ra quyết định áp dụng công cụ test tự động hay test bằng tay. Điều này giúp tránh xa, loại bỏ những chi phí không cần thiết. Vì nói chung test bằng công cụ test tự động thì chi phí thường cao hơn so với test tay. Sau đây là một số ví dụ áp dụng test tự động: o Việc test phải được thực hiện nhiều hơn một lần: Công ty Tinh Vân – Lưu hành nội bộ Số trang : 46/78
  • 47.
    Effective Software Testing 11/4/2013 Ngượclại, việc test chỉ được thực hiện một lần duy nhất thì việc sử dụng công cụ test tự động là rất lãng phí. o Việc test nhằm đánh giá các điều kiện rủi ro cao. Các nhân tố rủi ro ít thì không nhất thiết phải áp dụng công cụ test tự động. Chúng ta quan tâm tới test function nơi người dùng thực hiện các kịch bản test đặc biệt. Ví dụ, khi test, hệ thống cho phép người dùng thực hiện các hành động này (do yêu cầu của bên kinh doanh) nhưng việc test chúng không thể quan sát hết, rõ ràng bằng trực quan. Rủi ro liên quan tới các kịch bản của loại test này là thấp nếu số lượng người dùng là ít. Và khi một hành động nào đó không đơn thuần quan sát được bằng trực quan khi thiết kế test thì các rủi ro xảy ra là rất cao. o Tests thực hiện trên nền tảng, cơ sở thông thường (Test that are run on a regular basis). Ví dụ, bao gồm smoke (build verification) tests, regression tests, and mundane tests (tests đơn giản, test lặp và lặp nhiều lần). o Công việc test đó không thể thực hiện test tay. Ví dụ, Test tự động được thực hiện khi cần kết quả đầu ra của việc có 1000 người tiếp cận hệ thống trong một thời điểm. o Test với nhiều bộ dữ liệu cho cùng một hành động (data-driven tests). o Baseline tests(danh giới test) được thực hiện trên các cấu hình khác nhau. o Test với kết quả có thể đoán trước. Khi này, áp dụng công cụ test tự động sẽ mang lại chi phí hiệu quả. o Test xem sự ổn định của hệ thống đạt đến mức nào. Với functionality, implementation, và công nghệ không thay đổi thường xuyên. Mặt khác, sự bảo dưỡng của các công cụ test tự động sẽ mang lại các lợi ích nhiều hơn. • What kind of test data is needed?Các kiểu test data cần thiết là gì. Trước đây, công việc test chưa được phân chia một cách rõ rệt, chưa thể hiện vai trò quan trọng thì việc test data được thực hiện bắng cách nhập các bộ dữ liệu đầu vào. Điều quan trọng là test data được chọn lựa rất cẩn thận, nếu test data với bộ dữ liệu đầu vào không đúng hay quá đơn giản có thể dẫn đến xót các trường hợp hay lỗi sẽ xảy ra do việc test chứ không phải do chương trình. Như vậy, test data yêu cầu phải đầy đủ các trường hợp xảy ra ( test data sẽ được nói kỹ hơn trong phần 10). Công ty Tinh Vân – Lưu hành nội bộ Số trang : 47/78
  • 48.
    Effective Software Testing 11/4/2013 Việctrả lời các câu hỏi được liệt kê trong phần này sẽ giúp cho người lập kế hoạch chia nhỏ được các công việc test, quan trọng là phải quan tâm tới lịch test và chi phí giành cho test là bao nhiêu. 3.2. Sử dụng Template Test Procedure và các tiêu chuẩn thiết kế test khác. Tính lặp lại, độ chắc chắn, sự hoàn thành, template các test Procedure chuẩn nên được qui định thích hợp. Sau đây là một số ví dụ về các template test Procedure: Test Procedure Template Công ty Tinh Vân – Lưu hành nội bộ Số trang : 48/78
  • 49.
    Effective Software Testing 11/4/2013 Phươngpháp kiểm thử: Hình 21.1. Template file test case: Yếu tố đầu tiên của một file test case chuẩn được thể hiện qua hình 21.1, bao gồm: Công ty Tinh Vân – Lưu hành nội bộ Số trang : 49/78
  • 50.
    Effective Software Testing 11/4/2013 •Mã test case: Thoả thuận cách đặt ID cho test Procedure. • Tên test case: Thể hiện sự mô tả của các test case trong phần đó.. • Ngày lập file test case: Ngày bắt đầu tạo các test case. • Tên người thiết kê lên form của file test case: Họ tên của người thiết kế file test case • Người tạo các test case: Họ tên người tạo ra các test case • Mục đích test: Phác thảo mục đích test của test case đó. • Mối liên quan giữa các use case, số lượng các yêu cầu: Thể hiện đầy đủ số lượng các yêu cầu được xác nhận trong test Procedure. • Sự dự đoán, giả thiết và sự ràng buộc: Đưa ra các tiêu chuẩn hay các điều kiện tiên quyết cần có trước khi viết các test case, ví dụ như các dữ liệu đặc biệt cho các yêu cầu đặt ra là gì. Điều này sẽ được hoàn thành khi test case đó phụ thuộc vào các test case trước đó. Điều này cũng có thể được hoàn thành khi 2 test case này có xung đột nhau nếu như chúng cùng được thực hiện trong cùng một khoảng thời gian. Cần chú ý rằng điều kiện tiên quyết của các use case thường là điều kiện tiên quyết của các test case. • Phương pháp kiểm thử: Mục này này có thể bao gồm các kiểu test đã được kiểm chứng, các công cụ test tự động và test tay, sự kiểm thử, việc thực hiện và phân tích. • User Action (Inputs): Đây là kết quả mong đợi của thao tác và kết quả mong đợi này phải rõ ràng và cơ sở. Kết quả mong đợi là kết quả sau khi thực hiện các thao tác, các bước được mô tả. Đầu vào của kết quả mong đợi có thể là như nhau đối với các phần mềm khác nhau. Việc chỉ rõ trường này làm cho tài liệu rõ ràng, dễ hiểu, dễ kiểm tra. Các bứơc mô tả phải tuân theo các use case. • Kết quả mong đợi: Xác định kết quả mong đợi khi thực hiện lần lượt các thao tác được mô tả trước đó. • Thông tin theo dõi Log: Document the behavior of back-end components. Trong suốt quá trình thực hiện các thao tác, các bước trong hệ thống, sẽ được Log lại chi tiết các chức năng mà chúng được thực hiện. Quá trình ghi Log cũng được diễn tả trong file test case. • Kết quả thực tế: Trường kết quả thực tế có thể có các giá trị mặc định để mô tả kết quả thực tế nếu như test case này bị thất bại không đúng với kết quả mong đợi hay thành công. • Yêu cầu test data: Sự tham chiếu của việc thiết lập test data sẽ tạo nên các test case trong file test case. Chúng ta sẽ nghiên cứu phần 26 để biết thêm chi tiết. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 50/78
  • 51.
    Effective Software Testing 11/4/2013 Khixác định nỗ lực test, test các yêu cầu phi chức năng thường được thực hiện sau. Tuy nhiên, điều quan trọng là phải quan tâm tới test phi chức năng ngay từ khi bắt đầu dự án. Chú ý, trong phần 21.1, file test case được chia thành 5 phần, một phần giành cho test chức năng, và 4 phần còn lại giành cho test phi chức năng, bao gồm, test tính bảo mật_an toàn hệ thống, test hiệu năng, sự tương thích, tiện ích. Xem phần 41 để biết nhiều hơn về việc cần thiết của test phi chức năng. Các tiêu chuẩn của một tài liệu thiết kế test phải được thể hiện bằng tài liệu, trao đổi và buộc phải tuân theo để mọi người liên quan có được những nguyên tắc thiết kế và các thông tin về yêu cầu của khách hàng.[2]. Việc tạo ra mẫu file test case và các nguyên tắc là điều cần thiết cho việc test tay và test tự động. Các tiêu chuẩn cho file test case bao gồm các ví dụ càng chi tiết càng tốt. Mức độ chi tiết nên đơn giản khi thực hiện mô tả các thao tác. Ví dụ, Bước 1. Click chọn File menu. Bước 2. Chọn nút Open. Bước 3. Chọn một thư mục trên máy tính Phụ thuộc vào qui mô của application được test và thời gian và số tiền giành cho việc test mà qui định thời gian cho viết test case nhiều hay ít, và viết kỹ hay không kỹ các trường hợp. Một file test case chuẩn bao gồm các nguyên tắc trong việc mô tả kết quả mong đợi. Các tiêu chuẩn nên chú tâm vào nhiều câu hỏi: kết quả mong đợi sẽ được thể hiện ra màn hình như thế nào? Yêu cầu test sẽ bị loại bỏ bởi người thứ 2 thực hiện test? Khi đạt đến việc test tự động theo cái chuẩn thì các chuẩn mực đó phải dựa trên kỹ thuật Code tốt nhất như sự kết nối rõ ràng, các biến chuẩn,…Việc Code ảnh hưởng lớn đến chất lượng của phần mềm. Trong một số trường hợp, không phải kịch bản test được mô tả rõ ràng, chi tiết trong SRS hay URD. Test case của các ứng dụng khó, phức tạp như hệ thống về tài chính; đối với hệ thống phần mềm cung cấp cho lĩnh vực tài chính, đầu vào là hàng vạn các phép tính và kết quả đầu ra là khác nhau. 3.3. Việc chuyển hoá thành các test cases từ yêu cầu của khách hàng. Mục đích chính của Test chức năng đảm bảo chương trình có và thực hiện đầy dủ các chức năng theo yêu cầu của khách hàng. Test chương trình theo các kịch bản hay nói cách khác theo các case và được mô tả trong test Procedure case giúp cho việc test hiệu quả hơn. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 51/78
  • 52.
    Effective Software Testing 11/4/2013 Đểđảm bảo mục đích của test chức năng thì tester phải bám sát vào tài liệu đặc tả yêu cầu khách hàng. Thêm vào đó, phải có các test case để test hiệu năng, test tính bảo mật, và test tiện ích. Trong chương 1 đã thảo luận về một SRS chi tiết, hoàn thành và có thể thực hiện test. Tuy nhiên, trong quá trình thực hiện viết SRS thì không phải trường hợp nào cũng thực hiện tốt. Để tạo ra các kịch bản test chức năng chuẩn, các tester phải hiểu chi tiết và tính phức tạp của hệ thống. Muốn vậy, tester phải phân tích được hệ thống. Thậm chí họ phải đưa ra được luồng test để người khác nhìn vào luồng đó sẽ biết tester sẽ test như thế nào, đúng hay sai. Do đó, tester phải khảo sát hệ thống để hiểu đầy đủ về hệ thống. Nói chung, các tester phải phân tích làm cách nào để hiểu được sự chuyển đổi các phần của hệ thống, như thay đổi biến và trường thì sẽ ảnh hưởng, thay đổi đến các phần còn lại. Không nên coi nhẹ việc thay đổi yêu cầu. Ví dụ, hệ thống có tính linh động và cho phép thay đổi yêu cầu, khi này hệ thống sẽ sử dụng tập con của sự kết hợp và dao động dữ liệu đầu vào; và sự thay đổi này vẫn cho phép lưu lại một cách chính xác. Khi này, kết quả test trước đó vẫn không bị ảnh hưởng vào nó vẫn bao gồm tất cả các trường hợp xảy ra. Ví dụ, Xem xét yêu cầu sau: “ Hệ thống phải cho phép người dùng sửa tên tuỳ thích và được thể hiện trên bản ghi với trường tương ứng”. Trường tên và sự giới hạn của trường tên cũng phải được thể hiện cụ thể trong SRS. Một số bước test đảm bảo cho yêu cầu này bao gồm: 1. Kiểm tra hệ thống xem nó có cho phép người dùng sửa tên tuỳ thích trên giao diện người dùng bằng cách click vào bản ghi có trường tên đó và sửa hay không. 2. Cố gắng kết hợp kiểm tra cả trường hợp đúng và sai, tất cả các phân lớp tương đương, các giá trị biên. 3. Chạy lệnh SQL để kiểm tra việc update là đúng và được update vào 1 bảng thích hợp. Ở trên bao gồm các bước kiểm thử cơ bản. Tuy nhiên, trong một số trường hợp vẫn còn bỏ sót các tình huống của yêu cầu đưa ra. Ngoài việc test hiệu năng và test phi chức năng khác thì câu hỏi cần phải trả lời là " làm thế nào để biết được có sự thay đổi trong hệ thống khi một trường nào đó bị thay đổi?”, “giao diện người dùng, các chức năng hay các mục khác sẽ bị ảnh hưởng, còn các phần nào không bị ảnh hưởng?”. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 52/78
  • 53.
    Effective Software Testing 11/4/2013 Vídụ: • Kiểm tra chức năng tạo mới 1 đơn đặt hàng trong module đặt hàng là việc kiểm tra xem đơn đặt hàng đó có được insert vào CSDL và được thể hiện trên giao diện hay không. • Thêm một bản ghi và kiểm tra xem bản ghi đó có được lưu lại với tên đúng như khi thêm mới hay không. • Thực hiện test chức năng thêm mới và các chức năng khác có liên quan tới chức năng thêm mới đó để thấy sự ảnh hưởng của việc thêm mới đó. Tester phải phân tích và test hết các phần liên quan, bị ảnh hưởng. Khi yêu cầu không được cụ thể hoá chi tiết trong SRS, để test hiệu quả trong trường hợp này rất khó, do đó, dễ bị bỏ xót. Thực tế, hầu hết các yêu cầu không được viết thành tài liệu một cách đầy đủ, rõ ràng để có thể thấy ngay mối liên hệ giữa các yêu cầu và các chức năng. Do vậy, thường thì một test Procedure hiệu quả không được viết lên từ riêng SRS. Tài liệu thiết kế test hiệu quả không được chồng chéo lên nhau, thay vì đưa ra một quyết định phải test hiệu quả toàn bộ với nỗ lực cần là gấp đôi ( mặc dù nỗ lực thời gian gấp đôi nhưng vẫn không tránh khỏi sự thiếu sót khi test). Sẽ không hiệu quả nếu để 2 tester test cùng một chức năng nhưng trên 2 file test case khác nhau của 2 người, trừ khi điều đó là cần thiết cho việc test toàn bộ các chức năng ( Ví dụ, khi có 2 phần cùng sử dụng các bước tương tự nhau) Vấn đề quan trọng khi phân tích luồng test nhằm đảm bảo trong suốt quá trình test, việc test được diễn ra đúng theo luồng, và chương trình xử lý có đúng hay không mà không cần nỗ lực gấp đôi, tester không cần test dữ liệu không hợp lệ với kết quả mong đợi khác, vì khi này chỉ lãng phí thời gian. Nếu test theo luồng thì lập trình cũng tốn ít thời gian để sửa lỗi hơn, và tập trung vào những lỗi quan trọng. Nhóm test nên review kế hoạch test và tài liệu thiết kế test để: • Xác định các kiểu actions hay các events tương tự thường xảy ra. Việc xác định này giúp cho việc viết test Procedure được tốt hơn, do vậy, có thể tái sử dụng và kết hợp lại các actions hay events đối với các chức năng, tránh được việc tăng nỗ lực gấp đôi. • Xác định thứ tự hay sơ đồ test. Các vấn đề cần test trước thì phải được ưu tiên thực hiện test trước, như việc xác định cấu hình database, hay các yêu cầu mà kết quả mong đợi cần được kiểm soát, hay các work flow. • Tạo ra các mối liên hệ được kết hợp chặt chẽ theo luồng, các phần test cần ưu tiên test trước trong test Procedure. Sơ đồ mối liên hệ này đưa ra sự ảnh hưởng lẫn nhau của các chức năng, sơ đồ luồng test được tạo ra từ quá trình thiết kế test và làm tăng hiệu quả test. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 53/78
  • 54.
    Effective Software Testing 11/4/2013 Việcphân tích ở trên giúp nhóm test xác định trình tự test thích hợp trong tài liệu thiết kế và phát triển test. Các vấn đề khác cần quan tâm khác để tạo ra test Procedure hiệu quả là phải xác định và review các yêu cầu có độ rủi ro cao để có sự ưu tiên test và test kỹ hơn, chức năng quan trọng nhất sẽ ưu tiên test sớm hơn. Như vậy, sẽ là lãng phí thời gian đầu tư tạo ra test Procedure các chức năng rất hiếm khi người dùng sử dụng, trong khi các chức năng quan trọng lại chưa được test và test kỹ dẫn đến rủi ro cao. Cần phải xác định ưu tiên test đối với các chức năng có xác suất rủi ro cao và việc sử dụng là nhiều nhất. Phần 8 sẽ cho chúng ta biết chi tiết hơn) Để có test case hiệu quả, phải hiểu hệ thống, luồng test và các kịch bản. Vấn đề khó khăn thường xảy ra là nếu chỉ thông qua 1 tài liệu SRS thì rất khó có thể hiểu hết được sự kết nối, luồng và mối tương quan giữa các đối tượng. Suy nghĩ theo logic và quan tâm đến chi tiết các yêu cầu để hiểu được tính phức tạp của hệ thống. Test Procedure và thiết kế test sẽ bị thiếu các trường hợp nếu thiết kế test không được chi tiết trong khi test hộp đen. 3.4. SRS là tài liệu không thể không có (như tài liệu sống còn) của quá trình test (“Living" Documents) Thường thì người thiết kế test Procedure chỉ thực hiện test các case 1 hoặc 2 lần rồi thôi, do sự thay đổi yêu cầu, thiết kế, hay việc thực hiện test chỉ diễn ra 2 lần. Do áp lực công việc, các testers thường không xem lại test Procedure của họ. Các testers dựa vào trực giác và kỹ năng phân tích để viết các test case, bao quát toàn bộ các trường hợp, các chức năng quan trọng của hệ thống. Vấn đề là, nếu tài liệu SRS không còn thích hợp, nó trở nên quá lỗi thời thì công việc trước đó tạo ra các tài liệu này trở nên lãng phí. Vì vậy, vẫn đề quan trọng là phải coi SRS như tài liệu sống còn của việc test và nó tài liệu động chứ không phải không có sự thay đổi. Hầu hết các dự án phần mềm được phát triển theo kiểu lặp lại và phát triển, và tài liệu để test thường tương tự theo 1 cách. Trong vòng đời của 1 dự án phát triển, đa số là được xây dựng dựa trên 1 kế hoạch riêng. Và điều đó rất khó để người viết test Procedure giữ và thừa kế lại các test Procedure trước đó. Khi phần xây dựng đầu tiên được hoàn thành và giao lại cho phía test, thì tài liệu này phải dùng để tạo test case được. Chúng ta sẽ không thể hoàn thành việc test toàn bộ hệ thống nếu nhóm phát triển vẫn đang trong giai đoạn code hay mới chỉ code xong một số phân hệ của hệ thống đó. Trong Công ty Tinh Vân – Lưu hành nội bộ Số trang : 54/78
  • 55.
    Effective Software Testing 11/4/2013 trườnghợp này, nhóm test chỉ viết test Procedure cho các phần đã được code xong dựa vào kế hoạch đã được xây dựng trước đó, và test Procedure này không phải là tất cả các yêu cầu, thiết kế chi tiết, và tất cả kịch bản test của dự án đó. Rất ít test Procedure liệt kê được tất cả các các chức năng hay kịch bản của 1 hệ thống. Do đó, test Procedure phải được phát triển theo từng giai đoạn của phía phát triển. Và theo từng giai đoạn phát triển từ phía lập trình, test Procedure cũng dần dần được hoàn thiện. Ngoài ra, chúng còn được hoàn thiện ngay trong quá trình thực hiện test. Test Procedure cần được thảo luận hay sửa để cập nhật các thông tin mới. Ví dụ, khi yêu cầu thay đổi, tester phải test theo sự thay đổi, do đó, họ cần điều chỉnh test Procedure. Các chức năng có thể bị thay đổi hay nâng cấp trong suốt vòng đời phát triển hệ thống. Điều này ảnh hưởng tới test Procedure, và vì vậy, cần phải thiết kế lại theo chức năng mới được thay đổi đó. Khi một lỗi được phát hiện thì nó cần được phản ánh vào test Procedure. Với 1 số chức năng, việc phát hiện 1 lỗi đôi khi làm ảnh hưởng tới cả hệ thống vì luồng test sẽ không thực hiện được. Test Procedure phải phản ánh được luồng nghiệp vụ để phát hiện các lỗi trên. Khi các testers có đủ thời gian hiểu rõ hệ thống, họ sẽ test được hết các yêu cầu đặt ra. Tuy nhiên, vấn đề là công việc test sẽ chấm dứt khi nào? Để trả lời được câu hỏi đó, thì khi một kịch bản test được viết lên cần có sự đánh giá, review và có mức độ ưu tiên. Test Procedure nên được lưu lại thành các version để kiểm soát sự thay đổi của nó. 3.5. Sử dụng các Prototypes. Tài liệu Prototypes có rất nhiều mục đích. Chúng cho người dùng biết kết quả mong đợi khi thực hiện một chức năng. Chúng cho phép người dùng quay trở lại xem xét những gì được phía phát triển thiết kế. Prototypes giúp phát hiện ra sự mâu thuẫn trong các yêu cầu. Đôi khi sự mâu thuẫn này không được giải quyết nếu chúng xuất hiện ở các phần của các trang khác nhau, hoặc khi có nhiều hơn 1 lập trình tham gia code. Mặc dù yêu cầu rất khắt khe và việc kiểm tra sẽ làm giảm thiểu sự đối lập, mâu thuẫn nhưng việc thực hiện chúng cũng có giới hạn. Việc tạo ra các prototypes và thiết kế chúng giúp phát hiện ra các điều trái ngược, mâu thuẫn và thiếu xót, và đưa ra các công cụ hiệu quả giúp lập trình phát hiện ra những chỗ thiếu xót. Khi có Prototypes kiểm tra với các chức năng phức tạp cho phép đạt được cơ chế test ( ví dụ, tài liệu khai thác test…) và lọc những trường hợp tốt nhất. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 55/78
  • 56.
    Effective Software Testing 11/4/2013 Với1 prototype ra đời, nó xác định các lớp và tiếp cận dần đến tài liệu khai thác test. Prototypes giúp lọc ra những test Procedure hiệu quả ngay cả với các yêu cầu thêm vào hay thay đổi, chúng sẽ được hoàn thiện đầy đủ và chi tiết hơn. Prototypes cung cấp thêm các thông tin cho phép hoàn thiện và cải tiến test Procedure. Prototypes cung cấp chi tiết thông tin về các yêu cầu tĩnh mà tài liệu đặc tả yêu cầu khách hàng không có. Prototypes cũng giúp testers xác định các phần sử dụng công cụ test tự động. Đôi khi 1 prototype còn có thể xác định, phát hiện ra sự thiếu xót của công cụ test tự động. 3.6. 3.7. Các kỹ thuật test được sử dụng khi thiết kế kịch bản test. Như trên đã thảo luận các vấn đề quan trọng của kế hoạch test. Trong suốt giai đoạn thiết kế test Procedure, kế hoạch test ngày càng được thể hiện rõ ràng. Việt test sẽ không giải quyết hết mọi tình huống nếu thiếu kỹ thuật test. Kỹ thuật test giúp giảm số lượng test case nhưng vẫn đảm bảo hiệu quả, giảm nỗ lực test tới mức tối thiểu. Để sử dụng và áp dụng hiệu quả kỹ thuật test thì phải hiểu rõ về nó như thế nào. Có 2 loại kỹ thuật test là kỹ thuật test white-box và black-box . Sử dụng kỹ thuật test đã được chứng minh, đã từng sử dụng hiệu quả hơn là tập trung vào 1 kỹ thuật test duy nhất. Khi hệ thống yêu cầu xác định đầy đủ các test case thì chỉ một nửa chúng cần có nỗ lực thích hợp. Khi tester test theo cảm tính thì chất lượng test sẽ không tốt, khi này chưa chắc họ đã bao quát hết các tình huống của chương trình. Trong số các kỹ thuật test nhằm giảm số lượng test case test các chức năng thì kỹ thuật phân lớp tương đương, kỹ thuật biên và giao giữa các ma trận được sử dụng phổ biến. Sau đây là một vài điều đáng quan tâm về các kỹ thuật này: • Phân tích các chức năng được thảo luận chi tiết trong phần 22. Sự phân tích này liên quan tới kết quả mong đợi của chức năng đó. Và từ đó nó sinh ra test Procedure cho các chức năng đó hay các phần đặc trưng khác của hệ thống. Nếu yêu cầu đưa ra cần có chức năng x; sau đó, việc viết test case nhằm kiểm thử chức năng đó theo 1 cách thích hợp. Mà cách này được hướng dẫn trong phần 22. Sau khi xác định các chức năng cần test và các kỹ thuật test thì sẽ giảm được việc nhập nhiều dữ liệu đầu vào cho các chức năng đó. • Phân lớp tương đương xác định các miền giá trị đầu vào theo điều kiện ban đầu và kết quả mong đợi của chúng là gì. Kỹ thuật phân lớp tương đương liên quan chặt chẽ tới các Công ty Tinh Vân – Lưu hành nội bộ Số trang : 56/78
  • 57.
    Effective Software Testing 11/4/2013 tìnhhuống phổ biến và mẫu thuẫn nhau. Nếu các trường hợp là tương đương nhau, hay về bản chất là tương tự nhau thì chỉ được test 1 trường hợp, không cần test tất cả. Mặc dù sự phân lớp tương đương được thực hiện bằng trực quan tốt thì điều cần thiết vẫn phải chú ý tới các giả định để phân lớp. Xem xét các ví dụ sau để thấy được sự phân lớp tương đương đối với trường hợp biên: Trường password cho phép nhập 8 số, nếu nhập nhiều hơn là sai. Khi giá trị nhập vào nằm trong khoảng đã cho thì chúng gọi là một phân lớp tương đương. Trong trường hợp này chỉ có 2 phân lớp tương đương mà thôi. Một phân lớp nằm trong đoạn [1,8], và một phân lớp nữa nằm ngoài đoạn đó. • Phân tích hướng đi, đường dẫn được sử dụng trong việc test bản chất đường dẫn bên trong, cấu trúc bên trong và kết nối với kết quả của chúng. Nó có thể được áp dụng theo 2 mức độ. Một là dựa vào code và hai là trong giai đoạn test whitebox (unit test). Unit test nhằm sửa code của chương trình (chương 6 sẽ đi chi tiết về unit testing). Phân tích đường dẫn cũng có thể được áp dụng ở mức độ thứ 2: mức độ thuộc về chức năng hay test black-box. Mã nguồn đóng và test black – box được thực hiện ở giai đoạn system test hay user-acceptance. Thậm chí mã nguồn mở, thì test black-box vẫn được test theo yêu cầu của khách hàng. • Phân tích giá trị biên (BV) có thể hoàn thành việc phân tích đường dẫn. Test giá trị biên sử dụng phần lớn dữ liệu đầu vào là invalid. Do đó, còn gọi là test phủ định (negative testing). Điều kiện giá trị biên xác định phần lớn hiệu quả của các test case giá trị biên khi có nhiều lỗi xảy ra trong phần giá trị biên. Giá trị biên xác định 3 kiểu hay 3 lớp dữ liệu là kiểu dữ liệu trong khoảng, ngoài khoảng và giá trị biên (hay còn gọi là in-bounds, out-of-bounds, and on-bounds). Ví dụ kiểm tra 1 application, trong đó có đầu vào phải đảm bảo giá trị hơn 10 trường hợp xảy ra. o Kiểm tra 1 giá trị nằm trong khoảng giá trị là 13 (lớn hơn 10) o Kiểm tra 1 giá trị nằm ngoài khoảng giá trị là 5 (nhỏ hơn 10) o Kiểm tra giá trị Thêm giá trị trong và ngoài khoảng giá trị biên, như điểm cuối của đoạn/khoảng. Test giá trị biên sử dụng giá trị lớn nhất và nhỏ nhất, giá trị lớn hơn giá trị lớn nhất hay nhỏ hơn giá trị nhỏ nhất của đoạn, hay giá trị 0 hoặc không có giá trị nào. Ví dụ, Khi xác định giá trị đầu vào dạng số, cần quan tâm tới các câu hỏi sau: o Trường đó chỉ nhận giá trị số hay nhận cả giá trị là anphabel? Công ty Tinh Vân – Lưu hành nội bộ Số trang : 57/78
  • 58.
    Effective Software Testing 11/4/2013 oĐiều gì sẽ xảy ra nếu nhập giá trị anphabel? hệ thống có cho phép nhập không? Nếu không thì có thông báo lỗi không? o WĐiều gì sẽ xảy ra nếu giá trị nhập vào là các ký tự mà các ký tự này thuộc riêng về ứng dụng đó hay do công nghệ. Ví dụ, khi nhập các ký tự đặc biệt như dấu “&” trong ứng dụng Web (Web applications)? Khi này hệ thống có bị phá vỡ không? Hệ thống nên mặc định không cho người dùng nhập các giá trị nằm ngoài khoảng biên hoặc thay vào đó là hiển thị thông báo lỗi khi họ nhập các giá trị nằm ngoài giá trị cho phép. • Ma trận trực giao cho phép test với mức bao phủ lớn nhất, các trường hợp có thể xảy ra đều được test. Ma trận trực giao rất hữu dụng khi khối lượng dữ liệu đầu vào lớn hoặc sự kết hợp dữ liệu lớn và không thể tạo ra tất cả các test case cho mỗi trường hợp kết hợp. Để hiểu rõ về nội dung của ma trận trực giao, chúng ta nên tìm hiểu ví dụ cụ thể sau: Giả thiết có 3 tham số A, B và C. Mỗi tham số có thể nhận 3 giá trị là 1, 2 và 3. Việc test tất cả sự kết hợp của 3 tham số trên yêu cầu phải có 27 test case. Nhưng 27 test case đó có thực sự cần thiết không? Điều này là không cần thiết nếu tester nghi ngờ có lỗi xảy ra thì sẽ thiết đặt giá trị đặc biệt cho 3 tham số trên ( ví dụ, có lỗi xảy ra cho case sau: A=1, B=1, và C=1). Tuy nhiên, lỗi còn phụ thuộc vào giá trị 2 trong 3 tham số. Trong trường hợp này, lỗi có thể xảy ra ở 1 trong 3 test case (A=1, B=1, and C=1); (A=1, B=1, and C=2); và (A=1, B=1, and C=3). Trong các test case trên, nếu chỉ có giá trị của C là thay đổi thì chỉ cần 1 test case là đủ. Với giả thiết trên thì ma trận trực giao sẽ cần 9 test cases sau: Ma trận trên gọi là ma trận trực giao vì cứ 2 tham số ( A và B), (B và C) hay ( A và C) đều được kiểm tra 1 lần. Mỗi 1 test case kết hợp cảu 2 tham số trên có thể được gọi là ma Công ty Tinh Vân – Lưu hành nội bộ Số trang : 58/78
  • 59.
    Effective Software Testing 11/4/2013 trậntrực giao cảu 2 tham số, chứ không phải của 3 tham số vì không phải tất cả 3 tham số đều xảy ra sự kết hợp. Ví dụ, sự kết hợp (A=1, B=2, and C=3) sẽ không xuất hiện. Vậy, điều quan trọng ở đây là cách nào để bao phủ hết tất cả các trường hợp có thể? Người thiết kế phải chọn bộ dữ liệu mẫu nằm trong khỏang giá trị chấp nhận. Đôi khi điều này rất khó khi mối tương quan giữa các tham số là rất lớn, nhiều. Trong những trường hợp này, tester có thể thêm các mẫu ngẫu nhiên có thể. Nói chung là không thể, không khả thi và không mang lại hiệu quả khi test một hệ thống sử dụng tất cả các phép hoán vị là sự kết hợp của các tham số. Do đó, điều quan trọng là sử dụng cách phân tích giá trị biên với các kỹ thuật test khác như phân lớp tương đương và ma trận trực giao để đưa ra tất cả các trường hợp test có thể và đầy đủ, chính xác. 3.8. Tránh sự ràng buộc và chi tiết các yếu tố dữ liệu trong các test cases. Phần trên thảo luận về sự quan trọng của các template cho test Procedure để xác định và cụ thể hoá các bước trong tài liệu này. Template nên viết theo cách chung nhất để có thể sử dụng cho nhiều dự án (tái sử dụng). Test case không nên có các dữ kiện đặc biệt vì điều này dẫn đến sự không cần thiết ở 1 dự án khác. Mối kịch bản, tất cả các bước thao tác phải được lặp lại, chỉ thay đổi duy nhất là bộ dự liệu đầu vào và kết quả mong đợi. Ví dụ về sự không cần thiết trong template test Procedure như sau: xem xét URL liên quan tới các test case trong test Procedure ra sao? Nếu URL thay đổi thì nó phải được sửa trong tất cả các test cases, và điều này rất mất thời gian và xảy ra lỗi. Để test Procedure có thể sử dụng lại một cách dễ dàng, các dữ liệu đầu vào đặc biệt và kết quả mong đợi liên quan nên cho vào tài liệu riêng biệt. Các kịch bản test dữ liệu đặc biệt nên cho ra các sheet tách rời hay các file riêng nên phải viết các test case riêng. Các kịch bản test này có thể attach theo test Procedure với các dữ liệu đưa ra cụ thể. Khi xuất phát từ dữ liệu cụ thể, dữ liệu này phải được lấy từ kho dữ liệu mà nó được tham chiếu đến và mang tính ràng buộc. Điều này đảm bảo test Procedure được tái sử dụng và tránh được những khó khăn gặp phải vớicác kịch bản đặc biệt. Mục 3.7.1 đưa ra các ví dụ đơn giản về sự tách rời các kịch bản test trong việc kiểm tra các ID và password của người dùng khi test chức năng log on hệ thống. Khi này, việc kiểm tra log on hệ thống của người dùng có thể sử dụng lại các test case của các dự án trước. Chú ý việc sử dụng lại file tách rời nên có cột “kết quả thực tế” của Công ty Tinh Vân – Lưu hành nội bộ Số trang : 59/78
  • 60.
    Effective Software Testing 11/4/2013 dựán test sau đó (cột này không được hiển thị trong mục 3.7.1). Do đó, testers phải diễn tả kết quả mong đợi trong khi test mà không cần dựa vào dự án trước. Mục 3.7.1. Ví dụ về bảng kịch bản test 2 chiều. Kịch bản test được mô tả trong mục 3.7.1 là test Procedure tách rời mà mục đích của nó là có hiệu quả cao. Giữ lại dữ liệu test trong các bảng dữ liệu 2 chiều hoặc trong database, được tham chiếu trong test Procedure chính sẽ cho phép giữ lại test Procedure dễ dàng và hiệu quả hơn. Test Procedure với các yếu tố dữ liệu được giữ lại ngoài tài liệu chính sẽ giúp ích rất nhiều trong test tự động và có thể thiết lập như là nền tảng cho các tài liệu lần sau. Cả test Procedure hướng dẫn và tự động, các yếu tố dữ liệu nên được tách thàh các kịch bản khác nhau, sử dụng các biến số thay cho giá trị code cứng, và điều này được thảo luận trong chương 8. 3.9. Áp dụng Exploratory Testing (test qua toàn bộ chương trình). Như đã bàn luận phần trên, Khi hoàn thành và chi tiết hoá được các yêu cầu sẽ xác định được các mối quan hệ và phụ thuộc trong các môi trường phát triển. Thường thì 1 tester phải sử dụng kỹ năng phân tích của họ để xác định tính phức tạp của ứng dụng. Đôi khi cần có exploratory testing để có kiến thức vững vàng, cần thiết cho thiết kế test hiệu quả. Exploratory testing hữu dụng nhất khi kiến thức về hệ thống còn mơ hồ. Ví dụ với các đặc tả chức năng không đầy đủ, rõ ràng hoặc khi không đủ thời gian để nghiên cứu kỹ thiết kế chi tiết và tài liệu khác để test thì Exploratory tests rất hữu ích. Exploratory tests làm tăng cường khả năng test. Exploratory testing xác định các điều kiện test dựa trên các mục tiêu lặp lại. Vấn đề sớm được tìm ra trong exploratory testing là giúp tập trung trực tiếp vào nỗ lực test sau đó. Ví dụ, nếu sự tích hợp hệ thống ban đầu chỉ ra rằng có 1 phần của hệ thống có khá nhiều lỗi, còn các phần còn lại khá ổn thì sẽ tập trung test lại dựa trên thông tin phản hồi này. Phần test và xác định ra lỗi trong suốt quá trình exploratory testing nên được đánh giá để xác định sự tương quan với các phần phức tạp của phần mềm. Không giống với quá trình test được sự cân nhắc kỹ càng và có kế hoạch, exploratory tests không được xác định trước hay thực hiện hoàn toàn theo kế hoạch. Tất cả nỗ lực test mong muốn exploratory testing được test trước hay test thêm, kể cả việc test dựa trên yêu cầu chi tiết nhất hay yêu cầu đó chỉ trên lý thuyết (không được tài liệu hoá). Khi tester thực hiện test, phát hiện ra lỗi và cố gắng tạo lại và phân tích chúng, exloratory testing chắc chắn đưa ra nguyên nhân của vấn đề này. Thêm vào đó, trong suốt quá trình tìm kiếm lỗi, mối liên quan của Công ty Tinh Vân – Lưu hành nội bộ Số trang : 60/78
  • 61.
    Effective Software Testing 11/4/2013 củalỗi tới các phần khác của ứng dụng được phát hiện. Điều này thường yêu cầu thực hiện các bước kiểm tra các giá trị ngoài giá trị biên theo các kịch bản đã được tạo ra. Một vấn đề khác của exploratory testing khi tester phải xác định các ngưỡng (giá trị lớn nhất và nhỏ nhất) của các tính năng đặc biệt. Xem xét ví dụ sau: Có một yêu cầu như sau: “ Trường đó phải cho phép tạo ra danh sách các quyền lựa chọn” . Dựa vào danh sách dữ liệu để xác định quyền lựa chọn (“pick-list items") và giới hạn các quyền đó, câu hỏi đầu tiên của testers là “Có bao nhiêu quyền được lựa chọn?”. Trong ví dụ này, câu hỏi trên thường bị bỏ qua trong suốt giai đoạn lấy yêu cầu của khách hàng (thậm chí vấn đề còn bị bỏ qua trong quá trình walk-throughs và kiểm thử) Tester nghiên cứu sự tồn tại của yêu cầu và hỏi phía phát triển nhưng câu trả lời không phải lúc nào cũng đáp ứng được vì nhiều khi chính khách hàng cũng mơ hồ về yêu cầu của họ. Điều cần thiết cho tester để viết test cases và thực hiện test là xác định có bao nhiêu quyền lựa chọn trong trường cho phép. Khi tester thêm quyền thì hệ thống bắt đầu suy biến hoặc để đơn giản thì hệ thống không cho phép người dùng thêm mới quyền khác. Testers phải xác định số lượng quyền giới hạn. Sau khi kiểm thử với quyền được chấp nhận thì testers khẳng định được tất cả các quyền còn lại. Tester tiêp tục test mối liên hệ giữa các trường (và các quyền lựa chọn giữa chúng), điều này được mô tả trong phần 3.3. Exploratory tests không được lập kế hoạch trước vì chúng được kiểm soát theo trường hợp case-by-case. Tuy nhiên, viết tài liệu cho exploratory tests có thể thực hiện trước hay sau khi test đều được. Thực hiện test hồi qui đối với trường hợp này (test hồi qui (regression testing) được bàn tới trong phần sau) Exploratory testing chiếm khá nhiều nỗ lực test: Nó làm tăng việc test chức năng, và được thảo luận trong phần 3.3. Khi sử dụng exploratory testing, phạm vi test thường không xác định hay đo lường được và các chức năng quan trọng có thể bị bỏ xót. Điều quan trọng là các test case về test các chức năng cần được tăng lên với sự hiểu biết sâu về các chức năng này trong suốt quá trình exploratory testing, và coi tài liệu này như là "living documents" đã được thảo luận trong phần 3.4. Để có thể test hiệu quả nhất thì cần có sự kết hợp giữa kế hoạch test hoàn hảo, chiến lược test tốt với các test cases đầy đủ và chuẩn, kết hợp với kỹ năng phân tích các chức năng Công ty Tinh Vân – Lưu hành nội bộ Số trang : 61/78
  • 62.
    Effective Software Testing 11/4/2013 vàsử dụng các kỹ thuật test thích hợp như kỹ thuật phân lớp tương đương, kỹ thuật test biên và ma trận trực giao (đã được thảo luận trong phần 3.5), và sau đó là tăng việc test exploratory testing có cơ sở. Vì không có đủ thời gian để viết tài liệu cho tất cả các kịch bản test, sự thay đổi và kết hợp của các tài liệu này. Exploratory testing là kỹ thuật test quan trọng, nó đảm bảo độ bao phủ các tình huống trong 1 chu kỳ test. 4. CÔNG CỤ TEST TỰ ĐỘNG. Công cụ test tự động có thể làm công việc test hiệu quả hơn vì quản lý được kết quả mong đợi, công cụ test tự động được hiểu và tương thích với thiết kế hệ thống được chọn. Điều quan trọng là công cụ test này cũng cho kết quả hợp với trường hợp test thủ công. Có rất nhiều loại công cụ test tự động khác nhau cho các giai đoạn phát triển, bao gồm the highly touted capture/playback testing tools. Công cụ test được xác định sau khi nghiên cứu và đánh giá nhưng đôi khi không tìm được một công cụ nào thích hợp 1 cách hoàn toàn cho 1 dự án. Trong trường hợp này, về phương diện thương mại thì có những tool có thể áp dụng vào test được nhưng nó lại thừa tính năng mà dự án cần thiết nên giá cả rất đắt. Như vậy, cần tìm 1 tool khác thích hợp. Việc xây dựng và chọn lựa 1 tool phù hợp được uỷ quyền cho người thích hợp; đặc biệt đối với phần đặc biệt của phần mềm, hay những phần có rủi ro cao hoặc những phần không test được bằng tool cũ. Trong trường hợp này, đặc biệt khi đầu tư khoản tiền lớn vào test tool thì cần có sự quan tâm của tất cả mọi người trong công ty. Một tool được chọn hay xây dựng phải thích hợp với công nghệ được chọn và thích hợp với ngân quỹ của công ty, cũng như thời gian nghiên cứu nó phải nằm trong giới hạn cho phép. Tiêu chuẩn đánh giá được thiết lập và tính khả thi của tool đó được đánh giá và kiểm tra trên các chuẩn đó. Từ đó mới ra quyết định mua hay không. Việc đánh giá và đưa ra lựa chọn 1 tool xác định để test dự án càng được đưa ra sớm càng tốt, vì khi này tránh được sự thay đổi chi phí của dự án sau này. 4.1. Các loại testing tools Trong khi các test tool chức năng (còn được gọi là "capture/playback tools") được chào bàn rất nhiều thì điều quan trọng phải có được kiến thức về các tools khác nhau để chọn được 1 tool hỗ trợ được việc test phù hợp với dự án. Trong bảng 31.1 cho chúng cái nhìn tổng quan về các tools hỗ trợ các giai đoạn khác nhau của dự án. Mặc dù có rất nhiều tool khác nhau, như tool theo dõi lỗi (defect-tracking tools) và tool quản lý cấu hình Công ty Tinh Vân – Lưu hành nội bộ Số trang : 62/78
  • 63.
    Effective Software Testing 11/4/2013 (configuration-management)và chúng có thể sử dụng trong hầu hết các dự án phần mềm, nhưng trong bảng 31.1 cũng chỉ đưa ra các tools tiêu biểu. Tất cả các tools được đưa ra trong bảng này rất có giá trị trong việc cải thiện chu trình test. Tuy nhiên, trước khi công ty đi đến quyết định mua 1 tool nào đó thì người được uỷ quyền phân tích tool đó phải kiểm tra tool đó kỹ nhằm xác định được tool tốt nhất cho quá trình test. Ưu nhược điểm của 1 tool được kiểm tra qua việc so sánh các kết quả mà nó mang lại với mục tiêu cần chọn 1 tool. Từ đó đánh giá tiềm năng thực hiện và chỉ đạo người phân tích lợi ích và chi phí (cost/benefit). Trước khi mua 1 tool thì phải chắc rằng nó hỗ trợ hoạt động thiết kế, kỹ thuật phần mềm. Quá trình đánh giá 1 testing tool được mô tả trong phần 34. Bảng 31.1. Test Tools Công ty Tinh Vân – Lưu hành nội bộ Số trang : 63/78
  • 64.
    Effective Software Testing Côngty Tinh Vân – Lưu hành nội bộ 11/4/2013 Số trang : 64/78
  • 65.
    Effective Software Testing 11/4/2013 Dướiđây là một vài điểm mấu chốt về các tools khác nhau: • Người nghĩ ra Test-procedure. Một tool quản lý các yêu cầu có thể đi đôi với một người nghĩ ra các test procedures. Tool quản lý yêu cầu được sử dụng để lấy các thông tin yêu cầu của khách hàng. Sau đó, đến giai đoạn tạo ra các test procedures. Người này tạo ra các test procedures dựa vào cách thức thống kê, thuật toán và kinh nghiệm. Trong khi việc tạo ra các test procedures nhờ việc thống kê thì tool sẽ chọn cấu trúc và giá trị đầu vào trong trường hợp thống kê ngẫu nhiên, hoặc đưa ra sơ lược các thức sử dụng phần mềm khi test. Thông thường người thiết kế ra test procedures thực hiện các thao tác, dữ liệu, logic, sự kiện với tool này. Mỗi 1 hoạt động trên nhằm tìm ra các lỗi khác nhau của phần mềm. Trong trường hợp tạo ra các test-procedure nhờ vào kinh nghiệm, tool này sẽ sử dụng các thông tin được cung cấp bởi testers. Các lỗi tester tìm được trong quá khứ sẽ là đầu vào của tool này (Tool này sử dụng các lỗi trong quá khứ để tạo ra các test procedures). • Người phân tích code và công cụ viết code. Việc đo lường mức độ bao phủ của code đảm bảo cho nhóm phát triển và nhóm test nhìn thấu được sự việc, vấn đề để thực hiện viết code và test hiệu quả. Tool để làm được điều này có thể xác định được độ phức tạp của thiết kế, đo lường số lượng test tích hợp được test và không được test. Tool khác đo lường độ phức tạp của độ bao phủ test là sự phân đoạn, chia nhánh và các mức độ điều kiện khác. Mức độ bao phủ của test phụ thuộc từng phần mềm cụ thể. • Công cụ tìm ra sự thiếu hụt bộ nhớ. Các tool tìm ra sự thiếu hụt của bộ nhớ được sử dụng trong các mục đích đặc biệt: Kiểm tra xem phần mềm đó dùng tài nguyên bộ nhớ có phù hợp không. Bộ nhờ liên quan tới nhiều lỗi của chương trình, bao gồm việc thực hiện các vấn đề đặt ra. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 65/78
  • 66.
    Effective Software Testing 11/4/2013 •Công cụ đo lường các tiện ích. Test tiện ích là test phạm vi rộng lớn của chương trình, bao gồm test về thiết kế giao diện, thiết kế đồ hoạ, nhân tố con người, dân tộc học, tâm lý học… Test tiện ích nhằm mang lại sự thoải mái, thuận tiện mà các đặc tính, tính năng của giao diện phần mềm mang lại cho người sử dụng. Do vậy, việc test giao diện phải được test thủ công của con người. Tuy nhiên, vẫn có một số tool test tự động có thể hỗ trợ quá trình này. • Test-data. Test dữ liệu hỗ trợ quá trình test thông qua tool test dữ liệu. Có nhiều tool test hỗ trợ việc test dữ liệu và database. Muốn Test dữ liệu thì phải vào được database. Và điều này thực hiện được thông qua việc thiết đặt vai trò để có thể thực hiện test chức năng, load testing, or performance and stress testing. • Công cụ quản lý test. Công cụ quản lý test hỗ trợ lập kế hoạch test, việc quản lý và phân tích toàn bộ diện mạo chu kỳ test. Một vài tool quản lý test như Rational's Test Studio. Tool này quản lý bằng cách kết hợp với việc quản lý các yêu cầu, quản lý cấu hình và tool theo dõi lỗi. • Công cụ test Web Tính phổ biến của các ứng dụng Web là hoạt động theo mô client server hoặc môi trường Web. Test Cũng khá phức tạp khi xác định nỗ lực cho test Web. Testers không chỉ test trên 1 môi trường mà còn phải test trên nhiều môi trường khác. Cấu trúc Client-server liên quan tới 3 đối tượng tách rời là server, client, và network. Inter-platform. Sự kết nối giữa chúng có thể gây lên lỗi. Do đó, quá trình test phải bao quát hết được sự thực hiện của server và network, sự thực hiện của toàn bộ hệ thống cũng như các chức năng liên quan. Nhiều công cụ test Web cho phép giám sát, đo lường, test và đoán toàn bộ chương trình. • Tool test GUI (capture/playback tools). Trên thị trường có rất nhiều tool test GUI. Các tool này thường gồm chức năng recordand-playback, chức năng cho phép testers tạo ra (record), sửa và chạy (playback) công việc test tự động trong nhiều môi trường. Các tools này record các đối tượng GUI hay mức độ “widget” (không phải mức độ ảnh bitmap). Thao tác record chụp lại các thao tác trên bàn phím mà testers nhập vào, tự động tạo ra các scripts trên nền tảng ngôn ngữ lập trình bậc cao. Việc record này là chương trình được đề cập đến như 1 kịch bản test. Tuy nhiên, nếu chỉ sử dụng chức năng capture và playback thì mới chỉ sử dụng 1 phần 10 chức năng của tool. Để có kết quả tốt nhất khi thực hiện chức năng capture/playback, Công ty Tinh Vân – Lưu hành nội bộ Số trang : 66/78
  • 67.
    Effective Software Testing 11/4/2013 testersnên tận dụng ngôn ngữ kịch bản đã được xây dựng của tool đó. Xem phần 36 sẽ cho chúng ta biết nhiều hơn rằng tại sao không chỉ sử dụng mỗi chức năng capture/playback. Kịch bản record phải do người thiết kế ra nó sửa lại để có thể tái sử dụng và duy trì kịch bản này trong các procedures. Kết quả của các scripts cho ra các baseline test. Các script có thể được chạy lại trong nhiều phần mềm sau đó để so sánh kết quả của các baseline. Một testing tool cung cấp khả năng record và thường kèm theo đó là công cụ so sánh. Sự so sánh này là so sánh giữa kết quả đầu ra thực tế với kết quả mong đợi và log lại kết quả so sánh đó. Tool có thể so sánh giữa các điểm ảnh với nhau (pixel-by-pixel), giữa các ký tự với nhau (character-by-character), hay các đặc tính với nhau (property-by-property), và điều này phụ thuộc loại so sánh mà test cần thực hiện. Tool này sẽ tự động xác định sự khác nhau giữa kết quả mong đợi và kết quả thực tế. Ví dụ, Rational Robot và Mercury's Winrunner có thể ghi lại kết quả xác thực của việc test là pass và mô tả kết quả pass trong phần màu xanh lá cây trên màn hình và kết quả fail thì được mô tả bằng màu đỏ. • Load, performance, and stress testing tools . Performance-testing tools Cho phép testers xem xét thời gian trả về và khả năng load dữ liệu của một hệ thống hay ứng dụng. Các Tools này có thể được lập trình chạy trên nhiều máy clients một lúc để đo lường thời gian trả về của hệ thống client-server khi có nhiều người cùng truy cập hệ thống cùng một thời điểm. Stress testing liên quan tới việc chạy máy client với rất nhiều kịch bản để xác định xem hệ thống có bị sụp không và khi nào thì bị sụp. • Công cụ chuyên dụng Các kiểu ứng dụng và các cấu trúc ứng dụng khác nhau sẽ cần các công cụ test chuyên dụng cho từng phần kiến trúc đặc biệt. Ví dụ, Web application cần test Web đó không có đường link bị hỏng, không link được và test tính bảo mật của Web servers. 4.2. Xây dựng 1 tool thay cho việc mua một tool. Giả định nhóm test sẽ thực hiện test tự động 40% trong việc test dự án bằng công cụ capture/playback tool. Khi này, để test tự động hiệu quả cần yêu cầu nhóm phát triển hỗ trợ về code để test thuận lợi hơn. Nhóm test cần quan tâm tới việc xây dựng 1 tool test tự động mới để làm nổi bật chức năng capture/playback của tool đó. Sự không tương thích của 1 tool là nguyên nhân dẫn đến test không đầy đủ các trường hợp của chương trình. Đôi khi 1 ứng dụng không thích hợp với việc sử dụng tool để test Công ty Tinh Vân – Lưu hành nội bộ Số trang : 67/78
  • 68.
    Effective Software Testing 11/4/2013 vìkhông có tool nào thích hợp cho việc test nó hoặc để thực hiện chức năng capture/playback quá phức tạp và mất nhiều thời gian. Như vậy, việc mua hay xây dựng 1 tool do người quản lý quyết định, và nó còn phụ thuộc vào ngân quỹ và nguồn lực được phê duyệt. Quá trình dẫn đến quyết định mua tool cần được đánh giá cẩn thận. Những ý kiến tán thành hay phản đối cần được cân nhắc kỹ. Việc xây dựng 1 tool đơn giản thì rất dễ dàng và rẻ hơn là đi mua, nhưng nếu xây dựng không thành công, xây dựng lên 1 tool lộn xộn thì tính ra lại đắt bằng hoặc thậm chí đắt hơn là bỏ tiền ra mua • Tính không tương thích của các hệ thống. Nếu như không có 1 tool nào hiện tại đang có trên thị trường thích hợp với các hệ thống khác nhau đang chạy thì nên xây dựng 1 tool riêng, theo yêu cầu của mình. • Tính không tương thích của ứng dụng. Một ứng dụng test có thể chứa 1 yếu tố là có tester biết về chức năng capture/playback của các tools trên thị trường. Nhưng nếu tool đó không được sử dụng lại trong các phần mềm sau đó thì tiền bỏ ra mua nó là lãng phí. Việc tái swr dụng nó thông qua việc có thể tái sử lại các scripts. • Sự cần thiết của công cụ test chuyên dụng. Để test đạt hiệu quả nhất thì các scipts phải là đại diện nhất. Công việc test phải được phát triển để làm tăng khả năng test GUI. Nếu như quyết định là xây dựng 1 tool thì các vấn đề quan trọng cần quan tâm là: − Xác định nguồn lực, ngân quỹ, và thời gian cần thiết cho việc xây dựng tool đó. − Sự phê duyệt của người quản lý về các yếu tố trên. − Coi sự phát triển 1 tool như nỗ lực phát triển 1 phần mềm. − Quản lý mã nguồn của tool trong việc kiểm soát phiên bản của hệ thống. Nếu không kiểm soát được nó thì không dễ dàng đồng bộ hoá phần mềm và ngừng các chức năng một cách thích hợp. − Coi việc phát triển 1 tool như mục đích chính. Khi việc phát triển 1 tool không được coi như 1 dự án thì ít khi nó được phát triển tốt. • Với một số phần codes sẽ được test với tool của công ty phát triển được nhằm kiểm tra chương trình có đáp ứng các yêu cầu của khách hàng không. Nhược điểm của tool này là không khẳng định được kết quả fail hay không. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 68/78
  • 69.
    Effective Software Testing 11/4/2013 Quátrình xây dựng 1 tool có thể được thực hiện từ bước viết các file đơn giản hoặc ngôn ngữ kịch bản Perl đến bước tạo ra các ứng dụng phức tạp của ngôn ngữ C++. Ngôn ngữ thích hợp để xây dựng 1 tool phụ thuộc vào các thao tác cần có và các chức năng cần test. Ví dụ, nếu chức năng cần test là kiểm tra kỹ càng sự tính toán phức tạp của C++ với hàm tính toán DLL bằng việc sử dụng một vài hay toàn bộ dữ liệu đầu vào có thể, giải pháp thích hợp có thể là chương trình C++ gọi trực tiếp DLL, cung cấp sự kết hợp cần thiết để đánh giá và kiểm tra kết quả test. Thêm vào đó, việc nghiên cứu testing tool trên thị trường và xem xét việc xây dựng 1 tool thích hợp sẽ có ích rất nhiều so với việc tập hợp nhiều các phần mềm miễn phí hay cần bản quyền trên Internet. Một số phần mềm có thể nghiên cứu như DejaGNU, TETware, xUnit, và Microsoft's Web Application Stress Tool (WAST), trong khi đó, một số phần mềm không được thiết kế đặc biệt dành riêng cho việc test nhưng chúng có thể có ích trong 1 tình huống nào đó như macro-recorders, XML editors, và các tool chuyên dụng. Cuối cùng, hãng cung cấp tool lớn thường chào giá thấp với các phiên bản thấp (tính năng ít nhất) đối với các tool của họ, vì họ sợ chào giá các phiên bản cao thì kinh phí của các công ty không đáp ứng được. Ví dụ, Mercury chào bán Astra line, Rational chào bán Visual Test, và Watchfire chào bán Linkbot Personal Edition. Những versions đơn giản này có khả năng với nỗ lực việc test trong trường hợp nào đó khi ngân quỹ của 1 công ty không đủ để mua tool đắt hơn. 4.3. Ảnh hưởng của Automated Tools đến nỗ lực test Công cụ test tự động chỉ đơn thuần là một phần của giải pháp, chúng không phải là 1 giải pháp kỳ diệu nhất trong vấn đề test. Công cụ test tự động không thay thế được kỹ năng phân tích, sự quản lý test cũng như không thay thế được test thủ công. Công cụ test tự động phải được nhìn nhận như 1 sự nổi bật hơn so với quá trình test thủ công. Với ý tưởng trên, công cụ test tự động được trông đợi hỗ trợ test thủ công quá nhiều. Một số người có quan niệm rằng công cụ test tự động không thể thực hiện mọi thứ từ khi có kế hoạch test đến khi thực hiện test nếu không có test thủ công. Một số người có quan niệm sai lầm nữa là coi test tool sẽ thực hiện test được tất các yêu cầu của khách hàng, không phân biệt các thông số của các môi trường khác nhau như về ngôn ngữ lập trình khác nhau… Tuy nhiên, nhân tố môi trường được đặt ra để xác định giới hạn test thủ công và test tự động. Có một số giả thiết không đúng khi cho rằng sử dụng công cụ test tự động sẽ giảm nỗ lực và thời gian test. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 69/78
  • 70.
    Effective Software Testing 11/4/2013 Thỉnhthoảng, sự cố gắng sử dụng test tự động sẽ bị thất bại bởi nó là phi hiện thực, không thể thực hiện được hay chọn nhầm tool. Danh sách các yếu tố sau sẽ chấn chỉnh lại các quan điểm sai lệch ở trên về testing tool và giúp tránh chọn nhầm tool test: • Nhiều tools được yêu cầu. Nói chung, chỉ 1 tool thì không thể đáp ứng test hết các yêu cầu của tất cả các phần mềm của 1 công test, trừ khi các phần mềm của công ty đó có cùng 1 kiểu hệ thống hay 1 kiểu ứng dụng. Điều này là 1 trong các nguyên nhân giải thích tại sao cần nhiều tool để đáp ứng nhiều công nghệ khác nhau. Ví dụ, nhiều tool được thừa nhận kiểm soát được giao diện người dùng. Nó có thể tương thích với ngôn ngữ chính được dùng để phát triển ứng dụng, nhưng vẫn không thể biết nó có tương thích với tất cả các ngôn ngữ hay không trừ khi hãng cung cấp khẳng định là tool đó tương thích với tất cả các ngôn ngữ. Phần 34 sẽ thảo luận việc đánh giá và mua 1 tool thích hợp cho môi trường phát triển phần mềm. • Nỗ lực test không giảm. Động cơ thúc đẩy đầu tiên khi muốn sử dụng 1 tool test tự động là giảm nỗ lực test. Kinh nghiệm chỉ ra rằng, để áp dụng được tool vào thực tế công việc test cần có sự nỗ lực nghiên cứu và học về công cụ đó. Thời gian đầu sẽ mất rất nhiều nỗ lực cho việc record các scripts và sau đó là sửa chúng để tái sử dụng lại. Và việc này tốn nhiều nỗ lực hơn so với test thủ công. Tuy nhiên, một số Test manager hay PM có thể đọc và hiểu được các tài liệu và cách thức áp dụng tool đó như thế nào nhưng khả năng áp dụng nó vào thực tế công việc của mình thì lại là vấn đề hoàn toàn khác. Điều ngạc nhiên là, khi áp dụng tool lần đầu thì nỗ lực test ban đầu sẽ bị tăng lên. Nỗ lực cần phải tính cho đến khi testers thành thạo tool đó. Người quản lý phải hiểu rằng không có 1 tool nào có thể thay thế hoàn toàn cho test thủ công. • Thời gian dự án không giảm. Một quan niệm sai về automated testing là khi áp dụng tool này cho 1 dự án mới thì ngay lập tức thời gian của dự án sẽ giảm đi. Do nỗ lực test khi áp dụng công cụ test tự động lần đầu thực tế là tăng nên thời gian của dự án cũng phải tăng theo. Một công cụ test tự động sẽ cho phép test được đầy đủ hơn các tình huống nhưng nói chung thì thời gian của dự án không thể giảm ngay lập tức được. • Automated testing dựa vào vòng đời phát triển của phần mềm. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 70/78
  • 71.
    Effective Software Testing 11/4/2013 Khimới áp dụng 1 tool ở giai đoạn đầu thì cần phân tích kỹ ứng dụng dưới góc độ test để xác định phần nào của ứng dụng có thể test tự động. Và cũng cần thiết phải quan tâm tới sự phát triển và thiết kế các procedure. Nỗ lực automated test được xem xét như 1 dự án nhỏ mà kế hoạch của nó có sự kết hợp nỗ lực của cả phía lập trình. • Yêu cầu ứng dụng phù hợp. Một phần mềm phải thích hợp để test tự động có hiệu quả khi sử dụng chức năng capture/playback. Việc test tự động không thể thực hiện cho toàn bộ chương trình nhưng cần thực hiện ở 1 phần nào đó của phần mềm do yêu cầu của phần mềm buộc phải thực hiện test tự động mà không test thủ công được. • Không nên thực hiện test toàn bộ bằng công cụ test tự động. Như đã nói ở phần yêu cầu trên, automated testing là công cụ tối ưu hơn test thủ công nhưng nó không thay thế được test thủ công. Điều quan trọng là phân tích được khi nào và cái gì thì test tự động, còn lại là test thủ công. Một số trường hợp test không thực hiện test tự động được như kiểm tra chức năng in của chương trình. Testers có thể tự động gửi tài liệu đến máy in, khi này hiển thị 1 thông báo là “in thành công”, nhưng testers phải kiểm tra kết quả bằng cách xem máy in có thực sự in ra tài liệu mà mình mong muốn không (nếu in ra thì còn phải kiểm tra xem các thông số in và các thiết lập trang in có đúng mong muốn không, dữ liệu có bị mất hay không…). Sau đó, kiểm tra nội dung dữ liệu trên giấy in ra bằng thị giác…. • Một test tool không cho phép thực hiện test kết hợp của tất cả các trường hợp. Một suy nghĩ sai lầm phổ biến cho rằng khi sử dụng test tool thì có thể test tự động 100% các yêu cầu đặt ra, có thể thực hiện được vô số các lần hoán vị và kết hợp vô số các tình huống khi test cũng như các thao tác của người dùng. Như vậy sẽ không đủ thời gian để làm được tất cả các điều đó. Thậm chí, về mặt lý thuyết có thể thực hiện việc kết hợp và hoán vị như trên thì nhóm test cũng không đủ thời gian và nguồn lực để thực hiện test tự động 100% toàn bộ chương trình. • Trị giá toàn bộ tool không chỉ tính mỗi giá phải trả cho nó, mà còn nhiều hơn nhiều. Khi áp dụng 1 tool không chỉ chịu giá mua tool đó mà còn bao gồm cả chi phí đào tạo, chi phí phát triển scripts tự động, và chi phí bảo trì. • "Out-of-the-box" automation is not efficient. Để bán được sản phẩm, nhiều hãng cung cấp tool thổi phồng cách sử dụng của tool đó, rằng tool này rất dễ sử dụng…Họ không cần chú ý tới thời gian, nỗ lực học tool khi một công ty mua nó. Họ nói rằng, với tool của họ, việc record thật đơn giản đối với testers, và Công ty Tinh Vân – Lưu hành nội bộ Số trang : 71/78
  • 72.
    Effective Software Testing 11/4/2013 sauđó việc tạo ra các scripts cũng vậy, rất đơn giản khi muốn played back. Nhưng để test hoàn hảo thì thật chẳng đơn giản chút nào. Nói chung, để tạo ra các scripts test không hề đơn giản chút nào, trong suốt quá trình record, các scipts này phải sửa và việc sửa phải tiến hành thủ công bằng tay và người tạo các scripts. Điều quan trọng khi viết scripts là viết sao cho thật rõ ràng, thiết thực để kiểm tra được; ngoài ra còn phải viết sao để sau này có thể tái sử dụng nó trong các phần mềm sau. • Training. Đôi khi 1 tester chỉ có thể biết cách sử dụng tool đó đủ để thực hiện test một số trường hợp thôi vì họ không được đào tạo về tool đó, nên không thể biết hết các hỗ trợ, chức năng của nó. Khi đưa 1 tool vào sử dụng test 1 dự án mới, điều sai lầm quan trọng đã không tính đến thời gian training cách sử dụng tool trong thời gian dự án và không quan tâm tới các mốc quan trọng (milestones). Do vậy, trong suốt quá trình test từ đầu đến cuối dự án, việc training tool không được tiến hành trước và sớm nên khó có thể áp dụng chúng thành công trong dự án. Nếu việc training được tiến hành sớm sẽ đảm bảo áp dụng tool vào ngay khi bắt đầu test. Khi này các vấn đề của tool cần giải quyết cũng sớm được phát hiện ra và giải quyết sớm. Theo cách này, khả năng áp dụng test tool được thực hiện ngay từ đầu dự án. Đôi khi việc training về tool ngay từ đầu dự án cũng là quá muộn. Ví dụ, chỉ thực hiện chức năng capture/playback của test tool thì các scripts phải tạo lại, như vậy rất lãng phí nỗ lực. Nếu như testers được đào tạo sớm và nhiều hơn về test tool thì họ sẽ sử dụng thành thạo và có khi không phải tạo lại scripts mà có thể tái sử dụng lại scripts của dự án trước. • Testing tools có thể xâm nhập. Một số test tool có thể xấm nhập vào phần mềm cần test, để chúng hoạt động tốt cần phải chèn vào mã đặc biệt vào phần mềm để tích hợp phần mềm với test tool. Khi này phía lập trình sẽ không thoải mái vì để làm được điều trên thì họ phải thêm code. Họ sợ điều này vì nếu làm vậy rất có thể phần mềm hoạt động không đúng cách hoặc khi phải sửa code sẽ rất phức tạp. Để tránh nhiều xung đột, mâu thuẫn có thể xảy ra, testers lên cùng với phía phát triển chọn ra 1 test tool. Nếu test tool cần phải thêm code (không phải tool nào cũng cần thêm code), developers cần được biết trước. Để một lần nữa đảm bảo cho developers không gặp vấn đề khó khăn cũng như phức tạp thì công ty cần yêu cầu phía cung cấp tool phải đưa ra kinh nghiệm sử dụng tool và được thể hiện bằng tài liệu. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 72/78
  • 73.
    Effective Software Testing 11/4/2013 •Testing tools có thể không ổn định. Testing tool có thể không ổn định với tất cả công nghệ. Ví dụ, với 1 công nghệ nào đó thì tool này không thực hiện thao tác lưu lại các thao tác, baselines không được lưu lại hay tool này không cho kết quả như mong muốn. Nếu có nhiều thưòi gian thì cần nghiên cứu xem tool đó có các vấn đề gì hay xảy ra hay nó có back-up được các thao tác hay không (repository). Testing tools bản thân nó cũng là 1 phần mềm phức tạp, do vậy, nó cũng có lỗi và có thể gây trở ngại với nỗ lực test. Chính vì vậy, phải yêu cầu nhà cung cấp sửa lại. Tất cả các yếu tố trên khiến nỗ lực test tăng lên trong suốt quá trinh test. • Công cụ tự động có thể làm mất đi cách nhìn nhận mục tiêu test cần đạt được là gì. Thường thì khi 1 công cụ test tự động được sử dụng lần đầu tiên cho 1 chương trình phần mềm, cần nhiều thời gian cho việc tạo scripts hơn là thời gian test thật sự. Các testers có thể rất hăm hở tạo các scripts test rất phức tạp, do vậy, có thể làm mất mục tiêu thực sự cần đạt được khi test. Họ luôn phải nhớ trong đầu rằng các scripts là 1 phần nỗ lực test, nhưng không thế được chúng. Không phải mọi thứ có thể hay nên tự động. Như đã nói ở các phần trước, việc đánh giá các phần thích hợp với test tự động là rất quan trọng. Khi lên kế hoạch test tự động, điều quan trọng là phải xác định rõ ràng sự phân chia trách nhiệm. Không cần thiết phải cả nhóm test tham gia tạo các scripts mà chỉ cần 1 vài người. Việc tạo các scripts phải căn cứ vào sự phát triển phần mềm. 4.4. Tập trung vào những gì mà công ty cho là cần thiết Bất kỳ ai tham gia nhóm test sẽ thường xuyên đỗi mặt với câu hỏi sau: “ Test tool nào là tốt nhất trên thị trường?” Người dùng sẽ có những phản ứng với các quan điểm khác nhau trên diễn đàn testing. Một người dùng có kinh nghiệm nhất về 1 tool cụ thể nào đó sẽ có quan điểm rằng tool họ đang dùng là tốt nhất. Tuy nhiên, câu trả lời tốt nhất cho câu hỏi trên là “điều đó còn phụ thuộc”. Tool tốt nhất còn phụ thuộc vào công ty và môi trường thiết kế hệ thống cũng như môi trường test, phương pháp test và nỗ lực dành cho test tự động. Những điều sau sẽ hỗ trợ cho việc chọn 1 testing tool. • Xác định loại công cụ vòng đời test cần thiết. Nếu như vai trò tự động hoá cần nỗ lực lớn của công ty thì công ty sẽ đặt ra câu hỏi: Công ty muốn tự động hoá để hoàn thành cái gì?. Xác định kết quả mong đợi của quá trình tự động hoá test để từ đó quản lý được các kết quả mong đợi (điều này đã được thảo luận trong phần 33). Công ty Tinh Vân – Lưu hành nội bộ Số trang : 73/78
  • 74.
    Effective Software Testing 11/4/2013 Đôikhi người quản lý test sẽ chỉ dẫn để tìm ra 1 tool phù hợp với yêu cầu của công ty. Khi này, TM (test manager) sẽ quan tâm tới môi trường thiết kế hệ thống và các yếu tố cần thiết khác của công ty để đưa ra 1 loạt danh sách các tiêu chuẩn đánh giá tool. Ví dụ, môi trường thiết kế hệ thống như thế nào? Công nghệ phát triển phần mềm công ty đang sử dụng? Việc trả lời những câu hỏi này là 1 phần trong quá trình chọn lựa tool. TM cũng tìm ra các tool hỗ trợ cho 1 dự án đặc biệt mà họ đang làm, như 1 dự án Web yêu cầu 1 tool test Web riêng. Chúng ta không nên giới hạn các tiêu chuẩn chọn 1 testing tool cho 1 dự án riêng lẻ vì có khi tool này chỉ thích hợp cho 1 dự án tức thời, và sau đó nó bị bỏ đi. Khi đã quyết định chọn 1 loại testing tool, các tiêu chuẩn có thể được đưa ra nhiều hơn. Ví dụ, nếu 1 tool được sử dụng nhiều lần cho công ty. testers phải chắc chắn rằng nó có khả năng chạy được với nhiều hệ thống, ngôn ngữ lập trình và các khía cạnh khác về môi trường kỹ thuật của công ty. Testers phải xem xét môi trường thiết kế hệ thống bằng cách đưa ra các câu hỏi và các mối quan tâm đặc biệt như đã được trình bày trong chương này và các tài liệu tìm thấy. • Xác định các kiến trúc hệ thống khác nhau. Trong suốt quá trình khảo sát môi trường thiết kế hệ thống, testers phải xác định được cấu trúc ứng dụng kỹ thuật, bao gồm middle ware (lớp tác nghiệp, thường thuật ngữ này hay dùng khi lập trình mô hình 3 lớp, lớp 1 presentation là lớp giao diện, lớp 2 là lớp nghiệp vụ, lớp 3 là lớp database), database và các hệ thống thường được sử dụng nhất trong công ty hoặc những dự án đặc trưng. Họ cũng nên xác định ngôn ngữ phát triển GUI của mỗi ứng dụng. Thêm vào đó, testers cũng cần hiểu chi tiết về thiết kế cấu trúc ảnh hưởng như thế nào tới việc thực hiện các yêu cầu của khách hàng. Việc xem xét thực hiện 1 yêu cầu phổ biến, bao gồm thực hiện yêu cầu đó dưới điều kiện heavy loads, cơ chế bảo mật phức tạp, sự đo lường khả năng và độ tin cậy của hệ thống một cách tốt nhất. Tiêu chuẩn chọn lựa đặc biệt liên quan tới nỗ lực sẽ phụ thuộc yêu cầu hệ thống thích hợp của ứng dụng khi test. Nếu không thể sử dụng 1 testing tool cho tất cả các dự án hay ứng dụng thì có thể thiết lập các tiêu chuẩn chọn lựa liên quan tới các ứng dụng quan trọng dưới vai trò test. • Xác định chọn 1 hay nhiêu tool. Khi chọn 1 tool thì tool đó phải đáp ứng các tiêu chuẩn đề ra. Như đã nói ở phần 32, nói chung 1 tool không thể thoả mãn tất các yêu cầu của 1 công ty. Một tool luôn thay đổi và Công ty Tinh Vân – Lưu hành nội bộ Số trang : 74/78
  • 75.
    Effective Software Testing 11/4/2013 pháttriển, mức độ bao quát của testing tool đối với các yêu cầu của hệ thống ngày càng mở rộng và chúng luôn được cải tiến để đáp ứng các yêu cầu mong đợi. Rút cuộc, 1 tool chỉ lý tưởng cho việc test GUI, tool khác có thể cover khối lượng công việc test lớn và tool thứ 3 hiệu quả trong việc test các tiện ích. Nhiều tool phụ thuộc vào các giai đoạn test và tính khả thi của chúng cần được xem xét và tính đến. Một tool không thể thích ứng với tất cả các phần mềm hay ngôn ngữ lập trình. Ví dụ, khi test trên máy Client chạy hệ điều hành LINUX kết nối với máy chủ của IBM sử dụng 3270 sessions và máy Java client. Khi này rất khó tìm được 1 tool chạy được cả hệ điều hành LINUX, Java, và 3270 thiết bị đầu cuối. • Dưới khía cạnh test thì hiểu cách quản lý dữ liệu bằng các ứng dụng như thế nào. Nhóm test phải hiểu cách quản lý dữ liệu bởi các ứng dụng và xác định cách thức testing tool hỗ trợ việc kiểm tra dữ liệu như thế nào. Mục đích đầu tiên của hầu hết các ứng dụng là chuyển đổi dữ liệu thành các thông tin mang ý nghĩa và thể hiện chúng trên giao diện người dùng hay các form text. Nhóm test phải hiểu việc chuyển đổi dữ liệu được thực hiện bằng các ứng dụng như thế nào để có chiến lược test đúng với việc kiểm tra sự chuyển đổi dữ liệu. • Review các thông báo trợ giúp trên màn hình. Khi 1 ứng dụng hay 1 version của ứng dụng đang hoạt động, nhóm test có thể gặp thông báo có sự cố gì đó xảy ra được hiện trên màn hình. Các thông báo này thường là những thông báo lỗi do người dùng nhập liệu. Nếu có 1 version mới, nhóm test tập trung vào test các báo cáo thường xuyên xuất hiện, bao gồm việc xác định các tool hỗ trợ. • Hiểu rõ các loại test. Khi 1 dự án được chia thành nhiều giai đoạn, thì điều cần thiết là chọn 1 kiểu test test. Chiến lược test nên xác định kiểu tesễtm nó là regression testing, stress hay volume testing, usability testing. Câu hỏi giúp xác định kiểu test phù hợp là: chức năng quan trọng nhất cần test test bằng tool là gì? Tool sẽ được sử dụng chính để test stress testing? Có một vài testing tool chuyên dụng trong việc phân tích toàn bộ mã nguồn mở. Chúng xác định tất cả các đường dẫn mã nguồn mở có thể phải test. Điều này có nên yêu cầu thành lập 1 dự án đặc biệt hay không? Các tool khác cần quan tâm là các tool hỗ trợ quá trình tự động và khối lượng dữ liệu load thông qua các file dữ liệu đầu vào. Một số câu hỏi khác như: Mục tiêu cần đạt được khi test dự án đó là gì? Các chức năng mong đợi là gì? • Thời gian. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 75/78
  • 76.
    Effective Software Testing 11/4/2013 Mộtđiểm khác khi chọn 1 tool là nó ảnh hưởng tới thời gian của dự án. Điều quan trọng là phải xác định đủ thời gian cần thiết cho testers học về tool. Nếu không có đủ thời gian, rủi ro nhóm test chọn 1 tool không thích hợp cho dự án, cho công ty. • Ngân quỹ cho phép. Khi đã xác định được 1 tool thích hợp là điều rất tốt nhưng điều quan trọng là ngân quĩ của công ty có đáp ứng được hay không. Công ty có thể dành nỗ lực hàng tháng để đánh giá thế mạnh của tool đó, nhưng chi phí cho nó vượt quá ngân quỹ cho phép. Thêm vào đó, ngân sách còn phải tính cho cả chi phí training cho testes sử dụng thành thạo tool. Điều quan trọng nhất testers nên nhớ là không có 1 tool nào tốt nhất cho tất cả các môi trường phần mềm. Tất cả các tool đều có cái thuận lợi và cái khó khăn với các môi trường khác nhau. Việc chọn lựa tool nào còn phụ thuộc vào môi trường thiết kế hệ thống và các yêu cầu cũng như các tiêu chuẩn đặc biệt được công ty đặt ra. 4.5. Kiểm tra tool bằng các Prototype. Đưa ra 1 loạt các hình ảnh rộng lớn về các kỹ thuật được sử dụng trong khi phát triển phần mềm. Khi này điều quan trọng là kiểm tra chức năng chỉ dẫn thích hợp của tool với phần mềm đang phát triển. Cách tốt nhất để hoàn thành việc này là có sự giải thích của hãng cung cấp tool này về sự tương thích của tool với các phần mềm được test. Tuy nhiên, điều này thường không thể thực hiện được, do vậy, khi phần mềm được test thì không được đánh giá về tính tương thích của tool. Khi có sự lựa chọn, các lập trình viên có thể tạo ra các prototypes để đánh giá các tool này. Trong suốt quá trình đánh giá, có thể phát hiện ra 1 vài chức năng khác thường của tool không tương thích với các công nghệ phát triển hiện có của phần mềm. Ví dụ, Nhóm test không thể thực hiện thao tác capture/playback hay thực hiện các chức năng quan trọng của tool. Các prototypes phải dựa vào các phần chính của hệ thống, các phần này là đại diện của công nghệ dùng phát triển phần mềm. Khả năng thực hiện của tool đặc biệt quan trọng trong test GUI vì có thể tool rất khó nhận biết các đối tượng trên giao diện. Vấn đề thường gặp khi các đối tượng là lịch, grids và spin controls được kết hợp trong nhiều ứng dụng, đặc biệt trên nền Window. Các đối tượng này được gọi duy nhất 1 lần VBXs, sau đó là OCXs, và bây giờ lại được đề cập đến như Active-X Controls trên Windows và Web interface. Chúng thường được viết bởi bên thứ 3. Ví dụ, 1 tool có khả năng nhận ra và tương thích với ngôn ngữ Visual Basic và PowerBuilder. Nhưng nếu tool này được kiểm soát bởi bên thứ 3 thì rất có thể nó không Công ty Tinh Vân – Lưu hành nội bộ Số trang : 76/78
  • 77.
    Effective Software Testing 11/4/2013 nhậnbiết được các đối tượng trên màn hình. Testers cần xác định được các đối tượng mà tool này không nhận biết được thông qua cách thức làm việc có trao đổi với nhau để test các đối tượng này theo cách thủ công. Những đối tượng không được test bằng tool có thể bị xót không được test nếu testers không đánh giá được và thực hiện cách test khác thích hợp. Các thành viên đánh giá tool cũng cần đánh giá trên nền tảng thích hợp. Thường thì việc đánh giá dựa trên nền tảng kỹ thuật nhằm đảm bảo người thiết kế có thể sử dụng các prototype để đánh giá các chức năng của tool thích hợp với công nghệ. Hơn nữa, tính dễ sử dụng, tính mềm dẻo và các đặc tính khác được thảo luận trong phần 34 là cơ sở đánh giá tốt nhất của các thành viên tham gia đánh giá cho phần mềm đó. Như vậy là không có gì có thể thay thế trong việc nhìn nhận 1 tool thông qua các prototype. Một vài hãng có thể đưa ra lời hứa, tool của họ tương thích với nhiều công nghệ Web, nhưng điều tốt nhất vẫn nên kiểm tra lại. Với công nghệ "churn" trong ngành công nghiệp phần mềm, không có hãng nào có thể tuyên bố là tool của họ thích hợp với mọi công nghệ. Công ty phải tự chọn tool mà mình thấy cần thiết. Công ty Tinh Vân – Lưu hành nội bộ Số trang : 77/78
  • 78.
    Effective Software Testing Côngty Tinh Vân – Lưu hành nội bộ 11/4/2013 Số trang : 78/78