Wikipedia

Thử nghiệm phần mềm

(Đổi hướng từ Kiểm thử phần mềm)

Kiểm thử phần mềm (tiếng Anh: Software testing) là một cuộc kiểm tra được tiến hành để cung cấp cho các bên liên quan thông tin về chất lượng của sản phẩm hoặc dịch vụ được kiểm thử.[1] Kiểm thử có thể cung cấp cho doanh nghiệp một quan điểm, một cách nhìn độc lập về phần mềm để từ đó cho phép đánh giá và thấu hiểu được những rủi ro trong quá trình triển khai phần mềm.

Trong kỹ thuật kiểm thử không chỉ giới hạn ở việc thực hiện một chương trình hoặc ứng dụng với mục đích đi tìm các lỗi phần mềm (bao gồm các lỗi và các thiếu sót) mà còn là một quá trình phê chuẩn và xác minh một chương trình máy tính / ứng dụng / sản phẩm nhằm:

  • Đáp ứng được mọi yêu cầu hướng dẫn khi thiết kế và phát triển phần mềm.
  • Thực hiện công việc đúng như kỳ vọng.
  • Có thể triển khai được với những đặc tính tương tự.
  • Và đáp ứng được mọi nhu cầu của các bên liên quan.

Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất cứ lúc nào trong quá trình phát triển phần mềm. Theo truyền thống thì các nỗ lực kiểm thử được tiến hành sau khi các yêu cầu được xác định và việc lập trình được hoàn tất nhưng trong Agile (là một tập hợp các phương pháp phát triển phần mềm linh hoạt dựa trên việc lặp đi lặp lại và gia tăng giá trị) thì việc kiểm thử được tiến hành liên tục trong suốt quá trình xây dựng phần mềm. Như vậy, mỗi một phương pháp kiểm thử bị chi phối theo một quy trình phát triển phần mềm nhất định.

Tổng quan

sửa

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.[2] 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,[3] 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ể.[4] 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.[5]

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

sửa

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.[6] 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.[7] 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 đề

sửa

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.[4][8] Đ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ể.[9]

Kinh tế

sửa

Một nghiên cứu được tiến hành bởi NIST trong năm 2002 cho biết rằng các lỗi phần mềm gây tổn thất cho nền kinh tế Mỹ 59,5 tỷ đô mỗi năm, hơn một phần ba chi phí này có thể tránh được nếu việc kiểm thử phần mềm được thực hiện tốt hơn.[10]

Người ta thường tin rằng, một kiếm khuyết nếu được tìm ra sớm hơn thì chi phí để sửa chữa nó sẽ rẻ hơn. Bảng dưới đây cho thấy chi phí sửa chữa các khiếm khuyết tùy thuộc vào giai đoạn nó được tìm ra.[11] Ví dụ, một vấn đề được tìm thấy sau khi đã ra bản phần mềm chính thức rồi sẽ có chi phí gấp 10-100 lần khi giải quyết vấn đề từ lúc tiếp nhận yêu cầu. Với sự ra đời của cách thức triển khai thực tiễn liên tục và các dịch vụ dựa trên đám mây, chi phí tái triển khai và bảo trì có thể làm giảm bớt theo thời gian.

Chi phí sửa chữa một khiếm khuyết Thời gian phát hiện
Các yêu cầu của phần mềm Kiến trúc phần mềm Xây dựng phần mềm Kiểm thử hệ thống Sau khi phát hành
Thời gian sử dụng Các yêu cầu của phần mềm 1× 3× 5–10× 10× 10–100×
Kiến trúc phần mềm – 1× 10× 15× 25–100×
Xây dựng phần mềm – – 1× 10× 10–25×

Vai trò

sửa

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[12] 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ử.

Lịch sử

sửa

