test
1.要为某个方法A m(int b,String c)构造黑盒测试用例，那么设计实现Junit测试用例不需要依据的内容为
m()的内部实现代码
需要依照的内容包括：
m()的pre-condition（该方法输入参数满足的条件）
m()的post-condition（该方法执行后返回值满足的条件）
类A的等价性判断方法A.equals()
2.并不是说测试用例的数量越多，越容易发现潜在的bug
再好的测试也无法证明代码里100%不存在bug
设计测试用例时，需要给出输入数据和期望的输出结果
测试用例具有优先级，应该将最容易发现错误的用例先执行
TDD的思想是：先设计方法的spec，然后根据spec设计测试用例，然后再写代码并确保代码通过测试
3.all are good time to re-run all your Junit tests
Before doing git add/commit/push
After rewriting a function to make it faster
when using a code coverage tool such as EclEmma
After you think you fixed a bug
4.在使用等价类划分方法进行测试用例设计时：
如果输入参数a在spec中仅被规定a>10且未说明a<=10应该如何，那么无需测试a<=10的情况
采用笛卡尔积“全覆盖”策略进行测试用例设计，会导致用例数量多，测试代价高
采用“覆盖每个取值”的策略进行用例设计，测试代价低，但测试覆盖度可能较差
5.all are useful for choosing test cases in test-first programming,before any code is written
Black box黑盒测试
partitioning等价类划分
Boundaries边界值
6.以下说法不正确的是：
如果某个bug已被正确修复并已经通过测试，那么为了降低后续测试的代价，应将该bug对应的测试用例从测试库中删除
正确的：
如果发现了一个新的bug，需要返回到版本仓库中对之前的各个版本进行测试，以确认该bug最早是在哪个历史版本中引入的
代码覆盖度code coverage是指所有测试用例执行后有多大百分比覆盖了被测程序的所有的代码行
可以从被测代码中寻找依据来设计处于“边界”上的测试用例
7.关于JUnit的说法不正确的是：
如果一个Java测试类定义了多个@Test方法，那么它们按照在代码中出现的先后次序加以执行
正确的有：
某方法前标注着@Test，意味着它是一个测试方法。@Test是Java中的annotation
如果未通过测试，方法中的assertXXX()将抛出AssertionError
一个Java测试类可以定义全局属性并在@Before方法中对属性进行数据准备，在@Test方法中使用数据