Kiểm thử phần mềm – Wikipedia tiếng Việt

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ỉ số lượng giới hạn ở việc thực thi một chương trình hoặc ứng dụng với mục tiêu đi tìm những lỗi ứng dụng ( gồm có những lỗi và những thiếu sót ) mà còn là một quy trình phê chuẩn và xác định một chương trình máy tính / ứng dụng / loại sản phẩm nhằm mục đích :

  • Đá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 giải pháp, việc kiểm thử hoàn toàn có thể được triển khai bất kể khi nào trong quy trình tăng trưởng ứng dụng. Theo truyền thống cuội nguồn thì những nỗ lực kiểm thử được triển khai sau khi những nhu yếu được xác lập và việc lập trình được hoàn tất nhưng trong Agile ( là một tập hợp những giải pháp tăng trưởng ứng dụng linh động dựa trên việc lặp đi lặp lại và ngày càng tăng giá trị ) thì việc kiểm thử được thực thi liên tục trong suốt quy trình thiết kế xây dựng ứng dụng. Như vậy, mỗi một chiêu thức kiểm thử bị chi phối theo một quy trình tiến độ tăng trưởng ứng dụng nhất định .

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 những lỗi ứng dụng để từ đó khắc phục và thay thế sửa chữa. Việc kiểm thử không hề khẳng định chắc chắn được rằng những tính năng của mẫu sản phẩm đúng trong mọi điều kiện kèm theo, mà chỉ hoàn toàn có thể chứng minh và khẳng định rằng nó không hoạt động giải trí đúng trong những điều kiện kèm theo đơn cử. [ 4 ] Phạm vi của kiểm thử ứng dụng thường gồm có việc kiểm tra mã, thực thi những mã trong môi trường tự nhiên và điều kiện kèm theo khác nhau, và việc kiểm thử những góc nhìn của mã : nó có làm đúng trách nhiệm của nó hay không, và nó có làm những gì cần phải làm hay không. Trong thiên nhiên và môi trường tăng trưởng ứng dụng lúc bấy giờ, một đội kiểm thử hoàn toàn có thể tách biệt với đội tăng trưởng. Các thành viên trong đội kiểm thử giữ những vai trò khác nhau. Các thông tin thu được từ kiểm thử hoàn toàn có thể được sử dụng để kiểm soát và điều chỉnh quy trình tăng trưởng ứng dụng. [ 5 ]Mỗi mẫu sản phẩm ứng dụng có một đối tượng người dùng ship hàng riêng. Ví dụ như đối tượng người tiêu dùng của ứng dụng game show điện tử là trọn vẹn khác với đối tượng người dùng của ứng dụng ngân hàng nhà nước. Vì vậy, khi một tổ chức triển khai tăng trưởng hoặc góp vốn đầu tư vào một loại sản phẩm ứng dụng, họ hoàn toàn có thể nhìn nhận liệu những loại sản phẩm ứng dụng có được đồng ý bởi người dùng cuối, đối tượng người tiêu dùng ship hàng, 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ử ứng dụng là một quy trình nỗ lực để đưa ra những nhìn nhận này .

Mục lục nội dung

Khiếm khuyết và thất bại[sửa|sửa mã nguồn]

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

