现在，几乎所有接触IT行业的人都开始熟悉软件测试了。但似乎所有人的评判标准似乎还停留在“能更多更快找出bug的才是好的测试工程师”。仔细思考这句话，有错吗？好像逻辑上挺能说得过去，于是不光别人这样认为，测试工程师自己也开始这样考量自己了。

　　这样下来，测试工程师就直接与“找bug的人”划上了等号。我挺想用本末倒置来形容这种现象，当然回想自己这2年多的工作，与这也比较类似。对测试工程师来说，目的是要保证产品质量，找bug只是其中比较重要的一个环节，但绝不是做好了这个环节就能代表自己很出色，因为你一定还听说过“bug是找不完的”这么个预言。

　　这个问题有些纠结，因为翻开书，都会先把软件工程大篇幅描述一遍，然后告诉你一整套规范的软件企业流程，具体怎么用，几乎没有涉及。当你了解之后，进了公司，发现“我X，完全不一样”，说好的这些规范怎么都不执行，这个公司是不是不靠谱啊。

　　答案当然是否定的，leader当然知道需求的变更、开发的延迟都会对软件质量带来风险，但是对当下的市场来说，按照流程按部就班肯定不符合大局。那么测试工程师要怎样适当地将风险降低呢？分享一些小经验，对于大牛来说直接跳过吧。

　　对任何一个产品，增加对产品的熟知程度总归不是坏事。当知道产品的开发逻辑是怎样的，便能很好的响应需求变更。

　　举个例子，产品的需求原本使用A方案实现，却由于需求进行了微调，使用B方案将更适合。对于没有经验的产品经理，往往从开发那里获取方案，此时开发流程已经开始，调整方案将会增加工作量，带来风险是必然的，那么对测试来说，该如何给出建议？

　　如果对产品逻辑不知晓，当然是任由开发“摆布”，后期二次改动同样需要工作量。但如果熟悉产品逻辑，可以将两种实现方案进行比较，列出优缺点进行评估，最终采用更合理的方式解决问题。

　　所以，对产品各个模块的熟悉是测试人员一个非常必要的能力。

　　对于测试用例的优先级明确划分

　　在测试时，大家总是会忽略测试用例的重要性。一个产品动辄上千的用例实在让人头疼。但是，好的测试用例能够帮助测试工程师在时间紧急的时候提高测试效率。

　　测试工程师对测试用例一定不陌生，但是挑选待执行的用例时往往比较随意，有一句话特别好，“差不多就行了”。但这个差不多往往是坑了自己，工作量变大，有效性可能降低，反而得不偿失。

　　如果你有想法把产品的部分功能做成自动化测试，那么恭喜你，至少为自己减少工作量提高效率找了一个好思路。But，自动化没有想象中那么简单。

　　首先，得要研究不同的自动化测试框架，并且找到当前产品适用的

　　第二，区分好产品模块，哪里适合，哪里不适合，比如UI自动化和功能自动化有可能选择不同的框架

　　第三，区分优先级，一般来说，使用频率高的模块优先考虑

　　另外，实现时一定要考虑方案是否完善，一个半成品的自动化测试代码更加坑人。

　　介入需求一定要早早早

　　千万不要认为测试工作开始于开发的动工，了解需求对于测试工作太重要了。工作中，经常会出现产品经理描述需求不明确，或者产品、开发、测试三方理解不一致，提前统一战线必然有利于降低风险。

　　同时，讨论评估需求时，测试工程师可以从需求的来源进行分析，提出这个需求是不是该这么做，虽然没有太多的工作量，但是对于产品的质量和可用性是很有好处的。