Thông thường, testers sử dụng kiểm tra tự động để nâng cao chất lượng kiểm tra thủ công, đẩy nhanh việc thực hiện các kiểm tra chức năng và giảm thiểu lỗi của con người trong quá trình xác minh. Nó tích hợp tự động hóa vào toàn bộ quy trình đảm bảo chất lượng, do đó chúng ta phải áp dụng các bước tương tự cho kiểm thử tự động như chúng ta làm cho kiểm thử thủ công.
Khi quyết định những gì nên được tự động hóa và những gì nên được thực hiện thủ công, có một số tiêu chí cần lưu ý. Blog này cung cấp về 10 mẹo cho quy trình thử nghiệm tự động và chỉ ra mối liên hệ giữa thử nghiệm thủ công và tự động.
1. Tránh lặp lại chức năng ứng dụng được kiểm thử trong script
Một ứng dụng thử nghiệm thực hiện các phép tính và trả về một kết quả. Làm thế nào để bạn xác minh rằng kết quả là chính xác? Lựa chọn đầu tiên là thực hiện cùng một phép tính trong tập lệnh thử nghiệm và so sánh kết quả với những gì ứng dụng trả về! Tuy nhiên, chiến lược này không chính xác vì những lý do sau:
- Việc tính toán có thể khó khăn. Các lập trình viên đã đầu tư thời gian cho việc tính toán, và bây giờ bạn sẽ làm điều tương tự.
- Công thức tính toán có thể thay đổi trong tương lai. Trong trường hợp này, sẽ có lỗi trong báo cáo, mặc dù ứng dụng vẫn hoạt động bình thường. Bạn sẽ cần phải điều chỉnh, điều này sẽ cần thêm thời gian.
- Khi làm việc với các số điểm nổi, độ chính xác của các phép tính có thể khác nhau tùy thuộc vào ngôn ngữ được sử dụng để kiểm tra và ngôn ngữ mà ứng dụng đang được kiểm tra. Do đó, bạn sẽ cần phải điều chỉnh giả lập các tính toán của mình sao cho chúng tương ứng với đầu ra của ứng dụng.
Trong những trường hợp như vậy, cách tiếp cận chính xác là tính toán thủ công giá trị chính xác và lưu nó trong kịch bản theo kế hoạch. Nếu một phép tính duy nhất là đủ, kết quả phải được ghi ngay vào tập lệnh. Nếu cần tính toán, sử dụng mảng hoặc phương pháp DDT.
Sẽ là tối ưu nếu các cá nhân có thẩm quyền cung cấp cho bạn dữ liệu nguồn và kết quả chính xác cho họ (ví dụ: chuyên gia sản phẩm). Bạn chịu trách nhiệm mã hóa bản test, nhưng việc xác định kết quả mong đợi thường không phải là trách nhiệm của bạn.
Bây giờ, nếu bản test của bạn đã thất bại, hoặc ứng dụng không hoạt động hiệu quả hoặc các yêu cầu đã thay đổi, đòi hỏi phải cập nhật dữ liệu bản test.
Trong mọi trường hợp, bạn có thể yên tâm rằng thất bại không liên quan đến mã thử nghiệm!
Nếu không thể loại bỏ hoàn toàn các phép tính như vậy vì một số lý do, hãy cố gắng đơn giản hóa và giảm chúng càng nhiều càng khả thi trong các bản test. Ngoài ra, hãy cẩn thận để bao gồm các nhận xét trong tập lệnh hoặc thông báo lỗi giải thích những gì đã được tính toán và tại sao. Trong tương lai, bạn hoặc người khác có thể cần phân tích các lỗi tiềm ẩn.
2. Kiểm tra độc lập
Khi tự động hóa, sản phẩm mới hơn của người thử nghiệm thường xuyên gặp lỗi khi một thử nghiệm sử dụng dữ liệu được cung cấp bởi một thử nghiệm khác. Minh họa cho điều này là tính năng CRUD, trong đó một bản test tạo một bản ghi, một bản cập nhật khác và một bên thứ ba xóa nó.
Ưu điểm duy nhất của chiến lược này là nó tiết kiệm thời gian; tuy nhiên, nhiều khuyết điểm có thể xuất hiện đồng thời:
- Nếu test tạo ra bản ghi thất bại, các bản test còn lại cũng sẽ thất bại.
- Có nhiều lỗi trong báo cáo, trong khi khả năng chỉnh sửa và xóa là chính xác.
- Không phải lúc nào cũng có thể đảm bảo rằng các bản test sẽ chạy theo một thứ tự cụ thể khi chúng được bắt đầu tự động.
- Nếu bạn muốn tiết kiệm thời gian và tránh phải tạo thêm mục nhập trong đơn ứng tuyển, bạn có thể hoàn thành nó theo cách khác. Ví dụ: tạo chúng bằng cách sử dụng truy vấn SQL vào cơ sở dữ liệu, API của ứng dụng hoặc cơ sở dữ liệu đã chứa thông tin liên quan. Trong trường hợp này, để đảm bảo tính độc lập của các bản test, bạn có thể chạy chúng theo thứ tự ngẫu nhiên nếu công cụ tự động hóa của bạn hỗ trợ chức năng này.
3. Xác định nhiệm vụ nào không nên được tự động hóa.
Có những công việc phải được tự động hóa trong mỗi dự án, trong khi những công việc khác chỉ nên được để lại cho thử nghiệm thủ công. Những nhiệm vụ như vậy sẽ là duy nhất cho mỗi dự án, nhưng bạn có thể xác định một số lĩnh vực chung không nên tự động hóa.
- Không tự động hóa một cái gì đó đòi hỏi bảo trì nhiều. Ngay cả khi bạn đã tạo một bản test, nếu nó yêu cầu bảo trì và khởi động lại liên tục, bạn nên xem xét loại bỏ hoặc đơn giản hóa nó càng nhiều càng tốt.
- Không tự động hóa đơn của người khác. Ví dụ: nếu bạn cần xử lý Google Mail, tránh viết mã quá phức tạp để hoạt động với giao diện của nó (tất nhiên, điều này không áp dụng cho nhân viên Google).
- Tự động hóa giao diện (tính đúng đắn và khả năng sử dụng của nó) về mặt lý thuyết là có thể, nhưng quá tốn thời gian và thường không đủ.
- Thông thường, sự tương tác với các thiết bị ngoại vi (máy in, máy quét, v.v.) đòi hỏi sự can thiệp của con người là cồng kềnh hoặc đòi hỏi một lượng lao động thủ công bổ sung quá lớn.
- Ngoài ra, xác minh thủ công về độ chính xác của các hình ảnh, đồ họa và video khác nhau đơn giản hơn.
- Tự động hóa các ứng dụng và các thành phần riêng lẻ là không thể, vì tên của các thuộc tính của chúng thay đổi theo từng biên dịch.
4. Xác minh các lỗi cụ thể
Trong phần lớn các trường hợp, các bản test được viết để đánh giá chức năng cơ bản và không xác minh các trường hợp cá nhân, chẳng hạn như một khiếm khuyết với dữ liệu cụ thể. Tuy nhiên, không phải là không phổ biến đối với một lỗi cố định trước đây xuất hiện lại sau một thời gian; lý do cho sự xuất hiện lại của nó có thể hoàn toàn khác nhau, nhưng hậu quả là như nhau. Trong những trường hợp như vậy, việc xây dựng một bản test riêng biệt để kiểm tra lỗi đơn lẻ này hoặc một số lỗi là hợp lý.
Do chúng không phù hợp với các kịch bản thử nghiệm thủ công, những khiếm khuyết này chỉ có thể được phát hiện bằng sự trùng hợp ngẫu nhiên. Thông thường, các vấn đề như vậy xảy ra trong việc tích cực phát triển các dự án mà nhiều lập trình viên đang sửa đổi cùng một chức năng, do đó can thiệp vào các sửa đổi của nhau. Nếu bạn viết một bản test như vậy, bạn phải cung cấp số lỗi hiện có trong trình theo dõi lỗi trong báo cáo để bạn có thể xem lịch sử khám phá và sửa lỗi. Khi viết một bản test tự động và phát hiện ra một sai lầm trong chương trình đang được kiểm tra, bạn có thể trả lời tương tự. Bạn báo cáo lỗi và cho biết số lỗi trong phần nhận xét của quá trình xác minh bản test mới. Sau khi lỗi loại này đã được giải quyết, lỗi chỉ đơn giản là biến mất khỏi báo cáo.
5. Hỏi lập trình viên nếu cần
Để bản test được đơn giản hóa, các bản test phải bao gồm mã đơn giản hóa. Rõ ràng, bạn có thể tạo ra một khuôn khổ phức tạp, nhưng trong phần lớn các trường hợp, điều này là không cần thiết. Điều tương tự cũng đúng với các chủ đề khác mà lập trình viên gặp phải thường xuyên, chẳng hạn như biểu thức thông thường, tương tác với cơ sở dữ liệu và sử dụng các chức năng ứng dụng nội bộ. Trong một vài trường hợp khi bạn cần thiết kế các giải pháp kiểm thử phức tạp hơn, thì các lập trình viên thường có kiến thức nhiều hơn và có thể cung cấp hướng dẫn có giá trị.
Nếu bạn phải đối mặt với một tình huống khó khăn mà bạn không biết cách giải quyết, hãy tìm kiếm sự tư vấn của các nhà phát triển. Rõ ràng, nó không đáng để tìm kiếm sự trợ giúp cho mỗi điều nhỏ; nó thường có lợi hơn nhiều để hiểu một mình bạn, do đó có được kinh nghiệm.
Tuy nhiên, hãy nhớ rằng quan điểm của nhà phát triển ứng dụng khác với quan điểm của bạn và không phải tất cả các đề xuất đều hữu ích như nhau. Lập trình viên xem ứng dụng từ bên trong và hiểu cách nó hoạt động. Từ bên ngoài, bạn có thể thấy nó nên hoạt động như thế nào.
Kết luận
Nếu bạn đang tìm kiếm một nhà cung cấp IT giàu kinh nghiệm, GCT Solution là sự lựa chọn lý tưởng. Chúng tôi có hơn 3 năm kinh nghiệm trong việc cung cấp các giải pháp số hóa cho doanh nghiệp như phát triển ứng dụng di động, phát triển ứng dụng web, phát triển hệ thống, phát triển blockchain và dịch vụ kiểm thử. Cùng đội ngũ gồm hơn 100 chuyên gia và lập trình viên, chúng tôi có thể xử lý các dự án ở mọi quy mô cũng như độ phức tạp. Chúng tôi đã hợp tác thành công với các khách hàng từ nhiều ngành nghề và khu vực khác nhau, mang lại hơn 50+ giải pháp chất lượng cao. Tại GCT Solution, chúng tôi cam kết hỗ trợ bạn trong việc đạt được mục tiêu của bạn. Nếu bạn quan tâm, xin vui lòng liên hệ với chúng tôi để có một cuộc thảo luận chi tiết. Chúng tôi tự tin rằng GCT Solution có thể đáp ứng mọi nhu cầu IT của bạn với những giải pháp linh hoạt và hiệu quả.
