반응형
블로그 이미지
개발자로서 현장에서 일하면서 새로 접하는 기술들이나 알게된 정보 등을 정리하기 위한 블로그입니다. 운 좋게 미국에서 큰 회사들의 프로젝트에서 컬설턴트로 일하고 있어서 새로운 기술들을 접할 기회가 많이 있습니다. 미국의 IT 프로젝트에서 사용되는 툴들에 대해 많은 분들과 정보를 공유하고 싶습니다.
솔웅

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

글 보관함

카테고리

Page Object Design Pattern

2014. 8. 1. 10:43 | Posted by 솔웅


반응형

테스트 케이스를 만들 때 사용되는 Page Object Design Pattern에 대해 알아 보겠습니다.


우선 개념 파악부터 하고 넘어가죠.




이제 예제를 보겠습니다.


public class Login {

        public void testLogin() {
                selenium.type("inputBox", "testUser");
                selenium.type("password", "my supersecret password");
                selenium.click("sign-in");
                selenium.waitForPageToLoad("PageWaitPeriod");
                Assert.assertTrue(selenium.isElementPresent("compose button"),
                                "Login was unsuccessful");
        }
}

이 코드의 두가지 문제점

1. 테스트 메소드와 AUTs locators (이 예제에서는 ID 들) 들 간의 어떤 구분이 없다. 두개가 하나의 메소드에 그냥 얽혀 있다. 만약에 AUT의 UI가 그 identifiers, layout을 바꾸거나 로그인 방법을 바꾼다면 이 테스트 소스코드도 반드시 바뀌어야 한다.
2. id-locator들은 여러 다른 테스트에서도 사용될 것이다. 로그인을 해야 하는 모든 테스에서 사용될 것이다.

이 예제 대신에 Page Object technique을 사용하면 아래와 같이 고칠 수 있다.

public class SignInPage {

        private Selenium selenium;

        public SignInPage(Selenium selenium) {
                this.selenium = selenium;
                if(!selenium.getTitle().equals("Sign in page")) {
                        throw new IllegalStateException("This is not sign in page, current page is: "
                                        +selenium.getLocation());
                }
        }

        public HomePage loginValidUser(String userName, String password) {
                selenium.type("usernamefield", userName);
                selenium.type("passwordfield", password);
                selenium.click("sign-in");
                selenium.waitForPageToLoad("waitPeriod");

                return new HomePage(selenium);
        }
}

그리고 홈페이지에 대한 page object는 아래와 같을 것이다.

public class HomePage {

        private Selenium selenium;

        public HomePage(Selenium selenium) {
                if (!selenium.getTitle().equals("Home Page of logged in user")) {
                        throw new IllegalStateException("This is not Home Page of logged in user, current page" +
                                        "is: " +selenium.getLocation());
                }
        }

        public HomePage manageProfile() {
                // Page encapsulation to manage profile functionality
                return new HomePage(selenium);
        }

        /*More methods offering the services represented by Home Page
        of Logged User. These methods in turn might return more Page Objects
        for example click on Compose mail button could return ComposeMail class object*/

}

이제 로그인 테스트에서는 이 두 page object들을 아래와 같이 사용하면 된다.

public class TestLogin {

        public void testLogin() {
                SignInPage signInPage = new SignInPage(selenium);
                HomePage homePage = signInPage.loginValidUser("userName", "password");
                Assert.assertTrue(selenium.isElementPresent("compose button"),
                                "Login was unsuccessful");
        }
}





이 page object를 디자인 하는 방법은 여러가지가 있을 수 있다. 하지만 지켜야할 기본적인 룰은 지켜야 한다.
page object에는 어떤 verification이나 assertion을 만들면 안된다. 이 부분은 테스트의 한 부분이다. 그러므로 테스트 코드 내에 그런 기능이 있어야 한다. 절대 page object 내에 그것을 만들면 안된다. page object에는 페이지의 representation이 포함될 것이다.

page object에 들어갈 verification이 하나 있는데 그것은 해당 페이지를 verify 하는 부분이다. 혹은 해당 페이지의 아주 중요한 element도 될 수 있는데 그것은 해당 페이지가 제대로 load 됐는지를 확인하기 위한 부분이다. 이 verification은 해당 page object가 초기화 될 때 수행되어야 한다. 위 예제에서는 SignInPage와 HomePage 생성자가 그 기능을 수행한다.

page object는 전체 페이지를 represent할 필요는 없다. Page Object Design Pattern은 페이지안의 components를 represent하기 위해 사용된다. 만약 AUT안의 페이지가 여러 component들을 가지고 있다면 각 component별로 별도의 page object를 가지고 있게 되면 좀 더 유지관리하기 편할 것이다.

테스팅에 사용되는 다른 Design Pattern들도 있다. 어떤 경우에는 page object들을 instant화 하기 위해 Page Factory 패턴을 사용하기도 한다.


Selenium Wiki 에서 정의된 Page Object를 보려면 여기로 가시면 됩니다.

https://code.google.com/p/selenium/wiki/PageObjects



반응형

Software Estimation Memo

