stanford-oval/wikipedia huggingface dataset:
Lý Lâm Phủ
Quan hệ với giới văn nhân

Cả Tân Đường thư và Tư trị thông giám đều ghi rằng Lý Lâm Phủ "đặc biệt ghen ghét những người thuộc giới văn nhân". Theo hai bộ sử liệu này, vào năm Thiên Bảo thứ 6, ông thao túng kỳ thi khoa cử, dẫn đến không ai đỗ đạt, trong đó có cả những tài năng như Đỗ Phủ và Nguyên Kết. Tuy nhiên, ông lại tấu trình rằng "không còn nhân tài nào bị bỏ sót". Nguồn gốc của câu chuyện trên bắt nguồn từ bài thơ Dụ hữu của Nguyên Kết, nhưng trong bài viết gốc, cụm từ "布衣之士无有第者" (những người áo vải không ai đỗ đạt) chỉ ám chỉ rằng người bình dân không đỗ, chứ không hoàn toàn phủ nhận khả năng những người có xuất thân không bình dân đạt khoa danh.
Cựu Đường thư còn ghi rằng Cao Thích từng bị Lý Lâm Phủ coi thường nên chỉ được bổ nhiệm làm Huyện úy Phong Khâu. Tuy nhiên, Phong Khâu là một huyện quan trọng và đối với người không có xuất thân gia thế như Cao Thích, việc được giao chức vụ này không hẳn là bị coi nhẹ. Sau khi nhận chức, Cao Thích còn viết bài Lưu thượng Lý hữu tướng để bày tỏ lòng biết ơn với Lý Lâm Phủ.
Mặc dù bản thân Lý Lâm Phủ không xuất thân từ khoa cử, ông cũng biết làm thơ và từng giao du với những văn nhân như Hàn Triều Tông và Tịch Dự. Ông còn có qua lại và ngâm vịnh thơ với các nhân vật như Trương Cửu Linh, Vương Duy, Tôn Địch và Lư Chuẩn. Trong bài Hòa Bộc Xạ Tấn Công hộ tòng Ôn Thang, Vương Duy gọi ông là "triết tượng" (bậc thầy trí tuệ), trong khi Tôn Địch trong bài Phụng hòa Lý hữu tướng thưởng hội Xương Lâm đình ca ngợi ông là "hiền tướng". Dưới thời Lý Lâm Phủ làm Tể tướng, Vương Duy từng giữ chức Lang trung Bộ Khố và Bộ Lại (hàm Ngũ phẩm thượng), Tôn Địch làm Thái tử Tả Thứ tử (hàm Chính Tứ phẩm thượng), còn Tịch Dụ được bổ nhiệm làm Lễ bộ Thượng thư (hàm Chính Tam phẩm).
Quan hệ giữa Lý Lâm Phủ và Vương Duy đặc biệt tốt. Ngoài việc làm thơ qua lại, hai người còn là bạn đồng hành trong hội họa. Lịch đại danh họa ký của Trương Nghiễm Viễn từng ghi rằng: "Lý Lâm Phủ cũng giỏi vẽ tranh". Vương Duy cũng có mối giao thiệp với thư ký Viện Hàm của Lý Lâm Phủ. Ông từng viết bài Viện Xá nhân năng thư Phạn tự kiêm đạt Phạn âm giai khúc tận kỳ diệu hí vi chi tặng để tặng Viện Hàm, và Viện Hàm đáp lại bằng bài Thù Vương Duy. Sau đó, Vương Duy lại viết bài Trùng thù Viện Lang trung tịnh tự để hồi đáp.
Trong 18 năm nắm quyền, dù Lý Lâm Phủ mang tiếng là "kẻ âm mưu và gian trá", song năng lực của ông được đánh giá cao. Cựu Đường thư nhận xét rằng ông xử lý công việc cẩn trọng, có phương pháp: "Mỗi việc đều cẩn thận, sắp xếp quy củ, tăng cường kỷ luật. Việc bổ nhiệm và thuyên chuyển trong triều ngoài nội đều có sự cân nhắc kỹ lưỡng."
Gia quyến

