Kiểm thử phần mềm

Tổng quan

Kiểm thử không thể xác định hoàn toàn được tất cả các lỗi bên trong phần mềm. Thay vào đó, nó so sánh trạng thái và hành vi của sản phẩm với các oracle - các nguyên tắc hay cơ chế để phát hiện vấn đề. Các oracle này có thể bao gồm (nhưng không giới hạn ở) các đặc tả phần mềm, hợp đồng, sản phẩm tương đương, các phiên bản trước của cùng một sản phẩm, phù hợp với mục đích dự kiến nhằm đáp ứng sự kỳ vọng của người dùng, khách hàng, quy định của pháp luật hiện hành và các tiêu chuẩn liên quan khác.
Mục đích chính của kiểm thử là phát hiện ra các lỗi phần mềm để từ đó khắc phục và sửa chữa. Việc kiểm thử không thể khẳng định được rằng các chức năng của sản phẩm đúng trong mọi điều kiện, mà chỉ có thể khẳng định rằng nó không hoạt động đúng trong những điều kiện cụ thể. Phạm vi của kiểm thử phần mềm thường bao gồm việc kiểm tra mã, thực hiện các mã trong môi trường và điều kiện khác nhau, và việc kiểm thử các khía cạnh của mã: nó có làm đúng nhiệm vụ của nó hay không, và nó có làm những gì cần phải làm hay không. Trong môi trường phát triển phần mềm hiện nay, một đội kiểm thử có thể tách biệt với đội phát triển. Các thành viên trong đội kiểm thử giữ các vai trò khác nhau. Các thông tin thu được từ kiểm thử có thể được sử dụng để điều chỉnh quá trình phát triển phần mềm.
Mỗi sản phẩm phần mềm có một đối tượng phục vụ riêng. Ví dụ như đối tượng của phần mềm trò chơi điện tử là hoàn toàn khác với đối tượng của phần mềm ngân hàng. Vì vậy, khi một tổ chức phát triển hoặc đầu tư vào một sản phẩm phần mềm, họ có thể đánh giá liệu các sản phẩm phần mềm có được  chấp nhận bởi người dùng cuối,  đối tượng phục vụ, người mua, hay những người giữ vai trò quan trọng khác hay không. Và việc kiểm thử phần mềm là một quá trình nỗ lực để đưa ra những đánh giá này.

Khiếm khuyết và thất bại

Không phải tất cả các khiếm khuyết của phần mềm bị gây ra bởi lỗi lập trình mà cội nguồn chung của các khiếm khuyết đó nằm ở những thiếu sót trong yêu cầu; ví dụ, yêu cầu không được xác nhận mà gây ra lỗi là sự sơ suất của các nhà thiết kế của chương trình. Những thiếu sót yêu cầu thường thấy trong những yêu cầu phi chức năng như là khả năng kiểm thử, khả năng mở rộng, bảo trì, tính khả dụng, hiệu suất, và khả năng bảo mật.
Lỗi phần mềm xảy ra thông suốt quá trình như sau: Một lập trình viên làm cho một lỗi (sai lầm), mà kết quả cho ra là một khiếm khuyết (thất bại, sai sót) trong mã nguồn phần mềm. Nếu lỗi này được thực hiện, trong những tình huống nhất định hệ thống sẽ tạo ra kết quả sai, gây ra một sự thất bại. Không phải tất cả các khiếm khuyết nhất thiết sẽ dẫn đến thất bại. Ví dụ, lỗi trong mã chết sẽ không bao giờ dẫn đến thất bại. Lỗi có thể biến thành một sự thất bại khi môi trường thay đổi. Ví dụ về những thay đổi trong môi trường bao gồm các phần mềm đang chạy trên một nền tảng phần cứng máy tính mới, thay đổi trong nguồn dữ liệu, hoặc tương tác với các phần mềm khác nhau. Một khiếm khuyết duy nhất có thể dẫn đến một loạt các dấu hiệu thất bại.

Kết nối đầu vào và điều kiện tiền đề

