|
Xin chào
Guest
| Đăng ký
| Đăng nhập
|
|
|
| Trang chủ | Những mạch mới | Mạch chưa trả lời | Người dùng trực tuyến | Thành viên | Giúp đỡ |
Diễn đàn SEGVN
Software Engineering - Information System Management
Software Engineering
Mạch: Nhóm kiểm thử độc lập
|
| Không có thành viên nào đang xem mạch |
|
Trạng thái mạch: Bình thường Tổng số bài viết trong mạch này: 4 |
|
| Tác giả |
|
JohnVu
Prof. Tham gia: 29-12-2008 Tổng số bài đã viết: 849 Trạng thái: Offline |
Phát triển phần mềm bao giờ cũng có lỗi và kiểm thử được dùng để tìm và sửa lỗi. Cách tiếp cận này KHÔNG hiệu quả trong cải tiến chất lượng phần mềm nhưng nhiều trường vẫn dạy cách tiếp cận này. Sinh viên được dạy rằng phát triển phần mềm tuân theo bốn pha: Yêu cầu, Thiết kế, Viết mã và Kiểm thử. Phần mềm không nên được thiết kế chừng nào yêu cầu còn chưa được phân tích đầy đủ. Phần mềm không nên được viết mã chừng nào thiết kế còn chưa làm xong. Phần mềm không thể được kiểm thử chừng nào viết mã còn chưa được đầy đủ. Lỗi phần mềm được loại bỏ trong kiểm thử trước khi đưa ra cho người dùng. Trong thực hành, phần lớn lỗi thường được tạo ra trong pha yêu cầu hay thiết kế, nhưng kiểm thử không thể phát hiện được chúng chừng nào viết mã còn chưa được thực hiện do đó lỗi bao giờ cũng được tìm thấy muộn trong dự án. Trong thời gian này, phần lớn các dự án đã chạy hết thời gian cho nên người phát triển vội vàng đưa ra phần mềm và người dùng chấm dứt với sản phẩm có lỗi. Giải pháp cho vấn đề này là ở chỗ người kiểm thử phải lập kế hoạch kiểm thử trong pha yêu cầu và các trường hợp kiểm thử thiết kế đồng thời lúc người phát triển thiết kế phần mềm, và viết mọi trường hợp kiểm thử đồng thời lúc người phát triển thực hiện viết mã. Vậy, phát triển kiểm thử xảy song hành với phát triển phần mềm. Điều quan trọng là có nhóm kiểm thử độc lập để làm việc về phát triển kiểm thử đồng thời với phát triển phần mềm. Điều này có thể giúp phát hiện sớm lỗi và cải tiến chất lượng phần mềm. Không may là nhiều công ti dùng những người phát triển để làm kiểm thử cho phần mềm riêng của họ để tiết kiệm chi phí thuê người kiểm thử phụ. Thực hành này có thể làm phát sinh việc người phát triển tạo ra kiểm thử mà chỉ kiểm thử những phần của phần mềm đã làm việc, dựa trên thiên kiến riêng của họ. Chung cuộc, phần mềm sẽ qua kiểm thử nhưng vẫn chứa lỗi. Khi người dùng tìm thấy lỗi trong phần mềm, phần lớn người phát triển khăng khăng rằng các kiểm thử của họ không để lộ ra lỗi nào. Điều này tạo ra thái độ đối đầu giữa người dùng và người phát triển. Có người kiểm thử độc lập phân tích các yêu cầu một cách tách rời với người phát triển thì có thể nhận diện một số lỗi yêu cầu hay thiếu thông tin. Về căn bản, phần lớn người dùng chỉ cho người phát triển các yêu cầu mức cao và phần lớn những người phát triển muốn dẫn ra yêu cầu riêng của họ (thường không được làm tài liệu) dựa trên hiểu biết riêng của họ về nhu cầu của người dùng. Có người kiểm thử độc lập kiểm điểm lại các yêu cầu sẽ tránh được vấn đề này bởi vì người kiểm thử phải hiểu yêu cầu một cách chi tiết. Nếu họ không biết các yêu cầu, họ không thể tạo ra được các kiểm thử hay ngược lại, nếu họ không thể kiểm thử được chúng, họ không biết yêu cầu. Theo kinh nghiệm của tôi, đây là lúc dự án có thể nhận diện mọi yêu cầu không nhất quán, không đầy đủ, mơ hồ và sửa chúng trước khi chuyển sang pha tiếp. Với hiểu rõ về yêu cầu, những người kiểm thử độc lập có thể thiết kế các trường hợp kiểm thử mà kiểm thử cái gì đó có thể đã không được người phát triển xét tới trong thiết kế của họ. Bằng việc có kiểm điểm kiểm thử thiết kế, người kiểm thử và người phát triển có thể so sánh các ghi chú ở mức chi tiết. Hoạt động này có thể nhận diện các lỗi thiết kế hoặc bởi người phát triển hoặc bởi người kiểm thử. Bằng việc có hành động sửa chúng trước pha thực hiện, dự án có thể khử bỏ được nhiều lỗi. Đây là lúc phần lớn các cấu phần trùng lặp nhất, các hoạt động thiết kế dư thừa có thể được nhận diện. Bằng việc có góc nhìn tách rời, tổ dự án có thể kiểm thiết kế giao diện, cách dùng đúng các thực thể và quan hệ, luồng dữ liệu và điều khiển, việc chuyển trạng, để chứng tỏ rằng thiết kế thoả mãn yêu cầu. Nếu dự án đã có yêu cầu tốt và kiểm điểm thiết kế nhận diện và sửa hầu hết các lỗi thì việc thực hiện thường là dễ dàng. Việc đưa lỗi vào trong pha viết mã là dễ sửa bởi kiểm thử đơn vị. Tôi bao giờ cũng tin rằng nguồn của hầu hết lỗi phần mềm là do thiếu kỉ luật trong cách tổ chức xây dựng phần mềm. Bằng việc áp dụng kỉ luật kĩ nghệ phần mềm như có nhóm kiểm thử độc lập, có nhiều cuộc kiểm điểm, dự án phần mềm có thể loại bỏ được hầu hết các lỗi thoe cách có trật tự. ----English version---- Independent test group Software development always has defects and testing is used to find and fix defects. This approach is NOT effective in improving the quality of software but many schools are still teaching this approach. Students are taught that software development follows four phases: Requirements, Design, Code and Test. Software should not be designed until their requirements are fully analyzed. Software should not be coded until design is done. Software cannot be tested until coding is complete. Software defects are removed during testing before released to users. In practice, most defects are often created during requirements or design phases, but testing cannot detect them until coding is done therefore defects always are found late in the project. During this time, most projects are already run out of time so developers are hurrying to release the software and users end up with defective products. The solution to this problem is that tester should plan the test during requirements phase and design test cases at the same time developer design software, and write all test cases at the same time as developer implementing code. Thus, test development happens concurrently with software development. It is important to have an independent testing group to work on test development at the same time with software development. This may help in early defect detection and improve software quality. Unfortunately, many companies use developers to do testing of their own software to save costs of hiring additional testers. This practice may result in developers create tests that only test the parts of software that work, based on their own biases. Eventually, software will pass tests but still contains defects. When users find defects in the software, most developers insist that their tests reveal no defects. This create an adversarial attitude between users and developers. To have independent testers analyze requirements separately from developers can identify some requirements defects or missing informations. Typically, most users only give high-level requirements to developers and most developers want to derived their own requirements (often-undocumented) based on their own understanding of users’ needs. To have an independent testers review requirements would avoid this problem because testers must understand the requirement in detail. If they do not know the requirements, they can not create the tests or vice versa, if they can not test them, they do not know the requirements. Based on my experiences, this is the time where project can identify any inconsistent, incomplete, ambiguous requirements and fix them before moves into the next phase. By understand the requirements well, independent testers can design test cases that test something which may not been considered by the developers in their designs. By having design test review, testers and developers can compare notes in detailed level. This activity can identify design defects either by developers or testers. By taking corrective actions to fix them before the implementation phase, the project can eliminate a lot of defects. This is the time where most duplicate components, redundant design activities can be identified. By having separate views, project team can check on interface design, proper use of entities and relationships, data and control flow, state transitions, to demonstrate that a design satisfies its requirements. If project already has good requirements and design reviews that identify and fix most defects then implementation is usually easy. Defect injection during the coding phase are easy to fix by unit tests. I always believe that the source of most software defects is the lack of discipline in the way organizations build software. By applying strong software engineering disciplines such as having independent testing group, having more reviews, software projects can remove most defects in an orderly manner. ---------------------------------------- Prof. Vu Carnegie Mellon University |
||
|
|
beheo320
Novice Viet Nam Tham gia: 27-11-2010 Tổng số bài đã viết: 2 Trạng thái: Offline |
Thưa thầy cho em hỏi: What are related manual defect detection activities? |
||
|
|
JohnVu
Prof. Tham gia: 29-12-2008 Tổng số bài đã viết: 849 Trạng thái: Offline |
Phát hiện lỗi thủ công (như đối lập với kiểm thử tự động) là quá trình kiểm thử thủ công phần mềm để tìm lỗi. Kĩ thuật đơn giản nhất là "kiểm mã" hay "giám định mã" nơi người lập trình kiểm tra lại từng dòng mã để chắc chắn rằng nó làm việc như mong đợi, điều này thực tế là hoạt động "gỡ lỗi". "Kĩ thuật hộp đen" là hoạt động thủ công được thực hiện bởi người kiểm thử để chắc chắn rằng mọi CHỨC NĂNG được chạy đúng với đặc tả yêu cầu. Trong trường hợp này, người kiểm thử hành động giống như người dùng cho chạy phần mềm dựa trên kế hoạch kiểm thử có chứa nhiều trường hợp kiểm thử (từng trường hợp có thể gọi tới một chức năng để thực hiện). "Kiểm thử hộp trắng" là hoạt động thủ công được người kiểm thử thực hiện để kiểm ở MỨC ĐƠN VỊ của phần mềm. Người kiểm thử cung cấp cái vào nào đó cho một số đường chạy qua mã và xác định cái ra đúng. Người kiểm thử cũng cho chạy phần mềm dựa trên kế hoạch kiểm thử bao gồm vài trường hợp kiểm thử (từng trường hợp kiểm thử sẽ cung cấp cái vào nào đó cho đơn vị và cái ra được mong đợi nào đó, tương ứng). Loại kiểm thử này yêu cầu tri thức riêng về cấu trúc nội bộ mã và cách chương trình được thiết kế. Kiểm thử này là rất hữu ích trong việc xác định tính đúng đắn trong việc thực hiện, luồng dữ liệu, nhánh đúng, đường thực hiện và cuối cùng tích hợp nhiều chức năng, hệ thống, hệ con để chắc chắn tất cả làm việc đúng tương ứng. Bởi vì phát hiện thủ công là công việc mệt mỏi, tốn nhiều thời gian, nhiều người dùng kiểm thử tự động để giảm chi phí kiểm thử. Kiểm thử tự động thực tế là "chương trình kiểm thử" được viết bao gồm nhiều trường hợp kiểm thử và được cho chạy trên máy tính qua đêm và trình bày kết quả ngày hôm sau. Có nhiều công cụ kiểm thử sẵn có trên thị trường có thể giúp việc kiểm thử tự động nhanh hơn, vững chãi hơn trong trường hợp bạn cần kiểm thử nhiều dữ liệu như trong kiểm thử rà lại. Manual defect detection (As oppose to automate testing) is the process of manually testing software for defects. The simplest technique is the “code check” or “code inspection” where programmer examines each line of code to make sure that it works as expected, this is actually the “debugging” activities. The “Blackbox testing” is a manual activities done by testers to make sure that all FUNCTIONS are running correctly according to the requirements specification. In this case, the tester acts like an user that runs the software based on a test plan that consists of several test cases (Each case may call for a function to execute). The “Whitebox testing” is a manual activities done by testers that check at the UNIT LEVEL of the software. Tester provides certain inputs to number of paths through the code and determine the correct outputs. Tester also runs the software based on a test plan that consists of several test cases (Each test case will provide certain inputs to the unit and expect certain outputs, accordingly) this kind of test requires specific knowledge of the code internal structure and how the program is designed. This test is very useful in determine the correctness in execution, the flow of data, the correct branch, the path of execution, and finally the integration of many functions, systems, subsystems to make sure all are working accordingly. Because manual detection is tedious works, consumes a lot of time, many people use automated tests to reduce the cost of testing. Automation test is actually a “testing program” written that consists of many test cases and run by a computer overnight and present the results the next day. There are many testing tools available in the market that can help make automated testing faster, more robust in case you need to test a lot of data such as in Regression Tests. ---------------------------------------- Prof. Vu Carnegie Mellon University |
||
|
|
beheo320
Novice Viet Nam Tham gia: 27-11-2010 Tổng số bài đã viết: 2 Trạng thái: Offline |
Cám ơn thầy Thanks |
||
|
|
|
Múi giờ hiện tại là GMT 22:56:07 05-02-2012 |
