软件测试——基础知识

软件测试的定义&软件的生命周期
软件测试工作流程&测试用例编写
bug相关知识
版本控制工具SVN的使用
计算机网络&Linux操作系统
项目笔记
数据库
抓包工具
接口测试Jmeter
APP测试项目笔记
Git&Java基础知识
Jmeter & Jenkins & Maven
性能测试

这段时间十分焦虑，最开始的求职目标是产品经理，但是发现在准备过程中自己一直不自信，仔细分析之后发现，这种不自信完全是来自于对自身能力的不认可，或者说就是能力不够，优秀的产品经理都是通过项目磨练出来的，可是我没有，怎样能改变呢，那就曲线救国吧，自己是工科学生，但是对于技术其实自己却没有真正踏踏实实去钻研，软件测试是给自己的一个挑战，从现在开始完全沉下心来为它做准备，确定方向之后便只顾风雨兼程！三个月之后我要看到一个不一样的我，有你陪着我什么都不怕~加油！

软件测试的定义

1. 软件测试
   一个过程或者一系列过程，用来确认计算机代码完成了其应该完成的功能，不执行其不该有的操作。** 测试是为发现错误而执行程序的过程。**
   一次成功的测试是指：在对某段程序进行经过合理设计并得到有效执行的测试过程中，发现了错误并且这些错误是可修复的。如果本次测试可以最终确定再无其他可查出的错误，同样也被称作是成功的。
2. 软件测试的原则
   原则一：测试用例中一个必需部分是对预期输出或结果的定义
   一个测试用例必须包括两个部分：对程序的输入数据的描述；对程序在上述输入数据下的正确输出结果的精确描述。
   原则二：程序员应当避免测试自己编写的程序
   原则三：编写软件的组织不应当测试自己编写的软件
   原则四：应当彻底检查每个测试的执行结果
   原则五：测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入情况
   原则六：检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”
   原则七：应避免测试用例用后即弃，除非软件本身就是一个一次性的软件
   原则八：计划测试工作时不应默许假定不会发现错误
   原则九：程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比
   错误总倾向于聚集存在，为了使测试获得更大的成效，最好对这些容易存在错误的部分进行额外的测试。
   原则十：软件测试是一项极富创造性、极具挑战性的工作

一个好的测试用例具有较高的发现某个尚未发现的错误的可能性；一个成功的测试用例能够发现某个尚未发现的错误

软件测试一些分类

• 黑盒测试
  数据驱动的测试或输入/输出驱动的测试。测试目标与程序的内部机制和结构完全无关，而是将重点集中放在发现程序不按程序规范正确运行的环境条件。
  测试策略：穷举输入测试

• 白盒测试
  逻辑驱动的测试。允许我们检查程序的内部结构，这种测试策略对程序的逻辑结构进行检查，从中获取测试数据（遗憾的是，常常忽略了程序的规范）
  测试策略：穷举路径测试（即如果使用测试用例执行了程序中所有可能的控制流路径，那么程序有可能得到了完全测试）