Kết nối nguồn vào và điều kiện kèm theo tiền đề[sửa|sửa mã nguồ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.[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à tăng trưởng ứng dụng không hề kiểm thử được toàn bộ mọi thứ, nhưng họ hoàn toàn có thể sử dụng tổng hợp phong cách thiết kế kiểm thử để xác lập số lượng tối thiểu của những kiểm thử thiết yếu để bao quát được những điều họ muốn. Dù là kiểm thử vận tốc hay độ sâu thì họ hoàn toàn có thể sử dụng giải pháp này để kiến thiết xây dựng được những cơ cấu tổ chức khác nhau trong từng trường hợp kiểm thử ( test case ) đơn cử. [ 9 ]
Một điều tra và nghiên cứu được triển khai bởi NIST trong năm 2002 cho biết rằng những lỗi ứng dụng gây tổn thất cho nền kinh tế tài chính Mỹ 59,5 tỷ đô mỗi năm, hơn một phần ba ngân sách này hoàn toàn có thể tránh được nếu việc kiểm thử ứng dụng được thực thi 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ì ngân sách để sửa chữa thay thế nó sẽ rẻ hơn. Bảng dưới đây cho thấy ngân sách thay thế sửa chữa những khiếm khuyết tùy thuộc vào quy trình tiến độ nó được tìm ra. [ 11 ] Ví dụ, một yếu tố được tìm thấy sau khi đã ra bản ứng dụng chính thức rồi sẽ có ngân sách gấp 10-100 lần khi xử lý yếu tố từ lúc đảm nhiệm nhu yếu. Với sự sinh ra của phương pháp tiến hành thực tiễn liên tục và những dịch vụ dựa trên đám mây, ngân sách tái tiến hành và bảo dưỡng hoàn toàn có thể làm giảm bớt theo thời hạn .

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×

Kiểm thử ứng dụng được triển khai bởi nhiều Tester. Cho đến những năm 1980, thuật ngữ ” nhân viên cấp dưới kiểm thử ứng dụng ” đã được sử dụng thường, nhưng sau đó cũng được coi là một nghề riêng không liên quan gì đến nhau. Liên quan đến những tiến trình và những tiềm năng khác nhau trong kiểm thử ứng dụng [ 12 ] thì những vai trò khác nhau đã được thiết lập cho những nhà quản trị, trưởng nhóm kiểm thử, nhà nghiên cứu và phân tích kiểm thử, nhà phong cách thiết kế kiểm thử, Tester, nhà tăng trưởng tự động hóa và quản trị viên kiểm thử .

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|sửa mã nguồn]

Kiểm thử tĩnh và động[sửa|sửa mã nguồn]

Có rất nhiều chiêu thức để kiểm thử ứng dụng. Đánh giá, xu thế 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 tiễn trong những trường hợp được gọi là kiểm thử động. Kiểm thử tĩnh thường thì hoàn toàn có thể được bỏ lỡ khi thực hành thực tế 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 hoàn toàn có thể khởi đầu trước khi chương trình đã hoàn tất 100 % để kiểm thử những phần đơn cử của mã và được vận dụng cho những tính năng riêng không liên quan gì đến nhau hoặc Module. Kỹ thuật nổi bật cho điều này được sử dụng trong cả mạch nhánh / trình điều khiển và tinh chỉnh hoặc được triển khai trong một thiên nhiên và môi trường gỡ lỗi nhất định .Kiểm thử tĩnh tương quan đến việc kiểm chứng trong khi kiểm thử động tương quan đến việc xác nhận. Nó đều cùng giúp cải tổ chất lượng ứng dụng .

Phương pháp thăm dò[sửa|sửa mã nguồn]

Theo truyền thống lịch sử thì những giải pháp kiểm thử ứng dụng đượ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 để diễn đạt quan điểm của một kỹ sư kiểm thử khi phong cách thiết kế những Test Case .

Kiểm thử hộp trắng[sửa|sửa mã nguồn]

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 giải trí của một chương trình, như tương phản với tính năng được thể hiện của người dùng cuối. Một góc nhìn nội bộ của mạng lưới hệ thống trong kiểm thử hộp trắng giống như là những kiến thức và kỹ năng lập trình được sử dụng để phong cách thiết kế ra những trường hợp kiểm thử. Các Tester lựa chọn yếu tố nguồn vào để thực thi đường dẫn trải qua những mã và xác lập được hiệu quả đầu ra thích hợp. Điều này tương tự như những 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 hoàn toàn có thể được vận dụng tại đơn vị chức năng, tích hợp mạng lưới hệ thống và những Lever của quy trình kiểm thử ứng dụng, nó thường được thực thi ở cấp đơn vị chức năng. Nó hoàn toàn có thể kiểm thử đường dẫn trong một đơn vị chức năng, link giữa những đơn vị chức năng trong quy trình tích hợp, và giữa những mạng lưới hệ thống con trong một kiểm thử mạng lưới hệ thống cấp. Mặc dù giải pháp này phong cách thiết kế kiểm thử hoàn toàn có thể phát hiện ra nhiều lỗi hoặc những yếu tố, nó hoàn toàn có thể không phát hiện những phần chưa thực thi của những đặc thù kỹ thuật hoặc nhu yếu thiếu sót .Các kỹ thuật được sử dụng trong kiểm thử hộp trắng gồm có :

  • 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 trùm mã hoàn toàn có thể nhìn nhận rất đầy đủ của một bộ kiểm thử đã được tạo ra bằng giải pháp bất kể nào đó, gồm có cả kiểm thử hộp đen. Điều này được cho phép nhóm điều tra và nghiên cứu ứng dụng kiểm thử những bộ phận của một mạng lưới hệ thống mà hiếm khi được kiểm thử và bảo vệ rằng những điểm công dụng quan trọng nhất đã được kiểm thử. [ 21 ] Bao phủ mã giống như một ứng dụng metric hoàn toàn có thể báo cáo giải trình tỷ suất 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 trùm câu lệnh bảo vệ rằng toàn bộ những đường dẫn mã, hoặc những nhánh ( trong điều kiện kèm theo của luồng tinh chỉnh và điều khiển ) được thực thi tối thiểu một lần. Điều này hữu dụng trong việc bảo vệ đúng tính năng nhưng không đủ kể từ khi những mã tương tự như hoàn toàn có thể thực thi tiến trình giải quyết và xử lý tài liệu nguồn vào khác nhau dù đúng hoặc không .

Kiểm thử hộp đen[sửa|sửa mã nguồn]

Sơ đồ hộp đenKiểm thử hộp đen coi ứng dụng như thể một ” hộp đen “, kiểm thử tính năng mà không cần bất kể kiến thức và kỹ năng về cấu trúc và hành vi bên trong ứng dụng. Các Tester chỉ biết về những gì ứng dụng 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 gồm có : Phân vùng tương tự, nghiên cứu và phân tích giá trị biên, toàn bộ những cặp kiểm thử, bảng quy đổi trạng thái, kiểm thử bảng quyết định hành động, kiểm thử chéo, kiểm thử dựa trên quy mô, sử dụng Test Case, thăm dò kiểm thử và kiểm thử dựa trên đặc thù 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 thù kỹ thuật hoàn toàn có thể là thiết yếu để bảo vệ công dụng đúng chuẩn, nhưng nó không đủ để bảo vệ chống lại những trường hợp phức tạp hoặc có độ rủi ro đáng tiếc cao. [ 24 ]Một lợi thế của kỹ thuật kiểm thử hộp đen là không nhu yếu nhất thiết phải có kiến thức và kỹ năng lập trình. Các Tester triển khai kiểm thử ở những khu vực và những công dụng khác nhau của ứng dụng mà không tương quan đến những 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 trường hợp những 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 hàng loạt hoạt động giải trí của chương trình .Phương pháp kiểm thử này hoàn toàn có thể được vận dụng cho toàn bộ những cấp kiểm thử ứng dụng : đơn vị chức năng, tích hợp, mạng lưới hệ thống và đồng ý. Nó không hề thực thi được tổng thể những kiểm thử những Lever cao hơn nhưng nó hoàn toàn có thể tạo lợi thế tốt khi kiểm thử từng đơn vị chức năng .

Kiểm thử trực quan[sửa|sửa mã nguồn]

Mục đích của kiểm thử trực quan là cung ứng những nhà tăng trưởng năng lực trấn áp những gì đang xảy ra tại thời gian ứng dụng thất bại theo cách mà họ hoàn toàn có thể nhìn thấy thông tin được nhu yế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à sáng tạo độc đáo giúp ai đó nhận ra được một yếu tố ( hoặc một kiểm thử thất bại ) thay vì chỉ diễn đạ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ì vậy luôn nhu yếu phải ghi lại hàng loạt tiến trình kiểm thử – chụp lại toàn bộ mọi thứ xảy ra trên mạng lưới hệ thống ở định dạng video. Các video đầu ra được bổ trợ bằng thời hạn kiểm thử thực tiễn nguồn vào trải qua hình ảnh từ webcam và âm thanh từ micro .Kiểm thử trực quan cung ứng 1 số ít lợi thế như : Chất lượng của tiếp xúc được tăng lên đáng kể bởi những Tester hoàn toàn có thể giúp cho nhà tăng trưởng nhìn rõ được yếu tố xảy ra ( và những sự kiện dẫn đến nó ) chứ không phải chỉ miêu tả chung chung nó và cần phải sửa chữa thay thế những lỗi này để nó không còn sống sót trong nhiều trường hợp khác nữa. Các nhà tăng trưởng sẽ có toàn bộ những vật chứng được nhu yếu trong bài kiểm thử lỗi và hoàn toàn có thể tập trung chuyên sâu vào những nguyên do gây ra lỗi cũng như làm thế nào để cố định và thắt chặt đượ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|sửa mã nguồn]

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, những kiểm thử mà nhu yếu thay thế sửa chữa một kho tàng trữ tài liệu back-end như một cơ sở tài liệu hoặc một tập tin đăng nhập không xác lập như hộp xám, người dùng sẽ không hề biến hóa những kho tàng trữ tài liệu trong khi mẫu sản phẩm vẫn đang hoạt động giải trí thông thường .Kiểm thử hộp xám cũng hoàn toàn có thể gồm có kỹ thuật đảo ngược để xác lập đối tượng người tiêu dùng, giá trị biên hoặc những thông tin lỗi .Khi biết được những khái niệm cơ bản về phương pháp những ứng dụng hoạt động giải trí như thế nào, Tester thực thi kiểm thử ứng dụng 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 thiên nhiên và môi trường kiểm thử bị cô lập với những hoạt động giải trí như gieo một cơ sở tài liệu. Các kiểm thử hoàn toàn có thể quan sát trạng thái của mẫu sản phẩm được kiểm thử sau khi thực thi hành vi nhất định giống như việc thực thi những câu lệnh SQL so với cơ sở tài liệu và sau đó thực thi truy vấn để bảo vệ rằng những biến hóa dự kiến đã được phản ánh. Kiểm thử hộp xám thực thi ngữ cảnh kiểm thử mưu trí, dựa trên thông tin hạn chế. Điều này sẽ đặc biệt quan trọng vận dụng cho những kiểu giải quyết và xử lý tài liệu, kể cả giải quyết và xử lý ngoại lệ, và cứ thế. [ 29 ]

