Chương 4: Kiểm thử phần mềm

Chapter 4: Phần mềm Testing

Nhóm 4:

Phạm Văn Thiện

Ngô Thế Hải Anh

Nguyễn Anh Tuấn

Giới thiệu

Kiểm thử phần mềm kể cả việc kiểm chứng động (dynamic), này là một chương trình phân phối các hành vi dự tính trên một tập hữu hạn các trường hợp thử nghiệm, thích hợp được lựa chọn từ các miền thực hiện thường là vô hạn.
Các vấn đề mấu chốt trong việc miêu tả các học thức kiểm thử phần mềm (knowledge area – KA) dưới đây:

  • Dynamic

Thuật ngữ này có nghĩa là kiểm thử luôn luôn bao gồm thực thi chương trình khi lựa chọn đầu vào (input). Để được chuẩn xác, giá trị đầu vào đơn (alone) không phải bao giờ cũng đủ để xác nhận 1 bài check, vì một hệ thống không xác nhận cầu kỳ có thể phản ứng với các đầu vào cùng với các hành vi khác nhau, tùy thuộc vào vào tình trạng hệ thống. Ngoài ra trong KA này, thuật ngữ đầu vào sẽ phải được duy trì, với quy ước bao hàm rằng ý nghĩa của nó cũng bao gồm một tình trạng đầu vào quy định trong những trường hợp trọng yếu. Các kỹ thuật tĩnh khác nhau & hỗ trợ cho kiểm thử động. Các kỹ thuật tĩnh được bao gồm trong Phần mềm Quality KA. Điều đáng lưu ý là thuật ngữ không hợp nhất giữa các cộng đồng khác nhau & một số sử dụng thuật ngữ “kiểm thử” trong mối liên hệ với các kỹ thuật tĩnh.

  • Kiểm thử tĩnh: Kiểm thử tĩnh là một cách thức của kiểm thử phần mềm mà phần mềm không được sử dụng thực sự. Điều này ngược với thử nghiệm động. Thường thì nó không kiểm thử cụ thể mà chủ chốt kiểm soát tính chính xác của code (mã lệnh), thuật toán hay ebook. Cốt yếu là kiểm soát cú pháp của code &/hoặc review code (là kiểm soát xem code có được viết theo đúng tiêu chí code – chẳng hạn cách đặt tên hàm tên biến, cách dùng hàm chung,… đã đề ra hay chưa) hoặc ebook để tìm lỗi bằng cách thủ công. Đây là loại kiểm thử có thể được sử dụng bởi DEV (những người lập trình), làm việc một cách độc lập. Các kỹ thuật review code, kiểm soát & walkthroughs cũng được sử dụng trong kiểm thử tĩnh này. Từ hướng nhìn theo quan niệm của kiểm thử hộp đen, kiểm thử tĩnh liên quan tới việc suy xét các yêu cầu & các ebook kiến trúc cụ thể (chẳng hạn Spec, SRS, BSS). Điều này được thực hiện với một khoảng cách nhìn hướng đến đầy đủ hay thích hợp cho các bổ phận. Lỗi được phát hiện ở công đoạn lớn mạnh đó là ít tốn kém để sửa chữa hơn đối với bug phát hiện được ở các công đoạn sau này trong các quy trình lớn mạnh phần mềm.

  • Finite:

Ngay cả trong các chương trình dễ dàng, rất là nhiều trường hợp kiểm thử về mặt lý thuyết đòi hỏi kiểm soát toàn diện có thể yêu cầu nhiều tháng hoặc nhiều năm để thực hiện. Này là nguyên nhân vì sao trong thực tiễn, một tập đẩy đủ các kiểm thử có thể được xem như là vô hạn, & sự kiểm thử được tiến hành trên một tập toàn bộ các bài kiểm thử khả thi, có thể được xác nhận theo các tiêu chuẩn nguy cơ & ưu tiên. Kiểm thử luôn bao hàm sự cân đối giữa các tài nguyên giới hạn & tiến độ.

  • Selected:

Có nhiều kỹ thuật kiểm thử khác nhau được đề nghị trong một tập kiểm thử được chọn, & các kỹ sư phần mềm phải được nhận thức rằng các tiêu chuẩn lựa chọn khác nhau có thể đem lại sự khác nhau về tính hiệu quả. Nhưng làm sao mà xác nhận các tiêu chuẩn lựa chọn phù thống nhất trong điều kiện khẳng định là 1 vấn đề cầu kỳ.

  • Expected:

Cần có khả năng, dù rằng không phải bao giờ cũng đơn giản, để quyết định xem các kết quả xem xét của chương trình thử nghiệm được chấp thuận hay không; còn nếu không, các cố gắng thử nghiệm là vô bổ. Các hành vi xem xét có thể được so sánh với nhu cầu của người tiêu dùng (thường được gọi là thử nghiệm để xác định), chống lại một đặc tính kỹ thuật (thử nghiệm để kiểm tra), hoặc, có vẻ, so với các hành vi được đợi mong từ các yêu cầu bao hàm hoặc đợi mong (xem thử nghiệm Đồng ý trong các yêu cầu phần mềm KA ).
Trong những năm gần đây, kiểm thử không còn được xem như là một hoạt động mà chỉ khởi đầu sau thời điểm công đoạn coding được giải quyết với mục đích giới hạn của việc phát hiện lỗi. Kiểm thử phần mềm trở nên thông dụng trong suốt tiến trình lớn mạnh & bảo dưỡng. Kế sách kiểm thử phần mềm nên khởi đầu với công đoạn đầu của quy trình yêu cầu phần mềm, các kế sách & quy trình thử nghiệm phải được lớn mạnh một cách có hệ thống & liên tục – & có thể tinh chế – như tiến hành lớn mạnh phần mềm. Những hoạt động lập kế sách kiểm thử & thử nghiệm kiến trúc phân phối các đầu vào hữu hiệu cho các nhà kiến trúc phần mềm & giúp họ làm nổi trội những điểm yếu, thiết sót.
So với nhiều tổ chức, cách thức tiếp cận đến chất lượng phần mềm là một trong những sự ngăn chặn: tức là ngăn chặn vấn đề tốt hơn là sửa chữa chúng. Kiểm thử có thể được chứng kiến, sau đó, được dùng như một phương tiện để phân phối thông tin về các chức năng & chất lượng các tính chất của phần mềm & cũng để xác nhận lỗi trong những trường hợp ngăn chặn lỗi không có hiệu quả. Sự thật hẳn nhiên là phần mềm có thể chứa lỗi, thậm chí sau thời điểm giải quyết việc kiểm thử bao quát. Các lỗi phần mềm có sau đó sẽ được khắc phục bằng bảo dưỡng sửa chữa. Mục bảo dưỡng phần mềm có trong phần Phần mềm Mainteance KA (chương 5).
Trong Kỹ thuật làm chủ chất lượng phần mềm, được phân loại thành 2 kỹ thuật đáng lưu ý là Tĩnh (không thực thi mã) & động (thực thi mã). KA này chăm chú & các kỹ thuật động. Kiểm thử phần mềm cũng có liên quan đến xây dựng phần mềm.

Cụ thể đề tài kiểm thử phần mềm

1. Kiểm thử phần mềm căn bản

1.1. Thuật ngữ liên quan đến kiểm thử.

1.1.1. Khái niệm về kiểm thử & thuật ngữ liên quan

