1. Trang chủ
  2. » Giáo Dục - Đào Tạo

Service directory kế hoạch kiểm thử

25 0 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Service Directory Kế Hoạch Kiểm Thử
Tác giả Trần Văn A, Nguyễn Văn C, Trần Thị D
Trường học Hà Nội
Thể loại kế hoạch kiểm thử
Năm xuất bản 2018
Thành phố Hà Nội
Định dạng
Số trang 25
Dung lượng 119,98 KB

Nội dung

Unit Test Kiểm thử Mức đơn vị: Mục đích: Đảm bảo tính chính xác của dữ liệu và chức năng ở mức đơn vị nhỏ nhất của trang web.. 06 SPT4-06 Quản lý tài khoản Test GUI 07 SPT4-07 Xem danh s

Trang 1

Hà Nội - 01-2018

Trang 2

bản mới

Trang 3

TRANG KÝ

Người lập: <Ngày>

Trang 4

MỤC LỤC

3.1.3 Test Bảo mật và Kiểm soát truy cập (Security and Access Control Testing) 18

Trang 5

1 GIỚI THIỆU

1.1 Mục đích

Mục đích của tài liệu này là cung cấp hướng dẫn về kiểm thử cơ bản cho một trang web thương mại điện tử chuyên bán đồ thể thao Tài liệu được tổ chức thành các phần sau:

1 Giới thiệu: Trình bày mục đích và tổ chức của tài liệu.

2 Phân tích yêu cầu: Xác định các yêu cầu cơ bản của trang web.

3 Chuẩn bị môi trường kiểm thử: Hướng dẫn cách chuẩn bị môi trường để thực

hiện các bước kiểm thử.

4 Kiểm thử chức năng: Hướng dẫn về việc kiểm tra các chức năng cơ bản của

trang web.

5 Kiểm thử tương thích: Hướng dẫn kiểm tra tính tương thích của trang web trên

các trình duyệt và thiết bị khác nhau.

6 Kiểm thử hiệu suất: Hướng dẫn về việc đánh giá hiệu suất của trang web trong

điều kiện tải trọng.

7 Báo cáo và đánh giá: Hướng dẫn về việc tạo báo cáo sau khi hoàn thành kiểm

thử và đánh giá kết quả.

1.2 Thông tin chung

Mục đích kiểm tra phần mềm của trang web thương mại điện tử bán đồ thể thao là tìm ra càng nhiều lỗi càng tốt để phục vụ cho việc phát triển và cải thiện trang web Phạm vi kiểm tra bao gồm các mục sau:

** Test chức năng:

Trang 6

 Test chức năng cơ bản của trang web, bao gồm các tính năng như tìm kiếm sản phẩm, thêm vào giỏ hàng, thanh toán, và quản lý tài khoản người dùng.

 Test giao diện người sử dụng để đảm bảo tính thẩm mỹ và tính nhất quán của trang web trên các thiết bị và màn hình khác nhau.

 Test dữ liệu và tích hợp dữ liệu để đảm bảo tính chính xác của thông tin hiển thị và lưu trữ trên trang web.

 Test chu trình nghiệp vụ để đảm bảo rằng các quy trình kinh doanh như đặt hàng, giao hàng, và quản lý kho hoạt động một cách mượt mà.

** Test chức năng không phụ thuộc vào chức năng:

 Kiểm tra tính sẵn sàng của trang web khi đối mặt với các tình huống bất thường hoặc không được dự đoán trước.

** Test hiệu suất:

 Đánh giá hiệu suất của trang web thông qua việc đo lường thời gian tải trang, tải trọng của trang web dưới nhiều điều kiện khác nhau, bao gồm cả điều kiện tải trọng cao và căng thẳng.

 Thực hiện kiểm tra về hiệu suất bằng cách tiến hành các phương pháp như Performance Profiling, Load Testing, Stress Testing và Volume Testing.

** Test Bảo mật và Kiểm soát truy cập:

 Kiểm tra các biện pháp bảo mật của trang web để đảm bảo tính

an toàn của thông tin cá nhân và giao dịch của người dùng.

 Xác minh tính bảo mật của các tính năng như đăng nhập, thanh toán và quản lý tài khoản.