2014. 7. 28. 21:07 | Posted by 솔웅


반응형

Software Estimation Memo

Size, Effort Cost, Schedule, Staffing

- Productivity (Size/Efforts)
- Defect Density (Defects/size)
- Effort = Size/Productivity
- Productivity
  : 비슷한 productivity Values 참조, 이전 프로젝트 참조
  : Organization productivity 참조 (PPB)
  : Industry Productivity Rate
- Product Size : Cost and Effort -> Schedule -> Risk Assessment
- KLOC : Kilo Lines of Code
- FP : Function Points
- WBS : Work Breakdown Structure
- Estimation Model
  : Dev FP ; Enh FP : KLOC (Technology Centric Development)
  : Large FP > 1500 Pday : DE Model (DE Point) -> WBS concept (Agile Project)
                           Development and Enhancement Projects
- MR (Micro) < 4Pds, Minor 4~15 ; Major > 15

Data Function
- EIF : External Interface Files - Application 에만 참고 되고 Maintained 되지는 않음
- ILF : Internal Logical Files - Application 에 의해 Maintained 되는 파일들

Transactional Functions
- EI : External Inputs - 1개 이상의 ILE Maintain 하기 위함
- EO : External Outputs - 사용자에게 정보를 주기 위한 것 (로직의 결과물)
- EQ : External Inquiries - 사용자에게 정보를 주기 위한 것 (데이터 수정 후 제공)

- VAF : Value Adjustment Factor
- GSCs : General System Characteristics

- Large FP
  : Sub Application 들이 있음
  : Sub System Level FP counting

- KLOC
  : Development Project with less Functional Scope
  : Reengineering. Migration Projects
  : Technology Centric Development

- DE Model
  : Development and Enhancements Projects (FP/KLOC or DE Size Unit)
    Home Grown WBS concepts



* Maintenance Estimation Models

- FTE (Full Time Equivalences) - Maintenance and Prod. Support Proposal/Projects
- CP (Maint Model) : Small Maintenance : Micro MPs, GUI based. Use Post Data
- MR GUI : GUI Based Maintenance Request, Minor and Major MRs
- MR NGUI : Non GUI Based Maintenance Request, Minor and Major MRs
- PPM : Micro MRs and Production Support

* Test Estimation Methods
- Testable items (Manual Testing Method) : TC
- Test Automation

- RET : Recorded Element Type
- DET : Data Element Type. A unique user recognizable, non-repeated field
- FTR : File Type Reference. A FTR is ILF maintained, and EIF referenced

- DFP = (FP + CFP) * VAI
  DFP : Development Project FP counting
  FP : Adjusted FP Count for functions available after installation
  CFP : Conversion Unadjusted FP counting
  VAF : Value Adjustment Factor

