Cách kiểm thử tính năng Email của một ứng dụng.

Trong hầu hết các ứng dụng web và điện thoại di động, xác nhận tính năng Email được coi là một trong những phần quan trọng nhất của kiểm thử, để đảm bảo chất lượng trong thành phần Email cũng như các thành phần khác của hệ thống. Các email được kích hoạt dưới các tình huống khác nhau được coi là hợp lệ bằng cách kiểm tra tất cả các thành phần của nó trong đó bao gồm mẫu Email, Liên kết / nút trong các trường Email, Từ, Tới, Cc, Bcc, Tệp đính kèm, Nội dung theo Email, vv…

Tại sao chúng ta cần Kiểm tra Email? Mỗi thành phần trong hệ thống (Web / ứng dụng trên điện thoại di động) có thể có các mục đích khác nhau để gửi email. Tích hợp giữa (các) thành phần và Email đóng một vai trò quan trọng trong việc tiếp cận người dùng cuối cùng với các thông báo phù hợp. Bất kỳ sơ suất nào khi xác nhận tính năng này sẽ dẫn đến sự hiểu nhầm, tạo tiếng xấu với khách hàng, hacking, v.v.

Tại sao chúng ta cần Kiểm thử Email?

Mỗi thành phần trong hệ thống (Web / ứng dụng trên điện thoại di động) có thể có các mục đích khác nhau để gửi email. Tích hợp giữa (các) thành phần và Email đóng một vai trò quan trọng trong việc tiếp cận người dùng cuối cùng với các thông báo phù hợp. Bất kỳ sơ suất nào khi xác nhận tính năng này sẽ dẫn đến sự hiểu nhầm, tạo tiếng xấu với khách hàng, hacking, v.v.

Ví dụ: hãy tưởng tượng tình huống người dùng đã nhận được email để đặt lại mật khẩu. Điều gì sẽ xảy ra nếu liên kết Đặt lại mật khẩu / nút hoặc URL được cung cấp để sao chép trong một trình duyệt không hoạt động? Tùy chọn duy nhất còn lại ở đây là liên hệ với bộ phận hỗ trợ khách hàng, điều này có thể trở thành một điều tẻ nhạt hoặc tưởng tượng một tình huống mà người dùng tiếp tục nhận được Email hàng ngày về ngày đến hạn thanh toán hóa đơn từ 10-15 ngày trước đó hoặc nhận được lời nhắc sau ngày đáo hạn là thông qua. – Điều này sẽ gây phiền phức cho người dùng hay không ??

Có rất nhiều tình huống mà email đã trở thành một phần không thể tách rời của cuộc sống của chúng ta vì chúng nhằm giữ cho người dùng được cập nhật thông tin chính xác.

Các kịch bản thời gian thực phổ biến và điểm xác nhận cho email

Những điểm cần xác minh trong kiểm thử email thì khác nhau từ loại này sang loại khác, và một lần nữa từ ứng dụng này đến ứng dụng khác. Thông thường tất cả các Email phải được xác nhận hợp lệ cho mẫu (bao gồm logo ứng dụng, tên ứng dụng, Địa chỉ người dùng, Nội dung chân trang - Bản quyền, Thông tin hỗ trợ khách hàng), ngày tháng và thời gian cho các múi giờ khác nhau.

Ở đây, chúng ta sẽ thảo luận về một số loại Email phổ biến mà hầu hết mọi người đều biết (tất cả các điểm xác nhận được đưa ra dưới đây là kiểm tra cơ bản mà người kiểm tra phải thực hiện trong khi kiểm tra Email của ứng dụng).

1) Kích hoạt email

Khi người dùng đăng ký vào một ứng dụng lần đầu tiên, họ cần kích hoạt tài khoản bằng cách nhấp vào liên kết kích hoạt được gửi bằng Email. Điều này cũng xác minh địa chỉ Email đã cho của người dùng là hợp lệ và có thể truy cập được.

