Hướng dẫn kiểm tra ứng dụng web. Chúng ta thực sự thấy gì, một lỗi hay một triệu chứng? Các loại thử nghiệm ứng dụng web

Là người kiểm tra tự động, bạn phải phát hiện nhiều lỗi khác nhau mỗi ngày, ngay cả trong khuôn khổ của riêng bạn. Điều này không nói lên điều gì về năng lực của bạn hoặc công ty không đầu tư đủ nguồn lực vào việc thử nghiệm. Hầu hết các vấn đề nằm ở mã kết nối lỏng lẻo, các quy trình và tích hợp phức tạp. Ngoài ra, quá trình tích hợp liên tục đòi hỏi nhiều nỗ lực và thời gian để đảm bảo ứng dụng hoạt động chính xác trong các môi trường khác nhau. Đổi lại, với việc sử dụng các công nghệ mới trong quá trình phát triển, việc viết bài kiểm tra tự động cho các ứng dụng web trở nên phức tạp hơn.

Tất cả điều này đòi hỏi một số kinh nghiệm và thực hành.

Dưới đây là 7 thủ thuật cuộc sống được sử dụng để tự động kiểm tra trang web và điều này sẽ chứng minh cho khoản đầu tư được thực hiện vào đó.

Thực hiện các kịch bản thực

Điều rất quan trọng là phải biết kịch bản thực tế để tự động hóa trường hợp thử nghiệm một cách chính xác. Nếu có thể, bạn nên tránh chế giễu và làm mọi thứ trên một ứng dụng “trực tiếp”. Trong trường hợp này, bạn có thể tin tưởng vào kết quả của quá trình kiểm tra tự động và quá trình kiểm tra đã diễn ra như mong đợi.

Chạy autotests hàng ngày sau lần cam kết cuối cùng

Có một tình huống gấp đôi ở đây. Trên một số dự án, các cam kết được hợp nhất suốt cả ngày. Và không có cái gọi là “ngày cam kết”. Trong trường hợp này, bạn nên chọn thời điểm để chạy thử nghiệm tự động. Một mặt nó có vẻ tẻ nhạt nhưng mặt khác nó rất hữu ích cho cập nhật thường xuyên các ứng dụng. Lỗi được phát hiện ở giai đoạn đầu, khi các khu vực có vấn đề vẫn chưa bén rễ.

Giảm thời gian thực hiện kiểm thử và tăng phạm vi kiểm thử

Đôi khi điều này khó đạt được; nó đòi hỏi kinh nghiệm và kiến thức kỹ thuật nhất định. Tại sử dụng đúng phương pháp kiểm tra và sử dụng tối ưu Công cụ phần mềm Có thể, nếu không giảm thời gian chạy thử nghiệm xuống mức tối thiểu thì ít nhất hãy giảm nó bằng cách nào đó. Loại thử nghiệm cũng đóng một vai trò quan trọng: API và thử nghiệm từ đầu đến cuối nhanh hơn nhiều so với thử nghiệm giao diện người dùng.

Kiểm tra khả năng tương thích của trình duyệt và nền tảng

Môi trường trong đó các cuộc kiểm tra tự động kiểm tra một ứng dụng web phải có khả năng sửa đổi nhanh chóng để chúng tôi có thể kiểm tra chức năng của nó trên tất cả các nền tảng tiềm năng nơi ứng dụng có thể được sử dụng. Ứng dụng này cũng phải tương thích với các trình duyệt chính.

Lập báo cáo về các lỗi được phát hiện ngay từ đầu

Lỗi cần phải được ghi lại ngay khi chúng được phát hiện. Trong trường hợp này, lợi nhuận từ việc sử dụng autotests sẽ không bị mất. Thông tin về sự hiện diện của lỗi trong ứng dụng, được cung cấp ngay khi phát hiện lỗi, rất có giá trị, bởi vì cho phép bạn tiết kiệm đủ tài nguyên để sửa lỗi.

Sử dụng lại các phương pháp và tập lệnh kiểm tra

Các phương pháp kiểm thử được sử dụng lại (có nghĩa là các tập lệnh và thành phần của các lớp trong một ngôn ngữ) là cơ sở để tối ưu hóa các khoản đầu tư được thực hiện trong kiểm thử tự động. Trong trường hợp này, thời gian và công sức cần thiết để viết bài kiểm thử tự động sẽ giảm dần. Các bài kiểm tra kết quả rất linh hoạt và dễ dàng sửa đổi.

Báo cáo thường xuyên

Cuối cùng, điều quan trọng là phải trao đổi với các bên liên quan về tiến trình tự động hóa thử nghiệm, xác định các khu vực quan trọng và kế hoạch khắc phục tình trạng hiện tại. Điều này không chỉ áp dụng cho các lỗi được tìm thấy mà còn áp dụng cho quá trình viết và chạy các bài kiểm tra tự động cũng như sự tương tác của các bài kiểm tra tự động với ứng dụng đang được kiểm tra.

7 thủ thuật kiểm thử ứng dụng web tự động bạn nên biết

http://site/wp-content/uploads/2017/04/website-test-automation-150x150.jpg

Trong bài viết này chúng ta sẽ xem xét thử nghiệm trang web(ứng dụng web) bằng cách sử dụng bộ thử nghiệm. Nó khá dài nên hãy chắc chắn rằng bạn ngồi thoải mái.

Các loại thử nghiệm trang web chính (ứng dụng web)

Kiểm tra chức năng;
Kiểm tra khả năng sử dụng;
Kiểm tra giao diện;
Kiểm tra khả năng tương thích;
Kiểm tra hiệu suất và tốc độ tải trang web;
Kiểm tra an ninh.

1. Kiểm tra chức năng

Kiểm tra tất cả các liên kết

Kiểm tra các liên kết đến từ tất cả các trang đến một tên miền cụ thể.
Liên kết nội bộ.
Liên kết đến các phần tử khác nằm trong trang.
Liên kết gửi E-mail quản trị viên hoặc người dùng khác của trang web.
Kiểm tra các liên kết đến các trang bị cô lập.

Kiểm tra các biểu mẫu

Các biểu mẫu được sử dụng để lấy thông tin từ người dùng và tương tác với họ.

Những điều cần kiểm tra trong biểu mẫu:

Xác thực hoạt động chính xác trong từng trường biểu mẫu.
Giá trị trường mặc định.
Các tùy chọn tạo biểu mẫu, xóa, xem và chỉnh sửa biểu mẫu ( nếu có cái nào).

Hãy xem một ví dụ về dự án công cụ tìm kiếm mà tôi hiện đang thực hiện. Dự án có các giai đoạn đăng ký nhà quảng cáo và đối tác. Mỗi bước đăng ký khác nhau nhưng phụ thuộc vào các bước khác. Vì vậy, toàn bộ quá trình đăng ký phải được thực hiện chính xác.

