báo cáo môn học nhập môn công nghệ phần mềm chương 15 luồng công việc thực thi

Các quy chuẩn phổ biến khi lập trình 1.1.Sử dụng tên biến thích hợp và có nghĩa -Việc đặt tên biến thích hợp và có nghĩa là vô cùng quan trọng với việc bảo trì phần mềm do thành phần m

HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG

Khoa Công nghệ thông tin

Báo cáo

MÔN HỌC: Nhập môn công nghệ phần mềm

NHÓM MÔN HỌC: 11 Giảng viên: Đặng Ngọc Hùng

Nhóm sinh viên thực hiện: nhóm 23

Nguyễn Minh Tuân B19DCCN604

Đỗ Như Đức B19DCCN189

Nguyễn Tiến Chức B19DCCN106

Hà Nội năm 2022

Chương 15: Luồng công việc thực thi

1 Khái niệm và mục tiêu nghiên cứu

- Luồng công việc thực thi là quá trình chuyển đổi từ quá trình thiết kế chi tiếtthành mã nguồn ngôn ngữ lập trình Trên thực tế đối với dự án phần mềm phức tạp

và có quy mô lớn, việc thực hiện cả luồng công việc thực thi với một cá nhân làđiều rất khó và đòi hỏi sự hợp tác của nhiều lập trình viên với nhau Sản phẩm khi

đó sẽ được thực thi bởi một nhóm, làm việc đồng thời trên các thành phần khácnhau nhỏ hơn của sản phẩm

- Mục tiêu

Tìm hiểu luồng công việc thực thi trong kỹ thuật lập trình

Tìm hiểu các kĩ thuật kiểm thử hộp đen (black-box), kiểm thử hộp thuỷ tinh (white-box) và kiểm thử phi thực thi (non-execution-based)

Tìm hiểu các loại tích hợp (integration testing), kiểm thử sản phẩm

(product testing) và kiểm thử chấp nhận (acceptance testing)

Đánh giá các tiêu chuẩn và các giải pháp tốt trong kỹ thuật lập trình

sẽ phù hợp để thực thi các sản phẩm của công ty COBOL Để trả lời vấn đề nàychúng ta đi xem xét các khía cạnh:

Vấn đề bảo trì: việc thực thi các sản phẩm mới bằng Java vẫn phải đảm bảo việc bảo trì những sản phẩm cũ viết bằng COBOL Việc quản lý hai phân lớp lập trình viên khác nhau là không hề dễ dàng bởi vấn đề bất đồng có thể xảy ra khi lập trình viên Java thường được trả lương cao hơn

do nhân lực lúc đầu khan hiếm

Vấn đề chi phí: Quá trình tuyển dụng và đào tạo lập trình viên bằng ngôn ngữ mới sẽ tốn rất nhiều kinh phí và thời gian của công ty Mặt khác công ty sẽ phải tốn thêm một khoản để đầu tư các thiết bị phần cứng, phần mềm phục vụ việc lập trình bằng ngôn ngữ mới

Quá trình chuyển đổi lựa chọn ngôn ngữ lập trình mới có thể gây ra nhiều hậu quả về tài chính cũng như nhân lực cho doanh nghiệp.

- Khi sản phẩm khó hoặc không thể được thực thi bằng ngôn ngữ lập trình sẵncó: vấn đề lựa chọn ngôn ngữ lập trình khác phù hợp hoặc mạnh mẽ hơn là điềucần thiết để phù hợp với yêu cầu sản phẩm của khách hàng Việc thực hiện lựachọn này ví dụ có thể đánh giá theo các cách sau:

Đánh giá theo chi phí: Doanh nghiệp phải tính toán chi phí cần phải đầu

