1.开发模型演化：瀑布模型-v模型-w模型-迭代模型-devops模型
不同模型下软件测试的工作方法完全不同
2.传统软件测试对文档及其重视，其实，文档并不是最重要的。传统的软件测试理论中，测试人员极端重视文档，是因为在很多年前的软件测试中，很多软件项目采用瀑布模型。
3.瀑布模型逐渐被淘汰了，因为：效率低下
4.迭代模型下，需要频繁发布。发布次数越多，越需要自动化测试。此外，迭代模型的紧凑型导致了测试人员不再像以往那样依赖文档，因为需求整天改。测试人员开始尝试以思维导图等更简洁的方式来替代测试用例设计文档。测试人员在迭代模型中，真正开始介入项目前期。
5.开发模型的进化逐步打破了手工测试不可替代的神话。手工测试可以替代，用例设计不是软件测试人员的核心竞争力。
6.测试和核心是效率，效率要高必须自动化。所以，测试人员的核心竞争力必须是技术能力。
7.坚持“实事求是”原则的测试方案：
A.测试目标是什么：
（常见的是：找到重要的bug，使他们得到修复、对是否发布产品的决策提供帮助、评估产品和实际需求的一致性）
B.怎样组织测试，以实现测试目标：
b1.对于发现的bug是什么样的重视程度，为什么？
b2. 什么样的bug的重要性比较高，为什么？
b3. 工作所做的文档应细致到什么程度，为什么？
C.假设程序有一个数字输入域，在需求文档上说明了，这个域必须能够接受一位的数字作为输入值，但是没有说明如果输入字母或者符号等等，系统会如何反应。那么你应该去测试输入字母或者符号的情况吗？假如，现在这个项目的时间非常紧急呢？
8.怎样确定一个项目的测试依据：
1.有没有标准的需求文档
2.能不能开会讨论需求
3.有没有了解需求的人
4.可不可以由测试人员或其他角色的人学习需求或通过操作现成软件等方式尝试汇总需求
5.能不能结合相关企业标准、行业标准、国家标准、国际标准等给项目设置一个大前提的需求
6.是否可以参考同类软件
7.有没有真实用户的反馈
8.有没有违背常识的功能
9.有没有犯法的功能
10.有没有影响安全相关的问题
11.有没有影响性能的问题
12.有没有影响用户体验的问题
9.当没有测试依据的时候，怎么做测试：
结合常识、竞品同类功能、用户体验等，杜撰一个依据，然后问需求提出方对这个需求有没有意见。把这个依据抄送全组作为证据。
另外一种情况，当新加入一个项目组时，你不知道测试的依据是什么。这种情况务必多提问，可以把问题整理出来，以问题列表形式发给他们，而不要自己想当然得觉得需求应该是这样。
10.我们需要在承认测试的不可穷尽的前提下，通过技术的手段，尽量提高测试的效率，在有限的时间和资源下，尽可能多测一些。
11.覆盖率所无法发现的bug：
1.输入特定的某个值或者某组值（代码路径是覆盖了，但无法覆盖所有输入值，等价类也不一定靠谱）
2.在编码中遗漏的代码（虽然覆盖率100%，但是开发漏掉的代码覆盖不到）
3.中断，以及其他并行操作的情况（代码可以覆盖，运行环境上的系统中断却无法覆盖）
4.需求中包含的错误（从一开始就错了，测试覆盖再多错误的逻辑又有什么用）
5.兼容性方面的错误（比如让app运行在不同平台或在不同浏览器上打开网页）
6.配置错误（不是代码的错误，代码覆盖率100%也测不到）
7.性能问题（又是一种覆盖率无法覆盖的问题）
这些问题有一个共同点，即使你代码覆盖率硬生生推到100%了，仍然对这些问题无能为力或者说对减少与发现这些问题毫无帮助。
12.“测试人员不再发现新的bug就代表测试穷尽了”是错误的观念。
原因如下：
1.每周做的工作并不是完全等价的。还有可能是后面几周开发新提交的代码少了，所以bug发现的也少了。只看曲线是无法看出测试是否足够的。
2.心理因素驱使测试人员后面几周不如前面几种那么“用力”地找bug，去迎合这个曲线。
13.系统是不会自然而然稳定的，能不能稳定取决于测试设计和探索性测试到底做的好不好，以及取决于新代码量是否减少了。
14.我们在项目有限的时间内，是可以通过制定计划，然后让团队去评审这个计划，来限定我们的测试范围的。这样，虽然测试不能穷尽，但我们可以有效的缩减测试范围。计划的要点之一是缩减测试范围，化无穷为有限。
15.bug汇报和处理流程：
考虑bug是什么，质量的多维度性，测试人员考虑各个角色的看法，bug的处理流程