test di accettazione automatizzati / BDD e flusso di lavoro per la progettazione di un sistema

Question

test di accettazione automatizzati / BDD e flusso di lavoro per la progettazione di un sistema

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

5

Recentemente, ho iniziato a leggere il libro Specifica per esempio , che si riferisce al test funzionale automatizzato e BDD (da quello che ho capito fino ad ora ).

Ho provato a usare Concordion (.Net) e mi sembra molto interessante. Ho riscontrato problemi con la conservazione di qualsiasi forma di documentazione utile per qualsiasi sistema progettato e questo potrebbe aiutare

Il mio problema è, come si potrebbe suggerire che il flusso di lavoro nella progettazione di un sistema completo è? Alcune domande che si presentano sono:

È ideale provare a progettare l'intero sistema nel suo complesso?
Se si progetta una panoramica di livello molto elevato del sistema e quindi si creano specifiche una caratteristica principale alla volta, creiamo specifiche dettagliate - > sviluppare - > test - > passare alla funzione principale successiva?
Dovresti creare le specifiche in stile BDD per il ogni singolo metodo nel sistema, anche quelle insignificanti come alcune GetProductByReferenceCode ?

Il problema è che la maggior parte delle volte in cui in realtà inizi a sviluppare, inizi a realizzare qualcosa che deve essere fatto in modo diverso rispetto a quanto inizialmente pensato, o omissioni non notate durante la progettazione iniziale. Trovo che a volte la fase di progettazione iniziale richieda molto tempo, solo che il design effettivo del sistema sarà molto diverso una volta lanciato il prodotto.

Il mio flusso di lavoro corrente per la progettazione di un sistema è:

Inizia con l'interfaccia utente, creando prototipi di ogni schermo con cui gli utenti si occuperanno. Trovo che questo sia il metodo più visivo che gli utenti aziendali possano capire.
Definisci la logica direttamente correlata all'interfaccia utente
Definisci qualsiasi logica che si verifica in background , ad esempio notifiche, ecc.

Ha senso? In che modo questo potrebbe essere migliorato?

bdd design test-automation functional-testing

posta Karl Cassar 23.05.2014 - 15:10

fonte

3 risposte

Leggi altre domande sui tag bdd design test-automation functional-testing

Interfaccia a livello di classe o di funzione? Usare le classi parziali per supportare più versioni di entità di dati per scenari di consegna continua è una cattiva idea?

score 1 · Answer 1