- EFP = [(ADD+(HGA+CFP) * VAFA] + (DEL * VAFB)
  EFP : Enhancement Project FP Count
  ADD : Adjusted FP of functions added
  CHGA : Adjusted FP of functions changed
  CFP : Conversion adjusted FP counting
  VAFA : VAF of application after completion of enhancement project
  DEL : Adjusted FP of functions deleted
  VAFB : VAF of application before commencement of enhancement project




- 14 General System Characteristics
  1. Data Communications
  2. Distributed Data Processing
  3. Performance
  4. Heavily Used Configuration
  5. Transaction Rate
  6. Online Data Entry
  7. End-User Efficiency
  8. Online Update
  9. Complex Processing
  10. Reusability
  11. Installation Ease
  12. Operational Ease 
  13. Multiple Sites
  14. Facilitate Change 

반응형


반응형

Automated Testing Advantages, Disadvantages and Guidelines


이 글은 Automated Testing에 대한 간략한 소개로 시작합니다. Automated Testing의 다른 방법들과 잇점 그리고 Automated teste들이 automation의 잇점을 충분히 활용하기 위해 반드시 따라야 하는 가이드 라인 등도 함께 소개 됩니다.



Advantages of Automated Testing



Introduction:



"Automated Testing"은 현재 사용하고 있는 manual testing 과정을 자동화 하는 겁니다. 이를 위해서는 먼저 현재 회사나 조직에서 사용하고 있는 manual testing process를 formalized 해야 겠죠. 


Automation은 manual 혹은 human involvement를 줄이고 기술이 필요로 하지 않은 반복적이거나 redundant 한 일들을 줄이기 위한 strategy, tool, artifact들이다.


최소한 아래의 프로세스들이 포함된다. :


- 예상되는 결과를 포함한 자세한 테스트 케이스. 이 테스트 케이스는 Business Functional Specification과 Design documentation을 바탕으로 개발 된다.

- standalone Test Environment. 테스트 케이스가 매번 반복될 때마다 어플리케이션에 수정되면서 적용될 수 있도록 하는 미리 정해진 constant 같은 것들이 restorable 될 수 있도록 하는 Test Database 같은 것들이 포함 되어야 한다.



아래와 같은 테스트 타입이 자도화 될 수 있습니다.


* Functional – 항상 예상대로 진행 되어야 하는 것들에 대한 테스트

* Regression – 어떤 시스템의 동작이 변경되지 말아야 되는 경우에 대한 테스트

* Exception or Negative – 시스템에 일부러 에러를 일으켜서 테스트 해야 되는 경우

* Stress – 어플리케이션이나 operational infrastructure 의 capacity 를 측정해야 될 경우* 

* Performance – 시스템의 퍼포먼스가 business projection, 요구조건과 관계된 온라인 트랜잭션 과 batch run들 모두에 대해 알맞게 이루어 지고 있음을 보여주어야 할 필요가 있을 때.

* Load – 시스템의 capacity와 performance가 하드웨어나 소프트웨어의 업그레이드가 필요할 정도로 노화되는 시점을 파악할 필요가 있을 때




Benefits of Automated Testing


* Reliable: 매번 실행될 때마다 정확하게 동일한 동작을 시행함으로서 human error를 줄일 수 있다.

* Repeatable: 같은 동작에 대해 반복 시행될 경우 소프트웨어가 어떻게 작동하는지 테스트 할 수 있음.

* Programmable: 어플리케이션의 알려지지 않은 부분을 알아내기 위한 정교한 테스트를 프로그램할 수 있음.

* Comprehensive: 어플리케이션의 여러 기능들을 한번에 테스트하는 test suite를 만들어 사용할 수 있음

* Reusable: 하나의 테스트 케이스를 여러 버전의 어플리케이션에 적용할 수 있다. (유저 인터페이스가 바뀐 경우에도 사용할 수 있다.)

* Better Quality Software: 적은 resource로 짧은 시간에 더 많은 테스트를 진행할 수 있다.

* Fast: Automated Tool은 사람이 하는 것보다 훨씬 빨리 일을 처리 할 수 있다.

* Cost Reduction: Regression을 위한 테스트 인원을 감원할 수 있다. 


해당 작업에 알맞는 tool을 고르는 것과 deploy를 위해 해당 조직의 제대로 된 적용 범위를 정함으로서 이러한 잇점을 최대화 할 수 있다. Automation 이 반드시 사용되어야 할 알맞는 적용 범위를 정하는 것이 중요하다.


아래의 분야들은 반드시 자동화 되어야 한다.


1. 중복적으로 진행되는 일이나 시나리오.

2. 단순하고 오래 걸리며 human error를 일으 킬 수 있는 반복적인 일

3. 잘 개발 되고 잘 구성되어진 use case나 시나리오 우선으로 자동화

4. 상대적으로 안정된 부분



Automated tester들은 자동화의 장점을 최대화 하기 위해 아래 가이드 라인을 따라야 한다.


• Concise: 최대한 간단하게

• Self-Checking: Test Report에 모든 결과가 있도록. 사람이 별도의 분석작업을 할 필요가 없도록

• Repeatable: 사람의 개입 없이 여러번 테스트가 진행될 수 있도록

• Robust: 테스트의 결과가 항상 같아야 함. 테스트가 외부적인 변화에 영향을 받지 않도록 해야 함

• Sufficient: Tests verify all the requirements of the software being tested. 해당 소프트웨어에 대한 요구조건을 모두 검증할 수 있어야 함

• Necessary: 각 테스트 마다 특정 테스트 사항들이 포함돼 있어야 한다.

• Clear: 모든 statement가 이해하기 쉬워야 한다.

• Efficient: 테스트 실행 시간이 적당해야 한다. (너무 길면 안된다.)

• Specific: 각 기능마다 failure point가 있어야 한다.  unit test failures provide "defect triangulation".

• Independent: 각 테스트는 임의의 suite 내에 있더라도 독립적으로도 실행 될 수 있어야 한다.

• Maintainable: 테스트는 쉽게 이해하고 수정하고 확장 될 수 있도록 만들어야 한다.

• Traceable: 요구사항의 시작과 끝과 같이 테스트의 시작과 끝을 추적할 수 있어야 한다.



Disadvantages of Automation Testing



자동화 테스트가 많은 장점을 가지고 있지만 단점도 있다. 아래에 그 단점들이 있다.


• 자동화 테스트 script를 작성할 수 있는 인원이 필요하다.

• 디버깅하는 것이 가장 이슈인 부분이다. 테스트 스크립트에 에러가 있는 경우 deadly consequences에 이르게 할 수 있다.

• playback method들인 경우 테스트를 유지관리 하는데 비용이 든다. GUI에 약간의 변화가 있어도 test script 는 수정되거나 다시 작성되어야 한다.

• 테스트 데이터를 관리하는 것이 어렵다. 


위의 단점들이 테스트 자동화로부터 얻을 수 있는 잇점에 손상을 가할 수 있다. 테스트 자동화에는 이렇게 장점과 단점이 있음에도 세계적으로 널리 적용되고 있다.




반응형


반응형



반응형

TDD Project Production Deployment 경험....

2014. 3. 17. 11:24 | Posted by 솔웅


반응형

지난주에 새로운 팀에 배치된 후 첫째주인 지난 토요일 Production Deployment 가 있었어.

우리 Automation Tester 들은 토요일 새벽 5시부터 대응해서 낮 12시까지 일했거든...


조금 전에 회사 이메일 보니까 그 이후에도 작업이 계속 되고 마지막으로 담당자가 Complete 됐다는 메일이 조금 전에 오고 (일요일 8:00PM)  대빵이 Great Deployment weekend everyone!! 이라는 단체메일을 보낸 걸로 봐서 바로 조금 전에 모든 일이 완료 됐나봐...


나는 당연히 이 팀에 온지 1주일도 안 됐으니 대응은 인도에 있는 offshore partner 가 했어..

걔 담주에 1주일간 휴가인데 휴가 들어가는 토요일 사무실에 출근해서 밤 늦게까지 일했어..

불쌍한 Versha... Anyway Have a great vacation.

그러니까 인도랑 시간차이를 계산하면 걔는 오후 3시부터 밤 10시까지 일한거네...

(우리는 새벽 5시부터 오후 12시까지 집에서 Online으로 대응했어..)


하여간 이번 Production Deployment를 Observe 하면서 많은걸 배운거 같애...

특히 Automation Test 의 필요성 같은거 말야...





Production에 Web Application이 Deploy 되면서 Automation Test 프로그램들도 같이 Deploy 돼...

Automation Test 는 Selenium Webdriver로 만들고 Jenkins 에서 관리가 되거든.

Production Server에 테스트들이 Deploy 되면 이 테스트들을 실행 시키고 그 결과가 Excel 파일로 정리가 되서 Automation Tester 들에게 전달 돼..

그러면 Tester 들은 fail 난 job들을 manual 테스트를 해서 Web Application에 defect가 있는 거면 ALM에 Defect 보고를 하고 Test Script에 문제가 있는 거면 그걸 분석해서 보고를 하지...


그러면 Developer들은 해당 defect를 보고 이걸 제대로 modify 해서 보완을 하고 다시 테스트를 돌려서 성공하는 걸 확인 하면 일은 끝....



물론 Production에 Deploy 되면 Developer 들은 Development Team 대로 테스트를 하고 Business Team 은 Business 팀대로 테스트를  하겠지..


거기에 Automation Test Team까지 추가되서 자동화 시킨 Test job들을 가지고 테스트 하는 부분이 추가 된거야..


4~5년전 한국에 있을 때만해도 TDD 프로젝트는 거의 없었던거 같은데.. Test 를 별도로 Tester 들이 진행하는 구조도 거의 없고 그냥 개발자나 현역(Business)들이 개발 후에 테스트 하고 넘어가는 식으로 일하는게 보통이었었어..

지금은 어떤지 모르지만 Test를 따로 Team을 만들어서 Automation 시킨다는 것에 대해 별로 필요하다고 생각하지도 않는 분위기였던거 같아...



그런데 여기 와서 제대로 TDD 프로젝트에 참여하고 Production Deployment 까지 경험하니까... 이 Automated Testing 의 중요성을 제대로 알 게 되더라구...


지금 나는 Test Server 환경에서 작업을 하고 있는데 이 작업이 끝나면 QA 환경으로 옮겨 져서 테스트가 진행이 될 거야..

그 다음에 Production으로 Deployment 되는거지...

이제 Production Deployment까지 경험했으니 조만간 QA 환경에서의 테스트는 어떤게 어떻게 진행이 될지 배우게 되겠지...


TDD Project를 제대로 배울 수 있는 좋은 기회인거 같애.. :)



