标签：
《IBM-从菜鸟到测试架构师-一个测试工程师的成长日记》
Warning
IBM的业务性质是做大型企业的IT解决方案，仍然属于比较中规中矩的传统企业。所以对传统的软件企业有比较大的借鉴意义，但是对于互联网等新兴企业的从业人员，还是采取保留式的态度，取其精华即可。
1968年NATO会议提出了“软件危机”：
测试的理论及实践已经逐渐完善，但是测试的方法和体系却缺乏完整性的讨论。
确定软件从安装到使用及至后期维护的稳定性和健壮性。
测试是一个严谨、全面而有条理的过程
除了小型项目，进行完全（各种输入和前提条件的组合）的测试是不可行的。需要动用风险分析和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试。
定义：开发人员针对程序模块（软件设计的最小单位）来进行正确性检验的测试。
单元测试是和开发最接近的一种测试
由开发人员编写。开发人员编写单元测试用例并执行，验证单元模块是否得出预期的结果
子系统只有通过单元测试之后才集成到大系统中
定义：指测试人员可以直接访问内部数据结果、算法及其代码实现的测试。
常见的方法：
定义：通过黑盒模式发现代码集成后存在的功能问题的测试。
和 单元测试 的区别：粒度不同。
验证软件的非功能性需求的测试
通过自动化的方法模拟真实用户并发访问的场景
形成良好互补，2/8原则
创造性的工作交付人来做，重复性工作交付机器来做
大项目适合自动化测试，小项目适合手工测试
估计自动化脚本开发的必要性：
小规模项目成本对比图：
分析：
大规模项目成本对比图：
分析：
自动化从各个模块的源码构建组装成一个完整的产品
构建前自动完成相应的测试工作
对于通过测试的构建好的产品，做好成品测试后，自动化部署到生产服务器
自动化脚本的开发工作并不是越早越好，而是应该基于稳定的测试环境和测试计划。
有经验的测试工程师，是会在效率和质量上寻求平衡点，把精力集中在最容易出问题的点上。
这和另外的思路“最好的文档就是产品本身的代码”有所出入。
完全的TDD是不适合大多数公司的。毕竟测试是属于上层建筑，建立在已有的开发产品上的。
| 作者: | Harmo哈莫 |
|---|---|
| 作者介绍: | https://zhengwh.github.io |
| QQ: | 1295351490 |
| 时间: | 2015-08-24 |
| 版权说明: | 未经许可，严禁用于商业目的的非法传播 |
| 联系或打赏: | http://zhengwh.github.io/contact-donate.html |
标签：
原文地址：http://www.cnblogs.com/beer/p/4805146.html
