黑盒测试 简单讨论

黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。黑盒测试试图发现以下类型的错误：

　　1）功能错误或遗漏；
　　2）界面错误；
　　3）数据结构或外部数据库访问错误；
　　4）性能错误；
　　5）初始化和终止错误。
　　
白盒测试在测试的早期采用，而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构，而是注意信息域。黑盒测试用于回答以下问题：

　　·如何测试功能的有效性？
　　·何种类型的输入会产生好的测试用例？
　　·系统是否对特定的输入值尤其敏感？
　　·如何分隔数据类的边界？
　　·系统能够承受何种数据率和数据量？
　　·特定类型的数据组合会对系统产生何种影响？
　　
运用黑盒测试方法，可以导出满足以下标准的测试用例集：

　　1）所设计的测试用例能够减少达到合理测试所需的附加测试用例数；
　　2）所设计的测试用例能够告知某些类型错误的存在或不存在，而不是仅仅与特定测试相关的错误
1、架构和算法的可行性测试分析：主要包括性能、并发等方面
2、CodeReview：很简单，但很多人没有这样做；其实这比“黑盒测试”更容易发现边界问题、流程正确性问题等。值得推广！
3、测试驱动和单元测试，很多人为了达到那些并不太懂编程管理层的要求，往往是少了这些看似不容易出成绩的步骤。（很大程度上改变设计思维） 知道可能出错的地方，当然容易避免出错。
4、UML和用例：特别是UI建模，个人觉得最不可少；UML和用例至少要能覆盖核心内容。 具体如何做，要根据每个人、每个单位甚至每个项目做具体优化，这里提供思路。
5、用心架构（各功能模块的关系、分布式计算的节点关系、类的层次结构、升级的备案、数据库架构、数据库表的范式、并发访问和多线程等）：不好的架构，Code起来吃力、问题又多又不好解决！以个人的经验认为，一般可分为六个阶段
A 用户需求收集、访谈和确认-->B 架构和可行性分析并文档化--> C 开发测试部署和维护详细计划--> D1 单元编码、测试<-->D2 部署测试--> E1 开发环境集成和测试-->E2 真实环境模拟测试-->E3 部署预演-->（原系统备份）-->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阶段的时间这里指项目启动时算起，启动前的时间不计在内。

转自：junzhongxu.cnblogs.com