Question

如何提高测试用例编写效率

Answer 1

如何区分测试用例的粒度

我们是不太可能在一个测试用例中包含所有测试需求，因为众多的功能以及不同的路径组合将使这样一个测试用例像大象一般，完全不具有可行性。除非您的软件所包含的功能真的又少又简单，不过如果真的有这么一个软件，恐怕也没有测试和发布的必要了。

当然，这也并不是要您走向另一个极端，为需求中定义的每个特性或功能都提供一个甚至多个测试用例。这里的关键，是要寻找一个合适的度。

有效功能：就是指在被测应用所涉及的实际业务中，当用户在手工状态下进行工作时，整个业务流程中对用户来说，具有实际意义那些功能。

如何评价一个软件测试用例的好坏？

1、易用性。对于一个即熟悉测试工作，又熟悉被测应用的测试人员，应当可以花费很少的时间就可以理解测试用例中表达的测试思路，并可以很快的执行完这个测试用例。

2、易维护性。当开发过程中的某些因素影响了测试需求，测试用例的作者或其他测试设计人员，应该可以花费很少的时间就完成定位并维护所有相关测试用例的工作。

测试人员应具备的七种思维方式

作为软件测试人员，应具备以下七种思维方式：逆向思维方式，组合思维方式，全局思维方式，两极思维方式，简单思维方式，比较思维方式，动起来，更精彩！

1、逆向思维方式

逆向思维在测试中用的很多，比如将根据结果逆推条件，从而得出输入条件的等价类划分

其实逆向思维在调试当中用到的也比较多，当发现缺陷时，进一步定位问题的所在，往往就是逆流而上，进行分析

逆向思维是相对的，就是按照与常规思路相反的方向进行思考，测试人员往往能够运用它发现开发人员思维的漏洞

2、组合思维方式

很多东西单一的思考都没有问题，当将相关的事物组合在一起却能发现很多问题；如多进程并发，让程序的复杂度上了一个台阶，也让程序的缺陷率随之而增长

按照是否排序组合可以分为：排列（有序）和组合（无序）；针对不同的应用，可以酌情考虑使用“排列”或者“组合”

为了充分利用组合思维而不致于让自己的思维混乱，要注意“分维”，将相关的因素划分到不同的维度上，然后再考虑其相关性

3、全局思维方式

事物往往存在多面性，当我们掌握了越多的层面，我们对它的认识就越清楚，越有利于我们掌握其本质，全局思维方式就是让我们从多角度分析待测的系统；试着以不同角色去看系统，分析其是否能够满足需求

其实平常我们在软件开发过程中，进行的各种评审，就是借助全局思维的方式，让更多的人参与思考，脑力激荡，尽可能的实现全方位审查某个解决方案的正确性以及其他特性

4、两极思维方式

边界值分析是两极思维方式的典范

为了看系统的稳定性，我们采用了压力测试

两极思维方式，是在极端的情况下，看是否存在缺陷？

注意是两极，不是一极

测试人员做久了，往往容易走极端——职业病，不利于与人沟通

5、简单思维方式

剥离一些非关键特征，追逐事物的本质，让事物简单的只剩下“根本”

针对事物本质（解决问题的本质）的测试，让我们不至于偏离方向

6、比较思维方式

认识事物时，人们往往都是通过和头脑中的某些概念进行比较，找出相同、相异之处，或者归类，从而将其加入大脑中的知识体系，可能的话，再建立好的搜索方式，以便以后使用

应用模式是“比较思维”很常见的例子，现在模式很火，有设计模式、体系结构模式、测试模式、等等，一些专家针对一些相关问题的共性找出来的解决方法，取完名字后，可以让大家方便的复用

让经验在这里发挥作用，测试中经验很重要，比较思维是使用经验的方式

7、动起来，更精彩

传统的基于结构的程序可以更多的在代码中反映将来程序的运行方式；而面向对象将代码和运行时显著分离

其实这些思维方式，大家都在有意识或者无意识的使用着，它们各自都有自己的妙处，将我们的思维发散，有意识的将他们用在问题的思考上，有时可以给我们一种“柳暗花明又一村”的感觉。

最后想说，只是知道这些原则意义不是很大，如果真能让它们成为思考的血液，才能发挥它的真正价值。那真的需要很多的历练，其实成为一名出色的测试人员，远没有那么简单，需要简单，需要（不断的学习 不断的经历 不断的思考）。

测试新人答疑解惑之测试用例篇

编者按：本文主要回答了测试爱好者提出的一些关于测试方面的问题，希望能给大家提供帮助，共同进步。

网友来信中提到的问题如下，都是和测试用例相关：

1、做测试已快一年了，感觉学到很多.但是很迷茫。

迷茫的问题是：会写测试用例了，但是写的测试用例总觉得不全面会有遗漏

2、关于幻灯片播放模块不知道该用什么样的思路来写模块，希望我能给些建议

这两个问题我的回复如下：