Một vấn đề rất cơ bản với kiểm thử phần mềm là việc kiểm thử tất cả các kết nối đầu vào và điều kiện tiền đề (trạng thái ban đầu) là không khả thi, ngay cả với một sản phẩm đơn giản. Điều này có nghĩa rằng số lượng các khiếm khuyết trong một sản phẩm phần mềm có thể rất lớn và có thể xảy ra thường xuyên nên rất khó để tìm thấy trong quá trình kiểm thử. Quan trọng hơn, những yêu cầu phi chức năng về chất lượng (làm nó như thế nào hơn là làm được gì?) như: tính khả dụng, khả năng mở rộng, hiệu suất, khả năng tương thích, độ tin cậy nếu xét về mặt chủ quan thì nó chưa tạo nên giá trị đủ để mọi người có thể chấp nhận được nó.
Các nhà phát triển phần mềm không thể kiểm thử được tất cả mọi thứ, nhưng họ có thể sử dụng tổ hợp thiết kế kiểm thử để xác định số lượng tối thiểu của các kiểm thử cần thiết để bao quát được những điều họ muốn. Dù là kiểm thử tốc độ hay độ sâu thì họ có thể sử dụng phương pháp này để xây dựng được những cơ cấu khác nhau trong từng trường hợp kiểm thử (test case) cụ thể.

Vai trò

Kiểm thử phần mềm được thực hiện bởi  nhiều Tester. Cho đến những năm 1980, thuật ngữ "nhân viên kiểm thử phần mềm" đã được sử dụng thường, nhưng sau đó cũng được coi là một nghề riêng biệt. Liên quan đến các giai đoạn và các mục tiêu khác nhau trong kiểm thử phần mềm thì những vai trò khác nhau đã được thiết lập cho các nhà quản lý, trưởng nhóm kiểm thử, nhà phân tích kiểm thử, nhà thiết kế kiểm thử, Tester, nhà phát triển tự động hóa và quản trị viên kiểm thử.

Kiểm thử tĩnh và động

Có rất nhiều phương pháp để kiểm thử phần mềm. Đánh giá, định hướng hoặc kiểm tra được gọi là kiểm thử tĩnh, trong khi việc chạy mã lập trình thực tế trong các tình huống được gọi là kiểm thử động. Kiểm thử tĩnh thông thường có thể được bỏ qua khi thực hành nhưng kiểm thử động diễn ra khi bản thân chương trình đó đang được sử dụng. Kiểm thử động có thể bắt đầu trước khi chương trình đã hoàn tất 100% để kiểm thử các phần cụ thể của mã và được áp dụng cho các chức năng riêng biệt hoặc Module. Kỹ thuật điển hình cho điều này được sử dụng trong cả mạch nhánh/trình điều khiển hoặc được thực hiện trong một môi trường gỡ lỗi nhất định.
Kiểm thử tĩnh liên quan đến việc kiểm chứng trong khi kiểm thử động liên quan đến việc xác nhận. Nó đều cùng giúp cải thiện chất lượng phần mềm.

Phương pháp thăm dò

Theo truyền thống thì các phương pháp kiểm thử phần mềm được bắt nguồn từ kiểm thử hộp trắng và hộp đen. Có hai cách tiếp cận được sử dụng để mô tả quan điểm của một kỹ sư kiểm thử khi thiết kế các Test Case.

Kiểm thử trực quan