Sự tách biệt giữa việc gỡ lỗi (sửa lỗi, debugging) với kiểm thử (testing) lần đầu tiên được Glenford J. Myers đưa ra vào năm 1979.[13] Mặc dù sự quan tâm của ông là kiểm thử sự gián đoạn ("một kiểm thử thành công là tìm ra được một lỗi"[13][14]) nó minh họa mong muốn của cộng đồng công nghệ phần mềm để tách biệt các hoạt động phát triển cơ bản, giống như việc tách phần gỡ lỗi ra riêng khỏi quá trình kiểm thử. Vào năm 1988, Dave Gelperin và William C. Hetzel đã phân loại các giai đoạn và mục tiêu trong kiểm thử phần mềm theo trình tự sau:[15]

  • Trước 1956: Hướng về việc kiểm soát lỗi.[16]
  • 1957-1978: Hướng về chứng minh lỗi.[17]
  • 1979-1982: Hướng về tính phá hủy của lỗi.[18]
  • 1983–1987: Hướng về đánh giá lỗi.[19]
  • 1988–2000: Hướng về việc phòng ngừa lỗi.[20]

Phương pháp kiểm thử

sửa

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

sửa

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ò

sửa

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ử hộp trắng

sửa
Bài chi tiết: Kiểm thử hộp trắng

Kiểm thử hộp trắng (được biết đến như là kiểm thử tính rõ ràng của hộp, kiểm thử hộp kính, kiểm thử hộp trong suốt và kiểm thử cấu trúc) giúp kiểm thử được cấu trúc nội bộ hoặc hoạt động của một chương trình, như tương phản với chức năng được bộc lộ của người dùng cuối. Một góc nhìn nội bộ của hệ thống trong kiểm thử hộp trắng giống như là các kỹ năng lập trình được sử dụng để thiết kế ra các tình huống kiểm thử. Các Tester lựa chọn yếu tố đầu vào để thực hiện đường dẫn thông qua các mã và xác định được kết quả đầu ra thích hợp. Điều này tương tự các nút kiểm thử trong một mạch, ví dụ như kiểm thử thông mạch (ICT).

Trong khi kiểm thử hộp trắng có thể được áp dụng tại đơn vị, tích hợp hệ thống và các cấp độ của quá trình kiểm thử phần mềm, nó thường được thực hiện ở cấp đơn vị. Nó có thể kiểm thử đường dẫn trong một đơn vị, liên kết giữa các đơn vị trong quá trình tích hợp, và giữa các hệ thống con trong một kiểm thử hệ thống cấp. Mặc dù phương pháp này thiết kế kiểm thử có thể phát hiện ra nhiều lỗi hoặc các vấn đề, nó có thể không phát hiện các phần chưa thực hiện của các đặc điểm kỹ thuật hoặc yêu cầu thiếu sót.

Các kỹ thuật được sử dụng trong kiểm thử hộp trắng bao gồm:

  • Kiểm thử API (giao diện lập trình ứng dụng) - kiểm thử ứng dụng có sử dụng các API công cộng và cá nhân.
  • Kiểm thử độ bao phủ mã - tạo ra các bài kiểm thử để đáp ứng một số tiêu chí của bảo hiểm mã (ví dụ, các nhà thiết kế kiểm thử có thể tạo ra các bài kiểm thử để làm tất cả các câu lệnh trong chương trình được thực hiện ít nhất một lần).
  • Phương pháp chèn lỗi - cố tình đưa ra những lỗi lầm để đánh giá hiệu quả của các chiến lược kiểm thử.
  • Phương pháp kiểm thử đột biến.
  • Phương pháp thử tĩnh.

Các công cụ bao phủ mã có thể đánh giá đầy đủ của một bộ kiểm thử đã được tạo ra bằng phương pháp bất kỳ nào đó, bao gồm cả kiểm thử hộp đen. Điều này cho phép nhóm nghiên cứu phần mềm kiểm thử các bộ phận của một hệ thống mà hiếm khi được kiểm thử và đảm bảo rằng các điểm chức năng quan trọng nhất đã được kiểm thử.[21] Bao phủ mã giống như một phần mềm metric có thể báo cáo tỷ lệ phần trăm cho:

  • Bao phủ chức năng: dựa vào các báo cáo của chức năng này thực hiện.
  • Bao phủ câu lệnh: dựa vào các báo cáo về số lượng các dòng được thực hiện để hoàn thành kiểm thử.

100% bao phủ câu lệnh đảm bảo rằng tất cả các đường dẫn mã, hoặc các nhánh (trong điều kiện của luồng điều khiển) được thực hiện ít nhất một lần. Điều này hữu ích trong việc đảm bảo đúng chức năng nhưng không đủ kể từ khi các mã tương tự có thể thực hiện tiến trình xử lý dữ liệu đầu vào khác nhau dù đúng hoặc không.

