Làm thế nào để các công ty lớn của các nhà phát triển phần mềm kiểm tra các lỗi trong chương trình của họ?

Tôi đã tự hỏi làm thế nào các công ty lớn của các nhà phát triển phần mềm kiểm tra các lỗi trong chương trình của họ.

Họ chỉ kiểm tra nó trên một số máy tính?

Dưới đây là một số kỹ thuật mà Google sử dụng.

1. Thuê các nhà phát triển tốt, những người có khả năng sản xuất mã đáng tin cậy.
2. Đơn vị kiểm tra nặng.
3. Sử dụng xem lại mã .
4. Thiết lập một bản dựng liên tục để nắm bắt các vấn đề tích hợp.
5. Có bộ phận QA chuyên dụng. Có nghĩa là cả hai người đang thử nghiệm và các chương trình tự động (ví dụ: sử dụng Selenium) mô phỏng người dùng cuối.
6. Có giám sát trong sản xuất để bắt bằng chứng về những điều sai trái.

Tôi đã xếp hạng những thứ này trong những gì tôi nghi ngờ là thứ tự hiệu quả giảm dần trong việc bắt lỗi.

Các công ty lớn hơn thường có toàn bộ bộ phận Q / A chịu trách nhiệm kiểm tra mã và đảm bảo nó hoạt động theo đúng nghĩa của nó. Nó thường đúng như bạn mô tả-- một nhóm người đang thử nghiệm rất nhiều máy móc. Đôi khi các bài kiểm tra được tự động, đôi khi chúng không. Xem Đảm bảo chất lượng - Wikipedia

Nhiều lần, chính các nhà phát triển sẽ tìm thấy lỗi trong quá trình phát triển. Ngoài ra, khách hàng thường là người đầu tiên tìm thấy một lỗi.

Các công ty nhỏ hơn, như một công ty tôi hiện đang làm việc, sử dụng thực hành Kiểm tra Agile

Tôi sẽ nói về sự trưởng thành của một công ty chứ không phải quy mô :) Có những công ty lớn có thực tiễn phát triển kém và các công ty nhỏ đang trên đà phát triển.

Nói chung, một nhóm phát triển trưởng thành sẽ tham gia vào các hoạt động sau đến 1; giảm thiểu giới thiệu các lỗi mới cho hệ thống và 2; tìm lỗi trong hệ thống hiện có.

Đơn vị kiểm tra: Đây là những 'tài xế mini' cho các phương pháp cá nhân để đảm bảo rằng một phương pháp làm những gì nó nói nó. Đây luôn là những bài kiểm tra tự động.

Kiểm thử tích hợp: Các thử nghiệm này nhằm kiểm tra xem một đơn vị chức năng lớn hơn có hoạt động trong hệ thống không. Điều này có thể liên quan đến thử nghiệm tích hợp cơ sở dữ liệu hoặc tích hợp với các thư viện bên thứ ba. Đây là những bài kiểm tra tự động là tốt.

Kiểm tra chấp nhận: Kiểm tra chấp nhận được viết để kiểm tra các yêu cầu của người dùng. Chúng thường chỉ kiểm tra "con đường hạnh phúc". Trong nhóm của tôi, các thử nghiệm này được thiết kế để cho thấy rằng nếu người dùng sử dụng chức năng như được thiết kế để sử dụng, họ sẽ không gặp rắc rối. Có thể là thủ công hoặc tự động.

Kiểm tra chức năng: Các kiểm tra này tương tự như kiểm tra chấp nhận, nhưng chúng cũng kiểm tra 'đường dẫn không vui'. Những thử nghiệm này có nghĩa là để kiểm tra các kịch bản không quá rõ ràng. Có thể là thủ công hoặc tự động.

Kiểm tra hồi quy: Chúng tôi sử dụng thuật ngữ này để thực hiện 'kiểm tra toàn bộ' hệ thống trước khi phát hành cho khách hàng. Hướng dẫn sử dụng hoặc tự động.

Kiểm tra Gorilla: (Chỉ bằng tay). Đây là loại thử nghiệm khi con người rất thông minh cố tình phá vỡ ứng dụng.

Kiểm tra hiệu suất Nhằm đảm bảo rằng hiệu suất có thể chấp nhận được và không bị suy giảm theo thời gian. Thường tự động.