Mục đích của kiểm thử trực quan là cung cấp các nhà phát triển khả năng kiểm soát những gì đang xảy ra tại thời điểm phần mềm thất bại theo cách mà họ có thể nhìn thấy thông tin được yêu cầu rõ ràng và dễ hiểu nhất.
Cốt lõi của kiểm thử trực quan là ý tưởng giúp ai đó nhận ra được một vấn đề (hoặc một kiểm thử thất bại) thay vì chỉ mô tả nó từ đó giúp cho sự rõ ràng và hiểu biết tăng lên đáng kể. Kiểm thử trực quan vì thế luôn yêu cầu phải ghi lại toàn bộ tiến trình kiểm thử – chụp lại tất cả mọi thứ xảy ra trên hệ thống ở định dạng video. Các video đầu ra được bổ sung bằng thời gian kiểm thử thực tế đầu vào thông qua hình ảnh từ webcam và âm thanh từ micro.
Kiểm thử trực quan cung cấp một số lợi thế như: Chất lượng của giao tiếp được tăng lên đáng kể bởi các Tester có thể giúp cho nhà phát triển nhìn rõ được vấn đề xảy ra (và các sự kiện dẫn đến nó) chứ không phải chỉ mô tả chung chung nó và cần phải sửa chữa các lỗi này để nó không còn tồn tại trong nhiều trường hợp khác nữa. Các nhà phát triển sẽ có tất cả các bằng chứng được yêu cầu trong bài kiểm thử lỗi và có thể tập trung vào các nguyên nhân gây ra lỗi cũng như làm thế nào để cố định được nó.
Kiểm thử trực quan đặc biệt rất phù hợp cho các môi trường mà triển khai theo phương pháp AGILE trong phát triển phần mềm đòi hỏi việc giao tiếp tốt hơn giữa các Tester và các nhà phát triển cũng như sự cộng tác giữa các nhóm nhỏ với nhau.
Kiểm thử Ad hoc và kiểm thử thăm dò là những phương pháp quan trọng để kiểm thử tình trạng nguyên vẹn của phần mềm bởi chúng đòi hỏi chuẩn bị thời gian để thực thi ít hơn trong khi các lỗi quan trọng phải được tìm thấy một cách nhanh chóng. Trong kiểm thử Ad hoc thì địa điểm kiểm thử là một vị trí không định trước và với khả năng của một công cụ kiểm thử trực quan giúp ghi lại tất cả những gì xảy ra trên một hệ thống đều trở nên rất quan trọng.
Kiểm thử trực quan là tập trung nhận diện kiểm thử sự chấp nhận của khách hàng và tính khả dụng của phần mềm bởi vì kiểm thử này có thể do nhiều cá nhân liên quan sử dụng trong quá trình phát triển. Đối với khách hàng, nó trở nên dễ dàng để cung cấp các báo cáo lỗi chi tiết và thông tin phản hồi còn đối với người sử dụng chương trình thì kiểm thử trực quan có thể ghi lại hành động của người dùng trên màn hình như tiếng nói và hình ảnh của họ để cung cấp một bức tranh hoàn chỉnh tại thời điểm phần mềm thất bại cho các nhà phát triển.

Kiểm thử hộp xám

Kiểm thử hộp xám liên quan đến hiểu biết về cấu trúc dữ liệu bên trong và các thuật toán cho mục đích của các bài kiểm thử thiết kế. Khi thực hiện những bài kiểm thử với User hoặc mức độ hộp đen, Tester không nhất thiết phải truy cập vào mã nguồn của phần mềm. Ta có thể thao tác với dữ liệu đầu vào và định dạng đầu ra không xác định như hộp xám bởi vì đầu vào và đầu ra rõ ràng ở bên ngoài của "hộp đen" mà chúng được hệ thống gọi ra trong quá trình kiểm thử. Sự phân biệt này là đặc biệt quan trọng khi tiến hành kiểm thử tích hợp giữa hai Module được viết mã bởi hai nhà phát triển khác nhau, mà ở đó chỉ có các giao diện được bộc lộ ra để kiểm thử.
Tuy nhiên, các kiểm thử mà yêu cầu thay thế một kho lưu trữ dữ liệu back-end như một cơ sở dữ liệu hoặc một tập tin đăng nhập không xác định như hộp xám, người dùng sẽ không thể thay đổi các kho lưu trữ dữ liệu trong khi sản phẩm vẫn đang  hoạt động bình thường.
Kiểm thử hộp xám cũng có thể bao gồm kỹ thuật đảo ngược để xác định đối tượng, giá trị biên hoặc các thông báo lỗi.
Khi biết được những khái niệm cơ bản về cách thức các phần mềm hoạt động như thế nào, Tester thực hiện kiểm thử phần mềm từ bên trong tốt hơn so với bên ngoài. thường, một Tester hộp xám sẽ được phép thiết lập một môi trường kiểm thử bị cô lập với các hoạt động như gieo một cơ sở dữ liệu. Các kiểm thử có thể quan sát trạng thái của sản phẩm được kiểm thử sau khi thực hiện hành động nhất định giống như việc thực hiện các câu lệnh SQL đối với cơ sở dữ liệu và sau đó thực hiện truy vấn để đảm bảo rằng những thay đổi dự kiến đã được phản ánh. Kiểm thử hộp xám thực hiện kịch bản kiểm thử thông minh, dựa trên thông tin hạn chế. Điều này sẽ đặc biệt áp dụng cho các kiểu xử lý dữ liệu, kể cả xử lý ngoại lệ, và cứ thế.

