少来点虚的，多来点实在的。有单元测试数据吗？有统计效果吗？

marcus1877

老板想利用单元测试后砍掉一部分黑盒测试。
老板既然下命令了，有难度当然要说清楚了“单元测试发现的问题很难与黑盒测试发现的问题对应起来”。
老板“如果UT发现的问题不及黑盒测试，干什么要养一群人做UT，直接做黑盒就好了。”(黑盒人员成本低)
所以，我们得证明，UT发现的问题能覆盖黑盒的吗？
要解决这个问题，就必须把黑盒发现的bug映射到源码上，才知道UT有没有cover到。
还得考虑能不能把UT的覆盖映射到真实的用户可见现象上。
昨天和黑盒测试的同事讨论过了，这个UT覆盖与黑盒case覆盖就是双向一对多的关系。一个黑盒case对应多个ut,一个ut对应多个黑盒。
黑盒的case可以用人所能感知的设计出来，那么ut能做到这一点吗？痛苦。

现在所谓的这个测试好，那个测试好，都缺乏数据，谁有详细案例、数据、成本？
老板当然要知道那种成本高、那种符合企业了，但是这些活就得我们去做。

hotivy

我也正在想这个问题。我是这么认为这个问题的：
      UT和系统测试是两个阶段的行为，按“理论上”说，系统测试发现的bug肯定包含UT的bug。但是这两个测试的侧重点是不同的。正是因为“UT”不到位，所以在系统测试阶段发现些低级的功能错误，给人们造成的“错觉”就是UT测一测就行了，后面系统测试兜着。
     我觉得更多的功能Bug更应该在UT或集成测试阶段发现，而系统测试则偏重于业务方面，整体流程方面及性能、安全、易用性等测试。

其实你要的数据很简单： 目前很多公司都有自己的框架来做项目或产品。常年使用的框架很少有功能bug，所以：
一个成熟框架+项目 和  一个新开发框架+项目 哪个bug多呢？ “成熟框架”无法就是UT到位了，没有什么bug了。

    我现在正考虑在快餐型的项目中，可否加强UT和集成测试，取代系统测试。

iov_cp

回复 2# hotivy


    非常感谢你花时间回复我，目前我们是准备放弃UT。主要是因为我们无法通过UT快速发现有效错误，写了1个月的200条case还不如手工发现的快。
    写出一个UT倒是快，可是不是有效的。如何写出有效的UT case呢？话说到简单。比如如下完整代码

    public bool ParseHttpResponse(byte[] buffer,int offset,ref int count, out IHttpResponse httpResponse)  {
    if (_HttpRequest==null)
    { _HttpResponse=new HttpResponse();
     }
     _Buffer=buffer;
     _Reader.Assign(buffer,offset,count);
     while(_ParserMethod())
     {
         
      }
     count=_Reader.Index;
     if(_Finished)
     {
            httpResponse=_HttpResponse;
            httpResponse.Body.Seek(-,System.IO.SeekOrigin.Begin);
            _HttpResponse=null;
            }
        return _Finished;
     }
     这里开发人员笔误把_HttpResponse==null写成了_HttpRequest==null，只有在连续2次调用此function后才会出现问题，因为IHttpResponse不是期望的。
    可是，写UT就能cover到这个bug吗？我怎么知道该返回一个旧的，而不是新的IHttpResponse？说不定开发人员自己写UT时也没留意，就放过这个bug了??

iov_cp

刚才思考了下，确实要求非常熟悉流程与设计要求才行。如果只考虑到out 的IHttpResponse !=null是不够的。

Zgi46Z

有空一起交流一下

hotivy

正在缓慢研究，有时理论和实践差距太大，再推上去更是难。我觉得对于单个项目来说单元和集成测试做好了效率更高。对于长期的项目，还是系统测试有优势。因为一批测试人员长期鏖战一个项目，对于业务、架构、业务都很熟悉了，往往系统测试比单元测试更有效果。