软件测试那些事儿

lsekfe

软件测试工程师在各个企业起着举足轻重的作用，把着我们质量的这道大关口。虽然是老生常谈，但作为某养老项目的成员，分享一下我们心目中软件测试那些事儿。
　　以下的内容从某保险集团养老团险项目的介绍、测试工作流程以及测试工作技巧三方面来分享。
　　一、项目介绍
　　某养老项目是以某养老团险自助投保系统为支撑。
　　某保险集团养老团险项目是以自助投保系统为支撑，用于其养老团险产品互联网销售业务及客户服务的系统，为中介等合作伙伴或个人提供电子出单、代理直联、银行直联、POS出单、自助卡激活、移动出单等模式的投保、撤单、查询等保单服务及相关客户服务。
　　系统关键模块包括投保、撤保、保单查询、对账、营销方案配置、中介银行管理、保单结算、POS机管理等。
　　系统特点可概况为以下几点：深度整合、统一平台；统一对外标准接口、支持定制；全部保单直接进入核心系统、实时承保；统一的保单查询平台、可实时查询。
　　二、测试工作流程
　　整个项目测试工作流程分为，需求评审、编写测试用例、评审测试用例、执行测试用例，以下是个流程的简述。
　　1、需求评审
　　参加需求评审时关注这十项特性：完整性、正确性、一致性、可行性、无二义性、健壮性、必要性、可测试性、可修改性、可跟踪性。另外，评审前最后将基于产品的项目的业务需求、用户需求和功能需求好好组织、理解、梳理一遍，这样对于整个产品就有了更为全面的了解。如果不懂的地方及时跟需求分析人员进行询问以便于接下来编写质量更好的测试用例。
　　2、编写测试用例
　　编写用例时仔细分析每句需求所涵盖的功能点，把测试的思路理清晰，多思考，扩展思维的去写。如果需求是对系统中原有的某项功能进行优化，最好进系统对那项功能进行操作一遍看看。如果需求中新增的按钮功能同系统中某个按钮功能及处理逻辑一致，那么一定要先操作一遍再编写测试用例，这样的目的是能事先发现需求的可行性，写出质量好的测试用例。
　　3、评审测试用例
　　测试用例写完后一定要再过一遍，然后让同事评审一下，因为人无完人，没人能考虑的万无一失，同事指出不足的时候，也是自己提高学习的一个过程
　　4、执行测试用例
　　第一时间执行一下冒烟测试用例，接下来将测试用例整个看一遍，看哪些用例是可以放一起测试的，或者哪些用例的测试数据是可以整合在一起进行准备的。执行用例时将用例名称和前置条件以及描述信息也都看清楚，因为有些需求信息不是都体现在测试步骤和预期结果里。详细记录软件系统的实际输入输出，仔细对比实际输入和测试用例中的期望输入是否一致。每条用例多个角度多种操作方式多测试几次，发现错误时尽量定位软件出错的位置和原因，并测试出因为这个错误会不会导致更严重的错误出现。在一个项目组中，项目的开发时间是有限的，如果我们测试时能把问题描述的详细一些，那么开发人员就会很容易的重现这个问题，也就能更快的解决问题，节省项目时间
　　三、作为测试人员你会工作吗？
　　项目中经常会出现，在有限的开发时间内我们测试人员在保质保量的情况下，测试完成待上线产品，但也在过程中我们常常听到这样的抱怨，我现在很忙、人手不够、效率太低……带来的结论是：我们的问题太多了。对于测试人员的工作技巧，我主要从以下三个维度进行分享，来提高我们测试人员的工作效率。
　　1.注重细节，不要给自己的工作打折
　　很多人认为：“把工作做到60%太危险，会被公司炒鱿鱼；做到100%太辛苦，也不太现实；把工作做到90%就很不错了。”最终给自己打了10%的折扣。90%真的很不错吗？拿我们执行用例来分析，一个产品的测试用例分成5个模块，每个模块的测试用例测试人员都执行90%，那么这个产品质量的最后结果就是：90%×90%×90%×90%×90%=59%。第一个环节你可能做到了90%，下一个环节还是90%，在五个模块之后，你的成绩就不是平均值90%，而是59%——可想而知，后期的缺陷可能接踵而至，缺陷跟踪占据了你其他的时间……
　　我们从事的工作是业务密集型，深究业务逻辑的话会很复杂，在这种情况下，稍不留神就会漏测需求，我们对细节的要求就会更高。不能以时间紧任务重，对10%的用例含糊了；不仅仅是用例，以上工作流程已经详细介绍每一个环节了，遵循工作流程的SOP，绝对不能打折。
　　2.经验程序化，工作系统化
　　我进入该项目两周的时间，因为老员工交接时间较短，前两天自己的状态像“无头苍蝇”，强迫硬性记忆一些自己并没有接触过的业务要点。对于刚进新公司的员，给自己一个任务，好记性不如烂笔头，每天写一个自己的操作手册，目的主要有3个：①.更快的熟悉“某养老”项目的产品流程；②.通过自己记录的操作手册，记录过程中的问题（问题必须写下来），下班前逐一找同事理解过程难点；③.总结的操作手册反复回看，不仅能更加熟悉产品，还能领悟到新的知识。让自己的经验逐步程序化，自己提高更快。
　　经验上逐渐程序化，除以上需要形成工作手册之外，自己老东家（之前公司）的项目过程中与麦肯锡顾问交流过程中也总结学习到：做要事而不是做急事。对此，我每天早上到公司的第一件事情就是在本子上将今天做的事情做一个分类：
　　今天‘必须’做的事（即为最紧迫的事）；
　　今天‘应该’做的事（即有点紧迫的事）；
　　今天‘可以’做的事（即最不紧迫的事）。
　　一天下来20件事情都不会漏掉。工作系统化，工作效率也会提高。
　　3.沟通是一种武器
　　项目中什么时候需要沟通？上述内容中我们讲到工作流程，按照工作流程内容，在评审的时候为了更加理解需求，我们需要与需求分析人员进行沟通；测试用例评审时我们需要与模块内部人员沟通检查问题点；用例执行时发现BUG或需要了解需求逻辑需要与开发人员进行沟通……由此可见测试人员的沟通在很多地方承上启下，位置很关键。这就需要我们自身具备良好沟通的素质。
　　以上举的例子是正常流程环节下的较简单的沟通内容，那么遇到僵持不下的问题呢？沟通出现问题一定是双方遇到不可让步的难点，解决方法分享（此解决方法纯属个人观点，每次都是这么解决）：①找出矛盾点；②换位理解对方的痛点、难点是什么；③因为在项目中目标是一致的，从对方的难点开始解决攻克问题。很多问题都能解决。
　　沟通其实就是不要吝啬自己的那张嘴。在执行任务的过程中，一定要和上级、下级进行积极主动的沟通，这样我们的目标才会保持一致性，避免执行的偏差。用好沟通这个武器。
　　总结：
　　通过对我们项目整体的介绍和测试流程操作再加上我们测试工作中的小技巧，我们已经规范的运用到实际的工作当中，再通过机制不断地完善，我相信我们的工作会越来越高效。这就是我们项目中软件测试那些事儿，你受益了吗？