写了第一篇关于软件测试的文章，觉得还是有读者的，让我觉得特别欣慰。
我自己对软件测试的了解不算深入，文章也很入门级，起初的感觉最好的是写测试用例（TestCase），特别是使用mindmanager+excel，写出感觉的时候那真是分分钟的事儿。不过写出用例后问题来了，用例执行时间与用例数量基本是成正比的，往往执行用例会很耗时，那时就要开始合理的删减用例了。
整理用例常用的方法无非是什么等价类、边界值、因果图、判定表、正交法等常用的，究其根本，是通过一些逻辑推理的方式将相同路径的用例合并，从而达到事半功倍的效果。不过这里有坑，因为写用例时，大部分测试人员基本不了解开发实现的过程，这也会导致看上去可以合并的用例背后逻辑有所区别，从而引发漏测。而一旦漏测的点属于关键路径，触发几率高，那么产生的线上问题足够整个团队喝上一壶了。另一方面，如果项目前期测试与团队的沟通不足，很有可能出现推卸责任的问题，虽然从职业素养上不提倡，但关系到个人或小组利益时，往往不得已而为之。
以上的内容有点暗黑，但是并非不存在。
自己接触软件测试的理由比较“单纯”，开发能力不行，代码勉强读懂，毕业时看着软件工程的一些理论知识，眼前一亮——“就是他了！！！”
现在再观察一下国内的软件企业，对于80%的企业软件测试岗位更像个鸡肋。没有的话觉得特别low，产品质量怎么保证呢？说产品高质量自己都心虚啊。但有了又能怎样？所有的测试平台、测试流程都要自行搭建，没几个资深的测试架构人员还真搞不定。那这测试岗位搞不搞呢？个人认为大公司得搞，而且得结合自身条件狠狠搞，几十人的小团队就值得考虑了，产品质量是不是重点，流程未规范的时候，专门招聘测试的成本可不低。
对于谈论很多的开发测试比，实际使用时却有点上纲上线了。对于具体的数值，没有定论，也别觉得1：1就是好6：1就是差。这与开发测试的能力息息相关，一个牛逼的白盒测试工程师也许能抵10个普通的黑盒测试工程师，这也是为何开发转测试so easy的原因。通过接口测功能也许只要10个用例，但是被添加了上层逻辑之后，也许就需要100个用例。每个测试都向往着google的开发测试比1：1，却不知测试工程师的能力比开发工程师还要出众。
对于企业来说，普通的测试工程师的数量怎么都觉得多；对于普通的测试工程师来说，数量怎么都觉得不够。没有对错，所站的角度不一样而已。
