一、软件测试的基础
抽样：对场景/路径和数据抽样。故而，不可能穷尽所有的路径和数据。
ps: 要想在所有可能出现问题的地方穷尽测试，要么功能极其简单，要么测试员想象力差。
二、最佳实践
不相信最佳实践，在一定条件下，一些实践比另一些要好
三、测试在项目中的作用
在产品交付前，及时使用【质量问题】进行了各方敲打，可能最终的问题仍然归于敲打不彻底；
项目中各个功能离“悬崖峭壁”还有多远；
注意：
过于偏重某一方面，而忽略另一个方面；
与产品，开发，UI等协调关注点；满足其需要；
个人的理解：
- 测试与用户在使用的根本差别
用户： 带着问题，需求，迫切需要一个方案；
-
测试与程序员，产品的差别区别： 客观性医不自治， 医生能给别人治病却不能给自己治ps:写工具/框架时，尽管自己也随时测试；感觉比程序员好一些； 但同时一定不再是一个合格的测试员了(初级测试员)
四、测试的理想情况
理想情况：
程序员为了修改测试员找出的问题忙的团团转，使得程序员，而非测试员，成为项目的瓶颈。
ps: 虽然是终极目标，但由于项目本身的特性(UI比重，上下游，项目本身的复杂程度等)，能够实现自动化的程度不同，有些场景是必须复杂的手工才能确保万无一失的。
测试前，中，后， 有效的提出问题；
测试： 不仅知道可以干什么，还知道： 不能干什么，错误路径应该傻瓜式提示；
尽早避免用户在使用产品中的消极情绪的出现；
不会发现所有问题，故而合理分配测试时间更加重要
五、通过测试不能保证质量
测试通过： 在某些条件/场景下，系统没有发现异常/可正常工作。并不能保证所有场景/条件均正常。系统不可能通过测试达到100%的质量。不能证明100%正常，只能证明在一定条件下没有不正常。
测试目标：目前条件下做到最好
六、当心成为过程改进小组
过程改进需要真个团队的参与与执行，并非测试员一个角色的工作
七、测试员的素质
- 测试需要自我驱动。质量的把握程度需要测试员自我驱动去“精益求精”。
- 认识论-批判性思维。抱着“问题心态”去审视产品。
- 推理思维。根据现有“证据”推理更多可能的问题所在，并找出更多的证据加以证明
- 判断力。需要采用各种手段将预期结果与实际结果做对比，并对对比结果加以筛选和判断(个人理解： 测试的整个过程，某个角度可以说是对比)。
- 视野。产品的理解，测试手段的理解
- 复杂产品的陷入和退出。在测试特别复杂的产品时，需要适时地陷入和退出，不能指望快速理解复杂产品，可以理解30分钟后，干点别的事情。
- 不能避免偏向，需要管理偏向。每个人都是自己的擅长与盲点，下意识。例如同样一个输入框，人员A可能输入混乱的字符，人员B可能下意识输入类似“111111”、“222222”类似的字符。测试员虽然不能避免类似的偏向，但需要适当管理，比如模拟不同偏好用户操作、利用不同方法相互印证等等
- 观察和学习
八、探索测试
所有的测试都是采样，样本永远不可能完备，探索式思考在最大化测试价值中起作用。
探索测试同时需要大量的思考和联想，才能发挥功能测试不可完成的作用。
九、不要期望需求的完整性
不同成熟度的产品需求，由于都是由某个/某些人提出的，必然存在可推敲，可完善，甚至需要改进的地方。
十、测试策略的完备
- 遗漏一个问题，是偶然还是必然
如果是偶然，比如不同人员执行问题，理解问题，那么测试策略本身不需要改变；
如果是必然，那么就要去修改测试策略本身了。
通过遗漏的问题本身，也是一个反向检查测试策略完备性的一个方法。
- 困惑也是一种测试工具
测试中遇到的产品困惑，应该作为需求/设计方面的问题，向产品提出。测试员的困惑往往也是用户使用时的困惑。
另外最大化减少产品使用困惑的方法，便是加入用户内测了，让真正用户，或内部人员参与上线前的内测。
ps:测试策略中当然需要包括用户体验方面的测试
- 避免测试惯例
理解事物，把新信息吸收到已知信息中，同时修改已知信息来适应新洗洗的高智力过程。测试员在理解产品/功能后，在头脑中形成映射，
随着对产品的了解，逐渐从各个方面提高对产品的反应能力和敏感性，并且头脑不再那么努力工作。
对测试员来说，可能是个问题：非常了解产品后，会对产品做出更多的假设，并更少检查这些假设，以越来越窄的方式进行测试，这便是测试惯例。
避免的方法:
1）特别留意自己困惑和烦恼的地方；
2）与新成员一起工作时，观察他们了解产品的反应；
- 根据产品成熟度来制定测试策略
十一、清晰报告问题，而非解决所有问题
测试员应该清晰报告所有问题，但不要试图解决所有问题。提出bug的同时，是否要花时间去“独立”找问题的根源，应该依照实际情况而言。测试的执行过程是一个极具思考用例、执行用例、对已有问题联想的不易“中断”的过程，如果发现一个问题，需要停下来去找问题的根本原因，很可能打断甚至打乱了原本的思路，甚至错过了本该尽早发现的问题。
十二、不要强行解决所有问题，要量力而行
- 可能引入更多的问题
- 项目周期不允许
- 问题本次没有达到非修不可的程序
十三、自动化测试
- 自动化目标
迅速检测新版本中不稳定的变更
尽可能迅速暴露回归程序问题
快速报告问题
- 自动化范围
范围：
冒烟测试
单元测试
功能测试
性能测试
- 自动化实施
不要强求100%自动化
界定非自动化不能完成的部分
自动化实施前要求测试员具备较好的测试策略理解和自动化实施方案，否则自动化转移测试员的注意力
- 自动化vs手工测试
自动化测试是手工测试的补充，能够完成手工测试不能完成的工作
- 测试自动化是一种投资(要充分考虑)。测试自动化设计要尽可能完善。与实现尽可能解耦，避免产品升级导致的自动化成本
十四、测试管理
- 测试团队需要不同背景，不同专长的人员
- 超出公司，制定自己的发展规划。哪怕公司倒闭，你的发展规划应该是不变的。