Kiểm thử phần mềm là 1 cuộc kiểm soát được tiến hành để phân phối cho các bên liên quan thông tin về chất lượng của máy hoặc dịch vụ được kiểm thử. Kiểm thử có thể phân phối cho công ty một quan niệm, một cách nhìn độc lập về phần mềm để từ đó cho phép nhận xét & hiểu rõ được những nguy cơ trong tiến trình triển khai phần mềm.
Trong kỹ thuật kiểm thử chẳng những hạn chế ở việc thực hiện một chương trình hoặc vận 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 & các thiếu sót) mà đang là một tiến trình phê duyệt & kiểm tra một chương trình laptop / vận dụng / sản phẩm nhằm:
• Giải quyết được mọi yêu cầu chỉ dẫn khi kiến trúc & lớn mạnh phần mềm.
• Thực hiện công việc đúng như hy vọng.
• Có thể triển khai được với những đặc điểm tương đương.
• & giải quyết được mọi nhu cầu của các bên liên quan.
Tùy vào vào từng cách thức, việc kiểm thử có thể được thực hiện bất kì bao giờ trong tiến trình lớn mạnh phần mềm.

1.1.2. Lỗi & chịu lỗi

1.2. Key Issues (Các vấn đề chính)

1.2.1. Tiêu chuẩn lựa chọn kiểm thử/Kiểm tra mức độ đầy đủ tiêu chuẩn

Tiêu chuẩn lựa chọn thử nghiệm có nghĩa là lựa chọn trường hợp kiểm thử hoặc xác nhận một tập các trường hợp kiểm thử là đủ cho một mục đích rõ ràng.

1.2.2. Hiệu quả kiểm thử/Mục tiêu kiểm thử

Hiệu quả kiểm thử được xác nhận bằng cách nghiên cứu một tập hợp các chương trình thực thi. Lựa chọn kiểm thử được thực hiện có thể được chỉ dẫn bởi các mục tiêu khác nhau.

1.2.3. Kiểm thử phát hiện khiếm khuyết

Phát hiện lỗi hoặc những khiếm khuyết của phần mềm để thấy được cư xử của nó có chuẩn xác hoặc phù phù hợp với ebook đặc tả của nó hay không. Về mặt lý thuyết, tất cả chúng ta phải kiểm thử hệ thống một cách cặn kẽ thì mới cam kết được chương trình không còn khiếm khuyết. Ngoài ra, trong thực tiễn chẳng thể kiểm thử một cách cặn kẽ được.

1.2.4. Các vấn đề về Oracle

Oracle là bất kỳ người hoặc máy móc dùng để quyết định xem liệu một chương trình có thực hiện một cách chuẩn xác trong một thử nghiệm khẳng định & thích hợp kết quả là đạt hoặc thất bại (các phép tắc hay chính sách phát hiện vấn đề). Kiểm thử không cơ thể định hoàn toàn được toàn bộ các lỗi bên trong phần mềm. Thay vào đó, nó so sánh tình trạng & hành vi của máy với các oracle. Các oracle này có thể bao gồm (nhưng không hạn chế ở) các đặc tả phần mềm, hợp đồng, sản phẩm tương tự, các phiên bản trước của cùng một sản phẩm, phù phù hợp với mục đích dự tính nhằm thỏa mãn sự hy vọng của người dùng, KH, quy định của luật pháp hiện hành & các tiêu chí liên quan khác.

1.2.5. Hạn chế lý thuyết & thực tế của kiểm thử

1.2.6. Vấn đề về đường dẫn không khả thi

Đường dẫn không khả thi là các đường dẫn luồng điều khiển chẳng thể được thực thi bởi bất kỳ dữ liệu đầu vào.

1.2.7. Khả năng kiểm thử
Khả năng kiểm thử là mức độ mà một thành phần phần mềm (hệ thống phần mềm, module, ebook kiến trúc) suport kiểm thử trong một hoàn cảnh kiểm thử khẳng định. Nếu khả năng kiểm thử của thành phần phần mềm cao, thì việc tìm kiếm lỗi trong hệ thống (nếu có) bằng việc kiểm thử được đơn giản hơn.

1.3. Mối quan hệ của kiểm thử với các hoạt động khác

  • Kiểm thử vs kỹ thuật làm chủ chất lượng phần mềm tĩnh
  • Kiểm thử vs Chứng cứ về tính chính xác & kiểm tra cách thức
  • Kiểm thử vs Gỡ lỗi
  • Kiểm thử vs Xây dựng chương trình

2. Check Levels

Kiểm thử phần mềm thường được thực hiện ở các cấp độ khác nhau trong suốt tiến trình lớn mạnh & bảo dưỡng. Mức có thể được phân biệt dựa vào các đối tượng thử nghiệm, được gọi là các target, hoặc về mục đích, được gọi là các objective (từ cấp thử nghiệm).

2.1. Mục tiêu của kiểm thử (Target of the Check)

Mục tiêu của thử nghiệm có thể khác nhau: một mô-đun duy nhất, một nhóm các mô-đun như (liên quan theo mục đích, sử dụng, hành vi, hoặc cơ cấu), hay toàn hệ thống. Ba công đoạn thử nghiệm có thể được phân biệt: nhà cung cấp, tích hợp & hệ thống.

2.1.1. Kiểm thử nhà cung cấp

Unit testing đề cập đến các kiểm thử để chứng nhận (kiểm tra – verify) tính năng của một phần biệt lập của code, thường ở mức hàm (function level). Trong một môi trường hướng đối tượng (object-oriented environment), kiểm thử nhà cung cấp hay được sử dụng ở mức lớp (class) & kiểm thử các nhà cung cấp nhỏ nhất bao gồm các hàm constructor & destructor.

Loại kiểm thử này thường được viết bởi các DEV như công việc của họ trong việc code (loại check white-box), để đảm bảo rằng từng hàm biệt lập hoạt động đúng theo mong chờ. Một hàm có thể có nhiều kiểm thử, để bắt được các trường hợp hoặc các nhánh trong code. Unit testing một mình chẳng thể đảm bảo tính năng của một phòng ban của phần mềm mà là sử dụng để đảm bảo rằng các khối thiết kế của phần mềm làm việc độc lập với nhau.
Unit testing (kiểm thử nhà cung cấp) cũng được gọi là component testing (kiểm thử thành phần).

2.1.2. Kiểm thử tích hợp

Integration testing là một loại kiểm thử phần mềm mà tìm kiếm để kiểm soát các giao diện giữa các thành phần dựa theo kiến trúc của phần mềm. Các thành phần phần mềm có thể được tích hợp lại với nhau theo cách lặp đi lặp lại (từng phần nhỏ ghép lại với nhau, rồi ghép tiếp phần nhỏ khác vào nữa, hành động này lặp lại cho đến khi phối hợp toàn thể phần mềm) hoặc toàn bộ các thành phần cùng tích hợp một lần (gọi là “big bang”). Thông thường trước đó được coi là một cách làm tốt hơn từ khi nó cho phép các vấn đề về giao diện được xác nhận địa điểm mau hơn & cố định. Integration testing làm việc để tìm thấy lỗi (defect) trong các giao diện & giao tiếp giữa các thành phần (mô-đun). Các nhóm thành phần phần mềm đã được kiểm thử lớn dần từng bước tương ứng với các yếu tố của kiến trúc thiết kế đã được tích hợp & kiểm thử cho đến khi phần mềm hoạt động như một hệ thống.

2.1.3. Kiểm thử hệ thống

System testing kiểm thử một hệ thống đã được tích hợp hoàn chỉnh để kiểm tra rằng nó giải quyết được yêu cầu.
Kiểm thử tích hợp hệ thống chứng nhận rằng hệ thống đã được tích phù hợp với các hệ thống bên ngoài hoặc hệ thống thứ ba đã được xác nhận trong các yêu cầu hệ thống.

2.2. Mục đích của kiểm thử

