怎样算是“好”的软件测试用例--兼谈软件测试人员的评价标准

         看了茹炳晟在极客时间的专栏，结合十来年工作的感受，也谈谈自己的看法。测试用例评价当然不能以是否发现问题来评估，毕竟测试是否发现问题，和被测系统关联很大。测试本身的一大作用，就是确认交付件（工作产品）的可接受度，也可以说是质量评估，或者系统发布的风险的信心程度。对于第三方测评，是按照某个标准来说，是否可以接受；对于内部研发测试，就是系统发布的风险度，是否在可承受范围内。

一、测试用例（集）评价         

       具体来说，评价单个测试用例是没有太大意义的，应该针对测试用例集（测试设计）来评估：

       1、用例覆盖程度
　　毫无疑问，这一点应该是最重要的，无需多说，覆盖率最大化是一套测试用例的最重要评价标准，如果漏测就杯具了。

　　2、用例工作量是否满足限制情况下最优化，当然通常就是指最小化
　　在满足各项资源限制情况下（比如时间、人力、设备、工具、花费），用例覆盖程度最大化的前提下，应该尽量实现工作量最小化，减小执行用例所需要的工作量。这些方面的方法有不少，如条件覆盖，分支覆盖，正交覆盖等方法。面对不同的测试对象，也有不同的方法来保证：对于网页背后的php逻辑，可以通过在网页上测试后，用一些工具比如xdebug来统计代码覆盖率；对于向外提供接口的server，采用的方式就是分析在外面暴露的接口设计用例，大致的通过接口参数来估计一下分支判断的情况。需要有权衡（Tradeoff）的情况下，最优化和覆盖程度应该根据测试目的基于风险驱动。

　    3、用例的设计技术是否合理
　　和写代码一样，用例设计得好，合理的话，应该是，a、思路清晰；b、可以按照模块提取，方便地重用的；c、易于维护和修改。这三个好像是一回事，但确实比较重要。其实最好有个高层文档，就好像一个测试设计方案，但不要用格式化的word文档，最好就是一个表格的，把整个设计的权衡、数据的准备和选择、环境准备等，具体的用例项分解表等方面简明地展示出来。有就写，没有就空着。

       ps： 还是决定增加一点。4.测试用例设计人员对被测系统了解得是否深入。针对第三点，其实思路清晰、策略得当，前提就是理解被测系统，所以评价前，先请测评项目组真的要理解被测对象，能够深入浅出地说清楚被测对象的运行机理和处理机制，能说得清楚，才能够真正地测得到位。

 

   二、软件测试人员评价

          上面的测试用例集评价标准其实是适用所有测试的，不只是软件测试。

          具体到软件测试人员评价，那么就比较复杂了。因为根据我的实际经验，一般中小企业的软测人员，素质好的总希望转行去做软件开发（毕竟技术上升空间和满足感强）、或者想转行去做业务（毕竟职业空间相对大）；素质差一些的就想着哪里活少薪资高盘算着蹦跶；最次的就是混吃等死的，要做就去瞎点一阵，报告就照模板出一下。

          好吧，只从个人的职业经历出发：

         1、爱岗敬业：测试岗位比较热爱，达到一定等级之前不会只想着转换工作，愿意花时间学习和钻研测试技术，学习行业领先公司和专家的思路、方法、工具和论文；

         2、服务大局：对测试项目的各项限制有清晰认识，在此基础上尽量做好测试设计，做出好的测试用例（集），服务项目大局，不一根筋死抠。

         3、目标达成：测试工作综合效果比较好，个人能够按照预期的设计完成执行，报告的问题有效，经手的被测件和软件测试工作交付件，能够达到测试设计预期的综合效果。

        4、持续改进：态度积极主动，愿意花时间去琢磨自己的工作，考虑如何优化和重构自己的工作交付件（测试用例集）和测试工作中的各个环节，保证测试效果，做项目过程中特别是项目节点会不时总结，分享经验，考虑推进模板更新和流程改进。

         5、方法优化：和4有点像，但偏重技术方面。愿意去钻研一些软件脚本开发等自动化技术，优化和改进自己的工作过程和测试方法。例如：用一些工具化的方式来自动提取测试结果；工程化的方法自动重用和生成常规测试用例等。