Kế hoạch đảm bảo chất lượng phần mềm cho

hệ thống tính tiền điện cho hộ cá nhân

04/2021

1
Revision History

Descriptio
Version
Date n of Prepared by Approved by
no.
changes

Nguyễn Nguyễn Bá
Draft 1/3/2021 Initial draft
Thanh Phong Nhật

Phạm Minh Nguyễn Bá

1.0 6/4/2021 First release
Phúc Nhật

2
I. Giới thiệu 4

1. Phạm vi 4

2. Mục đích 4

3. Tham khảo 4

4. Thuật ngữ và định nghĩa 5

5. Vai trò 6

6. Các chuẩn và hướng dẫn 7

II. Phạm vi và ràng buộc 8

Phạm vi kiểm thử 8

Phạm vi không kiểm thử 14

Ràng buộc 14

III. Phương pháp kiểm thử 14

Chiến lược kiểm thử 14

Quy trình kiểm thử 17

Phương pháp kiểm soát 17

Testing convention 17

Kế hoạch kiểm thử 18

Kế hoạch báo cáo 18

Công cụ kiểm thử 19

Tiêu chuẩn kiểm thử 19

IV. Môi trường kiểm thử 19

3
I. Giới thiệu
1. Phạm vi
Kế hoạch này áp dụng cho tất cả giai đoạn trong dự án xây dựng hệ thống tính tiền điện.
Kế hoạch này luôn được duy trì trong suốt quá trình dự án và có thể được
duyệt và cập nhật nếu cần.
2. Mục đích
Kế hoạch này thiết lập các hoạt động SQA được thực hiện xuyên suốt trong
vòng đời dự án và chỉ ra các kỹ thuật tiêu chuẩn cho thực hiện các hoạt động
này.
Mục đích của kế hoạch SQA là xác minh rằng tất cả phần mềm và tài liệu
chuyển giao thỏa mãn yêu cầu kỹ thuật.
3. Tham khảo

Reference Origin Comments

[1] Phụ lục K, Murali

Chemuturi, Mastering software
quality assurance Best Practices, SQA team
Tools and Techniques for
Software Developers.

4
 [2] Đặc tả yêu cầu phần mềm:
Hệ thống tính tiền điện cho hộ Project team
cá nhân.

[3] IEEE Guide for Software

Quality Assurance Planning, SQA team
IEEE Std 730.1 – 1995.

[4]   IEEE Standard for

Software Quality Assurance SQA team
Plans, IEEE Std 730 – 1998.

4. Thuật ngữ và định nghĩa

Term/acronym Definition/full form

SQA Software Quality Assurance

SQA Mgr SQA Manager

Prog Mgr Program Manager

Proj Mgr Project Manager

SCM Software Configuration Management

Sys Eng System Engineering

SW Dev Software Developer

SW Test Software Test

Sys Test System Test

Logistics Bộ phận hậu cần

5
 SDP Software Development Plan

CRLCMP Computer Resource Life Cycle Management Plan

SDL Software Development Library

SDFs Software Development Files

STR Software Trouble Report

CSCI Computer Software Configuration Item

KPA Key Process Area

SQAP
SQA Plan

IEEE Institute of Electrical and Electronic Engineers

5. Vai trò
4.1. Vai trò

No. Tên thành viên Vai trò

1 Nguyễn Bá Nhật SQA Manager

2 Nguyễn Thanh Phong Program Manager

3 Phạm Minh Phúc Project Manager

4 ... Software Configuration Management

5 System Engineering

6 Software Developer

7 Software Test

6
 8 System Test

9 … Logistics

6. Các chuẩn và hướng dẫn

Project area Reference to applicable standard or guideline

Documentation
Tuân theo các chuẩn của IEEE
standards

Design standards Sử dụng UML

Coding standards Java 1.8, Java Documentation, MVC, lập trình hướng đối tượng

Comment standards Sử dụng các chuẩn comment trong Java, HTML, XML

Testing standards IEEE – chuẩn cho tài liệu kiểm thử phần mềm

- Độ dài phương thức không quá 30 dòng lệnh.