Kiểm thử được tiến hành trong hoàn cảnh mục tiêu rõ ràng, trong đó được ghi nhận nhiều hơn hoặc thấp hơn một cách rõ ràng và cụ thể & có độ chuẩn xác khác nhau. Trong số đó nêu rõ mục đích của kiểm thử một cách chuẩn xác, suport về mặt định lượng đo đạc & kiểm tra trong tiến trình kiểm thử.
Kiểm thử có thể được dùng để kiểm tra các thuộc tính khác nhau. Trường hợp kiểm thử có thể được kiến trúc để kiểm soát các thông số kỹ thuật kỹ thuật tính năng được thực hiện một cách chuẩn xác, năng suất, độ tin cậy, khả dụng…

Xem Thêm  Border layout java swing - borderlayout trong java

2.2.1. Nghiệm thu/Năng lực kiểm thử

Nghiệm thu/Năng lực kiểm thử xác nhận một hệ thống thỏa mãn tiêu chí nghiệm thu của nó, thường là bằng cách kiểm soát các hành vi hệ thống mong chờ so với các yêu cầu của người tiêu dùng.

2.2.2. Kiểm thử thiết lập

Thông thường, sau thời điểm giải quyết hệ thống & chấp thuận kiểm thử, các phần mềm được kiểm tra sau thời điểm thiết lập trong môi trường mục tiêu. Seting kiểm thử có thể được coi là hệ thống thử nghiệm được tiến hành trong môi trường hoạt động cùa cấu hình phần cứng & hoạt động giới hạn khác.

2.2.3. Kiểm thử Alpha & Beta

Alpha testing là việc kiểm thử hoạt động tính năng thực tiễn hoặc giả lập do người dùng/KH tiềm năng hoặc một nhóm check độc lập thực giờ đây nơi sản xuất phần mềm. Alpha testing thường dùng cho phần mềm đóng gói sẵn để bán (chẳng hạn như MS office, window, chương trình diệt virus) là một cách thức kiểm thử chấp thuận nội bộ, trước khi phần mềm được tiến hành kiểm thử beta.

Beta testing được thực hiện sau alpha testing. Các phiên bản của phần mềm – được biết như là các phiên bản beta – chúng được cho ra đời tới một số lượng hạn chế khán giả bên ngoài nhóm sản xuất phần mềm. Sản phẩm được cho ra đời đến một số nhóm người để check nhiều hơn nữa có thể chắc nịch rằng sản phẩm có một số bug. Đôi lúc, các phiên bản beta được cho ra đời rộng rãi để tăng phạm vi bình luận từ một lượng người tiêu dùng tương lai lớn nhất.

2.2.4. Độ tin cậy & nhận xét

Kiểm thử cải tổ độ tin cậy bằng cách xác nhận & fix lỗi. không dừng lại ở đó, các bí quyết thống kế về độ tin cậy có thể được bắt nguồn bằng cách tạo thành một cách bỗng nhiên trường hợp kiểm soát theo hoạt động của phần mềm.

2.2.5. Kiểm thử hồi quy

Chăm chú vào việc tìm kiếm lỗi sau thời điểm xảy ra việc biến đổi code. Đặc biệt, nó tìm kiếm theo cách hồi qui (đệ qui) hoặc kiểm soát các bug cũ có bị lại hay không. Hồi qui như thế xảy bất kì lúc nào mà tính năng phần mềm trước đó làm việc đúng đã ngưng làm việc theo đợi mong. Điển hình, hồi qui xảy ra như là một kết quả không mong chờ của việc biến đổi chương trình, khi phần code của phần mềm mới được lớn mạnh xung độ với code cũ đang có. Mẹo thông thường của kiểm soát hồi quy là kể cả việc chạy lại các kiểm thử trước đó & kiểm soát xem có lỗi đã được fixed trước đó bị lỗi lại (bị lại các lỗi cũ đã fixed rồi). Độ sâu của việc kiểm thử lệ thuộc vào các công đoạn trong tiến trình cho ra đời & nguy cơ của các chức năng được thêm vào. Chúng có thể được giải quyết – vì việc biến đổi đã thêm vào sau bản cho ra đời hoặc coi nó là mạo hiểm, rất hời hợt, bao gồm các kiểm thử trường hợp đúng (positive) trên từng tính năng – nếu các biến đổi được thêm vào trước khi cho ra đời hoặc coi nó ít nguy cơ.

2.2.6. Kiểm thử hiệu năng

Kiểm thử hiệu năng được thực hiện để xác nhận hệ thống hoặc hệ thống con thực hiện một khối lượng công việc rõ ràng nhanh thế nào. Nó cũng có thể dùng để xác định & kiểm tra những tính chất chất lượng khác của hệ thống như là khả năng mở rộng, độ tin cậy & sử dụng tài nguyên. Load testing là định nghĩa chủ chốt của việc kiểm thử mà có thể tiếp tục hoạt động ở một mức tải rõ ràng, cho dù này là một lượng lớn dữ liệu hoặc lượng lớn người tiêu dùng. Cái này gọi chung là khả năng mở rộng của phần mềm. Hoạt động load testing liên quan khi thực hiện hoạt động phi tính năng thường được gọi là kiểm thử sức chịu đựng (độ bền).

2.2.7. Kiểm thử bảo mật

Kiểm thử bảo mật chăm chú vào việc kiểm tra rằng phần mềm được bảo vệ khỏi các cuộc tấn công từ bên ngoài. Đặc biệt, kiểm thử bảo mật kiểm tra tính bảo mật, tính chu toàn & tính sẵn sàng của hệ thống & dữ liệu của nó.

2.2.8. Kiểm thử Căng thẳng

Căng thẳng testing là một cách thức kiểm thử được sử dụng để xác nhận tính ổn định của một hệ thống hoặc một thực thể được đề ra. Nó liên quan đến những kiểm thử vượt quá khả năng bình bình của hệ thống, thường để xác nhận điểm phá vỡ, để xem xét các kết quả. Căng thẳng testing có thể có nghĩa rõ ràng hơn trong một số nghề công nghiệp khẳng định, như là kiểm thử tính mỏi của Nguyên vật liệu.

2.2.9. Kiểm thử Back-to-Back (so sánh)

Khi triển khai nhiều phiên bản phần mềm từ cùng một đặc tả. Kiểm thử hộp đen cho các sản phẩm này được thực hiện với cùng ca kiểm thử & cùng các dữ liệu vào. So sánh các kết quả nhận được, nếu có độc đáo nghĩa là có sai trong một sản phẩm nào đó.

2.2.10. Kiểm thử hồi phục

Kiểm thử hồi phục có mục đích kiểm soát khả năng khởi động lại của phần mềm sau thời điểm hệ thống bị treo hoặc crash.

2.2.11. Kiểm thử giao diện

Các điểm yếu giao diện rất thông dụng trong các hệ thống cầu kỳ. Kiểm thử giao diện nhằm kiểm tra các thành phần giao diện chuẩn xác để phân phối những thỏa thuận chuẩn xác của dữ liệu & kiểm tra thông tin. Thông thường các trường hợp thử nghiệm được tạo thành từ các đặc tả giao diện. Mục tiêu rõ ràng của thử nghiệm giao diện là để mô phỏng việc sử dụng các API của các vận dụng của người dùng cuối. Điều này liên quan tới việc tạo thành các thông số kỹ thuật của các cuộc gọi API, cài đặt các điều kiện môi trường bên ngoài, & khái niệm của dữ liệu nội bộ có tác động đến các API.

2.2.12. Kiểm thử cấu hình

Trong trường hợp phần mềm được xây dựng để phục vụ người dùng khác nhau, kiểm thử cấu hình dùng để kiểm chứng các phần mềm theo quy định cấu hình khác nhau.

2.2.13. Kiểm thử tính khả dụng & tương tác người – máy

