Please enable JavaScript.

Coggle requires JavaScript to display documents.

TỔNG HỢP KIẾN THỨC KIỂM THỬ - Coggle Diagram

- - - - Tích hợp từ dưới đi lên: Việc kiểm thử được bắt đầu bằng unit test, sau đó sẽ đi đến mức cao hơn, đó là kết hợp các thành phần và chức năng của hệ thống.
      - Tích hợp từ trên đi xuống: Những module cấp cao nhất được thử nghiệm đầu tiên rồi đến các module thấp hơn được thử nghiệm.
  - - - Kiểm thử chức năng (Functional Test): Là kiểm thử toàn bộ hệ thống, đảm bảo hệ thống hoạt động đúng theo yêu cầu được đưa ra trước đó
      - Kiểm thử hiệu năng (Performance Test): Là kiểm tra sự tuân thủ của hệ thống với các yêu cầu được chỉ định về hiệu năng. Xác định những thuộc tính chất lượng của hệ thống như khả năng mở rộng, độ tin cậy…
      - Kiểm thử cơ sở dữ liệu ( Database Test): Là kiểm tra dữ liệu hiển thị trên hệ thống có giống với dữ liệu trong cơ sở dữ liệu hay không?
      - Kiểm thử khả năng bảo mật ( Security Test): Là kiểm tra hệ thống được bảo vệ an toàn, không bị đánh cắp dữ liệu, thông tin trước các tấn công từ bên ngoài.
      - Kiểm thử tính khả dụng (Usability Test): Kiểm tra tính thân thiện với người dùng và tính dễ sử dụng của hệ thống.
      - Kiểm tra tính tương thích ( Compatibility Test) : Là kiểm tra xem hệ thống có tương thích với các yếu tố khác của hệ thống mà nó sẽ hoạt động hay không? (Ví dụ: Trình duyệt, hệ điều hành, phần cứng).
      - Kiểm tra khả năng phục hồi ( Recovery Test): Là kiểm tra hệ thống có khả năng khôi phục trạng thái ổn định khi gặp các sự cố bất thường không.
  - - - Alpha Test, người dùng kiểm thử phần mềm ngay tại nơi phát triển phần mềm, 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.
      - Beta Test, phần mềm sẽ được gửi tới cho người dùng để kiểm thử 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. 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.
- - - - Thay vì chọn nhiều giá trị trong lớp đương tương để làm đại diện, phân tích giá trị biên yêu cầu chọn một hoặc vài giá trị là các cạnh của lớp tương đương để làm điều kiện test.
      - Kỹ thuật thiết kế test cases này bổ sung cho phân vùng tương đương. Kỹ thuật kiểm thử phần mềm này dựa trên nguyên tắc: Nếu một hệ thống hoạt động tốt với các giá trị biên thì nó sẽ hoạt động tốt cho tất cả các giá trị nằm giữa hai giá trị biên.
    - - Giá trị ngay dưới giá trị nhỏ nhất
      - Giá trị nhỏ nhất
      - Giá trị ngay trên giá trị nhỏ nhất
      - Giá trị ngay dưới giá trị lớn nhất
      - Giá trị lớn nhất
      - Giá trị ngay trên giá trị lớn nhất
  - - - Vùng tương đương hợp lệ: tập hợp các giá trị kiểm thử thỏa mãn điều kiện của hệ thống
      - Vùng tương đương không hợp lệ: Tập hợp các giá trị kiểm thử mô tả trạng thái khác của hệ thống: sai, thiếu, không đúng,...
    - - Xác định các lớp tương đương
      - Xác định các ca kiểm thử
    - - 1 lớp các giá trị lớn hơn
      - 1 lớp các giá trị nhỏ hơn
      - n lớp các giá trị hợp lệ
  - - - Ví dụ: Nút Submit phải được enable nếu người dùng đã nhập tất cả các trường bắt buộc.
      - Đầu tiên là xác định đấu ra của các chức năng có phụ thuộc vào sự kết hợp của các đầu vào. Nếu có tập hợp kết hợp đầu vào lớn, thì hãy chia nó thành các tập hợp nhỏ hơn hữu ích cho việc quản lý bảng quyết định.
      - Đối với mọi chức năng, cần tạo một bảng và liệt kê tất cả các loại kết hợp đầu vào và đầu ra tương ứng. Điều này giúp xác định các điều kiện bị tester bỏ qua.
    - - Các bước để tạo bảng quyết định:
      - Nhập đầu vào theo hàng
      - Nhập tất cả các quy tắc trong cột
      - Điền vào bảng với sự kết hợp của đầu vào
      - Trong hàng cuối cùng, ghi chú đầu ra so với kết hợp đầu vào.
  - - - Tester nên sử dụng kinh nghiệm trước đây để kiểm thử các ứng dụng tương tự
      - Hiểu biết về hệ thống đang kiểm thử
      - Kiến thức về các lỗi thực hiện điển hình
      - Nhớ những chức năng phức tạp trước đây
      - Đánh giá lịch sử dữ liệu và kết quả kiểm thử
