软件测试的核心价值是什么？

　　Philonis高在微博上发起了软件测试的价值体现在何处的讨论，蛙蛙王子则向大家提问：如何在实际工作中更好的重构?

　　测试的价值

　　Philonis高在微博上表达了对软件测试价值取向的看法：

　　很多人都说质量不是测出来的，这句话没错。不过，测试存在的意义其实有两点，创造价值和守护价值。质量要靠测试者来守护，而不是创造出来。“守护价值”存在于传统测试工作中;而“创造价值”，正是我们现在正在探索的。

　　对于测试如何创造价值，或者说测试创造的价值是什么，很多人也有自己的看法。我预设的前提是，静态测试、需求评审等工作被划入“守护价值”，也就是将“创造价值”的范围缩小了，免得有哲学帝说一切工作都是创造价值。

　　朱少民老师：

　　守护价值和创造价值说得好!创造价值体现在基于客户的立场提出积极的质量反馈意见，以及对缺陷的分类、分析，总结出缺陷模式，回馈到前期过程，预防缺陷。

　　原草莫莫：

　　认同。我们现在搞的故障模式测试就是这样的一个实践。测试不依赖于开发的上游输入，通过反向验证推动产品质量改进。测试在产品也愈来愈有话语权。

　　还有就是，当质量标准往往很难定义的时候，这个时候往往测试标准就成了产品潜在的质量标准。通过测试对产品质量作出诠释，这实际上也是一个引领开发、创造价值的过程。当然前提是测试对质量标准有足够的理解。

　　Ang-Ani：

　　测试当然创造价值。如在V model 中所谓的静态测试，review用户需求，及早发现需求中的defect，就是创造价值。如在敏捷测试中，测试结果反馈到下一个iteration,也是创造价值。再如测试驱动开发中，测试主导着开发过程，当然创造价值。

　　质量就是测出来的。但是要知道何时测，测什么，如何测。不能把测试局限于后期的execution。从项目开始的最初，测试作为一个activity就应该存在，测试包括，静态的review 用户需求、技术文档及代码，动态的单元测试及非功能测试..如果脑海里只有waterfall模式：design code test，那么质量只能靠天收。

　　梅万龙：

　　"质量不是测出来的"——质量主要是靠设计的，有些产品还是得靠测试去发现，这也可以说质量是测出来的，而通过设计分析预防，测试维度分析预防成本更低，我们更乐于说，来通过预防来保证质量，而不是傻呼呼的都靠去测。

　　"质量要靠测试者来守护"——质量是靠整个团队来守护，测试只是其中比较大的"发动机"。产品有比同行更好的质量，不就是要探索的价值吗?否则，不能从岗位角度看价值，得从人的职责和能力角度找价值了。

　　Aullyxiao：

　　这种情况也遇到不少，最后是项目经理确认某需求问题不找需求人员，而是找测试人员了，而测试人员直接找用例库，可想而知用例库的重要性和作用。这样思考之，探索式测试由于在事先没用例，事后补充的测试记录比较有限，也是一个限制。

　　陈尚义：

　　质量不是测出来的，这句话对传统产品是无可挑剔的正确，我见过纺织厂的质量检测人员，他们发现了错误就不能改，质量检测员当然不能提高质量。但对软件产品情形就不太一样，测试发现了问题马上就得到改正，这就提高了质量。另外，软件测试涵盖的范围很广，测试还可以建立对产品质量的信心。

　　让测试飞起来：

　　软件的历史是隐藏细节的历史。从routine到子程序，到procedure，到函数，到类(抽象类、接口)、到SOA，再到今天的云，无一不是将简单留给用户或后来的调用者，将细节隐藏。云计算将资源调度、管理、运维、安全保障、应用开发等细节隐藏，用户按需使用即可，一种到目前为止最高级别的细节隐藏。

　　Frank-Lin：

　　分析用户及其习惯，从用户角度进行测试和评估系统，从而，测试不仅仅是守护价值，推动了价值的创造。

　　重构之惑

　　蛙蛙王子在微博中向大家提问：

　　看到代码中的坏味道，做到立刻重构，感觉太难了。书上说一个敏捷开发的人，从来不说稍后再重构，稍后等于永远不，他们不会看着软件走向腐化。认同是非常认同，实际中做的话，感觉哪儿都需要重构，坑太大了，而且还得先补测试，大家怎么来按部就班重构没测试的老系统的?

　　乐淘网丁学：

　　我一般是不会要求大家去做重构，但是会要求遵守童子军规则：永远保持离开时的露营地比你发现它时更整洁。

　　软软的胖糖：

　　如果是一个新系统，大家按照这个原则去做就不会有这个问题了。当然如果个别人做，坑太大了那也是没办法的事情。

　　横刀天笑：

　　除非你有一个非常能接受这种做法的团队，不然这种看见不爽就重构只会死的很惨。当然，如果你要染指某块代码，你可以乘机重构～

　　wolvever：

　　我们花了2年重构，边重构边开发新功能。所谓高速列车上换轮子，外科手术式重构。不分支，先易后难，影响小依赖少的优先，还要考虑业务发展，保证每次重构部分随时可以上线。时机很重要，不是看见就改，修改代码必须立项;不是一次改彻底，一定得容易可控周期短;不是纯技术问题，要与业务充分沟通。

　　飞林沙:

　　我觉得更现实的做法是当出现新需求时，如果原有代码无法适应需求，那么则为了适应这个需求重构。

　　TW张逸：

　　我认为重构必须把握几个原则：

　　1、重构需要有测试的保护网，每次重构后必须跑一下测试;

　　2、代码库的集体所有权;

　　3、最好能有CI，至少保证频繁提交，避免因为重构引起的大量冲突;

　　4、重构应随时进行;

　　此外，还有一些比较好的实践，例如每日的Code Review;尝试尽量使用工具进行重构。

原文转自：http://www.ltesting.net