背景：参与了某银行管理驾驶舱二期的需求设计和测试工作，总结些测试的感受吧~
1.人人有责，要有总责
1.1 人人有责：
不论是需求人员、开发人员、测试人员，都需要以“挑刺儿”的态度来测试产品。
需求人员设计完毕后，这个界面是否满足业务的需求，业务通过后再开发。
开发人员开发完毕后，自己要点一下自己的界面，自测与需求是否一致。
测试人员（通常是需求人员兼着），更反复多次的测试，上前线发现的问题解决了，就不是问题，上线后的问题就真是问题了。
1.2 要有总责：
一定要有一个总负责人，跟踪测试进度。
一鼓作气，再而衰，三而竭，当由于这样或那样的原因导致项目进展困难时，在面对再而衰、三而竭的阶段时，总负责人一定要实时跟踪项目，要跟踪把测试点尽可能完成。
2.测试文档，特别重要
测试跟踪清单、测试跟踪矩阵，一个也不能少，防止问题跟丢利器。
测试跟踪清单，不用多说，把来自各方提出的测试问题记录，记录测试日期、测试问题、提出人、答复、状态，跟踪解决。
测试跟踪矩阵用于同一类测试的情况，需要对每一个条目进行同样细类的测试，整理一个测试矩阵，横向是测试点，纵向是测试条目，跟踪测试矩阵，能够防止漏测的情况。
3.测试过程，迭代迭代
初期测试着力点是对与错，后期测试着力点是更好。
测试关注点不一样，给开发人员感觉就是，为什么一直有问题？为什么不早提？
4.改需求，我也不想啊
一次性把程序开发完，一次性测试通过，上线，这是谁都想要的结果，但是貌似并不现实。
业务人员是否清楚地描述了需求？
需求分析人员是否准确地理解需求？
开发人员是否准确地理解需求？
测试人员是否认真地测试？
任何一个环节，都无法保证100%保证信息对称。
那么，
当你发现初期的需求不妥的地方，改不改？
当你发现有用户体验不好的地方，改不改？
对业务来说，是同一个功能，你做的和以前不一样，改不改？
这期间有各种权衡取舍，有解释说明，有无奈放弃，把自己负责的部分当做自己的孩子（这么肉麻啊），能给自己更多的坚持的动力，加油吧！
网友评论