- - - - Là một loại kiểm thử hộp đen, tập trung vào việc xác minh hệ thống hoạt động theo đúng các yêu cầu nghiệp vụ, thông qua một tài liệu gọi là đặc tả yêu cầu (Requirement Specification) được phát triển nhằm hướng dẫn kiểm tra ứng dụng chính xác hơn.
      - Functional Testing về cơ bản là một quy trình so sánh sự khác biệt giữa đặc tả bên ngoài của phần mềm với các chức năng thực tế mà phần mềm cung cấp. Các chức năng sẽ được kiểm tra bằng cách nhập các giá trị đầu vào và sau đó sẽ kiểm tra, đánh giá các kết quả đầu ra mà không cần quan tâm đến các cấu trúc hay cài đặt bên trong của ứng dụng.
      - Nhờ có Functional Testing, có thể tránh được những việc kiểm thử dư thừa các chức năng không cần thiết. Đồng thời giúp ngăn chặn nhiều lỗi xuất hiện cùng một thời điểm.
    - - Unit testing (Kiểm thử đơn vị)
      - Smoke Testing
      - Sanity Testing
      - Interface testing (Kiểm thử giao diện)
      - Integration testing (Kiểm thử tích hợp)
      - System testing (Kiểm thử hệ thống)
      - Regression testing (Kiểm thử hồi quy)
      - Acceptance testing (Kiểm thử chấp nhận)
  - - - Theo thuật ngữ phần mềm, khi một ứng dụng hoạt động theo mong đợi của người dùng, trơn tru và hiệu quả trong bất kỳ điều kiện nào, thì ứng dụng đó được coi là một ứng dụng đáng tin cậy. Dựa trên các khía cạnh này của chất lượng, việc kiểm tra theo các thông số này là rất quan trọng. Loại kiểm tra này được gọi là Non-Functional Testing (Kiểm thử phi chức năng).
      - Non-Functional Testing (Kiểm thử phi chức năng) cung cấp thông tin quan trọng về độ an toàn, khả năng phục vụ và độ tin cậy của hệ thống.
    - - Stability tests (Kiểm thử độ ổn định):
      - Reliability Tests (Kiểm thử độ tin cậy)
      - Robustness Tests (Kiểm thử độ bền)
      - Stress tests (Kiểm thử áp lực)
      - Performance Tests (Kiểm tra hiệu năng)
      - Load Tests (Kiểm thử khả năng chịu tải)
      - Usability Tests (Kiểm thử tính khả dụng)
      - Maintainability Tests (Kiểm thử khả năng bảo trì)
      - Portability Tests (Kiểm tra tính tương thích)
  - - - Kiểm thử chức năng xác minh từng chức năng/tính năng của phần mềm trong khi kiểm thử phi chức năng xác minh các khía cạnh phi chức năng như hiệu suất, khả năng sử dụng, độ tin cậy, v.v.
      - Kiểm thử chức năng có thể được thực hiện thủ công trong khi kiểm thử phi chức năng khó thực hiện bằng tay.
      - Kiểm thử chức năng dựa trên yêu cầu của khách hàng trong khi kiểm thử phi chức năng dựa trên kỳ vọng của khách hàng.
      - Kiểm thử chức năng có mục tiêu xác thực các hành động phần mềm trong khi kiểm thử phi chức năng có mục tiêu xác nhận hiệu suất của phần mềm.
      - Ví dụ: bạn có thể kiểm tra xem việc nhập tên người dùng và mật khẩu có cho phép bạn đăng nhập vào tài khoản trên trang web hay không. Và với Non-functional Testing, bạn xác minh xem bằng cách nhập cùng một dữ liệu, bạn có thể đăng nhập vào tài khoản của mình trong vòng 2 giây hay không.
      - Kiểm thử chức năng mô tả những gì sản phẩm làm trong khi Kiểm thử phi chức năng mô tả cách sản phẩm hoạt động.
      - Kiểm thử chức năng được thực hiện trước khi kiểm thử phi chức năng.
    - - Kiểm thử chức năng
        
        Là kiểm tra các hoạt động (operations) và hành động (actions) của một Ứng dụng
        
        Rất dễ dàng để xác định các yêu cầu chức năng và tiến hành chính xác
        
        Được thực hiện bằng cách sử dụng đặc tả chức năng
        
        Là kiểm tra xem kết quả thực tế có hoạt động theo kết quả mong đợi hay không
        
        Được thực hiện thủ công. (Manual test)
        Ví dụ: Phương pháp kiểm tra hộp đen. (Black box testing)
        
        Kiểm tra theo yêu cầu của khách hàng.
        
        Phản hồi của khách hàng giúp giảm các yếu tố rủi ro của sản phẩm trong quá trình sử dụng.
        
        Giúp xác thực hành vi của ứng dụng.
        
        Kiểm thử (thực hiện test) các chức năng của phần mềm.
        
        Bao gồm
        
        · Unit testing
        
        · Smoke testing
        
        · User Acceptance
        
        · Integration Testing
        
        · Regression testing
        
        · Localization
        
        · Globalization
        
        · Interoperability
      - Kiểm thử phi chức năng
        
        Là kiểm tra các hành vi (behavior) của 1 Ứng dụng
        
        Rất khó để xác định các yêu cầu cho kiểm thử phi chức năng. Bởi vậy khó xác định được hiệu quả bằng một con số cố định cụ thể.
        
        Đươc thực hiện bởi các thông số kỹ thuật về hiệu suất
        
        Là kiểm tra thời gian đáp ứng (response time) và tốc độ (speed) của phần mềm trong các điều kiện cụ thể.
        
        Được thực hiện thông qua các công cụ tự động để xác định các chỉ số
        Ví dụ: Loadrunner, Jmeter…
        
        Kiểm tra theo mong đợi của khách hàng.
        
        Phản hồi của khách hàng có giá trị hơn đối với thử nghiệm phi chức năng vì nó giúp cải thiện và cho phép người thử nghiệm biết được sự mong đợi của khách hàng, từ đó đáp ứng tốt mong đợi khách hàng hơn.
        
        Giúp xác nhận hiệu suất của ứng dụng.
        
        Kiểm tra hiệu năng (performance) của chức năng của phần mềm.
        
        Bao gồm
        
        · Performance Testing
        
        · Volume Testing
        
        · Scalability
        
        · Usability Testing
        
        · Load Testing
        
        · Stress Testing
        
        · Compliance Testing
        
        · Portability Testing
        
        · Disaster Recover Testing
