Une \u00e9quipe a une fois exp\u00e9di\u00e9 des cartes avec un tampon \u00ab test fonctionnel r\u00e9ussi \u00bb parce qu\u2019un bootloader affichait une banni\u00e8re UART amicale. La cha\u00eene correspondait, la fixture s\u2019allumait en vert, et le calendrier semblait moins terrifiant. Puis, les premi\u00e8res unit\u00e9s ont commenc\u00e9 \u00e0 revenir avec des resets al\u00e9atoires \u2014 environ 6% \u00e9checs en d\u00e9but de vie dans les premi\u00e8res milliers \u2014 juste au moment o\u00f9 le produit avait besoin de cr\u00e9dibilit\u00e9. Sur le banc, les cartes semblaient correctes jusqu\u2019\u00e0 ce qu\u2019une activit\u00e9 r\u00e9elle se produise : une rafale de transmission BLE tirait sur le syst\u00e8me d\u2019alimentation et une chute de rail de 1,8 V apparaissait clairement sur une trace de scope. La cause profonde n\u2019\u00e9tait pas un comportement myst\u00e9rieux du firmware. C\u2019\u00e9tait une r\u00e9alit\u00e9 d\u2019assemblage : un inducteur substitu\u00e9 avec une marque sup\u00e9rieure similaire mais un comportement de saturation diff\u00e9rent, plus un test qui n\u2019a jamais mis le rail \u00e0 l\u2019\u00e9preuve.<\/p>\n\n\n\n
Cette \u00e9chapp\u00e9e n\u2019est pas seulement une erreur technique ; c\u2019est un \u00e9chec social portant un costume technique. Une fois qu\u2019un rapport indique \u00ab PASS fonctionnel \u00bb, d\u2019autres entendent \u00ab fonctionnalit\u00e9s valid\u00e9es \u00bb, et l\u2019organisation commence \u00e0 prendre des d\u00e9cisions d\u2019exp\u00e9dition avec une carte fausse.<\/p>\n\n\n\n
Fonctionnel n\u2019est pas un synonyme de \u00ab \u00e7a imprime quelque chose \u00bb.<\/p>\n\n\n
Lorsque le firmware est en retard ou instable, les premiers tests doivent se comporter comme ce qu\u2019ils sont : d\u00e9tecteurs de d\u00e9fauts d\u2019assemblage et r\u00e9f\u00e9rences mat\u00e9rielles. Les qualifier de \u00ab fonctionnels \u00bb est la fa\u00e7on dont les \u00e9quipes certifient accidentellement un comportement qu\u2019elles n\u2019ont jamais exerc\u00e9.<\/p>\n\n\n\n
Voici le pi\u00e8ge de l\u2019\u00e9tiquette \u00ab test fonctionnel \u00bb. Quelqu\u2019un dit : \u00ab nous avons besoin d\u2019un test fonctionnel sans firmware \u00bb, et ce qu\u2019il veut g\u00e9n\u00e9ralement dire, c\u2019est \u00ab nous avons besoin d\u2019un moyen de faire avancer la ligne sans transformer la fabrication en laboratoire de firmware \u00bb. Ce sont des objectifs diff\u00e9rents. La premi\u00e8re formulation invite \u00e0 un tampon PASS\/FAIL b\u00e2cl\u00e9. La seconde invite \u00e0 un test cadr\u00e9 avec des revendications explicites et des non-revendications explicites, ce qui \u00e9vite que les arguments tournent en boucle lors des revues de build. Cela maintient \u00e9galement l\u2019honn\u00eatet\u00e9 des tableaux de bord lorsque la direction demande des taux de r\u00e9ussite et que quelqu\u2019un tente d\u2019associer automatisation et qualit\u00e9.<\/p>\n\n\n\n
Pour \u00e9viter le d\u00e9rapage de la port\u00e9e, obligez chaque plan de test pr\u00e9coce \u00e0 r\u00e9pondre par \u00e9crit \u00e0 deux questions : quels d\u00e9fauts cela d\u00e9tecte-t-il, et quels comportements du produit cela pas<\/em> ne certifie pas. Certaines \u00e9quipes le formalisent comme un artefact de validation \u00e0 deux colonnes lors du transfert DVT vers PVT, car la m\u00e9moire ne survit pas \u00e0 la pression du calendrier.<\/p>\n\n\n\n Un public professionnel n'a pas besoin d'une d\u00e9finition de JTAG, SWD, UART, I2C ou SPI ici. Le travail utile consiste \u00e0 d\u00e9cider ce qui peut \u00eatre mesur\u00e9 de mani\u00e8re d\u00e9terministe aujourd'hui, et comment ces mesures sont nomm\u00e9es et transmises pour que personne ne weaponise un feu vert.<\/p>\n\n\n Une ligne de base ne signifie pas ajouter \u00ab plus de tests \u00bb. Cela consiste \u00e0 \u00e9tablir un petit ensemble d'invariants \u2014 5 \u00e0 8 suffisent g\u00e9n\u00e9ralement \u2014 qu'une carte doit satisfaire avant que tout sympt\u00f4me du micrologiciel ne vaille la peine d'\u00eatre d\u00e9battu. Les rails et les horloges sont les invariants classiques car ils sont des pr\u00e9conditions pour tout le reste, et il est difficile de contester lorsqu'ils sont captur\u00e9s sur des instruments plut\u00f4t que dans des journaux.<\/p>\n\n\n\n Cela appara\u00eet dans le motif \u00ab excuse du micrologiciel tardif qui a cach\u00e9 un probl\u00e8me d'horloge \u00bb. Dans un cas, les cartes d\u00e9marraient parfois et se bloquaient d'autres fois, et \u00ab le micrologiciel est instable \u00bb est devenu l'explication par d\u00e9faut. La solution a commenc\u00e9 par \u00e9liminer la variabilit\u00e9 : r\u00e9p\u00e9ter la m\u00eame exp\u00e9rience sur 50 cycles d'alimentation, mesurer le d\u00e9marrage de l'oscillateur et le timing de r\u00e9initialisation, et cesser de consid\u00e9rer les journaux incoh\u00e9rents comme des preuves. La source d'horloge avait un d\u00e9marrage marginal dans des conditions froides \u00e0 cause d'un choix de condensateur de charge qui \u00e9tait \u00ab suffisamment proche \u00bb sur le papier. Une fois cela mesur\u00e9 et corrig\u00e9, le micrologiciel a cess\u00e9 de para\u00eetre flaky. La victoire n'\u00e9tait pas un meilleur format de journal ; c'\u00e9tait une forme d'onde et une discipline de r\u00e9p\u00e9tabilit\u00e9.<\/p>\n\n\n\n La premi\u00e8re priorit\u00e9 de la ligne de base est les rails d'alimentation, car si les rails sont incorrects, tous les autres sympt\u00f4mes sont faussement attribu\u00e9s. Cela signifie mesurer plus que \u00ab il d\u00e9marre donc l'alimentation est correcte \u00bb. Cela implique les tensions nominales des rails, la s\u00e9quence par rapport aux enable et r\u00e9initialisation, le ripple\/bruit avec une bande passante connue et une technique de sonde d\u00e9cente, et un stress d\u00e9lib\u00e9r\u00e9 qui approche un transitoire en pire cas. Un oscilloscope Tektronix MDO3000 et une alimentation de table comme une Keysight E36313A peuvent faire beaucoup de cela sans c\u00e9r\u00e9monie, et un multim\u00e8tre calibr\u00e9 comme un Fluke 87V d\u00e9tecte rapidement les mensonges ennuyeux.<\/p>\n\n\n\n L'histoire du \u00ab tampon de validation qui co\u00fbte un quart \u00bb est une bonne raison de traiter la r\u00e9ponse transitoire de charge comme non optionnelle. Une comparaison de banni\u00e8re UART peut passer sur un rail marginal parce que le d\u00e9marrage est un \u00e9v\u00e9nement \u00e0 faible stress compar\u00e9 aux radios, moteurs ou capteurs tirant du courant par rafales. Une \u00e9tape de charge script\u00e9e de 10 secondes, ou toute \u00e9tape r\u00e9p\u00e9table qui approche un transitoire de courant r\u00e9el, est une m\u00e9thode peu co\u00fbteuse pour d\u00e9tecter des inductances substitu\u00e9es, des condensateurs de mauvaise valeur ou un r\u00e9gulateur \u00e0 peine stable. Sans ce stress, le test v\u00e9rifie seulement que la carte est calme, pas qu'elle est saine.<\/p>\n\n\n\n \u00c0 ce stade, le pi\u00e8ge du scan I2C tend \u00e0 appara\u00eetre : \u00ab notre scan i2c montre des dispositifs, donc le mat\u00e9riel est bon \u00bb. Une \u00e9num\u00e9ration peut encore passer avec la mauvaise valeur de pull-up, un rail marginal alimentant un level shifter, une soudure froide qui s'ouvre sous vibration, ou une horloge qui d\u00e9marre lentement au point de brouiller le timing une fois sur dix. Elle peut aussi passer alors qu'une r\u00e9f\u00e9rence analogique est de qualit\u00e9 inf\u00e9rieure, car les communications num\u00e9riques restent parfaites jusqu'\u00e0 ce que les mesures d\u00e9rivent sur le terrain. Un scan I2C est une v\u00e9rification utile de fum\u00e9e, mais ce n'est pas une preuve d'une fondation stable en puissance et timing.<\/p>\n\n\n\n Une ligne de base con\u00e7ue pour survivre aux changements du micrologiciel doit au moins avoir un exemple de seuil concret, car l'impr\u00e9cision est la fa\u00e7on dont la \u00ab mesure \u00bb se transforme en vibrations. Un exemple, pas une r\u00e8gle universelle : une ligne de 1,8 V pourrait devoir rester dans \u00b15% en r\u00e9gime permanent, et sous une \u00e9tape de charge d\u00e9finie (par exemple, en approchant la rafale radio attendue), la chute pourrait \u00eatre limit\u00e9e \u00e0 <100 mV avec une r\u00e9cup\u00e9ration dans une courte fen\u00eatre. Cette fen\u00eatre pourrait \u00eatre inf\u00e9rieure \u00e0 une milliseconde ou plusieurs millisecondes selon le r\u00e9gulateur, le profil de charge, et ce que les circuits int\u00e9gr\u00e9s en aval peuvent tol\u00e9rer. C'est ici que la limite d'incertitude compte : les seuils de ripple et de chute d\u00e9pendent de la compensation sp\u00e9cifique du r\u00e9gulateur, de la bande passante de la sonde, de la zone de boucle physique de la sonde, et de la forme transitoire r\u00e9elle. La fa\u00e7on de rendre le seuil honn\u00eate est de le valider sur une unit\u00e9 de r\u00e9f\u00e9rence et ensuite sur une unit\u00e9 d\u00e9fectueuse connue (ou une faute induite) pour confirmer que la mesure discrimine entre \u00ab sain \u00bb et \u00ab sur le point de cr\u00e9er une file RMA \u00bb.<\/p>\n\n\n\n La r\u00e9f\u00e9rence de base devrait \u00e9galement inclure un petit ensemble de v\u00e9rification analogique sur les cartes \u00e0 signal mixte, car sauter l'analogique est la fa\u00e7on dont les \u00e9quipes livrent des catastrophes \u00ab \u00e7a fonctionne sur mon banc \u00bb. La d\u00e9faillance classique est subtile et co\u00fbteuse : l'interface num\u00e9rique est parfaite, les valeurs semblent raisonnables \u00e0 temp\u00e9rature ambiante, puis les lectures sur le terrain d\u00e9rivent avec la temp\u00e9rature ou la variation de l'alimentation. Dans un programme de capteurs, la cause \u00e9tait une substitution due \u00e0 une p\u00e9nurie : une r\u00e9f\u00e9rence de 2,048 V remplie avec la mauvais tol\u00e9rance, un caract\u00e8re diff\u00e9rent dans le num\u00e9ro de pi\u00e8ce. Le firmware a essay\u00e9 de masquer la d\u00e9rive avec des tables de compensation jusqu'\u00e0 ce que quelqu'un mesure la broche de r\u00e9f\u00e9rence et regarde la distribution du code ADC avec une entr\u00e9e fixe. La solution \u00e9tait le contr\u00f4le du BOM et une seule mesure de r\u00e9f\u00e9rence lors des premiers tests avec un seuil suffisamment strict pour d\u00e9tecter les substitutions. La calibration ne peut pas corriger une famille de composants \u00e9chang\u00e9s ; elle ne peut que masquer la d\u00e9faillance jusqu'\u00e0 ce qu'elle \u00e9chappe.<\/p>\n\n\n\n Les horloges et les r\u00e9initialisations m\u00e9ritent une place de r\u00e9f\u00e9rence pour la m\u00eame raison que les rails : elles cr\u00e9ent des mensonges si elles sont marginales. Une habitude simple \u2014 capturer le timing de la d\u00e9sassertion de la r\u00e9initialisation et le d\u00e9marrage de l'oscillateur lors de dizaines de cycles d'alimentation \u2014 transforme un \u00ab blocage al\u00e9atoire \u00bb en un syst\u00e8me reproductible. Cela emp\u00eache \u00e9galement les \u00e9quipes de fuseaux horaires diff\u00e9rents de transformer chaque intermittence en une dispute Slack sur qui a cass\u00e9 quoi pendant la nuit.<\/p>\n\n\n Les d\u00e9faillances intermittentes ont souvent une origine m\u00e9canique, et un dispositif de production est un syst\u00e8me m\u00e9canique avec des effets secondaires \u00e9lectriques. Consid\u00e9rer les r\u00e9sultats du dispositif comme la v\u00e9rit\u00e9 absolue sans prouver que le dispositif est fiable, c'est ainsi que les \u00e9quipes perdent des journ\u00e9es en retouches qui n'avaient aucune chance d'aider.<\/p>\n\n\n\n Un dispositif \u00e0 lit d'aiguilles qui a commenc\u00e9 \u00e0 \u00e9chouer des cartes ayant auparavant pass\u00e9 la mise en service sur banc. Les sympt\u00f4mes \u00e9taient incoh\u00e9rents, ce qui faisait de la \u00ab stabilit\u00e9 du firmware \u00bb un bouc \u00e9missaire facile. La solution plus rapide \u00e9tait de faire passer une carte dor\u00e9e connue pour \u00eatre bonne \u00e0 travers le dispositif et de comparer la r\u00e9sistance de contact entre les broches pogo. La carte dor\u00e9e a aussi \u00e9chou\u00e9. Cela a imm\u00e9diatement d\u00e9plac\u00e9 le bl\u00e2me loin de la conception et vers l'infrastructure de test. Le coupable n'\u00e9tait pas subtil : un bo\u00eetier de connecteur sur le dispositif \u00e9tait hors tol\u00e9rance, d\u00e9calant l'alignement de sorte que deux broches pogo touchaient \u00e0 peine. Remplacer le connecteur, et le motif d'\u00e9chec dispara\u00eet. Apr\u00e8s cela, une \u00e9tape d'auto-test du dispositif est devenue non n\u00e9gociable.<\/p>\n\n\n\n Utilisez cet arbre de d\u00e9cision pour pr\u00e9venir la plupart du chaos pr\u00e9coce :<\/p>\n\n\n\n L'expression \u00ab d\u00e9faillances al\u00e9atoires sur le dispositif \u00bb doit \u00eatre consid\u00e9r\u00e9e comme une demande de prouver le dispositif, et non comme une demande de plus de journaux de firmware. Cette habitude seule change le ton du d\u00e9bogage nocturne inter-sites car elle r\u00e9duit imm\u00e9diatement l'espace de recherche.<\/p>\n\n\n Une strat\u00e9gie de test pr\u00e9coce productive n'est pas celle avec la liste de contr\u00f4le la plus longue. C'est celle qui d\u00e9tecte le plus de classes de d\u00e9fauts probables avec les mesures fiables les moins co\u00fbteuses, tout en rendant explicites les reports pour qu'ils ne puissent pas \u00eatre dissimul\u00e9s dans un tampon vert.<\/p>\n\n\n\n Une \u00e9chelle de mod\u00e8le de d\u00e9faut commence par \u00e9num\u00e9rer les classes de d\u00e9fauts qui apparaissent r\u00e9ellement dans les constructions sous contrat : ouvertures, courts-circuits, pi\u00e8ce incorrecte, orientation incorrecte, pi\u00e8ce manquante, ponts de soudure, et mauvais alignement m\u00e9canique. Ensuite, elle associe chaque classe \u00e0 une m\u00e9thode de d\u00e9tection qui ne n\u00e9cessite pas de firmware stable : inspection automatique pour les erreurs grossi\u00e8res de placement et de polarit\u00e9, v\u00e9rifications de continuit\u00e9 l\u00e0 o\u00f9 l'acc\u00e8s existe, signatures de rails et r\u00e9ponse en charge pour les substitutions et composants passifs manquants, et test de d\u00e9tection de fronti\u00e8re l\u00e0 o\u00f9 les cha\u00eenes et l'acc\u00e8s sont r\u00e9els. La valeur de l'\u00e9chelle n'est pas la couverture th\u00e9orique, mais la capacit\u00e9 \u00e0 dire, \u00e0 haute voix et par \u00e9crit, \u00ab ce test d\u00e9tecte les ouvertures\/courts sur ces r\u00e9seaux, mais ne valide pas la fonctionnalit\u00e9 X. \u00bb<\/p>\n\n\n\n Cela r\u00e9pond \u00e9galement \u00e0 la pression de \u00ab automatiser compl\u00e8tement les tests de production maintenant \u00bb. L'automatisation n'est pas un progr\u00e8s si elle automatise le bruit. Prouver la r\u00e9p\u00e9tabilit\u00e9 du dispositif, d\u00e9finir des invariants, et choisir des tests de classe de d\u00e9faut qui auront encore la m\u00eame signification la semaine prochaine, c'est du progr\u00e8s. Tout le reste n'est que th\u00e9\u00e2tre de tableau de bord.<\/p>\n\n\n\n Le report n\u00e9cessite une ligne de d\u00e9fense car les gens assimilent \u00ab non test\u00e9 \u00bb \u00e0 de la n\u00e9gligence. La meilleure fa\u00e7on de formuler cela est que les reports sont des d\u00e9cisions de risque intentionnelles : report\u00e9s parce que l'acc\u00e8s manque, parce que le firmware est trop volatile, ou parce que la classe de d\u00e9faut est rare par rapport au calendrier et au contexte de construction actuels. Le but est d'emp\u00eacher ces reports de se transformer en revendications implicites.<\/p>\n\n\n La d\u00e9tection par balayage de fronti\u00e8re est l'outil le moins glamour, mais le plus efficace dans cette situation, car elle peut fournir une couverture d\u00e9terministe pour les ouvertures et courts sur des composants \u00e0 pas fin sans n\u00e9cessiter de firmware d'application. Elle \u00e9limine \u00e9galement les d\u00e9bats. Si la cha\u00eene peut effectuer des tests d'interconnexion et qu'un r\u00e9seau montre une ouverture, il n'y a pas d'argument pour savoir si une modification de timing du firmware le corrigera.<\/p>\n\n\n\n Dans un cas avec des d\u00e9faillances intermittentes du bus, un analyseur logique bon march\u00e9 donnait l'impression que le bus \u00e9tait \u00ab principalement en bon \u00e9tat \u00bb, ce qui maintenait la responsabilit\u00e9 sur le timing du firmware. Les tests d'interconnexion boundary-scan ont isol\u00e9 un circuit ouvert sur une broche d'adresse BGA\u2014probablement une soudure froide\u2014sans attendre plus de logs ou de code. Cela a \u00e9vit\u00e9 une boucle co\u00fbteuse de rework par rayons X et a transform\u00e9 le rework en une action cibl\u00e9e avec une v\u00e9rification quantitative. La coordination entre Everett et une \u00e9quipe CM \u00e0 Penang est devenue plus simple car la preuve \u00e9tait d\u00e9terministe.<\/p>\n\n\n\n La v\u00e9rification de la r\u00e9alit\u00e9 est importante : le boundary-scan ne fonctionne que si l'acc\u00e8s est r\u00e9el. La continuit\u00e9 de la cha\u00eene doit \u00eatre con\u00e7ue, les BSDL doivent \u00eatre utilisables, les r\u00e9sistances de tirage et les straps doivent \u00eatre coh\u00e9rents, et les param\u00e8tres de s\u00e9curit\u00e9 ne sont pas des \u00ab probl\u00e8mes ult\u00e9rieurs \u00bb\u2014l'acc\u00e8s d\u00e9bogage fusible est une contrainte stricte. La demande souvent irr\u00e9aliste est \u00ab le boundary scan peut-il tout tester \u00bb, souvent associ\u00e9 \u00e0 \u00ab pas de pads de test mais cela devrait quand m\u00eame \u00eatre faisable \u00bb. La r\u00e9ponse honn\u00eate est que la faisabilit\u00e9 d\u00e9pend de l'acc\u00e8s \u00e0 la cha\u00eene, de la qualit\u00e9 des BSDL, et de l'\u00e9tat de verrouillage ; promettre un pourcentage de couverture sans ces faits est la fa\u00e7on dont les plans de test deviennent de la fiction.<\/p>\n\n\n\n Un compromis pratique qui emp\u00eache les \u00e9quipes de tourner en rond est de piloter le boundary-scan sur une seule carte avec l'acc\u00e8s pr\u00e9vu et la cha\u00eene d'outils (les suites Corelis\/Asset\/Keysight sont courantes en usine). Si cela fonctionne, cela peut remplacer des journ\u00e9es de d\u00e9bat lors de chaque futur \u00e9chec d'analyse. Si cela ne fonctionne pas, le plan doit imm\u00e9diatement revenir aux rails, horloges, resets, et un petit ensemble de signatures analogiques\u2014des choses qui peuvent encore \u00eatre mesur\u00e9es via des connecteurs et pads disponibles.<\/p>\n\n\n Les premiers tests ont tendance \u00e0 \u00e9chouer parce qu'ils sont fragiles, non document\u00e9s, ou li\u00e9s aux pr\u00e9f\u00e9rences d'outil d'une seule personne. Un harnais minimal qui survit est ennuyeux par conception : un conducteur, une carte sp\u00e9cifique avec une carte de broches, un seuil d\u00e9fini, et une journalisation qui rend les reruns comparables.<\/p>\n\n\n\n Un mod\u00e8le qui a r\u00e9sist\u00e9 \u00e0 plusieurs r\u00e9\u00e9critures du firmware est un harnais \u00e0 trois couches : abstraction stimulus\/mesure (pilotes d'instrument via quelque chose comme pyvisa ou une couche DAQ), une carte de la carte (souvent un fichier YAML de broches suffit), et des cas de test qui restent d\u00e9terministes. La journalisation en CSV index\u00e9e par num\u00e9ro de s\u00e9rie peut \u00eatre suffisante d\u00e8s le d\u00e9but, tant que les m\u00e9tadonn\u00e9es sont disciplin\u00e9es : r\u00e9vision de la carte, ID du fixture, conditions ambiantes, et version de l'image de test lorsque le firmware est impliqu\u00e9. Le choix du langage (Python vs LabVIEW vs environnements du fournisseur) importe moins que la fronti\u00e8re modulaire. Un VI LabVIEW monolithique que seule une personne peut modifier devient un risque de personnel plut\u00f4t qu'une strat\u00e9gie de test.<\/p>\n\n\n\n Il existe aussi une subtile incertitude qui appartient \u00e0 la conversation sur le harnais : les signatures de profil de courant. Elles sont puissantes lorsque les \u00e9tats du firmware sont stables. Lorsque le firmware change quotidiennement, les seuils de courant doivent \u00eatre trait\u00e9s comme une d\u00e9tection de tendance\/anomalie, pas comme un passage\/\u00e9chec strict, \u00e0 moins que l'\u00e9quipe ne puisse verrouiller une image de test versionn\u00e9e avec des drapeaux de fonctionnalit\u00e9s contr\u00f4l\u00e9s et une reproductibilit\u00e9.<\/p>\n\n\n\n Le point de passage est simple : les premiers tests peuvent \u00e9tendre leurs affirmations \u00e0 mesure que le firmware m\u00fbrit, mais seulement si le harnais maintient la couche de mesure fiable et si la nomination reste honn\u00eate. Le d\u00e9pistage pr\u00e9coce r\u00e9duit les \u00e9vasions lors de l'assemblage. Il ne certifie pas le comportement du produit.<\/p>","protected":false},"excerpt":{"rendered":" Lorsque le firmware est instable, un tampon vert \u00ab fonctionnel \u00bb peut masquer de v\u00e9ritables d\u00e9fauts. Cet article reformule les tests pr\u00e9coces autour de mesures d\u00e9terministes \u2014 rails, horloges, r\u00e9initialisations, preuve de fixture et couverture du mod\u00e8le de d\u00e9faut \u2014 afin que les taux de r\u00e9ussite refl\u00e8tent la r\u00e9alit\u00e9, et non l'optimisme.<\/p>","protected":false},"author":1,"featured_media":10696,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"article_term":"","article_term_alternate":"","article_term_def":"","article_hook":"","auto_links":"","article_topic":"","article_fact_check":"","mt_social_share":"","mt_content_meta":"","mt_glossary_display":"","glossary_heading":"","glossary":"","glossary_alter":"","glossary_def":"","article_task":"Functional test development when firmware is late or unstable","footnotes":""},"categories":[12],"tags":[],"class_list":["post-10694","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"_links":{"self":[{"href":"https:\/\/www.besterpcba.com\/fr\/wp-json\/wp\/v2\/posts\/10694","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.besterpcba.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.besterpcba.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.besterpcba.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.besterpcba.com\/fr\/wp-json\/wp\/v2\/comments?post=10694"}],"version-history":[{"count":1,"href":"https:\/\/www.besterpcba.com\/fr\/wp-json\/wp\/v2\/posts\/10694\/revisions"}],"predecessor-version":[{"id":10698,"href":"https:\/\/www.besterpcba.com\/fr\/wp-json\/wp\/v2\/posts\/10694\/revisions\/10698"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.besterpcba.com\/fr\/wp-json\/wp\/v2\/media\/10696"}],"wp:attachment":[{"href":"https:\/\/www.besterpcba.com\/fr\/wp-json\/wp\/v2\/media?parent=10694"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.besterpcba.com\/fr\/wp-json\/wp\/v2\/categories?post=10694"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.besterpcba.com\/fr\/wp-json\/wp\/v2\/tags?post=10694"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Cat\u00e9gorie<\/th> Le test peut revendiquer cela<\/th> Le test ne doit pas revendiquer cela<\/th><\/tr><\/thead> D\u00e9pistage pr\u00e9coce en assemblage<\/td> D\u00e9tecte les d\u00e9fauts d'assemblage conformes aux mesures d\u00e9finies (rails\/horloge\/r\u00e9initialisation\/continuit\u00e9\/une ou deux v\u00e9rit\u00e9s analogiques)<\/td> Certifie les fonctionnalit\u00e9s visibles par le client, la performance dans diverses conditions, la s\u00e9curit\u00e9\/conformit\u00e9, ou \u00ab fonctionne \u00bb dans un sens large<\/td><\/tr> Assist\u00e9 par le micrologiciel ult\u00e9rieurement<\/td> Valide des comportements sp\u00e9cifiques li\u00e9s \u00e0 une image de test versionn\u00e9e et reproductible et \u00e0 la tra\u00e7abilit\u00e9 des exigences<\/td> Implique une couverture en dehors des drapeaux de fonctionnalit\u00e9s activ\u00e9s ou en dehors des conditions de test<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Ligne de r\u00e9f\u00e9rence Mesure-First : Rails, puis horloges\/r\u00e9initialisations, puis une v\u00e9rit\u00e9 analogique<\/h2>\n\n\n
Prouver la fixture avant de bl\u00e2mer les cartes (Discipline Golden-First)<\/h2>\n\n\n
\n
Couverture par classe de d\u00e9fauts : une petite \u00e9chelle de mod\u00e8les de d\u00e9fauts l'emporte sur le th\u00e9\u00e2tre du \u00ab test complet \u00bb<\/h2>\n\n\n
Scan de limite : preuve d\u00e9terministe, lorsque le mat\u00e9riel le permet<\/h2>\n\n\n
Le harnais qui survit : minimal maintenant, plus profond plus tard<\/h2>\n\n\n