logo
Chào mừng Khách! Để kích hoạt tất cả tính năng xin vui lòng Đăng nhập Hoặc Đăng ký.

Thông báo

Icon
Error

Tùy chọn
Xem bài viết cuối Đến bài chưa đọc đầu tiên
Offline thaihihi002  
#1 Đã gửi : 05/10/2018 lúc 03:13:23(UTC)
thaihihi002

Danh hiệu: Newbie

Nhóm: Registered
Gia nhập: 09-07-2018(UTC)
Bài viết: 0
Viet Nam
Đến từ: hà nội

Kiểm thử phần mềm bao gồm việc kiểm chứng động (dynamic), đó là một chương trình cung cấp các hành vi dự kiến trên một tập hữu hạn các trường hợp thử nghiệm, phù 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 đề quan trọng trong việc mô tả các kiến 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 chính xác, giá trị đầu vào đơn (alone) không phải lúc nào cũng đủ để xác định 1 bài test, vì một hệ thống không xác định phức tạp 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 trạng thái hệ thống. Tuy nhiên 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 trạng thái đầu vào quy định trong những trường hợp quan trọng. Các kỹ thuật tĩnh khác nhau và bổ trợ cho kiểm thử động. Các kỹ thuật tĩnh được bao gồm trong Software Quality KA. Điều đáng chú ý là thuật ngữ không thống nhất giữa các cộng đồng khác nhau và 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 hình 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ử chi tiết mà chủ yếu kiểm tra tính đúng đắn của code (mã lệnh), thuật toán hay tài liệu. Chủ yếu là kiểm tra cú pháp của code và/hoặc review code (là kiểm tra xem code có được viết theo đúng tiêu chuẩn code – ví dụ cách đặt tên hàm tên biến, cách sử dụng hàm chung,... đã đưa ra hay chưa) hoặc tài liệu để 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 tra và walkthroughs cũng được sử dụng trong kiểm thử tĩnh này. Từ góc nhìn theo quan điểm của kiểm thử hộp đen, kiểm thử tĩnh liên quan đến việc xem xét các yêu cầu và các tài liệu thiết kế chi tiết (ví dụ Spec, SRS, BSS). Điều này được thực hiện với một tầm nhìn hướng tới đầy đủ hay phù hợp cho các nhiệm vụ. Lỗi được phát hiện ở giai đoạn phát triển này là ít tốn kém để sửa chữa hơn so với bug phát hiện được ở các giai đoạn sau này trong các quy trình phát triển phần mềm.
Finite:
Ngay cả trong các chương trình đơn giản, rất nhiều trường hợp kiểm thử về mặt lý thuyết đòi hỏi kiểm tra toàn diện có thể yêu cầu nhiều tháng hoặc nhiều năm để thực hiện. Đó là lý do tại sao trong thực tế, một tập đẩy đủ các kiểm thử có thể được coi là vô hạn, và sự kiểm thử được tiến hành trên một tập tất cả các bài kiểm thử khả thi, có thể được xác định theo các tiêu chí rủi ro và ưu tiên. Kiểm thử luôn bao hàm sự cân bằng giữa các tài nguyên hạn chế và tiến độ.
Selected:
Có nhiều kỹ thuật kiểm thử khác nhau được đề xuất trong một tập kiểm thử được chọn, và các kỹ sư phần mềm phải được nhận thức rằng các tiêu chí lựa chọn khác nhau có thể mang lại sự khác nhau về tính hiệu quả. Nhưng làm thế nào để xác định các tiêu chí lựa chọn phù hợp nhất trong điều kiện nhất định là 1 vấn đề phức tạp.
Expected:
Phải có khả năng, mặc dù không phải lúc nào cũng dễ dàng, để quyết định xem các kết quả quan sát của chương trình thử nghiệm được chấp nhận hay không; nếu không, các nỗ lực thử nghiệm là vô ích. Các hành vi quan sát có thể được so sánh với nhu cầu của người sử dụng (thường được gọi là thử nghiệm để xác nhận), chống lại một đặc điểm kỹ thuật (thử nghiệm để xác minh), hoặc, có lẽ, đối với các hành vi được mong đợi từ các yêu cầu bao hàm hoặc mong đợi (xem thử nghiệm Chấp nhận 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 coi là một hoạt động mà chỉ bắt đầu sau khi giai đoạn coding được hoàn thành với mục đích hạn chế của việc phát hiện lỗi. Kiểm thử phần mềm trở nên phổ biến trong suốt quá trình phát triển và bảo trì. Kế hoạch kiểm thử phần mềm nên bắt đầu với giai đoạn đầu của quy trình yêu cầu phần mềm, các kế hoạch và quy trình thử nghiệm phải được phát triển một cách có hệ thống và liên tục - và có thể tinh chế - như tiến hành phát triển phần mềm. Những hoạt động lập kế hoạch kiểm thử và thử nghiệm thiết kế cung cấp các đầu vào hữu ích cho các nhà thiết kế phần mềm và giúp họ làm nổi bật những khuyết điểm, thiết sót.
Đối với nhiều tổ chức, phương pháp 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 nhìn thấy, sau đó, được dùng như một phương tiện để cung cấp thông tin về các tính năng và chất lượng các thuộc tính của phần mềm và cũng để xác định lỗi trong những trường hợp ngăn chặn lỗi không có hiệu quả. Sự thật hiển nhiên là phần mềm có thể chứa lỗi, thậm chí sau khi hoàn thành việc kiểm thử bao quát. Các lỗi phần mềm có sau đó sẽ được giải quyết bằng bảo trì sửa chữa. Mục bảo trì phần mềm có trong phần Software Mainteance KA (chương 5).
Trong Kỹ thuật quản lý chất lượng phần mềm, được phân loại thành 2 kỹ thuật đáng chú ý là Tĩnh (không thực thi mã) và động (thực thi mã). KA này tập trung và 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.
Mục tiêu và mục đích chính của kiểm thử phần mềm ?
Tùy vào những đối tượng khác nhau mà kiểm thử phần mềm có những mục tiêu khác nhau. Tuy nhiên, nhìn tổng thể thì mục tiêu chung của nó bao gồm :
Tìm tất cả cá lỗi và khuyết điểm phát sinh bởi các lập trình viên trong quá trình phát triển phần mềm.
Đảm bảo sản phẩm cuối cùng đến tay khách hằng hoàn chỉnh, không lỗi, đáp ứng đúng nhu cầu của khách hàng.
Vì sao kiểm thử lại quan trọng?
Phần mềm, ứng dụng đều là sản phẩm của trí tuệ nhân tạo, chính con người tạo ra chúng. Để có một sản phẩm như vậy, không thể nào không phát sinh lỗi. Điều quan trọng là chúng ta cần phải phát hiện ra những lỗ hổng, khuyết điểm ấy để kịp thời sửa chữa. Đôi khi chính những người trong cuộc, những lập trình viên không thể tìm ra lỗi của chính họ. Bởi tìm ra lỗi của bản thân là không hề đơn giản. Vì thế, cần có một đội ngũ kiểm thử, test lại sản phẩm một cách khách quan, ở một góc nhìn mới để hoàn thiện sản phẩm.
Test phần mềm sẽ giúp hoàn thiện các ứng dụng phần mềm hoặc sản phẩm so với yêu cầu kinh doanh và người sử dụng. Nó là rất quan trọng để có thể đảm bảo để thử nghiệm các ứng dụng phần mềm hoàn toàn và làm cho nó chắc chắn rằng nó hoạt động tốt và theo các thông số kỹ thuật
Bạn có định hướng nghề nghiệp trong ngành công nghệ thông tin này chưa? Nếu chưa, hãy nghiêm túc nghiên cứu và xem nghề Tester này nhé. Như đã trình bày phần trên, nguồn nhân lực ngành này đang khan hiếm, cơ hội việc làm sẽ nhiều hơn. Hi vọng bài viết về diện mạo ngành kiểm thử phần mềm sẽ hữu ích cho bạn.
Ai đang xem chủ đề này?
Di chuyển  
Bạn không thể tạo chủ đề mới trong diễn đàn này.
Bạn không thể trả lời chủ đề trong diễn đàn này.
Bạn không thể xóa bài của bạn trong diễn đàn này.
Bạn không thể sửa bài của bạn trong diễn đàn này.
Bạn không thể tạo bình chọn trong diễn đàn này.
Bạn không thể bỏ phiếu bình chọn trong diễn đàn này.

Vận hành bởi YAF.NET 2.2.2 | YAF.NET © 2003-2018, Yet Another Forum.NET
Thời gian xử lý trang này hết 0.100 giây.