- - - - Dựa vào ngày tháng năm sinh và ngày tháng năm hiện tại?
      - hay
      - Chỉ dựa vào năm sinh và năm hiện tại?
  - - - App/ web cần được check trên môi trường nào?
      - Format file CSV để import thông tin user như thế nào?
  - - - Nên đặt theo thứ tự
        
        Q&A chung cho toàn dự án
        
        Thứ tự ưu tiên cho các chức năng là gì?
        
        Môi trường test là gì (web, app, web-app), support version bao nhiêu?
        
        Test trên devices nào (Android/IOS), Browser nào (Cốc cốc, Chrome, firefox...)
        
        Q&A riêng cho từng function cụ thể.
        
        Khi nào thì có specs cho một function cụ thể.
        
        Thực hiện Q&A theo 5W-1H:
    - - Nên đặt theo thứ tự
        
        Dùng Q&A mở (5W1H): khi spec của function X đã có, nhưng chưa thực sự rõ ràng.
        
        Dùng Q&A mở (5W1H): khi spec của function X đã có, QA chưa nắm được, khách hàng đang băn khoăn các phương án và cần tìm hiểu technical skill.
        
        Dùng Q&A đóng (Y/N question): khi spec của function X đã có, QA nắm được, nhưng khách hàng đang băn khoăn các phương án, cách thức xử lý: Cần đưa ra suggestion cho khách hàng.
        
        Dùng Q&A đóng (Y/N question): khi spec của function X đã có, QA nắm được nhưng chưa chắc chắn, cần confirm lại.
    - - Có đối ứng CR (change request) hay không?
      - Nếu có thì cần Q&A để clear nội dung CR, xác định mức độ rủi ro, phạm vi ảnh hưởng và tổng hợp rồi gửi cho khách hàng sớm nhất có thể.
    - - Khi nội dung requirement chưa rõ ràng mà trong nội bộ có thể giải quyết được.
    - - Khi cần confirm lại requirement với khách hàng.
      - Tránh tình trạng Q&A trong nội bộ có thể giải quyết được mà lại thực hiện Q&A với khách hàng.
