前文提到，在UI自动化之外，我们着力探索了如何实施单元测试（unit test）
　　相对于UI自动化，单元测试方面的实践还是不够充分的，因此，这里也只是小结一下我们的经验
　　概述
　　首先明确一下，此处单元测试概念与经典意义有所不同，泛指所有：
　　由开发工程师编写的，可以在开发本地一键运行的，运行时间在分钟级别的测试用例，用例执行会依赖不多的，但往往也是稳定可靠的外部环境
　　测试框架一般使用TestNg而不是JUnit，主要原因在于TestNg的 DataProvider 功能很给力，非常适合用例须要覆盖多分支的场景
　　用例组织原则：
　　一个测试类对应一个功能类： funcOneTest.java 对应于 funcOne.java
　　若干个测试方法对应一个功能方法：test_funcOne_smoke() & test_funcOne_normal() & test_funcOne_error() 对应于 funcOne()
　　用例分类约定
　　还是以 超市购物 为背景，写几个Demo用例
　　Δ冒烟型用例 – 甲

@Test(description = "getNewestItems_冒烟_获取新商品并检查若干关键属性")
public void test_getNewestItems_smoke() {
List<ItemVo> itemList = itemBean.getNewestItems(1);
Assert.assertTrue(itemList.size() == 16，        "size应该是16");
for (ItemVo vo : itemList) {
Assert.assertTrue(vo.getName() != null，     "name不能为空");
Assert.assertTrue(vo.getPrice() != null，    "price不能为空");
}
}
　　说明：
　　顾名思义，是在用例中简单调用一下被测方法（method），主要是为了跑通流程，拒绝Block级别问题
　　实践中，推荐 伴随着功能开发，随时编写冒烟用例，功能代码与冒烟用例一起提交代码库
　　对于一些复杂的功能，功能开发的过程也是一个持续重构的过程，编码前期完成的冒烟用例，可以有效起到安全网作用
　　Δ冒烟型用例 – 乙
@Test(description = "enter_and_leave_market_冒烟_进入与离开超市")
public void test_enter_and_leave_market_smoke() {
Custom tom = new Custom("Tom");
tom.enterMarket();
Assert.assertTrue(Custom.isAtMarket(tom)，   "tom应该在超市内");
tom.leaveMarket();
Assert.assertFalse(Custom.isAtMarket(tom)，  "tom应该不在超市");
}
　　说明：
　　这个用例把进入超市及离开超市这两个（强相关的）接口串起来了，目的在于走通流程
　　实践中，建议 将新模块（函数）与其强相关的模块（函数）尽早进行简单的集成测试以提前发现一些问题
上一页123下一页
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系SPASVO小编(021-61079698-8054)，我们将立即处理，马上删除。