关于软件测试的一些思考

1 第一个问题，以系统化的视角看待
  类似项目管理和系统架构主题，将理论与经验结合，系统化、全方位、立体、整体、全面、由表入里、由浅入深考虑软件测试时，
  应该如何构建测试系统以支撑最初的需求和要求？此时，该如何把握测试构建的方向？如何站在全局性的高度看待测试问题。
  其实，这里所谓的角度问题还是重点在于如何做这个点上，用于指导如何做这件事。
  

2 全局视图4W+H。What? Why? Where? Who? How?
  Why 为什么要进行软件测试？
  构建测试系统的目的是什么？促成软件产品达到设计要求或目标？促成软件产品达到更高性能、更高稳定性、更少资源消耗等质量属性？
  这里探讨为什么的问题。先要弄清楚，为什么要测试，测试的目的是什么，然后才能自如的讨论如何做测试。
  软件质量属性的要求？可用性、可靠性、性能、安全性、可维护性？--可移植性、可修改性、可扩展性、结构重组。
  考虑清楚目的，反过来可以指导方法。
  比如要实现可用性，该如何通过测试保证。
  比如要实现安全性要求，又该如何通过测试保证。等等。
  
  Where 在哪里进行软件测试？
  可能是在开发环境，也可能是在模拟环境，还可能是实际环境。
  
  When 在什么时候进行软件测试？
  涉及软件测试的生命周期的问题。
  测试开始于需求，与设计同步，与开发同时。
  测试驱动开发，先进行单元测试用例的开发，再进行实际功能的开发。
  软件维护期测试也是如影随形的，可以说测试的生命周期伴随着软件自身的生命周期。
  
  Who 由那些人进行软件测试？
  开发人员
  测试人员
  特邀试用用户
  潜在用户
  
  How 如何做软件测试？
  这是重点需要考虑的问题。
  从全局出发，对关键节点、状态的信息导出，形成有效跟踪日志信息（比如登录状态、协议点、是否上传下载、编解码状态等），用于指导测试
  通过这些日志信息，形成整个产品的骨架信息。
  
  What 软件测试都要做哪些内容？
  或者是软件测试都要测试啥？与目的强相关
  测试功能，各个具体的功能，功能的可用性
  测试性能，满足设计要求？满足需求要求？
  测试可靠性，根据影响可靠性的因素，具体展开
  测试其他质量属性
  

3 收集资料，做合适的测试
  测试的指导思路：避免为测试而测试，测试要有其目的性，突出重点，还要有高效性，达到事半功倍的效果。
  另外也必须认识到测试有其适应性，不同类型的产品、不同的应用场景都有其特殊的测试要求，并不是每种测试方法都适宜，也不是每种测试方法都需要。
  
  测试的手段方法收集。
  
  每种测试方法，其难易程度、复杂程度要有正确的评估。最好是理论结合实际的统计数据来表达。
  如果某种测试方法过于复杂，难以实施，而其产生的实际效果又比较有限，则可以做出取舍，放弃该种测试方法。
  策略上，可以先易后难，先高效全面后深入细致。力争做到百分之二十的方法完成百分之八十的结果。
  

  在理清上述问题后，再具体挑选方法手段，细化步骤，选择合适的工具，因地制宜的、有针对性的做测试

4 测试方法实践论
  测试从大的方面划分，包括黑盒测试和白盒测试
  
  黑盒测试
  倾向于功能测试、集成测试、整机系统测试
  单元模块测试
  集成测试
  功能测试
  系统测试
  预定义测试功能，测试用例
  
  白盒测试
  倾向于单元模块测试，自顶向下拆分，从系统拆到单元模块
  路径覆盖测试
  桩测试
  自动脚本测试
  模拟器测试
  
  动态测试
  静态测试
  性能测试
  
  支持工具
  Bug系统
  自动化测试平台、工具
  
 
5 各种方法的收集
  参考手机平台：
  按键模拟的自动化UI测试
  Monkey MonkeyRunner
  UI Automator
  
  WEB 性能测试工具 Loadrunner
  QTP是Quick Test Professional的简称
  Selenium 
  
  Appium
  Robotium 
  
  http://www.spasvo.com/ TestCenter测试管理平台
  测试场景--测试用例--测试数据--测试轮次--测试结果，缺陷管理，报告导出
  
  TESSY
  CodeTEST