Bổ phận chính của phần đó là nhận xét như vậy nào là đơn giản cho người dùng cuối để khám phá & sử dụng phần mềm. Nói chung, nó có thể liên quan tới việc thử nghiệm các tính năng phần mềm suport việc sử dụng, ebook chỉ dẫn nhằm suport người tiêu dùng, & khả năng của hệ thống để hồi phục từ lỗi người tiêu dùng

3. Kỹ thuật kiểm thử

Một trong những trung tâm của việc kiểm thử này là phát hiện nhiều lỗi nhất có thể. Nhiều kỹ thuật đã được lớn mạnh để làm việc này. Những kỹ thuật này để thử phá một chương trình trình một cách hệ thống bằng việc nêu ra đầu & mà sẽ tạo thành các tình trạng của chương trình. Chẳng hạn, suy xét các lớn con của miền đầu vào, các cốt truyện, tình trạng & luồng dữ liệu.

Việc phân loại các kỹ thuật kiểm thử được trình bày bước này là dựa vào cách kiểm thử được thực hiện: từ trực giác & kinh nghiệm của kỹ sư phần mềm, các cụ thể kỹ thuật, kết cấu mã nguồn, lỗi thực hoặc lỗi tưởng tượng được tìm thấy, việc sự dụng được phán đoán trước, mô hình hoặc bản chất của vận dụng. Một loại tiến hành với 2 hoặc nhiều kỹ thuật phối hợp lại.

Một vài kỹ thuật này được xếp loại như white-box hoặc glass-box nếu kiểm thử dựa vào thông tin về cách phần mềm được kiến trúc hoặc viết mã nguồn. Hoặc được coi là black-box nếu nó chỉ dựa vào tình trạng đầu vào đầu ra của phần mềm. Dưới đây bao gồm vài kỹ thuật phổ biến, nhưng một vài người kiểm thử lệ thuộc vào một số kỹ thuật hơn các kỹ thuật khác

3.1. Dựa theo trực giác & kinh nghiệm của kỹ sư phần mềm

3.1.1. Tùy biến

Có vẻ kỹ thuật được thực hiện nhiều đặc biệt là kiểm thử tùy biến: các kiểm thử có được dựa vào tuyệt kỹ, trực quan & kinh nghiệm của kỹ sư phần mềm với cá chương trình thân thuộc. Kiểm thử tùy biến có thể hữu hiệu cho việc định danh các trường hợp kiểm thử mà không dễ thực hiện bằng các kỹ thuật bình bình.

3.1.2. Kiểm thử tìm tòi

Kiểm thử theo kiểu tìm tòi được khái niệm là tiến hành song song việc học hành, kiến trúc & thực hiện kiểm thử, nó không được thực hiện theo kế sách kiểm thử đã được lên trước & linh hoạt về việc kiến trúc, thực hiện & sửa đổi. Hiệu quả của kiểm thử tìm tòi lệ thuộc & kinh nghiệm của kỹ sư phần mềm, điều này có được từ nhiều nguồn như quan sán hành vi của máy trong tiến trình kiểm thử, sự thân thuộc với các vận dụng, môi trường, tiến trình lỗi, các dạng lôi có thể có, rủi ro khi tích phù hợp với các sản phẩm biệt lập….

3.2. Kỹ thuật dựa vào miền đầu vào

3.2.1. Phân vùng tương tự

Phân vùng tương tự liên quan tới việc phân tách miền đầu vào thành các vùng dựa vào tiêu chí hoặc quan hệ. Tiêu chí hoặc quan hệ này có thể là những kết quả tính toán khác nhau, quan hệ dựa vào luồng điều khiển hoặc luồng dữ liệu, hoặc một sự phân biệt được tạo thành giữa các đầu vào hợp được chấp thuận & đầu vào không hợp lệ sẽ bị chối từ & đề ra lỗi.

3.2.2. Kiểm thử theo cặp

Các trường hợp kiểm thử có được bằng việc phối hợp các giá trị tiêu biểu cho mỗi cặp của một tập hợp biến đầu vào thay vì xét đến toàn thể các phối hợp có thế có. Kiểm thử theo cặp thuộc về kiểm thử tổ hợp, nhìn chung bao gồm mức tổ hợp cao hơn đối với cặp: những kỹ thuật này được coi như t-wise, cái mà toàn thể tổ hợp đầu vào t được suy xét.

3.2.3. Nghiên cứu giá trị biên

Các trường hợp kiểm thử được chọn ra sẽ nằm trên hoặc gần với điên của miền đầu vào, nơi tỉ lệ lỗi thường tập chung cao nhất. Trường hợp ngoại lệ của kỹ thuật đó là kiểm thử sự vững bền, nơi mà trường hợp kiểm thử được chọn bên ngoài miền biến đầu vào để kiểm thử sự vững bền của sản phầm trong việc giải quyết đầu vào lỗi.

3.2.4. Kiểm thử bỗng nhiên

Các kiểm thử được thực hiện đơn thuẩn một cách bỗng nhiên. Dạng kiểm thử này đặt dưới đầu của miền đầu vào bởi vì miền đầu vào phải được biến để để có thể lấy ra được những điểm bỗng nhiên. Kiểm thử bỗng nhiên phân phối một tiếp cận dễ dàng để kiểm thử auto, gần đây các dạng chuyên sâu của kiểm thử bỗng nhiên được đề ra, mẫu đầu vào bỗng nhiên được hướng bởi tiêu chí lựa chọn đầu vào khác. Kiểm thửu Fuzz hay Fuzzing là dạng đặc biệt của kiểm thử bỗng nhiên,tập chung vào việc phá vỡ phần mềm, nó chủ chốt được dùng để kiểm thử an ninh của phần mềm.

3.3. Kỹ thuật dựa vào mã nguồɳ

3.3.1. Tiêu chí dựa vào luồng điều khiển

Tiêu chí phủ dựa vào luồng điều khiển được tập chung vào việc phủ toàn thể các câu lệnh, khối lệnh hoặc phối hợp đặc biệt của các câu lệnh trong chương trình. Thế mạnh nhất của tiêu chí đó là kiểm thử đường đi, cái mà tập chung vào để thực thi toàn thể đường đi lường điều khiển từ khi vào đến khi chấm dứt trong biểu đồ luồng điều khiển của chương trình. Vì kiểm thử vét kiệt đường đi là không khả thi do vòng lặp, tiêu chí ít chuẩn xác tập chung vào đọ phủ của đường đi các mà hạn chế các bước lặp như phủ câu lệnh, phủ nhánh & kiểm thử quyết định. Sự đầy đủ của các kiểm thử như vậy được tổng hợp theo phần trăm, chẳng hạn, khi toàn bộ các nhánh được thự thi tối thiểu một lần khi kiểm thử thì độ phủ nhánh là 100%.

3.3.2. Tiêu chí dựa vào luồng dữ liệu

Trong kiểm thử dựa vào luồng dữ liệu, biểu đồ luồng điều khiển được diễn đạt với thông tin về việc bằng cách nào các biến chương trình được khái niệm, dử dụng & chấm dứt. Tiêu chí mạnh nhất yêu cầu từ khái niệm của biến tới việc sử dụng khái niệm đó được thực thi. Để giảm số đường đi yêu cầu, những kế hoạch yếu hơn hẳn như khái niệm toàn bộ & sử dụng toàn bộ được dùng.

3.3.3. Các mô hình xem qua cỏ kiểm thử dựa vào mã nguồn

Dù rằng bản thân không phải là một kỹ thuật, kết cấu điều khiển của một chương trình có thể được hình ảnh hoá để trình diễn việc sử dụng một biểu đồ như kỹ thuật dựa vào mã nguồn. Một biểu đồ là đồ thị có hướng, các nút & cung trình diễn cho các yếu tố của chương trình. Chẳng hạn, các nút có thể trình diễn các lệnh hoặc tần xuất không bị can thiệp của lệnh & cung có thể trình diễn sử thỏa thuận giữa các nút.