Có nhiều loại xác thực khác nhau, chẳng hạn như kiểm tra email của người dùng, thông tin tài chính, v.v. Tất cả các trường có xác thực phải được kiểm tra thủ công hoặc tự động.

Kiểm tra cookie

Cookies là các tệp nhỏ được lưu trữ trên máy tính của người dùng. Chúng thường được sử dụng để hỗ trợ các phiên xác thực. Kiểm tra ứng dụng bằng cách tắt và bật cookie trong tùy chọn trình duyệt của bạn.

Kiểm tra xem Cookies có được mã hóa hay không trước khi được lưu trữ trên máy tính của bạn. Kiểm tra phiên đăng nhập và thống kê người dùng khi phiên trang web kết thúc. Kiểm tra xem việc xóa cookie có ảnh hưởng đến bảo mật ứng dụng của bạn hay không.

Kiểm tra HTML/CSS

Nếu bạn đang tối ưu hóa trang web của mình cho công cụ tìm kiếm, thì việc xác thực HTML/CSS đặc biệt quan trọng. Trước hết, hãy kiểm tra trang web để biết tính khả dụng lỗi cú pháp trong mã HTML. Kiểm tra xem trang web có thể truy cập được bởi các công cụ tìm kiếm khác nhau hay không.

Kiểm tra cơ sở dữ liệu

Sự tương tác của một ứng dụng web với cơ sở dữ liệu là rất tâm điểm. Kiểm tra tính toàn vẹn dữ liệu và thực hiện kiểm tra lỗi trang web khi chỉnh sửa, xóa, thay đổi biểu mẫu hoặc các hành động khác liên quan đến cơ sở dữ liệu.

Kiểm tra xem tất cả các truy vấn cơ sở dữ liệu có được thực thi chính xác không và dữ liệu có được truy xuất và cập nhật như mong đợi hay không.

Khi kiểm tra chức năng của trang web, bạn cần kiểm tra:

Liên kết

Liên kết nội bộ;
Liện kết ngoại;
Liên kết tới email;
Liên kết bị hỏng.

Các hình thức

Xác thực hiện trường;
Thông báo lỗi do đầu vào không chính xác;
Các trường bắt buộc và tùy chọn.

Cơ sở dữ liệu

Tính toàn vẹn của cơ sở dữ liệu cần được kiểm tra.

2. Kiểm tra khả năng sử dụng (khả năng sử dụng trang web)

Kiểm tra khả năng sử dụng là phân tích sự tương tác giữa người dùng và trang web, tìm lỗi và loại bỏ chúng.

Điều này kiểm tra:

Dễ học;
Dẫn đường;
Sự hài lòng chủ quan của người dùng;
Hình thức chung.

Kiểm tra điều hướng

Điều hướng đề cập đến phương tiện để người dùng xem các trang. Đây là các nút, khối. Và cả cách khách truy cập trang web sử dụng liên kết đến các trang khác.

Kiểm tra khả năng sử dụng:

Trang web phải dễ sử dụng;
Các hướng dẫn phải rất rõ ràng;
Kiểm tra xem các hướng dẫn được cung cấp có đạt được mục đích dự định hay không;
Menu chính phải có sẵn trên mọi trang;
Menu chính nên được xây dựng theo trình tự hợp lý.

Xác minh nội dung

Nội dung phải logic và dễ hiểu. Kiểm tra lỗi văn bản. Ứng dụng màu tối gây khó chịu cho người dùng, không cần thiết phải sử dụng chúng trong chủ đề.

Đối với nội dung và nền của trang, tốt hơn nên sử dụng các tiêu chuẩn được chấp nhận chung để màu sắc của phông chữ, khung, v.v. không gây khó chịu cho người dùng.

Nội dung phải có ý nghĩa, liên kết phải hoạt động chính xác, hình ảnh phải có kích thước phù hợp. Đây là những tiêu chuẩn cơ bản được tuân theo trong phát triển web. Nhiệm vụ của bạn là kiểm tra mọi thứ như một phần của quá trình kiểm tra giao diện người dùng.

Thông tin khác cho người dùng

Tùy chọn tìm kiếm, sơ đồ trang web, những tài liệu tham khảo vân vân. Kiểm tra xem tất cả các liên kết trong sơ đồ trang web có hoạt động không. Chức năng “Tìm kiếm trang web” sẽ giúp bạn dễ dàng tìm thấy nội dung bạn cần.

3. Kiểm tra giao diện

Bạn cần kiểm tra xem việc giao tiếp với máy chủ có được thực hiện chính xác hay không. Bạn nên kiểm tra tính tương thích của máy chủ với phần mềm, phần cứng, mạng và cơ sở dữ liệu bạn đang sử dụng.

Các giao diện chính:

Giao diện ứng dụng và máy chủ web.
Giao diện máy chủ cơ sở dữ liệu và máy chủ ứng dụng.

Nếu cơ sở dữ liệu hoặc máy chủ web trả về thông báo lỗi cho bất kỳ yêu cầu nào đến từ máy chủ ứng dụng, máy chủ ứng dụng phải nắm bắt và hiển thị nó cho người dùng.

Kiểm tra điều gì xảy ra khi người dùng làm gián đoạn một hành động. Và điều gì sẽ xảy ra khi kết nối lạiđến máy chủ trong quá trình thực hiện bất kỳ hoạt động nào.

4. Kiểm tra tính tương thích

Cần kiểm tra:

Tính tương thích của trình duyệt web;
Khả năng tương thích của hệ điều hành;
Xem trên thiêt bị di độngỒ;
Tùy chọn in ấn.

Tính tương thích của trình duyệt web

Một số ứng dụng web có thể khác nhau tùy thuộc vào loại trình duyệt của bạn. Trang web phải tương thích với cấu hình khác nhau và cài đặt của các trình duyệt khác nhau.

Bố cục trang web phải tương thích với nhiều trình duyệt. Khi sử dụng tập lệnh Java và AJAX để cung cấp chức năng giao diện người dùng, việc kiểm tra hoặc xác thực bảo mật sẽ được tạo tải nặng trên hệ thống.

Kiểm tra ứng dụng web trên trình duyệt trình duyệt web IE, Firefox, Netscape Navigator, AOL, Safari, Opera với nhiều phiên bản khác nhau.

Khả năng tương thích của hệ điều hành

Một số tính năng của ứng dụng web có thể không tương thích với một số hệ điều hành nhất định. Không phải tất cả chúng đều hỗ trợ các công nghệ mới được sử dụng trong phát triển web. Vì vậy hãy kiểm tra ứng dụng đang chạy trên Windows, Unix, MAC, Linux, Solaris và các phiên bản khác nhau của chúng.

Xem trên thiết bị di động

Vuốt kiểm tra trang web trên thiết bị di động và kiểm tra cách các trang web được xem bằng cách sử dụng trình duyệt di động. Các vấn đề về khả năng tương thích cũng có thể phát sinh do thiết bị di động. Cũng đừng quên về kiểm tra trang web ở các độ phân giải khác nhau.