Kiểm thử hộp đen

sửa
Bài chi tiết: Kiểm thử hộp đen
 
Sơ đồ hộp đen

Kiểm thử hộp đen coi phần mềm như là một "hộp đen", kiểm thử chức năng mà không cần bất kỳ kiến thức về cấu trúc và hành vi bên trong phần mềm. Các Tester chỉ biết về những gì phần mềm phải làm mà không biết là nó làm như thế nào.[22] Phương pháp kiểm thử hộp đen bao gồm: Phân vùng tương đương, phân tích giá trị biên, tất cả các cặp kiểm thử, bảng chuyển đổi trạng thái, kiểm thử bảng quyết định, kiểm thử chéo, kiểm thử dựa trên mô hình, sử dụng Test Case, thăm dò kiểm thử và kiểm thử dựa trên đặc điểm kỹ thuật.

Kiểm thử dựa trên đặc điểm kỹ thuật nhằm mục đích để kiểm tra các chức năng của phần mềm theo các yêu cầu ứng dụng.[23] Mức độ kiểm thử thường đòi hỏi Test Case kỹ lưỡng để được cung cấp bởi các Tester, những người mà sau đó có thể xác minh một cách đơn giản rằng đối với một giá trị đầu vào hoặc đầu ra (hoặc cách xử lý) có thể giống hoặc không so với giá trị kỳ vọng được định vị trong một Test Case nhất định. Các Test Case được xây dựng quanh các thông số kỹ thuật và các yêu cầu đề xuất, tức là những tất cả những gì ứng dụng đó phải làm. Nó được sử dụng để mô tả mở rộng phần mềm bao gồm các thông số kỹ thuật, các yêu cầu và thiết kế được bắt nguồn trong Test Case. Các kiểm thử này có thể là chức năng hoặc phi chức năng.

Kiểm thử dựa trên đặc điểm kỹ thuật có thể là cần thiết để đảm bảo chức năng chính xác, nhưng nó không đủ để bảo vệ chống lại các tình huống phức tạp hoặc có độ rủi ro cao.[24]

Một lợi thế của kỹ thuật kiểm thử hộp đen là không yêu cầu nhất thiết phải có kiến thức lập trình. Các Tester tiến hành kiểm thử ở các khu vực và các chức năng khác nhau của phần mềm mà không liên quan đến các lập trình viên. Mặt khác, kiểm thử hộp đen được cho là "đi bộ trong một mê cung tối tăm mà không có đèn pin".[25] Bởi vì họ không kiểm thử mã nguồn và đã có nhiều tình huống các Tester chỉ kiểm thử được tính năng trong một vài trường hợp chứ không kiểm thử được toàn bộ hoạt động của chương trình.

Phương pháp kiểm thử này có thể được áp dụng cho tất cả các cấp kiểm thử phần mềm: đơn vị, tích hợp, hệ thống và chấp nhận. Nó không thể thực hiện được tất cả các kiểm thử các cấp độ cao hơn nhưng nó có thể tạo ưu thế tốt khi kiểm thử từng đơn vị.

Kiểm thử trực quan

