Δ特殊场景 & 复杂流程
　　个别特殊场景，不方便使用@DataProvider合并的复杂流程，可以单独创建一个用例进行测试，函数命名的时候注明一下，例如：
　　test_addToCart_error_withoutEnoughMoney() – 钞票不够
　　test_addToCart_normal_mergeMultiCarts() – 合并多个购物车
　　Δ前事不忘，后事之师
　　出过Bug的地方（及其周边）补充单元测试覆盖，由单元测试帮你记住前事 – test_funcOne_issue12345_bugfix()
　　用例编写流程
　　用例编写顺序：
　　开发新功能时，同步编写冒烟测试，用于自测及调试，功能代码与冒烟用例一起提交 – test_funcOne_smoke()
　　稍晚，补充更多分支覆盖的正常流程用例，相当于进行又一轮自测 – test_funcOne_normal()
　　后，补充异常流程和特殊（复杂）场景用例 – test_funcOne_error() & test_funcOne_specialScenario()
　　之所以这样安排，一个很重要的原因是希望 保持主干及正常流程的畅通，确保开发及测试不会Block
　　此外：
　　尽量把单个开发任务切分成多个小功能点，频繁提交，稳扎稳打，配合Jenkins & Sonar，多跑单元测试和静态代码检查，问题早发现早处理
　　前事不忘，后事之师，出过Bug的地方补充单元测试
　　补遗
　　单元测试与静态代码检查（static analysis， SA）是一对好基友，两者可以统一显示在Sonar上面，在实践中往往一起考察
　　关于Sonar，实乃居家必备，代码度量之利器，以后会另外讲述，这里先贴个图：