Tùy chọn in

Nếu bạn dự định in trang, hãy đảm bảo rằng phông chữ, căn chỉnh, đồ họa, v.v. xuất hiện chính xác trên giấy. Các trang phải vừa với kích thước được đặt trong tùy chọn in.

5. Kiểm tra hiệu suất trang web

Kiểm tra hiệu suất của một trang web hoặc ứng dụng web nên bao gồm:

Bài kiểm tra về áp lực.
Bài kiểm tra về áp lực.

Kiểm tra hiệu suất ứng dụng trên tốc độ khác nhau Internet.

Kiểm tra tải trang web(ứng dụng web) đang thử nghiệm trong đó một số lượng lớn người dùng đồng thời đưa ra yêu cầu tới cùng một trang. Hệ thống có thể xử lý tải cao điểm không?

Kiểm tra căng thẳng - tải hệ thống vượt quá giới hạn đã thiết lập. Kiểm tra căng thẳng được thực hiện với mục tiêu đạt được lỗi trong hoạt động của trang web hoặc ứng dụng web bằng cách tăng tải. Đồng thời kiểm tra cách hệ thống phản ứng với căng thẳng và cách hệ thống phục hồi sau thất bại. Các trường nhập thông tin, đăng nhập và đăng ký có thể bị căng thẳng.

kiểm tra chức năng ab cũng bao gồm việc kiểm tra các lỗi liên quan đến RAM.

Kiểm tra hiệu suất có thể được sử dụng để kiểm tra khả năng mở rộng trang web hoặc đánh giá năng suất khi sử dụng bên thứ ba phần mềm.

Tốc độ kết nối

Kiểm tra trang web phân chia sử dụng Các tùy chọn khác nhau Kết nối Internet: qua modem, ISDN, v.v.

Trọng tải

Số lượng người dùng truy cập đồng thời vào trang web;
Kiểm tra hoạt động của hệ thống khi tải cao điểm;
Người dùng truy cập một lượng lớn dữ liệu.

Tải căng thẳng

Hiệu suất của bộ nhớ, bộ xử lý, xử lý tập tin, v.v.

6. Kiểm tra bảo mật

Dưới đây là một số bộ thử nghiệm bảo mật web:

Xác thực bằng cách chèn URL nội bộ vào thanh địa chỉ trình duyệt mà không có sự cho phép. Các trang nội bộ không nên được mở.
Sau khi ủy quyền sử dụng thông tin đăng nhập và mật khẩu của bạn, cũng như xem trang nội bộ hãy thử thay đổi URL. Ví dụ: bạn kiểm tra một số thống kê trang web theo ID= 123. Hãy thử thay đổi ID URL thành ID trang web khác không liên quan đến người dùng được ủy quyền. Trong mọi trường hợp, quyền truy cập của người dùng này để xem các số liệu khác sẽ bị từ chối.
Hãy thử nhập dữ liệu không chính xác vào các trường mẫu đăng nhập. Tìm hiểu cách hệ thống phản ứng với dữ liệu đầu vào không hợp lệ.
Không thể truy cập trực tiếp các thư mục hoặc tệp trừ khi chúng có thể tải xuống được.
Kiểm tra hoạt động của captcha để bảo vệ chống lại đăng nhập tự động sử dụng mã chương trình.
Kiểm tra xem SSL có được sử dụng cho mục đích bảo mật hay không. Nếu vậy, một thông báo sẽ được hiển thị khi người dùng điều hướng từ các trang HTTP không bảo mật sang các trang HTTP an toàn và ngược lại.
Mọi thao tác, thông báo lỗi, vi phạm bảo mật đều phải được ghi lại vào file log trên máy chủ web.

Lý do chính để kiểm tra bảo mật trang web là tìm ra các lỗ hổng tiềm ẩn và sau đó loại bỏ chúng.

Quét mạng;
Quét lỗ hổng;
Khả năng bị hack mật khẩu;
Tạp chí phê bình;
Công cụ kiểm tra tính toàn vẹn;
Phát hiện virus.

Những điểm cần cân nhắc khi thử nghiệm một trang web

Bạn nên chú ý đến sự tương tác của các trang HTML, kết nối Internet, tường lửa, các ứng dụng chạy trên trang web ( ứng dụng nhỏ, JavaScript, ứng dụng mô-đun ), cũng như các ứng dụng chạy phía máy chủ (tập lệnh CGI, giao diện cơ sở dữ liệu, trình tạo trang web động).

Có nhiều loại máy chủ và trình duyệt phiên bản khác nhau. Có những khác biệt nhỏ nhưng đáng kể giữa chúng.

Tập lệnh kiểm tra trang web mẫu

Các yếu tố bổ sung cần xem xét khi kiểm tra trang web của bạn:

Tải dự kiến trên máy chủ là gì ( ví dụ: số lượng yêu cầu trên một đơn vị thời gian)?
Hiệu suất nào là cần thiết cho nhiều loại khác nhau trọng tải ( thời gian phản hồi của máy chủ web, thời gian phản hồi của cơ sở dữ liệu đối với một yêu cầu)?
Những công cụ nào cần thiết để kiểm tra hiệu suất?
Ai là khán giả mục tiêu? Người dùng sẽ sử dụng trình duyệt nào? Tốc độ kết nối là bao nhiêu? Trang web này có được thiết kế để sử dụng trong tổ chức hay nó sẽ có sẵn trên Internet cho nhiều người dùng?
Khách hàng mong đợi nhận được hiệu suất như thế nào ( các trang sẽ tải nhanh như thế nào, hoạt ảnh, applet, tải và khởi chạy sẽ hoạt động như thế nào)?
Liệu thời gian ngừng hoạt động của máy chủ, việc bảo trì và cập nhật nội dung có được cho phép không? Nếu có, với số lượng bao nhiêu?
Những biện pháp an ninh nào được yêu cầu ( tường lửa, mã hóa, mật khẩu, v.v.), và họ sẽ làm loại công việc gì? Làm thế nào họ có thể được kiểm tra?
Kết nối Internet của bạn đáng tin cậy đến mức nào? Nó sẽ ảnh hưởng như thế nào hỗ trợ hệ thống?
Cập nhật nội dung trang web sẽ được quản lý như thế nào?
Yêu cầu cho BẢO TRÌ, theo dõi và giám sát nội dung của các trang web, yếu tố đồ họa, liên kết, v.v.
Đặc tả HTML nào sẽ được tuân theo? Làm thế nào chính xác?
Nội bộ sẽ như thế nào và liện kết ngoại? Bao lâu?
Các ứng dụng CGI sẽ được quản lý và xác minh như thế nào? Tập lệnh JavaScript , Thành phần ActiveX vân vân.?
Kích thước trang web tối đa không được vượt quá 3-5 màn hình, trừ khi nội dung tập trung vào một chủ đề duy nhất. Nếu trang web lớn hơn, hãy cung cấp các liên kết nội bộ để điều hướng nó.
Bố cục trang web và các yếu tố thiết kế phải nhất quán và được kết nối hợp lý.
Các trang web sẽ được hiển thị bất kể loại trình duyệt.
Mỗi trang nên bao gồm một liên kết liên hệ.