Trang 7

** Test hồi qui:

 Kiểm tra xem các cập nhật và thay đổi trên trang web có ảnh hưởng đến các tính năng hiện có hay không.

 Đảm bảo rằng các tính năng đã kiểm tra trước đó vẫn hoạt động đúng sau khi có sự thay đổi trong mã nguồn hoặc cơ sở dữ liệu.

1.3 Tài liệu liên quan ( chưa lam )

Phạm vi Test cho Website Thương mại điện tử Bán đồ Thể thao

1 Giai đoạn kiểm tra:

a Unit Test (Kiểm thử Mức đơn vị):

Mục đích: Đảm bảo tính chính xác của dữ liệu và chức năng ở mức đơn vị nhỏ nhất của trang web.

Phạm vi: Kiểm tra từng hàm, thủ tục, lớp hoặc phương thức của trang web.

Loại kiểm thử: Test case được thực hiện để đảm bảo tính chính xác và hoạt động của mỗi đơn vị.

b Integration Test (Kiểm thử tích hợp):

Trang 8

Mục đích: Kiểm tra tích hợp các thành phần thành một hệ thống hoàn chỉnh.

Phạm vi: Kiểm tra tích hợp các đơn vị đã qua Unit Test thành các hệ thống nhỏ và hệ thống hoàn chỉnh.

Loại kiểm thử: Kiểm thử cấu trúc, chức năng, hiệu suất và khả năng chịu tải.

c System Test (Kiểm thử mức hệ thống):

Mục đích: Đánh giá toàn bộ hệ thống và kiểm tra xem nó có đáp ứng được yêu cầu và chất lượng không.

Phạm vi: Đánh giá hoạt động, thao tác, sự tin cậy và các yêu cầu khác của hệ thống.

Loại kiểm thử: Kiểm thử chức năng, hiệu suất, khả năng chịu tải, bảo mật và khả năng phục hồi.

d Acceptance Test (Kiểm thử chấp nhận sản phẩm):

Mục đích: Chứng minh rằng sản phẩm đáp ứng được tất cả yêu cầu của khách hàng.

Phạm vi: Thực hiện bởi khách hàng hoặc một nhóm thứ ba được ủy quyền.

Loại kiểm thử: Tương tự như System Test nhưng tập trung vào sự chấp nhận của khách hàng.

o b ng test ch c n ngảng test chức năng ức năng ăng

01 SPT4-01 Tìm kiếm sản phẩm Test GUI

02 SPT4-02 Thêm sản phẩm vào giỏ hàng Test GUI

03 SPT4-03 Thanh toán Test GUI

Trang 9

06 SPT4-06 Quản lý tài khoản Test GUI

07 SPT4-07 Xem danh sách sản phẩm Test function

08 SPT4-08 Xem chi tiết sản phẩm Test function

09 SPT4-09 Quản lý đơn hàng Test function

10 SPT4-10 Quản lý danh mục sản phẩm Test function

1.5 Ràng buộc

 Đảm bảo website chạy được trên Win 2003, XP phiên bản sau cùng sử dụng browser IE6, IE7 và FireFox

 Mọi thành viên trong nhóm đều phải đảm bào hoàn thành lịch trình trong Testplanv1.0

 Mọi vấn đề phát sinh trong quá trình Test cần phải liên hệ với nhóm trưởng để tìm giải pháp

và phải báo cáo thường xuyên những vấn đề này

 Thành viên tham gia đầy đủ các buổi hướng dẫn Test cũng như đưa ra nhận xét cho từng module trong Website thương mại điện tử bán đồ thể thao của bản thân và của các thành viênkhác

1.6 Liệt kê các mạo hiểm

phòng ngừa

Mức độ ảnh hưởng (MD)

- Sử dụng công cụ quảng test chức năngn lý

dự án như Trello để theo dõi và phân công công việc

Cao

2 Thời gian làm việc cá nhân

không đồng nhất

- Thiết lập lịch trình làm việc chung và đề xuất thời gian hợp lý cho mỗi nhiệm vụ

cao

Trang 10

- Theo dõi tiến độ công việc và thúc đẩy sự chia sẻ

và hợp tác giữa các thành viên