Lý Lâm Phủ có tổng cộng 25 con trai và 25 con gái, dưới đây là một số người nổi bật
Con trai, Lý Tụ, giữ chức Tướng Tác Giám
Con trai, Lý Ngạc, giữ chức Tư Trữ Lang Trung
Con trai, Lý Tự, giữ chức Thái Thường Thiếu Khanh
Con trai, Lý Tốt, giữ chức Huyện lệnh tại huyện Võ Công
Con trai, Lý Đôn, giữ chức Phù Bảo Lang
Lý Hoằng Trạch, tự Đức Nhuận, giữ chức Tông Chính Khanh
Lý Nhân Chi, tham quân tại Biện Châu
Lý Xương Đồ
Lý Tổn Chi, tham quân tại Quát Châu
Lý Đại Nhã, giữ chức Huyện úy tại huyện Thường Thục
Con gái, gả cho Trương Bác Tế
Con gái, gả cho Trịnh Bình
Con gái, gả cho Đỗ Vị
Con gái, gả cho Tề Tuyên
Con gái, gả cho Nguyên Tồn
Con gái, Lý Đằng Không, xuất gia làm đạo cô, đạo hiệu là Nữ Chân
Scopula nesciaria

| Scopula nesciaria> Phân loại khoa học |
| --- | --- |
Giới (regnum): Animalia
Ngành (phylum): Arthropoda
Lớp (class): Insecta
Bộ (ordo): Lepidoptera
Họ (familia): Geometridae
Tông (tribus): Scopulini
Chi (genus): Scopula
Loài (species): S. nesciaria
Danh pháp hai phần
Scopula nesciaria (Walker, 1861) 
Danh pháp đồng nghĩa
 Acidalia nesciaria Walker, 1861  Acidalia negataria Walker, 1861  Acidalia absconditaria Walker, 1861 
Scopula nesciaria là một loài bướm đêm trong họ Geometridae.
Chú thích

↑  Sihvonen, P., 2005: Phylogeny and classification of the Scopulini moths (Lepidoptera: Geometridae, Sterrhinae). Zoological Journal of the Linnean Society 143: 473–530.
↑  Bisby, F.A.; Roskov, Y.R.; Orrell, T.M.; Nicolson, D.; Paglinawan, L.E.; Bailly, N.; Kirk, P.M.; Bourgoin, T.; Baillargeon, G.; Ouvrard, D. (2011). “Species 2000 & ITIS Catalogue of Life: 2011 Annual Checklist”. Species 2000: Reading, UK. Truy cập ngày 17 tháng 6 năm 2014.
Nguyễn Văn Bính (chính khách)

Nguyễn Văn Bính (sinh 1952) là đại biểu Quốc hội Việt Nam khóa 12, thuộc đoàn đại biểu Cao Bằng.
Asclepias subaphylla

| Asclepias subaphylla> Phân loại khoa học |
| --- | --- |
Giới (regnum): Plantae
(không phân hạng): Angiospermae
(không phân hạng): Eudicots
Bộ (ordo): Gentianales
Họ (familia): Apocynaceae
Chi (genus): Asclepias
Loài (species): A. subaphylla
Danh pháp hai phần
Asclepias subaphylla Woodson, 1954 
Asclepias subaphylla là một loài thực vật có hoa trong họ La bố ma. Loài này được Woodson mô tả khoa học đầu tiên năm 1954.
Chú thích

↑  The Plant List (2010). “Asclepias subaphylla”. Truy cập ngày 10 tháng 6 năm 2013.
Thử nghiệm phần mềm

Kiểm thử phần mềm (tiếng Anh: Software testing) là một cuộc kiểm tra được tiến hành để cung cấp cho các bên liên quan thông tin về chất lượng của sản phẩm hoặc dịch vụ được kiểm thử. Kiểm thử có thể cung cấp cho doanh nghiệp một quan điểm, một cách nhìn độc lập về phần mềm để từ đó cho phép đánh giá và thấu hiểu được những rủi ro trong quá trình triển khai phần mềm.
Trong kỹ thuật, kiểm thử không chỉ giới hạn ở việc thực hiện một chương trình hoặc ứng dụng với mục đích đi tìm các lỗi phần mềm (bao gồm các lỗi và các thiếu sót) mà còn là một quá trình phê chuẩn và xác minh một chương trình máy tính / ứng dụng / sản phẩm nhằm:
Đáp ứng được mọi yêu cầu hướng dẫn khi thiết kế và phát triển phần mềm.
Thực hiện công việc đúng như kỳ vọng.
Có thể triển khai được với những đặc tính tương tự.
Và đáp ứng được mọi nhu cầu của các bên liên quan.
Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất cứ lúc nào trong quá trình phát triển phần mềm. Theo truyền thống thì các nỗ lực kiểm thử được tiến hành sau khi các yêu cầu được xác định và việc lập trình được hoàn tất nhưng trong Agile (là một tập hợp các phương pháp phát triển phần mềm linh hoạt dựa trên việc lặp đi lặp lại và gia tăng giá trị) thì việc kiểm thử được tiến hành liên tục trong suốt quá trình xây dựng phần mềm. Như vậy, mỗi một phương pháp kiểm thử bị chi phối theo một quy trình phát triển phần mềm nhất định.
Tổng quan

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

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

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