- - - - Lập kế hoạch kiểm thử là việc tạo ra một tài liệu mô tả tiếp cận tổng thể và các mục tiêu cần test. Bao gồm :
        
        Xem xét cơ sở test
        
        Xác định các điều kiện dựa trên phân tích các mục thử test,
        
        Viết các trường hợp và thiết kế môi trường test.
        
        Tiêu chí hoàn thành được chỉ định để biết khi nào việc kiểm thử hoàn tất (ở bất kỳ giai đoạn nào).
      - Kiểm soát là hoạt động so sánh tiến độ thực tế so với kế hoạch và báo cáo tình trạng, bao gồm
        
        cả những sai lệch so với kế hoạch. .
        
        Nó liên quan đến việc thực hiện các hành động cần thiết để đáp ứng mục tiêu của dự án
    - - Xác định phạm vi, rủi ro và các mục tiêu test
      - Xác định các tài nguyên test cần thiết như con người, môi trường, v.v.
      - Lên lịch trình cho các nhiệm vụ phân tích và thiết kế, thực hiện, và đánh giá test
  - - - Xem xét cơ sở test – thông tin dựa trên các trường hợp test, chẳng hạn như yêu cầu, đặc điểm thiết kế, phân tích rủi ro, kiến trúc và giao diện
      - Xác định các điều kiện test
      - Thiết kế các bài test
      - Thiết kế môi trường thử test, thiết lập và xác định cơ sở hạ tầng và công cụ cần thiết
  - - - Tiến hành các trường hợp test bằng cách sử dụng các kỹ thuật và tạo dữ liệu cho các thử nghiệm đó
      - Tạo các bộ kiểm thử từ các trường hợp test để thực hiện hiệu quả. Bộ kiểm thử là tập hợp các trường hợp test được sử dụng để kiểm thử phần mềm
      - Thực hiện lại các trường hợp test không thành công trước đó để xác nhận bản sửa lỗi
      - Ghi lại kết quả của việc thực hiện test. Ở đó nhật ký kiểm thử ghi lại trạng thái của trường hợp test. (đạt / không đạt)
      - So sánh kết quả thực tế với kết quả mong đợi
  - - - Đánh giá xem có cần test thêm hoặc tiêu chí hoàn thành đã chỉ định có cần thay đổi hay không
      - Viết một báo cáo tóm tắt kiểm thử cho các bên liên quan
    - - Đánh giá tiêu chí hoàn thành là quá trình xác định thời điểm dừng kiểm thử. .
      - Nó phụ thuộc vào phạm vi của mã code, chức năng hoặc rủi ro
      - Ngoài ra cũng phụ thuộc vào rủi ro business, chi phí, thời gian và sự khác nhau giữa các dự án.
  - - - Hoàn tất khi phần mềm ss được bàn giao
        và dừng lại vì vài lý do sau :
        
        Khi dự án bị hủy bỏ
        
        Khi đạt được một số mục tiêu
        
        Khi bản cập nhật hoặc release bảo trì hoàn thành
      - Bước này có các nhiệm vụ chính sau:
        
        Kiểm tra xe sản phẩm được bàn giao chưa, theo kế hoạch nào, và để đảm bảo rằng tất cả các báo cáo sự cố đã được giải quyết
        
        Hoàn thiện và lưu trữ phần mềm kiểm thử như scripts, môi trường test, v.v. để sử dụng lại sau này
        
        Bàn giao phần mềm kiểm thử cho bên bảo trì
        
        Đánh giá cách test đã thực hiện và rút kinh nghiệm cho các bản release và dự án trong tương lai
