USB-PD-Firmware-Tests sollten zeigen, dass eine vorgeschlagene Version das erforderliche Verhalten über feste Profile, PPS, EPR, Portzuweisung und Fehlerbehebung hinweg beibehält. Der nützlichste Vergleich vergleicht die freigegebene Baseline mit dem Kandidaten-Build unter identischen Eingaben und untersucht sowohl dekodierte Protokollereignisse als auch die gelieferte Leistung. Eine geänderte Versionsnummer oder eine erfolgreiche Telefonaufladung sind kein Vergleich.
Wählen Sie für ein Ladegerät-Entwicklungsprojekt Regressionsfälle aus dem Verhalten aus, das die Firmware beeinflussen kann. Bewahren Sie die Beweise der vorherigen Version auf und identifizieren Sie, welche Anforderungen absichtlich geändert wurden. Der USB-C PD-Programmumfang und der Qualitätskontrollprozess von WECENT können eine Freigabesdiskussion bilden; die Firmware-Genehmigung hängt immer noch vom genauen Modell, Build, der Konfiguration und der ausgeführten Regressionsabdeckung ab. Unterscheiden Sie geplante Verbesserungen von unerwarteten Abweichungen, bevor der Kandidat freigegeben wird.
Was macht eine nützliche Baseline für USB-PD-Firmware-Tests aus?
Behalten Sie den Basisaufbau und seine reproduzierbaren Eingaben bei.
Eine Baseline sollte ausführbare Firmware und dauerhafte Einstellungen sowie den Trace bewahren; Ohne diese Artefakte kann es unmöglich sein, einen offensichtlichen Verhaltensunterschied zuverlässig zu reproduzieren.
Ein alter Bericht ohne den ausführbaren Build oder die ausführbare Konfiguration ist eine schwache Basislinie. Notieren Sie die Controller-Version, die Projektkonfiguration, die Hardware-Revision und alle dauerhaften Einstellungen, die ein Update überdauern. Behalten Sie die relevante Quellfähigkeitsliste und Portzuweisungsregeln sowie die Versionszeichenfolge bei. Eine Konfigurationsinkongruenz kann ansonsten wie eine Firmware-Regression aussehen.
Die Dokumentation zum Infineon CY4500-EPR-Analysator bietet ein Beispieltool für die Erfassung von Protokollnachweisen. Korrigieren Sie die Decoderversion oder dokumentieren Sie, wie sich ihre Änderungen auf den Vergleich auswirken. Ordnen Sie Ereignisse anhand ihrer Bedeutung und ihres Reizes zu, anstatt Byte-für-Byte-Gleichheit in unabhängigen Zeitstempeln zu erfordern. Eine wiederholbare Basislinie sollte es einem Ingenieur ermöglichen, zu entscheiden, ob ein beobachteter Unterschied beabsichtigt ist, eine harmlose Variabilität oder eine Änderung, die gegen eine Anforderung verstößt.
Behandeln Sie einen Spurenunterschied als einen zu untersuchenden Zweig. Geänderte Zeitstempel können normale Ausführungsschwankungen widerspiegeln; Geänderte angebotene Profile oder das Wiederherstellungsverhalten können sich auf die Anforderung auswirken. Vergleichen Sie äquivalente Ereignisse und Ausgaben, bevor Sie identische Erfassungen verlangen oder einen Unterschied als harmlos abtun.
Wie sollte die Geräteabdeckung gewählt werden?
Decken Sie unterschiedliche Protokollverhalten und Kundenanwendungsfälle ab.
Ein für einen Verhandlungspfad ausgewählter Empfänger sollte nicht stillschweigend einen anderen Pfad abdecken; Behalten Sie den Grund bei, warum jedes physische Gerät oder jede kontrollierte Testvorrichtung zur Regressionsmatrix gehört.
Frühere Fehler verdienen einen Namen als Regressionsfall, wenn ihr Auslöser reproduziert werden kann. Geben Sie die genaue Version des betroffenen Geräts oder einen berechtigten Vertreter sowie die Softwareversion und das Kabel an. Fügen Sie Fälle für neue Features und für Funktionen hinzu, die den geänderten Codepfad teilen. Ein Build, der die Verarbeitung von Änderungsanfragen vornimmt, kann sich auf mehr als das in der Änderungsanfrage genannte einzelne Profil auswirken.
Notieren Sie, ob in einem Fall ein echtes Leistungsempfangsgerät, ein Trainingsgerät mit kontrolliertem Protokoll oder eine elektronische Last verwendet wird. Jeder beantwortet eine andere Frage. Echte Geräte zeigen Interoperabilitätsverhalten; kontrollierte Reize machen Randbedingungen wiederholbar; Elektrische Lasten testen die gelieferte Leistung unter definierten Anforderungen. Die USB-IF USB-C-Ressourcenseite unterstützt die Auswahl anwendbarer Compliance-Materialien, eine interne Gerätematrix sollte jedoch nicht als USB-IF-Zertifizierung dargestellt werden.
Was sollte die Regression mit festem Profil vergleichen?
Vergleichen Sie beworbene Profile, akzeptierte Anfragen und Lieferung.
Überprüfen Sie die unteren Profile ebenso sorgfältig wie das Headline-Profil. Eine geänderte Fähigkeitsliste kann sich auf den normalen Fallback auswirken, selbst wenn die Demonstration der maximalen Leistung immer noch zu funktionieren scheint.
Beginnen Sie mit den in der Produktspezifikation geforderten Profilen. Wenn der Kandidat absichtlich eine Fähigkeit entfernt oder ändert, identifizieren Sie die genehmigte Anforderungsänderung und die betroffenen Kundenszenarien. Testen Sie den Fallback mit geringerer Leistung, der von repräsentativen Geräten mit Stromempfang verwendet wird, sowie die Hauptausgabe. Ein Erfolg mit maximaler Leistung begründet keine korrekte Auswahl bei den anderen beworbenen Profilen.
Behalten Sie Strom-, Spannungs- und Protokollbeobachtungen aus derselben Erfassung oder von synchronisierten Instrumenten bei. Wenn eine Anfrage abgelehnt wird, prüfen Sie, ob dies das erforderliche Verhalten für ihre Parameter ist. Wenn es akzeptiert wird, überprüfen Sie den Auslieferungszustand nach dem entsprechenden Übergang. Behalten Sie Ausgabegenauigkeit, Anforderungsbearbeitung und Wiederherstellung als separate Entscheidungen bei, damit ein Release-Prüfer erkennen kann, welche Anforderung durch einen unerwarteten Unterschied tatsächlich gefährdet wird.
Ein Fall mit festem Profil benötigt das tatsächlich angeforderte Objekt, nicht nur die erwartete Spannung. Wenn beide Builds durch unterschiedliche Verträge die gleiche Spannung erzeugen, kann der elektrische Schnappschuss veränderte Verhandlungen verbergen. Behalten Sie diese Unterscheidung bei, wenn das unterstützte Stromempfangsgerät von einer bestimmten Fähigkeit abhängt.
Wie können PPS-Änderungen bewertet werden?
Replay-Anforderungsgrenzen und nachhaltiger PPS-Betrieb.
Verwenden Sie wiederholbare Anforderungen für die Grenzabwicklung und echte Stromempfangsgeräte für die Interoperabilität. behalten ihre getrennten Rollen bei, sodass eine sich ändernde Telefonanforderung den kontrollierten Firmware-Vergleich nicht ungültig macht.
Die TI TPS25751-Dokumentation bietet ein Komponentenbeispiel für eine PPS-fähige Steuerung. Überprüfen Sie für das überprüfte Produkt, welche Einstellungen und Codepfade den beworbenen Bereich und das aktuelle Verhalten definieren. Vergleichen Sie eine bekannte Anforderungssequenz auf beiden Builds, anstatt sich nur auf ein Telefon zu verlassen, dessen Anforderungen sich je nach Temperatur oder Ladezustand ändern.
Behalten Sie dann einen geeigneten Fall eines realen Geräts bei, um die Interoperabilität unter seinem tatsächlichen Anforderungsmuster zu überprüfen. Klassifizieren Sie einen Unterschied als veränderte Werbung, veränderte Reaktion, veränderte gelieferte Ausgabe oder verändertes nachhaltiges Verhalten. Bewerten Sie Fälle mit begrenzter Leistung anhand der geltenden Anforderung. Gehen Sie nicht davon aus, dass jedes gültig aussehende Spannungs- und Strompaar gleichzeitig geliefert werden kann. Ein Freigabeprotokoll sollte jeden beobachteten Unterschied mit der genehmigten Konfiguration oder einem dokumentierten Mangel in Verbindung bringen.
Teilen Sie den PPS-Vergleich in beworbene Reichweite, Anfragebearbeitung und geliefertes Ergebnis auf. Eine Grenzablehnung kann korrekt sein, während eine gültige In-Range-Anfrage fehlschlägt. Wenn Sie nur den normalen Ladepfad des Telefons verwenden, werden die Grenzen, die durch den geänderten Code gesteuert werden, möglicherweise nie überschritten.
Welches EPR-Verhalten gehört zur Regression?
Berücksichtigen Sie die Einfahrt, den aufrechterhaltenen Betrieb und die ordnungsgemäße Ausfahrt.
Der Test sollte über den Übergang in den Dauerbetrieb und den Ausgang hinaus fortgesetzt werden; eine Hochspannungsmessung erfasst nur einen Zustand innerhalb des Lebenszyklus, den die Freigabe unterstützen soll.
Die TI TPS26750A-Dokumentation veranschaulicht eine EPR-Controller-Implementierung. Die Konfiguration oder Leistung eines bestimmten Ladegeräts wird nicht ermittelt. Wählen Sie Fälle für den implementierten Modus und die anwendbare Protokollversion aus. Kabelqualifizierung, Anforderungen an stromempfangende Geräte und Strompfadverhalten müssen alle sichtbar genug sein, um das Ergebnis zu unterstützen.
Eine Änderung der Verbindungsverwaltung kann sich auch dann auf den EPR auswirken, wenn die Nennleistungseinstellungen identisch bleiben. Vergleichen Sie Wartungsereignisse und -reaktionen unter kontrollierten Eingaben und unterscheiden Sie eine nicht unterstützte Kombination von einem fehlgeschlagenen unterstützten Fall. Behalten Sie Exit- und Reconnect-Captures bei. Die relevante Akzeptanzfrage ist, ob der Kandidat den angegebenen Lebenszyklus richtig handhabt, und nicht, ob der Testtisch einmal die größte beworbene Wattzahl des Produkts erreicht hat.
Der Eintrittsschutz ist kein Wartungsschutz. Ein Kandidat kann den erforderlichen EPR-Status herstellen und ihn später aufgrund eines Wartungs- oder Exit-Ereignisses verlieren. Behalten Sie während dieses Lebenszyklus das gleiche Kabel und Stromempfangsgerät bei und überprüfen Sie dann das früheste geänderte Verhalten und nicht nur die endgültige Spannung.
Wie sollen Multiport-Ereignisse wiedergegeben werden?
Legen Sie die Lastkombination und die Befestigungsreihenfolge fest.
Zeichnen Sie das ursprüngliche Stromempfangsgerät auf, während ein zweiter Port seinen Zustand ändert. Dass das neue Gerät mit Strom versorgt wird, beweist nicht, dass das erste Gerät seine erforderliche Betriebskontinuität beibehalten hat.
Im TI Multi-Port-USB-C-Ladeanwendungshinweis wird ein Designkontext für die Shared-Power-Steuerung erläutert. Ein Kandidat kann seine Zuteilungspolitik bewusst ändern, das daraus resultierende Verhalten muss jedoch mit der genehmigten Produktanforderung übereinstimmen. Identifizieren Sie, welches Stromempfangsgerät seinen Vertrag einhält, welches neu aushandelt und welches eine messbare Unterbrechung erfährt.
Verwenden Sie mehr als einen statischen Zustand, in dem alle Ports verbunden sind, wenn die beabsichtigte Verwendung das Hinzufügen oder Entfernen von Geräten umfasst. Behalten Sie die Reizreihenfolge und den Zustand unmittelbar vor jedem Ereignis bei. Ein Telefon, das am Ende noch aufgeladen wird, kann eine kurze Unterbrechung verbergen, die ein anderes Gerät neu startet. Vergleichen Sie die gelieferte Leistung und den relevanten Betriebszustand des Stromempfangsgeräts und unterscheiden Sie dann eine akzeptable Zuordnungsänderung von einer nicht genehmigten Kontinuitätsregression.
| Fall und Revision | Grundbeobachtung | Kandidatenbeobachtung | Entscheidungsbeweise |
|---|---|---|---|
| Erforderliches festes Profil; Builds identifiziert | Erforderliche Anfrage angenommen und Ausgabe überprüft | Dieselbe Anfrage abgelehnt | Fähigkeits- und Anforderungsverfolgung; eine unbeabsichtigte Regression untersuchen |
| PPS-Grenze; Builds identifiziert | Anwendbare Grenze wird wie angegeben behandelt | Unterschiedliche Reaktion auf denselben Reiz | Verschlüsselte Anfrage und genehmigte Methode; feststellen, ob eine Änderung beabsichtigt ist |
| Zweitanschlussanschluss; Builds identifiziert | Zuteilungsänderungen innerhalb des vereinbarten Verhaltens | Das aktive Strom empfangende Gerät startet unerwartet neu | Erfassung des Ausgangs- und Leistungsempfangsgerätezustands; Kontinuitätsentscheidung erforderlich |
| Fehlerbehebung; Builds identifiziert | Der nächste Anhang ist erfolgreich | Nächster Anhang kann nicht ausgehandelt werden | Fehler- und Wiederverbindungsspuren; der Defektschluss bleibt unvollständig |
Welche Fehlerfälle sollen nach einer Behebung erhalten bleiben?
Behalten Sie den ursprünglichen Auslöser und die Wiederherstellungsanforderung bei.
Wiederholen Sie die nächste Verbindung nach der Fehlerreaktion; ein erfolgreicher Schutzstopp kann einen unbeabsichtigten dauerhaften Zustand hinterlassen, der durch den ursprünglichen Ein-Ereignis-Test nicht aufgedeckt werden würde.
Verwenden Sie zugelassene Labormethoden für ungültige Nachrichten, Trennereignisse oder elektrische Fehlerreize. Notieren Sie, welches Instrument das Ereignis erzeugt hat und wie seine Parameter gesteuert wurden. Eine fehlerhafte Erfassung ist nicht automatisch ein Beweis dafür, dass das Produkt den beabsichtigten Fehler aufweist. Überprüfen Sie die Reizabgabe, bevor Sie die Reaktion interpretieren.
Vergleichen Sie die Genesung des Kandidaten mit dem erforderlichen Rückkehrzustand: Leerlauf, wiederhergestellter Vertrag oder ein anderer explizit definierter Zustand. Wiederholen Sie die entsprechende Verbindung nach der Wiederherstellung, um den dauerhaften Controller-Status anzuzeigen. Ein Fix, der ein Ereignis übersteht, den nächsten Anhang jedoch unbrauchbar macht, ist für diese Anforderung unvollständig. Bewahren Sie den ursprünglichen Fehlerbeweis und das neue Ergebnis zusammen auf, mit einer klaren Erklärung, warum die beobachtete Wiederherstellung die Behebung des Fehlers unterstützt.
Ein Patch kann den sichtbaren Fehler beseitigen und gleichzeitig den Fallback an anderer Stelle ändern. Verwenden Sie den ursprünglichen fehlgeschlagenen Reiz erneut und untersuchen Sie dann die angrenzenden Zustände, die über denselben Kontrollpfad erreicht werden. Das ist informativer, als eine unabhängige Demonstration der maximalen Leistung erneut durchzuführen und die Regression als abgeschlossen zu bezeichnen.
Welche Beweise sollten eine Firmware-Freigabe autorisieren?
Genehmigen Sie definierte Abdeckungen und ungelöste Probleme explizit.
Das installierte Produktionsartefakt muss mit dem genehmigten Kandidaten übereinstimmen; Archivieren Sie seine Konfiguration mit der ausgeführten Abdeckung, damit technische Versuche nicht mit dem veröffentlichten Firmware-Build verwechselt werden können.
Das Release-Paket sollte den Build, die Konfigurationsprüfsumme oder eine gleichwertige Artefaktkontrolle, kompatible Hardware und die ausgeführte Matrix angeben. Zusammenfassungen müssen mit den zugrunde liegenden Spuren und Messungen übereinstimmen. Ein als bestanden markierter Fall sollte eine nachvollziehbare Anforderung und ein nachvollziehbares Ergebnis haben; ein nicht ausgeführter Fall sollte nicht ausgeführt werden und nicht von einem zugehörigen Gerät abgeleitet werden.
Erstellen Sie eine Release-Genehmigung anhand von Unterschieden und nicht anhand der Gesamtzahl der Durchgänge. Klassifizieren Sie jedes geänderte Ergebnis als beabsichtigt, als Anforderungsverstoß oder als ungelöst; ein unterlassener Fall bleibt unvollendet. Vereinbaren Sie diese Verantwortlichkeiten in der OEM/ODM-Spezifikation. Halten Sie das genehmigte Artefakt von einem Kandidaten fern, der lediglich eine geeignete Teilmenge bestanden hat. Behalten Sie bei einer Fehlerbeseitigung den ursprünglichen Auslöser und angrenzende betroffene Pfade bei, damit die Genehmigung die Korrektur nachweist, ohne einen neuen Fallback, eine neue Portzuweisung oder eine Wiederherstellungsregression zu verbergen.
Häufige Fragen
Kann ein Multimeter einen PD-Firmware-Regressions-Trace ersetzen?
Nein. Es kann einen nützlichen elektrischen Messwert unter einer bestimmten Bedingung liefern, zeigt jedoch nicht den Fähigkeitsaustausch, die Anforderungsverarbeitung oder die Ereignissequenz an, die von der Firmware gesteuert werden. Kombinieren Sie geeignete elektrische Messungen mit einer dekodierten Erfassung oder einem validierten Controller-Protokoll. Selbst eine stabile Endspannung kann auf einen unerwarteten Reset oder Fallback folgen. Die benötigten Werkzeuge hängen vom jeweiligen Fall ab; die Aufzeichnung muss sowohl das bewertete Verhalten als auch die gelieferte Ausgabe offenlegen, wenn diese Ausgabe die Akzeptanz beeinflusst.
Sollten Gerätesoftware-Updates die Regressionsmatrix ändern?
Überprüfen Sie sie, wenn sie das Anforderungsmuster, die unterstützten Modi oder das Startverhalten des Stromempfangsgeräts ändern können. Behalten Sie nach Möglichkeit den zuvor genehmigten Gerätestatus bei und fügen Sie einen separat identifizierten aktualisierten Status hinzu. Andernfalls kann ein geändertes Stromempfangsgerät dazu führen, dass der Ladegerätkandidat anders aussieht als sein Ausgangswert, ohne dass eine Ladegerätregression erstellt wird. Erklären Sie die Abdeckungsentscheidung und bewahren Sie beide Softwareidentitäten. Die Matrix sollte die unterstützten Kundenbedingungen widerspiegeln und es einem Ingenieur dennoch ermöglichen, den ursprünglichen Vergleich zu reproduzieren.
Was sollte passieren, nachdem eine ungelöste Firmware-Regression festgestellt wurde?
Halten Sie den Kandidaten von der genehmigten Version fern und nutzen Sie den Änderungskontrollprozess des Programms, um eine dokumentierte Entscheidung über den Umgang mit der Feststellung zu treffen. Behalten Sie die Ausgangslage, den fehlgeschlagenen Stimulus und die betroffene Abdeckung bei, bevor Sie eine Korrektur oder einen Rollback in Betracht ziehen. Die Wiederverwendung eines früheren Builds erfordert außerdem kompatible Hardware und Konfiguration; Gehen Sie nicht davon aus, dass es automatisch für jede überarbeitete Baugruppe geeignet ist. Die technische Genehmigung sollte das akzeptierte Artefakt und die verbleibenden Einschränkungen erläutern, anstatt einen ungelösten Unterschied in einer allgemeinen Zählung erfolgreicher Tests verschwinden zu lassen.
Fazit: Geben Sie ein Artefakt mit seinen Beweisen frei
Eine Firmware-Version ist eine kontrollierte Verhaltensänderung. Vergleichen Sie den genauen Kandidaten mit einer reproduzierbaren Basislinie, decken Sie die relevanten festen, programmierbaren, erweiterten Leistungs- und Shared-Port-Pfade ab und behalten Sie die Fehler bei, die zuvor Schwachstellen aufgedeckt haben. Verwenden Sie echte Stromempfangsgeräte und kontrollierte Reize für ihre unterschiedlichen Zwecke, anstatt beides als vollständige Abdeckung zu betrachten. Trennen Sie vor der Freigabe beabsichtigte Änderungen von ungeklärten Unterschieden und identifizieren Sie jeden ungelösten Fall. Halten Sie das genehmigte Artefakt, die Konfiguration und die unterstützenden Erfassungen zusammen, damit die in der Produktion installierte Version mit den von der Technik überprüften Beweisen abgeglichen werden kann.
{“@context”: “https://schema.org”, “@type”: “FAQPage”, “mainEntity”: [{“@type”: “Question”, “name”: “Kann ein Multimeter einen PD-Firmware-Regressions-Trace ersetzen?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Nein. Es kann einen nützlichen elektrischen Messwert unter einer bestimmten Bedingung liefern, zeigt jedoch nicht den Fähigkeitsaustausch, die Anforderungsverarbeitung oder die Ereignissequenz an, die von der Firmware gesteuert werden. Kombinieren Sie geeignete elektrische Messungen mit einer dekodierten Erfassung oder einem validierten Controller-Protokoll. Selbst eine stabile Endspannung kann auf einen unerwarteten Reset oder Fallback folgen. Die benötigten Werkzeuge hängen vom jeweiligen Fall ab; die Aufzeichnung muss sowohl das bewertete Verhalten als auch die gelieferte Ausgabe offenlegen, wenn diese Ausgabe die Akzeptanz beeinflusst.”}}, {“@type”: “Question”, “name”: “Sollten Gerätesoftware-Updates die Regressionsmatrix ändern?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Überprüfen Sie sie, wenn sie das Anforderungsmuster, die unterstützten Modi oder das Startverhalten des Stromempfangsgeräts ändern können. Behalten Sie nach Möglichkeit den zuvor genehmigten Gerätestatus bei und fügen Sie einen separat identifizierten aktualisierten Status hinzu. Andernfalls kann ein geändertes Stromempfangsgerät dazu führen, dass der Ladegerätkandidat anders aussieht als sein Ausgangswert, ohne dass eine Ladegerätregression erstellt wird. Erklären Sie die Abdeckungsentscheidung und bewahren Sie beide Softwareidentitäten. Die Matrix sollte die unterstützten Kundenbedingungen widerspiegeln und es einem Ingenieur dennoch ermöglichen, den ursprünglichen Vergleich zu reproduzieren.”}}, {“@type”: “Question”, “name”: “Was sollte passieren, nachdem eine ungelöste Firmware-Regression festgestellt wurde?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Halten Sie den Kandidaten von der genehmigten Version fern und nutzen Sie den Änderungskontrollprozess des Programms, um eine dokumentierte Entscheidung über den Umgang mit der Feststellung zu treffen. Behalten Sie die Ausgangslage, den fehlgeschlagenen Stimulus und die betroffene Abdeckung bei, bevor Sie eine Korrektur oder einen Rollback in Betracht ziehen. Die Wiederverwendung eines früheren Builds erfordert außerdem kompatible Hardware und Konfiguration; Gehen Sie nicht davon aus, dass es automatisch für jede überarbeitete Baugruppe geeignet ist. Die technische Genehmigung sollte das akzeptierte Artefakt und die verbleibenden Einschränkungen erläutern, anstatt einen ungelösten Unterschied in einer allgemeinen Zählung erfolgreicher Tests verschwinden zu lassen.”}}]}