Xây dựng quy trình kiểm thử cho website của công ty cổ phẩn sản xuất thƣơng mại tiến nga
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.85 MB, 61 trang )
LỜI CẢM ƠN !
Trong quá trình nghiên cứu và thực hiện khóa luận tốt nghiệp, em đã nhận
được sự hướng dẫn nhiệt tình của cô giáo hướng dẫn Ths Lê Việt Hà , cùng sự giúp đỡ
của ban giám đốc và toàn thể nhân viên công ty cổ phần sản xuất thương mại Tiến Nga
Đầu tiên , em xin gửi lời cảm ơn sâu sắc nhất tới giáo viên hướng dẫnTh.s Lê
Việt Hà . Cô đã giúp đỡ em có những định hướngđúng đắn khi thực hiện khóa luận tốt
nghiệp cũng như những kỹ năng nghiên cứu cần thiết khác.
Em cũng xin gửi lời cảmơn chân thành tới ban giám đốc cũng như những anh/chị
làm việc tại công ty cổ phần sản xuất thương mại Tiến Nga vì sự quan tâm, ủng hộ hỗ
trợ cho em trong quá trình thực tập và thu thập tài liệu.
Em xin gửi lời cảm ơn tới các thầy cô giáo trong khoa Hệ thống thông tin kinh
tế về sự động viên khích lệ mà em đã nhận được trong suốt quá trình học tập và hoàn
thành khóa luận này.
Do trình độ và khả năng của bản thân em còn hạn chế.Vì vậy, khóa luận chắc
chắn sẽ gặp nhiều sai sót. Em kính mong ths Lê Việt Hà , các thầy cô giáo trong khoa
Hệ thống thông tin kinh tế, các anh/ chị nhân viên trong công ty gópý, chỉ bảo để khóa
luận có giá trị cả về lý luận và thực tiễn.
Em xin chân thành cảm ơn !
1
1
MỤC LỤC
2
2
DANH MỤC BẢNG BIỂU
3
3
TỔNG QUAN VỀ ĐỀ TÀI NGHIÊN CỨU
1.Tính cấp thiết của đề tài
Ngày nay, với sự phát trển của công nghệ thông tin, Internet trở thành cấu nối
chia sẻ kiến thức, thông tin giúp con người đến gần nhau hơn. Ứng dụng tin học vào
lĩnh vực kinh tế giúp ta nắm bắt thông tin một cách chính xác, kịp thời, đầyđủ, góp
phần nâng cao hiệu quả kinh doanh, thúc đẩy nền kinh tế mở rộng và phát triển. Vì vậy
các công ty, doanh nghiệp hiện nay rất quan tâm đến website của mình ,tầm quan trọng
của website cũng như việc Kiểm thử nó sẽ giúp hoàn thiện các ứng dụng, module
hoặc sản phẩm so với yêu cầu kinh doanh và người sử dụng. Kiểm thử rất quan
trọng ,đây là một giai đoạn bắt buộc trong quá trình phát triển phần mềm, để đảm bảo
kiểm thử tốt để kiểm thử các ứng dụng hoàn toàn và chắc chắn rằng nó hoạt động tốt
và theo mong muốn của chúng ta.
Việc xác định phạm vi kiểm tra các trường hợp kiểm thử nên được thiết kế tốt với
khả năng tối đa của việc tìm kiếm các lỗi hiệu quả và được tính toán là số bug báo cáo
cho mỗi trường hợp kiểm thử. Kiểm thử không chỉ đơn giản là đi tìm bug, mà là người
có cái nhìn tổng quát nhất. Sản phẩm tới tay người dùng là sự kết hợp của kiến thức,
kinh nghiệm, kỹ năng, cách nhìn để mang lại sản phẩm tốt nhất. Luôn luôn hướng đến
bức tranh tổng thể nhất để cho ra những sản phẩm tốt nhất.
Công ty Cổ Phần Sản xuất Thương Mại Tiến Nga thành lập ngày 22/08/2005.
lĩnh vực kinh doanh chính của công ty là chế biến thực phẩm, sản phẩm của công ty đã
có mặt trên toàn quốc thông qua các hệ thống siêu thị
Trang web của công ty được mở từ khi thành lập công ty, hiện tại vẫn đang được
duy trì hoạt động hiệu quả. Trang web của Công ty là nơi cung cấp thông tin về các
hoạt dộng của công ty, các sản phẩm . Tuy hoạt động hiệu quả nhưng công ty hiện tại
chưa để ý tới việc kiểm thử đến các module , chức năng của các ứng dụng, hay giao
diện vì vậy qua quá trình tìm hiểu và thực tập tại công ty Cổ Phần Sản xuất Thương
Mại Tiến Nga em xin thực hiện đề tài khóa luận
“Xây dựng quy trình kiểm thử cho
website của công ty cổ phẩn sản xuất thương mại Tiến Nga ”
4
5
2.Mục tiêu nghiên cứu của đề tài
Mục tiêu nghiên cứu của đề tài là tập hợp và hệ thống hóa một số lý thuyết cơ
bản về kiểm thử, nghiên cứu bằng những phương pháp khác nhau. Từ đó, xem xét
đánh giá và viết các test case cho các module của trang web. Giúp website của công
ty được hoàn thiện không xảy ra lỗi khi sử dụng, tìm ra các lỗi để giải quyết ngay lập
tức
Các mục tiêu cụ thể cần giải quyết trong đề tài:
- Làm rõ cơ sở lý thuyết về vấn đề kiểm thử trên website công ty cổ phẩn sản
xuất thương mại Tiến Nga
- xây dựng quá trình kiểm thử của website công ty cổ phẩn sản xuất thương mại
Tiến Nga
- viết testcase cho các modul của website công ty cổ phẩn sản xuất thương mại
Tiến Nga
3. Đối tượng và phạm vi nghiên cứu của đề tài.
- Đối tượng của đề tài: website công ty cổ phẩn sản xuất thương mại Tiến Nga
- Phạm vi nghiên cứu : công ty cố phần sản xuất thương mại Tiến Nga
4 . Phương pháp nghiên cứu của đề tài.
4.1. phương pháp thu thập dữ liệu
Đề tài được thực hiện dựa trên các phương pháp sau:
- Phương pháp thu nhập tài liệu
+ Điều tra trắc nghiệm: Đây là phương pháp sử dụng mẫu phiếu điều tra khảo sát
tại công ty.
+ phỏng vấn trực tiếp: Trong quá trình thực tập tổng hợp tại công ty, tiến hành
phỏng vấn trực tiếp nhân viên phòng ban để thu thập thêm các thông tin cần thiết.
+ Quan sát trực tiếp cơ sở hạ tầng, môi trường làm việc của công ty để nắm bắt
được các nghiệp vụ quản lý nhân sự tại công ty.
+ Thu thập tài liệu liên quan đến cơ sở lý luận, các lý thuyết về hệ thống
6
thông tin và phân tích thiết kế hệ thống từ các phương tiện truyền thông như sách, báo,
internet.
7
4.2 . phương pháp xử lí dữ liệu
Khóa luận được thực hiện trên cơ sở vận dụng tổng hợp các phương pháp nghiên
cứu như phân tích, so sánh, thống kê, tổng hợp,
+ Xử lý số liệu qua excel, viết tescase qua excel và log bug qua tool redmine
+ Phương pháp so sánh, đối chiếu: Đây là phương pháp đối chiếu giữa lý luận và
thực tiễn để tìm ra các lỗi gặp phải và lỗi so với đặc tả yêu cầu
+ Kết quả đạt được là tìm ra lỗi của các modunl và tiến hành log bug sử lỗi
8
CHƯƠNG 1. CƠ SỞ LÍ LUẬN VỀ KIỂM THỬ
1. Cơ sở lý luận về kiểm thử
1.1. Khái niệm cơ bản về kiểm thử
1.1.1. khái niệm kiểm thử phần mềm
Khái niệm phần mềm
-
Phần mềm (Software) là một tập hợp những câu lệnh hoặc chỉ thị (Instruction) được
viết bằng một hoặc nhiều ngôn ngữ lập trình theo một trật tự xác định, và các dữ
liệu hay tài liệu liên quan nhằm tự động thực hiện một số nhiệm vụ hay chức năng
hoặc giải quyết một vấn đề cụ thể nào đó
-
Phần mềm thực hiện các chức năng của nó bằng cách gửi các chỉ thị trực tiếp đến phần
cứng hoặc bằng cách cung cấp dữ liệu để phục vụ các chương trình hay phần mềm
khác.
-
Phần mềm là một khái niệm trừu tượng, nó khác với phần cứng ở chỗ là "phần mềm
không thể sờ hay đụng vào", và nó cần phải có phần cứng mới có thể thực thi được.
Khái niệm website
-
Website còn gọi là trang web, trangmạng, là một tập hợp các trang web bao gồm văn
bản, hình ảnhvideo, flash vv, thường chỉ nằm trong một tên miền( domain name) hoặc
tên miền phụ (subdomain)
Kiểm thử phần mềm: (kiểm tra, thử nghiệm) là một cuộc kiểm tra được tiến
hành để cung cấp cho các bên liên quan thông tin về chất lượng của sản phẩm hoặc
dịch vụ được kiểm thử. Kiểm thử có thể cung cấp cho doanh nghiệp một quan điểm,
một cách nhìn độc lập về phần mềm để từ đó cho phép đánh giá và thấu hiểu được
những rủi ro trong quá trình triển khai phần mềm.
Trong kỹ thuật kiểm thử không chỉ giới hạn ở việc thực hiện một chương trình
hoặc ứng dụng với mục đích đi tìm các lỗi phần mềm (bao gồm các lỗi và các thiếu
sót) mà còn là một quá trình phê chuẩn và xác minh một chương trình máy tính / ứng
9
dụng / sản phẩm nhằm:
-
Đáp ứng được mọi yêu cầu hướng dẫn khi thiết kế và phát triển phần mềm.
Thực hiện công việc đúng như kỳ vọng.
Có thể triển khai được với những đặc tính tương tự.
Và đáp ứng được mọi nhu cầu của các bên liên quan.
Tùy thuộc vào từng phương pháp, việc kiểm thử có thể được thực hiện bất cứ lúc
nào trong quá trình phát triển phần mềm.
1.1.2. Mục tiêu Kiểm thử phần mềm
-
Tìm các bug phát sinh do dev tạo ra khi code.
-
Đạt được sự tự tin và cung cấp thông tin về mức độ chất lượng.
-
Để ngăn ngừa lỗi.
-
Đảm bảo rằng kết quả cuối cùng đáp ứng các yêu cầu kinh doanh và người sử
dụng.
Để đạt được sự tín nhiệm của khách hàng bằng cách cung cấp cho họ một sản
-
phẩm chất lượng.
Kiểm thử phần mềm sẽ giúp hoàn thiện các ứng dụng phần mềm hoặc sản phẩm
so với yêu cầu kinh doanh và người sử dụng. Nó là rất quan trọng để đảm bảo kiểm thử
tốt để kiểm thử các ứng dụng phần mềm hoàn toàn và chắc chắn rằng nó hoạt động tốt
và theo các thông số kỹ thuật.
Việc xác định phạm vi kiểm tra các trường hợp kiểm thử nên được thiết kế tốt với
khả năng tối đa của việc tìm kiếm các lỗi hiệu quả và được tính toán là số bug báo cáo
cho mỗi trường hợp kiểm thử.
Kiểm tra phần mềm để chắc chắn kiểm thử đang thực hiện đúng cách và hệ thống
đã sẵn sàng để sử dụng. Kiểm thử bao phủ các lĩnh vực khác nhau như: chức năng của
các ứng dụng, khả năng tương thích của các ứng dụng với các hệ điều hành, phần cứng
và các loại khác nhau của các trình duyệt, thực hiện kiểm thử để kiểm tra hiệu năng của
các ứng dụng để đảm bảo rằng hệ thống đáng tin cậy và không có trục trặc hay không
nên có bất kỳ vấn đề cản trở. Xác định rằng các ứng dụng có thể được triển khai một
cách dễ dàng với máy tính và không có bất kỳ sự cố. Do đó các ứng dụng rất dễ dàng
để cài đặt, tìm hiểu và sử dụng.
Kiểm thử phần mềm cho phép tạo ra những đánh giá khách quan về mức độ phù
hợp của hệ thống các yêu cầu đã nêu và thông số kỹ thuật.
10
Kiểm tra xác nhận rằng hệ thống đáp ứng các yêu cầu khác nhau bao gồm: chức
năng, hiệu suất, độ tin cậy, an toàn, khả năng sử dụng và như vậy. Việc xác nhận này
được thực hiện để đảm bảo rằng chúng tôi đang xây dựng hệ thống phù hợp.
Xác nhận để đảm bảo đang xây dựng hệ thống phù hợp. Ngoài việc giúp đưa ra
quyết định, các thông tin từ các kiểm thử phần mềm giúp quản lý rủi ro.
1.1.3 . Các nguyên tắc cơ bản của kiểm thử
Kiểm thử chứng mình sự hiện diện của lỗi
Kiểm thử chỉ có thể chứng minh được rằng sản phẩm có lỗi. Kiểm thử phần mềm
không thể chứng mình rằng sản phẩm không còn lỗi. Nghĩa là sản phẩm luôn có lỗi cho
dù có kiểm thử nhiều bao nhiêu. Do đó, điều quan trọng là chúng ta phải thiết kế các
trường hợp kiểm thử (test case) sao cho có thể tìm được càng nhiều lỗi càng tốt.
Kiểm thử toàn bộ là không thể
Trừ khi sản phẩm được kiểm thử quá đơn giản cũng như không có nhiều giá trị
đầu vào (chẳng hạn như “Hello World”) thì việc chứng minh sản phẩm không còn bug
cho dù có kiểm thử nhiều đến đâu là không khả thi. Hầu hết các sản phẩm ngày nay rất
đa dạng và phức tạp do được phát triển trên nhiều nền tảng, công nghệ phong phú cũng
như khả năng lưu trữ kết nối dữ liệu lớn, khiến việc kiểm thử trở nên khó khăn và việc
kiểm thử toàn bộ là gần như không thể. Kiểm thử với tất cả các kết hợp đầu vào và đầu
ra, với tất cả các kịch bản là không thể trừ phi nó chỉ bao gồm ít trường hợp thì có thể
kiểm thử toàn bộ. Thay vì kiểm thử toàn bộ, việc phân tích rủi ro và dựa trên sự mức độ
ưu tiên chúng ta có thể tập trung việc kiểm thử vào một số điểm cần thiết, có nguy cơ
lỗi cao hơn.
Kiểm thử càng sớm càng tốt
Nguyên tắc này yêu cầu bắt đầu thử nghiệm phần mềm trong giai đoạn đầu của
vòng đời phát triển phần mềm. Các hoạt động kiểm thử phần mềm từ giai đoạn đầu sẽ
giúp phát hiện bug sớm hơn. Nó cho phép chuyển giao phần mềm theo yêu cầu đúng
thời gian với chất lượng dự kiến. Ngoài ra ai làm phần mềm cũng biết được rằng việc
phát hiện lỗi càng trể bao nhiêu thì chi phí để sửa lỗi càng cao bấy nhiêu. Tương tự,
việc thay đổi yêu cầu không đúng ngay từ đầu thường tốn ít chi phí thay đổi tính năng
trong hệ thống..
Lỗi thường được phân bố tập trung
11
Thông thường, phần lớn lỗi tập trung vào những module, thành phần chức năng
chính của hệ thống. Điều này cũng thuận theo nguyên lý Pareto: 80% số lượng lỗi được
tìm thấy trong 20% tính năng của hệ thống. Nếu bạn thành công xác định được điều
này, bạn sẽ tập trung vào tìm kiếm lỗi quanh khu vực được xác định. Nó được coi là
một trong những cách hiệu quả nhất để thực hiện kiểm tra hiệu quả
Nghịch lý thuốc trừ sâu
Trong kiểm thử phần mềm, nếu bạn cứ thực thi lặp đi lặp lại một bộ test case thì
có khả năng rất thấp bạn sẽ tìm được lỗi từ những trường hợp kiểm thử này. Nguyên
nhân là do khi hệ thống ngày càng hoàn thiện, những lỗi được tìm thấy lúc trước đã
được sửa trong khi những trường hợp kiểm thử đã cũ. Do đó, khi một lỗi được sửa hay
một tính năng mới được thêm vào, chúng ta nên tiến hành làm regression (kiểm thử hồi
qui) nhằm mục đích đảm bảo những thay đổi này không ảnh hưởng đến những vùng
khác của sản phẩm.
Kiểm thử phụ thuộc vào ngữ cảnh
Theo nguyên tắc này thì nếu bạn đang kiểm thử ứng dụng web và ứng dụng di
động bằng cách sử dụng chiến lược kiểm thử giống nhau, thì điều đó là sai lầm. Chiến
lược để kiểm thử nên khác nhau và phụ thộc vào chính ứng dụng đó. Chiến lược cho
test web application phải khác với ứng dụng android mobile.
Quan niệm sai lầm về việc “hết lỗi”
Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm đã
sẵn sàng để tung ra thị trường. Việc không tìm thấy lỗi cũng có thể là do bộ trường hợp
kiểm thử được tạo ra chỉ nhằm kiểm tra những tính năng được làm đúng theo yêu cầu
thay vì nhằm tìm kiếm lỗi mới.
1.1.4 Vai trò của kiểm thử
Vai trò của kiểm thử phần mềm là
Kiểm thử để tìm ra lỗi, ghi nhận thông tin về lỗi nhưng không sửa lỗi.
Kiểm thử phần mềm không chỉ cần tìm lỗi phần mềm, mà còn là quá trình kiểm
tra và xác minh một phần mềm đã đáp ứng được yêu cầu và mong đợi của khách hàng.
Một số lỗi phần mềm đã gây ra thiệt hại nghiêm trọng trong lịch sử như:
12
Máy bay Airbus A300 do lỗi Phần mềm và bị tai nạn ngày 26/4/1994 giết chết
-
264 người
Năm 1985, Máy xạ trị Therac-25 của Canada do lỗi phần mềm mà phát ra tia
-
gây chết người đã giết chết 3 người và làm 3 người khác bị thương nặng.
Vào tháng Tư năm 1999, một lỗi phần mềm gây ra sự thất bại của một vụ phóng
-
vệ tinh quân sự gây thiệt hại 1,2 tỷ USD, vụ tai nạn đắt đỏ nhất trong lịch sử.
5/1996, Một lỗi phần mềm gây ra các tài khoản ngân hàng của 823 khách hàng
-
của một ngân hàng lớn của Hoa Kỳ được ghi với 920 triệu đô la Mỹ.
Chính vì vậy, việc kiểm thử phần mềm là vô cùng quan trọng vì lỗi phần mềm
nếu để lọt thì ko chỉ thiệt hại về kinh tế mà còn thiệt hại đến tính mạng con người.
1.2 . Một số lý thuyết cơ bản về kiểm thử
1.2.1 .Quy trình kiểm thử
Phân tích yêu cầu :Trong giai đoạn này, test team nghiên cứu các yêu cầu từ quan điển
của một nhân viên kiểm thử để xác định được những yêu cầu cần thực hiện kiểm thử. QA
team có thể tương tác với các bên liên quan khác (ví dụ như khách hàng, phân thích
nghiệp vụ (BA), technical Leader...) để hiểu rõ các yêu cầu cụ thể. Các yêu cầu có thể là
chức năng - Functional (xác định những gì phần mềm phải làm) hoặc không phải chức
năng - Non functional ( như hiệu năng, tính bảo mật của hệ thống). Activities:
-
Xác định loại kiểm thử sẽ được thực hiện.
-
Tổng hợp chi tiết về thứ tự ưu tiên và mức độ tập trung.
-
Xác định môi trường kiểm thử.
-
Phân tích khả năng sử dụng automation (nếu cần)
Deliverables
-
RTM
-
Báo cáo về khả năng sử dụng automation (nếu cần)
Lên kế hoạch kiểm thử : Giai đoạn này còn gọi là lên chiến lược thử nghiệm. Thông
thường trong giai đoạn này QA leader sẽ xác định được effort và dự toán chi phí cho dự
án và sẽ chuẩn bị và hiển thị kế hoạch kiểm thử. Activities:
-
Lựa chọn công cụ kiểm thử (test tool)
-
Dự đoán test effort.
13
-
Lên kế hoạch về nhân sự và ấc định vai trò trách nhiệm.
-
Training yêu cầu dự án.
Tạo test case : Giai đoạn này cần phải tạo, xác minh, kiểm tra lại các test cases và
test scripys. Test data cũng được tạo, xác định và freview trong giai đoạn này.
Activities:
-
Tạo test cases, automation scripts (nếu có)
-
Review test cases và scripts.
-
Tạo test data.
.Cài đặt môi trường kiểm thử: Môi trường test quyết định bở các điều kiện phần
mềm và phần cứng cần để thực hiện kiểm thử. thiết lập môi trường kiểm thử là một tiêu
chí quan trọng trong quá trình kiểm thử và có thể thực hiện song song với giai đoạn tạo
test case. Nhóm kiểm thử có thể không cần tham gia vào hoạt động này nếu có đội hỗ
trợ, nhiệm vụ của nhóm kiểm thử chỉ là yêu cầu môi trường cần thiết. Activities:
Hiểu được kiến trúc yêu cầu, thiết lập môi trường và chuẩn bị danh sách yêu
-
cầu về phần cứng và phần mềm cho môi trường thử nghiệm.
-
Thiết lập môi trường kiểm thử.
-
Thực hiện smoke test trên môi trường đã xây dựng.
Thực hiện kiểm thử: Trong giai đoạn này nhóm kiểm thử sẽ thực hiện kiểm thử theo
plan và test cases đã chuẩn bị. Lỗi sẽ được thông báo cho development team để sửa và
test lại. Activities:
-
Thực hiện kiểm thử theo kế hoạch.
-
Làm tài liệu về kế quả kiểm thử, log các lỗi cho những trường hợp fail.
-
Map các lỗi với test cases trong RTM
-
Kiểm thử lại các lỗi đã được sửa.
-
Kiểm tra để đóng lỗi.
Đóng chu trình kiểm thử: Nhóm kiểm thử sẽ họp, thảo luận và phân tích những bài
học rút ra sau quá trình test, và đưa ra chiến lược cho những lần thực hiện sau hoặc chia
sẻ kinh nghiệm cho các dự án tương tự. Activities:
Đánh giá việc hoàn thành chu trình dựa vào thời gian, mức độ bao phủ, chi phí,
-
phần mềm, chất lượng và business objectives.
Chuẩn bị dữ liệu dựa trên các tiêu chí trên.
-
14
-
Tạo tài liệu learning out của project.
-
Chuẩn bị báo cáo kết thúc kiểm thử.
-
Báo cáo chất lượng sản phẩm cho khách hàng.
-
Phân tích kết quả kiểm thử để tìm ra sự phân bố lỗi theo loại và mức độ nghiêm
trọng.
1.2.2. Các phương pháp kiểm thử
Kiểm thử phần mềm được chia làm 2 loại: Kiểm thử tĩnh và kiểm thử động.
Kiểm thử tĩnh là một hình thức của kiểm thử phần mềm mà không thực hiện phần
mềm. Điều này ngược với thử nghiệm động. Thường thì nó không kiểm thử chi tiết
mà chủ yếu kiểm tra tính đúng đắn của code (mã lệnh), thuật toán hay tài liệu.
Kiểm thử động là phương pháp thử phần mềm thông qua việc dùng máy chạy
chương trình để điều tra trạng thái tác động của chương trình, đó là kiểm thử dựa trên
các ca kiểm thử xác định bằng sự thực hiện
1.2.3.Các kĩ thuật kiểm thử
Với phương pháp kiểm thử tự động. chúng ta có Kiểm thử hộp trắng(White box
testing) và Kỹ thuật kiểm thử hộp đen (Black-Box Testing)
Kiểm thử hộp trắng bao gồm:
Kiểm thử đường dẫn (Path test): Kiểm thử bao quát các dòng source code,
-
nhánh và đường dẫn.
Kiểm thử luồng điều khiển(Control flow test): Xác nhận truy cứu các lịch sử
-
thực hiện source code bằng cách sử dụng trình gỡ lỗi.
-
Kiểm thử nội bộ: Xác nhận các tham số, counter, vòng lặp
-
Kiểm thử tính năng: Đo thời gian xử lý của module,đường dẫn, dữ liệu cụ thể.
Kiểm thử hộp đen bao gồm:
15
-
Kiểm thử chức năng và kiểm thử hệ thống
Kiểm thử quá tải và kiểm thử hỏng hóc
Kiểm tra hiệu năng
Các kỹ thuật trong kiểm thử hộp đen có:
Phân vùng tương đương (Equivalence partitioning)
-
Chia (partition) đầu vào thành những nhóm tương đương nhau (equivalence). Nếu
một giá trị trong nhóm hoạt động đúng thì tất cả các giá trị trong nhóm đó cũng hoạt
động đúng và ngược lại
-
Mục đích : Giảm đáng kể số lượng test case cần phải thiết kế vì với mỗi lớp tương
đương ta chỉ cần test trên các phần tử đại diện
Phân tích giá trị biên (Boundary value analysis)
-
Đây là phương pháp test mà chúng ta sẽ test tất cả các giá trị ở vùng biên của dữ liệu
vào và dữ liệu ra. Chúng ta sẽ tập trung vào các giá trị biên chứ không test toàn bộ dữ
liệu
1.2.4 . Mô hình kiểm thử phần mềm
1, Water fall
Các giai đoạn phát triển
Lấy yêu cầu khách hàng: thu thập thông tin về chi tiết và tính năng của sản
-
phẩm từ khách hàng càng nhiều càng tốt.
Thiết kế: lên kế họach xem bạn sẽ sử dụng ngôn ngữ lập trình nào (Java hay
-
.NET), cơ sở dữ liệu nào (Oralce hay MySQL) cũng như những tính năng tổng quát
cũng như kiến trúc của sản phẩm.
-
Xây dựng: Sau khi thiết kế là giai đoạn xây dựng (viết code cho sản phẩm).
-
Kiểm thử: kiểm tra xem sản phẩm được xây dựng có đúng theo yêu cầu ban đầu
của khách hàng hay không.
-
Triển khai: Triển khai sản phẩm cho khách hàng.
-
Bảo trì: Sau khi triển khai sản phẩm cho khách hàng, bạn có thể sẽ nhận được
yêu cầu từ khách hàng để tùy chỉnh hay chỉnh sửa sản phẩm
16
Ưu điểm:
Các giai đoạn được định nghĩa đầu vào và đầu ra rõ ràng. Cơ bản dựa trên tài
-
liệu.
Sản phẩm phần mềm được hình thành thông qua chuỗi các hoạt động có trình tự
-
rõ ràng.
Nhược điểm:
Đòi hỏi tất cả yêu cầu phần mềm phải được xác định rõ ràng ngay từ đầu dự án.
-
Nhưng đa số dự án thực tế yêu cầu phần mềm thường ẩn chứa những vấn đề chưa chắc
chắn.
dự án thực tế ít khi được thực hiện đầy đủ các bước trong suốt chu kỳ dự án.
-
Khi cận ngày gửi cho khách hàng chương trình hay được sửa đổi trực tiếp dẫn đến bản
đặc tả phần mềm không phản ánh đầy đủ những gì đã được sửa đổi trong mã nguồn.
Người sử dụng không có cơ hội tham gia trong suốt thời gian của các giai đoạn
-
trung gian từ thiết kế cho đến kiểm thử. Đặc biệt với những dự án lớn, người sử dụng
chỉ có thể nhận ra rằng hệ thống phần mềm không phù hợp cho nhu cầu của họ vào
thời điểm cuối dự án.
ẩn chứa nhiều rủi ro mà chỉ có thể phát hiện ở giai đoạn cuối cùng và chi phí để
-
sửa chữa có thể rất cao.
2. V-model:
Các giai đoạn phát triền
-Tương ứng mỗi giai đoạn của chu kỳ phát triển là giai đoạn kiểm thử tương ứng.
Phía bên trái của mô hình chữ V là giai đoạn (vòng đời) phát triển phần mềm. Phía bên
phải của mô hình chữ V là các hoạt động kiểm thử tương ứng.
Ưu điểm.
-
Đơn giản dễ sử dụng.
-
Có hoạt động, kế hoạch cụ thể cho quá trình test.
-
Tiết kiệm được thời gian, và có cơ hội thành công cao hơn waterfall.
-
Các hoạt động kiểm thử được chú trọng và thực hiện song song với các hoạt
động liên quan đến đặc tả yêu cầu và thiết kế. Chủ động trong việc phát hiện bug, sớm
tìm ra bug ngay từ những bước đầu.
Nhược điểm.
17
Độ linh hoạt ít và còn tồn tại sự cứng nhắc. Nó thể hiện ở chỗ cứ sau mỗi step
-
thì lại phải có một - công đoạn test, nếu yêu cầu dự án không quá phức tạp và dễ hiệu,
thì việc thực hiện nhiều công đoạn test như vậy là tốn thời gian.
Giống với waterfall, sản phẩm của dự án chỉ được xuất hiện khi tất cả các bước
-
được hoàn thành xong, không có nguyên mẫu ngay từ ban đầu. Không đáp ứng được
yêu cầu dịch vụ vừa phát triển, song song với vừa bán sản phẩm.
Nếu có sự thay đổi về kỹ thuật ở nửa chừng, thì sẽ phải quay lại các bước đầu
-
tiên, thực hiện lại, update lại tài liệu.
3, mô hình agile
Các giai đoạn phát triển
Là dạng mô hình phát triển “lặp”. Trong mô hình loại này, việc phát triển phần
mềm được tiến hành theo từng chặng và mỗi chặng chỉ tập trung phát triển 1 hoặc vài
tính năng của sản phẩm. Mỗi dự án được chia thành nhiều mảng nhỏ để dễ sử dụng và
thay đổi khi khách hàng yêu cầu thay đổi. Từng phần nhỏ của dự án sẽ được test ngay
trong quá trình làm dự án. Yêu cầu gặp mặt trao đổi thường xuyên vì trong Agile tại
mỗi thời điểm cả nhóm phải cùng tập trung phát triển một mảng của dự án. Ưu điểm
Agile là sự lựa chọn rất tốt cho những dự án nhỏ bởi những dự án nhỏ thường
-
có những yêu cầu không được xác định rõ ràng và có thể thay đổi thường xuyên.
Với Agile khách hàng có thể được xem trước từng phần dự án trong suốt quá
-
trình phát triển vì Agile phát triển phần mềm theo hướng tăng dần, có thể đưa cho
khách hàng xem từng phần đã thực hiện hoàn thành. Từ đó có thể bám sát dự án và
luôn sẵn sàng cho bất kỳ thay đổi nào từ phía khách hàng yêu cầu về dự án.
Agile chia dự án thành những phần nhỏ và giao cho mỗi người, hàng ngày tất
-
cả mọi người phải họp với nhau trong khoảng thời gian ngắn để thảo luận về tiến độ và
giải quyết những vấn đề nảy sinh nếu có nhằm đảm bảo đúng quy trình phát triển dự
án. Tỉ lệ thành công của các dự án sử dụng Agile thường cao hơn các quy trình khác.
Nhược điểm
-
Thiếu sự nhấn mạnh về thiết kế và tài liệu cần thiết
-
Quy mô nhân lực thường giới hạn từ 7 đến 10 người, sẽ có trở ngại lớn nếu
nguồn nhân lực yêu cầu vượt quá con số này ví dụ trong các cuộc họp trao đổi.
Số lượng yêu cầu có thể nhiều và khó quản lý nếu như nó bao gồm nhiều khía
-
18
cạnh khác nhau về dự án.
1.3. TỔNG QUAN QUÁ TRÌNH NGHIÊN CỨU
1.3.1 . Trên Thế Giới
Trên thế giới , những công trình nghiên cứu về kiểm thử phần mềm đã được các
tác giả ấp ủ và rút ra được rất nhiều điều . Dưới đây là hai cuốn sách rất bổ ích để
đào tạo và trau dồi kiến thức kiểm thử gồm :
User Stories Applied
Cách tốt nhất để xây dựng phần mềm đáp ứng được nhu cầu của người dùng là
bắt đầu bằng "user story": đơn giản, rõ ràng, mô tả ngắn gọn về chức năng sẽ có giá trị
cho người dùng thực.
Trong cuốn User Stories Applied, bạn sẽ học được điều gì tạo nên một user story
tuyệt vời, và điều gì làm cho một user story không tốt. Bạn sẽ khám phá ra cách thực
hành để thu thập user story, ngay cả khi bạn không thể nói chuyện với người dùng của
mình. Sau đó, khi bạn đã biên soạn user story, tác giả cho chúng ta biết cách tổ chức
chúng, xác định độ ưu tiên và sử dụng chúng để lập kế hoạch, quản lý và kiểm thử.
Sau khi đọc cuốn sách chúng ta sẽ rút ra được rất nhiều điều như
Mô hình hóa vai trò người dùng: Hiểu người dùng có điểm gì chung và khác
-
biệt ở đâu
Thu thập các user story: phỏng vấn người dùng, thăm dò ý kiến, quan sát và hội
-
thảo
-
Làm việc với các manager, trainer, salespeople và các người đại diện khác
-
Viết user story để kiểm thử chấp nhận
-
Sử dụng các user story để thiết lập độ ưu tiên, thiết lập lịch biểu và ước tính chi
phí phát hành
Specification by Example
Đặc tả bằng ví dụ là một phương pháp hợp tác để xác định các yêu cầu và kiểm
-
thử.
Trong cuốn sách này, tác giả Gojko Adzic phỏng vấn các team thành công trên
-
19
toàn thế giới, chia sẻ cách họ xác định, phát triển và bàn giao phần mềm, mà không có
-
lỗi, trong các chu kỳ phân phối ngắn lặp đi lặp lại.
Các nghiên cứu điển hình trong cuốn sách này bao gồm các trang web khởi
nghiệp nhỏ cho các tổ chức tài chính lớn, hoạt động trong nhiều quy trình bao gồm XP,
-
Scrum, và Kanban.
Trong cuốn Specification by Example, tác giả mô tả khái niệm về các đặc tả có
thể thực hiện được được kiểm tra tự động như tài liệu. Loại tài liệu này luôn cập nhật,
-
bởi vì nó chạy hàng ngày chống lại phần mềm để kiểm tra nó.
Cuốn sách này dành cho các nhà phát triển, người thử nghiệm, nhà phân tích làm
việc cùng nhau để xây dựng phần mềm tốt nhất vì nó nhấn mạnh tầm quan trọng của
việc hiểu các yêu cầu của khách hàng và làm thế nào để thực hiện nó sao cho đáp ứng
được nhu cầu của khách hàng.
Continuous Delivery
Việc phát hành phần mềm cho người dùng thường là một quá trình vất vả, may rủi
và tốn nhiều thời gian.
Sau khi đọc cuốn sách này, bạn sẽ học được các nguyên tắc và kỹ thuật thực tiễn
cho phép cung cấp chất lượng, tính năng mới có giá trị và nhanh chóng cho người
dùng.
Cuốn sách này bao gồm
Tự động hóa mọi khía cạnh của việc xây dựng, tích hợp, thử nghiệm và triển
-
khai phần mềm
-
Thực hiện các đường ống triển khai ở cấp độ team và tổ chức
-
Cải thiện sự hợp tác giữa deverloper, tester và nhà điều hành
-
Phát triển các tính năng gia tăng trên các tem lớn và phân tán
-
Thực hiện chiến lược quản lý cấu hình hiệu quả
-
Kiểm thử chấp nhận tự động, từ phân tích đến thực hiện
-
Khả năng kiểm thử và các yêu cầu phi chức năng khác
-
Thực hiện triển khai liên tục và các bản phát hành không ngừng hoạt động
-
Quản lý cơ sở hạ tầng, dữ liệu, các thành phần và phụ thuộc
-
Điều hướng quản lý rủi ro, tuân thủ và kiểm toán
1.3.2. Trong Nước
Hiện nay nước ta hiện nay có rất nhiều tài liệu nghiên cứu về kiểm thử phần
20
mềm
Trong đó có các cuốn sách
“ kiểm thử phần mềm ( testing)” - tác giả Trần tường Thụy
và Phạm Quang
Hiển : cuốn sách này tác giả khái quát cho chúng ta những nội dung cơ bản về testing,
các kĩ thuật kiểm thử, cách làm việc với các ứng dụng rất hiệu quả
“Kiểm thử các ứng dụng web” là một trong những bộ sách bán chạy tại Mỹ. Đồng
tác giả của bộ sách gồm ông Nguyễn Quốc Hùng, ông Michael Hackett và ông Bob
Johnson, là 3 chuyển gia về lĩnh vực kiểm thử phần mềm trên thế giới.
Ngoài những cuốn sách này để học hỏi thêm về kiến thức kiểm thử còn có các
trang web như VIBLO , trong trang web này đều là kinh nghiệm của các anh chị đi
trước có kinh ngiệm về kiểm thử viết các bài viết bổ ích , về quy trình
Ví dụ như :
Bài viết của anh Nguyễn Huy Hùng về Một số lời khuyên khi review code
Trong bài viết anh có nói về 5 lời khuyên
1. Đặt ra thứ tự ưu tiên khi review
2. Hãy "chơi đùa" với ứng dụng
3. Trực quan hóa
4. Khi có yêu cầu từ ai đó, hãy review code càng sớm càng tốt
5. Tưởng tượng mình là người thực hiện những thay đổi đó
6. Đọc về những thay đổi trong môi trường phát triển thực tế
7. Luôn luôn đưa ra những sự đồng thuận, trừ khi bạn có thể chứng tỏ rằng có
bug xảy ra
Như vậy .tại VN kế thừa rất nhiều công trình nghiên cứu của thế giới của công
nghệ kiểm thử phần mềm . Về mặt triển khai thực tế tại các doanh nghiệp hầu hết
doanh nghiệp đã xây dựng được quy trình kiểm thử dành cho các phần mềm hay trang
web của mình tuy nhiên trong ngành chế biến thực phẩm ăn liền như công ty cổ phần
sản xuất thương mại Tiến Nga việc kiểm thử cho website
của công ty còn nhiều
vướng mắc , chưa được chú trọng nhiều .Đặc biệt qua khảo sat tại công ty vấn đề này
chưa quan tâm thì khoảng trống, giải pháp cho vấn đề này cấp thiết và ý nghĩa khoa
21
học lý luận và thực tiễn.
Vì vậy em đã đề xuất ra đề tài luận “Xây dựng quy trình kiểm thử cho website
công ty cổ phẩn sản xuất thương mại Tiến Nga ”
22
CHƯƠNG 2: KẾT QUẢ PHÂN TÍCH ĐÁNH GIÁ THỰC TRẠNG CỦA ĐỀ
TÀI “XÂY DỰNG QUY TRÌNH KIỂM THỬ CHO WEBSITE CỦA CÔNG TY
CỔ PHẦN SẢN XUẤT THƯƠNG MẠI TIẾN NGA ”
2.1 Tổng quan tình hình công ty cổ phần sản xuất thương mại Tiến nga
2.1.1. Giới thiệu về công ty
-
Sơ lược về công ty, quá trình thành lập và phát triển của doanh nghiệp
Cổ Phần Sản xuất Thương Mại Tiến Nga lập ngày 22/08/2005
Trụ sở chính: 1/11 Đường Linh Đông, KP7, P.Linh Đông, Q.Thủ Đức, Tp.HCM
Nhà Máy: Đường Chu Mạnh Trinh, Tp.Biên Hòa,Tỉnh Đồng Nai
Chi nhánh Hà Nội: Ô 17.1, Lô E7, Đường Phạm Hùng, Phường Mễ Trì, Quận
Nam Từ Liêm, Hà Nội
Điện thoại : (028).37203122 -38968498-37205960
Fax: (028).37204429
Email:
Website:
-
Các lĩnh vực hoạt động
Công ty Cổ Phần Sản xuất Thương Mại Tiến Nga thành lập ngày 22/08/2005
.lĩnh vực kinh doanh chính của công ty là chế biến thực phẩm. sản phẩm của công ty
có mặt trên toàn quốc thông qua các hệ thống siêu thị
-
Cơ sở vật chất
+Nhà máy sản xuất tại biên hòa đồng nai
+Khu nhà nghỉ 2 tầng khang trang hiện đại phục vụ cho đội ngũ công nhân viên
của công ty
+Cơ sở máy tính , máy in đầy đủ dành cho cán bộ , nhân viên văn phòng
23
-
Cơ cấu tổ chức của công ty
Hình 1 .Sơ đồ cơ cấu tổ chức của công ty
( Nguồn :tổng hợp )
Chức năng nhiệm vụ các phòng ban.
-
Hội đồng quản trị : nhân đanh công ty quyết định mọi vấn đề liên quan mục đích và
quyền lợi của công ty , Hội đồng quản trị có trách nhiệm giám sát hoạt động của tổng
-
giám đốc và các cán bộ quản lí khác
Tổng giám đốc : tổng giám đốc điều hành quyết định các vấn đề liên quan đến hoạt
động sản xuất kinh doanh , chịu trách nhiệm trước Hội đồng quản trị về việc thực hiện
các quyền và nghĩa vụ được giao , các giám đốc giúp việc cho từng lĩnh vực và chịu
-
trách nhiệm trước tổng giám đốc trong công việc được giao
Ban giám sát: có nhiệm vụ kiểm tra tính hợp lí , hợp pháp , tính trung thực trong việc
quản lí . ban kiểm soát hoạt động độc lập với ban giám đốc , báo cáo trực tiếp với Hội
24
-
đồng quản trị
Giám đốc tài chính , giám đốc kinh doanh –maketing , giám đốc chi nhánh Hà Nội ,
giám đốc chi nhánh Hồ Chí Minh , giám đốc nhà máy : thực hiện và chịu trách nhiệm
-
trước tổng giám đốc
Trưởng phòng RD : nghiên cứu và phát triển sản phẩm theo kế hoạch của tổng giám
đốc duyệt, thực hiện và đánh giá các sản phẩm mới ,tham gia các buổi test sản phẩm
với người tiêu dùng , đánh giá để đề xuất hướng phát triển mới
Kết quả kinh doanh
Bảng 1: kết quả kinh doanh từ năm 2015-2017 công ty cổ phần sản xuất
thương mại Tiến Nga
So sánh
Các chỉ tiêu
Năm
2015
Năm 2016
Năm 2017
2016/2015
Chênh
Tỷ
1.Tổng doanh
2965
4215
6135
lệch
1250
thu
2. Tổng chi phí
3. Tổng lợi
2143
822
3150
1065
4715
1420
1007
243
So sánh
2017/2016
Chênh
Tỷ
lệ(%)
42.1
lệch
1920
lệ(%)
45.5
46.1
29.5
1565
355
49.05
33.3
nhuận
(Nguồn : tổng hợp)
-
Năm 2016/2015: Tổng doanh thu tăng 42.1% tương ứng tăng 1250 triệu đồng.
Tổng chi phí tăng 46.1% tương ứng tăng 1007 triệu đồng.
Tổng lợi nhuận tăng 29.5% tương ứng tăng 243triệu đồng.
-
Năm 2017/2016: Tổng doanh thu tăng 45.5% tương ứng tăng 1920 triệu đồng.
Tổng chi phí tăng 49.05% tương ứng tăng 1565 triệu đồng.
Tổng lợi nhuận tăng 33.3% tương ứng tăng 355 triệu đồng
Chỉ tiêu tài chính của Công ty dự tính Năm 2018
Công ty CPSXTM Tiến Nga đạt mục tiêu tăng trưởng ổn định; giữ được khối
khách hàng trọng điểm; cơ cấu lại dịch vụ theo hướng dịch chuyển dần và tăng tỷ
trọng doanh thu của các mảng dịch vụ giá trị gia tăng và giải pháp tương ứng các chỉ
tiêu trong năm 2018, với doanh thu tăng 65%, lợi nhuận tăng gấp 2.5 lần năm 2017
Tỷ lệ đầu tư cho công nghệ thông tin (%)
Ước tính tỉ trọng của chi ứng dụng CNTT trong tổng chi phí hoạt động thường
25
