软件测试从是否运行程序的角度可分为静态测试和动态测试其中静态测试指的是不运行程序情况下对软件进行的测试。静态测试不运行程序分为代码走查和文档评审其实就是去看代码和文档。1.代码走查代码走读定义开发人员之间互相阅读代码检查其编写正确与否。意义只有理解了源代码才可以完成单元测试或者说快速理解源代码是完成单元测试的前提代码走读发现的问题比单元测试发现的更多、更快和更早单元测试发现不了不满足编程规范的问题快速理解源代码找出流程设计中的问题对原有代码进行优化。方式线上代码评审、线下会议。代码走查内容已编写的代码检查其是否符合编程规范行业规范、公司规范。2.文档评审定义对软件开发各个阶段输出的文档进行评审。内容需求文档评审设计文档评审测试文档评审测试计划测试设计、测试用例、测试报告等用户手册评审联机帮助文档评审等。动态测试运行程序并使用一定的测试方法和测试工具以发现软件缺陷按不同的划分方式可以划分出不同的类型如是否考虑软件内部结构可分为白盒、灰盒、黑盒测试。白盒测试根据软件内部的逻辑结构分析来进行测试是基于代码的测试测试人员通过阅读程序代码或通过使用开发工具中的单步调试来判断软件的质量。黑盒测试通过软件外部表现发现其缺陷和错误完全不考虑内部结构和处理过程。在程序界面处进行测试只是检查程序是否按照需求规格说明书规定正确实现。如果软件需求本身有问题或者规格说明书有误很难发现。灰盒测试介于白盒和黑盒之间的测试工作中用的比较多一般不直接这么叫也就面试可能问到。灰盒测试关注输出对于输入的正确性同时也关注内部表现但这种关注不像白盒测试那样详细完整只是通过一些表征性的现象、事件、标志来判断内部的运行状态。灰盒测试结合了白盒测试和黑盒测试的要素。黑盒测试设计方法等价类划分法边界值分析法错误推断法因果图法场景分析法流程分析法测试方法运用范围单元测试用白盒测试方法集成测试用灰盒测试系统测试和确认测试用黑盒测试方法系统测试System Testing将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起进行信息系统的各种组装测试和确认测试。是针对整个产品系统进行的测试目的是验证系统是否满足了需求规格的定义找出与需求规格不符或与之矛盾的地方从而提出更加完善的方案。基于系统整体需求说明书的黑盒类测试应覆盖系统所有联合的部件。对象不仅仅包括需测试的软件还包括软件所依赖的硬件、外设甚至某些数据、某些支持软件及其接口。系统测试类型功能测试功能测试的依据是需求规格说明书。对产品的各功能进行验证根据功能测试用例逐项测试检查产品是否达到用户要求的功能。功能测试的基本方法构造正常/异常输入检查输出是否符合预期不一致则功能有误。功能测试难点在于正确理解用户需求和如何构造有效的测试数据。性能测试一般不大于24小时测试软件处理业务的速度检验性能是否符合需求。得到某些性能数据以供参考或用于宣传等。健壮性测试在异常情况下软件还能正常运行的能力。容错性测试容错性测试通常构造一些不合理的输入来引发软件出错。输入错误的数据类型输入定义域之外的数值。测试客户机–服务器模式的软件时把网线拔掉造成通信异常中断等验证其恢复能力系统能否重新运行有无重要数据丢失是否毁坏了其他相关的软硬件。压力测试也叫负荷测试系统能正常运行的极限状态一般不大于2小时。可靠性测试在一定环境下、在给定的时间内、系统不发生故障的概率一般3-5-15天都有可能。黑盒测试特点从理论上讲黑盒测试只有采用穷举输入测试把所有可能的输入都作为测试情况考虑才能查出程序中所有的错误实际上测试情况有无穷多个不仅需要测试所有的合法输入而且还要对那些不合法但可能的输入进行测试。完全测试是不可能的。等价类划分法等价类划分法的目的是把无穷的情况划分为有限进而选取合适的测试数据有效等价类无效等价类局限性孤立的考虑各个输入数据的测试效果而没有考虑多个输入数据的组合效应可能会遗漏了输入数据易于出错的组合情况多个输入数据孤立测试导致测试用例数量庞大不利于维护和执行可以采用因果图设计法弥补。方法根据等价类表生成测试用例为每一个等价类规定一个唯一的编号设计一个新的测试用例使其尽可能多地覆盖尚未被覆盖的有效等价类重复这一步直到所有的有效等价类都被覆盖为止设计一个新的测试用例使其仅覆盖一个尚未被覆盖的无效等价类重复这一步直到所有的无效等价类都被覆盖为止。边界值法基于单元功能、输入、状态及控制的合法和非法边界值设计测试用例的方法。选择在边界附近的值进行测试从而有效的暴露程序错误。特点用边界情况的处理为主要目标设计测试用例。许多软件错误发生在边界及其附近。边界点上点边界上的点。内点区间内的点。离点离边界值最近且与上点不属于同一等价类的点。实际使用时重点考虑边界情况上点离点内点。无限小数没有离点不用取。错误猜测法基于经验和直觉推测程序中所有可能存在的错误而有针对性的设计测试用例的方法。基本思想列举出所有可能和容易发生错误的特殊情况并设计测试用例。常见依据单元测试中出现的错误。以前测试时出现的错误。客户实际使用时发现的错误。容易发生错误的场景和位置。一些公共模块、功能。修复了bug的功能和模块。因果图法因果图法适用范围一个页面下多个输入框。分析规格说明书中哪些是因哪些是果。原因是输入条件结果是输出条件。因果图最终生成判定表适合程序输入条件的各种组合情况。因果图法生成测试用例的步骤罗列出所有输入。分析每一个输入有哪些可能性进行排列组合。和输出结果进行比较。删除重复部分。判定表分析和表达多种条件下执行不同操作的工具。条件桩列出问题的所有条件。动作桩列出问题规定可能采取的操作。条件项列出特定条件的取值。动作项列出在条件项目的各种取值情况下应该采取的动作。场景法现在的软件几乎都是用事件触发来控制流程的事件触发时的情景就是场景同一事件不同的触发顺序和处理结果就是事件流。场景法路径基本流备选流场景法设计步骤根据说明描述出程序的基本流及各项备选流。根据基本流和各项备选流生成不同的场景。对每一个场景生成相应的测试用例。对生成的所有测试用例进行复审去掉多余的测试用例测试用例确定后对每一个测试用例确定测试数据值。个人建议主要且常用的测试方法大概就4种等价类、边界值、场景法、错误推测法实际工作中要灵活使用这几种方法特殊情景可能涉及到判定表和因果图法慢慢掌握就行其实都不难。