Các điểm xác nhận như sau:

• Kích hoạt đường Link hoặc là Button - Khi nhấp vào nó sẽ:
  • Đưa người dùng đến trang ứng dụng tương ứng với tài khoản người dùng đã đăng nhập.
  • Tài khoản Email của Người dùng sẽ tự động được xác minh nếu trang ứng dụng được truy cập thành công qua Email.
• Thời lượng - Kiểm tra khoảng thời gian mà liên kết phải được nhấp và xác minh.
  • Xác minh trong khoảng thời gian đã chỉ định.
  • Hãy thử xác minh sau khi thời gian đã trôi qua - Tài khoản không được kích hoạt và Email vẫn không được xác minh.

2) Quên mật khẩu email

Khi người dùng quên mật khẩu để đăng nhập vào ứng dụng, quên mật khẩu có thể được thực hiện để nhận Email với liên kết để đặt lại mật khẩu (tính năng khác nhau giữa ứng dụng và ứng dụng).

Các điểm cần xác nhận như sau:

• Đặt lại mật khẩu liên kết:

  • Nhấp vào nó sẽ đưa người dùng đến trang của ứng dụng tương ứng để đặt lại mật khẩu.
  • Một số ứng dụng sẽ yêu cầu người dùng trả lời câu hỏi bảo mật trước khi hiển thị trang đặt lại mật khẩu và một số sẽ có câu hỏi bảo mật được tích hợp với trang mật khẩu đặt lại và một số sẽ không có tính năng này.
  • Nếu người dùng đặt lại mật khẩu thành công, liên kết trong Email Quên mật khẩu đã nhận được sẽ bị vô hiệu hoá và không hoạt động.
  • Nếu người dùng hủy quy trình đặt lại mật khẩu, liên kết trong Email Quên mật khẩu đã nhận được sẽ vẫn được kích hoạt.

• Thời lượng - Kiểm tra khoảng thời gian mà liên kết phải được nhấp để đặt lại mật khẩu.

  • Nhấp vào liên kết và đặt lại mật khẩu thành công trong khoảng thời gian xác định.
  • Hãy thử nhấp vào liên kết sau thời gian đã qua - Liên kết phải bị vô hiệu hóa và hết hạn.

3) Các Thông báo về ngày đến hạn

Đây là để nhắc nhở người dùng về hành động số ngày tham gia. Đây thường là thanh toán hóa đơn, thực hiện hành động đối với các mục đang chờ xử lý (ví dụ: chấp nhận hoặc từ chối lời mời đến một số sự kiện trong một số ngày cụ thể, gửi biểu mẫu, v.v ...).

Các điểm xác nhận như sau:

• Số ngày đến hạn / Ngày đáo hạn
  • Nếu email thông báo về một số ngày đến hạn, số đó phải là 0 hoặc nhiều hơn, không có nghĩa là ngày hiện tại là đến hạn. Nó không phải là số âm. Nếu email thông báo về Ngày đến hạn (Lịch ngày) do đó ngày hết hạn sẽ phải là ngày hiện tại hoặc tương lai.
• Loại hành động
  • Kiểm tra loại hành động được yêu cầu. Cần phải nêu rõ rõ loại hành động mà người dùng phải thực hiện. Có thể là thanh toán hóa đơn, đơn trình, phản hồi, v.v.

4) Thông báo quá hạn

Đây là thông báo cho người dùng về ngày hết hạn đã trôi qua. Điều này thường là để thông báo cho người sử dụng rằng anh / cô ấy đã không thực hiện các mục yêu cầu trong thời hạn.

• Số ngày quá hạn
  • Kiểm tra xem số ngày quá hạn phải là một hoặc nhiều. Không bao giờ nên là số không hoặc số âm