반응형


반응형

지난 주부터 새로운 팀에 소속돼서 일하고 있습니다.

전임자 일을 이어 받아서 Sprint 1 을 무사히 마치고 어제부터 Sprint 2 가 시작됐습니다.

여기서는 15일 단위로 Sprint 를 나눠서 일을 진행하고 있습니다.


지금 일하고 있는 곳에서는 Agile business를 위해서 Rally Software를 사용하고 있습니다.

사용한지 며칠 안 됐지만 직관적이고 꽤 사용이 편리한 것 같더라구요.


Rally 전에는 HP에서 나온 ALM (Application Lifecycle Management)를 사용했는데.. 아마 Rally로 점차 이동하고 있나 봅니다.


지금은 ALM은 Manual Test 관리와 Defect 관리용으로만 사용하고 있고 주요 작업인 Automation testing 과 관련한 lifecycle 관리는 Rally에서 하고 있습니다.


저도 Rally에 대해 좀 더 알아보려고 Rally 홈페이지에 가 봤는데요.


그 홈페이지 중 about Rally 페이지에 있는 글을 소개해 드리겠습니다.





Your Agile Business Partner


In a world driven by software, we are convinced that Agile can help accelerate the pace of innovation so that companies create products users love.  At Rally, we are absolutely dedicated to making your entire company faster, leaner and more Agile. In fact, we think helping you be "on time and on budget" is a pretty low bar for success. We want you to consistently win product awards. We want to spike your net promoter score. We want you to be in control of your own destiny, because no matter how fast things change, you will have the speed and agility to create your next generation of growth.


