Kiểm tra xác thực Email: Cách kiểm tra chức năng Email của một ứng dụng

Với đa số các ứng dụng web hoặc mobile, chức năng xác thực email được coi như 1 trong những phần quan trọng nhất cần kiểm thử, để đảm bảo chức năng email hoạt động tốt với phần còn lại của hệ thống.

Việc sử dụng email với nhiều kịch bản được coi là đã kiểm tra khi tất cả các thành phần của nó bao gồm: template của email, link/button trong email, người gửi, người nhận, cc, bcc, file đính kèm, nội dung của email,...đều đã được kiểm tra.

Tại sao chúng ta cần kiểm thử email

Mỗi thành phần của hệ thống (Web/Mobile) có thể có mục đích gửi email khác nhau. Việc kết nối giữa các thành phần với email đóng vai trò sống còn để tiếp cận với người dùng cuối với những thông báo phù hợp. Bất kỳ sự cẩu thả khi kiểm tra chức năng này đều dẫn đến sự hiểu sai đối với khác hàng, hacking, ... Ví dụ, giả sử một tình huống khi 1 người dùng nhận được email để reset mật khẩu. Sẽ thế nào nếu như link/Button Khôi phục Mật khẩu hoặc đường Link được cho để sao chép vào trình duyệt không hoạt động? Chỉ còn 1 lựa chọn duy nhất đó là liên hệ với bộ phận Hỗ trợ khách hàng, điều này có thể dẫn đến những vấn đề tệ hơn hoặc nếu như người dùng liên tục nhận được email hàng ngày liên quan đến hạn thanh toán của một hoá đơn từ 10-15 ngày trước hoặc nhận được nhắc nhở sau khi hạn cuối đã qua - Thực sự sẽ phát điên nhỉ?

Có rất nhiều kịch bản trong đó email trở thành một phần cuộc sống của chúng ta khi chúng giữ cho người dùng luôn có được những thông tin chính xác mới nhất.

Các kịch bản thời gian thực và các điểm cần xác thực với Email Các điểm cần xác thực với trong kiểm thử Email rất đa dạng tuỳ từng loại và khác nhau với từng ứng dụng cụ thể. Nhưng nhìn chung, email cần được kiểm tra về Template (bao gồm logo của ứng dụng, tên ứng dụng, địa chỉ người dùng, nội dung footer - copyright, thông tin hỗ trợ khác hàng), ngày tháng và thời gian với ứng múi giờ.

Ở đây chúng ta sẽ trao đổi về một vài loại Email phổ biến mà mọi người đều quan tâm đến (tất cả các điểm cần xác thực đưa ra dưới đây đều là các kiểm tra cơ bản mà tester phải thực hiện khi kiểm tra chức năng email).

1) Kích hoạt Email

Khi một người dùng đăng ký ứng dụng lần đầu tiên, người đó cần phải kích hoạt tài khoản bằng cách click vào một đường link kích hoạt trong email. VIệc này cũng xác thực luôn địa chỉ Email mà người dùng cung cấp ban đầu. Các điểm cần xác thực:

• Link/Button kích hoạt: khi click vào thì:
  • đưa người dùng đến trang ứng dụng tương ứng và với trạng thái đã đăng nhập.
  • Email của người dùng được coi là đã verified một các tự động
• Thời hạn - Kiểm tra thời hạn cho phép link có thể được xác thực thành công
  • Xác thực trong thời gian cho phép
  • Thử xác thực sau thời gian cho phép - Tài khoản nên vẫn bị coi là chưa được kích hoạt và email cũng coi như chưa được kiểm chứng.

2) Khôi phục mật khẩu Email

Khi một người dùng quên mật khẩu đăng nhập vào ứng dụng, kịch bản quên mật khẩu có thể được thực hiện để nhận được một email với link để reset mật khẩu (chức năng có thể khác nhau tuỳ ứng dụng. Đây chỉ là một phương pháp phổ biến nhất). Các điểm cần xác thực:

• Link khôi phục mật khẩu:

  • Click vào link sẽ mang người dùng đến trang ứng dụng tương ứng để khôi phục mật khẩu.
  • Một vài ứng dụng sẽ hỏi người dùng thêm các câu hỏi bảo mật trước khi hiển thị trang khôi phục mật khẩu, và một vài ứng dụng khác sẽ tích hợp câu hỏi bảo mật trong trang khôi phục mật khẩu. Một vài ứng dụng hoàn toàn không sử dụng câu hỏi bảo mật.
  • Nếu người dùng khôi phục mật khẩu thành công, Link khôi phục mật khẩu ban đầu nên huỷ bỏ và không hoạt động nữa.
  • Nếu người dùng huỷ bỏ việc khổi phục mật khẩu, link khôi phục mật khẩu đã nhận vẫn coi như đã kích hoạt.