- Một phương thức không nên có nhiều hơn 7 tham số.
Metrics
- Độ sâu tối đa của các lệnh if-else lồng nhau phải nhỏ hơn 4.
- Độ sâu tối đa của các vòng lặp lồng nhau phải nhỏ hơn 3.

II. Phạm vi và ràng buộc

1. Phạm vi kiểm thử
- Giai đoạn và kiểu kiểm thử

STT Giai đoạn kiểm Kiểu kiểm thử Ghi chú

thử
Chức năng Hiệu năng Bảo mật
1 Kiểm thử hệ x x x N/A
thống

7
 2 Kiểm thử đơn vị x x x N/A

- Kiểm thử chức năng

STT Tên module Mức Kiểu kiểm thử Giai đoạn kiểm
độ ưu thử
tiên

EMS01 Thông báo khách hàng 1 GUI & Unit testing,

qua mail functional test system testing

EMS02 Theo dõi danh sách 1 GUI & Unit testing,

functional test system testing

EMS0201 Theo dõi danh sách nợ 1 GUI & Unit testing,

functional test system testing

EMS0201 Theo dõi danh sách không 1 GUI & Unit testing,
nợ functional test system testing

EMS0203 Theo dõi top 100 người 1 GUI & Unit testing,
dùng nhiều điện nhất functional test system testing

EMS0204 Theo dõi top 100 người 1 GUI & Unit testing,
dùng ít điện nhất functional test system testing

EMS03 Quản lý hộ cá nhân 1 GUI & Unit testing,

functional test system testing

EMS0301 Thêm hộ cá nhân 1 GUI & Unit testing,

functional test system testing

EMS0302 Tìm kiếm hộ cá nhân 2 GUI & Unit testing,

functional test system testing

EMS0303 Sửa hộ cá nhân 1 GUI & Unit testing,

functional test system testing

EMS0304 Xóa hộ cá nhân 2 GUI & Unit testing,

functional test system testing

EMS04 Quản lý điện 1 GUI & Unit testing,

functional test system testing

8
 EMS0401 Sửa giá điện 1 GUI & Unit testing,
functional test system testing

EMS0402 Sửa thuế VAT 1 GUI & Unit testing,

functional test system testing

EMS0403 Sửa lượng điện tiêu thụ 1 GUI & Unit testing,
functional test system testing

EMS05 Quản lý người quản lý 1 GUI & Unit testing,

functional test system testing

EMS0501 Thêm người quản lý 1 GUI & Unit testing,

functional test system testing
EMS0502 Tìm kiếm người quản lý 2 GUI & Unit testing,
functional test system testing

EMS0503 Sửa người quản lý 1 GUI & Unit testing,

functional test system testing

EMS0504 Xóa người quản lý 2 GUI & Unit testing,

functional test system testing

- Kiểm thử phi chức năng

ST Các yêu cầu kiểm thử
T phi chức năng
1 Yêu cầu về tính đúng
đắn
Nội dung Kiểu kiểm Giai đoạn
thử kiểm thử
Kiểm thử hiệu Functional
Khi thực hiện các năng, kiểm thử testing
chức năng thêm hộ cá luồng nghiệp
nhân, sửa hộ cá nhân, vụ
thêm người quản lý,
sửa người quản lý,
thông tin người dùng
nhập vào cần phải
được kiểm tra. Cần
kiểm tra số CMT,
SĐT, Email xem có
thực hay không; kiểm

9
 tra Username,
Password xem đã tồn
tại hay chưa. Giá điện
phải là một số nguyên
dương, đơn vị là vnđ /
kWh. Thuế VAT là số
thập phân với phần
thập phân gồm 2 chữ
số, đơn vị là %.
Lượng điện tiêu thụ là
số nguyên dương,
đơn vị là kWh. Số
tiền điện phải là một
số nguyên dương,
đơn vị là vnđ. Thời
gian hệ thống tính ra
số tiền điện tối đa là 2
giây. Thời gian load
xong 1 trang web tối
đa là 15 giây.

2 Yêu cầu về tính tin cậy N/A N/A

Tổng số bugs trong
hệ thống không được
vượt quá 1% tổng số
dòng code. Tỷ số thời
gian hệ thống ngừng
hoạt động trên thời
gian hệ thống hoạt
động là 0.2%. Thời
gian trung bình giữa 2
lần xảy ra lỗi (MTBF)
là 2 năm. Thời gian
trung bình để sửa lỗi
(MTTR) là 60 phút.

