标签: testing

根据Strategy Analytic市场报告研究指出， USB Type-C®连接接口 已经在消费领域迅速普及，并在汽车连接领域取得重大的进展。因应市场趋势，百佳泰针对车内USB-C® 高速传输接口全方位打造测试服务， 针对装置的充电 、 联机 、 信号完整性 等等，进行严格控管。 随着科技的发展，汽车的车机功能越来越多，系统也越来越复杂，电子产品通过高速传输接口连接，不仅能帮装置充电还能传输数据。USB的高数据传输率也让新一代信息娱乐系统支持丰富多样的车载功能，只需连接车机，即可导航，拨打电话，听音乐，看电影，App应用共享，还能控制语音助手来调节车机。不论充电或是传输数据，本意是让驾驶更方便安全的操作，但当系统操作不够顺畅，不论是导航或是打电话，都有可能造成驾车安全上的潜在风险。 车载信息娱乐 联机即可得？ 潜在风险成您驾车大危机！ · 车载界面快充能力为车内不断增加的应用设备充电，如手机、平板、笔记本电脑，然而，充电过程中的发热现象，造成的意外却时有所闻，不得不谨慎！ · 车机透过高速传输接口读取手机信息，数据读取时好时坏，兼容问题让驾驶上路易导致意外事故。 · 高速传输接口失灵，装置App软件应用无法共享，车载信息娱乐系统变呆瓜。 虽说高功率车载USB-C ® 接口能让车主在充电的同时，实现数据传输，一专多能，将宝贵的车内空间最大化。但是，车用传输接口的安全问题，兼容性问题，以及联机问题等将导致操作体验参差不齐，严重则引发安全事故。 车用传输接口测试服务包含以下： USB Test ：已可支持最新的规范USB4 ™ 可达40G的测试 · Physical Layer · Link Layer · Protocol Layer · Power Tests · Interoperability Test · Battery Charging 1.2 Test · Embedded Host Only Tests · Car Play SI USB Type-C ® Test · Power Delivery 2.0/3.0 Compliance Plan · Functional Tests · Interoperability Test · Source Inrush Current Test · Source Power Requirements Test · Cable & Connector Test HDMI Test · Premium HDMI Cable Certification Program Services（By Sony ATC ） · HDMI Compliance Program（By Sony ATC） · HDMI Pre-Compliance Testing · HDMI Compatibility Testing