• 非基于计算机的测试（人工测试）
  代码检查
  主要包括两项活动：
  1）由程序编码人员逐条语句讲述程序的逻辑结构，在讲述的过程中，小组的其他成员应提问题，判断是否存在错误。
  2）对着历来常见的编码错误列表分析程序。
  [用于代码检查的错误列表]
  数据引用错误：

  是否有引用的变量未赋值或未初始化？
  1. 对于所有的数组引用，是否每一个下标的值都在相应维规定的界限之内？是否每个下标的值都是整数？
  2. 对于所有的通过指针或引用变量的引用，当前引用的内存单元是否分配？（虚调用错误，当指针的生命周期大于所引用内存单元的生命周期时，错误就会发生）
  3. 如果一个内存区域具有不同属性的别名，当通过别名进行引用时，内存区域中的数据值是否具有正确的属性？
  4. 变量值的类型或属性是否与编译器所预期的一致？
  5. 在使用的计算机上，当内存分配的单元小于内存可寻址的单元大小时，是否存在直接或者间接寻址错误？
  6. 当使用指针或者引用变量时，被引用的内存的属性是否与编译器所预期的一致？
  7. 如果一个数据结构在多个过程或者子程序中被引用，那么每个过程或者子程序对该结构的定义是否相同？
  8. 如果字符串有索引，当对数组进行索引操作或下标引用，字符串的边界取值是否有“仅差一个”（off-by-one）的错误？
  9. 对于面向对象的语言，是否所有的继承需求都在实现类中得到了满足？
     数据声明错误
  10. 是否所有的变量都进行了明确的声明？
  11. 如果变量所有的属性在声明中没有明确说明，那么默认的属性能否被正确理解？
  12. 如果变量在声明语句中被初始化，那么它的初始化是否正确？
  13. 是否每个变量都被赋予了正确的长度和数据类型？
  14. 变量的初始化是否与其存储空间的类型一致？
  15. 是否存在着相似名称的变量？
      运算错误
  16. 是否存在不一致的数据类型（如非算术类型）的变量间的运算？
  17. 是否有混合模式的运算？
  18. 是否有相同数据类型，不同字长变量间的运算？
  19. 赋值语句的目标变量的数据类型是否小于右边表达式的数据类型或结果？
  20. 在表达式的运算中是否存在表达式向上或向下溢出的情况？
  21. 除法运算中的除数是否可能为0？
  22. 如果计算机表达变量的基本方式是基于二进制的，那么运算结果是否不精确？也就是说，在一个二进制计算机上，10*0.1很少会等于1.0.
  23. 在特定场合，变量的值是否超出了有意义的范围？
  24. 对于包含一个以上操作符的表达式，赋值顺序和操作符的优先顺序是否正确？
  25. 整数的运算是否有不当的情况，尤其是除法？
      比较错误
  26. 是否有不同数据类型的变量之间的比较运算，例如，将字符串与地址、日期或数字相比较？
  27. 是否有混合模式的比较运算，或不同长度的变量之间的比较运算？如果有，应确保程序能正确理解转换规则。
  28. 比较运算符是否正确？程序员经常混淆“至多”、“至少”、“大于”、“不小于”、“小于”和“等于”等比较关系。
  29. 每个布尔表达式所叙述的内容是否都正确？在编写涉及“与”、“或”、“非”的表达式时，程序员经常犯错。
  30. 布尔运算符的操作数是否是布尔类型的？比较运算符和布尔运算符是否错误地混淆在一起？
  31. 在二进制的计算机上，是否有用二进制表示的小数或者浮点数的比较运算？由于四舍五入，以及用二进制表示十进制的近似度，这往往是错误的根源。
  32. 对于那些包含一个以上布尔运算符的表达式，赋值顺序以及运算符的优先顺序是否正确？
  33. 编译器计算布尔表达式的方式是否会对程序产生影响？例如，语句if（（x==0）&&（x/y）>z）对于有的编译器来说是可以接受的，因为其认为一旦“与”运算符的一侧为FALSE时，另一侧就不用计算，但是对于其他编译器来说，却可能引起一个被0除的错误。
      控制流程错误
  34. 如果程序包含多条分支路径，比如有计算GO TO语句，索引变量的值是否会大于可能的分支数量？
  35. 是否所有的循环都终止了？应设计一个非正式的论据或者证据来证明每一个循环都会终止。
  36. 程序、模块或子程序是否最终都终止了？
  37. 由于实际情况没有满足循环的入口条件，循环体是否有可能从未执行过？如果确实发生这种情况，这里是否是一处疏漏？
  38. 如果循环同时由迭代变量和一个布尔条件所控制（如一个搜索循环），如果循环越界（fall-through）了，后果会如何？
  39. 是否存在“仅差一个”的错误，如迭代数量恰恰多一次或少一次？这在从0开始的循环中是常见的错误，我们会经常忘记将“0”作为一次计数。
  40. 如果编程语言中有语句组或者代码块的概念（例如do-while或{…}），是否每一组语句都有一个明确的while语句，并且do语句也与其相应的语句组对应？或者，是否每一个左括号都对应有一个右括号？目前大多数编译器都能识别出这些不匹配的情况。
  41. 是否存在不能穷尽的判断？举例来说，如果一个输入参数的预期值是1，2或3，当参数值不为1或2时，在逻辑上是否假设了参数必定为3？如果是这样的话，这种假设是否有效？
      接口错误
  42. 被调用模块接收到的形参数量是否等于调用模块发送的实参数量？另外，顺序是否正确？
  43. 实参的属性（如数据类型和大小）是否与相应的形参的属性相匹配？
  44. 实参的量纲是否与对应的形参量纲相匹配？举例来说，是否形参以度为单位而实参以弧度为单位。
  45. 此模块传递给彼模块的实参数量，是否等于彼模块期望的形参数量？
  46. 此模块传递给彼模块的实参的属性，是否与彼模块相应形参的属性相匹配？
  47. 此模块传递给彼模块的实参的量纲，是否与彼模块相应形参的量纲相匹配？
  48. 如果调用了内置函数，实参的数量、属性、顺序是否正确？
  49. 如果某个模块或者类有多个入口点，是否引用了与当前入口点无关的形参？
  50. 是否有子程序改变了某个原本仅为输入值的形参？
  51. 如果存在全局变量，在所有引用它们的模块中，它们的定义和属性是否相同？
  52. 常数是否以实参形式传递过？在一些用FORTRAN语言编写的程序中，诸如CALL SUBX（J，3）的语句时很危险的，因为如果子程序SUBX对其第二个形参进行赋值，常数3的值会被改变。
      输入/输出错误
  53. 如果对文件明确声明过，其属性是否正确？
  54. 打开文件的语句中各项属性的设置是否正确？
  55. 格式规范是否与I/O语句中的信息吻合？
  56. 是否有足够的可用内存空间，来保留程序将读取的文件？
  57. 是否所有的文件在使用之前都打开了？
  58. 是否所有的文件在使用之后都关闭了？
  59. 是否判断文件结束的条件，并正确处理？
  60. 对I/O出错情况处理是否正确？
  61. 任何打印或显示的文本信息中是否存在拼写错误？
      其他检查
  62. 如果编译器遍历了一个标识符交叉引用列表，那么对该列表进行检查，查看是否有变量未引用过，或者仅被引用过一次。
  63. 如果编译器遍历了一个属性列表，那么对每个变量的属性进行检查，确保没有赋予过不希望的默认属性。
  64. 如果程序编译通过了，但计算机提供了一个或多个“警告”或“提示”信息，应对此逐一认真检查。
  65. 程序或模块是否具有足够的鲁棒性？也就是说，它是否对其输入的合法性进行了检查？
  66. 程序是否遗漏了某个功能？

