Không Gian Web Group

Phát triển phần mềm

"Kiểm thử phần mềm - khái niệm, phân loại và quy trình"

Một hoạt động mang tính sống còn trong các dự án sản xuất hoặc gia công phần mềm (PM), đó là kiểm tra, kiểm thử phần mềm (Testing). Dân làm PM chắc hẳn không ai nghi ngờ vai trò quan trọng của nó, tuy nhiên không phải ai (cả trong ngành và ngoài ngành) cũng hiểu rõ hoạt động này. Bản thân công việc kiểm tra phần mềm (KTPM) cũng là một lĩnh vực hoạt động độc lập và khá “hấp dẫn”. Cùng với các dự án gia công sản xuất PM, hiện cũng có khá nhiều dự án mà nội dung công việc chỉ là kiểm tra những PM đã được khách hàng phát triển sẵn.

Tai lieu hoc kiem thu phan mem

Mặc dù công việc kiểm thử phần mềm không xa lạ song những khái niệm và kỹ thuật lại khá rắc rối. Bài viết này sẽ nhằm cung cấp một cái nhìn tương đối bao quát về lĩnh vực “tưởng cũ nhưng không cũ” này.

ĐỊNH NGHĨA KIỂM THỬ PHẦN MỀM

Thực ra kiểm thử phần mềm là công việc mà bất cứ người nào từng tham gia phát triển phần mềm (PTPM) đều biết và từng làm. Theo nghĩa thông thường nhất, kiểm thử phần mềm bao gồm việc “chạy thử” PM hay một chức năng của PM, xem nó “chạy” đúng như mong muốn hay không. Việc kiểm tra này có thể thực hiện từng chặng, sau mỗi chức năng hoặc module được phát triển, hoặc thực hiện sau cùng, khi PM đã được phát triển hoàn tất. Kiểm thử phần mềm đứng ở vị trí hết sức nhạy cảm, nó là bước đệm giữa giai đoạn xây dựng PM và sử dụng PM, trước khi giao sản phẩm hoàn chỉnh cho khách hàng.

Chi tiết hơn Kiểm thử phần mềm 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ử.[1] 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.

PHƯƠNG PHÁP KIỂM THỬ PHẦN MỀM

Phương pháp tiếp cận test, sử dụng các kỹ thuật BOX

Gồm có:

1. White box testing
2. Black box testing
3. Grey box testing

Các phương pháp test được chia theo cách truyền thống gồm có whitebox testing (kiểm thử hộp trắng) - và blackbox testing (hộp đen). Hai phương pháp tiếp cận này được sử dụng để mô tả điểm nhìn mà kỹ thuật viên test (tester engineer) sử dụng khi thiết kế các test case.

1. White box testing

Khi thiết kế test case và test, các tester truy cập thẳng vào bên trong source code, cấu trúc và thuật toán của chương trình và thực thi nó được gọi là White box testing.

Có các loại white box testing đang tồn tại như sau:

  • * API testing (application programming interface) – Kiểm thử ứng dụng bằng cách sử dụng các hàm API public và private
  • * Code coverage – Là việc tạo các trường hợp test để thỏa mãn một số điều kiện bao phủ code - code coverage (ví dụ như, người thiết kế test có thể tạo ra các trường hợp test sao cho tất cả các câu lệnh của chương trình đều được thực thi ít nhất 1 lần)
  • * Fault injection methods – cải tiến bao phủ một trường hợp bằng cách đưa một số lỗi vào để test các đường dẫn code.
  • * Mutation testing methods
  • * Static testing - White box testing bao gồm tất cả các phương pháp kiểm thử tĩnh (ví dụ review code).

Kiểm thử độ bao phủ
Phương pháp kiểm thử white box cũng có thể được sử dụng để ước lượng tính trọn vẹn đầy đủ của các tập hợp kiểm thử (test suit) đã được tạo ra bằng phương pháp kiểm thử black box. Điều này cho phép nhóm sản xuất phần mềm xem xét lại các phần của hệ thống ít được test nhất và để chắc chắn rằng các chức năng quan trọng nhất đã được tập trung test kỹ.