3 Yêu cầu về tính hiệu Kiểm thử hiệu Functional

quả - Sử dụng 3 server để năng, kiểm thử testing
nhận yêu cầu từ luồng nghiệp
người dùng, mỗi vụ, kiểm thử
server có tối thiểu

10
 dữ liệu
16GB RAM. Sử dụng
3 server khác chứa
các bản sao dữ liệu
của hệ thống, mỗi
server có tối thiểu
20TB dung lượng ổ
cứng.

- Hệ thống hoạt động

tốt với tốc độ mạng
internet là 2 Mbps.

4 Yêu cầu về tính toàn Kiểm thử bảo Functional

vẹn - Sử dụng Username mật, kiểm thử testing
và Password để xác luồng nghiệp
thực người dùng. vụ
- Người dùng được
phân quyền. Hộ cá
nhân chỉ có các
quyền: xem thông tin,
nộp tiền điện online.
Người quản lý có các
quyền: xem thông tin,
cấu hình, gửi thông
báo, xuất hóa đơn.

- Sử dụng giao thức

HTTPS/TLS.

- Mật khẩu được mã

hóa MD5 trước khi
lưu vào database.

- Hệ thống được bảo

vệ khỏi tấn công chèn
mã SQL.

5 Yêu cầu về tính khả Giao diện thân thiện, Kiểm thử giao Functional

11
 dụng rõ ràng, dễ hiểu: các diện người testing
màn hình đảm bảo dùng
tính đồng nhất, nhất
quán; các biểu tượng
đồ họa đồng nhất; hỗ
trợ kiểm soát dữ liệu
đầu vào; hỗ trợ font
giao diện theo chuẩn
Unicode.

Cung cấp giao diện

người dùng nền tảng
web-base, thiết bị di
động và hỗ trợ các
trình duyệt web phổ
biến sau:
- Chrome
- Firefox
- Internet
Explorer
- Safari

Nhân viên mới có thể

sử dụng thành thạo
sau 1 ngày.

Một nhân viên có thể

xử lý 10 giao dịch /
60 phút.

Hệ thống có chức
năng “Trợ giúp” nơi
người dùng có thể
đọc hướng dẫn sử
dụng.

6 Yêu cầu về tính linh Phần mềm có thể dễ Kiểm thử chức Functional
hoạt dàng mở rộng, thêm năng test
tính năng mới. Phần
mềm có thể dễ dàng
chỉnh sửa lại để tạo
ra các phần mềm

12
 khác tương tự như:
phần mềm tính điểm
sinh viên, phần
mềm nộp học phí,…

7 Yêu cầu về tính bảo trì Lập trình hướng đối Kiểm thử dữ Maintenance
được tượng theo kiến trúc liệu, kiểm thử test
MVC.Đặt tên lớp, tên luồng nghiệp
biến, tên phương thức vụ
có ý nghĩa, dễ hiểu. Sử
dụng comment khi
code. Tuân thủ các
chuẩn coding cho ngôn
ngữ lập trình đang sử
dụng. Một phương thức
không quá 30 dòng
lệnh.

8 Yêu cầu về tính kiểm Ghi lại các kết quả N/A Non -
thử được tính toán trung gian. Functional
Sử dụng file log. test

9 Yêu cầu về tính di Kiểm thử khi System test

động Hệ thống cần hoạt cài đặt chương
động trên môi trường trình
web và chỉ ảnh hưởng
bởi mạng internet,
không ảnh hưởng khi
chuyển đổi giữa các
môi trường mobile,
tablet, computer,…
hay các hệ điều hành
khác nhau (Window,
Linux, MacOS,…) sẽ
không có gì ảnh
hưởng tới hệ thống.

10 Yêu cầu về tính tái sử Kiểm thử khi System test

dụng Hệ thống gồm các cài đặt chương
chức năng:Thông trình
báo, Theo dõi danh

13
 sách, Quản lý hộ cá
nhân, Quản lý điện,
Quản lý người quản
lý, Xuất báo cáo; và
các chức năng này
đều có khả năng tái
sử dụng cho các hệ
thống khác