tư để thực hiện dự án theo từng loại ngôn ngữ khả dụng Ngôn ngữ lập trình phù hợp nhất sẽ cho lợi nhuận cao và chi phí thực hiện nhỏ nhất.Đánh giá theo rủi ro: Xét các rủi ro có thể gặp phải và phương hướng giảiquyết Ngôn ngữ lập trình phù hợp nhất là ngôn ngữ cho rủi ro thấp nhất

3 Ngôn ngữ lập trình thế hệ thứ 4

- Thế hệ thứ nhất: Ở thời kì sơ khai của lập trình phần mềm, chưa hề có kháiniệm trình biên dịch hay thông dịch, phần mềm được viết bằng mã nhị phân, hoặcbảng mạch và switch

- Thế hệ thứ 2: hợp ngữ ra đời khiến và hoạt động bằng cách dịch hợp ngữsang mã máy Việc lập trình và bảo trì trở nên dễ dàng hơn tuy nhiên độ dài mãchương trình vẫn tương tự mã máy

- Thế hệ thứ 3: ý tưởng của ngôn ngữ lập trình thế hệ thứ 3 là các loại ngônngữ bậc cao như C, C++, Pascal hoặc Java khiến cho việc lập trình trở nên dễ dànghơn khi mỗi dòng mã có thể biên dịch và thực thi thay cho 5-10 dòng mã máy Tuynhiên việc bảo trì các phần mềm viết bằng hợp ngữ thời điểm này lại tốn ít chi phíhơn

- Thế hệ thứ 4: ý tưởng của ngôn ngữ lập trình thứ 4 có từ những cuối năm

1970 Mục tiêu của việc thiết kế ngôn ngữ thế hệ thứ 4 (4GL) này là mỗi dòng mã

sẽ tương đương với 30-50 dòng mã máy Vì thế giúp rút ngắn quá trình phát triểnsản phẩm và khiến việc bảo trì dễ dàng hơn

2 Các quy chuẩn phổ biến khi lập trình

1.1.Sử dụng tên biến thích hợp và có nghĩa

-Việc đặt tên biến thích hợp và có nghĩa là vô cùng quan trọng với việc bảo trì phần mềm do thành phần mã được viết ra bởi một lập trình viên sẽ có thể bảo trì bởi nhiều hơn 1 người, việc bảo trì sẽ dàng và tiết kiệm chi phí hơn nếu các tên biến được đặt theo đúng quy chuẩn ngay từ khi thực thi Các quychuẩn đặt tên biến:

Đặt tên biến thích hợp: chọn duy nhất một tên biến có nghĩa hay vì nhiều tên biến đều cùng chỉ một đối tượng Ví dụ không nên dùng cả tên biến là

average và medium trong cùng một chương trình bởi chúng có nghĩagần tương đương

Đồng bộ thứ tự cách đặt tên biến: nếu đã chọn một thứ tự cho các thành phần trong tên biến, thì các tên biến tương tự cũng phải tuân theo thứ tự

đó Ví dụ: “frequencyMax” thì không nên dùng cách đặt tên

“minFrequency” cho giá trị min Thay vì đó hãy đồng bộ thành

Mã tự chú thích: là cách viết mã có tính mô tả cao và có thể hiểu một cách dễ dàng mà không cần chú thích Tuy nhiên lập trình viên có thể viết cách này khá hiếm

- Các vấn đề gặp phải khi không chú thích mã:

Với các lập trình viên thiếu kinh nghiệm việc viết mã không đảm bảo chất lượng là hoàn toàn có thể xảy ra, điều này khiến việc thực thi và bảotrì trở nên khó khăn hơn

Với đoạn mã không có chú thích nếu giả dụ có thay đổi nhân sự thì nhân

sự mới sẽ gặp khó khăn khi làm việc với đoạn mã có sẵn

1.3.Sử dụng tham số

- Tại sao nên sử dụng tham số để gán giá trị hằng số:

Sử dụng tham số khiến hằng số trở nên có ý nghĩa thay vì những con số không rõ ràng

