Đề tài Báo cáo Web Engineering - Công nghệ phần mềm

BÁO CÁO NHÓM 15 – 08110CLC1 BÀI TẬP LỚN: MÔN CÔNG NGHỆ PHẦN MỀM ĐỀ TÀI: WEB ENGINEERING – KIỂM THỬ ỨNG DỤNG WEB DANH SÁCH SINH VIÊN THỰC HIỆN: Huỳnh Tấn Phát Vũ Việt Hùng Cao bá Lộc Mục Lục Lời giới thiệu. Trong thế giới điện toán ngày nay, các ứng dụng Web đã thực sự phát triển rất mạnh, nhanh. Hàng loạt công nghệ mới ra đời để đáp ứng những đòi hỏi của những người sử dụng muốn có mỗi khi họ bật trình duyệt Web của mình lên. Gần như những gì mà phần mềm truyền thống có thể làm được thì Web cũng làm được. Từ nghe nhạc, xem phim, đọc báo, cả những công việc mà trước đây chỉ có phần mềm truyền thống mới có thể thực hiện được như soạn thảo văn bản, các sản phầm chế bản văn phòng, chuyển đổi định dạng các file, hay thậm chí cả những bài toán quản lý phức tạp của các doanh nghiệp cũng có thể triển khai trên Web. Rõ ràng, Web là tương lai của điện toán hiện đại. Thế nhưng để tạo được ra những ứng dụng Web tuyệt vời như vậy thì đằng sau đó là một loạt những công đoạn, thao tác từ phân tích thiết kế, lập trình, kiểm thử, định giá. Trong đó vấn đề kiểm thử các ứng dụng Web tuy cũng có một số điểm tương đồng với kiểm thử phần mềm truyền thống nhưng nó có những điểm khác biệt rõ nét. Trong đề tài bài tập lớn này, chúng em chỉ tìm hiểu khái quát về “thế nào gọi là kiểm thử ứng dụng Web” để có 1 cái nhìn bao quát và nhìn ra sự khác biệt giữa kiểm thử Web và kiểm thử phần mềm truyền thống. Thế Nào Là Kiểm Thử 1 Ứng Dụng Web? Khái quát. Các ứng dụng Web đã được phát triển và trở thành 1 nền tảng kết nối thông tin thiết yếu trong nhiều doanh nghiệp. Các ứng dụng Web đóng vai trò quyết định của thương mại điện tử (e-commerce), trao đổi thông tin. Để có thể đạt được điều này, các ứng dụng Web cần phải có hiệu năng cao, đáng tin cậy v.v… Việc đưa ra 1 ứng dụng Web hoàn hảo cho những người đang và sẽ sử dụng ứng dụng đã trở thành 1 thử thách chính trong đảm bảo chất lượng. Kiểm thử là một trong những công việc quan trọng để có thể đánh giá chất lượng của 1 sản phẩm và đương nhiên là các ứng dụng Web cũng không phải là ngoại lệ. Các phương pháp kiểm thử thông thường và các kĩ thuật sẽ tập trung vào đánh giá các chức năng yêu cầu của ứng dụng. Tuy nhiên, không thể nào tập trung được vào hết tất cả các chức năng yêu cầu. Bởi có rất nhiều chức năng quan trọng cho người sử dụng ứng dụng như đó là: tính hiệu năng, tính dễ sử dụng, độ tin cậy, và tính bảo mật cần phải được xem xét. Những yêu cầu và mong đợi của người sử dụng, những vấn đề về nền tảng và cấu hình, mô hình nghiệp vụ, sự phát triển và chi phí cho việc kiểm thử là những vấn đề thường hay gặp phải và thay đổi liên tục đổi xuyên suốt chu trình của 1 ứng dụng Web. Vì thế, cần thiết phải phát triển 1 chiến lược hiệu quả cho việc kiểm thử mà có thể bao quát được giới hạn tổng thể rộng lớn của những yêu cầu, chức năng cho 1 ứng dụng Web qua đó có thể giúp cho việc cài đặt, hoàn thành ứng dụng cũng như tránh được các rủi ro có thể gặp. Tại Sao Phải Kiểm Thử Ứng Dụng Web Các ứng dụng Web đưa ra những thử thách mới trong việc đánh giá và kiểm thử. Các ứng dụng Web bao gồm nhiều thành phần khác nhau có thể được cung cấp bởi những nhà phát triển khác nhau. Chất lượng của 1 ứng dụng Web về cơ bản phụ thuộc vào các thành phần kể trên và khả năng tương tác giữa chúng. Kiểm thử là 1 trong những công cụ quan trọng nhất trong quá trình phát triển 1 ứng dụng Web để tạo ra những sản phầm với chất lượng cao đáp ứng được mong đợi của người dùng. Việc kiểm thử 1 cách có phương pháp và hệ thống các ứng dụng Web là một điều quan trọng, và chúng nên được quan tâm xứng đáng trong quy trình tạo ra 1 sản phẩm Web. Kiểm thử là một biện pháp ngắm vào việc tìm ra các lỗi, thiếu sót trong ứng dụng dưới góc độ kĩ thuật. Hiện nay có rất nhiều phương pháp và kĩ thuật tiên tiến, hiệu quả để kiểm thử những hệ thống phần mềm. Tuy nhiên, chúng ta không thể áp dụng 1 cách cứng nhắc những phương pháp hay kĩ thuật áp dụng cho phần mềm truyền thống lên những ứng dụng Web. Vậy vấn đề đặt ra ở đây là chúng ta cần phải linh hoạt khi áp dụng làm cho những phương pháp này phù hợp, thích ứng với việc kiểm thử các ứng dụng Web. Những kiểm thử cần có cho 1 ứng dụng Web Kiểm thử các ứng dụng Web đã vượt qua giới hạn của kiểm thử những hệ thống phần mềm truyền thống. Như chúng ta biết, 1 ứng dụng Web thường có rất nhiều nhóm người sử dụng với rất nhiều những nền tảng khác nhau (hệ điều hành, trình duyệt v.v…), điều này dẫn tới việc kiểm thử 1 ứng dụng Web cần phải có những phương pháp đặc biệt khác với phần mềm truyền thống. Thông thường, rất khó để có thể đoán trước được số lượng người sẽ sử dụng 1 ứng dụng Web là bao nhiêu. Thời gian hồi đáp lại yêu cầu của người sử dụng là 1 yếu tố then chốt trong số những yếu tố quyết định thành công của 1 ứng dụng Web trên Internet và nó cần được quan tâm và kiểm thử sớm. Những yếu tố còn lại như khả năng - giá trị sử dụng, tính bảo mật, tính tương thích với các trình duyệt, hiệu năng cũng rất quan trọng và cần được quan tâm đến sớm trong công việc kiểm thử. Chúng ta sẽ đề cập đến những giải pháp, phương thức và công cụ cho kiểm thử Web. Kinh nghiệm đúc kết từ những dự án nghiên cứu và rất nhiều các dự án trong thực tế đã góp phần hình thành những nền tảng cơ sở cho sự phát triển của các phương pháp kiểm thử ứng dụng Web. Những công việc khi kiểm thử 1 ứng dụng Web. Kiểm thử là một hoạt động để đánh giá chất lượng của 1 sản phẩm phần mềm và quan trọng là cải thiện nó bằng cách tìm ra những thiếu xót, khiếm khuyết. “Nếu chúng ta chạy 1 phần mềm mà với ý định tìm ra lỗi của nó tức là chúng ta đang nói đến việc kiểm thử” (Myers 1979). Trong hình sau, chúng ta thấy kiểm thử là 1 phần của công việc phân tích, đánh giá chất lượng. Bằng việc tìm ra các lỗi và kiểm tra chất lượng của 1 chương trình là 1 cách cơ bản để cải thiện chất lượng cho 1 phần mềm. Cấu trúc của kiểm định chất lượng phần mềm Mục đích của bất kì chương trình nào chính là xử lý thông tin. Chúng ta nói rằng “lỗi” là khi chương trình không đưa ra kết quả như mong đợi.Tức là sự khác biệt giữa kết quả thực tế và kết quả mong đợi sẽ là lỗi. Định nghĩa này ngụ ý rằng các định nghĩa yêu cầu được sử dụng như một cơ sở cho việc thử nghiệm được hoàn tất và có sẵn trước khi cài đặt và kiểm tra. Một vấn đề thường hay xảy ra trong quá trình phát triển các ứng dụng Web đó là các yêu cầu này thường không đầy đủ, tường minh và có thể thay đổi bất cứ lúc nào. Thông thường, chúng ta cần có được cái nhìn khái quát về các chức năng cơ bản mà ứng dụng Web sẽ có. “Cái nhìn khái quát” này sẽ là tầm nhìn để thực hiện phát hành lần đầu ứng dụng. Kết quả là, các chu kì nhỏ hơn của các chức năng mới được bổ sung sẽ theo sau các chu trình phát triển ban đầu này. Phương pháp tiếp cận nhanh – tập trung vào tính chất lặp và tiến hóa của 1 ứng dụng Web và vòng đời phát triển của chúng mà không hề có bất cứ 1 văn bản cụ thể nào định nghĩa về phương pháp này. Các mục tiêu, mối quan tâm và mong đợi của các bên liên quan có để hình thành cơ sở cho việc thử nghiệm. Các bên liên quan (trong công việc phát triển 1 ứng dụng Web) thường có những mong đợi, kỳ vọng khác nhau, thậm chí 1 số kỳ vọng còn có thể mơ hồ. Chính vì lý do này, mong đợi, kỳ vọng của các bên liên quan sẽ không thể thống nhất và quyết định xem 1 kết quả mà ứng dụng đưa ra có là sai sót hay không trừ khi các bên liên quan đã có 1 thỏa thuận về các yêu cầu, mong đợi cụ thể từ ứng dụng và những mong đợi, yêu cầu này ở dạng có thể kiểm thử. Để hỗ trợ giúp cho những “kiểm thử viên” có thể có được cái nhìn sâu sắc và thấu đáo những mong đợi, kỳ vọng của người sử dụng thì những kiểm thử viên này cần được tham gia càng sớm càng tốt vào công việc xác định và định nghĩa các yêu cầu. Các Đặc Điểm Về Chất Lượng Của Một Ứng Dụng Web. Một người sử dụng không chỉ mong đợi chương trình của họ sẽ vận hành 1 cách ổn định, đúng đắn mà họ còn yêu cầu một số chức năng nào đó phải luôn sẵn sàng trên 24 giờ trong 1 ngày và 7 ngày trong tuần. Hơn nữa, người sử dụng còn mong đợi ở chương trình những ưu điểm sau: tính dễ sử dụng, độ tin cậy, tốc độ, tương thích với các hệ thống khác nhau và tương thích với các phiên bản trong tương lai. Còn với 1 ứng dụng Web, thì những yêu cầu về chất lượng bao gồm: Yêu cầu về chức năng: sự hiện diện của các chức năng đáp ứng những yêu cầu được xác định. Các yêu cầu cần có nữa là tính phù hợp, chính xác, khả năng tương tác, tuân thủ và bảo mật. Yêu cầu về Độ tin cậy: khả năng của 1 ứng dụng để duy trì sự hiệu quả của nó trong 1 điều kiện cụ thể và trong 1 khoảng thời gian xác định. Yêu cầu về Khả năng sử dụng: tính dễ sử dụng và hiệu quả của 1 ứng dụng. Vấn đề này có thể được thẩm định bởi 1 nhóm người dùng giả định. Yêu cầu về Hiệu quả: tỷ lệ giữa mức độ hiệu quả của 1 ứng dụng và các tài nguyên mà nó sử dụng trong các điều kiện cụ thể. Các yêu cầu về chất lượng đóng một vai trò thiết yếu khi thử nghiệm các ứng dụng Web. Mặc dù nhìn chung thì chúng tương tự như những yêu cầu về chất lượng cho các hệ thống phần mềm truyền thống, tuy nhiên chúng có thể có mức độ đòi hỏi cao hơn về chiều sâu. Do ý nghĩa quan trọng của các đặc điểm về chất lượng và sự khác biệt ở cách mà chúng được kiểm thử, nhiều phương pháp để kiểm thử 1 ứng dụng Web tập trung vào một vài các đặc điểm. Tuy nhiên tất cả các đặc điểm đều quan trọng đối với 1 ứng dụng Web. Và công việc kiểm thử phải đảm bảo những yêu cầu này được cài đặt thành công. Các Mục Tiêu Của Việc Kiểm Thử Một ứng dụng được kiểm thử không có nghĩa là ứng dụng đó được cải thiện về chất lượng trừ khi các lỗi và khiếm quyết được phát hiện và loại bỏ. Mục tiêu chính của kiểm thử chính là phát hiện lỗi thay vì chứng minh rằng 1 ứng dụng không có lỗi. Kiểm thử phần mềm không thể chứng minh 1 sản phẩm là không có lỗi mà sẽ làm điều ngược lại. Vì khi 1 sản phẩm sau khi thử nghiệm không bị phát hiện lỗi thì không có nghĩa là nó không có lỗi. Đơn giản là vì các lỗi chưa được phát hiện. Một số lượng lớn các đặc điểm về chất lượng cần được xem xét cùng vô vàn các giá trị đầu vào làm cho việc kiểm thử không thể được hoàn tất. Ngay cả khi kiểm thử trên diện rộng cũng không thể thực hiện được vì thông thường 1 chu trình phát triển rất ngắn. Do đó, không thể tránh khỏi những thiếu sót khi kiểm thử và các lỗi tiềm tàng sẽ không bị phát hiện. Đây là lý do tại sao việc kiểm thử thường có xu hướng tiếp cận với các lỗi. Những phần của ứng dụng mà có khả năng các chứa lỗi nghiêm trọng cần được tập trung thử nghiệm đầu tiên. Exploring the sources of risk may point to defects more directly than basing tests mainlyon requirements (Bach 1999). As a consequence, a further important test objective is to bring that risk to light, not simply to demonstrate conformance to stated requirements. Một kiểm thử là thành công khi nếu nó tìm ra các lỗi, đồng thời thêm vào đó là các thông tin về trạng thái của ứng dụng được thu thập qua mỗi lần kiểm thử. Trái lại, kiểm thử không thành công tức là kiểm thử không tìm ra lỗi mà chỉ làm lãng phí thời gian. Điều này hoàn toàn chính xác đối với các ứng dụng Web – nơi việc kiểm thử luôn bị hạn chế bởi yếu tố thời gian và nguồn lực. Chính vì vậy, các lỗi nghiêm trọng nên được phát hiện càng sớm càng tốt để giảm thiểu chi phí cho những đầu tư không cần thiết vào việc tìm kiếm và tháo gỡ các sai sót với từng giai đoạn phát triển. Những lỗi sảy ra trong giai đoạn đầu phát triển thường rất khó tháo gỡ trong các giai đoạn sau bởi bởi việc loại bỏ chúng thường gây nhiều xáo trộn và yêu cầu rất nhiều yếu tố để có thể đối phó với những lỗi này. Vì thế cần phải tiến hành kiểm thử càng sớm càng tốt, ngay từ lúc bắt đầu dự án. Kiểm thử 1 cách có hiệu quả và hiệu quả của kiểm thử đóng vai trò rất quan trọng. Tóm lại, chúng ta có thể nói đối với công việc kiểm thử nói chung và kiểm thử Web nói riêng, là cần phát hiện ra nhiều sai sót nhất có thể, đặc biệt là các lỗi nghiêm trọng, với chi phí thấp nhất có thể, thực hiện trong một thời gian ngắn nhất có thể, càng sớm càng tốt. Các Mức Độ Kiểm Thử According to the distinct development phases in which we can produce testable results, we identify test levels to facilitate testing of these results. Tùy thuộc vào các giai đoạn phát triển khác nhau, có thể đưa ra những kết quả kiểm thử cho mỗi giai đoạn. Cần xác định rõ mức độ kiểm thử để tạo điều kiện thực hiện mỗi mức độ một cách hiệu quả: Kiểm thử đơn vị (Unit Test): kiểm thử những đơn vị nhỏ nhất có thể kiểm thử độc lập với nhau (các lớp, các trang Web v.v..). Kiểm thử đơn vị thường được thực hiện bởi chính các lập trình viên trong suốt quá trình cài đặt. Kiểm thử độ tích hợp: đánh giá sự tương tác giữa những đơn vị riêng biệt và đã được kiểm thử đơn vị trước đó khi chúng kết hợp với nhau. Kiểm thử độ tích hợp có thể được thực hiện bởi người kiểm thử (tester), lập trình viên hay có sự kết hợp của cả 2. Kiểm thử hệ thống: kiểm tra sự hoàn thiện, tích hợp của hệ thống. Thông thường, kiểm thử hệ thống được thực hiện bởi 1 nhóm chuyên gia. Kiểm thử để nghiệm thu: đánh giá hệ thống cùng sự phối hợp từ phía khách hàng trong những điều kiện gần với môi trường thực tế nhất. Kiểm thử nghiệm thu được tiến hành dựa trên những điều kiện và dữ liệu thực tế nhất. Thử nghiệm Beta: để cho những người sử dụng dùng những phiên bản đầu của sản phầm nhằm mục tiêu nhận thông tin phản hồi sớm từ họ. Thử nghiệm Beta chính là thử nghiệm chính thức (tuy nhiên không có các chiến lược kiểm thử và các trường hợp kiểm thử mà dựa vào sự sáng tạo của 1 số lượng lớn người dùng tiềm năng). Một nguy cơ khi tiến hành các mức độ kiểm thử theo trình tự của các giai đoạn phát triển dự án là các thiếu xót khi không hiểu đúng mong đợi của người sử dụng được phát hiện ra ở những giai đoạn cuối dẫn đến việc xử lý chúng rất tốn kém. Để giảm thiểu nguy cơ này, kiểm thử cần được tích hợp thành một phần của công việc xây dựng sản phẩm. Một quá trình phát triển liên tục và lặp đi lặp lại sẽ làm giảm thiểu nguy cơ này vì những phần nhỏ của hệ thống được kiểm thử trên tất cả các mức độ do đó các lỗi có thể được tìm thấy trước khi chúng ảnh hưởng sâu đến những bộ phận khác trong hệ thống. This means that the sequence of test levels described above does not always dictate the temporal sequence for Web project testing but may be performed several times, e.g. once for each incrementation of functionality. Điều này có nghĩa là trình tự của các mức độ kiểm thử được mô tả ở trên không phải luôn luôn tuân theo trình tự thời gian và có thể được thực hiện nhiều lần. Vai Trò Của Người Kiểm Thử Để tìm ra nhiều lỗi nhất có thể thì yêu cầu người kiểm thử cần có tư tưởng của “kẻ phá hoại”. Trong các dự án Web, cần tập trung vào kiểm thử đơn vị được thực hiện bởi các lập trình viên còn các kiểm thử bổ sung cần được tiến hành bởi chính các phòng ban kinh doanh của khách hàng. Vì vấn đề chất lượng luôn bao gồm nhiều yếu tố, ta không nên tách rời 2 công việc phát triển và kiểm thử và sẽ có thêm nhiều khó khăn nếu cản trở sự hợp tác giữa đội ngũ kiểm thử và đội ngũ phát triển. Sau tất cả, mục tiêu chính là tìm ra các lỗi và những lỗi đó sẽ được gỡ bỏ bởi lập trình viên. Để đạt được điều này, thì một người kiểm thử cần xác định rằng: “Một người kiểm thử giỏi không phải là người tìm ra nhiều lỗi nhất hay người làm cho các lập trình viên lúng túng nhất mà là làm cho nhiều lỗi được sửa nhất”. Vì các nhóm trong 1 dự án Web thường hoạt động ở nhiều lĩnh vực khác nhau và thời gian hợp tác giữa các nhóm thường ngắn nên vì thế nên rất khó khăn cho các thành viên trong nhóm để thiết lập độ tin tưởng cần thiết để hợp tác chặt chẽ giữa những lập trình viên là người kiểm thử. II. Những Phương Pháp Kĩ Thuật Khi Kiểm Thử 1 Ứng Dụng Web Khi thử nghiệm các ứng dụng web, về cơ bản chúng ta có thể áp dụng tất cả các phương pháp và kỹ thuật thường được sử dụng trong thử nghiệm phần mềm truyền thống (xem Myers 1979, 1990 Beizer, Kaner et al 1999,. Jorgensen 2002). Chú ý đến những chi tiết cụ thể của các ứng dụng web vào tài khoản, một số trong những phương pháp thử nghiệm và kỹ thuật sẽ được suy nghĩ đến, hoặc thích nghi và mở rộng (ví dụ, " Những yếu tố nào có ảnh hưởng để được đưa vào tài khoản khi thử nghiệm khả năng tương thích với các trình duyệt Web khác nhau ? "). Ngoài ra, chúng ta sẽ cần các phương pháp thử nghiệm và kỹ thuật mới để che tất cả những đặc điểm mà không có trong thử nghiệm phần mềm truyền thống (ví dụ, thử nghiệm của các cấu trúc siêu văn bản). Bản tóm tắt được hiển thị trong bảng 7-1 tương ứng với sơ đồ thử nghiệm được giới thiệu trong phần 7.5 và có cấu trúc bằng kích thước đối tượng kiểm tra và kích thước các ký tự tiêu biểu. Bảng (xem thêm Ramler et al 2002) tóm tắt mẫu của những phương pháp, kỹ thuật, và công cụ ứng dụng lớp cho thử nghiệm ứng dụng web trong văn học (ví dụ, 2003 Ash, Dustin et al. Năm 2002, Nguyễn et al. 2003, Pressman 2005, Splaine và Jaskiel 2001). Nó cho thấy đại diện tiêu biểu của phương pháp thử nghiệm và các kỹ thuật như là một cơ sở thu xếp một phương pháp của công ty, dự án cụ thể và hộp công cụ. Bảng 7-1 Các phương pháp, kỹ thuật, và các lớp công cụ để thử nghiệm các ứng dụng Web Chức năng Nội dung và cấu trúc Cơ sở hạ tầng và môi trường Chức năng Phù hợp Xem lại và kiểm tra, kiểm tra hướng phát triển Bảng kiểm mục, kiểm tra từ vụng, phong cách hướng dẫn, xem lại Độ chính xác Thu hút / chạy lại kiểm tra hướng phát triển Phân tích tĩnh, kiểm thủ ngữ phát, xem lại. Phân tích tĩnh, kiểm thử ngữ pháp Thao tác giữa các phần Trình duyệt chéo và nền tảng Kiểm tra khả năng tương thích Kiểm thử in ấn, bảng chỉ mục, xem lại, thử tình tương thích Trình duyệt chéo và nền tảng Kiểm tra khả năng tương thích Sự hài lòng Thử nghiệm tương hợp Phong cách hướng dẫn, Kiểm tra khả năng tương thích Bảng kiểm mục, Tương thích thử nghiệm, Phong cách hướng dẫn viên, Xem lại Trình duyệt chéo và nền tảng Kiểm tra khả năng tương thích Bảo mật Phân tích chung tấn công, xét và thanh tra Phân tích chung tấn công, cưỡng-lỗi thử nghiệm, đạo đức hacking Độ tin cậy Đáo hạn Độ bền thử nghiệm Độ bền thử ghiệm Dung sai Buộc-lỗi thử nghiệm , Căng thẳng thử nghiệm Buộc-lỗi thử nghiệm, Nguồn lực thử nghiệm thấp, Căng thẳng thử nghiệm Tính có thể khôi phục Buộc lỗi thử nghiệm Fail-over thử nghiệm Fail-over thử nghiệm, Buộc-lỗi thử nghiệm, Nguồn lực thử nghiệm thấp Khả năng sử dụng Tính dễ hiểu Có thể học được Tìm tòi đánh giá Dễ phân tích để đọc, Có thể học được Có thể học được Nghiên cứu khả năng sử dụng, Tìm tòi đánh giá Tính thực thi Nghiên cứu khả năng sử dụng, Tìm tòi đánh giá Tìm tòi đánh giá Sức hấp dẫn Công khai thử nghiệm Tính hiệu quả Thời gian Hành vi Kiểm thử tải và căng thẳng, Giám sát Kiểm thử tải và căng thẳng, Giám sát Tài nguyên sử dụng Độ bền thử nghiệm Tải thử nghiệm Độ bền thử nghiệm Giám sát Thử nghiệm liên kết (link) Liên kết bên trong một cấu trúc siêu văn mà điểm đến không tồn tại một nút (các trang web, hình ảnh,vv) hoặc mấu neo được gọi là liên kết hỏng và đại diện nổi tiếng và thường xuyên xảy ra sai sót trong các ứng dụng web. Để kiểm tra cho chính xác của các trang liên kết (link kiểm tra), tất cả các liên kết được hệ thống theo sau bắt đầu trên một trang bắt đầu, và sau đó được nhóm trong một đồ thị liên kết ( bản đồ trang web). Khi chạy một thói quen kiểm tra liên kết, người ta thường thấy các liên kết không chỉ là điểm đến không tồn tại trang, nhưng cũng có các trang không được interlinked với những người khác hoặc cái gọi là các trang mồ côi. Những trang mồ côi có thể được đạt đến thông qua một liên kết, nhưng không có một liên kết đến cấu trúc siêu văn bản. Để đơn giản cho người sử dụng nó không rõ ràng nơi để đi tới, để họ rời bỏ trang web. Các trang là thiết kế lý tưởng để họ kết thúc bằng một đề nghị của nơi người đọc có thể đi tiếp theo. Ngoài ra, khi vượt qua các liên kết, người ta thường có thể tìm thấy dữ liệu bổ sung để cung cấp chỉ dẫn tiềm năng lỗi, ví dụ, độ sâu và bề rộng của các cơ cấu chuyển hướng, khoảng cách giữa hai tramg liên quan đến các trang, được đo bằng số lượng các liên kết, hoặc lần tải của các trang. Thử nghiệm trình duyệt Một số lượng lớn các trình duyệt web khác nhau có thể được sử dụng như là các khách hàng cho các ứng dụng web. Tùy thuộc vào nhà sản xuất (ví dụ, Microsoft, Mozilla, Netscape, Opera), hoặc phiên bản (ví dụ, trình duyệt Internet Explorer 5.0, 5,01, 5,5, 6,0), hoặc hệ điều hành (ví dụ, trình duyệt Internet Explorer cho Windows XP/2000, Windows 98/ME/NT, hoặc Macintosh), hoặc các thiết bị phần cứng (ví dụ như, màn hình có độ phân giải và độ sâu màu), hoặc cấu hình (ví dụ, kích hoạt các cookie, script ngôn ngữ, stylesheets), mỗi trình duyệt web cho thấy một hành vi khác nhau. Tiêu chuẩn như những quy định của W3C thường không thực hiện đầy đủ và "nâng cao" do không tương thích nhà cung cấp, mở rộng số liệu thống kê cụ thể và trình duyệt Web và cài đặt có sẵn trên mạng (ví dụ, ở Một trình duyệt Web Thử nghiệm trình duyệt cố gắng để tìm ra lỗi trong ứng dụng web do không tương thích khác nhau giữa các trình duyệt Web. Nhằm mục đích này, người ta thường định nghĩa cốt lõi của một ứng dụng web chức năng, thiết kế trường hợp thử nghiệm phù hợp, và chạy các thử nghiệm trên các hệ thống khác nhau với những phiên bản trình duyệt khác nhau. Trong những thử nghiệm này, cần hỏi một trong những câu hỏi sau đây: • Có phải các ứng dụng web của nhà nước quản lý chính xác, hoặc tiểu bang không phù hợp có thể xảy ra khi điều hướng trực tiếp đến một trang, ví dụ, bằng cách sử dụng nút "Back" của trình duyệt? • Một trang web có thể được đánh dấu trong một giao dịch, và có thể người dùng sẽ trở lại trang đó sau này mà không cần phải nhập tên người dùng và mật khẩu để đăng nhập ? • Người sử dụng có thể sử dụng các ứng dụng Web để mở đồng thời nhiều cửa sổ trong trình duyệt (một hay nhiều trường hợp của các trình duyệt Web)? • Các ứng dụng Web phản ứng như thế nào khi trình duyệt có cookie hoặc tập lệnh ngôn ngữ ngừng hoạt động? Để hạn chế số lượng kết hợp có thể có của các trình duyệt, nền tảng, cài đặt, và nhiều yếu tố ảnh hưởng đến một tập thể quản lý các trường hợp kiểm tra, các cấu hình của hiện tại hoặc tiềm năng người dùng cần phải được phân tích, ví dụ, bằng cách đánh giá các tệp tin sổ ghi và tư vấn thống kê của trình duyệt, để tìm các kết hợp phổ biến. Kiểm thử khả năng sử dụng Kiểm tra đánh giá khả năng sử dụng của các vấn đề của sử dụng các mẫu thiết kế web khác nhau, bố trí tổng thể, và sự điều hướng (xem Chương 11) của một ứng dụng web bằng một tập các đại diện người sử dụng. Trọng tâm là sự xuất hiện và khả năng sử dụng. Một thử nghiệm khả năng sử dụng chính thức thường được tiến hành trong phòng thí nghiệm thiết lập, sử dụng các phòng kính trang bị máy quay video, và một trạm thu âm. Cả hai dữ liệu định lượng và định tính được thu thập. Loại thứ hai của việc đánh giá khả năng sử dụng là một đánh giá xem xét. Một đánh giá xem xét bao gồm một hoặc nhiều chuyên gia giao diện khác áp dụng một bộ các hướng dẫn để đo khả năng sử dụng của giải pháp, xác định các khu vực để khắc phục, và cung cấp các khuyến nghị cho thay đổi thiết kế. Hệ thống đánh giá khả năng sử dụng các nguyên tắc sử dụng đó phải được theo sau bởi tất cả các nhà thiết kế giao diện người dùng chẳng hạn như công tác phòng chống lỗi, cung cấp thông tin phản hồi và nhất quán, vv Trong bối cảnh khả năng sử dụng thử nghiệm các vấn đề làm việc có thể truy cập web cho người dùng bị khuyết tật đã được điều chỉnh. Khả năng tiếp cận có nghĩa là người khuyết tật (ví dụ như thị giác, thính giác, hoặc nhận thức) có thể nhận thức, hiểu, điều hướng, và tương tác với Web. WAI (The Web Accessibility Initiative ) của W3C đã phát triển phương pháp tiếp cận để đánh giá trang web cho khả năng tiếp cận, mà cũng có liên quan đến thử nghiệm các ứng dụng web. Ngoài ra W3C còn đánh giá các nguyên tắc cung cấp dịch vụ xác nhận ( sử dụng kết hợp với hướng dẫn sử dụng và thử nghiệm người dùng của tính năng tiếp cận. Load, Stress, và Kiểm Thử Tính Liên Tục Tải thử nghiệm, bài kiểm tra căng thẳng, và thử nghiệm liên tục được dựa trên các thủ tục tương tự. Một số yêu cầu được gửi đến các ứng dụng web nhỏ hơn đồng thời kiểm tra bởi người dùng mô phỏng để đo lường phản ứng lần và thông qua. Các yêu cầu sử dụng trong các thử nghiệm này được tạo ra bởi một hoặc một vài " máy tải ". Một ứng dụng kiểm soát phân phối với các tập lệnh kiểm tra trên máy tải; nó cũng đồng bộ hóa các hoạt động thử nghiệm và thu thập các kết quả thử nghiệm. Tuy nhiên, tải thử nghiệm, bài kiểm tra căng thẳng, và thử nghiệm liên tục có các mục tiêu thử nghiệm khác nhau: • Một thử nghiệm tải xác minh hay không hệ thống sẽ đáp ứng thời gian đáp ứng các yêu cầu và các yêu cầu thông qua. Để cuối cùng này, chúng ta lần đầu tiên xác định các cấu hình tải (truy cập cái gì, vào những gì thời gian cao điểm, có bao nhiêu lượt truy cập trong phiên làm việc, có bao nhiêu giao dịch trong một phiên làm việc, vv) và pha trộn các giao dịch (có chức năng sẽ được thực hiện với những tỉ lệ phần trăm). Tiếp theo, chúng ta xác định các giá trị mục tiêu cho thời gian trả lời và thông qua (trong hoạt động bình thường và tại đỉnh điểm, cho truy cập đơn giản hay phức tạp, với mức tối thiểu, tối đa, và các giá trị trung bình). Sau đó, chúng ta chạy thử nghiệm, tạo ra khối lượng công việc với sự pha trộn giao dịch được xác định trong hồ sơ tải, và đo số lượt phản ứng và thông qua. Các kết quả được đánh giá, và tắc nghẽn tiềm năng được xác định. • Một kiểm tra xác minh sự căng thẳng hay không hệ thống phản ứng một cách kiểm soát trong " những tình huống căng thẳng ". Tình huống căng thẳng được mô phỏng bằng cách áp dụng điều kiện khắc nghiệt, chẳng hạn như không thực tế quá tải, hoặc rất nhiều biến động nạp. Thử nghiệm là nhằm tìm hiểu xem hệ thống có hay không đạt thời gian đáp ứng các yêu cầu và thông qua các yêu cầu theo căng thẳng tại bất kỳ thời điểm nào, và liệu nó đáp ứng một cách thích hợp bằng cách tạo ra một lỗi tin nhắn (ví dụ, bằng cách từ chối tất cả yêu cầu thêm ngay khi trước một định nghĩa "ngưỡng lũ" là đạt). Các ứng dụng sẽ không bị đổ vỡ khi có yêu cầu bổ sung. Một lần một tình hình căng thẳng hơn, hệ thống sẽ phục hồi nhanh nhất và có thể tiếp tục một cách bình thường. • Liên tục kiểm nghiệm có nghĩa là hệ thống được thực hiện trong một khoảng thời gian dài để khám phá những lỗi tinh vi, khó phát hiện. Trong vấn đề quản lý tài nguyên, chẳng hạn như cơ sở dữ liệu thoát kết nối hoặc “ rò rỉ bộ nhớ " là một ví dụ điển hình. Chúng xảy ra khi một hoạt động phân bổ nguồn lực (ví dụ, chính bộ nhớ, xử lý tập tin, hoặc kết nối cơ sở dữ liệu), nhưng không phát hiện ra khi nó kết thúc. Nếu chúng ta gọi các hoạt động bị lỗi trong một cuộc thử nghiệm bình thường một vài lần, chúng ta sẽ không thể phát hiện lỗi. Chỉ có liên tục thử nghiệm có thể đảm bảo rằng các hoạt động được thực thi nhiều lần hơn trong thời gian dài để cuối cùng tái tạo nút cổ chai tài nguyên gây ra bởi lỗi này, ví dụ như hết bộ nhớ. Kiểm tra tính bảo mật Tiêu chí quan trọng nhất cho 1 ứng dụng Web có lẽ là tính bảo mật. Sự cần thiết phải quản lý truy cập thông tin, để xác minh danh tính người dùng, và để mã hóa thông tin bí mật là quan trọng tối thượng. Kiểm tra bảo mật là một lĩnh vực rộng, nó không đại diện cho một kỹ thuật thử nghiệm theo nghĩa đen. Nó liên quan đến các vấn đề về đặc tính chất " bảo mật ": • Bảo mật: Ai có thể truy cập dữ liệu? Ai có thể sửa đổi và xóa dữ liệu? • Quyền hạn : Làm thế nào và ở đâu thì có quyền truy cập quản lý ? Tất cả dữ liệu phải được mã hóa ? Dữ liệu đã được mật mã như thế nào ? • Thẩm định quyền hạn: Làm thế nào để người dùng hoặc máy chủ xác thực chính mình? • Trách nhiệm : Đăng nhập như thế nào ? • Tính toàn vẹn : Thông tin được bảo vệ như thế nào để khỏi bị thay đổi trong quá trình truyền ? Khi thử nghiệm trong lĩnh vực bảo mật, điều quan trọng để tiến hành theo một lược đồ thử nghiệm hệ thống (xem phần 7.5). Tất cả các chức năng đã được kiểm nghiệm đối với chất lượng an ninh đặc tính, nghĩa là, chúng ta phải kiểm tra từng chức năng như để có hoặc không đáp ứng mỗi yêu cầu được liệt kê ở trên cơ chế bảo mật. Kiểm tra (ví dụ mật mã) cho đúng đắn vẫn còn chưa đủ. Mặc dù một thuật toán mật mã xác thực, một chức năng tìm kiếm, ví dụ : có thể hiển thị các dữ liệu bảo mật trên trang kết quả. Đây là một lỗi mà chạy thử nghiệm nên phát hiện. Thông thường, kiểm tra bảo mật không chỉ tìm thấy những khiếm khuyết do dự định nhưng không đầy đủ hoặc không đúng chức năng, mà còn do sự bổ sung nào được nêu ra hành vi không mong muốn có thể có hiệu ứng phụ không lường trước hoặc thậm chí có chứa mã độc. Không mong muốn, thêm hành vi thường được tiếp xúc bằng cách gửi dữ liệu đầu vào không ngờ đến một ứng dụng. Một số lượng lớn các thông tin về các ứng dụng bảo mật điển hình trong Web có sẵn trong Internet (ví dụ, phổ biến các lỗ hổng và được thảo luận tại một danh sách kiểm tra các vấn đề an ninh hiện có tại Test-hướng phát triển Test hướng phát triển (Beck 2002) nổi lên từ thử nghiệm đầu tiên tiếp cận được sử dụng trong Extreme lập trình, nhưng nó không nhất thiết phải cách tiếp cận dự án một cách nhanh nhẹn. Điều này có nghĩa rằng chúng ta có thể sử dụng kỹ thuật này, ngay cả trong các dự án thường. Như tên của nó, kiểm tra hướng phát triển là thử nghiệm, mà được tạo ra mã hóa trước khi làm việc. Mã mới được viết, nếu một thử nghiệm trước đó tạo ra không thành công, các nhà phát triển phải viết bài kiểm tra trước khi họ tiến hành để thực hiện. Trong cách này, việc phát triển các thiết kế (các ứng dụng) "hữu cơ" và tất cả các đơn vị đã thử nghiệm đơn vị của nó. Thiết kế tự nhiên bao gồm rất nhiều cố kết và cùng các thành phần lỏng lẻo, tạo điều kiện cho các thử nghiệm. Sau khi thử nghiệm không thành, phát triển thực hiện những gì là tuyệt đối cần thiết để thành công chạy kiểm tra càng nhanh càng tốt, mặc dù điều này có nghĩa là vi phạm một vài nguyên tắc. Một lần trong trong khi một, phát triển loại bỏ các mã trùng lặp giới thiệu trong thời gian thực hiện. Cái nhiều đơn vị thử nghiệm nhỏ có thể làm việc dò thay đổi như là nhỏ "" trong quá trình của dự án. Test-hướng phát triển có hiệu ứng tâm lý có lợi; nhà phát triển có thể tập trung ngày bước nhỏ và giữ cho mục tiêu lớn hơn ( "mã sạch mà tác phẩm") trong tâm trí. Điều này là trái ngược với các điển hình vòng tròn luẩn quẩn, nếu tăng áp lực đã để lại ít thời gian hơn để thử nghiệm, do đó ít hơn những điều được kiểm tra, sau đó bất trắc hơn dẫn đến áp lực nhiều hơn nữa. Test phát triển hướng đảm bảo rằng một nhà phát triển bị căng thẳng gia tăng hiện tự động, chỉ cần chạy thử nghiệm thường xuyên hơn. Điều này cho phép anh ta hoặc cô nhận được phản hồi trực tiếp rằng những thứ vẫn còn làm việc, làm giảm căng thẳng và lỗi xác suất. Kiểm Thử Tự Động Thử nghiệm hệ thống lớn rất nhiều lợi ích từ công cụ thực hiện và những phương pháp và kỹ thuật tự động hoá. Điều này đặc biệt đúng cho sự phát triển lặp và phát triển của các ứng dụng web, nơi một tổ chức sử dụng các công cụ có thể hỗ trợ các thử nghiệm được lặp đi lặp lại thường xuyên trong các chu kỳ phát triển ngắn và khung thời gian hẹp. Nhưng ngay cả khi phát triển hoàn thành, thay đổi cho cơ sở hạ tầng và môi trường của một ứng dụng Web thường yêu cầu thử nghiệm để được lặp lại. Lợi ích và hạn chế của thử nghiệm tự động Tự động hóa một cách đáng kể có thể làm tăng hiệu quả của thử nghiệm và, không những cho phép các loại thử nghiệm mới mà còn làm tăng phạm vi (ví dụ như các đối tượng thử nghiệm khác nhau và đặc điểm chất lượng) và chiều sâu của thử nghiệm (ví dụ như số lượng lớn và kết hợp dữ liệu đầu vào). Thử nghiệm tự động hóa mang lại các lợi ích sau đây để thử nghiệm ứng dụng Web (xem thêm Fewster và Graham 1999): • Chạy thử nghiệm hồi quy tự động trên các phiên bản mới của một ứng dụng Web cho phép phát hiện các lỗi gây ra do tác dụng phụ với chức năng không thay đổi. Những thử nghiệm hồi quy giúp bảo vệ tính năng hiện có của các ứng dụng Web thường xuyên thay đổi. • Những phương pháp thử nghiệm khác nhau và các kỹ thuật sẽ là khó khăn hoặc không thể thực hiện bằng tay. Ví dụ, thử tải và căng thẳng đòi hỏi tự động hóa và các công cụ tương ứng với mô phỏng một số lượng lớn người dùng cùng lúc. Trong cùng một cách đó là hầu như không thể kiểm tra đầy đủ tất cả các liên kết của ứng dụng rộng rãi của Web, cấu trúc siêu văn bản bằng tay được. • Tự động cho phép chạy nhiều thử nghiệm trong thời gian ít hơn và, do đó, để chạy nhiều thử nghiệm cho kết quả đáng tin hơn trong hệ thống dưới sự kiểm tra. Vì vậy, tự động hóa là một điều kiện tiên quyết cho test-hướng phát triển, như các nhà phát triển chạy thử nghiệm cho mỗi bit mã họ thực hiện để liền phát triển ứng dụng. • Ngoài ra, khả năng chạy một cách nhanh chóng thiết lập tự động của các thử nghiệm có thể giúp rút ngắn kiểm tra thực hiện thời gian và giảm thời gian để thực hiện các thử nghiệm hiện có. Tuy nhiên, mặc dù đạt được hiệu quả tiềm năng mà các thử nghiệm tự động có thể cung cấp, mong đợi về tự động hóa kiểm tra thường không thể thực hiện được cao. Thư nghiệm tự động hóa không cải thiện hiệu quả của thử nghiệm (tức là tổng số các lỗi phát hiện). Tự động hoá một thử nghiệm không làm cho nó có hiệu quả hơn chạy thử nghiệm cùng một cách thủ công. Thông thường, các thử nghiệm thủ công tìm được nhiều sai sót hơn hơn thử nghiệm tự động vì nó đếm lại các sai sót mà lần đầu tiên chạy đã tìm thấy. Nếu thử nghiệm đã được thông qua một lần, không chắc rằng một lỗi mới sẽ được phát hiện khi cùng được chạy thử nghiệm một lần nữa, trừ khi các mã được thử nghiệm là bị ảnh hưởng bởi một sự thay đổi. Hơn nữa, nếu thử nghiệm là tổ chức kém, với các thử nghiệm không hiệu quả mà khả năng tìm kiếm lỗi thấp, tự động hoá các thử nghiệm này không cung cấp bất kỳ lợi ích nào. Thay vào đó, việc tự động hóa của một quá trình thử nghiệm hỗn loạn chỉ cho kết quả hỗn loạn hơn và nhanh hơn. Kiểm tra tự động hóa là một đầu tư đáng kể. Mặc dù những công cụ cung cấp các tính năng thuận tiện để tự động thử nghiệm, hiện còn có một số lượng đáng kể nỗ lực tham gia vào việc lập kế hoạch, chuẩn bị, thực hiện, và báo cáo về các thử nghiệm tự động. Và hiện còn có một số lượng đáng kể không tham gia vào việc chạy thử nghiệm, bao gồm cả việc triển khai các cuộc thử nghiệm, xác minh kết quả, việc xử lý các cảnh báo sai, và bảo trì các cơ sở hạ tầng thực hiện thử nghiệm. Tự động thử nghiệm cũng phải được duy trì như các thử nghiệm trở nên lỗi thời hoặc phá vỡ vì những thay đổi rằng mối quan tâm giao diện người dùng, định dạng đầu ra, các API hoặc các giao thức. Ngoài ra, tổng chi phí của quyền sở hữu của các công cụ kiểm tra bao gồm không chỉ các lệ phí cấp giấy phép mà còn bổ sung các chi phí như đào tạo hoặc xử lý các vấn đề kỹ thuật từ các sản phẩm công cụ kiểm tra thường lớn và phức tạp. Các chi phí thường vượt quá tiềm năng tiết kiệm từ nhanh hơn và rẻ hơn (tự động) kiểm tra thực hiện. Vì vậy, trong khi lập luận rằng chi phí của cuộc thử nghiệm tự động đã giảm do sự giảm thử nghiệm chu trình thực hiện, trong thử nghiệm ứng dụng web lợi ích chính của tự động hóa đến từ các lợi thế được liệt kê ở trên dẫn đến cải thiện chất lượng và thời gian ngắn hơn để chu kỳ thị trường. Thậm chí nếu các chi phí phát sinh do kiểm định tự động có thể cao hơn so với các thử nghiệm thủ công, lợi ích kết quả về chất lượng và thời gian kêu gọi đầu tư. Vì thế, một chiến lược đầu tư hợp lý sử dụng công cụ để năng cao hiệu quả của thử nghiệm thủ công, nhưng không nhằm mục đích thay thế thử nghiệm thủ công bằng thử nghiệm tự động. Thử nghiệm thủ công là tốt nhất để khám phá nhũng chức năng mới, thúc đẩy sự sáng tạo, sự hiểu biết, kinh nghiệm, và tay nghề của một tester. Thử nghiệm tự động thì an toàn hiện chức năng, tìm thấy tác dụng phụ và khuyết điểm đã được tái giới thiệu, và tăng cường phạm vi và tính chính xác của thử nghiệm bằng tay. Vì vậy, không phải tất cả các thử nghiệm đã được tự động. Công cụ kiểm tra phần tự động hóa có sẵn có thể rất hữu ích và khác nhau để hỗ trợ các loại hoạt động thử nghiệm khác nhau. Công cụ thử nghiệm Thường sử dụng các công cụ hỗ trợ thử nghiệm các nhiệm vụ sau: • Kiểm tra quy hoạch và quản lý: Các công cụ này tạo thuận lợi cho việc quản lý các trường hợp kiểm tra và thử nghiệm dữ liệu, sự lựa chọn các trường hợp thử nghiệm phù hợp, và bộ sưu tập của các kết quả thử nghiệm và theo dõi lỗi. • Kiểm tra trường hợp thiết kế: Công cụ có sẵn để thiết kế các trường hợp thử nghiệm hỗ trợ các nhà phát triển trong các trường hợp thử nghiệm từ định nghĩa các yêu cầu hoặc trong việc tạo dữ liệu để thử nghiệm. • Phân tích tĩnh và phân tích động: Dụng cụ có sẵn để phân tích các ứng dụng web, ví dụ như, HTML hoặc cờ liên kết, hãy thử khám phá từ độ lệch chuẩn. • Tự động kiểm tra chạy: Dụng cụ có thể tự động chạy thử nghiệm bằng cách mô phỏng cũng như thu giữ và thực hiện lại hành vi của các thành phần hoặc người sử dụng. • Hệ thống giám sát: Công cụ có sẵn để giám sát các hệ thống hỗ trợ chúng ta trong việc phát hiện lỗi, ví dụ như hệ thống thu giữ tài nguyên, chẳng hạn như tiêu thụ bộ nhớ hoặc truy cập vào cơ sở dữ liệu. • Tổng Công việc: Dụng cụ như biên tập hoặc báo cáo rất là hữu ích Chọn công cụ thử nghiệm Xu hướng hiện nay trong công cụ thử nghiệm ứng dụng Web là kết hợp chặt chẽ cùng với sự tiến triển liên tục trang web công nghệ và quá trình phát triển hiện đại. Ngày nay, một số lượng lớn các công cụ khác nhau đều đã có sẵn. Khi lựa chọn công cụ thích hợp để thử nghiệm các ứng dụng web, chúng ta luôn luôn cần phải nghiên cứu và đánh giá lại mọi thứ. Đề án thử nghiệm được giới thiệu trong chương này có thể hỗ trợ chúng ta trong lựa chọn công cụ và xây dựng thành công một hộp công cụ cấu trúc và đầy đủ. Một cửa hàng toàn diện các tiêu chí để đánh giá công cụ kiểm tra được mô tả trong (Dustin et al 2002).. Ngoài ra, nhiều trang web luôn có một bảng tóm tắt liên tục cập nhật các công cụ để thử nghiệm các ứng dụng web (ví dụ, ở Kết Luận Các loạt ứng dụng yêu cầu chất lượng trên Web khuyến khích một sự thay đổi ngoài truyền thống tập trung vào chức năng trong việc kiểm tra và yêu cầu một cách tiếp cận để quản lý các nỗ lực của kiểm tra bên trong khung thời gian thu hẹp lại và ngân sách dựa trên cân nhắc rủi ro. Người dùng mong đợi Các ứng dụng web được liên tục có sẵn, để có thời gian trả lời ngắn, dễ sử dụng, để có một cái nhìn và cảm thấy dễ chịu, để được bảo mật cao, tương thích với các trình duyệt web của họ, cung cấp cập nhật dữ liệu và, tất nhiên, để cung cấp thực hiện đúng chức năng. Không cái nào trong các đặc điểm chất lượng trong chính nó là mới, và chúng không phải là mới trong lĩnh vực thử nghiệm. Cái gì là mới ở đây, khi phát triển ứng dụng web, sự kết hợp của chất lượng các đặc điểm có ý nghĩa quyết định cho sự thành công của một ứng dụng web. Trong phát triển phần mềm truyền thống, một số nhưng không phải tất cả các đặc điểm chất lượng là quan trọng, tùy thuộc vào lĩnh vực ứng dụng (ví dụ, các dữ liệu hướng ứng dụng, thời gian thực và nhúng hệ thống, hoặc các ứng dụng phân phối). Ngược lại, khi ứng dụng developingWeb, nó sẽ trở thành ngày càng quan trọng đối với người thử để có phương pháp và công cụ thích hợp cho chất lượng mỗi lúc xử lý đặc trưng của mình. Sự chia tách của việc phát triển một ứng dụng web từ hoạt động của nó là không có một phần còn các phương pháp tiếp cận phát triển tiến hóa, mà thay vì tập trung vào cải tiến liên tục và thường xuyên, giới thiệu những thách thức thử nghiệm mới. Các thử nghiệm nên được sử dụng lại trên nhiều máy phát triển các chu kỳ, và chúng cần được thích hợp cho việc giám sát hoạt động của một ứng dụng web. Một ứng dụng web sẽ tùy thuộc vào sự thay đổi trong quá trình phát triển và hoạt động của nó, thử nghiệm cũng cần được thích nghi. Điều này có nghĩa là ý nghĩa của các yêu cầu chất lượng đối với để tiện lợi và dễ thay đổi cho các cuộc thử nghiệm. Hệ quả hợp lý là tự động thử nghiệm trở nên ngày càng quan trọng cho các ứng dụng web, các chi phí như vậy là cao hơn chi phí ban đầu cho kiểm định tự động bằng cách tái sử dụng thường xuyên nhất là trong giai đoạn bảo trì với quy mô lớn các ứng dụng web. Phương pháp tiếp cận nhanh chóng, mà xây dựng trên lặp ngắn và thường xuyên giao hàng để cuối cùng đạt đến hội nhập liên tục, đã được chấp nhận như là một thử nghiệm tự động hóa không thể thiếu được. Tài liệu tham khảo Web Engineering - The Discipline of Systematic Development of Web Applications