sửa

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.[26][27]

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.[cần dẫn nguồn]

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.[cần giải thích][cần dẫn nguồn]

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.[cần dẫn nguồ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

sửa

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.[28] 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ế.[29]

Các mức kiểm thử

sửa

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ử đơn vị

sửa
Bài chi tiết: Kiểm thử đơn vị

Kiểm thử đơn vị hay còn được gọi là kiểm thử thành phần, đề cập đến việc kiểm thử chức năng từng phần của mã, thường ở mức độ chức năng. Trong một môi trường hướng về đối tượng thì điều này thường là cấp độ lớp, và các kiểm thử đơn vị tối thiểu bao gồm hàm dựng và hàm hủy. Nhiều loại kiểm thử được viết bởi các nhà phát triển như họ làm việc trong mã (kiểu hộp trắng) để đảm bảo rằng từng hàm riêng biệt hoạt động đúng như kỳ vọng. Một hàm có thể có nhiều kiểm thử từ đó giúp nắm bắt được các trường hợp góc hoặc các nhánh trong Code. Kiểm thử đơn vị một mình không thể đảm bảo hết được từng chức năng của từng bộ phận trong phần phềm nhưng nó được sử dụng để đảm bảo rằng các khối kiến trúc của phần mềm hoạt động độc lập với nhau.

Kiểm thử đơn vị là một quá 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, thời gian và chi phí. Nó được thực hiện bởi kỹ sư hay nhà phát triển trong suốt giai đoạn xây dựng của vòng đời phát triển phần mềm. Không chỉ tập trung vào việc đảm bảo chất lượng truyền thống mà phải gia tăng nó lên vì thế kiểm thử đơn vị có mục đích loại bỏ những lỗi cấu trúc trước khi mã hóa rồi mới thúc đẩy việc quản lý chất lượng. Chiến lược này nhằm nâng cao chất lượng cũng như hiệu quả của phần mềm trong tiến trình quản lý và phát triển chung.

Tùy thuộc vào kỳ vọng của tổ chức phát triển phần mềm, kiểm thử đơn vị 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 dữ liệu, đánh giá mã cân bằng, phân tích mã bao phủ và các thực hành xác nhận phần mềm khác.

Kiểm thử tích hợp

sửa

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

sửa

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

sửa

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

Các loại hình kiểm thử

sửa

Kiểm thử cài đặt

sửa

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

sửa

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

sửa

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

sửa

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

sửa

Kiểm thử mức chấp nhận được hiểu theo một trong hai nghĩa sau:

  1. 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.
  2. 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

sửa

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

sửa

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

sửa

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

sửa

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

sửa

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

sửa

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

sửa

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

sửa

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

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

sửa

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

sửa

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.

Quy trình kiểm thử

sửa

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

sửa

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

sửa

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

sửa

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

Một chu kỳ kiểm thử mẫu

sửa

Dẫu cho các biến thể tồn tại giữa các tổ chức lập trình thì vẫn có một quy trình điển hình để kiểm thử. Mẫu dưới đây là phổ biến trong các tổ chức sử dụng mô hình phát triển Waterfall (thác nước). Các hoạt động tương tự thường được tìm thấy trong các mô hình phát triển khác, nhưng có thể có hoặc không rõ ràng.

  • Phân tích yêu cầu: Kiểm thử thường sẽ bắt đầu lấy các yêu cầu trong các giai đoạn của vòng đời phát triển phần mềm. Trong giai đoạn thiết kế, các Tester làm việc với các nhà phát triển để xác định những khía cạnh của một thiết kế được kiểm chứng và những thông số được kiểm tra.
  • Lập kế hoạch kiểm thử: Chiến lược kiểm thử, kế hoạch kiểm thử, kiểm thử sáng tạo… Và có một kế hoạch là cần thiết vì nhiều hoạt động sẽ được thực hiện trong thời gian kiểm thử.
  • Kiểm thử phát triển: Các quy trình kiểm thử, các kịch bản, Test Case, các dữ liệu được sử dụng trong kiểm thử phần mềm.
  • Kiểm thử thực hiện: Dựa trên các kế hoạch, các văn bản kiểm thử và các báo cáo bất kỳ lỗi nào tìm thấy cho nhóm phát triển.
  • Kiểm thử báo cáo: Sau khi hoàn tất kiểm thử, các Tester tạo ra các số liệu và báo cáo cuối cùng về nỗ lực kiểm thử của họ và có sẵn sàng phát hành phần mềm hay không.
  • Phân tích kết quả kiểm thử hoặc phân tích thiếu sót được thực hiện bởi đội ngũ phát triển kết hợp với khách hàng để đưa ra quyết định xem những thiếu sót gì cần phải được chuyển giao, cố định và từ bỏ (tức là tìm ra được phần mềm hoạt động chính xác) hoặc giải quyết sau.
  • Test lại khiếm khuyết: Khi một khiếm khuyết đã được xử lý bởi đội ngũ phát triển, nó phải được kiểm tra lại bởi nhóm kiểm thử.
  • Kiểm thử hồi quy: Người ta thường xây dựng một chương trình kiểm thử nhỏ là tập hợp của các bài kiểm tra cho mỗi tích hợp mới, sửa chữa hoặc cố định phần mềm, để đảm bảo rằng những cung cấp mới nhất đã không phá hủy bất cứ điều gì và toàn bộ phần mềm vẫn còn hoạt động một cách chính xác.

Kiểm thử đóng gói: Mỗi phép thử thỏa mãn các chỉ tiêu truy xuất và thu được những kết quả quan trong như: bài học kinh nghiệm, kết quả, các bản ghi, tài liệu liên quan được lưu trữ và sử dụng như một tài liệu tham khảo cho các dự án trong tương lai.

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

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

Các công cụ kiểm thử

sửa

Chương trình kiểm thử và phát hiện lỗi có thể được hỗ trợ đáng kể bởi các công cụ kiểm thử và gỡ lỗi. Các công cụ kiểm thử/gỡ lỗi bao gồm các tính năng như:

  • Những màn hình chương trình cho phép giám sát toàn bộ hoặc một phần của mã chương trình gồm:
    • Lệnh thiết lập simulator cho phép giám sát hoàn chỉnh cấp hướng dẫn và các thiết bị vi lượng.
    • Hình ảnh chương trình cho phép thực hiện từng bước và ngắt đoạn có điều kiện ở cấp nguồn hoặc trong mã máy.
    • Các báo cáo độ bao phủ của mã.
  • Các công cụ gỡ lỗi biểu tượng hoặc kết xuất định dạng cho phép kiểm tra các biến tại các chỗ lỗi và tại các điểm được lựa chọn.
  • Các công cụ kiểm thử GUI chức năng tự động được sử dụng để lặp lại mức độ kiểm tra hệ thống thông qua GUI (giao diện đồ họa).
  • Điểm định chuẩn cho phép so sánh hiệu suất chạy thực được hoạt động.
  • Phân tích hiệu suất (hoặc các công cụ định hình) có thể giúp làm nổi bật các điểm tới hạn và sử dụng tài nguyên.

Một số các tính năng này có thể được kết hợp vào một môi trường phát triển tích hợp (IDE).

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

sửa

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ạ

sửa

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ử

sửa

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

sửa

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)

