ERP ERP-TEST? Các bạn sẽ nói gì?

Thảo luận trong '[QC] Phần mềm kế toán, giải pháp quản trị DN' bắt đầu bởi springthuy18, 28 Tháng mười 2005.

6,622 lượt xem

  1. springthuy18

    springthuy18 Thành viên sơ cấp

    Bài viết:
    47
    Đã được thích:
    0
    Nơi ở:
    Ha Noi
    Chào bạn tuanna_itsoft!
    Tôi đọc bài của bạn tuanna_itsoft có nói về ERP-TEST, mà tôi chưa thấy biết gì về điều này cả. Và tôi xin mạn phép bạn để đưa đề tài này vào việc trao đổi với mọi người! Vâỵ bạn hãy tham gia chủ đề này với tôi nhé!
    Tôi không phải là một nhà cung cấp ERP, tôi cũng không là đơn vị nào đã sử dụng ERP, nhưng tôi thực sự quan tâm đến vấn đề này!
    Vậy trong bản thân ERP thì việc Test có quan trọng không? Và Test sẽ đem lại lợi ích gì cho sản phẩm ERP? Test trong ERP như thế nào?....
    Ôi có lẽ tôi phải học về công nghệ thông tin để biết test là gì........
    Mọi người hãy giúp tôi nhé!
    Cảm ơn mọi người!
     
    #1
  2. NgânGiang

    NgânGiang Cố lên! Cố lên...

    Bài viết:
    202
    Đã được thích:
    0
    Nơi ở:
    Trong Mây mù
    Mình cũng không rành lắm, chỉ mạn phép các cao thủ góp vài lời.
    Các bác có thấy khi mài 1 con dao, muốn biết nó có sắc hay không thì thử gại vào tay. Cạo thôi đừng cứa nhé, và theo cảm nhận của người mài có thể xác định được nó sắc hay không. Như vậy cũng gọi là 1 cái test nho nhỏ.
    Khi đóng 1 con tàu, hay lắp đặt 1 cỗ máy...; để nó hoạt động thì cần sự phối hợp của nhiều bộ phận: Động cơ, bộ phận truyền dẫn ... Và người ta phải làm những cái Test gọi là chạy thử (Rõ ràng là kỹ hơn kiểm tra độ sắc của con dao. Trong hạch toán kế toán cũng thừa nhận chi phí lắp đặt chạy thử được cộng vào nguyên giá TSCĐ)
    Trong viết phần mềm, nếu chỉ để giải quyết 1 vấn đề nào đó có thể chỉ cần viết 1 chương trình con và theo kinh nghiệm của người lập trình có khi cũng không chạy thử hoặc chỉ chạy sơ sơ và đưa vào sử dụng.
    Còn với ERP, ở góc độ nào đó được hiểu là phần mềm đóng gói dùng cho nhiều lĩnh vực. Giống như bộ lego đựng trong 1 cái túi, ta mua về - xem hướng dẫn và ráp thành cái xe, cái nhà ... theo mong muốn sử dụng của ta. Và đây thực sự là phần mềm đồ sộ, để đảm bảo nó vận hành tốt cần xây dựng các test từ phân quyền cho người dùng đến nhập dữ liệu thì nó đưa đến đâu, khả năng kết xuất ra sao ... Nói đến đây thì mình thấy bí rồi
    Mong được học tập thêm
     
    #2
  3. alovo

    alovo Thành viên thân thiết

    Bài viết:
    95
    Đã được thích:
    0
    Nơi ở:
    Quê huơng là chùm kế ngọt
    Bạn à! khi chào mời triển khai ERP thì nhà cung cấp nói đều làm được và dn thì cứ nghĩ ERP làm được tất cả mọi thứ, do vậy test ERP là chạy thử chương trình theo bài toán mẫu mà NCC đưa ra xem vướng mắc ở đâu thì giải quyết ở đó, nó có thể hệ thống mạng của dn có vấn đề hoặc 1 khâu nào đó không theo quy trình đưa ra.... và có rất nhiều cái cần xem xét do vậy bạn có thể hiểu theo 2 nghĩa: sai đâu sửa đấy hoặc sửa đâu sai đấy...
     
    #3
  4. hai2hai

    hai2hai VNUNI Makes a difference

    Bài viết:
    2,012
    Đã được thích:
    128
    Nơi ở:
    Hà nội
    Không hiểu mọi người nói test ERP là xét trên quan điểm nào?

    Nếu xét trên quan điểm từ khi phát triển đến lúc bàn giao sản phẩm phần mềm thì phần mềm nào cũng phải trải qua nhiều loại test chứ ko chỉ đơn thuần là đưa cho end users hay 1 ai đó gõ gõ mấy cái trên PM rồi bảo đó là test.

    Này nhé, khi viết tài liệu yêu cầu phần mềm, khi ta thiết kế (mức cao, mức chi tiết), khi ta viết code, v.v... và sau đó ta phải review lại xem những cái đó có đúng không,... Cái đó người ta gọi là Document Review (Hay còn gọi là test tài liệu)

    Mỗi khi thực hiện xong 1 module (hiểu theo nghĩa đơn vị nhỏ nhất của PM) chứ ko phải module finance như mọi người hiểu thì người lập trình test ngay module đó. Cái đó người ta gọi là Unit test

    Sau khi các modules được thực hiện và Unit test xong thì được lắp giáp với nhau để được 1 khối to hơn (có thể là phần mềm hoặc 1 phân hệ nào đó) và cần phải test xem các modules đó sau khi gắn vào thì có lỗi ko? có ản hưởng tới các modules khác mà gây lỗi không, v.v.... Cái đó cũng cần phải test và người ta gọi là Integration test

    Sau khi đã có 1 hệ thống đã được lắp ghép, người ta kiểm tra phần mềm dựa trên bản thiết kế (thiết kế có nhiều views lắm) và tài liệu yêu cầu phần mềm. Cái đó người ta gọi là System test.

    Sau khi System Test rồi thì đó mới chỉ là test nội bộ thôi. Khi đem đến khách hàng để ký nghiệm thu hợp đồng và trước khi làm cái việc mà vendor sung sướng đó thì phải trải qua 1 giai đoạn là Khách hàng sẽ kiểm tra xem PM đã đáp ứng đúng theo các yêu cầu mà 2 bên đã ký kết trước khi thực hiện phần mềm hay không (thường là dựa vào tài liệu Đặc tả yêu cầu phần mềm) --> Cài này người ta gọi là Acceptant test.

    Sơ sơ thì các loại test là như vậy.

    Còn có nhiều cách phân loại test nữa như operation test, black test, white test, v.v...

    Dĩ nhiên, nói về test trong phần mềm thì nói cả ngày chưa hết. Ví dụ, nào là test leader, tester, test plan, test case, v.v... rất nhiều thuật ngữ về test mà chỉ có ai đã từng làm theo CMM, đọc các tài liệu về test, hay đã từng làm việc ở các công ty phần mềm lớn mới hiểu thế nào là TEST.

    Chúc mọi người vui vẻ với ERP test theo cách riêng của mình nhé. (Có lẽ cách hiểu test của tớ ko dính dáng đến ERP mấy nhỉ :))
     
    Last edited: 29 Tháng mười 2005
    #4
  5. tuanna_itsoft

    tuanna_itsoft Thành viên sơ cấp

    Bài viết:
    55
    Đã được thích:
    0
    Nơi ở:
    Dân "du mục"
    Bác hai2hai thử coi lại cái certificate của CMM xem ở VN hiện nay có bao nhiêu công ty đạt được, cái mà bác đưa ra tôi thấy cũng rất basic của Test, nhưng đấy mới chỉ là cho software-supporter thôi, còn về khía cạnh end-user thì chưa, hiện nay có một số các template của test sản phẩm, bác nào có nhu cầu, liên hệ với tôi YM: itsoft_online. Đây cũng là quy trình test tôi đúc kết thôi, tuy hơi khó và rườm rà nhưng tôi thấy là được
     
    #5
  6. tuanna_itsoft

    tuanna_itsoft Thành viên sơ cấp

    Bài viết:
    55
    Đã được thích:
    0
    Nơi ở:
    Dân "du mục"
    Nếu bạn muốn thì liên hệ với tôi, YM: itsoft_online, cái này đưa lên diễn đàn dài lắm. CHúng ta cùng thảo luận, OK?
     
    #6
  7. PAT

    PAT PAT

    Bài viết:
    287
    Đã được thích:
    3
    Nơi ở:
    Ho chi Minh city
    to springthuy18

    Bạn hai2hai đã trình bày bài toán test với cách nhìn của một nhà phát triển phần mềm. PAT thử trao đổi cách nhìn test với ghó độ người dùng thông qua một vài ví dụ :

    Ví dụ 1 : Bạn hãy làm một động tác nhâp số liệu là chúng từ mua hàng với các nội dung khác nhau - Tên , số chứng từ, hợp đồng, điều khoản thanh toán. Bạn đang nhập ở ô cuối cùng ->phát hiện thấy sai thông tin ở lần nhập trước. Bạn có thể qua trở lại bằng cách dùng phím mũi tên <- hoặc phím chỉ lên hoặc dùng chuột đưa con trỏ đến vị trí cấn sửa và click.. Nếu chỉ kiểm soát con chuột mà không test phím -> lỗi. hãy tưởng tượng hàng nghìn màn hình nhập liệu như vậy với các tổ hợp phím bạn phải test để người dùng không gặp lỗo trong vận hành. Đó là công tác test đấy.

    Ví dụ Hai : bạn nhập liệu vào ô ngày chứng từ. Bạn có thể đánh theo kiểu dd/mm/yyyy hoặc mm/dd/yyyy hoặc một các nào đó. nếu vô tình sai hoặc không kiểm tra số liệu đúng -> tập hợp chứng từ có thể sai. Tìm và loại trừ các khả năng này -> Đó là test đấy

    Ví dụ ba : Bạn định nhập thông tin tên tuổi, số chứng từ với dộ dài lớn nhất là 40 ký tự. Nhưng chương trình lại không cho biết bạn đã vượt quá quy định này -> thông tin nhập vào chương trình bị sai. kiểm tra hết các kảh năng có thể xây ra -> Đó là test đấy.

    Ví dụ thứ bốn : , Bạn nhập số lượng , mặt hàng, hệ thống tính được thành tiền, các loại thuế. Nếu không đúng bạn sẽ có số liệu doanh thu sai, báo cáo thuế không đúng. kiểm tra tất cả tính đúng đắn của các nghiệp vụ phát sinh trước khi đi bán chương trình -> Đó là test đấy.

    Ví dụ thứ năm: Bạn phải chuyển chứng từ từ kinh doanh hay kho lên phòng kế toán nếu chuyển không được hoặc chuyển sai địa chỉ thì phòng kế toán sẽ không có thông tin để theo dõi công nợ hay giá trị tồn kho . Kiểm tra và loại trừ tất cả các sai sót cho tất cả các nghiệp vụ phát sinh ->đấy là test

    Ví dụ thứ sáu : Thực tế công việc của nhiều doanh nghiệp có số liệu lớn, đòi hỏi phải làm hóa đơn bán hàng chẳng hạn, nhanh trong thời gian ngắn . Tốc độ chương trình không đáp ứng chẳng hạn. Tính toán và đảm bảo tố độ xử lý ứng với các kích thứoc nghiệp vụ khác nhau phù hợp với thực tế -> Đó là test đấy

    Ví dụ thứ bảy : Khi đưa hệ thống vào hoạt động. bí mật thông tin trở nên là đối tượng cần bảo vệ. Kiểm tra ngăn ngừa các khả năng ăn cắp thông tin từ hệ thống như tư cách là một người muốn ăn trộm ...-> Đó là test

    PAT chỉ đưa một vài ví dụ để bạn hình dung chứ còn trong nội bộ công ty phần mềm thì có nhiều mức kiểm soát chât lượng lắm và phải hình thành một quy trình hẳn hoi. Thực tế để test một module quản lý sản xuất trong giải pháp IRP Solution công ty của PAT có một đội từ 12-15 người test trong gần hai năm mới hết các kịch bản đề ra.

    Nếu test kỹ thì khách hàng sẽ được hưởng lợi và cũng giảm chi phí cho bản thân công ty phần mềm. Khi deliver một phần đóng gói của dự án của công ty PAT làm với Nhật - Đã đưa vào triển khai cho 4 khách hàng bên nhật từ cuối tháng 1 đến nay mới chỉ nhận được phản hồi 2 lỗi - Điều này cũng giúp công ty AZ Solution tiết kiêm rất nhiều các chi phí

    Chia xẻ với các bạn một vài kinh nghiệm của mình
     
    #7
  8. alovo

    alovo Thành viên thân thiết

    Bài viết:
    95
    Đã được thích:
    0
    Nơi ở:
    Quê huơng là chùm kế ngọt
    Nhân việc nói về test cho người dùng cuối, tôi xin đưa ra ví dụ về 1 công ty CPN. Sau khi khảo sát dn và viết từng quy trình cho từng bộ phận từ IT, nhập liệu, kho, kế toán.... đến GĐ. Với yêu cầu GĐ là bảo mật, oneline liên tục, truy vết để quy trách nhiệm cho từng bộ phận và từng cá nhân và tích hợp hệ thống cân điện tử với hệ thống quýet mã vạch để tạo chu trình khép kín để có thể check oneline xem hàng hoá đang ở đâu và mấy giờ đến tay người nhận... Bên cung cấp đưa ra giải pháp sử dụng cilen/server để tất cả dữ liệu điều đổ về server, mọi vấn đề đều ngon lành cho đến khi chạy mã vạch thì dữ liệu ở chi nhánh quýet thì chờ đến 15 p mới xong 1 vận đơn trong khi mỗi ngày khoảng 2000VĐ(??? )... đến in thì chỉ in ở máy chủ ở CT chứ không in được ở CN và căng thẳng xảy ra khi lập thêm 1 CN mà ở đó không có ADSL ( làm sao oneline đây và backup dữ liệu khi chỉ có 2 cơ sở là PRO và SYS chứ không có cho từng chi nhánh)...và còn rất nhiều vấn đề khác. Nên túm lại càng hiểu dn bao nhiêu càng tốt bấy nhiêu
     
    #8
  9. hai2hai

    hai2hai VNUNI Makes a difference

    Bài viết:
    2,012
    Đã được thích:
    128
    Nơi ở:
    Hà nội
    Sau khi đã có 1 hệ thống đã được lắp ghép, người ta kiểm tra phần mềm dựa trên bản thiết kế (1) (thiết kế có nhiều views lắm) và tài liệu yêu cầu phần mềm (2). Cái đó người ta gọi là System test.

    Vậy, với cơ sở thứ 2 là tài liệu yêu cầu phần mềm (đáp ứng khá chi tiết các yêu cầu bao gồm, yêu cầu nghiệp vụ - quy trình..., yêu cầu về giao diện, yêu cầu về kiến trúc, yêu cầu về bảo mật, yêu cầu về tốc độ, yêu cầu về tích hợp, v.v....các yêu cầu này nằm trong các tài liệu yêu cầu (đối với dự án CDM thì do 2 bên đã thống nhất, đối với SP thương mại thì tài liệu yêu cầu do nhà cung cấp tự xây dựng) thì test này là đảm bảo những gì mà bác PAT đưa ra. Các ví dụ mà bác PAT đưa ra chính là 1 phần trong công việc SYSTEM TEST.

    Ngoài ra, Acceptant Test cũng là do người bên mua hàng và bên cung cấp cùng thực hiện chứ ko phải chỉ do nhà cung cấp PM thực hiện. Và làm cái Acceptant Test cũng là dựa trên tài liệu yêu cầu phần mềm đấy chứ.

    Bên cạnh các quy trình test như vậy thì có các phương pháp để test như phương pháp black box test, white box test, v.v...

    Bác PAT ạ, em cũng 1 lần làm PM do bọn Nhật nó detail design. Quả thật, khi đã có chi tiết các tài liệu yêu cầu, có thiết kế chi tiết và qua bọn nó test trước khi deliver SP thì đúng là công việc của lập trình viên cực nhàn hạ (cứ nhìn mà code thôi-chẳng hiểu phần mềm nó làm cái gì cả) và sản phẩm sau này chẳng mấy khi phải support mấy (trừ 1 lần nó chết con ổ cứng server - nhưng đã có giải pháp tap backup hàng ngày rồi nên ko sao cả)

    Từ hồi đó đến nay em chưa làm 1 dự án nào sướng như vậy.
     
    Last edited: 29 Tháng mười 2005
    #9
  10. tuanna_itsoft

    tuanna_itsoft Thành viên sơ cấp

    Bài viết:
    55
    Đã được thích:
    0
    Nơi ở:
    Dân "du mục"
    Bác hai2hai này còn làm ERP thì anh em sẽ được nhiều kinh nghiệm lắm đây, bravo hai2hai, tiếp tục đi bác, lâu lắm mới có người post nhiệt tình như bác, có khi chúng mình cùng compress nó vào sau đó share cho mọi người thì tốt hơn đấy, chứ nếu post bài nên như vậy tôi thấy không ổn lắm, dài quá
     
    #10
  11. nguoingoaihanhtinh

    nguoingoaihanhtinh Thành viên sơ cấp

    Bài viết:
    17
    Đã được thích:
    0
    Nơi ở:
    Sao Thổ
    Các bác ơi? mình làm rồi tự minh kiểm tra thì sao không để người khác test thử lại cho minh?
     
    #11
  12. hai2hai

    hai2hai VNUNI Makes a difference

    Bài viết:
    2,012
    Đã được thích:
    128
    Nơi ở:
    Hà nội
    Bác này....bị làm sao vậy, đọc bài 1, đọc bài 2, cố gắng nhịn đi. Đọc đến bài này...choáng quá. Thôi thì tớ đoán luôn:

    1. Bác tự xưng ko phải là dân kế toán rồi nên khỏi phải đoán vì dân nhà kế chắc là rất kiên nhẫn.

    2. Bác không phải là dân làm business rồi vì dân business họ im tiếng lắm. Ăn nói khá thận trọng và ko làm mếch lòng người khác bao giờ.

    3. Dân ngoại đạo chăng ??? Chắc ko phải vì nếu ko có tý related gì đến IT hay kế toán hay KD về PMKT... thì chắc ko lên đây viết thế này mà chỉ nghe ngóng mà thôi.

    4. Là dân IT đang làm về PM KT (vì thấy nói về test) chăng? Hỡi ôi, dân IT đâu có vậy!!! Các bạn đồng nghiệp tớ đang làm việc quần quật kia kìa. Có ai nói về test như người ngoàihtinh đâu.

    5. Chỉ có thể là .... unknown object (người ngoài hành tinh tiếng anh gọi là gì ấy nhể). Mới biết wkt có 1 ngày thì phải.
     
    Last edited: 31 Tháng mười 2005
    #12
  13. lion_itsoft

    lion_itsoft Thành viên sơ cấp

    Bài viết:
    5
    Đã được thích:
    0
    Nơi ở:
    Hà Nội
    Test ERP hấp dẫn quá!

    Tiểu muội xin chào các anh các chị!
    Em thấy trong quy trình công nghệ phần mềm thì quy trình test là cực kỳ quan trọng. Nó cho phép từ nhà phân tích thiết kế, nhà lập trình...Đến người quản trị dự án đều có cái nhìn chính xác về những lỗi mà trong phần mềm gặp phải.
    Quá trình test giúp cho PM giảm thiểu những lỗi sơ đẳng nhất đến những lỗi lớn hơn và rắc rồi hơn. Điều đó giúp cho phần mềm hoàn thiện hơn.
    Công ty em đội ngũ test cũng khá lắm. Và công việc của họ rất vất vả!
    Còn em ...huhuuhu...hơi bị rảnh hơn họ nên có thời gian nên đây post bài cùng các anh các chị!
     
    #13
  14. vit_cth_vit

    vit_cth_vit Thành viên sơ cấp

    Bài viết:
    8
    Đã được thích:
    0
    Nơi ở:
    hanoi
    Bác ngoài hành tinh ơi, bác xem lại đi... Springthuy18 ko phải là nhà cc ERP, cũng ko thuộc lĩnh vực sử dụng ERP... :(
    Đề tài này em thấy cũng khá hay đấy chứ các bác, vỡ vạc ra nhiều điều. Thank kiu các bác nhiều! :)
     
    #14
  15. PAT

    PAT PAT

    Bài viết:
    287
    Đã được thích:
    3
    Nơi ở:
    Ho chi Minh city
    Thú thực với bạn là khi đọc những trao đổi thế này thì chẳng thấy vui tý nào. Tại sao chúng ta không thể dùng những lời khác đi thì hay biết mấy

    Theo hiểu biết của PAT thì test sẽ gồm hai giai đoạn :
    1. Alpha Test : Là thực thi test sản phẩm tại nhà sản xuất ở đây là các công ty phát triển phần mềm
    2. Beta test : Là nhà sản xuất mang sản phẩm của mình đi dùng thực tế tại khách hàng để ghi nhận các phản hồi của khách hàng giúp sản phẩm hoàn thiện và gần gũi với End-User hơn
    3. Test trong quá trình Service sau bán hàng : Là test những phần customize trong quá trình triển khai đến khách hàng.

    Với Alpha test thì giống như bạn hiểu . Tất cả các quy trình test trong đơn vị phần mềm phải tuân thủ nghiêm ngặt từ khâu phân tích, thiết kế, Interface , report mà phạm vi bài viết này PAT không thể đưa ra hết được.
    Khối lượng test rất lớn . Có thể hình dung gồm Test lỗi cú pháp khi lập trình, test về dữ liệu đúng sai cho từng nghiệp vụ (Unitest) , test về cỡ chữ, mầu, font.... Sau đó kết nối các nghiệp vụ trong một Module (SI test) - Kết nối các nghiệp vụ giữa các Module - test tiện ích, test tốc độ với dữ liệu lớn ........Bạn có thể hình dung chỉ riêng Module quản lý sản xuất bên công ty của PAT có một đội test 8 người - Test ròng rã trong gần hai năm đấy.

    Với beta test : Đưa sản phẩm cho Khách hàng sử dụng (thường là free) - Được người đồng ý test hộ mình là may quá rồi còn gì. Ở Việt Nam mình thì khó thuyết phục một công ty dùng và test hộ lắm. Nên phương án ở đây là cài vào các site của các chuyên gia về ERP có hiểu biết sâu sắc nhiều sản phẩm khác nhau để họ đánh giá. Nhờ beta test các nghiệp vụ được bổ sung hiệu chỉnh và đặc biệt là tính tiện ích khi sử dụng. PAT lấy một ví dụ để bạn hình dung nhé : Trước đây sản phẩm của PAT làm chuyện bán hàng - in hóa đơn là OK hết - Nhưng khi cài thực tế KH yêu cầu thế này : Tôi có khoảng 15 trình dược viên mang thuốc đi bán hàng ngày. Mỗi buổi sáng với hai máy phải in được hóa đơn tạm trong khoảng 30'. Mỗi hóa đơn có khoảng 50-70 mặt hàng chẳng hạn. Thế là lại phải ngồi bàn với KH để tiết kiệm từng lần gõ bàn phím cho một form nhập liệu.

    Với test trong quá trình customize thì cũng làm gióng như alpha test nhưng với phạm vi công việc nhỏ hơn

    Hy vọng chia xẻ một phần nào với bạn về chuyện test trong erp trong một bài ngắn
     
    #15
  16. H5N1

    H5N1 Thành viên sơ cấp

    Bài viết:
    14
    Đã được thích:
    0
    Nơi ở:
    Ninh Bình
    Nói chung nói về Test thì có nhiều chuyện để nói lắm. Nhưng quan trọng là phải nắm được yêu cầu của khách hàng để tạo dữ liệu và Test case cho phù hợp.
     
    #16
  17. hai2hai

    hai2hai VNUNI Makes a difference

    Bài viết:
    2,012
    Đã được thích:
    128
    Nơi ở:
    Hà nội
    Chịu bác.

    Hãy nhìn vấn đề trên nhiều góc độ (views) khác nhau đi các bác ơi. Test đâu chỉ có mỗi thế mà bác viết có mỗi 1 câu.
     
    #17
  18. H5N1

    H5N1 Thành viên sơ cấp

    Bài viết:
    14
    Đã được thích:
    0
    Nơi ở:
    Ninh Bình
    Thông cảm đi ít thời gian quá đang bận mà

    Thì nói theo quan điểm của dân phầm mềm thì chỉ nguyên UnitTest đã được chia ra là White Box và Black Box
    White box là Test dạng debug
    Black box là test dang chạy chương trình và coi dữ liệu đầu ra đầu vào có đúng không.

    Rồi interface(Hay còn gọi Test Gui) để coi dữ liệu xuất ra có đúng không? Vi trí Button, label, có đúng không, .....
     
    Last edited: 22 Tháng ba 2006
    #18

Chia sẻ trang này