Hai hình thức chung của kiểm thử độ bao phủ code:

  • * Bao phủ chức năng - Function coverage, dựa trên việc thực thi các chức năng.
  • * Bao phủ câu lệnh - Statement coverage, dựa trên số lượng các dòng lệnh đã được thực thi để hoàn thành kiểm thử.

Cả hai hình thức trên đề trả về một cách đo độ bao phủ code, sự đo lường được tính bằng phần trăm %.

2. Black box testing

Phương pháp kiểm thử Black box là nghiên cứu xem phần mềm như là một “hộp đen” – không biết gì về hoạt động bên trong của nó. Các phương pháp kiểm thử Black box bao gồm: equivalence partitioning (phân vùng tương đương), boundary value analysis (phân tích giá trị biên), all-pairs testing (kiểm thử tất cả các cặp), fuzz testing (cách test: nhập vào các điều kiện sai hoặc data một cách ngẫu nhiên), model-based testing (Kiểm thử dựa trên model), traceability matrix (các chức năng của chương trình được tạo thành một ma trận, các trường hợp test là sự kết hợp các dòng hoặc các cột có liên quan), exploratory testing (kiểm thử chủ yếu dựa vào kinh nghiệm và khả năng focus vào việc test các chức năng của tester) và specification-based testing (kiểm thử dựa vào chức năng).

Phương pháp kiểm thử dựa vào chức năng - Specification-based testing: Việc kiểm thử được tiến hành dựa vào việc kiểm thử chức năng của phần mềm xem nó có phù hợp với yêu cầu của người dùng hay không. Vì vậy, các tester nhập data vào phần mềm và chỉ cần xem kết quả của phần mềm và các mục tiêu test. Mức test này thường yêu cầu các tester phải viết test case đầy đủ trước khi test, khi test, đơn giản chỉ cần thực hiện theo các bước mô tả trong test case thao tác và nhập data vào, sau đó xem kết quả trả về hoặc hành vi của phần mềm, rồi so sánh với kết quả mong đợi đã được viết trong test case, điền kết quả test vào test case là OK (OK = is – chương trình làm đúng theo mong đợi) hay NG (not good = is not – chương trình không làm đúng theo mong đợi).

Specification-based testing là cần thiết, nhưng nó không đủ để bảo đảm chắc chắn các rủi ro xảy ra (nó chỉ là điều điện cần chứ không phải là điều kiện đủ).

Ưu điểm và nhược điểm: Các tester kiểm thử theo phương pháp black box không có “mối ràng buộc” nào với code, và nhận thức của một tester rất đơn giản: một source code có nhiều lỗi. Sử dụng nguyên tắc, "Hỏi và bạn sẽ nhận" các tester black box tìm được nhiều bug ở nơi mà các DEV không tìm thấy. Mặt khác, việc kiểm thử black box được xem như "là bước đi trong mê cung tối đen mà không mang đèn pin” bởi vì tester không biết phần mềm đang test đã được xây dựng như thế nào. Như là một kết quả, ở đây có nhiều trường hợp khi một tester viết rất nhiều trường hợp test để kiểm tra một số thứ có thể chỉ được test bằng một trường hợp test (1), và/hoặc một vài phần cuối cùng không được test hết.

Vì vậy, black box testing có ưu điểm là "an unaffiliated opinion" (một quan điểm độc lập), mặt khác, nó có nhược điểm là "blind exploring" (khám phá mù).

3. Grey box testing