sửa

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ử

sửa

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ử

sửa

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

sửa

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

sửa

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

sửa

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.

Các loại giấy chứng nhận kiểm thử phần mềm

sửa
  • Dựa vào thi cử: Bạn cần phải vượt qua các kỳ thi chính thức hoặc cũng có thể tự học (ví dụ như cho ISTQB – Hội đồng đánh giá trình độ chuyên môn kiểm thử phần mềm quốc tế hay QAI – Viện bảo đảm chất lượng).
  • Dựa vào giáo dục: Thông qua các bài giảng hướng dẫn trong các khóa học giúp bạn được chứng nhận (ví dụ: Viện nghiên cứu quốc tế về kiểm thử phần mềm).

Các giấy chứng nhận kiểm thử

sửa
  • Hiệp hội chứng nhận kiểm thử phần mềm (CAST) được cung cấp bởi Viện bảo đảm chất lượng.
  • CATe được cung cấp bởi Viện quốc tế về kiểm thử phần mềm.
  • Chứng nhận quản lý trong kiểm thử phần mềm (CMST) được cung cấp bởi các Viện bảo đảm chất lượng.
  • Chứng nhận quản lý kiểm thử (CTM) được cung cấp bởi Viện quốc tế về kiểm thử phần mềm.
  • Chứng nhận phần mềm Tester (CSTE) được cung cấp bởi Viện Đảm bảo chất lượng.
  • Chứng nhận thử nghiệm phần mềm chuyên nghiệp (CSTP) được cung cấp bởi Viện quốc tế về kiểm thử phần mềm.
  • CSTP (TM) (phiên bản Australia) được cung cấp bởi KJ Ross & Associates.
  • ISEB được cung cấp bởi các Hội đồng hệ thống thông tin thi cử.
  • ISTQB Certified Tester, Quỹ Cấp (CTFL) được cung cấp bởi các phần mềm kiểm tra Hội đồng Văn bằng quốc tế.
  • ISTQB Certified Tester, Cao cấp (CTAL) được cung cấp bởi các phần mềm kiểm tra Hội đồng Văn bằng quốc tế
  • Quỹ TMPF TMap Next theo được cung cấp bởi Viện Kiểm tra Khoa học Thông tin.
  • TMPA TMap Next Advanced được cung cấp bởi Viện Kiểm tra Khoa học Thông tin.