Bản dịch của bài viết “ Hướng dẫn hoàn chỉnh về kiểm thử web (Mẹo và kịch bản kiểm thử ứng dụng web)” được chuẩn bị bởi nhóm dự án thân thiện

Kiểm thử ứng dụng web là quá trình kiểm thử các sản phẩm máy khách-máy chủ được cung cấp trên web, thường liên quan đến việc hỗ trợ nhiều yếu tố phụ thuộc lẫn nhau. Hiệu quả, tiết kiệm chi phí và sự hài lòng chung của người dùng hệ thông thông tin phần lớn phụ thuộc vào chất lượng phát triển của họ. Lỗi phần mềm có thể dẫn đến tổn thất tài chính cho công ty và ngược lại, việc sử dụng các tiêu chuẩn được chấp nhận chung, các yêu cầu và giải pháp về thiết kế và chức năng thuận tiện - làm tăng số lượng người dùng tích cực.

Kiểm tra có tính đến một loạt các thành phần hệ thống phân tán tương tác với ứng dụng. Nếu có lỗi xảy ra trong môi trường mạng thường không thể xác định nơi xảy ra nếu không có sự tham gia của chuyên gia có trình độ, vì nó có thể xảy ra ở bất kỳ phần nào ứng dụng máy khách-máy chủ. Trong quá trình thử nghiệm các ứng dụng web, các kỹ sư QA tính đến các tính năng của kiến trúc dự án và cơ chế tương tác giữa cơ sở dữ liệu, phần máy chủ của ứng dụng, dịch vụ web, các thành phần của bên thứ ba và giao diện người dùng.

Phương pháp tiếp cận QA của Webmart để thử nghiệm các ứng dụng web

Là một phần của việc thử nghiệm các ứng dụng web, nhóm của chúng tôi thực hiện:

Kiểm tra chức năng(kiểm tra việc triển khai nội dung chức năng của ứng dụng xem có tuân thủ các yêu cầu và tiêu chuẩn được chấp nhận chung không).
Thử nghiệm đa trình duyệt và đa nền tảng(xác định các khiếm khuyết và khác biệt trong hoạt động của hệ thống khi người dùng tương tác với sản phẩm trên các hệ điều hành, trình duyệt và trên các thiết bị khác nhau).
Kiểm tra dịch vụ web (kiểm tra tính chính xác của các dịch vụ được ứng dụng web gọi để xử lý dữ liệu chính xác, thay đổi trạng thái của đối tượng, trả về thông tin từ cơ sở dữ liệu, v.v.).
Kiểm tra tích hợp, E2E (thử nghiệm các kịch bản từ đầu đến cuối cho một tập hợp các hệ thống con tương tác, bao gồm xác thực các kết nối và kết nối, chuẩn bị dữ liệu thử nghiệm trong một số thành phần nhất định và xác minh từng bước kết quả của quy trình kinh doanh cho toàn bộ hệ thống).
Kiểm tra khả năng sử dụng(kiểm tra khả năng sử dụng, phát hiện các sai sót trong điều hướng và giao diện cũng như nội dung thông tin thừa hoặc thiếu).
Kiểm tra tải và căng thẳng ( kiểm tra độ ổn định và khả năng chống lại các lỗi hệ thống trong điều kiện hoạt động bình thường và tải cao điểm trong một thời gian dài).

Quy trình điển hình để làm việc với một ứng dụng web được gửi đi kiểm tra như sau. Các chuyên gia của chúng tôi tiến hành kiểm tra và phân tích chức năng đầy đủ của hệ thống để xác định tất cả những vấn đề đang tồn tại. Trong tương lai, họ sẽ theo dõi tính đầy đủ của việc điều chỉnh ở các giai đoạn phát triển tiếp theo. Đối với mỗi dự án, một lịch trình làm việc và định dạng tài liệu kiểm tra riêng biệt sẽ được phát triển.

Tuy nhiên, các chuyên gia QA của Webmart muốn đảm bảo rằng việc sửa lỗi ứng dụng không dẫn đến xuất hiện các lỗi mới. Vì vậy, theo quy định, công việc của chúng tôi kết thúc kiểm tra hồi quy– kiểm tra xem hệ thống đã cải tiến có hoạt động như bình thường không: các cải tiến được triển khai không gây ra lỗi trong các chức năng liên quan và các lỗi đã sửa không dẫn đến sự xuất hiện của các lỗi mới.

Chỉ có sự kết hợp phù hợp

Nhóm của chúng tôi không bao giờ cung cấp mọi thứ: chúng tôi chỉ triển khai những phương pháp thực sự phù hợp và có thể áp dụng trong từng trường hợp cụ thể:

Các ứng dụng đơn giản nhất sẽ được đề xuất các thủ tục chuẩn, điều này sẽ cho phép bạn đạt được chất lượng mong muốn mà không phải trả thêm chi phí.
Đối với các ứng dụng có chức năng nghiêm túc hơn, chiến lược thử nghiệm mở rộng sẽ được phát triển và lịch trình làm việc và lặp lại sẽ được chuẩn bị. Đối với những dự án như vậy, nhân viên của bộ phận phân tích sẽ tham gia.
Đổi lại, đại diện của các nhóm chuyên gia và nhân viên bộ phận phát triển sẽ tham gia làm việc trong các dự án phức tạp, dựa trên kết quả nghiên cứu chuyên sâu, chiến lược thử nghiệm độc đáo sẽ được xây dựng và vòng đời dự án với sự phân bổ công việc và các loại thử nghiệm để đạt được mục tiêu trong khung thời gian quy định.

Để tìm ra cách tiếp cận nào chúng tôi cho là tối ưu cho bạn, hãy liên hệ với chúng tôi theo bất kỳ cách thuận tiện nào. các phương pháp trên hoặc để lại yêu cầu theo một trong các hình thức được đề xuất.

Mô tả khóa học:

Ngày nay hiếm khi ứng dụng hiện đại hoạt động mà không cần API. Điều này đúng cho cả một trang web đơn giản và những trang có lượng tải cao. hệ thống phân phối. Kiểm tra API là một trong những nhiệm vụ chính trong quy trình đảm bảo chất lượng. Không có gì đáng ngạc nhiên khi nhu cầu về người thử nghiệm biết cách kiểm tra API ngày càng tăng. TRÊN khóa học này bạn sẽ hiểu rõ hơn về các phương pháp, công cụ và cách tiếp cận trong thử nghiệm API, tiếp thu kiến thức cần thiết, điều này chắc chắn sẽ có tác động tích cực đến chi phí của bạn với tư cách là chuyên gia kiểm tra.