Grey box testing (Viết theo Tiếng Mỹ: gray box testing) bao gồm các kiến thức về các thuật toán, cấu trúc bên trong của chương trình để thực hiện mục đích việc thiết kế các trường hợp test, nhưng việc test phải thực hiện như là người dùng (suy nghĩ theo cách nghĩ của người dùng cuối), hoặc thiết kế ở mức black-box. Việc vận dụng dữ liệu đầu vào và xác định qui cách đầu ra không được gọi là grey box, bởi vì điều kiện input và output là ở bên ngoài rõ ràng là của "black-box" trên hệ thống chúng ta đang test. Sự phân biệt này đặc biệt quan trọng khi tiến hành thử nghiệm tích hợp giữa hai module đã được viết bởi hai DEV khác nhau, ở đó chỉ có các interface (giao tiếp giữa 2 module) được đưa ra để kiểm thử. Tuy nhiên, việc chỉnh sửa ngân hàng data test không được xem là grey box, như người dùng bình thường thì sẽ không thể thay đổi data bên ngoài hệ thống đang test. Grey box testing cũng có thể bao gồm kỹ thuật đảo ngược để xác định, ví dụ, các giá trị biên hoặc thông báo lỗi.

Ghi chú:

- Trường hợp kiểm thử = test case
- Các trường hợp kiểm thử = test cases

CÁC MỨC ĐỘ KIỂM THỬ PHẦN MỀM

Thực tế, KTPM không đơn giản như nhiều người thường nghĩ, công việc này có nhiều mức độ khác nhau và có mối tương quan với các chặng phát triển trong dự án PTPM. Hình 1 cho thấy 4 mức độ cơ bản của KTPM và hình 2 cho thấy mối tương quan với các chặng PTPM trong mô hình V-model.

Phần sau sẽ làm rõ chi tiết về các mức độ KTPM, do một số thuật ngữ không có từ tương đương sát nghĩa trong tiếng Việt, mặt khác để các bạn tiện tham khảo sau này, chúng tôi xin giữ nguyên một số thuật ngữ gốc tiếng Anh.

1. Unit Test – Kiểm tra mức đơn vị

Để có thể hiểu rõ về Unit Test, khái niệm trước tiên ta cần làm rõ: thế nào là một đơn vị PM (Unit)?

Một Unit là một thành phần PM nhỏ nhất mà ta có thể kiểm tra được. Theo định nghĩa này, các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method) đều có thể được xem là Unit.

Vì Unit được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn giản, chúng ta không khó khăn gì trong việc tổ chức, kiểm tra, ghi nhận và phân tích kết quả kiểm tra. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể Unit đang kiểm tra. Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit Test sẽ được đền bù bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm tra và sửa lỗi ở các mức kiểm tra sau đó.

Unit Test thường do lập trình viên thực hiện. Công đoạn này cần được thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ PTPM. Thông thường, Unit Test đòi hỏi kiểm tra viên có kiến thức về thiết kế và code của chương trình. Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của Unit. Điều này thường đòi hỏi tất cả các nhánh bên trong Unit đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các lệnh được thực thi trong một Unit, ví dụ: chuỗi các lệnh sau điều kiện If và nằm giữa then … else là một nhánh. Thực tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm tra và quét hết Unit đòi hỏi phải có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa.

Cũng như các mức kiểm tra khác, Unit Test cũng đòi hỏi phải chuẩn bị trước các tình huống (test case) hoặc kịch bản (script), trong đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong chờ sẽ xuất ra. Các test case và script này nên được giữ lại để tái sử dụng.

2. Integration Test – Kiểm tra tích hợp

Integration test kết hợp các thành phần của một ứng dụng và kiểm tra như một ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.

Integration Test có 2 mục tiêu chính:

  • Phát hiện lỗi giao tiếp xảy ra giữa các Unit.
  • Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm tra ở mức hệ thống (System Test).

Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu trúc nội tại của Unit. Có một số phép kiểm tra đơn giản trên giao tiếp giữa Unit với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit thật sự được kiểm tra đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện Integration Test.

Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã được kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được sửa chữa. Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao tiếp giả lập thì không cần phải thực hiện Integration Test nữa. Thực tế việc tích hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác.

Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit. Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp trước đó và đã hoàn tất (passed) các đợt Integration Test trước đó. Lúc này, ta chỉ cần kiểm tra giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này làm cho số lượng kiểm tra sẽ giảm đi rất nhiều, sai sót sẽ giảm đáng kể.