Tránh việc vô tình thay đổi giá trị biến khiến sinh ra lỗi trong phần mềm hoặc cho kết quả không chính xác

Việc thay đổi giá trị hằng số sẽ dễ dàng hơn vì dùng tham số tương quan thay vì cố định

1.4.Sắp xếp bố cục mã nguồn hợp lý

- Với sự ra đời của các IDE hiện đại có chức năng định dạng được tích hợpsẵn thì việc sắp xếp bố cục mã nguồn càng dễ dàng hơn Tuy nhiên ta vẫn nên xemxét các tiêu chí để sắp xếp:

Thụt lùi đầu dòng và sử dụng ngoặc

Nên viết mỗi câu lệnh trên một dòng

Sử dụng dòng trống để phân cách các đoạn mã

1.5.Câu lệnh điều kiện lồng nhau

- Ta đánh giá cách sử dụng các câu lệnh điều kiện if lồng nhau qua các trường

TH3 (Figure 15.5): Sử dụng phương pháp đơn giản hóa điều kiện if-if phức tạp bằng toán tử &&

Sử dụng câu lệnh lặp lồng nhau sao cho bố cục hợp lí và có thể đơn giản hoá bằng các toán tử nếu có thể, không nên dùng quá 3 câu điều kiện if lồng nhau.

- Quy chuẩn lập trình có thể vừa có lợi vừa gây khó khăn Theo định nghĩa từtrước với các module thực hiện nhiều và đa dạng các hoạt động không liên quanđến nhau, thường đặt ra những luật như “mỗi module phải được viết trong khoảng35-50 dòng câu lệnh thực thi” Hay nói một cách khác rõ ràng hơn là “lập trìnhviên phải báo với quản lý nếu muốn xây dựng một module ít hơn 35 hoặc nhiềuhơn 50 dòng lệnh thực thi” Những quy chuẩn áp đặt như vậy thường bị bỏ qua

- Khác với với những quy chuẩn chung và phổ biến như với câu lệnh điềukiện if không nên được đặt lồng nhau quá 3 lần Lập trình viên thường không tuânthủ theo những quy chuẩn lập trình mà họ không hiểu tại sao lại được áp dụng.Hơn thế nữa, việc áp đặt các quy chuẩn lập trình có thể gây ra sự mâu thuẫn nội bộgiữa quản lý và lập trình viên

- Quy chuẩn lập trình có thể được đặt ra bởi đơn vị quản lý chất lượng phầnmềm Việc sử dụng các quy chuẩn lập trình khiến giai đoạn bảo trì dễ dàng hơn.Tuy nhiên việc áp dụng nó cũng khiến công đoạn lập trình trở nên khó khăn hơnvới những quy chuẩn quá ngặt nghèo và phức tạp sẽ khiến hiệu suất và tiến độ làmviệc của dự án bị chậm lại

- Thay vì đó nếu có thể áp dụng quy chuẩn lập trình vào hệ thống kiểm tra tựđộng mà máy tính có thể kiểm tra như: kiểm tra lệnh if, số dòng, hay mã lệnh sửdụng, … sẽ nâng cao chất lượng phần mềm đáng kể

- Việc tái sử dụng (reuse) là tương đối quan trọng trong ngành lập trình phầnmềm Thời gian và chi phí có thể được tiết kiệm được đáng kể nếu có thể áp dụngviệc tái sử dụng lên các tiêu chí dự án như: yêu cầu chức, kế hoạch, thiết kế, và cácđoạn mã

- Đặc biệt tái sử dụng các đoạn mã trong quá trình thực thi là vô cùng cần thiết và quan trọng.

driver: là một đoạn mã phục vụ mục đích kiểm thử gọi một thành phần

mã một hoặc nhiều lần, nếu có thể kiểm tra kết quả đầu ra

- Xét sơ đồ tích hợp sau đây:

Nếu muốn kiểm thử thành phần mã a ta cần phải gộp và kiểm thử cả 3 thành phần mã b, c, d như một stub

