空间管理您的位置: 51Testing软件测试网 » qishaorain的个人空间 » 日志

测试新说——重新定义测试的结束点

上一篇 / 下一篇 2014-09-24 17:29:10 / 个人分类：测试新说

看了一些探讨如何定义“测试 结束点”的文章，略有感想。还是先感谢作者的分享。原文每条很有道理，但是推广起来，一个字~难！为何？时代使然，环境使然。就如古语说“尽信书不如无书”未免冗余，我仅分享一下，对原文中两点的思考，其余大家可以结合实际去考虑。
   关于测试结束点：
1. 原文提到基于测试阶段。
称每个测试都要经过，由单元测试到，集成测试的过程！
且提到了量化指标，例如功能覆盖率达100%等
【问题】
1）正如我前面所说，现在是移动 互联网的时代，测试工作也面临着改革。
其中测试时间短，发布周期短，快速迭代的特征不容忽视。
敢问有多少测试同胞的实际测试工作中，从单元测试，集成测试，系统测试，一步步走下来？
又多少人为每个阶段制定严格的标准，量化考核？
              这感觉就像是OSI七层网络模型，和TCP/IP参考模型的关系。
2)如何能说明功能覆盖率真的达100%？
似乎从接触软件测试的第一天就明白了，bug永远不能穷举。

2.原文提到基于测试用例
称功能用例达到100%，非功能用例达到95%可以认为通过。
【问题】
1）敏捷流程中的用例评审时间非常短，直接影响的就是用例质量。
且说到底，用例评审属于准备阶段，软件测试的核心在于测！
有个原则说的好，尽早，尽快介入测试。发现尽可能多的bug这是测试的目的。
2)可以回想一下自己的项目，实际中有多少是经过严格反复的用例评审？
有多少甚至是后补用例？
有多少次面临需求变更，导致用例难以维护？
3)即便保证100%的用例通过，就能说明测试软件没有问题，可以停止测试了嘛？

……

很多时候，大家更希的是实际的解决方案，而非理论的罗列。我也曾反思，只有一堆的策略却无具体的实施方案，难免落实起来困难。回归问题，测试结束点该如何定义？若我说：“测试不可能真的结束，除非项目消亡”。听到这里是不是有些失落？试图给这样一个无止境的点下个定义，略显徒劳了。
莫不来看个相关的话题“如何有效的组织测试过程？其实原来作者提到的很多观点，并非回答如何定义测试结束点。更准确说应该是探讨如何组织测试过程。只是这种组织过程过于传统，也过于理论化了。

来些实际的。如今测试，尤其是移动互联网测试，可以做到的无非是三点。
1）软件发布前，尽可能发现多的bug，且推动修复。
2）软件发布中，尽可能早的发现暴露出去的问题，且推动快速修复，迭代上线。
3）一轮发布完成，尽可能多的总结此次的经验，教训。不断的优化测试过程。
这就是简单的软件测试组织过程，感兴趣的朋友可以联系我，一起讨论。

至于测试何时“告一段落”也就是所说的结束点。通常有这些因素：
1)测无可测
比如只有两个人负责测试，他们能想到的测试点，和测试思路，都已经反复测试。
此时在无新人员补给，无新思路提供，无bug反馈的时候。恐怕再让他俩测一年也不会有更多的bug。
这就是所谓的“bug相对饱和期”。
此时，要么让此二人，去做新的版本。要么安排更多人进来思维风暴。这就看公司的资源情况了。
前者避免资源浪费，后者能提升测试覆盖度。是很实在的办法。
2)项目紧迫。上线时间严格。
正如前面提到，bug必然不能穷举，我们能追求的是在有限的时间里，尽可能的发现更多的bug。
如果上线时间定死，我们所有的测试计划，测试评审，测试讨论，测试进程都要严格把控在这个时间点前。
就像冲锋号一吹不能不能补冲！如此令行禁止项目才能良好运转。
我们的目标是在这个时间点前，达到“测无可测”。
能力不足可以慢慢提高，经验不足可以慢慢积累。
未尽全力就是态度问题，能测未测总有遗憾，就是组织不当。
3)做完反馈收集，用户体验分析，bug数据分析，再稍微歇息。
人不是永动机，测试不停人要歇息。但是何时才能暂时歇息呢？
不是上线，而是把重要的收尾工作做好。也就是以上这些。
4)项目over，这个不用多说了。

其实，每个人心中都有自己的测试结束点，每个项目也有自己的特性。一句话实事求是的解决问题才有效果。
共勉之！