Các mức kiểm thử[sửa|sửa mã nguồn]

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

Kiểm thử đơn vị chức năng[sửa|sửa mã nguồn]

Kiểm thử đơn vị chức năng hay còn được gọi là kiểm thử thành phần, đề cập đến việc kiểm thử công dụng từng phần của mã, thường ở mức độ tính năng. Trong một thiên nhiên và môi trường hướng về đối tượng người tiêu dùng thì điều này thường là Lever lớp, và những kiểm thử đơn vị chức năng tối thiểu gồm có hàm dựng và hàm hủy. Nhiều loại kiểm thử được viết bởi những nhà tăng trưởng như họ thao tác trong mã ( kiểu hộp trắng ) để bảo vệ rằng từng hàm riêng không liên quan gì đến nhau hoạt động giải trí đúng như kỳ vọng. Một hàm hoàn toàn có thể có nhiều kiểm thử từ đó giúp chớp lấy được những trường hợp góc hoặc những nhánh trong Code. Kiểm thử đơn vị chức năng một mình không hề bảo vệ hết được từng tính năng của từng bộ phận trong phần phềm nhưng nó được sử dụng để bảo vệ rằng những khối kiến trúc của ứng dụng hoạt động giải trí độc lập với nhau .Kiểm thử đơn vị chức năng là một quy trình tăng trưởng ứng dụng có tương quan đến ứng dụng đồng nhất của một loạt những kế hoạch phòng ngừa phát hiện lỗi và để giảm thiểu rủi ro đáng tiếc, thời hạn và ngân sách. Nó được thực thi bởi kỹ sư hay nhà tăng trưởng trong suốt quá trình kiến thiết xây dựng của vòng đời tăng trưởng ứng dụng. Không chỉ tập trung chuyên sâu vào việc bảo vệ chất lượng truyền thống lịch sử mà phải ngày càng tăng nó lên vì vậy kiểm thử đơn vị chức năng có mục tiêu vô hiệu những lỗi cấu trúc trước khi mã hóa rồi mới thôi thúc việc quản trị chất lượng. Chiến lược này nhằm mục đích nâng cao chất lượng cũng như hiệu suất cao của ứng dụng trong tiến trình quản trị và tăng trưởng chung .Tùy thuộc vào kỳ vọng của tổ chức triển khai tăng trưởng ứng dụng, kiểm thử đơn vị chức năng hoàn toàn có thể gồm có nghiên cứu và phân tích mã tĩnh, nghiên cứu và phân tích luồng tài liệu, nghiên cứu và phân tích tài liệu, nhìn nhận mã cân bằng, nghiên cứu và phân tích mã bao trùm và những thực hành thực tế xác nhận ứng dụng khác .

