文章目录
- 前言
- 业务测试需求辨识能力
- 当前问题现状分析
- 需求实现后的状况分析
- 需求实现的可行性
- 需求实现的成本
- 测试开发项目设计能力
- 测试开发项目调整能力
- 测试开发项目的落地能力
- 测试开发项目的反馈关注
- 总结
- 新书推荐
前言
测试开发 - 一个很“神奇”的存在。职位属测试岗位，但干的是开发的活，钱拿的没有开发多，但事一点不比开发操心的少。但今天要讲的却是如何成为一个合格的“测试开发”攻城狮。
天然的熟悉业务系统，掌握必备的开发技能，这些都是测试开发攻城狮们所要具备的基础能力。
除此之外，想要成为一名合格或者优秀的测试开发，你可能还需要具备更多的软硬技能。其中硬技能包括：
- 对业务架构技术栈的理解和分析能力
- 对开发工具技术栈的运用和掌握深度
- 对业界主流技术发展趋势的关注和洞察能力
- 对开发、测试新技术的研究和学习能力
而软实力则主要体现在：
- 对业务测试需求的辨识能力
- 对开发项目的设计和规划能力
- 对开发项目的风险评估和调整能力
- 对开发项目的落地和推广能力
- 对开发项目的反馈处理和响应能力
通过上面的分类我们可以发现，硬实力基本属于技术能力提升的范畴，把自己当作一个完全的开发去关注和学习新技术即可，重点关注的是项目的技术可行性。
而软实力则更偏向于项目能力的范畴，把自己当作一个完全的产品经理去思考项目的必要性和可行性，重点关注的是项目的业务可行性，保障测试开发项目的成功率。
相对于软实力而言，硬实力通常更为广大的测试开发所关注和实践。这种情况在新手测试开发身上体现的更为明显。
而经过了“洗礼”的测试开发老鸟们，则会吃一堑，长一智。除了关注硬实力，更多的还会去关注软实力的提升。
因为硬实力只能保证测试开发项目的实现，软实力才是保证测试开发项目最终能否成功落地和应用的重要砝码。所以想要成为一名合格乃至优秀的测试开发，你需要一颗“产品”的心。
业务测试需求辨识能力
测试开发这个岗位之所以存在，是因为在业务测试过程中，发现很多重复、繁琐、不便于人工操作的场景存在；而这些场景恰恰可以通过技术和工程化的手段来轻松解决。所以就有测试开发这样的一个细分工种，专门实现测试业务中的需求。
与纯开发人员相比不同的是，纯开发人员主要关注实现的可行性，开发需求则是由独立的产品人员来整理和提出；而测试开发人员则没有这样的待遇，不会有专门的产品经理来做需求整理的工作。
而对于非大厂的测试开发而言，他们的首要能力就是发现和提炼业务测试需求；因为整体上是没有规划的，你只能凭借对业务的熟悉程度和洞察能力，来发现业务测试过程中的痛点 - 业务测试需求。之后才能有发挥自己开发特长的能力，去做测试开发方面的工作。
对于大厂的测试开发而言，可能从架构上就有整体规划，自己需要开发的大目标就有了。
这样的情况之下，一方面需要在具体的实现上多关注、贴近业务需求，否则做出来的工具不易用就会很难推广；
另一方面你可能需要培养更广阔的洞察能力，从合作的业务部门、甚至整个公司去发现一些共性的需求，然后梳理出来进行评估和立项。
对于大厂的测试开发而言，测试开发的需求可能有很多，这时就需要培养对项目的选型能力。比如：第一优先的是那些团队和公司内部都存在的业务测试需求；
因为同样是做一个需求，你的所选的项目覆盖范围越广，最后能达到的效果就会越大。升职加薪自然就少不了你了！
发现了业务测试需求才仅仅是开始，你还需要对发现的业务测试需求进行评估，辨识这个需求的真伪。具体参考依据如下：
- 当前问题的现状分析 - 分析人力成本、时间成本
- 需求实现后的状况分析 - 分析人力成本、时间成本、额外优势
- 需求实现的可行性 - 对技术实现和场景进行充分调研、demo、评估
- 需求实现的成本 - 项目整体实现成本，分析投资回报率
当前问题现状分析
主要分析人力成本、时间成本。即当前操作该业务需要多少人、做多长时间；这里面要考虑多次操作时个体间的成本差异，每成功操作一次的出错率、和调试时间等；最后综合评估得出一个平均值。
需求实现后的状况分析
主要分析人力成本、时间成本。即通过测试工具/平台/脚本实现该操作时，需要额外补充的人力；以及需要等待工具完成该操作的时间。这里面要考虑测试工具运行的稳定性、成功率和并发执行的场景。
另外可以分析工具可能会带来的隐性优点。综合评估后得出的人力、时间成本，再跟当前现状的人力、时间成本相减，即可得到节约的人力、时间成本。
需求实现的可行性
主要对技术实现、技术难点进行分析和评估，对不熟悉的技术栈进行demo确认；梳理出整个业务场景的支点，并进行demo确认。
通过demo实现的反馈结果，综合评估出整体实现上的可行性，以及技术难点。
需求实现的成本
通过前面的demo实现，初步确定技术难点和主要耗时模块，结合架构设计综合评估出整体的实现成本；然后就是计算投资回报率：
总体实现成本 / 单次执行节约的成本 = 最少执行的总次数
最少执行的总次数 / 当前业务的使用频率 = 最少需要执行天数
最后，如果是阶段性业务项目则要考虑项目结束时间，如果
项目结束时间 - 当前时间 > 最少执行天数
则表示可以投入成本可以收回，否则表示收不回成本。
当然并不是所有情况下都能收回成本，有些时候仅仅只是单纯的为了提高效率而已。此时其作用等同于增加额外的人力来缩短测试周期。
测试开发项目设计能力
通过了各种需求提取、可行性分析之后，表示该业务测试需求可以做，并且值得一做。但是能不能把项目做好是另外一回事，可能给A做就能成，而换成B可能就成了烂尾。而这很大程度就体现在测试开发人员的项目设计和把控能力。
首先，作为测试开发人员在项目设计的时候，往往会进入的误区是：从技术实现的角度来设计项目，而非从用户使用场景的角度来设计项目。
换句话说就是：技术实现驱动用户界面，用户界面驱动用户使用场景。通过这种方式设计的项目，最后都会很难落地和应用并最终导致烂尾。
提升项目设计能力的重点就在于，要把测试开发的项目当做用户产品来对待，要从用户的角度想问题，设计界面及场景交互，用最少的额外成本来完成某个任务。举个简单的例子：
在不使用测试工具前，操作一个业务需要5分钟，而使用测试工具后需要进行3分钟的额外操作，才能通过工具来执行该操作。那么这就不是一个好的用户场景。
在用户场景设计好之后，才会去依照这个用户场景和实际的业务操作来设计程序的架构，当然好的架构还要考虑业务并发性、业务扩展性等等。
测试开发项目调整能力
按照理想的情况，到目前为止应该正在愉快的开发项目，甚至马上就结项了。但是事实上，即使我们严格按照了上述的步骤来提取、评估需求，到头来还是出出现各种差错。
比如：公司架构调整、业务需求调整等。当遇到这些实际开发与目标期望严重偏离的时候，就要具备项目调整能力来
把项目尽量带回“正轨”。
对于组织架构调整，但是业务需求没有调整的情况下，可能原有的需求还是存在的，那么原来的测试开发项目就可以继续保留。
而如果原来的业务需求也一并调整了，那么就需要根据新的业务线来分析，当前测试开发项目是否可以兼容、改造和复用。
还有一种情况就是上层架构都没有变动，但是之前的需求分析阶段出了差错，没有提取到业务测试“真正”的需求。此时就需要通过及时的复盘，来发现需求实现和实际场景的偏差。
总体而言，就是在测试开发项目的每一个评审阶段，都要对把目标用户拉进来。一方面希望他们能提供宝贵意见，另一方面更重要的是获得他们的及时反馈。
测试开发项目的落地能力
在经历千辛万苦的设计、开发、内侧之后，项目在工程方面终于完成了。但离结项还有最重要的一步 - 应用与落地。
测试开发除了是项目的实现者，更是项目的首席布道师。你要对自己开发的项目有信心、有激情，并且运用一切的资源去推广项目，让项目能够在适用的场景下成功落地。
首先，如果是组内的业务测试需求的项目，一般都会比较容易落地，毕竟是知根知底，只要做出来的产品足够的易用、稳定即可。
其次，如果是可以覆盖跨部门的业务测试需求的项目，通常会先在本部门内先落地和应用；在取得了一定的效果和数据积累之后，再开始向外部门推广。
推广的策略是优先选取好合作、愿意合作的部门。比如：友情部门、业务测试需求比较迫切的部门，这些都是我们的种子用户。当积累了一定的实际数据之后，就可以依次往其它部门推广；这其中又把重要的部门作为第一批推广目标，这样可以作为后面其它部门推广当示范。
测试开发项目的反馈关注
测试开发项目落地后，可以说已经完成了95%的工作，但最后还差一个有效的反馈机制。因为项目的落地并不代表项目的成功应用，只有当项目落地后并有很好的应用数据来支撑，才算是成功的项目。
但好的应用数据往往不是天然就有的，可能需要我们不断的通过分析数据、追查原因、改善功能来不断的修复，最终才能达到我们想要的应用数据。所以一个好的反馈机制是保障应用最终有效落地的手段。
一方面可以通过提供用户反馈通道来直接的获取反馈；另一方面可以通过应用数据分析来间接的获得反馈信息。大部分情况可能需要通过第二种方式来获取反馈，并通过主动积极的与用户进行沟通来获取根本原因。
总结
通过这一系列的测试开发软技能的分析，可以发现想成为一名出色的测试开发并非易事。除了懂业务、会开发之外，还需要更多的产品、项目管理、运营的能力。如果把这样一名测试开发放在创业公司，那他就是“整支”创业团队的角色。
以前听说老王开公司，董事长、CEO、会计、出纳、保洁、保安都是他一个人，我不信；但自从做了测试开发之后，我信了！
新书推荐
获取更多关于Python和自动化测试的文章，请扫描如下二维码！