Có 4 loại kiểm tra trong Integration Test:

 

  • Kiểm tra cấu trúc (structure): Tương tự White Box Test (kiểm tra nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng), chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình chẳng hạn các lệnh và nhánh bên trong.
  • Kiểm tra chức năng (functional): Tương tự Black Box Test (kiểm tra chỉ chú trọng đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong), chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật.
  • Kiểm tra hiệu năng (performance): Kiểm tra việc vận hành của hệ thống.
  • Kiểm tra khả năng chịu tải (stress): Kiểm tra các giới hạn của hệ thống.

3. System Test - Kiểm tra mức hệ thống

Mục đích System Test là kiểm tra thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không.

System Test bắt đầu khi tất cả các bộ phận của PM đã được tích hợp thành công. Thông thường loại kiểm tra này tốn rất nhiều công sức và thời gian. Trong nhiều trường hợp, việc kiểm tra đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ hệ thống, người kiểm tra cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống.

Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau. Thông thường ta phải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test.

Sau khi hoàn thành Integration Test, một hệ thống PM đã được hình thành cùng với các thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trình viên hoặc kiểm tra viên (tester) bắt đầu kiểm tra PM như một hệ thống hoàn chỉnh. Việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu. Phần sau ta sẽ nói rõ hơn về một quy trình System Test cơ bản và điển hình.

System Test kiểm tra cả các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật. Mức kiểm tra này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với PM hoặc phần cứng bên ngoài, chẳng hạn các lỗi “tắc nghẽn” (deadlock) hoặc chiếm dụng bộ nhớ. Sau giai đoạn System Test, PM thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm tra để chấp nhận (Acceptance Test) hoặc dùng thử (Alpha/Beta Test).

Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test thường được thực hiện bởi một nhóm kiểm tra viên hoàn toàn độc lập với nhóm phát triển dự án.

Bản thân System Test lại gồm nhiều loại kiểm tra khác nhau (xem hình 3), phổ biến nhất gồm:

  • Kiểm tra chức năng (Functional Test): bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế.
  • Kiểm tra khả năng vận hành (Performance Test): bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn
  • Kiểm tra khả năng chịu tải (Stress Test hay Load Test): bảo đảm hệ thống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc). Stress Test tập trung vào các trạng thái tới hạn, các “điểm chết”, các tình huống bất thường…
  • Kiểm tra cấu hình (Configuration Test)
  • Kiểm tra khả năng bảo mật (Security Test): bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống.
  • Kiểm tra khả năng phục hồi (Recovery Test): bảo đảm hệ thống có khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến.

Nhìn từ quan điểm người dùng, các kiểm tra trên rất quan trọng: bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực.

Lưu ý không nhất thiết phải thực hiện tất cả các loại kiểm tra nêu trên. Tùy yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập kế hoạch, trưởng dự án sẽ quyết định áp dụng những loại kiểm tra nào.

Phat trien pham mem va kiem thu phan mem

Hình 2: Mối tương quan giữa phát triển và kiểm tra phần mềm

4. Acceptance Test - Kiểm tra chấp nhận sản phẩm

Thông thường, sau giai đoạn System Test là Acceptance Test, được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của Acceptance Test là để chứng minh PM thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng).

Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các phép kiểm tra của System Test và Accepatnce Test gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt.

Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người sử dụng, thông thường sẽ thông qua hai loại kiểm tra gọi là Alpha Test và Beta Test. Với Alpha Test, người sử dụng (tiềm năng) kiểm tra PM ngay tại nơi PTPM, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa. Với Beta Test, PM sẽ được gửi tới cho người sử dụng (tiềm năng) để kiểm tra ngay trong môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa chữa.

Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình PTPM thì kết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù PM đã trải qua tất cả các kiểm tra trước đó. Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong chờ của khách hàng. Ví dụ đôi khi một PM xuất sắc vượt qua các phép kiểm tra về chức năng thực hiện bởi nhóm thực hiện dự án, nhưng khách hàng khi kiểm tra sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn, thao tác không tự nhiên, không theo tập quán sử dụng của khách hàng v.v…

