|
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,具体的实例化可以与开发共同完成。
|
|