Kiểm thử cài đặt
Một kiểm thử cài đặt đảm bảo rằng hệ thống được cài đặt đúng và hoạt động tại phần cứng thực tế của thiết bị.
Kiểm thử khả năng tương thích
Một nguyên nhân phổ biến của lỗi phần mềm (thực tế hay nhận thức) là thiếu khả năng tương thích với các hệ điều hành hoặc phần mềm ứng dụng khác (có thể là các phiên bản cũ hay mới của hệ điều hành), hoặc môi trường mục tiêu khác nhau rất nhiều so với bản gốc (chẳng hạn như một thiết bị đầu cuối hoặc ứng dụng giao diện dùng để chạy trên máy tính để bàn hiện nay đang được yêu cầu để trở thành một ứng dụng web, trong đó phải thực hiện trong một trình duyệt web). Ví dụ, trong trường hợp thiếu tính tương thích ngược có thể xảy ra bởi vì các lập trình viên chỉ phát triển và kiểm thử phần mềm trên phiên bản mới nhất của môi trường mục tiêu, mà không phải tất cả người dùng có thể chạy. Điều này dẫn đến hậu quả không lường được rằng các chức năng mới nhất có thể không hoạt động trong các phiên bản trước đây của môi trường mục tiêu nhưng lại có thể chạy được với phần cứng cũ hơn và phiên bản trước trước đó của môi trường mục tiêu. Đôi khi các vấn đề như vậy có thể được cố định bằng cách chủ động trừu tượng hóa chức năng hệ điều hành vào một Module chương trình riêng biệt hoặc thư viện.
Smoke & Sanity Testing
Sanity Testing xác định tính hợp lý để tiến hành các kiểm thử khác.
Smoke Testing được sử dụng để xác định xem có vấn đề nghiêm trọng với bộ phận của phần mềm, ví dụ như một bài kiểm thử xác minh khi xây dựng phần mềm.
Kiểm thử hồi quy
Kiểm thử hồi quy tập trung vào việc tìm kiếm lỗi sau khi xảy ra một thay đổi mã chính. Cụ thể, nó tìm cách phát hiện ra các hồi quy của phần mềm hoặc các lỗi cũ quay trở lại. Những hồi quy như vậy xảy ra bất cứ khi nào chức năng phần mềm trước đây đang hoạt động giờ tạm ngưng như đã định. Thông thường, những hồi quy xảy ra như một hệ quả không lường trước được những thay đổi chương trình, khi một phần mới của phần mềm được phát triển xung đột với mã tồn tại trước đó. Phương pháp phổ biến của kiểm thử hồi quy bao gồm chạy lại những kiểm thử trước đó và kiểm thử xem lỗi cố định trước đây tại sao lại xuất hiện. Độ sâu của kiểm thử phụ thuộc vào các nguy cơ và giai đoạn trong quá trình phát hành các tính năng bổ sung. Chúng có thể được hoàn tất khi thay đổi thêm vào đầu hoặc cuối bản phát hành, cũng có thể được có mức độ nguy hiểm thấp khi thực hiện kiểm thử tích cực trên mỗi tính năng.
Ví dụ: một PM đang phát triển khi kiểm tra cho thấy nó chạy tốt các chức năng A, B và C. Khi có thay đổi code của chức năng C, nếu chỉ kiểm tra chức năng C thì chưa đủ, cần phải kiểm tra lại tất cả các chức năng khác liên quan đến chức năng C, trong ví dụ này là A và B. Lý do là khi C thay đổi, nó có thể sẽ làm A và B không còn làm việc đúng nữa.
Mặc dù không là một mức kiểm tra, thực tế lại cho thấy Regression Test là một trong những loại kiểm tra tốn nhiều thời gian và công sức nhất. Tuy thế, việc bỏ qua Regression Test là “không được phép” vì có thể dẫn đến tình trạng phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng, mặc dù ta “tưởng rằng” những lỗi đó hoặc không có hoặc đã được kiểm tra và sửa chữa rồi!
Kiểm thử mức chấp nhận
Kiểm thử mức chấp nhận được hiểu theo một trong hai nghĩa sau:
- Một Smoke Testing được sử dụng như một bài kiểm thử mức chấp nhận trước khi giới thiệu một bản built mới để thực hiện tiến trình kiểm thử chính, tức là trước khi thực hiện kiểm thử tích hợp hoặc hồi quy.
- Kiểm thử mức chấp nhận do khách hàng thực hiện trong môi trường thí nghiệm riêng với những thiết bị phần cứng của họ, nó còn được biết đến như là kiểm thử mức độ chấp nhận của người dùng (UAT). Kiểm thử mức chấp nhận còn được thực hiện như là một phần của quá trình chuyển giao (hand-off) giữa hai pha của quá trình phát triển phần mềm.
Kiểm thử Alpha
Kiểm thử Alpha là việc kiểm thử hoạt động chức năng thực tế hoặc giả lập do người dùng/khách hàng tiềm năng hoặc một nhóm Tester độc lập thực hiện tại nơi sản xuất phần mềm. Kiểm thử Alpha thường được sử dụng cho phần mềm đại trà (đóng gói sẵn để bán) như là một hình thức kiểm thử mức chấp nhận nội bộ trước khi phần mềm chính thức đi vào giai đoạn kiểm thử Beta.
Kiểm thử Beta
Kiểm thử phiên bản Beta được đưa ra sau khi kiểm thử Alpha và có thể được coi là một hình thức mở rộng của kiểm thử mức chấp nhận của người dùng. Các phiên bản của phần mềm, gọi là phiên bản beta, được phát hành cho một đối tượng hạn chế bên ngoài của nhóm lập trình. Phần mềm này được phát hành cho nhiều nhóm người dùng để kiểm thử nhiều hơn nữa và nó có thể đảm bảo sản phẩm có ít thiếu sót và lỗi. Đôi khi, các phiên bản beta được phát hành rộng rãi để tăng phạm vi phản hồi thông tin từ một số lượng tối đa người dùng trong tương lai.
Kiểm thử chức năng và phi chức năng
Chức năng kiểm thử liên quan đến các hoạt động xác minh một hành động cụ thể hoặc chức năng của các mã. Đó là những điều được tìm thấy trong các tài liệu yêu cầu, mặc dù có một số phương pháp phát triển được làm từ các câu chuyện của người dùng. Kiểm thử chức năng nhằm trả lời cho câu hỏi “người dùng có hay không làm được với tính năng cụ thể này”.
Kiểm thử phi chức năng đề cập đến các khía cạnh của phần mềm có thể không liên quan đến một chức năng cụ thể hoặc hành động người dùng, chẳng hạn như khả năng mở rộng và hiệu suất khác, hành vi dưới những hạn chế hoặc bảo mật nhất định. Việc kiểm thử sẽ xác định điểm cuộn mà tại đó khả năng mở rộng và thực hiện của các điểm cực trị hoạt động không ổn định. Những yêu cầu phi chức năng thường là những phản ánh về chất lượng của sản phẩm, đặc biệt là trong bối cảnh các quan điểm phù hợp của người sử dụng nó.
Kiểm thử sự phá hủy
Kiểm thử sự phá hủy cố gắng làm hỏng phần mềm hoặc một hệ thống con. Nó xác minh rằng các phần mềm có chức năng đúng ngay cả khi nó nhận được đầu vào không hợp lệ hoặc không mong muốn, do đó tạo ra sự vững mạnh của xác nhận đầu vào và thói quen quản lý các lỗi. Chèn lỗi phần mềm ở dạng mờ nhạt là một ví dụ về kiểm thử thất bại. Các công cụ kiểm thử phi chức năng thương mại được liên kết từ các trang chèn lỗi phần mềm mà ở đó có sẵn vô số các mã nguồn mở và các công cụ miễn phí để thực hiện kiểm thử sự phá hủy phần mềm.
Kiểm thử hiệu suất phần mềm
Kiểm thử hiệu suất thường được chạy để xác định một hệ thống hay hệ thống con thực hiện như thế nào về độ nhạy và tính ổn định theo một khối lượng công việc cụ thể. Nó cũng có thể dùng để điều tra, đánh giá, xác nhận hoặc xác minh các thuộc tính chất lượng khác của hệ thống, chẳng hạn như khả năng mở rộng, độ tin cậy và sử dụng tài nguyên.
Kiểm thử lượng tải chủ yếu liên quan đến việc kiểm thử hệ thống có thể tiếp tục hoạt động dưới một lượng tải cụ thể, cho dù đó là một lượng lớn dữ liệu hoặc một số lượng lớn người sử dụng. Điều này thường được gọi là khả năng mở rộng phần mềm. Các hoạt động kiểm thử lượng tải có liên quan khi thực hiện như một hoạt động phi chức năng thường được gọi là kiểm thử sức chịu đựng.
Kiểm tra khối lượng là một cách để kiểm tra các chức năng của phần mềm ngay cả khi một số thành phần (ví dụ như một tập tin hoặc cơ sở dữ liệu) tăng triệt để kích thước. Kiểm thử độ căng là một cách để kiểm tra độ bền đột xuất hoặc ít gặp theo khối lượng công việc.
Kiểm thử tính ổn định (thường được tham chiếu lượng tải và kiểm thử độ bền) giúp kiểm tra xem phần mềm có thể hoạt động tốt liên tục trong hoặc trên một chu kỳ chấp nhận được. Có rất ít quy ước về các mục tiêu cụ thể của kiểm thử hiệu suất như là: Các thuật ngữ lượng tải, kiểm thử hiệu suất, kiểm thử tính mở rộng và kiểm thử khối lượng, thường được sử dụng thay thế cho nhau.
Hệ thống phần mềm thời gian thực có những ràng buộc chính xác thời gian. Để kiểm thử những ràng buộc thời gian được đáp ứng thì người ta dùng phương pháp kiểm thử thời gian thực.
Kiểm thử tính khả dụng
Kiểm tra tính khả dụng là rất cần thiết để kiểm tra xem giao diện có tiện dụng và dễ hiểu với người dùng không, nó liên quan trực chủ yếu đến năng lực sử dụng của ứng dụng.
Kiểm thử khả năng tiếp cận
Kiểm thử khả năng tiếp cận bao gồm việc tuân thủ các tiêu chuẩn sau:
- Người Mỹ với Đạo luật bất khả thi năm 1990
- Mục 508 sửa đổi của đạo luật Phục hồi năm 1973.
- Sáng kiến tiếp cận Web (WAI) của World Wide Web Consortium (W3C).
Kiểm thử bảo mật
Kiểm thử bảo mật phần mềm là rất cần thiết trong việc xử lý dữ liệu mật và ngăn chặn các hacker xâm nhập hệ thống.
Tính toàn cầu và bản địa hóa
Khả năng tổng quát của phần mềm được toàn cầu và bản địa hóa có thể được tự động kiểm tra mà không dịch thực tế, bằng cách sử dụng phương thức giả bản địa. Nó sẽ xác minh rằng các ứng dụng vẫn hoạt động, ngay cả sau khi nó đã được dịch sang một ngôn ngữ mới hoặc thích nghi với một nền văn hóa mới (chẳng hạn như tiền tệ và múi giờ khác nhau).
Việc thực dịch ra nhiều ngôn ngữ phải được kiểm tra. Sự cố bản địa hóa có thể bao gồm:
- Phần mềm thường được bản địa hóa bằng cách dịch một danh sách các chuỗi ra khỏi bối cảnh, và người dịch có thể chọn dịch sai đối với một chuỗi mã nguồn không rõ ràng.
- Thuật ngữ kỹ thuật có thể trở nên không phù hợp nếu dự án được phiên dịch bởi một số người phối hợp không tốt hoặc nếu người dịch thiếu thận trọng.
- Những bản dịch từ ngữ theo nghĩa đen có vẻ không phù hợp, giả tạo hoặc quá kỹ thuật trong mục tiêu ngôn từ.
- Thông điệp chưa được dịch bằng ngôn ngữ gốc có thể khó mã hoá trong mã nguồn.
- Một số thông điệp có thể được tạo ra tự động tại thời gian chạy và chuỗi kết quả có thể là sai ngữ pháp và chức năng không chính xác, dễ gây hiểu lầm hoặc khó hiểu.
- Phần mềm có thể sử dụng một phím tắt mà không có chức năng trên layout phím ngôn ngữ nguồn nhưng lại được sử dụng để gõ ký tự trên layout ngôn ngữ mục tiêu.
- Phần mềm có thể thiếu hỗ trợ cho các ký tự mã hóa của ngôn ngữ mục tiêu.
- Phông chữ và kích thức chữ có thể phù hợp trong ngôn ngữ nguồn nhưng có thể không phù hợp trong ngôn ngữ mục tiêu. Ví dụ, ký tự CJK có thể không đọc được nếu font chữ quá nhỏ.
- Một chuỗi trong ngôn ngữ mục tiêu có thể kéo dài hơn so với các xử lý của phần mềm. Điều này có thể làm cho một phần chuỗi bị ẩn đi với người dùng và gây ra một số va chạm hoặc sự cố với phần mềm.
- Phần mềm có thể thiếu hỗ trợ thích hợp cho việc đọc hoặc viết văn bản hai chiều.
- Phần mềm có thể hiển thị hình ảnh với văn bản mà không được bản địa hóa.
- Những hệ điều hành bản địa có thể khác nhau trong cách đặt tên các file cấu hình hệ thống, các biến môi trường và các định dạng khác nhau cho ngày tháng và tiền tệ.
Kiểm thử sự phát triển
Kiểm thử sự phát triển là một tiến trình phát triển phần mềm có liên quan đến ứng dụng đồng bộ của một loạt các chiến lược phòng ngừa phát hiện lỗi và để giảm thiểu rủi ro về thời gian và chi phí. Nó được thực hiện bởi các kỹ sư hoặc các nhà phát triển trong giai đoạn xây dựng vòng đời phát triển phần mềm. Không chỉ thay thế các trọng tâm QA truyền thống mà phải bổ sung nó. Kiểm thử sự phát triển nhằm mục đích loại bỏ những lỗi xây dựng trước khi mã được đẩy mạnh QA, chiến lược này là nhằm nâng cao chất lượng của phần mềm cũng như hiệu quả của sự phát triển chung và cả quá trình QA.
Tùy thuộc vào kỳ vọng của tổ chức phát triển phần mềm, kiểm tra phát triển có thể bao gồm phân tích mã tĩnh, phân tích luồng dữ liệu, phân tích số liệu, đánh giá mã cân bằng, kiểm thử đơn vị, phân tích mã bao phủ, truy xuất nguồn gốc, và các thực hành xác minh phần mềm khác.
Kiểm thử A/B
Kiểm thử A/B là một phương pháp sử dụng trong quảng cáo được thí nghiệm ngẫu nhiên với hai biến thể A và B, trong đó có sự kiểm soát và điều trị trong các kiểm thử có kiểm soát. Những thí nghiệm này thường được sử dụng trong phát triển web và tiếp thị, cũng như trong nhiều hình thức quảng cáo truyền thống.
(Tham khảo: wikipedia.org)
