Phần mềm máy tính (Computer Software) hay gọi tắt là Phần mềm (Software) là một tập hợp những câu lệnh hoặc chỉ thị (Instruction) được viết bằng một hoặc nhiều ngôn ngữ lập trình theo một trật tự xác định, và các dữ liệu hay tài liệu liên quan nhằm tự động thực hiện một số nhiệm vụ hay chức năng hoặc giải quyết một vấn đề cụ thể nào đó. Show
Phần mềm thực hiện các chức năng của nó bằng cách gửi các chỉ thị trực tiếp đến phần cứng (hay phần cứng máy tính, Computer Hardware) hoặc bằng cách cung cấp dữ liệu để phục vụ các chương trình hay phần mềm khác. 1.1.2. Phân loại các loại phần mềm
1.2. Quy trình phát triển phần mềmCũng như các ngành sản xuất khác, quy trình là một trong những yếu tố đầu tiên và cực kỳ quan trọng đem lại thành công cho các nhà phát triển phần mềm, nó giúp cho mọi thành viên trong dự án từ người cũ đến người mới, trong hay ngoài công ty đều có thể xử lý đồng bộ công việc tương ứng với trị trí của mình thông qua cách thức chung của công ty. Quy trình phát triển phần mềm có tính chất quyết định để tạo ra 1 sản phẩm có chi phí thấp và năng suất cao. Quy trình phát triển phần mềm là một cấu trúc bao gồm tập hợp các thao tác và các kết quả tương quan sử dụng trong việc phát triển để sản xuất ra một sản phẩm phần mềm. Một quy trình phát triển phần mềm bao gồm các giai đoạn như sau:
1.3. Một số mô hình phát triển phần mềm phổ biến hiện nay1.3.1. Mô hình thác nước (Waterfall model)Hình 1.1: Mô hình thác nước -Mô tả:
-Các giai đoạn xử lý của mô hình thác nước:
-Ứng dụng vào các dự án phần mềm sau:
-Ưu điểm:
-Nhược điểm:
1.3.2. Mô hình chữ V (V model)Hình 1.2: Mô hình chữ V -Mô tả:
-Giai đoạn phát triển:
-Giai đoạn triển khai:
-Ứng dụng vào các dự án phần mềm sau:
-Ưu điểm:
-Nhược điểm:
1.3.3. Mô hình AgileAgile là một phương pháp phát triển phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt và được xem như là sự cải tiến so với những mô hình cũ như mô hình “Thác nước (waterfall)” hay “CMMI”. Phương thức phát triển phần mềm Agile là một tập hợp các phương thức phát triển lặp và tăng dần trong đó các yêu cầu và giải pháp được phát triển thông qua sự liên kết cộng tác giữa các nhóm tự quản và liên chức năng. Hình 1.3: Mô hình Agile -Mô tả:
-Ứng dụng vào các dự án phần mềm sau:
-Ưu điểm:
-Nhược điểm: Mô hình Agile được sử dụng rộng rãi trên thế giới nhưng cũng không đồng nghĩa với phù hợp với tất cả các dự án phần mềm.
1.3.4. Mô hình ScrumHình 1.4: Mô hình Scrum -Mô tả:
-Các nhân tố tạo nên quy trình Scrum: -Có ba nhân tố quan trọng cấu thành nên Scrum:
-Tổ chức dự án:
-Ưu điểm:
-Nhược điểm:
1.4. Lỗi phần mềm1.4.1. Khái niệm lỗi phần mềmMột lỗi phần mềm là một lỗi, lỗ hổng, thất bại, hoặc có lỗi trong một chương trình máy tính hoặc hệ thống đó là nguyên nhân nó tạo ra kết quả không chính xác hoặc không mong muốn, hoặc vận hành theo cách không được định hướng trước. 1.4.2. Những thuật ngữ mô tả về lỗi phần mềmCó nhiều thuật ngữ khác nhau để mô tả lỗi phụ thuộc vào tình trạng của lỗi. Dưới đây là một số thuật ngữ:
“Fault”, “failure” và “defect” có xu hướng ám chỉ một vấn đề thật sự quan trọng, thậm chí là nguy hiểm. “Anomaly”, “incident”, “variance” thường được sử dụng để đề cập tới sự vận hành không được dự tính trước thay vì hoàn toàn là lỗi (all-out failure). “Problem”, “error” và “bug” là những thuật ngữ chung nhất thường được sử dụng, dùng để chỉ sai sót của lập trình viên trong quá trình tạo ra sản phẩm. 1.4.3. Quy tắc xác định lỗi phần mềmMột lỗi phần mềm xuất hiện khi vi phạm ít nhất 1 trong 5 quy tắc dưới đây:
1.4.4. Vòng đời lỗiVòng đời của lỗi là một hành trình mà mà lỗi đi qua trong suốt cuộc đời của nó. Nó thay đổi từ tổ chức này sang tổ chức khác, từ dự án này đến dự án khác và nó được điều chỉnh bởi quy trình kiểm thử phần mềm. Hình 1.5: Vòng đời của lỗi -Vòng đời của lỗi bao gồm các trạng thái dưới đây:
1.5. Kiểm thử phần mềm1.5.1. Kiểm thử phần mềm (Software Testing)Kiểm thử phần mềm là quá trình thực thi 1 chương trình với mục đích tìm ra lỗi. Kiểm thử phần mềm đảm bảo sản phẩm phần mềm đáp ứng chính xác, đầy đủ và đúng theo yêu cầu của khách hàng, yêu cầu của sản phẩm đề đã đặt ra. Kiểm thử phần mềm cũng cung cấp mục tiêu, cái nhìn độc lập về phần mềm, điều này cho phép việc đánh giá và hiểu rõ các rủi ro khi thực thi phần mềm. Kiểm thử phần mềm tạo điều kiện cho bạn tận dụng tối đa tư duy đánh giá và sáng tạo để bạn có thể phát hiện ra những điểm mà người khác chưa nhìn thấy. 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ì việ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. Vai trò của kiểm thử phần mềm: Kiểm thử phần mềm đóng vai trò quan trọng trong việc đánh giá và thu được chất lượng cao của sản phẩm phần mềm trong quá trình phát triển. Thông qua chu trình “ kiểm thử – tìm lỗi – sửa lỗi”, ta hy vọng chất lượng của sản phẩm phần mềm sẽ được cải tiến. Mặt khác, thông qua việc tiến hành kiểm thử mức hệ thống trước khi cho lưu hành sản phẩm, ta biết được sản phẩm của ta tốt ở mức nào. Vì thế, nhiều tác giả đã mô tả việc kiểm thử phần mềm là một quy trình kiểm chứng để đánh giá và tăng cường chất lượng của sản phẩm phần mềm.[1] 1.5.2. Các nguyên tắc cơ bản của kiểm thử phần mềm
Kiểm thử có thể cho thấy rằng phần mềm đang có lỗi, nhưng không thể chứng minh rằng một phần mềm không có lỗi. Kiểm thử làm giảm xác suất lỗi tiềm ẩn trong phần mềm, ngay cả khi đã kiểm thử nghiêm ngặt phần mềm vẫn có thể còn lỗi. Vì vậy, cần phải tìm được càng nhiều lỗi càng tốt.
Kiểm thử với tất cả các kết hợp đầu vào và đầu ra, với tất cả các kịch bản là không thể trừ khi kiểm thử chỉ bao gồm một số ít trường hợp thì có thể kiểm thử toàn bộ. Thay vì kiểm thử toàn bộ, việc phân tích rủi ro và dựa trên sự mức độ ưu tiên người kiểm thử có thể tập trung việc kiểm thử vào một số điểm cần thiết, có nguy cơ lỗi cao hơn. Nghĩa là phải lên kế hoạch kiểm thử, thiết kế trường hợp kiểm thử sao cho có độ bao phủ nhiều nhất và giảm thiểu rủi ro sót lỗi khi đến tay người dùng.
Để tìm được lỗi sớm, các hoạt động kiểm thử nên được bắt đầu càng sớm càng tốt trong quy trình phát triển (vòng đời phát triển) phần mềm hoặc hệ thống, và nên tập trung vào các hoạt động/mục tiêu đã xác định trước. Các hoạt động kiểm thử được bắt đầu càng sớm thì sẽ phát hiện ra lỗi sớm khi đó ít tốn công để tìm lỗi và sửa chữa.
Thông thường, lỗi tập trung vào những module, thành phần chức năng chính của hệ thống. Nếu xác định được điều này bạn sẽ tập trung vào tìm kiếm lỗi quanh khu vực được xác định. Nó được coi là một trong những cách hiệu quả nhất để thực hiện kiểm tra hiệu quả.
Nếu bạn sử dụng cùng một tập hợp các trường hợp kiểm thử liên tục, sau đó một thời gian các trường hợp kiểm thử không tìm thấy lỗi nào mới. Hiệu quả của các trường hợp kiểm thử bắt đầu giảm xuống sau một số lần thực hiện, vì vậy luôn luôn chúng ta phải luôn xem xét và sửa đổi các trường hợp kiểm thử trên một khoảng thời gian thường xuyên.
Theo nguyên tắc này thì việc kiểm thử phụ thuộc vào ngữ cảnh và chúng ta phải tiếp cận kiểm thử theo nhiều ngữ cảnh khác nhau Nếu bạn đang kiểm thử ứng dụng web và ứng dụng di động bằng cách sử dụng chiến lược kiểm thử giống nhau, thì đó là sai. Chiến lược để kiểm thử ứng dụng web sẽ khác với kiểm thử ứng dụng cho thiết bị di động của Android.
Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm đã sẵn sàng để tung ra thị trường. Việc không tìm thấy lỗi cũng có thể là do bộ trường hợp kiểm thử được tạo ra chỉ nhằm kiểm tra những tính năng được làm đúng theo yêu cầu thay vì nhằm tìm kiếm lỗi mới. 1.5.3. Quy trình kiểm thử phần mềmQuy trình kiểm thử phần mềm gồm có 5 bước: Hình 1.6: Các bước trong một quy trình kiểm thử phần mềm
Nhằm chỉ định và mô tả các loại kiểm thử sẽ được triển khai và thực hiện. Kết quả là bản kế hoạch kiểm thử phần mềm bao gồm chi tiết từ các loại kiểm thử, chiến lược kiểm thử, cho đến thời gian và phân định lực lượng kiểm thử viên. Hình 1.7: Các bước lập kế hoạch kiểm thử -Các bước lập kế hoạch kiểm thử:
Nhằm chỉ định các test case và các bước kiểm tra chi tiết cho mỗi phần mềm. Giai đoạn thiết kế test case là hết sức quan trọng, nó đảm bảo các tình huống kiểm thử bao phủ tất cả các yêu cầu. Hình 1.8: Các bước thiết kế kiểm thử
Bước này thường không bắt buộc trong các loại và mức kiểm thử, chỉ yêu cầu trong những trường hợp đặc thù cần thiết kế, tạo ra các test script có khả năng chạy trên máy tính giúp tự động hóa việc thực thi các bước kiểm tra đã định nghĩa ở các bước thiết kế kiểm thử.
Mục đích thực hiện kiểm tra các bước đã thiết kế và ghi nhận kết quả. Hình 1.9: Các bước thực hiện kiểm thử
Bao gồm xem xét và đánh giá kết quả kiểm thử lỗi, chỉ định các yêu cầu thay đổi và tính toán số liệu liên quan đến quá trình kiểm thử (chẳng hạn số giờ, thời gian kiểm tra, số lượng lỗi…) Các bước đánh giá quá trình kiểm thử:
1.5.4. Phân loại kiểm thửCó 2 phương pháp kiểm thử chính là: Static testing (Kiểm thử tĩnh) và Dynamic testing (Kiểm thử động).
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ự. 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 kiểm tra cú pháp của code/ hoặc review code (kiểm tra xem code có được viết đúng tiêu chuẩn code. Đâ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à walkthoughs cũng được sử dụng trong test tĩnh này. 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. Kiểm thử tĩnh cũng có thể được tự động hóa. Nó sẽ thực hiện kiểm tra toàn bộ bao gồm các chương trình được phân tích bởi một trình thông dịch hoặc biên dịch mà xác nhận tính hợp lệ về cú pháp của chương trình. Các kỹ thuật kiểm thử tĩnh giúp nâng cao chất lượng phần mềm bằng cách hỗ trợ các nhà phát triển nhận ra và sửa chữa các sai sót của họ trong quá trình phát triển phần mềm.
Kiểm thử tự động là việc sử dụng phần mềm đặc biệt (tách biệt với phần mềm đang được kiểm thử) để kiểm soát việc thực hiện các bài kiểm tra và so sánh kết quả thực tế với kết quả dự đoán. Kiểm thử tự động có thể tự động hóa một số nhiệm vụ lặp đi lặp lại nhưng cần thiết trong một quá trình kiểm thử đã được chính thức hóa, hay là các kiểm thử bổ sung nhưng sẽ khó thực hiện thủ công. Kiểm thử động kiểm tra cách thức hoạt động của mã lệnh, tức là kiểm tra sự phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian. Trong kiểm thử động, phần mềm phải thực sự được biên dịch và chạy. Kiểm thử động thực sự bao gồm: làm việc với phần mềm, nhập các giá trị đầu vào và kiểm tra xem liệu đầu ra có như mong muốn hay không. Các phương pháp kiểm thử động gồm có: Unit test (Kiểm thử đơn vị), Intergration Tests (Kiểm thử tích hợp), System Tests (Kiểm thử hệ thống) và Acceptance Tests (Kiểm thử chấp nhận). 1.5.5. Các cấp độ kiểm thử phần mềmKiểm thử phần mềm gồm có 4 cấp độ: Unit test (Kiểm thử đơn vị), Intergration Tests (Kiểm thử tích hợp), System Tests (Kiểm thử hệ thống) và Acceptance Tests (Kiểm thử chấp nhận). Tùy theo yêu cầu và đặc trưng của từng hệ thống, khả năng và thời gian cho phép của dự án, khi lập kế hoạch, người quản lý dự án sẽ quyết định những loại kiểm thử được sử dụng. Hình 1.10: Các cấp độ kiểm thử phần mềm
Unit (Đơn vị) là một thành phần phần mềm nhỏ nhất có thể kiểm thử được. Các hàm (Function), thủ tục (Procedure), lớp (Class) hay phương thức (Method) đều có thể được xem là Unit. 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, vì vậy thường không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận và phân tích kết quả kiểm thử. 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 vị đ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 thử và sửa lỗi ở các mức kiểm thử 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ỳ phát triển phần mềm. Thông thường, Unit Test đòi hỏi kiểm thử viên có kiến thức về thiết kế và code của chương trình. Mục đích của kiểm thử đơn vị 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 đơn vị. Đ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. Thực tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm thử và bao phủ 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 với các mục kiểm thử khác, unit test cũng đòi hỏi phải chuẩn bị trước test case (ca kiểm thử) hoặc test script (kịch bản kiểm thử), trong đó chỉ định rõ dữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn. Các test case và test script này nên được giữ lại để tái sử dụng.
Intergration test là kết hợp các thành phần của một ứng dụng và kiểm thử như một ứng dụng đã hoàn thiện. Trong khi unit test kiểm tra các thành phần và đơn vị riêng lẻ thì intergration test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng. Hai mục tiêu chính của intergration 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 thử đơ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 chỉ 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 kiểm thử tích hợp. 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.
System test là một phương pháp theo dõi và đánh giá hành vi của sản phẩm hoặc hệ thống phần mềm hoàn chỉnh và đã được tích hợp đầy đủ, dựa vào đặc tả và các yêu cầu chức năng đã được xác định trước. System test bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp thành công. Thông thường loại kiểm thử 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 thử đò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, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ hệ thống, người kiểm thử 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 intergration 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 intergration test chú trọng sự giao tiếp giữa các unit hoặc đối tượng khi chúng làm việc cùng nhau. Thông thường, unit test và intergration test cần phải thực hiện trước để 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 intergration test, một hệ thống phần mềm đã đượ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 thử viên bắt đầu kiểm thử phần mềm như một hệ thống hoàn chỉnh. Việc lên 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. System test thực hiện kiểm thử 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 thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi “tắc nghẽn” hoặc chiếm dụng bộ nhớ. Sau giai đoạn system test, phần mềm thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm thử chấp nhận sản phẩm hoặc dùng thử sản phẩm. System 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 thử viên hoàn toàn độc lập với nhóm phát triển dự án. Trong system test lại bao gồm nhiều loại kiểm thử khác nhau, một số loại phổ biến nhất gồ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 phần mềm 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. 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 phát triển phần mềm thì kết quả kiểm thử chấp nhận sản phẩm sẽ sai lệch rất lớn, mặc dù phần mềm đã trải qua tất cả các kiểm thử 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. 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… Tất cả tài liệu đi kèm phải được cập nhật và kiểm thử chặt chẽ. 1.5.6. Thiết kế Test CaseTest case mô tả một dữ liệu đầu vào (input), hành động (action) hoặc sự kiện (event) và một kết quả mong đợi (expected response), để xác định một chức năng của ứng dụng phần mềm hoạt động đúng hay không. Quá trình phát triển test case có thể giúp tìm ra lỗi trong các yêu cầu hoặc thiết kế của ứng dụng, vì nó đòi hỏi phải tư duy hoàn toàn thông qua các hoạt động của ứng dụng. Vì vậy, việc chuẩn bị test case sớm nhất có thể trong quy trình phát triển phần mềm là rất hữu ích. Các trường hợp kiểm thử phải bao phủ được toàn bộ luồng xử lý chức năng mô tả trong tài liệu phân tích và thiết kế; các yêu cầu về bảo mật an toàn thông tin, yêu cầu hiệu năng của hệ thống. Cấu trúc một test case thường bao gồm các thông tin:
Equivalence Partitioning (Phân vùng tương đương) -Ý tưởng: Phân vùng tương đương là phương pháp chia các điều kiện đầu vào thành những vùng tương đương nhau. Tất cả các giá trị trong một vùng tương đương sẽ cho một kết quả đầu ra giống nhau. Vì vậy chúng ta có thể kiểm tra một giá trị đại diện trong vùng tương đương. Hình 1.11: Kỹ thuật phân vùng tương đương -Thiết kế test case bằng kỹ thuật phân vùng tương đương tiến hành theo 2 bước:
-Ưu/ Nhược điểm của kỹ thuật phân vùng tương đương:
Boundary-value Analysis (Phân tích giá trị biên) -Ý tưởng: Phân tích giá trị biên là trường hợp đặc biệt của phân vùng tương đương, dựa trên những phân vùng tương đương tester sẽ xác định giá trị biên giữa những phân vùng này và lựa chọn test case phù hợp. -Các case chuẩn được lựa chọn dựa vào quy tắc sau:
Hình 1.12: Kỹ thuật phân tích giá trị biên -Ưu/ Nhược điểm của kỹ thuật phân tích giá trị biên:
Error Guessing (Đoán lỗi) -Ý tưởng: Phương pháp này không có quy trình cụ thể vì có tính trực giác cao và không thể dự đoán trước. Phương pháp chỉ phù hợp với những Tester có kinh nghiệm. Họ phỏng lỗi phần mềm dựa vào trực giác, dựa vào kinh nghiệm, dữ liệu lịch sử về các lỗi đã từng xảy ra với chương trình trước đó… và sau đó viết các ca kiểm thử để đưa ra các lỗi đó. -Ưu/ Nhược điểm:
Ngoài 3 kỹ thuật thiết kế các trường hợp kiểm thử đã nói ở trên, còn rất nhiều các kỹ thuật kiểm thử khác như: thiết kế các trường hợp kiểm thử dựa trên đồ thị nguyên nhân – kết quả (Cause-Effect Diagram), dựa trên bảng quyết định (Decision Tables)… Để giảm thiểu số case đến mức tối ưu mà vẫn đảm bảo chất lượng phần mềm, mỗi tester cần linh hoạt trong việc lựa chọn các kỹ thuật thiết kế các trường hợp kiểm thử. 1.6. Các kỹ thuật kiểm thử phần mềm1.6.1. Kiểm thử hộp đen (Black box testing)Kiểm thử hộp đen hay còn gọi là kiểm thử hướng dữ liệu. Trong kỹ thuật này người kiểm thử xem phần mềm như là một hộp đen. Người kiểm thử hoàn toàn không quan tâm đến cấu trúc, hành vi bên trong phần mềm. Người kiểm thử chỉ quan tâm đến việc tìm ra các lỗi mà phần mềm không xử lý theo đúng đặc tả của nó. Vì thế dữ liệu kiểm thử xuất phát từ đặc tả. Hình 1.13: Kiểm thử hộp đen -Kiểm thử hộp đen cố gắng tìm ra các lỗi trong các loại sau:
-Một số loại kiểm thử hộp đen hay dùng
-Ưu điểm: Các tester được thực hiện từ quan điểm của người dùng sẽ giúp sáng tỏ sự chênh lệch về thông số kỹ thuật. Theo phương pháp này, tester 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. Các tester có thể được thực hiện bởi một cơ quan độc lập từ các developer, cho phép một cái nhìn khách quan và tránh sự phát triển thiên vị. -Nhược điểm: Dữ liệu đầu vào yêu cầu một khối lượng mẫu khá lớn. Nhiều dự án không có thông số rõ ràng thì việc thiết kế các trường hợp kiểm thử rất khó và do đó khó viết kịch bản kiểm thử cần xác định tất cả các yếu tố đầu vào, và cả yếu tố thời gian. Khả năng để bản thân kỹ sư lạc lối trong khi kiểm thử là khá cao. Chỉ có một số nhỏ các đầu vào có thể được kiểm tra và nhiều đường dẫn chương trình sẽ được để lại chưa được kiểm tra. 1.6.2. Kiểm thử hộp trắng (White box testing)Kiểm thử hộp trắng còn gọi là kiểm thử cấu trúc. Dựa vào thuật giải cụ thể, vào cấu trúc dữ liệu bên trong của đơn vị phần mềm cần kiểm thử để xác định đơn vị phần mềm đó có thực hiện đúng không. Do đó người kiểm thử hộp trắng phải có kỹ năng, kiến thức nhất định về ngôn ngữ lập trình được dùng, về thuật giải được dùng trong phần mềm để có thể thông hiểu chi tiết về đoạn code cần kiểm thử. Hình 1.14: Kiểm thử hộp trắng Kiểm thử hộp trắng thường tốn rất nhiều thời gian và công sức nếu phần mềm quá lớn (thí dụ trong kiểm thử tích hợp hay kiểm thử chức năng). Do đó kỹ thuật này chủ yếu được dùng để kiểm thử đơn vị, kiểm thử từng tác vụ của một lớp chức năng. -Tiêu chuẩn của kiểm nghiệm hộp trắng phải đáp ứng các yêu cầu như sau:
-Các kỹ thuật kiểm thử hộp trắng:
-Ưu điểm: Buộc các chuyên gia kiểm thử phải suy luận cẩn thận về việc kiểm thử lỗi vì vậy lỗi sẽ được triệt để, cho phép tìm kiếm các lỗi ẩn bên trong. Do yêu cầu kiến thức cấu trúc bên trong của phần mềm, nên việc kiểm soát lỗi tối đa nhất. -Nhược điểm: Khá mất thời gian và công sức nhưng vẫn sẽ tồn tại lỗi. Đòi hỏi ngưởi kiểm thử có kinh nghiệm và am hiểu về kiểm thử cũng như về cấu trúc bên trong của phần mềm được thử nghiệm. 1.6.3. Kiểm thử hộp xámKiểm thử hộp xám là một phương pháp kiểm thử phần mềm được kết hợp giữa phương pháp kiểm thử Black Box và White Box. Trong kiểm thử hộp đen tester kiểm thử các hạng mục mà không cần biết cấu trúc bên trong của chương trình, còn kiểm thử hộp trắng thì tester biết được cấu trúc bên trong của chương trình. Trong kiểm thử hộp xám, cấu trúc bên trong sản phẩm chỉ được biết một phần. Tester có thể truy cập vào cấu trúc dữ liệu bên trong và thuật toán của chương trình với mục đích là để thiết kế các trường hợp kiểm thử, nhưng khi thực hiện kiểm thử thì test như người dùng cuối hoặc là ở mức hộp đen. Hình 1.15: Kiểm thử hộp xám Mặc dù phương pháp kiểm thử hộp xám có thể được dùng trong các mức khác nhau của kiểm thử, tuy nhiên nó chủ yếu được sử dụng trong kiểm thử tích hợp. Kiểm thử hộp xám nhằm tìm ra tối đa số lỗi về cấu trúc dữ liệu của hộp trắng và lỗi chức năng của hộp đen. Trong kiểm thử hộp xám viết các trường hợp kiểm thử dựa vào yêu cầu và nội dung Source Code (can thiệp vào bên trong Code của chương trình). Thực hiện kiểm thử trên giao diện của chương trình (yêu cầu chương trình phải chạy được mới kiểm thử được, không can thiệp vào code). -Ưu điểm: Hoạt động tốt cho các đoạn mã lớn, các vai trò được xác định rõ ràng cho người dùng và nhà phát triển trong quá trình thử nghiệm. Thử nghiệm dựa trên yêu cầu của người dùng chứ không phải người thiết kế. -Nhược điểm: Hầu hết các trường hợp kiểm thử đều khó thiết kế. Kiểm thử hộp xám không được coi là một phương pháp hiệu quả vì không có nhiều kịch bản để kiểm thử. 2. Kiểm thử tự động2.1 Khái quát về kiểm thử tự động (Automation testing)Kiểm thử tự động là quá trình thực hiện một cách tự động các bước trong một ca kiểm thử. Nó sử dụng một công cụ kiểm thử tự động nào đó để rút ngắn thời gian kiểm thử. Kiểm thử tự động hỗ trợ các kiểm thử viên rất nhiều tùy vào công cụ và các nội dung kiểm thử có thể thực hiện bằng tay hay không. Đối với những nhiệm vụ kiểm tra khó mà thực hiện bằng tay hoặc yêu cầu chi phí về nhân công là quá lớn thì sử dụng công cụ hỗ trợ là điều hết sức cần thiết. Lợi ích của kiểm thử tự động:
2.2 Ưu và nhược điểm2.2.1. Ưu điểm
2.2.2. Nhược điểm
2.3. Các loại kiểm thử tự động2.3.1. Kiểm thử chức năngKiểm thử chức năng là một loại kiểm thử hộp đen và test case của nó được viết dựa trên đặc tả của ứng dụng phần mềm. Các chức năng được kiểm thử bằng cách nhập vào các giá trị nhập vào và kiểm tra các kết quả đầu ra, không quan tâm đến cấu trúc bên trong của phần mềm. Kiểm thử chức năng phần mềm là một quy trình cố gắng tìm ra các sự khác biệt giữa đặc tả bên ngoài của phần mềm và thực tế của phần mềm cung cấp. Một số công cụ kiểm thử chức năng: Selenium, QTP (Quick Test Pro), Appium, … 2.3.2. Kiểm thử hiệu năng (Performance Testing)Kiểm thử hiệu năng là một loại kiểm thử nhằm xác định mức độ đáp ứng, độ tin cậy và khả năng mở rộng hệ thống dưới một khối lượng truy cập nhất định. Kiểm thử hiệu năng thường được dùng để giúp xác định tắc nghẽn trong một hệ thống, thiết lập một đường cơ sở để kiểm thử trong tương lai, hỗ trợ điều chỉnh hiệu suất hiệu quả, xác định sự phù hợp mục tiêu và yêu cầu hiệu suất, và thu thập dữ liệu hoạt động liên quan khác để giúp các bên liên quan đưa ra quyết định liên quan đến chất lượng chung của các ứng dụng đang được kiểm thử. Ngoài ra, các kết quả từ việc kiểm thử hiệu suất và phân tích có thể giúp nhà phát triển ước tính cấu hình phần cứng cần thiết để hỗ trợ các ứng dụng khi đưa sản phẩm đi vào sử dụng rộng rãi |