3 Thiếu sự hợp tác và giao

tiếp giữa các thành viên

- Tạo môi trường mở cửa

và khích lệ sự trao đổi ý kiến và ý tưởng

- Sử dụng các phương tiện truyền thông như Zoom, Google Meet để giao tiếp

từ xa

Trung bình

4 Thiếu sự hiểu biết về công

nghệ hoặc kỹ năngng cần thiết

- Tổ chức năngc buổi học nhóm hoặc tìm kiếm tài liệu tham khảng test chức năngo để học hỏi - Phân chia công việc dựa trên sở thích

và kỹ năngng của từng thành viên

Design TC 2 MD Test function

phẩm

Design TC 1 MD Test function

09 SPT4-09 Quản lý đơn hàng Design TC 1 MD Test function

10 SPT4-10 Quản lý danh mục Design TC 2 MD Test function

Trang 11

sản phẩm

3 CHIẾN LƯỢC TEST

<Chiến lược test giới thiệu phương án tiếp cận để test các mục tiêu test

Những vấn đề chính trong chiến lược test là các kỹ thuật được áp dụng và điều kiện để biết

khi nào việc test được hoàn thành.

Mô tả các kiểu test dùng trong dự án

Có thể liệt kê với mỗi kiểu test tương ứng test cho chức năng nào1

Việc test có thể dừng khi nào

<Đối với mỗi kiểu test phải giải thích kỹ thuật, điều kiện hoàn thành và các vấn đề đặc

biệt liên quan.

Kỹ thuật: Kỹ thuật phải mô tả việc test được thực hiện như thế nào, bao gồm cả những gì sẽ

được test, các hoạt động chính sẽ được thực hiện trong quá trình test và các phương phápdùng để đánh giá kết quả

Điều kiện hoàn thành: Điều kiện hoàn thành được phát biểu nhằm hai mục đích:

- Xác định chất lượng sản phẩm được chấp nhận

- Xác định thời điểm mà các nỗ lực test được thực hiện thành công

Một điều kiện hoàn thành được phát biểu rõ ràng phải bao gồm:

1 Chỉ dành cho tester FIS-HCM khi lập tài liệu kế hoạch test

Trang 12

- Chức năng, hoạt động hoặc các điều kiện được tính toán

- Phương pháp tính toán

Điều kiện hoặc mức độ thích ứng với phép đo

Các vấn đề đặc biệt: Phần này phải chỉ ra các ảnh hưởng hoặc phụ thuộc có thể tác động

hoặc ảnh hưởng đến nguồn lực test mô tả trong chiến lược Các ảnh hưởng có thể bao gồm:Nhân công (ví dụ sự sẵn sàng hoặc cần thiết của các nguồn lực khác test để hỗ trợ/tham giatrong test); các ràng buộc (ví dụ hạn chế về thiết bị hoặc sự sẵn sàng hoặc cần thiết/thiếu cácthiết bị đặc biệt); các yêu cầu đặc biệt (ví dụ lịch test hoặc truy cập vào hệ thống)

Một ví dụ về mô tả kiểu test:

Trong giai đoạn đầu tiện, các UC 1-4 và 12 sẽ được test, theo hình thức sau:

UC 1 bắt đầu với tác nhân đã truy cập thành công vào ứng dụng và tại cửa sổ chính, và kết thúc khi người dùng xác định SAVE.

Mỗi TC sẽ được tiến hành và thực hiện bằng cách sử dụng Rational Robot.

Việc kiểm tra và đánh giá việc thực hiện mỗi TC sẽ được thực hiện theo phương pháp sau: Thực hiện Test script (Mỗi test script có được thực hiện thành công như mong muốn không?)

Tình trạng Window hoặc phương pháp kiểm tra Object Data (tiến hành trong các test script) sẽ được dùng để kiểm tra sự hiển thị của các màn hình chính và dữ liệu được xác định được nắm bắt/hiển thị bởi mục tiêu test trong khi thực hiện test.

Cơ sở dữ liệu của các mục tiêu test (sử dụng Microsoft Access) sẽ được kiểm tra trước khi test và kiểm tra lại sau khi test để kiểm chứng rằng các thay đổi thực hiện trong quá trình test đã được phản ánh chính xác trong dữ liệu.