Chứng nhận đảm bảo chất lượng

sửa
  • CMSQ được cung cấp bởi Viện Bảo đảm Chất lượng (QAI).
  • CSQA được cung cấp bởi Viện Bảo đảm Chất lượng (QAI).
  • CSQE được cung cấp bởi Hiệp hội chất lượng Hoa Kỳ (ASQ).
  • CQIA được cung cấp bởi Hiệp hội chất lượng Hoa Kỳ (ASQ).

Sự tranh luận

sửa

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ì?

sửa

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

sửa

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

sửa

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

sửa

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

sửa

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?

sửa

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

Quy trình liên quan

sửa

Kiểm thử phần mềm được sử dụng kết hợp với xác minh và xác nhận

sửa
  • Xác minh: Chúng ta đã xây dựng quyền của phần mềm? (nghĩa là, nó thực hiện các yêu cầu).
  • Xác nhận: Chúng tôi đã xây dựng các phần mềm? (nghĩa là, không đáp ứng các yêu cầu của khách hàng).

Các điều khoản xác minh và xác nhận thường được sử dụng thay thế cho nhau trong ngành công nghiệp, mà còn là phổ biến để xem hai thuật ngữ này không đúng quy định.

Theo chuẩn IEEE Thuật ngữ Công nghệ Phần Mềm:

  • Xác minh là quá trình đánh giá một hệ thống hay thành phần để xác định xem các sản phẩm của một giai đoạn phát triển nhất định đáp ứng các điều kiện áp đặt tại lúc bắt đầu của giai đoạn đó.
  • Xác nhận là quá trình đánh giá một hệ thống hay cấu phần trong hay cuối của quá trình phát triển để xác định xem nó đáp ứng yêu cầu quy định.

Theo tiêu chuẩn ISO 9000:

  • Xác minh là khẳng định bằng cách kiểm tra và thông qua cung cấp các bằng chứng khách quan rằng các yêu cầu cụ thể đã được thực hiện.
  • Xác nhận là khẳng định bằng cách kiểm tra và thông qua cung cấp các bằng chứng khách quan rằng các yêu cầu cho một mục đích sử dụng cụ thể hoặc ứng dụng đã được hoàn thành.

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

sửa

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.

Xem thêm

sửa

Tham khảo

