Because the HTML5 engine of different browsers still has a huge difference in quality and correctness, we will continue to make our own contribution to the test suite being developed by the consortium to further achieve the goal of WEB platform interoperability and the same markup. We have submitted 7573 tests to it altogether, and you can view them in the IE Test Center. As browsers have improved their support for the same tags, we will end up with a consistent effect and a common commitment to HTML5.
The title of this post refers to the weekend activities that Adobe hosted at its San Francisco headquarters on June 15 and 16th. In this event, dozens of volunteers learned from the experts and members of the consortium from Adobe, Google, Mozilla, Apple, HP and Microsoft to learn how to conduct WEB standard tests, how to write CSS and SVG tests, and how to create good bugs Report and learn more about the tools used to manage test suites.
The event then entered the "Programming Marathon" test session, where everyone enjoyed a free food and drink while writing a whole day of testing procedures. The volunteers spent most of Saturday writing new test cases for CSS OM, [Transforms] (transform), [Backgrounds & Borders] (Background and border), [exclusions] (surround), SVG, and other modules. One of the best winners has also been nominated for several awards.
Testing WEB Standards
Alan Stearns of Adobe briefed the participants on the general principles of the universal test and the role of testing in driving the development of the specification. In particular, the single pass rate for setting up browsers for specified specifications is not the goal of the Consortium test suite. In order for the specification to be recommended by the consortium, the Working Group must demonstrate that the specification is optional. In practice, this means:
• Create test cases for each requirement in the specification (called a "standardized declaration") • Verify that at least two individual implementations pass each test
Note the difference between "at least two browsers must pass the entire test suite" and "at least two browsers must pass each test in the test suite." The browser tester typically describes the sentence as "testing the specification."
However, an important side effect of the testing process is to establish a common interaction benchmark that can be developed and tested for all browsers. Test suites help find bugs across all browsers and sometimes identify problems in the specification.
Writing CSS and SVG tests
There are three kinds of tests:
• Independent testing typically relies on visual validation: If a failure occurs, the content is displayed in red.
• Reference tests compare Tests against visual references that do not depend on the functionality being tested. Note that the test contains a link to a reference test that should be compared against.
The CSS object Model test relies on JavaScript test tools, which validate that the object model reflects the content specified by the static style sheet, such as the CSS Media query test.
Doug Schepers of the consortium has carefully explained the SVG test, while Adobe's Rebecca Hauck and Jacob Goldstein provide a test-writing tutorial. The CSS Workgroup co-chair, Peter Linss, delves into the CSS test framework, including test suite building systems and management tools such as Shepherd.
Create excellent Bug reports
Mozilla's Elika Etemad gives active participants advice on how to create excellent browser bug reports:
• Problems are specific and reproducible
• Identify versions and platforms
• Have looked for repetition
• Steps to include recurring problems
• Describe expected and actual results
• If possible, the problem has been simplified by removing all the HTML, JavaScript, and CSS parts that are not needed to reproduce the problem from the problem page, and the remainder is attached to the bug.
Building Test Suites
Building a test suite requires a lot of investment. One of the reasons that CSS2.1 takes a long time to reach the "recommendation" stage is that the size of the specification and the amount of basic requirements required for testing are too large. The latest version of the test suite contains 9,422 tests.
Microsoft has contributed more than 7,000 of these tests, and we are continuing to contribute more testing to other standard specifications.
In IE10, we have added support for many new standard features across CSS, HTML, SVG, and DOM. We have released some test cases for these new features at our IE Test Center. We will continue to submit more test cases, especially for those features that have not been IE10 release Preview in the near future.
How do you contribute your power
We are all proud to be part of a community that improves WEB interoperability. If you are committed to promoting WEB development, it will also help to make interoperability a new step. You can learn how to contribute to a test or view an existing test.
We will inform you in time of event.
-sylvain galineau,internet Explorer project manager;
-john jansen,internet Explorer Test Manager