Các mức kiểm thử

Kiểm thử thường xuyên được nhóm lại theo địa điểm chúng được thêm vào trong quá trình phát triển phần mềm, hoặc do mức độ đặc hiệu của kiểm thử. Các cấp chính trong quá trình phát triển theo quy định của hướng dẫn SWEBOK là đơn vị, kiểm thử hội nhập, và kiểm thử hệ thống được phân biệt bởi các mục tiêu kiểm thử mà không ám chỉ một mô hình quy trình cụ thể. Các mức độ kiểm thử khác được phân loại theo mục tiêu kiểm thử.

Kiểm thử tích hợp

Kiểm thử tích hợp là một hình thức kiểm thử phần mềm nhằm tìm cách xác minh các giao diện giữa các thành phần xung đột của một thiết kế. Các thành phần này có thể tích hợp theo cách lặp đi lặp lại hoặc tất cả cùng nhau ("Big Bang"). Thông thường cách thức này được coi là một thực hành tốt hơn vì nó cho phép các vấn đề về giao diện được định vị một cách nhanh chóng và cố định hơn.
Kiểm thử tích hợp làm lộ ra các khiếm khuyết trong các giao diện và tương tác giữa các thành phần tích hợp (Modules). Các nhóm thành phần đã được kiểm thử lớn dần từng bước tương ứng với các thuộc tính của cấu trúc thiết kế đã được tích hợp và kiểm thử cho đến khi phần mềm hoạt động như một hệ thống.

Kiểm thử hệ thống

Kiểm thử hệ thống giúp xác minh rằng một hệ thống được tích hợp có đáp ứng đầy đủ các yêu cầu hay không. Ngoài ra, kiểm thử phần mềm phải đảm bảo rằng các chương trình hoạt động như kỳ vọng, không còn bị phá hủy hay lỗi phần nào đó trong môi trường hoạt động của nó hoặc không gặp sự cố khi hoạt động với tiến trình khác (điều này bao gồm bộ nhớ chia sẻ không bị hỏng, nguồn tài nguyên không bị dư thừa hay chiếm dụng quá mức và không bị đẩy ra khi hoạt động song song các tiến trình).

Kiểm thử mức chấp nhận

Cuối cùng hệ thống được giao cho người dùng để kiểm thử mức chấp nhận.

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ử 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ử 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.

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.

Mô hình truyền thống CMMI và mô hình phát triển thác nước

Một thực tế phổ biến trong kiểm thử phần mềm đó là các kiểm thử được thực hiện bởi một nhóm các Tester độc lập sau khi các chức năng được phát triển và trước khi nó được chuyển tới khách hàng. Thực hành này thường là kết quả trong giai đoạn kiểm thử đang được sử dụng như một bộ đệm tham chiếu để bù đắp cho độ trễ tham chiếu do đó ảnh hưởng đến thời gian dành cho việc kiểm thử.
Một thực tế khác là khởi động kiểm thử phần mềm tại cùng một thời điểm bắt đầu dự án và nó là một quá trình liên tục cho đến khi dự án kết thúc.

Mô hình phát triển Agile or Extreme

