测试人员如何编写给开发做参考的“可测试性标准”

ttma00

公司网站正处在祥设阶段，开发反映不知道该如何写[可测试性]，于是项目经理让我们测试组出一个标准，用于指导开发去写[可测试性]
请教各位该如何书写这样一个标准呢？
以下是我从网上搜集到的资料

软件的可测试性通常包含可操作性、可观察性、可控制性、可分解性、简单性、稳定性和易理解性：
•可操作性－“运行地越好，被测试的效率越高。”
•可观察性－“所看见的，就是所测试的。”
•可控制性－“对软件的控制越好，测试越能够被自动执行与优化。”
•可分解性－“通过控制测试范围，能够更好地分解问题，执行更灵巧的再测试。”
•简单性－“需要测试的内容越少，测试的速度越快。”
•稳定性－“改变越少，对测试的破坏越小。”
•易理解性－“得到的信息越多，进行的测试越灵巧。
但在实际软件设计中，通常考虑其可观察性和可控制性。其中可控制性有如下特性：
１）        所有可能的输出都产生于某种输入组合；
２）        通过各种输入组合，所有代码都可能被执行；
３）        测试工程师可直接控制软件和硬件的状态及变量；
４）        输入和输出格式保持一致且有结构；
５）        能够便利地对测试进行说明、自动化和再生；
６）        接口和模块易控制；
７）        业务流程和场景易控制。
可观察性特性见下节。
4.2        日志
详细的输出信息是记录软件事件的其中一种技术。日志可以帮助测试人员更容易理解软件的运转情况。也可以帮助发现一些容易忽略的bug。当bug出现，日志可以帮助定位到错误的代码和帮助调试。日志应重点体现可观察性，可观察性有如下特性：
1）        每个输入都有唯一的输出；
2）        系统状态和变量可见，或在运行中可查询；
3）        过去的系统状态和变量可见，或在运行中可查询（例如：事务日志）；
4）        所有影响输出的因素都可见；
5）        容易识别错误输出；
6）        通过自测机制自动侦测内部错误；
7）        可获取源代码；

ttma00

５５５５５５５５５没人回答
自己顶

lijiepig

本想要回答一通的，可是发现你贴的资料已经讲得非常到位了，不知道你对于这一摊资料有什么不明白的？

强调一点，对于考虑做自动化的项目，在接口和流程上应尽量要求开发要谨慎设计，免得后面又要改，浪费测试组人力又耽误进度。其实应该是这么说：对于一个有经验的高级测试工程师，会在参与系统设计的过程中就敏感地挑出流程和接口的隐患，这样后面就没太多好担心的了。这一点来源于1-丰富的经验；2-对需求的深刻理解；

其实从需求的层面上，可测试性需求确实不好写，会有“很泛、没什么要提的”的感觉，建议这里就笼统的写一写，但是要在具体模块的需求规格和概要设计上逐个给出明确的要求，怎么要求就参照你贴的资料，加上自己的分析就可以了。记住，确实有必要的才提，否则是对人力的浪费。