Giới thiệu quy trình kiểm thử hệ thống điện thoại

Hiện nay việc sử dụng các smartphone không còn lạ lẫm đối với chúng ta. Các dòng smartphone ngày càng đa dạng, đa chức năng, với các dịch vụ tích hợp như ghi âm, chụp hình, nối mạng, gắn nhạc chuông và hình nền phong phú, tán gẫu và gửi tin nhắn, nghe nhạc xem phim chơi game ... làm cho chiếc smartphone của chúng ta như khoác lên mình một bộ cánh lộng lẫy. Nhu cầu con người không dừng lại ở đó, mỗi năm hàng nghìn sản phẩm phần mềm được ra đời để phục vụ cho nhu cầu của con người. Và công việc kiểm thử lại càng khắt khe hơn bao giờ hết. Bài seminar của chúng tôi hy vọng với phần nào giúp các bạn hình dung về quy trình kiểm thử trên mobile là như thế nào.

Trước hết chúng tôi xin đưa ra các thuật ngữ/ Tên viết tắt được dùng trong bài viết này :

1. Tổng quan về vòng đời kiểm thử Mobile System

Mục đích:

• Xác định phạm vi và đối tượng của dự án, từ đó tạo kế hoạch tổng quát và các kế hoach chi tiết cho dự án.

• Đánh giá sơ bộ về chất lượng của của pre-installed apps và các chức năng của các app cơ bản được cài đặt (Pre-ST) để quyết định ST có thể bắt đầu khởi động.

• Thực thi test dựa trên TCs và test chức năng, phải đảm bảo rằng nó là bản được tạo mới hoặc cập nhật mới nhất.

• Thực thi strengthen test dựa trên TCs đã được cập nhật với những chức năng tìm được nhiều bugs ở ST1.

• Thực thi test dựa trên những TCs đã được lựa chọn từ ST1 để đảm bảo rằng các chức năng hoạy động ổn định và không có bug phát sinh do degrade.

• Close project.

Hoạt động chính:

• Ước lượng phạm vi và đối tượng của dự án.

• Ước lượng effort, kế hoạch …

• Tạo master plan và kế hoạch chi tết.

• Tạo Pre-TP và TC để thực thi Pre-ST.

• Tạo TP, FL, VP, VM, TM và TC để bao phủ UI.

• Dựng môi trường cần thiết và đảm bảo nó luôn sẵn sàng hoạt động tốt.

• Bắt đầu thực hiện full-test nếu 95-98% Pre-ST TCs pass.

• Dựa trên việc phân tích bugs của ST1, tạo TP, cập nhật TCs.

• Thực hiện test để phát hiện toàn bộ bugs của phần mềm.

• Tạo TP để chắc chắn rằng không có degrade bugs.

• Lựa chọn TCs từ ST1 để verify các chức năng cơ bản.

• Tổng quát, phân tích và close dự án.

• Bài học kinh nghiệm được rút ra.

Đầu vào:

• Yêu cầu của khách hàng

• Các sản phẩm được cung cấp bởi khách hàng, tools, specs, shedule, technical docs,...

• Yêu cầu của khách hàng, phạm vi và đối tượng test.

• Các sản phẩm được cung cấp bởi khách hàng.

• Kế hoạch phát triển

Đầu ra:

• WO

• Estimation

• Project plan

• CM plan

• Test Design: Pre-TP, TP, FL, VP, VM, TM

• Tạo TCs: TCs, test data

• Thực hiện test: Test Report, Test evidences, Bugs list, Bug analyst report

• Khác: Chi tiết plan, schedule

• Test Design: TP

• TC Creation: Test Report, Test evidences, Bugs list, Bug analyst report

2. Chi tiết

2.1 Test Design Process

Nghiên cứu

• UI specs

• List mục thay đổi

• TC được cung cấp ( nếu có)

• List bug của model cũ

Tạo Test policy

Tạo :

• List chức năng

• Quan điểm chung/ cá nhân

Tạo Volume matrix

2.1.1. Create Test policy

Định nghĩa tổng quan về test policy

Đầu vào:

• List các mục thay đổi so với phase trước
• UI Specs
• Test case khách hàng cung cấp (nếu có)
• Phân tích các lỗi đã xảy ra ở model cũ

Đầu ra:

• Phạm vi chức năng
• Số chức năng
• Số TCs cho mỗi chức năng
• Điều kiện khi tạo TCs
• Phương pháp tạo Tcs

2.1.2. Function list/viewpoint

Đầu vào:

• Test policy
• List chức năng của old model
• Phân tích các lỗi đã xảy ra ở model cũ

Đầu ra:

• List chức năng
• Quan điểm test

