博客分类：
关于如何参与一个新项目
- 1. 对于一个新项目,我首先要站在用户的角度了解这个产品.有可能的话,我会作为一个用户,以自己的账户和个人数据去使用产品.我努力使自己经历完整的用户体验.一旦有自己的真实数据在里面,你对一个产品的期待会彻底改变.在具备了用户心态之后,我会做下面一些事情
- 从头到尾理解产品.不管是整体的设计文档,还是主要功能的设计文档,我都会去看.只要有文档,我就会去看
- 在消化了这些文档之后,我开始关注项目的状态,特别是质量状态.我会去了解bug数量,问题的分组方式,已经报告的bug类型,最长时间未处理的bug,最近一些bug的类型等,我还会看一下发现-修复比例.只有熟悉了团队的全貌,才能真正有效地开展工作
- 2. 我还会去检查应用的代码库.对于每一个大一点的类,我会寻找关联的单元测试,并且运行这些测试查看是否能够通过.这些测试用例是否有效?是否完整?有集成或端到端的测试用例吗?他们仍然通过吗?历史通过率是多少?这些测试用例只是基本场景,还是也覆盖到了边界情况?代码库哪些包变化最多?哪些已经很长时间没有变更了?开发人员在测试方面的文档工作是否非常随意
- 3. 我还会评审所有的自动化测试.有自动化测试吗?是否还在运行且能运行通过吗?不管怎样,我都要去检查测试代码,理解每个测试步骤,看他们是否完整,看相关的假设,通过和失败点是否正确,是否有效.有时,自动化测试只覆盖了简单的测试.有时,自动化测试集包含了复杂的用户场景(这是一个非常好的迹象)
- 4. 我会了解团队的沟通方式和对他们对测试人员的期望.询问他们对测试的期望,会帮助发现开发团队没有测试过的内容
- 5. 接下去开始干正事.第一件事是把应用分解为合理的功能模块,有一点重叠没有关系.分解不能太细,以免纠缠于细节.也不能太粗,必须细致到可以罗列子模块和功能
- 6. 有了功能模块,就可以排列测试的优先级了.风险最大的是哪部分呢?到这里,我会再次检查bug库.这次是按模块对bug进行分组.这将加快已有bug的查找,减少重复的bug,更容易暴露不断重现的问题.
- 7. 接下来,我会按照优先级顺序更加细致地遍历所有模块,创建用户故事.对于那些需要详细的步骤说明才能绝对pass/fail的特性,通常会编写测试用例并链接到相应模块的用户故事
- 8. 我会查看不同类型的测试,检查覆盖情况:安全,兼容性,集成,探索式,回归,性能,负载等.
- 9. 有了以上基础材料,我的工作通常只是维护和更新的.更新测试用例,增加新特性的文档,更新变化了的模块的截屏或视频.最后,观察哪些bug遗漏到了生产环境,会告诉我们测试覆盖上的不足.
关于测试工作
- 当我坦诚地指出某些组件或领域的测试不应该由我负责,而应该由他们负责的时候,开发反而更加看重我的工作了.很多测试人员试图避免自我宣传,避免公开讨论他们不会测试的东西,担心这样做会使人看轻测试的价值.但在我的经验里,事实恰恰相反,开发会因此而尊重你
- 我认为测试的退出标准应该是:你有足够的信心,剩下的bug都属于那些使用率较低,出问题之后对用户影响也较低的模块.这就是为什么要按照一定的优先级处理应用的各种功能和环境支持
- 我会从对用户产生的影响的角度来说明为什么一个功能不能上线或整个发布都不能上线
- 当SET不清楚从何处开始实现测试或者工具时候,我会展示最需要测试的地方并以bug数据做支持
关于如何参与一个新项目
- 1. 对于一个新项目,我首先要站在用户的角度了解这个产品.有可能的话,我会作为一个用户,以自己的账户和个人数据去使用产品.我努力使自己经历完整的用户体验.一旦有自己的真实数据在里面,你对一个产品的期待会彻底改变.在具备了用户心态之后,我会做下面一些事情
- 从头到尾理解产品.不管是整体的设计文档,还是主要功能的设计文档,我都会去看.只要有文档,我就会去看
- 在消化了这些文档之后,我开始关注项目的状态,特别是质量状态.我会去了解bug数量,问题的分组方式,已经报告的bug类型,最长时间未处理的bug,最近一些bug的类型等,我还会看一下发现-修复比例.只有熟悉了团队的全貌,才能真正有效地开展工作
- 2. 我还会去检查应用的代码库.对于每一个大一点的类,我会寻找关联的单元测试,并且运行这些测试查看是否能够通过.这些测试用例是否有效?是否完整?有集成或端到端的测试用例吗?他们仍然通过吗?历史通过率是多少?这些测试用例只是基本场景,还是也覆盖到了边界情况?代码库哪些包变化最多?哪些已经很长时间没有变更了?开发人员在测试方面的文档工作是否非常随意
- 3. 我还会评审所有的自动化测试.有自动化测试吗?是否还在运行且能运行通过吗?不管怎样,我都要去检查测试代码,理解每个测试步骤,看他们是否完整,看相关的假设,通过和失败点是否正确,是否有效.有时,自动化测试只覆盖了简单的测试.有时,自动化测试集包含了复杂的用户场景(这是一个非常好的迹象)
- 4. 我会了解团队的沟通方式和对他们对测试人员的期望.询问他们对测试的期望,会帮助发现开发团队没有测试过的内容
- 5. 接下去开始干正事.第一件事是把应用分解为合理的功能模块,有一点重叠没有关系.分解不能太细,以免纠缠于细节.也不能太粗,必须细致到可以罗列子模块和功能
- 6. 有了功能模块,就可以排列测试的优先级了.风险最大的是哪部分呢?到这里,我会再次检查bug库.这次是按模块对bug进行分组.这将加快已有bug的查找,减少重复的bug,更容易暴露不断重现的问题.
- 7. 接下来,我会按照优先级顺序更加细致地遍历所有模块,创建用户故事.对于那些需要详细的步骤说明才能绝对pass/fail的特性,通常会编写测试用例并链接到相应模块的用户故事
- 8. 我会查看不同类型的测试,检查覆盖情况:安全,兼容性,集成,探索式,回归,性能,负载等.
- 9. 有了以上基础材料,我的工作通常只是维护和更新的.更新测试用例,增加新特性的文档,更新变化了的模块的截屏或视频.最后,观察哪些bug遗漏到了生产环境,会告诉我们测试覆盖上的不足.
关于测试工作
- 当我坦诚地指出某些组件或领域的测试不应该由我负责,而应该由他们负责的时候,开发反而更加看重我的工作了.很多测试人员试图避免自我宣传,避免公开讨论他们不会测试的东西,担心这样做会使人看轻测试的价值.但在我的经验里,事实恰恰相反,开发会因此而尊重你
- 我认为测试的退出标准应该是:你有足够的信心,剩下的bug都属于那些使用率较低,出问题之后对用户影响也较低的模块.这就是为什么要按照一定的优先级处理应用的各种功能和环境支持
- 我会从对用户产生的影响的角度来说明为什么一个功能不能上线或整个发布都不能上线
- 当SET不清楚从何处开始实现测试或者工具时候,我会展示最需要测试的地方并以bug数据做支持