Làm thế nào để xác nhận hợp lệ mã của bạn?

Tôi có khoảng 4000 dòng mã cho một ứng dụng web bằng JavaScript / PHP / CSS / HTML. Làm thế nào tôi có thể kiểm tra nó đúng cách?

Tôi chỉ hỗ trợ phiên bản IE và Safari mới nhất. Tôi đã tìm ra tất cả các lỗi. Có cách nào tốt để kiểm tra nó để tôi có thể gọi mã mạnh mẽ không?

Tôi đã cân nhắc sử dụng perl Mechanize để tự động điền vào các biểu mẫu hoặc làm điều gì đó tương tự.

Tôi cũng có một lớp kiểm tra PHP để kiểm tra hoạt động bên trong của các lớp PHP của tôi. Tuy nhiên, có một số loại hướng dẫn tiêu chuẩn hoặc phù hợp được đáp ứng? Có cách nào để nói mã này vượt qua các tiêu chuẩn foo của IEEE xxx về tính cướp mã, v.v. không?

Tôi đã xác thực HTML của mình bằng trình xác thực W3 và tôi đã xác thực JavaScript của mình bằng jslint.com.

Dưới đây là danh sách các mục dilligence:

1. HTML / CSS vượt qua xác thực W3
2. JavaScript vượt qua jslint
3. PHP vượt qua lớp kiểm tra PHP nội bộ

Kiểm tra người dùng

1. Tạo một tập hợp các hành động người dùng và triển khai bằng cách sử dụng cơ chế perl hoặc tương tự.

Có các tiêu chuẩn hoặc thủ tục để phát hành mã lên web?

Xác nhận phần mềm là một lĩnh vực rất lớn, không có câu trả lời chắc chắn cho câu hỏi của bạn. Hơn nữa, kỹ sư xác nhận phần mềm thường là một vị trí đặc biệt đòi hỏi nhiều kiến ​​thức hơn phát triển và nhiều kỹ năng (ví dụ như "đặc tả gỡ lỗi" thực sự rất không tầm thường) hiện đang phổ biến trong cộng đồng nhà phát triển.

Thứ hai, xác nhận phần mềm (và xác thực mã là một phần thiết yếu của nó) không phải là thử nghiệm. Có một câu nói nổi tiếng của Dijkstra:

Thử nghiệm cho thấy sự hiện diện, không phải là không có lỗi

Vì vậy, đây là điểm khác biệt chính so với xác thực phần mềm (nghĩa là phần mềm của bạn hợp lệ, không có lỗi) và kiểm tra (đối với các lỗi hoặc lỗi tiềm ẩn).

Nếu chúng tôi giảm câu hỏi của bạn xuống "làm thế nào để xác nhận hợp lệ một ứng dụng web dựa trên PHP?" Tôi có thể đưa ra câu trả lời sau:

Phân tích mờ nhạt.

Có một số công cụ gọn gàng ( 1 , 2 ) để thực hiện phân tích mờ trên PHP. Đây là một phân tích tĩnh (có nghĩa là nó được thực hiện mà không cần chạy mã của bạn) để xác định các thông tin bí mật có thể bị rò rỉ (rò rỉ).

Tôi đã sử dụng một số các công cụ này ( Pixy ) trong thực tiễn của riêng tôi và phát hiện ra rằng chúng, như tất cả các công cụ khác trong phân tích tĩnh, dường như đánh giá quá cao mối nguy hiểm tiềm tàng. Tuy nhiên, họ có thể giúp bạn xác định một số vấn đề bảo mật mà bạn có thể không biết. Điều này đặc biệt quan trọng đối với các ứng dụng web xử lý một số dữ liệu nhạy cảm.

Điều này sẽ không loại trừ tất cả các lỗ hổng có thể xảy ra, như XSS, nhưng sẽ bao gồm nhiều lỗ hổng phổ biến, như mã PHP và SQL SQL, v.v.

Xác nhận sự phù hợp.

Bước này bạn đã thực hiện bằng cách chạy trình xác thực JSLint và CSS / HTML đối với trang web hoàn chỉnh của bạn.

Tải thử nghiệm.

Nếu tính khả dụng của ứng dụng web của bạn là một vấn đề (hoặc thậm chí là một phần của SLA của bạn) thì tôi cũng sẽ thực hiện một số thử nghiệm tải. Chúng có thể được tạo bởi một số IDE, như Visual Studio hoặc bạn cũng có thể sử dụng khung JMeter mã nguồn mở cho mục đích này.

Các tiêu chuẩn chỉ tốt như những người thực thi chúng. (đặc biệt đúng với tiêu chuẩn chất lượng ISO ...)

Nếu bạn muốn kiểm tra đầy đủ phần mềm của mình, bạn cần một thông số yêu cầu tốt có thể được sử dụng để xác minh thực tế rằng bạn đã hoàn thành / thực hiện tất cả các tác vụ / tính năng / vv khi chúng nên được thực hiện. Ngoài ra, nó cũng giúp người khác nhìn vào dự án từ góc độ kiểm tra phần mềm / đảm bảo chất lượng (từ đánh giá mã đến kiểm tra người dùng khám phá).

Một lưu ý khác mà bạn có thể muốn xem xét là thực tế là nếu không có yêu cầu rõ ràng là nhà phát triển, bạn có thể sẽ thường xuyên hơn là không coi mọi thứ là 'tính năng' thay vì 'lỗi' :)

Có các tiêu chuẩn IEEE cho thông số kỹ thuật yêu cầu (IEEE 830) và kế hoạch kiểm tra (IEEE 829). Tuy nhiên tôi nghĩ rằng họ là một chút OTT cho rất nhiều dự án.

(Tôi cũng hơi ngạc nhiên khi bạn không có cơ sở dữ liệu?)

Câu trả lời không phổ biến.

Bạn phải có người dùng đánh bại địa ngục sống ra khỏi nó. Sau khi bạn sử dụng hết danh sách các lỗi được báo cáo sau nhiều lần thử nghiệm, bạn chỉ có thể gọi mã của mình mạnh mẽ.

Bạn thử nghiệm nó một mình sẽ ít được sử dụng vì bạn đang ở trong cây mã hóa và không thể nhìn thấy rừng.

Bạn không biết các nhà phát triển là những người thử nghiệm tồi tệ nhất bao giờ? Tôi là một nhà phát triển và tôi biết điều này chỉ sau nhiều năm rơi vào mặt tôi sau khi tuyên bố một cách tự hào, "công việc này hoàn hảo trên máy tính xách tay của tôi".