What method would you use for testing a new version of a ClickOnce application (side by side with the current version) amongst multiple users? Are there any best practices (especially as the applications depend on different servers for the live/test versions of SQL / web services etc).
We use internal DNS to set up http://application.ourdomain.test sites to test web based applications. It's obvious from the address bar that you're logged into a test site and it's just a change to the connection string to force that deployment to connect to our test SQL server. Is there any way to approximate this?
For ClickOnce deployment testing, we set up a few virtual machines and have testers connect using remote desktop. The VM desktop backgrounds are an ugly color and say "TESTING" in big bold red letters.
Also, all of our applications display a warning message if the user is about to connect to anything but the production database.
I came across this link text this afternoon, which seems to offer a way of doing it - you have to use different certificates to sign the manifests. I vary the Suite Name in the Publish Options dialog to create different menus.
Related
Background: I'm working on developing client functionality for OpenLDAP and ActiveDirectory in java. Have used Unboundid LDAP SDK for the same. This setup will be used for pulling data from different clients.
I've setup a Windows server with AD instance running on it. As a next step, I want to test my functionality against this AD server. However, setting up all of the "corporate level" data sounds like a big task given that I'm not terribly familiar with all of the possible configurations/group permissions setup. I did find this option which looked ideal for my scenario but the download won't complete. Please suggest what's the best way to generate "real looking" corporate data for testing AD server.
http://ldapwiki.willeke.com/wiki/LDIF%20Generator.
I followed this to setup the data.
http://blogs.technet.com/b/askpfeplat/archive/2014/02/10/how-to-use-the-active-directory-performance-testing-tool-on-windows-server-2012.aspx
No issues faced on 2012 server.
I am testing one Desktop based client server application. I want to perform a Security test of that application.
Can anybody explain me which points i can consider while performing Security Test of the Desktop application?
Testing of desktop application is easier than web application as there are less users than web applications.
Followings are two important point that you need to keep in mind during security testing of desktop application
• Test user’s rights and roles-authorized person should allow to login
• Test security of data or information stored in application.
Security testing on Desktop application is not that much easy task, in market we can't find the proper free tools like web application tools
for java based desktop application use JavaSnoop tool and proxy tool
for .Net based desktop application use echo-mirage and proxy tools
the test cases are quite simple
1. System testing: verification of registries, files and logs
2. Static testing: de-compile the files and do code-review, Gendarme tool is perfect
- do memory dump analysis
3. Dynamic testing: verify the communication
i hope this will help you
I'm looking for a way to allow potential customers to try my application before they buy it.
The product is a windows forms application that requires an SQL Server database to operate.
Although I have a functional demo that the customer can install on their network, I want to make it easier for them by have them "play" with it at my environment.
I remember Microsoft had (has?) something similar. I was testing Visual Studio a few years ago in a virtual environment where I was connecting to a server at Microsoft.
They setup the environment this way so when a user logs off after using it rollback his actions. Or to explain it better: when a user logins it starts with a new, clean environment.
So any projects I've created testing Visual Studio were lost after I logged off.
Any suggestions?
Thanks.
Some solutions that come to mind:
Provide remote access
You could provide access to a running instance of your application via some sort of remote connection protocol, e.g. via RDP or via VNC.
For example, there is a Java VNC client which can run as a Java applet; you could put that on a webpage and have it connect to a VNC session you host on your servers.
Or use Windows Terminal Server, and allow connection via RDP.
Both solutions of course have the drawback that people need to open the appropriate ports, if they are behind a firewall. There might be ways around that, however (e.g. you can run VNC over HTTP).
VM image
A completely different solution: Provide a ready-to-run VM image (for VMWare, VirtualBox or similar) of your application, including server and everything. You would need a demo version of your app though, plus getting redistribution rights for all the proprietary components (Windows OS, SQL server) might get hairy.
Offer videos
Often people do not really need to actually use the app; they are mainly interested to see how it works. So maybe it is enough to host videos of the app in operation. That allows you to put in some advertising for your features, and lets you show the users what they might miss when testing on their own.
I have a scenario where I have to setup a test environment where I want to be able to tell my NAnt or other build tool to make an new IIS web application, put the latest bins in the newly created IIS web application, and post me an email where the new address and port where the new application are addressed, is this possible and how? which tool?
There are several ways to approach this:
Set up a continuous integration (CI) server on the test environment. This is a viable option if your test environment machine doesn't change often and it's a single machine.
Push the installation from your development machine using tools like PsExec
Combination of the two: you have a build CI server which pushes the installation to (multiple) test environments.
Of course, you also need a good build script which will set up the IIS application (NAnt offers tasks for this). Emailing to you can be done by CI server (CruiseControl.NET Email Publisher, Hudson...).
I suggest taking some time to read this excellent article series: Automation for the people: Deployment-automation patterns
Our CruiseControl .Net build server does exactly this as part of it's NAnt build-script process...
Once the code is retrieved from source control, it's all built/compiled in turn. Web projects are then handled slightly differently to normal .dlls, as they are deployed to a particular folder (either on the current machine or otherwise) where IIS (also set-up by the script) to serve the pages.
Admittedly, we're using Virtual Directories instead of creating and disposing of new website instances on the server, as otherwise we'd have to manage the port numbers for each website.
NAnt has the capabilities of doing all of this IIS work, as well as all of the email work too - I'd certainly recommend looking at this avenue of enquiry to solve your problem. Plus, you also get the continous integration aspect as a side-benefit in your case!
I'm in the process of providing a Web UI as an alternative to our current desktop UI for our C/S enterprise application.
When developing the client-side in our desktop version, UI developers could connect to any server so they only needed the client-side environment.
When developing a Web UI (Client-side JavaScript in the browser), we are bound by the browser's "Same origin policy" so the UI must talk to the same server from which the UI code is downloaded.
As far as I see it till now, the development scenario for the UI guys is:
Developer installs server on local
machine and runs it.
Developer edits the HTML+JS+CSS files on local installation.
Developer has to reinstall/update server on local machine each time there's a need to test UI code against new server behaviour.
This does not seem too comfortable, at least compared to our previous C/S style development.
Are there any other ways you can suggest to that will not require UI developers from installing and updating server side components on their development machine ?
Or anything else related that can simplify the development process ?
Thanks :-)
Editing in some clarifications:
I'm mostly interested in the aspects of UI coding, not UI design.
I need a lot of server interaction - getting data from RESTful web services, which are developed in parrallel - hence the need to have an up-to-date server
You haven't specified the development platform.
As far as pure HTML/JS/CSS is concerned, you don't need a server. The UI developer can fine tune UI components locally.
The moment you want to talk/integrate to Server (via AJAX, JSP, ASP...) then you need to connect a development server as now your changes have to be served by Server.
Most of UI fine tuning can also be done from Firebug
In our office when changes to styling are required we save the page as a local copy and send it to the UI designer, he makes his changes and we integrate them. So the UI designer don't have to maintain a development environment.
JSONP lets you work around the same-origin problem (with server support) -- check it out! If the front-end-in-the-browser developers are using a good framework suc as jQuery or (my favorite) Dojo, JSONP should be no harder for them than plain JSON.
Develop on a shared server, but depending on the size of the team.. that's challeging with respect to version control.
Or deploy automatically generated virtual machines with nightly builds, so the devs don't have to install, but always use a recent version.
In the case of UI developers depending on a common REST server, the UI development can be done on the local machine and the REST service should be on a central server. When changes are made to the REST service these should be deployed to the central server (when stable), so all developers can use the newest version (this also helps with testdata).
You could try using a proxy on the developer's machine where some paths redirect to the server and some paths redirect to local folders.
Hmm, I actually didn't really get any information on what kind of technology you're using. If - with UI Developers - you mean designers, which have to take care about the CSS, layout etc, then we do it the same as lud0h said. We (developers) send the UI designers a copy of the server-side produced HTML pages. They then edit the HTML pages according to accessibility guidelines, CSS and layout and send us back the outcome of their work. We use their HTML pages then for integrating them in our web applications.
If you don't just mean tuning CSS, but also to write JavaScript / Ajax functionality you HAVE to use a server with which you're communicating. As you said, normally this is done by having a local environment which is similar to the server-one. In .Net Visual Studio '08 provides an internal webserver, alternatively you have to install IIS locally. In Java environments you have to install Tomcat and related technologies. In my eyes this is a must. What you have to have is
Versioning system (CVS, SVN,...) where developers commit regularly (minutes/hours)
local environments where developers checkout the source from the repository and develop
Test server where you deploy on a daily basis (could be like daily builds) in order to test your running product
I guess this should be what a professional development environment should consist of. The difference to C/S application development is that web UI and web-client code are not that separable as a Client UI in C/S environment from the server-side. Unless you develop with technologies like GWT or Silverlight which are quite similar to C/S, just running inside the browser, but communicating over RPC calls or web services.
//Edit:
What I nearly forgot. Don't do something like developing on the server directly, meaning that all of the developers access the server's filesystem where the code, UI etc. lies!!
You can use CORS. a new technique just like Ajax, but with ability to make calls on other domains. so you will need only one UI on one server. think this can help you.