소프트웨어로 운영되는 세상에서, 우리는 Agile 이 혁신의 속도를 더욱 가속시키는데 도움을 주고 회사는 이용자들의 사랑을 받는 제품을 창조할 수 있다고 확신합니다. Rally를 통해 우리는 여러분 회사 업무 전체를 훨씬 더 Agile 방법에 의해 훨씬 더 신속하게 처리될 수 있도록 도와 드립니다. 궁극적으로 저희들이 도와드리려고 하는 것은  "on time and on budget" 으로서 성공에 이르는 아주 기본적인 요소 입니다. 저희는 고객님들이 꾸준히 성공적인 사업을 이어나갈 수 있기를 바랍니다. 여러분의 실적 신장에 실질적인 도움을 드리고 싶습니다. 여러분의 목표를 향해 나아가는데 도움을 드리고 싶습니다. 모든것이 빨리 변해가는 세상에서 Rally는 여러분 회사가 한단계 더 도약할 수 있는 speed와 agility(민첩성)을 제공합니다.


Rally helps you go Agile.  And we really mean help.  We've never been only an award-winning software vendor whose cloud-based products and platform give companies what they need to steer corporate strategy, run their development lifecycle, and expand team collaboration. We keep going.


Rally는 여러분을 Agile로 가는 길을 도와 드립니다. 저희는 단지 cloud-based 제품에서 software vendor로서 수상한 경력만 가지고 있는 것이 아닙니다. 저희들은 고객님들의 전략적인 방향을 조타수의 역할을 하고 고객님들의 개발 lifecycle을 운영하고 팀들간 그리고 팀 내의 collaboration을 확장하는데 실질적인 도움을 드리고 있습니다. 저희들은 계속 이러한 도움을 드릴 것입니다.



We’re an Agile partner with a team of Agile coaches and comprehensive training services that help your teams and leaders navigate the organizational change required to become a great, innovative, Agile business. Forrester Research summed it up more modestly, saying, "Rally's leadership rests with its breadth and depth of capabilities for Agile teams, combined with a strong and focused corporate strategy."


저희는 Agile coach를 해주는 팀으로서 좋은 Agile 파트너 입니다. 그리고 여러분의 팀과 리더들을 도와 더 성장하고, 혁신적이고 Agile business에 맞도록 조직을 변화시킬 수 있는 포괄적인 training 서비스이기도 합니다. 회사의 strategy를 더 강화 집중시키는데 Rally가 함께 합니다.


We think holistically about all the collaboration it takes to get valuable ideas to market.  But a more traditional view of Rally comes from important industry analysts who describe us (in the nicest terms) as helping disrupt their technology categories of Application Lifecycle Management (ALM) and Project/Program Portfolio Management (PPM).  You can even read all about the evaluations Forrester Research did of Rally vs 9 ALM vendors and 10 PPM vendors, if you want, for free.


우리는 collaboration이 시장에 더 가치 있는 아이디어를 가져다 준다는 것에 대해 의미있게 생각합니다. 저희를 표현하는 주요 industry 분석가들은 ALM(Application Lifecycle Management) 와 PPM(Project/Program Portfolio Management) 라는 분야를 없애고 있는 제품이라고 평가하고 있습니다. Forrester Research 가 Rally 대 9개의 ALM vendor들과 10개의 PPM 벤더들을 평가한 글을 참고하시기 바랍니다.


OK. But what can your company really expect from choosing Rally as your Agile business partner?


자 그럼 여러분의 Agile business partner로서 Rally를 선택하시면 여러분 회사에 어떤 효과를 기대할 수 있을까요?


The best way to learn about Rally is to hear from our customers. We are proud to serve 192,000 users, including 34 of the Fortune 100 companies. You can check out some of our customers in these quotes and videos or attend one of our events when we visit a city near you.


Rally에 대해서 알 수 있는 가장 좋은 방법은 저희들의 고객들로부터 듣는 것입니다. 저희들은 Fortune 100 companies에 속해 있는 34개의 회사를 포함해서 총 192000 업체를 고객으로 모시고 있습니다. 링크를 클릭하시면 저희들의 고객님들의 평가와 비디오를 보실 수 있습니다. 또는 저희들이 여러분이 계시는 근처 도시에서 소개행사를 열 때 참석하실 수도 있습니다.


Why Go Agile?

Building a great, Agile business is not easy - though most find it's easier to produce great, innovative products when you use Agile practices. Put simply, Agile shortens development cycles. It minimizes all types of risks, roots out waste, and it ensures you are always working on the most important needs of the business. For the benchmarking set, an independent study by QSMA showed Rally customers had 50% faster time-to-market than their industry peers. These companies also measured a 25% increase in productivity and saw only 1/4 the expected defect counts.