Một nghiên cứu được tiến hành bởi NIST trong năm 2002 cho biết rằng các lỗi phần mềm gây tổn thất cho nền kinh tế Mỹ 59,5 tỷ đô mỗi năm, hơn một phần ba chi phí này có thể tránh được nếu việc kiểm thử phần mềm được thực hiện tốt hơn.
Người ta thường tin rằng, một kiếm khuyết nếu được tìm ra sớm hơn thì chi phí để sửa chữa nó sẽ rẻ hơn. Bảng dưới đây cho thấy chi phí sửa chữa các khiếm khuyết tùy thuộc vào giai đoạn nó được tìm ra. Ví dụ, một vấn đề được tìm thấy sau khi đã ra bản phần mềm chính thức rồi sẽ có chi phí gấp 10-100 lần khi giải quyết vấn đề từ lúc tiếp nhận yêu cầu. Với sự ra đời của cách thức triển khai thực tiễn liên tục và các dịch vụ dựa trên đám mây, chi phí tái triển khai và bảo trì có thể làm giảm bớt theo thời gian.
| Chi phí sửa chữa một khiếm khuyết | 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 | Thời gian phát hiện> Kiến trúc phần mềm | Thời gian phát hiện> Xây dựng phần mềm | Thời gian phát hiện> Kiểm thử hệ thống | Thời gian phát hiện> 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× |
| Thời gian sử dụng | Kiến trúc phần mềm | – | 1× | 10× | 15× | 25–100× |
| Thời gian sử dụng | Xây dựng phần mềm | – | – | 1× | 10× | 10–25× |
Tổng quan > Vai trò

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

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. 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") 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:
Trước 1956: Hướng về việc kiểm soát lỗi.
1957-1978: Hướng về chứng minh lỗi.
1979-1982: Hướng về tính phá hủy của lỗi.
1983–1987: Hướng về đánh giá lỗi.
1988–2000: Hướng về việc phòng ngừa lỗi.
Phương pháp kiểm thử > Kiểm thử tĩnh và động

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

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

Kiểm thử hộp trắng (được biết đến như là kiểm thử tính rõ ràng của hộp, kiểm thử hộp kính, kiểm thử hộp trong suốt và kiểm thử cấu trúc) giúp kiểm thử được cấu trúc nội bộ hoặc hoạt động của một chương trình, như tương phản với chức năng được bộc lộ của người dùng cuối. Một góc nhìn nội bộ của hệ thống trong kiểm thử hộp trắng giống như là các kỹ năng lập trình được sử dụng để thiết kế ra các tình huống kiểm thử. Các Tester lựa chọn yếu tố đầu vào để thực hiện đường dẫn thông qua các mã và xác định được kết quả đầu ra thích hợp. Điều này tương tự các nút kiểm thử trong một mạch, ví dụ như kiểm thử thông mạch (ICT).
Trong khi kiểm thử hộp trắng có thể được áp dụng tại đơn vị, tích hợp hệ thống và các cấp độ của quá trình kiểm thử phần mềm, nó thường được thực hiện ở cấp đơn vị. Nó có thể kiểm thử đường dẫn trong một đơn vị, liên kết giữa các đơn vị trong quá trình tích hợp, và giữa các hệ thống con trong một kiểm thử hệ thống cấp. Mặc dù phương pháp này thiết kế kiểm thử có thể phát hiện ra nhiều lỗi hoặc các vấn đề, nó có thể không phát hiện các phần chưa thực hiện của các đặc điểm kỹ thuật hoặc yêu cầu thiếu sót.
Các kỹ thuật được sử dụng trong kiểm thử hộp trắng bao gồm:
Kiểm thử API (giao diện lập trình ứng dụng) - kiểm thử ứng dụng có sử dụng các API công cộng và cá nhân.
Kiểm thử độ bao phủ mã - tạo ra các bài kiểm thử để đáp ứng một số tiêu chí của bảo hiểm mã (ví dụ, các nhà thiết kế kiểm thử có thể tạo ra các bài kiểm thử để làm tất cả các câu lệnh trong chương trình được thực hiện ít nhất một lần).
Phương pháp chèn lỗi - cố tình đưa ra những lỗi lầm để đánh giá hiệu quả của các chiến lược kiểm thử.
Phương pháp kiểm thử đột biến.
Phương pháp thử tĩnh.
Các công cụ bao phủ mã có thể đánh giá đầy đủ của một bộ kiểm thử đã được tạo ra bằng phương pháp bất kỳ nào đó, bao gồm cả kiểm thử hộp đen. Điều này cho phép nhóm nghiên cứu phần mềm kiểm thử các bộ phận của một hệ thống mà hiếm khi được kiểm thử và đảm bảo rằng các điểm chức năng quan trọng nhất đã được kiểm thử. Bao phủ mã giống như một phần mềm metric có thể báo cáo tỷ lệ phần trăm cho:
Bao phủ chức năng: dựa vào các báo cáo của chức năng này thực hiện.
Bao phủ câu lệnh: dựa vào các báo cáo về số lượng các dòng được thực hiện để hoàn thành kiểm thử.
100% bao phủ câu lệnh đảm bảo rằng tất cả các đường dẫn mã, hoặc các nhánh (trong điều kiện của luồng điều khiển) được thực hiện ít nhất một lần. Điều này hữu ích trong việc đảm bảo đúng chức năng nhưng không đủ kể từ khi các mã tương tự có thể thực hiện tiến trình xử lý dữ liệu đầu vào khác nhau dù đúng hoặc không.
Phương pháp kiểm thử > Phương pháp thăm dò > Kiểm thử hộp đen

