实用的测试理论-笔记

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的处理流程