Gắn liền với giai đoạn Acceptance Test thường là một nhóm những dịch vụ và tài liệu đi kèm, phổ biến như hướng dẫn cài đặt, sử dụng v.v… Tất cả tài liệu đi kèm phải được cập nhật và kiểm tra chặt chẽ.

cac loai kiem tra systemtest
Hình 3: Các loại kiểm tra khác nhau trong System Test

5. Regression Test - Kiểm tra hồi quy

Trước tiên cần khẳng định Regression Test không phải là một mức kiểm tra, như các mức khác đã nói ở trên. Nó đơn thuần kiểm tra lại PM sau khi có một sự thay đổi xảy ra, để bảo đảm phiên bản PM mới thực hiện tốt các chức năng như phiên bản cũ và sự thay đổi không gây ra lỗi mới trên những chức năng vốn đã làm việc tốt. Regression test có thể thực hiện tại mọi mức kiểm tra.

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!

TÓM TẮT LẠI

Trên đây là tổng quan về các mức và loại kiểm thử phần mềm cơ bản. Thực tế nếu đi sâu vào từng mức và loại kiểm tra, còn có rất nhiều kiểm tra đặc thù khác nữa, mang tính chuyên biệt cho từng vấn đề hoặc từng loại ứng dụng. Tuy nhiên, những mức độ và loại kiểm tra nêu trên là cơ bản nhất và có thể áp dụng trong hầu hết các loại ứng dụng PM khác nhau. Hi vọng có thể mang lại cho các bạn những hiểu biết cơ bản nhất về lĩnh vực kiểm thử phần mềm.

 

(Bài viết tham khảo nguồn từ diễn đàn PCWorld, wiki và một số nguồn khác)

Add comment

Vui lòng bình luận có tính xây dựng, có thể chém nhưng không nói tục, chửi bậy, vi phạm pháp luật Việt Nam.

Security code
Refresh

kiotviet copy

SỬA FILE VIDEO MP4 LỖI VỚI GIẢI PHÁP DUY NHẤT

sua file video mp4Bạn đã từng sử dụng điện thoại để quay 1 video rất quan trọng hoặc rất có ý nghĩa, nhưng trong quá trình quay video thì điện thoại hết pin, sập nguồn hoặc bị đơ khiến file video bị hỏng không mở được. Mình đã từng sử dụng rất nhiều phần mềm sửa file video từ chuyên nghiệp đến nghiệp dư, từ free đến mất phí nhưng đều không sửa được. Cuối cùng mình đã tìm được 1 giải pháp hoàn hảo và duy nhất trên thế giới (theo hiểu biết cá nhân) để sửa được file video mp4 bị lỗi. Và tất nhiên là mất phí. Nếu bạn gặp phải trường hợp như vậy hãy liên hệ ngay với mình để lấy lại file video quý giá với chi phí cực thấp. <<Chi tiết>>

Không gian web group - thiết kế website, tư vấn thiết kế web

Không gian web group - thiết kế website, tư vấn thiết kế web, nâng cấp bảo trì web. Đối tượng khách hàng chính mà Không gian web group hướng tới chính là các doanh nghiệp mới - cần một công cụ hữu hiệu để quảng bá hình ảnh của mình. Không gian web group sẽ đáp ứng đầy đủ các yêu cầu chi tiết theo ý khách hàng để tạo cho doanh nghiệp một không gian hình ảnh và thông tin đảm bảo tính thẩm mỹ, riêng biệt và duy nhất.
Website đơn giản, hiệu quả là thành công tương lai của bạn.
Liên hệ: lienhe24@gmail.com  Hotline: 0126.4758686Skype: lienhe24  Website: khonggianweb.com 

Khách trực tuyến

We have 40 guests and no members online