软件测试流程

软件测试流程

一、测试设计

• 测试方案
     测试工作需要尽早的开始，从需求导入开始测试就应当介入。开发需要评估需求的可执行性，测试也需要评估需求的可测性。在需求接入的时候，就可以开始准备测试方案，包括测试资源的准备、测试范围的确定等。测试方案需要经项目组评审。
• 测试计划
    制定测试计划时先列出大的功能模块，再逐步细化列出功能点，估算测试工时。总工时可乘系数，预留好平时开会、沟通等其他工作的时间（不得不说，当一块功能测试不顺利时，复现缺陷、与开发沟通定位问题真的很耗时）。测试计划需要经项目组评审。
• 测试用例
    测试用例在测试过程中是非常重要的部分，所有的测试范围、测试方法、测试标准都涵盖其中，一定要经过项目组评审，当出现争议时，测试用例也是很重要的证据，最大程度的避免与开发或产品由于需求理解错误产生扯皮。穷尽测试是不存在的，测试只能在一定条件一定范围内尽可能多的找出产品缺陷。
    测试用例应当尽可能的详细，使所有执行的人都能按照步骤达到相应的效果。设计测试用例时要注意的地方很多，例如数据长度及格式的校验、唯一性、必填项、边界值、异常操作及提示等等，测试场景的设计需要扎实的业务功底，将自己放在用户的位置上，模拟用户的操作，设计出用户有可能会进行的操作场景。

二、测试执行

• 测试环境部署
     我参与的项目是B/S架构，需要在LINUX环境中部署测试环境，我们环境部署流程并不成熟，理想的情况应该能够通过Jenkins打包自动部署到测试环境中，最好能再执行一边主功能的自动化测试进行冒烟测试。当前很多步骤没有连接起来，都是手动打包后手动解压缩修改配置文件进行更新。自动打包部署也是接下来需要补充学习的地方。
• 冒烟测试
     冒烟测试是针对系统最主要的功能流程，冒烟测试通过后才可进行其他模块的详细测试，主要功能不通过可直接将当前版本打回（开发八成是没有自测）
• 功能测试
     每次版本迭代功能测试一般计划三轮，第一轮针对新需求，第二轮新需求加上主要功能回归，第三轮验证遗留问题，回归主要功能场景。每一轮测试间隙都可开评审会议决策下一轮的测试范围，缺陷较少的模块可减少用例覆盖率，缺陷较多的模块则需要详细测试（ps：测试中的二八法则，80%的缺陷可能都集中在20%的易出错模块中）。事实往往是三轮测试过后依旧会有遗留问题，需要项目组评审是下个迭代解决还是加测一轮。
• 性能测试
     性能测试安排在功能测试的第二轮开始时，经过第一轮的测试，功能基本稳定，此时进行性能测试比较可靠，若是第一轮就同步开始性能测试如果功能没有通过就做了无用功了，而且这种几率很大。性能测试是一个不断调优的过程，需要测试和开发配合定位问题不断尝试，并且在性能调优结束后，一定要再次经过功能测试回归，结果方才可靠。

三、测试结果

• 功能测试报告
     附一张目录结构图
  

• 性能测试报告
     附一张目录结构图
  

• 版本发布说明
     附一张目录结构图
  

四、总结分析

• 测试用例补充更新
     测试用例设计是在产品未完成的阶段，很多细节和开发完成的产品并不一致，对于不停迭代的软件产品，测试完成后最好及时更新测试用例，使测试用例与产品一致，便于之后回归。
• 测试方法总结归纳
     测试过程中的测试方法应及时总结输出，可用作培训文档便于其他同事快速上手。不同人负责的模块还可以进行内部分享，使所有人对系统各个模块都能有大致的了解。
• 测试疏漏总结及规避
     及时的对测试过程进行总结分析，是十分有必要的。例如测试遗漏的问题，是由于需求理解错误还是测试用例覆盖需求不完整；测试进度是否按计划进行，为何延期或提前；哪些测试方法需要改进以提高效率等等。不断地完善测试过程才能更好地提高测试效率。