代码走查&同行评分

软件的生命周期

软件生命周期时指软件从开始研制到最终被废弃所经历的各个阶段，在不同的阶段里，由不同的组织和人员执行不同的任务，需要消耗不同的资源。

• 瀑布型生命周期
  瀑布模型是将软件生命周期的各项活动规定为按照固定顺序而连接的若干阶段工作，包括问题定义及规划、需求分析、软件设计、程序编码、软件测试、运行维护等六个基本活动。如果有信息为未被覆盖或发现了问题，那么最好“返回”上一阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，就像瀑布一样。
  每个阶段按照规定的文档进行评审，评审完成后才能进行下一个阶段。
  
  优点：
  1）为项目提供按阶段划分的检查点。
  2）当前一阶段完成后，你只需要关注后一阶段。
  3）可在迭代模型中应用瀑布模型。
  4）提供一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
  缺点：
  1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
  2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
  3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
  4）瀑布模型的突出缺点是不适应用户需求的变化。

• V模型
  通过开发和测试同时进行的方式来缩短开发周期，提高开发效率。其形状像一个字母V，故称为V模型。
  对应关系：
  一般来讲，单元测试对应的是详细设计环节，也就是说，单元测试的测试用例是和详细设计一起出现的，在研发人员做详细设计的时候，相应的测试人员也把测试用例写了出来；集成测试对应概要设计，在做模块功能分析及模块接口、数据传输方法的时候，就把集成测试用例根据概要设计中模块功能及接口等实现方法编写出来，以备以后作集成测试的时候可以直接引用；而系统测试，就是根据需求分析来的，在系统分析人员作系统分析，编写需求说明书的时候测试人员就根据客户需求说明书，把最后能实现系统功能的各种测试用例写出来，为做最后系统测试作准备。验收测试与用户需求对应，是非设计流程。
  适用范围：
  V模型是一种传统的软件开发模型，一般适用于一些传统信息系统应用的开发，而一些高性能高风险的系统、互联网软件，或一个系统难以被具体模块化的时候，就比较难做成V模型所需的各种构件，需要更强调迭代的开发模型或者敏捷开发模型。