11 Yêu cầu về tính tương Kiểm thử khi System test

thích - Phần mềm cần giao cài đặt chương
tiếp tốt với hệ thống trình
ngân hàng.

- Website phải tuân

theo kiến trúc hướng
dịch vụ.

- Sử dụng API.

2. Phạm vi không kiểm thử

STT Tên module chức năng Ghi chú

1 Báo cáo Xuất báo cáo Chức năng chưa được phát
triển

3. Ràng buộc
N/A

III. Phương pháp kiểm thử

1. Chiến lược kiểm thử

1.1. Kiểm thử giao diện người dùng

Kiểm thử giao diện người dùng (UI) mục đích là kiểm tra so sánh giao diện phát
triển với thiết kế ban đầu và yêu cầu của khách hàng, đảm bảo hoạt động của các

14
thành phần trên giao diện. Bên cạnh đó cần đảm bảo tính thẩm mỹ, tiện dụng cho
người dùng.

Mục đích Mục đích đảm bảo:

- Việc sử dụng thông qua mục
tiêu kiểm thử phản ánh đúng các
chức năng và yêu cầu nghiệp
vụ, bao gồm màn hình đến màn
hình, trường đến trường và sử
dụng các phương pháp truy cập
(phím tab, di chuột, tổ hợp
phím)
- Các đối tượng và thuộc tính
màn hình như: menus, size,
position, state và tập trung vào
việc tương thích yêu cầu
Cách thực hiện Tạo ra và chỉnh sửa kịch bản kiểm thử
cho mỗi màn hình để kiểm tra việc sử
dụng đúng cách và tình trạng các đối
tượng cho mỗi màn hình và đối tượng
của ứng dụng

Kiểm tra giao diện hiển thị dựa trên

đúng các điều kiện môi trường và cấu
hình yêu cầu.

Điều kiện hoàn thành Mỗi màn hình được kiểm tra đảm bảo
đúng với phiên bản kiểm tra hoặc
phạm vi chấp nhận được.
Lưu ý Việc hiển thị các trường thông tin trên
màn hình có thể gắn với phân quyền
người dùng

1.2. Kiểm thử luồng nghiệp vụ

Kiểm thử luồng căn cứ trên các yêu cầu của các tài liệu đặc thù của ứng dụng.
Mục tiêu là kiểm tra tính đúng đắn của các dữ liệu, quy trình và báo cáo cũng như
thực hiện đúng những quy tắc nghiệp vụ.

15
 Mục đích Kiểm thử luồng nghiệp vụ để đảm bảo
các công thức tính toán và ràng buộc
xử lý đúng không, luồng nghiệp vụ
đúng không, quá trình xử lý và đầu ra
đúng không, phục hồi được dữ liệu
không

Cách thực hiện Sử dụng các công thức, dữ liệu,... hợp

lệ và không hợp lệ để đưa ra kết quả
mong đợi và cảnh báo với kết quả
không mong đợi, kiểm tra các quy tắc
nghiệp vụ có thỏa mãn không
Điều kiện hoàn thành Toàn bộ kế hoạch kiểm thử được thực
hiện
Các vấn đề đặc biệt Mô tả các vấn đề ảnh hưởng đến việc
kiểm thử chức năng

1.3. Kiểm thử dữ liệu và tích hợp dữ liệu

Cơ sở dữ liệu (CSDL) và việc xử lý CSDL phải đảm bảo đúng với thiết kế dữ liệu
đã thống nhất. Nghiên cứu thêm về hệ quản trị dữ liệu (DBMS) để xác định các
công cụ và kỹ thuật có thể hỗ trợ cho việc kiểm thử.

Mục đích Đảm bảo các thao tác lưu trữ, sửa đổi,
truy vấn dữ liệu được trả lại đúng như
đặc tả

Cách thực hiện Kiểm tra thiết kế CSDL

Thực hiện truy vấn, sửa đổi,... để đảm
bảo dữ liệu trả về đúng
Điều kiện hoàn thành Tất cả các phương pháp truy cập và
chức năng xử lý đều giống thiết kế và
không có sai lệch về dữ liệu

Các vấn đề đặc biệt Cần có kiến thức về DBMS

16
1.4. Kiểm thử hiệu năng

