Tài liệu 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

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 ! MỤC LỤC LỜI CẢM ƠN ..............................................................................................................i TỔNG QUAN VỀ ĐỀ TÀI NGHIÊN CỨU...............................................................1 1.Tính cấp thiết của đề tài..............................................................................................1 2.Mục tiêu nghiên cứu của đề tài...................................................................................2 3. Đối tượng và phạm vi nghiên cứu của đề tài..............................................................2 CHƯƠNG 1. CƠ SỞ LÍ LUẬN VỀ KIỂM THỬ......................................................4 1. Cơ sở lý luận về kiểm thử..........................................................................................4 1.1. Khái niệm cơ bản về kiểm thử...............................................................................4 1.1.1. khái niệm kiểm thử phần mềm.............................................................................4 1.1.2. Mục tiêu Kiểm thử phần mềm.............................................................................5 1.1.3 . Các nguyên tắc cơ bản của kiểm thử...................................................................6 1.1.4 Vai trò của kiểm thử............................................................................................7 Vai trò của kiểm thử phần mềm là.................................................................................7 1.2 . Một số lý thuyết cơ bản về kiểm thử......................................................................8 1.2.1 .Quy trình kiểm thử...............................................................................................8 1.2.2. Các phương pháp kiểm thử................................................................................10 1.2.3.Các kĩ thuật kiểm thử.........................................................................................10 1.2.4 . Mô hình kiểm thử phần mềm............................................................................11 1.3. TỔNG QUAN QUÁ TRÌNH NGHIÊN CỨU.......................................................13 1.3.1 . Trên Thế Giới...................................................................................................13 1.3.2. Trong Nước........................................................................................................15 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 ”...........................................17 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....................17 2.1.1. Giới thiệu về công ty..........................................................................................17 2.1.2. Thực trạng ứng dụng công nghệ thông tin và thương mại điện tử tại công ty cổ phần sản xuất thương mại Tiến Nga............................................................................20 2.2 Đánh giá website công ty......................................................................................25 CHƯƠNG 3: ĐỊNH HƯỚNG PHÁT TRIỂN VÀ ĐỀ HƯỚNG GIẢI PHÁP “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 ”..................................................26 3.1. Phương hướng phát triển của công ty cổ phần sản xuất thương mại Tiến Nga trong gia đoạn năm 2018 đến 2023.......................................................................................26 3.2. Giải pháp xây dựng quy trình kiểm thử tại công ty cổ phần sản xuất thương mại Tiến Nga...................................................................................................................... 28 3.2.1 . xây dựng quy trình kiểm thử cho website.........................................................28 3.2.2 Xây dựng test case kiểm thử chức năng đặt hàng................................................29 3.2.3. Ứng dụng phần mềm quản lí lỗi redmine...........................................................44 3.2.4 Đánh giá và bình luận........................................................................................47 PHỤ LỤC DANH MỤC BẢNG BIỂU 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...................................................................................................................... 19 Bảng 2: trang hiết bị phần cứng của công ty cổ phần sản xuất thương mại Tiến Nga..21 Sơ đồ 1: sơ đồ mạng của công ty cổ phần sản xuất thương mại Tiến Nga...................20 Hình 1 .Sơ đồ cơ cấu tổ chức của công ty....................................................................18 Hình 2.1. Biểu đồ đào tạo công nghệ thông tin...........................................................22 Hình 2.2. Biểu đồ khách hàng tiếp cận qua website.....................................................24 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 ” 1 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 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. 2 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 3 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 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. 4 - 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. 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 5 đượ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 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 6 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ư: - 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. 7 - 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. - 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: 8 - 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. - 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. 9 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: - 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) 10 - Đâ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 Ư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 11 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. - Độ 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 12 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 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 13 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 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 14 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 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 15 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 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 ” 16