Można użyć scenariusza Specflow z Visual Studio 2013 Load Test

Question

Planuję ponownie wykorzystać istniejące scenariusze Specflow (obecnie używa do akceptacji i automatycznego testu) dla testu obciążenia VS, aby uniknąć powielania i dodatkowej pracy. Specflow działa dobrze dla tych testów, ponieważ uruchamia je raz, ale w kontekście testu obciążenia, gdy wykonuje każdy scenariusz Specflow więcej niż jeden raz i równolegle działa na problemy i błędy, a przy większej liczbie użytkowników dostaje więcej

Te błędy może zawieść niektóre z testów, które na końcu powodują niepoprawny wynik testu, na przykład używając jednego scenariusza Specflow jako scenariusza testowego z testem obciążeniowym 20 użytkowników i okresu 2 minut może spowodować 50 błędów podobnych do poniższych. Tak więc wynik testu pokazuje, że określony scenariusz jest wykonywany 200 razy, gdy 150 przeszło i 50 nieudanych testów, a niepowodzenie spowodowane jest błędami Specflow. W kontekście testu obciążenia wynik ten jest całkowicie błędny i nieprawidłowy, ponieważ sam test ma problemy.

Komunikat o błędzie:

ScenarioTearDown threw exception. System.NullReferenceException: System.NullReferenceException: Object reference not set to an instance of an object. 
TechTalk.SpecFlow.Infrastructure.TestExecutionEngine.HandleBlockSwitch(ScenarioBlock block) 
TechTalk.SpecFlow.Infrastructure.TestExecutionEngine.ExecuteStep(StepInstance stepInstance) TechTalk.SpecFlow.Infrastructure.TestExecutionEngine.Step(StepDefinitionKeyword stepDefinitionKeyword, String keyword, String text, String multilineTextArg, Table tableArg) 
TechTalk.SpecFlow.TestRunner.Then(String text, String multilineTextArg, Table tableArg, String keyword) 

Po jakimś dochodzeniu wydaje Specflow nie może generować i uruchomić sam scenariusz równolegle, który spowodował ten konflikt i nie powiedzie się kilka testów, ale ja też mam pewne wątpliwości co do tego i dąży do sprawdzenia, czy istnieje jakiekolwiek obejście tego problemu lub jeśli czegoś brakuje i zastanawiam się, czy scenariusze Specflow mogą być w ogóle użyte do testu obciążenia?

Answer 1

Rozumiem, że chcę ponownie użyć twoich testów do testowania obciążenia (Nie powtarzaj się), jednak test obciążenia ma zupełnie inny cel niż testy akceptacyjne. Testy obciążenia powinny uwzględniać realistyczne scenariusze codziennego użytkowania i zwiększać liczbę użytkowników. Z tego powodu zachęcam Cię, aby testy obciążenia były niezależne od testów akceptacyjnych i automatycznych. Naprawdę testują różne rzeczy.

Testy obciążenia powinny testować wydajność aplikacji przy wysokim poziomie użycia dla scenariuszy każdego dnia, a testy akceptacyjne i automatyczne sprawdzają, czy aplikacja działa zgodnie ze specyfikacją.

Testowanie obciążenia to proces wprowadzania popytu na system lub urządzenie i pomiaru jego odpowiedzi. Testy obciążenia są przeprowadzane w celu określenia zachowania systemu zarówno w normalnych, jak i przewidywanych warunkach obciążenia szczytowego. Pomaga zidentyfikować maksymalną wydajność roboczą aplikacji, a także wszelkie wąskie gardła i określić, który element powoduje degradację.

Źródło: Wikipedia: Load testing

Test akceptacja formalny opis zachowania produktu oprogramowania, ogólnie wyrażone jako przykład lub scenariusza użytkowania. ... Dla wielu zespołów Agile testy akceptacyjne są główną formą specyfikacji funkcjonalnej; czasami jedyny formalny wyraz wymagań biznesowych. W innych przypadkach uzupełniają jedynie dokument specyfikacji wynikający z mniej konkretnej techniki lub formalizmu Agile, takich jak przypadki użycia lub więcej dokumentów narracyjnych.

Źródło: Agile Aliance: Acceptance Testing

Są różne rzeczy, więc testy, i ramy badań, powinny być różne, jak również. Naprawdę nie "powtarzasz się", zachowując oddzielny pakiet dla testów obciążenia.

Co z technicznego punktu widzenia, dlaczego to się nie udaje?SpecFlow, uruchamiany przy użyciu normalnego programu testowego Visual Studio, nie został zbudowany, aby równolegle wykonywać testy. Dostępne są równoległe serie testowe, ale większość z nich to płatne oprogramowanie.