java测试的类型？
创新互联专注为客户提供全方位的互联网综合服务，包含不限于网站制作、成都网站设计、巧家网络推广、小程序制作、巧家网络营销、巧家企业策划、巧家品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；创新互联为所有大学生创业者提供巧家建站搭建服务，24小时服务热线：18980820575，官方网址：www.cdcxhl.com
黑盒测试？白盒测试？灰盒测试？
白盒测试(White-box Testing，又称逻辑驱动测试,结构测试)是把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时，需要测试软件产品的内部结构和处理过程，不需测试软件产品的功能。白盒测试又称为结构测试和逻辑驱动测试。
白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
六种覆盖标准：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖发现错误的能力呈由弱至强的变化。语句覆盖每条语句至少执行一次。判定覆盖每个判定的每个分支至少执行一次。条件覆盖每个判定的每个条件应取到各种可能的值。判定/条件覆盖同时满足判定覆盖条件覆盖。条件组合覆盖每个判定中各条件的每一种组合至少出现一次。路径覆盖使程序中每一条可能的路径至少执行一次。
白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。
"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。
白盒测试目前主要用在具有高可靠性要求的软件领域，例如：军工软件、航天航空软件、工业控制软件等等。白盒测试工具在选购时应当主要是对开发语言的支持、代码覆盖的深度、嵌入式软件的测试、测试的可视化等。
对开发语言的支持：白盒测试工具是对源代码进行的测试，测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。但是对于不同的开发语言，测试工具实现的方式和内容差别是较大的。目前测试工具主要支持的开发语言包括：标准C、C＋＋、Visual C＋＋、Java、Visual J＋+等。
代码的覆盖深度：从覆盖源程序语句的详尽程度分析，逻辑覆盖标准包括以下不同的覆盖标准：语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖和修正判定条件覆盖。
·语句覆盖 为了暴露程序中的错误，程序中的每条语句至少应该执行一次。因此语句覆盖（STatement Coverage）的含义是：选择足够多的测试数据，使被测程序中每条语句至少执行一次。语句覆盖是很弱的逻辑覆盖。
·判定覆盖 比语句覆盖稍强的覆盖标准是判定覆盖（DECision Coverage）。判定覆盖的含义是：设计足够的测试用例，使得程序中的每个判定至少都获得一次“真值”或“假值”，或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次，因此判定覆盖又称为分支覆盖。
·条件覆盖 在设计程序中，一个判定语句是由多个条件组合而成的复合判定。为了更彻底地实现逻辑覆盖，可以采用条件覆盖（ConDItion Coverage）的标准。条件覆盖的含义是：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。
·多条件覆盖 多条件覆盖也称条件组合覆盖，它的含义是：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。
·修正条件判定覆盖 修正条件判定覆盖是由欧美的航空/航天制造厂商和使用单位联合制定的“航空运输和装备系统软件认证标准”，目前在国外的国防、航空航天领域应用广泛。这个覆盖度量需要足够的测试用例来确定各个条件能够影响到包含的判定的结果。它要求满足两个条件：首先，每一个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值要至少转换一次；其次，程序的判定被分解为通过逻辑操作符（and、or）连接的布尔条件，每个条件对于判定的结果值是独立的。
黑盒测试
也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。 “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。
黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。
黑盒测试试图发现以下类型的错误：
1）功能错误或遗漏；
2）界面错误；
3）数据结构或外部数据库访问错误；
4）性能错误；
5）初始化和终止错误。
黑盒测试的优点
1. 基本上不用人管着，如果程序停止运行了一般就是被测试程序CRASh了
2. 设计完测试例之后，下来的工作就是爽了，当然更苦闷的是确定crash原因
黑盒测试的缺点
1. 结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG的东西很值得借鉴
2. 没有状态转换的概念，目前一些成功的例子基本上都是针对PDU来做的，还做不到针对被测试程序的状态转换来作
3. 就没有状态概念的测试来说，寻找和确定造成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来说，就更麻烦了，尤其不是一个单独的tEStcase造成的问题。这些在堆的问题中表现的更为突出。
灰盒测试介于白盒测试与黑盒测试之间
单元测试关注代码覆盖率
系统测试、集成测试关注功能覆盖率，不能统计代码覆盖率了
void DoWork (int x,int y,int z){1 int k=0, j=0;2 if ( (x3)(z10) )3 {4 k=x*y-1;5 j=sqrt(k);6 }7 if((x==4)||(y5))8 j=x*y+10;9 j=j%3;10 }说明：程序段中每行开头的数字（1~10）是对每条语句的编号。（1）画出程序的控制流图（用题中给出的语句编号表示）。（2）分别以语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖方法设计测试用例，并写出每个测试用例的执行路径（用题中给出的语句编号表示）。题目二、折半查找请按要求对下面的java 代码进行测试。代码的功能是：用折半查找法在元素呈升序排列的数组中查找值为key 的元素。public int binSearch ( int array[], int key ) {int mid, low, high;low = 0;high = array.length-1;while ( low = high ) {mid = (low +high)/2;if ( key = = array [mid] )return mid;else if ( key array [mid] )high = mid -1;elselow = mid + 1}return -1;}（1） 试计算此程序段的McCabe 复杂性；（2） 用基本路径覆盖法给出测试路径；（3） 为各测试路径设计测试用例。
一:创建一个测试类,建议将测试类单独放在一个包中(在 maven 项目里有测试类专门的存放位置),新建一个Junit Test Case类,下一步
测试类的命名建议是你将要测试的类名+Test,然后点 Browse, 你可以选择要进行测试的类(一般选择 Service, 因为 Service 关心的是业务需求),用这种方式创建可以自动生成要测试类的测试类,你只需要进行测试代码的书写.
@Test
public void testqueryById(){
} @Test
public void testQueryAll(){
} @Test
public void testReduceNumber(){
}123456789101112
如果里面有自动生成的代码,删除或注释即可…
二:配置 spring 和 junit 整合, junit 启动时加载 springIOC 容器,这里你需要 Spring-test jar包
@RunWith(SpringJUnit4ClassRunner.class) //告诉junitspring配置文件
@ContextConfiguration(locations = {"classpath:spring/spring-dao.xml"})123
同样的,在测试类中我们会调用 Service 的逻辑,由于我们使用的是 Spring+SpringMVC+ 持久化框架,所以要注入一个 IService 接口(这里我直接对 DAO 进行测试了)
@Autowired
private SeckillDao seckillDao;12
接下来是测试逻辑,在编写测试代码之前建议覆盖实体中的 toString 方法,不然打印会很麻烦.
@Test public void testqueryById(){ long id = 1000;
Seckill seckill = seckillDao.queryById(id);
System.out.println(seckill.getSeckillName());
System.out.println(seckill);
} //JAVA没有保存形参的记录,如果你在 dao 中传了多个参数,那么需要声明它的形参对应的实参,否则 JVM 会显示找不到参数.声明方式稍后奉上
@Test public void testQueryAll(){
ListSeckill seckills = seckillDao.queryAll(0, 100); for(Seckill seckill:seckills){
System.out.println(seckill);
}
}
@Test public void testReduceNumber(){
Date killTime = new Date(); //对增加进行测试的时候,只要数据库增加了一条数据,我们就默认这个方法执行成功了
int updateCount = seckillDao.reduceNumber(1000L, killTime);
System.out.println("updateCount = "+updateCount);
}123456789101112131415161718192021222324
解决JAVA不保存形参的记录
int reduceNumber(@Param("seckillId")long seckillId,@Param("killTime")Date killTime);
Seckill queryById(long seckillId); /**
* mysql的分页查询
* @param offset 告诉它实际的形参
* @param limit
* @return
*/
ListSeckill queryAll(@Param("offset")int offset,@Param("limit")int limit);1234567891011
接下来我们根据他返回的结果和我们想要的结果对应就可以了. 测试类不用部署项目, 测试周期非常短, 而且可以进行专项测试. 测试类代码逻辑十分简单, 几乎不会出错. 如果结果不是预期的, 那么根据你的需求修改!
当然, 它的局限性也很打. 从单元测试不能看出页面传值的错误, 许多项目在服务器中的表现也不能模拟.
那么我们什么时候用junit呢?
当你的数据库操作非常复杂, 你不确定能输出你想要的值的时候, 相比用 debug 调试, 使用 Junit 是更方便的手段.或者新手出错概率非常大, 也不用在服务器中专门测试项目的表现, Junit 是个必备的工具!而且测试类的测试代码重用性很高.
如果你的数据和预期相悖, 那么修改业务逻辑; 否则, 查看页面是否有错! Junit在一定程度上减轻了我们业务代码调试的压力, 让我们关注于一点解决错误.