Agile 방법을 사용하면 향상된 제품과 혁신적인 제품들을 더욱 쉽게 만들어 낼 수 있음에도 불구하고 Agile business는 그렇게 쉽지 않습니다. 간단하게 말해서 Agile은 development cycles를 단축시킵니다. 그리고 모든 종류의 risk들과 waste의 근본적인 원인들을 최소화 시킵니다. 그리고 항상 가장 중요한 business의 needs에 대해 일할 수 있도록 해 줍니다. QSMA의 연구 조사에 따르면 Rally 고객들은 다른 경쟁사들에 비해 50% faster time-to-market 효과를 가져왔습니다. 이 조사대상 Rally 고객사들은 25%의 생산성 향상과 1/4의 defect counts를 보이고 있습니다.


It's Your Move


If you're ready to adopt or expand your Agile and Lean efforts, Forrester made deciding whom to partner with pretty easy... here is their Agile vendor evaluation report. You can also contact us and talk to smart people about your efforts and how Rally's products and Agile services can make your life easier.


만약 여러분이 Agile을 받아들이시거나 더 확장하시려고 한다면 누가 그 파트너가 되어야 하는지 Forrester 가 도와 드릴 것입니다. 이 링크를 보시면 Agile vendor evaluation report 가 있습니다. 또한 저희들에게 직접 연락하셔도 됩니다. Rally와 Agile service가 얼마나 여러분의 생활을 쉽게 만들 수 있는지에 대해 말씀해 드리겠습니다.


If you're still learning about how Agile and Lean would fit in your company, then browse our famous educational materials. At a minimum, you'll probably get a lot out of tracking Rally's Agile Blogs led by our Founder/CTO Ryan Martens and Agile Fellow Jean Tabaka, with contributions from our Agile coaches, engineers, product owners; even our Agile marketing teams.


만약 여러분 회사에 어떻게 Agile과 Lean을 도입해서 사용할 수 있을가에 대해 더 알고 싶다면 저희들의 요명한 educational materials를 보시기를 바랍니다. 또한 Rally의 여러 Agile Blogs 들을 보시면 다양한 정보를 얻으실 수 있습니다. 저희의 Founder/CTO Ryan Martens와 Agile Fellow Jean Tabaka 가 lead 하고 많은 Agile coache들과 engineer 그리고 product owner들이 참여하고 있습니다. 저희 회사의 Agile marketing team도 참여하고 있습니다.


Oh, and we are always looking to add super-talented people to the Rally team. We keep growing and would love to meet you. Named as #8 on Fortune Magazine's Best Medium-Sized Workplaces list, and ranked as a Best Place to Work in the Nation by Outside Magazine four times, Rally offers a highly collaborative culture and work-life balance that attracts top talent.


그리고 저희 Rally team 에서는 언제나 능력있는 분들을 찾고 있습니다. 저희는 지속적으로 성장하는 회사이고 당신을 만나고 싶습니다. Fortune지의 Best Medium-Sized Workplace 리스트에서 8위를 차지했습니다. 그리고 외부 잡지에서 가장 일하고 싶은 곳에 4번이나 rank 됐었습니다. Rally는 훌륭한 인재들이 매력을 가질만한 highly collaborative culture와 work-life balance를 제공합니다.


반응형

'TDD Project > Rally' 카테고리의 다른 글

Manifesto for Agile Software Development  (0) 2022.04.29
[Rally] Create and Customize Fields  (0) 2016.02.03
Test Module in Rally  (0) 2016.01.13
[Agile] Sprint Retrospective  (0) 2014.08.27


반응형

Selenium WebDriver로 테스트를 작성하다 보면 웹화면 입력할 데이터를 Testsuit(XML) 에 정의하고 그것을 받아서 일을 처리하는 경우가 많습니다.


데이터량이 많을 경우에는 많은 파라미터를 사용해야 하는데 그러면 번거로우니까 특정 문자로 데이터들을 구분하고 그것을 JAVA 파일에서 분리해서 배열에 담아 사용하면 편리한데요.


<parameter name="teststring" value="Hong|Gildong|Seoul|34|Male"/>


Test Suite 에 위와 같이 돼 있는 경우 자바 파일에서는 아래와 같이 사용할 수 있습니다.


@Parameters({"teststring"})


우선 teststring 파라미터를 위와 같이 지정하고.


public void testSplitString(String msg) throws Exception {
        List<String> msgList=Arrays.asList(msg.split("\\|"));
        otherClass.methodInOtherClass(msgList);
    }


이렇게 코드가 작성됩니다.


그러면 "|" 문자를 기준으로 Hong, Gildong, Seoul, 34, Mail 이 분리되서 msgList 에 담기고 이 리스트를 다른 비지니스를 구현하는 클래스의 해당 메소드로 패스해서 일을 처리하게 됩니다.



Split 이라는 유명한 관광지가 있나 봅니다. 크로아티아에....


Java - String split() Method


Description:


이 메소드는 2개의 variant를 가지고 있고 주어진 regular expression에 따라 String을 split 합니다.


Syntax:


이 메소드의 신택스는 아래와 같습니다.


public String[] split(String regex, int limit)

or

public String[] split(String regex)

Parameters:


아래는 파라미터들에 대한 설명입니다.

  • regex -- 구분 기준이 되는 regular expression.

  • limit -- return 될 String의 갯수 (result threshold)


Return Value:

  • 주어진 regular expression에 따라 String을 split 한 다음에 array를 return 하게 됩니다.