Kiểm thử hộp đen coi phần mềm như là một "hộp đen", kiểm thử chức năng mà không cần bất kỳ kiến thức về cấu trúc và hành vi bên trong phần mềm. Các Tester chỉ biết về những gì phần mềm phải làm mà không biết là nó làm như thế nào. Phương pháp kiểm thử hộp đen bao gồm: Phân vùng tương đương, phân tích giá trị biên, tất cả các cặp kiểm thử, bảng chuyển đổi trạng thái, kiểm thử bảng quyết định, kiểm thử chéo, kiểm thử dựa trên mô hình, sử dụng Test Case, thăm dò kiểm thử và kiểm thử dựa trên đặc điểm kỹ thuật.
Kiểm thử dựa trên đặc điểm kỹ thuật nhằm mục đích để kiểm tra các chức năng của phần mềm theo các yêu cầu ứng dụng. Mức độ kiểm thử thường đòi hỏi Test Case kỹ lưỡng để được cung cấp bởi các Tester, những người mà sau đó có thể xác minh một cách đơn giản rằng đối với một giá trị đầu vào hoặc đầu ra (hoặc cách xử lý) có thể giống hoặc không so với giá trị kỳ vọng được định vị trong một Test Case nhất định. Các Test Case được xây dựng quanh các thông số kỹ thuật và các yêu cầu đề xuất, tức là những tất cả những gì ứng dụng đó phải làm. Nó được sử dụng để mô tả mở rộng phần mềm bao gồm các thông số kỹ thuật, các yêu cầu và thiết kế được bắt nguồn trong Test Case. Các kiểm thử này có thể là chức năng hoặc phi chức năng.
Kiểm thử dựa trên đặc điểm kỹ thuật có thể là cần thiết để đảm bảo chức năng chính xác, nhưng nó không đủ để bảo vệ chống lại các tình huống phức tạp hoặc có độ rủi ro cao.
Một lợi thế của kỹ thuật kiểm thử hộp đen là không yêu cầu nhất thiết phải có kiến thức lập trình. Các Tester tiến hành kiểm thử ở các khu vực và các chức năng khác nhau của phần mềm mà không liên quan đến các lập trình viên. Mặt khác, kiểm thử hộp đen được cho là "đi bộ trong một mê cung tối tăm mà không có đèn pin". Bởi vì họ không kiểm thử mã nguồn và đã có nhiều tình huống các Tester chỉ kiểm thử được tính năng trong một vài trường hợp chứ không kiểm thử được toàn bộ hoạt động của chương trình.
Phương pháp kiểm thử này có thể được áp dụng cho tất cả các cấp kiểm thử phần mềm: đơn vị, tích hợp, hệ thống và chấp nhận. Nó không thể thực hiện được tất cả các kiểm thử các cấp độ cao hơn nhưng nó có thể tạo ưu thế tốt khi kiểm thử từng đơn vị.
Phương pháp kiểm thử > Phương pháp thăm dò > Kiểm thử trực quan

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

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

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