如何开发一套测试工具
请教，现在需要开发一套测试工具软件，用来测试公司针对Winform类产品。但是现在无任何头绪。
请高手指点一下。
谢谢。
[最优解释]
呵呵，不就是“头绪”嘛，那就抛砖引玉一下吧。随便写一段代码看看：
private static Random Rnd = new Random();
private static void BeginTest()
{
var testcases = (from asm in AppDomain.CurrentDomain.GetAssemblies()
from type in asm.GetTypes()
where type.IsClass && typeof(Form).IsAssignableFrom(type) && typeof(ITestForm).IsAssignableFrom(type)
select type).ToList();
if (testcases.Count > 0)
BeginInstance(testcases, 0);
}
private static void BeginInstance(List<Type> testcases, int n)
{
var pos = Rnd.Next(testcases.Count); //随机选择一个测试用例
var testcase = testcases[pos];
var testinstance = (Form)Activator.CreateInstance(testcase); //创建一个测试Form的实例
((ITestForm)testinstance).TestCompleted += () =>
{
if (n <= testcases.Count * 10) //一共进行 testcases.count*10 次测试可以保证每一个测试用例都至少实例一次。
BeginInstance(testcases, n + 1);
};
testinstance.Show();
}
[其他解释]
NUnit做单元测试挺方便的
真正的全面自动化集成测试都是自己写测试程序,可以将发现的bug自动导入测试管理系统
随机产生测试数据,随机抽取测试用例来反复测试
http://blog.csdn.net/wyingquan/category/231722.aspx
[其他解释]
public interface ITestForm
{
void StartTest();
event Action TestCompleted;
}
其实测试程序跟随便写一个程序也没有什么区别。没有必要统计有多少测试是“红灯”，有多少是“绿灯”。因为第一个红灯，那么所执行的那个测试程序就应该抛出异常：throw new Excepsion(...)。只要有一个bug，我们就没有必要再去测试别的东西，应该集中精力解决这一个bug。其实这种遇到了bug就立刻停止所有其它工作的做法，才真正敏捷。
进一步，我们可以增加一个StartTestAttribute，可以为测试程序定义何时开始测试。甚至一个ReopenAttributes，这样我们可以声明某个测试推迟测试（例如2011/1/13 13:00之后才开始测试）。
这样，当你的测试用例很多时，大多数时候可以让上面的uery仅仅查找最近3天的测试。对于（每）个人来说，每隔10分钟就应该运行一次测试。然后用测试的bug来驱动你去写下面几分钟的代码。不要做不必要的事情，也就是说不要在没有测试用例的情况下盲目写代码。
每天也至少应该进行几次包括所有测试用例的测试。
[其他解释]
这样我们可以声明某个测试推迟测试 --> 这样我们可以声明某个以前已经貌似可以淡忘了的测试推迟测试
其实测试程序跟随便写一个程序也没有什么区别。比如你在一个测试Form里从数据库里查询并随机生成了一个数据，并加载了一个被测试控件到这个Form，然后所谓StartTest方法就是为控件（可能需要反射）填入值，（可能需要反射）触发按下按钮的事件，然后（假设这时候被测试控件需要联系世界上另一头的服务器）过了几秒钟判断一下控件的下一步行为（比如可能需要反射来取得控件，判断它的值）是否正确，如果不正确就抛出异常就行了。
一旦测试程序执行完，触发TestCompleted，那么（上面的demo程序）引擎程序就知道可以产生下一个测试用例的实例了。
[其他解释]
测试的目的是期望的结果与实际结果是否一样。如一个方法在特定的条件下返回0,在测试时创造返回0的条件，可实际结果是否为0.如果为0测试通过，否则没有通过.
[其他解释]
谢谢分享。。
[其他解释]
这帖由于2-4楼的精彩回答应该推荐...
[其他解释]
其实好的测试工具就是自动化模拟用户的行为，越不像程序员的行为越好...
[其他解释]
该回复于2012-08-28 09:23:36被版主删除
[其他解释]
learning......
[其他解释]
该回复于2011-01-12 10:58:25被版主删除
[其他解释]
该回复于2011-01-12 11:03:29被版主删除
[其他解释]
是的 这个是针对高校学生而设立的比赛
[其他解释]
该回复于2011-01-12 11:03:28被版主删除
[其他解释]
该回复于2011-01-12 10:57:32被版主删除
[其他解释]
该回复于2011-01-12 11:09:03被版主删除
[其他解释]
思路最重要。谢谢提供。
[其他解释]
该回复于2011-01-12 10:58:23被版主删除
[其他解释]
很有看头的讨论，
支持推荐加精
[其他解释]
我只是举了一个winform的测试，应lz所说的环境。而且是现写的。
随着你的需求不同，会增加各种不同平台的测试引擎，例如silverlight的、javascript的、console的，等等。但是概念是一样的。其实跟写普通的程序也没有太大的区别，只是技术要求更高一点，往往需要你使用反射，甚至写十几个实用的扩展方法专门用户反射出被测试对象的内部结构。
最重要的是测试的目的是什么。许多人只是图新鲜，没过几天就又回到“先实现代码然后再写测试”的老路上去了。其实开发人员如果先写代码，那么就很难在思想上真正愿意去怀疑自己的代码，很难写出真正好的测试代码。所以应该先写测试代码，然后根据编译或者运行时的bug来修复它，让你的程序可以通过测试就是达到了开发的终极目的了。
对于一些没有界面的程序，我们往往可以按照1小时左右的工作量来写测试，即使用10分钟时间写测试代码，然后使用50分钟时间让测试通过。仍然是每隔几分钟、十分钟就要运行一次测试程序，让后让出现bug的那一条语句通过就可以了。而对于有界面的程序，我们可以按照1天或者1天半的工作量来写测试。
写测试不要过细，因为写测试程序就是软件设计，它应该用来说明你要实现什么操作流程（功能），说明需求接口，而不是说明内部的实现方法。
写测试也不要过粗。如果所写的测试程序大多都是通过4、5天才实现的，那么你控制开发进度的强度可能比较爱差了。
根据产品的水平高低，所需要的测试的数量不同。一个小项目，可能需要200个测试，其中只有当你有50个测试的时候系统的架构才基本稳定。而一个大项目，比如开发一个代码编辑器，可能需要上万个测试，才能保证产品稳定。
[其他解释]
该回复于2011-01-12 13:59:07被版主删除
[其他解释]
该回复于2011-01-12 13:54:46被版主删除
[其他解释]
该回复于2011-01-12 14:28:05被版主删除
[其他解释]
VS2010有一个自带的测试工具，能记录下用户的操作过程，并生成C#代码，用户只要操作一次，今后重复测试的时候 就能自动化进行了。
[其他解释]
该回复于2011-01-12 16:22:48被版主删除
[其他解释]
哇塞，2楼的兄弟好猛啊。应该赏
!
[其他解释]
该回复于2011-01-12 16:51:26被版主删除
------其他解决方案--------------------
该回复于2011-01-12 16:47:02被版主删除
[其他解释]
该回复于2011-01-13 09:01:05被版主删除
[其他解释]
很有看头的讨论，
支持推荐加精
[其他解释]
《Delphi下深入Windows核心编程》有介绍如何隐藏进程，可以研究一下
[其他解释]
该回复于2011-01-13 09:12:46被版主删除
[其他解释]
这个有点意思。
[其他解释]
该回复于2011-01-13 14:27:26被版主删除
[其他解释]
需要更好的答案。。。。。。。。。。。。。
[其他解释]
该回复于2011-01-13 10:05:35被版主删除
[其他解释]
private static Random Rnd = new Random();
private static void BeginTest()
{
var testcases = (from asm in AppDomain.CurrentDomain.GetAssemblies()
from type in asm.GetTypes()
where type.IsClass && typeof(Form).IsAssignableFrom(type) && typeof(ITestForm).IsAssignableFrom(type)
select type).ToList();
if (testcases.Count > 0)
BeginInstance(testcases, 0);
}
private static void BeginInstance(List<Type> testcases, int n)
{
var pos = Rnd.Next(testcases.Count); //随机选择一个测试用例
var testcase = testcases[pos];
var testinstance = (Form)Activator.CreateInstance(testcase); //创建一个测试Form的实例
((ITestForm)testinstance).TestCompleted += () =>
{
if (n <= testcases.Count * 10) //一共进行 testcases.count*10 次测试可以保证每一个测试用例都至少实例一次。
BeginInstance(testcases, n + 1);
};
testinstance.Show();
}
[其他解释]
该回复于2011-01-13 15:33:56被版主删除
[其他解释]
该回复于2011-01-13 15:15:23被版主删除
[其他解释]
该回复于2011-01-13 15:12:57被版主删除
[其他解释]
.....
[其他解释]
该回复于2011-01-13 16:14:21被版主删除
------其他解决方案--------------------
该回复于2011-01-13 14:38:26被版主删除
[其他解释]
2#的太强了
[其他解释]
该回复于2011-01-14 14:33:17被版主删除
[其他解释]
谢谢分享！！！
[其他解释]
该回复于2011-01-13 15:53:05被版主删除
[其他解释]
http://blog.csdn.net/wyingquan/category/231722.aspx
[其他解释]
该回复于2011-01-14 16:10:54被版主删除
[其他解释]
我也想搞自动化测试。。。不知从何入手~~
[其他解释]
该回复于2011-01-14 14:31:56被版主删除
[其他解释]
该回复于2011-01-14 13:48:15被版主删除
[其他解释]
该回复于2011-01-15 17:06:26被版主删除
[其他解释]
该回复于2011-01-15 09:25:35被版主删除
[其他解释]
该回复于2011-01-15 08:43:35被版主删除
[其他解释]
该回复于2011-01-14 16:36:53被版主删除
[其他解释]
该回复于2011-01-17 10:06:14被版主删除
[其他解释]
该回复于2011-01-17 09:05:22被版主删除
[其他解释]
该回复于2011-01-17 08:32:26被版主删除
[其他解释]
该回复于2011-01-17 08:48:40被版主删除
[其他解释]
好像没有这本书吧？怎么我在网上没有找到阿
[其他解释]
使用UIA类库进行测试。推荐一本书《.NET 轻量化测试工具开发》
[其他解释]
测试这件事，很重要的啊……
[其他解释]
+1
[其他解释]
这个测试工具，我们公司开发过一套，包括每日代码自动构建，exe自动发布，exe自动测试，dump文件上传，日志数据库系统，基本上一套完整的自动构建与测试系统！
[其他解释]
MAUI,微软内部测试框架，偷一套来就可以了，呵呵。在中国，IT行业就是Copy,make money，别太把技术当回事情，呵呵
[其他解释]
微软在Visual Studio 2010中对测试进行了大幅的改进，推出了真多UI的自动化测试框架（类似于微软内部ＭＡＵＩ），可以看看我的博客上。同时微软推出了针对手工测试测试人员Microsoft Test Manager，可以用来管理和执行测试用例。
[其他解释]
知。。
[其他解释]
我现在也在学习呵呵，共同进步
[其他解释]
LZ这个阶段，对测试工具尚无认识。给你2个月的工作量建议：
先采取录制回放的黑盒，做完前50-100个功能测试用例。依赖工作：选择一款适合WinForm的自动化工具，有免费的。推荐一个AutoITv3。
2个月后，如果产品规模发展了，可以按照代码量与测试用例数量的比率建设更多。
什么时候需要写脚本语言和ActionWord？
建议先达到以下几个不太充分，也不太必要的条件：
1.超过100个用例
2.已经实现了100个录制回放脚本
3.被测软件发布了V2.0以后
[其他解释]
如何开发一套测试工具，我可以按10000分/小时的价格讲。
[其他解释]
该回复于2011-01-17 15:02:01被版主删除
[其他解释]
Web的话可以用蜘蛛
[其他解释]
自己开发测试工具,有个最大的优势,
比如,我们的页面是自动的,元素的Id是动态的,会变化,
那么我的测试工具其实是先访问文档,通过文档去推断页面有哪些元素,
只要文档接口没有变化,测试代码就不用迭代
所以说,微软的那个测试猛一看是挺玄的,但不是真正的自动化测试
[其他解释]
自己？和都不允，呵呵
用成的吧
Gibraltar Software Gibraltar Analyst
[其他解释]
该回复于2011-01-24 09:13:19被版主删除
[其他解释]
录制回放不是真正的自动化测试。
这是从针对手工测试人员写的那些书上抄来的做法，但是那些书上95%的内容都是在讲不切实际的、比如手工测试覆盖率之类的空谈。其内容，跟现在敏捷开发过程中自动化测试的开发方法完全是两回事。
[其他解释]
录制回放，呵呵，如果不是搞软件开发的人（而是仅仅有手工测试经验的人），我是可以理解的。不过，这不是开发人员所说的自动化测试。
虽然我专门研究软件项目开发过程，但是根本不讨论这类手工测试人员心目中的测试方法。
[其他解释]
自动化测试工具，无需自己开发，可以考虑用现成的，简单一点就像用游戏的脚本工具 键盘精灵，如果希望用微软自己的，考虑用Test Manager，如果要专业一点的，考虑去找一个QTP（QuickTestProfessional），不过需要自己写脚本，但是上手也是相对容易的。
[其他解释]
必须自己开发,测试渗透到几乎所有工序,而不是仅仅测试最终代码,况且90%的代码不是人写的,
比如:
当我派工单是需要提交文档,我需要的是即席验证,而不是等文档解释成代码后才发现设计有错误
[其他解释]
null
[其他解释]
狠狠地支持一下，继续观望,,,...
[其他解释]
null
[其他解释]
null
[其他解释]
另外，如果你参与一个跨地域，甚至跨国的开源软件的开发就会发现，每一种流行的开源系统里边都有几千个测试用例程序，你会很习惯自己的程序测试自己的程序。学会这个小玩意，可以真正进行敏捷开发团队的管理工作。
[其他解释]
用3天时间自己写一个测试引擎，然后就能很好地推广给每一个程序员，可以100%地协调你的开发进度，而且可以自动产生进度跟踪报告。
而靠从网上找一些工具，然后学习其脚本编程，再来使用，大多数人都经历了好几年，都没有真正全面在开发组织里用起来过。
这真是一个天上，一个地下。这是实打实的经验教训。
[其他解释]
可以试一下前面有人说的 AutoIt，我们现在就是基于AutoIt来进行WinForm的自动测试，只不过这工具还不是很稳定。
[其他解释]
强调一下，习惯于用自己的程序测试自己的程序，抬手就写了。比如你要开发一个winform程序，那么你可以创建另外一个console或者winform程序，引用被测试的winform程序工程，以及提供一点测试引擎程序的工程，然后自己的这个winform程序中就开始写测试程序了。程序员自己最清楚如何写测试程序，手工测试人员则对设计细节、需要测试到内部哪一语句并点不了解，不会写测试程序。
[其他解释]
null