没有UI层 怎么测试BLL和DAL层？ 没有UI层 怎么测试BLL和DAL层？现在暂时没有UI层数据访问层业务逻辑层做好了。大家都是怎么测试的？ 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 弄个Test.aspx 专门测试用啊 里面 掉bll方法 用VS自带的nunit测试用法 BLL和DAL层本来就应该在ui之前测试通过的 http://wenku.baidu.com/view/4e2aa08884868762caaed551.html BLL和DAL层的测试本来就不应该通过UI来完成 用VS自带的测试工具：Unit Test DAL没有什么意义，不去管它。测试BLL层不用UI。BLL层是独立设计的，往往它是在UI之前。虽然要强调要先想好UI、各种UI的可能性，然后才总结出BLL接口需求，但是BLL接口文档实际上在所有开发之前形成的。UI经常变来变去，而BLL接口是非常稳定不变的。BLL开发时使用一个console测试工程就可以了，无需界面。实际上如果你觉得只有用某种UI实现才能测试BLL，我估计你以前是做手工测试的，习惯于把“录制-回放”当作自动化测试。这种测试根本无用，完全应该忘掉。敏捷开发中的自动化测试，既不是手工测试人员所说的白盒测试也不是它们所说的黑盒测试。比如说BLL层有独立的API文档，那么你就要编写测试程序来测试这些个API，跟UI毫无关系。手工测试人员总是从最终软件的用户操作出发，它不考虑测试程序中某一个独立层、模块进行接口测试。 1.DAL是一般都是基于类似ado等现成的技术或者在这基础上扩展的, 要测试早就该测试过了,难道说楼主的DAL不是通用的?2.BLL的测试,根据文档接口,具体落实下来,就是每个派工单的设计接口 测试的意义绝非这些。不仅仅是测试BLL，有很多比这个编程方面更为重要的应用理念。测试至少可以有以下种类：1. 里程碑需求。这些都是客户最关心的、涉及利益最大化的需求，必须完成。而且跟奖金和罚金直接挂钩。2. 产品需求。这是指客户指定的使用人员（用户）最关心的操作性细节。这不可能一次性搞清楚，在产品生命期中需要反复与用户沟通，用户看到了你的产品的原型时，也许主意立刻就有新的主意了，你也可能觉得确实值得开发。3. 具有重大意义的内部接口API。4. 普通单元测试。许多开发人员也不知道为什么要测试，只知道每当写个方法就空洞地单元测试。（这类越少越好）5. 探针测试。通常是在进行产品规划前，对于一些不怎么了解的组件预先进行试验、了解其功能和性能。6. 运维测试。对测试环境、生产环境的网络、主机、进程、数据库等等不断进行多方面测试和预警。7. 第三方项目验收。外包开发时，你可能无法及时控制其进度，只能在2周甚至更长时间之后才开始测试他们的产品，而且反馈也很慢。8. 功能点压力测试。根据项目的特点，还会有其它的测试要关注的点。但是测试都应该关注于产品设计和进度管理，而那些过于低级的细节反而不要写测试程序。死抠传统的“单元测试”这个概念是无法告诉你该测试什么、不该测试什么的。测试可以让（至少一个小组内）开发人员可以随时更改别人的代码，而不是将代码专属于某个人自己拥有；可以随时发布；假设一个代码注释掉也可以让测试通过，那么那些垃圾代码就可以放心地删除掉。 既然在asp.net论坛说到这个问题，我给你举一个互联网公司运维可能常用的测试例子。比如说他们需要开发一种插件，以一定频率随机然后放入产品的个别网页中，让这些插件从浏览器端采集一些信息然后传到运维使用的web服务器中，这样就可以成比例地反映全世界各地每一个地方都有多少用户访问此网页、下载速度快不快，鼠标集中在哪一个区域上操作等等。这些都是基于自动测试技术，自动测试需要有比开发更强的编程能力。 关于ID字段自增的问题 关于页面打印的问题 怎么实现asp.net手动分页 asp.net3.5(C#)连接SQL2005数据库问题 Ajax和Jquery的作用和简单应用语法 问一个关于DataList. 注册GAC 我最近在准备MCAD 70-305的考试，请前辈们指点一下,也请asp.net的爱好者来发表自己的看法 新手问题!!只想知道各文件的大概用处 winform下出现如下的错误,该如何解决? 求一段，动态查找图片并写到前台页面的代码或者方法 asp.net如何获得用户登录和退出的时间
用法
DAL没有什么意义，不去管它。测试BLL层不用UI。BLL层是独立设计的，往往它是在UI之前。虽然要强调要先想好UI、各种UI的可能性，然后才总结出BLL接口需求，但是BLL接口文档实际上在所有开发之前形成的。UI经常变来变去，而BLL接口是非常稳定不变的。BLL开发时使用一个console测试工程就可以了，无需界面。实际上如果你觉得只有用某种UI实现才能测试BLL，我估计你以前是做手工测试的，习惯于把“录制-回放”当作自动化测试。这种测试根本无用，完全应该忘掉。敏捷开发中的自动化测试，既不是手工测试人员所说的白盒测试也不是它们所说的黑盒测试。比如说BLL层有独立的API文档，那么你就要编写测试程序来测试这些个API，跟UI毫无关系。手工测试人员总是从最终软件的用户操作出发，它不考虑测试程序中某一个独立层、模块进行接口测试。
要测试早就该测试过了,难道说楼主的DAL不是通用的?
2.BLL的测试,根据文档接口,具体落实下来,就是每个派工单的设计接口
2. 产品需求。这是指客户指定的使用人员（用户）最关心的操作性细节。这不可能一次性搞清楚，在产品生命期中需要反复与用户沟通，用户看到了你的产品的原型时，也许主意立刻就有新的主意了，你也可能觉得确实值得开发。
3. 具有重大意义的内部接口API。
4. 普通单元测试。许多开发人员也不知道为什么要测试，只知道每当写个方法就空洞地单元测试。（这类越少越好）
5. 探针测试。通常是在进行产品规划前，对于一些不怎么了解的组件预先进行试验、了解其功能和性能。
6. 运维测试。对测试环境、生产环境的网络、主机、进程、数据库等等不断进行多方面测试和预警。
7. 第三方项目验收。外包开发时，你可能无法及时控制其进度，只能在2周甚至更长时间之后才开始测试他们的产品，而且反馈也很慢。
8. 功能点压力测试。根据项目的特点，还会有其它的测试要关注的点。但是测试都应该关注于产品设计和进度管理，而那些过于低级的细节反而不要写测试程序。死抠传统的“单元测试”这个概念是无法告诉你该测试什么、不该测试什么的。测试可以让（至少一个小组内）开发人员可以随时更改别人的代码，而不是将代码专属于某个人自己拥有；可以随时发布；假设一个代码注释掉也可以让测试通过，那么那些垃圾代码就可以放心地删除掉。