开发与测试关系处理换位思考.pdf

开发与测试关系处理 -- 换位思考 在整个项目中，其实开发和测试是一个团队，团队的目标是一致的，提高软件的质量。但是工作当中 因为职责的不一样，往往可能会造成分歧。为了更好的配合开发，测试人员要把握好以下几点： 1、在提交问题时，表达要清楚，重现步骤和预期结果要清楚。 2 、如果是概率性出现的问题，最好记录好有用的 日志并保持现场，这样能帮助开发更快解决问题，必 要时，要协助开发重现问题。 3 、在提交问题单时，可以先把严重的问题现象，步骤告诉开发，然后再提单。如果问题较多时，先提 严重的，小问题最后再提，因为开发也有绩效考核的，开发修改问题的效率高了，这样开发会很乐意和你 合作。 4 、有些有争执的问题或可改可不改的问题，和开发讨论没有结果，但是测试觉得实在是改了更好，可 以找上一级或者专家协商确定后，再提单，或者告诉开发兄弟，这个问题可以不用马上改，优先级很低， 要改了这个软件更好，更能体现开发的能力等。 5 、把开发当你朋友。遇到很严重的问题时，找开发聊，这个问题是怎样产生的，你是怎样解决的？然 后会问开发人员，你这样解决之后会不会产生 其他 的问题？然后会跟开发人员说，以你的能力你肯定能解 决这个问题的，相信你！这样会增加开发对你信任，也说明你和他是站在一起的。 试初学者对 软件测试 以及他们在实际 工作 中将怎样实现测试有很多问题。作为一个测试初学者，你需要对 软件测试这个职业有一定了解。下面的这些建议，对于你在软件测试的发展，肯定会有所帮助。这些测试 真理同样适用于有丰富测试经验的测试工程师。将下面的测试真理运用到你的测试中，你永远不会懊悔你 所做的一切。 熟悉你所测试的软件 在没有理解测试需求前，不要盲目开始测试。如果你不理解测试需求，你是无法判断软件功能是否依 照设计说明来进行设计，也无法判断功能是否有遗漏。在开始测试之前，重中之重的是要有清晰的软件需 求说明。 熟悉你工作领域的常识 我强调过很多次，对于你工作领域内的常识，你必须要有全面的了解。这些常识可以帮助你提出好的 解决问题的方法。如果你的建议的确有用，你的测试主管肯定会欣赏你的建议。不要仅仅是找出 BUG ，还 要尽量提出解决的办法。较好的工作领域知识，对你设计出覆盖面广而又效的 测试用例 是很有帮助的。想 要知道更多关于如何获得工作领域知识的信息，可以看一下这个帖子。 在测试中无假设 永远不要在开始测试时就假想软件中没有错误，软件工程师的职责就是不断的找出错误。 学习新的测试技术 毫无疑问，旧的测试技术在日常的测试中仍然发挥着举足轻重的作用，但是在你的测试工作中尝试引 入新的测试技术，会对你的测试工作更有帮助。不要过分的依赖书本上的知识。实践、实践、再实践。新 的测试理念所带来的惊喜可能让你自己都感到吃惊。 你不能保证每个 BUG 都不遗漏 不管你进行了多少测试工作，你永远不能确保软件的 BUG100% 的解决。尽管知道还有一些些普通的 或低等级的问题，但由于有某些限制，使得你的项目小组必须将该产品推向下一阶段。尽你所能的发现问 题，但是要优先侧重于那些基本的并且重要的功能上面。尽你所能去做好工作。 把自己当作最终用户 这是我的建议中的 NO.1 。不要把你作为一个技术人员， 把自己想象成客户或最终用户。 甚至考虑的要 比他们还多。做为最终用户来测试软件。想想他们会怎样使用软件。你拥有技术的优势，再加上最终用户 的的思维方式，将会使你的软件更容易受用户欢迎和认可，同时也可以轻松的通过验收测试。这也是我做 为一个测试新人的时候，从我的测试主管那里得到的第一个并且是最重要的一个建议。 100% 的测试覆盖率是不可能的 不要相信有 100% 的测试覆盖率。即使是只有一个简单的软件功能，也有数不尽的输入和组合。运用 一些测试方法，如边界分析法和等价划分法等，来限制你的测试用例数，使其在可控范围之内。 与开发人员建立良好的关系 一个测试员，你需要和 其他 的小组成员进行沟通，尤其是开发人员。很多时候，开发人员和测试人员 对同一问题会有不同的看法。此时将需要你运用善意而不伤害开发人员的沟通技巧去处理这类情况。如果 你是错的，那就认了它；如果你是对的