这里写自定义目录标题

• 为什么写这篇文章
• • 立项阶段
  • 项目初期
  • 研发期
  • 测试期
  • 版本迭代中
  • 其他

为什么写这篇文章

来源于一次面试的提问，多年来一直致力于如何测好自己负责的项目，至于中间的流程都忽略了，于是一次面试的时候，有一个面试官问我：你如何开展测试。我反而哑口无言不知从何说起。当然，那次面试被PASS了，于是在这里结合过往经验，以及某次自己在boss直聘上的某次回答，结合自己的测试思路在这里汇总一下，请各位大佬多多指点。

立项阶段

主要参与立项评审，关注项目的性能指标，质量指标，明确项目的测试范围。并根据质量指标转化测试目标。明确测试范围，编写项目验收指标。

项目初期

参加立项评审后，就已经明确了项目的类型，根据上述的各种指标，来考虑对应的测试策略，评估各个阶段的测试人力需求，设备资源需求，以及其他的测试资源需求。再结合现阶段的状态，来评估项目中存在的各种风险，人力风险，技术风险等等。然后推动这些风险的解决。再根据项目计划、研发计划制定测试计划，分配人员。

研发期

1、获取需求文档，并对需求进行测试评估，从整体业务考虑系统设计是否合理，对需求不明确的地方，尽量促进三方理解一致性（测试、研发、产品）
2、解决了需求文档上面存在的不确定因素后，根据所测系统的类型，制定测试方案。并思考测试用例覆盖范围：不仅仅是功能哈，我这里整理的是APP应用，所以我是从这这几个角度去考虑测试用例的：手机APP应用环境、APP业务场景、业务性能场景、APP在手机上的性能表现、APP在设备上的特性。
（1、手机APP应用环境
通过分析手机APP应用环境来反推所需的测试环境，手机APP的应用环境可以分为，手机使用环境和APP应用环境，这些都是在不考虑业务的情况下，所要做的测试。
（1.1、根据手机使用环境可以反推出网络兼容要求，所以等到业务测试完成后，要准备相应的测试环境。根据目前的手机网络环境可以整理出要测试的网络兼容情况：2g、3g、4g、5g、wifi、弱网。前面几种都很好处理，唯独弱网会有点麻烦，我这里提供两种建议：一找专门的弱网模拟路由器，二、使用网络控制软件，看各自项目的需求。
（1.2、根据APP应用环境1，来反推测试场景。APP应用环境目前是运行在Android和IOS系统上的，之前是运行在Symbian和IOS上的，这个要根据市场主流系统占用情况来反推。根据市场主流系统反推应用所要运行的系统。这里是Android和IOS。IOS好办，机型固定，系统不杂，所以只要考虑系统新老版本兼容，和屏幕分辨率兼容。Android要考虑开发环境的SDK版本对市场上主流系统版本采用的SDK版本的兼容，手机品牌型号及系统版本，手机屏幕分辨率，还有一些直接更改SDK并进行二次开发的系统的兼容。
（1.3、根据APP应用环境2，APP是运行在手机上的，用户使用手机的习惯性操作，手机打开应有优先级也会产生相应的测试场景。比如使用APP中来电、短信提醒、消息提醒、电量耗尽等等
（2、APP业务场景
(2.1、根据业务需求，分析业务场景，结合业务实现方式，来制定APP业务测试的测试方法，设计测试用例。一般聪明的APP开发，都会将业务逻辑交由服务端处理，APP很少做业务逻辑判断的，也有，甚少。所以这里不如就说是项目的业务场景如何测试：
1⃣️、根据业务需求，了解业务场景，了解业务流程中因为操作或者状态变更引申的各个检查点。了解各个接口间的业务关系，以及相关联接口间的联系关键点。
2⃣️、根据业务流程，业务操作，记住这里首要条件是，要对业务特别熟悉，要对业务实现逻辑特别熟悉。每一步请求，每一步逻辑的处理都要很清楚，必要时画业务逻辑实现流程图。然后根据接口测试三要素：输入、处理逻辑、输出，对业务逻辑进行测试。要注意接口安全传输。要注意接口安全传输。要注意接口安全传输。重要的事情说三遍。
3⃣️、接口测试的常规套路，参数类型、等价、边界也要考虑到。
4⃣️、至于怎么去验测试结果：通过接口的响应结果，通过数据库的存储结果，通过相关联的接口校验。
5⃣️、响应结果除了检验业务逻辑外，还要检查响应码：通过响应码可以判断服务器处理情况。返回结果：可以看到出业务逻辑运行处理情况。正常结果，异常结果：可以推出一些异常问题所在。特殊：非业务逻辑内的特殊情况。失败等等
6⃣️、一些中间件的测试，这里要准备大量的测试数据去测，之前测的MQ消息队列，也只能用大量的测试数据去测。其他的测试方式我不清楚，希望有大佬指点。
（3、APP业务性能场景
说是APP的业务性能场景，其实就是业务本身的性能场景。APP性能测试可以往后面放放，待所有功能测试到一段落的时候开始。
业务性能场景，根据业务特性进行业务需求分析，找到业务的压力点，再根据项目部署情况去做针对性的压力测试。大多数分布式系统，都是仗着服务器多，而无所畏惧。但是只要有一个关键性服务器完蛋，整个业务都玩不转。所以我们要根据业务中负责不同服务的服务器的特性有针对性的去做压力测试，负载测试。这里不一一描述了，等空下来，我会再整理一波性能测试的心酸历程。
（4、APP在手机上的性能表现
这里要了解APP的具体实现方式，内嵌H5还是原生开发的功能。原生开发出来的功能就要通过ADB一些命令去做监控，这个建议等功能测试完毕后进行，然后单独用一天或者几天时间进行测试观察。功能都不完善，你就盯着APP的内存泄露或者是耗电情况吗，不靠谱。这个暂时不说，一样，等空下来我会整理一份完整的ADB使用指南。这里又是一段心酸史，因为我从来不记，特别是一些ADB性能监控的命令，都是到某一阶段才偶尔用一下，谁会想到有面试官会问这个。我要是开始写自动化了该多好！！！大好机会就是这么离我而去的。基础很重要、基础很重要、基础很重要。重要的事情说三遍。
（5、APP在手机上的特性
安装应用、卸载应用（是否卸载干净、卸载后是否清除本地缓存等等）、运行、权限获取（蓝牙权限、手机通讯录访问权限、本地数据读写权限、摄像头访问权限等等）、覆盖安装、本地缓存机制等
整理到了这里，测试用例覆盖范围也就基本清晰了，如果还有遗漏，欢迎各位大佬指点迷津。然后根据各自负责的业务设计测试用例，核心用例编写。

测试期

1、测试用例质量把控
测试用例评审可以保证测试用例的质量，这一步有条件一定要做。一个人的思路是有局限性的，评审后的用例质量得到了一个保障。如果用例评审期间都未发现问题，很可能都是极为经典的问题，值得记录保存，回朔。
2、测试环境准备
这里是APP，所以要准备测试机（之前做的APP应用使用环境派上用场了），搭建测试环境，测试资源整合。还要准备测试数据，具体就是一些用户数据啊，资源数据啊等等
3、测试进行中
3.1、冒烟测试
先对提测的版本做一个冒烟测试，输出冒烟测试结果，根据结果来分析后续版本测试的测试策略。灵活变换嘛。
3.2、测试用例执行
很多测试人员写测试用例是一回事，执行测试用例又是另外一回事。但是老测试人员都会按照用例去执行，因为可以防止非必要的遗漏测试点。当然完完全全的执行一次用例，工作量巨大，所以如果公司条件充足，建议将固定的功能自动化处理，一些其他的工作还是要手工执行，千万不要认为自动化了，就可以不手动了。自动化可以缩减工作量，但是做不到全部代替手工。这里只能说一些业务上与前端交互特别多的项目哈，不敢说太满，知识面不够，可能有的项目压根不与前端交互呢，纯服务型项目，自动化不仅测试效率提升，也能完全应对吧。不清楚这类，期待有一天能接到这样的项目。
3.3、测试结果反馈跟进
这个就不多说了，随着经验的提升，提出的bug质量也会越来越高。这个跟个人能力有关，初级提的bug很表面，所以开发改的也很表面。以量大引起质变。中级提bug，可能会找原因，问题根结，如何解决，按照怎么样解决可以避免后续其他问题能提供建议。这样提的bug质量会相对高一些。高级如何提我不清楚，我还是一枚初级中级之间的小娄娄。
3.4、版本测试总结，项目进度情况了解以及现阶段风险评估
先根据测试结果，进行版本质量分析，再检查缺陷，以及项目进度做风险评估。根据这些来决定下一步要做什么，是安排公测，还是上生产环境测试，还是其他的测试。
3.5、根据上述测试的最终结果，来确认产品是否可以发布，重点还要筛查未测试点，一些非bug问题风险，已知问题对线上影响。出具测试报告，以及已知问题跟进修复表。
3.6、版本发布后，要推动线上问题反馈渠道的开通，QQ群，客服电话等等，一定要形成闭环。再结合线上问题分析，完善到测试用例中。

版本迭代中

1、历史功能回归，历史问题修复情况进度跟踪。
2、新功能实现，新老功能交互影响检查。
3、APP还要根据更新方式做一些常规检查，比如Android，有热更新，强制更新，重新安装、覆盖安装等方式。常规的热更新容易丢失资源引起bug。
4、根据更新方式、历史功能、历史问题进度制定线上回归策略。

其他

发版时期风险等级时间表，这个是团队踩坑点，经常遇到的情况。我根据自身经历，写的一个时间判断表，并非绝对，仅供参考哈！也是介于这个原因，测试人员一定不要被牵着鼻子走。不背锅，但也不躲避问题。做好一切积极处理问题的准备。
超过20点的发版：风险等级提高至中级，做好夜里回归准备。
超过24点仍旧没有发版结束：风险等级自动调到最高等级，所有测试人员回家休息，做好第二天应急响应准备（版本发布取消，回归历史版本）
超过夜里2点仍未发版结束：做好线上致命问题响应准备。
超过夜里4点仍未发版结束：事故一级响应。
聪明的运维发版时间都会是最不起眼的时间，但绝对是一天当中发版时间最稳妥的时候。进可攻，退可守。24点至6点期间，不做发版，所有人员进入休息状态，待运维人员休息好了，精力恢复充沛状态，再做发版。没有最愚蠢的发版，只有没有做好准备的发版。不要一出问题就杀个运维祭天，或者杀个测试祭天，或者杀个谁谁谁祭天。问题仍旧没有解决，得不偿失。做到遇坑填坑，坑填的多了，经验就有了，再遇到类似的问题，就很好解决了！

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！