Jmeter 接口测试工具性能测试需求分析

【接口测试工具】
1、可以做功能测试，针对http 请求对input对象编写测试用例；
2、可以做性能测试；
测试脚本维护方便，可以将测试脚本复制，并且可以将某一部分单独保存
可以跳过页面限制，向后台程序添加非法数据，这样可以测试后台程序的健壮性
利用badboy录制测试脚本，可以快速的形成测试脚本
 Jmeter断言可以验证代码中是否有需要得到的值


●    Jmeter比较适用于数据添加，数据修改，数据查询的测试，使用其他测试工具虽然也可以完成该类测试，但是利用Jmeter添加数据更快，更方便，而且不依赖于界面，只要添加数据的参数不改变，无论界面是否有变动，都不影响针对数据的操作。
【创建测试计划】
元件测试和非元件测试
 
输入 处理 输出


点 、线 、面、体


点：功能点
线：业务场景
面：非功能性（测试点）
体：系统接口


一、测试需求分析的过程：
1.根据需求规格提取独立的功能点，确定测试范围；
2.对独立功能进行分析，确定各独立功能的测试点；
3.对业务场景即功能组合进行分析，提供业务场景的测试点；
4.对非功能特性进行分析，了解需要测试的非功能特性；
5.针对系统级接口进行分析，了解被测试对象、测试规格。分析可测性，确定测试方法、工具。


 
二、测试需求分析需要考虑的一些问题和细节：
问题：
1.已文档化的需求是否被正确实现；
2.是否存在遗漏需求；
3.是否存在画蛇添足的问题(实现了不存在于需求规格的需求)。


细节：
1.需求项与测试项关联、与测试用例关联（避免遗漏）；
2.区分出测试项的优先级（80/20法则）；（可以使用两次80/20法则，将优先级快速分为三个层次：5%、15%、80%）
3.针对可能存在的需求遗漏和疑似额外的实现，主动联系需求提出方，进行沟通并确认；
4.若需求项（测试项）可测试性差，及时反馈（涉及接口的，需要看到API，或接口文档）。




三、工作方法改进：
1. 量体为用：在不同的工作环境中开展测试活动，需按工作环境中的实际情况灵活的调整工作方式。
    比如在软件开发不是公司主营业务的团队做测试，就需要把握好以下工作（身为测试员的体会）：
    A. 沟通；
    B. 前期早介入（想办法熟悉产品的需求）；
    C. 做好测试需求分析、用例（包括用例的评审）；
    D. 提出改进工作流程及方法，提出提升被测物可测试性的建议（发现问题就提出，否则领导会认为你不主动或什么都不懂）；
    E. 测试总结：测试覆盖率、测试充分性（是否可以从这些方面再有所提高）、改进意见、经验分享；
    F. 终极测试：将测试的触手伸向代码（越主动越有利）。


说明：有时候会发现，本来是变量没有初始化就被调用，或是对象没有被正确的实例化就被使用，而产生的错误。但是开发人员在对应类或函数的日志输出部分
       写的是“Network Error.”  或是“New Error + $Date”. 这样就给通过日志判断、定位错误的测试人员造成一些困扰。




2. 换位思考：不管是做领导工作，还是普通的测试员或研发人员，能够做到换位思考的人，未来可期。
      
3.不二过：尽量不在工作中犯同样的错误。即要善于总结问题并及时改正。同时，分享自己犯的错误和解决方法也很重要。






注：
        很多时候要做需求分析是没有文档的，不管有没有文档，文档写的如何，有效的沟通最关键。看文档其实也是和写文档的人做思想的交流嘛。