Does anyone know of any tools out there that will let me run and debug a VXML application visually? There are a ton of VXML development tools, but they all require you to build your application within them.
I have an existing application that uses JSPs to generate VXML, and I'm looking for a way to navigate through and debug the rendered VXML in much the same way that Firebug allows one to do this with HTML. I have some proxy-like tools that let me inspect the rendered code as it is sent to the VXML browser, but there's a ton of JS, which makes traversing the code by hand rather difficult.
Has anyone worked with a product that allows for this?
Thanks!
IVR Avenger
There is JigSaw Test suite - has free trial license and reasonably priced.
There is IBM's debugger - part of WebSphere Voice Toolkit.
Many other products have debuggers - a very good summary is here
Disclaimer: I am the development manager for Voiyager (www.voiyager.com), a VoiceXML testing tool. It doesn't meet your criteria nor do I believe it is the type of tool you want, but I thought it was worth mentioning it.
As far as I know, there isn't such a test tool for VoiceXML. In fact there are very few VoiceXML tools on the market and hardly any of them test or analysis. The vendors that created development tools, have all been acquired by other companies. Some of them offered did offer various forms of debugging that were specific to their tool set or stayed at the Dialog (caller input) level. From your question, I'm assuming you need much lower level debugging capabilities.
I think the alternative paths are minimal and somewhat difficult. I believe your primary goal is to debug or rewrite an existing application, but you haven't provided any specific challenges beyond the JavaScript. Some thoughts or approaches that may help:
Isolate the JavaScript and place the code into a unit test harness. That will go a long way to understanding the logic of the application. Any encapsulation of the JavaScript you perform will probably go a long way towards better code maintainability.
Attempt to run the VoiceXML through a translation layer to HTML so you could use FireBug. The largest challenge would involve caller input (ie processing the SRGS grammars). You could probably cheat this by just having the form accept a JSON string the populates the field values. There are tools on the market to test grammars. Depending on the nature of your problems, you could take a simple and light approach and attempt this over just the trouble areas.
Plumb the application with a lot of logging. This can be done through the VoiceXML LOG element, or push the variable space back to the server. By adding intermediate forms, you may be able to provide a dump from each via the VoiceXML Data element.
See if your application will run in one of the open source VoiceXML browsers (not sure of the state of the open source browsers as we've built and bought for our various product lines). If you can get it mostly working, you can use the development debugger to provide some ability to step through the logic. However, it is probably one of the more difficult paths as you'll really need to understand the browser to know when and where to stick your breakpoints and to figure out how to expose the data you want.
Good luck on the challenge. If you find another approach, I would be interested in seeing it posted.
An alternative debug env is to use something like Asterisk with a voicexml browser plugin like the one from http://www.voiceglue.org/ or for a limited licence, i6net.
You can keep all the pieces separate(dynamic html and vxml application in php/jsp/j2ee/, tts processing, and optional asr processing as separate virtual machines with something like virtualbox. If the logic can be kept the same, then it is just a matter of changing the UI based on the channel.
A softphone is all you need to call a minimal asterisk machine, which has the voicexml browser with the url of the vxml in the call plan.
I just used Zend Framework as php is used in this environment, and changed view suffixes(phtml vs vxml) based on the user-agent string.
Flite for tts is fine for debugging, and when your app is ready you can either record phrases, and there was a page on the ubuntu forums with directions for how to increase flite quality with some additional sound files.
Do you have tried Eclipse VTP or InVision Studio?
Eclipse VTP
This is Eclipse plugin. But I feel that it is user-unfriendly a little (of Japanese viewpoint).
InVision Studio *Required create user account*
This is Convergys's IVR tool. It has to edit standard VXML mode. (Unfortunately, It's not exact matching.)
For just debugging vxml, I use Nuance Cafe's VoiceXML checker. It doesn't give you a visual tree or anything, but it's pretty good at spotting syntax errors and is free. I think they might also have more advanced debugging tools if you look into it, but I haven't had the need. (Note: I have no association with them)
http://cafe.bevocal.com/tools/vxmlchecker/vxmlchecker.jsp
I'm looking for the same problem that most of the links are down. I found a document where they propose an open source solution, which works as a plugin for Asterisk (https://www.researchgate.net/publication/228873959_Open_Source_VoiceXML_Interpreter_over_Asterisk_for_Use_in_IVR_Applications) and is available at https://sourceforge.net/projects/voxy/
I would like to know if there are current options to create a VXML structure graphically, like the next image.
Related
Background
I'm at the planning stages of a DIY project that'll help me automate some hardware at my house. It's probably also worthwhile to mention that I've got almost no experience with web-related development.
The Basics
http://img7.imageshack.us/img7/4706/drawingo.png -- I can't seem to embed the diagram.
In order to simplify management, I want to implement my UI in the browser.
The meat of my application will reside inside a Windows service or Linux daemon; this does not mean, however, that I'm after a cross-platform solution -- I'm not tied to any particular platform, so I'll pick one (probably based on the responses that I get) and stick with it.
I would prefer to use "free" tools (e.g., LAMP/WAMP), but it's not a deal breaker.
It would be nice to be able to communicate back to the user that some action is in progress (I think AJAX would be one way to go?)
Questions
The only thing that's not entirely clear to me is the implementation of step № 3. I'd like to hear possible implementation ideas (on Windows or Linux) as to how this should be done. Hopefully some of you can share how this sort of thing is done in the real world.
Miscellaneous
As always, if there's a problem with my thinking, please point it out!
There are many people better qualified to help with step 3 so I'll leave that to them.
My question is whether is you are looking forward to learning the mess of web technologies required for the front end or consider it a necessary evil on the way to what you really want to accomplish? If the latter (and assuming you are working in C/C++) consider taking a look at WT. It's a toolkit that makes the developing the web interface seem more like a desktop gui while handling much of the ugliness for you. It could potentially cut a lot of time off your development.
We are developing an ASP.NET application. We retained an outside UI design firm, and for the most part have been very pleased with their work. Their "deliverable" to us was clickable screens -- Visual Studio solutions with ASPX files, images, master pages, etc. The screens were not connected to any data source. They had dummy data so that we could see how the UI worked.
One problem we've run into is that our developers are used to using Visual Studio design mode. The pages we receive from the UI firm have problems sometimes when we pull them up into design mode. The consultant's developers coded these screens without using design mode.
We assumed they'd be using design mode, but this wasn't specified in the contract. Was this too much to assume? Is there a lot of ASP.NET development work that never goes through VS design mode?
Third party edit:
Suggestion: people responding to this question should specify which
version of Visual Studio they're
using, as Microsoft trashed the code
base that was in the VS2005 and
earlier designers, and replaced it
with the one they purchased when they
purchased the Expression products. The
two are totally unrelated, and the new
one is far better. - John
Saunders
The more and more you work with Visual Studio, the less and less you rely on Design Mode. Complicated UIs tend to make the design view look atrocious.
I (and peers) never use Design Mode, for two reasons:
I learnt in VS 2003 not to touch Design Mode because your HTML was managled by VS. (Not anymore though since 2008, but once bitten ...)
It can take ages to render.
Much quicker to drag-drop from toolbox and hand-code.
I actually find that ASP.NET developers that do use the designer to be quite rare. The Visual Studio designer is notoriously bad at generating clean markup.
I never use design mode, probably because it used to mess my markup so much. Plus I do a lot of dynamic rendering, so there is no point. And I use exclusively CSS for formatting, I don't want VS messing around.
Many never use it, because of bad past experiences. I have found little trouble with Design mode in VS2008, when using modern controls, which are up to date and have good designer support.
On the other hand, because of the earlier problems, a lot of custom server controls do not have good designer support, so are much less useful in design mode now that the earlier designer code base has been replaced with a good one.
I almost never use design mode. It typically creates ugly HTML, and call me anal, but I really like to have clean HTML. If that means hand-coding it, so be it.
I prefer doing it manually, I like to have control.
If I want to look at the result, F5.
I almost never use design mode. For me, the biggest reason is because I learned web design/development in Notepad, so I was used to (and comfortable) working with code. Design mode makes me uncomfortable because I'm never sure exactly what decisions VS will make with regard to HTML, etc. Additionally, I can't imagine that a developer would learn nearly as much about ASP.NET and VB/C# using design mode.
The only time I use design mode is to automatically configure a GridView or something like that like.
Design Mode is taking quite a beating here, but let me point out that it is great for learning about new controls. When you are new to ASP.NET, or are using a new library of controls, Design Mode is a godsend for two reasons:
You can modify properties on the Property Editor and see them reflected immediately. This is particularly true for list-container type controls, where the entire layout may depend on one property. Running your application five times to see all five layouts is very tedious.
Controls with complex behavior (and lets face it, thats why you're using a control, right?) often have a lot of configuration built into their Smart Tags. Notice the little [>] arrow in the top right of the control? Click it. It'll probably help you out big time. This is particularly true for configuring DataSources, whose syntax is very meticulous.
When I was first learning to use Telerik controls, I relied heavily on the Smart Tags they provide, which are very robust and complete. From that, you can see what kind of ASPX markup is generated and learn to work outside of Design Mode. I am a learn-by-doing kind of guy, so I much prefer this approach to looking at the documentation when using something for the first time.
I'm using VS2008, and I never use the design view. I find the code view to just be easier and more responsive than the designer.
Y'know, I never even realised I use the source screens 100% of the time. I usually develop in VS2005.
Whenever I do actually open the design mode, it's by accident, and I try and hit the source view before it renders. I've never been impressed with the design mode, and find it slow as well as adding a lot of unnecessary markup. I also find that intellisense and the properties window mean that I don't need a GUI to develop.
The design mode can also be a nightmare when you're trying to add any nested items. Because we've been developing for a customer using IE6 we've been using tables for formatting so we don't need different DIV definitions. Just clicking in an empty cell can be difficult, and resizing a column can take far too long.
For things like Template Fields in grids, I don't even know how I'd go about setting this up in design view!
Having said that, design mode every time for windows apps!
Design mode is getting better and I'd say that it's likely to become more prevalent as time goes on and the design mode tools continue to improve. I design all my components for design mode, but I still do the large majority of my code by hand - it allows greater control of code layout and doesn't end up creating an auto-formatted mess that I then have to dig through to figure out what changes need making. I know that in future my components are likely going to be used by developers that do most of their design by drag/drop and it's easier to cater for that now than have to come back and do it after the event.
Granted I'm doing MVC stuff, but I never use it - I "grew up" with PHP and code editors, and it still does me just fine.
I'm using two different versions of .NET (2003 & 2005). Some of the forms that were written in 2003 can no longer be edited in 2003 and the installation requires that they be maintained in 2003, so I use KEDIT to edit those forms.
Some of the forms in one application are too big for the .NET editor and I prefer a strong editor anyway.
I have no problem working in design mode. One exception is asp:Repeaters, which are not supported, or GridViews which tend to override my manual column definitions.
The other is if VS tries to do a full project scan if I rename a control, and then fails.
We primarily use the code view. The design mode is quite buggy we've found in VS 2008. XML controls tend to barf random character sets out for some reason, and VS will generally run slow whilst trying to render everything on screen. I mainly use the code-view.
Traditionally WYSIWYG designers produced poor code and render CSS and #INCLUDEd files poorly so they were of limited use, so developers tended to code by hand. In addition, these tools allowed you to go a certain distance without real knowledge of what you were doing, which was fine for web tutorials and personal homepages, but as soon as you wanted an extra degree of control you became unstuck - when meant you had to resort to looking 'under the hood' anyway.
Although tools have improved over time, many developers are so comfortable with hand-coding that they all but forget about the Design View - I certainly can't remember last time I used it. I'm sure there are a number of situations where such tools could be genuinely useful, but we are doing fine without and don't want to be bothered with figuring when & where such features can best be used.
Our UI is complicated and it is impossible for us to use design mode with VS2005.
The only time I have touched design mode is to do a quick and dirty prototype or an internal app.
How often do I not use design mode? 99% of the time.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
What are the good automated web UI testing tools?
I want to be able to use it in the .Net world - but it doesn't have to written in .net.
Features such as a record mode, integration into build process\ continuous integration would be nice.
Im going to look at:
Watir
Selenium
Are there any others I should look at?
I definitively recommend Selenium, you can use it from .NET, supports different browsers, works in automatic builds and CI processes (we use it from CCNet). The code is stable. It has a few quirks, but after all they all do.
Whichever tool you choose, I recommend making your own test facade class(es) around it. The facade should be designed to suite your concrete testing needs, without exposing too much the details of the testing tool's API. This will make the test code easier to write and maintain.
UPDATE: if you use ASP.NET view state in your app, you could have problems using a pure HTTP test tool. This is where browser-controllers (like Selenium) are much better.
WatiN
Automates FF and IE
[Test]
public void SearchForWatiNOnGoogle()
{
using (IE ie = new IE("http://www.google.com"))
{
ie.TextField(Find.ByName("q")).TypeText("WatiN");
ie.Button(Find.ByName("btnG")).Click();
Assert.IsTrue(ie.ContainsText("WatiN"));
}
}
http://watin.sourceforge.net/
Watin is pretty unstable to use it in serious projects. It often fails with unexpected reasons like "EI is busy" or something like "Error with COM object".
Selenium is much more stable and it already has a lot of supporting tools. For example Selenium GRID is a solution which allows significantly decrease run time of tests. (Our smoke tests on Watin takes 6 hours to run).
Currently in my job i use QTP and it so far atleast can handle pretty much anything we throw at it both on the UI and it has a special mode for testing non gui services allowing us to check both and help us narrow down where some problems occur when we change the system. It is in my opinion very configurable and the inclusion of vbscript as its language allows integration with lots and lots of things on windows to allow you to do pretty much anything you want! For instance we use it to control the excel com object to make custom excel reports of success and failure so the format of the results is the same wether a test was run manually and also on another project used the adodb object to check that when a page submits information to the database that the database contains the correct data for that record!
As for integration into the build process i have not tried this myself but it is possible to launch qtp and a test from a vbs file so i would assume this should be fairly trvial as ms tools tend to allow you to run vbs files pretty easily from most tools.
I would reccomend it to anyone assuming you can get someone to buy the license!
You can also try VSTT - http://blogs.msdn.com/b/slumley/archive/2009/05/28/vsts-2010-feature-enhancements-for-web-test-playback-ui.aspx
Telerik Test Tools - http://www.telerik.com/automated-testing-tools.aspx
Visual Studio UI Test Extensibility–Scenarios & Guiding Principles - http://blogs.msdn.com/b/mathew_aniyan/archive/2011/03/28/visual-studio-ui-test-extensibility-scenarios-amp-guiding-principles.aspx
VSTS Web Test Step-by-Step Primer - http://blogs.msdn.com/b/jimmymay/archive/2009/02/23/vsts-web-test-step-by-step-primer-7-minute-video-by-microsoft-a-c-e-performance-engineer-chris-lundquist-with-copious-notes-screen-shots-from-your-humble-correspondent.aspx
you might also be interested in taking a look at what the ASP.NET team cooked up itself: Lightweight Test Automation Framework.
There's also a dedicated forum for it.
Having used several different automated testing solutions (TestComplete, QTP, etc), I have to put a vote in for Telerik + Visual Studio. Telerik has great support forums, and is very compatible with whatever testing framework you come up with. Our Devs put unique IDs into their HTML code so that our scripts don't need to be rewritten even with pretty drastic UI refactors. It's definitely more challenging than record and playback, but once you have your unique IDs in place, the automation code requires little or no maintenance.
Try httpunit
Depend on what you would like to achieve.
You can use web test built in the Visual Studio Tester Edition. It's quite good and easy to automate. You can use external data as a test data source and it integrates nicely with VS.
There is also test tool by Automated QA (forgot the name) which looks good but expensive.
And there is Selenium. That's the one we are using in Symantec. The biggest advantage is that it actually uses a browser you want to test. VS mimic a browser by changing http request parameters only so you may not be able to test your site for cross-browser compatibility. Selenium on the other hand uses browser and automates it so you can actually test your site in IE, Firefox etc. It can be also integrated with VS unit tests so you can see test results in VS.
So I would recommend Selenium or VS.
I've used Selenium. The features were good, and it was usable but it was buggy.
The IDE would often record events incorrectly (so tests would need to be manually changed), and test files occasionally became completely unusable for no apparent reason, which meant they would have to be recreated all over again. Also development on Selenium IDE seems to have stopped; there hasn't been any bug fixes and patches for a while, and bug reports seem to go unnoticed.
Molybdenum is an alternative, built on Selenium that's worth looking into.
http://www.molyb.org/
Just to throw out another option (of which I haven't tried but I do like Telerik) is Telerik's new WebUI Testing Studio. I will also echo Selenium up votes.
I forget one nice tools and can find link on it but find this ... http://weblogs.asp.net/bsimser/archive/2008/02/21/automated-ui-testing-with-project-white.aspx maybe can help.
If you are looking for simple, cross-browser tool with record and playback, multithreaded playback, intergration with build processes, powerful scripting, good reporting and excellent support, go for Sahi. It will be much easier for your testers/devs to learn and maintain.
you might want to take in consideration near Selenium also Rational Functional Tester ! whether you are familiar with coding in .Net or Java and want to just play around with record & replay or want to create more sophisticated programmatic testing I would recommend it.
WebDriver is another possibility: http://code.google.com/p/webdriver
They are working on a .NET wrapper that may be interesting for you.
Try QEngine. It has all the features of QTP.
You may want to look at RIATest for cross-platform cross-browser testing of web applications.
It works on Windows and Mac, supported browsers are Firefox, IE and Chrome. Automated testing scripts written on one platform/browser can be run against all other supported platforms/browsers.
It has the features that you want: user interaction recording mode and integration with CI servers (outputs results in JUnit format which can be consumed by CI servers such as Hudson).
(Disclaimer: I am a RIATest team member).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
This question isn't about unit-testing. And it is for a desktop product.
This is about testing of the gui and testing that the right stuff is input in the right text box at the right time.
A company I used to work at used WinRunner (different department so I don't know much more that that), but that has now been shutdown by HP but they don't seem that bothered whether you stay with HP or go elsewhere. You can't read about the product until you've signed up which is annoying.
The tool has to work with MFC (non-negotiable) and the ideal tool will also...
be automated.
be scriptable.
work with different screen resolutions automatically.
be able to 'spy' on individual static text boxes, etc.
intuitive enough so non-programmers can create the scripts.
have reporting tools, including email of individual users.
What do other SO users do for automated GUI testing?
We use the SAFS framework for Rational Robot (RRAFS). There are also SAFS implementations for WinRunner (WRAFS) and it looks like they have a new "Image-Based Testing" implementation, which I'm not familiar with.
This framework does a nice job of seperating the UI implementation from the test scripts. I've tested four releases of a web application developed by two different teams (one team using classic ASP, one using ASP.NET) and I only had to change the application map of my UI objects, the tests themselves didn't need to change.
That said, the language of the framework is cumbersome and takes getting used to. It's not very robust, in terms of language constructs, but with some effort you can do anything you need to. It's sort of like "programming" in Windows Batch language, but for tests ;)
To address your individual requirements above:
1) The tool has to work with MFC (non-negotiable).
The SAFS framework uses a 3rd party "record-playback" tool to drive the tests, like Rational Robot or Mercury WinRunner. If that tool can interact with MFC apps, then the framework can. I don't know how the "Image-Based Testing" implementation drives the tests, but I'd guess it can also work with MFC.
2) be automated.
The SAFS framework integrates with the STAF framework, which will allow you to automate the execution of your tests. I have a proof-of-concept test that uses STAF to start a VM image from a pool of images, install the application under test, run the RRAFS test, and put the results on a web server for others to get at.
3) be scriptable.
Yes, but as mentioned, it's not the most robust programming language. I wrote an Excel add-in that our testers use to write their tests that simplifies things a little bit.
4) work with different screen resolutions automatically.
Yes, since it's looking "under the covers" at the UI objects and not the screen. Except for maybe the "Image-based Testing" option...
5) be able to 'spy' on individual static text boxes, etc.
Yes, you can wait for a UI object to appear, disapper, to have a value, for a value to be changed, etc.
6) intuitive enough so non-programmers can create the scripts.
With some training. We've had limited success. Some QA folks can write the tests, some struggle.
7) have reporting tools, including email of individual users.
Yes, using the STAF framework you can post results to a web server, send out emails, etc.
Lots of good answers here, but I wanted to address this goal statement, specifically:
intuitive enough so non-programmers
can create the scripts
I can understand why you'd want this, but it's a lot harder than you might think. While you can find any number of tools out there that'll claim to make writing scripts easy, in practice, you're going to need at least some people on your automation team who understand programming. Writing scripts that are reasonably robust is going to involve one or more of looping, if/then/else, and subroutine calls. Not the kind of thing that non-programmers are going to find intuitive.
Be especially wary of the idea that you can "record" a person using a tool, then play it back for testing. That sort of "automation" is often so brittle that you'll end up modifying or re-recording the script for nearly every change in the software.
Coming from a strong Mercury/HP background, I would highly recommend using QuickTest Professional for your GUI testing. It has a lot of the same functionality as WinRunner, but without a lot of code. Simple GUI checks can be done through the QTP interface with minimal, if any, custom VB code. Checks for text next to boxes can be done with simple compares using the datasheet in QTP.
If you are used to WinRunner, and know VBScript (not so much TSL), then I would definantly look at QTP.
As far as your other requirements, QTP also has the Spy feature, like WinRunner, that will list all properties and actions you can perform on objects. And as for simplicity of use, at my old job, we would have business or system testers create simple smoke scripts, then I would take them and code them for more in-depth testing (multiple data values, error checking, etc). And as for reporting, QTP will do simple reporting of pass/fail/warning on tags that you put in, along with custom data you can input. So you could use a case statement to populate your output values based on your results. It won't do e-mail naitevly, but if you integrate with TestDirector/QualityCenter, you can setup through there, along with automating the kick-off of your scripts, and parameterizing data right from there (which is nice to send back to testers to have populate data without being involved in the script itseld).
Pat
See User Interface Testing.
Desktop or Web apps alike have the same testing pattern here (I've worked in both).
Place as little logic as possible in the UI and test everything below it. So you say, but what if I want to test that such and such happens when a button is clicked? The method that is called when that button is clicked should call out to another class that actually does the thinking.
You might say, but I'm using some static classes/methods that can only exist in my UI, wrap those with an adapter and utilize that interface in order to make your code testable.
The parts of your GUI tests that you want to automate should be automated below the UI. There are parts of your GUI that you can't automate. Checking to make sure things "look right", or testing that you can see certain elements, etc. All of that is what your humans should be doing. Ensuring that events are properly firing, and that values are being appropriately returned from your business objects, that's all unit tests.
I can see from your question that you've already pretty much decided you need an automated GUI tester, but that's not the right tool for this job. If you decide to use that you're trying to find the best way of doing the wrong thing.
If you think that this isn't about unit testing because you're testing GUI interactions, then I can guarantee you're not unit testing close enough to your UI. If you were, you'd feel like most of what you'd be testing was redundant.
If you disagree with me, please post some reasons and we'll hash this out.
There are a lot more (open source) alternatives if you are testing a web product. For a desktop product, some popular general purpose desktop GUI automation tools below (in no particular order). I've worked with all of these personally, and they all get the job done. If you choose to go with a vendor tool, get POCs for the ones you are considering, and make the decision based on what tool is the best fit for the company in general. One tool may be a better fit for a particular application, but there may be other projects/applications to consider.
QuickTest Pro (HP's successor to WinRunner)
Rational Functional Tester (IBM's successor to Robot)
TestPartner
We are about to get a canned package in that has been modified to our needs. I'm part of the team setup to prepare tests for it. It has an Oracle back end and I believe it's written in C++ .NET.
My question is what free or open source testing tools would you recommend.
Thanks
Ken
For regression testing of our applications I use a free tool called AutoHotKey http://www.autohotkey.com/. It is simple, batch configurable, and can work for virtually any application you have. Not exactly designed for black box testing, but a good free tool to add to your toolbox.
While there are a few good commercial applications for black box testing of applications (HoloDeck http://www.sisecure.com/holodeck/index.shtml, Cenzic Hailstorm http://www.cenzic.com/), the only open source applications that I know about only test network security (Spike http://www.immunitysec.com/resources-freesoftware.shtml, OWASP WebScarab http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project, and Nikto http://www.cirt.net/nikto2)
Value checking. See if only valid dates are exempted, number fields except the full range, ect.
What do you expect from such a tool? I don't know of any tool that can arbitrarily test any piece of software.
For what is sounds like you already know what it is that you want to check. Being a custom application your best bet would be to devise a test plan and manually test the values that you would like to validate.
Agree with the others - since the application has been modified to your needs, you should make sure that it actually is modified to your needs.
If the assembly isn't obfuscated, you can use FxCop to analyze the binaries and see if there are any critical bugs (note - if you're not familiar with fxcop and static analysis, find someone who is before reporting a ton of bugs that won't be fixed).
Beyond that, you're looking at more techniques vs. tools to get the job done.
Testing, either functional or non-functional, without reference to the
internal structure of the component or system.