Ngược lại, một số quy tắc phần mềm đang nổi lên như lập trình cực đoan và sự chuyển động phát triển phần mềm AGILE, tuân thủ mô hình "Test – Driven Development " (TDD). Trong quy trình này, kiểm thử đơn vị được viết đầu tiên do các kỹ sư phần mềm (thường là lập trình song song trong các phương pháp lập trình Extreme). Tất nhiên những kiểm thử bước đầu thất bại như dự kiến, nhưng sau đó Code được viết xong thì phần lớn các Test Suite sẽ từng bước tăng lên. Nó được cập nhật như là các lỗi điều kiện mới và các trường hợp tiềm ẩn vừa được phát hiện ra, chúng được tích hợp với bất kỳ kiểm thử hồi quy nào được phát triển. Kiểm thử đơn vị được duy trì cùng với phần còn lại của các mã nguồn phần mềm và được tích hợp chung vào quá trình xây dựng (với những kiểm thử tương tác vốn đã bị loại bỏ quá trình xây dựng mức chấp nhận thông thường). Mục tiêu cuối cùng của quá trình kiểm thử này là để đạt được việc triển khai liên tục mà ở đó những cập nhật phần mềm có thể được công bố cho công chúng thường xuyên.
Phương pháp này làm tăng các nỗ lực kiểm thử trước khi động đến bất kỳ nhóm kiểm thử chính thức. Trong một số mô hình phát triển khác, hầu hết việc thực hành các kiểm thử xảy ra sau khi các yêu cầu đã được xác định và quá trình mã hóa đã được hoàn thành.

Mô hình từ trên xuống và mô hình từ dưới lên

Kiểm thử từ dưới lên là một cách tiếp cận để kiểm thử tích hợp nơi các thành phần tồn tại ở cấp độ thấp nhất (Các Module, các biện pháp và các chức năng) được kiểm thử đầu tiên, sau đó tích hợp và sử dụng để tạo thuận lợi cho việc kiểm thử các thành phần cấp cao hơn. Sau khi kiểm thử tích hợp các Module ở cấp độ thấp hơn sẽ tiến hành kiểm thử ở các cấp độ tiếp theo. Quá trình này được lặp đi lặp lại cho đến khi các thành phần ở trật tự trên cùng của hệ thống được kiểm tra. Cách tiếp cận này là chỉ hữu ích khi tất cả hoặc hầu hết các Module có cấp độ phát triển tương đương sẵn sàng được kiểm thử. Phương pháp này cũng giúp xác định các cấp độ phát triển phần mềm và làm cho nó dễ dàng hơn để báo cáo tiến độ kiểm thử theo tỷ lệ phần trăm.
Kiểm thử từ trên xuống là một cách tiếp cận để kiểm thử tích hợp các Module trên đầu với các Module nhánh được kiểm tra từng bước cho đến khi kết thúc Module liên quan.
trong cả hai phương pháp và các trình điều khiển được sử dụng để cố định các thành phần bị thiếu sót và được hoàn thiện ở các cấp độ thay thế.

Kiểm thử tự động hóa

Nhiều nhóm lập trình càng ngày càng dựa vào các kiểm thử tự động, đặc biệt là các nhóm sử dụng mô hình TDD (Test – Drive – Development). Có rất nhiều framework được viết bên trong và mã trong mỗi phiên bản được chạy kiểm thử tự động mọi lúc khi tích hợp liên tục phần mềm.
Tuy kiểm thử tự động không thể sao chép tất cả mọi thứ như con người có thể làm (và tất cả các cách họ nghĩ để làm việc đó) nhưng nó có thể rất hữu ích cho việc kiểm thử hồi quy. Mặc dù vậy, nó cũng đòi hỏi phải có những kịch bản phát triển tốt để tiến hành kiểm thử.

Đo lường trong kiểm thử phần mềm

Thông thường, chất lượng bị hạn chế đến các chủ đề như tính chính xác, tính hoàn chỉnh và tính bảo mật nhưng cũng có thể bao gồm các yêu cầu kỹ thuật như được mô tả trong các tiêu chuẩn ISO (ISO / IEC 9126), chẳng hạn như khả năng, độ tin cậy, hiệu quả, tính di động, độ bảo trì, khả năng tương thích và khả năng sử dụng.
Có một số số liệu thường được sử dụng các độ đo phần mềm, hoặc các biện pháp được sử dụng để hỗ trợ trong việc xác định tình trạng của phần mềm hoặc tính đầy đủ của các kiểm thử.