Khóa học này sẽ hữu ích cho những sinh viên đã quen với những kiến thức cơ bản về kiểm thử phần mềm, những người muốn phát triển hơn nữa và cải thiện kỹ năng của mình.

Chương trình khóa học:

Bài học 1. Giới thiệu. Giao thức SOAP

Sơ lược về giảng viên;
Mục tiêu khóa học;
API, WS là gì và tại sao chúng cần thiết;
Vai trò của thử nghiệm API trong quy trình đảm bảo chất lượng;
Đánh giá các công cụ kiểm tra WS;
Các phương pháp được sử dụng trong thử nghiệm WS;
Lịch sử của SOAP;
Thuật ngữ và khái niệm chính (XML, XSD, Endpoint, WSDL).

Bài 2: Giao thức SOAP. Kiến trúc REST

Thuật ngữ và khái niệm chính (UDDI, XSLT, XPath, XQuery, phương thức HTTP, trạng thái HTTP);
Cấu trúc và các thành phần chính của SOAP;
Phạm vi áp dụng;
Đặc điểm công việc;
Ưu điểm và nhược điểm;
Đặc điểm của kiến trúc REST;
Thuật ngữ và khái niệm chính (WADL, RESTful, JSON, JSONPath);
Nguyên tắc REST;
Mã trạng thái và các trạng thái chính;
Động từ CRUD;
Ưu điểm và nhược điểm.

Bài 3. Giới thiệu SoapUI. Làm việc với dự án REST

cài đặt Java;
Cài đặt SoapUI;
Tổng quan về các thành phần giao diện chính;
Kết nối một dự án giáo dục;
Xem xét các phương pháp dự án;
Gửi yêu cầu và phân tích phản hồi nhận được;
Nghiên cứu các dịch vụ web hiện có của dự án;
Lập kế hoạch kiểm tra;
Viết các trường hợp thử nghiệm;
Các phần tử “TestSuite”, “TestCase”, “TestSteps”.

Bài 4. Làm việc với dự án REST (XML)

Khối “Khẳng định”;
Chạy thử nghiệm ở nhiều cấp độ khác nhau;
Yếu tố “Thuộc tính”, khả năng chính;
Làm việc với Thuộc tính;
Yếu tố “Chuyển giao tài sản”;
Làm việc với các xác nhận.

Bài 5. Làm việc với dự án REST (JSON)

Điều kiện và chi nhánh;
Làm việc với các Xác nhận;
TestRunner, tính năng công việc;
Khởi chạy TS, TC từ dòng lệnh;
Làm việc với Test Runner;
Làm việc với tập lệnh Groovy.

Bài 6. Làm việc với tập lệnh Groovy

Làm việc với dữ liệu tĩnh và động;
Tạo dữ liệu thử nghiệm;
Chúng tôi lấy dữ liệu từ “Thuộc tính”;
Ghi và truyền dữ liệu;
Điều kiện và chi nhánh;
Khẳng định kịch bản.

Bài 7. Tính năng bổ sung

Kết nối các thư viện bên ngoài và các lớp tùy chỉnh;
Dịch vụ giả;
Tại sao chúng ta cần dịch vụ Mock?
Một ví dụ về làm việc với dịch vụ Mock;
Còn CI thì sao?
Cài đặt Jenkins;
Khởi động một dự án trên Jenkins.

Kiểm tra các ứng dụng web có nhiều điểm chung với việc kiểm tra hệ điều hành máy tính để bàn. Bạn cần kiểm tra chức năng tiêu chuẩn, cấu hình và khả năng tương thích cũng như tất cả các yếu tố khác. các loại tiêu chuẩn các bài kiểm tra. Nhưng thử nghiệm các ứng dụng web còn hơn thế nữa quá trình khó khăn, bởi vì những khó khăn được nhân lên bởi tất cả các thành phần phân tán của hệ thống tương tác với ứng dụng. Khi chúng tôi thấy có lỗi trong môi trường mạng, thường rất khó để xác định chính xác nơi xảy ra lỗi và do đó hành vi hoặc thông báo lỗi mà chúng tôi nhận được có thể là kết quả của các lỗi xảy ra trong các bộ phận khác nhau hệ thống mạng. Trong trường hợp này, việc sửa lỗi sẽ có vấn đề. Vậy chúng ta nên phân tích các lỗi trong hệ thống dựa trên công nghệ Internet như thế nào và cần tiến hành nghiên cứu gì để sửa các loại lỗi này?

Khi chúng ta hiểu thiết bị công nghệ cơ bản, chúng tôi có thể tăng hiệu quả kiểm tra nhiều hơn bằng cách viết các thông báo lỗi và sự cố dễ tái tạo hơn. Đổi lại, điều này cho phép chúng tôi phát hiện lỗi nhanh hơn. Nhưng điều này dễ khai báo hơn là thực hiện. Đặc biệt là trong môi trường Internet. Nó có đầy đủ các biến số công nghệ, trong ở một mức độ vừa đủ dễ bị lỗi. Dưới đây là 5 đánh giá cơ bản, cơ bản về việc thử nghiệm các ứng dụng Web:

Khi chúng tôi thấy lỗi ở phía máy khách, chúng tôi thấy dấu hiệu của lỗi chứ không phải bản thân lỗi đó.
Lỗi phụ thuộc vào môi trường và có thể không xảy ra trong các môi trường khác nhau.
Lỗi có thể ở mã hoặc trong cấu hình.
Lỗi có thể tồn tại ở bất kỳ cấp độ nào.
Việc xem xét 2 loại môi trường vận hành - tĩnh và động - đòi hỏi những cách tiếp cận khác nhau.

Chúng ta hãy xem xét 5 tuyên bố này một cách chi tiết hơn:

1. Chúng ta thực sự thấy gì, một lỗi hay một triệu chứng?

Nếu không có chẩn đoán môi trường, chúng tôi không thể nói hoàn toàn chắc chắn chính xác nguyên nhân gây ra triệu chứng này. Nếu bất kỳ điều cụ thể nào biến môi trường về phía máy khách hoặc máy chủ bị di chuyển hoặc thay đổi thì có khả năng chúng tôi sẽ không thể tái hiện sự cố.

Đây là một ví dụ. Tôi đang thử nghiệm một ứng dụng web để theo dõi lỗi và đang trong quá trình tạo báo cáo lỗi mới. Khi bạn nhấp vào MỚI, một thông báo lỗi xuất hiện như sau:

Nhà cung cấp Microsoft OLE DB cho lỗi Trình điều khiển ODBC "8004014".

Sau khi dành chút thời gian khám phá phần cứng của trình duyệt, tôi phát hiện ra trong hộp thoại tùy chọn của trình duyệt rằng JavaScript không được bật. Kích hoạt JavaScript sẽ giải quyết được lỗi. Ý tưởng cơ bản là tôi thêm Thông tin thêmồ thiết lập JavaScript liên quan đến thông báo vấn đề. Ngoài ra, mục “vô hiệu hóa JavaScript” cũng được bao gồm trong Tập kiểm tra trong tương lai, nó sẽ được thêm vào tất cả các phần của ứng dụng để mọi thứ đều có khả năng lỗi liên quan có thể đã được phát hiện.