Il BDD è essenzialmente una metodologia di sviluppo del software con l'obiettivo di guidare (o guidare) il codice da esempi di come viene utilizzato il sistema. Non ha nulla da dire sull'aspetto e sull'aspetto reale dell'interfaccia utente (che può essere considerato un semplice "controller" per la tua applicazione e potrebbe teoricamente essere facilmente scambiato con un'API REST, un browser-ui o altro attraverso che l'utente può interagire con l'applicazione). Pertanto, partendo dall'interfaccia utente potrebbe essere abbastanza fuorviante se si tenta di praticare BDD.

Pensa alla tua interfaccia utente come a un sottile strato che non contiene alcuna logica aziendale e si concentra invece sulla guida delle "viscere" dell'applicazione. Questa è la logica che descrivi nel passaggio (3) del tuo flusso di lavoro.

Ad esempio, immagina che si tratti di un'applicazione per lo shopping e il comportamento finale che vorresti guidare è l'acquisto di un prodotto. Ciò richiede di essere in grado di dare il comando di sistema per aggiungere un prodotto a un "paniere", essere in grado di pagare ecc. "Aggiungi il prodotto X al carrello" e "Paga per il mio carrello" sono i comandi che puoi dare al sistema Indipendentemente dell'interfaccia utente.

Anche se hai già specificato l'interfaccia utente, puoi / dovrebbe identificare i comandi dati al sistema. È essenziale concettualizzare il sistema in termini di logica aziendale in modo da non distrarsi dai dettagli su come funzionerà l'interfaccia utente (puoi pensarci più tardi).

Ciascuno di questi comandi che identifica diventa When nel tuo scenario Given/When/Then . L'azione che viene infine testata quando viene eseguita la suite.

Identifica le regole aziendali - queste ti aiuteranno a comprendere le precondizioni che devono essere soddisfatte per ciascun comando per ottenere il risultato atteso. Supponiamo che tu abbia una regola aziendale sui clienti che ricevono un tostapane gratuito su ogni forno a microonde quando è attiva una vendita:

Background:
  Given the price of a microwave oven is £100
  And the price of a toaster is £10

Scenario: Customers get free toaster if they buy a microwave 
  Given the winter sale starts on Sun 31st Dec at 9am
  When I buy a microwave oven on Sun 31st Dec at 9am
  Then my basket should contain the following line items
    | Product        | Price |
    | Microwave oven | £100  |
    | Toaster        | £0    |

Scenario: Customers do not get free toaster if they buy a microwave before sale
  Given the winter sale starts on Sun 31st Dec at 9am
  When I buy a microwave oven on Sun 31st Dec at 8am
  Then my basket should contain the following line items
    | Product        | Price |
    | Microwave oven | £100  |
    | Toaster        | £10   |

Da questi scenari è possibile iniziare a scrivere codice: nei passaggi specificati si impostano i prodotti con i relativi prezzi e la regola di vendita. Nel tuo When step esegui l'azione, chiamando il codice direttamente (sviluppo e feedback più rapido), chiamando un'API o automatizzando il browser effettivo (il feedback più lungo e lento) Nel tuo passo Then dichiari che il risultato è avvenuto come previsto: ciò potrebbe comportare l'ispezione del contenuto della persistenza dei dati e probabilmente della risposta dal sistema o dall'interfaccia utente.

Costruire l'applicazione in questo modo ti costringe a fare un sacco di ragionamenti in anticipo (la logica del business) ma la codifica è più semplice perché devi semplicemente passare gli scenari (che diventano test a questo punto). Il tuo codice è letteralmente guidato dagli scenari / esempi. / Quando passano ti puoi garantire che il sistema funzioni correttamente - vai e costruisci un'interfaccia che permetta ai clienti di fare quello che dicono gli scenari.

score 0 · Answer 2

Questa è una domanda ampia senza una risposta specifica - probabilmente ne hai inventata una da quando hai postato la domanda.

Potresti pensare a test di accettazione più BDD come sviluppo red-green per ogni livello del progetto. In un mondo puro, è possibile scrivere i test di accettazione di livello superiore prima usando BDD sapendo che la funzionalità non esiste e tutti i test falliranno. Quindi è possibile scrivere i test di stile BDD generali per ciascuno dei principali componenti o sottosistemi dell'applicazione. Man mano che si sviluppa ciascun sottosistema, si rendono più specifici i test BDD generali. Quindi utilizzerai lo sviluppo basato su test per creare i test per la logica del dietro le quinte e le funzioni private mentre li implementa.

Personalmente, ho scoperto che tutti i livelli di BDD sono utili in una certa misura, ma ci vuole un team disciplinato per farlo dall'inizio alla fine. Anche BDD potrebbe non essere appropriato per tutti i progetti, a seconda delle esigenze aziendali, dei tempi, del personale, del budget, all'infinito.

score 0 · Answer 3

Tendo a scrivere i test BDD come accettazione per gli endpoint del mio sistema WCF / MVC / WEBAPI .... poiché si tratta di storie che interessano l'azienda. Sto usando SpecFlow per creare file di caratteristiche e scenari di criteri di accettazione. Quindi, per quanto riguarda il mio test MVC, creerò un file Feature simile a

Feature: High School Manamgement 
    In order to manage a list of high schools
    As a coach 
    I want to be able to create, edit or delete a high school

@web
Scenario: Navigate to the high school home page
    Given I am logged in as ''
    When I navigate to the page '/HighSchool'
    Then I should see a table named 'HighSchoolGrid'
        And I should see the 'Create High School' button

@web
Scenario: Navigate to high school create page
    Given I am logged in as ''
    When I navigate to the page '/HighSchool/Create'
    Then I should see the fields
    | Field               |
    | Name                |
    | Type                |
    | PhoneNumber         |
    | Mascot              |
    | AddressLine1        |
    | AddressLine2        |
    | AddressCity         |
    | AddressState        |
    | AddressZipCode      |
    | AddressZipExtension |
        And the required fields should be marked required  
        | Required Field |
        | Name           |
        | AddressState   |
        And I should see the form submit button 'Create'
        And I should see the 'Cancel' button

@web
Scenario: Submit Empty Create Form
    Given I am logged in as ''
    And I have navigated to the page '/HighSchool/Create'
    When I submit the form
    Then I should see the required fields highlighted
        | Required Field |
        | Name           |
        | AddressState   |
        And I should see the error message ''

@web
Scenario: Submit Form Successful
    Given I am logged in as ''
        And I have navigated to the page '/HighSchool/Create'
        And I have filled out the form as follows
            | Name      | Type | PhoneNumber    | Mascot  | AddressLine1  | AddressLine2 | AddressCity | AddressState | AddressZipCode | AddressZipExtension |
            | xxxxxxxxx |      | (215) 555-1212 | XXXXXXX| 1 Main Street |              | XXXXXXXXX| PA           | 18964          |                     |
    When I submit the form
    Then I should be redirected to '/HighSchool'
        And  I should see the success message 'xxxxxxxxx has been added'

Quindi questi scenari sono i miei test di accettazione che sono test di integrazione che esercitano l'intero sistema. Ho creato il tag @web per generare un'istanza di web driver Selenium da eseguire attraverso il sito web. Ho anche creato un tag @api che fa girare un HttpClient che poi pubblicherà sull'endpoint WebApi.

Quindi, come il tuo attuale flusso di lavoro, utilizzo ui mock (s), ui-logic, ... per acquisire un test che un tester qa manuale o un business partner potrebbe eseguire. L'altra cosa bella è che ora ho i test di regressione automatici a questo se i miei requisiti cambiano quando eseguo la mia suite di test, ora dovrei vedere un errore per il requisito modificato. Posso creare un nuovo test BDD che acquisisca tale modifica in modo che qualsiasi regressione non riuscita possa essere valutata e rimossa se non è più un test valido. Questo può anche aiutarti a trovare i vari requisiti in competizione tra loro.

Questa è davvero l'estensione del vero test BDD / accettazione che faccio.

Ho anche dei test unitari che rispecchiano uno stile alquanto BDD in quanto sono espressi in una sintassi alquanto Gherkin. Comincio con questa classe di base delle Specifiche per i test che ho trovato da Jimmy Bogard su Los Techies.

public abstract class SpecificationBase
{
    [SetUp]
    public void SetUp()
    {
        Given();
        When();
    }

    protected virtual void Given() {}
    protected virtual void When() {}
}

public class ThenAttribute : TestAttribute {}

Quindi i miei test unitari seguono tutti uno schema standard. Vedi la mia risposta qui per un'implementazione di esempio di questa classe astratta. Trovo che questo mi dia una buona copertura sia per l'integrazione che per i test unitari.