Tài liệu kiểm thử phần mềm

Kiểm thử phần mềm (kiểm tra, thử nghiệm) kiểm tra tiến hành để cung cấp cho bên liên quan thông tin chất lượng sản phẩm dịch vụ kiểm thử.[1] Kiểm thử cung cấp cho doanh nghiệp quan điểm, cách nhìn độc lập phần mềm để từ cho phép đánh giá thấu hiểu rủi ro trình triển khai phần mềm Trong kỹ thuật kiểm thử không giới hạn việc thực chương trình ứng dụng với mục đích tìm lỗi phần mềm (bao gồm lỗi thiếu sót) mà q trình phê chuẩn xác minh chương trình máy tính / ứng dụng / sản phẩm nhằm:  Đáp ứng yêu cầu hướng dẫn thiết kế phát triển phần mềm  Thực công việc kỳ vọng  Có thể triển khai với đặc tính tương tự  Và đáp ứng nhu cầu bên liên quan Tùy thuộc vào phương pháp, việc kiểm thử thực lúc trình phát triển phần mềm Theo truyền thống nỗ lực kiểm thử tiến hành sau yêu cầu xác định việc lập trình hồn tất Agile (là tập hợp phương pháp phát triển phần mềm linh hoạt dựa việc lặp lặp lại gia tăng giá trị) việc kiểm thử tiến hành liên tục suốt trình xây dựng phần mềm Như vậy, phương pháp kiểm thử bị chi phối theo quy trình phát triển phần mềm định Mục lục  Tổng quan  Lịch sử  Phương pháp kiểm thử  Các mức kiểm thử  Các loại hình kiểm thử  QUY TRÌNH KIỂM THỬ  Kiểm thử tự động hóa  Kiểm thử thành phần lạ  Những chứng nhận  10 Sự tranh luận  11 Quy trình liên quan  12 Xem thêm  13 Tham khảo  14 Liên kết ngồi Tổng quan Kiểm thử khơng thể xác định hoàn toàn tất lỗi bên phần mềm [2] Thay vào đó, so sánh trạng thái hành vi sản phẩm với oracle - nguyên tắc hay chế để phát vấn đề Các oracle bao gồm (nhưng không giới hạn ở) đặc tả phần mềm, hợp đồng,[3] sản phẩm tương đương, phiên trước sản phẩm, phù hợp với mục đích dự kiến nhằm đáp ứng kỳ vọng người dùng, khách hàng, quy định pháp luật hành tiêu chuẩn liên quan khác Mục đích kiểm thử phát lỗi phần mềm để từ khắc phục sửa chữa Việc kiểm thử khẳng định chức sản phẩm điều kiện, mà khẳng định khơng hoạt động điều kiện cụ thể.[4] Phạm vi kiểm thử phần mềm thường bao gồm việc kiểm tra mã, thực mã môi trường điều kiện khác nhau, việc kiểm thử khía cạnh mã: có làm nhiệm vụ hay khơng, có làm cần phải làm hay không Trong môi trường phát triển phần mềm nay, đội kiểm thử tách biệt với đội phát triển Các thành viên đội kiểm thử giữ vai trò khác Các thơng tin thu từ kiểm thử sử dụng để điều chỉnh trình phát triển phần mềm.[5] Mỗi sản phẩm phần mềm có đối tượng phục vụ riêng Ví dụ đối tượng phần mềm trò chơi điện tử hồn tồn khác với đối tượng phần mềm ngân hàng Vì vậy, tổ chức phát triển đầu tư vào sản phẩm phần mềm, họ đánh giá liệu sản phẩm phần mềm có chấp nhận người dùng cuối, đối tượng phục vụ, người mua, hay người giữ vai trò quan trọng khác hay khơng Và việc kiểm thử phần mềm trình nỗ lực để đưa đánh giá Khiếm khuyết thất bại Không phải tất khiếm khuyết phần mềm bị gây lỗi lập trình mà cội nguồn chung khiếm khuyết nằm thiếu sót u cầu; ví dụ, u cầu không xác nhận mà gây lỗi sơ suất nhà thiết kế chương trình.[6] Những thiếu sót u cầu thường thấy yêu cầu phi chức khả kiểm thử, khả mở rộng, bảo trì, tính khả dụng, hiệu suất, khả bảo mật Lỗi phần mềm xảy thơng suốt q trình sau: Một lập trình viên làm cho lỗi (sai lầm), mà kết cho khiếm khuyết (thất bại, sai sót) mã nguồn phần mềm Nếu lỗi thực hiện, tình định hệ thống tạo kết sai, gây thất bại [7] Không phải tất khiếm khuyết thiết dẫn đến thất bại Ví dụ, lỗi mã chết không dẫn đến thất bại Lỗi biến thành thất bại mơi trường thay đổi Ví dụ thay đổi môi trường bao gồm phần mềm chạy tảng phần cứng máy tính mới, thay đổi nguồn liệu, tương tác với phần mềm khác Một khiếm khuyết dẫn đến loạt dấu hiệu thất bại Kết nối đầu vào điều kiện tiền đề Một vấn đề với kiểm thử phần mềm việc kiểm thử tất kết nối đầu vào điều kiện tiền đề (trạng thái ban đầu) không khả thi, với sản phẩm đơn giản.[4][8] Điều có nghĩa số lượng khiếm khuyết sản phẩm phần mềm lớn xảy thường xuyên nên khó để tìm thấy q trình kiểm thử Quan trọng hơn, yêu cầu phi chức chất lượng (làm làm gì?) như: tính khả dụng, khả mở rộng, hiệu suất, khả tương thích, độ tin cậy xét mặt chủ quan chưa tạo nên giá trị đủ để người chấp nhận Các nhà phát triển phần mềm khơng thể kiểm thử tất thứ, họ sử dụng tổ hợp thiết kế kiểm thử để xác định số lượng tối thiểu kiểm thử cần thiết để bao quát điều họ muốn Dù kiểm thử tốc độ hay độ sâu họ sử dụng phương pháp để xây dựng cấu khác trường hợp kiểm thử (test case) cụ thể.[9] Kinh tế Một nghiên cứu tiến hành NIST năm 2002 cho biết lỗi phần mềm gây tổn thất cho kinh tế Mỹ 59,5 tỷ đô năm, phần ba chi phí tránh việc kiểm thử phần mềm thực tốt [10] Người ta thường tin rằng, kiếm khuyết tìm sớm chi phí để sửa chữa rẻ Bảng cho thấy chi phí sửa chữa khiếm khuyết tùy thuộc vào giai đoạn tìm [11] Ví dụ, vấn đề tìm thấy sau phần mềm thức có chi phí gấp 10-100 lần giải vấn đề từ lúc tiếp nhận yêu cầu Với đời cách thức triển khai thực tiễn liên tục dịch vụ dựa đám mây, chi phí tái triển khai bảo trì làm giảm bớt theo thời gian Thời gian phát Chi phí sửa chữa Các yêu cầu Kiến trúc Sau Xây dựng Kiểm thử khiếm khuyết phần phần phát phần mềm hệ thống mềm mềm hành Các yêu cầu phần 1× 3× 5–10× 10× 10–100× mềm Thời gian Kiến trúc sử dụng – 1× 10× 15× 25–100× phần mềm Xây dựng – – 1× 10× 10–25× phần mềm Vai trò Kiểm thử phần mềm thực nhiều Tester Cho đến năm 1980, thuật ngữ "nhân viên kiểm thử phần mềm" sử dụng thường, sau coi nghề riêng biệt Liên quan đến giai đoạn mục tiêu khác kiểm thử phần mềm[12] vai trò khác thiết lập cho 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 quản trị viên kiểm thử Lịch sử Sự tách biệt việc gỡ lỗi (sửa lỗi, debugging) với kiểm thử (testing) lần Glenford J Myers đưa vào năm 1979 [13] Mặc dù quan tâm ông kiểm thử gián đoạn ("một kiểm thử thành cơng tìm lỗi" [13][14]) minh họa mong muốn cộng đồng công nghệ phần mềm để tách biệt hoạt động phát triển bản, giống việc tách phần gỡ lỗi riêng khỏi trình kiểm thử Vào năm 1988, Dave Gelperin William C Hetzel phân loại giai đoạn mục tiêu kiểm thử phần mềm theo trình tự sau:[15]  Trước 1956: Hướng việc kiểm soát lỗi.[16]  1957-1978: Hướng chứng minh lỗi.[17]  1979-1982: Hướng tính phá hủy lỗi.[18]  1983–1987: Hướng đánh giá lỗi.[19]  1988–2000: Hướng việc phòng ngừa lỗi.[20] Phương pháp kiểm thử Kiểm thử tĩnh động Có nhiều phương pháp để kiểm thử phần mềm Đánh giá, định hướng kiểm tra gọi kiểm thử tĩnh, việc chạy mã lập trình thực tế tình gọi kiểm thử động Kiểm thử tĩnh thơng thường bỏ qua thực hành kiểm thử động diễn thân chương trình sử dụng Kiểm thử động bắt đầu trước chương trình hồn tất 100% để kiểm thử phần cụ thể mã áp dụng cho chức riêng biệt Module Kỹ thuật điển hình cho điều sử dụng mạch nhánh/trình điều khiển thực môi trường gỡ lỗi định Kiểm thử tĩnh liên quan đến việc kiểm chứng kiểm thử động liên quan đến việc xác nhận Nó giúp cải thiện chất lượng phần mềm Phương pháp tiếp cận Theo truyền thống phương pháp kiểm thử phần mềm bắt nguồn từ kiểm thử hộp trắng hộp đen Có hai cách tiếp cận sử dụng để mô tả quan điểm kỹ sư kiểm thử thiết kế Test Case Kiểm thử hộp trắng Bài chi tiết: Kiểm thử hộp trắng Kiểm thử hộp trắng (được biết đến kiểm thử tính rõ ràng hộp, kiểm thử hộp kính, kiểm thử hộp suốt kiểm thử cấu trúc) giúp kiểm thử cấu trúc nội hoạt động chương trình, tương phản với chức bộc lộ người dùng cuối Một góc nhìn nội hệ thống kiểm thử hộp trắng giống kỹ lập trình sử dụng để thiết kế tình kiểm thử Các Tester lựa chọn yếu tố đầu vào để thực đường dẫn thông qua mã xác định kết đầu thích hợp Điều tương tự nút kiểm thử mạch, ví dụ kiểm thử thơng mạch (ICT) Trong kiểm thử hộp trắng áp dụng đơn vị, tích hợp hệ thống cấp độ q trình kiểm thử phần mềm, thường thực cấp đơn vị Nó kiểm thử đường dẫn đơn vị, liên kết đơn vị q trình tích hợp, hệ thống kiểm thử hệ thống cấp Mặc dù phương pháp thiết kế kiểm thử phát nhiều lỗi vấn đề, khơng phát phần chưa thực đặc điểm kỹ thuật yêu cầu thiếu sót Các kỹ thuật sử dụng 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 API cơng cộng cá nhân  Kiểm thử độ bao phủ mã - tạo kiểm thử để đáp ứng số tiêu chí bảo hiểm mã (ví dụ, nhà thiết kế kiểm thử tạo kiểm thử để làm tất câu lệnh chương trình thực lần)  Phương pháp chèn lỗi - cố tình đưa lỗi lầm để đánh giá hiệu 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ã đánh giá đầy đủ kiểm thử tạo phương pháp đó, bao gồm kiểm thử hộp đen Điều cho phép nhóm nghiên cứu phần mềm kiểm thử phận hệ thống mà kiểm thử đảm bảo điểm chức quan trọng kiểm thử.[21] Bao phủ mã giống phần mềm metric báo cáo tỷ lệ phần trăm cho:  Bao phủ chức năng: dựa vào báo cáo chức thực  Bao phủ câu lệnh: dựa vào báo cáo số lượng dòng thực để hoàn thành kiểm thử 100% bao phủ câu lệnh đảm bảo tất đường dẫn mã, nhánh (trong điều kiện luồng điều khiển) thực lần Điều hữu ích việc đảm bảo chức khơng đủ kể từ mã tương tự thực tiến trình xử lý liệu đầu vào khác dù không Kiểm thử hộp đen 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 "hộp đen", kiểm thử chức mà không cần kiến thức cấu trúc hành vi bên phần mềm Các Tester biết phần mềm phải làm mà khơng biết làm [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ặp kiểm thử, bảng chuyển đổi trạng thái, kiểm thử bảng định, kiểm thử chéo, kiểm thử dựa mơ hình, sử dụng Test Case, thăm dò kiểm thử kiểm thử dựa đặc điểm kỹ thuật Kiểm thử dựa đặc điểm kỹ thuật nhằm mục đích để kiểm tra chức phần mềm theo yêu cầu ứng dụng.[23] Mức độ kiểm thử thường đòi hỏi Test Case kỹ lưỡng để cung cấp Tester, người mà sau xác minh cách đơn giản giá trị đầu vào đầu (hoặc cách xử lý) giống không so với giá trị kỳ vọng định vị Test Case định Các Test Case xây dựng quanh thông số kỹ thuật yêu cầu đề xuất, tức tất ứng dụng phải làm Nó sử dụng để mô tả mở rộng phần mềm bao gồm thông số kỹ thuật, yêu cầu thiết kế bắt nguồn Test Case Các kiểm thử chức phi chức Kiểm thử dựa đặc điểm kỹ thuật cần thiết để đảm bảo chức xác, khơng đủ để bảo vệ chống lại tình phức tạp có độ rủi ro cao.[24] Một lợi kỹ thuật kiểm thử hộp đen khơng u cầu thiết phải có kiến thức lập trình Các Tester tiến hành kiểm thử khu vực chức khác phần mềm mà khơng liên quan đến lập trình viên Mặt khác, kiểm thử hộp đen cho "đi mê cung tối tăm mà đèn pin" [25] Bởi họ khơng kiểm thử mã nguồn có nhiều tình Tester kiểm thử tính vài trường hợp khơng kiểm thử tồn hoạt động chương trình Phương pháp kiểm thử áp dụng cho tất cấp kiểm thử phần mềm: đơn vị, tích hợp, hệ thống chấp nhận Nó khơng thể thực tất kiểm thử cấp độ cao tạo ưu tốt kiểm thử đơn vị Kiểm thử trực quan Mục đích kiểm thử trực quan cung cấp nhà phát triển khả kiểm sốt xảy thời điểm phần mềm thất bại theo cách mà họ nhìn thấy thơng tin u cầu rõ ràng dễ hiểu nhất.[26][27] Cốt lõi kiểm thử trực quan ý tưởng giúp nhận vấn đề (hoặc kiểm thử thất bại) thay mơ tả từ giúp cho rõ ràng hiểu biết tăng lên đáng kể Kiểm thử trực quan ln u cầu phải ghi lại tồn tiến trình kiểm thử – chụp lại tất thứ xảy hệ thống định dạng video Các video đầu bổ sung thời gian kiểm thử thực tế đầu vào thông qua hình ảnh từ webcam âm từ micro Kiểm thử trực quan cung cấp số lợi như: Chất lượng giao tiếp tăng lên đáng kể Tester giúp cho nhà phát triển nhìn rõ vấn đề xảy (và kiện dẫn đến nó) khơng phải mơ tả chung chung cần phải sửa chữa lỗi để khơng tồn nhiều trường hợp khác Các nhà phát triển có tất chứng yêu cầu kiểm thử lỗi tập trung vào nguyên nhân gây lỗi làm để cố định Kiểm thử trực quan đặc biệt phù hợp cho môi trường mà triển khai theo phương pháp AGILE phát triển phần mềm đòi hỏi việc giao tiếp tốt Tester nhà phát triển cộng tác nhóm nhỏ với [cần dẫn nguồn] Kiểm thử Ad hoc kiểm thử thăm dò phương pháp quan trọng để kiểm thử tình trạng nguyên vẹn phần mềm chúng đòi hỏi chuẩn bị thời gian để thực thi lỗi quan trọng phải tìm thấy cách nhanh chóng Trong kiểm thử Ad hoc địa điểm kiểm thử vị trí khơng định trước với khả công cụ kiểm thử trực quan giúp ghi lại tất xảy hệ thống trở nên quan trọng.[cần giải thích][cần dẫn nguồn] Kiểm thử trực quan tập trung nhận diện kiểm thử chấp nhận khách hàng tính khả dụng phần mềm kiểm thử nhiều cá nhân liên quan sử dụng trình phát triển [cần dẫn nguồn] Đối với khách hàng, trở nên dễ dàng để cung cấp báo cáo lỗi chi tiết thông tin phản hồi người sử dụng chương trình kiểm thử trực quan ghi lại hành động người dùng tiếng nói hình ảnh họ để cung cấp tranh hoàn chỉnh thời điểm phần mềm thất bại cho nhà phát triển Kiểm thử hộp xám Kiểm thử hộp xám liên quan đến hiểu biết cấu trúc liệu bên thuật toán cho mục đích kiểm thử thiết kế Khi thực kiểm thử với User mức độ hộp đen, Tester không thiết phải truy cập vào mã nguồn phần mềm.[28] Ta thao tác với liệu đầu vào định dạng đầu khơng xác định hộp xám đầu vào đầu rõ ràng bên "hộp đen" mà chúng hệ thống gọi trình kiểm thử Sự phân biệt đặc biệt quan trọng tiến hành kiểm thử tích hợp hai Module viết mã hai nhà phát triển khác nhau, mà có giao diện bộc lộ để kiểm thử Tuy nhiên, kiểm thử mà yêu cầu thay kho lưu trữ liệu back-end sở liệu tập tin đăng nhập không xác định hộp xám, người dùng thay đổi kho lưu trữ liệu sản phẩm hoạt động bình thường Kiểm thử hộp xám bao gồm kỹ thuật đảo ngược để xác định đối tượng, giá trị biên thông báo lỗi Khi biết khái niệm cách thức phần mềm hoạt động nào, Tester thực kiểm thử phần mềm từ bên tốt so với bên thường, Tester hộp xám phép thiết lập môi trường kiểm thử bị cô lập với hoạt động gieo sở liệu Các kiểm thử quan sát trạng thái sản phẩm kiểm thử sau thực hành động định giống việc thực câu lệnh SQL sở liệu sau thực truy vấn để đảm bảo thay đổi dự kiến phản ánh Kiểm thử hộp xám thực kịch kiểm thử thông minh, dựa thông tin hạn chế Điều đặc biệt áp dụng cho kiểu xử lý liệu, kể xử lý ngoại lệ, [29] Các mức kiểm thử Kiểm thử thường xuyên nhóm lại theo địa điểm chúng thêm vào trình phát triển phần mềm, mức độ đặc hiệu kiểm thử Các cấp q trình phát triển theo quy định hướng dẫn SWEBOK đơn vị, kiểm thử hội nhập, kiểm thử hệ thống phân biệt mục tiêu kiểm thử mà không ám mơ hình quy trình cụ thể Các mức độ kiểm thử khác phân loại theo mục tiêu kiểm thử Kiểm thử đơn vị Bài chi tiết: Kiểm thử đơn vị Kiểm thử đơn vị hay gọi kiểm thử thành phần, đề cập đến việc kiểm thử chức phần mã, thường mức độ chức Trong môi trường hướng đối tượng điều thường cấp độ lớp, kiểm thử đơn vị tối thiểu bao gồm hàm dựng hàm hủy Nhiều loại kiểm thử viết nhà phát triển họ làm việc mã (kiểu hộp trắng) để đảm bảo hàm riêng biệt hoạt động kỳ vọng Một hàm có nhiều kiểm thử từ giúp nắm bắt trường hợp góc nhánh Code Kiểm thử đơn vị khơng thể đảm bảo hết chức phận phần phềm sử dụng để đảm bảo khối kiến trúc phần mềm hoạt động độc lập với Kiểm thử đơn vị q trình phát triển phần mềm có liên quan đến ứng dụng đồng loạt chiến lược phòng ngừa phát lỗi để giảm thiểu rủi ro, thời gian chi phí Nó thực kỹ sư hay nhà phát triển suốt giai đoạn xây dựng vòng đời phát triển phần mềm Không tập trung vào việc đảm bảo chất lượng truyền thống mà phải gia tăng lên kiểm thử đơn vị có mục đích loại bỏ lỗi cấu trúc trước mã hóa thúc đẩy việc quản lý chất lượng Chiến lược nhằm nâng cao chất lượng hiệu phần mềm tiến trình quản lý phát triển chung Kiểm tra khối lượng cách để kiểm tra chức phần mềm số thành phần (ví dụ tập tin sở liệu) tăng triệt để kích thước Kiểm thử độ căng cách để kiểm tra độ bền đột xuất gặp theo khối lượng cơng việc Kiểm thử tính ổn định (thường tham chiến lượng tải kiểm thử độ bền) giúp kiểm tra xem phần mềm hoạt động tốt liên tục chu kỳ chấp nhận Có quy ước mục tiêu cụ thể kiểm thử hiệu suất 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 kiểm thử khối lượng, thường sử dụng thay cho Hệ thống phần mềm thời gian thực có ràng buộc xác thời gian Để kiểm thử ràng buộc thời gian đáp ứng người ta dùng phương pháp kiểm thử thời gian thực Kiểm thử tính khả dụng Kiểm tra tính khả dụng cần thiết để kiểm tra xem giao diện có tiện dụng dễ hiểu với người dùng khơng, liên quan trực chủ yếu đến lực sử dụng ứng dụng Kiểm thử khả tiếp cận Kiểm thử khả tiếp cận bao gồm việc tuân thủ 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 đạo luật Phục hồi năm 1973  Sáng kiến tiếp cận Web (WAI) World Wide Web Consortium (W3C) Kiểm thử bảo mật Kiểm thử bảo mật phần mềm cần thiết việc xử lý liệu mật ngăn chặn hacker xâm nhập hệ thống Tính tồn cầu địa hóa Khả tổng quát phần mềm tồn cầu địa hóa tự động kiểm tra mà không dịch thực tế, cách sử dụng phương thức giả địa Nó xác minh ứng dụng hoạt động, sau dịch sang ngơn ngữ thích nghi với văn hóa (chẳng hạn tiền tệ múi khác nhau) Việc thực dịch nhiều ngôn ngữ phải kiểm tra Sự cố địa hóa bao gồm:  Phần mềm thường địa hóa cách dịch danh sách chuỗi khỏi bối cảnh, người dịch chọn dịch sai chuỗi mã nguồn không rõ ràng  Thuật ngữ kỹ thuật trở nên khơng phù hợp dự án phiên dịch số người phối hợp không tốt người dịch thiếu thận trọng  Những dịch từ ngữ theo nghĩa đen không phù hợp, giả tạo kỹ thuật mục tiêu ngôn từ  Thông điệp chưa dịch ngơn ngữ gốc khó mã hố mã nguồn  Một số thơng điệp tạo tự động thời gian chạy chuỗi kết sai ngữ pháp chức khơng xác, dễ gây hiểu lầm khó hiểu  Phần mềm sử dụng phím tắt mà khơng có chức layout phím ngôn ngữ nguồn lại sử dụng để gõ ký tự layout ngôn ngữ mục tiêu  Phần mềm thiếu hỗ trợ cho ký tự mã hóa ngơn ngữ mục tiêu  Phơng chữ kích thức chữ phù hợp ngơn ngữ nguồn khơng phù hợp ngơn ngữ mục tiêu Ví dụ, ký tự CJK không đọc font chữ nhỏ  Một chuỗi ngơn ngữ mục tiêu kéo dài so với xử lý phần mềm Điều làm cho phần chuỗi bị ẩn với người dùng gây số va chạm cố với phần mềm  Phần mềm thiếu hỗ trợ thích hợp cho việc đọc viết văn hai chiều  Phần mềm hiển thị hình ảnh với văn mà khơng địa hóa  Những hệ điều hành địa khác cách đặt tên file cấu hình hệ thống, biến mơi trường định dạng khác cho ngày tháng tiền tệ Kiểm thử phát triển Kiểm thử phát triển tiến trình phát triển phần mềm có liên quan đến ứng dụng đồng loạt chiến lược phòng ngừa phát lỗi để giảm thiểu rủi ro thời gian chi phí Nó thực kỹ sư nhà phát triển giai đoạn xây dựng vòng đời phát triển phần mềm Không thay trọng tâm QA truyền thống mà phải bổ sung Kiểm thử phát triển nhằm mục đích loại bỏ lỗi xây dựng trước mã đẩy mạnh QA, chiến lược nhằm nâng cao chất lượng phần mềm hiệu phát triển chung trình QA Tùy thuộc vào kỳ vọng tổ chức phát triển phần mềm, kiểm tra phát triển bao gồm phân tích mã tĩnh, phân tích luồng 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, thực hành xác minh phần mềm khác Kiểm thử A/B Kiểm thử A/B phương pháp sử dụng quảng cáo thí nghiệm ngẫu nhiên với hai biến thể A B, có kiểm sốt điều trị kiểm thử có kiểm sốt Những thí nghiệm thường sử dụng phát triển web tiếp thị, nhiều hình thức quảng cáo truyền thống QUY TRÌNH KIỂM THỬ Mơ hình truyền thống CMMI mơ hình phát triển thác nước Một thực tế phổ biến kiểm thử phần mềm kiểm thử thực nhóm Tester độc lập sau chức phát triển trước chuyển tới khách hàng Thực hành thường kết giai đoạn kiểm thử sử dụng đệm tham chiếu để bù đắp cho độ trễ tham chiếu ảnh hưởng đến thời gian dành cho việc kiểm thử Một thực tế khác khởi động kiểm thử phần mềm thời điểm bắt đầu dự án trình liên tục dự án kết thúc Mơ hình phát triển Agile or Extreme Ngược lại, số quy tắc phần mềm lên lập trình cực đoan chuyển động phát triển phần mềm AGILE, tn thủ mơ hình "Test – Driven Development " (TDD) Trong quy trình này, kiểm thử đơn vị viết kỹ sư phần mềm (thường lập trình song song phương pháp lập trình Extreme) Tất nhiên kiểm thử bước đầu thất bại dự kiến, sau Code viết xong phần lớn Test Suite bước tăng lên Nó cập nhật lỗi điều kiện trường hợp tiềm ẩn vừa phát ra, chúng tích hợp với kiểm thử hồi quy phát triển Kiểm thử đơn vị trì với phần lại mã nguồn phần mềm tích hợp chung vào q trình xây dựng (với kiểm thử tương tác vốn bị loại bỏ q trình xây dựng mức chấp nhận thơng thường) Mục tiêu cuối trình kiểm thử để đạt việc triển khai liên tục mà cập nhật phần mềm cơng bố cho công chúng thường xuyên Phương pháp làm tăng nỗ lực kiểm thử trước động đến nhóm kiểm thử thức Trong số mơ hình phát triển khác, hầu hết việc thực hành kiểm thử xảy sau yêu cầu xác định q trình mã hóa hồn thành Mơ hình từ xuống mơ hình từ lên Kiểm thử từ lên cách tiếp cận để kiểm thử tích hợp nơi thành phần tồn cấp độ thấp (Các Module, biện pháp chức năng) kiểm thử đầu tiên, sau tích hợp sử dụng để tạo thuận lợi cho việc kiểm thử thành phần cấp cao Sau kiểm thử tích hợp Module cấp độ thấp tiến hành kiểm thử cấp độ Quá trình lặp lặp lại thành phần trật tự hệ thống kiểm tra Cách tiếp cận hữu ích tất hầu hết Module có cấp độ phát triển tương đương sẵn sàng kiểm thử Phương pháp giúp xác định cấp độ phát triển phần mềm làm cho dễ dàng để báo cáo tiến độ kiểm thử theo tỷ lệ phần trăm Kiểm thử từ xuốnglà cách tiếp cận để kiểm thử tích hợp Module đầu với Module nhánh kiểm tra bước kết thúc Module liên quan rong hai phương pháp trình điều khiển sử dụng để cố định thành phần bị thiếu sót hồn thiện cấp độ thay Một chu kỳ kiểm thử mẫu Dẫu cho biến thể tồn tổ chức lập trình có quy trình điển hình để kiểm thử Mẫu phổ biến 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 tìm thấy mơ hình phát triển khác, có khơng rõ ràng  Phân tích u cầu: Kiểm thử thường bắt đầu lấy yêu cầu giai đoạn vòng đời phát triển phần mềm Trong giai đoạn thiết kế, Tester làm việc với nhà phát triển để xác định khía cạnh thiết kế kiểm chứng thông số 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ó kế hoạch cần thiết nhiều hoạt động thực thời gian kiểm thử  Kiểm thử phát triển: Các quy trình kiểm thử, kịch bản, Test Case, liệu sử dụng kiểm thử phần mềm  Kiểm thử thực hiện: Dựa kế hoạch, văn kiểm thử báo cáo lỗi tìm thấy cho nhóm phát triển  Kiểm thử báo cáo: Sau hoàn tất kiểm thử, Tester tạo số liệu báo cáo cuối nỗ lực kiểm thử họ có sẵn sàng phát hành phần mềm hay khơng  Phân tích kết kiểm thử phân tích thiếu sót thực đội ngũ phát triển kết hợp với khách hàng để đưa định xem thiếu sót cần phải chuyển giao, cố định từ bỏ (tức tìm phần mềm hoạt động xác) giải sau  Test lại khiếm khuyết: Khi khiếm khuyết xử lý đội ngũ phát triển, phải kiểm tra lại nhóm kiểm thử  Kiểm thử hồi quy: Người ta thường xây dựng chương trình kiểm thử nhỏ tập hợp kiểm tra cho tích hợp mới, sửa chữa cố định phần mềm, để đảm bảo cung cấp không phá hủy điều tồn phần mềm hoạt động cách xác Kiểm thử đóng gói: Mỗi phép thử thỏa mãn tiêu truy xuất thu kết quan như: học kinh nghiệm, kết quả, ghi, tài liệu liên quan lưu trữ sử dụng tài liệu tham khảo cho dự án tương lai Kiểm thử tự động hóa Nhiều nhóm lập trình ngày dựa vào kiểm thử tự động, đặc biệt nhóm sử dụng mơ hình TDD (Test – Drive – Development) Có nhiều framework viết bên mã phiên chạy kiểm thử tự động lúc tích hợp liên tục phần mềm Khi kiểm thử tự động chép tất thứ người làm (và tất cách họ nghĩ để làm việc đó) hữu ích cho việc kiểm thử hồi quy Tuy nhiên, đòi hỏi phải có kịch phát triển tốt để tiến hành kiểm thử Các công cụ kiểm thử Chương trình kiểm thử phát lỗi hỗ trợ đáng kể công cụ kiểm thử gỡ lỗi Các công cụ kiểm thử/gỡ lỗi bao gồm tính như:  Những hình chương trình cho phép giám sát tồn phần mã chương trình gồm: o Lệnh thiết lập simulator cho phép giám sát hoàn chỉnh cấp hướng dẫn thiết bị vi lượng o Hình ảnh chương trình cho phép thực bước ngắt đoạn có điều kiện cấp nguồn mã máy o Các báo cáo độ bao phủ mã  Các công cụ gỡ lỗi biểu tượng kết xuất định dạng cho phép kiểm tra biến chỗ lỗi điểm lựa chọn  Các công cụ kiểm thử GUI chức tự động 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 hoạt động  Phân tích hiệu suất (hoặc cơng cụ định hình) giúp làm bật điểm tới hạn sử dụng tài ngun Một số tính kết hợp vào mơi trường phát triển tích hợp (IDE) Đo lường kiểm thử phần mềm Thông thường, chất lượng bị hạn chế đến chủ đề tính xác, tính hồn chỉnh tính bảo mật bao gồm yêu cầu kỹ thuật mô tả tiêu chuẩn ISO (ISO / IEC 9126), chẳng hạn khả năng, độ tin cậy, hiệu quả, tính di động, độ bảo trì, khả tương thích khả sử dụng Có số số liệu thường sử dụng độ đo phần mềm, biện pháp sử dụng để hỗ trợ việc xác định tình trạng phần mềm tính đầy đủ kiểm thử Kiểm thử thành phần lạ Quá trình kiểm thử phần mềm tạo số thành phần lạ Kế hoạch kiểm thử Một kiểm thử đặc điểm kỹ thuật gọi kế hoạch kiểm thử Các nhà phát triển nhận thức rõ kế hoạch kiểm thử thực thông tin cung cấp cho nhà quản lý nhà phát triển Ý tưởng để làm cho họ thận trọng phát triển mã họ làm thay đổi bổ sung Một số cơng ty có tài liệu cao cấp gọi chiến lược kiểm thử Ma trận truy xuất nguồn gốc Một ma trận truy xuất nguồn gốc bảng tương quan yêu cầu tài liệu thiết kế tài liệu kiểm thử Nó sử dụng để thay đổi kiểm tra nguồn tài liệu liên quan thay đổi, chọn Test Case để thực lập kế hoạch để kiểm thử hồi quy cách xem yêu cầu độ bao phủ Tình kiểm thử (Test Case) Một Test Case thông thường bao gồm ký hiệu nhận dạng nhất, tài liệu tham khảo yêu cầu từ thông số thiết kế, điều kiện tiền đề, kiện, loạt bước (còn gọi hành động) để làm theo, đầu vào, đầu ra, kết dự kiến, kết thực tế Lâm sàng xác định Test Case đầu vào kết kỳ vọng Hiểu cách đơn giản Test Case có liệu đầu vào có kết đầu Điều có thực tế "cho điều kiện X kết bắt nguồn lại bạn Y", Test Case khác mô tả chi tiết kịch đầu vào kỳ vọng kết Nó đơi loạt bước (nhưng thường chứa thủ tục kiểm tra riêng biệt mà thực nhiều Test Case) tương ứng với loạt kết kỳ vọng Kịch kiểm thử Kịch kiểm thử thử tục mà lập trình viên chép thao tác người dùng Ban đầu, thuật ngữ bắt nguồn từ sản phẩm công việc tạo công cụ kiểm thử hồi quy tự động Test Case sở để tạo kịch kiểm thử sử dụng công cụ chương trình Bộ kiểm thử Các thuật ngữ phổ biến sưu tập Test Case kiểm thử Các kiểm thử thường hướng dẫn chi tiết có mục tiêu cho sưu tập Test Case Nó chắn có phần mà thử nghiệm xác định cấu hình hệ thống sử dụng q trình test Một nhóm Test Case chứa trạng thái bước điều kiện tiên quyết, mô tả kiểm thử sau Kiểm thử thiết bị cố định liệu Trong hầu hết trường hợp, nhiều giá trị liệu sử dụng để kiểm tra chức tương tự tính đặc biệt Tất giá trị kiểm thử thành phần môi trường thay đổi thu thập tập tin riêng biệt lưu trữ liệu kiểm thử Nó hữu ích để cung cấp liệu cho khách hàng cho sản phẩm dự án Kiểm thử an tồn Phần mềm, cơng cụ, mẫu liệu đầu vào đầu ra, cấu hình gọi chung kiểm thử an toàn Những chứng nhận Một số chương trình chứng nhận hành hỗ trợ Tester chuyên gia bảo đảm chất lượng phần mềm trì khát vọng nghề nghiệp Những đòi hỏi nghề nghiệp khả kiến thức khiến số người không thực sẵn sàng Và không đủ lực kiến thức mà làm chắn ảnh hưởng đến chất lượng tính chuyên nghiệp phần mềm Các loại giấy chứng nhận kiểm thử phần mềm  Dựa vào thi cử: Bạn cần phải vượt qua kỳ thi thức tự học (ví dụ cho ISTQB – Hội đồng đánh giá trình độ chun 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 giảng hướng dẫn khóa học giúp bạn chứng nhận (ví dụ: Viện nghiên cứu quốc tế kiểm thử phần mềm) Các giấy chứng nhận kiểm thử  Hiệp hội chứng nhận kiểm thử phần mềm (CAST) cung cấp Viện bảo đảm chất lượng  CATe cung cấp Viện quốc tế kiểm thử phần mềm  Chứng nhận quản lý kiểm thử phần mềm (CMST) cung cấp Viện bảo đảm chất lượng  Chứng nhận quản lý kiểm thử (CTM) cung cấp Viện quốc tế kiểm thử phần mềm  Chứng nhận phần mềm Tester (CSTE) cung cấp 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) cung cấp Viện quốc tế kiểm thử phần mềm  CSTP (TM) (phiên Australia) cung cấp KJ Ross & Associates  ISEB cung cấp Hội đồng hệ thống thông tin thi cử  ISTQB Certified Tester, Quỹ Cấp (CTFL) cung cấp phần mềm kiểm tra Hội đồng Văn quốc tế  ISTQB Certified Tester, Cao cấp (CTAL) cung cấp phần mềm kiểm tra Hội đồng Văn quốc tế  Quỹ TMPF TMap Next theo cung cấp Viện Kiểm tra Khoa học Thông tin  TMPA TMap Next Advanced cung cấp Viện Kiểm tra Khoa học Thông tin Chứng nhận đảm bảo chất lượng  CMSQ cung cấp Viện Bảo đảm Chất lượng (QAI)  CSQA cung cấp Viện Bảo đảm Chất lượng (QAI)  CSQE cung cấp Hiệp hội chất lượng Hoa Kỳ (ASQ)  CQIA cung cấp Hiệp hội chất lượng Hoa Kỳ (ASQ) Sự tranh luận Một số tranh luận 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 gì? Thành viên trường kiểm thử "bối cảnh theo định hướng" tin khơng có "các thực hành tốt nhất" mà tập hợp kỹ cho phép thử nghiệm để chọn phát minh thực hành kiểm thử phù hợp với hoàn cảnh đặc biệt AGILE so với Truyền thống Các Tester nên học cách làm việc điều kiện không chắn thay đổi liên tục họ nên nhắm vào trình "trưởng thành"? Phong trào kiểm thử AGILE phổ biến ngày tăng kể từ năm 2006 chủ yếu giới thương mại, việc cung cấp phần mềm sử dụng phương pháp cho phủ quân mà mơ hình thử nghiệm, lựa chọn cuối kiểm thử theo truyền thống (ví dụ mơ hình thác nước) Thăm dò kiểm thử so với kịch Các test phải thiết kế đồng thời chúng thực họ cần thiết kế trước? Hướng dẫn kiểm thử so với tự động Một số tác giả tin kiểm thử tự động hóa đắt so với giá trị mà nên sử dụng cách tiết kiệm Thêm nữa, quốc gia phát triển kiểm thử điều khiển nhà phát triển phải viết đơn vị kiểm thử xUnit, trước mã hóa chức Các kiểm thử sau coi cách để nắm bắt thực yêu cầu Thiết kế phần mềm so với thực phần mềm Kiểm thử nên thực cuối suốt trình? Ai quan sát? Ý tưởng hình thức quan sát kiểm thử tương tác hành động nhìn thấy ảnh hưởng kiểm thử Quy trình liên quan Kiểm thử phần mềm sử dụng kết hợp với xác minh xác nhận  Xác minh: Chúng ta xây dựng quyền phần mềm? (nghĩa là, thực yêu cầu)  Xác nhận: Chúng xây dựng phần mềm? (nghĩa là, không đáp ứng yêu cầu khách hàng) Các điều khoản xác minh xác nhận thường sử dụng thay cho ngành cơng nghiệp, mà phổ biến để xem hai thuật ngữ không quy định Theo chuẩn IEEE Thuật ngữ Công nghệ Phần Mềm:  Xác minh trình đánh giá hệ thống hay thành phần để xác định xem sản phẩm giai đoạn phát triển định đáp ứng điều kiện áp đặt lúc bắt đầu giai đoạn  Xác nhận trình đánh giá hệ thống hay cấu phần hay cuối trình phát triển để xác định xem đáp ứng yêu cầu quy định Theo tiêu chuẩn ISO 9000:  Xác minh khẳng định cách kiểm tra thông qua cung cấp chứng khách quan yêu cầu cụ thể thực  Xác nhận khẳng định cách kiểm tra thông qua cung cấp chứng khách quan yêu cầu cho mục đích sử dụng cụ thể ứng dụng hoàn thành Đảm bảo chất lượng phần mềm (SQA) Kiểm thử phần mềm phần 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ý kiểm toán viên quan tâm đến trình phát triển phần mềm vật tài liệu, mã số hệ thống Họ kiểm tra thay đổi phần mềm quy trình kỹ thuật riêng để giảm số lượng lỗi mà kết thúc phần mềm gửi: gọi "tỷ lệ khiếm khuyết" Tạo nên mà "tỷ lệ lỗi chấp nhận được" phụ thuộc vào chất phần mềm, chuyến bay mô trò chơi video có khả chịu lỗi cao nhiều so với phần mềm cho máy bay thực tế Mặc dù có liên kết chặt chẽ với SQA, phòng kiểm thử thường tồn cách độc lập, khơng có chức SQA số công ty Kiểm thử phần mềm nhiệm vụ có ý định để phát lỗi phần mềm cách đối chiếu kết kỳ vọng từ chương trình máy tính với kết thực tế cho tập hợp yếu tố đầu vào Ngược lại, bảo đảm chất việc thực sách thủ tục nhằm ngăn ngừa khiếm khuyết xảy nơi Xem thêm  Hiệp Hội Kiểm Định Kiểm Tra Phần Mềm Quốc tế Tham khảo ^ Exploratory Testing, Cem Kaner, Florida Institute of Technology, Quality Assurance Institute Worldwide Annual Software Testing Conference, Orlando, FL, November 2006 ^ Software Testing by Jiantao Pan, Carnegie Mellon University ^ 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 ^ a ă Kaner, Cem; 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 Lỗi thích: Thẻ không hợp lệ: tên “Kaner1” định rõ nhiều lần, lần có nội dung khác ^ Kolawa, Adam; Huizinga, Dorota (2007) Automated Defect Prevention: Best Practices in Software Management Wiley-IEEE Computer Society Press tr 41–43 ISBN 0-470-04212-5 ^ Kolawa, Adam; Huizinga, Dorota (2007) Automated Defect Prevention: Best Practices in Software Management Wiley-IEEE Computer Society Press tr 426 ISBN 0-470-04212-5 ^ Section 1.1.2, Certified Tester Foundation Level Syllabus, International Software Testing Qualifications Board ^ Principle 2, Section 1.3, Certified Tester Foundation Level Syllabus, International Software Testing Qualifications Board ^ “Proceedings from the 5th International Conference on Software Testing and Validation (ICST) Software Competence Center Hagenberg "Test Design: Lessons Learned and Practical Implications.” ^ Software errors cost U.S economy $59.5 billion annually, NIST 10 report 11 12 13 ^ McConnell, Steve (2004) Code Complete (ấn 2) Microsoft Press tr 29 ISBN 0-7356-1967-0 ^ see D Gelperin and W.C Hetzel ^ a ă 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 ^ Gelperin, D.; B Hetzel (1988) “The Growth of Software Testing” CACM 31 (6): 687 ISSN 0001-0782 doi:10.1145/62959.62965 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 Gelperin, D.; B Hetzel (1988) “The Growth of Software Testing” CACM 31 (6) ISSN 0001-0782 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 Gelperin, D.; B Hetzel (1988) “The Growth of Software Testing” CACM 31 (6) ISSN 0001-0782 18 ^ The time between 1979–1982 is announced as the destruction oriented period, where the goal was to find errors Gelperin, D.; B Hetzel (1988) “The Growth of Software Testing” CACM 31 (6) ISSN 0001-0782 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 Gelperin, D.; B Hetzel (1988) “The Growth of Software Testing” CACM 31 (6) ISSN 0001-0782 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 Gelperin, D.; B Hetzel (1988) “The Growth of Software Testing” CACM 31 (6) ISSN 0001-0782 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” (PostScript) Dept of Computer Science, Sheffield University, UK Truy cập ngày 13 tháng năm 2008 24 ^ Bach, James (tháng năm 1999) “Risk and Requirements-Based Testing” (PDF) Computer 32 (6): 113–114 Truy cập ngày 19 tháng 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 năm 2012 27 ^ “Article on visual testing in Test Magazine” Testmagazine.co.uk Truy cập ngày 13 tháng năm 2012 28 29 ^ Patton, Ron Software Testing ^ “SOA Testing Tools for Black, White and Gray Box SOA Testing Techniques” Crosschecknet.com Truy cập ngày 10 tháng 12 năm 2012 ... phần mềm, biện pháp sử dụng để hỗ trợ việc xác định tình trạng phần mềm tính đầy đủ kiểm thử Kiểm thử thành phần lạ Q trình kiểm thử phần mềm tạo số thành phần lạ Kế hoạch kiểm thử Một kiểm thử. .. xuất phần mềm Kiểm thử Alpha thường sử dụng cho phần mềm đại trà (đóng gói sẵn để bán) hình thức kiểm thử mức chấp nhận nội trước phần mềm thức vào giai đoạn kiểm thử Beta Kiểm thử Beta Kiểm thử. .. Các mức độ kiểm thử khác phân loại theo mục tiêu kiểm thử Kiểm thử đơn vị Bài chi tiết: Kiểm thử đơn vị Kiểm thử đơn vị hay gọi kiểm thử thành phần, đề cập đến việc kiểm thử chức phần mã, thường