Example:


import java.io.*;

public class Test{
   public static void main(String args[]){
      String Str = new String("Welcome-to-Tutorialspoint.com");

      System.out.println("Return Value :" );
      for (String retval: Str.split("-", 2)){
         System.out.println(retval);
      }
      System.out.println("");
      System.out.println("Return Value :" );
      for (String retval: Str.split("-", 3)){
         System.out.println(retval);
      }
      System.out.println("");
      System.out.println("Return Value :" );
      for (String retval: Str.split("-", 0)){
         System.out.println(retval);
      }
      System.out.println("");
      System.out.println("Return Value :" );
      for (String retval: Str.split("-")){
         System.out.println(retval);
      }
   }
}


이렇게 하면 아래와 같은 결과를 얻을 수 있습니다.


Return Value :
Welcome
to-Tutorialspoint.com

Return Value :
Welcome
to
Tutorialspoint.com

Return Value:
Welcome
to
Tutorialspoint.com

Return Value :
Welcome
to
Tutorialspoint.com



반응형

[JAVA] getInstance() 와 관련해서....

2014. 3. 11. 14:42 | Posted by 솔웅


반응형

우리 팀에서 관리하는 어플리케이션 중에 Oracle에서 Teradata로 데이터 migration 하는 작업을 도와주는 어플리케이션이 있습니다. 데이터를 옮기는 건 아니고 옮긴 후 두 데이터를 비교해 주는 어플리케이션 인데요.

사용자들이 두 데이터를 비교할 때 데이터를 trim 한 후에 비교해 달라고 하는 요청이 들어왔습니다.

제가 관리하는 어플리케이션은 아니지만 담당자가 어떻게 처리하나 유심히 봤거든요.

담당자는 singleton을 이용하더라구요.

해당 값들을 갖고 있는 custom 객체가 Singleton 패턴으로 선언 됐더라구요.

저는 custom 객체 선언 부분은 안 보고 로직 있는 부분에서만 찾으려고 하다가 헤맸는데 인도에 있는 담당자는 깔끔하게 처리했더라구요.

오늘 한가지 배웠습니다. ^^

customobject test = customobject.getInstance(value.toString().trim());

해당 object 에 getInstance 메소드가 있으면 Singleton 방식으로 객체를 관리 하는 것이고 안의 value를 관리하고 싶으면 이 getInstance를 사용해서 관리하면 됩니다.

하나 배운김에 Singleton 클래스에 대해 확실하게 배우고 가려고 누군가가 올려 놓은 tutorial 하나 보고 갑니다.



Java - How to use Singleton Class ?

Singleton은 객체 생성을 control 하기 위한 목적으로 사용됩니다. 객체의 갯수를 오직 하나로 제한하죠. 한개의 Singleton instance가 있으면 Singleton의 instance 필드들은 한개의 클래스에 한번만 발생하게 됩니다. static 필드와 비슷하죠. Singleton은 종종 데이터베이스 커넥션이나 socket 연결 등에 사용 됩니다.


예를 들어 데이터베이스에 한개의 connection만 가능할 때 JDBC로 multithreading을 하다 보면 문제가 발생할 수 있습니다. 이 Singleton은 한번에 한개의 connection혹은 한개의 thread 만 만들어 지도록 관리를 할 수 있습니다.



Implementing Singletons:

Example 1:


제일 쉽게 구현하는 방법은 private 생성자와 필드를 만들어서 result를 hold 하는 방법입니다. 그리고 static accessor method 를 getInstance() 같은 이름으로 만들어서 사용합니다.

private field는 static initializer block안에서 할당 될 수 있습니다. getInstance() 메소드는 반드시 public이어야 하고 여기서 해당 instance를 return 합니다.


// File Name: Singleton.java
public class Singleton {

   private static Singleton singleton = new Singleton( );
   
   /* A private Constructor prevents any other 
    * class from instantiating.
    */
   private Singleton(){ }
   
   /* Static 'instance' method */
   public static Singleton getInstance( ) {
      return singleton;
   }
   /* Other methods protected by singleton-ness */
   protected static void demoMethod( ) {
      System.out.println("demoMethod for singleton"); 
   }
}


아래에 singleton 객체를 생성할 main program file 이 있습니다.

// File Name: SingletonDemo.java
public class SingletonDemo {
   public static void main(String[] args) {
      Singleton tmp = Singleton.getInstance( );
      tmp.demoMethod( );
   }
}


그 결과는 아래와 같을 겁니다.

demoMethod for singleton







Example 2:

아래는 고전적인 Singleton 디자인 패턴입니다.

public class ClassicSingleton {

   private static ClassicSingleton instance = null;
   protected ClassicSingleton() {
      // Exists only to defeat instantiation.
   }
   public static ClassicSingleton getInstance() {
      if(instance == null) {
         instance = new ClassicSingleton();
      }
      return instance;
   }
}


ClassicSingleton 클래스는 singleton 인스턴스를 static reference로 관리 합니다. 그리고 그 reference를 static getInstance() 메소드에서 반환을 하죠.