Kiểm thử hiệu năng nhằm kiểm tra và đánh giá thời gian phản hồi, tỉ lệ giao dịch
và các yêu cầu liên quan tới thời gian khác. Mục tiêu của kiểm thử hiệu năng là để
xác minh các yêu cầu về hiệu năng.

Mục đích Xác minh hiệu năng của các hành vi cho các giao
dịch đã thiết kế hoặc chức năng nghiệp vụ:
- thời gian email gửi tới khách hàng
- thời gian thống kê khách hàng
…..
Cách thực hiện Sử dụng các testcases đã viết cho từng chức năng

Điều kiện hoàn thành Mỗi chức năng hoàn thành công việc mà không bị
lỗi ngoài liên quan tới vấn đề hiệu năng

Các vấn đề đặc biệt Có một số cách để thực hiện:

- Tạo các người dùng ảo để mô phỏng nhiều
người dùng , có thể sử dụng các công cụ
mô phỏng
- sử dụng nhiều người dùng thật, mỗi người
chạy các test scripts ở một địa điểm
Kiểm thử hiệu năng nên được chạy trên một máy
điển hình vào thời gian điển hình để có đánh giá
chính xác
Cơ sở dữ liệu dùng để kiểm thử hiệu năng nên có
kích thước lớn.

1.5. Kiểm thử bảo mật và truy cập

Kiểm thử bảo mật và truy cập có 2 mục tiêu:

- Bảo mật mức ứng dụng, bao gồm truy cập tới dữ liệu hoặc các tính năng
nghiệp vụ. Bảo mật mức ứng dụng đảm bảo chỉ người được phân quyền
mới có quyền truy cập dữ liệu hoặc tính năng tương ứng.

17
 - Bảo mật mức hệ thống, bao gồm đăng nhập vào hệ thống hoặc truy cập hệ
thống từ xa. Bảo mật mức hệ thống đảm bảo là chỉ người dùng được cấp
phép được quyền truy cập vào hệ thống.

Mục đích Bảo mật mức ứng dụng đảm bảo chỉ người được
phân quyền mới có quyền truy cập dữ liệu hoặc
tính năng tương ứng.

Bảo mật mức hệ thống đảm bảo là chỉ người dùng

được cấp phép được quyền truy cập vào hệ thống.

Cách thực hiện Bảo mật mức ứng dụng: xác định và liệt kê với
mỗi loại người dùng các chức năng, dữ liệu được
quyền truy cập
Tạo ca kiểm thử cho mỗi loại người dùng và xác
minh quyền bằng cách tạo các transactions cho
từng loại người dùng
Chỉnh sửa loại người dùng và chạy lại ca kiểm thử
cho đúng người dùng đó. Sau đó xác minh các
chức năng, dữ liệu thay đổi có được thêm/xóa
chính xác hay không.
Điều kiện hoàn thành Với mỗi loại người dùng, các chức năng và dữ liệu
được truy cập hoạt động đúng
Các vấn đề đặc biệt Truy cập vào hệ thống phải được review với mạng
thích hợp hoặc quản trị hệ thống. Kiểm thử này có
thể không cần thiết nếu là một tính năng của mạng
hoặc systems administration.

2. Quy trình kiểm thử

● Bước 1: xây dựng checklist chung cho toàn dự án, SQA manager review
● Bước 2 : chia từng chức năng và xây dựng test cases cho từng chức năng,
Program manager review
● Bước 3: các thành viên project thực hiện test.
3. Phương pháp kiểm soát
Việc kiểm soát lỗi được đề xuất như sau:

Công cụ log bug: Excel + Skype + Redmine

18
 Quy trình kiểm soát lỗi:

- Step 1: Tester log lỗi vào Redmine