Kiểm thử tích hợp[sửa|sửa mã nguồn]

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

Kiểm thử mạng lưới hệ thống[sửa|sửa mã nguồn]

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

Kiểm thử mức đồng ý[sửa|sửa mã nguồn]

Cuối cùng mạng lưới hệ thống được giao cho người dùng để kiểm thử mức gật đầu .

Các mô hình kiểm thử[sửa|sửa mã nguồn]

Kiểm thử setup[sửa|sửa mã nguồn]

Một kiểm thử thiết lập bảo vệ rằng mạng lưới hệ thống được setup đúng và hoạt động giải trí tại phần cứng trong thực tiễn của thiết bị .

Kiểm thử năng lực thích hợp[sửa|sửa mã nguồn]

Một nguyên do phổ cập của lỗi ứng dụng ( trong thực tiễn hay nhận thức ) là thiếu năng lực thích hợp với những hệ quản lý hoặc ứng dụng ứng dụng khác ( hoàn toàn có thể là những phiên bản cũ hay mới của hệ quản lý và điều hành ), hoặc thiên nhiên và môi trường tiềm năng khác nhau rất nhiều so với bản gốc ( ví dụ điển hình 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 lúc bấy giờ đang được nhu yếu để trở thành một ứng dụng web, trong đó phải thực thi trong một trình duyệt web ). Ví dụ, trong trường hợp thiếu tính thích hợp ngược hoàn toàn có thể xảy ra chính bới những lập trình viên chỉ tăng trưởng và kiểm thử ứng dụng trên phiên bản mới nhất của môi trường tự nhiên tiềm năng, mà không phải tổng thể người dùng hoàn toàn có thể chạy. Điều này dẫn đến hậu quả không lường được rằng những tính năng mới nhất hoàn toàn có thể không hoạt động giải trí trong những phiên bản trước kia của thiên nhiên và môi trường tiềm năng nhưng lại hoàn toàn 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 thiên nhiên và môi trường tiềm năng. Đôi khi những yếu tố như vậy hoàn toàn có thể được cố định và thắt chặt bằng cách dữ thế chủ động trừu tượng hóa công dụng hệ quản lý và điều hành vào một Module chương trình riêng không liên quan gì đến nhau hoặc thư viện .

Smoke và Sanity Testing[sửa|sửa mã nguồn]

Sanity Testing xác lập tính hài hòa và hợp lý để thực thi những kiểm thử khác .Smoke Testing được sử dụng để xác lập xem có yếu tố nghiêm trọng với bộ phận của ứng dụng, ví dụ như một bài kiểm thử xác định khi kiến thiết xây dựng ứng dụng .