Personally, I think that for most products we should automate as much testing as possible. The old adage still holds: If you have to do something once, do it. If you have to do it twice, automate it. But some things are tough to delegate to a machine. Watching and interacting with a UI is an example.   But some people are doing very clever things. Some get LabVIEW with its vision module. They aim a camera at a control panel or even a screen and use LabVIEW to dissect the visual field, returning elements as text items. It’s possible to sometimes close the testing loop this way.   Bruno didn’t mention holding tests to objective standards. We have no idea how to figure how many tests cases are needed, but we can compute the minimum. Cyclomatic complexity gives us a hard number: If you don’t have that number of tests, then, for sure, the system is not being completely tested.   Testing is a hugely important activity. But it suffers from three flaws: - Outside of agile shops testing takes place at the end of the project. The project is late, of course, so what gets cut? - It doesn’t work. Plenty of studies have shown that, absent code coverage metrics, the average test regime only exercises half the code. Exception handlers and special cases are notoriously difficult to test. Deeply-nested Ifs lead to mind-boggling numbers of testing permutations. - Test is the wrong way to find bugs.   To elaborate on the last point, we have to first “man up” and admit that we are flawed firmware developers who will produce code with all sorts of defects. That’s just the nature of this activity. Given that we know we will inject bugs into the code (and maybe a lot of them), and that testing is flawed, wise developers will employ a wide range of strategies to beat back the bugs.   I like to think of generating high-quality software in terms of a series of filters. No one filter will have 100% efficacy; each will screen different percentages of problems. Used together the net effect is to remove essentially all of the bad gunk while letting only the purest and most pristine code out the door.   This is not a new idea. Capers Jones lists over 100 filtering steps (and analyzes the effectiveness of each) in The Economics of Software Quality. He makes it clear that no team needs to use all of these, of course; some, for instance, are for dealing with data bases; others are for web page design.   The compiler is a filter we all use. It won’t generate an object file when there are bugs that manifest as syntax errors. Unfortunately, it will happily pass a binary to the linker even if there are hundreds of warning messages. It’s up to us to be disciplined enough to have a near-zero tolerance for warnings.   (I remember using the RALPH Fortran compiler in 1971 on a Univac 1108. If there were more than 50 errors or warnings in your card deck it would abort, print a picture of Alfred E. Neumann with the caption “This man never worries, but from the look of your program, you should.”)   Do you use Lint? You should. Though annoying to set up, Lint will catch big classes of errors. It’s another filter stage.   Static Analysis is becoming more important. The tools cost too much, but they’re cheaper than engineering labor. Another filter.   Then there’s the most effective filter ever devised for eliminating bugs. Study after study shows it to be the cheapest and most powerful way to generate decent code: reviews. Decent code reviews should eliminate 70% of the defects. The best teams eliminate over 90% with reviews.   Test, of course, is yet another filter. Or rather, another series of filters. Unit test, integration test, black-box test, regression test, each serves to clean up the code.   But these filters won’t work well unless you monitor their effectiveness. What percentage of the bugs sneak through each stage? If test is finding 90% then there’s something seriously wrong with the earlier filters, and corrective action must be taken.   Engineering is, after all, about the numbers.   What filters do you use?

Bruno Soko’s recent article “ Software development: Automated vs manual testing ” is worth a read. In it he lays out the tradeoffs between the two approaches.   Personally, I think that for most products we should automate as much testing as possible. The old adage still holds: If you have to do something once, do it. If you have to do it twice, automate it. But some things are tough to delegate to a machine. Watching and interacting with a UI is an example.   But some people are doing very clever things. Some get LabVIEW with its vision module. They aim a camera at a control panel or even a screen and use LabVIEW to dissect the visual field, returning elements as text items. It’s possible to sometimes close the testing loop this way.   Bruno didn’t mention holding tests to objective standards. We have no idea how to figure how many tests cases are needed, but we can compute the minimum. Cyclomatic complexity gives us a hard number: If you don’t have that number of tests, then, for sure, the system is not being completely tested.   Testing is a hugely important activity. But it suffers from three flaws: - Outside of agile shops testing takes place at the end of the project. The project is late, of course, so what gets cut? - It doesn’t work. Plenty of studies have shown that, absent code coverage metrics, the average test regime only exercises half the code. Exception handlers and special cases are notoriously difficult to test. Deeply-nested Ifs lead to mind-boggling numbers of testing permutations. - Test is the wrong way to find bugs. To elaborate on the last point, we have to first “man up” and admit that we are flawed firmware developers who will produce code with all sorts of defects. That’s just the nature of this activity. Given that we know we will inject bugs into the code (and maybe a lot of them), and that testing is flawed, wise developers will employ a wide range of strategies to beat back the bugs.   I like to think of generating high-quality software in terms of a series of filters. No one filter will have 100% efficacy; each will screen different percentages of problems. Used together the net effect is to remove essentially all of the bad gunk while letting only the purest and most pristine code out the door.   This is not a new idea. Capers Jones lists over 100 filtering steps (and analyzes the effectiveness of each) in The Economics of Software Quality. He makes it clear that no team needs to use all of these, of course; some, for instance, are for dealing with data bases; others are for web page design.   The compiler is a filter we all use. It won’t generate an object file when there are bugs that manifest as syntax errors. Unfortunately, it will happily pass a binary to the linker even if there are hundreds of warning messages. It’s up to us to be disciplined enough to have a near-zero tolerance for warnings.   (I remember using the RALPH Fortran compiler in 1971 on a Univac 1108. If there were more than 50 errors or warnings in your card deck it would abort, print a picture of Alfred E. Neumann with the caption “This man never worries, but from the look of your program, you should.”)   Do you use Lint? You should. Though annoying to set up, Lint will catch big classes of errors. It’s another filter stage.   Static Analysis is becoming more important. The tools cost too much, but they’re cheaper than engineering labor. Another filter.   Then there’s the most effective filter ever devised for eliminating bugs. Study after study shows it to be the cheapest and most powerful way to generate decent code: reviews. Decent code reviews should eliminate 70% of the defects. The best teams eliminate over 90% with reviews.   Test, of course, is yet another filter. Or rather, another series of filters. Unit test, integration test, black-box test, regression test, each serves to clean up the code.   But these filters won’t work well unless you monitor their effectiveness. What percentage of the bugs sneak through each stage? If test is finding 90% then there’s something seriously wrong with the earlier filters, and corrective action must be taken.   Engineering is, after all, about the numbers.   What filters do you use?

