一定要记住，有一个职位是软件测试工程师，那么大部分是系统测试工程师。
但是，我带过很多的实习生都不太理解到底什么是系统测试工程师，或者说压根意识不到自己是一个系统测试工程师。比如说，我让他测试一下一款android盒子上的软件，但在测试的时候发现了硬件上的问题、系统上的问题或者遥控器是上的问题，竟然以和我测试的软件没有关系为由，不重视，或者并不上报！这肯定是不对的。(这些硬件、系统是兄弟部门的产品)
作为系统测试工程师，一定要站在整个系统的角度去考虑问题，系统就包括我们要测试软件以及这个软件配合的其他部分，比如和这个软件配合的其他第三方软件，运行的平台等，都是你需要考虑和关注的地方，这才是系统测试工程师。
这里，可能有人要问了，那我要是把所有的功能全测试了，那也太累了吧。这就牵扯到了测试粒度的问题，自己要测试的软件，粒度可以足够的小，而其他模块粒度可以足够的大，甚至几条测试用例就可以完成测试，但不能说不测试，或者说出现了问题不能以和我测试的软件无关而不重视!
这个是许多老员工比较容易犯的，特别是对于连续迭代增量开发很多年的产品。测试用例很完善了，所以基本测试用例很长时间都不会修改，就会犯这个错误。
当一个测试用例使用的时间过久，我们的软件就无法通过这个测试用例测试出问题了，就是免疫了。所以，必须要经常的修改测试用例，比如，根据语法修改，输入框为“刘德华的电影”，过一段时间可以修改为“我要看刘德华的电影”、“我要看电影刘德华的”，所以，也可以搞一个巨大的测试用例库，每次回归测试从中随意的抽取测试用例测试，也是可以的。
这也是我在测试的过程中经常用到的一个原则。就是一个模块发现的问题越多，那么就会有更多的问题没有被发现。
举个我亲身经历的一个例子。我要测试一个模块，模块中定义了大约有20款设备，但是每款设备的使用方法基本相同。于是我写出了第一版的测试用例，重点测试一个设备，如果这个设备通过了，那么另外19款设备我的测试粒度就足够的大，因为我认为只要一款设备通过了测试，其他设备基本就没有问题，流程都是一样的么。
结果呢，这一款设备我测试出了不少的BUG根据物以类聚的原则，我认为会存在更多的BUG在这个模块里，那么之前的测试计划就舍弃了，我又抽取了额外的5个设备进行重点测试，结果又发现了更多的问题。
最后没什么说的了，我设计出了一款超级多的测试用例，针对这20款设备进行了详细的设计，可以说测试用例跑一遍都要2天的时间才能执行完。你能说这是浪费时间么？不能！因为这个模块我发现了超过100个BUG，所依据的就是物以类聚原则，根据测试的结果调整我的测试用例！
这是我最常用的测试原则，也是许多人容易犯错的地方
当然，测试原则很多，许多大家继续学习！测试也是有很多理论的，并非说的容易入门！