Development of Windows device drivers was greatly simplified when Microsoft introduced the Windows Driver Foundation (WDF) in 2005-06. WDF gave an object-oriented look to the traditional Windows Driver Model (WDM). One of the results was that driver developers could focus on the core functionalities of their device, and could leave the Windows OS specific stuff to the new frameworks.
While the development of device drivers has been simplified, testing them is still like a complex puzzle for many people. The traditional approach is based on ad-hoc means of generating test plans and test cases that treat device drivers as a black box. As a result, critical features are missed out or don’t get enough attention. In this blog post, I will try to structure device driver testing by listing the seven basic areas that need primary attention.
Our approach is simple yet comprehensive and is based on better and systematic analysis of different activities that go on during a driver’s life cycle.
Breaking the testing approach into crisply defined areas helps in not only streamlining the testing process, but also ensures better quality assurance for the driver through better coverage. Following are some of the key benefits of using this modularized approach.
Seven benefits of using this modularized approach
- The approach covers majority of the scenarios any Windows device driver would face in the real world.
- The testable areas are directly coupled with the driver’s design and implementation.
- It can be applied to majority of the device drivers designed using any model or framework and for any Windows OS versions, starting from Windows 2000.
- Allows better categorization in device driver test plans.
- Faster and focused methods can be applied for identifying test cases.
- Better way to prioritize issues and measure their severity.
- The approach does not treat the driver as single isolated entity, but considers dependencies on other sub-systems like Pnp manager, Power manager and other drivers in its stack.
Thinking and treating device drivers in the way described above has led us to streamline and simplify the way we approach testing of device drivers at Harbinger Systems. While there are more areas of a device driver that need to be tested, from our experience, the ones listed above are the most critical. They apply in a majority of scenarios and to almost all the modern device drivers. In a subsequent post, I will try and identify more special testable areas and tools to test them.
