项目功能验收阶段的小问题

在进行项目管理过程中，每个迭代或每个阶段的任务功能验收是一个必不可少的环节。

特别是项目团队成员较多，任务功能分散的情况中。

本文就个人工作中情况，技术上介绍下功能点验收流程遇到的小问题。

本司有一套对feature、story进行管理工具。迭代结束时亦是基于上面的feature、story由QA进行验收。

功能验收标准，主要有以下几条：

输出	具体要求	是否必要
单元测试用例	提供UT，代码行覆盖率>=60%	是
功能测试用例	提供RF，目前只要求运行通过	是
系统测试用例	由测试部测试人员提供	N/A
接口文档或使用说明书	作为功能开发辅助输出	否

单元测试用例在开发过程中起着举足轻重的作用，相信每一个专业的开发者，必定也会重视。所以目前团队中针对单元测试用例行覆盖率才有了60%的硬指标。这里需要吐槽也就是60%的指标。

团队采用的是IDE环境中的runCoverge进行验证，如图：

QA关注的重点，即line的百分比，超过60%则通过。

但现实是，存在一些模块由于辅助代码较多，较难达到60%的情况的（换句话说50%已经足够了）。由于一刀切的缘故，测试用例的原来本意出现了偏差，开发人员开始想法设法提供行覆盖率，而不是提高用例本身的质量。这边列举了几个：

• 将低覆盖率的代码暂时注释掉，先通过验收，再恢复
• 写一堆反射方法，测试用例中触发调用无测试意义的代码
• 将一些功能代码直接删除，先把数据提高再说

哎，上有政策下有对策。而其带来的不好影响也显而易见。如占用开发大量时间、无用测试代码占用编译时间，版本构建时间超长、代码质量下降等。（刚刚遇到的问题是一次代码gerrit提交，模块编译时间达20分钟以上，也曾经花费一天才完成一个commit的提交，心力交瘁）

 

项目以前也使用过jacoco进行检查，但不知为何没有推广。由比上面的验收方法来说，jacoco显得专业的多，插件自身功能就不说了。列了几个管理上的好处：

1、每次编译都会产生覆盖率报告，QA随时查看、监控数据。避免开发人员动手脚。（每日构建通过UI进行数据展示，不知小伙伴知不知道有什么好的软件）

2、通过plugin配置，过滤掉无测试意义的代码，如BEAN对象。给足开发人员空间。

3、QA通过检查2中配置，把控测试用例质量。

 

附上配置：

           <plugin>
                <groupId>org.jacoco</groupId>
                <artifactId>jacoco-maven-plugin</artifactId>
                <version>0.8.0</version>
                <configuration>
                    <excludes>
                        <exclude>**/com/x/x/x/sal/compat/postgre/impl/NN*.class</exclude>
                        <exclude>**/com/x/x/x/sal/compat/postgre/impl/*Test.class</exclude>
                       <exclude>**/com/x/x/x/sal/compat/SchemaContextHelper.class</exclude>
                        <exclude>**/com/x/x/x/sal/compat/postgre/impl/cli/*.class</exclude>
                    </excludes>
                </configuration>
                <executions>
                    <execution>
                        <id>report</id>
                        <phase>prepare-package</phase>
                        <goals>
                            <goal>report</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>