http://www.51testing.com/?uid-293557-action-viewspace-itemid-170162 架构师Jack的个人空间
重点和难点两个词汇有时能代表同样的方向，有时却是相差较远的方向。
为什么我要把是否有能力区分测试 重点和测试难点作为测试架构师必备的第二个基本能力。因为，我曾在某产品线对测试活动的质量进行抽查时，与每个产品的系统测试 工程师进行了沟通，发现只有一名有 6 年经验的系统测试工程师在我的的启发下，分清了自己所负责产品的测试重点和测试难点。而其他 的系统测试工程师一直都把测试难点误当成了测试重点，作为他技术攻关工作 的主力方向。甚至从来没有真正思考过什么测试技术 才 是自己所负责产品决定成败的测试重点，只是简单地把自己在工作中碰到的所不具有的测试技术都当成测试重点，其实很多都只是测试难点。的确，在某些产品测试 难点和测试重点刚好重合。虽然某些产品测试重点在技术上并不难，但是却需要我们把测试重点部分的工作质量做到最佳，时间和资源投入最多，而不要把有限的资 源投入到测试难点的工作中去。我很认同华为任正非对华为工程师的要求“要做工程商人”，我们其他公司的工程师同样应该以商业目标为自己的技术工作目标，不 应唯技术论，越新的技术，越难的技术就越愿意投入。测试工程师同样要心中一直有一个目标指引着自己的所有技术工作方向。这个目标就是我测试架构师日记 中第一篇谈到的“准确的商业理解力”告诉你的工作目标。
由 于项目中每个人的分工不同，因此不可能每个测试人员一开始就能知道自己工作的商业目标是什么，所以也不用去责怪大家。可是领导产品的测试架构师不能准确的 识别或培养其他测试工程师具备识别测试重点和测试难点的能力，那么注定这个测试团队的工作不但质量保障会打折扣，而且会浪费不少组织的资源和成本。
因 为资源和时间是有限的，而完美工作的追求是无限的。因此，我们如何在有限的资源和时间下，保障基本的质量目标，并尽可能提升质量目标。就需要在分清测试重 点后，优先针对测试重点目标进行系统地测试技术研究，测试技术攻关，测试资源主要投入。对于非测试重点的测试难点部分就要降低优先级，放在最后考虑。
测试架构师的工作应该牢牢抓住真正的测试重点来开展，甚至在整个产品测试组都方向错误时，要能从商业角度帮助测试组改变观点。那么当从测试经理到普通工程师都误理解了测试重点时，测试架构师应该如何来启发他们呢？我这里就分享一个案例吧：
在一次到产品测试组进行测试活动质量抽检时。我们问测试经理，你们产品测试目前最大的需求是什么？他说是如何进行压力测试 和性能测试 ， 希望我们测试架构师团队能在此领域多给予支持。我心里知道：他所负责的产品特性核心不是性能和压力测试，但我没有反驳他。而是继续问他下一个问题：“你觉 得会让你产品未来应用时商业失败的最大担心是什么？”他想了想说：“不能对客户的生产系统产生破坏，让客户的业务中断。”“依据我们的经验，与客户生产系 统交互的模块虽然是个小模块，但是在其他产品上经常出现内存泄露的故障从而破坏了生产系统。那你针对该小模块做过哪些系统地测试？有无专门进行内存泄露的 测试，因为内存泄露对客户生产系统的破坏最大。”我问到。这时此测试经理才恍然大悟，这个对生产系统质量影响最大的小模块居然没有系统地进行过深入全面的 测试。我这时告诉他“你之所以开始说性能和压力测试是你的重点需求，是因为你们组里没有在性能和压力测试方面的积累，有工作开展的难处，这是困扰你的困 惑。但是你的产品形态的质量不是性能或所谓压力测试来保障的，而是需要不对生产系统产生破坏。因此，你唯一能破坏生产系统的那个小模块应该是你整个产品中 质量最高的模块，也应该是测试最全面最深入的模块，你的技术力量应该主要投到这个地方”。后来，针对该小模块我们进行专项内存泄露的测试，结果发现了好几 个内存泄露的大 bug ，这些 bug 每一个都是会导致客户生产系统中断的杀手。
测试架构师不是团队中专门解决测试难点的专家，而是识别测试重点，并支撑测试重点工作的专家。“区分测试重点和难点的能力”不是测试架构师独有，系统测试工程师和测试工程师一样可以具有。与第一篇“准确的商业理解力”一样，第二篇要做的是：做正确的事。
请继续关注后续测试架构师应该具备的能力系列：
第三篇 “全面，多样化的产品经验”
第四篇 “参与产品架构工作的能力”
第五篇 “识别产品测试组测试技术需求的能力”
第六篇 “为产品测试组提供测试技术解决方案的能力”
第七篇 “测试技术解决方案的推广能力”
第八篇 “与周边部门沟通配合能力”
第九篇 “创新解决方案能力”
第十篇 “领导力和影响力”
扫一扫
994
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