• Tần số
  • Rất ít ứng dụng sẽ có điều khoản để tùy chỉnh email quá hạn được gửi hàng ngày / hàng tuần / hàng tháng, một khi ngày đáo hạn đã trôi qua, cho đến khi người dùng hoàn tất hành động. Rất ít ứng dụng sẽ có thông báo chuẩn được gửi chỉ một lần chỉ sau ngày hết hạn đã trôi qua.

5) Đăng ký

Điều này thay đổi theo yêu cầu của người dùng. Người dùng có thể chọn một trong số các đăng ký Hàng ngày, Hàng tuần, Hàng tháng hoặc Hàng tháng sau đấy. Điều này thường là đối với bản tin, cập nhật, phiếu mua hàng, v.v ...

• Tần số
  • Email phải được gửi theo lựa chọn người dùng cho thuê bao. Nếu Hàng ngày, sau đó gửi email đăng ký chỉ nên gửi một lần trong một ngày. Nếu hàng tuần, thì một lần trong một tuần. Và tiếp tục ...
• Liên kết
  • Bất kỳ liên kết nào trong email phải chuyển đến trang tương ứng của ứng dụng. Nếu email được cập nhật, sau đó liên kết sẽ chuyển hướng đến trang nơi bản cập nhật sẽ được hiển thị. Nếu email được cung cấp, sau đó liên kết nên chuyển hướng đến trang Phiếu mua hàng của ứng dụng. Nó phụ thuộc vào loại người sử dụng đã đăng ký.

6) Biểu mẫu

Email ở đây muốn nói đến việc người dùng cung cấp các phản hồi thông qua các hình thức / liên kết tới các biểu mẫu. Các điểm xác nhận như sau:

• Liên kết
  • Liên kết trong email nên chuyển hướng người dùng đến trang gửi mẫu của ứng dụng theo kiểu người dùng được yêu cầu phải gửi
  • Khi đã gửi, nhấp vào liên kết một lần nữa sẽ thông báo cho người dùng rằng biểu mẫu đó đã được gửi. Không nên cho phép người dùng gửi lại biểu mẫu.

7) Email Xác nhận

Email ở đây là để thông báo cho người dùng về việc xác nhận thông qua hành động được thực hiện. Đây thường là xác nhận đặt chỗ, xác nhận đơn đặt hàng, xác nhận truy vấn, v.v ...

Các điểm xác nhận như sau:

• Chi tiết xác nhận:
  • Số đơn đặt hàng / số đặt chỗ phải chính xác và khớp với số được hiển thị trong UI ứng dụng. Vì nó là định danh để theo dõi các đơn đặt hàng / đặt chỗ, nó nên là duy nhất (được xác nhận trong backend - DB) trong suốt ứng dụng. Không có đơn đặt hàng / đặt phòng nên chia sẻ cùng một số nhận dạng.
  • Cùng với số lượng, nó cũng cần được xác nhận cho các loại thứ tự, thông tin người dùng, địa chỉ thanh toán, địa chỉ vận chuyển, và giá cả. Tất cả thông tin phải chính xác tương tự như những gì người dùng đã cung cấp trong UI ứng dụng.
• Liên kết:
  • Liên kết trong email nên đưa người dùng đến trang chi tiết của đơn đặt hàng trong giao diện người dùng ứng dụng. Cần có kết hợp chính xác giữa thông tin trong Giao diện người dùng Email và ứng dụng.

8) Bản ghi trò chuyện

Ở đây, người dùng nhận được toàn bộ bản ghi trò chuyện như Email. Điều này thường xảy ra khi cuộc trò chuyện trực tuyến với sự hỗ trợ của Khách hàng kết thúc.

Các điểm xác nhận là như dưới đây

• Chi tiết
  • Kiểm tra tên của người đã cung cấp hỗ trợ trực tuyến. Kiểm tra xem toàn bộ cuộc trò chuyện có trong email với chi tiết của người gửi cho mỗi mục nhập trò chuyện (Tên người, Ngày và giờ tin nhắn trò chuyện đã được gửi, v.v ...).