- - - - Luôn đặt tên một cách có ý nghĩa nhất, dễ hiểu đối với bất kỳ ai sẽ thực hiện các trường hợp thử nghiệm trong tương lai (bao gồm BẠN!).
      - Mẹo nhanh: Đặt tên cho các testcase để mô tả tên mô-đun hoặc khu chức năng mà bạn sẽ xác minh trong trường hợp kiểm tra đó.
      - Ví dụ: Có hệ thống bán hàng online, trong đó có chức năng: Đăng Ký Vậy, khi viết testcase, thay cho việc viết tên TC01, ta sẽ viết cụ thể thêm chức năng đang nói tới: TCĐăng_Ký
    - - Mô tả là nơi bạn đề cập đến tất cả các chi tiết về những gì sẽ kiểm tra, và hành vi đặc biệt được xác minh bằng kịch bản kiểm tra.
      - Mẹo nhanh: Đưa càng nhiều thông tin càng tốt trong phần mô tả của testcase!
    - - Dưới đây là loại chi tiết bạn muốn bao gồm như là một phần của phần này:
        
        Sự phụ thuộc vào môi trường thử nghiệm
        
        Bất kỳ thiết lập đặc biệt nào được thực hiện trước khi thực thi thử nghiệm
        
        Sự phụ thuộc vào bất kỳ trường hợp kiểm tra nào khác - Trường hợp thử nghiệm cần được thực hiện trước / sau một số trường hợp kiểm tra khác không?
        
        Bất kỳ phụ thuộc dữ liệu người dùng nào (ví dụ: người dùng phải đăng nhập, trang nào người dùng bắt đầu cuộc hành trình, v.v ...)
      - Mẹo nhanh: Đảm bảo thêm càng nhiều thông tin càng tốt để có thể đáp ứng các điều kiện trước khi chạy thử.
    - - Xác định dữ liệu thử nghiệm có thể rất tốn thời gian - bởi vì cần nhiều lần chuẩn bị dữ liệu thử nghiệm, nên mất nhiều thời gian trong một chu kỳ thử nghiệm.
      - Đôi khi bạn cần tạo một dữ liệu thử nghiệm một lần nữa vì việc tạo ra một dữ liệu mới có thể mất ít thời gian hơn so với việc xác định nó
      - Để dễ dàng cho một người thử nghiệm (và những người kiểm thử khác), Bất cứ khi nào có thể, bạn có thể cung cấp cho họ dữ liệu thử nghiệm để sử dụng cho các trường hợp thử nghiệm trong mô tả của testcase hoặc với từng bước cụ thể trong testcase Điều này sẽ tiết kiệm rất nhiều thời gian trong quá trình bạn cần phải thực hiện lại các testcase
      - Một vài gợi ý:
        
        Trong nhiều trường hợp bạn biết dữ liệu thử nghiệm có thể được sử dụng lại theo thời gian, bạn có thể đề cập đến chính xác dữ liệu kiểm tra để sử dụng cho việci kiểm thử.
        
        Nếu thử nghiệm chỉ bao gồm một số giá trị được xác minh, bạn có thể chọn để chỉ định phạm vi giá trị hoặc mô tả những giá trị nào sẽ được kiểm tra cho trường nào.
        
        Kiểm tra với mỗi giá trị là không thực tế, do đó bạn có thể chọn một vài giá trị từ mỗi lớp tương đương mà nên cung cấp cho bảo hiểm tốt cho bài kiểm tra của bạn.
        
        Bạn cũng có thể quyết định đề cập đến loại dữ liệu được yêu cầu để chạy thử nghiệm chứ không phải giá trị dữ liệu thử nghiệm thật sự. Điều này áp dụng cho các dự án mà dữ liệu thử nghiệm vẫn tiếp tục thay đổi khi nhiều nhóm sử dụng nó và có thể không ở trong cùng một trạng thái khi sử dụng nó trong lần tiếp theo
    - - Một phần quan trọng khác của một trường hợp thử nghiệm tốt, là các bước xác minh trường hợp thử nghiệm được xác định chính xác bao gồm tất cả các điểm xác minh đối với tính năng được thử.
      - Mẹo nhanh: Các bước Thiết kế Thử nghiệm không chỉ bao gồm các luồng chức năng mà còn phải đảm bảo mỗi điểm được kiểm tra!
      - Bằng cách so sánh các bước Test Case của bạn với các tài liệu (Tài liệu yêu cầu, trường hợp sử dụng, bản đồ quy trình) dự án của bạn, bạn có thể đảm bảo rằng Test Case tối ưu bao gồm tất cả các điểm xác minh.
    - - Như tôi đã đề cập ở trên, nếu có thể, bạn nên đính kèm các hiện vật có liên quan vào trường hợp thử nghiệm của bạn.
      - Nếu sự thay đổi bạn đang thử nghiệm không lớn, bạn có thể cân nhắc đề cập đến nó trong bước kiểm tra.
      - Tuy nhiên, nếu nó liên quan đến một phần cụ thể trên màn hình, nó có thể là khó khăn để đề cập đến trong bước kiểm tra, gắn tài liệu đặc tả hoặc thiết kế màn hình với bước cụ thể giúp.
    - - Một testcase rõ ràng sẽ đề cập rõ kết quả dự kiến của ứng dụng hoặc hệ thống đang thử nghiệm. Mỗi bước thiết kế thử nghiệm cần đề cập rõ ràng những gì bạn mong đợi như là kết quả của bước xác minh đó.
      - Vì vậy, trong khi viết các trường hợp thử nghiệm, hãy đề cập chi tiết về trang / màn hình mà bạn mong đợi xuất hiện sau bài kiểm tra, và bất kỳ bản cập nhật nào bạn mong đợi như là một kết quả sẽ được thực hiện trong hệ thống hoặc cơ sở dữ liệu back-end (ví dụ như một mục nhập mới nên ghi vào Bảng dữ liệu).
      - Bạn cũng có thể đính kèm ảnh chụp màn hình hoặc tài liệu đặc tả cho bước tương ứng đề cập đến hệ thống nên hoạt động như đã nêu trong tài liệu cho trước để làm cho mọi thứ đơn giản hơn.
    - - Để viết bài kiểm tra hiệu quả, bạn nên xem xét việc phân chia các testcase thành các bộ và các bộ phụ để kiểm tra một số tình huống đặc biệt như các hành vi cụ thể của trình duyệt, xác minh cookie, kiểm tra khả năng sử dụng, kiểm tra dịch vụ Web và kiểm tra các điều kiện lỗi ...
      - Mẹo nhanh: Nếu trong khi viết các kịch bản này thành tập hợp, một tính năng cụ thể có nhiều kết hợp đầu vào, bạn có thể tách thử nghiệm thành các testcase phụ
    - - Dù dự án bạn làm việc, khi thiết kế các trường hợp thử nghiệm, bạn nên luôn luôn xem xét rằng Các trường hợp kiểm tra sẽ không phải luôn luôn được thực hiện bởi người thiết kế chúng. Vì vậy, các bài kiểm tra phải dễ hiểu, dễ đọc và chính xác.
      - Bộ phần mềm thử nghiệm chỉ có thể hiểu được bởi những người thiết kế chúng là phổ biến. Vì vậy, bạn nên tập trung vào việc viết các testcase mà:
      - Đều đơn giản và dễ hiểu bởi tất cả mọi người (kể cả BẠN!)
      - Chia nhỏ các thử nghiệm một cách tối giản thành một Thử nghiệm mới vẫn có đủ độ phủ sóng
    - - Các testcase đóng một vai trò quan trọng trong vòng đời Kiểm thử Phần mềm. Hãy đảm bảo rằng chúng là chính xác và phù hợp với các tiêu chuẩn, thậm chí còn rất cần thiết
      - Mẹo nhanh: Kiểm tra lại trường hợp thử nghiệm có thể được thực hiện bởi các tester khác, BA, nhà phát triển, chủ sở hữu sản phẩm hoặc bất kỳ bên liên quan nào.
    - - Bạn nên viết các test case với suy nghĩ rằng chúng có thể được tái sử dụng trong tương lai đối với các nhóm hoặc dự án khác.
      - Chú ý rằng, trước khi viết một Test case mới cho dự án hay module của bạn, luôn luôn cố gắng tìm ra nếu các test case đã được viết sẵn đối với vùng giống nhau? Điều đó thực sự giúp tiết kiệm được nhiều thời gian.
      - Nếu bạn dành chút thời gian với các nhóm khác để tìm ra các test case đã có sẵn thì bạn có thể may mắn là sẽ không lặp lại một số test case, từ đó tránh được sự dư thừa trong các công cụ quản lý test (như ALM hoặc QC).
    - - Nó rất quan trọng để đảm bảo rằng các Test case luôn được cập nhật theo những thay đổi đã được đề cập ở hiện tại trong ứng dụng mà họ áp dụng.
      - Việc nhắc lại điểm của tôi về khả năng sử dụng lại, trong trường hợp có thay đổi đối với tiến trình hoặc chức năng hiện tại, bạn PHẢI xem xét cập nhật các Test case hiện tại thay vì viết thêm bất kỳ Test case mới nào, từ đó tránh sự dư thừa đối với bộ test case hiện tại.
      - Điều này cũng đảm bảo bạn luôn cập nhật các Test case cho bất kỳ tiến trình nào trong ứng dụng của bạn.
    - - Các điều kiện công bố xác định dựa trên những điều khác nhau cần được xác minh sau khi Kiểm thử đã được thực hiện Thêm nữa, các điều kiện công bố cũng được sử dụng để hướng dẫn để khôi phục lại hệ thống về trạng thái ban đầu của nó vì nó không liên quan tới việc kiểm thử sau này. Ví dụ, điều này khá hữu ích nếu bạn đề cập đến những thay đổi được thực hiện với một dữ liệu kiểm thử mà nó sẽ được sử dụng cho một trường hợp thử nghiệm sau đối với cùng một chức năng.