One of the most powerful tools to enhance the quality of firmware is the code inspection. They also speed development. A lot of data supports the latter statement; for example, in A Survey of Software Inspection Technologies by Oliver Laitenberger, the author shows that Jet Propulsion Laboratory’s inspections are ten to 34 times cheaper than testing. A wealth of other studies confirm this.   Worse, test doesn’t work. V. Basili and R. Selby, in Comparing the Effectiveness of Software Testing Strategies , showed that test is unlikely to reveal more than half of the defects in a body of code. Glass and others have confirmed these results. (There are exceptions; disciplined code coverage will improve the numbers).   In my travels this Autumn I’ve had a chance to visit several companies that do disciplined inspections, which is laudable, and unfortunately uncommon. Interestingly, the companies I’ve recently visited do the inspection before final commit to the version control system. That is, the developers write and test the code, fix the bugs they find, and then inspect it. That’s a mistake. Inspections should take place after cleaning up errors found by automated tools, like the compiler, lint, and static analysis. No test should be done pre-inspection. It’s completely understandable that developers wish to test first. Who wants their mistakes pointed out in a meeting of their colleagues? Sneak in a couple of hours of test to get rid of the smack-your-forehead-obvious mistakes. But inspections are cheaper – much cheaper – than test, so test first is akin to burning stacks of hundred-dollar bills. It’s simply bad business. A central observation of the quality movement is that you can’t test quality into a product. That’s also true in software; a focus on fixing bugs will not lead to quality code. Quality must be designed in from the beginning. When inspections are done pre-test, the code automatically improves. If I’m writing code that no one will look at it’s quite different from that which will go through an inspection. And that’s part of the goal of the process: encourage the developers to write correct code from the outset. Have them work harder during the coding process, rather than devoting eons of time to fixing all of the bugs – or, at least, all of the ones they can find. In The Economics of Software Quality , By Capers Jones and Olivier Bonsignour, the authors report that out of 121 known ways to improve software quality, the fifth most effective is pretest inspections. To repeat: a focus on fixing bugs will not lead to quality code. We need to break the cycle of writing a lot of code fast and then getting into the tar pit of endless test. Think first. Code carefully. Examine the results. Make it as perfect as possible. Feed it through the tools and fix any errors detected. Inspect it and fix those defects. Finally, test.

Toptest International Technology Limited is based in Hong Kong, mainly provides testing services for  integrated circuit (IC), electronic components and products .We have many experienced engineers in IC testing area and maintain a good relationship of cooperation with many universities.Now We have tested thousand  kinds of chips,including DC/DC voltage conversion, ADC and DAC/module of integration, digital-to-analog amp, Flash Memory, SRAM, DRAM, MCU, FPGA, DSP, CPU, etc. based on the integrated circuit testing field, offering most high-quality services for customers from home and abroad. Whenever you need,whatever problems you have  in IC testing, we will do the utmost effort to offer high-quality services to you, just a telephone, an email,  we can start to cooperate.