Nếu muốn kiểm thử thành phần mã h ta cần có một driver gọi nó

Tương tự nếu muốn kiểm thử thành phần mã d ta cần một driver và 2 stubs

Điều này khiến quá trình thực thi trở nên khó khăn khi quá trình thực hiện sẽ tốn rất nhiều công sức thiết lập stubs và drivers Chưa kể, nếu quátrình thực thi hoàn thành trước khi quá trình tích hợp, việc phát hiện và định vị lỗi gần như không thể thực hiện với các dự án lớn

Đòi hỏi cần phải có sự kết hợp giữa kiểm thử đơn vị và tích hợp

1.2.Tích hợp Top-Down

- Trong tích hợp top-down, nếu thành phần phía bên trên giao tiếp và gọithành phần bên dưới thì thành phần bên trên phải được thực thi và tích hợp trướcthành phần bên dưới

- Ưu điểm của tích hợp top-down:

Hỗ trợ cô lập và tìm lỗi: do các thành thành phần sẽ được thực thi và tích hợp theo thứ tự từ trên xuống, khi thêm một thành phần hoặc liên kết mộtthành phần khác vào bộ khung sẵn có, nếu có lỗi xảy ra ta có thể xác địnhngay lỗi có thể xảy ra ở thành phần liên kết với nó hoặc chính nó

Có thể phát hiện lỗ hổng thiết kế sớm hơn: thứ tự sắp xếp thành thành phần để kiểm thử và tích hợp sẽ chắc chắn rằng các thành phần logic sẽ luôn luôn hoạt động ổn định

- Nhược điểm của tích hợp top-down:

Có khả năng các thành phần được tái sử dụng sẽ không được kiểm thử tương đối như nhau nếu được giả sử là thành phần không sinh lỗi và sẽ bị

bỏ qua Nhưng trên thực tế có thể xảy ra các trường hợp phát sinh các lỗi không ngờ đến

Dễ gặp rủi ro khi các thành thành phần điều hành tái sử dụng mà không được kiểm thử kỹ lưỡng Lý do là các thành thành phần điều hành thường

ở tầng dưới của kiến trúc tích hợp top-down và số lần được kiểm thử sẽ íthơn so với tầng trên

1.3.Tích hợp Bottom-up

- Trong tích hợp bottom-up, nếu thành phần bên trên giao tiếp với và gọithành phần bên dưới thì thành phần bên dưới sẽ được thực thi và tích hợp trướcthành phần bên trên

- Tích hợp bottom-up:

Ưu điểm: những thành thành phần điều hành (operational artifacts) sẽ được kiểm thử một cách toàn diện qua các driver kiểm thử Vì thế giải bài toán của tích hợp top-down bởi cơ chế bắt lỗi dễ dàng

Nhược điểm: các thành phần logic (logic artifacts) sẽ là các thành phần được tích hợp cuối cùng Do đó nếu có phát hiện lỗi thiết kế nghiêm trọng nào đó trong giai đoạn cuối của dự án sẽ khiến quy trình làm việc

bị thay đổi hoặc cần trả một chi phí lớn cho việc tái thiết kế lại một phần lớn của sản phẩm

1.4.Tích hợp Sandwich

- Xét lược đồ 15.7 trên hình, ta thấy 6 thành phần logic (tô màu xám) đượctích hợp theo kiểu top-down, còn 7 thành phần điều hành (tô màu hồng) được tíchhợp theo kiểu bottom-up.

- Việc áp dụng kiến trúc kiểu này bởi là khi nếu dùng duy nhất kiến trúc down hoặc bottom-up đều sẽ không phù hợp với sản phẩm, giải pháp đưa ra là phảiphân vùng chúng Hai phần được kiểm thử một cách riêng biệt theo kiến trúc tíchhợp của chúng, và khi ghép lại các giao thức giữa 2 nhóm sẽ được kiểm thử từngphần đầy đủ