- - - - Trong ngữ cảnh API, từ “Ứng dụng” đề cập đến mọi phần mềm có chức năng riêng biệt.
      - Giao diện có thể được xem là một hợp đồng dịch vụ giữa 2 ứng dụng.
      - Hợp đồng này xác định cách thức hai ứng dụng giao tiếp với nhau thông qua các yêu cầu và phản hồi.
      - Tài liệu API của các ứng dụng này chứa thông tin về cách nhà phát triển xây dựng cấu trúc cho những yêu cầu và phản hồi đó.
  - - - URL: đường dẫn để gọi api
      - Method: api có rất nhiều phương thức, nhưng chủ yếu sử dụng 5 loại phương thức sau:
        
        GET: Sử dụng để lấy thông tin từ server theo URL đã cung cấp.
        
        POST: Gửi thông tin tới server thông qua các parameters.
        
        PUT: Ghi đè tất cả thông tin của đối tượng với những gì được gửi lên.
        
        PATCH: Ghi đè các thông tin được thay đổi của đối tượng.
        
        DELETE: Xóa đối tượng trên server.
      - Header: nơi chứa các thông tin cần thiết của 1 request nhưng end-users không biết có sự tồn tại của nó.
      - Body: nơi chứa thông tin mà client sẽ truyền lên api
    - - Status code: là các mã code để biết api được gọi thành công hay thất bại.
        
        Ví dụ: thành công thì trả về status code là 200, lỗi validate thì trả về 400, not found thì trả về 404, ..
        
        (Tham khảo: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes)
      - Header: tương tự như request
      - Body: tương tự như request
  - - - JSON là 1 định dạng đơn giản với 2 thành phần: keys và values.
      - – Key thể hiện thuộc tính của Object
      - – Value thể hiện giá trị của từng Key
      - Có nhiều trường hợp, 1 key sẽ có Value là 1 dãy key + value
    - - Trong JSON dùng { } và [ ] để dánh dấu dữ liệu. XML thì tương tự như HMTL, dùng thẻ để đánh dấu và được gọi là nodes
  - - - Đây là phương thức xác thực ít được khuyến khích bởi tình bảo mật của nó không an toàn. Trong phương thức này ta rất dễ dàng thực hiện được như sau.
      - Client sẽ gửi username, password của mình trong header của request. Username và password phải được mã hóa dưới dạng Base64 để đảm bảo tính an toàn hơn.
      - Với phương thức này không cần đến hỗ trợ từ response khác.
    - - Bearer token sẽ cho phép truy cập đến một số tài nguyên hoặc url nhất định và thường là một chuỗi string được mã hóa, được sinh ra bởi server trong response để thực hiện request login.
      - Khi thực hiện bằng phương thức này thì client phải gửi bearer token này trong header để thực hiện request
    - - OAuth là viết tắt của Open với Authentication hoặc Authorization. đây là một phương thức chứng thực giúp các ứng dụng có thể chia sẻ tài nguyên với nhau mà không cần chia sẻ thông tin username và password. OAuth bao gồm bốn vai trò khác nhau:
        
        Resource Server: REST API là một ví dụ, một máy chủ HTTP nơi người dùng có thể tạo, sửa đổi hoặc xóa các bản ghi, tài liệu hoặc tệp.
        
        Resource Owner: Duy trì quyền sở hữu tài nguyên mà người dùng đã tạo hoặc sửa đổi trên máy chủ và người ủy quyền cho ứng dụng bên thứ 3 truy cập vào tài khoản của họ. Ứng dụng của bên thứ 3 có quyền truy cập hạn chế vào tài khoản của người dùng, dựa trên phạm vi của phạm vi của ủy quyền được cấp.
        
        Client: Ứng dụng bên thứ 3 muốn truy cập vào tài khoản người dùng. Trước khi nó có thể làm như vậy, máy chủ resource/authorization và chủ sở hữu tài nguyên phải ủy quyền cho yêu cầu đó. Mọi khách hàng phải được đăng ký với máy chủ authorization và sẽ được cung cấp cho nó thông tin xác thực duy nhất của riêng mình (client_id và client_secret) để xác thực riêng.
        
        Authorization Server (thường là giống Resource Server): Đôi khi, ta có thể muốn rút ra khỏi máy chủ authorization từ máy chủ resource và triển khai nó như một phiên bản chuyên dụng, đặc biệt là trong các môi trường phân tán.
      - Sơ đồ luồng hoạt động của OAuth2
        
        Ứng dụng (website hoặc mobile app) yêu cầu ủy quyền để truy cập vào Resource Server (Gmail,Facebook, Twitter hay Github…) thông qua User
        
        Nếu User ủy quyền cho yêu cầu trên, Ứng dụng sẽ nhận được ủy quyền từ phía User (dưới dạng một token string)
        
        Ứng dụng gửi thông tin định danh (ID) của mình kèm theo ủy quyền của User tới Authorization Server
        
        Nếu thông tin định danh được xác thực và ủy quyền hợp lệ, Authorization Server sẽ trả về cho Ứng dụng access_token. Đến đây quá trình ủy quyền hoàn tất.
        
        Để truy cập vào tài nguyên (resource) từ Resource Server và lấy thông tin, Ứng dụng sẽ phải đưa ra access_token để xác thực.
        
        Nếu access_token hợp lệ, Resource Server sẽ trả về dữ liệu của tài nguyên đã được yêu cầu cho Ứng dụng.
  - - - Kiểm thử API là loại kiểm thử phần mềm xác nhận API.
        
        Nó rất khác với kiểm thử GUI và tập chung chủ yếu vào logic nghiệp vụ của kiến trúc phần mềm.
        
        Thay vì sử dụng đầu vào (bàn phím) và đầu ra, trong kiểm thử API bạn sử dụng phần mềm để gửi yêu cầu đến API, nhận đầu ra và ghi lại phản hồi của hệ thống.
        
        Kiểm thử này không tập chung vào kiểm thử giao diện.
      - Kiểm thử API yêu cầu một ứng dụng để tương tác với API. Để kiểm thử API bạn sẽ cần:
        
        Sử dụng Tool kiểm thử để kiểm tra API
        
        Viết các câu lệnh để kiểm tra API
    - - Trong quá trình triển khai dự án, phần Server và Client làm độc lập với nhau nên có nhiều chỗ bên Client chưa làm xong, ta không thể chờ Client làm xong để test được dữ liệu. Do đó ta cần kiểm tra API bằng công cụ khác, lúc này việc test hoàn toàn không phụ thuộc gì vào client.
      - Khi Client làm xong rồi, nếu ta kiểm tra trên client mà thấy lỗi liên quan đến logic và dữ liệu thì cũng cần phải kiểm tra thêm cả API để biết chính xác là Server sai hay Client sai nhằm giúp cho việc sửa lỗi nhanh hơn.
      - Khi làm hệ thống web services, dự án chỉ viết API cho bên khác dùng, nên sẽ không có client để test giống như các dự án khác. Do đó, phải test API hoàn toàn.
