小型开发团队的特点主要表现在开发成员少，整个团队成员在10人以内；团队成员岗位较多重叠，开发人员常常是测试人员，项目工作量大、上线时间紧迫，相比大型开发团队来说，没有专业的测试人员，没有完善的质量保障体系。小型开发团队的测试工作常常是软件开发过程中的一大问题，这里浅谈下小型开发团队常常陷入的测试误区。

　　一、唯单元测试论

　　单元测试由开发人员编写的一段代码，用于证明功能代码的行为和我们期望的一致。单元测试的重要性不用多说，单元测试是项目质量的一个重要保证，但是不能说做好了单元测试项目的质量一定会提高。团队要正确认识单元测试的重要性，同时也要注重功能测试、系统测试（系统测试主要内容：功能测试、性能测试、ＵＩ测试、安全测试，压力测试等）。质量保证是一个完整的体系，不能厚此薄彼。

　　二、过于追求单元测试代码覆盖率

　　单元测试代码覆盖率代表着代码的覆盖程度，往往被用来作为单元测试的指标。难道代码覆盖率达到100%，项目就没有BUG了吗？答案一定是否定的。网络上有一个很经典的案例，要测试一个除法代码（a/b）的正确性，假如我们的程序员编写用例：a=500，b=0；很明显这段代码的代码覆盖率达到了100%，但是系统会出现异常，出现BUG；所以代码覆盖率只能代码测试过那些代码，并不能代表这段代码有多好，我们的程序员在追求代码覆盖率时，更要想办法设计编写好更高水平的用例。

　　三、软件功能开发完成之后再测试

　　很多小型开发团队在工作时，往往所有人投入到开发工作中，功能开发完之后，再将代码合并，发布一个测试版本，所有人员统一测试，这样项目开发的后期工作压力剧增，团队成员工作压力大，时间一长，团队成员工作效率低。

　　对于全新项目来说，从项目管理角度来说，测试参与越早越好，从需求分析和设计阶段参与，可以有效的对需求和设计审查，尽早的发现风险，风险提前暴露，以免项目偏移预期过多。对于增量式开发也同样，开发新的功能和新的模块，测试人员可以在设计阶段提前准备测试计划，考虑测试用例、代码覆盖等。在开发过程中，也可以对阶段性的开发成果进行测试，越到开发后期测试，投入的成本往往过高，时间保证也越加困难。

　　四、频出BUG是软件测试人员的问题

　　这个误区大部分IT人员已经纠正，但是还是要强调的是：软件测试的目的是尽量多的发现软件中的问题，找出软件的潜在危险，尽量的保证软件的高质量。但是不能说软件出BUG就是软件测试人员没测试出来。不管一个软件团队中有没有专业的测试人员，整个团队的目的是一致的，即交付高质量的可用的软件。开发人员提高代码质量，写单元测试，是为了提高软件质量，测试人员利用各种手段测试软件，找出软件的问题，也是为了提高软件质量，只有各个环节共同努力，目标一致，才是正确之路。

　　五、上线频出BUG是测试时间不够的事情

　　软件开发过程中，软件质量和时间有直接联系，那么如何在有限的时间内，达到质量的标准是软件项目管理中经常思考的问题，对于小型开发团队来说，各团队提升软件测试质量的方法各异，往往很多团队采用的提高单位软件测试时间内的产出。时间是后勤保障，同时测试方法是武器，有了强大的武器才能战胜敌人。比如说制订详细的测试计划，使软件的功能性需求和非功能性需求的全面覆盖，同时提高测试人员的有效产出，合理的安排测试人员的测试工作，减少重复测试，减少无用功。

　　六、测试就是点表单

　　功能测试的很多工作主要是测试表单，以确定功能是否按照需求执行，是否达到预定的效果，但是点表单也是需要一定的逻辑和方法，不能没有目的的去“点表单”。即使没有事先准备测试用例，开始“点表单”工作之前，最好在纸上形成测试路径及测试目标，保证测试工作的顺利进行，同时也能避免遗漏。

　　最终，基于小型开发团队的特点，所有的问题归结于投资收回率和实用主义。针对软件开发过程中具体环境和开发团队的状态，充分考虑时间、成本，结合测试理论和方法，也可以借助自动化测试工具等，制订有效的，可行的的测试方案，来提供软件质量。