2. Môi trường lỗi có phụ thuộc không?

Chơi phụ thuộc vào môi trường lỗi, chúng ta cần sao chép hoàn hảo cả chuỗi hành động chính xác và các điều kiện của môi trường mà ứng dụng sẽ hoạt động (hệ điều hành, phiên bản trình duyệt, thành phần bổ sung, máy chủ cơ sở dữ liệu, máy chủ web, thành phần cấp ba, tài nguyên máy chủ/máy khách, băng thông mạng, lưu lượng truy cập, v.v.). Ví dụ: nếu bạn cố gắng đăng nhập vào ứng dụng web của mình bằng kết nối quay số ở tốc độ 28,8 kbps, bạn sẽ gặp phải lỗi đăng ký cho đến khi quá trình ủy quyền bị gián đoạn do hết thời gian được phân bổ cho mục đích này. Tuy nhiên, việc đăng ký trên mạng được thực hiện theo cách tương tự nhưng sử dụng kết nối T-1 với tốc độ 1,54 Mb/s sẽ thành công. Trong trường hợp này, bạn gặp lỗi phụ thuộc vào môi trường trong đó sự phụ thuộc có liên quan đến thông lượng mạng.

Mặt khác, các lỗi không phụ thuộc vào môi trường lại tương đối dễ tái tạo hơn. Không cần phải nhân đôi môi trường hoạt động. Đối với các lỗi không phụ thuộc vào môi trường, tất cả những gì cần làm là lặp lại các bước sẽ tái tạo lỗi. Ví dụ: nếu tên của một công ty trên tất cả các trang web có sản phẩm của công ty đó được viết sai và trông như thế này - WebTesting.Con, sau đó bạn Luôn luôn Bạn sẽ thấy lỗi này bất kể các biến phần cứng, phần mềm hoặc tài nguyên trong môi trường hoạt động của bạn. Nói cách khác, chúng tôi coi các lỗi không phụ thuộc vào môi trường là có tính chất cụ thể về mặt chức năng.

3. Đây là lỗi mã hóa hay vấn đề về cấu hình?

Có thể sửa lỗi (hoặc triệu chứng nghi ngờ lỗi) bằng cách sử dụng tọa độ vị trí của chúng trong chương trình (giả sử rằng lỗi thực sự tồn tại) hoặc bằng cách cấu hình lại hệ thống (máy khách, máy chủ hoặc mạng). Bạn không nên đưa ra kết luận vội vàng vì cho rằng đây là một sai lầm.

Lỗi nhà cung cấp Microsoft OLE DB cho trình điều khiển ODBC "80004005"

Dưới đây là một ví dụ minh họa những khó khăn trong việc xác định khả thi vấn đề cấu hình so với thực tế vấn đề phần mềm. Chúng tôi thấy thông báo lỗi, nguyên nhân là do không thể đăng ký ("đăng nhập thất bại"). Thông báo này được tạo bởi một ứng dụng web. Tuy nhiên, chỉ nhìn vào thông báo lỗi này thì không thể xác định được đó thực sự là lỗi hay là do lỗi phần mềm, sự cố cấu hình phía máy chủ, sự cố không tương thích, sự cố cấu hình trình duyệt hoặc tất cả những vấn đề này. mức độ lớn hơn hoặc ít hơn.

Sau khi phân tích sâu hơn về sự thất bại, tôi tìm thấy một số lý do có thể có thể đã tạo ra thông báo lỗi này:

Thư mục ảo của máy chủ web (IIS) không được cài đặt đúng cách.

Khi thư mục ảo không được cấu hình đúng, các tệp, tập lệnh hoặc dữ liệu được yêu cầu sẽ không được tìm thấy. Thông thường đây là sự cố cấu hình máy chủ. Mặc dù vậy, nếu chương trình cài đặt không thể tự động cấu hình máy chủ web theo thông số kỹ thuật thì điều này lỗi phần mềm. Nếu như quản trị hệ thống máy chủ web không thể được cấu hình đúng theo đặc điểm kỹ thuật, khi đó lỗi sẽ chuyển thành lỗi người dùng.

Thư mục ứng dụng không được cấu hình đúng cách để chạy tập lệnh chính xác.

Thư mục tiêu chuẩn của máy chủ ứng dụng chứa các tập lệnh được thực thi khi chúng được máy chủ web gọi theo yêu cầu của máy khách. Vì lý do bảo mật, máy chủ web có thể được cấu hình để cho phép hoặc chặn việc thực thi các tập lệnh trong các thư mục riêng lẻ. Do đó, nếu máy chủ ứng dụng của bạn được tạo theo cách chứa các tập lệnh phải được thực thi và máy chủ web được định cấu hình để chặn việc thực thi chúng trong thư mục này thì ứng dụng sẽ không hoạt động. Thế thì nó là gì? lỗi phần mềm hoặc vấn đề cấu hình?

Trang web mặc định không được cài đặt đúng cách.

Vấn đề tương tự như vấn đề được mô tả ở trên.

Máy chủ SQL không hoạt động.

Máy chủ ứng dụng yêu cầu kết nối tới nút cơ sở dữ liệu nằm trên máy chủ SQLđể thực hiện các truy vấn, lưu thủ tục và truy cập dữ liệu. Nếu tiến trình dịch vụ SQL không chạy thì rõ ràng ứng dụng sẽ không chạy.

Đối tượng DLL/COM bị thiếu hoặc chưa được đăng ký thành công.

Có lẽ chương trình cài đặt không thể sao chép mọi thứ tập tin DLLđược sử dụng bởi máy chủ ứng dụng trong quá trình cài đặt. Nếu cần thiết cho hoạt động của máy chủ DLL ứng dụng thiếu tập tin, ứng dụng sẽ không hoạt động.

Có thể chương trình cài đặt đã sao chép chính xác tất cả các mô-đun cần thiết nhưng không thể đăng ký một hoặc nhiều mô-đun trong số đó. Ví dụ: trong các đối tượng dựa trên OLE như COM hoặc DCOM, ID lớp (CLSID) của chúng phải được đăng ký trong cơ sở dữ liệu đăng ký hệ thống trước khi chúng sẵn sàng để sử dụng. Nếu một ứng dụng cố gắng truy cập một đối tượng COM chưa được đăng ký thành công thì nó sẽ không hoạt động.

Sự cố này thường xảy ra do lỗi trong quá trình cài đặt. Mặt khác, nếu các thành phần phải được đăng ký thủ công thì sẽ trở thành vấn đề cấu hình.

Cài đặt JavaScript ở phía trình duyệt đã bị tắt.

Đây là sự cố cấu hình dành riêng cho trình duyệt xảy ra ngay khi ứng dụng yêu cầu trình duyệt bật JavaScript. Đây có phải là lỗi phần mềm, sự cố cấu hình hay sự cố hỗ trợ kỹ thuật không?