List chức năng / Quan điểm

Quan điểm chung: Tính chức năng, cấu trúc, khả năng tin cậy, độ bền, khả năng tương thích, khả năng mở rộng.

Quan điểm riêng: các sự kiện, trạng thái chỉ test cho application.

2.1.4. Volume matrix

Volume matrix là bảng số lượng TCs của từng viewpoint trên mỗi big function, mục đích xác định phương châm, chiến lược thực hiện test đối với từng big function.

Đầu vào:

• List chức năng
• Quan điểm chung
• Quan điểm riêng
• Phương châm chung
• Thông tin phân tích bug cũ
• Template Volume matrix
• Review checklist

Hoạt động:

Taọ Volume Matrix

Đầu ra

• Volume matrix
• Review record
• Review checklist

2.1.5. Test matrix

Test Matrix là 1 bảng kết hợp giữa function list và viewpoint, mục đích chỉ ra các scenarios/TCs được tạo cho chức năng cần thực hiện (function nào kết hợp với quan điểm nào)

Đầu vào:

• List chức năng
• Quan điểm chung
• Quan điểm riêng
• Phương châm chung
• Thông tin phân tích bug cũ
• Template Volume matrix
• Review checklist

Hoạt động:

Tạo Test matrix

Đầu ra:

• Test matrix
• Review record
• Review checklist

2.2. Test case creation process

Đầu vào:

• Tài liệu Test design
• Các sản phẩm được Khách hàng cung cấp: List các mục thay đổi so với phase trước, UI specs, TC được cung cấp bởi khách hàng ( nếu có)
• Danh sách các điều kiện môi trường cần thiết và dữ liệu test để thực hiện test
• Template testcase
• Tool generation test case
• Checklist review testcase

Hoạt động:

• Tạo testcase
• Tạo dữ liệu test

Đầu ra:

• Testcase
• Danh sách các điều kiện môi trường cần thiết và dữ liệu test để thực hiện test
• Test data
• Review records ( review checklist filled up, defects logged)

2.3 Test execution Process

ST1

• Kiểm tra không có gì bất thường xảy ra với tất cả các chức năng.
• Thực hiện xác minh hoạt động của các thao tác/chức năng cơ bản theo spec.
• Thực hiện xác minh spec của mobile về số lượng user data, các loại format support.

ST2

• Thực hiện việc xác minh hoạt động của các chức năng trên soft đã thực hiện.
• Về khả năng sử dụng(hoạt động theo spec, tầm nhìn trực quan, chờ pin), là đối tượng đánh giá các thông số kỹ thuật đặc biệt không được quy định.
• Từ điểm yếu của model cũ, tạo item thực hiện(Tăng cường function liên kết, test kết hợp...)
• Thực hiện free test cho các chức năng không có tài liệu specification.

ST3

• Xác định xem có bug degrade hay không.
• Kiểm chứng độ ổn định của mobile.

Đầu vào:

1. Policy thực hiện test chung
2. Các sản phẩm được Khác hàng cung cấp: UI specs, testcase
3. Test case được tạo / chọn bởi team STS ( system test specification)
4. Chuẩn bị môi trường và testdata
5. Test tool
6. Danh sách bug của phase trước

Hoạt động:

1. Tạo Policy test/ Plan test
2. Mở cuộc họp giao dịch về chính sách test
3. Mở cuộc họp giao dịch về testcase cho các tester
4. Mở cuộc họp về chính sách test, assign công việc cho test
5. Chuẩn bị môi trường
6. Thực hiện test
7. Tạo test report
8. Xác nhận test

Đầu ra:

1. Chính sách test (Test policy)
2. Plan test ( 1 phần của chính sách test)
3. Test report
4. List bug

2.4. Device management process

Quy trình Quản lý thiết bị được phân thành 4 quy trình nhỏ hơn:

1. Process with customer: miêu tả cách thức quản lý thiết bị từ khi KH gửi đến khi Admin, Manager confirm.
2. Internal Process: miêu tả cách thức mượn/trả thiết bị đối với các members trong dự án
3. External Process: miêu tả cách thức mượn/trả thiết bị đối với các members ngoài dự án.
4. Quy trình quản lý Micro SD: miêu tả cách thức mượn trả Micro SD (thiết bị lưu trữ rời, có khả năng gây thất thoát tài sản thông tin)

Kết luận:

Trên đây là qui trình kiểm thử trên mobile. Tùy vào tính chất của sản phẩm và qui trình sản xuất của mỗi công ty, qui trình trên có thể có nhiều hoặc ít loại test khác hơn. Hy vọng giúp ích cho các bạn trong công việc của mình.