Kiểm tra độ ổn định: Các thử nghiệm này được thiết kế để đảm bảo hệ thống vẫn ổn định theo thời gian. Tự động hóa.

Tích hợp liên tục: Đây là một hệ thống tự động kiểm tra mã của bạn, biên dịch mã và chạy các kiểm tra tự động của bạn. Các bài kiểm tra nhanh hơn (đơn vị, tích hợp) của bạn sẽ chạy mỗi khi một nhà phát triển cam kết mã. Một số khác chạy hàng đêm (chấp nhận, chức năng) hoặc hàng tuần (hiệu suất, ổn định).

Báo cáo bảo hiểm mã: Hiển thị cho bạn bao nhiêu mã của bạn được kiểm tra. Mã không có phạm vi kiểm tra có nhiều khả năng bị phá vỡ.

Các công cụ khác nhau để phân tích mã: Chúng thường hiển thị nơi mã cần được xác nhận lại để làm cho nó ít bị lỗi hơn.

Lập trình cặp: Hai nhà phát triển làm việc cùng nhau để cung cấp chức năng. "Một cặp gắn kết tốt hơn tổng số các bộ phận của nó."

Điều quan trọng nhất để lấy đi là: tự động hóa và tích hợp liên tục .

Nó phụ thuộc vào công ty và các sản phẩm mà nó phát triển.

Đầu tiên, nhiều công ty thực thi các thực hành mã hóa như đánh giá mã và bắt buộc (công cụ phát hiện lỗi tự động) để giảm lượng lỗi xảy ra trong kho lưu trữ. Nhiều công ty cũng đã áp dụng thử nghiệm đơn vị. Đây là trường hợp tôi làm việc (Google). Khi mã được kiểm tra, các kiểm tra được chạy với mọi thứ, để đảm bảo không có lỗi mới nào được đưa ra.

Thứ hai, nhiều công ty có các bộ phận QA chịu trách nhiệm xác nhận hành vi. Điều này đặc biệt phổ biến trong Tài chính (trong đó các lỗi có thể tốn kém và quy tắc xác thực rất phức tạp), nhưng cũng tồn tại ở các công ty bán sản phẩm cho người dùng nơi thu hồi có thể đắt (ví dụ: Intel, Microsoft, v.v.).

Thứ ba, bất cứ khi nào các công ty có thể làm Dogfooding (có người dùng riêng sử dụng sản phẩm trong nội bộ) và sau đó phát hành betas giới hạn. Nhiều lỗi được bắt gặp ở giai đoạn này. Ví dụ: những người làm việc tại Microsoft sử dụng các phiên bản nội bộ mới hơn của Office và Windows và DevStudio so với những gì bạn có bên ngoài. Sau đó, các nhóm người dùng hoặc công ty hợp đồng hạn chế sẽ lấy mẫu này. Tương tự, tại Google, chúng tôi sử dụng các phiên bản nội bộ của GMail và Docs trước khi phát hành. Các công ty trò chơi tổ chức các betas mở để kiểm tra sản phẩm của họ và tải trên các máy chủ, v.v.

Tất nhiên câu trả lời là "Nó dpends", nhưng tôi sẽ đưa ra một mẫu từ dự án lớn nhất của tôi cho đến nay, lúc đó có khoảng 50 nhà phát triển tham gia.

Cài đặt cơ bản: Phần mềm phụ trợ để xử lý lượng lớn dữ liệu với BizTalk.

Các tuyến phòng thủ đầu tiên là các bài kiểm tra đơn vị. Trong trường hợp của chúng tôi, những thứ này được thực thi hàng ngày cho mọi thứ được kiểm tra trong kiểm soát nguồn và thường một số trong số chúng được nhà phát triển thực hiện thủ công trước khi đăng ký. Các thử nghiệm đơn vị chủ yếu được viết bởi các nhà phát triển nhưng đôi khi được sửa đổi với các thử nghiệm bổ sung của những người thử nghiệm.

Bước tiếp theo là bản dựng PC ảo hàng tuần, trong đó những người thử nghiệm đã chạy một loạt các thử nghiệm đầu cuối chủ yếu tự động trên luồng dữ liệu dựa trên các tài liệu đặc tả cho từng thành phần.

Sau đó, cùng một PC ảo đã được làm giàu với một số dữ liệu kinh doanh khá gần với thực tế và được thử nghiệm lại với một số trường hợp sử dụng cụ thể.

