UT TDD and others

1，UT需要许多的人力资源，并且在项目执行过程中维护工作量很大。如果在项目启动之前思考是否要投入UT，那么一定要非常仔细的考虑后面投入资源的问题；

2，许多做UT的项目，在UT用例的维护上投入很多，但最后随着项目的结束（有些可能还没有结束），这些用例就被丢弃了，因为后来发现需要投入越来越多的工作量；

3，如果在项目中决定做UT，那么测试和开发的人力配比需要1：1，如果只能投入1：3，那么对于测试人员来说，将会非常困难

4，TDD是一个很好的想法，但我觉得TDD并非说要尽早进行UT，而是尽早尽心PC测试

按：经典的观念认为UT应该是函数测试，但是100%的函数测试几乎是不可能的，但仅仅挑一些函数进行UT则测试边界可能变得比较主观，因此，我觉得是否有必要更抽象的定义unit的概念和范围

5，PC测试加上真实环境测试是一个比较好的测试方式

6，每个开发人员都使用一套有很多用例的PC自动化测试套，并且执行速度很快，这是一种比较好的方式

7，可考虑同一套测试用例在PC和机架上共享

按：这说的应该就是端到端的测试

8，对于测试人员来说，参与前期高层设计的讨论很有必要，了解系统的状态图和高层时序图是很重要的

9，对于PC测试来说，灰盒测试比较合适

10，对于系统级的PC测试，需要关注代码覆盖率

11，对于PC测试来说，尽可能多的准备一些测试用例，对于真实环境测试来说，需要的是一些常用用例，因为比较耗时

按：PC测试就是要快，秒级最好

12，如果关心分支覆盖，建议把关心的部分单独拎出来，做一个更小粒度的测试，这样比较容易观察到覆盖情况

13，特性的测试分析和设计是一个长期的工作，和测试执行不要分离才好

按：这其实是测试人员能力建设的问题，每一个测试管理者都必须考虑这个问题