工具类软件计算准确性测试历程
上一篇 /
下一篇 2015-07-06 19:36:55
/ 个人分类：测试总结
今天是2015-7-6，3年的前的今天是自己硕士毕业的日子，时间过得真快啊，已经工作3年了。
平时的工作就是先熟悉需求文档，了解相关功能业务，然后设计测试用例，执行用例，提交及复测bug等。 对于我而言，这3年来，测试功能点归纳一下其实就一点：就是验证和确认软件计算的是否正确。将自己的工作分为以下三个阶段：
1）刚开始的时候，称之为第一阶段：单一软件之间的比对。即在界面上输入一套参数，计算得出计算结果，就拿着结果和对手软件进行比对（输入同样的参数），只要计算的结果误差在5%以内就算计算通过。由于计算的东西有时候会有一些不确定的因素，比如程序内部考虑的算法不同，但这种算法也不能说是错的，这样也会导致误差的存在，这时候就需要找组内的需求人员确认，如果觉得程序内部的算法合理，讲的通，那即使对不上也没问题，也算是测试通过。
2）第二阶段：多软件之间的比对。即一个算例需要在不同的对手软件之间输入完成，将各软件的结果汇总，对比分析所研发软件计算结果的正确性。这种测试方法的难点和关键点在于不同软件之间所输入参数的统一上，这是往后面继续测试的前提，如果参数设置的不同，后面的对比工作肯定做不好。所以就需要平时将各个对手软件都学会、熟练操作。另外，就是工作量大，如果设计了10个算例，每个算例都需要在5个软件中的执行，那就需要执行50遍。
3）第三阶段：自己编excel表对比。这种对比方法相对自由了一些，因为需求想实现一种全新的办法，因此只需要按照需求文档，将计算项做成excel表，然后输入参数，测试excel表格计算的结果和开发在程序实现的是否一致。当然，不排除测试人员和开发人员对需求的理解不一致造成的bug，如果结果对不上，就重新和需求文档核对，最终达到测试所用的excel表和开发实现的一致。这种测试方法适用于在需求提供的计算公式十分明朗、便于手算的情况。另外，也增加了测试人员对业务的理解，相当于测试人员按照需求文档完成了一次编码工作。
想想这三年来，最难的就是测试算例的构造了。因为有时候计算结果提前不可控，你设计完的算例并不能测到某个分支，所以就需要加强对业务的学习，尽可能多的尝试，直到出现能覆盖测试点的算例。另外的一个难点就是中间计算的结果的输出上，因为程序往往反馈给你的是最终的一个结果，而需要计算这个结果，中间还有很多中间参数，有时间是中间参数出错造成最终输出出错，所以就要和开发协商，能不能辅助测试，将中间结果一并输出，也好定位bug出现的原因。总结一下，计算出bug的原因：1）输入的参数的不一致；2）计算公式出错，需求中一个加号，开发编一个减号；分子分母编制颠倒等；3）某些参数的取值不能随着界面参数的改变而做联动；4）计算的没错，就是在文本的输出或者是结果展示上出错。
计算准确性的测试还是挺有意思的，当然，还要不断的学习，多扩展自己的知识面才能做好更多的测试工作。
收藏
举报
TAG:
软件
引用 删除 sunshine2006 / 2015-07-07 13:40:27
