cyanic-selkie/wikianc huggingface dataset:
Đồi Makli
Đồi Makli là một trong những nghĩa trang khảo cổ lớn nhất trên thế giới, với đường kính khoảng 8 km. Nó nằm cách thành phố Karachi khoảng 98 km về phía đông và là nơi chôn cất với 125.000 ngôi mộ, bao gồm cả của một số nhà lãnh đạo địa phương như thánh Sufi và những người khác. Makli nằm ở vùng ngoại ô của Thatta, thủ đô của Sindh cho đến thế kỷ XVII, ở miền đông nam ngày nay của Pakistan. Khu vực khảo cổ này đã được ghi vào danh sách Di sản thế giới vào năm 1981 với tên Các Di tích Lịch sử tại Makli, Thatta.
Lịch sử
Có rất nhiều truyền thuyết về quá trình thành lập khu vực, nhưng người ta tin rằng, nghĩa trang lớn xung quanh ngôi đền của Muhammad Hussain Abro thế kỷ 14. Tuy nhiên, việc thiết lập Makli sau đó chỉ như là nơi linh thiêng để thờ phụng, chôn cất đi những thánh địa phương như nhà thơ và học giả Shaikh Hammad Jamali cùng người cai trị địa phương sau đó, Jam Tamachi. Ngoài ra, tại đây còn là nơi chôn cất của thánh Pir Murad (1428-1488).
Những ngôi mộ và bia mộ trải rộng tại nghĩa trang là văn bản tài liệu đánh dấu lịch sử xã hội và chính trị của Sind. Nhiều trong số chúng được xây dựng bằng cách sử dụng đá sa thạch tại địa phương, những số khác được xây bằng gạch (sử dụng nhiều nhất). Những lăng mộ hoàng gia tại đây được chia thành hai nhóm chính, lăng mộ thời kỳ Samma (1352-1520) và Tarkhan (1556-1592). Có tổng số bốn thời kỳ lịch sử được thể hiện thông qua kiến trúc tại khu khảo cổ là Samma, Arghun, Tarkhan và Mughal. Ngôi mộ của vua Jam Nizamuddin II (trị vì từ năm 1461-1508), là một cấu trúc hình vuông ấn tượng được xây dựng bằng sa thạch và trang trí với rất nhiều hoa văn và hình học là cấu trúc ấn tượng nhất. Ngoài ra còn có lăng mộ của Isa Khan Hussain II (mất năm 1651), một tòa nhà hai tầng với vòm lớn cùng ban công.
Clarinda, Iowa
Clarinda là một thành phố thuộc quận Page, tiểu bang Iowa, Hoa Kỳ. Năm 2010, dân số của thành phố này là 5572 người.
Dân số
Dân số qua các năm:
Xem thêm
Thể loại:Thành phố của Iowa Thể loại:Quận Page, Iowa
Cyanotis caespitosa
Cyanotis caespitosa là một loài thực vật có hoa trong họ Commelinaceae. Loài này được Kotschy & Peyr. mô tả khoa học đầu tiên năm 1867.
Liên kết ngoài
Thể loại:Cyanotis Thể loại:Thực vật được mô tả năm 1867
Cỏ Mombasa
Cỏ Mombasa (Panicum maximum cv Mombasa), tên gọi khác là cỏ sả, sả lá lớn, cỏ Guinea Mombasa; là loài cây hòa thảo, cỏ mọc từng bụi như bụi sả. Cỏ có vị ngọt, ăn ngon, giá trị dinh dưỡng cao thường được trồng làm thức ăn cho gia súc.
Đặc điểm
Cỏ rất dễ trồng, dễ chăm sóc, chịu hạn tốt, có thể chịu bóng râm. Cỏ có thể sinh trưởng ở nhiều vùng đất khác nhau, cho sản lượng cao nhất ở các loại đất phù sa; chịu được đất mặn nhẹ và không chịu được đất ẩm kéo dài. Trồng thâm canh thu hoạch từ 8-10 lứa/năm, sản lượng đạt 100-200 tấn/ha/năm.
Chú thích
Thể loại:Giống cây trồng Thể loại:Thức ăn chăn nuôi
Boothipuram
Boothipuram là một thị xã panchayat của quận Theni thuộc bang Tamil Nadu, Ấn Độ.
Nhân khẩu
Theo điều tra dân số năm 2001 của Ấn Độ, Boothipuram có dân số 9623 người. Phái nam chiếm 51% tổng số dân và phái nữ chiếm 49%. Boothipuram có tỷ lệ 60% biết đọc biết viết, cao hơn tỷ lệ trung bình toàn quốc là 59,5%: tỷ lệ cho phái nam là 69%, và tỷ lệ cho phái nữ là 50%. Tại Boothipuram, 12% dân số nhỏ hơn 6 tuổi.
Tham khảo
Thể loại:Thành phố thuộc bang Tamil Nadu
Pseudantechinus roryi
Pseudantechinus roryi là một loài động vật có vú trong họ Dasyuridae, bộ Dasyuromorphia. Loài này được Cooper, Aplin & Adams mô tả năm 2000.
Tham khảo
Thể loại:Pseudantechinus Thể loại:Động vật được mô tả năm 2000
Crataegus laevigata
Crataegus laevigata là loài thực vật có hoa trong họ Hoa hồng. Loài này được (Poir.) DC. mô tả khoa học đầu tiên năm 1825.
Liên kết ngoài
Thể loại:Chi Sơn tra Thể loại:Thực vật được mô tả năm 1825 Thể loại:Thực vật Đức Thể loại:Thực vật Ukraina Thể loại:Thực vật Ý Thể loại:Cây trang trí Thể loại:Thực vật vườn châu Âu Thể loại:Thực vật Hungary Thể loại:Cây châu Âu
Mimene atropatene
Mimene atropatene, purple swift là một loài bướm thuộc Họ Bướm nhảy. Chúng được tìm thấy dọc theo bờ biển đông bắc của Queensland, cũng như quần đảo Aru, Irian Jaya và Papua New Guinea.
Sải cánh dài khoảng 40 mm.
Candelaria, México
Candelaria là một đô thị thuộc bang Campeche, Mexico. Năm 2005, dân số của đô thị này là 37006 người.
Célestine N'Drin
Célestine N'Drin (sinh ngày 20 tháng 7 năm 1963) là một vận động viên điền kinh người Bờ Biển Ngà, chuyên môn trong 400 và 800 mét. Cô đại diện cho đất nước của mình tại Thế vận hội mùa hè trong ba lần: 1976, 1984 và 1988.
Candelaria, México
Tham khảo
Thể loại:Đô thị bang Campeche
Célestine N'Drin
Tham khảo
Thể loại:Nhân vật còn sống Thể loại:Sinh năm 1963
Pisaboa mapiri
Tham khảo
Thể loại:Pisaboa Thể loại:Loài đặc hữu của Bolivia
Tragon silaceoides
Tragon silaceoides là một loài bọ cánh cứng trong họ Cerambycidae.
Tham khảo
Thể loại:Tragon
Fluminicola columbiana
Tham khảo
Thể loại:Động vật đặc hữu Hoa Kỳ Thể loại:Fluminicola Thể loại:Động vật được mô tả năm 1899
Ruslan Startsev
Ruslan Sergeyevich Startsev (Руслан Сергеевич Старцев; sinh ngày 17 tháng 1 năm 1998) là một cầu thủ bóng đá người Nga thi đấu cho FC Znamya Truda Orekhovo-Zuyevo.
Sự nghiệp câu lạc bộ
Anh có màn ra mắt tại Giải bóng đá chuyên nghiệp quốc gia Nga cho FC Znamya Truda Orekhovo-Zuyevo vào ngày 27 tháng 7 năm 2017 trong trận đấu với FC Veles Moskva.
Liên kết ngoài
Thể loại:Sinh năm 1998 Thể loại:Nhân vật còn sống Thể loại:Cầu thủ bóng đá Nga Thể loại:Cầu thủ bóng đá FC Znamya Truda Orekhovo-Zuyevo Thể loại:Thủ môn bóng đá
Dhythyanakerekaval, Hunsur
Dhythyanakerekaval là một làng thuộc tehsil Hunsur, huyện Mysore, bang Karnataka, Ấn Độ.
Tham khảo
Thể loại:Làng ở huyện Mysore
Saint-Dézéry
Saint-Dézéry là một xã ở tỉnh Gard. Xã này có diện tích 6,01 km², dân số năm 1999 là 251 người. Khu vực này có độ cao trung bình 70 mét trên mực nước biển.
Tham khảo
Saintdezery
Interferon alfacon-1
Interferon alfacon-1 là một loại interferon tổng hợp tái tổ hợp được sử dụng để điều trị bệnh bạch cầu tế bào lông, khối u ác tính và sarcoma Kaposi liên quan đến AIDS.
Tham khảo
Thể loại:Thuốc kháng virus Thể loại:Chất kích thích miễn dịch
(58504) 1996 VZ3
(58504) 1996 VZ3 là một tiểu hành tinh vành đai chính. Nó được phát hiện qua chương trình tiểu hành tinh Beijing Schmidt CCD ở trạm Xinglong ở tỉnh Hồ Bắc, Trung Quốc ngày 7 tháng 11 năm 1996.
Tham khảo
Thể loại:Thiên thể phát hiện năm 1996 Thể loại:Tiểu hành tinh vành đai chính
Xung đột biên giới Eritrea–Ethiopia
Là một phần của xung đột tại Sừng Phi châu, Xung đột biên giới Eritrea–Ethiopia là những vụ bạo lực bế tắc giữa Eritrea và Ethiopia. Xung đột biên giới Eritrea–Ethiopia gồm những vụ va chạm lác đác giữa lực lượng quân sự hai bên, một vài vụ đụng độ trong đó là một phần của cuộc Nổi dậy Afar lần thứ Hai có quy mô lớn hơn. Xung đột biên giới diễn ra kể từ Chiến tranh Eritrea–Ethiopia hồi những năm 1998–2000, và bao gồm nhiều cuộc đụng độ với nhiều thương vong, như cuộc đụng độ Tserona 2016. Năm 2018, Ethiopia cuối cùng cũng tuyên bố rằng nước này sẽ nhượng lại Badme cho Eritrea, kéo theo hệ quả kết thúc những xung đột dai dẳng suốt hai thập niên. Vào ngày 9 tháng 7 năm 2018, hai quốc gia chính thức kết thúc xung đột biên giới trên bàn Hội nghị thượng đỉnh Eritrea – Ethiopia 2018 thông qua việc ký thỏa thuận chung để tiếp nối quan hệ ngoại giao hòa bình.
Bối cảnh
Eritrea giành được độc lập từ Ethiopia năm 1993, sau quá trình đấu tranh vũ trang lâu dài. Trong giai đoạn 1998-2000, xung đột tiếp diễn giữa hai nước về chủ quyền lãnh thổ Badme, khiến khoảng 70.000 tới 80.000 người thiệt mạng.
Lịch sử
Tháng 6 năm 2016, Eritrea nhận trách nhiệm vụ tiêu diệt 200 lính và làm bị thương 300 quân của phía Ethiopia trong trận Tsorona.
Tham khảo
Thể loại:Nội chiến liên quan tới đất nước và con người châu Phi Thể loại:Chiến tranh liên quan tới Ethiopia Thể loại:Lịch sử quân sự Ethiopia Thể loại:Chiến tranh liên quan tới Eritrea Thể loại:Lịch sử quân sự Eritrea Thể loại:Nổi dậy ở châu Phi Thể loại:Quan hệ quân sự Eritrea–Ethiopia Thể loại:Biên giới Eritrea–Ethiopia Thể loại:Xung đột thập niên 2000 Thể loại:Xung đột thập niên 2010
Steins;Gate 0 (anime)
Cốt truyện
Câu chuyện diễn ra ở dòng thời gian khác với kết thúc của loạt anime Steins;Gate. Sau khi nỗ lực cứu Makise Kurisu để ngăn chặn chiến tranh trong tương lai nhờ cỗ máy thời gian thất bại, Okabe Rintaro, bị ám ảnh bởi trải nghiệm thay đổi quá khứ bằng khả năng Reading Steiner của mình, quyết định ở lại dòng thời gian Beta nơi Kurisu chết. Sau nhiều tháng, Rintaro gặp Hiyajo Maho, đồng nghiệp cũ của Kurisu đang làm việc với Amadeus, một trí tuệ nhân tạo được xây dựng từ ký ức của Kurisu trước khi cô chết. Khi Rintaro quyết định giúp đỡ quá trình phát triển Amadeus, cậu nhận ra trải nghiệm với các dòng thời gian khác nhau của mình vẫn chưa kết thúc.
Sản xuất và phát hành
Steins;Gate 0 được thực hiện bởi White Fox, và chuyển thể từ trò chơi điện tử cùng tên năm 2015. Trò chơi là phần tiếp theo của game Steins;Gate, cũng được chuyển thể thành anime bởi White Fox vào năm 2011. Mặc dù cốt truyện của visual novel có nhiều nhánh truyện khác nhau, bộ phim xây dựng lại cốt truyện thành một nhánh duy nhất.
Phần âm nhạc do Abo Takeshi, Nobusawa Nobuaki, và Moe Hyūga biên soạn. Ca khúc mở đầu, "Fatima", trình bày bởi Itō Kanako, ca sĩ đã thực hiện ca khúc mở đầu cho anime Steins;Gate và phim anime Steins;Gate: The Movie trước đó, và ca khúc kết thúc, "Last Game", do nhóm nhạc Zwei trình bày, cũng từng thực hiện ca khúc kết thúc cho game Steins;Gate 0.
Bô phim chính thức công bố vào tháng 3 năm 2015, cùng lúc với game Steins;Gate 0. Phim lại được giới thiệu lần nữa bằng trailer và thông tin nghệ thuật vào tháng 7 năm 2017 như một phần thuộc dự án "Steins;Gate World Line 2017–2018 Project", bao gồm các phương tiện truyền thông của trò chơi Steins;Gate 0; vào lúc này, bộ phim đã đi vào khâu sản xuất. Phim bắt đầu công chiếu từ ngày 12 tháng 4 năm 2018, tiếp nối kết thúc của anime Steins;Gate được phát sóng lại trước đó, và dự kiến có 23 tập. Anime chiếu trên các kênh Tokyo MX, TVA, KBS Kyoto, Sun TV, TVQ, AT-X, BS11, và GYT, và phát sóng trực tuyến thông qua Ameba TV tại Nhật Bản. Loạt phim công chiếu đồng loạt bởi Crunchyroll, và Aniplus Asia tại Đông Nam Á, cùng phần lồng tiếng Anh sẽ phát sóng trực tuyến thông qua Funimation tại Mỹ, Canada, vương quốc Anh, và Ireland. Bộ phim còn dự định phát hành theo bộ 6 đĩa Blu-ray và DVD tại Nhật từ ngày 27 tháng 6 đến 28 tháng 11 năm 2018, với đĩa cuối cùng sẽ kèm theo một tập không được công chiếu.
Liên kết ngoài
Thể loại:Anime dài tập dựa trên trò chơi điện tử Thể loại:Science Adventure Thể loại:Phim truyền hình lấy bối cảnh ở Tokyo Thể loại:Loạt phim truyền hình có nội dung du hành thời gian Thể loại:White Fox Thể loại:Anime truyền hình dài tập năm 2018 Thể loại:Funimation
Rhizedra lechneri
Rhizedra lechneri là một loài bướm đêm trong họ Noctuidae.
Liên kết ngoài
Thể loại:Rhizedra
Barrolândia
Liên kết ngoài
Thể loại:Đô thị bang Tocantins
Androlepis
Androlepis là một chi thực vật có hoa trong họ Bromeliaceae.
Liên kết ngoài
Thể loại:Androlepis Thể loại:Chi thực vật
Barichneumon curticornis
Barichneumon curticornis là một loài tò vò trong họ Ichneumonidae.
Liên kết ngoài
Thể loại:Barichneumon
Ptarmica septentrionalis
Ptarmica septentrionalis là một loài thực vật có hoa trong họ Cúc. Loài này được (Serg.) Klokov & Krytzka miêu tả khoa học đầu tiên năm 1984.
Liên kết ngoài
Thể loại:Ptarmica Thể loại:Thực vật được mô tả năm 1984
Ptarmica septentrionalis
Bopal
Bopal là một thị trấn thống kê (census town) của quận Ahmadabad thuộc bang Gujarat, Ấn Độ.
Nhân khẩu
Theo điều tra dân số năm 2001 của Ấn Độ, Bopal có dân số 12.181 người. Phái nam chiếm 53% tổng số dân và phái nữ chiếm 47%. Bopal có tỷ lệ 80% biết đọc biết viết, cao hơn tỷ lệ trung bình toàn quốc là 59,5%: tỷ lệ cho phái nam là 84%, và tỷ lệ cho phái nữ là 75%. Tại Bopal, 12% dân số nhỏ hơn 6 tuổi.
Tham khảo
Thể loại:Thành phố thuộc bang Gujarat
Kiểm thử phần mềm
Kiểm thử phần mềm (tiếng Anh: Software testing) là một cuộc kiểm tra được tiến hành để cung cấp cho các bên liên quan thông tin về chất lượng của sản phẩm hoặc dịch vụ được kiểm thử. 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: 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
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.
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.
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ó.
Telicota anisodesma
Telicota anisodesma, bướm phi tiêu lớn hay bướm phi tiêu lớn phương Nam là một loài bướm thuộc Họ Bướm nhảy. Chúng được tìm thấy dọc theo tây nam bờ biển của New South Wales và đông bắc bờ biển của Queensland.
Kiểm thử phần mềm
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.
Telicota anisodesma
Sải cánh dài khoảng 30 mm.
Kiểm thử phần mềm
Kinh tế
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.
Telicota anisodesma
Ấu trùng ăn các loài rừng nhiệt đới khác nhau, bao gồm mây nước. Chúng sống ở nơi trú ẩn hình trụ được xây dựng bằng cách cuộn một đầu lá, để lại một lối vào ở phía dưới.
Kiểm thử phần mềm
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ử.
Telicota anisodesma
Liên kết ngoài
Thể loại:Telicota
Kiểm thử phần mềm
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:
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 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.
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 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:
100% bao phủ câu lệnh đảm bảo rằng tất cả các đường dẫn mã, hoặc các nhánh (trong điều kiện của luồng điều khiển) được thực hiện ít nhất một lần. Điều này hữu ích trong việc đảm bảo đúng chức năng nhưng không đủ kể từ khi các mã tương tự có thể thực hiện tiến trình xử lý dữ liệu đầu vào khác nhau dù đúng hoặc không.
Kiểm thử hộp đen
thumb|200px|Sơ đồ hộp đen Kiểm thử hộp đen coi phần mềm như là một "hộp đen", kiểm thử chức năng mà không cần bất kỳ kiến thức về cấu trúc và hành vi bên trong phần mềm. Các Tester chỉ biết về những gì phần mềm phải làm mà không biết là nó làm như thế nào. 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.
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ị.
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.
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.
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. Đối với khách hàng, nó trở nên dễ dàng để cung cấp các báo cáo lỗi chi tiết và thông tin phản hồi còn đối với người sử dụng chương trình thì kiểm thử trực quan có thể ghi lại hành động của người dùng trên màn hình như tiếng nói và hình ảnh của họ để cung cấp một bức tranh hoàn chỉnh tại thời điểm phần mềm thất bại cho các nhà phát triển.
Kiểm thử hộp xám
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ử.
Kiểm thử đơn vị
Kiểm thử đơn vị hay còn được gọi là kiểm thử thành phần, đề cập đến việc kiểm thử chức năng từng phần của mã, thường ở mức độ chức năng. Trong một môi trường hướng về đối tượng thì điều này thường là cấp độ lớp, và các kiểm thử đơn vị tối thiểu bao gồm hàm dựng và hàm hủy. Nhiều loại kiểm thử được viết bởi các nhà phát triển như họ làm việc trong mã (kiểu hộp trắng) để đảm bảo rằng từng hàm riêng biệt hoạt động đúng như kỳ vọng. Một hàm có thể có nhiều kiểm thử từ đó giúp nắm bắt được các trường hợp góc hoặc các nhánh trong Code. Kiểm thử đơn vị một mình không thể đảm bảo hết được từng chức năng của từng bộ phận trong phần phềm nhưng nó được sử dụng để đảm bảo rằng các khối kiến trúc của phần mềm hoạt động độc lập với nhau.
Kiểm thử đơn vị là một quá trình phát triển phần mềm có liên quan đến ứng dụng đồng bộ của một loạt các chiến lược phòng ngừa phát hiện lỗi và để giảm thiểu rủi ro, thời gian và chi phí. Nó được thực hiện bởi kỹ sư hay nhà phát triển trong suốt giai đoạn xây dựng của vòng đời phát triển phần mềm. Không chỉ tập trung vào việc đảm bảo chất lượng truyền thống mà phải gia tăng nó lên vì thế kiểm thử đơn vị có mục đích loại bỏ những lỗi cấu trúc trước khi mã hóa rồi mới thúc đẩy việc quản lý chất lượng. Chiến lược này nhằm nâng cao chất lượng cũng như hiệu quả của phần mềm trong tiến trình quản lý và phát triển chung.
Tùy thuộc vào kỳ vọng của tổ chức phát triển phần mềm, kiểm thử đơn vị có thể bao gồm phân tích mã tĩnh, phân tích luồng dữ liệu, phân tích dữ liệu, đánh giá mã cân bằng, phân tích mã bao phủ và các thực hành xác nhận phần mềm khác.
Kiểm thử tích hợp
Kiểm thử tích hợp là một hình thức kiểm thử phần mềm nhằm tìm cách xác minh các giao diện giữa các thành phần xung đột của một thiết kế. Các thành phần này có thể tích hợp theo cách lặp đi lặp lại hoặc tất cả cùng nhau ("Big Bang"). Thông thường cách thức này được coi là một thực hành tốt hơn vì nó cho phép các vấn đề về giao diện được định vị một cách nhanh chóng và cố định hơn.
Kiểm thử tích hợp làm lộ ra các khiếm khuyết trong các giao diện và tương tác giữa các thành phần tích hợp (Modules). Các nhóm thành phần đã được kiểm thử lớn dần từng bước tương ứng với các thuộc tính của cấu trúc thiết kế đã được tích hợp và kiểm thử cho đến khi phần mềm hoạt động như một hệ thống.
Kiểm thử hệ thống
Kiểm thử hệ thống giúp xác minh rằng một hệ thống được tích hợp có đáp ứng đầy đủ các yêu cầu hay không. Ngoài ra, kiểm thử phần mềm phải đảm bảo rằng các chương trình hoạt động như kỳ vọng, không còn bị phá hủy hay lỗi phần nào đó trong môi trường hoạt động của nó hoặc không gặp sự cố khi hoạt động với tiến trình khác (điều này bao gồm bộ nhớ chia sẻ không bị hỏng, nguồn tài nguyên không bị dư thừa hay chiếm dụng quá mức và không bị đẩy ra khi hoạt động song song các tiến trình).
Kiểm thử mức chấp nhận
Cuối cùng hệ thống được giao cho người dùng để kiểm thử mức chấp nhận.
Kiểm thử cài đặt
Một kiểm thử cài đặt đảm bảo rằng hệ thống được cài đặt đúng và hoạt động tại phần cứng thực tế của thiết bị.
Kiểm thử khả năng tương thích
Một nguyên nhân phổ biến của lỗi phần mềm (thực tế hay nhận thức) là thiếu khả năng tương thích với các hệ điều hành hoặc phần mềm ứng dụng khác (có thể là các phiên bản cũ hay mới của hệ điều hành), hoặc môi trường mục tiêu khác nhau rất nhiều so với bản gốc (chẳng hạn như một thiết bị đầu cuối hoặc ứng dụng giao diện dùng để chạy trên máy tính để bàn hiện nay đang được yêu cầu để trở thành một ứng dụng web, trong đó phải thực hiện trong một trình duyệt web). Ví dụ, trong trường hợp thiếu tính tương thích ngược có thể xảy ra bởi vì các lập trình viên chỉ phát triển và kiểm thử phần mềm trên phiên bản mới nhất của môi trường mục tiêu, mà không phải tất cả người dùng có thể chạy. Điều này dẫn đến hậu quả không lường được rằng các chức năng mới nhất có thể không hoạt động trong các phiên bản trước đây của môi trường mục tiêu nhưng lại có thể chạy được với phần cứng cũ hơn và phiên bản trước trước đó của môi trường mục tiêu. Đôi khi các vấn đề như vậy có thể được cố định bằng cách chủ động trừu tượng hóa chức năng hệ điều hành vào một Module chương trình riêng biệt hoặc thư viện.
Smoke & Sanity Testing
Sanity Testing xác định tính hợp lý để tiến hành các kiểm thử khác.
Smoke Testing được sử dụng để xác định xem có vấn đề nghiêm trọng với bộ phận của phần mềm, ví dụ như một bài kiểm thử xác minh khi xây dựng phần mềm.
Kiểm thử hồi quy
Kiểm thử hồi quy tập trung vào việc tìm kiếm lỗi sau khi xảy ra một thay đổi mã chính. Cụ thể, nó tìm cách phát hiện ra các hồi quy của phần mềm hoặc các lỗi cũ quay trở lại. Những hồi quy như vậy xảy ra bất cứ khi nào chức năng phần mềm trước đây đang hoạt động giờ tạm ngưng như đã định. Thông thường, những hồi quy xảy ra như một hệ quả không lường trước được những thay đổi chương trình, khi một phần mới của phần mềm được phát triển xung đột với mã tồn tại trước đó. Phương pháp phổ biến của kiểm thử hồi quy bao gồm chạy lại những kiểm thử trước đó và kiểm thử xem lỗi cố định trước đây tại sao lại xuất hiện. Độ sâu của kiểm thử phụ thuộc vào các nguy cơ và giai đoạn trong quá trình phát hành các tính năng bổ sung. Chúng có thể được hoàn tất khi thay đổi thêm vào đầu hoặc cuối bản phát hành, cũng có thể được có mức độ nguy hiểm thấp khi thực hiện kiểm thử tích cực trên mỗi tính năng.
Ví dụ: một PM đang phát triển khi kiểm tra cho thấy nó chạy tốt các chức năng A, B và C. Khi có thay đổi code của chức năng C, nếu chỉ kiểm tra chức năng C thì chưa đủ, cần phải kiểm tra lại tất cả các chức năng khác liên quan đến chức năng C, trong ví dụ này là A và B. Lý do là khi C thay đổi, nó có thể sẽ làm A và B không còn làm việc đúng nữa.
Mặc dù không là một mức kiểm tra, thực tế lại cho thấy Regression Test là một trong những loại kiểm tra tốn nhiều thời gian và công sức nhất. Tuy thế, việc bỏ qua Regression Test là "không được phép" vì có thể dẫn đến tình trạng phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng, mặc dù ta "tưởng rằng" những lỗi đó hoặc không có hoặc đã được kiểm tra và sửa chữa rồi!
Kiểm thử mức chấp nhận
Kiểm thử mức chấp nhận được hiểu theo một trong hai nghĩa sau:
Kiểm thử Alpha
Kiểm thử Alpha là việc kiểm thử hoạt động chức năng thực tế hoặc giả lập do người dùng/khách hàng tiềm năng hoặc một nhóm Tester độc lập thực hiện tại nơi sản xuất phần mềm. Kiểm thử Alpha thường được sử dụng cho phần mềm đại trà (đóng gói sẵn để bán) như là một hình thức kiểm thử mức chấp nhận nội bộ trước khi phần mềm chính thức đi vào giai đoạn kiểm thử Beta.
Kiểm thử Beta
Kiểm thử phiên bản Beta được đưa ra sau khi kiểm thử Alpha và có thể được coi là một hình thức mở rộng của kiểm thử mức chấp nhận của người dùng. Các phiên bản của phần mềm, gọi là phiên bản beta, được phát hành cho một đối tượng hạn chế bên ngoài của nhóm lập trình. Phần mềm này được phát hành cho nhiều nhóm người dùng để kiểm thử nhiều hơn nữa và nó có thể đảm bảo sản phẩm có ít thiếu sót và lỗi. Đôi khi, các phiên bản beta được phát hành rộng rãi để tăng phạm vi phản hồi thông tin từ một số lượng tối đa người dùng trong tương lai.
Kiểm thử chức năng và phi chức năng
Chức năng kiểm thử liên quan đến các hoạt động xác minh một hành động cụ thể hoặc chức năng của các mã. Đó là những điều được tìm thấy trong các tài liệu yêu cầu, mặc dù có một số phương pháp phát triển được làm từ các câu chuyện của người dùng. Kiểm thử chức năng nhằm trả lời cho câu hỏi "người dùng có hay không làm được với tính năng cụ thể này".
Kiểm thử phi chức năng đề cập đến các khía cạnh của phần mềm có thể không liên quan đến một chức năng cụ thể hoặc hành động người dùng, chẳng hạn như khả năng mở rộng và hiệu suất khác, hành vi dưới những hạn chế hoặc bảo mật nhất định. Việc kiểm thử sẽ xác định điểm cuộn mà tại đó khả năng mở rộng và thực hiện của các điểm cực trị hoạt động không ổn định. Những yêu cầu phi chức năng thường là những phản ánh về chất lượng của sản phẩm, đặc biệt là trong bối cảnh các quan điểm phù hợp của người sử dụng nó.
Kiểm thử sự phá hủy
Kiểm thử sự phá hủy cố gắng làm hỏng phần mềm hoặc một hệ thống con. Nó xác minh rằng các phần mềm có chức năng đúng ngay cả khi nó nhận được đầu vào không hợp lệ hoặc không mong muốn, do đó tạo ra sự vững mạnh của xác nhận đầu vào và thói quen quản lý các lỗi. Chèn lỗi phần mềm ở dạng mờ nhạt là một ví dụ về kiểm thử thất bại. Các công cụ kiểm thử phi chức năng thương mại được liên kết từ các trang chèn lỗi phần mềm mà ở đó có sẵn vô số các mã nguồn mở và các công cụ miễn phí để thực hiện kiểm thử sự phá hủy phần mềm.
Kiểm thử hiệu suất phần mềm
Kiểm thử hiệu suất thường được chạy để xác định một hệ thống hay hệ thống con thực hiện như thế nào về độ nhạy và tính ổn định theo một khối lượng công việc cụ thể. Nó cũng có thể dùng để điều tra, đánh giá, xác nhận hoặc xác minh các thuộc tính chất lượng khác của hệ thống, chẳng hạn như khả năng mở rộng, độ tin cậy và sử dụng tài nguyên.
Kiểm tra khối lượng là một cách để kiểm tra các chức năng của phần mềm ngay cả khi một số thành phần (ví dụ như một tập tin hoặc cơ sở dữ liệu) tăng triệt để kích thước. Kiểm thử độ căng là một cách để kiểm tra độ bền đột xuất hoặc ít gặp theo khối lượng công việc.
Kiểm thử tính ổn định (thường được tham chiếu lượng tải và kiểm thử độ bền) giúp kiểm tra xem phần mềm có thể hoạt động tốt liên tục trong hoặc trên một chu kỳ chấp nhận được. Có rất ít quy ước về các mục tiêu cụ thể của kiểm thử hiệu suất như là: Các thuật ngữ lượng tải, kiểm thử hiệu suất, kiểm thử tính mở rộng và kiểm thử khối lượng, thường được sử dụng thay thế cho nhau.
Hệ thống phần mềm thời gian thực có những ràng buộc chính xác thời gian. Để kiểm thử những ràng buộc thời gian được đáp ứng thì người ta dùng phương pháp kiểm thử thời gian thực.
Hyposidra ingrata
Hyposidra ingrata là một loài bướm đêm trong họ Geometridae.
Kiểm thử phần mềm
Kiểm thử khả năng tiếp cận
Kiểm thử khả năng tiếp cận bao gồm việc tuân thủ các tiêu chuẩn sau:
Kiểm thử bảo mật
Kiểm thử bảo mật phần mềm là rất cần thiết trong việc xử lý dữ liệu mật và ngăn chặn các hacker xâm nhập hệ thống.
Danh sách câu lạc bộ bóng đá ở Tchad
Về danh sách đầy đủ, xem Thể loại:Câu lạc bộ bóng đá Tchad
Kiểm thử phần mềm
Tính toàn cầu và bản địa hóa
Khả năng tổng quát của phần mềm được toàn cầu và bản địa hóa có thể được tự động kiểm tra mà không dịch thực tế, bằng cách sử dụng phương thức giả bản địa. Nó sẽ xác minh rằng các ứng dụng vẫn hoạt động, ngay cả sau khi nó đã được dịch sang một ngôn ngữ mới hoặc thích nghi với một nền văn hóa mới (chẳng hạn như tiền tệ và múi giờ khác nhau).
Danh sách câu lạc bộ bóng đá ở Tchad
Tham khảo
Tchad  Bóng đá
Kiểm thử phần mềm
Tính toàn cầu và bản địa hóa
Việc thực dịch ra nhiều ngôn ngữ phải được kiểm tra. Sự cố bản địa hóa có thể bao gồm:
Eremurus fuscus
Eremurus fuscus là một loài thực vật có hoa trong họ Thích diệp thụ. Loài này được (O.Fedtsch.) Vved. miêu tả khoa học đầu tiên năm 1952.
Kiểm thử phần mềm
Kiểm thử sự phát triển
Kiểm thử sự phát triển là một tiến trình phát triển phần mềm có liên quan đến ứng dụng đồng bộ của một loạt các chiến lược phòng ngừa phát hiện lỗi và để giảm thiểu rủi ro về thời gian và chi phí. Nó được thực hiện bởi các kỹ sư hoặc các nhà phát triển trong giai đoạn xây dựng vòng đời phát triển phần mềm. Không chỉ thay thế các trọng tâm QA truyền thống mà phải bổ sung nó. Kiểm thử sự phát triển nhằm mục đích loại bỏ những lỗi xây dựng trước khi mã được đẩy mạnh QA, chiến lược này là nhằm nâng cao chất lượng của phần mềm cũng như hiệu quả của sự phát triển chung và cả quá trình QA. Tùy thuộc vào kỳ vọng của tổ chức phát triển phần mềm, kiểm tra phát triển có thể bao gồm phân tích mã tĩnh, phân tích luồng dữ liệu, phân tích số liệu, đánh giá mã cân bằng, kiểm thử đơn vị, phân tích mã bao phủ, truy xuất nguồn gốc, và các thực hành xác minh phần mềm khác.
Kiểm thử A/B
Kiểm thử A/B là một phương pháp sử dụng trong quảng cáo được thí nghiệm ngẫu nhiên với hai biến thể A và B, trong đó có sự kiểm soát và điều trị trong các kiểm thử có kiểm soát. Những thí nghiệm này thường được sử dụng trong phát triển web và tiếp thị, cũng như trong nhiều hình thức quảng cáo truyền thống.
Eremurus fuscus
Liên kết ngoài
Thể loại:Eremurus Thể loại:Thực vật được mô tả năm 1952
Kiểm thử phần mềm
Mô hình truyền thống CMMI và mô hình phát triển thác nước
Một thực tế phổ biến trong kiểm thử phần mềm đó là các kiểm thử được thực hiện bởi một nhóm các Tester độc lập sau khi các chức năng được phát triển và trước khi nó được chuyển tới khách hàng. Thực hành này thường là kết quả trong giai đoạn kiểm thử đang được sử dụng như một bộ đệm tham chiếu để bù đắp cho độ trễ tham chiếu do đó ảnh hưởng đến thời gian dành cho việc kiểm thử.
Một thực tế khác là khởi động kiểm thử phần mềm tại cùng một thời điểm bắt đầu dự án và nó là một quá trình liên tục cho đến khi dự án kết thúc.
Mô hình phát triển Agile or Extreme
Ngược lại, một số quy tắc phần mềm đang nổi lên như lập trình cực đoan và sự chuyển động phát triển phần mềm AGILE, tuân thủ mô hình "Test – Driven Development " (TDD). Trong quy trình này, kiểm thử đơn vị được viết đầu tiên do các kỹ sư phần mềm (thường là lập trình song song trong các phương pháp lập trình Extreme). Tất nhiên những kiểm thử bước đầu thất bại như dự kiến, nhưng sau đó Code được viết xong thì phần lớn các Test Suite sẽ từng bước tăng lên. Nó được cập nhật như là các lỗi điều kiện mới và các trường hợp tiềm ẩn vừa được phát hiện ra, chúng được tích hợp với bất kỳ kiểm thử hồi quy nào được phát triển. Kiểm thử đơn vị được duy trì cùng với phần còn lại của các mã nguồn phần mềm và được tích hợp chung vào quá trình xây dựng (với những kiểm thử tương tác vốn đã bị loại bỏ quá trình xây dựng mức chấp nhận thông thường). Mục tiêu cuối cùng của quá trình kiểm thử này là để đạt được việc triển khai liên tục mà ở đó những cập nhật phần mềm có thể được công bố cho công chúng thường xuyên.
Phương pháp này làm tăng các nỗ lực kiểm thử trước khi động đến bất kỳ nhóm kiểm thử chính thức. Trong một số mô hình phát triển khác, hầu hết việc thực hành các kiểm thử xảy ra sau khi các yêu cầu đã được xác định và quá trình mã hóa đã được hoàn thành.
Mô hình từ trên xuống và mô hình từ dưới lên
Kiểm thử từ dưới lên là một cách tiếp cận để kiểm thử tích hợp nơi các thành phần tồn tại ở cấp độ thấp nhất (Các Module, các biện pháp và các chức năng) được kiểm thử đầu tiên, sau đó tích hợp và sử dụng để tạo thuận lợi cho việc kiểm thử các thành phần cấp cao hơn. Sau khi kiểm thử tích hợp các Module ở cấp độ thấp hơn sẽ tiến hành kiểm thử ở các cấp độ tiếp theo. Quá trình này được lặp đi lặp lại cho đến khi các thành phần ở trật tự trên cùng của hệ thống được kiểm tra. Cách tiếp cận này là chỉ hữu ích khi tất cả hoặc hầu hết các Module có cấp độ phát triển tương đương sẵn sàng được kiểm thử. Phương pháp này cũng giúp xác định các cấp độ phát triển phần mềm và làm cho nó dễ dàng hơn để báo cáo tiến độ kiểm thử theo tỷ lệ phần trăm.
Crocomela palmeri
Crocomela palmeri là một loài bướm đêm thuộc phân họ Arctiinae, họ Erebidae.
Kiểm thử phần mềm
Mô hình từ trên xuống và mô hình từ dưới lên
Kiểm thử từ trên xuống là một cách tiếp cận để kiểm thử tích hợp các Module trên đầu với các Module nhánh được kiểm tra từng bước cho đến khi kết thúc Module liên quan.
Crocomela palmeri
Liên kết ngoài
Thể loại:Crocomela
Kiểm thử phần mềm
Mô hình từ trên xuống và mô hình từ dưới lên
trong cả hai phương pháp và các trình điều khiển được sử dụng để cố định các thành phần bị thiếu sót và được hoàn thiện ở các cấp độ thay thế.
Một chu kỳ kiểm thử mẫu
Dẫu cho các biến thể tồn tại giữa các tổ chức lập trình thì vẫn có một quy trình điển hình để kiểm thử. Mẫu dưới đây là phổ biến trong các tổ chức sử dụng mô hình phát triển Waterfall (thác nước). Các hoạt động tương tự thường được tìm thấy trong các mô hình phát triển khác, nhưng có thể có hoặc không rõ ràng.
Kiểm thử đóng gói: Mỗi phép thử thỏa mãn các chỉ tiêu truy xuất và thu được những kết quả quan trong như: bài học kinh nghiệm, kết quả, các bản ghi, tài liệu liên quan được lưu trữ và sử dụng như một tài liệu tham khảo cho các dự án trong tương lai.
Kiểm thử tự động hóa
Nhiều nhóm lập trình càng ngày càng dựa vào các kiểm thử tự động, đặc biệt là các nhóm sử dụng mô hình TDD (Test – Drive – Development). Có rất nhiều framework được viết bên trong và mã trong mỗi phiên bản được chạy kiểm thử tự động mọi lúc khi tích hợp liên tục phần mềm.
Tuy kiểm thử tự động không thể sao chép tất cả mọi thứ như con người có thể làm (và tất cả các cách họ nghĩ để làm việc đó) nhưng nó có thể rất hữu ích cho việc kiểm thử hồi quy. Mặc dù vậy, nó cũng đòi hỏi phải có những kịch bản phát triển tốt để tiến hành kiểm thử.
Các công cụ kiểm thử
Chương trình kiểm thử và phát hiện lỗi có thể được hỗ trợ đáng kể bởi các công cụ kiểm thử và gỡ lỗi. Các công cụ kiểm thử/gỡ lỗi bao gồm các tính năng như:
Một số các tính năng này có thể được kết hợp vào một môi trường phát triển tích hợp (IDE).
Đo lường trong kiểm thử phần mềm
Thông thường, chất lượng bị hạn chế đến các chủ đề như tính chính xác, tính hoàn chỉnh và tính bảo mật nhưng cũng có thể bao gồm các yêu cầu kỹ thuật như được mô tả trong các tiêu chuẩn ISO (ISO / IEC 9126), chẳng hạn như khả năng, độ tin cậy, hiệu quả, tính di động, độ bảo trì, khả năng tương thích và khả năng sử dụng.
Có một số số liệu thường được sử dụng các độ đo phần mềm, hoặc các biện pháp được sử dụng để hỗ trợ trong việc xác định tình trạng của phần mềm hoặc tính đầy đủ của các kiểm thử.
Kiểm thử thành phần lạ
Quá trình kiểm thử phần mềm có thể tạo ra một số thành phần lạ.
Kế hoạch kiểm thử
Một kiểm thử đặc điểm kỹ thuật được gọi là một kế hoạch kiểm thử. Các nhà phát triển nhận thức rõ những gì kế hoạch kiểm thử sẽ được thực hiện và thông tin này được cung cấp cho các nhà quản lý và các nhà phát triển. Ý tưởng là để làm cho họ thận trọng hơn khi phát triển mã của họ hoặc làm thay đổi bổ sung. Một số công ty có một tài liệu cao cấp được gọi là một chiến lược kiểm thử.
Ma trận truy xuất nguồn gốc
Một ma trận truy xuất nguồn gốc là một bảng tương quan yêu cầu hoặc tài liệu thiết kế các tài liệu kiểm thử. Nó được sử dụng để thay đổi các bài kiểm tra khi nguồn tài liệu liên quan được thay đổi, chọn Test Case để thực hiện khi lập kế hoạch để kiểm thử hồi quy bằng cách xem yêu cầu độ bao phủ.
Tình huống kiểm thử (Test Case)
Một Test Case thông thường bao gồm một ký hiệu nhận dạng duy nhất, tài liệu tham khảo yêu cầu từ một thông số thiết kế, điều kiện tiền đề, các sự kiện, một loạt các bước (còn được gọi là hành động) để làm theo, đầu vào, đầu ra, kết quả dự kiến, và kết quả thực tế. Lâm sàng xác định một Test Case là một đầu vào và kết quả kỳ vọng. Hiểu một cách đơn giản thì một Test Case có một dữ liệu đầu vào thì sẽ có một kết quả đầu ra.
Điều này có một thực tế như là "cho điều kiện X nhưng kết quả bắt nguồn lại là của bạn Y", trong khi Test Case khác được mô tả chi tiết hơn về kịch bản đầu vào và những gì có thể kỳ vọng ở kết quả. Nó đôi khi có thể là một loạt các bước (nhưng thường được chứa trong một thủ tục kiểm tra riêng biệt mà có thể được thực hiện đối với nhiều Test Case) tương ứng với một loạt kết quả kỳ vọng.
Kịch bản kiểm thử
Kịch bản kiểm thử là một thủ tục mà các lập trình viên sao chép các thao tác của người dùng. Ban đầu, thuật ngữ này được bắt nguồn từ các sản phẩm của công việc được tạo ra bởi công cụ kiểm thử hồi quy tự động. Test Case sẽ là cơ sở để tạo ra kịch bản kiểm thử sử dụng một công cụ hoặc một chương trình.