sửa
  1. ^ Exploratory Testing Lưu trữ 2009-01-26 tại Wayback Machine, Cem Kaner, Florida Institute of Technology, Quality Assurance Institute Worldwide Annual Software Testing Conference, Orlando, FL, November 2006
  2. ^ Software Testing by Jiantao Pan, Carnegie Mellon University
  3. ^ Leitner, A., Ciupa, I., Oriol, M., Meyer, B., Fiva, A., "Contract Driven Development = Test Driven Development – Writing Test Cases", Proceedings of ESEC/FSE'07: European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering 2007, (Dubrovnik, Croatia), September 2007
  4. ^ a b Cem Kaner & Falk, Jack and Nguyen, Hung Quoc (1999). Testing Computer Software, 2nd Ed. New York, et al: John Wiley and Sons, Inc. tr. 480 pages. ISBN 0-471-35846-0.Quản lý CS1: sử dụng tham số tác giả (liên kết) Lỗi chú thích: Thẻ <ref> không hợp lệ: tên “Kaner1” được định rõ nhiều lần, mỗi lần có nội dung khác
  5. ^ Adam Kolawa & Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. tr. 41–43. ISBN 0-470-04212-5.Quản lý CS1: sử dụng tham số tác giả (liên kết)
  6. ^ Adam Kolawa & Huizinga, Dorota (2007). Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. tr. 426. ISBN 0-470-04212-5.Quản lý CS1: sử dụng tham số tác giả (liên kết)
  7. ^ Section 1.1.2, Certified Tester Foundation Level Syllabus Lưu trữ 2008-12-17 tại Wayback Machine, International Software Testing Qualifications Board
  8. ^ Principle 2, Section 1.3, Certified Tester Foundation Level Syllabus Lưu trữ 2008-12-17 tại Wayback Machine, International Software Testing Qualifications Board
  9. ^ “Proceedings from the 5th International Conference on Software Testing and Validation (ICST). Software Competence Center Hagenberg. "Test Design: Lessons Learned and Practical Implications”.
  10. ^ Software errors cost U.S. economy $59.5 billion annually Lưu trữ 2011-07-07 tại Wayback Machine, NIST report
  11. ^ McConnell, Steve (2004). Code Complete (ấn bản thứ 2). Microsoft Press. tr. 29. ISBN 0-7356-1967-0.
  12. ^ see D. Gelperin and W.C. Hetzel
  13. ^ a b Myers, Glenford J. (1979). The Art of Software Testing. John Wiley and Sons. ISBN 0-471-04328-1.
  14. ^ Company, People's Computer (1987). “Dr. Dobb's journal of software tools for the professional programmer”. Dr. Dobb's journal of software tools for the professional programmer. M&T Pub. 12 (1–6): 116.
  15. ^ D. Gelperin & B. Hetzel (1988). “The Growth of Software Testing”. CACM. 31 (6): 687. doi:10.1145/62959.62965. ISSN 0001-0782.Quản lý CS1: sử dụng tham số tác giả (liên kết)
  16. ^ until 1956 it was the debugging oriented period, when testing was often associated to debugging: there was no clear difference between testing and debugging. D. Gelperin & B. Hetzel (1988). “The Growth of Software Testing”. CACM. 31 (6). ISSN 0001-0782.Quản lý CS1: sử dụng tham số tác giả (liên kết)
  17. ^ From 1957–1978 there was the demonstration oriented period where debugging and testing was distinguished now – in this period it was shown, that software satisfies the requirements. D. Gelperin & B. Hetzel (1988). “The Growth of Software Testing”. CACM. 31 (6). ISSN 0001-0782.Quản lý CS1: sử dụng tham số tác giả (liên kết)
  18. ^ The time between 1979–1982 is announced as the destruction oriented period, where the goal was to find errors. D. Gelperin & B. Hetzel (1988). “The Growth of Software Testing”. CACM. 31 (6). ISSN 0001-0782.Quản lý CS1: sử dụng tham số tác giả (liên kết)
  19. ^ 1983–1987 is classified as the evaluation oriented period: intention here is that during the software lifecycle a product evaluation is provided and measuring quality. D. Gelperin & B. Hetzel (1988). “The Growth of Software Testing”. CACM. 31 (6). ISSN 0001-0782.Quản lý CS1: sử dụng tham số tác giả (liên kết)
  20. ^ From 1988 on it was seen as prevention oriented period where tests were to demonstrate that software satisfies its specification, to detect faults and to prevent faults. D. Gelperin & B. Hetzel (1988). “The Growth of Software Testing”. CACM. 31 (6). ISSN 0001-0782.Quản lý CS1: sử dụng tham số tác giả (liên kết)
  21. ^ Introduction, Code Coverage Analysis, Steve Cornett
  22. ^ Ron, Patton. Software Testing.
  23. ^ Laycock, G. T. (1993). “The Theory and Practice of Specification Based Software Testing”. Dept of Computer Science, Sheffield University, UK. Bản gốc (PostScript) lưu trữ ngày 14 tháng 2 năm 2007. Truy cập ngày 13 tháng 2 năm 2008. Chú thích journal cần |journal= (trợ giúp)
  24. ^ Bach, James (1999). “Risk and Requirements-Based Testing” (PDF). Computer. 32 (6): 113–114. Truy cập ngày 19 tháng 8 năm 2008.
  25. ^ Savenkov, Roman (2008). How to Become a Software Tester. Roman Savenkov Consulting. tr. 159. ISBN 978-0-615-23372-7.
  26. ^ “Visual testing of software – Helsinki University of Technology” (PDF). Truy cập ngày 13 tháng 1 năm 2012.
  27. ^ “Article on visual testing in Test Magazine”. Testmagazine.co.uk. Truy cập ngày 13 tháng 1 năm 2012.
  28. ^ Patton, Ron (2006). Software Testing.
  29. ^ “SOA Testing Tools for Black, White and Gray Box SOA Testing Techniques”. Crosschecknet.com. Bản gốc lưu trữ ngày 1 tháng 10 năm 2018. Truy cập ngày 10 tháng 12 năm 2012.

Liên kết ngoài

sửa
Lấy từ “https://vi.wikipedia.org/w/index.php?title=Thử_nghiệm_phần_mềm&oldid=70877780”