- - - - Needs identification là giai đoạn nghiên cứu thị trường và brainstorming (phương pháp động não) của quy trình. Trước khi xây dựng phần mềm, công ty cần thực hiện nghiên cứu sâu rộng thị trường để xác định khả năng tồn tại của sản phẩm. Developers phải xác định được các chức năng và dịch vụ mà phần mềm nên cung cấp được cho người tiêu dùng để họ cảm thấy sản phẩm cần thiết và hữu ích.
        Ngoài ra, developers cũng nên thảo luận cùng với các bộ phận khác trong công ty về : Điểm mạnh, điểm yếu và cơ hội của sản phẩm. Quá trình phát triển phần mềm chỉ bắt đầu nếu sản phẩm thỏa mãn được mọi thông số nhất thiết để thành công.
    - - Requirements Analytics là giai đoạn thực hiện khảo sát chi tiết yêu cầu, mong muốn của khách hàng. Sau đó, thông tin sẽ được tổng hợp vào tài liệu đặc tả yêu cầu ( Prototype). Tài liệu đặc tả phải đầy đủ các yêu cầu về chức năng, phi chức năng và giao diện. Ngoài ra, tài liệu còn cung cấp một bản phác thảo chi tiết về thành phần, phạm vi, nhiệm vụ của developers và các thông số thử nghiệm để tạo ra sản phẩm chất lượng.
        Phân tích yêu cầu cũng là giai đoạn mà các developers lựa chọn cách tiếp cận phát triển phần mềm như: Mô hình chữ V (V Model) hay mô hình thác nước (Waterfall)
    - - Sau khi đã xác định & phân tích kỹ lưỡng về yêu cầu, chúng ta sẽ chuyển sang giai đoạn nắm vai trò quan trọng thiết yếu của Quy trình phát triển phần mềm - Design (thiết kế). Tại đây, các kiến trúc sư và nhà phát triển phần mềm sẽ đưa ra các thông số kỹ thuật tiên tiến mà họ cần để tạo ra sản phẩm theo yêu cầu. Vấn đề cần được thảo luận thêm giữa các bên bao gồm: Mức độ rủi ro, thành phần nhóm, công nghệ áp dụng, thời gian, ngân sách, giới hạn của dự án, phương pháp và thiết kế kiến trúc.
        Tài liệu DSD (Đặc điểm kỹ thuật thiết kế) sẽ là kết quả cuối cùng của giai đoạn. DSD chỉ định thiết kế kiến trúc, thành phần, giao tiếp, đại diện front-end và luồng người dùng của sản phẩm.
    - - Tại giai đoạn 4, developers sẽ lập trình và triển khai thông số thiết kế. Lập trình viên sẽ coding dựa trên các thông số kỹ thuật và yêu cầu của sản phẩm đã được thống nhất trong các giai đoạn trước.
        Sau khi coding hoàn tất, developers sẽ deploy sản phẩm trong môi trường phát triển (development environment). Lập trình viên sẽ thử nghiệm phiên bản đã tạo ra và điều chỉnh lại cho phù hợp với yêu cầu.
    - - Sau khi developers đã hoàn thành giai đoạn lập trình, tester sẽ tiếp nhận sản phẩm và tiến hành testing. Tester sẽ tạo test case (Kịch bản kiểm thử) dựa trên tài liệu giải pháp tạo ở giai đoạn 2 và tiến hành kiểm tra. Tester sẽ cập nhật kết quả test vào tool quản lý và thông báo bug (lỗi) đến developers. Tester và developers sẽ cùng nhau phối hợp xử lý các bug và cập nhật trên hệ thống quản lý lỗi. Trong thực tế, tùy theo mô hình phát triển phần mềm mà hoạt động Develop và Kiểm Thử có thể diễn ra song song hoặc tiến hành lần lượt. Vì dụ như ở mô hình Waterfall, lập trình được thực hiện xong mới đến giai đoạn kiểm thử.
    - - Tại giai đoạn này khi lỗi đã được xử lý xong, nhà phát triển phần mềm sẽ cung cấp sản phẩm hoàn chỉnh đến tay khách hàng. Testing vẫn được diễn ra ở giai đoạn triển khai để đảm bảo sản phẩm luôn có mức độ hoàn hảo cao. Sau khi phát hành, công ty sẽ tạo ra một nhóm bảo trì để quản lý các vấn đề mà khách hàng gặp phải khi sử dụng sản phẩm. Bảo trì giúp khắc phục nhanh các vấn đề nhỏ xảy ra trong quá trình sử dụng sản phẩm.