여기의 ClassicSingleton 클래스는 singleton;을 생성하는데 lazy instantiation이라고 알려진 방법을 사용합니다. singleton 인스턴스는 getInstance()가 첫번째로 호출되기 전까지는 생성되지 않습니다. 이 방법은 singleton이 필요한 때에만 생성이 되도록 합니다.

반응형


반응형

요즘 Selenium WebDriver로 작업하는 웹 어플리케이션은 새로운 창을 아주 많이 열었다 닫았다 합니다.


그래서 테스트 케이스를 작성하다 보면 창을 옮겨 다녀야 되는 일이 많은데요.


브라우저들을 옮겨 다니는 방법을 확실하게 알아두기 위해서 구글링해서 몇개 소스를 분석해 보겠습니다.





//Store the current window handle
String winHandleBefore = driver.getWindowHandle();

//Perform the click operation that opens new window

//Switch to new window opened
for(String winHandle : driver.getWindowHandles()){
    driver.switchTo().window(winHandle);
}

// Perform the actions on new window

//Close the new window, if that window no more required
driver.close();

//Switch back to original browser (first window)

driver.switchTo().window(winHandleBefore);

//continue with original browser (first window)


이 소스가 가장 기본적인 소스인것 같습니다.

winHandleBefore 이라는 변수에 현재의 윈도우를 등록해 넣습니다.
그리고 for 문에서 현재 열려 있는 창들을 확인해서 switchTo를 합니다.

이러면 브라우저를 옮긴 겁니다.

다시 원래 브라우저로 돌아오려면 아까 parent 윈도우를 저장해 뒀던 변수로 다시 switchTo()를 해 주면 됩니다.

그런데 parent 윈도우가 있고 여기서 child 윈도우를 열었는데 이 child 윈도우에서 다시 또 child 윈도우를 여는 경우가 있습니다.


그러면 처음에 parent 윈도우를 변수에 담고 새창(2)을 엽니다.

그리고 새창(2)에서 다시 새창(3)을 열기 전에 새창(2)를 다른 변수에 담습니다.


그리고 원하는 창으로 다시 switchTo를 하면 되겠죠.

그런데 소스들을 찾다 보니까 좋은 코드가 있네요.


private void handleMultipleWindows(String windowTitle) {
            Set<String> windows = driver.getWindowHandles();

            for (String window : windows) {
                driver.switchTo().window(window);
                if (driver.getTitle().contains(windowTitle)) {
                    return;
                }
            }
  }


새창의 Title을 가지고 그 창으로 switchTo 하는 겁니다.


이러면 굳이 창을 변수에 담지 않아도 원하는 때에 원하는 창으로 간단하게 switchTo를 할 수 있겠네요.


내일 사무실에 가서 지금 일하고 있는 소스에 적용해 봐야 겠습니다.


String parentWindow= driver.getWindowHandle();
List<String> allWindows = driver.getWindowHandles(); for(String curWindow : allWindows){ driver.switchTo().window(curWindow); }
driver.close();
driver.switchTo().window(parentWindow);

이 소스도 아주 기본이 되는 소스네요.


오늘 좀 막혔던 부분을 내일 해결할 수 있을 것 같습니다.

반응형


반응형

오늘 일하다가 Selenium 으로 Double Click 을 구현해야 했습니다.


아래처럼 하면 됩니다.


Actions action = new Actions(WebDriverAction.getDriver());

action.doubleClick(element).perform();



근데 이게 잘 안 되더라구요.


HTML은 아래와 같은 형식이었거든요.


<SELECT style="FONT-FAMILY: Courier; FONT-SIZE: 10pt" ondblclick="runJavaScript('parameter')" size=8 name=select>
    <OPTION selected value="korea">
                South Korea      
    </OPTION>
</SELECT>


Select 메뉴 안에 있는 옵션을 더블 클릭하면 새로운 창이 떠오르도록 애플리케이션이 돼 있더라구요.



Select 메뉴라도 Dropdown 이 아니라 그냥 일반 Table 이나 div 처럼 화면에 다 표시 돼 있는 상황입니다.


여기에서 암만 위의 doubleClick 메소드를 사용해도 동작이 안 되더라구요.


한참 헤매다가 생각해 낸게 Double 클릭을 구현하지 말고 그냥 ondbclick 일 경우 실행되는 자바스크립트를 실행시키는 거 였습니다.


((JavascriptExecutor) WebDriverAction.getDriver()).executeScript("runJavaScript('parameter');");


이렇게 하면 됩니다.

퇴근하기 직전에 Debugging 하면서 한번 실행해 봤는데 새로운 창이 뜨더라구요.


내일 아침에 출근해서 전체 테스트 케이스를 실행해 봐야겠어요.


제대로 작동하길 바랍니다. ;;


Selenium Webdriver로 테스트 케이스를 구현할 때 제대로 동작하지 않는 event 가 있으면 이렇게 그냥 자바스크립트를 곧바로 실행시키는것도 좋은 방법인 것 같습니다.






반응형
이전 1 2 3 4 5 6 ··· 9 다음