3.4. Kỹ thuật dựa vào lỗi

Xem Thêm  Làm thế nào để sử dụng khác biệt trong SQL? - cách sử dụng khác biệt trong máy chủ sql

3.4.1. Phán đoán lỗi

Trong việc phán đoán lỗi, các trường hợp kiểm thử được kiến trúc đặc biệt bởi kỹ sư phần mềm người mà phấn đấu phán đoán trước các lỗi có thể xảy ra trong chương trình cho trước. Một nguồn thông tin tốt là lịch sử lỗi được tìm thấy trong những dự án có trước cũng như tuyệt kỹ của kỹ sư phần mềm.

3.4.2. Kiểm thử đột biến

Một đột biến là một phiên bản cân chỉnh nhẹ của chương trình đang kiểm thử, với một sử biến đổi nhẹ để độc đáo với chương trình cũ. Mỗi lần kiểm thử là kiểm thử phiên bản gốc & toàn thể các đột biến: nếu trường hợp kiểm thử thành công trong việc định danh sự độc đáo giữa chương trình & đột biến thì đột biến sẽ bị hủy diệt. Nói cách khác, khi một đột biến được kiểm thử mà trả kết quả khác đối với bản gốc thì đột biến bị hủy diệt & xem như bản gốc đạt đúng chuẩn. Khi bản đột biến mà cho kết quả giống bản gốc thì xem như kiểm thửu thất bại. Hiệu của của kỹ thuật này được nhìn nhận bằng sll của các đột biến bị hủy diệt. Các đột biến thường được tạo thành một cách auto & kiểm thử thực hiện theo một cách có hệ thống.

3.5. Kỹ thuật dựa vào việc sử dụng

3.5.1. Hồ sơ vận hành

Trong việc kiểm thử sự nhận xét độ tin cậy, mội trường kiểm thử được tạo thành gần với môi trường vận hành của phần mềm hoặc gọi là hồ sơ vận hành. Mục tiêu là để suy ra từ các kết quả đã được theo dõi độ tin cậy tương lai của phần mềm khi được sử dụng thật. để làm điều này, đầu vào được gán các xác suất hoặc hồ sơ theo tần suất xảy ra trong thực tiễn. Hồ sơ vận hành so thể được dùng trong kiểm thử hệ thống để chỉ dẫn bắt nguồn của các trường hợp kiểm thử sẽ nhận xét sự tin cậy & thử nghiệm liên quan tới việc sử dụng & các tính năng khác nhau giống với những gì xảy ra trong môi trường kiểm thử vận hành.

3.5.2. Xem xét người dùng

Các phép tắc sử dụng có thể phân phối chỉ dẫn cho việc tìm thấy vấn đề trong kiến trúc giao diện. Nguồn thông tin cho vấn đề này có thể được lấy qua các nguồn như phỏng vấn & làm thăm dò người dùng.

3.6. Kỹ thuật dựa vào mô hình

3.6.1. Bảng quyết đinh

Những bảng quyết định trình diễn các mối quan hệ logic giữa các điều kiện & hành động. Các trường hợp kiểm thử có được một cách hệ thống bằng việc suy xét mọi tổ hợp của điều kiện & các hành động phản ứng. Một kỹ thuật liên quan là đồ thị lý do – tác động.

3.6.2. Máy tình trạng hữu hạn

Bằng việc mô hình hóa một chương trình như một máy tình trạng hữu hạn, việc kiểm thử được lựa chọn để bao phủ các tình trạng & sự chuyển tiếp.

3.6.3. Cụ thể kỹ thuật thông thường

Tình trạng hóa cả cụ thể kỹ thuật trong ngôn từ cách thức cho phép sự dẫn xuất auto các trường hợp kiểm thử tính năng & song song phân phối một phán đoán cho việc kiểm soát kết quả kiểm thử. TTCN3 là một ngôn từ được lớn mạnh để viết ra các trường hợp kiểm thử. Khái niệm được hiểu với những yêu cầu biệt lập của kiểm thử các hệ thống truyền thông, vì vậy nó đặc biệt phù hợp cho kiểm thử các giao thức truyền thông cầu kỳ.

3.6.4. Mô hình luồng công việc

Mô hình luồng công việc nêu ra tần xuất của các hoạt động được thực hiện bởi nhân loại hay vận dụng phần mềm, thường được trình diễn thông qua các định nghiwax hình ảnh. Mỗi tần suất của hành động cấu thành một luồng công việc.

3.7. Kỹ thuật dựa vào thuộc tính của phần mềm

Các kỹ thuật bên trên ứng dụng cho toàn thể các loại phần mềm. các kỹ thuật phụ cho kiểm thử dựa vào tính chấn của phần mềm như:

  • Phần mềm hướng đối tượng
  • Phần mềm dựa vào phòng ban
  • Phần mềm nền website
  • Các chương trình tương tranh
  • Phần mềm dựa vào giao thức
  • Hệ thống thời gian thực
  • Hệ thống an toàn khẩn cấp
  • Phần mềm hướng dịch vụ
  • Phần mềm mã nguồn mở
  • Phần mềm nhúng

3.8. Chọn & phối hợp các kỹ thuật

3.8.1. Phối hợp tính năng & kết cấu

Các kỹ thuật kiểm thử dựa vào mô hình & mã nguồn thường tương phản như kiểm thử tính năng & kết cấu. Hai cách tiếp cận lựa chọn kiểm thử này không được coi như thay thế cho nhau mà được coi là bổ sung cho nhau; trong thực tiễn, chúng sử dụng các nguồn thông tin khác nhau & đã nêu ra các loại vấn đề tiêu biểu khác nhau. Chúng có thể được dùng phối hợp & lệ thuộc vào suy xét đầu tư.

3.8.2. Tất định & bỗng nhiên

Các trường hợp kiểm thử được chọn theo cách tất định, theo một trong số các kỹ thuật hoặc thực hiện bỗng nhiên từ sự cung cấp đầu vào như trong kiểm thử độ tin cậy. Một vài so sánh theo kiểu nghiên cứu & kinh nghiệm được chọn để nghiên cứu các điều kiện mà tạo cách tiếp cận có hiệu quả hơn.

4. Các phép đo liên quan tới việc kiểm thử

4.1. Nhận xét chương trình đang kiểm thử

4.1.1. Các phép đo chương trình suport lên kế hoạc & kiến trúc kiểm thử

Các phép đó dựa vào kích thước của phần mềm (chẳng hạn: các dòng mã nguồn hoặc kích cỡ tính năng) hoặc kết cấu phần mềm có thể được dùng để chỉ dẫn kiểm thử. Các phép đo kết cấu bao gồm các phép đo mà quyết định tần suất của mô đun này gọi thực hiện mô đun khác.

4.1.2. Các loại lỗi, phân loại & đo đạc

Văn học kiểm thử phong phú trong phân loại & phép tắc phân loại lỗi. Để tạo thành kiêm thử hiệu quả hơn thì trọng yếu là biết loại lỗi nào có thể được phát hiện trong phần mềm đang kiểm thử & tần xuất tương đối những lỗi đó tồn tại trong dĩ vãng. Thông tin này có thể hữu hiệu trong việc phán đoán chất lượng cũng như trong việc cải tạo tiến trình.

4.1.3. Mật độ lỗi

Một chương trình đang kiểm thử có thể được nhìn nhận bằng việc tính toán các lỗi đã được tìm thấy như tỉ lệ giữa số lỗi được tìm ra & độ lớn cửa chương trình.

4.1.4. Nhận xét độ tin cậy

Một ước lượng đo đạc của độ tin cậy phần mềm có thể được dùng để nhận xét một sản phẩm phần mềm & quết định kiểm thử có thể dừng lại hay không bằng việc xem xét độ tin cậy được tạo thành.