• 敏捷开发模型
  是一种以用户需求进化为核心（强调沟通、弱化文档）、迭代、循序渐进的开发方法。强调以人为本，专注于交付对用户有价值的软件。是一个用于开发和维持负责产品的框架。就是把一个大项目分为多个相互联系，但也可以独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
  
  敏捷开发的流程
  1）产品负责人将整个产品设计成产品代办列表。就是一个个需求列表。（可以理解为需求或者要做的事情）
  2）召开产品迭代计划会议，确定哪些需求是需要在第一个迭代中完成的，评估迭代的时间（建议是2-4周），得到相应的迭代周期任务列表。
  PS:提前发布功能需求列表，会议提倡所有团队人员参与。
  3）把迭代的功能需求写在纸条上贴在任务墙，让大家（自主认领）认领分配。（任务墙就是把未完成、进行中、已完成的工作状态贴到一个墙上，这样大家都可以看到任务的状态）

• 举行每日站立会议，让大家在每日会议上总结昨天做的事情，遇到什么困难，今天开展什么任务。（每日站立会议，是在每天早上定时和大家在任务墙前站立讨论，时间控制在15分钟内）

• 绘制燃尽图，保证任务的概况能够清晰看到。（燃尽图把当前的任务总数和日期一起绘制，每天记录一下，可以看到每天还剩多少个任务，直到任务数为0，这个迭代就完成了)
  PS:在开发人员开始开发一个任务时，需要找来对应的测试人员讲解该任务功能，以便测试人员有一致的理解，并且一开始就进行测试用例，自动化系统测试脚本的开发（若需要自动化测试的话）。
  4）评审会议是在迭代完成时举行，要向客户演示自己完成的软件产品，并获得客户的反馈。
  PS:很多用户对软件开发是没有概念的，他只知道自己有某种需求。所以就要通过不断的让用户看到产品的模型，这个过程用户才会逐步的对产品产生概念。
  5）最后是总结会议，以轮流发言方式进行，每个人都要发言，总结好的实践和教训，并落实到后续的开发中。不要流于形式。
  敏捷开发适用原则
  1）个人与互动：重于流程与工具
  ----强调人与人的沟通，所以尽可能要集中化办公。异地开发模式容易让人疲惫
  ----个人技能要提高。尤其对于架构师要求很高。
  ----管理者要多参与项目有关的事情。
  ---- 减少对开发人员的干扰，问题集中整理问。
  2）可用的软件：重于详尽的文件
  ----强调文档的作用。必要的文档是必须的，具有传承性。
  3）与客户合作：重于合约协商
  ----做好客户引导。客户都是想在尽可能短的时间内，交付尽可能多的功能。
  4）回应变化：重于遵循计划
  ----无理变化，举棋不定的结果，并不是说都需要及时响应，会导致很多浪费。

软件测试阅读书籍

• 《软件测试的艺术》 Glenford J.Myers （王峰 陈杰译版）