Trang 13

Với mỗi UC, xác định một tập các giao dịch, như định nghĩa trong tài liệu phân tích workload, sẽ được tiến hành và thực hiện bằng Rational Suite Performance Studio và Rational Robot (GUI scripts)

Ít nhất 3 workload được phản ánh trong test script và lịch trình thực hiện test, bao gồm: Stressed workload: 750 người dùng (15 % quản lý, 50 % bán hàng, 35 % marketing) Peak workload: 350 người dùng (10 % quản lý, 60 % bán hàng, 30 % marketing)

Nominal workload: 150 người dùng (2 % quản lý, 75% bán hàng, 23 % marketing)

Test script dùng để thực hiện mỗi giao dịch sẽ bao gồm bộ đếm thời gian tương tự để đo thời gian phản hồi, ví dụ tổng thời gian giao dịch (như định nghĩa trong tài liệu phân tích workload), và các hoạt động giao dịch chính hoặc thời gian xử lý.

Test script sẽ thực hiện các workload trong 1 giờ (trừ phi được ghi chú khác trong tài liệu phân tích workload).

Kiểm tra và đánh giá việc thực hiện mỗi thực hiện test (của một workload) bao gồm:

Thực hiện test được theo dõi bằng biểu đồ trạng thái (để xác định rằng việc test và workload được thực hiện như mong muốn)

Thực hiện test script (mỗi test script có được thực hiện thành công như mong đợi không?) Ghi nhận và đánh giá thời gian phản hồi đã định nghĩa bằng các báo cáo sau:

− Performance Percentile

− Response Time

Điều kiện hoàn thành:

Tất cả các TC có trong kế hoạch đều đã được thực hiện

Tất cả các lỗi được xác định phải được ghi nhận vào một giải pháp đã thỏa thuận (All identified defects have been addressed to an agreed upon resolution)

Tất cả các TC có trong kế hoạch đã được thực hiện lại và toàn bộ các lỗi mở đã được ghi nhận như đã thỏa thuận và không có lỗi mới nào được phát hiện

Hoặc

Toàn bộ các TC đặt mức ưu tiên cao đều đã được thực hiện

Toàn bộ các lỗi tìm thấy đều được ghi nhận vào một giải pháp đã thỏa thuận

Trang 14

Toàn bộ các lỗi có trọng số 1 và 2 đều được giải quyết

Tất cả các TC có mức ưu tiên cao đều đã được thực hiện lại và toàn bộ các lỗi mở đã được ghi nhận như đã thỏa thuận và không có lỗi mới nào được phát hiện

Các vấn đề đặc biệt

nhật và làm tươi dữ liệu test

- Việc test hiệu suất hệ thống sử dụng máy chủ trong mạng hiện tại (có hỗ trợ cả các giao dịch khác không thuộc việc test) Việc test sẽ phải được lập lịch vào những giờ không còn các giao dịch khác trên mạng.

chức năng có thể được tiến hành và thực hiện

- Việc test có thể bị dừng khi <số lỗi vượt quá norm, >

- Cán bộ test có thể dừng test khi lập trình viên không thực hiện unit test,

>

3.1.1 Test chức năng (Functional Testing)

3.3.1.1 Test chức năng (Function Testing)

• Mục đích của test chức năng là tập trung vào các yêu cầu test có thể được lưu vết trựctiếp trong các UC hoặc các chức năng và qui tắc nghiệp vụ

• Mục tiêu của kiểu test này là kiểm tra tính đúng đắn của các dữ liệu, qui trình và báo cáocũng như việc thực hiện đúng những qui tắc nghiệp vụ

• Kiểu test này dựa vào kỹ thuật black box, tức là kiểm tra ứng dụng và các xử lý nội tạibằng cách tương tác với ứng dụng thông qua giao diện người sử dụng và phân tích cáckết quả hoặc đầu ra

• Bảng sau liệt kê một số gợi ý đối với mỗi ứng dụng:

Mục đích test: <Đảm bảo mục tiêu test đúng đắn của chức năng, bao gồm định

hướng, dữ liệu đầu vào, xử lý và dữ liệu nhận được>