4.1.5. Những mô hình lớn mạnh độ tin cậy

Những mô hình lớn mạnh độ tin cậy phân phối phán đoán dộ tin cậy dựa vào lỗi. Chúng giả thiết rằng các lỗi gây ra các thất bại được xem xét đều được sửa, độ tin cậy của sản phầm đữa ra một xu hướng tăng dần. Rất là nhiều mô hình kiểu này được đề ra. Đáng lưu ý, những mô hình này được chi ra là 2 loại là mô hình đếm lỗi & mô hình thời gian giữa các lỗi.

4.2. Nhận xét các kiểm thử được thực hiện

4.2.1. Các phép đo phủ

Một vài tiêu chí kiểm thử yêu cầu rằng các trường hợp kiểm thử thực hiện một tập yếu tố được định danh trong chương trình hoặc trong cụ thể kỹ thuật một các hệ thống. Để nhận xét độ cụ thể của các kiểm thử được thực hiện, các kỹ sư phần mềm cso thể theo dõi các yếu tố được bao bọc để họ có thể tổng hợp tỉ lệ giữa yếu tố được phủ & tổng số một các linh hoạt. Chẳng hạn, có thể đo tỉ lệ phần trăm của các nhánh được phủ trong biểu đồ dòng chảy chương trình hoặc phần trăm yêu cầu tính năng được thực hiện & danh mục tính năng trong ebook cụ thể kỹ thuật. Các tiêu chuẩn thích hợp dứa trên mã nguồn yêu cầu sự tổng hợp phù hợp của chương trình đang kiểm thử.

4.2.2. Gieo lỗi

Trong việc gieo lỗi, vài lỗi được mang nhân tạo vào chương trình trước khi kiểm thử. Khi kiểm thử được tiến hành, & trong số này sẽ được bộc lộ cũng như & lỗi có sẵn. Theo lý thuyết, lệ thuộc vào việc cái nào & bao nhiêu lỗi nhân tạo được tìm thấy, hiệu quả kiểm thử & số lỗi thực có thể được nhìn nhận. Trong thực tiễn, các nhà đo đạc đưa ra thắc mắc thử cung cấp & trình diễn của các lỗi được gieo trước đây quan hệ vơi lỗi thật & một cỡ bé mẫu thử lên bất kỳ phéo ngoại suy nào được dựa vào. Một số khác tranh biện rằng kỹ thuật này nên dùng cẩn trọng vì việc chèn lỗi vào phần mềm liên quan đến mạo hiểm rõ rằng rằng có thể quên các lỗi đó trong chương trình.

4.2.3. Điểm đột biến

Trong kiểm thử đột biến, tỉ lệ các đột biến bị hủy diệt với tổng số đột biến có thể là phép đo cho sự hiệu của của tập kiểm thử được thực hiện.

4.2.4. Sự so sánh & hiệu quả tương đối của các kỹ thuật khác nhau

& tìm hiểu được tiến hành đê so sánh hiệu quả tương đối của việc sử dụng các kỹ thuật khác nhau. Trọng yếu là để được chuẩn xác như so với tính chất dựa theo đó các kỹ thuật đang được nhìn nhận. Cách diễn dải có thể bao gồm số các kiểm thử cần để tìm thấy lỗi trước tiên, tỉ lệ của số lỗi được tìm thấy thông qua kiểm thử & toàn thể số lỗi được tìm thấy trong & sau thời điểm kiểm thử, & cải tổ độ tin cậy được bao nhiêu. Các so sánh nghiên cứu & thử nghiệm giữa các kỹ thuật khác nhau được tiến hành theo từng ý niệm về hiệu quả quy định ở trên.

5.Tiến trình kiểm thử

Định nghĩa về kiểm thử, kế hoạch, kỹ thuật & đo đạc cần phải được tích hợp vào một tiến trình xác nhận & kiểm tra. Tiến trình kiểm thử suport các hoạt động kiểm soát & phân phối chỉ dẫn cho các tester & đội tester, từ việc lập kế sách để nhận xét đầu ra, theo cách như thế để bảo đảm phân phối rằng các mục tiêu kiểm thử sẽ được thỏa mãn trong một ngân sách hiệu quả kịp thời.

5.1. Nhìn nhận thực tiễn

5.1.1. Thái độ / Lập trình giảm bớt “cái tôi”

Một yếu tố trọng yếu của kiểm thử thành công là một thái độ cộng tác hướng đến thử nghiệm & hoạt động bảo đảm chất lượng. Những người làm chủ có vai trò trọng yếu trong việc tác động một đảm nhiệm thuận tiện nói chung để hướng đến phát hiện lỗi & sửa chữa trong tiến trình lớn mạnh & bảo dưỡng phần mềm.

Chẳng hạn: bằng cách vượt mặt những nghĩ suy của quyền sở hữu cá nhân giữa các lập trình & bằng cách tác động một môi trường hợp tác với đội ngũ chịu bổ phận về dị thường trong các mã lập trình.

5.1.2. Chỉ dẫn kiểm thử

Các công đoạn kiểm thử có thể được chỉ dẫn bởi các mục tiêu khác nhau.

Chẳng hạn: Kiểm thử dựa vào nguy cơ sử dụng các nguy cơ sản phẩm ưu tiên & chăm chú các kế hoạch kiểm thử, & kiểm thử dựa vào cốt truyện xác nhận các trường hợp kiểm thử dựa vào cốt truyện phần mềm quy định.

5.1.3. Làm chủ tiến trình kiểm thử

Các hoạt động kiểm thử được tiến hành ở các cấp độ khác nhau (tham khảo thêm ở level 2: Check levels) phải được tổ chức lại với nhau, cùng với nhân loại, dụng cụ, cơ chế & các bí quyết thành tiến trình xác nhận, này là một phần chẳng thể thiếu của vòng đời.

5.1.4. Ebook kiểm thử & sản phẩm công việc

Ebook kiểm thử là một phần chẳng thể thiếu khi chính thức tiến trình kiểm thử. Ebook kiểm thử có thể bao gồm các kế sách kiểm soát, đặc tính kỹ thuật kiến trúc kiểm soát, đặc tính kỹ thuật quy trình kiểm soát, kiểm soát các trường hợp đặc tính kỹ thuật, kiểm soát log & giải trình sự việc kiểm soát.

Các phần mềm được kiểm thử được ghi nhận như một tác phẩm kiểm thử. Ebook kiểm thử nên được tạo thành & liên tục update tới cùng một mức độ chất lượng như các loại ebook khác trong công nghệ phần mềm. Ebook kiểm thử cũng cần chịu sự giám sát của làm chủ cấu hình phần mềm. Hơn nữa, ebook kiểm thử bao gồm các sản phẩm công việc mà có thể phân phối các ebook chỉ dẫn cho người tiêu dùng & huấn luyện.

5.1.5. Tiến triển hướng kiểm thử (TDD)

Tiến triển hướng kiểm thử (TDD) ban đầu là một trong những thực hành chủ chốt XP (extreme programming) & bao gồm các kiểm thử nhà cung cấp bằng văn bản trước khi các mã lập trình được kiểm soát (xem cách thức Agile trong mô hình công nghệ phần mềm & cách thức KA).

Bằng phương pháp này, TDD lớn mạnh các trường hợp kiểm thử như là một thay thế cho ebook đặc tả yêu cầu phần mềm hơn là một kiểm soát độc lập mà phần mềm đã thực hiện đúng các yêu cầu. Thay vì một kế hoạch kiểm thử, TDD là một thực tiễn đòi hỏi các nhà lớn mạnh phần mềm để xác nhận & duy trì kiểm soát nhà cung cấp (unit tests). Điều này có thể có một động tĩnh tích cực vào việc xây dựng nhu cầu người dùng & các đặc tả yêu cầu phần mềm.

