Android开发-----项目开发与测试

项目开发流程

从事开发工作这些年, 经历了一些公司和项目组, 绝大多数公司的项目开发流成是这样的:

从需求的提出(需求评审)到设计(评审阶段),再交由开发人员进行功能开发,当开发人员开发完功能后, 提交给测试人员进行测试(少部分公司, 在开发人员提交给测试前会验证测试人员编写的自测用例进行代码自测)

这种开发流程算是"主流(大多数)"的方式, 但是在实际过程中存在一些问题, 比如:
1). 开发人员在需求评审阶段, 并没有彻底的理解需求, 往往是在写代码过程中还存在对需求理解不到位的地方, 这个时候开发人员往往会去找产品进行, 这样反反复复的过程其实就增加了不必要的时间成本
2). 开发完成后测试阶段, 此时测试人员测试出bug, 然后再交由开发人员修复, 然后再提交给测试...如此反复, 此时

• 有可能测试人员临时从其它项目组抽调来协助, 或者是一名新入职不久的同事, 并没有参与需求评审, 那么他在测试时可能并没有完全理解需求, 会提出一些"不是bug的bug"
• 测试过程中, 可能会发现一些需求并不明确的地方, 然后再与产品沟通, 说不定还有可能由此更改需求, 从而导致开发人员去修改已经编写好的业务代码

综上, 其中反反复复的环节, 导致看似流程清晰明了, 但是实际开发效率并不理想. 更有甚者, 可能项目已经到了测试阶段, 然后由于发现有需求不明确的地方,又重新商定需求,再临时的去更改代码..., 而一般到达测试阶段的时候, 离版本上线时间已经不远了,
长此以往, 导致项目代码质量越来越低, 并且时间成本也在增加

测试驱动开发(TDD)

TDD的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。
TDD的重要目的不仅仅是测试软件，测试工作保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员去除模棱两可的需求。
TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证

简要概括, 其实是围绕测试来推动整个项目的进行, 主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证;

但是这种方式的在对于项目代码质量的把控方面,有绝对的优势; 同样劣势也比较明显, 开发人员往往要额外编写几倍于业务代码的测试代码, 这样会增加额外的开发时间

均衡传统流程与TDD流程的构想

对于上述两种方式, 我个人其实构想了一种均衡的方式, 在需求评审后和开发人员开发前, 会有UI设计阶段, 在此阶段时, 测试人员需要编写交给开发人员自测的自测用例,
在进入开发阶段时, 开发人员根据自测用例来编写功能代码, 需要保证所编写的功能代码能够跑通自测用例,
而开发完成进入测试阶段时, 测试人员更多的是充当一个"检测员"的角色, 主要是验证app是否通过了自测用例

但是这种方式, 我所能想到的直接缺点是, 对自测人员能力有一定要求, 测试人员需要用近乎UI设计的时间, 编写一份自测用例交付给开发人员

关于单元测试

对于项目开发时是否要编写单元测试, 现实情况, 我确实没遇到几个写单元测试用例的, 虽然android每次创建都会带有的junit和espresso;
至于为什么不愿意写单元测试, 不少原因是"开发时间不够", 不得不说这个问题的确存在, 如果编写单元测试,至少要额外编写两倍的功能代码,的的确确会需要不少的开发时间;
但是如果把视角放在整个项目的开发周期上来看, 如果开发人员能够熟练的编写单元测试, 并且根据实际情况选择性的编写, 实际能一定程度上节约开发时间

@end

参考:
《代码整洁之道》
《重构-改善既有代码的设计》
Android单元测试研究与实践 ----- 美团技术团队