4. Mức độ nào thực sự gây ra vấn đề?

Thông thường, các lỗi trong hệ thống web khó tái tạo một cách nhất quán vì một số lượng lớn các biến được thể hiện bằng tính chất phân tán của cấu trúc hệ thống máy khách/máy chủ. Có ít nhất 3 "nghi phạm thông thường" trong môi trường web. Cái này khách hàng, máy chủ Và mạng lưới.

Cả máy khách và máy chủ đều có sự không nhất quán về cấu hình và khả năng tương thích tương tự như môi trường PC nơi tất cả các thành phần đều nằm trong cùng một hộp. Tuy nhiên, những mâu thuẫn này càng gia tăng trong hệ thống máy khách/máy chủ vì có thể có nhiều máy khách và máy chủ được kết nối vào mạng. Cấu hình điển hình và sự không nhất quán về khả năng tương thích dẫn đến nhầm lẫn hỗ trợ kỹ thuật và hệ điều hành (ví dụ: các đơn vị dựa trên UNIX so với Windows) và hỗn hợp phần mềm phía máy chủ (gói máy chủ web, gói máy chủ cơ sở dữ liệu, tường lửa, đối tượng COM, đối tượng CORBA, v.v.). Sự không nhất quán cũng có thể dẫn đến sự trộn lẫn phần mềm phía máy khách (hàng đợi TCP/IP, phần mềm quay số, thành phần trợ giúp, nhãn hiệu và phiên bản trình duyệt). Ngoài ra, các cài đặt trình duyệt như Cài đặt chung, cài đặt kết nối, cài đặt bảo mật (bao gồm bộ điều khiển ActiveX, bổ sung module phần mềm(plugin), Java, tập lệnh, nội dung tải xuống, ủy quyền người dùng, v.v.), cài đặt nội dung, cài đặt phần mềm và các cài đặt nâng cao khác (bao gồm tùy chọn xem, tùy chọn đa phương tiện, tùy chọn Java VM, tùy chọn in và tùy chọn HTTP) cung cấp nhiều biến số cần được kiểm tra và đưa vào nghiên cứu.

Mạng cung cấp một tập hợp các biến khác nhau. Chúng ảnh hưởng đến các ứng dụng web theo nhiều cách, bao gồm vấn đề liên quan đến thời gian(trạng thái liên kết, hoạt động, thời gian ngừng hoạt động, v.v.) mà chúng tôi nợ do băng thông và độ trễ, các vấn đề có thể xảy ra về cấu hình và khả năng tương thích của phần cứng như cổng và bộ định tuyến cũng như các tác dụng phụ liên quan đến hoạt động của dịch vụ bảo mật.

5. Môi trường hoạt động tĩnh và động khác nhau.

Có 2 loại môi trường điều hành, mỗi loại có đặc điểm riêng bao gồm thử nghiệm:

Môi trường tĩnh trong đó các vấn đề không tương thích có thể tồn tại bất kể các biến số như tốc độ xử lý và bộ nhớ khả dụng.

Môi trường năng động. Trong đó, điều ngược lại là đúng - các thành phần tương thích có thể phát hiện lỗi theo các lỗi phụ thuộc vào bộ nhớ và các điều kiện ẩn. (Chúng ta sẽ thảo luận về môi trường động chi tiết hơn ở phần sau.)

Môi trường hoạt động tĩnh: Các biến cấu hình và khả năng tương thích.

Các vấn đề về cấu hình và tương thích có thể xảy ra tại bất kỳ điểm nào trong hệ thống Web: chúng có thể xuất hiện ở phía máy khách, máy chủ hoặc phía mạng.

Các vấn đề về cấu hình ảnh hưởng cài đặt khác nhau phần mềm và phần cứng máy chủ, cài đặt trình duyệt, kết nối mạng và cài đặt TCP/ Hàng đợi IP. Ví dụ về trình duyệt và JavaScript đã thảo luận trước đó đã minh họa một loại vấn đề về cấu hình. Một loại khác được hiển thị trong Sơ đồ 1 Và Sơ đồ 2 . Chúng được trình bày theo hai cấu hình máy chủ vật lý có thể có: một và hai đơn vị.

Sơ đồ 1: Máy chủ web, máy chủ ứng dụng và máy chủ cơ sở dữ liệu trên một nền tảng

Sơ đồ 2: Máy chủ WEB và máy chủ ứng dụng trên một nền tảng, máy chủ cơ sở dữ liệu trên nền tảng khác

Ứng dụng mẫu đang được thử nghiệm của chúng tôi có một số khả năng lập biểu đồ cho phép người dùng tạo báo cáo số liệu như thanh và biểu đồ đường. Khi người dùng yêu cầu báo cáo số liệu, mã giả của máy chủ ứng dụng sẽ chạy theo trình tự sau:

1. Kết nối với máy chủ cơ sở dữ liệu và đưa ra yêu cầu.

2. Ghi kết quả yêu cầu dưới dạng file có tên c:\temp\chart.val

3. Thực thi Java Applet biểu đồ. Đọc và sử dụng dữ liệu từ một tập tin c:\temp\chart.valđể có thể vẽ đồ thị.

4. Gửi Java Applet tới trình duyệt.

Trong quá trình thử nghiệm ứng dụng, tôi phát hiện ra một tính năng trong việc vẽ đồ thị là nó chỉ hoạt động với một trong các cấu hình trên. Sau khi xem xét kỹ hơn, chúng tôi thấy rõ rằng sự cố xảy ra ở cấu hình hai thiết bị. Sau khi kiểm tra mã thì hóa ra vấn đề nằm ở điểm 2 và 3. Ở điểm thứ 2, kết quả truy vấn c:\temp\chart.valổ đĩa cục bộ của máy chủ cơ sở dữ liệu đã được ghi. Ở điểm thứ ba, Chart Java Applet đã được khởi chạy trên máy chủ ứng dụng, nằm trên các khối khác với máy chủ cơ sở dữ liệu. Khi tôi cố mở một tập tin c:\temp\chart.val trên ổ đĩa cục bộ của máy chủ ứng dụng, hóa ra tệp này đơn giản là không có ở đó.

Trong trường hợp này, tôi khuyên bạn không nên đọc mã mỗi khi gặp lỗi. Hãy để các nhà phát triển thực hiện công việc khắc phục sự cố. Tôi chỉ muốn chỉ ra sự cần thiết phải xác định máy chủ nào có vấn đề về cấu hình và đưa thông tin này vào báo cáo sự cố. Tôi cũng sẽ chạy một bộ thử nghiệm nông trên tất cả các cấu hình phân tán được máy chủ ứng dụng đang thử nghiệm hỗ trợ.

Vấn đề tuân thủ cũng rất quan trọng trong môi trường hoạt động tĩnh. Như một ví dụ chúng ta có thể xem xét Sơ đồ 3 , nơi chúng tôi thấy sự khác biệt về khả năng tương thích giữa Netscape Navigator và Internet Explorer.

