看了茹炳晟在极客时间的专栏,结合十来年工作的感受,也谈谈自己的看法。测试用例评价当然不能以是否发现问题来评估,毕竟测试是否发现问题,和被测系统关联很大。测试本身的一大作用,就是确认交付件(工作产品)的可接受度,也可以说是质量评估,或者系统发布的风险的信心程度。对于第三方测评,是按照某个标准来说,是否可以接受;对于内部研发测试,就是系统发布的风险度,是否在可承受范围内。
一、测试用例(集)评价
具体来说,评价单个测试用例是没有太大意义的,应该针对测试用例集(测试设计)来评估:
1、用例覆盖程度
毫无疑问,这一点应该是最重要的,无需多说,覆盖率最大化是一套测试用例的最重要评价标准,如果漏测就杯具了。
2、用例工作量是否满足限制情况下最优化,当然通常就是指最小化
在满足各项资源限制情况下(比如时间、人力、设备、工具、花费),用例覆盖程度最大化的前提下,应该尽量实现工作量最小化,减小执行用例所需要的工作量。这些方面的方法有不少,如条件覆盖,分支覆盖,正交覆盖等方法。面对不同的测试对象,也有不同的方法来保证:对于网页背后的php逻辑,可以通过在网页上测试后,用一些工具比如xdebug来统计代码覆盖率;对于向外提供接口的server,采用的方式就是分析在外面暴露的接口设计用例,大致的通过接口参数来估计一下分支判断的情况。需要有权衡(Tradeoff)的情况下,最优化和覆盖程度应该根据测试目的基于风险驱动。
3、用例的设计技术是否合理
和写代码一样,用例设计得好,合理的话,应该是,a、思路清晰;b、可以按照模块提取,方便地重用的;c、易于维护和修改。这三个好像是一回事,但确实比较重要。其实最好有个高层文档,就好像一个测试设计方案,但不要用格式化的word文档,最好就是一个表格的,把整个设计的权衡、数据的准备和选择、环境准备等,具体的用例项分解表等方面简明地展示出来。有就写,没有就空着。
ps: 还是决定增加一点。4.测试用例设计人员对被测系统了解得是否深入。针对第三点,其实思路清晰、策略得当,前提就是理解被测系统,所以评价前,先请测评项目组真的要理解被测对象,能够深入浅出地说清楚被测对象的运行机理和处理机制,能说得清楚,才能够真正地测得到位。
二、软件测试人员评价
上面的测试用例集评价标准其实是适用所有测试的,不只是软件测试。
具体到软件测试人员评价,那么就比较复杂了。因为根据我的实际经验,一般中小企业的软测人员,素质好的总希望转行去做软件开发(毕竟技术上升空间和满足感强)、或者想转行去做业务(毕竟职业空间相对大);素质差一些的就想着哪里活少薪资高盘算着蹦跶;最次的就是混吃等死的,要做就去瞎点一阵,报告就照模板出一下。
好吧,只从个人的职业经历出发:
1、爱岗敬业:测试岗位比较热爱,达到一定等级之前不会只想着转换工作,愿意花时间学习和钻研测试技术,学习行业领先公司和专家的思路、方法、工具和论文;
2、服务大局:对测试项目的各项限制有清晰认识,在此基础上尽量做好测试设计,做出好的测试用例(集),服务项目大局,不一根筋死抠。
3、目标达成:测试工作综合效果比较好,个人能够按照预期的设计完成执行,报告的问题有效,经手的被测件和软件测试工作交付件,能够达到测试设计预期的综合效果。
4、持续改进:态度积极主动,愿意花时间去琢磨自己的工作,考虑如何优化和重构自己的工作交付件(测试用例集)和测试工作中的各个环节,保证测试效果,做项目过程中特别是项目节点会不时总结,分享经验,考虑推进模板更新和流程改进。
5、方法优化:和4有点像,但偏重技术方面。愿意去钻研一些软件脚本开发等自动化技术,优化和改进自己的工作过程和测试方法。例如:用一些工具化的方式来自动提取测试结果;工程化的方法自动重用和生成常规测试用例等。