top-1.5.Quá trình tích hợp của hướng đối tượng

- Sản phẩm thiết kế theo hướng đối tượng có thể được tích hợp theo cả bằng cách top-down hoặc bottom-up

Tích hợp theo top-down: các stub sẽ được sử dụng cho mỗi phương pháp giống với các module

Tích hợp theo bottom-up: các đối tượng độc lập sẽ được thực thi và tích hợp đầu tiên, sau đó đến các đối tượng mà chúng giao tiếp gọi các đối tượng khác, cứ tích hợp như vậy cho đến khi sản phẩm hoàn chỉnh

Tích hợp theo sandwich: tích hợp sandwich cũng có thể sử dụng tuỳ theotừng thuộc tính từng thành phần, hay tuỳ theo thuộc tính của ngôn ngữ

lập trình Có nhiều biến thể của tích hợp sandwich có thể được sử dụng trong chương trình hướng đối tượng.

1.6.Quản lý tích hợp

- Khi quá trình tích hợp giữa các thành thành phần với nhau của mỗi lập trìnhviên khác nhau có khả năng xảy ra sự xung đột hoặc không tương thích Giả sử lậptrình viên thực thi đối tượng 01 sử dụng tài liệu thiết kế yêu cầu đối tượng 01truyền đến đối tượng 02 4 tham số, tuy nhiên theo tài liệu thiết kế của lập trìnhviên thực thi đối tượng 02 chỉ có 3 tham số được truyền đến đối tượng 02 Sự xungđột này đến từ việc chỉnh sửa lại tài liệu thiết kế mà thiếu đi sự đồng bộ và thôngbáo cho các bên liên quan, khiến cho việc tích hợp gặp vấn đề và tốn thêm thờigian và chi phí để giải quyết

- Để giải quyết vấn đề không tương thích như trên, cả quá trình tích hợp phảiđược vận hành bởi nhóm SQA (quản lý chất lượng phần mềm) Nhiệm vụ củanhóm SQA là đảm bảo quá trình tích hợp phải diễn ra thuận lợi và hoàn thành đồngthời quyết định xem thành thành phần nào được tích hợp theo kiểu nào và phụtrách phân chia công việc tích hợp cho mỗi lập trình viên

Nhóm SQA phải lên kế hoạch kiểm thử tích hợp trong kế hoạch quản

lý dự án phần mềm, đồng thời có trách nghiệm thực thi kế hoạch đó Kếtthúc giai đoạn tích hợp, tất cả những thành thành phần đã được kiểm thửđược tích hợp thành một sản phẩm hoàn chỉnh

8 Luồng công việc thực thi

- Nhiệm vụ của luồng công việc thực thi là triển khai đối tượng sản phẩmphần mềm bằng ngôn ngữ lập trình được chọn Chính xác hơn là, một sản phẩmphần mềm lớn sẽ được phân mảnh ra thành các hệ thống nhỏ hơn, sau đó đượcthực thi song song bởi các nhóm Các hệ thống nhỏ hơn bao gồm những thànhphần hoặc các thành phần mã

- Sau khi các thành phần mã đã được viết, lập trình viên sẽ kiểm thử thànhphần đó, khái niệm đó gọi là kiểm thử đơn vị (unit testing) Sau khi đã kiểm thửxong, lập trình viên chuyển thành phần mã xuống đơn vị quản lý chất lượng phầnmềm để kiểm thử sâu hơn Giai đoạn kiểm thử sau đó được thực hiện trong luồngcông việc kiểm thử

9 Luồng công việc kiểm thử trong thực thi

- Trong luồng công việc thực thi, nhiều loại kiểm thử sẽ được thực hiện: Kiểm thử đơn vị

Tích hợp

Kiểm thử sản phẩm

Kiểm thử chấp nhận