Kiểm thử thành phần lạ

Quá trình kiểm thử phần mềm có thể tạo ra một số thành phần lạ.

Kế hoạch kiểm thử

Một kiểm thử đặc điểm kỹ thuật được gọi là một kế hoạch kiểm thử. Các nhà phát triển nhận thức rõ những gì kế hoạch kiểm thử sẽ được thực hiện và thông tin này được cung cấp cho các nhà quản lý và các nhà phát triển. Ý tưởng là để làm cho họ thận trọng hơn khi phát triển mã của họ hoặc làm thay đổi bổ sung. Một số công ty có một tài liệu cao cấp được gọi là một chiến lược kiểm thử.

Ma trận truy xuất nguồn gốc

Một ma trận truy xuất nguồn gốc là một bảng tương quan yêu cầu hoặc tài liệu thiết kế các tài liệu kiểm thử. Nó được sử dụng để thay đổi các bài kiểm tra khi nguồn tài liệu liên quan được thay đổi, chọn Test Case để thực hiện khi lập kế hoạch để kiểm thử hồi quy bằng cách xem yêu cầu độ bao phủ.

Tình huống kiểm thử (Test Case)

Một Test Case thông thường bao gồm một ký hiệu nhận dạng duy nhất, tài liệu tham khảo yêu cầu từ một thông số thiết kế, điều kiện tiền đề, các sự kiện, một loạt các bước (còn được gọi là hành động) để làm theo, đầu vào, đầu ra, kết quả dự kiến, và kết quả thực tế. Lâm sàng xác định một Test Case là một đầu vào và kết quả kỳ vọng. Hiểu một cách đơn giản thì một Test Case có một dữ liệu đầu vào thì sẽ có một kết quả đầu ra.
Điều này có một thực tế như là "cho điều kiện X nhưng kết quả bắt nguồn lại là của bạn Y", trong khi Test Case khác được mô tả chi tiết hơn về kịch bản đầu vào và những gì có thể kỳ vọng ở kết quả. Nó đôi khi có thể là một loạt các bước (nhưng thường được chứa trong một thủ tục kiểm tra riêng biệt mà có thể được thực hiện đối với nhiều Test Case) tương ứng với một loạt kết quả kỳ vọng.

Kịch bản kiểm thử

Kịch bản kiểm thử là một thủ tục mà các lập trình viên sao chép các thao tác của người dùng. Ban đầu, thuật ngữ này được bắt nguồn từ các sản phẩm của công việc được tạo ra bởi công cụ kiểm thử hồi quy tự động. Test Case sẽ là cơ sở để tạo ra kịch bản kiểm thử sử dụng một công cụ hoặc một chương trình.

Bộ kiểm thử

Các thuật ngữ phổ biến nhất đối với một bộ sưu tập các Test Case là một bộ kiểm thử. Các bộ kiểm thử thường hướng dẫn chi tiết hoặc có những mục tiêu cho mỗi bộ sưu tập các Test Case. Nó chắc chắn có một phần mà các thử nghiệm xác định các cấu hình hệ thống được sử dụng trong quá trình test. Một nhóm các Test Case cũng có thể chứa các trạng thái hoặc các bước điều kiện tiên quyết, và các mô tả của các kiểm thử sau đó.

Kiểm thử thiết bị cố định hoặc dữ liệu

Trong hầu hết các trường hợp, nhiều bộ giá trị hoặc dữ liệu được sử dụng để kiểm tra các chức năng tương tự của một tính năng đặc biệt. Tất cả các giá trị kiểm thử và các thành phần môi trường thay đổi được thu thập trong các tập tin riêng biệt và được lưu trữ như dữ liệu kiểm thử. Nó cũng rất hữu ích để cung cấp dữ liệu này cho khách hàng cũng như cho một sản phẩm hoặc một dự án.

Kiểm thử an toàn

Phần mềm, các công cụ, các mẫu dữ liệu đầu vào và đầu ra, và các cấu hình đều được gọi chung là một kiểm thử an toàn.

Những chứng nhận