Cách thực hiện: <Thực hiện mỗi UC, chu trình UC hoặc chức năng, sử dụng dữ

liệu hợp lệ và không hợp lệ để kiểm tra:

- Kết quả mong đợi với dữ liệu hợp lệ

- Lỗi thích hợp hoặc thông báo hiển thị khi dữ liệu không hợplệ

Trang 15

- Mỗi qui tắc nghiệp vụ đều được áp dụng đúng>

Điều kiện hoàn

thành:

- <Toàn bộ kế hoạch test đã được thực hiện

- Toàn bộ các lỗi phát hiện ra đã được ghi nhận.>

3.3.1.2 Test giao diện người sử dụng (User Interface Testing)

<Test giao diện người dùng (UI) kiểm tra các tương tác của người dùng với phần mềm Mụctiêu của test UI là để đảm bảo rằng giao diện người dùng cung cấp cho người sử dụng cáchtruy cập và sử dụng thích hợp thông qua các chức năng trong mục tiêu test Ngoài ra, test UIcòn để đảm bảo rằng các đối tượng trong phạm vi chức năng UI giống như mong đợi và phùhợp với tổ chức hoặc chuẩn ngành.>

Mục đích test:

<Kiểm tra:

 Việc sử dụng thông qua mục tiêu test phản ánh đúng các chứcnă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ímtabs, 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 tring vào việc tương thích với chuẩn>

Cách thực hiện: <Tạo ra và chỉnh sửa test 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>

Điều kiện hoàn

3.3.1.3 Test dữ liệu và tích hợp dữ liệu (Data and Database Integrity Testing)

<Cơ sở dữ liệu và xử lý cơ sở dữ liệu phải được test như một hệ thống con trong dự án hệthống con này phải được test không cần thông qua giao diện người dùng để giao tiếp với dữliệu Nghiên cứu thêm về DBMS để xác định các công cụ và kỹ thuật có thể có giúp hỗ trợcho việc test:

Trang 16

Mục đích test: <Đảm bảo rằng các phương pháp truy cập và chức năng xử lý làđúng và không có sai lệch dữ liệu>

Điều kiện hoàn

 Các xử lý phải được thực hiện bằng tay

 Cơ sở dữ liệu có kích thước nhỏ hoặc tối thiểu (giới hạn sốbản ghi) phải được dùng để làm rõ thêm các sự kiện không đượcphép chấp nhận>

>

3.3.1.4 Test chu trình nghiệp vụ (Business Cycle Testing)

<Test chu trình nghiệp vụ phải thực hiện các hoạt động trong dự án qua thời gian Phải xácđịnh một chu kỳ, ví dụ một năm, và các giao dịch và hoạt động có thể xảy ra trong chu kỳcủa năm đó phải được thực hiện Việc này bao gồm cả các chu kỳ hàng ngày, hàng tuầnhoặc hàng tháng và các sự kiện là ảnh hưởng bởi ngày tháng, ví dụ như ứng dụng ngânhàng>

Mục đích test: <Đảm bảo mục đích của test là đúng đắn và các tiến trình chạyngầm thực hiện đúng yêu cầu về mô hình nghiệp vụ và lịch

trình>

Cách thực hiện: <Việc test sẽ giả lập vài chu trình nghiệp vụ bằng cách thực hiện

các công việc sau:

 Các test dùng cho việc test chức năng sẽ được sửa lại hoặcnâng cấp để tăng số lần mỗi chức năng được thực hiện để giả lậpmột số người dùng khác nhau trong chu kỳ đã định

 Toàn bộ các chức năng theo ngày tháng sẽ được thực hiện với

dữ liệu hợp lệ và không hợp lệ hoặc chu kỳ thời gian

 Toàn bộ các chức năng xảy ra trong lịch trình chu kỳ sẽ đượcthực hiện vào thời gian thích hợp

 Việc test sẽ bao gồm cả dữ liệu hợp lệ và không hợp lệ để

Ngày đăng: 07/04/2024, 21:00

HÌNH ẢNH LIÊN QUAN

Bảng sau mô tả nguồn lực test cho dự án. - Service directory kế hoạch kiểm thử
Bảng sau mô tả nguồn lực test cho dự án (Trang 24)

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w