6 实际测试方法使用
  UI模拟触摸测试，类似手机的Monkey测试
  具体分为随机方式和非随机方式
  随机方式不考虑费用损失，为正真的monkey测试
  非随机方式，通过解析执行特定的测试脚本，走预订的切换路径进行针对性的测试
  对于非随机方式，可以采用预录制方式，将用户操作信息录制保存到脚本文件中，从而简化路径生成。生成的脚本文件可重复执行，这样既方便当前测试，也方便后续回归测试
  
  
  
  硬件单元的自动、半自动检测
  目的主要是为测试硬件模块的连接通路，用户不参与或者简单参与，参与时也仅做正确与否的判断。这部分甚至可以采用人工智能方法，自动检测分分析画面是否异常。
  可采用该测试的硬件模块有
  1 串口通信正确性验证，通过收发echo
  2 存储卡的检测，通过读写对比
  3 按键正确性验证
  4 摄像头正常使用验证
  5 触摸屏准确性验证
  6 显示屏无坏点，色彩正常验证
  7 音频采样及频率验证
  8 其他模块
  
  
  
  构建完善日志系统，支持自动分析，引入大数据分析类似方法，分类别、可视化。
  过滤导出关键路径，跟踪关键点信息
  使用python语言，对日志数据进行格式化分析处理
  关于日志系统构建和获取
  可参考类似手机LOGCAT。
  可参考Linux的日志系统。程序是否可以利用系统的日志系统？程序是否可以利用重定向将日志送到日志系统？Linux系统自带日志系统，syslog，rsyslog，用于管理系统的各种类型的日志。
  另外，可以使用log4plus，开源日志框架，管理程序日志，支持将日志发送到日志服务器。就日志框架本身，大同小异，Android的logcat和log4plus是类似的。
  日志数据内容可参考TR069协议，进行标准化格式化，方便对数据分析
  
  日志系统的总体需求就是方便的获取设备的日志信息。进一步的，包括生成方式、获取方式和获取内容。
  生成方式上，要简单易用，具有通用性，高效，尽量降低对正常程序逻辑和性能的影响。
  获取方式上，可以输出到屏幕跑；输出到日志服务器，并从日志服务器拉取；输出到文件；输出到其他媒介，甚至如浏览器。
  获取内容上，可以标准化、格式化，方便统计分析。比如分类、分级别，并进一步包含代码文件、行数、时间、进程号、线程ID等常规辅助信息，方便提取日志和分析。
  甚至可以将日志作为数据的一部分，做大数据分析，利用分布式文件系统。
  
  
  
  内置单元测试框架
  单元测试可以对函数进行正确性和性能验证（可以定义执行次数并获取执行总花费时间）。
  单元测试有比较多的现成框架，如Java类的JUNIT，c++也有GoogleTest。特别的，对于嵌入式系统，有一些更高级的测试工具，借助硬件仿真手段，深入介入执行代码，进行测试验证。
  这类嵌入式第三方工具多用于工业设备，可靠性要求很高的地方，比如航天航空设备，汽车电子等。大多提供方便的测试用例构建方法，比如通过图形化的手段，降低测试用例编写难度和复杂度。
  工具甚至可基于对代码进行分析做特定的测试介入。
  这类工具往往也提供对行业标准的支持。提供相关的测试报告和认证服务。
  
  总的来讲，在嵌入式设备上执行单元测试，具有一定局限性、复杂性，这类似在android手机上做单元测试。
  单元测试主要通过对被测接口或函数的执行，利用传入特定的参数（正确或故意错误、边界等特点），通过判断返回的结果是否符合预期而做出测试通过与否的界定。显然，该类测试比较方便应用于：
  单纯的算法处理类，比如：数学运算（比较、求和等数学运算）、特定算法数据结构的实现（堆、栈、字符串解析）、特定逻辑功能的实现（前面内容也包括在这类，简单增删查改及引申出来的登录、获取、保存等操作）
  简单的逻辑流程及交互
  其实一些独立的模块，功能性强、内聚性强、依赖少的模块，比较适合做单元测试。
  
  相应的，就有一些不太适应做单元测试的场景，包括：
  与硬件的交互，比如打开声卡，播放声音，暂停播放，关闭声卡这一系列操作无法通过代码本身完全判断成功与否，需要人为参与，视频也是类似，是否正常需要肉眼做观察的判断。
  任务调度相关的流程，比如启动一个线程、执行特定操作、依赖特定事件触发的逻辑流程等。
  无法通过返回值判断操作成功的逻辑流程，比如可视化、语音合成等相关操作，也是需要人为判断的干预。
  有依赖的功能，比如对某个接口的测试，依赖一个或多个其他接口，且接口之下还有很多接口依赖。
  接口与网络有交互。
  操作依赖UI且交互的接口。
  上述部分场景可以通过模拟隔离，在一定程度上实现单元测试。比如对数据库的模拟，对依赖模块的模拟，类似打桩，通过对横向（接口函数内调用）和纵向（接口函数内层次调用或者递归）多依赖的接口进行模拟隔离。
  
  
  
  模块或功能测试框架，集成测试
  UI自动化测试其实就可以改造成一个集成测试框架。
  定义功能列表
   对每一个功能定义专属操作步骤（涉及到UI操作，可以用控件、位置等其他要素模拟）
   对每一个功能定义专属数据（参数+属性+外部数据）
   对每一个功能定义检测条件及判断标准，完成与否，时间要求等
   对每一个功能完善测试所需其他环境要素
   对每一个功能，执行上述模块化（模板化）测试用例
  根据执行结果，得到功能集成测试报告
  
  
  
  系统测试
  主要采用测试用例，预先建立测试用例集，做整体功能覆盖测试
  很多时候与功能测试界限并不严格
  系统测试可更多关注系统功能之前的其他质量属性，比如性能，可靠性、可修改性（可维护性、可移植性、可扩展性、结构重组）、安全性、可测性、易用性等。
  系统测试目标为需求规格说明
  可以使用多种方法测试，比如对性能，可以通过虚拟容器模拟用户数、终端数等；对于安全性，可以通过假想攻击模拟进行；对于可靠性，可以通过各种环境高低温拷机等方式测试。