人无完人，测试用例不可能全都能想到，这个需要靠经验的积累。如何在写测试用例时，减少遗漏呢，这里有几个方法供参考：

1）测试用例要覆盖用户需求或者产品需求

2）如果是升级产品，可以参考以前编写过该产品的测试用例，通过了解别人写用例的经验来扩展测试点，在看别人写的用例可能会让你想出新的用例点

3）测试用例进行评审，让大家帮你检查一下测试点有哪些地方有遗漏或者你没有想到的测试点

4）收集遗漏的测试点进行总结；办法是：每次产品上线后，多收集统计用户反馈的问题，看是否是自己没有发现的，补充总结用例，每次写用例时多考虑考虑这些方面

5）对于遗漏的测试点或没有想到的测试用例点，要有个好的观点和心态去看待，不要因为自己的用例写的不全就觉得很丢人、觉得自身能力差；只要多多思考.总结找到方法应对，慢慢的你的测试用例就会遗漏的很少了。

6）测试用例即使想全了.也要把测试用例按照重要级别分3类：

主要业务流程、主要功能、扩展功能；

分成这几类是为了便于在执行时先测试优先级别高的用例，在测试不重要的用例，好早一些发现严重问题。

关于幻灯片播放的测试用例，我没有这方面的测试经验，对方也没有给出具体的需求，不过我可以提供几个思考点，希望会对你有帮助：

1）幻灯片播放的流程测试点：

用户登录-》正确创建幻灯片-》查看创建的幻灯片图片显示

2）主要功能测试点：

创建幻灯片支持的幻灯片图片样式：JPG等等，可否正确支持

幻灯片图片样式显示是否正确

修改幻灯片，修改幻灯片后查看显示

删除幻灯片，删除幻灯片后查看显示

幻灯片播放顺序等等等等

3）功能扩展测试点：

创建不支持的图片格式

上传的图片大小超过指定大小

各种浏览器下幻灯片显示的样式

没有创建幻灯片时初始文字显示等等等等

我暂时能提供这几个思路，具体要根据需求和产品业务去写测试用例中的测试点。

如何证明或者度量测试工作的有效性

度量是改进过程的有效途径之一。通过对测试过程的度量，可以使测试过程规范化、可视化;对度量数据的分析，可以测量出测试过程的有效性及存在的问题，明确测试过程的改进方向，从而保证软件的质量。因此，对软件测试过程的度量研究具有十分重要的意义。那么，如何证明或者度量测试工作的有效性？

下面来对这个问题，谈谈我的看法：如证明测试工作的有效性。

1）我们要看到我们所做的工作的存在

相信大家都经历过，自己虽然做了很多的工作，但领导却看不到。比如你一天中在不停的测试，反复的测试，但经理却以为你这一天浪费掉了。为什么？ 因为看没有看到可以看见的测试用例，没有看到你提交的大量的缺陷。

改进：把你做的工作具体化，量化。

你无论是按照计划测试，还是自由测试，那么做了多少测试执行就要写多少测试用例，发现了问题就要及时提交缺陷。即使你完全按照已有的用例测试，也没有发现缺陷，那么你要体现你的进度和你新增加了那些测试数据，这是你工作能力的体现。你做了多少工作，下班前报告给领导吧，让他知道你做了这些事情。

2）我们要看到我们所做工作是否有意义。

你在一个不是测试重点的地方花费了很多时间并且没有任何收获，显然你这次测试是没有意义的。

改进：测试前要很好的理解测试计划和 测试策略，测试方案，一定保证测试进度和测试重点。

3）要证明我们的测试工作是否完全。

测试覆盖是一个不可能完全做好的工作，需求覆盖，用例覆盖，功能点覆盖等。我们可以把已有的需求点来覆盖，但我们无法理解另外的我们所不知道的需求；我们可以写用例，但我们知道测试数据很难找全；我们可以测试看得见的功能，但那些看不见的呢？

改进：简单的说，要建立一套有效的管理模型。

4）保证我们所做工作的效率。

效率就是最短的时间处理最多的事情。这一点很难有标准。你能说一天执行10个用例的就比执行20个用例的效率低吗？

改进：加强测试人员自身的能力提高，可以有效的提高效率，减少无效的工作。例如，对一个经验丰富的测试人，他可以轻易的想到最可能多的测试数据，他可以最快的定位缺陷。

5）如何来度量我们的测试工作。

我们谁都不能证明我们繁忙了一段时间的工作做的到底有多好或者多烂，我们只能用数据说话，数据是公平的，是没有情绪的。

改进：在测试准备阶段，我们就要定义一些标准，来限定或者指导测试的进行。比如多少的用例通过率可以说明系统的健壮程度；同样还有需求覆盖率，严重缺陷比率，缺陷单日出现率，失败用例分布，缺陷分布等。我们后期更是可以利用这些数据来做测试过程的优化工作。数据统筹工作，对于测试来说是非常有意义的。

总之，最有效的测试工作就是用最少的工作时间，最高的工作效率，最低的测试风险来完成了测试工作。