|
|
1. 你老大这样说，其实是他对到底怎么控制质量不清楚。不过优秀tester应该具有一定的QA水平。
2. 简易需求文档一般都能支撑测试策略的实例化，如，测试范围、测试执行实例化(测试方法、测试环境、测试工具等)、测试里程碑等
3. 简易需求文档通常不能支撑测试执行的细节部分，如，核心逻辑的测试执行实例化、用户感受用例的实例化等
供参考的测试前期步骤：
1. 需求分析：
1.1 需求分类：
先将需求文档的各个功能划分出来(我通常是按照物理存储数据的用途来分类，如，客户信息、消息信息、配置信息等)。并在每个类型下根据
需求文档描述的内容，再向下拆分1,2个层次（粒度不需要很细，比如最小粒度为页面或者控件类型就OK了，不需要把同类控件的每个元素都列举出来）
1.2 需求分析：
根据1.1的目录，整理出实现效果可能存在二义性的部分（如，某类消息数据存储，既可以存在服务器上，也可以存在本地，而需求文档中未指明实现方式）
将二义性的部分与设计或者开发人员沟通，确认实现效果。
2. 测试实例化：
2.1 先框定需要实例化的测试类型（功能、性能、本地化等），如果某类测试需要前置条件才能实现，将前置条件作为风险写明，而此类测试作为变量安排在后期的测试生命周期里。
测试类型的选择不难，主要还是需要你自己来度量测试的深度（通常可以和决策者以及开发人员沟通着来制定，如性能部分，只做长周期测试，不做负载测试等。你所有的沟通筹码只有2枚：成本和价值）
2.2 根据2.1框定范围，细化非功能测试的内容。如工具化使用哪种工具，碎片化选择哪些平台等）
3. 功能测试用例设计：
不建议使用测试用例，可以考虑使用测试要点来实现。粒度到可以清晰指导测试执行即可，如，标准文档编辑框(它可以代替文档框的字符类型、字符长度、存储等文本框的测试用例)
4. 注意事项：
4.1 在设计出口标准时，多和决策者/设计沟通，了解客户使用场景以及尽可能理解用户的实际期望。
4.2 此类项目需要频繁与开发人员沟通，在沟通过程中，最好能经常站在用户角度多想一下（很多时候，开发人员能做少就不愿意做多，所以在细节实现上，经常出现功能实现，但使用不便的情况）
4.3 测试里程碑多和开发Leader沟通，根据开发进度来调整测试进度。
4.4 如果涉及需要开发辅助的部分，如帮忙写个测试工具什么的。尽早与开发沟通，以便双方明确需求，以及方便开发安排计划。
4.5 这类项目都建议使用Monkey Test，具体的实例化可以与开发共同完成。
|
|
/2 
关于我们
发表于 2015-1-6 10:50:34