- Các thành phần mã sẽ được kiểm thử bằng 2 loại kiểm thử:

Kiểm thử không hợp cách (informal unit testing): thực hiện bởi lập trình viên khi viết thành phần mã

Kiểm thử hợp cách (methodical unit testing): thực hiện bởi đơn vị quản

lý chất lượng phần mềm Kiểm thử hợp cách có 2 loại: kiểm thử thực thi

và kiểm thử không thực thi

Việc lựa chọn test case rất quan trọng trong quá trình kiểm thử Bởi vì sẽ có

vô vàn khả năng xảy ra và việc test hết tất cả các khả năng là vô cùng lãng phí Điều cần làm là cần xây dựng các test case một cách có hệ thống

1 Kiểm thử dựa trên đặc điểm và kiểm thử đoạn mã

- Dữ liệu cho việc kiểm thử có thể được xây dựng bằng 2 cách:

Kiểm thử đặc điểm: với cách tiếp cận này, thành phần sẽ bị bỏ qua, phần quan tâm duy nhất để tạo test case là tài liệu đặc tả Còn được gọi là kiểmthử hộp đen (black-box), kiểm thử hành vi (behavioral), kiểm thử hướng

dữ liệu (data-driven), kiểm thử hàm (functional), kiểm thử hướng vào ra (input/output driven)

Kiểm thử mã: chỉ kiểm thử thành phần và phần tài liệu đặc tả sẽ bị bỏ quakhi lựa chọn test case Còn được gọi là kiểm thử hộp thuỷ tinh, kiểm thử hộp trắng, kiểm thử có cấu trúc, kiểm thử hướng logic

2. Tính khả thi của kiểm thử đặc điểm

-Ta xét: Các đặc tả cho dữ liệu một trạng thái của sản phẩm có các loại phiếugiảm giá và các mẫu mã sản phẩm Giả sử sản phẩm có 5 mẫu mã khác nhau

và có 7 loại phiếu giảm giá khác nhau cần được áp dụng Kiểm thử tất cả các

tổ hợp giữa các mẫu mã sản phẩm và phiếu giảm giá ta được 35 test cases

Sẽ là vô nghĩa nếu coi loại mẫu mã và phiếu giảm giá được tính toán và xử

lý ở trong 2 thành phần riêng biệt và nên được kiểm thử riêng biệt Trongkiểm thử hộp đen, sản phẩm được coi như một hộp đen - có nghĩa là cấu trúcbên trong của nó hoàn toàn không được xét

Với số lượng sản phẩm và số các loại phiếu giảm giá càng nhiều thì số lượngkết quả giá sản phẩm tính ra càng vô cùng lớn Tương tự với nếu xét nhiềunhân tố hơn thì sẽ có vô số test case và rất tốn thời gian để có thể kiểm thửđược hết số lượng test case đó

Vì vậy kiểm thử đặc điểm đầy đủ là không khả thi trên thực tế bởi số lượng test case khả thi là vô cùng lớn Vì vậy kiểm thử mã được đưa vào xem xét.

3. Tính khả thi của kiểm thử mã

- Hình thức phổ biến nhất của kiểm thử mã là kiểm thử tất cả các trường hợp(các đường đi) trong đoạn mã Để xem xét tính khả thi của kĩ thuật kiểm thử này,xem xét một biểu đồ hoạt động sau:

-Mặc dù biểu đồ hoạt động trông có vẻ đơn giản, tuy nhiên xét kỹ hơn nó cóhơn 10^12 đường đi Có 5 đường đi khả thi trong nhóm 6 hộp được tô màuxám và sau đó được lặp 18 lần, ta tính được tổng số đường đi khả thi trongbiểu đồ hoạt động như sau:

=> Với một lần lặp đã có số đường đi rất lớn, nếu xét những thànhphần có độ phức tạp và quy mô lớn hơn thì việc kiểm thử mã cũnghoàn toàn không khả thi giống như kiểm thử đặc điểm