• Thời hạn - kiểm tra thời hạn hoạt động của link khôi phục mật khẩu

  • Click vào link thành công trong thời gian cho phép
  • Thử click Link sau thời hạn cho phép - Link nên bị vô hiệu hoá

  

3) Thông báo đáo hạn

Đây là thông báo nhắc nhỏ người dùng về hành động cần thực hiện trong thời gian sắp tới. Đây thường là thanh toán hoá đơn, làm việc gì đó với các vấn đề đang có (ví dụ: chấp nhận hoặc từ chối lời mời của một event nào đó,...)

Các điểm cần xác thực:

• Số ngày của thời hạn
  • Nếu email thông báo về số ngày trước khi đến hạn, thì số ngày phải hiển thị là 0 hoặc lớn hơn 0. 0 có nghĩa ngày hiện tại chính là thời hạn. Nếu email thông báo về Thời điểm (Due Date) thì ngày tháng 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 nào cần được thực hiện. Nên đề cập rõ ràng về loại hành động mà user cần thực hiện: thanh toán hoá đơn, submit form, hay feedback, ...

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

Đây là thông báo cho user về việc thời hạn đã qua. Đó thường là thông báo với user rằng họ đã không thực hiện một hành động nào đó trong thời hạn cho phép.

• Số ngày quá hạn
  • Kiểm tra số ngày quá hạn phải là 1 hoặc nhiều hơn. Không thể là 0 hoặc số âm.
• Tần suất:
  • Một vài ứng dụng sẽ gửi thông báo quá hạn hàng ngày, hàng tuần, hàng tháng khi qua thời hạn, cho đến khi người dùng thực hiện hành động cần thiết. Một vài ứng dụng khác sẽ có một thông báo được gửi 1 lần duy nhất sau khi thời hạn vùa qua.

5) Đăng ký (Subscriptions)

Loại này đa dạng tuỳ theo yêu cầu người dùng. Người dùng có thể chọn 1 trong số các loại Hàng ngày, hàng tuần, 2 lần 1 tháng, hoặc hàng tháng. Đây thường là các thông cáo báo chí, cập nhật, offer,...

• Tần suất:
  • Email cần được gửi cho người dùng theo đúng tuỳ chọn của người dùng. Nếu hàng ngày thì email phải được gửi 1 lần 1 ngày, ...
• Link:
  • Bất kỳ link nào xuất hiện trong email phải đưa người dùng đến đúng nơi. Nếu email về cập nhật thì link phải đưa người dùng đến nơi mà update đó hiển thị.

6) Form

Email muốn nhận được feedback của người dùng thông qua form hoặc link đến form.

• Link:
  • Các link trong mail phải đưa người dùng đến form cần nhập
  • Một khi đã submit thì việc click vào link lần nữa nên thông báo cho người dùng là họ đã submit rồi. Không nên cho phép người dùng nhập lại nữa.

7) Email xác nhận:

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

• Nội dung xác nhận:
  • Số đơn hàng phải chính xác và phù hợp với số hiển thị trên ứng dụng. Vì đây là số để định danh đơn hàng/đặt chỗ, nên số này phải là duy nhất trong toàn bộ hệ thống.
  • Cùng với số, các thông tin khác cần phải đúng: loại đơn hàng, thông tin người dùng, địa chỉ thanh toán, địa chỉ nhận hàng, giá. Tất cả các thông tin này phải khớp với thông tin hiển thị trên ứng dụng.
• Links:
  • Link trong email phải đưa người dùng đến trang thông tin chi tiết của order. Thông tin phải chính xác với thông tin hiển thị trong email và ứng dụng.

8) Bản sao trao đổi qua chat

Ở đây, người dùng nhận được toàn bộ nội dung trao đổi qua chat dưới dạng email. Loại này thường được gửi đi sau khi phiên Live Chat với hỗ trợ khách hàng kết thúc.

• Chi tiết:
  • Kiểm tra tên người hỗ trợ. Kiểm tra toàn bộ nội dung chat được hiển thị trong email cùng với người gửi của từng đoạn hội thoại (Tên người, ngày tháng, thời gian gửi,...)

9) Email có file đính kèm

Khi người dùng nhận được email với file đính kèm, các file đính kèm có thể được bảo mật hoặc không. Thường thì đó là báo cáo tài chính, thoả thuận người dùng để tham khảo,...

