以下准则出自Ron Patton《Software Testing》一书，在测试职位工作多年后，对其中的准则体会颇深，分享以下10条实用性超强的准则及其在工作中的实践，建议在工作中多加参考：
完全测试一个程序是不可能的。（It’s Impossible to Test a Program Completely.）
实践：根据项目时间、资源、风险、用户要求等，有选择地去测试。软件测试是一种基于风险的活动。（Software Testing Is a Risk-Based Exercise.）
实践：一般新功能、常用功能、默认配置属于高风险，需要优先测试，分配较多资源，而回归功能、不常用功能属于低风险，可以延后测试，分配较少资源。测试并不能证明错误不存在。（Testing Can’t Show That Bugs Don’t Exist.）
实践：测试过的场景没有问题，但没有测试过的场景无法确认是否有问题，所以测试结论只能基于已测试的部分说明。发现Bug越多的地方，会有更多Bug。（The More Bugs You Find, the More Bugs There Are.）
实践：在一个地方发现Bug后，应投入更多资源测试这个地方，在验证Bug时，要做回归测试。农药悖论：你对软件测试得越多，它对你的测试就越免疫。（The Pesticide Paradox: the more you test software, the more immune it becomes to your tests. ）
实践：相同模块分配不同测试人员进行交叉验证可以防止农药悖论。并不是所有你发现的bug都会被修复。（Not All the Bugs You Find Will Be Fixed.）
实践：Bug可能会由于风险大、项目紧迫、Bug等级低等原因，不被解决，对于此类Bug，要说明不被修复原因，便于后续跟踪。Bug什么时候会被变成Bug难以确定。（When a Bug’s a Bug Is Difficult to Say.）
实践：需求、项目成员、用户要求均可能变动，对于Bug的把握要基于最新的状态进行，不同时期要及时更新Bug准则，按最新的要求发现问题。产品说明永远不是最终版。（Product Specifications Are Never Final.）
实践：产品说明对测试至关重要，要推动产品及时更新并通知相关改动，此外，测试也是推动产品说明更新的来源，不要过于依赖产品说明，遇到不合理的地方要及时沟通。软件测试员不是项目团队中最受欢迎的成员。（Software Testers Aren’t the Most Popular Members of a Project Team.）
实践：要注意和团队其他成员的沟通方式，尤其是产品和研发，和产品沟通需求要尊重对方的意见，但觉得不合理处，也要提Bug记录，和研发沟通，多了解实现细节有助于判断影响范围，避免遗漏Bug。软件测试是一项规范的技术职业。（Software Testing Is a Disciplined Technical Profession.）
实践：软件测试不是凭借个人意识来进行的，从测试策略、用例、执行、Bug管理都有具体的方法论，要注意学习相关测试技术和方法，遵循测试规范。
如对以上准则有疑问，可以评论或者私信问我，会尽快回复，也推荐大家可以看看Ron Patton《Software Testing》一书。
（喜欢或者有用可以点个赞，或者关注我，带你了解更多测试知识和行业信息）
