路宁(luning)的博客

有一个新入职的Dev，每次开发完一个功能后就叫上QA到自己的机器上来测试，并不像大多数Dev一样发起正式的提测流程。

他这么做一方面是因为担心自己开发的质量差，正式提测后的Bug被记录下来，影响他的KPI表现。另一方面是正式提测如果有问题还要打回来，来回走流程费劲。

QA起初积极配合，但后来发现这么做对自己很不利，无法在领导那里体现自己的工作。因为QA是根据Dev的提测计划制定自己的测试计划，QA经理主要根据测试计划及执行情况来了解手下人的工作。不仅如此，这样做还会影响自己的一项KPI：漏测率。漏测率是指上线后发现的Bug数除以总Bug数，如果记录的Bug基数少了，漏测率极易上升。

QA反应过来这个问题后就不再配合了。Dev嫌QA变默唧了，QA 反过来嫌Dev懒，让他正式提测。两边合作不愉快，就开始找“流程”帮忙，沟通少了，一切走邮件，走流程。

Dev 感觉QA 让他名下的Bug多了，搞得自己在Dev经理面前很没面子，和QA说话时自然没什么好语气。QA 心里也不顺，本来没多大的事，搞得默默唧唧的。

最终的解决办法是，走流程，你在系统里提测，我才测试，有问题记录Bug，依赖Bug跟踪系统......

哈哈，有意思吧。你能说这个Dev或QA不够好吗？不是。

不管出于什么动机，他们确实发现了一个更高效的合作方式，但却被“流行的组织结构”，“僵化的KPI”，和“万能的流程”无情地打击了......

这是一个基于JSF的WEB应用，被测的场景是编辑一个巨大的表单，然后进行预览操作，最后再回到编辑页面，验证各个字段是否和以前的一样，据此间接检验各个页面元素与后台Bean的绑定是否正确。

以前的测试不是人读的

这是之前实现这一测试的代码片段：

@Test
public void createFullRequest_priview_backEditing_checkData(){
    goToCreationPage();
    browser.click(ADD_APPOINTMENT);
    browser.click("lorryTrucking1");
    browser.select("containerSizeType1_1", "label=20' Platform");
    typeAndBlur("containerQuantity1_1", "1");
    browser.select("cargoPackageType1_1", "label=Bar");

......

修bug时我们都有这样的经历：简单查看了一下代码，发现没有那个类负责这个逻辑，进一步深入代码，查找一番，才在一个看似不相关的地方找到了错误的根源。原来这个逻辑被散落在几个地方，隐讳地错误实现了。我们在出错的地方多加一个if else，或是写点别的什么代码，这个bug就这样被fix了。

仅仅这样做虽然提高了软件的外部质量，但对内部质量的提高毫无益处，泄漏在外的逻辑不仅仍然无家可归，而且有变得越加复杂和晦涩的倾向。

每一个bug的出现都是对分析、设计和编码过程的一次质疑。这次......

Q:单元测试的主要作用有哪些?

A:单元测试的作用主要有：
   (1) 确保代码实现了预想的逻辑。这是所有测试都有的，也是最重要的功能。
   (2) 确保重构不破坏现有的功能。所有测试都或多或少地支持这一功能，有些“重构不友好”的测试在重构过程中可能会被删除或修改。
   (3) 驱动出设计，主要是帮助识别出类或接口函数。这是个一次性的好处，只有部分测试会起到这个作用。那些直接保证内部函数实现逻辑的测试起不到这个作用。
   (4) 当难以编写满意的测试时，提示开发人员现有设计的问题并鼓励他们重构现有的代码。这也是个一次性的好处，只有部分测试会起到这个作用。
   (5) 作为需求文......