本文是本人多年工作所得出的经验和教训，采取言简意赅的短文字方式方便读者迅速阅读，也采纳了本人认同的的测试思想或见解。不过正因为字数少，所以希望读者能反复阅读和体会。有不当不对之处或者希望与本人沟通交流，请留言。
人工测试
1.人工测试的重要性仍是第一位的，尽管现在自动化测试如火如荼的发展着，但很多重大缺陷依然需要通过人工测试的方式才能发现，因为测试策略才是根本，人工测试在这里充分体现出了其灵活多样的特性，尤其是有意识的进行探索式测试；
2.一个经验丰富，能力较强的只会人工测试的测试工程师的价值肯定大于一个一般的自动化测试工程师；
自动化测试
1. 如同业务功能测试是测试的基本能力一样，自动化测试也正在成为测试人员的基本能力；
2.在深刻理解需求的基础上，自动化测试用例要能体现如同文本测试用例的基本编制要求：“精炼表达、主次分明、渐进可用”；
3.自动化测试的最大用途在于执行回归测试；
4.对一个产品/项目能做到80%的自动化测试覆盖就很不错了；
自动化测试金字塔
Test Automation Pyramid（测试自动化金字塔）
1.UI Tests：也称 GUI 测试，稳定度最低，只有长期且比较稳定的产品/项目适合开展自动化UI测试；否则很可能会导致成本大于产出，甚至完全成为花瓶；
2.API Tests：接口测试。当下提供的大都是HTTP API，相对稳定，适合自动化测试；
3.UNIT Tests：稳定度最高，开发人员应该采用TDD（Test Driven Development,测试驱动开发），实在不适应也应该有相应的单元测试；
4.在这里纠正一个观点：单元测试是测试人员来写的。正确的应该是开发人员来编写，对自己的行为负责！
5. 从上图中可以看出，单元测试应该占有最大的比例，其次是接口测试，最后才是基于图形界面的功能测试，可是很多测试团队都搞反了，所以结果很不理想。
6.个人建议自动化的单元测试也在短期和变化较大的产品/项目中开展；自动化的接口测试在中长期和较稳定的产品/项目中开展。
持续集成的做法
1.采用TDD或者开发人员编写单元测试代码；
2.采用自动化测试，尤其是自动化的全回归测试，包括单元测试，接口测试和UI测试；
3.开发提交代码到版本服务器后触发条件自动取得最新代码并自动编译，编译通过后自动执行其他脚本（如数据库），接下来自动执行单元测试和接口测试，测试通过后最后自动打成安装部署包。部署到测试环境后再开始自动化的UI回归测试。
持续交付
1.有了自动化测试和持续集成这两个作为前提，经过自动化部署，就可以达到持续交付。
采用敏捷测试模式
1.坚持实施Scrum,虽然会议会占用一定的时间，但这点时间对于团队成员间的沟通和协调是必不可少的；
2.这世界变化快，编写敏捷测用例，重点是写出测试用例的测试点而无需详细的操作步骤；
3.敏捷测试需要测试人员能够随时启动自动化的回归测试对马上发布的迭代代码进行快速验证。
测试策略
1.APP功能以手工测试为主；当前针对APP的自动化功能测试还不够成熟，稳定性不够，可以继续实施以敏捷测试用例为核心的策略，结合探索式测试；
2.WEB功能以自动化UI测试为主(短期，变化很大的产品/项目除外)，结合探索式测试；
3.WEB/APP的性能，安全性测试以工具测试为主；要不断发现、开发和学习使用各类工具，以帮助我们更有效率地完成任务；
4.WEB的兼容性测试还是人工方式，采用每个迭代内测试不同浏览器的方式即可；
5.APP的兼容性测试要采用第三方公司的云测试的方式；
6.开展单元测试和接口测试且最好全部实现自动化测试；
7.尽早测试，经常测试，充分测试。