Kiểm thử hồi quy[sửa|sửa mã nguồn]

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 đổi khác mã chính. Cụ thể, nó tìm cách phát hiện ra những hồi quy của ứng dụng hoặc những lỗi cũ quay trở lại. Những hồi quy như vậy xảy ra bất kể khi nào tính năng ứng dụng trước đây đang hoạt động giải trí 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 biến hóa chương trình, khi một phần mới của ứng dụng được tăng trưởng xung đột với mã sống sót trước đó. Phương pháp phổ cập của kiểm thử hồi quy gồm có chạy lại những kiểm thử trước đó và kiểm thử xem lỗi cố định và thắt chặt trước kia tại sao lại Open. Độ sâu của kiểm thử nhờ vào vào những rủi ro tiềm ẩn và quy trình tiến độ trong quy trình phát hành những tính năng bổ trợ. Chúng hoàn toàn có thể được hoàn tất khi biến hóa thêm vào đầu hoặc cuối bản phát hành, cũng hoàn toàn có thể được có mức độ nguy khốn thấp khi triển khai 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, trong thực tiễn lại cho thấy Regression Test là một trong những loại kiểm tra tốn nhiều thời hạn và công sức của con người nhất. Tuy thế, việc bỏ lỡ Regression Test là ” không được phép ” vì hoàn toàn có thể dẫn đến thực trạng phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng, mặc dầu ta ” tưởng rằng ” những lỗi đó hoặc không có hoặc đã được kiểm tra và thay thế sửa chữa rồi !

Kiểm thử mức gật đầu[sửa|sửa mã nguồn]

Kiểm thử mức đồng ý đượ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|sửa mã nguồn]

Kiểm thử Alpha là việc kiểm thử hoạt động giải trí tính năng thực tiễn hoặc giả lập do người dùng / người mua tiềm năng hoặc một nhóm Tester độc lập triển khai tại nơi sản xuất ứng dụng. Kiểm thử Alpha thường được sử dụng cho ứng dụng đại trà phổ thông ( đóng gói sẵn để bán ) như là một hình thức kiểm thử mức đồng ý nội bộ trước khi ứng dụng chính thức đi vào quy trình tiến độ kiểm thử Beta .

Kiểm thử Beta[sửa|sửa mã nguồn]

Kiểm thử phiên bản Beta được đưa ra sau khi kiểm thử Alpha và hoàn toàn có thể được coi là một hình thức lan rộng ra của kiểm thử mức đồng ý của người dùng. Các phiên bản của ứng dụng, gọi là phiên bản beta, được phát hành cho một đối tượng người dù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ó hoàn toàn có thể bảo vệ loại sản phẩm có ít thiếu sót và lỗi. Đôi khi, những phiên bản beta được phát hành thoáng rộng để tăng khoanh vù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ử tính năng và phi công dụng[sửa|sửa mã nguồn]

Chức năng kiểm thử tương quan đến những hoạt động giải trí xác định một hành vi đơn cử hoặc công dụng của những mã. Đó là những điều được tìm thấy trong những tài liệu nhu yếu, mặc dầu có một số ít giải pháp tăng trưởng được làm từ những câu truyện của người dùng. Kiểm thử tính năng nhằm mục đích vấn đáp cho câu hỏi ” người dùng có hay không làm được với tính năng đơn cử này ” .Kiểm thử phi tính năng đề cập đến những góc nhìn của ứng dụng hoàn toàn có thể không tương quan đến một tính năng đơn cử hoặc hành vi người dùng, ví dụ điển hình như năng lực lan rộng ra và hiệu suất khác, hành vi dưới những hạn chế hoặc bảo mật thông tin nhất định. Việc kiểm thử sẽ xác lập điểm cuộn mà tại đó năng lực lan rộng ra và triển khai của những điểm cực trị hoạt động giải trí không không thay đổi. Những nhu yếu phi công dụng thường là những phản ánh về chất lượng của mẫu sản phẩm, đặc biệt quan trọng là trong toàn cảnh những quan điểm tương thích của người sử dụng nó .

Kiểm thử sự tàn phá[sửa|sửa mã nguồn]

Kiểm thử sự hủy hoại cố gắng nỗ lực làm hỏng ứng dụng hoặc một mạng lưới hệ thống con. Nó xác định rằng những ứng dụng có công dụng đúng ngay cả khi nó nhận được nguồn vào không hợp lệ hoặc không mong ước, do đó tạo ra sự vững mạnh của xác nhận nguồn vào và thói quen quản trị những lỗi. Chèn lỗi ứng dụng ở 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 công dụng thương mại được link từ những trang chèn lỗi ứng dụng mà ở đó có sẵn vô số những mã nguồn mở và những công cụ không lấy phí để triển khai kiểm thử sự hủy hoại ứng dụng .

Kiểm thử hiệu suất ứng dụng[sửa|sửa mã nguồn]

