Đề tài Web Engineering – kiểm thử ứng dụng web

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ự độn