9) Các email với tệp đính kèm

Người dùng nhận được email với tệp đính kèm. Các tệp đính kèm có thể được bảo vệ bằng mật khẩu / không được bảo vệ. Đây thường là các báo cáo từ các lĩnh vực tài chính, Thỏa thuận cấp phép người dùng cuối để tham khảo, Điều khoản & Điều kiện để tham khảo, v.v. điều này lại thay đổi từ ứng dụng sang ứng dụng.

Các điểm xác nhận như sau:

• Loại tập tin đính kèm
  • Các loại tệp hợp lệ phải được gửi dưới dạng tệp đính kèm. Tất cả các tệp đính kèm đang mở sẽ được quét virus trước khi tải / mở. Điều này lại có thể được tùy chỉnh ở cấp ứng dụng ở phần phụ trợ, như quét virus chỉ được thực hiện khi tải xuống, chỉ khi mở, cho cả việc tải và mở.
  • Các tập tin đính kèm được bảo vệ bằng mật khẩu sẽ được tải xuống mà không yêu cầu mật khẩu. Nhưng trong khi mở nó từ chính Email hoặc mở các bản sao đã tải xuống thì luôn luôn cần mật khẩu. Mục nhập mật khẩu không chính xác ở đây sẽ không xác định vì bản sao cục bộ không thể theo dõi trực tuyến để khóa tệp đính kèm.

Các loại email

Loại email có thể là HTML (đầy màu sắc và hấp dẫn đối với người dùng, người dùng quan tâm đọc toàn bộ email) hoặc Plain Text (chỉ là một văn bản).

HTML là những trang ưa thích nhất và thường được đặt làm mặc định trong hầu hết các ứng dụng ở phần phụ trợ. Nếu được yêu cầu, ứng dụng có thể chọn gửi email văn bản Plain đến người dùng, một lần nữa điều này đòi hỏi phải thay đổi ở phụ trợ.

Điểm khởi hoạt của email:

Email có thể được gửi ngay lập tức hoặc như tóm lược/batch. Email ngay lập tức được kích hoạt bởi hành động của người dùng. Đây thường là các email kích hoạt, đặt lại mật khẩu email, phiên bản trò chuyện, email xác nhận, v.v. nghĩa là các email Tóm tắt/batch được kích hoạt dựa trên cài đặt ở phần hỗ trợ của ứng dụng.

Điểm Kích hoạt Email sẽ được xác định để kích hoạt tại thời điểm cụ thể (ví dụ như ngày thứ 3 hàng tuần lúc 12:00 sáng). Đây thường là các tuyên bố từ các lĩnh vực tài chính (Báo cáo ngân hàng), thông báo ngày đến hạn cho hóa đơn, thông báo quá hạn, đăng ký, v.v.,

Bouncebacks:

Đây là một tình huống rất phổ biến mà email bị trả lại khi chúng được gửi đến địa chỉ email không hợp lệ. Thông thường, địa chỉ email bị vô hiệu hóa/không còn sử dụng nữa và không tồn tại - là những ứng cử viên trả lại.

Máy chủ thường cố gắng cho một số thời gian nhất định để gửi Email tới địa chỉ dự định. Khi nó không đạt đến địa chỉ email mong muốn, nó sẽ bị trả lại và sẽ tạo một mục nhập trong máy chủ cho sự thất bại của nó. Sẽ có một máy chủ khác để duy trì các loại hoạt động này và thường được gọi là máy chủ trả lại. Có thể có một vài lý do để email không thành công bằng cách tiếp cận người dùng của nó.

Dưới đây là một vài điểm khác gây ra lỗi:

• Máy chủ email bị tắt trong một thời gian dài
• Thuật toán tìm đường ngắn để tiếp cận người dùng không hoạt động chính xác và mất rất nhiều thời gian để tiếp cận người dùng, bởi thời gian đó có thể nó đã vượt qua thời gian xác định để tiếp cận người dùng. Điều này thường được gọi là tăng số bước nhảy
• Miền email của người dùng đã giảm trong một thời gian dài
• Tài khoản của người dùng cho ứng dụng không được kích hoạt để nhận email

Định vị phạm vi đối với kiểm thử email

Khi ứng dụng hỗ trợ nhiều ngôn ngữ, do đó sự hỗ trợ này cũng sẽ mở rộng cho email.

Tất cả các Email gửi đi phải sử dụng ngôn ngữ của người sử dụng. Nếu người dùng đã cài đặt tiếng Anh làm ngôn ngữ, thì tất cả các email gửi cho anh ta / cô ấy phải bằng tiếng Anh. Nếu ngôn ngữ cài đặt của người dùng là tiếng Pháp, thì tất cả các email được gửi cho người đó phải bằng tiếng Pháp. Ngôn ngữ của người dùng có thể là cài đặt một lần hoặc có thể thay đổi theo thời gian và khi được yêu cầu, tùy thuộc vào cài đặt của ứng dụng.

Email phải được gửi bằng ngôn ngữ mà người dùng có ở điểm nó được kích hoạt.

Các điểm xác nhận hợp lệ cho việc bản địa hóa kiểm tra Email là như sau:

• Dòng chủ đề
• Phần thân của Email
  • Nội dung - văn bản của phần thân emai;
  • Tên / tên nút liên kết
  • Thông tin bản quyền
  • Chi tiết hỗ trợ khách hàng.

Tiêu chuẩn/Tuỳ chỉnh email

Email có thể được tùy chỉnh ở backend.

Ví dụ: vài ứng dụng hỗ trợ người dùng tùy chỉnh email khi chúng được gửi đi. Người dùng có thể thay đổi ở đây dòng chủ đề và / hoặc nội dung của email thuận tiện hoặc nhằm mục đích dễ dàng nhận ra. Trong trường hợp này, đội thử nghiệm phải tiến hành kiểm tra kỹ lưỡng vì cơ hội xâm nhập là cao.

Thử nghiệm phải được thực hiện để tiêm - gửi mã HTML, mã Java, SQL, vv Tất cả những điều này sẽ không thành công để tăng mức độ bảo mật. Nếu ứng dụng không hỗ trợ tuỳ chỉnh email, tất cả các email được gửi sẽ tuân theo chủ đề / cơ thể tiêu chuẩn do một ứng dụng đặt.

Phần kết luận

Kiểm thử email là một hoạt động quan trọng vì hầu hết các thành phần của ứng dụng được tích hợp với chức năng này.

Nó phải là sự hỗ trợ của cả nhóm và nỗ lực để kiểm tra toàn bộ chức năng email của ứng dụng. Cần phải có kế hoạch tốt trước khi bắt đầu thực hiện kiểm thử thực tế và nên thực hiện cùng lúc với từng thành phần / phần liên quan.

Kiểm tra Email nên có các trường hợp kiểm thử riêng biệt được viết cho mỗi loại Email bao gồm tất cả các khía cạnh để kiểm tra. Điều này cần được thực hiện trong tất cả các loại thử nghiệm Kiểm thử hồi quy, kiểm thử Adhoc, kiểm thử Localization, kiểm thử UAT, và kiểm thử trên Production.

Nếu cóbất cứ điều gì sai sót nào đối với chức năng Email này, sẽ để lại ấn tượng xấu về ứng dụng, khách hàng và cuối cùng, nó mang đến ấn tượng xấu cho người kiểm tra ứng dụng đó. Vì vậy, Xác nhận Email là hoạt động rất quan trọng và rất cần thiết trong Kiểm thử phần mềm.

Nguồn dịch: http://www.softwaretestinghelp.com/email-validation-testing/