Sơ đồ 3: Vấn đề tương thích với trình duyệt

Điều này không có nghĩa là Internet Nhà thám hiểm tốt hơn hơn Netscape Navigator. Điều này chỉ có nghĩa là có vấn đề không nhất quán giữa các trình duyệt và mã có thể không hoạt động được đường dẫn tương đối(để tập tin) cho tất cả các trình duyệt. Quan trọng hơn, điều này có nghĩa là nếu bạn gặp lỗi ở môi trường này thì ở môi trường khác nó có thể không phát sinh miễn là đây là lỗi phụ thuộc vào môi trường.

Môi trường hoạt động năng động: Mọi thứ không như cũ.

Khi giá trị của một thuộc tính môi trường cụ thể không giữ nguyên trong mỗi quy trình thử nghiệm, điều này sẽ dẫn đến việc môi trường vận hành trở nên khó khăn. năng động. Thuộc tính có thể là bất cứ thứ gì từ tài nguyên cụ thể (RAM có sẵn, dung lượng ổ đĩa, v.v.) đến thời gian cụ thể (độ trễ mạng, thứ tự giao dịch của người dùng, v.v.)

Khi một ca kiểm thử phụ thuộc vào chính xác phát lại dưới dạng tập hợp các hành động, Vì thế môi trường hoạt động và môi trường không thể được tái tạo (do tính chất động của nó), khi đó lỗi sẽ trở nên không thể tái tạo hoặc khó tái tạo.

Ngẫu nhiên, đây là lý do tại sao các lỗi liên quan đến bộ nhớ thường khó tái hiện. Ví dụ, khi có lỗi ghi đè bộ nhớ trong mã, nó sẽ luôn tạo ra một vấn đề tương ứng. Tuy nhiên, từ góc độ kiểm tra hộp đen, chúng tôi sẽ không thể thấy triệu chứng của lỗi này cho đến khi (các) byte mã hoặc dữ liệu bị ghi đè cụ thể được thực thi hoặc đọc. Trong ví dụ này, tập hợp các hành động thể hiện tập hợp chính xác các hàm hộp đen. Lỗi ghi đè bộ nhớ thể hiện lỗi thực tế trong mã. Điều kiện trong đó byte ghi đè được thực thi hoặc đọc cho biết môi trường hoạt động động hoặc điều kiện cần thiết để tái tạo lỗi.

Dưới đây là một ví dụ về lỗi ứng dụng web phụ thuộc vào môi trường động, trong đó chúng tôi sẽ xem xét lỗi liên quan đến thời gian.

Yêu cầu đặc điểm kỹ thuật:

Tên dự án trong hệ thống phải là duy nhất.
Việc phát hiện và xử lý lỗi đối với việc sao chép phía máy khách tiềm năng phải được thực hiện bằng cách sử dụng JavaScript.
Người dùng có thể thêm hoặc xóa tên dự án bằng cách yêu cầu một trang Cài đặtHướng lênDự án.
Khi người dùng tạo tên dự án mới, JavaScript ở phía trình duyệt sẽ kiểm tra tên đã nhập dựa trên danh sách chọn nằm trên trang HTML(như thể hiện trong Sơ đồ 4 )

Nhìn vào lỗi liên quan đến thời gian được hiển thị trong Đề án 5 . Đây là ảnh chụp màn hình của trang Thiết lập dự án làm ra trước Và sau đó, cho phép chúng tôi thấy rằng ứng dụng không thể phát hiện tiêu đề trùng lặp "Doomed". TRONG Sơ đồ 4 đưa ra lời giải thích cho lỗi liên quan đến thời gian này khiến cả hai người dùng phải thêm tên dự án mới vào cùng một cơ sở dữ liệu.

Lược đồ 4: Tập lệnh Java ở phía trình duyệt kiểm tra các giá trị đã nhập

Sơ đồ 5: Lỗi liên quan đến thời gian

Như thể hiện trong Bảng 1 , người dùng A và người dùng B tạo dự án mới, mặc dù đồng thời nhưng không biết về hành động của nhau. Theo điểm 3, người dùng A thêm một dự án có tên Khác. Nhưng vì tên như vậy đã tồn tại nên JavaScript trong trình duyệt của anh ấy hiển thị thông báo yêu cầu anh ấy sử dụng tên khác.

Bảng 1: Hoạt động của Người dùng A và B
[mở lớn hơn]

Người dùng B thêm tiêu đề dự án Chết tiệt. JavaScript trong trình duyệt của cô ấy không nhận ra nó là đã tồn tại từ trước nên nó thêm tên vào cả cơ sở dữ liệu và danh sách trả về. Danh sách cập nhật các tiêu đề dự án được gửi lại cho Người dùng B.

Sau đó, người dùng A thêm tên tương tự Bị tiêu diệt danh sách dự án. JavaScript của trình duyệt của anh ấy không phát hiện ra nó trong danh sách HTML, và do đó thêm lại tên cam chịu vào cơ sở dữ liệu và trả về danh sách. Danh sách cập nhật các tiêu đề dự án được gửi lại cho Người dùng A bao gồm hai mục Chết tiệt.

Kết quả thu được không đáp ứng các thông số kỹ thuật của sản phẩm. Mặc dù tình huống này là một trường hợp thử nghiệm được minh họa rõ ràng, nhưng việc vô tình phát hiện ra lỗi này và cố gắng tái tạo nó không phải là một nhiệm vụ dễ dàng. Trong ví dụ này, lỗi chính là ứng dụng không thể kiểm tra và sửa các tên trùng lặp ở phía máy chủ (ngoài việc kiểm tra ở phía máy khách). Các bước liên quan đến người dùng A. Động hệ điều hànhđược tạo bởi hành động của người dùng B bị ẩn khỏi người dùng A hoặc đơn giản là anh ta không biết.

Phần kết luận

Để có hiệu quả trong việc phân tích và tái tạo lỗi trong môi trường web, bạn cần có đòn bẩy đối với môi trường vận hành. Bạn cũng cần hiểu các biến của môi trường cụ thể có thể ảnh hưởng như thế nào đến khả năng tái tạo lỗi của bạn. Tôi hy vọng rằng với một số kỹ năng bạn có thể học được từ bài viết này, trải nghiệm kiểm thử web của bạn sẽ bớt khó chịu và thú vị hơn.

Hãy nhớ rằng không gì có thể thay thế được kỹ năng kiểm thử và khả năng đưa ra các trường hợp kiểm thử tốt của bạn. Đừng ngại hỏi "Điều gì sẽ xảy ra nếu...?", ghi chú chi tiết và điều tra một cách có phương pháp các lỗi khó tái tạo. Đây chính xác là những kỹ năng sẽ giúp bạn không chỉ trong việc nghiên cứu lỗi mà còn tìm ra các vấn đề khác liên quan đến chúng.