“黑盒测试管理”以外的编程经验片断

　　1、架构和算法的可行性测试分析：主要包括性能、并发等方面

　　2、CodeReview：很简单，但很多人没有这样做；其实这比“黑盒测试”更轻易发现边界问题、流程正确性问题等。值得推广！

　　3、测试驱动和单元测试，很多人为了达到那些并不太懂编程治理层的要求，往往是少了这些看似不轻易出成绩的步骤。（很大程度上改变设计思维）

　　知道可能出错的地方，当然轻易避免出错。

　　4、UML和用例：非凡是UI建模，个人觉得最不可少；UML和用例至少要能覆盖核心内容。

　　具体如何做，要根据每个人、每个单位甚至每个项目做具体优化，这里提供思路。

　　5、专心架构（各功能模块的关系%26lt;用例等%26gt;、分布式计算的节点关系%26lt;即分层%26gt;、类的层次结构%26lt;UML图%26gt;、升级的备案、数据库架构、数据库表的范式%26lt;ER图%26gt;、并发访问和多线程等）：不好的架构，Code起来吃力、问题又多又不好解决！以个人的经验认为，一般可分为六个阶段:

　　A 用户需求收集、访谈和确认--%26gt;
　　B 架构和可行性分析并文档化--%26gt;
　　C 开发测试部署和维护具体计划--%26gt;
　　D1 单元编码、测试%26lt;--%26gt;
　　D2 部署测试--%26gt;
　　E1 开发环境集成和测试--%26gt;
　　E2 真实环境模拟测试--%26gt;
　　E3 部署预演--%26gt;（原系统备份）--%26gt;
　　F 部署

　　1) 各阶段主要的“产出”（不考虑投入）
　　A：需求说明书、UI建模、用例和UML图和系统使用帮助文件初稿、系统可能存在的风险报告
　　B：系统架构图（逻辑图和物理图）、核心算法代码和测试报告、第二方和第三方组件的风险分析报告
　　C：系统各模块的具体说明书，数据库架构和测试，各功能的开发、CodeRivew和测试计划、部署计划（相当于每日构建）、集成测试计划、系统的升级考虑和方案。注重，尽可能在Code前将数据库可能的问题解决掉！
　　D：代码、BUG治理、可执行文件、开发环境、测试环境
　　E：可发布的安装包、最终用户文档、修改之前相关的文档到和现在的系统一致
　　F：可能的问题预案、安装和不断依实际情况优化，进入维护阶段

　　2)时间分配：A:B:C:D:E:F=10:10:20:50:5:5，A阶段的时间这里指项目启动时算起，启动前的时间不计在内。

　　真正的Code时间一般可能占50%

原文转自：http://www.ltesting.net