Kiểm thử đòi hỏi việc kiểm thử tất cả các đường đi khả thi Tuy nhiên cókhả năng xảy ra khi kiểm thử tất cả các đường đi vẫn không thể phát hiệnđược lỗi Ta xét ví dụ sau:

- Đoạn mã này có nhiệm vụ kiểm tra tính tương đương của 3 số dựa trên mộtlogic sai: nếu trung bình của 3 số bằng số đầu tiên thì 3 số đó bằng nhau Dựa trên

2 test case cho sẵn thì đoạn mã này sẽ được cho là chạy đúng Tuy nhiên nếu dùngmột test case khác chưa được xét là x = 2 y = 1, z = 3 thì đoạn mã sẽ có lỗ hổng vàsai lệch

- Ví dụ trên cho ta thấy rằng xem xét tất cả các đường đi trong phần mềm làkhông tin cậy, bởi vì phần mềm có thể tồn tại những đường đi gây sai lệch chưađược xét Tuy vậy, kiểm thử hướng đường đi là hoàn toàn hợp lệ

bởi vì nó vốn dĩ không loại trừ việc chọn dữ liệu kiểm thử có thể phát hiện lỗi

Bởi vì sự đa dạng tổ hợp dữ liệu, cả kiểm thử mã đầy đủ và kiểm thử đặc điểm đầy đủ đều không khả thi Cần có một phương pháp để có thể phát hiện lỗi nhiều nhất có thể, mặc dù có thể không đảm bảo việc phát hiện tất cả các lỗi Một phương pháp hợp lý đó là sử dụng kiểm thử hộp đen sau đó tạo thêm các test case bằng phương pháp hộp thuỷ tinh

Kiểm thử hộp đen đầy đủ có thể yêu cầu hàng tỷ test case Vì vậy phương thức yêu cầu đặt ra là để tạo một tập hợp các test case nhỏ, tối ưu hoá khả năng phát hiện lỗi trong khi giảm khả năng lãng phí test case khi phát hiện lỗi giống nhau, mỗi test case cần độc lập về khả năng phát hiện lỗi

1 Kiểm thử tương đương và phân tích giá trị giới hạn

- Giả sử một cơ sở dữ liệu chứa thông tin về các sản phẩm và có thể chứa cácbản ghi từ 1-16383 Khoảng từ 1-16383 được gọi là lớp tương đương bởi vì nếutest case một sản phẩm trong khoảng 1-16383 vẫn có thể hoạt động tốt, thì test casenhững sản phẩm có khoảng xung quanh sẽ tương tự Để chuẩn xác hơn, ta sẽ chia

số lượng bản ghi thành 3 lớp tương đương

Nhỏ hơn 1 bản ghi

Từ 1 đến 16383 bản ghi

Lớn hơn 16383 bản ghi

- Kiểm thử cơ sở dữ liệu sử dụng kĩ thuật lớp tương đương sẽ yêu cầu mỗi testcase từ mỗi lớp tương đương sẽ được chọn.

- Để tối đa hoá khả năng tìm được lỗi nên sử dụng kĩ thuật phân tích giá trịgiới hạn Trong khoảng từ (R1, R2) được liệt kê từ đầu ra hoặc đầu vào đặc điểm,

có 5 test cases nên được chọn, các giá trị nhỏ hơn R1, bằng R1, lớn hơn R1 và nhỏhơn R2, bằng R2, lớn hơn R2 Khi chỉ ra một đơn vị thuộc một tập, thì 2 lớp tươngđương nên được xét là lớp chứa đơn vị đó và lớp không chứa đơn vị đó

Việc sử dụng lớp tương đương cùng với phân tích giá trị giới hạn nhằm kiểm thử các đặc điểm đầu vào và đặc điểm đầu ra của một phương thức cho việc sinh các tập dữ liệu test nhỏ với mục tiêu tìm ra nhiều nhiều lỗi nhất có thể nếu các cách chọn test cases mạnh mẽ hơn không được áp dụng

