目录
前言
总有人要成功，为什么不能是你！！！
一、需求分析
产品写好原型图之后，会把原型图发给测试。我们就根据原型图看一下该版本要实现的功能是什么，产品设计的有没有遗漏的、不合理的地方，以及自己不理解的地方都做个记录。需求评审的时候和产品确定一下问题。
二、需求评审
参与人员：产品、测试、开发。
需求评审的目的是让产品、测试、开发对需求的理解一致，减少后期的沟通时间；对产品设计不足的地方及早修改；了解功能的背景，让测试更好的考虑用户体验度。
三、写测试计划
目的：为了规范软件测试内容、方法和过程。
内容：测试项目的背景、测试范围、测试方式、测试资源、测试开始和结束条件、嫉妒安排、以及与测试有关的风险。
四、编写用例
写测试用例最重要的就是保证测试用例的覆盖率，可以从以下几个方面考虑。
1、根据软件的六大特性考虑：
功能性：软件实现了原型图中的功能。
可靠性：软件是否成熟，是否有容错性。
易使用性：用户是否能快速的学会并正确的操作软件。
效率：响应时间是否达标，服务器的CPU、IO、内存消耗情况是否达标。
可维护性：软件易修改、更新、升级。
可移植性：在不同设备、软件上是否都能正常运行。
2、使用等价类、边界值、场景法、判定表、错误推断法等去设计测试用例。
等价类：
有效等价类：是指输入的数据是正常的，符合要求的。
无效等价类：输入不符合要求的数据，可以测试程序对这些数据的处理是否合理。
边界值：比如需求中定的是输入6-10个数字，取边界值就是5、6、10、11位数字。
场景法：站在用户的角度去思考，考虑一些正常异常的场景。
判定表：多个条件组合，用排列组合的方式写测试用例。
错误推断法：根据经验哪里容易出现bug。
3、进行用例评审，测试、开发、产品每个人的角度都不同，通过用例评审完善测试用例。
4、在测试的过程中不断补充、完善测试用例。
五、测试用例评审
参与人员：产品、测试、开发。
评审用例是否覆盖完整，用例中的前置条件、操作步骤、预期结果等是都都明确，比如预期结果中有数据库相关的，要写明是哪个表，那个字段。对于需要修改的做下记录，会后及时更新测试用例。
六、接口测试
接口测试的目的：测试提前介入，缩小测试成本；从底层保障软件的质量。
接口测试的时间：用例写完后，根据开发的开发计划执行接口测试。
接口测试的用例：从功能测试用例中挑选接口对应功能的用例，再根据接口的正常异常的请求报文、响应报文写测试用例。
接口测试的总述:测试用例评审修改完成后，根据开发的开发计划，按模块分给测试组成员，提前准备好测试数据。熟悉下接口文档，看下这个接口要实现的功能是什么，哪些参数是必传的，正常异常的响应码响应报文分别是什么，编写接口测试用例，接口测试用例是从把对应的功能测试用例抽取出来，再加上传参异常的用例。开发接口做好之后就开始用jmeter测试，用jmter做参数化就用CSV文件做参数化，再添加CSV配置元件读取，接口引用的话就是${}去引用。还有接口的关联，比如B接口的参数是A接口的返回值，那就要在A接口下面添加正则表达式提取器，B接口再用${}引用，接口需要做断言，就在每个接口下面添加响应断言，一个是做响应码断言，还有是要做一下业务断言，判断接口返回的内容是否符合预期。
七、冒烟测试
先测试基本流程是否正常，如果没问题就正式开始测试，如果有致命bug就打回，让开发修改后再提测。
八、测试环境测试
逐条执行测试用例，发现测试用例有需要修改的，及时更新测试用例。开发修改后的bug及时回归验证。
九、正式环境测试
正式环境一般不让造数据，就大致点一下没有问题就可以了。
十、写测试报告
内容：数据统计、遗留bug情况、测试风险、测试结论等。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
