这几天，将图书馆借来的《从菜鸟到测试架构师》这本书看完了；尽管作为有5年测试经验的人来说，这本书可能比较基础、深度不够，而且有不少IBM特有流程、工具，不过其中还是有一些值得学习的地方，测试新人来看看此书，估计还是能有不少收获。有看书记笔记的习惯，记录书中的一些对自己有用的知识点吧。
像外行一样思考，像专家一样实践。
将测试步骤做成一个个ANT target，再设计一个target去一次调用其余target，这样就可以用ANT将测试用例自动化。（ANT做自动化测试的思路还是不错的）
BVT（Build Verification Test，构建测试），一般是在一个测试产品生成后，构建测试团队执行一组最基本的测试用例，来确定做成的测试产品是否达到可以交付到各个测试组来进行更全面、更深入的各项测试的要求。
UT（Unit Test，单元测试）的特点和作用：1. 保证代码的质量； 2. 更容易发现缺陷； 3. 可重复执行； 4. 代码更容易维护； 5. 解决缺陷的成本更低。
如果没有足够的单元测试，则：1. 功能测试发现大量的单元测试层面的缺陷，功能测试无法投入更多的时间做更复杂的事情； 2. 系统集成测试阶段被大量的功能缺陷困扰； 3. 性能测试无法做充分的性能测试（或进度受到影响）； 4. 客户环境可能发现更多的功能或性能缺陷。
UT测什么？ 单元测试要覆盖到边界值和正常输入，也要测试每个方法的出错条件和无效输入；另外，开发人员还要在单元测试层面保证代码满足国际化、API兼容性及可测试性的要求。
一些单元测试工具：JUnit, JUnitEE, DbUnit, JsUnit, JTest
TDD（Test Drive Development，测试驱动开发）的流程是：1. 在实现功能之前，先考虑代码的使用需求，为其编写测试代码； 2. 让新写的测试代码和已有的测试代码一起运行； 3. 为新功能编写最少的实现代码，注意，是最少的实现代码； 4. 再次让新测试代码与已有测试代码一起运行，根据结果修改实现代码，知道全部测试代码通过； 5. 在此过程中，积极地对代码进行重构，使底层设计和实现更加优化，使接口更加简单； 6. 重复前面1~5步骤，直到完成全部功能的开发。
功能测试人员的素养：既要在广度上熟悉各种功能测试技能、工具、流程，又要在深度上理解产品、功能测试策略。
压力测试的目的：发现并解决在并发、长时间或者大数据量的情况下才出现的系统缺陷；验证在制定并发用户数下能达到既定的吞吐量。
自顶向下和自底向上的两种分析系统（性能）问题的方法；自底向上更适合于经验丰富的专家使用。
IBM的敏捷：”Use of continuous stakeholder feedback to deliver high quality and consumable code through user stories and a series of stable, short, time-boxed iterations”.
stakeholder（利益相关者）：高层管理人员、内部人员、合作方、最终用户。
用户故事（User Story）：As a
Scrum团队中的三个角色：1. Scrum Master； 2. Product Owner； 3. Team。
在Scrum中，一个迭代周期被称为一个Sprint（冲刺）。
Sprint包括开发工作和一些关键会议：Sprint Planning Meeting（确定做什么和怎么做）; Sprint Review Meeting（评审会议）； Sprint Retrospective Meeting（回顾会议）； Daily Scrum Meeting（每日站立会议）。
Scrum中提高关键信息透明度的工件：产品Backlog、Sprint Backlog 和 燃尽图。