Chẳng hạn: một mô hình khi ứng dụng TDD

Xem Thêm  Toán tử Lớn hơn hoặc Bằng (> =) trong JavaScript - lớn hơn bằng ký hiệu javascript

Tiến triển hướng kiểm thử TDD (Check-Driven Development) là một cách thức tiếp cận cải tạo để lớn mạnh phần mềm trong đó phối hợp cách thức Tiến triển kiểm thử trước (Check First Development) & cách thức Bố trí lại mã nguồn (Refactoring).

5.1.6. Đội kiểm thử nội bộ & độc lập

Tiến trình kiểm thử cũng có thể liên quan tới việc tổ chức các nhóm kiểm thử. Các nhóm kiểm thử có thể bao gồm các member nội bộ (có nghĩa là, trong nhóm dự án, gia nhập hay không trong xây dựng phần mềm), các member bên ngoài (với mơ ước đem lại một quan niệm độc lập, không thiên vị) , hoặc của cả hai member nội bộ hay bên ngoài. Xem xét về ngân sách, thời gian, mức độ trưởng thành của tổ chức có liên quan & trọng yếu của các vận dụng có thể chỉ dẫn các quyết định.

5.1.7. Ngân sách / dự toán & đo đạc tiến trình kiểm th

Một số các bí quyết liên quan đến các nguồn tài nguyên giành cho việc kiểm soát, cũng như hiệu quả tìm kiếm lỗi tương ứng của các công đoạn kiểm thử khác nhau, được sử dụng bởi các nhà làm chủ để kiểm tra & cải tổ tiến trình kiểm thử. Những bí quyết kiểm soát có thể bao gồm các góc cạnh như số trường hợp kiểm thử được chỉ định, số trường hợp kiểm soát được thực hiện, số lượng trường hợp kiểm thử đạt yêu cầu, số lượng trường hợp kiểm thử không đạt yêu cầu trong số những cái khác.

Giám định giải trình công đoạn kiểm thử có thể được kết phù hợp với nghiên cứu lý do gốc để nhận xét hiệu quả tiến trình kiểm thử trong việc tìm lỗi càng sớm càng tốt. Việc nhận xét đó có thể kết phù hợp với việc nghiên cứu nguy cơ. Hơn nữa, các tài nguyên giành cho việc kiểm thử phải phù phù hợp với việc sử dụng/trọng yếu của các vận dụng: các kỹ thuật khác nhau có các ngân sách khác nhau & đem lại mức độ khác nhau của độ tín nhiệm trong mức độ tin cậy của máy.

5.1.8. Chấm dứt kiểm thử

Một quyết định cần phải đề ra là việc kiểm thử như vậy nào là đủ & lúc nào công đoạn kiểm thử được chấm hết. Thông qua tổng hợp, xác nhận các tính năng bảo đảm, cũng như ước tính mật độ lỗi hoặc độ tin cậy của hoạt động.

Các quyết định cũng kể cả việc suy xét về ngân sách & nguy cơ phát sinh bởi sự thất bại còn tồn tại thể xảy ra, như trái ngược với ngân sách phát sinh bằng cách tiếp tục kiểm thử (xem tiêu chí lựa chọn kiểm thử / tiêu chí thử nghiệm Adequacy ở mục 1.2)

5.1.9. Tái sử dụng kiểm thử & Mẫu kiểm thử

Để thực hiện kiểm thử, bảo dưỡng một cách có tổ chức & hiệu quả ngân sách, các kiểm thử từng phần của phần mềm nên được tái sử dụng một cách hệ thống. Một kho lưu trữ kiểm thử nên chịu sự kiểm tra của làm chủ cấu hình phần mềm để mà biến đổi yêu cầu phần mềm hoặc kiến trúc có thể được phản ảnh trong biến đổi cho làm chủ các kiểm thử.

Các bí quyết kiểm thử được ứng dụng để kiểm thử một số loại vận dụng trong những cục diện khẳng định, với những động cơ đằng sau các quyết định đề ra, tạo ra một mô hình kiểm thử mà chính nó có thể được ghi lại để tái sử dụng sau này trong các dự án tương đương.

5.2. Hoạt động kiểm thử

Như trổ tài trong các miêu tả dưới đây, làm chủ thành công của các hoạt động kiểm thử lệ thuộc mạnh khỏe vào tiến trình làm chủ cấu hình phần mềm (xem làm chủ cấu hình phần mềm KA)

5.2.1. Lập kế sách

Giống như toàn bộ các góc cạnh khác nhau của làm chủ dự án, các hoạt động kiểm thử phải được quy hoạch. Góc cạnh trọng yếu của việc lập kế sách kiểm thử bao gồm sự kết hợp của các nhân sự, tính sẵn có của các nền tảng & trang thiết bị kiểm thử, tạo thành & bảo dưỡng toàn bộ các ebook liên quan đến kiểm thử, & lên kế sách cho những kết quả không mong chờ có thể. Nếu có nhiều hơn nền tảng của các phần mềm đang duy trì, sau đó suy xét một kế sách chính là thời gian & cố gắng thiết yếu để bảo đảm rằng các môi trường kiểm thử được cài đặt để cấu hình đúng.

5.2.2. Tạo thành các trường hợp kiểm thử

Việc tạo thành các trường hợp kiểm thử dựa vào mức độ kiểm thử được thực hiện & kỹ thuật kiểm thử rõ ràng. Các trường hợp kiểm thử nên được dưới sự kiểm tra của làm chủ cấu hình phần mềm & bao gồm các kết quả dự tính cho mỗi kiểm thử.

5.2.3. Tiến triển môi trường kiểm thử

Môi trường được sử dụng để kiểm thử phải có sự tương thích với các dụng cụ phần mềm được đề xuất. Nó tạo cơ hội lớn mạnh & kiểm tra các trường hợp kiểm thử, không khác gì như ghi lại & hồi phục các kết quả đợi mong, cốt truyện & các ebook kiểm thử khác.

5.2.4. Thực hiện kiểm thử

Thực hiện các kiểm thử nên trổ tài một phép tắc căn bản của thực nghiệm khoa học: toàn bộ mọi thứ được thực hiện trong tiến trình kiểm thử nên được thực hiện & ghi chép rõ ràng và cụ thể đủ để người khác có thể nhân rộng kết quả. Vì vậy, việc kiểm thử nên được thực hiện theo thủ tục bằng cách dùng một phiên bản xác nhận rõ ràng và cụ thể của phần mềm bên dưới các kiểm thử.

5.2.5. Nhận xét kết quả kiểm thử

Các kết quả của kiểm thử cần được nhìn nhận để xác nhận việc kiểm thử có thành công hay không. Trong đa số các trường hợp, thành công nghĩa là phần mềm thực hiện như đợi mong & không có các kết quả ngạc nhiên nào. Không phải toàn bộ các kết quả ngạc nhiên là nhất thiết phải lỗi.

Trước khi một lỗi có thể được xóa đi, một nghiên cứu & cố gắng gỡ lỗi là thiết yếu để cô lập, xác nhận & miêu tả nó. Khi kết quả kiểm thử là vô cùng quan trọng, một hội đồng xét duyệt chính thức có thể được triệu tập để nhận xét chúng.

5.2.6. Giải trình / nhật ký kiểm thử