- Step 2: Tester skype với DEV để nhắc check bug trên Redmine & trao đổi
trong quá trình sửa lỗi.
- Step 3: Dev & Tester làm việc, update bug lên Redmine theo quy trình sửa
lỗi.
4. Testing convention
- Quy tắc đặt mã test cases: T<mã chức năng>_<tên chức năng viết
tắt>_<số>
- Quy tắc đặt tên file test cases: <TC>_<mã chức năng>_<tên chức
năng>_<ngày tháng>_v<version>
- Quy tắc đặt tên sheets: <đánh số>_<mô tả>
- Thống nhất template test cases: check file template đính kèm.
- Thống nhất template Test report: check file template đính kèm.
- Check list review test cases cho từng loại test ở các mục 1.x trong phần
Chiến lược kiểm thử : check file template đính kèm.
- Template để chuẩn bị data test: check file template đính kèm.
5. Kế hoạch kiểm thử
STT NHIỆM VỤ NGƯỜI THỰC HIỆN
1 Unit test, system test, selenium test cho Phạm Minh Phúc
chức năng thông báo cho khách hàng qua
mail

2 Unit test, system test, selenium test cho Nguyễn Thanh Phong
chức năng theo dõi danh sách, quản lý hộ
cá nhân.
3 Unit test, system test, selenium test cho Nguyễn Bá Nhật
chức năng quản lý người quản lý, quản lý
điện

19
6. Kế hoạch báo cáo
STT Loại báo cáo Thời gian báo Hình thức Người Người
cáo báo cáo báo cáo nhận báo
cáo

1 Báo cáo định kỳ 1 tuần/lần Email Project SQA

manager manager

2 Báo cáo kết thúc Khi kết thúc kiểm Email Project SQA
chức năng thử 1 chức năng manager manager

3 Báo cáo kết thúc Khi kết thúc giai Email Project SQA
giai đoạn đoạn manager manager
4 Báo cáo kết thúc Khi kết thúc dự án Email Project SQA
dự án manager manager,
Đỗ Thị
Bích Ngọc

7. Công cụ kiểm thử

STT Công cụ Mục đích Ghi chú
1 Microsoft Office Lịch trình N/A

2 Trình duyệt web : Chrome Thực hiện kiểm thử trên trình N/A
duyệt

3 Excel Quản lý lỗi N/A

4 Email Quản lý lỗi, trao đổi nghiệp N/A
vụ với dự án, kiểm thử chức
năng

5 Skype Quản lý lỗi, trao đổi nghiệp N/A

vụ với dự án

6 Jmeter Kiểm thử hiệu năng N/A

7 Selenium Kiểm thử hiệu năng N/A

20
 8. Tiêu chuẩn kiểm thử
- Điều kiện bắt đầu kiểm thử: Kế hoạch kiểm thử đã thống nhất; Dự án đã hoàn
thành review code và self check cho module tương ứng; Dự án hoàn thành cài đặt
server và giao cho nhóm test chức năng cần kiểm tra.
- Điều kiện dừng quá trình kiểm thử: Đạt ngưỡng kiểm thử thành công;
Hủy/ngừng dự án; Hết thời hạn kiểm thử
- Tiêu chuẩn kiểm thử thành công: 100% Integration test case được thực hiện;
95% lỗi đã đóng và không còn lỗi Fatal hay Serious còn mở;
- Điều kiện thực hiện kiểm thử hồi quy: Khi có sự thay đổi về mã nguồn hay môi
trường phần mềm

IV. Môi trường kiểm thử

1. Máy chủ
- Máy chủ kiểm thử độc lập với máy chủ phát triển của hệ thống
2. Máy trạm
- Cấu hình: N/A
- Windows: window 7, window 10
- Trình duyệt: chrome, microsoft edge
3. Đường truyền

N/A

4. Khác

N/A

V. Lịch trình kiểm thử

1. Lịch trình

Kiểm thử dự án ngay khi hoàn thành 1 function

2. Mốc kiểm thử

STT Nội dung công việc Dự kiến bắt đầu Dự kiến kết thúc

1 Lập kế hoạch kiểm thử 21-02-2021 30-02-2021

21
2 Kiểm thử giao diện chính 15-03-2021 15-05-2021
3 Kiểm thử module Quản lý người 17-03-2021 17-05-2021
quản lý
4 Kiểm thử module Quản lý điện 17-03-2021 17-05-2021

5 Kiểm thử module Quản lý hộ cá 18-03-2021 18-05-2021

nhân

6 Kiểm thử module Theo dõi danh 20-03-2021 20-05-2021

sách

7 Kiểm thử module Gửi email cho 21-03-2021 21-05-2021

khách hàng

22