Sau đó, PC ảo được kết hợp với các thành phần hệ thống khác (cũng chủ yếu là ảo) từ các bộ phận khác sang chu trình kiểm tra tích hợp dựa trên thử nghiệm từ đầu đến cuối từ người dùng nhập dữ liệu đến hết luồng dữ liệu.

Trên một bản nhạc khác, các gói cài đặt đã được nhà cung cấp hệ thống kiểm tra để xem liệu chúng có được cài đặt chính xác trên môi trường giống như sản xuất hay không và liệu chúng có thể được khôi phục nếu có lỗi không.

Sau khi cài đặt trên môi trường giống như sản xuất, chúng tôi đã chạy thử nghiệm tải và căng thẳng ở đó để kiểm tra độ ổn định tổng thể (không phải là điều gì đó nhẹ nhàng khi bạn chạy trên 10 máy chủ BizTalk, 8 Máy chủ SQL và một loạt các phần cứng chuyên dụng khác như máy gia tốc XML và Lưu trữ dành riêng - tất cả được nhóm lại).

Khi chúng tôi hài lòng với tất cả các thử nghiệm, mã được đưa vào sản xuất. Bạn nhận được độ trễ khá lớn để sửa lỗi trong mã (như 4 - 6 tuần cho toàn bộ chu kỳ kiểm tra) và thật tốn kém khi thực hiện tất cả các thử nghiệm này, nhưng độ ổn định chung là khá tốt. Trong thực tế tốt nhất tôi đã thấy cho đến nay. Một lần nữa, điều đó khá quan trọng trên một hệ thống xử lý trị giá hàng triệu đô la mỗi ngày. Yêu cầu của bạn có thể khác nhau, nhưng đó là cách chúng tôi đã thực hiện và nó đã hoạt động.

Câu hỏi ban đầu có vẻ khái niệm chung chung hơn so với hầu hết các câu trả lời rất chi tiết được cung cấp.

Hãy để những người khác nhìn nó từ cấp độ cao hơn (ít chi tiết hơn). Phần mềm được phát triển để đáp ứng nhu cầu cụ thể từ một người nào đó (người, công ty, bất cứ điều gì).

Những nhu cầu đó cần được ánh xạ vào các câu chuyện / yêu cầu riêng lẻ sẽ được thực hiện gần đây (trong giai đoạn xây dựng) được thực hiện trong mã nguồn.

Có các câu chuyện / yêu cầu được xác định rõ là điều cần thiết cho nhóm Đảm bảo chất lượng (QA) (người kiểm thử phần mềm thực tế) để xác thực mã cuối cùng, khi được thực thi, theo yêu cầu của những câu chuyện và yêu cầu đó. Vì vậy, với mục đích đó, nhóm QA tạo ra "bản thử nghiệm" để thực hiện xác nhận đó.

Mã này, một khi được phát hành cho nhóm QA, sau đó sẽ được kiểm tra và các lỗi sẽ được xác định. Lỗi của các loại khác nhau và mức độ nghiêm trọng. Những lỗi đó được theo dõi và các nhà phát triển được chỉ định để cuối cùng sửa chúng.

Việc sử dụng các máy ảo, ngày nay, cho phép một người thử nghiệm chạy các môi trường khác nhau trong cùng một phần cứng thực. Nhưng đôi khi bạn cần một số máy tính dành riêng cho giai đoạn QA.

Tôi hy vọng điều đó sẽ giúp bạn hiểu (khoảng) quá trình tổng thể.

Chà, tôi ghét phải hoài nghi, nhưng với số lượng lỗi mở trong một hệ điều hành 'thiết bị' nhất định, có vẻ như công ty càng lớn và giàu có, họ càng có nhiều lỗi để tạo và cung cấp cho người dùng cuối. Nếu phần mềm hoạt động tốt và trông rất tuyệt thì họ vẫn phát hành nó. Nếu các nhà quản lý nghĩ rằng nó đã sẵn sàng, thì nó đã sẵn sàng. Đó là khi những con bọ thực sự khó chịu bắt đầu ra khỏi đồ gỗ và người dùng cuối trở thành lợn guinea. Mười năm sau, hầu hết các lỗi sẽ được xử lý (và một vài bổ sung cho biện pháp tốt) và công ty sẽ sẵn sàng chuyển sang ý tưởng lớn tiếp theo.