Assertion.ru

Comme mentionné avant que le produit final est le nombre de tests. Il existe une relation entre les tests et le cahier des charges. Le processus axé sur l'affirmation donne une idée de ce que chaque groupe d'analyses effectivement des contrôles dans le cahier des charges. En utilisant cette relation le développeur peut calculer la couverture, obtenir la liste des affirmations sur lequel les essais n'ont pas été écrites, etc

L'affirmation est une déclaration d'un cahier des charges qui peuvent être testés. Et la première étape consiste à identifier toutes les affirmations contenues dans la spécification. Après que le développeur peut écrire des tests.

Exemple d'affirmations de la Java Specification Language:

Il pourrait y avoir de nombreuses déclarations qui ne sont pas vérifiables ou qui impliquent l'incertitude. Parfois, de telles déclarations comprennent des termes comme «possible» ou «peut-être». Il n'est pas vrai que si une phrase a un mot «peut», il n'est pas vérifiable, mais habituellement il en est ainsi.

Exemples de déclarations non vérifiables:

Il ya de nombreuses discussions et les différends au sujet des affirmations. Certains disent que les exemples ne doivent pas être traités comme des affirmations. D'autres disent que chaque instruction est une des affirmations et il ya deux sortes d'entre eux: vérifiables et non vérifiables. Mon opinion personnelle est que l'affirmation est certainement quelque chose de vérifiable. Et dans la plupart des cas sont des exemples affirmations simplement parce que le test peut être écrite vérifier l'exemple particulier.

Le processus d'identification des affirmations contenues dans le cahier des charges est appelée majoration. Il existe plusieurs approches. Mais en tout cas, l'utilisateur doit être en mesure d'obtenir des informations indiquant si la déclaration est une affirmation et en quelque sorte distinguer une affirmation d'un autre. Il pourrait y avoir un dépôt séparé avec la cartographie d'affirmations et de leur carte d'identité à des déclarations. J'aime l'idée d'intégrer le balisage dans le cahier des charges. Cette approche a été choisie pour la région de langue de la version Java SE suite de test. Le JLS a été écrit dans FrameMaker. Avec des mécanismes d'exportation du format PDF et HTML ont été créés. Le version html été utilisée lors de la création de la suite de tests.

En JLS et JLS 2 quelques ancres spéciales identifié le début et la fin d'une affirmation. informations complémentaires ont été l'assertionID et bref résumé de la déclaration. La fin d'ancrage était une image et un lien vers le test. L'affichage HTML et la vue de code sont indiqués sur les illustrations correspondantes. L'affirmation d'identité sont arr033, arr034, arr020, etc

L'idée générale peut être décrite comme suit:

<a name=assertionID> <! - description shord en commentaire html ->
déclaration affirmation ici
<img href="path <a src="pics/assert.gif"> à test"> ID d'essai qui est le même que l'affirmation d'identité </ a>

Si des états distincts dans différentes parties du cahier des charges sont testées par un test de la première balise sera quelque chose comme arr033_0, arr033_1, arr033_2.

Ce type d'architecture a été utilisée pour JLS et JLS 2. Il est légèrement modifié pour JLS3, mais L'idée principale était maintenu. Je sais que certains des exemples d'approches avec les identifiants de l'affirmation de non-statique conservés dans un dépôt séparé, où ID est une valeur de hachage calculée en fonction du contenu. Pour diverses raisons, il a montré à ne pas être une très bonne solution. Il ya toujours un processus difficile la migration vers la nouvelle version de la spécification. Mais, à mon avis, il est beaucoup plus facile avec l'ID statique est-elle intégrée dans le cahier des charges.

Je lis les blogs. J'ai commencé à lire les beaucoup plus. Pourquoi fais-je cela? Eh bien .. Je suis un croyant que le partage d'informations ne se moquer du travail des autres plus. Et non seulement le travail, mais les gens la vie en général. Le partage des connaissances et des pensées est un grand pas vers la création de communautés. Weblog permet de publier des pensées, des opinions, des idées, des préoccupations pour les lecteurs. Tandis que les lecteurs peuvent ouvrir un dialogue sur un sujet abordé à l'aide des commentaires.
Je voulais créer mon blog personnel depuis longtemps, mais je suppose que je l'ai finalement fait.
Je travaille comme ingénieur logiciel dans un groupe qui crée un produit très important. Ce produit n'est pas aussi connu que Java ou Solaris. Je dirais que la plupart des ingénieurs en logiciels dans ce vaste monde ne sais pas ce sujet. Toutefois, sans ce produit, il y aura pas de Java que nous connaissons. Au moins Java ne sera pas aussi bonne, aussi populaire et aussi répandu tel qu'il est et que nous voulons qu'elle soit. Sans ce produit il n'y aura pas WORA (Write Once exécuter partout). Oui, je parle de compatibilité. Et le produit est un TCK (Technology Compatibility Kit) pour Java. En deux mots TCK est une suite de tests, ce qui permet de s'assurer que les implémentations de Java conformes à la spécification. Mon groupe travaille sous plusieurs TCK. Mais le principal est de Java SE plate-forme.
Il ya plusieurs zones différentes dans JCK (TCK pour Java SE): API, langage Java et VM.
Mon domaine que je travaille sur plus de 2 ans est «langage Java". J'écris compilateur et d'exécution des tests afin de s'assurer que Sun et les implémentations d'autres entreprises se comportent exactement comme il est dit dans la JLS (Java Language Specification).
Dans ce blog je vais essayer de partager mes connaissances, mes opinions et mes pensées au sujet de mon travail.
PS anglais n'est pas ma langue. C'est pourquoi je tiens à m'excuser pour les éventuelles erreurs (je suis sûr qu'il ya déjà beaucoup d'entre eux) et sentances bizarre dans mon blog. Je vais essayer de faire de mon mieux.