Kiểm thử hiệu suất thường được chạy để xác lập một mạng lưới hệ thống hay mạng lưới hệ thống con thực thi như thế nào về độ nhạy và tính không thay đổi theo một khối lượng việc làm đơn cử. Nó cũng hoàn toàn có thể dùng để tìm hiểu, nhìn nhận, xác nhận hoặc xác định những thuộc tính chất lượng khác của mạng lưới hệ thống, ví dụ điển hình như năng lực lan rộng ra, độ an toàn và đáng tin cậy và sử dụng tài nguyên .Kiểm thử lượng tải đa phần tương quan đến việc kiểm thử mạng lưới hệ thống hoàn toàn có thể liên tục hoạt động giải trí dưới một lượng tải đơn cử, mặc dầu đó là một lượng lớn tài 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à năng lực lan rộng ra ứng dụng. Các hoạt động giải trí kiểm thử lượng tải có tương quan khi triển khai như một hoạt động giải trí phi tính 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 những công dụng của ứng dụng ngay cả khi một số ít thành phần ( ví dụ như một tập tin hoặc cơ sở tài liệu ) tăng triệt để size. 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 việc làm .Kiểm thử tính không thay đổi ( thường được tham chiếu lượng tải và kiểm thử độ bền ) giúp kiểm tra xem ứng dụng hoàn toàn có thể hoạt động giải trí tốt liên tục trong hoặc trên một chu kỳ luân hồi đồng ý được. Có rất ít quy ước về những tiềm năng đơn cử của kiểm thử hiệu suất như thể : Các thuật ngữ lượng tải, kiểm thử hiệu suất, kiểm thử tính lan rộng ra và kiểm thử khối lượng, thường được sử dụng thay thế sửa chữa cho nhau .Hệ thống ứng dụng thời hạn thực có những ràng buộc đúng mực thời hạn. Để kiểm thử những ràng buộc thời hạn được cung ứng thì người ta dùng chiêu thức kiểm thử thời hạn thực .

Kiểm thử tính khả dụng[sửa|sửa mã nguồn]

Kiểm tra tính khả dụng là rất thiết yếu để kiểm tra xem giao diện có tiện lợi và dễ hiểu với người dùng không, nó tương quan trực đa phần đến năng lượng sử dụng của ứng dụng .

Kiểm thử năng lực tiếp cận[sửa|sửa mã nguồn]

Kiểm thử năng lực tiếp cận gồm có việc tuân thủ những 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 thông tin[sửa|sửa mã nguồn]

Kiểm thử bảo mật thông tin ứng dụng là rất thiết yếu trong việc giải quyết và xử lý tài liệu mật và ngăn ngừa những hacker xâm nhập mạng lưới hệ thống .

Tính toàn thế giới và địa phương hóa[sửa|sửa mã nguồn]

