原文：Top 20 Practical Software Testing Tips You Should Read Before Testing Any Application
Update Time: 2020.09.01
我希望所有的测试人员都阅读本文中更新的软件测试实践。仔细阅读每一个点并且在你日复一日的测试活动中实践它们。这是我希望读者可以通过这篇文章获得的东西。如果你不明白任何测试实践，请在底下评论区咨询更详细的说明。
即使不阅读这篇文章你仍然可以通过更多的经验学习到这些测试实践。但是为什么不在你犯错误之前就学到这些呢？
来吧！让我们看看他们。
以下是我从经验中获取到的一些最好的测试实践:
学习如何彻底分析你的测试结果。
不要忽略任何测试结果。最终测试结果可能是“通过”或者“失败”，但是排查失败的根本原因将会提供你解决问题的方法。测试人员将会得到尊重如果他们不仅仅是报告BUG同时提供解决方法的话。
学习最大化测试覆盖率
每一次你测试任何应用，100%的测试覆盖率是不可能的。但是你可以尝试接近100%。
分解应用为更小的方法模块
为了保证最大化测试覆盖率，把你的应用程序分解为更小的方法模块。写测试用例时需要细分到独立的，单独的模块。尽可能分解到更小。
举个例子，让我们假设你已经把你的网站应用按模块分解并且“接收用户信息”是其中的一个模块。你可以通过写测试用例把“用户信息”分解到更小的部分：比如UI 测试，安全测试，功能测试等。
应用所有表单字段类型和大小测试，对输入字段使用负面测试和验证测试并且为实现最大化覆盖率写所有这样的测试用例。
编写测试用例
根据需求文档编写有效条件（类）的测试用例然后再编写无效条件（类）的测试用例。这将会覆盖期望的和不期望的用户行为。
积极思考
带着找BUG/error的目的开始测试应用程序。不要认为被测应用没有任何BUG。如果你带着找BUG的目的测试应用程序那么你将会成功的找到细微BUG。
保证所有需求可测试
在需求分析和设计阶段编写测试用例，这样可以保证所有的需求可测试。
在开发人员开始编写代码之前写好测试用例
不要等待最终测试版本应用程序和你的测试用例同时出炉。认为你自己可以报告更多的BUG。让开发人员彻底分析你的测试用例开发一个高质量的应用程序。这将会减少返工时间。
组织和标识回归测试用例
尽可能组织和标识回归测试用例，这将会保证回归测试快速且有效。
性能测试是很重要的环节
在手工测试中，由于缺少大量数据因此性能测试总是被忽略。
找到一个可以为你的被测应用执行性能测试的方法。如果不可能通过手工创建测试数据，那么写一些简单的脚本区创建测试数据或者让开发人员写一个给你。
工程师最好不要测试自己的代码
在上一篇文章我们有提到过,应该要有足够的单元测试让开发人员发布应用程序，但是测试人员不应该强迫开发人员为了测试发布应用程序。
超出需求文档测试（Go beyond Requirement Testing.）
测试应用程序是否有不应该做的事。
使用之前的BUG图表进行回归测试
BUG图表 -为不同模块发现的BUG数量。跨模块BUG图表对于预测应用程序最可能出现BUG的部分是最有用的。
记录测试进度和观察结果
打开text文件当你在测试任何应用时，记录测试进度和观察结果，正在准备最终版本测试报告时会用到它。这个好习惯将会帮助你提供一个完整的，准确的测试报告和release细节。
为测试目的记录所有code变更
许多时候开发人员或测试人员会在代码库更改代码。
为测试目的记录所有code变更，并且 保证最终版本从客户端部署文件资源中移除所有变更。
确保开发人员远离测试环境
预测 在release或部署文本 任何配置信息的改变都不会出现是一个必要的步骤。有时候开发人员会修改系统或应用配置变更但是忘记在部署步骤中提及。
让测试人员参与需求和设计阶段
让测试人员参与需求和设计阶段是一个好的实践。这个方法可以让你知道更多应用程序的情况并且依赖这些来设计测试用例提高测试覆盖率。如果你没有被告知任何一个开发环节步骤那么你可以请求你的领导让你的测试团队参与所有会议。
分享好的测试经验
测试团队应该互相分享好的测试实践
与开发人员多交流
与开发人员 多交流以获知产品更多信息。面对面交流以解决纠纷避免任何误解。
不要把全部时间用在测试高优先级测试任务
描述一个清晰的，描述性的，确定的BUG报告。
不要只提供BUG症状，同时也要提供BUG影响范围并且可能的解决方案。
不要忘记测试时一个富有创造和挑战的额工作。最后，他完全依赖于你的能力和如何解决这些挑战的经验。