• Loại file đính kèm:
  • Có nhiều loại file có thể đính kèm. Tất cả các file đính kèm phải được mở thông qua một máy quét virus trước khi tải về hoặc mở ra. Tính năng này cũng tuỳ từng loại ứng dụng.
  • Với file có bảo mật, thì phải có thể tải về thành công mà không bị hỏi mật khẩu. Nhưng khi mở file từ email hoặc mở file sau khi tải về thì phải luôn yêu cầu mật khẩu.

Các loại email:

Email có thể là HTML (với nhiều màu sắc và hấp dẫn người dùng, thôi thúc họ xem email ở dạng đầy đủ) hoặc là chỉ có text. HTML thường được dùng nhiều hơn và thường được đặt là mặc định cho đa số các ứng dụng. Nếu cần thiết, ứng dụng có thể gửi email dạng plain text cho người dùng.

Các điểm kích hoạt email:

Email có thể được gửi ngay lập tức hoặc như là tóm tắt sau này. Những email gửi ngay thường được kích hoạt bởi một hành động nào đó của người dùng. Đó thường là các email kích hoạt, khôi phục mật khẩu, chat, xác nhận.... Các mail tổng hợp thường được kích hoạt tuỳ vào tuỳ chọn của ứng dụng.

Các điểm kích hoạt email được định nghĩa để kích hoạt gửi mail tại một thời điểm cụ thể (ví dụ: ngày thứ 3 hàng tuần, lúc 12:00 AM). Đó thường là các email báo cáo tài chính, thông báo đáo hạn,...

Email bị trả lại

Một kịch bản thường gặp là email bị trả về khi gửi đến 1 địa chỉ không hợp lệ. Thường thì địa chỉ email đã bị vô hiệu hoá, không còn sử dụng hoặc không hề tồn tại. Thường server sẽ cố gửi lại một vài lần. Khi nó không thể gửi được đến địa chỉ đó, thì nó sẽ báo lại và đánh dấu là việc gửi thất bại. sẽ có một server khác xử lý với những email thất bại này, và thường được gọi là bounce back server. Có nhiều nguyên nhân dẫn đến việc email không thể gửi đi được

• Email server bị down.
• thuật toán tìm đường đến user không hoạt động đúng và mất quá nhiều thời gian, dẫn đến quá hạn thời gian cho phép.
• domain của email của user bị down.
• Account của user không được phép nhận email.

Kiểm thử email với đa ngôn ngữ.

Khi ứng dụng hỗ trợ đa ngôn ngữ, thì email cũng nên hỗ trợ. Tất cả các email gửi đi phải đúng với ngôn ngữ mà người dùng sử dụng. Nếu người dùng chọn tiếng Anh thì mọi email đều phải là tiếng Anh. Ngôn ngữ người dùng sử dụng có thể chỉ thiết lập 1 lần hoặc nhiều lần tuỳ tứng loại ứng dụng. Email gửi đi phải đúng với ngôn ngữ mà người dùng đang xử dụng tại thời điểm phát sinh email. Một vài điểm cần xác thực:

• Tiêu đề email
• Nội dung email:
  • Nội dung
  • Tên link/button
  • Thông tin copyright
  • Thông tin hỗ trợ khác hàng.

#Email chuẩn / Tuỳ biến Email có thể tuỳ biến ở backend. Ví dụ, một vài ứng dụng cho phép người dùng tuỳ biến email khi gửi đi. Người dùng có thể thay đổi tiêu đề hoặc nội dung email theo ý họ cho phù hợp với mục đích. Trong trường hợp này, việc kiểm thử phải được thực hiện bởi test team Việc kiểm thử nên bao gồm: Chèn HTML code, java code, sql,.. tất cả những điều đó cần không được phép để đảm bảo tính bảo mật. Nếu ứng dụng không hỗ trợ tuỳ biến email thì tất cả các email gửi đi phải theo chuẩn

Kết luận

Kiểm thử email là một hoạt động quan trọng khi hầu hết các thành phần của ứng dụng đều sử dụng tính năng này. Cần phải có sự hỗ trợ của cả team trong việc kiểm thử hoàn thiện chức năng email. Việc này cần phải được lên kế hoạch chính xác trước khi băt đầu kiểm thử và thống nhất với ứng thành phần liên quan. Kiểm thử email nên được tách thành test case riêng cho từng loại email để bao gồm đủ các khía cạnh cần test. Cần thực hiện tất cả các loại Test: regression testing, adhoc testing, localization testing, UAT testing và production testing. Bất kỳ sai sót nào với email trong thời gian thực sẽ để lại ấn tượng xấu với khác hàng về ứng dụng.

Link nguồn: http://www.softwaretestinghelp.com/email-validation-testing/