Hoạt động kiểm thử có thể sử dụng các nhật ký kiểm thử để xác nhận một kiểm thử đã được tiến hành, ai là người thực hiện các kiểm soát, những cấu hình phần mềm nào được sử dụng & các thông tin nhận dạng khác có liên quan. Kết quả kiểm thử đột xuất hoặc không chuẩn xác có thể được ghi lại trong một hệ thống giải trình sự cố, các dữ liệu mà tạo nền tảng cho việc gỡ lỗi sau đó & sửa chữa các vấn đề đã được xem xét như những thất bại trong tiến trình kiểm thử. không dừng lại ở đó, dị thường không được phân loại là lỗi có thể được ghi lại trong trường hợp chúng lần lượt hiện ra là cực kỳ nghiêm trọng hơn nhiều đối với nghĩ suy trước tiên. Giải trình kiểm thử cũng là đầu vào để biến đổi quy trình làm chủ theo yêu cầu (xem điều khiển cấu hình phần mềm trong làm chủ cấu hình phần mềm KA)

5.2.7. Theo dõi khiếm khuyết

Các khiếm khuyết có thể được theo dõi & nghiên cứu để xác nhận khi chúng được mang vào phần mềm, vì sao chúng được tạo thành, (chẳng hạn, yêu cầu kém được xác nhận, khai báo biến không đúng, rò rỉ bộ nhớ lưu trữ, lập trình lỗi cú pháp), & khi họ có thể xem xét thấy lần trước tiên trong phần mềm. Khiếm khuyết về thông tin được sử dụng để xác nhận những góc cạnh của kiểm thử phần mềm & các tiến trình khác cần cải tổ & hiệu quả của cách thức tiếp cận trước đó diễn ra như vậy nào.

6.Dụng cụ kiểm thử phần mềm

6.1.Dụng cụ kiểm thử suport

Kiểm thử đòi hỏi nhiều công việc cần thực hiện, chạy nhiều chương trình & giải quyết một lượng lớn thông tin. Các dụng cụ phù hợp có thể làm giảm thiểu gánh nặng của việc lặp lại, hoạt động tẻ nhạt & khiến cho việc kiểm thử ít dễ bị lỗi. Dụng cụ tinh xảo có thể suport kiến trúc kiểm thử & tạo thành các trường hợp kiểm thử, khiến cho nó hiệu quả hơn.

6.1.1. Lựa chọn dụng cụ

Chỉ dẫn cho các nhà làm chủ & các người kiểm thử về cách chọn dụng cụ kiểm soát rằng sẽ hữu hiệu nhất để tổ chức & các quy trình là một đề tài rất trọng yếu, như là một dụng cụ tạo tác động lớn để hiệu quả kiểm thử & thật sự hiệu quả. Việc lựa chọn dụng cụ lệ thuộc vào các biểu hiện khác nhau, ví dụ như lựa chọn lớn mạnh, mục tiêu nhận xét, các nền tảng thực hiện,…Nói chung, có thể không có một dụng cụ duy nhất để thỏa mãn các nhu cầu rõ ràng, thành ra một bộ dụng cụ có thể là một lựa chọn phù hợp.

6.2. Mục lục các dụng cụ kiểm thử.

Tất cả chúng ta phân loại các dụng cụ có sẵn theo tính năng của chúng:

Check harnesses (drivers, stubs):

  • Trong kiểm thử phần mềm, check harness (khai thác kiểm thử) đề cập đến một bộ sưu tập các phần mềm & bộ dữ liệu kiểm thử được cấu hình sẵn để kiểm thử một nhà cung cấp chương trình bằng cách chạy nó trong nhiều điều kiện khác nhau & tất cả chúng ta sẽ theo dõi hành vi & kết quả đầu ra của nó.
  • Phân phối một môi trường điều khiển, trong đó việc kiểm thử có thể được thực hiện & kết quả đầu ra có thể được ghi lại. Để thực hiện kiểm thử các phần của một chương trình, các drivers & stubs được phân phối để mô phỏng một cách tương ứng.
  • Sự khác nhau giữa Drivers & Stubs:

Drivers: là loại giả mô-đun, cái được gọi là “các chương trình gọi”, được sử dụng trong kiểm thử tích hợp từ dưới lên, được sử dụng khi chương trình chính đang được xây dựng.

Stub: có nghĩa là một mô hình giả của một module rõ ràng.

  • Chẳng hạn:

Giả sử tất cả chúng ta cần kiểm thử sự tích hợp giữa mô đun ? & Ɓ & tất cả chúng ta đã xây dựng được mô đun ? trong lúc mô đun Ɓ chưa có trong công đoạn lớn mạnh.

Như thế, khi cần kiểm thử mô đun ? mà chưa có mô đun Ɓ, tất cả chúng ta cần tạo thành một giả mô đun để thay thế cho mô đun Ɓ, có chức năng cũng giống như mô đun Ɓ sau đó có thể sử dụng. Trường hợp mô đun giả này được gọi là Stub.
Trường hợp trái lại, ví dụ tất cả chúng ta đã xây dựng xong mô đun Ɓ nhưng mô đun ? chưa xây dựng xong, để kiểm thử mô đun Ɓ, tất cả chúng ta sẽ sử dụng một giải mô đun khác truy xuất dữ liệu đến mô đun Ɓ được gọi là Driver.

Check generators: phân phối các suport trong trường hợp tự tạo thành các dữ liệu thử nghiệm cho chương trình để kiểm thử. Các dữ liệu kiểm thử được tạo thành có thể là bỗng nhiên hoặc dựa vào một yếu tố nào đó như: dựa vào tìm đường đi, dựa vào mô hình, hoặc hỗn hợp của chúng.

Capture/replay tools:

  • Nhóm dụng cụ sử dụng để ghi & phát lại, các kiểm thử viên có thể chạy một vận dụng & ghi lại sự tương tác giữa người dùng & các vận dụng. Một cốt truyện được ghi lại với toàn bộ hành động của người dùng bao gồm cả việc di chuyển chuột & các dụng cụ sau đó có thể auto thực thi lại các phiên tương tác một cách không giới hạn số lần mà không yêu cầu sự can thiệp của nhân loại.
  • Một số dụng cụ sử dụng trong nhóm:

Oracle/file comparators/assertion checking tools:

  • Trợ giúp trong việc quyết định một kết quả kiểm thử có thành công hay không.

  • Chẳng hạn: dụng cụ Navicat for oracle: là một bộ dụng cụ của hãng PremiumSoft, có các chức năng phục vụ cho Developer & Administrator như: Database Designer, Table Viewer, SQL Builder, PL/SQL code Debugger,…

Coverage analyzers and instrumenters:

  • Nghiên cứu mức độ bao phủ trong toàn bộ những yêu cầu của các tiêu chí đã được lựa chọn kiểm thử. Các nghiên cứu có thể được thực hiện nhờ vào các dụng cụ chương trình.

  • Chẳng hạn: COVTOOL là dụng cụ kiểm thử coverage analyzers sử dụng cho ₵++
    (Backlinks xem qua: http://covtool.sourceforge.net/)

Tracers: ghi lại lịch sử của đường dẫn thực thi một chương trình.

Regression testing tools:

  • Các dụng cụ nhóm này được dùng để kiểm soát lại các phần tính năng của vận dụng khi có một phần của phần mềm đã được sửa đổi. Trường hợp kiểm thử được tái thực hiện để kiểm soát rằng các tính năng trước đây của vận dụng đang hoạt động bình bình có hoạt động ổn định nữa không khi có một sự biến đổi được update vào vận dụng.

  • Đây là cách thức kiểm tra. Giám định rằng các lỗi được sửa & các chức năng mới được bổ sung đã không được tạo thành các lỗi trong trong phiên bản làm việc trước của phần mềm.

  • Dụng cụ này cũng trợ giúp để chọn một tập hợp kiểm thử theo các biến đổi được thực hiện.

  • Một số dụng cụ sử dụng trong nhóm:

Reliability evaluation tools: suport nghiên cứu kết quả kiểm thử & hiển thị đồ họa để nhận xét độ tin cậy liên quan đến các bí quyết theo mô hình lựa chọn.

Viết một bình luận