2. Kiểm thử chức năng

- Một dạng kiểm thử khác của kiểm thử hộp đen là xây dựng dữ liệu test dựatrên chức năng của đoạn mã Trong kiểm thử chức năng, mỗi đơn vị của chức nănghoặc hàm được triển khai ở trong thành phần sẽ được định danh Một ví dụ điểnhình của quản lý nhà kho sẽ có những hàm như:

get_next_database_record

determine_whether_quantity_on_hand_is_below_the_reorder_point

- Sau khi xác định được tất cả các hàm của thành phần, dữ liệu test sẽ đượcxây dựng dựa trên các hàm khác nhau Từ đây, nếu các thành thành phần bao gồmcác hàm gọi các hàm con, kết nối bởi cấu trúc điều khiển của lập trình cấu trúc, khi

đó kiểm thử chức năng sẽ được thực hiện đệ quy

- Trên thực tế, các hàm cha không được xây dựng theo một cấu trúc từ cáchàm con Thay vì đó, các hàm con thường được đan xen vào nhau theo một cáchnào đó Để có thể tìm được các lỗi và lỗ hổng trong trường hợp này, phân tích chứcnăng cần được thực hiện theo một chu trình khá phức tạp

- Một nhân tố làm tăng tính phức tạp đó là các chức năng thường xuyên khôngtrùng hợp với các ranh giới thành phần Vì thế sự phân biệt giữa kiểm thử đơn vị vàtích hợp trở nên một cách thiếu quan trọng hơn: một đoạn mã không thể kiểm thửđồng thời nếu không kiểm thử một đoạn mã khác chứa chức năng mà nó sử dụng.Vấn đề này cũng có thể xảy ra trong mô hình hướng đối tượng khi một phương thứccủa một đối tượng gọi một phương thức của đối tượng khác

Các quan hệ ngẫu nhiên giữa các thành phần theo cách nhìn của kiểm thửchức năng có thể tạo ra những hậu quả không chấp nhận được cho việcquản lý Ví dụ như việc quản lý cột mốc dự án hoặc deadline có thể trở

thành một thứ khó xác định được, trở thành chướng ngại cho việc xác định trạng thái của sản phẩm theo kế hoạch quản lý dự án phần mềm.

hộp đen

Test cases kiểm thử hộp đen cho case study Tổ chức MSG:

- Biểu đồ 15.13 và 15.14 minh hoạ các test cases kiểm thử hộp đen cho casestudy tổ chức MSG Đầu tiên xem xét các test cases nhận được từ các lớp tươngđương và phân tích giá trị giới hạn Test case đầu tiên trong biểu đồ 15.13 kiểm traxem sản phẩm có phát hiện lỗi nếu biến itemName (tên) của một khoản đầu tưkhông bắt đầu bằng một chữ cái 5 test cases tiếp theo kiểm tra xem biếnitemName có giá trị độ dài từ 1 – 25 kí tự hay không Các test cases tương tự cònlại kiểm tra các mô tả đặc điểm khác

- Với kiểm thử hàm, có 10 hàm được liệt kê ở trong tài liệu đặc tả, như đượcminh hoạ ở biểu đồ 15.14 Có tổng cộng 11 test cases liên quan đến việc sử dụngcác hàm này

- Nên biết rằng các test cases ở đây có thể được phát triển ngay khi giai đoạnphân tích hoàn thành Lý do mà nó được đề cập ở nội dung luồng thực thi là nó cóliên quan đến chủ đề lựa chọn test case Cấu tạo chính của mọi kế hoạch kiểm thửnên là một quy định rằng kiểm thử hộp đen nên được thực hiện ngay khi quá trìnhphân tích đã được phê duyệt, nhằm thuận tiện cho nhóm SQA trong luồng côngviệc thực thi