Khả năng tổng quát của ứng dụng được toàn thế giới và bản địa hóa hoàn toàn có thể được tự động hóa kiểm tra mà không dịch thực tiễn, bằng cách sử dụng phương thức giả địa phương. Nó sẽ xác định rằng những ứng dụng vẫn hoạt động giải trí, ngay cả sau khi nó đã được dịch sang một ngôn từ mới hoặc thích nghi với một nền văn hóa truyền thống mới ( ví dụ điển hình như tiền tệ và múi giờ khác nhau ) .Việc thực dịch ra nhiều ngôn từ phải được kiểm tra. Sự cố bản địa hóa hoàn toàn có thể gồm có :

  • 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ự tăng trưởng[sửa|sửa mã nguồ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 là một giải 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ự trấn áp và điều trị trong những kiểm thử có trấn áp. Những thí nghiệm này thường được sử dụng trong tăng trưởng web và tiếp thị, cũng như trong nhiều hình thức quảng cáo truyền thống lịch sử .

Quy trình kiểm thử[sửa|sửa mã nguồn]

Mô hình truyền thống lịch sử CMMI và quy mô tăng trưởng thác nước[sửa|sửa mã nguồn]

Một trong thực tiễn phổ cập trong kiểm thử ứng dụng đó là những kiểm thử được triển khai bởi một nhóm những Tester độc lập sau khi những tính năng được tăng trưởng và trước khi nó được chuyển tới người mua. Thực hành này thường là hiệu quả trong tiến trình 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 tác động đến thời hạn dành cho việc kiểm thử .Một trong thực tiễn khác là khởi động kiểm thử ứng dụng tại cùng một thời gian mở màn dự án Bất Động Sản và nó là một quy trình liên tục cho đến khi dự án Bất Động Sản kết thúc .

Mô hình tăng trưởng Agile or Extreme[sửa|sửa mã nguồn]

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

Mô hình từ trên xuống và quy mô từ dưới lên[sửa|sửa mã nguồ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 những thành phần sống sót ở Lever thấp nhất ( Các Module, những giải pháp và những tính năng ) được kiểm thử tiên phong, sau đó tích hợp và sử dụng để tạo thuận tiện cho việc kiểm thử những thành phần cấp cao hơn. Sau khi kiểm thử tích hợp những Module ở Lever thấp hơn sẽ thực thi kiểm thử ở những Lever tiếp theo. Quá trình này được lặp đi tái diễn cho đến khi những thành phần ở trật tự trên cùng của mạng lưới hệ thống được kiểm tra. Cách tiếp cận này là chỉ hữu dụng khi tổng thể hoặc hầu hết những Module có Lever tăng trưởng tương tự sẵn sàng chuẩn bị được kiểm thử. Phương pháp này cũng giúp xác lập những Lever tăng trưởng ứng dụng và làm cho nó thuận tiện hơn để báo cáo giải trình quá trình kiểm thử theo tỷ suất 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 những Module trên đầu với những Module nhánh được kiểm tra từng bước cho đến khi kết thúc Module tương quan .trong cả hai chiêu thức và những trình tinh chỉnh và điều khiển được sử dụng để cố định và thắt chặt những thành phần bị thiếu sót và được triển khai xong ở những Lever thay thế sửa chữa .

Một chu kỳ luân hồi kiểm thử mẫu[sửa|sửa mã nguồn]

Dẫu cho những biến thể sống sót giữa những tổ chức triển khai lập trình thì vẫn có một tiến trình nổi bật để kiểm thử. Mẫu dưới đây là thông dụng trong những tổ chức triển khai sử dụng quy mô tăng trưởng Waterfall ( thác nước ). Các hoạt động giải trí tương tự như thường được tìm thấy trong những quy mô tăng trưởng khác, nhưng hoàn toàn 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 nhu cầu những chỉ tiêu truy xuất và thu được những hiệu quả quan trong như : bài học kinh nghiệm kinh nghiệm tay nghề, tác dụng, những bản ghi, tài liệu tương quan được tàng trữ và sử dụng như một tài liệu tìm hiểu thêm cho những dự án Bất Động Sản trong tương lai .

Kiểm thử tự động hóa[sửa|sửa mã nguồn]

Nhiều nhóm lập trình ngày càng dựa vào những kiểm thử tự động hóa, đặc biệt quan trọng là những nhóm sử dụng quy mô 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 hóa mọi lúc khi tích hợp liên tục ứng dụng .Tuy kiểm thử tự động hóa không hề sao chép tổng thể mọi thứ như con người hoàn toàn có thể làm ( và tổng thể những cách họ nghĩ để thao tác đó ) nhưng nó hoàn toàn có thể rất hữu dụng cho việc kiểm thử hồi quy. Mặc dù vậy, nó cũng yên cầu phải có những ngữ cảnh tăng trưởng tốt để thực thi kiểm thử .

Các công cụ kiểm thử[sửa|sửa mã nguồn]

Chương trình kiểm thử và phát hiện lỗi hoàn toàn có thể được tương hỗ đáng kể bởi những công cụ kiểm thử và gỡ lỗi. Các công cụ kiểm thử / gỡ lỗi gồm có những 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ố những tính năng này hoàn toàn có thể được phối hợp vào một thiên nhiên và môi trường tăng trưởng tích hợp ( IDE ) .

Đo lường trong kiểm thử ứng dụng[sửa|sửa mã nguồn]

Thông thường, chất lượng bị hạn chế đến những chủ đề như tính đúng mực, tính hoàn hảo và tính bảo mật thông tin nhưng cũng hoàn toàn có thể gồm có những nhu yếu kỹ thuật như được miêu tả trong những tiêu chuẩn ISO ( ISO / IEC 9126 ), ví dụ điển hình như năng lực, độ an toàn và đáng tin cậy, hiệu suất cao, tính di động, độ bảo dưỡng, năng lực thích hợp và năng lực sử dụng .Có một số ít số liệu thường được sử dụng những độ đo ứng dụng, hoặc những giải pháp được sử dụng để tương hỗ trong việc xác lập thực trạng của ứng dụng hoặc tính rất đầy đủ của những kiểm thử .

Kiểm thử thành phần lạ[sửa|sửa mã nguồn]

Quá trình kiểm thử ứng dụng hoàn toàn có thể tạo ra một số ít thành phần lạ .

Kế hoạch kiểm thử[sửa|sửa mã nguồn]

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

Ma trận truy xuất nguồn gốc[sửa|sửa mã nguồn]

Một ma trận truy xuất nguồn gốc là một bảng đối sánh tương quan nhu yếu hoặc tài liệu phong cách thiết kế những tài liệu kiểm thử. Nó được sử dụng để đổi khác những bài kiểm tra khi nguồn tài liệu tương quan được biến hóa, chọn Test Case để triển khai khi lập kế hoạch để kiểm thử hồi quy bằng cách xem nhu yếu độ bao trùm .

Tình huống kiểm thử ( Test Case )[sửa|sửa mã nguồn]

Một Test Case thường thì gồm có một ký hiệu nhận dạng duy nhất, tài liệu tìm hiểu thêm nhu yếu từ một thông số kỹ thuật phong cách thiết kế, điều kiện kèm theo tiền đề, những sự kiện, một loạt những bước ( còn được gọi là hành vi ) để làm theo, nguồn vào, đầu ra, hiệu quả dự kiến, và hiệu quả thực tiễn. Lâm sàng xác lập một Test Case là một đầu vào và hiệu quả kỳ vọng. Hiểu một cách đơn thuần thì một Test Case có một tài liệu nguồn vào thì sẽ có một hiệu quả đầu ra .Điều này có một trong thực tiễn như thể ” cho điều kiện kèm theo X nhưng tác dụng bắt nguồn lại là của bạn Y “, trong khi Test Case khác được miêu tả chi tiết cụ thể hơn về ngữ cảnh nguồn vào và những gì hoàn toàn có thể kỳ vọng ở tác dụng. Nó nhiều lúc hoàn toàn có thể là một loạt những bước ( nhưng thường được chứa trong một thủ tục kiểm tra riêng không liên quan gì đến nhau mà hoàn toàn có thể được triển khai so với nhiều Test Case ) tương ứng với một loạt tác dụng kỳ vọng .

Kịch bản kiểm thử[sửa|sửa mã nguồn]

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

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

Kiểm thử thiết bị cố định và thắt chặt hoặc tài liệu[sửa|sửa mã nguồn]

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

Kiểm thử bảo đảm an toàn[sửa|sửa mã nguồn]

Phần mềm, những công cụ, những mẫu tài liệu nguồn vào và đầu ra, và những thông số kỹ thuật đều được gọi chung là một kiểm thử bảo đảm an toàn .

Những ghi nhận[sửa|sửa mã nguồn]

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

Các loại giấy ghi nhận kiểm thử ứng dụng[sửa|sửa mã nguồn]

  • 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 ghi nhận kiểm thử[sửa|sửa mã nguồn]

  • 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 bảo vệ chất lượng[sửa|sửa mã nguồn]

  • 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|sửa mã nguồn]

Một trong số những tranh luận về kiểm thử ứng dụng đa phần gồm có :

Kiểm thử ứng dụng chịu nghĩa vụ và trách nhiệm tạo nên những gì ?[sửa|sửa mã nguồn]

Thành viên của trường kiểm thử ” toàn cảnh theo xu thế ” tin rằng không có ” những bài thực hành thực tế tốt nhất ” mà là một tập hợp những kiến thức và kỹ năng được cho phép những thử nghiệm để chọn hoặc ý tưởng ra thực hành thực tế kiểm thử tương thích với từng thực trạng đặc biệt quan trọng .

AGILE so với Truyền thống[sửa|sửa mã nguồn]

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

Thăm dò kiểm thử so với ngữ cảnh[sửa|sửa mã nguồn]

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

Hướng dẫn kiểm thử so với tự động hóa[sửa|sửa mã nguồn]

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 chi phí hơn. Thêm nữa, những vương quốc tăng trưởng kiểm thử tinh chỉnh và điều khiển những nhà tăng trưởng phải viết đơn vị chức năng kiểm thử như xUnit, trước khi mã hóa những tính năng .. Các kiểm thử sau đó hoàn toàn có thể được coi như một cách để chớp lấy và thực thi những nhu yếu .

Thiết kế ứng dụng so với triển khai ứng dụng[sửa|sửa mã nguồn]

Kiểm thử nên được thực thi chỉ ở cuối hoặc trong suốt quy trình ?
Ý 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 vi cũng hoàn toàn có thể nhìn thấy được ảnh hưởng tác động đó đang được kiểm thử .

Quy trình tương quan[sửa|sửa mã nguồn]

Kiểm thử ứng dụng được sử dụng phối hợp với xác định và xác nhận[sửa|sửa mã nguồn]

  • 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 pháp luật xác định và xác nhận thường được sử dụng thay thế sửa chữa cho nhau trong ngành công nghiệp, mà còn là thông dụng để xem hai thuật ngữ này không đúng lao lý .

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 ứng dụng ( SQA )[sửa|sửa mã nguồn]

Kiểm thử ứng dụng là một phần trong tiến trình bảo vệ chất lượng ứng dụng ( SQA ). Trong SQA, ứng dụng chuyên giải quyết và xử lý và kiểm toán viên được chăm sóc đến quy trình tăng trưởng ứng dụng hơn là chỉ những hiện vật như tài liệu, mã số và mạng lưới hệ thống. Họ kiểm tra và biến hóa ứng dụng tiến trình kỹ thuật riêng của mình để giảm số lượng những lỗi mà kết thúc trong ứng dụng được gửi : cái gọi là ” tỷ suất khiếm khuyết “. Tạo nên cái mà một ” tỷ suất lỗi đồng ý được ” phụ thuộc vào vào thực chất của ứng dụng, một chuyến bay mô phỏng game show video sẽ có năng lực chịu lỗi cao hơn nhiều so với ứng dụng cho máy bay trong thực tiễn. Mặc dù có những link ngặt nghèo với SQA, những phòng kiểm thử thường sống sót một cách độc lập, và hoàn toàn có thể không có tính năng SQA trong một số ít 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.

Liên kết ngoài[sửa|sửa mã nguồn]

Rate this post