Một số chương trình chứng nhận hiện hành hỗ trợ các Tester và các chuyên gia bảo đảm chất lượng phần mềm duy trì được khát vọng nghề nghiệp của mình. Những đòi hỏi của nghề nghiệp về khả năng và kiến thức khiến một số người không thực sự sẵn sàng. Và nếu không đủ năng lực và kiến thức mà vẫn làm thì chắc chắn sẽ ảnh hưởng đến chất lượng và tính chuyên nghiệp của phần mềm.

Sự tranh luận

Một trong số những tranh luận về kiểm thử phần mềm chủ yếu bao gồm:

Kiểm thử phần mềm chịu trách nhiệm tạo nên những gì?

Thành viên của trường kiểm thử "bối cảnh theo định hướng" tin rằng không có "các bài thực hành tốt nhất" mà là một tập hợp các kỹ năng cho phép các thử nghiệm để chọn hoặc phát minh ra thực hành kiểm thử phù hợp với từng hoàn cảnh đặc biệt.

AGILE so với Truyền thống

Các Tester nên học cách làm việc trong điều kiện không chắc chắn và thay đổi liên tục hoặc họ nên nhắm vào quá trình "trưởng thành"? Phong trào kiểm thử AGILE đã được phổ biến ngày càng tăng kể từ năm 2006 chủ yếu là trong giới thương mại, trong khi việc cung cấp phần mềm sử dụng phương pháp này cho chính phủ và quân sự mà còn là mô hình thử nghiệm, và lựa chọn cuối cùng trong kiểm thử vẫn theo truyền thống (ví dụ như trong mô hình thác nước).

Thăm dò kiểm thử so với kịch bản

Các bài test phải được thiết kế đồng thời khi chúng được thực hiện hoặc họ cần được thiết kế trước?

Hướng dẫn kiểm thử so với tự động

Một số tác giả tin rằng kiểm thử tự động hóa là quá đắt so với giá trị của nó mà nó nên được sử dụng một cách tiết kiệm hơn. Thêm nữa, các quốc gia phát triển kiểm thử điều khiển các nhà phát triển phải viết đơn vị kiểm thử như xUnit, trước khi mã hóa các chức năng.. Các kiểm thử sau đó có thể được coi như một cách để nắm bắt và thực hiện các yêu cầu.

Thiết kế phần mềm so với thực hiện phần mềm

Kiểm thử nên được thực hiện chỉ ở cuối hoặc trong suốt quá trình?

Ai quan sát?

Ý tưởng là bất kỳ hình thức quan sát cũng là một sự kiểm thử tương tác hành động cũng có thể nhìn thấy được ảnh hưởng đó đang được kiểm thử.

Đảm bảo chất lượng phần mềm (SQA)

Kiểm thử phần mềm là một phần trong tiến trình bảo đảm chất lượng phần mềm (SQA). Trong SQA, phần mềm chuyên xử lý và kiểm toán viên được quan tâm đến quá trình phát triển phần mềm hơn là chỉ các hiện vật như tài liệu, mã số và hệ thống. Họ kiểm tra và thay đổi phần mềm quy trình kỹ thuật riêng của mình để giảm số lượng các lỗi mà kết thúc trong phần mềm được gửi: cái gọi là "tỷ lệ khiếm khuyết". Tạo nên cái mà một "tỷ lệ lỗi chấp nhận được" phụ thuộc vào bản chất của phần mềm, một chuyến bay mô phỏng trò chơi video sẽ có khả năng chịu lỗi cao hơn nhiều so với phần mềm cho máy bay thực tế. Mặc dù có những liên kết chặt chẽ với SQA, các phòng kiểm thử thường tồn tại một cách độc lập, và có thể không có chức năng SQA trong một số công ty.
Kiểm thử phần mềm là một nhiệm vụ có ý định để phát hiện lỗi trong phần mềm bằng cách đối chiếu kết quả kỳ vọng từ một chương trình máy tính với kết quả thực tế của nó cho một tập hợp các yếu tố đầu vào. Ngược lại, bảo đảm chất lượng là việc thực hiện các chính sách và thủ tục nhằm ngăn ngừa khiếm khuyết xảy ra ở nơi đầu tiên.